지난 몇 년 동안 마이크로서비스에 대해 이미 많은 이야기가 나왔지만, 새로운 분산 시스템이 모놀리스라는 오래된 사고방식으로 개발되는 것을 흔히 볼 수 있습니다. 몇 가지 핵심 개념에 대한 이해 없이 새로운 것을 구축할 때의 부작용은 염두에 두었던 목표와는 전혀 다르게 이전보다 더 많은 문제가 발생한다는 것입니다.
이 글에서는 지금까지 당연하게 여겨왔지만 마이크로서비스에 적용했을 때 잘못된 아키텍처로 이어질 수 있는 몇 가지 개념을 다루고자 합니다:
동기식 통화만 하기
모놀리스 아키텍처에서는 언제든 서비스를 호출할 수 있는 '올 오어 낫싱' 가용성에 익숙해져 있습니다. 하지만 마이크로서비스 세계에서는 우리가 의존하는 서비스가 온라인 상태일 것이라는 보장이 없습니다. 외부 서비스의 응답을 기다리는 동안 각 스레드가 일정 시간 동안 잠겨 있기 때문에 서비스가 느려지면 전체 시스템 속도가 느려질 수 있기 때문에 상황이 더 나빠질 수 있습니다.
잠긴/느린 스레드가 결국 전체 스레드 풀을 소모하는 방법
서비스 간 통신을 올바르게 구현하는 방법은 아직 학습 중이지만 경험상 다음과 같은 규칙을 따르는 것이 좋습니다. 모든 것을 비동기식으로 만들기지금까지 우리는 동기식 흐름을 비동기식으로 전환하는 능력을 충분히 발휘하지 못했기 때문에 첫 번째 도전 과제 중 하나가 여기에 있습니다.
다행히도 대부분의 사용 사례는 적절한 노력만 기울이면 비동기식으로 구현할 수 있습니다. 예를 들어 Amazon은 전체 주문 시스템을 이러한 방식으로 구현했으며, 거의 느낌 를 클릭하세요. 주문은 거의 대부분 성공적으로 완료되지만 결제에 문제가 있거나 제품이 품절된 경우 몇 분 또는 몇 시간 후에 이에 대한 정보와 취해야 할 조치를 알려주는 이메일 알림을 받게 됩니다. 이 접근 방식의 장점은 결제 또는 재고 서비스가 중단되더라도 사용자의 주문이 차단되지 않는다는 점입니다. 이것이 바로 비동기식 커뮤니케이션의 장점입니다.
물론 시스템의 모든 것이 비동기식일 수는 없으며 네트워크 불안정, 높은 지연 시간 또는 일시적인 서비스 불능과 같은 동기식 호출의 일반적인 문제를 처리하려면 로컬 캐시, 타임아웃, 재시도, 회로 차단기, 차단벽 등과 같은 연쇄적인 장애를 피하기 위한 일련의 패턴을 마련해야 했습니다. 이러한 개념을 구현하는 프레임워크는 시중에 많이 나와 있지만 넷플릭스 히스트릭스 는 현재 가장 잘 알려진 라이브러리입니다.
이 접근 방식이 본질적으로 잘못된 것은 아니며 여러 회사에서 꽤 잘 작동하고 있습니다. 유일한 단점은 각 서비스에 대해 추가적인 책임을 지게 되어 마이크로 서비스를 더욱 '마이크로'하게 만든다는 것입니다. 지난 2년 동안 이 문제를 해결하기 위한 몇 가지 옵션이 제안되었습니다. 예를 들어 서비스 메시 패턴은 사이드카 컨테이너의 형태로 이러한 복잡성을 외부화하려고 시도합니다:
저는 개인적으로 이 접근 방식을 좋아하는데, 특히 언어 불가지론적이기 때문에 작성된 언어에 관계없이 모든 마이크로서비스에서 작동한다는 점이 마음에 듭니다. 또 다른 장점은 표준화된 메트릭입니다. 라이브러리/프레임워크마다 재시도, 시간 초과, 회로 차단 등에 대해 약간 다른 알고리즘을 사용할 수 있기 때문입니다. 이러한 작은 차이는 생성된 메트릭에 상당한 영향을 미쳐 시스템 동작에 대한 신뢰할 수 있는 시각을 확보하는 것을 불가능하게 만들 수 있습니다.
업데이트: 서비스 메시 패턴에 대해 자세히 알아보려면 다음을 참조하세요, 이 훌륭한 프레젠테이션을 확인하세요..
요약하자면, 성공적인 아키텍처를 위해서는 서비스가 서로 통신하는 방식을 고려하는 것이 필수적이며, 종속성 연쇄를 피하기 위해 미리 계획해야 합니다. 서비스들이 서로에 대해 아는 것이 적을수록 아키텍처가 더 좋습니다.
모든 것에 RDBMS 사용
30년 동안 RDBMS를 독점해 왔기 때문에 많은 사람이 여전히 그렇게 생각하는 이유를 이해할 수 있습니다. 하지만 오늘날에는 거의 매일 새로운 데이터베이스가 탄생하고 있습니다. 두 개의 자바스크립트 프레임워크). 예전에는 데이터베이스를 선택하는 것이 5가지 중 하나를 선택하는 문제였다면, 오늘날에는 같은 작업을 하더라도 훨씬 더 많은 주의를 기울여야 합니다.
출처: db-engines.com - 초기 릴리스 날짜
As 마틴 파울러 말 12년 전에는 더 높은 성능, 더 낮은 비용 등 전문화된 스토리지를 선택하면 많은 이점이 있었습니다. 여기서는 RDBMS의 모든 단점(느린 읽기, 희박한 데이터, 임피던스 불일치, 조인 등)에 대해 설명하는 데 시간을 할애하지 않겠습니다. 그보다는 데이터베이스가 시스템의 전반적인 성능에 얼마나 중요한 역할을 하는지, 그리고 부적절한 선택은 결국 훨씬 더 많은 비용을 초래한다는 점을 다시 한 번 강조하고 싶습니다.
다국어 지속성의 이점은 명확하며, 솔루션의 성숙도는 다음과 같이 입증되었습니다. 수많은 성공적인 중요 사용 사례등을 예로 들 수 있습니다: 포켓몬 고, 에어비앤비, Viber, eBay, Sky, 아마데우스, Amazon, Google, LinkedIn 그리고 넷플릭스
5년 전만 해도 왜 아직 NoSQL을 시작하지 않았는지에 대한 '학습 곡선 주장'에 동의했을 것입니다. 하지만 그 이후로 많은 변화가 있었고, 일부 회사에서는 개발자와 DBA가 정말 쉽게 사용할 수 있도록 하기 위해 많은 노력을 기울였습니다(예: Couchbase 스프링 부팅/스프링 데이터 지원 또는 최근 출시된 쿠버네티스 오퍼레이터 는 대부분의 DBA 작업을 자동화하는 것을 목표로 합니다.
디버깅 및 관찰 가능성에 대해 생각하지 마세요.
언젠가는 결국 전체 시스템에 불일치를 확산시키는 분산 버그가 발생하게 됩니다. 그러면 어디에서 문제가 발생하는지 쉽게 파악할 방법이 없다는 것을 깨닫게 됩니다: 버그였나요? 네트워크 문제였나요? 일시적으로 서비스를 사용할 수 없었던 건가요?
그렇기 때문에 시스템을 어떻게 디버깅할지 미리 계획해야 합니다. 네트워킹의 경우 서비스 메시가 빠른 해결책이 될 수 있으며, 분산 로깅의 경우 다음과 같은 도구가 도움이 될 수 있습니다. FluentD 또는 Logstash 는 편리합니다. 하지만 엔티티가 특정 상태에 도달한 방법이나 서비스 간의 데이터 상관관계를 파악하는 방법에 대해 이야기할 때는 쉬운 도구가 없습니다.
이 문제를 해결하려면 다음을 사용할 수 있습니다. 이벤트 소싱/로깅. 이 패턴에서는 각 서비스가 애플리케이션의 상태에 대한 모든 변경 사항을 이벤트 객체에 저장(및 유효성 검사)하므로 특정 엔터티에 무슨 일이 발생했는지 확인해야 할 때마다 자연스럽게 해당 엔터티와 관련된 모든 이벤트 로그를 탐색하기만 하면 됩니다.
상태에 버전 관리 기능까지 추가하면, 오브젝트의 상태를 이전 상태로 설정하는 것만으로 일관성 없는 메시지를 수정한 다음 문제가 있는 오브젝트로부터 수신된 모든 메시지를 다시 재생할 수 있으므로 불일치를 수정하는 것이 훨씬 쉬워집니다.
버전 관리와 로깅은 모두 비동기식으로 수행할 수 있으며 이 데이터를 자주 쿼리하지 않을 것이므로 시스템 디버깅/감사를 위한 저렴한 사내 솔루션입니다. 다음 주에 이 패턴에 대한 심층 분석을 게시할 예정이니 일주일만 기다려 주세요.
마이크로서비스를 디버깅하는 데 도움이 되는 다른 많은 프레임워크/패턴이 있지만, 모두 작동하려면 일반적으로 단일 분산 전략을 요구합니다. 안타깝게도 그러한 것이 필요하다는 것을 깨닫는 순간 이미 너무 늦어 전체 리팩토링에 상당한 시간을 소비해야 합니다. 이것이 바로 시작하기 전에 시스템을 어떻게 관찰/디버그할 것인지 정의해야 하는 주된 이유 중 하나입니다.
질문이 있으시면 언제든지 다음 주소로 트윗해 주세요. @deniswsrosa
