S hared-database-per-service パターン - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

S hared-database-per-service パターン

この shared-database-per-service パターンでは、同じデータベースが複数のマイクロサービスによって共有されます。このパターンを採用する前に、アプリケーションのアーキテクチャを慎重に評価し、ホトテーブル (複数のマイクロサービス間で共有される単一のテーブル) を避ける必要があります。また、データベースの変更にはすべて下位互換性が必要です。たとえば、開発者が列やテーブルを削除できるのは、すべてのマイクロサービスの現在のバージョンと以前のバージョンでオブジェクトが参照されていない場合のみです。

次の図では、保険データベースはすべてのマイクロサービスで共有されており、IAM ポリシーによってデータベースへのアクセスが許可されています。これにより、開発時間が連動します。たとえば、「セールス」マイクロサービスの変更では、スキーマの変更を「カスタマー」マイクロサービスと調整する必要があります。このパターンでは、開発チーム間の依存関係が減ることはなく、すべてのマイクロサービスが同じデータベースを共有するため、実行時のカップリングが発生します。たとえば、長時間実行される「セールス」トランザクションは「カスタマー」テーブルをロックし、これにより「カスタマー」トランザクションがブロックされることがあります。

S hared-database-per-service パターン

以下の場合は、このパターンの使用を検討してください。

  • 既存のコードベースをあまりリファクタリングしたくない。

  • データ整合性を確保するには、原子性、一貫性、分離性、および耐久性 (ACID) を提供するトランザクションを使用します。

  • 1 つのデータベースのみを維持および運用したい。

  • 既存のマイクロサービス間の相互依存性があるため、 database-per-service パターンの実装は困難です。

  • 既存のデータレイヤーを完全に再設計する必要はありません。