

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

# イベントソーシングパターン
<a name="service-per-team"></a>

イベントソーシングパターンは通常、[CQRS パターン](cqrs-pattern.md) とともに使用され、読み取りと書き込みのワークロードを切り離し、パフォーマンス、スケーラビリティ、セキュリティを最適化します。データは、データストアに直接更新されるのではなく、一連のイベントとして保存されます。マイクロサービスはイベントストアのイベントを再生して、独自のデータストアの適切な状態を計算します。このパターンは、アプリケーションの現在の状態を可視化し、アプリケーションがどのようにしてその状態に到達したかを示す追加のコンテキストを提供します。イベントソーシングパターンは、コマンドデータストアとクエリデータストアのスキーマが異なっていても、特定のイベントのデータを再現できるため、CQRS パターンと効果的に連携します。

このパターンを選択することで、任意の時点におけるアプリケーションの状態を特定して再構築できます。これにより、永続的なオーディットトレイルが作成され、デバッグが容易になります。ただし、データには最終的に一貫性が保たれるため、使用事例によっては適切でない場合があります。

このパターンは、Amazon Kinesis Data Streamsまたは Amazon EventBridge のいずれかを使用して実装できます。

## Amazon Kinesis Data Streams の実装
<a name="amazon-kinesis"></a>

次の図では、Kinesis Data Streams が一元化されたイベントストアの主要コンポーネントです。イベントストアは、アプリケーションの変更をイベントとしてキャプチャし、Amazon Simple Storage Service (Amazon S3) に保存します。

![Amazon Kinesis Data Streams の実装](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram4.png)


ワークフローは、以下の手順で構成されます。

1. 「/withdraw」または「/credit」マイクロサービスでイベントの状態が変化すると、Kinesis Data Streams にメッセージを書き込むことでイベントを発行します。

1. 「/balance」や「/CreditLimit」などの他のマイクロサービスは、メッセージのコピーを読み取り、関連性を判断してフィルタリングし、今後の処理のために転送します。

## Amazon EventBridge の実装
<a name="amazon-eventbridge"></a>

次の図のアーキテクチャでは、EventBridge を使用しています。EventBridge は、イベントを使用してアプリケーションコンポーネントどうしを接続するサーバーレスサービスです。これにより、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。イベント駆動型アーキテクチャとは、イベントの発信と応答によって連携する、ゆるやかに結合されたソフトウェアシステムを構築するスタイルです。EventBridge は、 AWS サービスによって発行されるイベント用の[デフォルトのイベントバス](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html)を提供します。また、ドメイン固有の[バス用のカスタムイベント](https://docs.aws.amazon.com//eventbridge/latest/userguide/create-event-bus.html)バスを作成することもできます。

![Amazon EventBridge の実装](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram5.png)


ワークフローは、以下の手順で構成されます。

1. 「OrderPlaced」イベントは「Orders」マイクロサービスによってカスタムイベントバスに公開されます。

1. 「/route」マイクロサービスなど、注文後にアクションを実行する必要があるマイクロサービスは、ルールとターゲットによって開始されます。

1. これらのマイクロサービスは、注文をカスタマーに配送するためのルートを生成し、「RouteCreated」イベントを発行します。

1. さらにアクションが必要なマイクロサービスも「RouteCreated」イベントによって開始されます。

1. イベントはイベントアーカイブ (EventBridge アーカイブなど) に送信され、必要に応じて再生して再処理できます。

1. 履歴注文イベントは、必要に応じて再処理のために新しい Amazon SQS キュー (再生キュー) に送信されます。

1. ターゲットが開始されない場合、影響を受けたイベントはさらなる分析と再処理のためにデッドレターキュー (DLQ) に置かれます。

このパターンの使用を検討すべきなのは、次のような場合です。
+ イベントはアプリケーションの状態を完全に再構築するために使用されます。
+ システム内でイベントが再生され、アプリケーションの状態を任意の時点で判断できることが必要です。
+ 空白のアプリケーションの状態から始めることなく、特定のイベントをリバースできるようにしたい。
+ システムには、自動ログを作成するために簡単にシリアル化できる一連のイベントが必要です。
+ システムには大量の読み取り操作が必要ですが、書き込み操作は軽いため、負荷の高い読み取り操作はメモリ内のデータベースに送ることができ、そのデータベースはイベントストリームで最新の状態に保たれます。

**重要**  
イベントソーシングパターンを使用する場合は、マイクロサービス間でデータの一貫性を保つために [Saga パターン](saga-pattern.md) をデプロイする必要があります。