Classic Load Balancer (CLB) は、ヘルスチェックを実行してバックエンドサーバーの可用性を確認します。 ヘルスチェックを有効にした後、バックエンドサーバーが異常であると宣言された場合、異常なバックエンドサーバー宛てのリクエストは他の正常なバックエンドサーバーに配信されます。 異常なバックエンドサーバーが正常になると、リクエストはバックエンドサーバーに戻って失敗します。 ヘルスチェックは、単一障害点 (SPOF) を防ぐことができるため、アプリケーションの可用性を向上させます。
ビジネスがトラフィック変動に非常に敏感な場合、頻繁なヘルスチェックがビジネスの可用性に影響を与える可能性があります。 ヘルスチェックのビジネスへの悪影響を減らすには、ヘルスチェックの頻度を減らすか、ヘルスチェックの間隔を増やすか、レイヤー7ヘルスチェックをレイヤー4ヘルスチェックに変更します。 ビジネスの継続性を確保するために、ヘルスチェック機能を有効にすることを推奨します。
ヘルスチェックの仕組み
CLBインスタンスはクラスターにデプロイされます。 レイヤー4またはレイヤー7クラスターのノードは、ネットワークトラフィックの転送とヘルスチェックの実行を担当します。
レイヤー4クラスターのノードは互いに独立しており、転送ルールに基づいてネットワークトラフィックを転送し、ヘルスチェックを実行します。 バックエンドサーバーがレイヤ4クラスター内のノードによって実行されたヘルスチェックに失敗した場合、バックエンドサーバーは異常と宣言されます。 バックエンドサーバー宛てのリクエストは、他のバックエンドサーバーに配信されます。 レイヤー4クラスター内のすべてのノードが、異常なバックエンドサーバーへのリクエストの配信を停止します。
次の図に示すように、CLBヘルスチェックではCIDRブロック100.64.0.0/10が使用されます。 iptablesなどのセキュリティルールを設定していない限り、CIDRブロック100.64.0.0/10からのアクセスを許可するようにセキュリティグループルールを設定する必要はありません。 CIDRブロックはAlibaba Cloudによって予約されているため、100.64.0.0/10を許可しても潜在的なリスクは増加しません。 CIDRブロック内のIPアドレスはユーザーに割り当てられません。
CLBがHTTPおよびHTTPSヘルスチェックを実行する方法
次の図に示すように、レイヤー7のHTTPおよびHTTPSリスナーの場合、ヘルスチェックではHEADまたはGETメソッドを使用して可用性をプローブします。
HTTPSリスナーの証明書はCLBで管理されます。 CLBとバックエンドサーバー間のヘルスチェックやサービスインタラクションデータなどのデータは、HTTPSではなくHTTP経由で交換され、システムパフォーマンスが向上します。
CLBがレイヤー7ヘルスチェックを実行する方法:
レイヤー7クラスターのノードは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレス、ヘルスチェックポート、およびヘルスチェックURLにHTTP Headリクエストを送信します。 HTTP Headリクエストには、指定されたドメイン名が含まれます。
バックエンドサーバーはリクエストを受信し、バックエンドサーバーのステータスに基づいてHTTPステータスコードを返します。
レイヤー7クラスター内のノードがタイムアウト期間内に応答を受信しない場合、バックエンドサーバーは異常であると宣言されます。
レイヤー7クラスターのノードがタイムアウト期間内に応答を受信した場合、返されたHTTPステータスコードは指定されたHTTPステータスコードと比較されます。 返されたステータスコードが指定されたステータスコードのいずれかと一致する場合、バックエンドサーバーは正常であると宣言されます。 それ以外の場合、バックエンドサーバーは異常と宣言されます。
CLBがTCPヘルスチェックを実行する方法
CLBインスタンスにTCPリスナーを追加すると、次の図に示すように、CLBインスタンスはTCPセッションを確立してレイヤ4ヘルスチェックを実行します。 これにより、ヘルスチェックの効率が向上します。
CLBがTCPヘルスチェックを実行する方法:
レイヤー4クラスターのノードは、リスナーのヘルスチェック設定に基づいて、TCP SYNパケットをバックエンドサーバーの内部IPアドレスとヘルスチェックポートに送信します。
バックエンドサーバーポートが稼働している場合、バックエンドサーバーはTCP-SYNパケットを受信した後にSYN-ACKパケットを返します。
レイヤ4クラスター内のノードがタイムアウト期間内にSYN-ACKパケットを受信しない場合、バックエンドサーバーは異常であると宣言されます。 ノードはRSTパケットをバックエンドサーバーに送信して、TCP接続を閉じます。
レイヤ4クラスター内のノードがタイムアウト期間内にSYN-ACKパケットを受信した場合、バックエンドサーバーは正常であると宣言されます。 ノードはRSTパケットをバックエンドサーバーに送信して、TCP接続を閉じます。
TCP 3ウェイハンドシェイクの後、レイヤ4クラスターのノードは、バックエンドサーバーからACKパケットを受信した後にSYN-ACKパケットを送信します。 次に、ノードは、TCP接続を閉じるためにRSTパケットを送信する。
このメカニズムにより、バックエンドサーバーで誤ったTCP接続エラーが発生する可能性があります。 その結果、バックエンドサーバーは、Java接続プールログなどのソフトウェアログにConnection reset by peerエラーメッセージを記録することがあります。
解決策：
TCPリスナーのHTTPヘルスチェックを設定します。
CLB CIDRブロックからのリクエストによってトリガーされた偽のTCP接続エラーを無視するために、バックエンドサーバーでクライアントIP保存を有効にします。
CLBによるUDPヘルスチェックの実行方法
UDPリスナーをCLBインスタンスに追加すると、次の図に示すように、CLBはUDPパケットを送信してバックエンドサーバーのステータスを確認します。
CLBがUDPヘルスチェックを実行する方法:
レイヤー4クラスターのノードは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレスとヘルスチェックポートにUDPパケットを送信します。
バックエンドサーバーポートが生きていない場合、
port XX unreachableなどのICMPエラーメッセージが返されます。 それ以外の場合、ICMPエラーメッセージは返されません。レイヤ4クラスター内のノードがタイムアウト期間内にICMPエラーメッセージを受信した場合、バックエンドサーバーは異常と宣言されます。
レイヤ4クラスター内のノードがタイムアウト期間内にICMPエラーメッセージを受信しない場合、バックエンドサーバーは正常であると宣言されます。
次の状況では、UDPヘルスチェックの結果がバックエンドサーバー上のアプリケーションの実際のステータスを反映しない場合があります。
Linuxバックエンドサーバーが同時実行性の高いシナリオで使用されている場合、LinuxのICMPフラッド保護機能はICMPパケットの送信頻度を抑制します。 この場合、アプリケーションエラーが発生した場合でも、CLBがエラーメッセージポートXX到達不能を受信していないため、CLBはバックエンドサーバーが正常であると見なす可能性があります。 その結果、ヘルスチェックの結果は、実際のアプリケーションの状態とは異なるものとなる。
解決策：
指定した文字列をバックエンドサーバーに送信するようにCLBを設定できます。 バックエンドサーバーは、CLBに指定された応答を返す場合にのみ正常と見なされます。 ただし、バックエンドサーバー上のアプリケーションは、応答を返すように設定する必要があります。
ヘルスチェックタイムウィンドウ
ヘルスチェック機能により、サービスの可用性が向上します。 ただし、異常なバックエンドサーバーによって頻繁に発生するフェイルオーバーは、システムの可用性に影響を与える可能性があります。 ヘルスチェックタイムウィンドウは、フェイルオーバーを制御するために導入されます。 フェイルオーバーは、バックエンドサーバーが時間枠内に特定の数のヘルスチェックに連続して合格または失敗した場合にのみ実行されます。 ヘルスチェックの時間枠は、次の要因によって決まります。
ヘルスチェック間隔: 2つのヘルスチェック間の時間。
応答タイムアウト: バックエンドサーバーが応答するのにかかる時間。
ヘルスチェックしきい値: バックエンドサーバーがヘルスチェックに合格または不合格になった連続回数。
ヘルスチェック時間ウィンドウは、次の式に基づいて計算されます。
ヘルスチェック失敗のタイムウィンドウ=応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値-1)
ヘルスチェック成功のタイムウィンドウ=ヘルスチェック成功の応答時間 × 健康しきい値 + ヘルスチェック間隔 × (健康しきい値-1)
説明ヘルスチェックが成功した場合の応答時間は、ヘルスチェック要求が送信されてから応答が受信されるまでの時間です。 TCPヘルスチェックが設定されている場合、応答時間は短く、ほとんど無視できます。 HTTPヘルスチェックを設定する場合、応答時間はアプリケーションサーバーのパフォーマンスと負荷によって異なりますが、通常は数秒以内です。
ヘルスチェックの結果は、リクエスト転送に次の影響を与えます。
バックエンドサーバーがヘルスチェックに失敗した場合、新しいリクエストは他のバックエンドサーバーに配信されます。 CLBはクライアントから引き続きアクセス可能です。
バックエンドサーバーがヘルスチェックに合格すると、新しいリクエストがバックエンドサーバーに配信されます。 CLBはクライアントから引き続きアクセス可能です。
バックエンドサーバーでエラーが発生し、ヘルスチェックに失敗したが、ヘルスチェックによって異常と判断されなかった場合、リクエストはバックエンドサーバーに配信されます。 ただし、バックエンドサーバーにはリクエストにアクセスできません。 デフォルトでは、3回連続してヘルスチェックに失敗した場合、バックエンドサーバーは異常と宣言されます。
ヘルスチェック応答のタイムアウトとヘルスチェック間隔の例
この例では、次のヘルスチェック設定が使用されています。
応答タイムアウト時間: 5秒
ヘルスチェック間隔: 2秒
健康しきい値: 3回
不健康なしきい値: 3回
ヘルスチェック失敗のタイムウィンドウ=応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値-1) 。 この例では、時間窓は式5 × 3 + 2 × (3 − 1) に基づいて19秒である。 バックエンドサーバーが19秒間応答しない場合、バックエンドサーバーは異常であると宣言されます。
次の図は、健康状態から不健康状態までの時間枠を示しています。
ヘルスチェック成功のタイムウィンドウ=ヘルスチェック成功の応答時間 × 健康しきい値 + 健康チェック間隔 × (健康しきい値 − 1) 。 この例では、式 (1 × 3) + 2 × (3 − 1) に基づいて、時間窓は7秒である。 バックエンドサーバーが7秒以内に応答する場合、バックエンドサーバーは正常であると宣言されます。
ヘルスチェックが成功した場合の応答時間は、ヘルスチェック要求が送信されてから応答が受信されるまでの時間です。 TCPヘルスチェックが設定されている場合、応答時間は短く、ほとんど無視できます。 HTTPヘルスチェックを設定する場合、応答時間はアプリケーションサーバーのパフォーマンスと負荷によって異なりますが、通常は数秒以内です。
次の図は、異常状態から正常状態までの時間枠を示しています。 次の図では、サーバがヘルスチェック要求に応答するまでの所要时间は1秒です。
HTTPヘルスチェックのドメイン名
HTTPヘルスチェックのドメイン名を指定できます。 This setting is optional. 一部のアプリケーションサーバーは、アプリケーションサーバーが要求を受け入れる前に、要求のホストヘッダーを確認する必要があります。 この場合、リクエストはHostヘッダーを運ぶ必要があります。 ドメイン名がヘルスチェック用に設定されている場合、CLBはドメイン名をHostヘッダーに挿入します。 それ以外の場合、ヘルスチェック要求にはホストヘッダーが含まれません。 この場合、ヘルスチェック要求はサーバーによって拒否され、異常と宣言される可能性があります。
アプリケーションサーバーがリクエストのHostヘッダーを検証する場合、ヘルスチェック機能が期待どおりに機能するように、ヘルスチェック用のドメイン名を設定する必要があります。
関連ドキュメント
リスナーの作成時にヘルスチェックを設定する方法の詳細については、「CLBヘルスチェックの設定と管理」をご参照ください。
ヘルスチェックに関するよくある質問 (FAQ) の詳細については、「ヘルスチェックに関するFAQ」をご参照ください。