Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@zumax

Amazon EventBridgeについて整理してみた

Posted at

背景・目的

EventBridgeについて、過去に使用したことはあり、何となくわかったつもりのため、知識として整理したいと思います。

まとめ

下記に特徴を整理します

特徴 説明
概要 ・イベントを介したアプリケーション同士を接続するサーバレスサービス
・イベント駆動型アプリケーションを構築できる
EventBridgeのメリット イベント駆動型アーキテクチャにより、下記が期待できる
・俊敏性を高い
・信頼性が高い
・スケーラブル
可能なこと ソースからのイベントをルーティングできる
・イベントの取り込み
・フィルタリング
・変換
・配信
処理方法 ・イベントバスとパイプの2つがある
・併用も可能
EventBus ・イベントを受信するルーター
・ゼロ個以上の送信先やターゲットに配信。
・イベントをさまざまなソースから多数のターゲットにルーティング
・オプションでターゲットに配信する前にイベントを変換する必要がある際に使用
イベント ・単純なイベントは、JSONオブジェクト
・イベント駆動型アーキテクチャでは、イベントは、リソースや環境の変化を示す指標になることがよくある
AWSからのイベント配信 イベントの種別の1つ。
下記の２つがある
・Best effort delivery
・Durable delivery
イベントソース 下記のイベントソースがある
・AWS サービス
・カスタムアプリケーション
・Software as a Service (SaaS)
ルール 受信したイベントを受信し、処理のためにターゲットに適切に送信する
ターゲット イベントがルールに定義されたイベントパターンと一致すると、イベントを送信するリソースやエンドポイント
EventBridge Pipes ・EventBridge Pipesはソースとターゲットを接続する
・パイプは、サポートされるソースとターゲット間のP2P統合を目的とする
・高度な変換と強化をサポートする
・イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性が軽減され、企業のアプリケーション全体で一貫性が促進される

概要

Amazon EventBridge とはをもとに整理します。

EventBridge は、イベントを使用してアプリケーションコンポーネント同士を接続するサーバーレスサービスです。これにより、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。イベント駆動型アーキテクチャとは、イベントの発信と応答によって連携する、ゆるやかに結合されたソフトウェアシステムを構築するスタイルです。イベント駆動型アーキテクチャは、俊敏性を高め、信頼性が高くスケーラブルなアプリケーションを構築するのに役立ちます。

  • イベントを介したアプリケーション同士を接続するサーバレスサービス
  • イベント駆動型アプリケーションを構築できる
  • イベント駆動型アーキテクチャにより、下記が期待できる
    • 俊敏性を高い
    • 信頼性が高い
    • スケーラブル

EventBridge を使用して、自社開発アプリケーション、AWS サービス、サードパーティソフトウェアなどのソースから組織全体のコンシューマアプリケーションにイベントをルーティングできます。EventBridge では、イベントの取り込み、フィルタリング、変換、配信をシンプルかつ一貫性のある方法で行うことができるため、アプリケーションをすばやく構築できます。

  • イベントをルーティングできる
  • 対象のソース
    • 自社開発アプリケーション
    • AWSサービス
    • サードパーティ
  • EventBridgeでできること
    • イベントの取り込み
    • フィルタリング
    • 変換
    • 配信

EventBridge では次の 2 つの方法でイベントを処理できます: イベントバスとパイプ。
イベントバスは、イベントを受信するルーターであり、ゼロ個以上のターゲットに配信します。イベントバスは、イベントをさまざまなソースから多数のターゲットにルーティングするのに適しており、オプションでターゲットに配信する前にイベントを変換できます。

パイプ EventBridge Pipes はポイントツーポイント統合を目的としています。各パイプは単一のソースからイベントを受け取り、処理して単一のターゲットに配信します。パイプでは、高度な変換やターゲットへの配信前のイベントのエンリッチメントもサポートされています。

