Network Load Balancer (NLB) は、ヘルスチェックを使用してバックエンドサーバーの可用性をテストします。 ヘルスチェックを有効にした後、バックエンドサーバーがヘルスチェックに失敗した場合、NLBはバックエンドサーバー宛てのリクエストを他の正常なバックエンドサーバーに自動的に転送します。 バックエンドサーバーが再び正常であると宣言されると、NLBは自動的にリクエストをバックエンドサーバーに転送します。 ヘルスチェックは、サービスの高可用性を確保するための重要な手段です。 ヘルスチェックは、ビジネスの全体的な可用性を向上させ、異常なサーバーによって引き起こされる単一障害点 (SPOF) を排除します。
ヘルスチェックプロセス
NLBインスタンスはクラスターにデプロイされます。 クラスター内のノードサーバーは、データの転送とヘルスチェックの実行に使用されます。
クラスター内のサーバーは互いに独立しており、NLBポリシーに基づいてデータを転送し、ヘルスチェックを並列に実行します。 NLBが異常なバックエンドサーバーを検出した場合、接続とリクエストは次のシナリオの説明に従って処理されます。
バックエンドサーバーの接続のドレインが無効になっている場合、既存のすべてのセッションが完了した後、バックエンドサーバーの接続は閉じられます。 その間、新しいリクエストはバックエンドサーバーに転送されなくなります。
バックエンドサーバーで接続のドレインが有効になっている場合、バックエンドサーバーは既存のセッションの処理を続行します。 接続ドレインタイムアウト期間が終了すると、接続は閉じられます。 その間、新しいリクエストはバックエンドサーバーに転送されなくなります。
NLBは、ローカルIPアドレスを使用してヘルスチェックを実行します。 IPアドレスがバックエンドサーバーによってブロックされていないことを確認してください。 IPアドレスのElastic Compute Service (ECS) セキュリティグループで許可ルールを設定する必要はありません。 ただし、iptablesなどの他のセキュリティポリシーが使用されている場合は、セキュリティポリシーでIPアドレスを許可します。
仕組み
TCPヘルスチェック
次の図に示すように、TCPヘルスチェックの効率を向上させるために、NLBはカスタマイズされたTCPプローブを送信してバックエンドサーバーの可用性をテストします。
NLBがTCPヘルスチェックを実行する方法:
NLBは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレスとヘルスチェックポートにTCP-SYNパケットを送信します。
バックエンドサーバーポートが稼働している場合、バックエンドサーバーはTCP-SYNパケットを受信した後にSYN-ACKパケットを返します。
応答タイムアウト期間が終了する前にNLBがバックエンドサーバーからSYN-ACKパケットを受信しない場合、バックエンドサーバーは異常であると宣言されます。 次に、NLBはRSTパケットをバックエンドサーバーに送信してTCP接続を閉じます。
応答タイムアウト期間が終了する前に、NLBがバックエンドサーバーからSYN-ACKパケットを受信した場合、バックエンドサーバーはヘルスチェックに合格します。 NLBはACKパケットを送信し、すぐにRSTパケットを送信してTCP接続を閉じます。
通常の場合、3回のTCPハンドシェイクが実行されます。 NLBがバックエンドサーバーからSYN-ACKパケットを受信した後、NLBはACKパケットを送信し、すぐにRSTパケットを送信してTCP接続を閉じます。 このメカニズムにより、バックエンドサーバーで誤ったTCP接続エラーが発生する可能性があります。 その結果、バックエンドサーバーは、Java接続プールログなどのソフトウェアログにConnection reset by peerエラーメッセージを記録することがあります。
解決策：
TCPリスナーのHTTPヘルスチェックを設定します。
バックエンドサーバーでクライアントIPの保存を有効にして、NLB CIDRブロックからのリクエストによってトリガーされた誤ったTCP接続エラーを無視します。
UDPヘルスチェック
次の方法を使用して、UDPヘルスチェックを実行できます。
方法1: ポートのヘルスチェック
ヘルスチェックの実行方法を次の図に示します。
次のプロセスでは、UDPリスナーがポートでヘルスチェックを実行する方法について説明します。
NLBは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレスにICMPリクエストパケットを送信します。
NLBは、リスナーのヘルスチェック設定に基づいて、バックエンドサーバーの内部IPアドレスとヘルスチェックポートにUDPプローブパケットを送信します。
応答タイムアウト期間が終了する前にバックエンドサーバーがICMP応答パケットを返し、
Port XX Unreachableメッセージを返さない場合、バックエンドサーバーはヘルスチェックに合格します。 それ以外の場合、バックエンドサーバーはヘルスチェックに失敗します。
方法2: カスタムヘルスチェック
ヘルスチェックの実行方法を次の図に示します。
次のプロセスでは、UDPリスナーによるカスタムヘルスチェックの実行方法について説明します。
NLBは、指定された文字を含むUDPプローブパケットをバックエンドサーバーの内部IPアドレスとヘルスチェックポートに送信します。
応答タイムアウト期間が終了する前にNLBが指定されたメッセージを受信した場合、バックエンドサーバーはヘルスチェックに合格します。 それ以外の場合、バックエンドサーバーはヘルスチェックに失敗します。
HTTPヘルスチェック
レイヤー4 (TCPまたはUDP) リスナーの場合、HTTPヘルスチェックを設定できます。HTTPヘルスチェックは、HEADまたはGETリクエストを送信して、バックエンドサーバーの可用性を照会します。 ヘルスチェックの実行方法を次の図に示します。
次のプロセスでは、HTTPヘルスチェックの実行方法について説明します。
NLBは、リスナーのヘルスチェック設定に基づいて、ドメイン名を含むHTTP HEADまたはGETリクエストをバックエンドサーバーの内部IPアドレスとヘルスチェックパスに送信します。
バックエンドサーバーがHTTPリクエストを受信すると、バックエンドサーバーはサーバーのステータスに基づいてHTTPステータスコードを返します。
応答タイムアウト期間が終了する前にNLBがバックエンドサーバーから応答を受信しない場合、バックエンドサーバーはヘルスチェックに失敗します。
応答タイムアウト期間が終了する前にNLBがバックエンドサーバーから応答を受信した場合、バックエンドサーバーは受信したHTTPステータスコードをヘルスチェック設定で設定されたHTTPステータスコードと比較します。 返されたステータスコードが指定されたステータスコードのいずれかと一致する場合、バックエンドサーバーは正常であると宣言されます。 そうでなければ、バックエンドサーバーは異常とみなされます。
シナリオ
TCPヘルスチェック
ファイル転送プロトコル (FTP) サービス: TCPヘルスチェックを使用して、FTPサービスが接続リクエストを受信して応答できるかどうかをテストできます。 TCPヘルスチェックは、FTPサービスの安定性と信頼性を保証します。
電子メールサービス: TCPヘルスチェックを使用して、電子メールサービスが電子メールを送受信できるかどうかをテストできます。 TCPヘルスチェックにより、電子メールサービスの信頼性が確保されます。
金融取引: 金融取引システムでは、取引サーバの信頼性が重要な要素である。 TCPヘルスチェックを使用して、システム障害を時間内に検出し、トランザクションの中断を防ぐことができます。
リモートログオン: TCPヘルスチェックを使用して、リモートログオンサービスの可用性とパフォーマンスをテストできます。 TCPヘルスチェックにより、ユーザーとリモートサーバー間の安全で安定した接続が保証されます。
UDPヘルスチェック
伝統産業
DNSサービス: UDPヘルスチェックを使用して、DNSサーバーが期待どおりにクエリに応答できるかどうかをすばやくテストできます。
Voice over Internet Protocol (VoIP) サービス: 小さなUDPパケットを送信して、SkypeやVoIP電話システムなどのVoIPサービスのネットワーク遅延、パケット損失率、ネットワークジッタなどの主要なメトリックをテストできます。 UDPヘルスチェックは、通信品質の向上に役立ちます。
オンラインゲーム: UDPヘルスチェックを使用して、ゲームサーバーの応答時間と可用性を監視できます。 UDPヘルスチェックは、ゲームの流暢さとユーザーエクスペリエンスの向上に役立ちます。
ストリーミングメディアサービス: UDPヘルスチェックを使用して、ビデオ会議やリアルタイムビデオストリーミングなどのストリーミングメディアサービスのビデオストリーミングの可用性と品質を評価できます。 UDPヘルスチェックは、応答効率とストリーミングの安定性の向上に役立ちます。
インスタントメッセージングサービス: UDPヘルスチェックを使用して、接続の安定性とネットワーク遅延をリアルタイムで監視できます。 UDPヘルスチェックにより、高速で信頼性の高いメッセージ配信が保証され、ユーザーエクスペリエンスが向上します。
新興産業
IT業界向けQUICへの移行: QUICシナリオでUDPヘルスチェックを使用して、接続ステータスを確認できます。 UDPヘルスチェックにより、高効率で安定したリアルタイムのデータ伝送が保証されます。
モノのインターネット (IoT) 業界: UDPヘルスチェックを使用して、センサーデバイスのステータスをすばやく確認できます。 UDPヘルスチェックにより、電力に敏感なIoTデバイスやコストに敏感なIoTデバイスのネットワーク遅延が低く、効率が高くなります。
Vehicle-to-Everything (V2X) 業界: 車両とインフラストラクチャの間でUDPヘルスチェックを実行して、リアルタイムのデータ交換と迅速な対応を確保できます。 UDPヘルスチェックにより、V2Xサービスの通信の安定性と信頼性が確保されます。
バーチャルリアリティ (VR) および拡張現実 (AR) 業界: UDPヘルスチェックを使用して、ビジュアルおよびインタラクションデータを迅速に送信し、ユーザーエクスペリエンスを向上させることができます。
クラウドゲーム業界: UDPヘルスチェックを使用して、クラウドゲームをリアルタイムで監視できます。 UDPヘルスチェックにより、ネットワークの待ち時間が短くなり、ゲームの流暢さが向上します。
HTTPヘルスチェック
webサービスのヘルスチェック: バックエンドサーバーがHTTPまたはHTTPS webサービスを実行している場合、HTTPヘルスチェックを使用してサーバーのステータスを照会できます。 サーバーがHTTPリクエストを処理できるかどうかをテストするには、HTTP GETリクエストまたはHEADリクエストをサーバー上の指定されたパス (
/healthなど) に送信します。アプリケーションのカスタムヘルスチェック: 一部のアプリケーションでは、カスタムヘルスチェックロジックを使用します。 たとえば、カスタムヘルスチェックを実行して、データベース接続プールとキャッシュステータスを確認できます。
マイクロサービスアーキテクチャ: マイクロサービスアーキテクチャでは、各マイクロサービスはHTTPインタフェースを使用して通信することができる。 HTTPヘルスチェックを使用して、マイクロサービスインスタンスのアプリケーション層エラーを検出できます。 ヘルスチェック応答は、より詳細な診断情報を提供することができる。
APIゲートウェイとリバースプロキシ: バックエンドサーバーがNGINXやHAProxyなどのAPIゲートウェイまたはリバースプロキシの場合、HTTPインターフェイスはコンポーネントによって提供されます。 HTTPヘルスチェックを使用して、サービスのヘルスステータスを監視できます。
HTTPヘルスチェックのドメイン名
HTTPヘルスチェックのドメイン名を指定できます。 This setting is optional. 一部のアプリケーションサーバーは、アプリケーションサーバーが要求を受け入れる前に、要求のホストヘッダーを確認する必要があります。 この場合、リクエストはHostヘッダーを運ぶ必要があります。 ヘルスチェック設定でドメイン名を指定した場合、NLBはドメイン名をHostヘッダーに追加します。 それ以外の場合、NLBはリクエストにHostヘッダーを追加しません。 この場合、ヘルスチェック要求はバックエンドサーバーによって拒否され、ヘルスチェックが失敗する可能性があります。
アプリケーションサーバーがリクエストのHostヘッダーを検証する場合、ヘルスチェック機能が期待どおりに機能するように、ヘルスチェック用のドメイン名を設定する必要があります。
参考情報
ヘルスチェックの設定方法の詳細については、「サーバーグループの作成と管理」をご参照ください。
ヘルスチェックの問題のトラブルシューティング方法の詳細については、「NLBヘルスチェックの問題のトラブルシューティング方法」をご参照ください。