Gateway Load Balancer (GWLB) は、バックエンドサーバーの状態を確認するためにヘルスチェックを使用します。ヘルスチェックを有効にすると、バックエンドサーバーがヘルスチェックに失敗した場合、GWLB はそのサーバーへの新しいリクエストの転送を停止し、他の正常なバックエンドサーバーに分散します。サーバーが正常な状態に戻ると、GWLB は自動的にトラフィックの転送を再開します。
ヘルスチェックの状態
以下の表は、バックエンドサーバーのヘルスチェック状態について説明しています。
状態 | 説明 |
初期化中 | GWLB インスタンスがヘルスチェック用に構成され、バックエンドサーバーリストを初期化中です。 |
正常 | バックエンドサーバーが期待通りに実行されています。 |
異常 | バックエンドサーバーがヘルスチェックに失敗したか、応答しませんでした。 |
未使用 | バックエンドサーバーは利用されていません。 |
無効 | ヘルスチェックは無効になっています。 |
仕組み
GWLB のヘルスチェック実施時、リクエストパケットは Geneve プロトコルを使用してカプセル化されません。
TCP ヘルスチェック
効率を向上させるため、GWLB はカスタム TCP プローブを使用してバックエンドサーバーのステータスを確認します。次の図に示すとおりです。
TCP ヘルスチェックのプロセスは次のとおりです。
リスナーの構成に基づき、GWLB はバックエンドサーバーのプライベート IP アドレスおよびヘルスチェックポートに TCP SYN パケットを送信します。
バックエンドサーバーのポートがリッスン中の場合、サーバーは SYN+ACK パケットで応答します。
指定された応答タイムアウト内に GWLB がバックエンドサーバーから SYN+ACK パケットを受信しない場合、ヘルスチェックは失敗します。
応答タイムアウト内に GWLB がバックエンドサーバーから SYN+ACK パケットを受信した場合、ヘルスチェックは成功します。その後、GWLB は TCP 接続を終了するために RST パケットを送信します。
HTTP ヘルスチェック
HTTP ヘルスチェックは GET プローブを使用してステータス情報を取得します。次の図に示すとおりです。
HTTP ヘルスチェックのプロセスは次のとおりです。
リスナーの構成に基づき、GWLB はバックエンドサーバーのプライベート IP アドレス、ヘルスチェックポート、およびチェックパスに対して HTTP GET リクエストを送信します。リクエストには構成済みのドメイン名が含まれます。
バックエンドサーバーは、自身の運用状況に基づいて HTTP ステータスコードを返します。
指定された応答タイムアウト内に GWLB がバックエンドサーバーから応答を受信しない場合、ヘルスチェックは失敗します。
タイムアウト内に GWLB が応答を受信した場合、返されたステータスコードを期待されるコードと比較します。一致する場合はヘルスチェックが成功し、そうでない場合は失敗します。
ヘルスチェックのタイムウィンドウ
ヘルスチェックはサービス可用性を向上させます。ただし、一時的な障害によって頻繁にフェールオーバーが発生し、システムの安定性が損なわれることを防ぐため、GWLB は指定された回数連続してヘルスチェックに合格または失敗した場合にのみサーバーのステータスを変更します。このプロセスは、ヘルスチェックのタイムウィンドウを定義する次の 3 つの要素によって決定されます。
ヘルスチェック間隔：ヘルスチェックの実行間隔です。
応答タイムアウト：応答を待つ最大時間です。
ヘルスチェックしきい値：サーバーのヘルスステータスを変更するために必要な連続チェック回数です。
ヘルスチェックのタイムウィンドウを計算するには、次の数式を使用します。
異常判定タイムウィンドウ = 応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値 - 1)
正常判定タイムウィンドウ = (正常なヘルスチェックの応答時間 × 正常しきい値) + ヘルスチェック間隔 × (正常しきい値 - 1)
説明正常なヘルスチェックの応答時間とは、ヘルスチェックリクエストの送信から応答の受信までの持続時間です。TCP ヘルスチェックの場合、プローブはポートがアクティブかどうかのみを確認するため、この時間は無視できるほど短くなります。HTTP ヘルスチェックの場合、この時間はアプリケーションサーバーのパフォーマンスや負荷に依存しますが、通常は秒単位です。
ヘルスチェックの状態は、リクエスト転送に次のように影響します。
バックエンドサーバーがヘルスチェックに失敗した場合、新しいリクエストはそれ以上そのサーバーに分散されません。これによりクライアントのアクセスは影響を受けません。
バックエンドサーバーがヘルスチェックに合格した場合、新しいリクエストはそのサーバーに分散されます。クライアントのアクセスは正常に継続されます。
バックエンドサーバーに問題があるものの、まだ異常しきい値に達していない場合、リクエストは引き続きそのサーバーに送信されます。これにより、該当リクエストが失敗する可能性があります。デフォルトでは、異常しきい値は連続 3 回の失敗です。
例：応答タイムアウトとヘルスチェック間隔
次のヘルスチェック設定を想定します。
応答タイムアウト：5 秒
ヘルスチェック間隔：2 秒
正常しきい値：3
異常しきい値：3
異常判定タイムウィンドウ = 応答タイムアウト × 異常しきい値 + ヘルスチェック間隔 × (異常しきい値 - 1) です。この例では、タイムウィンドウは 19 秒です：5 × 3 + 2 × (3 - 1) = 19 秒。ヘルスチェックが 19 秒間失敗し続けると、サーバーの状態は「異常」に変更されます。
次の図は、サーバーの状態が「正常」から「異常」に変化するプロセスを示しています。
正常判定タイムウィンドウ = (正常なヘルスチェックの応答時間 × 正常しきい値) + ヘルスチェック間隔 × (正常しきい値 - 1) です。サーバーの応答時間が 1 秒であると仮定すると、タイムウィンドウは 7 秒です：(1 × 3) + 2 × (3 - 1) = 7 秒。ヘルスチェックが 7 秒間成功し続けると、サーバーの状態は「正常」に変更されます。
次の図は、サーバーの状態が「異常」から「正常」に変化するプロセスを示しています（サーバーのリクエストに対する応答時間が 1 秒であると仮定）。
HTTP ヘルスチェックのドメイン名
HTTP ヘルスチェックを構成する際、ドメイン名の指定はオプションです。ただし、一部のバックエンドサーバーは着信リクエストの host ヘッダーを検証します。ドメイン名を指定した場合、GWLB はヘルスチェックプローブの host ヘッダーにそのドメイン名を含めます。ドメイン名を指定せず、バックエンドサーバーのプライベート IP を使用 を選択した場合、GWLB はサーバーのプライベート IP アドレスとポートを host 値として使用します。バックエンドサーバーがこの値を認識できない場合、リクエストを拒否し、ヘルスチェックが失敗する可能性があります。
したがって、バックエンドサーバーが host ヘッダーを検証する場合は、ヘルスチェックが正しく機能するようにドメイン名を構成する必要があります。