Webエンジニアなら知っておきたいイベント駆動アーキテクチャ

インフラ担当の柴田です。「Webエンジニアなら知っておきたい」シリーズです。今回はイベント駆動アーキテクチャ（Event-Driven Architecture: EDA）について紹介します。

私がAWSをよく使うので、AWSを例にしています。

イベント駆動アーキテクチャとは？

EDAは、イベントの発行、検出、消費といった、イベントへの反応を中心としたアーキテクチャです。イベントとは、状態の変化や更新を表します。EDAでは、個々のシステムコンポーネントがイベントを介した疎結合になることで、敏捷性や回復力、拡張性が向上するとして注目されています。

EDAのコンポーネント

EDAでは3つの主要なコンポーネントがあります。

Producer
Event Broker
Consumer

Producer

Producerは、状態の変化や更新を検知しイベントを発行するシステムです。

AWSでは、S3やAPI Gateway、EventBridge、Lambdaなどを使って実装できます。

Event Broker

Event BrokerはProducerとConsumerの間で、イベントを交換するためのシステムです。

AWSでは、EventBridgeやSNS、SQS、Kinesisなどを使って実装できます。

Consumer

Consumerはイベントを待ち受け、イベントを使用するシステムです。Consumerが新しいイベントを発行するProducerになることもあります。

AWSではLambdaやStep Functions、EC2、ECSなどを使って実装できます。

イベントとコマンドの違い

EDAを考えるときイベントとコマンドという2つのメッセージについて、その違いが語られることが多いです。これは、似ている2つの違いを理解してアーキテクチャを設計することが重要なためです。

コマンドはシステムに対して特定のアクションを実行するように指示をします。コマンドは1対1の関係になります。

一方、イベントは発生した事象をシステムに通知します。イベントは受信者に対してアクションを指示するのではなく、あくまでも発生した事象を通知します。これは1対多の関係になります。

例えば、ハンバーガーの注文で考えると、お客さんからハンバーガーとポテトの注文があったとき、コマンド駆動アーキテクチャでは、ハンバーガーを作れ、ポテトを作れとコマンドを投げます。

一方、EDAではハンバーガーとポテトの注文が入ったことを通知します。通知を受け取ったハンバーガー担当はハンバーガーの調理を開始し、ポテトの担当はポテトの調理を開始します。

EDAの利点

冒頭で、EDAが敏捷性や回復性、拡張性が向上するとご紹介しました。その一例を、先ほどのハンバーガーを例にご紹介します。

注文を受けたら、ハンバーガーとポテトを作るので次のような構成にします。

図の構成を簡単に説明すると次のようになります。

ProducerにはAPI Gatewayを採用し、注文用のREST APIを公開します。注文のリクエストがあればJSONフォーマットでイベントを発行します。Event BrokerにはSNSを使い注文のイベントをAPI Gatewayから受け付けます。SNSトピックに注文のイベントを配信します*1。ConsumerにはLambdaを使いSNSのTopicをサブスクライブして注文を処理します。

例えば、ビジネスが上手く行き、ドリンクも販売するようになった場合を考えてください。 EDAでは新しいサービスを追加するのに、SNSをサブスクライブするLambdaを1つ追加するだけで簡単に拡張ができ、既存のコードに影響を与えません。

このように、元々動いているサービスのコードに手を入れる必要が無いので、既存のサービスに問題が発生しづらいのも利点です。さらに3つのサービスは互いに関係無く動作していますので、万が一ドリンク作成サービスに障害が出ても、ハンバーガー作成サービスやポテト作成サービスは動き続けます。

EDAの欠点

EDAには利点もありますが、欠点もあります。

EDAでは多くの場合非同期処理を採用します。非同期処理が増えることで、全体的なシステム設計やデバッグの複雑さが増します。それに合わせて追加のコーディングが必要になります。例えばクライアント側の処理で、同期的な処理であればリクエストの応答に結果が含まれますが、非同期の場合リクエストの応答には最終的な結果が含まれていません。そのため、最終的な結果がどうなったかを取得するための追加の処理が必要になります。