마이크로 서비스에 적절한 크기는 얼마인가요? “너무 크지도 작지도 않은 것”이 효과가 있다고들 하며 이것이 물론 맞는 말이지만 실제로는 별로 도움이 되지 않습니다. 하지만 신중하게 디자인한 도메인 모델을 사용하여 시작하면 마이크로 서비스를 사용하는 이유를 쉽게 이해할 수 있습니다.
이 문서에서는 드론 배달 서비스를 실행 예제로 사용합니다. 시나리오 및 해당 참조 구현에 대한 자세한 내용은 여기에서 읽을 수 있습니다.
도메인 모델에서 마이크로 서비스로
이전 문서에서는 드론 배달 애플리케이션의 바인딩된 컨텍스트 집합을 정의했습니다. 그런 다음 바인딩된 컨텍스트 중 하나인 배송(Shipping) 바인딩된 컨텍스트를 자세히 살펴보고 바인딩된 컨텍스트에 대한 엔터티 집합, 집계 및 도메인 서비스를 확인했습니다.
이제 도메인 모델에서 애플리케이션 설계로 이동할 준비가 되었습니다. 도메인 모델에서 마이크로 서비스를 활용하기 위해 시작하는 방법은 다음과 같습니다.
바인딩된 컨텍스트로 시작합니다. 일반적으로 마이크로 서비스의 기능은 바인딩된 컨텍스트 하나에만 해당해야 합니다. 정의에 따라 제한된 컨텍스트는 특정 도메인 모델의 경계를 표시합니다. 마이크로 서비스가 서로 다른 도메인 모델을 함께 혼합한다는 것을 알게 되면, 다시 돌아가서 도메인 분석을 구체화해야 합니다.
그런 다음 도메인 모델에서 집계를 살펴봅니다. 집계는 마이크로 서비스에 적합한 경우가 많습니다. 잘 설계된 집계에는 다음과 같이 잘 설계된 마이크로 서비스의 특징이 많이 나타납니다.
- 집계는 데이터 액세스 또는 메시징과 같은 기술적인 문제보다는 비즈니스 요구 사항에서 파생됩니다.
- 집계에는 높은 기능적 응집력이 있어야 합니다.
- 집계는 지속성의 경계입니다.
- 집계는 느슨하게 연결되어야 합니다.
또한 도메인 서비스는 마이크로 서비스에 적합한 경우가 많습니다. 도메인 서비스는 여러 집계의 상태 비저장 작업입니다. 일반적으로 여러 마이크로 서비스를 포함하는 워크플로를 예로 들 수 있습니다. 드론 배달 애플리케이션에서 예를 확인할 수 있습니다.
끝으로, 비기능적 요구 사항을 고려하세요. 팀 규모, 데이터 유형, 기술, 확장성 요구 사항, 가용성 요구 사항 및 보안 요구 사항과 같은 요소를 확인합니다. 이러한 요소로 인해 마이크로 서비스를 둘 이상의 더 작은 서비스로 분해하거나 그 반대의 작업을 수행하고 여러 마이크로 서비스를 하나로 결합해야 하는 경우가 있습니다.
애플리케이션에서 마이크로 서비스를 확인한 후 다음 기준에 따라 디자인을 유효성을 검증합니다.
- 각 서비스에는 단일 책임이 있습니다.
- 서비스 간에 번잡한 호출이 없습니다. 기능을 두 개의 서비스로 나눠서 과도하게 번잡한 호출이 발생하는 경우, 해당 서비스가 동일한 서비스에 속한다는 징후일 수 입니다.
- 각 서비스는 소규모 팀이 독립적으로 작업할 수 있을 정도로 충분히 작습니다.
- 둘 이상의 서비스를 잠금 단계에서 배포해야 하는 상호 종속성이 없습니다. 다른 서비스를 다시 배포하지 않고도 서비스를 배포하는 것이 항상 가능합니다.
- 서비스는 밀접하게 결합되어 있지 않으며 독립적으로 진화할 수 있습니다.
- 서비스 경계로 인해 데이터 일관성이나 무결성에 문제가 발생하지 않습니다. 경우에 따라 단일 마이크로 서비스에 기능을 입력하여 데이터 일관성을 유지하는 것이 중요합니다. 즉, 강력한 일관성이 정말 필요한지 고려해야 합니다. 분산 시스템의 최종 일관성을 해결하기 위한 전략이 있으며, 서비스를 분해하는 이점이 최종 일관성을 관리하는 어려움보다 큰 경우가 많이 있습니다.
무엇보다 실용적인 디자인이 중요하며 도메인 기반 디자인은 반복적인 프로세스라는 것을 기억해야 합니다. 확신이 없다면 정교하지 않은 마이크로 서비스로 시작합니다. 마이크로 서비스를 두 개의 작은 서비스로 나누는 것이 기존의 여러 마이크로 서비스에서 기능을 리팩터링하는 것보다 쉽습니다.
예: 드론 배달 애플리케이션에 대한 마이크로 서비스 정의
앞에서 개발 팀은 배달, 패키지, 드론 및 계정이라는 네 가지 집계와 Scheduler 및 감독자라는 두 가지 도메인 서비스를 확인했습니다.
배달 및 패키지는 마이크로 서비스가 될만한 명백한 후보입니다. Scheduler와 감독자는 다른 마이크로 서비스가 수행하는 작업을 조정하기 때문에 이러한 도메인 서비스를 마이크로 서비스로 구현하는 것이 타당합니다.
드론 및 계정은 다른 바인딩된 컨텍스트에 속하기 때문에 고려할 필요가 있습니다. Scheduler에 대한 한가지 옵션은 드론 및 계정 바인딩된 컨텍스트를 직접 호출하는 것입니다. 또 다른 옵션은 배송(Shipping) 바인딩된 컨텍스트 내에 드론 및 계정 마이크로 서비스를 만드는 것입니다. 이러한 마이크로 서비스는 배송 컨텍스트에 적합한 API 또는 데이터 스키마를 노출하여 바인딩된 컨텍스트 사이에서 중재를 수행합니다.
드론 및 계정 바인딩된 컨텍스트의 세부 정보는 이 가이드의 범위를 벗어나기 때문에 이에 대한 모의 서비스를 참조 구현에 만들어 두었습니다. 하지만 이런 상황에서 고려할 몇 가지 요소가 있습니다.
다른 바인딩된 컨텍스트로 직접 호출하는 네트워크 오버헤드는 얼마나 되나요?
다른 바인딩된 컨텍스트의 데이터 스키마가 이 컨텍스트에 적합한가요? 아니면 이 바인딩된 컨텍스트에 맞는 스키마를 두는 것이 더 좋은가요?
다른 바인딩된 컨텍스트는 레거시 시스템인가요? 그렇다면 레거시 시스템과 최신 애플리케이션 사이에서 변환을 수행하여 손상 방지 레이어 역할을 하는 서비스를 만들 수 있습니다.
팀 구조는 어떤가요? 다른 바인딩된 컨텍스트를 담당하는 팀과 통신하기가 쉽나요? 그렇지 않은 경우 두 컨텍스트 사이에서 중재를 수행하는 서비스를 만들면 팀 간 통신 비용을 줄일 수 있습니다.
지금까지는 비기능적인 요구 사항을 고려하지 않았습니다. 애플리케이션의 처리량 요구 사항을 고려하여, 개발 팀은 클라이언트 요청에 대한 집계를 담당하는 별도의 집계 마이크로 서비스를 만들기로 결정했습니다. 이 마이크로 서비스는 들어오는 요청을 처리용 버퍼에 넣어서 부하 평준화를 구현합니다. Scheduler는 버퍼에서 요청을 읽고 워크플로를 실행합니다.
비기능적인 요구 사항으로 인해 팀에서 하나의 서비스를 추가로 만들었습니다. 여태까지 모든 서비스는 실시간으로 패키지를 예약하고 전달하는 프로세스에 관한 서비스였습니다. 시스템은 데이터 분석을 위해 장기 스토리지에 모든 배달 기록을 저장해야 합니다. 팀에서는 이것을 배달 서비스 담당으로 간주했습니다. 하지만 기록 분석을 위한 데이터 스토리지 요구 사항은 처리 중인 작업을 위한 데이터 스토리지 요구 사항과 매우 다릅니다(데이터 고려 사항 참조). 그래서 팀은 배달 서비스의 DeliveryTracking 이벤트를 수신 대기하고 장기 스토리지에 이벤트를 작성하는 별도의 Delivery History(배달 기록) 서비스를 만들기로 결정했습니다.
다음 다이어그램은 현 시점의 디자인입니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
다음 단계
이 시점에서, 디자인에서 각 마이크로 서비스의 목적과 기능을 명확하게 이해해야 합니다. 이제 시스템을 설계할 수 있습니다.