翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Classic Load Balancer のトラブルシューティング: ヘルスチェック
ロードバランサーは Elastic Load Balancing によって提供されたデフォルトのヘルスチェック設定、またはユーザーが指定するヘルスチェック設定を使用して、登録されたインスタンスの状態をチェックします。ヘルスチェック設定には、プロトコル、ping ポート、ping パス、応答タイムアウト、ヘルスチェック間隔などの情報が含まれます。インスタンスは、ヘルスチェックの間隔内に 200 応答コードを返せば、正常と見なされます。詳細については、「[Classic Load Balancer のインスタンスのヘルスチェック](elb-healthchecks.md)」を参照してください。
一部またはすべてのインスタンスの現在の状態が `OutOfService` で、説明フィールドに `Instance has failed at least the Unhealthy Threshold number of health checks consecutively` というメッセージが表示された場合は、インスタンスはロードバランサーのヘルスチェックに失敗しています。以下は確認する必要がある問題、考えられる原因、問題の解決のためのステップです。
**Topics**
+ [ヘルスチェックのターゲットページのエラー](#ts-elb-healthcheck-targetpage)
+ [インスタンスへの接続がタイムアウトした](#ts-elb-healthcheck-failed)
+ [パブリックキー認証が失敗する](#ts-elb-healthcheck-publickey)
+ [インスタンスがロードバランサーからのトラフィックを受信しない](#ts-elb-healthcheck-securitygroup)
+ [インスタンスのポートが開いていない](#ts-elb-healthcheck-ports)
+ [Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する](#ts-elb-healthcheck-autoscaling)
## ヘルスチェックのターゲットページのエラー
**問題**: 指定された ping ポートと ping パス (例: HTTP:80/index.html) 上のインスタンスに対して発行された HTTP GET リクエストで、200 以外の応答コードが受信されます。
**原因 1**: インスタンスでターゲットページが設定されていない。
**ソリューション 1**: 各登録インスタンスで、ターゲットページ (`index.html` など) を作成し、そのパスを ping パスとして指定します。
**原因 2**: 応答の Content-Length ヘッダーの値が設定されていない。
** 解決方法 2**: 応答に本文が含まれている場合、Content-Length ヘッダーの値を 0 以上に設定するか、Transfer-Encoding の値を "chunked" に設定します。
**原因 3**: アプリケーションがロードバランサーからリクエストを受け取るか、200 応答コードを返すように設定されていない。
** 解決方法 3**: インスタンス上のアプリケーションを確認し、原因を調査します。
## インスタンスへの接続がタイムアウトした
**問題**: ロードバランサーから EC2 インスタンスへのヘルスチェックのリクエストがタイムアウトしたか、断続的に失敗しています。
まず、インスタンスに直接接続して問題を確認します。そのインスタンスのプライベート IP アドレスを使用して、ネットワーク内からインスタンスに接続することをお勧めします。
TCP 接続では、次のコマンドを使用します。
```
telnet private-IP-address-of-the-instance port
```
HTTP または HTTPS 接続では、次のコマンドを使用します。
```
curl –I private-IP-address-of-the-instance:port/health-check-target-page
```
HTTP/HTTPS 接続を使用している場合に、200 以外の応答が返されたときは、「[ヘルスチェックのターゲットページのエラー](#ts-elb-healthcheck-targetpage)」を参照してください。インスタンスに直接接続できる場合は、以下を確認してください。
**原因 1**: インスタンスが、設定された応答タイムアウト期間内に応答できない。
** 解決方法 1**: ロードバランサーのヘルスチェック設定で、応答タイムアウト設定を調整します。
**原因 2**: インスタンスに大きな負荷がかかっていて、設定された応答タイムアウト期間よりも応答に時間がかかっている。
**解決策 2**:
+ モニタリンググラフで、CPU の過度の使用率について確認します。詳細については、*Amazon EC2 ユーザーガイド*の「[特定の EC2 インスタンスの統計を取得する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html)」を参照してください。
+ EC2 インスタンスに接続して、メモリ、制限など他のアプリケーションリソースの使用状況を確認します。
+ 必要に応じて、さらにインスタンスを追加するか、Auto Scaling を有効にします。詳細については[Amazon EC2 Auto Scaling ユーザーガイド](https://docs.aws.amazon.com/autoscaling/ec2/userguide/)を参照してください。
**原因 3**: HTTP または HTTPS 接続を使用していて、ping パスフィールドで指定したターゲットページ (例: `HTTP:80/index.html`) でヘルスチェックを実行している場合、ターゲットページからの応答は、設定したタイムアウトより長くかかる場合があります。
** 解決方法 3**: よりシンプルなヘルスチェックのターゲットページを使用するか、ヘルスチェック間隔の設定を調整します。
## パブリックキー認証が失敗する
**問題**: バックエンド認証が有効で、HTTPS または SSL プロトコルを使用するように設定されたロードバランサーが、パブリックキー認証に失敗します。
** 原因**: SSL 証明書のパブリックキーが、ロードバランサーで設定されたパブリックキーと一致しない。`s_client` コマンドを使用して、証明書チェーン内のサーバー証明書のリストを表示します。詳細については、OpenSSL ドキュメントの「[s\$1client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html)」を参照してください。
** 解決方法**: SSL 証明書の更新が必要な場合があります。SSL 証明書が最新状態である場合は、その証明書をロードバランサーに再インストールしてみます。詳細については、「[Classic Load Balancer の SSL 証明書の置き換え](elb-update-ssl-cert.md)」を参照してください。
## インスタンスがロードバランサーからのトラフィックを受信しない
**問題**: インスタンスのセキュリティグループが、ロードバランサーからのトラフィックをブロックしています。
インスタンスでパケットキャプチャを実行して、問題を確認します。次の コマンドを使用します。
```
# tcpdump port health-check-port
```
**原因 1**: インスタンスに関連付けられたセキュリティグループが、ロードバランサーからのトラフィックを許可していません。
** 解決方法 1**: ロードバランサーからのトラフィックを許可するようにインスタンスのセキュリティグループを編集します。ロードバランサーのセキュリティグループからのトラフィックを許可するルールを追加します。
**原因 2**: ロードバランサーのセキュリティグループで、EC2 インスタンスへのトラフィックが許可されていません。
**解決方法 2**: ロードバランサーのセキュリティグループを編集して、サブネットおよび EC2 インスタンスへのトラフィックを許可します。
セキュリティグループの管理方法の詳細については、「[Classic Load Balancer のセキュリティグループの設定](elb-vpc-security-groups.md)」を参照してください。
## インスタンスのポートが開いていない
**問題**: ロードバランサーによって EC2 インスタンスに送信されるヘルスチェックが、ポートまたはファイアウォールによってブロックされます。
次のコマンドを使用して問題を確認します。
```
netstat –ant
```
**原因**: 指定されたポートまたはリスナーポート (異なる設定の場合) が開いていません。ヘルスチェックに指定したポートと、リスナーポートの両方が開いていて、リッスンしている必要があります。
** 解決方法**: リスナーポートと、ヘルスチェックで指定したポート (異なる設定の場合) をインスタンスで開き、ロードバランサーのトラフィックを受信できるようにします。
## Auto Scaling グループのインスタンスが ELB ヘルスチェックに失敗する
**問題**: Auto Scaling グループのインスタンスがデフォルトの Auto Scaling ヘルスチェックには合格するにもかかわらず、ELB ヘルスチェックには合格しません。
**原因**: Auto Scaling は EC2 ヘルスチェックを使用して、インスタンスに存在するハードウェアとソフトウェアの問題を検出します。一方、ロードバランサーはリクエストをインスタンスに送信して 200 応答コードを待つか、インスタンスとの TCP 接続を確立することによって (TCP ベースのヘルスチェックの場合) ヘルスチェックを実行します。
インスタンスは、インスタンスで実行するアプリケーションに、ロードバランサーがインスタンスを停止中と判断する問題があることが原因で、ELB ヘルスチェックに失敗する場合があります。このインスタンスは、Auto Scaling ヘルスチェックに合格する場合があります。EC2 のステータスチェックに基づいて正常な状態と見なされているため、Auto Scaling ポリシーによる置き換えは行われません。
**解決方法**: Auto Scaling グループに対し ELB ヘルスチェックを使用します。ELB ヘルスチェックを使用すると、Auto Scaling は、インスタンスのステータスチェックと ELB ヘルスチェックの両方の結果を確認して、インスタンスのヘルスステータスを判断します。詳細については、*Amazon EC2 Auto Scaling 開発者ガイド*の「[Auto Scaling グループへの Elastic Load Balancing ヘルスチェックの追加](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)」を参照してください。