目次

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

• EventBridge Rules(イベントパターンとスケジュール)
• EventBridge Pipes
• EventBridge Scheduler

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

アーキテクチャーの違い

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

順に確認します。

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系の新サービスがリリースされました。

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

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

それでは。

Share this article