API送信はAPI Destinationsにおまかせを

こんにちは、中山（ @k1nakayama ) です。

昨年の11月にリリースされたAmazon EventBridgeの新機能について、これまでPipes、Schedulerについては紹介してきましたが、もう1つ同時に発表されている、EventBridge API Destinationsについてもオススメの機能なので、今回紹介していきたいと思います。

Amazon EventBridge API Destinationsとは

API Destinationsは、EventBridgeルールをトリガーに、SaaS等が提供する外部APIに対しリクエストを送信する機能です。これまでAPI Gatewayをターゲットとした送信は行えましたが、その送信先が外部APIにも行える様になったイメージです。
またAPI Destinationsは、認証、送信頻度調整、リトライ、デッドレターキューなどの機能が備わっており、API送信について本来考えるべき細かな処理を、API Destinationsが丸っと引き受けてくれます。

何が嬉しいの？

上記の説明だけだとイマイチ通じないですよね？
例えば、あなたの運用しているアプリケーションにおいて、エラーが発生した時や、特定のユーザーアクションが発生した際などに、Slack通知を行う仕組みが備わっているとします。Slack通知される内容は重要な通知です。この通知をあなたはどの様に実装しますか？

ここで考えるべきことがいくつかあります。

Slack通知という単純な処理だったはずですが、本来考えるべきことは山程ありますね。
API Destinationsを使うと、上記に挙げたことがらを設定するだけで満たすことが可能になります。もしも、上記を考えずにLambda関数の中でSlack通知を実装しただけにしていると、重要な通知であるにも関わらず、通知されずにより大きなインシデントに発展してしまうかもしれません。

更に、仮にLambda関数でこのAPI通知を実装した場合、相手のAPIレスポンスが非常に遅い場合など、無駄な実行時間に対する課金が発生してしまいます。API Destinationsは1送信あたり$0.00000024で送信でき、Lambda関数で128MBのメモリで実行した場合だと20ms程度で同様の価格を上回ります。APIレスポンスが20ms以内に収まるAPIはなかなか少ないだろうことを考えると、コスト面で見ても嬉しい機能と言えます。^{*価格はいずれも投稿時点の東京リージョンにおける価格です}

利用方法

API Destinationsについての設定方法は、既に下記のようにいくつか参考になる記事があります。

• https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-api-destinations.html
• https://dev.classmethod.jp/articles/event-bridge-api-destinations-with-slack/

上記を参考に設定をするだけで概ね使えると思いますが、リクエストURLなどに動的なパラメータを含める方法が参照できる情報少なかったため、ここでは、リクエストURLにパラメータを含める方法を簡単に紹介いたします。

API送信先設定

API送信先エンドポイントの欄に動的に設定するパラメータ部分を*に置き換えて設定します。
上記の例では、GitLabのIssue APIに対し、プロジェクトIDとイシューIDがそれぞれ置き換わる箇所を*にしています。
また、1秒あたりの呼び出しレート制限の欄を適切に呼び出し先に合わせて設定すると良いです。

ルール設定

続いてルールを作成する際にパラメータを何を設定するかを指定します。先程API送信先の設定で*に設定した数だけ、パスパラメータのところに設定欄が現れます。URLのルートに近い方（左側）から順番にイベントから指定する値のJSON Pathを設定します。
QueryStringについては、別途キーと値を設定できます。

ユースケース

上記で見てきたように非常に簡単な設定で、API通知をスケーラブルに実装可能です。以前紹介したPipesと組み合わせてDynamoDB等の更新イベントに対し、外部のAPIを叩くことも出来そうですね。

逆に1点注意が必要なのは、APIに対してリクエストを送信した結果を受け取ることはできなさそうです。リクエスト結果を使用することが必要な処理については、引き続きLambda等を使用して取得する必要がありそうです。

上記を踏まえてユースケースを考えてみました。

Slack通知（メッセージ送信）

API Destinationsを使用する上で、最も有力なユースケースと言えそうなのが、Slack通知ではないでしょうか？Slack通知については、AWS上のリソースについてのイベント通知をSlackに送る場合と、アプリケーション内のイベントなど、カスタムなイベント通知を送る場合と大きく2パターンがあると思います。前者の場合、CloudTrailイベントなどをフィルタリングしてルールを作成することで実現できます。後者の場合、Lambda等で処理を実装した上で、EventBusに対してPutEventを行うことで送信することができます。

ちなみに、CloudWatch Alarmなどいくつかの通知については、SNS + ChatBotの組み合わせで簡単にSlack通知を行うことができますので、通知するメッセージの種類などに応じて検討してみると良いでしょう。（もちろん、ChatBotでは通知されるメッセージの形が決まってしまっているので、カスタムな形で通知したい場合などはAPI Destinationsで、という選択もアリかと思います）

なお、API Destinationsのパートナー送信先としてSlackが存在しますが、こちらは認証方式がOAuthに限定されます。もし、Bot User OAuth Tokenを使ってサクッと実装したいという場合は、その他の送信先で認証方式をAPI Keyを選択し、Authorizationヘッダーの値にTokenを与える形で設定すると使えます。

ステータス変更

上記の利用方法のキャプチャでお見せしたものは、GitLabイシューのイベントをWebHookでLambda URLsで受け取り、そのイベント内容に従って、イシューに対するラベル付け等を行う処理を実装したものです。

このように、アプリの処理結果やAWS上のリソース変更をトリガーに、SaaS上のリソースに対するステータス変更等を行いたい時に使えます。今回GitLabを例にしましたが、SalesforeceやZendeskのようなサービスに対してAPIでステータスを更新することもできるかと思います。

モニタリング・分析

AWS上のリソースイベントやアプリケーション上のイベントについて、EventBridgeに一元的に収集し、それらを分析するためのサービスに送信していくことで、外部のSaaSとのシームレスな連携が行なえます。また、監視サービスなどとも同様に連携を図ることができそうです。

まとめ

EventBridgeの機能が益々強力なものになってきています。EventBusとして、一連のイベントをEventBridgeで収集していくことで、よりスムーズに外部連携等が図れるようになったのではないでしょうか？