EDA (イベント駆動型アーキテクチャ ) とは何ですか?

イベント駆動型アーキテクチャ (EDA) とは

イベント駆動型アーキテクチャ (EDA) は、イベントを発行、消費、またはルーティングする小規模な分離されたサービスから構築された最新のアーキテクチャパターンです。

イベントは、状態の変化または更新を表します。例: 商品がショッピングカートに入れられた、ファイルがストレージシステムにアップロードされた、または注文の出荷の準備が整った。イベントは、状態 (注文に含まれる商品名、価格、数量など) を伝えるか、単に関連情報を検索するために必要な識別子 (例えば、「注文番号 8942 が発送されました」) を含むことができます。

従来のリクエスト駆動型モデルとは異なり、EDA はプロデューサーサービスとコンシューマーサービスの間の疎結合を促進します。これにより、システムの個別コンポーネントのスケール、更新、および独立したデプロイがより容易になります。

分離アーキテクチャが重要な理由

多くの組織は、モノリシックなアプリケーション、データベース、およびテクノロジーがイノベーションとユーザーエクスペリエンスの向上に悪影響を及ぼしていることに気付いています。レガシーアプリケーションとデータベースは、最新のテクノロジーフレームワークを採用する選択肢を減らし、競争力とイノベーションに歯止めをかけます。ただし、アプリケーションとそのデータストアをモダナイズすると、スケーリングが容易になり、開発が迅速になります。

デカップリングされたデータ戦略により、フォールトトレランスと回復力が向上し、新しいアプリケーション機能を市場に投入するまでの時間 (TTM) が短縮されます。

モノリシックアプリケーションをモダナイズする利点の詳細については、AWS 規範ガイダンスの「マイクロサービスでのデータ永続化の有効化」を参照してください。

イベント駆動型アーキテクチャ (EDA) の利点

イベント駆動型アーキテクチャ (EDA) は、システムのコンポーネント間の疎結合を促進し、俊敏性を高めます。マイクロサービスは、独立してスケーリングし、失敗しても他のサービスに影響を与えることなく、ワークフローの複雑さを軽減できます。イベントは、監査目的で柔軟にルーティング、バッファリング、およびログに記録できます。プッシュベースのイベントフローはリアルタイムで動作し、システムの変更を継続的にポーリングするコードの作成と運用に関連するコストを削減します。

個別にスケーリングやエラー発生

サービスをデカップリングすることで、イベント駆動型アーキテクチャのコンポーネントは独立してスケーリングおよび障害が発生し、アプリケーションの回復力が向上します。これは、サービス間の統合の数が増えるにつれてますます重要になります。1 つのサービスに障害が発生しても、残りのサービスは引き続き実行できます。

イベント駆動型アーキテクチャは、ほぼリアルタイムのシステムを設計することを容易にし、組織がバッチベースの処理から脱却するのに役立ちます。アプリケーションの状態が変化すると、イベントが生成されます。イベントがスケールアップすると、イベントを処理するレイヤーもスケールアップします。

イベントは通常、メッセージングサービスに発行され、マイクロサービス間の伸縮自在なバッファのように動作し、スケーリングの処理に役立ちます。イベントは、イベントの内容に基づいてメッセージをフィルタリングおよびルーティングできるルーターサービスに送信される場合もあります。その結果、イベントベースのアプリケーションはよりスケーラブルになり、モノリシックアプリケーションよりも優れた冗長性をもたらします。

俊敏に開発

イベント駆動型アーキテクチャとイベントルーターにより、デベロッパーは、イベントをポーリング、フィルタリング、およびルーティングするためのカスタムコードを記述する必要がなくなりました。イベントルーターは、イベントを自動的にフィルタリングし、コンシューマーにプッシュします。また、ルーターによってプロデューサーサービスとコンシューマーサービス間の手間のかかる調整が不要になるため、デベロッパーの俊敏性が向上します。

イベント駆動型アーキテクチャはプッシュベースです。つまり、イベントがルーターやダウンストリームシステムに送信されると、すべてがオンデマンドで発生し、依存するサービスに通知する必要がなくなります。このため、インフラストラクチャとリソースはイベントボリュームに応じてスケールアップおよびスケールダウンでき、ワークロードの処理とデプロイされたアプリケーションの運用にかかるコストを削減できます。

