マイクロサービスあたりのデータ主権

マイクロサービス アーキテクチャの重要なルールは、各マイクロサービスがドメイン データとロジックを所有する必要があるということです。 完全なアプリケーションがロジックとデータを所有するのと同様に、各マイクロサービスは、マイクロサービスごとに独立したデプロイを使用して、自律的なライフサイクルの下でロジックとデータを所有する必要があります。

つまり、ドメインの概念モデルは、サブシステムまたはマイクロサービスによって異なります。 顧客関係管理 (CRM) アプリケーション、トランザクション購入サブシステム、およびカスタマー サポート サブシステムがそれぞれ一意の顧客エンティティ属性とデータを呼び出し、それぞれが異なる有界コンテキスト (BC) を使用するエンタープライズ アプリケーションについて考えます。

この原則は 、ドメイン駆動型設計 (DDD) で似ています。各 有界コンテキスト または自律サブシステムまたはサービスは、ドメイン モデル (データとロジックと動作) を所有する必要があります。 各 DDD 境界コンテキストは、1 つのビジネス マイクロサービス (1 つまたは複数のサービス) に関連付けます。 境界コンテキスト パターンに関するこの点は、次のセクションで展開されます。

一方、多くのアプリケーションで使用される従来の (モノリシック データ) アプローチは、単一の一元化されたデータベースまたは少数のデータベースを持つことです。 これは、多くの場合、図 4-7 に示すように、アプリケーション全体とそのすべての内部サブシステムに使用される正規化された SQL データベースです。

図 4-7 データ主権の比較: モノリシック データベースとマイクロサービス

従来のアプローチでは、すべてのサービスで共有される単一のデータベースがあり、通常は階層化アーキテクチャに存在します。 マイクロサービス アプローチでは、各マイクロサービスがそのモデル/データを所有します。 一元化されたデータベースアプローチは、最初は単純に見え、さまざまなサブシステムのエンティティを再利用してすべてを一貫性のあるものにできるようです。 しかし、実際には、多くの異なるサブシステムに対応し、ほとんどの場合必要のない属性と列を含む巨大なテーブルが得られます。 これは、短いトレイルをハイキングしたり、1日の車の旅をしたり、地理を学ぶのに同じ物理的な地図を使おうとするようなものです。

通常は 1 つのリレーショナル データベースを持つモノリシック アプリケーションには、 ACID トランザクション と SQL 言語という 2 つの重要な利点があります。両方とも、アプリケーションに関連するすべてのテーブルとデータで動作します。 この方法では、複数のテーブルのデータを結合するクエリを簡単に記述できます。

ただし、マイクロサービス アーキテクチャに移行すると、データ アクセスがはるかに複雑になります。 マイクロサービスまたは有界コンテキスト内で ACID トランザクションを使用する場合でも、各マイクロサービスが所有するデータはそのマイクロサービスに対してプライベートであり、API エンドポイント (REST、gRPC、SOAP など) を介して同期的にアクセスするか、メッセージング (AMQP または同様) を介して非同期的にアクセスする必要があることを考慮することが重要です。

データをカプセル化することで、マイクロサービスが疎結合され、相互に独立して進化できるようになります。 複数のサービスが同じデータにアクセスしている場合、スキーマの更新では、すべてのサービスに対する調整された更新が必要になります。 これにより、マイクロサービスのライフサイクルの自律性が損なわれる可能性があります。 ただし、分散データ構造は、マイクロサービス間で 1 つの ACID トランザクションを作成できないことを意味します。 つまり、ビジネス プロセスが複数のマイクロサービスにまたがる場合は、最終的な整合性を使用する必要があります。 これは、後で説明するように、整合性制約を作成したり、個別のデータベース間で分散トランザクションを使用したりできないため、単純な SQL 結合よりもはるかに実装が困難です。 同様に、他の多くのリレーショナル データベース機能は、複数のマイクロサービスでは使用できません。

さらに進むには、さまざまなマイクロサービスでさまざまな 種類 のデータベースが使用されることがよくあります。 最新のアプリケーションでは、さまざまな種類のデータが格納および処理され、リレーショナル データベースが常に最適な選択とは限りません。 一部のユース ケースでは、Azure CosmosDB や MongoDB などの NoSQL データベースの方が便利なデータ モデルがあり、SQL Server や Azure SQL Database などの SQL データベースよりも優れたパフォーマンスとスケーラビリティが提供される場合があります。 それ以外の場合でも、リレーショナル データベースが最適なアプローチです。 そのため、マイクロサービス ベースのアプリケーションでは、多くの場合、SQL データベースと NoSQL データベースの組み合わせが使用されます。これは、 ポリグロット永続化 アプローチと呼ばれることもあります。

データストレージのためのパーティション化された多言語永続性アーキテクチャには、多くの利点があります。 これには、疎結合されたサービスと、パフォーマンス、スケーラビリティ、コスト、管理容易性の向上が含まれます。 ただし、この章で後述する「ドメイン モデル境界の識別」で説明されているように、分散データ管理の課題をいくつか紹介できます。

マイクロサービスと境界コンテキスト パターンの関係

マイクロサービスの概念は、ドメイン駆動設計 (DDD) の境界コンテキスト (BC) パターンから派生します。 DDD では、大規模なモデルを複数の BC に分割し、その境界について明示的に扱います。 各 BC には、独自のモデルとデータベースが必要です。同様に、各マイクロサービスは関連データを所有します。 さらに、通常、各 BC には、ソフトウェア開発者とドメインエキスパート間のコミュニケーションを支援する独自の ユビキタス言語 があります。

ユビキタス言語の用語 (主にドメイン エンティティ) は、異なるドメイン エンティティが同じ ID (つまり、ストレージからエンティティを読み取るために使用される一意の ID) を共有している場合でも、異なる境界コンテキストで異なる名前を持つことができます。 たとえば、ユーザー プロファイルの境界付きコンテキストでは、ユーザー ドメイン エンティティは、境界付けられたコンテキストの順序で、購入者ドメイン エンティティと ID を共有する場合があります。

したがって、マイクロサービスは有界コンテキストに似ていますが、分散サービスであることを指定します。 これは境界コンテキストごとに個別のプロセスとして構築されており、HTTP/HTTPS、WebSocket、 AMQP など、前述の分散プロトコルを使用する必要があります。 ただし、Bounded Context パターンでは、境界付きコンテキストが分散サービスであるかどうか、または単にモノリシック展開アプリケーション内の論理境界 (汎用サブシステムなど) であるかどうかを指定しません。

各有界コンテキストのサービスを定義することは、開始するのに適した場所であることを強調することが重要です。 ただし、設計を制約する必要はありません。 場合によっては、複数の物理サービスで構成される境界コンテキストまたはビジネス マイクロサービスを設計する必要があります。 しかし、最終的には、コンテキストとマイクロサービス -Bounded 両方のパターンが密接に関連しています。

DDD は、分散マイクロサービスの形式で実際の境界を取得することで、マイクロサービスからメリットを得られます。 ただし、マイクロサービス間でモデルを共有しないなどのアイデアは、有界コンテキストでも必要です。

その他のリソース

• Chris Richardson。 パターン: サービスあたりのデータベース数
  https://microservices.io/patterns/data/database-per-service.html

• Martin Fowler。 境界づけられたコンテキスト
  https://martinfowler.com/bliki/BoundedContext.html

• Martin Fowler。 PolyglotPersistence
  https://martinfowler.com/bliki/PolyglotPersistence.html

• アルベルト・ブランドリーニ コンテキスト マッピングを使用した戦略的ドメイン駆動設計
  https://www.infoq.com/articles/ddd-contextmapping