パイプとイベントバスはよく一緒に使用されます。一般的なユースケースは、イベントバスをターゲットとするパイプを作成することです。パイプはイベントをイベントバスに送信し、イベントバスはそれらのイベントを複数のターゲットに送信します。たとえば、ソースに DynamoDB ストリームを使用し、ターゲットとしてイベントバスを含むパイプを作成できます。パイプは DynamoDB ストリームからイベントを受け取り、イベントバスに送信します。イベントバスは、イベントバスで指定したルールに従ってイベントを複数のターゲットに送信します。

  • イベント処理方法は下記の2つがある
    • イベントバス
    • パイプ
  • イベントバスの特徴
    • イベントを受信するルーター
    • ゼロ個以上のターゲットに配信できる
    • イベントを様々なソースから多数のターゲットにルーティングするのに適している
    • オプションでターゲットに配信する前にイベントを変換できる
  • パイプの特徴
    • ポイントツーポイント統合を目的としている
    • 単一のソースから受け取り、処理して単一のターゲットに配信する
    • 高度な変換やターゲットへの配信前のイベントのエンリッチメントが可能
  • イベントバスとパイプの併用は可能
  • ユースケース
    • イベントバスをターゲットとするパイプを作成
      1. パイプはイベントをイベントバスに送信
      2. イベントバスはそれらのイベントを複数のターゲットに送信
    • 例：DDBストリームを使用して、ターゲットにイベントバスを含むパイプ
      1. パイプは、DDBストリームからイベントを受け取り、イベントバスに送信
      2. イベントバスは、イベントバスで指定したルールに従いイベントを複数ターゲットに送信

Amazon EventBridge EventBus

イベントバスは、イベントを受信するルーターであり、ゼロ個以上の送信先やターゲットに配信します。イベントバスは、イベントをさまざまなソースから多数のターゲットにルーティングするのに適しており、オプションでターゲットに配信する前にイベントを変換できます。

イベントバスに関連付けられたルールによって、受信したイベントが評価されます。各ルールは、イベントがルールのパターンに一致するかどうかをチェックします。イベントが一致した場合、イベント EventBridge を送信します。
ルールを特定のイベントバスに関連付けると、そのルールはそのイベントバスで受信したイベントにのみ適用されます。

  • イベントバスに関連付けられたルールにより、受信したイベントが評価される
  • 各ルールは、イベントがルールのパターンに一致するかチェックする
  • イベントが一致した場合、送信する

image.png

出典：Amazon EventBridge イベントバス

Amazon EventBridge EventBusの概念

イベントバス

イベントバスは、イベントを受信するルーターであり、ゼロ個以上の送信先やターゲットに配信します。イベントバスは、イベントをさまざまなソースから多数のターゲットにルーティングし、オプションでターゲットに配信する前にイベントを変換する必要がある際に使用します。

アカウントには、 AWS サービスからイベントを自動的に受信するデフォルトのイベントバスが含まれています。以下の操作も可能です。

  • カスタムイベントバスという名のイベントバスを追加作成し、受信するイベントを指定します。
  • パートナーイベントバスを作成します。これは、SaaS パートナーからイベントを受信します。
  • AWSサービスからイベントを自動的に受診するイベントバス
  • カスタムイベントバス
  • SaaSパートナーからのパートナーイベントバス

イベントバスの一般的な使用例には以下が含まれます。

  • イベントバスを異なるワークロード、サービス、またはシステム間の仲介役として使用します。
  • アプリケーション内で複数のイベントバスを使用してイベントトラフィックを分割します。たとえば、個人識別情報 (PII) を含むイベントを処理するバスを作成し、個人識別情報 (PII) を含まないイベント用に別のバスを作成する場合などです。
  • 複数のイベントバスから一元化されたイベントバスにイベントを送信してイベントを集約します。この集中型バスは、他のバスと同じアカウントにあっても、別のアカウントやリージョンにあってもかまいません。
  • 使用例
    • 異なるワークロード、サービス、システム間の仲介役
    • アプリケーション内で複数のイベントバスを使用してイベントトラフィックを分割
    • 複数のイベントバスから一元化されたイベントバスにイベントを集約

