分散データ管理

モノリシックなアプリケーションは、通常、大規模なリレーショナルデータベースによってサポートされ、すべてのアプリケーションコンポーネントに共通のデータモデルが 1 つ定義されます。中央データベースのようなマイクロサービスアプローチでは、分散型の独立したコンポーネントを構築するという目標を達成できません。マイクロサービスの各コンポーネントに、データ永続レイヤーが必要です。

ただし、分散データ管理には新しい課題もあります。CAP 定理の結果として、分散マイクロサービスアーキテクチャでは、本質的にパフォーマンスを優先するため、整合性が犠牲になります。したがって、結果整合性を組み込む必要があります。

分散システムでは、ビジネストランザクションが複数のマイクロサービスに及ぶことがあります。複数のマイクロサービスで 1 つの ACID トランザクションを使用することはできないため、部分的な実行で終わる場合があります。このような場合、処理済みのトランザクションをやり直すためにコントロールロジックが必要になります。この目的のために、分散 Saga パターンが一般的に使用されます。ビジネストランザクションが失敗した場合、それまでのトランザクションでなされた変更を元に戻すために、Saga が一連の補正トランザクションをオーケストレートします。次の図に示すとおり、AWS Step Functions を使用すると、Saga 実行コーディネーターを簡単に実装できます。

Saga 実行コーディネーター

コアデータ管理ツールおよび手順でキュレートした重要なリファレンスデータの一元化されたストアを構築すると、マイクロサービスで重要なデータを同期し、さらに状態をロールバックできる場合があります。AWS Lambda を Amazon CloudWatch Events のスケジュールと組み合わせて使用すれば、クリーンアップおよび重複排除のシンプルなメカニズムを構築できます。

状態の変化が複数のマイクロサービスに影響を与えることがよくあります。このような場合、イベントソーシングが役立つパターンであることがわかっています。イベントソーシングの背景にある主な考え方は、アプリケーションの変更をすべてイベントレコードとして表現し、保持することです。アプリケーションの状態を保持する代わりに、データがイベントのストリームとして保存されます。データベーストランザクションのログ記録とバージョン管理のシステムは、よく知られているイベントソーシングの 2 つの例です。イベントソーシングにはいくつかの利点があります。任意の時点で状態の判断や再構築を行うことができます。また、永続的な監査証跡が自動的に生成され、デバッグも容易になります。

マイクロサービスアーキテクチャのコンテキストでは、イベントソーシングを通じてパブリッシュ/サブスクライブパターンを使用することで、アプリケーションのさまざまなパーツのデカップリングを行うことができます。また、同一のイベントデータをさまざまなデータモデルに提供してマイクロサービスを分離できます。イベントソーシングは、コマンド、クエリ、責任、分離 (CQRS) パターンと組み合わせて使用されることが多く、書き込みのワークロードから読み取りをデカップリングして、両方のパフォーマンス、スケーラビリティ、セキュリティを最適化します。従来のデータ管理システムでは、コマンドとクエリは同じデータリポジトリに対して実行されます。

次の図は、AWS でイベントソーシングパターンをどのように実装できるかを示しています。Amazon Kinesis Data Streams は、中央イベントストアという主要なコンポーネントとして機能し、アプリケーションの変更をイベントとしてキャプチャし、Amazon S3 に保存します。図は、Amazon API Gateway、AWS Lambda、Amazon DynamoDB で構成される 3 つの異なるマイクロサービスを示しています。矢印は、イベントの流れを示しています。マイクロサービス 1 は、イベントの状態の変化を検出すると、Kinesis Data Streams にメッセージを書き込むことで、イベントを発行します。すべてのマイクロサービスは、AWS Lambda で独自の Kinesis Data Streams アプリケーションを実行しています。これは、メッセージのコピーを読み取ってマイクロサービスとの関連性に基づいてフィルタリングし、必要に応じて次の処理のためにメッセージを転送します。関数からエラーが返されると、Lambda は、処理が成功するか、データの有効期限が切れるまでバッチを再試行します。シャードの停止を避けるには、より小さいバッチサイズで再試行するか、再試行数を制限するか、古すぎるレコードを破棄するように、イベントソースマッピングを設定できます。破棄したイベントを保持するには、失敗したバッチに関する詳細を Amazon Simple Queue Service (Amazon SQS) キューまたは Amazon Simple Notification Service (Amazon SNS) トピックに送信するように、イベントソースマッピングを設定できます。

AWS でのイベントソーシングパターン

Amazon S3 は、すべてのマイクロサービスにわたってすべてのイベントを永続的に保存し、アプリケーションの状態をデバッグまたは復旧したり、アプリケーションの変更を監査したりするときに、信頼性の高い単一の情報源となります。レコードは Kinesis Data Streams アプリケーションに複数回配信される場合があります。この理由として、プロデューサーの再試行とコンシューマーの再試行の 2 つがあります。アプリケーションは、各レコードの複数回処理を予測して適切に処理する必要があります。