ヘルスチェックのコンセプト

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

概要

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

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

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

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

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

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

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

ほとんどの GCP ロードバランサでは非レガシー ヘルスチェックが要求されますが、ネットワーク負荷分散では HTTP プロトコルを使用するレガシー ヘルスチェックが要求されます。カテゴリとプロトコルの選択、およびポートの指定に関する指針については、ヘルスチェックを選択するを参照してください。

レガシー ヘルスチェックからヘルスチェックへの変換や、その逆方向の変換はできません。

ヘルスチェックという用語は、レガシー ヘルスチェックを指すものではありません。このドキュメントでレガシー ヘルスチェックを指す場合は、明示的に「レガシー ヘルスチェック」と表記します。

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

ヘルスチェックには、ロードバランサの種類、およびロードバランサが使用するバックエンドの種類(インスタンス グループかネットワーク エンドポイント グループか)との互換性が必要です。ヘルスチェックを作成するときは、次の 3 つの要素を指定する必要があります。

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

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

このセクションで使用している「インスタンス グループ」という用語は、アンマネージド インスタンス グループ、ゾーンのマネージド インスタンス グループ、リージョンのマネージド インスタンス グループを指します。

カテゴリとプロトコル

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

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

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

ヘルスチェック カテゴリ サポートされているプロトコル
ヘルスチェック • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
レガシー ヘルスチェック • HTTP
• HTTPS (レガシー HTTPS ヘルスチェックはネットワーク ロードバランサに対応しておらず、他の種類のロードバランサでもほとんど使用できません。)

カテゴリとポート指定

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

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

これ以降では、--use-serving-port フラグは gcloud beta compute health-checks create で実装されていますが、gcloud beta compute health-checks update で実装されていないことに注意してください。

ロードバランサ ガイド

この表を使用して、所定のロードバランサに適切なヘルスチェックのカテゴリとプロトコルを選んでください。

ロードバランサ バックエンド タイプ ヘルスチェックのカテゴリと範囲 ポートの指定
内部 TCP / UDP インスタンス グループ(リージョン内部バックエンド サービス内) ヘルスチェック(グローバル) ポート番号(--port)または名前付きポート(--port-name)。
負荷分散スキームが INTERNAL のバックエンド サービスには関連付けられた名前付きポートがないため、--use-serving-port フラグは使用できません。
内部 HTTP(S) ネットワーク エンドポイント グループ
(バックエンド サービス内)
ヘルスチェック(リージョン) ポート番号(--port)または
--use-serving-port
インスタンス グループ(バックエンド サービス内) ヘルスチェック(リージョン) ポート番号(--port)、名前付きポート(--port-name)、または
--use-serving-port
ネットワーク ターゲット プールを使用するインスタンス グループ レガシー ヘルスチェック(グローバル)
HTTP プロトコルを使用
レガシー ヘルスチェックはポート番号(--port)によるポート指定だけに対応。
TCP プロキシ
SSL プロキシ
HTTP(S) 1
ネットワーク エンドポイント グループ
(バックエンド サービス内)
ヘルスチェック(グローバル) ポート番号(--port)または
--use-serving-port
インスタンス グループ(バックエンド サービス内) ヘルスチェック(グローバル) ポート番号(--port)、名前付きポート(--port-name)、または
--use-serving-port

1 以下のような状況では、HTTP(S) ロードバランサに関連付けられたバックエンド サービスでレガシー ヘルスチェックを使用することはできますが、おすすめはできません。

  • バックエンド サービスが使用するバックエンドはインスタンス グループであり、ネットワーク エンドポイント グループではない。
  • バックエンド VM は HTTPHTTPS のいずれかを使用してプローブできる。

ヘルスチェックの仕組み

プローブ

ヘルスチェックを作成するときやレガシー ヘルスチェックを作成するときは、以下のフラグを指定するか、デフォルト値を使用します。これらのフラグは、GCP ヘルスチェック システムのそれぞれがインスタンス グループや NEG バックエンドをプローブする頻度を制御します。GCP は、複数のシステムを使用してプローブを実装します。

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

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

プローブ IP 範囲

GCP プローブ システムの送信元 IP アドレスは、ロードバランサの種類によって異なります。次の表を使用して、GCP プローブ システムからバックエンドへのトラフィックを許可する、上り許可のファイアウォール ルールを作成します。

ロードバランサ プローブ IP 範囲 ファイアウォール ルールの例
内部
TCP プロキシ
SSL プロキシ
HTTP(S)
内部 HTTP(S)
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
ネットワーク ロードバランサを対象とするファイアウォール ルール

複数のプローブと頻度

GCP では、複数の冗長システムからのヘルスチェック プローブを、適切な送信元 IP 範囲から送信します。すべてのプローブがひとつのプローブ システムから発行されるのではありません。複数のシステムがプローブを同時に発行するため、そのうちひとつが失敗しても GCP がバックエンドの健全性を追跡できなくなることはありません。

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

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

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

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

      1(チェック間隔)

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

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

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

  • ネットワーク ロードバランサの複数の転送ルール: 複数の転送ルールが同じターゲット プールを指すように構成されている場合、GCP は複数のプローブ システムを使用して各 IP アドレスをチェックします。ターゲット プールの各バックエンドに対するプローブ頻度に、構成した転送ルールの数を掛けます。

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

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

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

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

ヘルスチェック パケットの宛先