image.png

出典：Amazon EventBridge EventBusの概念

イベント

最も単純なイベントは、 EventBridge イベントバスまたはパイプに送信される JSON オブジェクトです。
イベント駆動型アーキテクチャ (EDA) のコンテキストでは、イベントはリソースや環境の変化を示す指標となることがよくあります。

  • 単純なイベントは、JSONオブジェクト
  • イベント駆動型アーキテクチャでは、イベントは、リソースや環境の変化を示す指標になることがよくある

イベントソース

  • 下記のイベントソースがある
    • AWS サービス
    • カスタムアプリケーション
    • Software as a Service (SaaS)

ルール

ルールは、受信したイベントを受信し、処理のためにターゲットに適切に送信します。各ルールがターゲットを呼び出す方法は、次のいずれかに基づいて指定できます。

  • イベントパターン。イベントに一致する 1 つ以上のフィルターが含まれています。イベントパターンには、次の条件に一致するフィルターを含めることができます。
    • イベントメタデータ — イベント (イベントソースなど)、またはイベントが発生したアカウントまたはリージョンについてのデータ。
    • イベントデータ — イベント自体のプロパティ。これらのプロパティはイベントによって異なります。
    • イベントコンテンツ — イベントデータの実際のプロパティ値。
  • ターゲットを定期的に呼び出すスケジュール。
    スケジュールされたルールは、 内で、またはスケジューラ を使用して指定 EventBridgeできます。 EventBridge
  • ルールは受信したイベントを受信し、処理のためにターゲットに適切に送信する
  • 各ルールがターゲットを呼び出す方法、下記のいずれかに基づき指定できる
    • イベントパターン
      • イベントメタデータ
      • イベントデータ
      • イベントコンテンツ
    • スケジュール

各ルールは特定のイベントバスに対して定義され、そのイベントバス上のイベントにのみ適用されます。
1 つのルールで、最大 5 つのターゲットにイベントを送信できます。
デフォルトでは、イベントバスあたり最大 300 のルールを設定できます。このクォータは、Service Quotas コンソール内で数千のルールまで増やすことができます。ルール制限は各バスに適用されるため、さらに多くのルールが必要な場合は、アカウントに追加のカスタムイベントバスを作成できます。
サービスごとに異なるアクセス許可を持つイベントバスを作成することで、アカウントでのイベントの受信方法をカスタマイズできます。
がターゲットに EventBridge 渡す前にイベントの構造または日付をカスタマイズするには、Input Transformer を使用して、ターゲットに移動する前に情報を編集します。

  • 一つのルールで最大5つのターゲットにイベントを送信できる
  • イベントバスあたり、デフォルト300までルールを設定できる
  • サービスごとに異なるアクセス許可を持つイベントバスを作成し、アカウントでのイベントの受診方法をカスタマイズできる
  • ターゲットにイベントを渡すまえに、Input Transformerを使用しカスタマイズできる

ターゲット

ターゲットは、イベントがルールに定義されたイベントパターンと一致すると、 がイベント EventBridge を送信するリソースまたはエンドポイントです。
ターゲットは複数のイベントバスから複数のイベントを受信できます。

  • イベントがルールに定義されたイベントパターンと一致すると、イベントを送信するリソースやエンドポイント
  • 複数のイベントバスから複数のイベントを受信できる

イベントバス用の高度な機能

API 送信先を使用して、サービス間の REST API コールを有効にする

EventBridge API 送信先は、 AWS サービスまたはリソースにイベントデータを送信するのと同じ方法で、ルールのターゲットとして設定できる HTTP エンドポイントです。API 送信先を使用すると、API コールを使用して、 AWS サービス、統合された SaaS アプリケーション、および AWS外のアプリケーションの間でイベントをルーティングできます。API 送信先を作成するときは、その送信先に使用する接続を指定します。各接続 には、API 送信先エンドポイントでの認証に使用する認証タイプとパラメータに関する詳細が含まれます。

  • HTTPエンドポイント
  • APIを通してルーティングできる
