ECSバッチ起動に失敗した時にEventBridgeを使ってslackに通知を飛ばす話

# 初めに
私が担当している案件ではECSを使って、バッチ処理を動かしているのですが、ある日、バッチ処理が動かずに、次の日に原因を調査していると、CloudTrailのイベントレコードに以下のようなメッセージがありました。

```
Capacity is unavailable at this time. Please try again later or in a different availability zone
```

直訳すると、

**現時点で容量オーバー。しばらくしてから、または別のアベイラビリティーゾーンでもう一度試してね。**

ってことなので、対策としてはこのメッセージが出た時に手動でバッチ処理を動かそうということになりました。
しかし、このメッセージが出ていることをそもそも気づけなかったら、そもそも手動でも動かせないよってことでその時の対策をご紹介します。

# 構成
本チャプター下部添付画像のような構成を取りました。
ECSでバッチ処理を動かして、転けた時にCloudTrailでイベントを記録します。

なお、ECSはCloudTrailと統合されているので、ECSのAPIコールをイベントとしてCloudTrailは自動でキャプチャしてくれます。

そして、CloudTrailがキャプチャしたことをトリガーとして、EventBridgeがSNSに飛ばして、slackに通知します。
ChatbotをSNSとまとめて囲んだのはChatbotでslackを登録して、それをSNSと紐づけているからです。

今回は紹介しませんが、SNSとChatbotの紐付けについて気になるかたは以下などを参照してみてください。
引用) [【AWS】AWSサービスでSlack通知をやってみた（AWS Chatbot + Amazon SNS）](https://techblog.cartaholdings.co.jp/entry/archives/6411)

![スクリーンショット 2023-10-04 13.44.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/8cf4819d-a84f-7b34-3be3-a92592a4743a.png)

# 注意点
具体的な手順の前に、注意点を先に書いておきます。
ここを知った上で、手順に進んで欲しいからです。

↓こちらの記事がとても参考になりました。

引用) [カスタムサンプルイベントの作成](https://qiita.com/sakai00kou/items/3e032a6e4394a7aeaf40#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AE%E4%BD%9C%E6%88%90)

>CloudTrailに記録されるイベントの履歴は、実際にイベントが発生した際に呼び出されるイベントオブジェクトの書式と異なる

リンク先を見てもらうとわかるのですが、CloudTrailに記録されるイベントとイベント発生時に実行されるイベントオブジェクトは異なります。
イベント発生時に実行されるイベントオブジェクトはdetailの中にCloudTrailに記録されるイベント履歴を含めるような形になります。

なので、EventBridgeでイベントパターンを記述する時に気をつけなくてはいけません。
後述の手順の際に、詳しく記述します。

# 手順
まずはEventBridgeのルールを作成します。

イベントバスは基本的にdefaultで大丈夫です。
CloudTrailのキャプチャトリガーは、直接EventBridgeのルールに飛びません。
間にイベントバスというものを挟みます。
以下の記事を参照してみてください。わかりやすいです。

引用) [イベントバスについて](https://blog.serverworks.co.jp/2023/01/26/180101)

![スクリーンショット 2023-10-06 17.48.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/79d218e4-da7d-a323-4656-c91f3c77da28.png)

次にルールの詳細を定義ですが、特に変更は要りません。
「イベントパターンを持つルール」を選ぶことで、CloudTrailのキャプチャとマッチング判定をします。

![スクリーンショット 2023-10-06 17.57.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/29281703-bcbe-90c6-3304-3e6634fc3aa3.png)

詳細の定義が終わると、次は「イベントパターンを構築」です。
以下のような画面になりますが、特に変更せず一番下までスクロールして大丈夫です。

![スクリーンショット 2023-10-06 18.01.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/2dabcff8-f3a8-85a6-09f2-c6b75b06cb1d.png)

そうすると、画像のような「イベントパターン」　があると思うのですが、ここでCloudTrailのキャプチャとマッチングさせていきます。
ここの設定を間違えると、EventBridgeが発火しないので気をつけてください。

以下画像が参考です。
ここで先ほどの注意点で述べたように、detailの中にCloudTrailに記録されるイベント履歴を含めるような形にします。
sourceとdetail-typeは今回のようなインフラ構成だと必須項目ですがdetailの中はどのような条件にしたいかで変更してください。
本番だけ動かしたいとかだったら、clusterを指定した方がいいです。

今回のように
**Capacity is unavailable at this time. Please try again later or in a different availability zone**
のエラーを拾いたい時は、responseElementsのfailuresは必須ですね。

![スクリーンショット 2023-10-06 18.03.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/9cdff7bb-95db-057c-2a73-a7d3f5628226.png)

あとは、通知先を選ぶだけです。
私はSNSに通知を飛ばしたかったので、SNSトピックにしました。
Lambdaとかに飛ばすのとかもできます。
![スクリーンショット 2023-10-06 18.13.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/92f44d86-991d-30df-d67a-c5f896792769.png)

# やり残し
**Amazon EventBridge  > イベントバス > イベントの送信**から実際のテストイベントを起こすことができると思うのですが、私の場合は作成した翌日に実際にエラーが起こったので試す必要がありませんでした。
次回、もし触ることがあれば試したい...

今度はここらへんも試してみたい

![スクリーンショット 2023-10-05 16.53.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/942467/8f1074b4-c519-dcca-6eee-6d794b335170.png)