Classic Load Balancer (CLB) は、ヘルスチェックを使用してバックエンドサーバーの可用性を判断します。ヘルスチェックを有効にすると、バックエンドサーバーが異常になった場合に、CLB は他の正常なバックエンドサーバーにリクエストを分散します。サーバーが回復すると、CLB はそのサーバーへのトラフィックのルーティングを再開します。このメカニズムにより、個々のサーバー障害によるサービスの中断を防ぎ、サービスの可用性が向上します。
ワークロードが負荷に敏感な場合、頻繁なヘルスチェックは通常のサービスアクセスに影響を与える可能性があります。ビジネス要件に応じて、ヘルスチェックの頻度を下げたり、ヘルスチェックの間隔を広げたり、レイヤー 7 からレイヤー 4 のチェックに切り替えたりすることで、影響を軽減できます。ただし、継続的なサービスの可用性を確保するため、ヘルスチェックを無効にすることは推奨されません。
ヘルスチェックの仕組み
ヘルスチェックは、定期的にリクエストを送信することでサーバーのステータスを確認します。
CLB はクラスターにデプロイされます。そのノードは、データ転送とヘルスチェックの両方を処理します。バックエンドサーバーがヘルスチェックに失敗した場合、CLB はそのサーバーへの新しいクライアントリクエストの分散を停止します。
CLB のヘルスチェックは、CIDR ブロック 100.64.0.0/10 を使用します。バックエンドサーバーがこの CIDR ブロックをブロックしないようにしてください。この CIDR ブロックに対してセキュリティグループで許可ルールを追加する必要はありません。ただし、iptables などの他のセキュリティポリシーを設定している場合は、100.64.0.0/10 からのトラフィックを許可する必要があります。これは Alibaba Cloud の予約済み CIDR ブロックであり、セキュリティリスクはありません。
HTTP/HTTPS リスナーのヘルスチェック
レイヤー 7 リスナー (HTTP/HTTPS) は、HEAD または GET リクエストを使用してヘルスチェックを実行します。
HTTPS リスナーの場合、証明書は CLB によって管理されます。CLB とバックエンドサーバーは、パフォーマンスを向上させるために HTTP を介してデータを交換します。
レイヤー 7 リスナーのヘルスチェックプロセスは次のとおりです：
ノードは、リスナーの設定に基づいて、バックエンドサーバーに HTTP HEAD リクエストを送信します。
バックエンドサーバーは HTTP ステータスコードを返します。
応答タイムアウト期間内に応答が受信されない場合、ヘルスチェックは失敗します。
応答タイムアウト期間内に応答が受信された場合、CLB は応答のステータスコードと設定された正常ステータスコードを比較します。ステータスコードが一致する場合、チェックは成功します。それ以外の場合、チェックは失敗します。
デフォルトでは、CLB のヘルスチェックは HTTP 2xx および 3xx ステータスコードのみを正常として扱います。バックエンドサーバーが 4xx ステータスコード (400、403、404、429 など) または 5xx ステータスコード (500、502、503 など) を返した場合、ヘルスチェックは失敗します。
4xx または 5xx コードを正常ステータスコードのリストに追加するのではなく、HTTP 200 ステータスコードを返す専用のヘルスチェックエンドポイント (例：/health) を作成することを推奨します。
TCP リスナーのヘルスチェック
レイヤー 4 TCP リスナーのヘルスチェック効率を向上させるため、ヘルスチェックは次の図に示すように、カスタム TCP プローブを使用してステータス情報を取得します。
TCP リスナーのヘルスチェックプロセスは次のとおりです：
レイヤー 4 クラスターのノードは、ヘルスチェック設定に基づいて、バックエンドサーバーの内部 IP アドレスとヘルスチェックポートに TCP SYN パケットを送信します。
バックエンドサーバーのポートがアクティブにリッスンしている場合、SYN+ACK パケットで応答します。
ノードが応答タイムアウト期間内にバックエンドサーバーから応答を受信しない場合、ヘルスチェックは失敗します。その後、ノードは RST パケットを送信して TCP 接続を終了します。
ノードが応答タイムアウト期間内にバックエンドサーバーから応答を受信した場合、ヘルスチェックは成功します。その後、ノードは RST パケットを送信して TCP 接続を終了します。
このメカニズムにより、バックエンドサーバーのアプリケーションログに Connection reset by peer などの TCP 接続エラーが記録されることがあります。
ソリューション：
TCP リスナーに HTTP ベースのヘルスチェックを使用する。
バックエンドサーバーでクライアント IP の保持を有効にし、CLB サービスの CIDR ブロックからの接続エラーを無視するように設定する。
UDP リスナーのヘルスチェック
レイヤー 4 UDP リスナーの場合、ヘルスチェックは次の図に示すように、UDP プローブを使用してステータス情報を取得します。
UDP リスナーのヘルスチェックプロセスは次のとおりです：
レイヤー 4 クラスターのノードは、ヘルスチェック設定に基づいて、バックエンドサーバーの内部 IP アドレスとヘルスチェックポートに UDP パケットを送信します。
バックエンドサーバーのポートがリッスンしていない場合、そのオペレーティングシステムは
port XX unreachableなどの ICMP エラーメッセージを返します。ポートがリッスンしている場合、メッセージは返されません。ノードが応答タイムアウト期間内にこの ICMP エラーメッセージを受信した場合、ヘルスチェックは失敗します。
ノードが応答タイムアウト期間内にバックエンドサーバーから応答を受信しない場合、ヘルスチェックは成功します。
UDP サービスのヘルスチェックは、次のシナリオではサービスの実際のステータスを正確に反映しない場合があります：
バックエンドサーバーが Linux を実行している場合、オペレーティングシステムの ICMP フラッド保護により、高い同時実行性の期間中に ICMP メッセージを送信するレートが制限されることがあります。この場合、サービスがダウンしていても、CLB は port XX unreachable エラーを受信しない可能性があります。CLB は ICMP エラーが受信されなかったため、チェックを誤って成功とマークし、ヘルスチェックステータスと実際のサービスステータスとの間に不一致が生じます。
ソリューション：
CLB がバックエンドサーバーに特定の文字列を送信するように設定します。チェックは、特定の応答を受信した後にのみ成功します。この方法では、バックエンドアプリケーションの変更が必要です。
ヘルスチェックのタイムウィンドウ
ヘルスチェックはサービスの可用性を向上させます。頻繁なステータス変更による不安定さを防ぐため、CLB はバックエンドサーバーが複数回のチェックに連続して成功または失敗した後にのみ、そのステータスを変更します。このヘルスチェックウィンドウは、次の 3 つの要因に依存します：
ヘルスチェック間隔：2 つの連続したヘルスチェック間の時間。
応答タイムアウト：サーバーからの応答を待つ最大時間。
ヘルスチェックしきい値：サーバーのステータスを変更するために必要な、連続した成功または失敗したヘルスチェックの回数。
タイムウィンドウは、次の数式を使用して計算されます：
ヘルスチェックが失敗と判断されるまでのタイムウィンドウ = 応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値 - 1)
ヘルスチェックが成功と判断されるまでのタイムウィンドウ = (正常なチェックの応答時間 × 正常しきい値) + ヘルスチェック間隔 × (正常しきい値 - 1)
説明正常なチェックの応答時間は、ヘルスチェックリクエストの送信からその応答を受信するまでの期間です。TCP ヘルスチェックの場合、この時間は非常に短く、無視できます。HTTP ヘルスチェックの場合、この時間はバックエンドサーバーのパフォーマンスと負荷に依存しますが、通常は 1 秒未満です。
ヘルスチェックステータスがリクエスト転送に与える影響：
バックエンドサーバーがヘルスチェックに失敗した場合、新しいリクエストはそのサーバーに分散されません。これはクライアントのアクセスには影響しません。
バックエンドサーバーがヘルスチェックに成功した場合、新しいリクエストはそのサーバーに分散され、クライアントのアクセスは正常です。
バックエンドサーバーに問題があり、ヘルスチェックが失敗と判断されるまでのタイムウィンドウ内にあるが、まだ異常しきい値 (デフォルトでは 3 回連続の失敗) に達していない場合、リクエストは引き続きそのサーバーに分散されます。これにより、クライアントのリクエストが失敗する可能性があります。
例：応答タイムアウトとヘルスチェック間隔
次のヘルスチェック設定を考えます：
応答タイムアウト：5 秒
ヘルスチェック間隔：2 秒
正常しきい値：3
異常しきい値：3
ヘルスチェックが失敗と判断されるまでのタイムウィンドウ = 応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値 - 1)。計算すると、5 × 3 + 2 × (3 - 1) = 19 秒になります。これは、最初のヘルスチェックの失敗からサーバーが異常とマークされるまでに 19 秒が経過することを意味します。
ヘルスチェックが成功と判断されるまでのタイムウィンドウ = (正常なチェックの応答時間 × 正常しきい値) + ヘルスチェック間隔 × (正常しきい値 - 1)。応答時間が 1 秒であると仮定すると、計算は (1 × 3) + 2 × (3 - 1) = 7 秒になります。これは、異常なサーバーが最初のヘルスチェックに成功してから正常とマークされるまでに 7 秒が経過することを意味します。
正常なチェックの応答時間は、ヘルスチェックリクエストの送信からその応答を受信するまでの期間です。TCP ヘルスチェックの場合、ポートがアクティブであるかどうかをプローブするだけなので、この時間は非常に短く、無視できます。HTTP ヘルスチェックの場合、この時間はバックエンドサーバーのパフォーマンスと負荷に依存しますが、通常は 1 秒未満です。
HTTP ヘルスチェックのドメイン名
HTTP ヘルスチェックを使用する場合、オプションでドメイン名を設定できます。一部のバックエンドサーバーは、リクエストに Host ヘッダーが存在することを要求し、その内容を検証します。ドメイン名を設定すると、CLB はそれをヘルスチェックリクエストの Host ヘッダーに追加します。ドメイン名を設定しない場合、サーバーはヘルスチェックリクエストを拒否し、チェックが失敗する可能性があります。
したがって、バックエンドサーバーが Host ヘッダーを検証する場合、ヘルスチェックが正しく機能するようにドメイン名を設定する必要があります。
参照
リスナーを追加する際には、ヘルスチェックを設定する必要があります。手順については、「CLB ヘルスチェックの設定と管理」をご参照ください。
ヘルスチェックに関するよくある質問については、「CLB ヘルスチェックに関する FAQ」をご参照ください。