サービスごとのデータベースパターン

各マイクロサービスはそれぞれ独自のデータストアに情報を格納し、そこから情報を取り出すことができるため、疎結合はマイクロサービスアーキテクチャの核となる特性です。サービスごとのデータベースパターンを導入することで、アプリケーションやビジネス要件に最も適したデータストア (例えば、リレーショナルデータベースや非リレーショナルデータベースなど) を選択できます。つまり、マイクロサービスはデータレイヤーを共有せず、マイクロサービスの個々のデータベースを変更しても他のマイクロサービスには影響せず、個々のデータストアには他のマイクロサービスから直接アクセスできず、永続データには 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) を使用します。

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

サービスごとのデータベースパターンを使用する場合、次のような欠点があります。