LinuxのEC2上で稼働するECSサービスで、一部タスクのコンテナが終了コード137で停止した。サービス全体の平均メモリ使用率は低く、Container Insightsの拡張可観測性は有効になっている。
メモリ上限の超過、ホストのメモリ不足、別の終了要因を切り分けたい。停止タスクの情報・ログと、該当するタスク定義のリビジョンを確認できる。
最も適切な調査はどれか。
停止したコンテナの利用量・停止理由・ログとタスク定義を関連付け、終了コードだけでOOMの原因を断定しない。
詳細解説
サービス平均は一部のコンテナの急増を隠す。停止したTaskIdとコンテナ単位で確認する。
137だけでは終了原因を特定できない。OOMでもホスト側の制約が関係する場合があり、対象の停止情報が必要である。
停止対象の利用量と理由を確認し、コンテナの上限、ホストの圧迫、アプリの動作を追加証拠で切り分ける。
memoryReservationはソフト予約であり、設定されたmemoryのハード上限やホストの利用可能メモリとは異なる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料で拡張Container InsightsのContainerMemoryUtilizedの粒度、DescribeTasksの停止情報、LinuxのmemoryとmemoryReservationを確認する。
参考にした公式資料
確認できる内容
サービス平均と対象コンテナを区別し、ハード上限超過とホスト側の制約を追加情報で調査できる。
理解のポイント
- ContainerMemoryUtilized
- stoppedReason
- memoryReservation
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
停止した対象の情報を揃える
ECS/ContainerInsightsでContainerName、TaskId、ServiceName、ClusterNameの対象を選び、停止時刻付近のContainerMemoryUtilizedを確認する。DescribeTasksのstoppedReasonとcontainersのreason／exitCode、アプリログを照合する。低い集約平均や測定間隔の間の値だけでは、一時的なピークを否定できない。
予約、上限、ホスト容量を区別する
Linuxのコンテナ定義ではmemoryがハード上限、memoryReservationがソフト予約である。予約を超える利用は直ちに異常ではない。OOMは割り当てを超えた消費だけでなくホストの制約でも起こり得るため、ホストのメモリ圧迫とアプリの増加傾向も調べてから設定変更を決める。