Amazon ECS サービスが安定していない理由を知りたいです。

所要時間2分

Amazon Elastic Container Service (Amazon ECS) のサービスが定期的に再起動しています。Amazon ECS サービスの状態を安定させ、一貫性を持たせたいです。

簡単な説明

Amazon ECS サービスは、次のいずれかの理由で不安定になる場合があります。

コンテナのヘルスチェックが不合格となった。
Elastic Load Balancing (ELB) のヘルスチェックで不合格となった。
Amazon ECS タスクがゼロ (0) 以外の終了コードで終了した。
コンテナインスタンスが Amazon ECS タスクの要件を満たしていない。
コンテナインスタンスが予期せず終了した。
サービスで Amazon ECS タスクを開始できなかった。

解決策

Amazon ECS コンソールで Amazon ECS イベントを参照し、サービスが安定していない原因を確認します。

コンテナのヘルスチェックが不合格となった

アプリケーションを Amazon ECS にデプロイする前に、ヘルスチェックを使用してコンテナが想定どおりに動作することを確認します。コンテナのヘルスチェックで、Amazon ECS サービスが突然不合格になった場合は、アプリケーションログを確認します。アプリケーションが awslogs ドライバーを使用している場合は、Amazon CloudWatch のログを確認します。

注: コンテナ定義で指定したヘルスチェックのパラメータは、コンテナイメージ内の Docker ヘルスチェックを上書きします。

ELB のヘルスチェックが不合格となった

ロードバランサーは、各サーバーでコンテナのヘルスチェックを定期的に実行することで、トラフィックを安全に転送できるサーバーを判断します。ELB のヘルスチェックで Amazon ECS サービスが不合格になった場合、ロードバランサーとサービス間の通信に問題がある可能性があります。

ロードバランサーと Amazon ECS サービスが正しく設定されているかどうかを確認するには、次の手順を実行します。

コンテナのセキュリティグループがロードバランサーからのトラフィックを許可していることを確認します。
コンテナ内で次のコマンドを実行し、アプリケーションが正しいポートをリッスンしていることを確認します。
```
netstat -tulpn | grep LISTEN
```
ヘルスチェックパスが正確であることを確認します。
アプリケーションログにエラーがないか確認します。
Amazon Elastic Compute Cloud (Amazon EC2) 内のヘルスチェックパスに対して curl コマンドを実行します。または、AWS Fargate で ECS exec を有効化し、コンテナ内でヘルスチェックに curl コマンドを実行して応答コードを確認します。
CPU 使用率が高いとアプリケーションが応答しなくなり、ELB のヘルスチェックが合格できない可能性があるため、サービスの CPU とメモリのメトリクスを監視します。
ヘルスチェックの最小猶予期間を、アプリケーションが ACTIVE 状態になるまでにかかる時間の 1.5 ～ 2.0 倍に設定します。

Amazon ECS タスクがゼロ (0) 以外の終了コードで終了した

コンテナに問題がある場合、サービス内の Amazon ECS タスクはゼロ以外の終了コードで終了します。すべてのタスクには、少なくとも 1 つの必須コンテナが必要です。何らかの理由で必須コンテナが終了すると、タスク全体が失敗し、Amazon ECS サービスが不安定になります。

次の終了コードは、Amazon ECS タスクで障害が発生した原因を示します。

終了コード 1 は、アプリケーションエラーが発生した場合に発生します。エラーの詳細について、アプリケーションログをレビューします。
終了コード 137 は、コンテナのタスクが強制終了 (SIGKILL) されたか、メモリ不足 (OOM) エラーが発生した場合に発生します。OOM の問題が発生しているかどうかを確認するには、CloudWatch メトリクスをレビューします。
終了コード 139 は、セグメンテーション違反が発生している場合に発生します。これは通常、アプリケーションが使用できないメモリにアクセスしようとした場合や、未設定の変数や無効な環境変数がある場合に発生します。
終了コード 255 は、エラーが原因で、コンテナで ENTRYPOINT CMD コマンドが失敗した場合に発生します。これが原因であるかどうかを確認するには、CloudWatch メトリクスをレビューします。

注: DescribeTasks API を使用することで、停止したタスクの詳細を確認できます。ただし、停止したタスクの詳細は、結果に 1 時間のみ表示されます。

コンテナインスタンスが Amazon ECS タスクの要件を満たしていない

コンテナ要件を変更する方法の詳細については、「Amazon ECS で発生する、no container instance met all of its requirements というエラーを解決する方法を教えてください」を参照してください。

コンテナインスタンスが予期せず終了した

マネージドターミネーションを使用せずに、Amazon ECS クラスターでキャパシティプロバイダーを使用する場合、そのキャパシティプロバイダーは実行中のタスクがあるインスタンスを削除する可能性があります。この現象は、スケールインアクションが発生し、AWS ECS サービスが不安定になった場合に発生します。キャパシティプロバイダーにより、実行中のタスクがあるコンテナインスタンスが削除されることを防ぐには、マネージドターミネーション保護を有効にします。

マネージドターミネーション保護を有効にするには、Auto Scaling グループでインスタンスのスケールイン保護を有効にする必要があります。

スケールイン保護を有効にするには、次の手順を実行します。

Amazon EC2 コンソールを開きます。
ナビゲーションペインで [自動スケーリンググループ] を選択した後、該当する Auto Scaling グループを選択します。
[詳細] タブの [詳細設定] で [編集] を選択します。
[インスタンスのスケールイン保護] で [インスタンスのスケールイン保護を有効にする] を選択します。
[更新] を選択します。

マネージドターミネーション保護を有効にするには、次の手順を実行します。

Amazon ECS コンソールを開きます。
ナビゲーションペインで [クラスター] を選択します。
[クラスター] ページで該当するクラスターを選択します。
[クラスター: 名前] ページで [インフラストラクチャ] を選択してから、[更新] を選択します。
[キャパシティプロバイダーの作成] ページの [Auto Scaling グループ] にある [スケーリングポリシー] で次のオプションを設定します。
[マネージドスケーリングを有効にする] を選択します。
[スケーリング保護を有効にする] を選択します。
[更新] を選択します。

注: 使用する他のツールによって、Auto Scaling グループから AmazonECSManaged タグが削除されないよう注意してください。何らかのツールによりタグが削除されると、Amazon ECS はスケーリングを管理できなくなります。

サービス内の Amazon ECS タスクを開始できなかった

サービスを作成または更新する際、Amazon ECS タスクがイメージを取得できなかったことが原因で、サービスが安定しなくなる場合があります。

この問題を解決するには、次の AWS Knowledge Service の記事を参照してください。