イベント駆動サービスAmazon EventBridge 3兄弟をどう使い分ける?(Rules/Scheduler/Pipes) #reinvent

2022.12.02

AWSのサーバーレスのイベント駆動サービスEventBridgeには、最近になって SchedulerPipes という2種類の似たサービスが発表され、EventBridgeファミリーは3兄弟になりました。

の違いについて、簡単に整理します。

アーキテクチャーの違い

イベントの発生や処理方法で分類すると、用途が明確です。

サービス Rules Pipes Scheduler
ネームスペース events.amazonaws.com pipes.amazonaws.com scheduler.amazonaws.com
Publisher/Subscriber o
Producer/Consumer o
Schedule o

順に確認します。

Publisher/Subscriber(Pub/Sub)型

Pub/Sub型では、Publisherがメッセージブローカーにメッセージを送信(publish)すると、メッセージブローカーは購読(subscribe)しているすべてのSubscriberにメッセージをプッシュ(ブロードキャスト)します。

  • EventBridge Rules(イベントパターン)

がこのメッセージングモデルを採用し、メッセージブローカーとして機能します。

1:多なFan Out処理が可能です。

Amazon SNS もこのメッセージングモデルです。

Producer/Consumer 型

Producer/Consumer 型では、Producer がメッセージブローカーにメッセージを送信し、Consumerはメッセージブローカーをポーリングしてメッセージを受信します。

  • EventBridge Pipes

がこのメッセージングモデルを採用し、メッセージブローカーとConsumerを仲介します。

EventBridge Pipes のソースとして指定できる各種サービスは、メッセージキュー(SQSなど)とストリーミングサービス(Kinesis Data Streamsなど)の違いこそあれ、このメッセージングモデルです。

EventBridge Pipes を利用すると、Consumerの処理をSourceやTargetに関係なく

  1. Source(どのメッセージブローカー?)
  2. Filter(どのタイプのメッセージ?)
  3. Enrichment(プリプロセス)
  4. Target(誰がメッセージを処理?)

のフローで一貫して処理できます。

図は公式ドキュメントから引用

スケジュール型

スケジュール型では、決められたスケジュール(イベント)でターゲットを呼び出します。

  • EventBridge Rules(スケジュール)
  • EventBridge Scheduler

がこのメッセージングモデルを採用しています。

後発の EventBridge Scheduler はEventBridge Rules(スケジュール)の上位互換的な位置づけです。

目的から手段を選ぶ

スケジュール実行したい

EventBridge Schedulerを利用しましょう。

EventBridge Rulesを利用している場合、後続サービスであるEventBridge Schedulerへの移行を検討しましょう。

AWSサービス/SaaSをソースとするイベント駆動

EventBridge Rules(イベントパターン)を継続利用しましょう。

AWSマネージドのメッセージキュー・ストリームサービスを利用

メッセージブローカーやワーカーに関係なくメッセージ処理(Consumer)のパイプラインを抽象化したい場合、EventBridge Pipesの利用を検討しましょう。

最後に

EventBridgeはその前進のCloudWatch Eventsも含めると、2016年から続く、歴史あるサービスです。

過去1ヶ月で、Scheduler・Pipesと立て続けにEventBridge系の新サービスがリリースされました。

EventBridge SchedulerはEventBridge Rulesのスケジュールを再定義したものであり、EventBridge Pipesは従来カバーできていなかったProducer/Consumer型のメッセージング処理をカバーするものです。

EventBridge RulesのPub/Sub系処理は、今後も継続してご利用ください。

それでは。