기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
D atabase-per-service 패턴
느슨한 결합은 마이크로서비스 아키텍처의 핵심 특징입니다. 이를 통해 개별 마이크로서비스가 독립적으로 자체 데이터 스토어에서 정보를 저장하고 검색할 수 있기 때문입니다. database-per-service 패턴을 배포하여 애플리케이션 및 비즈니스 요구 사항에 가장 적합한 데이터 저장소 (예: 관계형 또는 비관계형 데이터베이스) 를 선택합니다. 즉, 마이크로서비스는 데이터 계층을 공유하지 않고, 마이크로서비스의 개별 데이터베이스를 변경해도 다른 마이크로서비스에 영향을 주지 않으며, 개별 데이터 스토어에 다른 마이크로서비스가 직접 액세스할 수 없으며, 영구 데이터는 API로만 액세스할 수 있습니다. 또한 데이터 스토어를 분리하면 전체 애플리케이션의 복원력이 향상되고 단일 데이터베이스가 단일 장애 지점이 되지 않도록 할 수 있습니다.
다음 그림에서는 ‘‘판매”’, “고객” 및 “규정 준수” 마이크로서비스가 서로 다른 AWS 데이터베이스를 사용합니다. 이러한 마이크로서비스는 AWS Lambda 함수로 배포되며 Amazon API Gateway API를 통해 액세스됩니다. AWS Identity and Access Management (IAM) 정책은 데이터가 비공개로 유지되고 마이크로서비스 간에 공유되지 않도록 보장합니다. 각 마이크로서비스는 개별 요구 사항을 충족하는 데이터베이스 유형을 사용합니다. 예를 들어 “판매”는 Amazon Aurora를 사용하고, “고객”은 Amazon DynamoDB를, “규정 준수”는 SQL Server용 Amazon Relational Database Service(RDS)를 사용합니다.
다음과 같은 경우에는 이 패턴을 사용하는 것이 좋습니다:
-
마이크로서비스 간에 느슨한 결합이 필요합니다.
-
마이크로서비스의 데이터베이스에 대한 규정 준수 또는 보안 요구 사항이 다릅니다.
-
규모 조정에 대한 보다 세밀한 제어가 필요합니다.
database-per-service 패턴 사용에는 다음과 같은 단점이 있습니다.
-
여러 마이크로서비스 또는 데이터 스토어에 걸쳐 있는 복잡한 트랜잭션과 쿼리를 구현하는 것은 어려울 수 있습니다.
-
여러 관계형 및 비관계형 데이터베이스를 관리해야 합니다.
-
데이터 스토어는 CAP 정리
요구 사항, 일관성, 가용성, 파티션 내성 중에서 두 가지를 충족해야 합니다.
