🎰
【Terraform】ECSスロットリング検知とSlackへの自動通知（AWS CloudWatchとChatbotの活用）〜要件定義〜
はじめに
こちらの記事はいくつかのシリーズ編です。
今回は、以下のトピックについて詳しく説明します
- 問題を発見
- 問題が本当に問題かを確認
- 優先度の確認
- 予想されるインパクト
- 現状把握
- 要件定義
- やること
- やらないこと
- 全体像（アーキテクチャ）の把握
- Todo決め
- イシュー作成
- 要件定義をもとに作成
- 対応〜
問題発見までの流れ
- （インフラのコストが気になり）AWS ECSの様子を確認
- ドル表記のコスト確認を終了（円安ヤバいな...154円って...）
- ECS > クラスター > サービス > タスクを徘徊中
- タスクのヘルスステータスが「異常」を示していた（スロットリング発生っぽいな...）
- 上長などと協議し、スロットリングを停止させる対応へ
- 再度ヘルスステータスを確認したら「正常」に戻っていた
- スロットリングが発生した際に検知できるよう監視体制を構築することを目標に設定
問題が本当に問題かを確認
- インパクト（この場合、損失）をざっくり計算
- 年間30万円の損失になりそうとのこと
- つまり、これを修正できれば年間約30万円の損失を阻止できる
- バケツの穴を塞ぐことも重要なタスクである
現状把握
- 主にDatadogを用いて監視しているECSコンテナのタスクに問題が発生していそう
- 他のECSコンテナのタスクは問題なさそう
要件定義
まず、以下を決めるようにしています
- 全体像（アーキテクチャ）の把握
- やること
- やらないこと
- Todo決め
全体像の把握
アーキテクチャ
大体のディレクトリ構造
Miroで作成
やること（できれば対応順に）
-
CloudWatchでメトリクスとアラームを設定し、スロットリング状況を監視すること
- CloudWatchからECSコンテナのタスクのスロットリングのイベントを取得することは可能
- Amazon SNSとAWS Chatbotを使用して、しきい値を超えた際に指定のSlackチャンネルに通知を設定すること
- 動作確認のため、Railsアプリケーションでスロットリングを意図的に発生させるテストコードを実装
やらないこと
- CloudTrailを使用したスロットリングイベントの検出
- AWSの監査ログのため今回は不適当
- Datadogを利用してのスロットリングイベントを直接取得
- Datadogはデプロイされたアプリケーションの監視に利用する
- しかし、今回の状況ではそもそもアプリケーションがデプロイされていない
- そのため、Datadogでそのイベントを直接取得することはできない
Todo決め
要件定義で使用しそうなサービスを列挙
- AWS ECS
- AWS CloudWatch
- AWS CloudWatch Alarm
- AWS SNS
- AWS Chatbot
- Slack
※本来ならば、ここで全体アーキテクチャの把握を試みる（現状把握の際にも意識しているが改めて）
全体像の把握のために調べた記事たち（感謝です）
Terraform公式リファレンス
以下のアーキテクチャを確認するため
- AWS ECS
- AWS Chatbot
- Slack
EventBridege経由でのSlack通知を求めている方は特にオススメ！
図解がとてもわかりやすく勉強になった
以下のアーキテクチャを確認するため
- AWS CloudWatch
- Slack
AWS CloudWatchでアラームをどのように検知すれば良いの？という方にオススメ！
（今回は使用しないが）Lambda関数を採用しているアーキテクチャが大変参考になりました！
SlackのワークスペースIDの取得やテスト送信までカバー
Terraformの実装もミニマムで大変見やすく分かりやすい！
まとめ
本シリーズでは、AWS ECSにおけるスロットリング問題の発見から対応策の定義までを確認してきました。問題の特定、その影響の評価、そして監視と通知の設定に至るまでのプロセスを通じて、効率的なシステム運用のための実践的なアプローチを記載しました。次回は、これらの計画に基づいた具体的な対応措置の実装とコードの解説に焦点を当てていきます。
今後ともよろしくお願いいたします。
追記
こちらで行ってきた要件定義などから、実装までシリーズ化として書いたのでよろしければご一読ください！
Discussion