この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
アノテーション テクニカルサポートの川崎です。
本記事は AWS re:Invent 2022 のセッションレポートとなります。
概要
イベント ドリブン アーキテクチャは、組織のビジネス機能に整合性をもたらすことができます。 Amazon EventBridge は、ビジネス アプリケーション間のアプリケーション統合を可能にし、最新のアプリケーション開発プラクティスを改善します。 このセッションでは、利害関係者グループの役割と責任について学び、組織のために持続可能でスケーラブルなサーバーレス イベント バスを設計および構築するための基本的な概念を発見します。
セッション動画
アジェンダ
- マルチアカウント トポロジについて学んだこと
- カップリングとイベント
- イベント駆動型アーキテクチャにおける役割と責任
- Amazon EventBridge を使用して、サーバーレスのイベント駆動型イベント バスを設計する
このプレゼンテーションでは、Eventbridge を使用したイベント駆動型アーキテクチャの設計の基礎について説明します。 組織全体での採用を計画する際に行う必要がある重要な設計上の決定について説明します。 プロデューサーとコンシューマーが持つ役割と責任、およびそれらが Eventbridge とどのように関係しているかを理解することが強調されています。 また、手元のアーキテクチャに適切なイベントを使用すること、および分散システムでのカップリングのコアを理解することの重要性も強調しています。 最後に、Eventbridge を使用したサービス統合の設計に関する考えを共有します。
過去のセッション 「Amazon EventBridge を使用したイベント駆動型アーキテクチャの構築」
マルチアカウント トポロジについて学んだこと
どのトポロジを選択すればよいですか?
- 1 つのアカウントで 1 つのイベント バス？
- 1 つのアカウントで複数のイベント バス？
- 単一のイベント バス、複数のアカウント？
- 複数のアカウントにまたがる複数のイベント バス？
シングルバス、マルチアカウント パターン
- 特徴
- すべてのサービスは、単一または「中央」のイベント バスにイベントをプッシュします。
- すべてのサービスのルールは、中央のイベント バスで作成されます。
- チーム
- DevOps チームがアクセス ポリシーを管理し、リソース管理をチームに委任します
- サービス チームは DevOps チームと協力してリソースのニーズを調整します
- 考慮事項
- 追加のクロスアカウント ポリシー管理。 ここでリソース ポリシーが役立ちます。
- 開発速度への潜在的な影響を考慮する
マルチバス、マルチアカウント パターン
- 特徴
- サービスは、所有および管理するイベント バスにイベントを発行します。
- サービスが公開しているイベントにサブスクライブしているサービスからのルールのみを含む
- チーム
- サービス チームは、サービス イベント バスと、イベントを送受信するためのすべてのリソースを管理します。
- 考慮事項
- 分散ルールを管理する際の追加のオーバーヘッド
マルチアカウント バス トポロジの比較
RESOURCE DISTRIBUTION
- シングルバス トポロジ
- 一元化された
- マルチバス トポロジ
- 分散型
統合ロジックからルーティング ロジックを分離することで、イベントの受信方法に影響を与えずに統合を追加または削除できます。 このパターンを使用すると、開発チームは、構築中のアプリケーションのイベントを配布する手段を手に入れ、それらのアプリケーションをより簡単に管理できるようになります。 管理する必要のあるリソースの数はそれほど多くなく、アプリケーションを構築するための非常に自然な方法のように思えます。
マルチアカウント バス トポロジの比較
RESOURCE MANAGEMENT
- シングルバス トポロジ
- 集中 (n+1)
- マルチバス トポロジ
- 分散型
マルチアカウント バス トポロジの比較
RESOURCE MANAGEMENT
- シングルバス トポロジ
- 集中 (n+1)
- マルチバス トポロジ
- 分散型
マルチアカウント バス トポロジの比較
RULE DISTRIBUTION
- シングルバス トポロジ ルールの配布
- マルチバス ルールの配布
ルールは両方のケースで配布されますが、方法が異なるだけです
マルチアカウント バス トポロジの比較
RULE DISTRIBUTION
- シングルバス トポロジ ルールの配布
- マルチバス ルールの配布
ルールは両方のケースで配布されますが、方法が異なるだけです
マルチアカウント バス トポロジの比較
DISTRIBUTION OF SERVICE LIMITS
- シングルバス ルール制限の配布
- 中央イベント バスのすべてのサブスクリプション ルールに制限が適用されます
- マルチバス ルール制限の配布
- 特定のドメインのサブスクリプション ルールに制限が適用されます
ルールの増大への対処
DISTRIBUTION OF SERVICE LIMITS
- 中央アカウントの複数のイベント バスにドメインを分散
- 論理ドメイン グループは、指定されたイベント バスに発行できます。
- 消費者は、イベントが公開される場所を認識する必要があります
- バス ポリシーでは、イベント コンシューマーが中央のイベント バスにルールを設定できるようにする必要があります。
ルールの増大への対処
DISTRIBUTION OF SERVICE LIMITS
Amazon EventBridge は、組織内のあらゆるタイプのトポロジーに使用および適応できる、非常にスケーラブルなサーバーレス ソリューションです。 イベントバスでルールを作成するサービスによって、適切なポリシーが保証される必要があります。 アプリケーションをクラウドに移行することで、組織は毎秒数万のイベントを処理し、それらをグローバルに配信できます。
マルチアカウント バス トポロジの比較
WHICH IS BEST?
- シングルバス トポロジ
- マルチバス トポロジ
場合によります ！！！
1 行のコードで何ができるでしょうか?
aws events create-event-bus --name MyDomainEventBus
- 非独占的なプロトコルとツールを使用した強力で軽量な統合サービス
- 毎秒数十万のメッセージをルーティングする機能
- 集中型または分散型のルーティング トポロジを作成する
- アカウントや地域全体でイベントを送信および複製する
- 管理するインフラがない
カップリングとイベント
カップリング
カップリングの多くの側面
- テクノロジーへの依存: Java と C++ の比較
- 場所の依存性: IP アドレス、DNS
- データ形式の依存関係: Binary、XML、JSON、ProtoBuf、Avro
- データ型の依存関係: int16、int32、string、UTF-8、null、empty
- セマンティックな依存関係: 名前、ミドルネーム、ZIP
- 一時的な依存関係: 同期、非同期
- インタラクション スタイルの依存関係: メッセージング、RPC、クエリ スタイル (GraphQL)
- 会話の依存関係: ページネーション、キャッシング、再試行
出典: EnterpriseIntegrationPatterns.com
結合の適切なレベルは、エンドポイントに対する制御のレベルによって異なります。
グレゴール・ホープ
エンタープライズ統合パターンより
イベント
イベント
名詞
- システムの状態が変化したというシグナル
- 不変オブジェクト
- システム統合契約
イベントの種類
- 通知イベント
- 何か重要なことが起こったことを通知する
- 最小限の情報
- 詳細についてはプロデューサーに問い合わせる必要がある場合があります
- イベントを運ぶ状態転送イベント
- データの変更を公開する
- 追加の詳細について生産者に問い合わせる必要はありません
- 例: Amazon DynamoDB ストリーム
- 直接的な依存関係のないドメイン間でデータを複製するのに便利
- ドメイン イベント
- 通知イベントと状態転送イベントの組み合わせ
- ビジネス ドメインにできるだけ近いモデル
- ステートレスで不変の信頼できる情報源
出典: https://martinfowler.com/articles/201701-event-driven.html
ここでは、ソフトウェア アーキテクチャにおけるイベントの重要性について説明し、Martin Fowler によって定義された 3 つのタイプのイベント (通知イベント、ドメイン イベント、およびイベント伝達状態転送イベント) について説明しています。 通知イベントは通常、何か重要なことが発生したことを示しますが、通常は情報やコンテキストが欠落しているため、サブスクライバーは別のシステムにクエリを実行して詳細情報を取得する必要があります。 イベント キャリング ステート トランスファー イベントは、外部ソースにクエリを実行することなく、ローカル ステートをさまざまなサービスに分散するのに役立ちます。ドメイン イベントは、情報の変化を表現し、自己完結型のイベントです。
Amazon EventBridge イベント
- コンシューマに提供するデータにコンテキストが追加されます
- 詳細タイプおよびソース スコープのイベントを境界付けられたコンテキストにフィールド化します。 一緒に、イベントの意図とその詳細を説明します
- 異種システムとアプリケーション間の同種統合を確立するためのコア
イベント駆動型アーキテクチャにおける役割と責任
役割と責任
パブリッシュ/サブスクライブ統合パターン
- パブリッシュ サブスクライブ
- 特定のドメイン イベントに対して 1 つの論理パブリッシャー、1 つ以上のコンシューマー
- 境界付けられたコンテキスト間に一貫した境界を適用します
- 複数のタイプのカップリングに対応 – 時間的、空間的、プラットフォーム
パブリッシュ/サブスクライブ統合パターン
- 契約の成立
- すべてのカップリングが除去されたわけではありません – 良好なカップリングがまだ残っています
- ビジネス コンテキストは、生産者と消費者の間の「契約」を確立します。
- 連絡先は EventBridge スキーマとして表すことができます
システムの境界を越えた一貫性は、イベントを定義する上で重要です。 イベントが変更された場合、新しいコントラクトを確立する必要があります。これは、コンシューマーがそれらのイベントに新しい実装を提供する必要があることも意味します。 プロデューサーは、同じイベントのバージョン 2 をまだ実装していないプロデューサーに下位互換性を提供しながら、コンシューマーをサポートするために、同じイベントの 2 つのバージョンを同時に発行する必要がある場合があります。 基本的に、同じスペースに同じイベントの 2 つのバージョンを同時に存在させることはできません。 プロデューサーは、誰がどのようにイベントを処理しているかを考慮せずに、できるだけリアルタイムに近いイベントを送信する必要があります。 プロデューサは、イベントが誰またはどのように消費されているか、またはイベントが消費されているかどうかについて、まったく想定していません。
プロデューサーの責任
- 生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネス プロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています
プロデューサーの責任
- 生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネス プロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています
これは、イベント定義が進化するにつれて後方互換性を確保することも意味します
プロデューサーの責任
- 生産者は確実に
- 彼らが発行するイベントは安定しており、イベントを定義するビジネス プロセスと一致しています。
- 彼らが発行するイベントは、合意された契約/定義に準拠しています
- メッセージの配信は、イベントのコンシューマーのニーズとは関係なく、可能な限りリアルタイムに近い形で行われます。
プロデューサーの責任
- プロデューサーは責任を負いません
- 消費者がイベントをどのように使用しているか
- コンシューマーの制約 (例えば、イベントがコンシューマーによって処理される速度) を知る
- コンシューマーがイベントを処理する前にどのように変換する必要があるかを理解する
消費者の責任
- 消費者の責任
- 受け取りたいイベントを指定する。 さらに、選択的フィルタリングを介して
- イベントを処理する速度を決定する。たとえば、受信イベント速度 > コンシューマの処理能力
- 変革の必要性を判断する
誰が何を所有していますか？
- イベント バスにイベントを公開できるユーザー
- イベント バスでルールを作成できるユーザー
-
パターン
- ターゲット
- 変換
-
DLQ
-
外部 API は、接続と API 宛先構成を定義します
外部関係者はイベント バスでリソースを作成できません。つまり、イベント バスの所有者は、外部の API 所有者と連携して、セキュリティ資格情報とエンドポイントの構成が変更されても統合が最新の状態に保たれるようにする責任があります。 責任を適切に委任するには、リソースの明確な所有権を確立する必要があります。
Amazon EventBridge を使用して、サーバーレスのイベント駆動型イベント バスを設計する
Amazon EventBridge を使用したサーバーレスのイベント駆動型統合の基礎
イベント駆動型の統合 – マインド マップ
- サーバーレスのイベント駆動型統合基盤
- イベント
- ソース
- 詳細タイプ
- 資力
- 詳細
- プロデューサー
- ポリシー
- スキーマ
- 暗号化
- カスタム フレームワーク
- 消費者
- ターゲット
- ポリシー
- 検証
- ルール
- ガバナンス
- 可観測性
- 信頼性
- 組織のポリシー
- 修復
- 発見
- バージョン管理
- スキーマ マッピング
- 自動化/DevOps
- セルフサービス プロビジョニング
- イベント
イベント
- イベントを一意に識別するには、一貫性が重要です。 運用上のメリット
- 明確に定義されたドメインに合わせた命名規則を確立する
- さまざまなイベント タイプを定義する方法について考えることに時間を費やす
- イベントに追加のコンテキストを追加するカスタム メタデータを定義する
生産者
- セマンティックの一貫性を強制することにより、イベントの整合性を確保します。
- 機密情報の暗号化はクライアント レベルで行う必要があります – 共有秘密は、消費者との間で確立された契約の一部です。
- メタデータ プロパティでイベントを初期化し、入力を検証するカスタム ユーティリティの構築を検討する
- 複数のランタイムを通じて組織全体で標準化
EventBridge では、メタデータ フィールドをイベントに追加して、追加のコンテキスト情報を提供できます。 これは、メタデータ作成プロセスを抽象化し、開発チーム間で共有する再利用可能なライブラリとユーティリティを作成することで実現できます。 統合チームは、このタイプのユーティリティをサポートし、プライベート パッケージ リポジトリを通じて配布することで、組織全体で共有することを検討できます。 ドメイン内のすべてのイベントのメタデータをモデル化することは、実際には意味がなく、構築されているドメインを反映しません。
独自のメッセージング ユーティリティを構築する
- 開発チームが独自のソリューションを実装して、イベント ペイロードにメタデータを含めることを避ける
- イベントの一貫性と構造を強化できるユーティリティ ライブラリを作成する
- 組織が使用するランタイムをサポートする
- 使いやすいプライベート アーティファクト リポジトリを介して配布する
C# でのメッセージング ユーティリティの例
- プロデューサーは、イベントの詳細を表す CustomerMadePreferred クラスを定義します。
- イベントは、ビジネス ドメインを反映するようにモデル化されています。
- メタデータを含まない
統合のニーズからドメイン ロジックを分離する
C# でのメッセージング ユーティリティの例
ユーティリティ ライブラリは、実装を介して任意のイベント クラスを公開するための汎用インターフェイス IPublishEvents を定義します。
C# でのメッセージング ユーティリティの例
Detail クラスもジェネリックで、Metadata プロパティが含まれています。 Metadata クラスは構造を定義し、IPublishEvents 実装を介して送信されるすべてのイベントのプロパティを初期化します
C# でのメッセージング ユーティリティの例
- 最後に、インターフェイス IPublishEvents の実装により、AWS SDK を介してイベントが送信されます。
- PublishEvent メソッドは、CustomerMadePreferred イベント パラメータを受け取り、シリアル化されて新しい PutEventsRequestEntry の構築に使用される新しい Detail オブジェクトを作成します。
独自のメッセージング ユーティリティを構築する
- メタデータの挿入をやめるのはなぜですか?
- 検証を追加する (公開されたスキーマに対して)
- 永続的なパブリッシャー – エラーを適切に処理し、イベントが「最終的に」確実に配信されるようにします。
- 複数のバージョンのイベントを配信するメカニズム
- 命名規則を強制する
- 配信前にイベントのサイズを検証する
機密データの操作
- イベント内の個人を特定できる情報には暗号化が必要です
- Amazon EventBridge は、転送中および保存中のイベントをすでに保護していますが、これはポイントツーポイントのみです。
- 暗号化はどこに適用されますか。
- ミドルウェアで処理するか。 責任をサービスに任せますか?
機密データの操作
ENCRYPTED PAYLOAD
パブリッシャーは、機密フィールドをイベントで送信する前に暗号化し、サブスクライバーがペイロードを復号化できるように暗号化キーにアクセスできるようにする責任があります。 イベントが消費されると、イベント コンシューマは同じキーを使用して、別のイベントを通じてその情報を再送信できなくなります。 暗号化キーは、パブリッシャーとサブスクライバー間の契約の延長を形成するものであり、そのように扱われるべきです。
機密データの操作
- KMS CMK を明示的に共有して「契約」を延長する
- コンシューマが管理するキーでデータを再暗号化する
機密データの操作
- 自問してみてください: 機密データの共有は絶対に必要ですか?
- 複数のドメイン境界にまたがる機密情報の複製
- 機密情報の管理は、複数の関係者の責任になります。
- ドメインの境界に注意してください。データの所有者は誰ですか? 正しくモデリングしましたか？
消費者
- 自己記述的なルール名を作成する
- 取り込み率を計画する – プロデューサーがイベントを発行する速度を制御することはできません
- イベントを検証する必要がある場合は、公開されたスキーマを使用し、ローカルにキャッシュします
- 失敗に備える！ これには再試行が含まれます。 消費者を冪等にする
イベント バス ルールの命名規則
- ルール名は一意である必要があります。 このための戦略がない場合、展開は失敗します
- 運用はルールのタグ付けで支援できますが、Amazon CloudFormation や AWS CDK を使用してルール タグを設定することはできないため、現時点ではこれの価値は限られています。
- 組織が採用する命名規則を設計する
- ルールだけでなく、イベント バス、ターゲット名なども。 これらをさまざまな環境 (開発、テスト、本番) に展開することに注意してください。
イベント バス ルールの命名規則
- イベントを購読しているのは誰ですか
- どのターゲットが呼び出されているか
- イベントはどこから来たのか
- イベントの名前は何ですか
加入者ドメイン + ターゲット + イベント ソース + 詳細タイプ com.marketing.CmpHandlerFunction-com.sales.CustomerMadePreferred (ルール名の最大 64 文字制限)
イベントの一意性
- 冪等性
- 操作は、1 回呼び出されても複数回呼び出されても同じ結果を返します (EIP)
- 冪等キー
- 送信者がメッセージに割り当てて、受信者による重複排除を簡素化
冪等性は、コンシューマーがメッセージを 2 回処理しないようにするために不可欠です。これにより、意図しない結果が生じる可能性があります。 冪等性を実現する一般的な方法は、冪等性キーを定義することです。 上記の例では、イベント ID を冪等キーとして使用できます。 冪等性状態は、外部データ ストアで追跡できます。 AWS Lambda Power Tools for Python は、この目的に使用できるユーティリティです。 このユーティリティは、冪等キーを持つイベントを受信したという事実を記録し、それを外部データ ストアに格納し、イベントを処理して、応答が送信される前に応答が保持されるようにします。
イベントの重複排除戦略
- 外部データ ストアでべき等状態を管理する
- 重複排除の時間枠を指定する
- AWS Lambda Powertools Python べき等性ライブラリ
- べき等 API で再試行を安全にする (AWS Builders' Library)
(Lambda Powertools Python べき等性、https://s12d.com/powertools-py-idempotency)
EventBridge の観点からの冪等性
冪等性ウィンドウはユースケースによって異なる場合があります
- 実行時 (べき等ウィンドウ 5 分)
- イベントの再生 (べき等ウィンドウ > 5 分) イベント
EventBridge の観点からの冪等性
- メッセージを複数回処理することを常に想定してください。
- パーティションはネットワーク上だけでなく、データベース レイヤーやディスク IO でも発生します。
- 重複排除と順序付けは保証ではありません – それらは役に立ちますが、複数回処理されるイベントの処理方法に関する答えを得るために、ビジネス プロセスを確認することを忘れないでください。
- システムの重要な部分にべき等制御を適用する – 重複を処理する方が簡単な場合があります。
ガバナンス
- AWS Lambda Powertools (Python、Java、TypeScript、.NET) などのユーティリティ ライブラリを活用し、トレースのベスト プラクティスを適用します。 ロギングとメトリクス
- EventBridge は AWS X-Ray トレース伝播をサポートしており、リクエストが流れているときにキャプチャすることができます 異なるスタック間でイベント バスを介して
- AWS CloudTrail によるリソース管理の監査 – これは自動化して、会社の基準の違反を是正することができます
AWS Lambda パワー ツールを使用すると、サーバーレス コンピューティングからベスト プラクティスを簡単に取り入れて、開発チームに組み込むことができます。 ロギング、メトリクス、トレーサビリティ、および eventbridge の X 線サポートのためのツールを使用すると、アーキテクチャの健全性についてさらに洞察を得ることができます。 AWS cloudtrail などのサービスを使用して、自動化を構築し、組織内で確立されたルールと基準を適用できます。 スキーマ レジストリにはスキーマなどの既存の機能がありますが、イベントの検出、カタログ化、および組織全体で使用するためのイベントの記述には、まだやるべきことがたくさんあります。
発見
- スキーマは、イベントの構造を記述する上で重要な役割を果たします
- サービスの関係を伝え、理解するのに役立ちます
- 明示的な連絡先は、依存関係グラフを作成して、システムの境界を越えた一貫性を確保するのに役立ちます
- このスペースでできることは他にもたくさんあります
オープン ソース プロジェクト – イベント カタログ
- 特徴
- Amazon EventBridge のスキーマ、ターゲット、およびルールをドキュメントに変換します
- イベント、サービス、スキーマ、コード例などを文書化してキャプチャします
- ビジュアライザーを使用すると、すべてのイベント、パブリッシャー、およびサブスクライバー間の関係を確認できます
- David Boyne @boyney123 によるオープンソース
重要ポイント (Key takeaways)
- カップリングを真剣に考えよう！ 分散型イベント駆動型システムを構築している – トレードオフがあります
- 適切なタイプのイベントを選択する – イベントのモデル化に時間を費やす
- プロデューサーのニーズと責任、およびイベントの消費方法に焦点を当てる
- チームの統合を容易にする – 再利用可能なライブラリを作成して、統合要件を抽象化し、一貫性を確保できるようにします
- 組織全体に適用できる基準とポリシーを作成する
- イベント ドリブン アーキテクチャをどのように文書化するかを考えます。
追加のリソース
- エンタープライズ統合パターン
- Gregor Hohpe と Bobby Woolf によって書かれた本 Enterprise Integration Patterns では、エンタープライズ アプリケーション統合とメッセージ指向ミドルウェアをパターン言語の形式で使用するための 65 のパターンが説明されています。 このウェブサイトには、パターンのカタログと他の多くの優れたリソースが含まれています
- Amazon EventBridge を使用して、分離されたイベント駆動型アーキテクチャを構築する
- EventBridge の概要、イベント駆動型アーキテクチャの基本、EventBridge 機能の詳細、およびサーバーレス アプリケーションでの EventBridge の最適な使用方法について説明します。
- Amazon EventBridge で AWS X-Ray を使用する
- サンプルアプリケーションは、AWS サーバーレスアプリケーションモデル (AWS SAM) を使用して、Amazon EventBridge で AWS X-Ray を使用する方法を示しています
- Amazon EventBridge リソース ポリシーのサンプル
- Amazon EventBridge リソース ポリシー、マルチアカウント デザイン パターン、クロスリージョン イベント ルーティングのサンプル実装を含む GitHub リポジトリ
- Python 用 AWS Lambda Powertools
- AWS X-Ray を使用したトレース、構造化されたログ記録、非同期でのカスタム メトリクスの作成を容易にする AWS Lambda 関数用の一連のユーティリティ。 Powertools は、Python、Java、TypeScript、および .NET で使用できます
AWS サーバーレスの学習を続ける
- 自分のペースで学ぶ
- AWS Skill Builder の学習プランでサーバーレスのスキルを伸ばしましょう
- 知識を増やす
- ランプアップ ガイドを使用して、サーバーレスの知識を構築してください
- AWS サーバーレス バッジを獲得する
- デジタル バッジを取得して知識を証明する
https://s12d.com/serverless-learning
これらの他のセッションをチェックしてください
- API311: イベント駆動型アーキテクチャによる次世代アプリケーションの構築
- API302: グローバルなイベント駆動型アプリケーションの構築
- API308: 分散アプリケーションを統合または構築していますか?
- SVS312: サーバーレスプレッソの構築: イベント駆動型アーキテクチャの作成
16
