Google Cloud では、Google Cloud ロードバランサのバックエンド、Cloud Service Mesh のバックエンド 、マネージド インスタンス グループのアプリケーション ベースの自動修復に構成可能なヘルスチェックを利用できます。このドキュメントでは、ヘルスチェックの主なコンセプトについて説明します。
特に明記されていない限り、Google Cloud ヘルスチェックは、ヘルスチェック リソースで指定されたパラメータに従ってバックエンドに接続する専用のソフトウェア タスクによって実装されます。接続を試みることをプローブと言います。Google Cloud は、各プローブの成功または失敗を記録します。
プローブが連続して成功または失敗した回数に基づいて、各バックエンドについて全体的な健全性を計算します（このしきい値もユーザーが個別に構成できます）。正常応答の回数が設定値に達した場合、バックエンドは正常であると判定され、応答に失敗した回数がしきい値（個別に構成可能）に達すると、バックエンドは正常ではないと判定されます。
各バックエンドの全体的な健全性により、新しいリクエストまたは接続の受信が可能であるかどうかを判定します。プローブの正常終了を定義する条件を設定できます。詳細については、ヘルスチェックの仕組みのセクションで説明します。
専用のソフトウェア タスクによって実装されるヘルスチェックは、Virtual Private Cloud（VPC）ネットワークで定義されていない特別なルートを使用します。詳細については、ヘルスチェックのパスをご覧ください。
ヘルスチェックのカテゴリ、プロトコル、ポート
ヘルスチェックにはカテゴリとプロトコルがあります。2 つのカテゴリは、ヘルスチェックとレガシー ヘルスチェックです。サポートされているプロトコルは次のとおりです。
ヘルスチェック
レガシー ヘルスチェック
プロトコルとポートにより、ヘルスチェック プローブの実行方法が決まります。たとえば、ヘルスチェックでは TCP ポート 80 で HTTP プロトコルを使用できます。また、インスタンス グループ内の名前付きポートに TCP プロトコルを使用することもできます。
レガシー ヘルスチェックをヘルスチェックに変換することはできません。また、ヘルスチェックをレガシー ヘルスチェックに変換することもできません。
ヘルスチェックを選択する
ヘルスチェックは、ロードバランサの種類 （または Cloud Service Mesh） とバックエンドの種類に対応している必要があります。ヘルスチェックを選択する際には、次のことを考慮する必要があります。
- カテゴリ: ヘルスチェックかレガシー ヘルスチェックか。レガシー ヘルスチェックが必要になるのは、ターゲット プールベースの外部パススルー ネットワーク ロードバランサのみです。他のすべてのプロダクトでは、定期的なヘルスチェックを使用します。
- プロトコル: Google Cloud がバックエンドの調査に使用するプロトコル。ロードバランサのバックエンド サービスまたはターゲット プールで使用されるプロトコルとプロトコルが一致するヘルスチェック（またはレガシー ヘルスチェック）を使用するのがおすすめの方法です。ただし、ヘルスチェック プロトコルとロードバランサ プロトコルは同じである必要はありません。
- ポート指定: Google Cloud がプロトコルで使用するポート。ヘルスチェック用のポートを指定する必要があります。ヘルスチェックのポート指定には、2 つの方法があります（
--portと--use-serving-port）。レガシー ヘルスチェックの場合、方法は 1 つです（--port）。ロードバランサあたりのヘルスチェック ポートの要件の詳細については、ポート仕様フラグをご覧ください。
次のセクションでは、ロードバランサとバックエンドのタイプごとに有効なヘルスチェックについて説明します。
ロードバランサ ガイド
次の表に、各ロードバランサ タイプでサポートされているヘルスチェックのカテゴリとスコープを示します。
| ロードバランサ | ヘルスチェックのカテゴリと範囲 |
|---|---|
|
グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ * グローバル外部プロキシ ネットワーク ロードバランサ 従来のプロキシ ネットワーク ロードバランサ クロスリージョン内部アプリケーション ロードバランサ クロスリージョン内部プロキシ ネットワーク ロードバランサ |
ヘルスチェック（グローバル） |
|
リージョン外部アプリケーション ロードバランサ リージョン内部アプリケーション ロードバランサ リージョン内部プロキシ ネットワーク ロードバランサ リージョン外部プロキシ ネットワーク ロードバランサ |
ヘルスチェック（リージョン） |
| 外部パススルー ネットワーク ロードバランサ | バックエンド サービスベースのロードバランサ: ヘルスチェック（リージョン） ターゲット プールベースのロードバランサ: レガシー ヘルスチェック |
| 内部パススルー ネットワーク ロードバランサ | ヘルスチェック（グローバルまたはリージョン） |
| ロードバランサ モード | レガシー ヘルスチェックをサポート |
|---|---|
グローバル外部アプリケーション ロードバランサ 従来のアプリケーション ロードバランサ |
○（次のいずれかに該当する場合）
|
| リージョン外部アプリケーション ロードバランサ | × |
その他の使用上の注意
VM インスタンス グループのバックエンドの場合、ヘルスチェックは、起動している VM インスタンスに対してのみ実行されます。停止した VM インスタンスはヘルスチェック パケットを受信しません。
内部パススルー ネットワーク ロードバランサの場合、バックエンド サービスのプロトコルに
TCPまたはUDPのみを使用できます。内部パススルー ネットワーク ロードバランサの背後で VM からの HTTP トラフィックを処理する場合、HTTP プロトコルを使用したヘルスチェックを採用したほうが有益です。ターゲット プールベースの外部パススルー ネットワーク ロードバランサでは、レガシー HTTP ヘルスチェックを使用する必要があります。レガシー HTTPS ヘルスチェックや非レガシー ヘルスチェックは使用できません。ターゲット プールベースの外部パススルー ネットワーク ロードバランサを使用して TCP トラフィックを分散する場合は、ロードバランスする VM で HTTP サービスを実行して、ヘルスチェック プローブに応答できるようにする必要があります。
その他のほとんどすべてのロードバランサ タイプでは、プロトコルがロードバランサのバックエンド サービスのプロトコルと一致する非レガシー ヘルスチェックを使用する必要があります。gRPC プロトコルを使用するバックエンド サービスの場合、gRPC ヘルスチェックまたは TCP ヘルスチェックのみを使用します。HTTP(S) ヘルスチェックや HTTP/2 ヘルスチェックは使用しないでください。
ハイブリッド NEG バックエンドを使用する Envoy ベースの特定のロードバランサは、gRPC ヘルスチェックをサポートしていません。詳細については、ハイブリッド NEG の概要をご覧ください。
Cloud Service Mesh によるヘルスチェック
Cloud Service Mesh でヘルスチェックを使用する場合の動作の違いに注意してください。
Cloud Service Mesh では、
INTERNET_FQDN_PORTタイプとNON_GCP_PRIVATE_IP_PORTタイプのネットワーク エンドポイントのヘルスチェックは、他のタイプのネットワーク エンドポイントのヘルスチェックと動作が異なります。Cloud Service Mesh は、専用のソフトウェア タスクを使用する代わりに、インターネット NEG（INTERNET_FQDN_PORTエンドポイント）とハイブリッド NEG（NON_GCP_PRIVATE_IP_PORTエンドポイント）のヘルスチェックを実行するように Envoy プロキシをプログラムします。Envoy は、ヘルスチェック用に次のプロトコルをサポートしています。
- HTTP
- HTTPS
- HTTP/2
- TCP
Cloud Service Mesh が Service Directory と統合されていて、Service Directory サービスを Cloud Service Mesh のバックエンド サービスにバインドする場合は、バックエンド サービスにヘルスチェックを設定することはできません。
ヘルスチェックの仕組み
以降のセクションでは、ヘルスチェックの仕組みについて説明します。
プローブ
ヘルスチェックを作成するときやレガシー ヘルスチェックを作成するときは、以下のフラグを指定するか、デフォルト値を使用します。作成するヘルスチェックまたはレガシー ヘルスチェックは、複数のプローブによって実装されます。これらのフラグは、各プローブがインスタンス グループ内のインスタンス、またはゾーン NEG のエンドポイントを評価する頻度を制御します。
ヘルスチェックの設定をバックエンドごとに構成することはできません。ヘルスチェックは、バックエンド サービス全体に関連付けられます。ターゲット プールベースの外部パススルー ネットワーク ロードバランサでは、レガシー HTTP ヘルスチェックがターゲット プール全体に関連付けられます。したがって、プローブのパラメータは、特定のバックエンド サービスまたはターゲット プールによって参照されるすべてのバックエンドで同じです。
| 構成フラグ | 目的 | デフォルト値 |
|---|---|---|
チェック間隔check-interval |
チェック間隔は、あるプローバーから発行された 1 回のプローブ開始から、同じプローバーから発行された次の回のプローブ開始までの時間です。単位は秒です。 | 5s（5 秒） |
タイムアウトtimeout |
タイムアウトは、Google Cloud がプローブに対するレスポンスを待つ時間です。この値は、チェック間隔に設定した数値以下にしてください。単位は秒です。 | 5s（5 秒） |
プローブ IP 範囲とファイアウォール ルール
ヘルスチェックを機能させるには、Google Cloud プローバーからのトラフィックをバックエンドに接続できるように、上り（内向き）allow ファイアウォール ルールを作成する必要があります。手順については、必要なファイアウォール ルールを作成するをご覧ください。
次の表に、各ロードバランサで許可するソース IP の範囲を示します。
| プロダクト | ヘルスチェック プローブのソース IP の範囲 |
|---|---|
|
バックエンドへの IPv6 トラフィックの場合:
|
バックエンドへの IPv6 トラフィックの場合:
|
|
|
|
| 外部パススルー ネットワーク ロードバランサ 3 |
バックエンドへの IPv4 トラフィックの場合:
バックエンドへの IPv6 トラフィックの場合:
|
| 内部パススルー ネットワーク ロードバランサ |
バックエンドへの IPv4 トラフィックの場合:
バックエンドへの IPv6 トラフィックの場合:
|
| インターネット NEG バックエンドとハイブリッド NEG バックエンドを使用する Cloud Service Mesh | Envoy ソフトウェアを実行している VM の IP アドレス 構成例については、Cloud Service Mesh のドキュメントをご覧ください。 |
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) レスポンス コードを受信する必要があります。301 や 302 などのリダイレクト レスポンス コードを含む、他のすべての HTTP レスポンス コードは異常と見なされます。
HTTP 200 (OK) レスポンス コードを必須にすることに加え、次のこともできます。
デフォルトのリクエストパス
/ではなく、特定のリクエストパスに HTTP リクエストを送信するように各ヘルスチェック プローバーを構成します。HTTP レスポンス本文に想定されるレスポンス文字列が存在するかどうかを確認するように、各ヘルスチェック プローバーを構成します。想定されるレスポンス文字列は、HTTP レスポンス本文の最初の 1,024 バイト内に存在する、シングルバイトの印刷可能な ASCII 文字のみで構成する必要があります。
次の表に、HTTP、HTTPS、HTTP/2 のヘルスチェックで使用できるリクエストパスとレスポンス フラグの有効な組み合わせを示します。
| 構成フラグ | プロバーの動作 | 成功基準 |
|---|---|---|
--request-path も --response も指定されていません |
プロバーは、リクエストパスとして / を使用します。 |
HTTP 200 (OK) レスポンス コードのみ。 |
--request-path と --response の両方が指定されている |
プロバーは、構成されたリクエストパスを使用します。 | HTTP 200 (OK) レスポンス コードと、HTTP レスポンス本文の最初の 1,024 バイトまでの ASCII 文字は、想定されるレスポンス文字列と一致する必要があります。 |
--response のみが指定されている
|
プロバーは、リクエストパスとして / を使用します。 |
HTTP 200 (OK) レスポンス コードと、HTTP レスポンス本文の最初の 1,024 バイトまでの ASCII 文字は、想定されるレスポンス文字列と一致する必要があります。 |
--request-path のみが指定されている |
プロバーは、構成されたリクエストパスを使用します。 | HTTP 200 (OK) レスポンス コードのみ。 |
SSL と TCP の正常終了の条件
TCP ヘルスチェックと SSL ヘルスチェックの基本的な成功基準は次のとおりです。
TCP ヘルスチェックの場合、ヘルスチェック プローバーは、ヘルスチェックのタイムアウト前にバックエンドへの TCP 接続を正常に開く必要があります。
SSL ヘルスチェックの場合、ヘルスチェック プローバーは、ヘルスチェックのタイムアウト前にバックエンドへの TCP 接続を正常に開き、TLS/SSL handshake を完了する必要があります。
TCP ヘルスチェックの場合、TCP 接続は次のいずれかの方法で閉じる必要があります。
- ヘルスチェック プローバーが FIN または RST（リセット）パケットを送信する。
- バックエンドが FIN パケットを送信します。バックエンドが TCP RST パケットを送信した場合、ヘルスチェック プローバーが FIN パケットをすでに送信している場合、プローブが正常に完了したとはみなされない可能性があります。
次の表に、TCP と SSL のヘルスチェックで使用できるリクエスト フラグとレスポンス フラグの有効な組み合わせを示します。リクエスト フラグとレスポンス フラグの両方は、シングルバイトの印刷可能な ASCII 文字のみで構成する必要があります。各文字列の長さは 1,024 文字以下にする必要があります。
| 構成フラグ | プロバーの動作 | 成功基準 |
|---|---|---|
--request も --response も指定されていません
|
プロバーはリクエスト文字列を送信しません。 | 基本的な成功基準のみ。 |
--request と --response の両方が指定されている |
プロバーは、構成されたリクエスト文字列を送信します。 | 基本の成功基準とプロバーが受信したレスポンス文字列は、想定されるレスポンス文字列と完全に一致している必要があります。 |
--response のみが指定されている |
プロバーはリクエスト文字列を送信しません。 | 基本の成功基準とプロバーが受信したレスポンス文字列は、想定されるレスポンス文字列と完全に一致している必要があります。 |
--request のみが指定されている
|
プロバーは、構成されたリクエスト文字列を送信します。 | 基本的な成功基準のみ（レスポンス文字列はチェックされません）。 |
gRPC の成功基準
gRPC ヘルスチェックを使用している場合は、ステータスが OK、ステータス フィールドが SERVING または NOT_SERVING に設定された RPC レスポンスを gRPC サービスが送信するように設定します。
次の点にご注意ください。
- gRPC ヘルスチェックは、gRPC アプリケーションと Cloud Service Mesh でのみ使用されます。
- 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 ヘルスチェック プローバーでは、バックエンドで証明書を使用する必要があるプロトコル（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 を停止します。
次のステップ
- ヘルスチェックを作成、変更、使用するには、ヘルスチェックを作成するをご覧ください。
- ヘルスチェックのトラブルシューティングを行うには、ヘルスチェックのロギングを有効にします。