拡張可能なシステムを構築

イベント駆動型アーキテクチャは、高い拡張性も備えています。他のチームは、既存のマイクロサービスに影響を与えることなく、機能を拡張して機能を追加できます。イベントを発行することにより、アプリケーションは既存のシステムと統合できます。また、将来のアプリケーションは、既存のソリューションを変更することなく、イベントコンシューマーとして簡単に統合できます。

イベントプロデューサーはイベントコンシューマーを認識していないため、システムを拡張する際の摩擦が少なくなり、新しい機能や統合によって依存関係が追加されて将来の開発が遅くなることもありません。

複雑さを軽減

マイクロサービスにより、デベロッパーとアーキテクトは複雑なワークフローを分解できます。例えば、e コマースのモノリスを注文受付と支払いプロセスに分割し、在庫、フルフィルメント、会計サービスを個別に利用できます。

モノリスでの管理とオーケストレーションが複雑なワークロードは、独立して管理され、イベントメッセージを通じて非同期に通信する一連のシンプルでデカップリングされたサービスになります。

イベント駆動型のアプローチにより、さまざまな速度でデータを処理するサービスを組み立てて調整することができます。次の例では、注文受付マイクロサービスがキューを介して支払い処理システムと対話します。

この例では、注文受付サービスは、メッセージをキューにバッファリングすることにより、受け取る大量の注文を保存できます。

支払い処理サービスは、支払いの処理が複雑なため通常は遅くなりますが、キューから安定したメッセージストリームを受け取ることができます。支払いサービスは、再試行およびエラー処理ロジックにより、さまざまなシステム状態間で遷移します。ワークフローサービスは、システムの状態に基づいて支払い手順を調整および管理し、最終的に、在庫、フルフィルメント、および会計サービスにとって重要なイベントをさらに生成します。

監査が簡単

イベント駆動型アーキテクチャのイベントルーターは、アプリケーションを監査し、ポリシーを定義するための単一のロケーションとして機能します。これらのポリシーは、ルーターにパブリッシュおよびサブスクライブできるユーザーを制限し、データへのアクセス許可を持つユーザーとリソースを制御します。また、転送中のイベントと保管時のイベントは共に暗号化できます。

コストを削減

EDA はプッシュベースであるため、ルーターにイベントが発生すると、すべてがオンデマンドで処理されます。この方法では、イベントの有無を確認するための継続的なポーリングに対する料金は発生しません。これは、ネットワーク帯域幅の消費量、CPU 使用率、アイドル状態のフリート容量、SSL/TLS ハンドシェイクが減ることを意味します。

イベント駆動型アーキテクチャ (EDA) の仕組み

以下は、e コマースサイトのイベント駆動型アーキテクチャ (EDA) の例です。

このサンプルサイトは、3 つの主要なイベントプロデューサーコンポーネントと、それらが生成するイベントを示しています。このシナリオでは、イベントルーターがイベントを取り込み、フィルタリングしてから、1 つ以上のイベントをイベントコンシューマーに送信します。

このイベント駆動型アーキテクチャでは、アプリケーションをクラッシュさせたり、リソースをオーバープロビジョニングしたりすることなく、需要のピーク時にさまざまなソースからの変更に対応できます。

イベント駆動型アーキテクチャ (EDA) に適したワークロードのタイプ

イベント駆動型アーキテクチャ (EDA) は、高度にスケーラブルで可用性の高いワークロードの要求を満たす効果的な方法を提供できます。EDA は、予測不可能なトラフィックパターンや「急増する」トラフィックパターンを持つワークロードにも適しています。

イベント駆動型アーキテクチャ (EDA) によるアプリケーションの改善方法

イベント駆動型アーキテクチャ (EDA) は、コンポーネント間の疎結合を促進するため、最新の分散アプリケーションを構築するための優れたアプローチになります。

イベントプロデューサーは、自らが生成するイベントのダウンストリームコンシューマーのアクティビティを認識せず、気にせず、また負荷もかかりません。イベント自体は状態の変化を表し、データが含まれている場合と含まれていない場合があります。イベントは、その存在の結果を認識しません。コンシューマーは、関心のあるイベントをリッスンして処理します。新しいコンシューマーをオンラインにして、既存のワークフローを中断することなく新しい機能を提供できます。

