Cloud Load Balancer（CLB）はヘルスチェックによってバックエンドサービスの可用性を判断します。ヘルスチェックで異常を発見した場合は、次の方法を参照してトラブルシューティングを行うことができます。
説明：
ヘルスチェックで異常が検出された場合、CLBは異常なバックエンドサービスへのトラフィック転送を停止します。
ヘルスチェックの結果、バックエンドサービスのすべてに異常が検出された場合、リクエストはすべてのバックエンドサービスに転送されます。
バックエンドサーバーのパブリックネットワーク帯域幅のチェック
従来型アカウントタイプでは、CLBにバインドしたバックエンドCVMにパブリックネットワーク帯域幅を設定する必要があり、それを行っていなければヘルスチェック結果が異常になります。このタイプのアカウントでは帯域幅の属性がCLBではなくCVM上にあるためです。
標準アカウントタイプでは、CLBにバインドしたバックエンドCVMにはパブリックネットワーク帯域幅を設定する必要はなく、ロードバランシングサービスへの影響もありません。
説明：
従来型アカウントタイプのCLBではトラフィックまたは帯域幅料金は発生しません。ロードバランシングサービスによって発生したパブリックネットワークトラフィック料金は、バインドしたバックエンドCVMで課金されます。
パブリックIPが割り当てられていなくても、CVM用にパブリックネットワーク帯域幅を購入することはできます。
セキュリティグループ設定のチェック
CLBインスタンスがセキュリティグループのデフォルト許可機能を有効化しているかどうかをチェックします。有効化していない場合は、CVMのセキュリティグループ上でソースIPを許可する必要があります。お客様のCLBサービスが任意のIPからのアクセスをサポートしている場合は、セキュリティグループのインバウンドルールでソースIPを0.0.0.0/0に設定します。詳細については、CLBセキュリティグループの設定をご参照ください。 レイヤー4リスナーのチェック
説明：
TCPプロトコルでは、CLBはSYNパケットを使用してチェックを行います。
UDPプロトコルでは、CLBはpingコマンドを使用してチェックを行います。
ページでCLBバックエンドサーバーポートのヘルスステータスを確認します。ステータスが異常だった場合のトラブルシューティング方法は次のとおりです。
CLBバックエンドサーバーにセキュリティグループを設定したことでサービスに影響が生じていないかを確認します。バックエンドサーバーはセキュリティグループによってアクセス制御を行い、サービスの正常な実行を保証することができます。詳細については、バックエンドCVMのセキュリティグループ設定の説明をご参照ください。 netstatコマンドを使用して、バックエンドサーバーのポートにリスニング中のプロセスがあるかどうかをチェックします。プロセスがなければ、サービスを再起動します。
レイヤー7プロトコルのチェック
レイヤー7（HTTPプロトコル）サービスについては、あるリスナーのヘルスチェック結果に「異常」が発生した場合、次の面についてトラブルシューティングを行うことができます。
CLBのレイヤー7ヘルスチェックサービスとバックエンドCVMの間ではプライベートネットワークによって通信が行われるため、サーバーにログインして、アプリケーションサーバーポートがプライベートネットワークアドレス上で正常にリスニングしているかをチェックする必要があります。プライベートネットワークアドレスでリスニングしていない場合は、アプリケーションサーバーポートのリスニング先をプライベートネットワークにすることで、ロードバランサシステムとバックエンドCVM間の正常な通信を確保してください。
CLBのフロントエンドポートが80、CVMのバックエンドポートも80であった場合、CVMのプライベートIPは1.1.1.10となります。
Windowsシステムのサーバーが使用するコマンドは次のとおりです。
netstat -ano | findstr :80
Linuxシステムのサーバーが使用するコマンドは次のとおりです。
1.1.1.10:80または0.0.0.0:80のリスニングを確認できた場合、その設定は正常です。
バックエンドサーバーがCLBリスナーに設定したバックエンドポートを有効にしていることを確認してください。
レイヤー4CLBの場合は、バックエンドポートのtelnetに応答があれば正常です。テストはtelnet 1.1.1.10 80を使用して行うことができます。
レイヤー7CLBの場合は、HTTPステータスコードが200などの正常を表すコードでなければなりません。チェック方法は次のとおりです。
WindowsシステムではCVM内のブラウザにプライベートIPを直接入力して、正常かどうかをテストすることができます。この例ではhttp://1.1.1.10とします。
Linuxシステムではcurl -Iコマンドによって、ステータスがHTTP/1.1 200 OKかどうかを確認することができます。この例ではcurl -I 1.1.1.10とします。
バックエンドCVMの内部にファイアウォールまたはその他のセキュリティソフトウェアがないかをチェックします。このタイプのソフトウェアがロードバランサシステムのローカルIPアドレスをブロックし、ロードバランサシステムがバックエンドサーバーと通信できなくなっていることがよくあります。
サーバーのプライベートネットワークのファイアウォールが80番ポートを開放していないかをチェックします。テストはファイアウォールを一時的に無効にして行うことができます。
Windowsシステムではfirewall.cpl コマンドの入力を実行し、無効化することができます。
Linuxシステムでは/etc/init.d/iptables stopコマンドを入力して無効化することができます（CenOS 7.xシステムではsystemctl stop firewalldコマンドを実行してください）。
CLBのヘルスチェックパラメータが正しく設定されているかどうかをチェックします。ヘルスチェックに記載したヘルスチェックパラメータのデフォルト値を参照して設定を行うことをお勧めします。 ヘルスチェックで指定するチェックファイルはHTML形式のシンプルなページにし、返された結果のチェックのみに用いることをお勧めします。PHPなどの動的スクリプト言語の使用は推奨しません。
バックエンドに、高負荷によるCVMの外部へのサービス応答遅延が起こっていないかをチェックします。
HTTPリクエストメソッドをチェックします。
HEADメソッドを使用する場合、バックエンドサービスがHEADをサポートしている必要があります。
GETメソッドの場合、バックエンドサービスがGETをサポートしている必要があります。
TCPの高速リサイクル（tcp_tw_recycle）とタイムスタンプ（tcp_timestamps）を同時に有効にしていると、ヘルスチェック結果が異常になる場合があります。tcp_tw_recycleを無効にすることをお勧めします。詳細については、原因の分析をご参照ください。 ヘルスチェックのチェック頻度が高すぎる場合
コンソールでチェック用パケットを5秒に1回受信する設定にしているのに、実際にバックエンドサーバーでは1秒に1回もしくはそれ以上のヘルスチェックリクエストを受信し、ヘルスチェック頻度が高くなりすぎる場合があります。その原因は主にCLBのバックエンドヘルスチェックの実現メカニズムに関連しています。
例えば100万のClientリクエストを4台のCLBバックエンド物理マシンに分散させ、バックエンドサーバーに転送するとします。ヘルスチェックはCLBの各バックエンド物理マシン上でそれぞれ行われます。このため、CLBインスタンスで5秒に1回のチェックリクエストを設定した場合、実際のCLBバックエンドの各物理マシンがすべて5秒に1回のチェックを送信します。このときバックエンドサーバーでは5秒間に4回のチェックリクエストを受信する可能性があります。
このスキームのメリットは、高効率でチェックの正確性が高く、誤削除を防止できる点にあります。例えば、CLBインスタンスクラスターの8台の物理マシンのうち、1台が失敗と判断されても、このマシンがトラフィックを転送しなくなるだけで、残りの7台はトラフィックを正常に転送できます。
業務が負荷に敏感であり、高頻度のヘルスチェックによって正常な業務アクセスに影響が生じる可能性がある場合は、チェック間隔を広げる方法で業務への影響を低減することができます（例えばチェックを15秒に1回に設定するなど）。
1つのバックエンドサーバーが複数のCLBインスタンスにバインドされている場合、各CLBインスタンスはヘルスチェックメッセージを送信してこのサーバーが健全であるかどうかをチェックするために使用するため、ヘルスチェックの頻度が高くなります。