開発とディザスタリカバリに役立つイベントの Archive and Replay

イベントをアーカイブして、後でそのアーカイブからイベントを再生することができます。アーカイブは次のような場合に役立ちます。

  • 新しいイベントを待つのではなく、イベントを保存して利用できるので、アプリケーションのテストに便利です。
  • 新しいサービスが初めてオンラインになったら、ハイドレートします。
  • イベント駆動型アプリケーションの耐久性を高めます。
  • イベントをアーカイブする。後ほどそのアーカイブからイベントを再生できる
スキーマレジストリを使用してイベントパターンの作成をすぐに開始する

を使用するサーバーレスアプリケーションを構築する場合 EventBridge、イベントを生成しなくても一般的なイベントの構造を把握すると便利です。イベント構造は、スキーマ で説明されています。スキーマ は、 AWS のサービスによって生成されたすべてのイベントで使用できます EventBridge。
AWS サービスから発生したものではないイベントの場合、次のことができます。

  • カスタムスキーマを作成またはアップロードします。
  • Schema Discovery を使用して、 がイベントバスに送信されるイベントのスキーマ EventBridge を自動的に作成します。

イベントのスキーマがあれば、一般的なプログラミング言語のコードバインディングをダウンロードできます。

  • AWSサービスから発生したものではないイベントの場合
    • カスタムスキーマを作成また発布ロードできる
    • Schema Discoveryを使用して、EventBridgeを自動的に作成する
ポリシーによるリソースへのアクセスの管理

AWS リソースを整理したり、 でコストを追跡したりするには EventBridge、リソースに AWS カスタムラベル またはタグ を割り当てることができます。タグベースのポリシー を使用すると、 内で実行できるリソースとできないリソースを制御できます EventBridge。

  • コストを追跡するには、AWSカスタムラベルまたはタグを割り当てる

タグベースのポリシーに加えて、 は へのアクセスを制御するためにアイデンティティベースのポリシーとリソースベースのポリシー EventBridge をサポートします EventBridge。アイデンティティ ベースのポリシーを使用して、グループ、ロール、またはユーザーのアクセス許可を制御します。リソースベースのポリシーを使用して、Lambda 関数や Amazon SNS トピックなど各リソースに特定のアクセス許可を付与します。

  • リソースベースのポリシーとアイデンティティベースのポリシーをサポートする

Amazon EventBridge イベント

イベントとは、 AWS 環境、SaaS パートナーサービスやアプリケーション、またはお客様のアプリケーションやサービスなどの環境での変化を示します。以下は、イベントの例です。

  • インスタンスの状態が保留中から実行中に変更されると、Amazon EC2 はイベントを生成します。
  • Amazon EC2 Auto Scaling は、インスタンスを起動または終了するときにイベントを生成します。
  • AWS CloudTrail API 呼び出しを行うとイベントが公開されます。
  • イベントとは、下記のサービスやアプリケーションなどの環境変化を示す

定期的に生成される予定されたイベントをセットアップすることもできます。
各サービスのサンプルイベントなど、イベントを生成するサービスの一覧については、「AWS サービスからのイベント」を参照し、表のリンクに従ってください。
イベントは JSON オブジェクトとして表現され、同じような構造をしています。トップレベルのフィールドも同じです。

[detail] の最上位のフィールドの内容は、どのサービスがイベントを生成したか、そのイベントが何であるかによって異なります。[source] フィールドと [detail-type] フィールドの組み合わせは、[detail] フィールドで見つかるフィールドと値を識別するために役立ちます。 AWS サービスによって生成されるイベントの例については、を参照してくださいAWS サービスからのイベント。

  • イベントはJSONオブジェクトである

イベント構造リファレンス

イベントには、次のフィールドが表示されます。

    {
      "version": "0",
      "id": "UUID",
      "detail-type": "event name",
      "source": "event source",
      "account": "ARN",
      "time": "timestamp",
      "region": "region",
      "resources": [
        "ARN"
      ],
      "detail": {
        JSON object
      }
    }
