Amazon EC2 起動タイプを使用する Amazon ECS タスクで、Application Load Balancer のヘルスチェックに合格する方法を教えてください
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行される Amazon Elastic Container Service (Amazon ECS) タスクに対する、Application Load Balancer のヘルスチェックに関する問題をトラブルシューティングして解決したいです。
簡単な説明
Amazon ECS タスクがロードバランサーのヘルスチェックに失敗すると、Amazon ECS サービスイベントメッセージから次のいずれかのエラーが表示されることがあります。
- 「(サービス AWS-service) (ポート 8080) は、(理由 コード[502または504]でのヘルスチェック失敗) または (リクエストタイムアウト) のため、(target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) で異常です」
- 「(サービス AWS-Service) (ポート 8080) は、(理由 ヘルスチェック失敗) のため、target-group tf-20190411170 で異常です」
- (service AWS-Service) (instance i-1234567890abcdefg) (port 443) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Health checks failed) ((サービス AWS-Service) (インスタンス i-1234567890abcdefg) (ポート 443) は、(ヘルスチェック失敗の理由) のため、(target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) で異常です)
Amazon ECS タスクコンソールに次のエラーが表示される場合があります。
Task failed ELB health checks in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) (タスクが (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) でELB ヘルスチェックに失敗しました)
不合格となったコンテナのヘルスチェックについては、「Amazon ECS タスクがコンテナヘルスチェックに合格できない場合のトラブルシューティング方法を教えてください」を参照してください。
Amazon ECS タスクが停止した理由を判断する方法については、「Amazon ECS の停止したタスクに関するエラーを確認する」と「Amazon ECS タスクが停止した理由を知りたいです」を参照してください。
解決策
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。
複数のセキュリティグループを設定する
複数のセキュリティグループを設定することで、ロードバランサーと、コンテナインスタンスまたはタスクの Elastic Network Interface との間のすべてのトラフィックを許可することがベストプラクティスです。コンテナインスタンスが、タスク用に指定したポートでトラフィックを受け入れるように設定することも有効です。
お使いの構成で、次の設定を確認します。
- ロードバランサーに関連付けられたセキュリティグループが、コンテナインスタンスまたはタスクの Elastic Network Interface へのアウトバウンドトラフィックを、登録したポートで許可している。さらに、ヘルスチェック用ポートでコンテナインスタンスへのアウトバウンドトラフィックを許可している。
- ロードバランサーに関連付けられたセキュリティグループからのインバウンドトラフィックを、タスクホスト用ポート範囲で許可している。
ロードバランサーでアベイラビリティーゾーンを有効にする
ロードバランサーでアベイラビリティーゾーンを構成すると、Elastic Load Balancing がそのアベイラビリティーゾーンにロードバランサーノードを作成します。アベイラビリティーゾーンにターゲットを登録したが、アベイラビリティーゾーンが有効化されていない場合は、登録されたターゲットはトラフィックを受信できません。詳細については、「アベイラビリティーゾーンとロードバランサーノード」を参照してください。
ロードバランサーを構成済みのアベイラビリティーゾーンを判別するには、次の手順を実行します。
- Amazon EC2 コンソールを開きます。
- ナビゲーションペインの [ロードバランシング] で、[ロードバランサー] を選択します。
- Amazon ECS サービスに使用するロードバランサーを選択します。
- [説明] タブにアベイラビリティーゾーンが表示されます。
または、AWS CLI コマンド describe-load-balancers を実行します。
aws elbv2 describe-load-balancers --load-balancer-arns EXAMPLE-ALB-ARN --query 'LoadBalancers[*].AvailabilityZones[].{Subnet:SubnetId}'
注: EXAMPLE-ALB-ARN は、実際の Application Load Balancer の ARN に置き換えます。
コンテナインスタンスが設定されているアベイラビリティーゾーンを判別するには、次の手順を実行します。
- Amazon EC2 コンソールを開きます。
- ナビゲーションペインの [自動スケーリング] で、[Auto Scaling グループ] を選択します。
- クラスターに関連付けられているコンテナインスタンスの Auto Scaling グループを選択します。
- [詳細] タブの [ネットワーク] に表示されるアベイラビリティーゾーンが、お使いのロードバランサー用のアベイラビリティーゾーンと一致していることを確認します。
または、AWS CLI コマンド describe-auto-scaling-groups を実行します。
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names EXAMPLE-ASG-NAME --query 'AutoScalingGroups[*].{Subnets:VPCZoneIdentifier}' --output text
注: EXAMPLE-ASG-NAME は、お使いの Auto Scaling グループ名に置き換えます。
クラスターのアベイラビリティーゾーンを変更するには、次の手順を実行します。
- AWS CloudFormation コンソールを開きます。
- クラスターの CloudFormation スタックを選択します。
- スタックを更新します。
- [スタックの詳細を指定] ページで、[サブネット ID] の設定を更新します。
タスクが設定されているアベイラビリティーゾーンを判別するには、次の手順を実行します。
-
Amazon ECS コンソールを開きます。
-
ナビゲーションペインで [クラスター] を選択し、サービスを含んでいるクラスターを選択します。
-
クラスターのページの [サービス] タブにある [サービス名] 列で、確認するサービスを選択します。
-
[設定とネットワーク] タブを選択します。
-
[ネットワーク設定] に設定済みのサブネットが表示されます。
-
Amazon Virtual Private Cloud (Amazon VPC) コンソールを開くと、ECS コンソールには表示されていない追加情報が表示されます。
-
describe-services コマンドを実行し、サブネットのアベイラビリティーゾーンがロードバランサーのアベイラビリティーゾーンと一致することを確認します。
aws ecs describe-services --cluster EXAMPLE-CLUSTER-NAME --service EXAMPLE-SERVICE-NAME --query 'services[*].deployments[].networkConfiguration[].awsvpcConfiguration.{Subnets:subnets}'注: お使いのものでそれぞれ、EXAMPLE-CLUSTER-NAME をクラスター名に、EXAMPLE-SERVICE-NAME をサービス名に置き換えます。
Amazon ECS コンソールを使用して Amazon ECS サービスのサブネット設定を変更することはできません。代わりに、AWS CLI の update-service コマンドを実行します。
ネットワーク ACL を設定し、サブネット間のトラフィックを許可する
ロードバランサー用のサブネットは、コンテナインスタンスまたはタスク用ネットワークインターフェイスのサブネットとは異なる場合があります。
サブネット間のトラフィックを許可するには、次のネットワークアクセスコントロールリスト (ネットワーク ACL) 設定を使用します。
- ロードバランサーのサブネットに関連付けられているネットワーク ACL は、エフェメラルポート (1024 ~ 65535) とリスナーポートでインバウンドトラフィックを許可する必要があります。
- ネットワーク ACL では、ヘルスチェック用ポートとエフェメラルポートでアウトバウンドトラフィックを許可する必要があります。
- コンテナインスタンスのサブネットまたは、awsvpc 用のタスクネットワークインターフェイスに関連付けられたネットワーク ACL では、ヘルスチェック用ポートでのインバウンドトラフィックを許可する必要があります。
- ネットワーク ACL では、エフェメラルポートでのアウトバウンドトラフィックを許可する必要があります。
ネットワーク ACL の詳細については、「ネットワークアクセスコントロールリストを使用してサブネットトラフィックを制御する」を参照してください。
ターゲットグループのヘルスチェック設定を確認する
ターゲットグループのヘルスチェック設定が正しく設定済みであることを確認するには、次の手順を実行します。
- Amazon EC2 コンソールを開きます。
- ナビゲーションペインの [ロードバランシング] で [ターゲットグループ] を選択します。
- ターゲットグループを選択します。
重要: 新しいターゲットグループを使用してください。Amazon ECS は ECS タスクをターゲットグループに自動的に登録および登録解除するため、ターゲットグループにターゲットを手動で追加することは避けてください。 - [ヘルスチェック] タブで、次の操作を行います。
Port フィールドと Path フィールドが正しく設定されていることを確認します。
注: フィールドを正しく設定していない場合、ヘルスチェックの不合格が原因で、Amazon ECS がロードバランサーにタスクの登録解除を要求する場合があります。
[ポート] で、トラフィックポートを選択します。
注: [オーバーライド] を選択した場合は、ポートがタスクホストポートと一致していることを確認してください。
[タイムアウト] の応答タイムアウト値が適切であることを確認してください。
注: この値が応答に必要な時間よりも小さい場合、ヘルスチェックは不合格となります。
ECS コンテナ内のアプリケーションのステータスと構成を確認する
アプリケーションがロードバランサーのヘルスチェックに応答することを確認する
次の操作を行います。
- ターゲットグループの ping 用ポートとヘルスチェック用パスが正しく設定されていることを確認します。
- Amazon ECS サービスの CPUとメモリの使用率に関するメトリクスを監視します。アプリケーションが遅くなったりタイムアウトしたりする場合は、タスクリソースのクォータを増やす、サービスをスケールアウトする、アプリケーションを最適化する、より大きいインスタンスタイプを使用するなどの措置をとります。
- ヘルスチェックの最小猶予期間を設定すると、タスクが開始した後に、事前に定義した期間はサービススケジューラがヘルスチェックを無視します。
注: Amazon ECS タスクでは、Application Load Balancer の登録には長いヘルスチェック猶予期間が必要になる場合があります。 - アプリケーションログで、アプリケーションエラーの有無を確認する詳細については、「Amazon ECS ログを CloudWatch に送信する」を参照してください。
アプリケーションが正しいステータスコードを返すことを確認する
ロードバランサーがヘルスチェックパスに HTTP GET リクエストを送信すると、ECS コンテナ内のアプリケーションはデフォルトの 200 OK ステータスコードを返します。HTTP 以外のエラーメッセージが表示される場合は、アプリケーションは HTTP トラフィックをリッスンしていないことを示しています。Matcher 設定で指定したステータスコードとは異なる HTTP ステータスコードが表示される場合があります。他のステータスコードが表示された場合は、アプリケーションは HTTP トラフィックをリッスンしているが、正常なターゲットに関するステータスコードを返していないことを示しています。
注: Application Load Balancer を使用している場合は、Matcher の設定を 200 以外のステータスコードに更新します。詳細については、「Application Load Balancer のターゲットグループに対するヘルスチェック」を参照してください。
ECS コンテナ内のアプリケーションが正しいステータスコードを返していることを確認するには、次の手順を実行します。
-
SSH、AWS Systems Manager の機能である Session Manager、EC2 Instance Connect のいずれかを使用してコンテナインスタンスに接続します。
-
(オプション) お使いのオペレーティングシステム (OS) に応じて次のコマンドを実行し、curl をインストールします。
Amazon Linux およびその他の RPM ベースのディストリビューションsudo yum -y install curlUbuntu など、Debian ベースのシステム
sudo apt-get install curl -
次のコマンドを実行し、コンテナ ID を取得します。
docker ps注: ローカルリスナーのポートは、コマンドの出力でシーケンスの最後にある PORTS に表示されます。
-
BRIDGE ネットワークモードを使用している場合は、docker inspect コマンドを実行してコンテナの IP アドレスを取得します。
IPADDR=$(docker inspect --format='{{.NetworkSettings.IPAddress}}' 112233445566)注: コンテナの IP アドレスは IPADDR に保存されています。112233445566 は、docker ps コマンドの出力に表示される Container ID の番号に置き換えます。awsvpc を使用している場合は、タスクネットワークインターフェイスに割り当てられたタスクの IP アドレスを使用します。HOST ネットワークモードを使用する場合は、タスクの公開に使用するホストコンテナインスタンスの IP アドレスを使用します。
-
ステータスコードを取得するには、IPADDR とローカルリスナーのポートを指定して curl コマンドを実行します。
curl -I http://${IPADDR}:8080/health注: 上記のコマンド例で、8080 をリスナーのポートに置き換えます。
コンテナインスタンスのステータスを確認する
Amazon ECS サービスイベントが次のイベントメッセージを表示した場合は、コンテナインスタンスのステータスを確認してください。
(service AWS-Service) (instance i-1234567890abcdefg) (port 443) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Health checks failed) ((service AWS-Service) (instance i-1234567890abcdefg) (port 443) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Health checks failed) ((サービス AWS-Service) (インスタンス i-1234567890abcdefg) (ポート 443) は、(ヘルスチェック失敗の理由) のため、(target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) で異常です))
Amazon EC2 コンソールでコンテナインスタンスのステータスを確認します。インスタンスがシステムステータスチェックに合格できなかった場合は、インスタンスを停止して起動します。
Application Load Balancer のアクセスログを一時的に有効にする
Application Load Balancer のアクセスログを一時的に有効化し、次の問題がないか確認します。
- Application Load Balancer がヘルスチェックを正しいパスまたはポートに送信しているかどうか、およびターゲットが正しく応答しているかどうかを確認します。
- ターゲットが返す HTTP ステータスコードを分析し、ルートの設定ミスやサーバー側のエラーなど、アプリケーションレベルの問題を特定します。
- ヘルスチェックがターゲットに到達したことを確認し、ネットワーク関連の問題がないかどうかを確認します。
- 応答時間が、設定されたヘルスチェックのタイムアウトを超えているかどうかを確認します。
その他の原因のトラブルシューティング
上記の解決策で問題が解決しない場合は、「Amazon ECS におけるサービスロードバランサーのトラブルシューティング」を参照してください。
関連情報
Application Load Balancer のターゲットグループを作成する
負荷分散により、Amazon ECS サービスのトラフィックを分散する
Application Load Balancer の使用時に発生する 504 エラーのトラブルシューティング方法を教えてください
- トピック
- Containers
- 言語
- 日本語

関連するコンテンツ
- 質問済み 1年前