EDA は、モノリシックシステムをより小さなドメインモデルに分解することを促します。デベロッパーは、少ない認知負荷でスピードを上げ、より迅速に生産性を高めることができます。重要な機能が分離されると、アップデートや新機能をデプロイするリスクも軽減されます。

一般的なイベント駆動型アーキテクチャ (EDA) のユースケース

ウェブおよびモバイルバックエンド用のマイクロサービス通信

小売、メディアや娯楽業界のウェブサイトは、予測できないトラフィックを処理するためにスケールアップする必要があることがよくあります。顧客は e コマースウェブサイトにアクセスして注文します。注文イベントはイベントルーターに送信されます。すべてのダウンストリームマイクロサービスは、処理のために注文イベントを取得できます。アクションの例としては、注文の送信、支払いの承認、配送業者への注文の詳細の送信などがあります。

各マイクロサービスは個別にスケーリングおよび失敗できるため、単一障害点なしで、注文のピーク時にプロセスをスケールアップできます。

ビジネスワークフローのオートメーション

金融サービストランザクションなど、多くのビジネスワークフローでは、同じ手順を繰り返す必要があります。イベント駆動型アーキテクチャ (EDA) を使用して、これらのステップを開始および自動化できます。

例えば、顧客が銀行に新しい口座を申請する場合、銀行はいくつかのデータチェック (身分証明書、住所など) を実行する必要があります。一部のアカウントでは、人間による承認段階も必要になるでしょう。このようなステップはすべて、新しいアカウントアプリケーションを受信したときにステップを自動的に実行するワークフローサービスを介して調整できます。

また、顧客のアプリケーションデータを機械学習と非同期に処理して関連データを抽出するワークフローを追加することで、手作業でデータを収集して検証する時間を何時間も節約できる可能性があります。

SaaS アプリケーション統合

Software as a Service (SaaS) 環境の最大の課題は、ユーザーのアクティビティとデータに対する可視性の欠如です。サイロ化されたデータのロックを解除するために、イベント駆動型アーキテクチャは SaaS アプリケーションイベントを取り込むか、イベントを SaaS アプリケーションに送信できます。例えば、受信したパートナーの注文データを取り込み、その注文を社内の注文処理アプリケーションに直接送信するミドルウェアを構築できます。

インフラストラクチャとオートメーション

コンピューティング集約型ワークロード (財務分析、ゲノム研究、メディアトランスコーディングなど) を実行する場合、高度な並列処理を行う際はスケールアップし、ジョブの完了後にスケールダウンすることで、コンピューティングリソースを適応させることができます。

例えば、規制の厳しい業界では、EDA を使用する企業は、インシデントに対応してセキュリティポスチャリソースをスピンアップしたり、セキュリティポリシーがアラートイベントを送信するたびに修復アクションを実行したりできます。

イベント駆動型アーキテクチャ (EDA) を使用する必要があるタイミング

イベント駆動型アーキテクチャ (EDA) は、俊敏性の向上と迅速な移行に最適です。マイクロサービスを使用する最新のアプリケーションや、疎結合されたコンポーネントを持つアプリケーションでよく利用されます。

異種システムの統合

異なるスタックで動作するシステムがある場合、EDA を使用すれば、結合しなくてもシステム間で情報を共有できます。イベントルーターは、システム間の間接化と相互運用性を確立するため、サーバーは互いに依存することがないまま、メッセージやデータを交換できるようになります。

クロスリージョン、クロスアカウントのデータレプリケーション

EDA を利用することによって、異なる AWS リージョンやアカウントで運用、デプロイされるチーム間でシステムを連携させることができます。システム間のデータ転送にイベントルーターを使用すれば、他のチームから独立してサービスの開発、スケール、デプロイを行うことができます。

リソースの状態のモニタリングとアラート

EDA を使用すれば、リソースを継続的にチェックしなくても、異常、変更、更新をモニタリングし、アラートを受信できます。これらのリソースには、ストレージバケット、データベーステーブル、サーバーレス関数、コンピューティングノードなどが含まれます。

ファンアウトと並列処理

