ヘルスチェックの概要

Google Cloud では、バックエンドがトラフィックに応答しているかどうかをヘルスチェックで判断します。このドキュメントでは、Google Cloud ロードバランサと Traffic Director のヘルスチェックのコンセプトについて説明します。

ヘルスチェックは、定期的な間隔でバックエンドに接続します(この間隔は構成可能です)。接続を試みることをプローブと言います。Google Cloud は、各プローブの成功または失敗を記録します。

プローブが連続して成功または失敗した回数に基づいて、各バックエンドについて全体的な健全性を計算します(このしきい値もユーザーが個別に構成できます)。成功応答の回数が構成済みの回数に達すると、バックエンドは正常と判定されます。応答に失敗した回数がしきい値(個別に構成可能)に達すると、バックエンドは正常ではないと判定されます。

各バックエンドの全体的な健全性により、新しいリクエストまたは接続の受信が可能であるかどうかを判定します。プローブの正常終了を定義する条件を構成できます。詳細については、ヘルスチェックの仕組みのセクションで説明します。

ヘルスチェックでは、Virtual Private Cloud(VPC)ネットワークで定義されていない特別なルートが使用されます。詳細については、ロードバランサのリターンパスをご覧ください。

ヘルスチェックのカテゴリ、プロトコル、ポート

ヘルスチェックにはカテゴリとプロトコルがあります。2 つのカテゴリは、ヘルスチェックとレガシー ヘルスチェックです。サポートされているプロトコルは次のとおりです。

プロトコルとポートにより、ヘルスチェック プローブの実行方法が決まります。たとえば、ヘルスチェックでは TCP ポート 80 で HTTP プロトコルを使用できます。また、インスタンス グループ内の名前付きポートに TCP プロトコルを使用することもできます。

レガシー ヘルスチェックをヘルスチェックに変換することはできません。また、ヘルスチェックをレガシー ヘルスチェックに変換することもできません。

ヘルスチェックを選択する

ヘルスチェックは、ロードバランサの種類(または Traffic Director)とバックエンドの種類に対応している必要があります。ヘルスチェックを選択する際には、次のことを考慮する必要があります。

  • カテゴリ: ヘルスチェックかレガシー ヘルスチェックか。
  • プロトコル: Google Cloud がバックエンドの調査に使用するプロトコル。
  • ポート指定: Google Cloud がプロトコルで使用するポート。

ロードバランサとバックエンドの種類ごとに有効なヘルスチェックについては、ロードバランサ ガイドをご覧ください。ヘルスチェックの概要については、ヘルスチェック機能の表をご覧ください。

カテゴリとプロトコル

ロードバランサと同じプロトコルを使用することがベスト プラクティスですが、これは必須ではなく、常に可能であるとは限りません。

たとえば、ターゲット プールベースのネットワーク ロードバランサでは TCP または UDP がサポートされていますが、ターゲット プールベースのネットワーク ロードバランサで必要なのは、レガシー ヘルスチェックが HTTP プロトコルを使用しているということです。ターゲット プールベースのネットワーク ロードバランサでは、HTTP サーバーを仮想マシン(VM)のインスタンス上で稼働させてヘルスチェック プローブに応答できるようにする必要があります。

他のすべてのロードバランサ タイプでは、プロトコルがロードバランサのバックエンド サービスのプロトコルと一致する非レガシー ヘルスチェックを使用する必要があります

カテゴリとポート指定

ヘルスチェック用のポートを指定する必要があります。ヘルスチェックには 2 つのポート指定方法(--port--use-serving-port)があります。レガシー ヘルスチェックの場合は 1 つ(--port)です。

ロードバランサ ガイド

次の表に、ロードバランサとバックエンド タイプごとにサポートされているカテゴリ、スコープ、ポート指定を示します。

ロードバランサ バックエンド タイプ ヘルスチェックのカテゴリと範囲 ポートの指定
グローバル外部 HTTP(S) ロードバランサ

グローバル外部 HTTP(S) ロードバランサ(従来) 1

外部 TCP プロキシ ロードバランサ

