Google Cloud では、Google Cloud ロードバランサのバックエンドと Traffic Director のバックエンドに対する構成可能なヘルスチェック、マネージド インスタンス グループのアプリケーション ベースの自動修復を利用できます。このドキュメントでは、ヘルスチェックの主なコンセプトについて説明します。
特に明記されていない限り、Google Cloud ヘルスチェックは、ヘルスチェック リソースで指定されたパラメータに従ってバックエンドに接続する専用のソフトウェア タスクによって実装されます。接続を試みることをプローブといいます。Google Cloud は、各プローブの成功または失敗を記録します。
プローブが連続して成功または失敗した回数に基づいて、各バックエンドについて全体的な健全性を計算します（このしきい値もユーザーが個別に構成できます）。成功応答の回数が構成済みの回数に達すると、バックエンドは正常と判定されます。応答に失敗した回数がしきい値（個別に構成可能）に達すると、バックエンドは正常ではないと判定されます。
各バックエンドの全体的な健全性により、新しいリクエストまたは接続の受信が可能であるかどうかを判定します。プローブの正常終了を定義する条件を構成できます。詳細については、ヘルスチェックの仕組みのセクションで説明します。
専用のソフトウェア タスクによって実装されるヘルスチェックは、Virtual Private Cloud（VPC）ネットワークで定義されていない特別なルートを使用します。詳細については、ロードバランサのリターンパスをご覧ください。
ヘルスチェックのカテゴリ、プロトコル、ポート
ヘルスチェックにはカテゴリとプロトコルがあります。2 つのカテゴリは、ヘルスチェックとレガシー ヘルスチェックです。サポートされているプロトコルは次のとおりです。
ヘルスチェック
レガシー ヘルスチェック:
プロトコルとポートにより、ヘルスチェック プローブの実行方法が決まります。たとえば、ヘルスチェックでは TCP ポート 80 で HTTP プロトコルを使用できます。また、インスタンス グループ内の名前付きポートに TCP プロトコルを使用することもできます。
レガシー ヘルスチェックをヘルスチェックに変換することはできません。また、ヘルスチェックをレガシー ヘルスチェックに変換することもできません。
ヘルスチェックを選択する
ヘルスチェックは、ロードバランサの種類（または Traffic Director）とバックエンドの種類に対応している必要があります。ヘルスチェックを選択する際には、次のことを考慮する必要があります。
- カテゴリ: ヘルスチェックかレガシー ヘルスチェックか。レガシー ヘルスチェックが必要になるのは、ターゲット プールベースの外部パススルー ネットワーク ロードバランサのみです。他のすべてのプロダクトでは、定期的なヘルスチェックを使用します。
- プロトコル: Google Cloud がバックエンドの調査に使用するプロトコル。ロードバランサのバックエンド サービスまたはターゲット プールで使用されるプロトコルとプロトコルが一致するヘルスチェック（またはレガシー ヘルスチェック）を使用するのがおすすめの方法です。ただし、ヘルスチェック プロトコルとロードバランサ プロトコルは同じである必要はありません。
- ポート指定: Google Cloud がプロトコルで使用するポート。ヘルスチェック用のポートを指定する必要があります。ヘルスチェックのポート指定には、2 つの方法があります（
--portと--use-serving-port）。レガシー ヘルスチェックの場合、方法は 1 つです（--port）。
次のセクションでは、ロードバランサとバックエンドのタイプごとに有効なヘルスチェックについて説明します。
ロードバランサ ガイド
次の表に、ロードバランサとバックエンド タイプごとにサポートされているカテゴリ、スコープ、ポート指定を示します。
| ロードバランサ | バックエンド タイプ | ヘルスチェックのカテゴリと範囲 | ポートの指定 |
|---|---|---|---|
|
グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ 1 グローバル外部プロキシ ネットワーク ロードバランサ 従来のプロキシ ネットワーク ロードバランサ |
サポートされている NEG | ヘルスチェック（グローバル） |
|
| インスタンス グループ | ヘルスチェック（グローバル） |
|
|
| リージョン外部アプリケーション ロードバランサ | サポートされている NEG | ヘルスチェック（リージョン） |
|
| インスタンス グループ | ヘルスチェック（リージョン） |
|
|
|
クロスリージョン内部アプリケーション ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ |
サポートされている NEG | ヘルスチェック（グローバル） |
|
| インスタンス グループ | ヘルスチェック（グローバル） |
|
|
|
リージョン内部アプリケーション ロードバランサ リージョン内部プロキシ ネットワーク ロードバランサ リージョン外部プロキシ ネットワーク ロードバランサ |
サポートされている NEG | ヘルスチェック（リージョン） |
|
| インスタンス グループ | ヘルスチェック（リージョン） |
|
|
| 外部パススルー ネットワーク ロードバランサ2 | インスタンス グループ | ヘルスチェック（リージョン） |
|
| ターゲット プールのインスタンス |
レガシー ヘルスチェック （HTTP プロトコルを使用するグローバル） |
レガシー ヘルスチェックは、ポート番号（--port）の指定のみをサポートします。 |
|
| 内部パススルー ネットワーク ロードバランサ2 | サポートされている NEG | ヘルスチェック（グローバルまたはリージョン） |
|
| インスタンス グループ | ヘルスチェック（グローバルまたはリージョン） |
|
| ロードバランサ モード | レガシー ヘルスチェックをサポート |
|---|---|
グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ |
○（次のいずれかに該当する場合）
|
| リージョン外部アプリケーション ロードバランサ | × |
--use-serving-port フラグは使用できません。また、内部パススルー ネットワーク ロードバランサは、ポート情報がない GCE_VM_IP エンドポイントを含むゾーン NEG のみをサポートします。その他の使用上の注意
内部パススルー ネットワーク ロードバランサの場合、バックエンド サービスのプロトコルに
TCPまたはUDPのみを使用できます。内部パススルー ネットワーク ロードバランサの背後で VM からの HTTP トラフィックを処理する場合、HTTP プロトコルを使用したヘルスチェックを採用したほうが有益です。ターゲット プールベースの外部パススルー ネットワーク ロードバランサでは、レガシー HTTP ヘルスチェックを使用する必要があります。レガシー HTTPS ヘルスチェックや非レガシー ヘルスチェックは使用できません。ターゲット プールベースの外部パススルー ネットワーク ロードバランサを使用して TCP トラフィックを分散する場合は、ロードバランスする VM で HTTP サービスを実行して、ヘルスチェック プローブに応答できるようにする必要があります。
その他のほとんどすべてのロードバランサ タイプでは、プロトコルがロードバランサのバックエンド サービスのプロトコルと一致する非レガシー ヘルスチェックを使用する必要があります。gRPC プロトコルを使用するバックエンド サービスの場合、gRPC ヘルスチェックまたは TCP ヘルスチェックのみを使用します。HTTP(S) ヘルスチェックや HTTP/2 ヘルスチェックは使用しないでください。
ハイブリッド NEG バックエンドを使用する Envoy ベースの特定のロードバランサは、gRPC ヘルスチェックをサポートしていません。詳細については、ハイブリッド NEG の概要をご覧ください。
Traffic Director によるヘルスチェック
Traffic Director でヘルスチェックを使用する場合の動作の違いに注意してください。
Traffic Director では、
INTERNET_FQDN_PORTタイプとNON_GCP_PRIVATE_IP_PORTタイプのネットワーク エンドポイントのヘルスチェックは、他のタイプのネットワーク エンドポイントのヘルスチェックと動作が異なります。Traffic Director は、専用のソフトウェア タスクを使用する代わりに、インターネット NEG（INTERNET_FQDN_PORTエンドポイント）とハイブリッド NEG（NON_GCP_PRIVATE_IP_PORTエンドポイント）のヘルスチェックを実行するように Envoy プロキシをプログラムします。Envoy は、ヘルスチェック用に次のプロトコルをサポートしています。
- HTTP
- HTTPS
- HTTP/2
- TCP
Traffic Director が Service Directory と統合されていて、Service Directory サービスを Traffic Director のバックエンド サービスにバインドする場合は、バックエンド サービスにヘルスチェックを設定することはできません。
ヘルスチェックの仕組み
以降のセクションでは、ヘルスチェックの仕組みについて説明します。
プローブ
ヘルスチェックを作成するときやレガシー ヘルスチェックを作成するときは、以下のフラグを指定するか、デフォルト値を使用します。作成するヘルスチェックまたはレガシー ヘルスチェックは、複数のプローブによって実装されます。これらのフラグは、各プローブがインスタンス グループ内のインスタンス、またはゾーン NEG のエンドポイントを評価する頻度を制御します。
ヘルスチェックの設定をバックエンドごとに構成することはできません。ヘルスチェックは、バックエンド サービス全体に関連付けられます。ターゲット プールベースの外部パススルー ネットワーク ロードバランサでは、レガシー HTTP ヘルスチェックがターゲット プール全体に関連付けられます。したがって、プローブのパラメータは、特定のバックエンド サービスまたはターゲット プールによって参照されるすべてのバックエンドで同じです。
| 構成フラグ | 目的 | デフォルト値 |
|---|---|---|
チェック間隔check-interval |
チェック間隔は、あるプローバーから発行された 1 回のプローブ開始から、同じプローバーから発行された次の回のプローブ開始までの時間です。単位は秒です。 | 5s（5 秒） |
タイムアウトtimeout |
タイムアウトは、Google Cloud がプローブに対するレスポンスを待つ時間です。この値は、チェック間隔に設定した数値以下にしてください。単位は秒です。 | 5s（5 秒） |
プローブ IP 範囲とファイアウォール ルール
ヘルスチェックを機能させるには、Google Cloud プローバーからのトラフィックをバックエンドに接続できるように、上り（内向き）allow ファイアウォール ルールを作成する必要があります。
次の表に、許可するソース IP の範囲を示します。
| プロダクト | プローブのソース IP の範囲 | ファイアウォール ルールの例 |
|---|---|---|
|
|
外部パススルー ネットワーク ロードバランサを除くすべてのプロダクトを対象とするファイアウォール ルール |
| 外部パススルー ネットワーク ロードバランサ |
バックエンドへの IPv4 トラフィックの場合:
バックエンドへの IPv6 トラフィックの場合:
|
外部パススルー ネットワーク ロードバランサのファイアウォール ルール |
| 内部パススルー ネットワーク ロードバランサ |
バックエンドへの IPv4 トラフィックの場合:
バックエンドへの IPv6 トラフィックの場合:
|
内部パススルー ネットワーク ロードバランサのファイアウォール ルール |
| インターネット NEG バックエンドとハイブリッド NEG バックエンドを使用する Traffic Director | Envoy ソフトウェアを実行している VM の IP アドレス | ファイアウォール ルールの例 |
1 ハイブリッド NEG では、Google のヘルスチェック プローブ範囲を許可リストに登録する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲を許可リストに登録する必要があります。
2 リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: 下り（外向き）に Cloud NAT を使用するをご覧ください。
3 ターゲット プールベースの外部パススルー ネットワーク ロードバランサは IPv4 トラフィックのみをサポートし、メタデータ サーバーを介してヘルスチェックをプロキシする場合があります。この場合、ヘルスチェック プローブの送信元はメタデータ サーバーの IP アドレス 169.254.169.254 と一致します。メタデータ サーバーからのトラフィックを許可するファイアウォール ルールを作成する必要はありません。メタデータ サーバーからのパケットは常に許可されます。
ファイアウォール ルールの重要性
Google Cloud では、必要な上り（内向き）allow ファイアウォール ルールを作成し、プローバーからバックエンドへのトラフィックを許可する必要があります。これらのルールは、ヘルスチェックで使用されているプロトコルとポートのみに制限することをおすすめします。ソース IP 範囲については、前のセクションで一覧表示しているプローブ IP 範囲を必ず使用してください。
ヘルスチェックを許可する上り（内向き）allow ファイアウォール ルールがない場合、暗黙の deny ルールによってインバウンド トラフィックがブロックされます。プローバーがバックエンドと接続できない場合、ロードバランサはバックエンドを正常ではないとみなします。
プローブ IP 範囲のセキュリティに関する考慮事項
ヘルスチェックと必要なファイアウォール ルールを計画する際は、次の点を考慮してください。
プローブの IP 範囲は Google に属します。Google Cloud では、VPC ネットワークの外部（Google の本番環境ネットワーク内）の特別なルートを使用して、プローバーからの通信を円滑にします。
Google では、プローブ IP 範囲を使用して、外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサのヘルスチェック プローブを送信します。パケットがインターネットから受信され、パケットの送信元 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 です。
内部パススルー ネットワーク ロードバランサの複数の転送ルール。複数の内部転送ルール（それぞれの IP アドレスが異なる）が同じリージョンの内部バックエンド サービスを指すように構成されている場合、Google Cloud では複数のプローバーを使用して、各 IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成した転送ルールの数を掛けます。
外部パススルー ネットワーク ロードバランサの複数の転送ルール。同じバックエンド サービスまたはターゲット プールを指す複数の転送ルールを構成する場合、Google Cloud は複数のプローバーを使用して各 IP アドレスをチェックします。バックエンド VM あたりのプローブ頻度に、構成した転送ルールの数を乗算します。
外部アプリケーション ロードバランサの複数のターゲット プロキシ。同じ URL マップにトラフィックを転送する複数のターゲット プロキシがある場合、Google Cloud は複数のプローバーを使用して、各ターゲット プロキシに関連付けられた IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成したターゲット プロキシの数を掛けます。
外部プロキシ ネットワーク ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサの複数のターゲット プロキシ。同じバックエンド サービスにトラフィックを転送する複数のターゲット プロキシを構成している場合、Google Cloud は複数のプローバーを使用して、各ターゲット プロキシに関連付けられた IP アドレスをチェックします。バックエンド サービスあたりのプローブ頻度に、構成したターゲット プロキシの数を掛けます。
バックエンド サービスの合計。1 つのバックエンドが複数のバックエンド サービスによって使用されている場合、そのバックエンド インスタンスへの接続頻度は、各バックエンド サービスのヘルスチェック頻度の合計と同じになります。
ゾーン NEG バックエンドでは、正確なヘルスチェック プローブ数を調べるのがより難しくなります。たとえば、同じエンドポイントが複数のゾーン NEG に存在している場合があります。これらの NEG のエンドポイント セットが必ずしも同じとは限らず、異なるエンドポイントが同じバックエンドを指していることもあります。
プローブ パケットの宛先
次の表に、ヘルスチェック プローバーがパケットを送信するネットワーク インターフェースと宛先 IP アドレスをロードバランサの種類別に示します。
外部パススルー ネットワーク ロードバランサと内部パススルー ネットワーク ロードバランサの場合、アプリケーションは、ロードバランサの IP アドレス（または任意の IP アドレス 0.0.0.0）にバインドする必要があります。
| ロードバランサ | 宛先ネットワーク インターフェース | 宛先 IP アドレス |
|---|---|---|
|
|
|
| 外部パススルー ネットワーク ロードバランサ | プライマリ ネットワーク インターフェース（nic0） |
外部転送ルールの IP アドレス。 複数の転送ルールが同じバックエンド サービスを指している場合（ターゲット プールベースの外部パススルー ネットワーク ロードバランサの場合、同じターゲット プールを指している場合）、Google Cloud は各転送ルールの IP アドレスにプローブを送信します。これにより、プローブの数が増加する可能性があります。 |
| 内部パススルー ネットワーク ロードバランサ | GCE_VM_IP エンドポイントを使用したインスタンス グループ バックエンドとゾーン NEG バックエンドのどちらの場合も、使用されるネットワーク インターフェースはバックエンド サービスの構成方法によって異なります。詳細については、バックエンド サービスとネットワーク インターフェースをご覧ください。 |
内部転送ルールの 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 をサポートしていません。
詳しくは以下をご覧ください。
レガシー ヘルスチェックの成功基準
レガシー ヘルスチェック プローブから受け取ったレスポンスが HTTP 200 OK の場合、プローブは正常であると判断されます。リダイレクト（301、302）を含む、その他すべての HTTP レスポンス コードは異常と見なされます。
健全性
Google Cloud は、以下の構成フラグを使用して、トラフィックの負荷分散の対象であるバックエンドの全体的な健全性を判断します。
| 構成フラグ | 目的 | デフォルト値 |
|---|---|---|
正常しきい値healthy-threshold |
正常しきい値は、バックエンドが正常であると判定する際に要求されるプローブ結果成功の連続回数を指定します。 | 2 つのプローブのしきい値。 |
異常しきい値unhealthy-threshold |
異常しきい値は、バックエンドが異常であると判定する際に要求されるプローブ結果失敗の連続回数を指定します。 | 2 つのプローブのしきい値。 |
この正常しきい値に達すると、Google Cloud はバックエンドを正常であるとみなします。正常なバックエンドは新しい接続の受信に適格であるとされます。
異常しきい値に達すると、Google Cloud はバックエンドが正常ではないとみなします。正常でないバックエンドは新しい接続を受信に不適格とされます。ただし、既存の接続がすぐに終了することはありません。すぐに終了するのではなく、タイムアウトが発生するか、トラフィックが破棄されるまで、その接続は開かれたままで保持されます。
プローブ失敗の原因によっては、既存の接続がレスポンスを返せない場合があります。正常でないバックエンドが、正常しきい値を再び満たすことができると、正常に復帰できます。
すべてのバックエンドが異常な場合の具体的な動作は、使用しているロードバランサの種類によって異なります。
| ロードバランサ | すべてのバックエンドが異常な場合の動作 |
|---|---|
| 従来のアプリケーション ロードバランサ | すべてのバックエンドが正常でない場合、クライアントに HTTP 502 ステータス コードを返します。 |
| グローバル外部アプリケーション ロードバランサ リージョン外部アプリケーション ロードバランサ 内部アプリケーション ロードバランサ |
すべてのバックエンドが正常でない場合は、HTTP 503 ステータス コードをクライアントに返します。 |
| プロキシ ネットワーク ロードバランサ | すべてのバックエンドが正常でない場合は、クライアント接続を終了します。 |
| 内部パススルー ネットワーク ロードバランサと、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ | すべてのバックエンドが正常ではなく、フェイルオーバーが構成されていない場合の最後の手段として、すべてのバックエンド VM にトラフィックを分散します。 この動作の詳細については、内部パススルー ネットワーク ロードバランサのトラフィック分散と、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサのトラフィック分散をご覧ください。 |
| ターゲット プールベースの外部パススルー ネットワーク ロードバランサ | すべてのバックエンドが正常でない場合の最後の手段として、すべてのバックエンド VM にトラフィックを分散します。 |
その他の情報
以降のセクションでは、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（デフォルト）
これらの設定では、ヘルスチェックは次のように動作します。
- ヘルスチェック パラメータを使用して複数の冗長システムが同時に構成されます。間隔とタイムアウトの設定は、各システムに適用されます。詳細については、複数のプローブと頻度をご覧ください。
各ヘルスチェック プローバーは、次の処理を行います。
- ソース IP アドレスの 1 つからバックエンド インスタンスへの HTTP 接続を、30 秒ごとに開始します。
- HTTP
200 (OK)ステータス コードを最大 5 秒間待ちます（HTTP、HTTPS、HTTP/2 プロトコルでの成功基準）。
少なくとも 1 つのヘルスチェック プローブ システムが次の処理を行う場合、バックエンドは異常とみなされます。
- 連続で 2 つのプローブの
HTTP 200 (OK)レスポンス コードを受信しない。たとえば、接続が拒否される、または接続やソケットのタイムアウトが発生する。 - プロトコル固有の成功基準に一致しないレスポンスを連続で 2 つ受信する。
- 連続で 2 つのプローブの
少なくとも 1 つのヘルスチェック プローブ システムが、プロトコル固有の成功基準に一致するレスポンスを連続で 2 つ受信した場合、バックエンドは正常とみなされます。
この例では、各プローバーは 30 秒ごとに接続を開始します。タイムアウトの時間にかかわらず（接続がタイムアウトしたかどうかにかかわらず）、プローバーの接続試行の間隔は 30 秒です。つまり、タイムアウトは常にその間隔以下であることが必要で、タイムアウトにより間隔が引き延ばされることはありません。
この例では、各プローバーのタイミングは、次のように秒単位で表されます。
- t=0: プローブ A を開始します。
- t=5: プローブ A を停止します。
- t=30: プローブ B を開始します。
- t=35: プローブ B を停止します。
- t=60: プローブ C を開始します。
- t=65: プローブ C を停止します。
次のステップ
- ヘルスチェックを作成、変更、使用するには、ヘルスチェックを作成するをご覧ください。
- ヘルスチェックのトラブルシューティングを行うには、ヘルスチェックのロギングを有効にします。