イベントに応じて動作させる必要があるシステムが多数ある場合、EDA を使用すれば、各コンシューマーにプッシュするカスタムコードを作成しなくても、イベントをファンアウトすることができます。ルーターはイベントをシステムにプッシュし、各システムは目的の異なるイベントを並行して処理できます。

一般的なイベント駆動型アーキテクチャ (EDA) パターンとは

多数の短い関数

少数の大きな関数よりも多くの短い関数を作成します。関数をワークロードに合わせて高度に特殊化するということは、関数が簡潔になり、一般的に処理時間が短縮されることを意味します。各関数は、ワークフロー全体やトランザクションの量についての知識や期待なしで関数に渡されたイベントを処理する必要があります。これにより、関数はイベントのソースに依存せず、他のサービスとの結合が最小限になります。

バッチではなくオンデマンド処理

多くの従来のシステムは、定期的に実行され、時間の経過とともに蓄積されるトランザクションのバッチを処理するように設計されています。例えば、バンキングアプリケーションは 1 時間ごとに実行され、ATM トランザクションを処理して中央台帳に記帳する場合もあるかもしれません。

イベント駆動型アーキテクチャ (EDA) では、カスタム処理がすべてのイベントに応答できます。これにより、ほぼリアルタイムでトランザクションを処理するために、サービスは必要に応じて同時実行をスケールアップできます。

中断回復

中断が発生した場合、サービスが自動的に呼び出されて、イベントの処理が再試行される場合があります。サービスは同じイベントを複数回受信する可能性があるため、べき等になるように関数を設計します。これにより、サービスで最初にイベントを受け取った後、結果が変わらないことが保証されます。

例えば、小売業者が再試行のためにクレジットカードの処理を 2 回試みた場合、サービスは最初の試行でのみ支払いを処理します。再試行時に、サービスは支払いステータスを確認し、イベントを破棄します。

イベント駆動型アーキテクチャ (EDA) が抱える課題

イベント駆動型アーキテクチャ (EDA) を採用する際には、アプリケーション設計に対する考え方の見直しが必要になる場合があります。

可変レイテンシー

1 つのデバイス上の同じメモリ空間内ですべてを処理する可能性があるモノリシックアプリケーションとは異なり、イベント駆動型アプリケーションはネットワークを介して通信します。この設計では、可変レイテンシーが発生します。モノリシックアプリケーションのレイテンシーは変動する可能性がより低いか、機会がより少ない可能性がありますが、これは通常、スケーラビリティと可用性を犠牲にしています。

サーバーレス AWS のサービスは可用性が高く、AWS リージョン内の複数のアベイラビリティゾーンで動作します。サービスが中断した場合、サービスは自動的に別のアベイラビリティゾーンにフェイルオーバーし、トランザクションを再試行します。その結果、トランザクションが失敗する代わりに、正常に完了する可能性がありますが、レイテンシーが長くなります。

一貫した低レイテンシーのパフォーマンスを必要とするワークロードは、EDA には適していません。銀行の高頻度取引アプリケーションや、倉庫でのサブミリ秒のロボティクスオートメーションがその例です。

結果整合性

イベントは、状態の変化を表します。任意の時点でアーキテクチャ内のさまざまなサービスを介して多くのイベントが流れており、このようなワークロードは多くの場合、最終的に整合性があります。これにより、トランザクションの処理、重複処理、またはシステムの正確な全体的な状態の判断がより複雑になります。

一部のワークロードは、ACID プロパティが必要なため、EDA にはあまり適していません。ただし、多くのワークロードには、結果的に整合性のある要件 (この 1 時間の合計注文数など) や強い整合性のある要件 (現在の在庫など) の組み合わせが含まれています。強力なデータ整合性が必要な機能については、これをサポートするアーキテクチャパターンがあります。以下に例を示します。

DynamoDB は強力な整合性のある読み込みを行えますが、場合によってはレイテンシーが高くなります。また、データ整合性を維持するためにトランザクションをサポートすることもできます。

ACID プロパティを必要とする機能にはリレーショナルデータベースを使用できますが、どのリレーショナルデータベースも NoSQL データストアほどスケーラブルではありません。

発信者に値を返す

