ヘルスチェックの概要

Google Cloud には、インスタンス グループやゾーン ネットワーク エンドポイント グループ(NEG)などのバックエンドがトラフィックに適切に処理しているかどうかを調べるヘルスチェック メカニズムがあります。このドキュメントでは、Google Cloud ロードバランサと Traffic Director に固有のヘルスチェックのコンセプトについて説明します。

Google Cloud が提供しているヘルスチェックは、グローバルまたはリージョン ベースで実施されるシステムで、ユーザーはバックエンドへの接続頻度を構成できます。接続を試みることをプローブ、ヘルスチェック システムをプローバーといいます。Google Cloud は、各プローブの成功または失敗を記録します。

ヘルスチェックは、ロードバランサまたは Traffic Director と連携して行われます。プローブが連続して正常終了または失敗した回数に基づいて、Google Cloud はロードバランサまたは Traffic Director の各バックエンドについて全体的な健全性を計算します(このしきい値もユーザーが個別に構成できます)。正常応答の回数が構成値に達した場合、バックエンドは正常であると判定され、同様に、応答に失敗した回数が設定したしきい値に達した場合、バックエンドは正常ではないと判定されます

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

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

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

Google Cloud では、ヘルスチェックがカテゴリとプロトコル別にまとめられています。

2 つのカテゴリは、ヘルスチェックとレガシー ヘルスチェックです。それぞれのカテゴリで、対応するプロトコル セットと、ヘルスチェックに使用するポートの指定方法が異なります。プロトコルとポートによって、Google Cloud ヘルスチェック システムがバックエンドにどのような接続を試みるかが決まります。たとえば、TCP ポート 80 で HTTP プロトコルを使用するヘルスチェックを作成できます。あるいは、インスタンス グループで構成された名前付きポートに対して TCP プロトコルを使用するヘルスチェックを作成することもできます。

Traffic Director と大半の Google Cloud ロードバランサには非レガシー ヘルスチェックが必要ですが、ネットワーク負荷分散では HTTP プロトコルを使用するレガシー ヘルスチェックが必要になります。カテゴリ、プロトコル、ポートの選択方法については、次のヘルスチェックを選択するをご覧ください。

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

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

ヘルスチェックは、Traffic Director またはロードバランサの種類、プロダクトが使用するバックエンドの種類(インスタンス グループまたはゾーン NEG)に対応している必要があります。ヘルスチェックを作成する場合は、次の 3 要素を指定する必要があります。

  • カテゴリ: ヘルスチェックかレガシー ヘルスチェックか。ロードバランサと互換性のあるものを選択する必要があります。
  • プロトコル: Google Cloud システムがバックエンドを定期的にプローブする際に使用するプロトコルを定義します。
  • ポート指定: ヘルスチェックのプロトコルに使用されるポートを定義します。

このセクションの最後のガイドでは、所定のタイプのロードバランサとバックエンドの種類に基づいて、ヘルスチェックのカテゴリ、プロトコル、ポート指定の有効な組み合わせをまとめています。

各種のロードバランサでサポートされるヘルスチェックの種類については、ヘルスチェックをご覧ください。

カテゴリとプロトコル

ロードバランサの種類とロードバランサが使用するバックエンドの種類によって、ヘルスチェックのカテゴリが決まります。ネットワーク負荷分散では、HTTP プロトコルを使用するレガシー ヘルスチェックが必要です。他の種類のロードバランサはすべて、通常のヘルスチェックを使用します。

プロトコルは、ヘルスチェックの各カテゴリがサポートするプロトコルのリストから選択する必要があります。ロードバランサと同じプロトコルを使用するのがベスト プラクティスですが、これは必須ではなく、常に可能であるとは限りません。たとえば、ネットワーク負荷分散では TCP と UDP が一般的にサポートされていますが、ネットワーク ロードバランサで必要になるのは、バランサのプロトコルに関係なく HTTP プロトコルを使用するレガシー ヘルスチェックです。そのため、ネットワーク ロードバランサでは、HTTP サーバーを仮想マシン(VM)インスタンス上で稼働させてヘルスチェック プローブに応答できるようにする必要があります。

次の表に、各カテゴリでサポートされているヘルスチェックのカテゴリとプロトコルを示します。

ヘルスチェック カテゴリ サポートされているプロトコル
ヘルスチェック • gRPC
• HTTP
• HTTPS
• HTTP/2(TLS を使用)
• SSL
• TCP
レガシー ヘルスチェック • HTTP
• HTTPS

レガシー HTTPS ヘルスチェックはネットワーク ロードバランサに対応しておらず、他の種類のロードバランサでもほとんど使用できません。