フィールド 説明
version デフォルトゼロ（0）
id ・イベントごとに生成されるバージョン 4 UUID
・ルールからターゲットに移動するときのイベントをトレースできる
detail-type ソースフィールドと組み合わせて、詳細フィールドに表示されるフィールドと値を識別する
source イベントを生成したサービスを識別する
・AWSサービスから発生するすべてのイベントは、「aws」で始まる
・顧客が生成したイベントは任意（ただしawsから始めることはできない）
・Javaパッケージ名スタイルの逆ドメイン名文字列を推奨
・AWSサービスの正しい値の見つけかた（※1）
account AWSアカウントを識別する12桁の番号
time イベントのタイムスタンプ
region イベントが発生したAWSリージョン
resource リソースを識別するARNを含むJSON
ARNが含まれない場合もある
detail イベントに関する情報を含むJSONオブジェクト

※1:条件キーテーブル

AWS サービスからのイベント

AWS サービスからのイベント配信

AWS イベントを生成する各サービスは、 EventBridge ベストエフォート型または永続的な配信試行のどちらかにイベントを送信します。

  • ベストエフォート配信とは、サービスがすべてのイベントの送信を試みるが EventBridge、まれにイベントが配信されない場合があることを意味します。
  • 永続配信とは、 EventBridge サービスが少なくとも 1 回は正常にイベントの配信を試みることを意味します。
    EventBridge 通常の条件下では、すべての有効なイベントを受け付けます。 EventBridge サービスの中断によりイベントを配信できない場合は、後からサービスによって最大 24 時間再試行されます。 AWS
    イベントが配信されたら EventBridge、 EventBridge ルールと照合し、再試行ポリシーとイベントターゲットに指定されたデッドレターキューに従います。
  • AWSからのイベント配信は、下記の２つに分けられる
    • Best effort delivery
      • サービスがすべてのイベントの送信を試みるが EventBridge、まれにイベントが配信されない場合がある
    • Durable delivery
      • EventBridge サービスが少なくとも 1 回は正常にイベントの配信を試みる
      • Event配信できない場合は、あとからサービスによって最大24H再試行される

Receiving events from a SaaS partner with Amazon EventBridge

SaaS パートナーアプリケーションおよびサービスからイベントを受信するには、そのパートナーからのパートナーイベントソースが必要です。その後、パートナーイベントバスを作成し、対応するパートナーイベントソースに一致させることができます。

  • SaaSパートナーからイベント受診する際には、パートナーイベントソースが必要

イベントの再試行ポリシーとデッドレターキューの使用

ルールで指定されたターゲットにイベントが正常に配信されないことがあります。これは、ターゲットリソースが使用できない場合や、 EventBridge ターゲットリソースに対する権限がない場合や、ネットワークの状態などが原因で発生することがあります。再試行可能なエラーが原因でイベントがターゲットに正常に配信されなかった場合、 EventBridge イベントの送信を再試行します。ターゲットの再試行ポリシー設定で、再試行する時間の長さと再試行回数を設定します。デフォルトでは、指数関数的なバックオフとジッター、またはランダムな遅延を発生させて、24 時間、最大 185 EventBridge 回イベントの送信を再試行します。再試行がすべて終了してもイベントが配信されない場合、そのイベントはドロップされ、処理は続行されません。 EventBridgeターゲットへの配信に失敗した後でイベントが失われるのを避けるために、デッドレターキュー (DLQ) を設定し、失敗したすべてのイベントをそこに送って後で処理することができます。

  • 下記の理由などにより、指定されたターゲットにイベントが正常に配信されないことがある
    • ターゲットリソースが使用できない
    • ターゲットリソースに対して権限がない
    • NWの状態
  • 再施行可能なエラーが原因で正常に配信されない場合は、イベントの再試行を行う
    • 再試行ポリシー設定で、再試行する時間の長さと再試行回数を設定する
    • デフォルトは、Exponential Backoff And Jitterまたは、ランダムな遅延を発生させて24H 最大185 回のイベント送信を再試行する
    • 再試行がすべて終了しても配信されない場合は、イベントがドロップされる
  • EventBridgeターゲットへの配信に失敗したあとで、イベントが失われるのを避けるために、DLQを設定する
    • 失敗したすべてのイベントをそこに送り、後で処理する

