Classic Load Balancer の背後にある 1 つまたは複数のインスタンのヘルスチェックが失敗しました。考えられる原因は何であり、どうすれば解決できますか?

Elastic Load Balancing (ELB) は、Application Load Balancer、Network Load Balancer、Classic Load Balancer をサポートしています。Classic Load Balancers で実行されているインスタンスは、以下の理由でヘルスチェックに失敗することがあります。

  • ロードバランサーとバックエンドの間の接続に関する問題
  • アプリケーションの設定に関する問題
  • ヘルスチェックを要求しているバックエンドから「200 OK」応答を受信していない
  • SSL に関する問題があり、HTTPS または SSL ヘルスチェックの失敗を引き起こしている

ヘルスチェック関連の問題のトラブルシューティングと解決を行うには、以下を確認します。

ロードバランサーとバックエンドの間の潜在的な接続の問題を解決する

以下が正しいことを確認します。

  • バックエンドが、ヘルスチェックのトラフィックを許可している。セキュリティグループのルールを確認するには、VPC でのロードバランサーのセキュリティグループを参照してください。バックエンドのインスタンスについては、VPC でのインスタンスのセキュリティグループを参照してください。
  • ロードバランサーまたはバックエンドのサブネットのネットワークアクセスコントロールリスト (ACL) が、ヘルスチェックのトラフィックを許可している。ロードバランサーまたはバックエンドのサブネットの ACL ルールを確認するには、VPC でのロードバランサーのネットワーク ACL を参照してください。
  • バックエンドのインスタンスレベルまたは OS レベルのファイアウォールが、ヘルスチェックのトラフィックを許可している。バックエンドのインスタンスレベルまたは OS レベルのファイアウォールが、ヘルスチェックの送信および受信のトラフィックを許可していることを確認します。
  • バックエンドインスタンスのリソースが、過度に使用されていない。メモリと CPU の使用率が許容範囲内であることを確認します。メモリまたは CPU の使用率が高すぎる場合は、バックエンドを追加するか、バックエンドをより大きなインスタンスの種類にアップグレードします。
  • 追加のリソースが、ヘルスチェックのトラフィックを許可している。ヘルスチェックの要求は、バックエンドによって追加のリソースに転送される可能性があります。追加の依存関係が応答しなかったり応答に時間がかかりすぎると、ヘルスチェックはタイムアウトして失敗します。追加のリソースが、ヘルスチェックの要求に応答していることを確認します。

アプリケーションの設定に関する潜在的な問題を解決する

  • アプリケーションが実行中である。たとえば、Linux インスタンスで Apache を実行している場合は、sudo service httpd status コマンドを使用して、Apache が実行中であることを確認します。
  • アプリケーションは、ヘルスチェックポートでリスンしている。サーバーがヘルスチェックポートでリスン状態であることを確認するには、サーバーで netstat -ant コマンドを実行します。アプリケーション設定ポートをチェックして、実行中であることを確認します。ロードバランサーとバックエンドの間の TCP 接続をシミュレートするには、インスタンスで telnet <バックエンドのプライベート IP> <ヘルスチェックポート> コマンドを実行します。出力が「Connected」であれば、バックエンドはヘルスチェックポートでリスンしています。
  • アプリケーションが、カスタムホストヘッダーを持つリクエストに応答するように設定されている。HTTP および HTTPS ヘルスチェックの場合、Classic Load Balancer はヘッダーをバックエンドのプライマリネットワークインターフェイスでのプライベート IP アドレスに設定し、ユーザーエージェントを「ELB-HealthChecker/1.0」に設定します。バックエンドがカスタムホストヘッダーまたはユーザーエージェントを持つ要求にしか応答しない場合、ヘルスチェック要求は失敗します。
  • アプリケーションは、バックエンドのプライマリネットワークインターフェイスでリスンしている。Classic Load Balancer は、バックエンドインスタンスのプライマリネットワークインターフェイスに接続します。アプリケーションがバックエンドインスタンスのプライマリネットワークインターフェイスでリスンしていて、バックエンドがヘルスチェック要求に対する応答を送信できることを確認します。

バックエンドからヘルスチェック要求への「200 OK」応答を確認する

以下が正しいことを確認します。

  • ping のパスが有効である。ping のパスで指定されたファイルがバックエンドで設定されていない場合、バックエンドは「404 Not Found」レスポンスコードで応答し、ヘルスチェックは失敗します。注意: ping のパスのデフォルト値は /index.html です。バックエンドに index.html ファイルがない場合は、ファイルを作成するか、または ping パスの値をバックエンドのファイル名に変更します。
  • バックエンドで、リダイレクトが設定されていない。バックエンドで設定されたリダイレクションが 301 または 302 のレスポンスコードとなり、結果としてヘルスチェックが失敗します。たとえば、バックエンドで HTTP:80 から HTTPS:443 へのリダイレクトがある場合、ヘルスチェックを HTTPS に変更し、ヘルスチェックポートを 443 に変更しない限り、ポート 80 の HTTP ヘルスチェックは失敗します。注意: ロードバランサーに関連付けられたサブネット内のインスタンスからの curl -Ivk http[s]://<バックエンドインスタンスのプライベート IP アドレス>:<ヘルスチェックポート>/<ヘルスチェックターゲットページ> コマンドを使用して、ロードバランサーによって送信されたヘルスチェック要求をシミュレートすることができます。

SSL 関連の問題を解決する

以下が正しいことを確認します。

  • すべてのプロトコルと暗号が一致している。HTTPS または SSL ヘルスチェックの場合、ロードバランサーとバックエンドが同じプロトコルと暗号を使用している必要があります。バックエンドインスタンスで行われたパケットキャプチャは、ロードバランサーによって送信されたクライアント hello のロードバランサーでサポートされている暗号とプロトコルを示します。登録されているバックエンドインスタンスが、ロードバランサーによって送信された 1 つまたは複数の一致する暗号とプロトコルをサポートしている必要があります。
  • バックエンドサーバーで、サーバーネームインディケーション (SNI) が有効になっていない。ヘルスチェックが HTTPS/SSL であり、SNI がバックエンドインスタンスで有効になっていると、ロードバランサーとバックエンドは SSL ハンドシェイクを確立できません。これは、クライアント hello の後にバックエンドサーバーが RST を送信するためです。SNI を無効にするか、代わりに TCP ヘルスチェックを使用します


このページは役に立ちましたか? はい | いいえ

AWS サポートナリッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2017 年 1 月 10 日

更新: 2018 年 6 月 8 日