AWS では、ALB（Application Load Balancer）配下に Auto Scaling Group（ASG）と ECS（Amazon Elastic Container Service）のアプリケーションサーバを配置する構成が一般的です。しかし、もしこの構成内の 1 台の ECS タスク（コンテナ）が故障したらどうなるのでしょうか？
ユーザーへの影響や、リクエストの扱い、さらに「ユーザーが障害に気づかない」設計方法について解説します。
ECS タスクが故障するとユーザーはどう感じる？
結論から言えば、適切に設計されていればほぼ気づきません。
ただし、以下のケースではユーザー影響が発生します：
❌ ユーザーが障害を感じるケース
- 故障した ECS タスクにリクエストがルーティングされたまま
- ALB のヘルスチェックの設定が甘くて、異常検知に時間がかかる
- ロングリクエスト処理（10秒以上の API）中にコンテナが死ぬ
- セッション情報をローカルに保持しており、そのサーバが死んだ場合
これらの状況では 「ページが固まる」「突然エラーになる」 といった体験が発生します。
故障した ECS タスクに処理中のリクエストはどうなる？
🔹 パターン1：処理中にコンテナが落ちた場合
- そのリクエストは 途中で失われる（500 エラーなど）
- 途中でコネクションが切断されることもある
→ この状況は ALB では救えません。
→ アプリ側でリトライ または クライアント側の再送 が必要です。
🔹 パターン2：ALB がタスクの異常を検知した後
ALB はタスクを Unhealthy として切り離し、以後リクエストは送られません。
- リクエストは残りの正常なタスクに流れる
- ユーザー影響はほぼゼロ
ただしポイントは：
ヘルスチェックの間隔 × 異常判定回数の間は故障ノードへ送られ続ける可能性
例：Interval 5秒 × UnhealthyThreshold 2 → 最大10秒間は影響あり
ユーザーが「障害を感じない」ための設計ポイント
１．ALB ヘルスチェックを高速化する
２．ECS タスクを最低 2 台以上にする
３．ステートレス化（セッションを外出し）
ユーザーセッションは ElastiCache（Redis） または DynamoDB に保存する。
→ 故障した ECS 内のセッション喪失でログアウトさせない
→ Sticky session（ALB のセッション維持）はできれば使わない
4. コンテナの正常性チェック（ECS Task Health Check）も設定する
ALB だけではアプリ内部の異常は検知できない。ECS の独自ヘルスチェックを併用：
・アプリ内部の死活を検知
・異常タスクを自動再起動
５．優雅なシャットダウン（graceful shutdown）を実装する
コンテナ停止時（→ SIGTERM を捕捉して処理する）に：
・新しいリクエスト受付を止める
・処理中のリクエストは完了するまで待つ
・ALB の connection draining / deregistration delay を活用
６．クライアント側（Web/アプリ）にリトライロジックを入れる
コメント