GCP ヘルスチェック プローブは、各バックエンド インスタンスのプライマリ ネットワーク インターフェースだけにパケットを送信します。これらのパケットの宛先 IP アドレスは、ロードバランサの種類によって異なります。

  • 内部 TCP / UDP ロードバランサとネットワーク ロードバランサの場合、ヘルスチェック パケットの宛先はロードバランサの転送ルールの IP アドレスです。複数の転送ルールが同じバックエンド サービスやターゲット プールを指している場合、GCP は各転送ルールの IP アドレスにプローブを送信します。この結果、前のセクションで説明したように、プローブ数が増加します。
  • HTTP(S)、TCP プロキシ、SSL プロキシ、内部 HTTP(S) のロードバランサが、インスタンス グループをバックエンドとして使用する場合、ヘルスチェック パケットの宛先は、各バックエンド インスタンスのプライマリ ネットワーク インターフェースに関連付けられたプライマリ内部 IP アドレスです。
  • HTTP(S)、TCP プロキシ、SSL プロキシ、内部 HTTP(S) のロードバランサが、ネットワーク エンドポイント グループをバックエンドとして使用する場合、ヘルスチェック パケットの宛先はエンドポイントの IP アドレス(プライマリ IP アドレス、セカンダリ(エイリアス IP)アドレスのいずれか)です。

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

HTTP(S)、HTTP/2、TCP、SSL のヘルスチェックは、必要に応じてコンテンツ ベース(リクエスト / レスポンス)にすることができます。コンテンツ ベースのヘルスチェックでは、ヘルスチェック プローバーはリクエスト文字列をバックエンドに送信します。ヘルスチェックは、プローブに対する特定のレスポンスを待ち受けるように構成されています。

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

HTTP、HTTPS、または HTTP/2 プロトコルを使用するヘルスチェック プローブからのレスポンスが正常終了したとみなされるのは、GCP が送信したリクエストに対して HTTP 200 (OK) のレスポンスを受信し、そのレスポンスがプローブ タイムアウトの前に到着した場合のみです。

リクエストは、構成可能なリクエストパスに送信されます。指定しなければ / に送信されます。コンテンツ ベースのチェックを使用し、待ち受けるレスポンス文字列を指定する場合を除いて、すべてのレスポンスが受け入れられます。HTTP、HTTPS、HTTP/2 ヘルスチェックの正常終了条件の制御に使用できるフラグを以下に示します。

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

コンテンツ ベース ヘルスチェックの使用は省略可能です。待ち受けるレスポンス文字列を指定してもしなくても、GCP はチェック対象のバックエンドからのレスポンスとして HTTP 200 (OK) を待ち受けます。待ち受けるレスポンスを指定すると、各 GCP ヘルスチェック プローバーはバックエンドから返されたレスポンスを検索し、返される最初の 1,024 バイト内で待ち受けるレスポンス文字列を探します。コンテンツ ベースの HTTP ヘルスチェックが正常終了と見なされるのは、HTTP 200 (OK) が受信され、それと同時に返されたレスポンスの最初の 1,024 バイト内で待ち受けるレスポンスが検出された場合です。

SSL と TCP の正常終了の条件

デフォルトでは、SSL または TCP プロトコルを使用したヘルスチェックのプローブからのレスポンスが正常終了したと見なされるのは、GCP が正常に SSL または TCP handshake を完了して、プローブ タイムアウト前にセッションを確立できる場合に限られます。

必要に応じて、handshake を完了するだけでなく、リクエスト文字列と待ち受けるレスポンス文字列を、それぞれ最長 1,024 字の ASCII 文字(シングルバイト)で指定できます。待ち受けるレスポンス文字列が構成されているときは、SSL または TCP handshake が完了し、それと同時に返されたレスポンス文字列が待ち受けるレスポンス文字列と完全一致する場合のみ、GCP はプローブが正常終了したとみなします。SSL プロトコルと TCP プロトコルを使用したヘルスチェックで使用できるリクエスト フラグとレスポンス フラグの組み合わせを以下に示します。

構成フラグ 動作
リクエストとレスポンスのいずれも指定されていない
--request--response のどちらのフラグも指定されていない
TCP または SSL セッションがプローブ タイムアウト前に確立された場合、GCP はプローブが正常終了したとみなします。
リクエストとレスポンスの両方が指定されている
--request--response のどちらのフラグも指定されている
GCP は構成されたリクエスト文字列を送信して、待ち受けるレスポンス文字列を待ちます。TCP または SSL セッションが確立されて、プローブ タイムアウト前に返されたレスポンス文字列が待ち受けるレスポンス文字列と完全一致した場合、プローブは正常終了したと見なされます。
レスポンスだけが指定されている
フラグ --response のみを指定
GCP は待ち受けるレスポンス文字列を待ちます。TCP または SSL セッションが確立されて、プローブ タイムアウト前に返されたレスポンス文字列が待ち受けるレスポンス文字列と完全一致した場合、プローブは正常終了したと見なされます。
負荷分散対象のバックエンドがレスポンス文字列を handshake の一環として自動的に送信する場合のみ、--response を単独で使用してください。
リクエストだけが指定されている
フラグ: --request のみを指定
構成されたリクエスト文字列を GCP が送信します。TCP または SSL セッションがプローブ タイムアウト前に確立された場合、プローブは正常終了したと見なされます。レスポンスが存在してもチェックされません。

健全性

GCP は以下の構成フラグと、プローブが正常終了したかどうかを使用して、負荷分散対象の各バックエンドの全体的な健全性を判断します。

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

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

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

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

次のステップ

ヘルスチェックの構成について、ヘルスチェックの作成を確認する。