カテゴリとポート指定

ヘルスチェックには、プロトコルだけでなく、ポート指定も選択する必要があります。ヘルスチェックには 3 つ、レガシー ヘルスチェックには 1 つのポート指定方法があります。ロードバランサの種類によっては、利用できないポート指定方法もあります。ロードバランサの種類とロードバランサが使用するバックエンドの種類によって、使用できるポート指定方法が決まります。

ヘルスチェック カテゴリ ポートの指定方法と意味
ヘルスチェック --port: TCP ポート番号を指定します。
--use-serving-port:
• インスタンス グループの場合は、バックエンド サービスで使用されている名前付きポートを使用します。
• ゾーン NEG の場合は、各エンドポイントで定義されたポートを使用します。
レガシー ヘルスチェック --port: TCP ポート番号を指定します。

ロードバランサ ガイド

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

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

TCP プロキシ負荷分散

SSL プロキシ負荷分散
ゾーン NEG ヘルスチェック(グローバル)
  • カスタムポート番号(--port
  • エンドポイントのポート番号(--use-serving-port
インスタンス グループ ヘルスチェック(グローバル)
  • カスタムポート番号(--port
  • バックエンド サービスの名前付きポート(--use-serving-port

1 内部バックエンド サービスには名前付きポートが関連付けられていないため、--use-serving-port フラグは使用できません。
2 以下のような状況では、外部 HTTP(S) ロードバランサに関連付けられたバックエンド サービスでレガシー ヘルスチェックを使用することはできますが、おすすめしません。

  • バックエンドはインスタンス グループであり、ゾーン NEG ではありません。
  • バックエンド VM は、HTTP または HTTPS プロトコルを使用するトラフィックを処理します。

ヘルスチェックの仕組み

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

プローブ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • フェイル オーバーが構成されていない内部 TCP / UDP ロードバランサは、すべてのバックエンド VM が正常でない場合に、最後の手段としてすべての VM に対してトラフィックを分散します。フェイル オーバーを有効にすると、この動作を無効にできます

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

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

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

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

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

複数のプローブと頻度

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 アドレスをチェックします。ターゲット プールの各インスタンスで検出されるプローブ頻度に、構成した転送ルールの数を掛けます。

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

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

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

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

プローブ パケットの宛先

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

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

ロードバランサ 宛先ネットワーク インターフェース 宛先 IP アドレス
内部 TCP / UDP 負荷分散 内部バックエンド サービス用に指定されたネットワーク内のインスタンスのネットワーク インターフェース。指定しない場合、プライマリ ネットワーク インターフェース(nic0)が使用されます。

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

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

複数の転送ルールが同じターゲット プールを指している場合、Google Cloud は各転送ルールの IP アドレスにプローブを送信します。これにより、プローブの数が増加する可能性があります。
外部 HTTP(S) 負荷分散

内部 HTTP(S) 負荷分散

SSL プロキシ負荷分散

TCP プロキシ負荷分散

プライマリ ネットワーク インターフェース(nic0
  • インスタンス グループ バックエンドの場合、各インスタンスのプライマリ ネットワーク インターフェース(nic0)に関連付けられたプライマリ内部 IP アドレス。
  • ゾーン NEG バックエンドの場合、エンドポイントの IP アドレス。これは、プライマリ内部 IP アドレス、または(エンドポイントをホストしているインスタンスのプライマリ ネットワーク インターフェース nic0 の)エイリアス IP 範囲です。

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

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

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

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

  • 待ち受けるレスポンス文字列を構成すると、各 Google Cloud ヘルスチェック プローブでは、バックエンドからの実際のレスポンスの最初の 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 セッションがバックエンドまたは Google Cloud プローバーにより正常に終了するか、バックエンドが、プローバーへの TCP セッションの確立中に TCP RST(リセット)パケットを送信します。

Google Cloud プローバーが適切な TCP 終端処理を開始した後、バックエンドが TCP RST(リセット)パケットを送信し、TCP ヘルスチェックの 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 ドキュメントをご覧ください。

健全性

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

構成フラグ 目的 デフォルト値
正常しきい値
healthy-threshold
正常しきい値は、バックエンドが正常であると判定する際に要求されるプローブ結果成功の連続回数を指定します。 省略した場合、Google Cloud は 2 プローブのしきい値を使用します。
異常しきい値
unhealthy-threshold
異常しきい値は、バックエンドが異常であると判定する際に要求されるプローブ結果失敗の連続回数を指定します。 省略した場合、Google Cloud は 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 を停止します。

次のステップ