EventBridge DLQ は、 EventBridge ターゲットに正常に配信できなかったイベントの保存に使用される標準の Amazon SQS キューです。DLQ を使用するかどうかは、ルールを作成してターゲットを追加するときに選択できます。DLQ を設定すると、正常に配信されなかったイベントを保持できます。そのため、失敗したイベント配信の原因となった問題を解決し、後でイベントを処理できるようになります。

  • EventBridge DLQとは、EventBridgeターゲットに正常に配信できなかったイベントの保存に使用される標準SQSキュー
  • DLQを設定すると、正常に配信されなかったイベントを保持する
    • 解決したあとでイベント処理ができる

イベントエラーには、さまざまな処理方法があります。一部のイベントは、再試行せずに削除されるか、DLQ に送信されます。例えば、ターゲットへのアクセス許可がない、またはターゲットリソースが存在しなくなったためにエラーが発生する場合、根本的な問題を解決するアクションが実行されるまで、再試行はすべて失敗します。 EventBridge これらのイベントは、再試行せずに DLQ に直接送信されます (DLQ がある場合)。

  • イベントエラーは、再試行せずに削除されるか、DLQをに送信される

イベント配信が失敗した場合、invocationターゲットが失敗したことを示すイベントを Amazon EventBridge CloudWatch メトリックスに公開します。DLQ を使用すると、 CloudWatchInvocationsSentToDLQとを含むに追加のメトリックスが送信されます。InvocationsFailedToBeSentToDLQ

  • イベント配信が失敗した場合、invocationターゲットが失敗したことを示すイベントを CloudWatchメトリックスに公開する

デッドレターキューを使用する際の考慮事項

の DLQ を設定する際は、次の点を考慮してください。 EventBridge

  • サポートされるのは標準キューのみです。DLQ 入力には FIFO キューを使用できません。 EventBridge
  • EventBridge には、エラーコード、エラーメッセージ、超過再試行条件、ルール ARN、再試行回数、ターゲット ARN などのイベントメタデータとメッセージ属性が含まれます。これらの値を使用して、イベントと障害の原因を特定します。
  • 同じアカウントの DLQ に対するアクセス許可。
    • コンソールを使用してルールにターゲットを追加し、同じアカウントの Amazon SQS キューを選択すると、 EventBridge キューへのアクセスを許可するリソースベースのポリシーがキューにアタッチされます。
    • EventBridge API PutTargets のオペレーションを使用してルールのターゲットを追加または更新し、同じアカウントで Amazon SQS キューを選択した場合、選択したキューに手動でアクセス権限を付与する必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
  • AWS 別のアカウントの Amazon SQS キューを使用するための権限。
    • コンソールからルールを作成する場合、他のアカウントのキューは表示されないため選択できません。他のアカウントのキューへのアクセス許可を付与するには、そのキューの ARN を指定し、リソースベースのポリシーを手動でアタッチする必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
    • API を使用してルールを作成する場合、デッドレターキューとして使用される別のアカウントの SQS キューに、リソースベースのポリシーを手動でアタッチする必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
  • 使用する Amazon SQS キューは、ルールを作成するリージョンと同じリージョンに存在する必要があります。
  • DLQを設定する際は、下記を考慮する
    • 標準キューのみサポートされる
  • SQSキューは、ルールを作成するリージョンと同じリージョンに存在する必要がある

デッドレターキューからイベントを再送信する方法

