D atabase-per-service パターン

各マイクロサービスはそれぞれ独自のデータストアに情報を格納し、そこから情報を取り出すことができるため、疎結合はマイクロサービスアーキテクチャの核となる特性です。この database-per-service パターンをデプロイすることで、アプリケーションとビジネス要件に最適なデータストア (リレーショナルデータベースや非リレーショナルデータベースなど) を選択します。つまり、マイクロサービスはデータレイヤーを共有せず、マイクロサービスの個々のデータベースを変更しても他のマイクロサービスには影響せず、個々のデータストアには他のマイクロサービスから直接アクセスできず、永続データには API のみがアクセスすることになります。データストアを分離すると、アプリケーション全体の耐障害性が向上し、1 つのデータベースが単一障害点になることがなくなります。

次の図では、「セールス」、「カスタマー」、「コンプライアンス」の各マイクロサービスによってさまざまな AWS データベースが使用されています。これらのマイクロサービスは AWS Lambda 関数としてデプロイされ、Amazon API Gateway の API を介してアクセスされます。AWS Identity and Access Management(IAM) ポリシーにより、データは非公開に保たれ、マイクロサービス間で共有されないことが保証されます。各マイクロサービスは、それぞれの要件を満たすデータベースタイプを使用します。たとえば、「セールス」は Amazon Aurora を使用し、「カスタマー」は Amazon DynamoDB を使用し、「コンプライアンス」は SQL Server 用の Amazon Relational Database Service (Amazon RDS) を使用します。

このパターンの使用を検討すべきなのは、次のような場合です。

• マイクロサービス間の疎結合が必要です。

• マイクロサービスは、データベースに対するコンプライアンスやセキュリティ要件が異なります。

• スケーリングをよりきめ細かく制御する必要があります。

database-per-service パターンを使用することには、次の欠点があります。

• 複数のマイクロサービスやデータストアにまたがる複雑なトランザクションやクエリを実装するのは難しいかもしれません。

• 複数のリレーショナルデータベースと非リレーショナルデータベースを管理する必要があります。

• データストアは、CAP 定理の 2 つの要件、つまり、一貫性、可用性、または分断耐性を満たす必要があります。

注記

database-per-service パターンを使用する場合は、 API 構成パターンまたは をデプロイCQRS パターン して、複数のマイクロサービスにまたがるクエリを実装する必要があります。