마이크로 서비스당 데이터 주권

마이크로 서비스 아키텍처의 중요한 규칙은 각 마이크로 서비스가 도메인 데이터 및 논리를 소유해야 한다는 것입니다. 전체 애플리케이션이 논리와 데이터를 소유하는 것처럼 각 마이크로 서비스는 마이크로 서비스당 독립적인 배포를 통해 자율 수명 주기에 따라 논리 및 데이터를 소유해야 합니다.

즉, 도메인의 개념적 모델은 하위 시스템 또는 마이크로 서비스 간에 다릅니다. CRM(고객 관계 관리) 애플리케이션, 트랜잭션 구매 하위 시스템 및 고객 지원 하위 시스템이 각각 고유한 고객 엔터티 특성 및 데이터를 호출하고 각각 서로 다른 BC(제한된 컨텍스트)를 사용하는 엔터프라이즈 애플리케이션을 고려합니다.

이 원칙은 각 제한된 컨텍스트 또는 자치 하위 시스템 또는 서비스가 도메인 모델(데이터와 논리 및 동작)을 소유해야 하는 DDD(도메인 기반 디자인)와 유사합니다. 각 DDD 바인딩된 컨텍스트는 하나의 비즈니스 마이크로 서비스(하나 또는 여러 서비스)와 관련이 있습니다. 경계 컨텍스트 패턴에 대한 이 지점은 다음 섹션에서 확장됩니다.

반면에 많은 애플리케이션에서 사용되는 기존의(모놀리식 데이터) 접근 방식은 단일 중앙 집중식 데이터베이스 또는 몇 개의 데이터베이스를 갖는 것입니다. 그림 4-7과 같이 전체 애플리케이션 및 모든 내부 하위 시스템에 사용되는 정규화된 SQL 데이터베이스인 경우가 많습니다.

그림 4-7. 데이터 주권 비교: 모놀리식 데이터베이스 및 마이크로 서비스

기존의 접근 방식에서는 일반적으로 계층화된 아키텍처에서 모든 서비스에서 공유되는 단일 데이터베이스가 있습니다. 마이크로 서비스 접근 방식에서 각 마이크로 서비스는 모델/데이터를 소유합니다. 중앙 집중식 데이터베이스 접근 방식은 처음에는 더 간단해 보이며 여러 하위 시스템의 엔터티를 다시 사용하여 모든 항목을 일관되게 만들 수 있습니다. 그러나 현실은 다양한 하위 시스템을 제공하고 대부분의 경우 필요하지 않은 특성과 열을 포함하는 거대한 테이블로 끝납니다. 마치 짧은 트레일을 하이킹하고, 하루 종일 자동차 여행을 하고, 지리를 배우기 위해 동일한 물리적 지도를 사용하는 것과 같습니다.

일반적으로 단일 관계형 데이터베이스를 사용하는 모놀리식 애플리케이션에는 ACID 트랜잭션 과 SQL 언어라는 두 가지 중요한 이점이 있으며, 둘 다 애플리케이션과 관련된 모든 테이블과 데이터에서 작동합니다. 이 방법은 여러 테이블의 데이터를 결합하는 쿼리를 쉽게 작성하는 방법을 제공합니다.

그러나 마이크로 서비스 아키텍처로 이동하면 데이터 액세스가 훨씬 더 복잡해집니다. 마이크로 서비스 또는 제한된 컨텍스트 내에서 ACID 트랜잭션을 사용하는 경우에도 각 마이크로 서비스가 소유한 데이터는 해당 마이크로 서비스에 대해 비공개이며 API 엔드포인트(REST, gRPC, SOAP 등)를 통해서만 동기적으로 액세스하거나 메시징(AMQP 또는 이와 유사)을 통해 비동기적으로 액세스해야 합니다.

데이터를 캡슐화하면 마이크로 서비스가 느슨하게 결합되고 서로 독립적으로 발전할 수 있습니다. 여러 서비스가 동일한 데이터에 액세스하는 경우 스키마 업데이트에는 모든 서비스에 대한 조정된 업데이트가 필요합니다. 이렇게 하면 마이크로 서비스 수명 주기 자율성이 손상됩니다. 그러나 분산 데이터 구조는 마이크로 서비스에서 단일 ACID 트랜잭션을 만들 수 없다는 것을 의미합니다. 즉, 비즈니스 프로세스가 여러 마이크로 서비스에 걸쳐 있는 경우 최종 일관성을 사용해야 합니다. 나중에 설명하겠습니다. 따라서 무결성 제약 조건을 만들거나 별도의 데이터베이스 간에 분산 트랜잭션을 사용할 수 없으므로 간단한 SQL 조인보다 구현하기가 훨씬 어렵습니다. 마찬가지로, 다른 많은 관계형 데이터베이스 기능은 여러 마이크로 서비스에서 사용할 수 없습니다.