外部 SSL プロキシ ロード バランサ
サポートされている NEG ヘルスチェック(グローバル
  • カスタムポート番号(--port
  • エンドポイントのポート番号(--use-serving-port
インスタンス グループ ヘルスチェック(グローバル
  • カスタムポート番号(--port
  • バックエンド サービスの名前付きポート(--use-serving-port
リージョン外部 HTTP(S) ロードバランサ サポートされている NEG ヘルスチェック(リージョン
  • カスタムポート番号(--port
  • エンドポイントのポート番号(--use-serving-port
インスタンス グループ ヘルスチェック(リージョン
  • カスタムポート番号(--port
  • バックエンド サービスの名前付きポート(--use-serving-port
内部 HTTP(S) ロードバランサ
内部リージョン TCP プロキシ ロードバランサ
サポートされている NEG ヘルスチェック(リージョン
  • カスタムポート番号(--port
  • エンドポイントのポート番号(--use-serving-port
インスタンス グループ ヘルスチェック(リージョン
  • カスタムポート番号(--port
  • バックエンド サービスの名前付きポート(--use-serving-port
ネットワーク ロードバランサ 2 インスタンス グループ ヘルスチェック(リージョン
  • カスタムポート番号(--port
ターゲット プールのインスタンス
レガシー ヘルスチェック
HTTP プロトコルを使用するグローバル
レガシー ヘルスチェックは、ポート番号(--port)の指定のみをサポートします。
内部 TCP / UDP ロードバランサ 2 サポートされている NEG ヘルスチェック(グローバルまたはリージョン
  • カスタムポート番号(--port
インスタンス グループ ヘルスチェック(グローバルまたはリージョン
  • カスタムポート番号(--port

1 外部 HTTP(S) ロードバランサの場合、レガシー ヘルスチェックは推奨されませんが、ロードバランサのモードによってはサポートされる場合があります。

ロードバランサ モード レガシー ヘルスチェックをサポート
グローバル外部 HTTP(S) ロードバランサ ×
リージョン外部 HTTP(S) ロードバランサ ×
外部 HTTP(S) ロードバランサ ○(次のいずれかに該当する場合)
  • バックエンドがインスタンス グループである。
  • バックエンド VM が HTTP または HTTPS プロトコルを使用するトラフィックを処理する。

2 内部 TCP / UDP ロードバランサと外部 TCP / UDP ネットワーク ロードバランサで使用されるバックエンド サービスは、どの名前付きポートにも登録しないため、--use-serving-port フラグは使用できません。また、内部 TCP / UDP ロードバランサは、ポート情報がない GCE_VM_IP エンドポイントを含むゾーン NEG のみをサポートします。

ヘルスチェックの仕組み

以降のセクションでは、ヘルスチェックの仕組みについて説明します。

プローブ

ヘルスチェックを作成するときやレガシー ヘルスチェックを作成するときは、以下のフラグを指定するか、デフォルト値を使用します。作成するヘルスチェックまたはレガシー ヘルスチェックは、複数のプローブによって実装されます。これらのフラグは、各プローブがインスタンス グループ内のインスタンス、またはゾーン NEG のエンドポイントを評価する頻度を制御します。

ヘルスチェックの設定をバックエンドごとに構成することはできません。ヘルスチェックは、バックエンド サービス全体に関連付けられます。ターゲット プールベースのネットワーク負荷分散では、レガシー HTTP ヘルスチェックがターゲット プール全体に関連付けられます。したがって、プローブのパラメータは、特定のバックエンド サービスまたはターゲット プールによって参照されるすべてのバックエンドで同じです。

構成フラグ 目的 デフォルト値
チェック間隔
check-interval
チェック間隔は、あるプローバーから発行された 1 回のプローブ開始から、同じプローバーから発行された次の回のプローブ開始までの時間です。単位は秒です。 5s(5 秒)
タイムアウト
timeout
タイムアウトは、Google Cloud がプローブに対するレスポンスを待つ時間です。この値は、チェック間隔に設定した数値以下にしてください。単位は秒です。 5s(5 秒)

プローブ IP 範囲とファイアウォール ルール

ヘルスチェックを機能させるには、Google Cloud プローバーからのトラフィックをバックエンドに接続できるように、上り(内向き)allow ファイアウォール ルールを作成する必要があります。

次の表に、許可するソース IP の範囲を示します。

プロダクト プローブのソース IP の範囲 ファイアウォール ルールの例
  • グローバル外部 HTTP(S) ロードバランサ
  • グローバル外部 HTTP(S) ロードバランサ(従来)
  • リージョン外部 HTTP(S) ロードバランサ
  • 内部 HTTP(S) ロード バランシング
  • 内部 TCP / UDP ロード バランシング
  • 外部 SSL プロキシ ロード バランシング
  • 外部 TCP プロキシ ロード バランシング
  • Traffic Director
  • 35.191.0.0/16
  • 130.211.0.0/22
ネットワーク ロードバランサを除くすべてのプロダクトを対象とするファイアウォール ルール
ネットワーク ロード バランシング

バックエンドへの IPv4 トラフィックの場合:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

バックエンドへの IPv6 トラフィックの場合:

  • 2600:1901:8001::/48

ターゲット プールベースのネットワーク ロードバランサは IPv4 トラフィックのみをサポートし、メタデータ サーバーを介してヘルスチェックをプロキシする場合があります。この場合、ヘルスチェック パケットのソースはメタデータ サーバーの IP アドレス 169.254.169.254 と一致します。

ネットワーク ロードバランサを対象とするファイアウォール ルール

ファイアウォール ルールの重要性

Google Cloud では、必要な上り(内向き)allow ファイアウォール ルールを作成し、プローバーからバックエンドへのトラフィックを許可する必要があります。これらのルールは、ヘルスチェックで使用されているプロトコルとポートのみに制限することをおすすめします。ソース IP 範囲については、前のセクションで一覧表示しているプローブ IP 範囲を必ず使用してください。

ヘルスチェックを許可する上り(内向き)allow ファイアウォール ルールがない場合、暗黙の deny ルールによって受信トラフィックがブロックされます。プローバーがバックエンドと接続できない場合、ロードバランサはバックエンドを正常ではないとみなします。すべてのバックエンドが正常でない場合の動作は、ロードバランサの種類によって異なります。

  • すべてのバックエンドが正常でない場合、グローバル外部 HTTP(S) ロードバランサ(従来)は HTTP 502 レスポンスをクライアントに返します。

  • すべてのバックエンドが正常でない場合、グローバル外部 HTTP(S) ロードバランサ、リージョン外部 HTTP(S) ロードバランサ、内部 HTTP(S) ロードバランサは HTTP 503 レスポンスをクライアントに返します。

  • すべてのバックエンドが正常でない場合、外部 SSL プロキシ ロードバランサと外部 TCP プロキシ ロードバランサはタイムアウトします。

  • 内部リージョン TCP プロキシ ロードバランサは、すべてのバックエンドが正常でない場合に TCP RST パケットを送信して、クライアント接続を終了します。

  • すべてのバックエンドが正常ではなく、フェイルオーバーが構成されていない場合、最後の手段として、内部 TCP / UDP ロードバランサとバックエンド サービスベースのネットワーク ロードバランサが、すべてのバックエンド VM にトラフィックを分散します。この動作の詳細については、内部 TCP / UDP ロードバランサのトラフィック分散と、バックエンド サービスベースのネットワーク ロードバランサのトラフィック分散をご覧ください。

  • すべてのバックエンドが正常でない場合、ターゲット プールベースのネットワーク ロードバランサは、最後の手段として、すべてのバックエンド VM にトラフィックを分散します。

プローブ IP 範囲のセキュリティに関する考慮事項

ヘルスチェックと必要なファイアウォール ルールを計画する際は、次の点を考慮してください。

  • プローブの IP 範囲は Google に属します。Google Cloud では、VPC ネットワークの外部(Google の本番環境ネットワーク内)の特別なルートを使用して、プローバーからの通信を円滑にします。

  • Google では、プローブ IP 範囲を使用して外部 HTTP(S) ロードバランサ、外部 SSL プロキシ ロードバランサ、外部 TCP プロキシ ロードバランサのヘルスチェック プローブを送信します。パケットがインターネットから受信され、パケットの送信元 IP アドレスがプローブ IP 範囲内にある場合、パケットは破棄されます。これには、Compute Engine インスタンスまたは Google Kubernetes Engine(GKE)ノードの外部 IP アドレスが含まれます。

  • プローブ IP 範囲には、Google Cloud プローバーで使用される可能性のあるすべての IP アドレスをリストします。tcpdump などのツールを使用している場合、プローブ IP 範囲に含まれる IP アドレスの中には、トラフィックの送信を確認できないアドレスが存在する可能性があります。すべてのプローブ IP 範囲を送信元として許可する上り(内向き)ファイアウォール ルールを作成することをおすすめします。Google Cloud では、新しいプローバーを通知なしで自動的に実装できます。

複数のプローブと頻度

Google Cloud では、プローバーと呼ばれる複数の冗長システムからヘルスチェック プローブを送信します。プローバーは、特定のソース IP 範囲を使用します。Google Cloud は、ヘルスチェックの実装に 1 つのプローバーのみを使用するのではなく、複数のプローバーで、インスタンス グループ バックエンド内のインスタンスやゾーン NEG バックエンド内のエンドポイントを同時に評価します。1 つのプローバーに障害が発生すると、Google Cloud はバックエンドの状態を引き続き追跡します。

ヘルスチェックに構成する間隔とタイムアウトの設定は、各プローバーに適用されます。バックエンドのソフトウェア アクセスログや tcpdump を見ると、そのバックエンドに設定した間隔に基づく頻度よりプローブの数が多いことがわかります。

これは予期される動作であって、Google Cloud がヘルスチェックに使用するプローバーの数をユーザーが構成することはできません。ただし、次の要素を検討することにより、複数の同時プローブの影響を概算することはできます。

  • バックエンド サービスあたりのプローブ頻度を概算するには、以下について検討してください。

    • バックエンド サービスあたりの基本頻度。各ヘルスチェックに関連付けられているチェック頻度は、構成されたチェック間隔に反比例しています。

      1(チェック間隔)

      バックエンド サービスにヘルスチェックを関連付けると、そのバックエンド サービスのバックエンドに対して各プローバーが使用する基本頻度が確定します。

    • プローブ スケール係数。バックエンド サービスの基本頻度に、Google Cloud が使用する同時プローバーの数を掛けます。この数は変動しますが、通常は 5~10 です。

  • 内部 TCP / UDP ロードバランサの複数の転送ルール。複数の内部転送ルール(それぞれの IP アドレスが異なる)が同じリージョンの内部バックエンド サービスを指すように構成されている場合、Google Cloud では複数のプローバーを使用して、各 IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成した転送ルールの数を掛けます。

  • ネットワーク ロードバランサの複数の転送ルール。同じバックエンド サービスまたはターゲット プールを指す複数の転送ルールを構成する場合、Google Cloud は複数のプローバーを使用して各 IP アドレスをチェックします。バックエンド VM あたりのプローブ頻度に、構成した転送ルールの数を乗算します。

  • 外部 HTTP(S) ロードバランサの複数のターゲット プロキシ。同じ URL マップにトラフィックを転送する複数のターゲット プロキシがある場合、Google Cloud は複数のプローバーを使用して、各ターゲット プロキシに関連付けられた IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成したターゲット プロキシの数を掛けます。

  • 外部 SSL プロキシ ロードバランサ、外部 TCP プロキシ ロードバランサ、内部リージョン TCP プロキシ ロードバランサに対する複数のターゲット プロキシ。同じバックエンド サービスにトラフィックを転送する複数のターゲット プロキシを構成している場合、Google Cloud は複数のプローバーを使用して、各ターゲット プロキシに関連付けられた IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成したターゲット プロキシの数を掛けます。

  • バックエンド サービスの合計。1 つのバックエンドが複数のバックエンド サービスによって使用されている場合、そのバックエンド インスタンスへの接続頻度は、各バックエンド サービスのヘルスチェック頻度の合計と同じになります。

    ゾーン NEG バックエンドでは、正確なヘルスチェック プローブ数を調べるのがより難しくなります。たとえば、同じエンドポイントが複数のゾーン NEG に存在している場合があります。これらの NEG のエンドポイント セットが必ずしも同じとは限らず、異なるエンドポイントが同じバックエンドを指していることもあります。

プローブ パケットの宛先

次の表に、ヘルスチェック プローバーがパケットを送信するネットワーク インターフェースと宛先 IP アドレスをロードバランサの種類別に示します。

ネットワーク ロードバランサと内部 TCP / UDP ロードバランサの場合、アプリケーションはロードバランサの IP アドレス(または任意の IP アドレス 0.0.0.0)にバインドする必要があります。

ロードバランサ 宛先ネットワーク インターフェース 宛先 IP アドレス
  • グローバル外部 HTTP(S) ロードバランサ
  • グローバル外部 HTTP(S) ロードバランサ(従来)
  • リージョン外部 HTTP(S) ロードバランサ
  • 内部 HTTP(S) ロードバランサ
  • 外部 SSL プロキシ ロードバランサ
  • 外部 TCP プロキシ ロードバランサ
  • 内部リージョン TCP プロキシ ロードバランサ(プレビュー
  • Traffic Director
プライマリ ネットワーク インターフェース(nic0
  • インスタンス グループ バックエンドの場合、各インスタンスのプライマリ ネットワーク インターフェース(nic0)に関連付けられたプライマリ内部 IP アドレス。
  • ゾーン NEG バックエンドの場合、エンドポイントの IP アドレス。これは、プライマリ内部 IP アドレスか、エンドポイントをホストしているインスタンスのプライマリ ネットワーク インターフェース nic0 のエイリアス IP 範囲です。
ネットワーク ロードバランサ プライマリ ネットワーク インターフェース(nic0 外部転送ルールの IP アドレス。

複数の転送ルールが同じバックエンド サービスを指している場合(ターゲット プールベースのネットワーク負荷分散の場合、同じターゲット プールを指している場合)、Google Cloud は各転送ルールの IP アドレスにプローブを送信します。これにより、プローブの数が増加する可能性があります。
内部 TCP / UDP ロードバランサ 内部バックエンド サービス用に指定されたネットワーク内のインスタンスのネットワーク インターフェース。指定しない場合、プライマリ ネットワーク インターフェース(nic0)が使用されます。

詳細については、バックエンド サービスとネットワーク インターフェースをご覧ください。
内部転送ルールの IP アドレス。

複数の転送ルールが同じバックエンド サービスを指している場合、Google Cloud は各転送ルールの IP アドレスにプローブを送信します。これにより、プローブの数が増加する可能性があります。

HTTP、HTTPS、HTTP/2 の正常終了の条件

ヘルスチェックで HTTP、HTTPS、または HTTP/2 プロトコルを使用する場合、各プローブでは HTTP 200 (OK) レスポンス コードがプローブ タイムアウトの前に配信される必要があります。また、次の操作が可能です。

  • HTTP リクエストを特定のリクエストパスに送信するように Google Cloud プローバーを構成できます。リクエストパスを指定しない場合は、/ が使用されます。

  • 想定されるレスポンス文字列を指定して、コンテンツ ベースのヘルスチェックを構成した場合、Google Cloud では、HTTP レスポンス本文の最初の 1,024 バイト内で想定される文字列が検出されます。

HTTP、HTTPS、HTTP/2 プロトコルを使用したヘルスチェックで使用できるリクエストパスとレスポンス文字列フラグの組み合わせを以下に示します。

構成フラグ 成功基準
リクエストパス
request-path
Google Cloud によるヘルスチェック プローブ リクエストの送信先となる URL パスを指定します。
省略した場合、Google Cloud ではプローブ リクエストがルートパス / に送信されます。
レスポンス
response
オプションのレスポンス フラグを使用すると、コンテンツ ベースのヘルスチェックを構成できます。待ち受けるレスポンス文字列は 1,024 字以下の ASCII(シングルバイト)文字にする必要があります。構成した場合、Google Cloud は、HTTP 200 (OK) ステータスの受信に加え、レスポンスの最初の 1,024 バイト内でこの文字列を待ち受けます。

SSL と TCP の正常終了の条件

待ち受けるレスポンス文字列を指定しない限り、SSL プロトコルと TCP プロトコルを使用したヘルスチェックのプローブは、次の両方の基本条件が true の場合に正常に完了します。

  • 各 Google Cloud プローバーは、構成されたプローブ タイムアウト前に、SSL handshake または TCP handshake を正常に完了できます。
  • TCP ヘルスチェックの場合、次のいずれかによって TCP セッションが正常に終了します。
    • バックエンド
    • プローバーとの TCP セッションの確立時に TCP RST(リセット)パケットを送信する Google Cloud プローバー

バックエンドが TCP RST(リセット)パケットを送信し、TCP ヘルスチェックの TCP セッションを閉じた場合、プローブが正常に完了したとはみなされない可能性があります。これは、Google Cloud プローバーがすでに適切な TCP 終端処理を開始している場合に発生します。

リクエスト文字列と待ち受けるレスポンス文字列、それぞれ最大 1,024 字の ASCII 文字(シングルバイト)を指定すると、コンテンツ ベースのヘルスチェックを作成できます。待ち受けるレスポンス文字列が構成されているときは、基本の条件が満たされ、かつ待ち受けるレスポンス文字列と返されたレスポンス文字列が完全一致する場合にのみ、Google Cloud ではプローブが正常終了したとみなされます。

SSL プロトコルと TCP プロトコルを使用したヘルスチェックで使用できるリクエスト フラグとレスポンス フラグの組み合わせを以下に示します。

構成フラグ 成功基準
リクエストとレスポンスのいずれも指定されていません。

--request--response のいずれのフラグも指定されていません。
基本の条件が満たされると、Google Cloud ではプローブが正常に完了したとみなされます。
リクエストとレスポンスの両方が指定されています。

--request--response の両方のフラグが指定されました。
Google Cloud は構成されたリクエスト文字列を送信して、待ち受けるレスポンス文字列を待ちます。基本の条件が満たされ、かつ待ち受けるレスポンス文字列と返されたレスポンス文字列が完全一致する場合にのみ、Google Cloud ではプローブが正常終了したとみなされます。
指定されたレスポンスのみ

指定されたフラグ: --response のみ
Google Cloud は待ち受けるレスポンス文字列を待機します。基本の条件が満たされ、かつ待ち受けるレスポンス文字列と返されたレスポンス文字列が完全一致する場合にのみ、プローブが正常終了したとみなされます。

バックエンドがレスポンス文字列を TCP handshake または SSL handshake の一環として自動的に送信する場合のみ、--response を単独で使用してください。
指定されたリクエストのみ

指定されたフラグ: --request のみ
Google Cloud では、基本の条件が満たされると、構成したリクエスト文字列が送信され、プローブが正常に完了したとみなされます。レスポンスが存在してもチェックされません。

gRPC の成功基準

gRPC ヘルスチェックを使用している場合は、ステータスが OK、ステータス フィールドが SERVING または NOT_SERVING に設定された RPC レスポンスを gRPC サービスが送信するように設定します。

次の点にご注意ください。

  • gRPC ヘルスチェックは、gRPC アプリケーションと Traffic Director でのみ使用されます。
  • gRPC ヘルスチェックは TLS をサポートしていません。

詳しくは以下をご覧ください。

健全性

Google Cloud は、以下の構成フラグを使用して、トラフィックの負荷分散の対象であるバックエンドの全体的な健全性を判断します。

構成フラグ 目的 デフォルト値
正常しきい値
healthy-threshold
正常しきい値は、バックエンドが正常であると判定する際に要求されるプローブ結果成功の連続回数を指定します。 2 つのプローブのしきい値。
異常しきい値
unhealthy-threshold
異常しきい値は、バックエンドが異常であると判定する際に要求されるプローブ結果失敗の連続回数を指定します。 2 つのプローブのしきい値。

この正常しきい値に達すると、Google Cloud はバックエンドを正常であるとみなします。正常なバックエンドは新しい接続の受信に適格であるとされます。

異常しきい値に達すると、Google Cloud はバックエンドが正常ではないとみなします。正常でないバックエンドは新しい接続を受信に不適格とされます。ただし、既存の接続がすぐに終了することはありません。すぐに終了するのではなく、タイムアウトが発生するか、トラフィックが破棄されるまで、その接続は開かれたままで保持されます。動作の詳細は、使用するロードバランサの種類に応じて異なります。

プローブ失敗の原因によっては、既存の接続がレスポンスを返せない場合があります。正常でないバックエンドが、正常しきい値を再び満たすことができると、正常に復帰できます。

その他の情報

コンテンツ ベースのヘルスチェック

コンテンツ ベースのヘルスチェックとは、待ち受けるレスポンス文字列の評価によって成功基準が決まるものです。コンテンツ ベースのヘルスチェックを使用して、Google Cloud のヘルスチェック プローブでバックエンドのレスポンスをより完全に検証します。

  • HTTP、HTTPS、または HTTP/2 コンテンツ ベースのヘルスチェックを構成するには、待ち受けるレスポンス文字列を指定し、必要に応じてリクエストパスを定義します。詳細については、HTTP、HTTPS、HTTP/2 での成功基準をご覧ください。

  • SSL または TCP コンテンツ ベースのヘルスチェックを構成するには、待ち受けるレスポンス文字列を指定し、必要に応じてリクエスト文字列を定義します。詳細については、SSL と TCP での成功基準をご覧ください。

証明書とヘルスチェック

Google Cloud ヘルスチェック プローバーでは、バックエンドで証明書を使用する必要があるプロトコル(SSL、HTTPS、HTTP/2)でも、証明書の検証は行われません。たとえば、次のようになります。

  • 自己署名証明書または任意の認証局(CA)が署名した証明書を使用できます。
  • 有効期限が切れている、またはまだ有効ではない証明書も許可されます。
  • CN 属性と subjectAlternativeName 属性はどちらも、Host ヘッダーまたは DNS PTR レコードに一致する必要はありません。

ヘッダー

任意のプロトコルを使用するヘルスチェック(従来のヘルスチェック以外)では、--proxy-header フラグを使用してプロキシ ヘッダーを設定できます。

HTTP、HTTPS、または HTTP/2 プロトコルを使用するヘルスチェックおよび従来のヘルスチェックでは、--host フラグを使用して HTTP Host ヘッダーを指定できます。

ヘルスチェックの例

次の設定でヘルスチェックを設定するとします。

  • 間隔: 30 秒
  • タイムアウト: 5 秒
  • プロトコル: HTTP
  • 異常しきい値: 2(デフォルト)
  • 正常しきい値: 2(デフォルト)

これらの設定では、ヘルスチェックは次のように動作します。

  1. ヘルスチェック パラメータを使用して複数の冗長システムが同時に構成されます。間隔とタイムアウトの設定は、各システムに適用されます。詳細については、複数のプローブと頻度をご覧ください。
  2. 各ヘルスチェック プローバーは、次の処理を行います。

    1. ソース IP アドレスの 1 つからバックエンド インスタンスへの HTTP 接続を、30 秒ごとに開始します。
    2. HTTP 200 (OK) レスポンス コードを最大 5 秒間待ちます(HTTP、HTTPS、HTTP/2 プロトコルでの成功基準)。
  3. 少なくとも 1 つのヘルスチェック プローブ システムが次の処理を行う場合、バックエンドは異常とみなされます。

    1. 連続で 2 つのプローブの HTTP 200 (OK) レスポンス コードを受信しない。たとえば、接続が拒否される、または接続やソケットのタイムアウトが発生する。
    2. プロトコル固有の成功基準に一致しないレスポンスを連続で 2 つ受信する。
  4. 少なくとも 1 つのヘルスチェック プローブ システムが、プロトコル固有の成功基準に一致するレスポンスを連続で 2 つ受信した場合、バックエンドは正常とみなされます。

この例では、各プローバーは 30 秒ごとに接続を開始します。タイムアウトの時間にかかわらず(接続がタイムアウトしたかどうかにかかわらず)、プローバーの接続試行の間隔は 30 秒です。つまり、タイムアウトは常にその間隔以下であることが必要で、タイムアウトにより間隔が引き延ばされることはありません。

この例では、各プローバーのタイミングは、次のように秒単位で表されます。

  1. t=0: プローブ A を開始します。
  2. t=5: プローブ A を停止します。
  3. t=30: プローブ B を開始します。
  4. t=35: プローブ B を停止します。
  5. t=60: プローブ C を開始します。
  6. t=65: プローブ C を停止します。

次のステップ