Network Load Balancer (NLB) は、ヘルスチェックを使用してバックエンドサーバーの可用性をテストします。ヘルスチェックを有効にすると、バックエンドサーバーがヘルスチェックに失敗した場合、NLB はそのバックエンドサーバー宛のリクエストを、正常な他のバックエンドサーバーに自動的に転送します。障害のあったバックエンドサーバーが正常な状態に復帰すると、NLB は再びそのサーバーへのリクエスト転送を自動的に再開します。ヘルスチェックは、サービスの高い可用性を確保するための重要な手段です。ヘルスチェックにより、ビジネス全体の可用性が向上し、異常なサーバーに起因する単一障害点 (SPOF) を排除できます。
ヘルスチェックのプロセス
NLB インスタンスはクラスターにデプロイされます。クラスター内のノードサーバーは、データの転送とヘルスチェックの実行に使用されます。
クラスター内のサーバーは互いに独立しており、NLB ポリシーに基づいてデータの転送とヘルスチェックを並行して実行します。
NLB が異常なバックエンドサーバーを検出し、そのサーバーで接続ドレインが無効になっている場合、既存のすべてのセッションが完了した後にバックエンドサーバー上の接続が切断されます。その間、新しいリクエストはそのバックエンドサーバーに転送されなくなります。
NLB が異常なバックエンドサーバーを検出し、そのサーバーで接続ドレインが有効になっている場合、バックエンドサーバーは既存のセッションの処理を継続します。接続は、接続ドレインのタイムアウト期間が終了したときに切断されます。その間、新しいリクエストはそのバックエンドサーバーに転送されなくなります。
NLB は、ローカル IP アドレスを使用してヘルスチェックを実行します。この IP アドレスがバックエンドサーバーによってブロックされていないことを確認してください。この IP アドレスに対して、Elastic Compute Service (ECS) のセキュリティグループで許可ルールを設定する必要はありません。ただし、iptables などの他のセキュリティポリシーが使用されている場合は、そのセキュリティポリシーでこの IP アドレスを許可してください。
NLB インスタンスのすべてのバックエンドサーバーがヘルスチェックに失敗した場合、NLB は「ベストエフォートモード」に入り、すべてのバックエンドサーバーにリクエストを転送します。これは、ビジネスの可用性を可能な限り維持するために行われます。
仕組み
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 接続を閉じます。
通常、TCP の 3ウェイハンドシェイクが実行されます。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) リスナーでは、HEAD または GET リクエストを送信してバックエンドサーバーの可用性を照会する HTTP ヘルスチェックを設定できます。次の図に、ヘルスチェックの実行方法を示します。
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 ヘルスチェックは、高効率で安定したリアルタイムのデータ伝送を保証します。
Internet of Things (IoT) 業界：UDP ヘルスチェックを使用して、センサーデバイスのステータスを迅速に確認できます。UDP ヘルスチェックは、電力に敏感またはコストに敏感な IoT デバイスの低いネットワーク遅延と高い効率を保証します。
V2X (Vehicle-to-Everything) 業界：車両とインフラストラクチャ間で UDP ヘルスチェックを実行して、リアルタイムのデータ交換と迅速な応答を保証できます。UDP ヘルスチェックは、V2X サービスの通信の安定性と信頼性を保証します。
仮想現実 (VR) および拡張現実 (AR) 業界：UDP ヘルスチェックを使用して、視覚データとインタラクションデータの迅速な伝送を保証し、ユーザーエクスペリエンスを向上させることができます。
クラウドゲーム業界：UDP ヘルスチェックを使用して、クラウドゲームをリアルタイムでモニターできます。UDP ヘルスチェックは、低いネットワーク遅延を保証し、ゲームの流暢さを向上させます。
HTTP ヘルスチェック
Web サービスのヘルスチェック：バックエンドサーバーが HTTP または HTTPS の Web サービスを実行している場合、HTTP ヘルスチェックを使用してサーバーのステータスを照会できます。サーバーが HTTP リクエストを処理できるかどうかをテストするには、
/healthなどのサーバー上の指定されたパスに HTTP GET または HEAD リクエストを送信できます。アプリケーションのカスタムヘルスチェック：一部のアプリケーションは、カスタムのヘルスチェックロジックを使用します。たとえば、カスタムヘルスチェックを実行して、データベース接続プールやキャッシュのステータスを確認できます。
マイクロサービスアーキテクチャ：マイクロサービスアーキテクチャでは、各マイクロサービスが HTTP インターフェイスを使用して通信する場合があります。HTTP ヘルスチェックを使用して、マイクロサービスインスタンスのアプリケーションレイヤーのエラーを検出できます。ヘルスチェックの応答は、より詳細な診断情報を提供できます。
API ゲートウェイとリバースプロキシ：バックエンドサーバーが NGINX や HAProxy などの API ゲートウェイまたはリバースプロキシである場合、コンポーネントによって HTTP インターフェイスが提供されます。HTTP ヘルスチェックを使用して、サービスのヘルスステータスをモニターできます。
HTTP ヘルスチェックのドメイン名
HTTP ヘルスチェックにドメイン名を指定できます。この設定はオプションです。一部のアプリケーションサーバーは、リクエストを受け入れる前に、リクエスト内の Host ヘッダーを検証する必要があります。この場合、リクエストには Host ヘッダーが含まれている必要があります。ヘルスチェックの設定でドメイン名を指定すると、NLB はそのドメイン名を Host ヘッダーに追加します。ドメイン名を指定しない場合、NLB は Host ヘッダーをリクエストに追加しません。この場合、ヘルスチェックリクエストはバックエンドサーバーによって拒否され、ヘルスチェックの失敗につながる可能性があります。
アプリケーションサーバーがリクエスト内の Host ヘッダーを検証する場合、ヘルスチェック機能が期待どおりに機能するように、ヘルスチェック用のドメイン名を設定する必要があります。
関連ドキュメント
ヘルスチェックの設定方法の詳細については、「NLB サーバーグループ」をご参照ください。
ヘルスチェックの問題のトラブルシューティング方法の詳細については、「NLB ヘルスチェックの問題のトラブルシューティング方法」をご参照ください。