多くの場合、イベントベースのアプリケーションは非同期です。これは、発信者サービスが他のサービスからのリクエストを待たずに他の作業を続行することを意味します。EDA のこの基本的な特性により、スケーラビリティと柔軟性がもたらされます。ただし、戻り値またはワークフローの結果を渡すことは、同期フローよりも複雑になります。

多くの場合、値を返すことは、イベント処理を確実に成功または失敗させることほど重要ではありません。イベント処理を確実に行う機能は、発信者に値を返すことよりも重要な可能性があります。

ウェブやモバイルアプリケーションなどのインタラクティブなワークロードの場合、エンドユーザーは通常、戻り値またはトランザクションの現在のステータスを受け取ることを期待しています。これらのワークロードには、豊富なイベント処理を発信者に返すことができるいくつかの設計パターンがあります。ただし、イベント駆動型アーキテクチャでこのような実装を行うことは、従来の非同期の戻り値を使用するよりも複雑です。多くの場合、プラットフォームはこの複雑さを軽減できます。

サービスと機能全体のデバッグ

イベント駆動型システムのデバッグは、モノリシックアプリケーションのデバッグとは異なります。すべてのマイクロサービスベースのアプリケーションや、イベントを渡すさまざまなシステムやサービスと同様に、エラーが発生したときに複数のサービスの正確な状態を記録して再現することは困難な場合があります。各サービスと関数の呼び出しには個別のログファイルがあるため、エラーの原因となった特定のイベントに何が起こったのかを判断するのがより複雑になる可能性があります。

オーケストレーション

単純なワークフローが時間の経過とともに複雑になるのはよくあることです。典型的なモノリスでは、これにより、機能とサービスのグループがより緊密に結合され、ルーティングと例外を処理する複雑なコードが発生する可能性があります。

システムの状態を追跡するために、分岐ロジック、さまざまな種類の障害モデル、および再試行ロジックを含むワークフローでは通常、オーケストレーターが使用されます。イベント駆動型サーバーレスアプリケーションを作成するときは、このロジックをステートマシンに移行して適切なオーケストレーションを実現できるように、これがいつ発生するかを特定することが重要です。

イベント駆動型アーキテクチャ (EDA) を使用する AWS のサービス

AWS のサービスは通常、イベントを生成または消費するため、イベント駆動型アーキテクチャ (EDA) でソリューションを簡単に構築できます。

さらに、Amazon EventBridge、Amazon SNS、Amazon SQS、AWS Step Functions などのサービスには、コンシューマーによる定型コードの記述を減らし、EDA を迅速に構築する機能が含まれています。

Amazon EventBridge

Amazon EventBridge を利用して、SaaS アプリケーション、AWS の他のサービス、またはカスタムアプリケーションからのイベントを使って、イベント駆動型アプリケーション用のイベントバスを大規模に構築できます。

EventBridge は、ルールを適用して、イベントソースから別のターゲットにイベントをルーティングします。ターゲットには、AWS Lambda、Step Functions、Amazon Kinesis などの AWS のサービス、または EventBridge API 送信先を介した任意の HTTP エンドポイントを含めることができます。

EDA のユースケースで一般的な統合は、イベントが特定のワークフローをトリガーする Step Functions です。

AWS Step Functions

AWS Step Functions には Workflow Studio が含まれています。これは、ビルダーがさまざまな AWS のサービスを調整するために使用するローコードのビジュアルワークフローデザイナーです。Workflow Studio を使用して、分散アプリケーションを構築し、IT およびビジネスプロセスを自動化し、AWS のサービスを使用してデータおよび機械学習パイプラインを構築できます。

Amazon SNS

Amazon Simple Notification Service (Amazon SNS) を使用して、他のアプリケーション、マイクロサービス、または AWS のサービスによって発行された高スループットで低レイテンシーのイベントに反応するアプリケーションを構築することをお勧めします。また、数千または数百万のエンドポイントへの非常に高いファンアウトを必要とするアプリケーションに Amazon SNS を使用することもできます。

Amazon SQS

Amazon Simple Queue Service (Amazon SQS) は、分散ソフトウェアシステムとコンポーネントを統合および分離するために使用できる、安全で耐久性があり、利用可能なホスト型キューサービスを提供します。Amazon SQS は、デッドレターキューやコスト配分タグなどの一般的な構造を提供します。