더 나아가 다른 마이크로 서비스는 종종 다른 종류의 데이터베이스를 사용합니다. 최신 애플리케이션은 다양한 종류의 데이터를 저장하고 처리하며 관계형 데이터베이스가 항상 최선의 선택은 아닙니다. 일부 사용 사례의 경우 Azure CosmosDB 또는 MongoDB와 같은 NoSQL 데이터베이스에는 SQL Server 또는 Azure SQL Database와 같은 SQL 데이터베이스보다 더 편리한 데이터 모델이 있고 더 나은 성능과 확장성을 제공할 수 있습니다. 다른 경우에는 관계형 데이터베이스가 여전히 가장 좋은 방법입니다. 따라서 마이크로 서비스 기반 애플리케이션은 종종 SQL 및 NoSQL 데이터베이스를 혼합하여 사용하며, 이를 다각형 지속성 접근 방식이라고도 합니다.

데이터 스토리지에 대한 분할된 다각형 영구 아키텍처에는 많은 이점이 있습니다. 여기에는 느슨하게 결합된 서비스와 향상된 성능, 확장성, 비용 및 관리 효율성이 포함됩니다. 그러나 이 장 뒷부분에 나오는 "도메인 모델 경계 식별"에 설명된 대로 일부 분산 데이터 관리 문제를 소개할 수 있습니다.

마이크로 서비스와 제한된 컨텍스트 패턴 간의 관계

마이크로 서비스의 개념은 DDD(도메인 기반 디자인)의 BC(경계 컨텍스트) 패턴에서 파생됩니다. DDD는 대형 모델을 여러 BC로 분할하고 경계에 대해 명시적으로 지정하여 처리합니다. 각 BC에는 자체 모델 및 데이터베이스가 있어야 합니다. 마찬가지로 각 마이크로 서비스는 관련 데이터를 소유합니다. 또한 각 BC에는 일반적으로 소프트웨어 개발자와 도메인 전문가 간의 통신을 돕는 고유한 유비쿼터스 언어 가 있습니다.

유비쿼터스 언어의 해당 용어(주로 도메인 엔터티)는 서로 다른 도메인 엔터티가 동일한 ID(즉, 스토리지에서 엔터티를 읽는 데 사용되는 고유 ID)를 공유하는 경우에도 서로 다른 제한된 컨텍스트에서 서로 다른 이름을 가질 수 있습니다. 예를 들어 사용자 프로필 바운디드 컨텍스트에서 사용자 도메인 엔터티는 주문 바운디드 컨텍스트에서 Buyer 도메인 엔터티와 정체성을 공유할 수 있습니다.

따라서 마이크로 서비스는 제한된 컨텍스트와 비슷하지만 분산 서비스임을 지정합니다. 각 제한된 컨텍스트에 대해 별도의 프로세스로 빌드되며, HTTP/HTTPS, WebSockets 또는 AMQP와 같이 앞에서 설명한 분산 프로토콜을 사용해야 합니다. 그러나 제한된 컨텍스트 패턴은 제한된 컨텍스트가 분산 서비스인지 아니면 모놀리식 배포 애플리케이션 내의 논리적 경계(예: 제네릭 하위 시스템)인지를 지정하지 않습니다.

각 제한된 컨텍스트에 대한 서비스를 정의하는 것이 시작하기에 좋은 위치라는 점을 강조하는 것이 중요합니다. 하지만 디자인을 제한할 필요는 없습니다. 경우에 따라 여러 물리적 서비스로 구성된 제한된 컨텍스트 또는 비즈니스 마이크로 서비스를 디자인해야 합니다. 궁극적으로 두 패턴인 -Bounded 컨텍스트와 마이크로서비스는 밀접하게 관련되어 있습니다.

DDD는 분산 마이크로 서비스의 형태로 실제 경계를 가져오면 마이크로 서비스의 이점을 누릴 수 있습니다. 그러나 마이크로 서비스 간에 모델을 공유하지 않는 것과 같은 아이디어는 제한된 컨텍스트에서도 원하는 것입니다.

추가 리소스

• 크리스 리처드슨. 패턴: 서비스당 데이터베이스
  https://microservices.io/patterns/data/database-per-service.html

• 마틴 파울러. 바운디드컨텍스트 (BoundedContext)
  https://martinfowler.com/bliki/BoundedContext.html

• 마틴 파울러. PolyglotPersistence
  https://martinfowler.com/bliki/PolyglotPersistence.html

• 알베르토 브란돌리니. 컨텍스트 매핑을 사용하는 전략적 도메인 기반 디자인
  https://www.infoq.com/articles/ddd-contextmapping