AWS・1分で読める
ECS デプロイ運用メモ: Circuit Breaker と監視設計
ECS サービス運用で詰まりやすいデプロイ失敗検知、CloudWatch Alarm 設計、Container Insights の見方を整理したメモ。
#aws#ecs#cloudwatch#deployment#monitoring#container insights
ECS デプロイ運用メモ: Circuit Breaker と監視設計
ECS では「デプロイできたように見えるのに不安定」という状態が起きがちです。 このメモでは、デプロイ失敗検知と監視の基本を整理します。
デプロイ時に見るべき項目
- サービスのデプロイステータス
- タスク停止理由(Stopped reason)
- Desired / Running タスク数の乖離
参考:
Deployment Circuit Breaker
ECS サービスで circuit breaker を有効化すると、失敗デプロイの自動ロールバックを取り入れやすくなります。
使う意図
- 起動失敗時の復旧を早める
- 手動監視依存を減らす
CloudWatch Alarm の考え方
ECS
- CPU / Memory 使用率
- Desired と Running の差
- リクエスト負荷に対するタスク数
RDS も合わせて見る
- CPU 使用率(例: 90% で通知)
- 同時接続数
- Writer / Reader の負荷差
監視設計で迷いやすい点
- Alarm の評価期間を短くしすぎると誤検知が増える
- 長すぎると障害検知が遅れる
まずは「通知過多にならない閾値」から始め、運用で調整するのが現実的です。
まとめ
ECS の安定運用は、 「失敗を素早く戻す仕組み(Circuit Breaker)」と 「戻すべき失敗を見逃さない監視(Alarm設計)」の両輪で考えるのがポイントです。