Amazon EventBridge Pipesを使ってBudgetsをChatworkに通知する
はじめに
こんにちは!
7月より新しくシステム統括課に加わりました、インフラチーム担当の田村です!
突然ですが、皆さんはAWSからチャットツールへの通知はどのように行っていますか?
取得データやソースイベントからのデータをLambdaを介してメッセージ投稿を行うか、またSlackやMicrosoft teamsなどであればAWS Chatbotを利用する事で簡単に通知ができるようになります。
Chatworkを利用している場合、AWS Chatbotが未対応のためLambdaを介して連携するのが一般的かと思います。
でも、Lambdaのコード実装と管理は少し手間ですよね?
今回はLambdaを使わず、Amazon EventBridge Pipesを利用してBudgetsをChatworkに通知させる方法を紹介します!
【前提】
- Chatwork APIトークンが払いだされている事
- AWS Oraganizationsを利用している事
今回Budgetsアラートの通知を行います。
Organizationsの管理アカウントで作業を行い、Budgetsの予算作成対象はメンバーアカウントになります。
【Amazon EventBridgeのPipesとAPI送信先について】
Amazon EventBridge Pipesは2022年末に新しくリリースされた機能で、イベントソースからのイベントデータをターゲットに受け渡すパイプラインを構築できます(調べている中で初めて知りました)。
特に、後述するAPI送信先をターゲットにする事で、わざわざLambdaを実装しなくても外部連携ができるようになります。
API送信先とは、AWSのサービスやリソースをターゲットとして呼び出す時と同様に、ルールのターゲットとして呼び出せるHTTPエンドポイントになります。これを利用する事でイベントソースからのデータをHTTPエンドポイント経由でサードパーティ製ツールに渡すことができ、Chatworkにもこの機能を使ってAWSからメッセージ投稿ができるようになります。
参考記事:Amazon EventBridgeを使ってChatworkにメッセージを送ってみた
仮説
現状AWS Chatbotが対応しているチャットツールは、Slack・Amazon Chime・Microsoft teamsのみですが、下記4点から、EventBridge Pipesを使えばLambdaを介さずともChatworkにBudgetsアラートを投稿できるのでは、という結論に至りました。
- Budgetsは通知先にSNSトピックを指定できる
- API送信先を利用する事でChatworkへ通知ができる
- EventBridge PipesはイベントソースにSQSを、ターゲットにAPI送信先を設定可能
- 上記からBudgets→SNS→SQS→EventBridge Pipesの構成が可能
実際に準備して検証をしてみます
検証準備
今回の検証に使用するサービスは以下のとおりです。
- SNS
- SQS
- Amazon EventBridge(PipesとAPI送信先)
- AWS Budgets
①SNSトピックとSQSキューの作成
SNSトピックの作成を行います。Simple Notification Serviceのサービスからトピックを作成していきます。
今回作成するトピック名は「Budgets_Alart」、タイプはスタンダード、アクセスポリシーは「ベーシック」を選択し、パブリッシャー・サブスクライバー共に「全員」を指定、他はデフォルト値になります。
問題なければ「トピックの作成」をクリック
このように作成されていればOK。
次にSQSキューの作成を行います。Simple Queue Serviceのサービスにいき、キューを作成します。
キューの名前は「Budgets_Alart」とし、タイプを標準キーにしてあとはデフォルト設定値にします。
SNSトピックとSQSキューの作成が完了したら、サブスクリプション登録を行います。
SNS、SQSどちらのコンソールからも設定できますが、今回はSNSのコンソールから登録します。
プロトコルにSQSを選択し、エンドポイントに先ほど作成したSQSキューを指定、更に「rawメッセージ配信の有効化」にチェックを入れます。
※有効化しないとBudgetsアラートがjson形式で飛んできてしまい、非常に見づらくなってしまいます。
②Amazon EventBridge PipesとAPI送信先の作成
Amazon EventBridgeのサービスに移り、先にAPI送信先の作成を行います。
「API送信先を作成」を選択します。
名前・API送信先エンドポイント・HTTPメソッドを入力します。名前は今回「Chatwork」とします。
エンドポイントは現在「https://api.chatwork.com/v2/rooms/[送信先のルームID]/messages」となっており、[送信先のルームID]に通知したいルームのIDを入力します。
※2023年8月現在の情報になります。最新のエンドポイントはChatworkのサイトを確認してください。
また今回は投稿を行うので、HTTPメソッドはPOSTです。特に要件もないので、レート制限はデフォルトの300の値を入れてます(デフォルトの場合は入力しなくてもOK)。
接続先の設定も必要ですので、「新しい接続を作成」を選択。
任意の接続名を入力・認証タイプはAPIキー、APIキー名に「X-ChatWorkToken」・値に用意したトークンの値を入力します。
入れ終わったら「作成」。
APIの送信先と接続がそれぞれこのように作成されます。
次にPipesに移り、「パイプの作成」を選択します。
このような画面に遷移したら、まずはソースの設定を行います。
ソースに先ほど作成したSQSキューを設定します。
次に、ターゲットを設定します。ターゲットサービスで「API送信先」を選択し、送信先に「Chatwork」を指定します。
またクエリ文字列パラメータを設定します。キー「body」・値「$.body」を設定します。これを設定しないとBudgetsアラートがChatworkまで飛んでくれません。
ここまで入力が完了したら、「パイプの作成」を押します。
作成後、このようにステータスが実行中になったらパイプの構築完了です。
③Budgetsの予算アラートの作成
最後に、Budgetsにて予算の作成とアラートの設定を行います。
今回は検証用にすぐに通知を飛ばしたいため、既に課金が発生しているアカウントに対して予算額0.01USD・閾値を100%で設定していきます。
請求コンソールからBudgetsの画面に移動し、「予算を作成」を選択します。
予算の設定は「カスタマイズ(アドバンスト)」、予算タイプは「コスト予算」を選択します。
予算名を入力し、期間「月」・予算更新タイプ「定期予算」・予算設定方法「固定」・予算額「0.01」に設定します。
次に予算の範囲を設定していきます。
今回作成対象がメンバーアカウントになるので、範囲オプションで「特定のAWSコストディメンションをフィルタリングする」にチェックを入れ、ディメンションを「リンクされたアカウント」・値に作成したいアカウントを選択して「フィルターを適用」を押します。
フィルターが適用されるとこのような表示になり、作成したいメンバーアカウントのみのコストを対象とする事ができます。
コストの集計基準は「非ブレンドコスト」、今回は請求タイプから「税金」と「サポート料金」を除きたいので削除し、「次へ」。
アラートの閾値を設定していきます。今回は予算額の100%にし、トリガーは実際のコストにします。
通知設定にAmazon SNSアラートを選択し、ここで「①SNSトピックの作成」にて作成したSNSトピックのARNをコピー&ペーストします。
SNSトピックに問題が無ければ、「次へ」。
予算アラートをトリガーにしたアクションを設定できますが、今回は設定しないため「次へ」。
最後に確認になります。問題無ければ「予算を作成」を押します。
作成が終わると、予算の一覧にこのように表示されます。
閾値のステータスがOKから超過に変わると、アラート通知が行われます。
検証
SNS〜EventBridge Pipesの構築に問題無ければ、予算アラート作成中に以下のようなメッセージが指定したチャットルームに届きます。
これは予算作成時に指定したSNSトピックを通じて、Budgetsアラートを受領できるようになった事を示すメッセージです。従って、BudgetsからChatworkまでの経路は問題無いと判断できます。
後は実際にアラートがきちんと届くかどうかです。0.01USDで予算を作成したので、すぐに閾値超過してアラートが飛ばされるはず・・・。
先ほど作成した予算アラートが、無事Chatworkに通知されました!
表示内容もjson形式にならずに、Eメールでの通知と同じ形で届いたので期待どおりの結果です!
まとめ
検証の結果、EventBridge Pipesを利用する事で、Lambdaを使うことなくChatworkにBudgetsの予算アラートを投稿する事ができました。
Budgetsの予算アラートは内容がフォーマット化されている事もあり、SNSトピックのrawメッセージを有効化する事で加工の必要性もありませんでした。
EventBridge Pipesにはオプションとしてフィルタリング機能や強化(エンリッチメント)機能も用意されており、例えばソースとしてAmazon DynamoDB Streamsのレコードを指定し、そのレコードを加工処理してターゲットに送信できたりもします。
今回はChatworkへの通知の際にLambdaでのコード実装や管理を省きたいという観点での検証になりましたが、他のイベントソースやオプションの組み合わせによってもっと応用が利きそうで、今後も色々と試してみる価値がありそうなサービスだと感じました。特にサーバレスでの構築・開発を行いたい場合はかなり助けになってくれそうです。
長くなってしまいましたが、ここまで読んで下さりありがとうございました。
少しでもこの記事が皆様の参考になればと思います。では!