はじめに
今回はバス関連の機能、グローバルエンドポイントについて調べてみました。
公式の説明については、下記の通りです。
Amazon EventBridge グローバルエンドポイントを使用して、アプリケーションの可用性を向上させることができます。グローバルエンドポイントを使用すると、追加コストなしでアプリケーションをリージョンフォールトトレラントにできます。
2つのリージョンに同じイベントバスを作り、プライマリリージョン側に障害が起きると、セカンダリリージョンへフェイルオーバーしたり、常に両方のリージョンにイベントを送ったりする機能です。
試してみます!
グローバルエンドポイントの作成
名前は適当に。
今回は東京とバージニア北部で作ってみます!
次にプライマリリージョンの正常性を監視するためのヘルスチェックの指定です。
新しいヘルスチェック
を選ぶと、CloudFormationで環境を作ってくれます。
次にイベントレプリケーションの設定を行います。
コストが上がる旨の記載がありますが、1つのイベントを2つのリージョンに送信することで倍のお金がかかるよ。という意味で、特にイベントレプリケーション自体に料金がかかるわけではありません。
なお、事前にセカンダリリージョン側にも同じ名前のイベントバスを作ってないとエラーになります。
セカンダリリージョンにも同じイベントバスを作ったら無事できました!
試してみる。
CLIを使ってイベントを送ってみます。
グローバルエンドポイントを使う場合、endpoint-id
及び、endpoint-url
を追加して送ります。
aws events put-events \
--entries '[{ "Source": "custom.application", "DetailType": "paid", "Detail": "{\"payment_number\": \"00001\"}", "EventBusName": "arn:aws:events:ap-northeast-1:000011112222:event-bus/Cross-Account-Bus" }]' \
--endpoint-id 69fcv3qa03.kwg \
--endpoint-url https://69fcv3qa03.kwg.endpoint.events.amazonaws.com \
なお、両リージョンはルールでSNSを通じてメールを送るようにしています。
東京リージョンは入力トランスフォーマを使い、バージニア北部は使っていません。
イベントを送ってみると、メールが2通届いていることを確認できました!
ヘルスチェックは何してるの?
グローバルエンドポイント作成時に指定するヘルスチェックは何を持って状態監視をしているかを確認してみます。
CloudFormationのスタックの説明を見ると以下のような記載がありました。
Global endpoints health check that will fail when the average Amazon EventBridge latency is above 30 seconds for a duration of 5 minutes. Note, missing data will cause the health check to fail, so if you only send events intermittently, consider changing the heath check to use a longer evaluation period or instead treat missing data as 'missing' instead of 'breaching'.
翻訳:Amazon EventBridgeの平均レイテンシーが5分間にわたって30秒を超えると失敗するグローバルエンドポイントのヘルスチェックです。なお、データが欠損するとヘルスチェックが失敗しますので、イベントを断続的にしか送信しない場合は、より長い評価期間を使用するようにヘルスチェックを変更するか、欠損データを「違反」ではなく「欠損」として扱うことを検討してください。
実際に作成されているリソースを覗いてみると、CloudWatchアラームと、アラーム元にヘルスチェックを行う、Route53ヘルスチェックができてました。
アラームの条件は5 分内の5データポイントのIngestionToInvocationStartLatency > 3000
でした。
最後に
可用性を高める仕組みのグローバルエンドポイントですが、イベントレプリケーションはA/Bテストみたいな検証作業にも使えそうな気がしました。
良い機能です!