ある企業が Amazon ECS on Fargate でマイクロサービスを運用しており、本番デプロイ後に特定のサービスでメモリリークが発生することが判明しています。デプロイ後 24 時間経過するとメモリ使用率が徐々に増加し、48 時間後に OOM（メモリ不足）でコンテナがクラッシュします。このパターンを事前に検知して、クラッシュが発生する前に自動的にコンテナを再起動する仕組みを構築したいと考えています。最も適切な実装はどれですか？
- A. ECS サービスの desired count を増やして常に複数のタスクが稼働するようにし、1 つがクラッシュしても他が対応できるようにする
- B. CloudWatch Container Insights でコンテナレベルのメモリ使用率メトリクスを収集し、使用率が 80% を超えたときに CloudWatch Alarm を発火させる。Alarm のアクションとして EventBridge ルール + Lambda 関数を設定し、Lambda から ECS API（StopTask）を呼び出して該当タスクを停止する（ECS サービスが自動的に新タスクを起動する）
- C. 毎朝 12 時に EventBridge スケジュールで Lambda を実行し、全 ECS タスクを強制的に再起動することでメモリリークをリセットする
- D. ECS タスク定義の memoryReservation を低く設定して ECS の OOM キラーが早めに動作するようにする
解答と解説を見る
正解: B
CloudWatch Container Insights はコンテナレベルのメモリ使用率をリアルタイムで収集します。メモリ使用率 80% でアラームを設定し、EventBridge + Lambda で ECS タスクを停止させることで、ECS サービスが自動的に新しいタスクを起動します。これによりクラッシュ前に予防的な再起動が実現できます。 A: desired count の増加は高可用性を提供しますが、全タスクがメモリリークの影響を受けるため根本的な解決にはなりません。すべてのタスクが 48 時間後にクラッシュします。 D: memoryReservation の低設定は ECS が OOM キラーを早期に動作させますが、OOM はタスクのクラッシュを意味し、「クラッシュが発生する前に」という要件を満たしません。 C: 毎日強制再起動は定期的な対処策ですが、24 時間以内にメモリ使用率が 80% を超える可能性があり、スケジュールが問題のパターンに合わない場合があります。動的なアラームベースの対応の方が適切です。
📚 関連サービスの解説: Amazon CloudWatch ・ Amazon EventBridge