[アップデート] Amazon EventBridge でターゲット配信成功までのレイテンシを監視出来るようになったので、配信遅延を発生させて観察してみた

いわさです。

先日のアップデートで Amazon EventBridge に新しい CloudWatch メトリクスが追加されました。

https://aws.amazon.com/about-aws/whats-new/2024/09/amazon-eventbridge-event-delivery-latency-metric-event-buses/

イベントの取り込みからターゲットへの配信までのレイテンシを示すメトリクスで、成功したイベントのみを対象とする計測値のため、エラーが起きていないイベント・ドリブンなワークロードでの遅延を検出することが出来ます。

マネージドサービスな EventBridge でイベント配信遅延ってどういう時にそもそも起きるのか？という点が気になった方もいると思いますが、EventBridge ルールで配信先として設定するターゲットで何らかの問題（スロットリングがプロビジョニング不足など）が起きており、イベントコンシューマー側起因で遅延が発生するパターンは実はよく起きます。

今回このメトリクスを使ってレイテンシ増加の様子を観察してみましたので紹介します！

ドキュメント

次のドキュメントは EventBridge 向けのモニタリングガイドラインです。こちらに新しいメトリクス「IngestionToInvocationSuccessLatency」が追加されています。

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-monitoring.html

従来から取り込みレイテンシを示すものとしては IngestiontoInvocationStartLatency と IngestiontoInvocationCompleteLatency いうメトリクスがありましたが、イベント配信の開始から終了までの一部を示すものであり、成功したイベントを対象に全体の配信遅延を監視出来るメトリクスは今回追加されたものが初です。

配信遅延の検証をしてみる

ではイベントドリブンなアプリケーションを用意し、配信遅延がおきた時にメトリクスがどのように変化するのか観察してみます。
ユーザーがコントロールしやすい一番簡単なものは API Gateway ではないでしょうか。スロットリングやバースト設定の制御に長けているので意図的にスロットリングを発生させたい際に使います。

今回は EventBridge ルールのターゲットに API Gateway を設定し、レイテンシを観察してみましょう。

EventBridge ルールを新規作成します。割愛しますがイベントパターンは AWS アカウント上で発生する全てのイベントとしました。結構な数になりそうですね。
そしてターゲットに適当に用意した API Gateway を設定します。API Gateway は呼び出しできればなんでも良いので REST API + Mock な環境を事前に作成しておきました。

まずはスロットリングなしでメトリクスを観察してみましょう。
早速イベントがが大量に発生し始めていますね。

結構頻繁に呼び出される状態で、追加されたIngestionToInvocationSuccessLatencyを見てみると、平均 60-100 くらいでしょうか。単位はミリ秒です。

スロットリング発生させる

では、API Gateway でスロットリングを発生させてみます。
ステージ設定から 1 秒あたり 1 リクエストまでしか処理出来ないようにしましょう。Too Many Request がレスポンスされ、EventBridge 側で再試行が発生することで結果的に遅延が発生するはず...です。

しばらく待ってメトリクスを見てみると...
おっ、かなり遅延が発生しはじめているようですね！
平均 20,000 ms です。

このあたりを検出して、レイテンシが増加しているので何か問題が発生しているのではと気づくことが出来そうです。
では問題に気がついた場合を想定してスロットリングの解除をしてみましょう。

またしばらく経過してメトリクスを見てみると、レイテンシが落ち着いたことが確認出来ました。
次のようにスロットリングが発生していた間だけレイテンシがかなり増大していたことがわかりますね。

さいごに

本日は Amazon EventBridge でターゲット配信成功までのレイテンシを監視出来るようになったので、配信遅延を発生させて観察してみました。

通常 X-Ray などを組み合わせてどこで遅延が起きているのかトラブルシューティングすると思いますが、検知する仕組みとしてこのメトリクスは非常に重要だと思いますね。
イベントドリブンなワークロードを運用されている方は使ってみてください。