メッセージを DLQ から移動するには、次の 2 つの方法があります。

  • Amazon SQS コンシューマーロジックの作成を避ける - DLQ をイベントソースとして Lambda 関数に設定し、DLQ を吸い出します。
  • Amazon SQS コンシューマーロジックの作成 — Amazon SQS API、 AWS SDK を使用するか AWS CLI 、DLQ 内のメッセージをポーリング、処理、削除するためのカスタムコンシューマーロジックを記述します。
  • メッセージをDLQから移動する方法
    • DLQをイベントソースとして、Lambda関数を設定しDLQから取得する
    • SQS API、SDK等を使用し、メッセージをポーリング、処理、削除するためのカスタムコンシューマーロジックを書く

Amazon EventBridge パイプ

Amazon EventBridge Pipes はソースとターゲットを接続します。パイプは、サポートされるソースとターゲット間のポイントツーポイント統合を目的としており、高度な変換と強化をサポートします 。イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性が軽減され、企業のアプリケーション全体での一貫性が促進されます。パイプを設定するには、ソースを選択し、オプションのフィルタリングを追加し、オプションのエンリッチメントを定義して、イベント データのターゲットを選択します。

  • EventBridge Pipesはソースとターゲットを接続する
  • パイプは、サポートされるソースとターゲット間のP2P統合を目的とする
  • 高度な変換と強化をサポートする
  • イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性が軽減され、企業のアプリケーション全体で一貫性が促進される
  • 設定するには下記を行う
    • ソースの選択
    • オプションのフィルタリングを追加
    • オプションのエンリッチメントを定義
    • イベントデータのターゲットを選択

EventBridge パイプの仕組み

EventBridge パイプの概念

image.png

ソース

EventBridge Pipes は、さまざまなソースからイベント データを受信し、そのデータにオプションのフィルターとエンリッチメントを適用して、ターゲットに送信します。ソースがパイプに送信されるイベントに順序を強制する場合、その順序はターゲットへのプロセス全体を通じて維持されます。

  • 様々なソースからイベントデータを受信する
フィルター

パイプは、特定のソースのイベントをフィルターして、それらのイベントのサブセットのみを処理できます。パイプでフィルタリングを構成するには、ターゲットに送信するイベントを決定するためにパイプが使用するイベント パターンを定義します。

  • 特定のソースのイベントをフィルターできる
エンリッチメント

EventBridge Pipes の強化ステップを使用すると、ソースからのデータをターゲットに送信する前に強化できます。たとえば、完全なチケット データが含まれていないチケット作成イベントを受信する場合があります。エンリッチメントを使用すると、Lambda 関数でget-ticketAPI を呼び出してチケットの完全な詳細を取得できます。その後、パイプはその情報をターゲットに送信できます。

  • エンリッチメントの強化ステップ
ターゲット

イベントデータがフィルタリングされ強化された後、Amazon Kinesis ストリームや Amazon CloudWatch ロググループなどの特定のターゲットに送信するパイプを指定できます。使用可能なターゲットのリストについては、「Amazon EventBridge Pipes ターゲット」を参照してください。

  • Kinesis Stream、CloudWatch Logsなどの特定のターゲットに送信するパイプを指定できる

データは、拡張後、パイプによってターゲットに送信される前に変換できます。詳細については、「Amazon EventBridge Pipes の入力変換」を参照してください。

それぞれが異なるソースを持つ複数のパイプは、同じターゲットにイベントを送信できます。

パイプとイベント バスを一緒に使用して、複数のターゲットにイベントを送信することもできます。一般的な使用例は、イベント バスをターゲットとしてパイプを作成することです。パイプはイベントをイベント バスに送信し、イベント バスはそれらのイベントを複数のターゲットに送信します。たとえば、ソースとして DynamoDB ストリームを使用し、ターゲットとしてイベント バスを使用するパイプを作成できます。パイプは、DynamoDB ストリームからイベントを受信し、イベント バスに送信します。イベント バスは、イベント バスで指定したルールに従って、イベントを複数のターゲットに送信します。

  • 複数のターゲットに送信も可能
  • 一般的な使用方法は、イベントバスをターゲットにパイプを作成する

考察

今回は、EventBridgeをおさらいしました。EventBridge Pipesは使ったことがないので、今後試してみようと思います。

参考

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?