製品アップデート情報
製品に関するお知らせ
ヘルスチェックの概要
CLBはヘルスチェックによってバックエンドサービスの可用性を判断し、バックエンドサービスの異常によるフロントエンドへの影響を回避することで、業務全体の可用性を向上させます。
ヘルスチェックを有効化すると、バックエンドサーバーの重み付けの大小にかかわらず（重みが0の場合も含めて）、CLBインスタンスは常にヘルスチェックを実行します。ヘルスチェックのステータスはインスタンスリストページの「ヘルスチェック」列か、リスナーにバインドしたバックエンドサービスの詳細ページで確認することができます。
バックエンドサーバーインスタンスが異常と判定された場合、CLBインスタンスは新しいリクエストを異常なバックエンドサーバーには転送せず、他の正常なバックエンドサーバーに自動的に転送します。
異常なインスタンスが正常に復旧すると、CLBはそのインスタンスをCLBサービスに復帰させ、リクエストの転送を再開します。
ヘルスチェックの結果、バックエンドサービスのすべてに異常が検出された場合、リクエストはすべてのバックエンドサーバーに転送されます。
ヘルスチェックを無効化すると、CLBはすべてのバックエンドサーバー（異常なバックエンドサーバーも含めて）にトラフィックを転送します。このため、ヘルスチェックを有効化し、CLBが異常なバックエンドサーバーを自動的にチェックして削除できるようにしておくことを強く推奨します。
デフォルトのパッシブヘルスチェックは、レイヤー4のTCP SSLリスナーやレイヤー7のHTTP/HTTPSリスナーには、パッシブヘルスチェック機能がデフォルトで設定されています（デフォルトで有効であり、無効化はサポートされません）。CLBは、トラフィックをバックエンドサービスに転送すると同時にバックエンドサービスのヘルスステータスを記録します。転送に失敗した場合、他のバックエンドサービスへの転送を再試行すると同時に、このバックエンドサービスの失敗回数を累計1回とします。失敗回数の累計が3に達した場合、バックエンドサービスは10秒間ブロックされます。ブロック時間が終了すると、トラフィック転送は再開され、バックエンドサービスのヘルスステータスが引き続き記録されます。
ヘルスチェックステータス
シングルリスナーのヘルスチェック状態の説明
ヘルスチェックでの検出状況に基づく、バックエンドサーバーのヘルスチェックステータスは次のとおりです。
ステータス | 説明 | トラフィックを転送するかどうか |
検出中 | 新たにバインドしたバックエンドサーバーの、チェック間隔×正常閾値の時間内におけるステータスです。例えば、チェック間隔が2秒、正常閾値が3回の場合、6秒間のステータスを表します。 | CLBは、「検出中」のバックエンドサービスにトラフィックを転送しません。 |
ヘルス | バックエンドサービスが正常な場合 | CLBは、「正常」なバックエンドサービスにトラフィックを転送します。 |
異常 | バックエンドサービスが異常な場合 | CLBは、「異常」なバックエンドサービスにトラフィックを転送しません。 レイヤー4リスナーまたはレイヤー7URLルールでは、CLBがすべてのバックエンドサービスが異常であることを検出した場合、all-dead-all-aliveロジックがアクティブ化され、リクエストがすべてのバックエンドサービスに転送されます。 |
すでにオフです | ヘルスチェックをオフにする | CLBはバックエンドサービスにトラフィックを転送します。 |
リストページのヘルスチェック状態の説明
インスタンスにおけるすべてのリスナーのヘルス検出状況に基づいて総合的に表示します。
状態 | 説明 |
正常 | このインスタンスの下にあるすべてのリスナーのバックエンドサービスは正常です。 このインスタンスの下にあるすべてのリスナーのヘルスチェックは有効になっていません。 |
異常 | このインスタンスの下にあるいずれかのリスナーに異常がある場合は、異常として表示されます。 |
未設定 | このインスタンスにはリスナー/ルールが設定されていない。 このインスタンスの下にあるいずれかのリスナーがバックエンドサービスにバインドされておらず、異常なリスナーが存在しません。 |
TCPヘルスチェック
レイヤー4TCPリスナーについては、TCPヘルスチェックを設定できます。TCPヘルスチェックではSYNパケット、すなわちTCPの3ウェイハンドシェイクの開始によって、バックエンドサーバーのステータス情報を取得します。もしくは、カスタムプロトコルのリクエスト内容および返される結果によって、バックエンドサーバーのステータス情報を取得することもできます。
TCPヘルスチェックのメカニズムは次のとおりです。
1. CLBがバックエンドサーバー（プライベートIPアドレス+ヘルスチェックポート）にSYN接続リクエストメッセージを送信します。
2. バックエンドサーバーはSYNリクエストメッセージを受信後、対応するポートが正常なリスニング状態にある場合は、SYN+ACKレスポンスメッセージを返します。
3. レスポンスタイムアウト時間内にCLBがバックエンドサーバーから返されたSYN+ACKレスポンスメッセージを受信した場合、サービスは正常に実行されていることを表し、ヘルスチェックは成功と判定されます。CLBはバックエンドサーバーにRSTリセットメッセージを送信し、TCP接続を中断します。
4. レスポンスタイムアウト時間内にCLBがバックエンドサーバーから返されたSYN+ACKレスポンスメッセージを受信しなかった場合、サービスの実行が異常であることを表し、ヘルスチェックは失敗したと判定されます。CLBはバックエンドサーバーにRSTリセットメッセージを送信し、TCP接続を中断します。
UDPヘルスチェック
レイヤー4 UDPリスナーについては、UDPヘルスチェックを設定できます。UDPヘルスチェックでは、
PingコマンドおよびヘルスチェックポートへのUDPチェックメッセージの送信によってヘルスステータスを取得します。もしくは、カスタムプロトコルのリクエスト内容および返される結果によってバックエンドサーバーのステータス情報を取得することもできます。
UDPヘルスチェックのメカニズムは次のとおりです。
1. CLBがバックエンドサーバーのプライベートIPアドレスに対し、
Pingコマンドを送信します。2.
Pingに成功し、なおかつレスポンスタイムアウト時間内に、バックエンドサーバーからエラーメッセージport XX unreachableが返されなかった場合、サービスは正常であることを表し、ヘルスチェックは成功と判定されます。3.
Pingに失敗するか、またはレスポンスタイムアウト時間内に、システムがバックエンドサーバーから返されたエラーメッセージport XX unreachableを受信した場合、サービスに異常があることを表し、ヘルスチェックは失敗と判定されます。ご注意：
UDPヘルスチェックはICMPプロトコルに依存しているため、バックエンドサーバーはICMPパケット（
Pingをサポート）、ICMPポート到達不能パケット（ポートチェックをサポート）を返せるよう許可する必要があります。バックエンドサーバーがLinuxサーバーの場合、多数同時実行のシーンにおいて、LinuxはICMP攻撃からの保護メカニズムを備えるため、サーバーからのICMPパケット送信の速度を制限します。この場合、バックエンドサービスに異常が生じていても、CLBに
port XX unreachableを返すことができないため、CLBはICMP応答を受信していないことからヘルスチェックを成功と判定し、最終的にバックエンドサービスの真のステータスがヘルスチェックと一致しなくなります。
対処方法：UDPヘルスチェックの設定の際に、バックエンドサーバーに指定の文字列を送信するよう入力および出力をカスタム設定し、CLBが指定の応答を受信した場合のみヘルスチェック成功と判断するようにします。この方法はバックエンドサーバーに依存しますので、バックエンドサーバーはヘルスチェックの入力を処理し、指定の出力を返す必要があります。カスタム検出方式を選択した場合、以下の 2 つの状況に分けられます：
1 つ目の状況では、「チェック要求」の内容のみを設定し、「チェックの戻り結果」を設定していない場合、ICMP ECHO メッセージ＋UDP 検出メッセージを使用します。
ヘルスチェックのメカニズムは以下の通りです：
3.1 CLB は、バックエンドサーバーのプライベートネットワーク IP アドレスに Ping コマンドを送信します。
3.2 CLB は、バックエンドサーバー（プライベートネットワーク IP アドレス + ヘルスチェックポート）に UDP 検出メッセージを送信します。
3.3 Ping が成功し、レスポンスタイムアウト時間内にバックエンドサーバーが port XX unreachable のエラーメッセージを返さない場合、サービスは正常であり、ヘルスチェックは成功したと判断されます。
3.4 Ping が失敗した場合、またはレスポンスタイムアウト時間内にバックエンドサーバーから port XX unreachable のエラーメッセージが返された場合、サービスは異常であり、ヘルスチェックは失敗したと判断されます。
注意：
ヘルスチェックは ICMP プロトコルに依存し、バックエンドサーバーが ICMP パケットに対するレスポンスを有効化（Ping をサポート）し、ICMP ポート到達不能パケットに対するレスポンスを有効化（検出ポートをサポート）する必要があります。
バックエンドサーバーが Linuxサーバーの場合、大規模な並列処理のシナリオでは、Linux には ICMP 攻撃に対する保護メカニズムがあるため、サーバーの ICMP 送信速度が制限されます。この場合、バックエンドサービスに異常があっても、CLB に port XX unreachable を返すことができないため、CLB はヘルスチェックの成功を判断するための ICMP レスポンスを受信できず、最終的にバックエンドサービスの実際の状態がヘルスチェックと一致しなくなります。
解決策：UDP ヘルスチェックを設定するときに、カスタム入力・出力を設定し、指定した文字列をバックエンドサーバーに送信し、CLB が指定したレスポンスを受信した場合にのみヘルスチェックの成功を判断します。この解決策はバックエンドサーバに依存しており、バックエンドサーバはヘルスチェックの入力を処理し、指定された出力を返す必要があります。
2 つ目の方法は、「チェックリクエスト 」と 「チェックの戻り結果」の内容を同時に設定した場合、UDP 検出メッセージのみを使用します。 RS ヘルス状態の判断条件は、UDP 返信メッセージを受信し、「チェックの戻り結果」の内容と一致することです。
ヘルスチェックのメカニズムは以下の通りです：
3.5 CLB は、バックエンドサーバー（プライベートネットワーク IP アドレス + ヘルスチェックポート）に UDP 検出メッセージを送信します。
3.6 UDP から返されたメッセージを受信し、「チェックの戻り結果」の内容と一致すれば、サービスは正常であり、ヘルスチェックは成功したと判断します。
3.7 レスポンスタイムアウト時間内に UDP から返されたメッセージを受信していない場合、または「チェックの戻り結果」の内容と一致しない場合、サービスは異常であり、ヘルスチェックは失敗したと判断します
HTTPヘルスチェック
レイヤー4 TCPリスナーおよびレイヤー7 HTTP/HTTPSリスナーについては、HTTPヘルスチェックを設定でき、HTTPリクエストを送信することでバックエンドサーバーのステータス情報を取得できます。
HTTPヘルスチェックのメカニズムは次のとおりです。
1. CLBがヘルスチェック設定に基づいて、バックエンドサーバー（プライベートIPアドレス+ヘルスチェックポート+チェックパス）にHTTPリクエストを送信します（チェックドメイン名を選択して設定できます）。
2. バックエンドサーバーはリクエストを受信後、該当するHTTPステータスコードを返します。
3. レスポンスタイムアウト時間内にCLBがバックエンドサーバーから返されたHTTPステータスコードを受信し、それが設定したHTTPステータスコードと一致した場合、ヘルスチェックは成功と判定され、そうでない場合は失敗と判定されます。
4. レスポンスタイムアウト時間内にCLBがバックエンドサーバーから返されたHTTPステータスコードを受信しなかった場合、ヘルスチェックは失敗と判定されます。
説明：
レイヤー7 HTTPSリスナーについては、HTTPSリスナーの転送ルールのバックエンドプロトコルにHTTPを選択した場合、ヘルスチェックにはHTTPヘルスチェックを使用します。HTTPSを選択した場合、ヘルスチェックにはHTTPSヘルスチェックを使用します。
HTTPSヘルスチェックは、基本的にHTTPヘルスチェックと類似しています。相違点は、HTTPSヘルスチェックはHTTPSリクエストを送信することによって、返されたHTTPSステータスコードに基づいてバックエンドサーバーのステータス情報を判断することです。
ヘルスチェックの時間範囲
CLBのヘルスチェックメカニズムは業務の可用性を効果的に向上させます。ヘルスチェックの頻繁な失敗に伴う切り替えがシステムの可用性に影響を与えることを防ぐため、ヘルスチェックはヘルスチェックの時間範囲内で複数回連続して成功または失敗した場合のみ、正常と異常のステータスを切り替えます。ヘルスチェックの時間範囲は次の要因によって決定されます。
ヘルスチェックの設定 | 説明 | デフォルト値 |
レスポンスタイムアウト | ヘルスチェックのレスポンスの最大タイムアウト時間です。 バックエンドサーバーがタイムアウト時間内に正しくレスポンスしない場合は、ヘルスチェックに異常があると判断されます。 設定可能範囲は2～60秒です。 | 2秒 |
チェック間隔 | CLBがヘルスチェックを行う時間の間隔です。 設定可能範囲は5～300秒です。 | 5秒 |
不健全なしきい値 | n回（nには数値を入力）連続してヘルスチェック失敗の結果を受信した場合に、異常であると認識し、コンソールで失敗と表示します。 設定可能範囲は2～10回です。 | 3回 |
健全なしきい値 | n回（nには数値を入力）連続してヘルスチェック成功の結果を受信した場合に、正常であると認識し、コンソールで成功と表示します。 設定可能範囲は2～10回です。 | 3回 |
レイヤー4ヘルスチェック時間範囲の計算方法は次のとおりです。
説明：
响应超时时间要小于检查间隔时间。
レイヤー4ヘルスチェック、すなわちTCPヘルスチェックまたはUDPヘルスチェックでは、チェックに成功したか、またはレスポンスタイムアウトかにかかわらず、前後2回の間の送信パケットのチェック間隔はすべて設定済みのチェック間隔となります。
ヘルスチェック失敗時間範囲 = チェック間隔 ×（異常閾値 - 1）
下図はヘルスチェックのレスポンスタイムアウト時間が2秒、チェック間隔が5秒、異常閾値が3回の場合の例です。ヘルスチェック失敗時間範囲は、5×（3-1）= 10sとなります。
ヘルスチェック成功時間範囲 = チェック間隔 ×（正常閾値 - 1）
下の図はヘルスチェック成功応答時間が1秒、チェック間隔が5秒、正常閾値が3回の場合の例です。ヘルスチェック成功時間範囲 = 5 x（3-1）= 10秒となります。
レイヤー7ヘルスチェック時間範囲の計算方法は次のとおりです。
ヘルスチェック失敗時間範囲 = 応答タイムアウト時間 × 異常閾値 + チェック間隔 ×（異常閾値 - 1）
下の図はヘルスチェックの応答タイムアウト時間が2秒、チェック間隔が5秒、異常閾値が3回の場合の例です。ヘルスチェック失敗時間範囲 = 2 x 3 + 5 x（3-1）= 16秒となります。
ヘルスチェック成功時間範囲 = ヘルスチェック成功応答時間 × 正常閾値 + チェック間隔 ×（正常閾値 - 1）
下図はヘルスチェック成功レスポンス時間が1秒、チェック間隔が5秒、正常閾値が3回の場合の例です。ヘルスチェック成功時間範囲 = 1×3+ 5×（3-1）=13sとなります。
ヘルスチェック検出識別子
CLBでヘルスチェックを有効化すると、バックエンドサーバーは正常な業務リクエストに加えて、ヘルスチェックリクエストも受信することになります。ヘルスチェックリクエストは次の識別子を有します。
ヘルスチェックプローブリクエストのソースIPは、CLBのVIPまたは100.64.0.0/10ネットワークセグメントです。
レイヤー4(TCP、UDP、TCP SSL)リスナーのヘルスチェックリクエストには、「HEALTH CHECK」の識別子が含まれます。
レイヤー7(HTTP、HTTPS)リスナーのヘルスチェックリクエストHeaderのuser-agentは、「clb-healthcheck」です。
説明：
従来型プライベートネットワークCLBでは、ヘルスチェックのソースIPは
169.254.128.0/17ネットワークセグメントです。基幹ネットワークのプライベートネットワークCLBでは、ヘルスチェックのソースIPはサーバーの物理IPとなります。
関連ドキュメント
フィードバック