内部 TCP / UDP ロードバランサは、Andromeda ネットワークの仮想化スタック上に構築されたリージョン ロードバランサです。
内部 TCP / UDP ロードバランサは、Virtual Private Cloud（VPC）ネットワークの同じリージョンに存在する内部仮想マシン（VM）インスタンス間でトラフィックを分散します。これにより、同じ VPC ネットワークのシステムまたは VPC ネットワークに接続しているシステムのみがアクセス可能な内部 IP アドレスの背後でサービスを実行し、スケーリングできます。
内部 TCP / UDP ロードバランサには、フロントエンド（転送ルール）とバックエンド（バックエンド サービス）があります。バックエンド サービスのバックエンドとしてインスタンス グループまたは GCE_VM_IP ゾーン NEG を使用できます。この例は、インスタンス グループのバックエンドを示しています。
Google Cloud の各種ロードバランサの違いについては、次のドキュメントをご覧ください。
ユースケース
内部 TCP / UDP ロードバランサは、次のような状況で使用します。
- TCP または UDP トラフィック用に、高パフォーマンスのパススルー レイヤ 4 ロードバランサが必要な場合。
TLS（SSL）を介してトラフィックを処理する場合は、ロードバランサの代わりにバックエンドによって SSL トラフィックを終端させることもできます。内部 TCP / UDP ロードバランサは、SSL トラフィックを終端させることはできません。
プロキシを経由せずに元のパケットを転送する必要がある場合。たとえば、クライアントの送信元 IP アドレスを保持する必要がある場合が該当します。
既存の環境でパススルー ロードバランサを使用していて、これを変更せずに移行する場合。
内部 TCP / UDP ロードバランサは、多くのユースケースに対応しています。このセクションでは、そのいくつかについて説明します。
アクセスの例
接続ネットワークから VPC ネットワーク内の内部 TCP / UDP ロードバランサにアクセスする方法は、次のとおりです。
- VPC ネットワーク ピアリング
- Cloud VPN と Cloud Interconnect
詳細例については、内部 TCP / UDP ロードバランサと接続されたネットワークをご覧ください。
3 層ウェブサービスの例
内部 TCP / UDP ロードバランサは、他のロードバランサと組み合わせて使用できます。たとえば、外部 HTTP(S) ロードバランサを使用する場合、外部 HTTP(S) ロードバランサはウェブ階層であり、内部 TCP / UDP ロードバランサの背後にあるサービスに依存します。
次の図は、外部 HTTP(S) ロードバランサと内部 TCP / UDP ロードバランサを使用する 3 層構成の例を示しています。
グローバル アクセスを使用する 3 層ウェブサービスの例
グローバル アクセスを有効にすると、次の図のように別のリージョンにウェブ層 VM を配置できます。
この多層アプリケーションの例のフローは、次のとおりです。
- グローバルに利用可能な、インターネットに接続したウェブ層が、HTTP(S) ロードバランサを使用してトラフィックをロード バランシングする。
us-east1リージョンの内部バックエンド ロード バランシングされたデータベース層に、グローバル ウェブ層がアクセスする。europe-west1リージョンのウェブ層の一部であるクライアント VM が、us-east1にある内部ロードバランスされたデータベース層にアクセスする。
ネクストホップとしての内部 TCP / UDP ロードバランサの使用
内部 TCP / UDP ロードバランサは、最終宛先へのパスに沿ってパケットを転送する際の次のゲートウェイとして使用できます。これを行うには、カスタム静的ルートでロードバランサをネクストホップに設定します。
カスタムルートでネクストホップとしてデプロイされた内部 TCP / UDP ロードバランサは、プロトコル（TCP、UDP、ICMP）に関係なくすべてのトラフィックを処理します。
次に、NAT ゲートウェイへのネクストホップとして内部 TCP / UDP ロードバランサを使用するサンプル アーキテクチャを示します。内部 TCP / UDP ロードバランサを介してファイアウォールまたはゲートウェイ仮想アプライアンス バックエンドにトラフィックをルーティングできます。
その他のユースケースには次のものがあります。
- ハブアンドスポーク: VPC ネットワーク ピアリングを使用したネクストホップ ルートの交換 -
hubVPC ネットワークに配置されたネクストホップ ファイアウォール仮想アプライアンスで、ハブアンドポーク トポロジを構成できます。ロードバランサをhubVPC ネットワークのネクストホップとして使用するルートは、各spokeネットワークで使用できます。 - バックエンド VM 上の複数の NIC への負荷分散。
これらのユースケースの詳細については、ネクストホップとしての内部 TCP / UDP ロードバランサをご覧ください。
内部 TCP / UDP ロードバランサと GKE
GKE が Service 用の内部 TCP / UDP ロードバランサを作成する方法の詳細については、GKE ドキュメントの LoadBalancer Service のコンセプトをご覧ください。
内部 TCP / UDP ロードバランサの仕組み
内部 TCP / UDP ロードバランサには次の特性があります。
- マネージド サービスである。
- プロキシではない。
- 仮想ネットワークで実装される。
プロキシ ロードバランサとは異なり、内部 TCP / UDP ロードバランサは、クライアントからの接続を終了せずに、バックエンドへの新しい接続を開きます。代わりに、内部 TCP / UDP ロードバランサは、接続をクライアントから正常なバックエンドに中断されることなく直接転送します。
- 中間デバイスや単一障害点が存在しない。
- ロードバランサの IP アドレスへのクライアント リクエストは、直接正常なバックエンド VM に送信されます。
- 正常なバックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。TCP 応答は、Direct Server Return を使用します。詳細については、TCP と UDP のリクエストと返信パケットをご覧ください。
ロードバランサは、ヘルスチェック プローブを使用して VM の状態を監視します。詳細については、ヘルスチェックをご覧ください。
Google Cloud Linux ゲスト環境、Windows ゲスト環境、またはそれと同様のプロセスは、各バックエンド VM をロードバランサの IP アドレスで構成します。Google Cloud イメージから作成された VM では、ゲスト エージェント（旧称 Windows ゲスト環境または Linux ゲスト環境）によって、ロードバランサの IP アドレスのローカルルートがインストールされます。Container-Optimized OS をベースとした Google Kubernetes Engine インスタンスは、代わりに iptables を使用してこれを実装します。
Google Cloud の仮想ネットワーキングが、トラフィック配信とスケーリングを適切に管理します。
プロトコル、スキーム、スコープ
各内部 TCP / UDP ロードバランサは、以下のものをサポートします。
- ロード バランシング スキーム
INTERNALと TCP または UDP プロトコルを備えた 1 つのバックエンド サービス（両方ではない） - 次のいずれかとして指定されたバックエンド VM。
- 1 つのリージョンと VPC ネットワークにあるマネージド インスタンス グループと非マネージド インスタンス グループ
- 同じリージョンと VPC ネットワークにある
GCE_VM_IPタイプ エンドポイントを持つバックエンド ゾーン ネットワーク エンドポイント グループ（NEG）NEG 内のエンドポイントは、NEG に使用されるものと同じサブネットとゾーン内のプライマリ内部 IP アドレスである必要があります。
- インスタンス グループのバックエンドを使用する場合の IPv4 トラフィックと IPv6 トラフィックのサポート。
GCE_VM_IPエンドポイントを使用するゾーン ネットワーク エンドポイント グループ（NEG）は、IPv4 トラフィックのみをサポートします。 - それぞれが TCP または UDP プロトコルを使用し、バックエンド サービスのプロトコルに一致する 1 つ以上の転送ルール。
- 独自の一意の IP アドレスを持つ各転送ルール、または共通の IP アドレスを共有する複数の転送ルール。
- 最大 5 つのポートまたはすべてのポートを持つ各転送ルール。
- グローバル アクセスが有効になっている場合、任意のリージョンのクライアント。
- グローバル アクセスが無効になっている場合、ロードバランサと同じリージョンのクライアント。
内部 TCP / UDP ロードバランサがサポートしていないものは、次のとおりです。
- 複数リージョンのバックエンド VM。
- インターネットからのトラフィックの分散（外部ロードバランサで使用する場合は不可）。
- IPv6 トラフィック用の TCP、UDP、ICMP 以外のプロトコル。
- ヘッダーが断片化された IPv6 パケット。
クライアント アクセス
デフォルトでは、クライアントはロードバランサと同じリージョンに存在する必要があります。クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。グローバル アクセスを有効にすると、任意のリージョンのクライアントが内部 TCP / UDP ロードバランサにアクセスできるようになります。
次の表にクライアント アクセスの概要を示します。
| グローバル アクセスが無効な場合 | グローバル アクセスが有効な場合 |
|---|---|
| クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 | クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。 |
| オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。 | オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。 |
リクエスト パケットと返信パケットの IP アドレス
バックエンド VM がクライアントからロード バランシングされたパケットを受信すると、パケットの送信元と宛先は次のようになります。
- 送信元: クライアントの内部 IPv4、IPv6、またはクライアントのエイリアス IPv4 範囲の IPv4 アドレス。
- 宛先: ロードバランサの転送ルールの IP アドレス。転送ルールでは、単一の内部 IPv4 アドレスまたは内部 IPv6 範囲を使用します。
ロードバランサはプロキシではなくパススルー ロードバランサであるため、パケットはロードバランサの転送ルールの宛先 IP アドレスに送信されます。バックエンド VM で実行されるソフトウェアは、次のように構成する必要があります。
- ロードバランサの転送ルールの IP アドレスまたは任意の IP アドレス（
0.0.0.0または::）をリッスン（バインド）する - ロードバランサの転送ルールのプロトコルがポートをサポートしている場合: ロードバランサの転送ルールのポートをリッスン（バインド）する
戻りパケットは、ロードバランサのバックエンド VM からクライアントに直接送信されます。戻りパケットの送信元アドレスと宛先 IP アドレスはプロトコルによって異なります。
- TCP は接続指向のため、バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスと一致するパケットで応答する必要があります。これにより、クライアントがレスポンス パケットを適切な TCP 接続に関連付けることができます。
- UDP はコネクションレスのため、バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスまたは VM に割り当てられた IP アドレスと一致するレスポンス パケットを送信できます。ほとんどのクライアントは、パケットの送信元と同じ IP アドレスからのレスポンスを想定しています。
次の表は、レスポンス パケットの送信元と宛先をまとめたものです。
| トラフィックの種類 | 送信元 | 宛先 |
|---|---|---|
| TCP | ロードバランサの転送ルールの IP アドレス | リクエスト パケットの送信元 |
| UDP | ほとんどの場合、ロードバランサの転送ルールの IP アドレス† | リクエスト パケットの送信元 |
† レスポンス パケットの送信元を VM NIC のプライマリ内部 IPv4 アドレスまたはエイリアス IP アドレス範囲に設定できます。VM で IP 転送が有効になっている場合は、任意の IP アドレスの送信元を使用できます。クライアントは、リクエスト パケットの宛先 IP アドレスと一致しない内部 IP アドレスからレスポンス パケットを受信します。このため、転送ルールの IP アドレスを送信元として使用しないのは高度なシナリオです。
アーキテクチャ
複数のバックエンドを持つ内部 TCP / UDP ロードバランサは、すべてのバックエンド間で接続を分散します。分散の方法と構成オプションの詳細は、トラフィックの分散をご覧ください。
内部 TCP / UDP ロードバランサのバックエンドとして、インスタンス グループまたはゾーン NEG を使用できますが、両方を組み合わせることはできません。
- インスタンス グループを選択した場合は、非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、リージョン マネージド インスタンス グループ、またはインスタンス グループ タイプの組み合わせを使用できます。
- ゾーン NEG を選択する場合は、
GCE_VM_IPゾーン NEG を使用する必要があります。
高可用性では、単一のゾーンに依存しない内部ロードバランサを設計する方法について説明しています。
内部 TCP / UDP ロードバランサのバックエンド VM として参加するインスタンスでは、適切な Linux または Windows ゲスト環境、または同等の機能を提供する他のプロセスが実行されている必要があります。これらのゲスト環境では、メタデータ サーバー（metadata.google.internal、169.254.169.254）に接続し、インスタンスのメタデータを読み取ることが可能である必要があります。これによって、ロードバランサの内部 IP アドレスに送信されるトラフィックを受け入れるローカルルートを生成できます。
この図は、2 つの個別のインスタンス グループに存在する VM 間のトラフィック分散を示しています。クライアント インスタンスからロードバランサの IP アドレス（10.10.10.9）に送信されたトラフィックが、いずれかのインスタンス グループのバックエンド VM 間で分散されます。サービスを提供するいずれかのバックエンド VM から送信されたレスポンスがクライアント VM に直接配信されます。
内部 TCP / UDP ロードバランサは、カスタムモードまたは自動モードの VPC ネットワークで使用できます。既存のレガシー ネットワークで内部 TCP / UDP ロードバランサを作成することもできます。
内部 TCP / UDP ロードバランサは、次の Google Cloud コンポーネントから構成されます。
| コンポーネント | 目的 | 要件 |
|---|---|---|
| 内部 IP アドレス | ロードバランサのアドレスです。 | 内部 IP アドレスは、内部転送ルールと同じサブネット内に存在する必要があります。サブネットは、バックエンド サービスと同じリージョンと VPC ネットワークに存在する必要があります。 |
| 内部転送ルール | 内部転送ルールを内部 IP アドレスと組み合わせると、ロードバランサのフロントエンドになります。ロードバランサが受け入れるプロトコルとポートを定義し、トラフィックをリージョンの内部バックエンド サービスにルーティングします。 | 内部 TCP / UDP ロードバランサの転送ルールは、次の条件を満たす必要があります。 • load-balancing-scheme が INTERNAL と指定されている。• バックエンド サービスの protocol に一致する TCP または UDP の ip-protocol を使用する。• バックエンド サービスと同じ VPC ネットワークとリージョン内の subnet を参照する。 |
| リージョンの内部バックエンド サービス | リージョンの内部バックエンド サービスは、バックエンドとの通信に使用するプロトコルを定義し、ヘルスチェックを指定します。バックエンドには、非マネージド インスタンス グループ、マネージド ゾーン インスタンス グループ、マネージド リージョン インスタンス グループ、GCE_VM_IP エンドポイントを使用したゾーン NEG があります。 |
バックエンド サービスは、次の条件を満たす必要があります。 • load-balancing-scheme が INTERNAL と指定されている。• 転送ルールの ip-protocol に一致する TCP または UDP の protocol を使用する。• 関連付けられたヘルスチェックを含む。 • 関連付けられたリージョンを含む。転送ルールとすべてのバックエンドは、バックエンド サービスと同じリージョンに存在する必要があります • 単一の VPC ネットワークに関連付けられている必要があります。指定されていない場合、各バックエンド VM のデフォルトのネットワーク インターフェース（ nic0）で使用されるネットワークに基づいてネットワークが推定されます。バックエンドサービスは特定のサブネットには接続されませんが、転送ルールのサブネットは、バックエンド サービスと同じ VPC ネットワークにある必要があります。 |
| ヘルスチェック | バックエンド サービスはいずれもヘルスチェックが関連付けられている必要があります。ヘルスチェックでは、Google Cloud が管理しているバックエンドについて、トラフィックの受信に適格であるかどうかを検討する際に使用するパラメータを定義します。正常なバックエンド VM のみが、クライアント VM からロードバランサの IP アドレスに送信されたトラフィックを受信します。 |
転送ルールとバックエンド サービスでは TCP か UDP のいずれかを使用できます。ただし、Google Cloud では UDP トラフィックに対するヘルスチェックが行われません。詳細は、ヘルスチェックと UDP トラフィックをご覧ください。 |
内部 IP アドレス
内部 TCP / UDP ロードバランサは、IPv4 のみ（シングルスタック）のサブネットと、IPv4 と IPv6（デュアルスタック）のサブネットをサポートします。詳細については、サブネットの種類をご覧ください。
内部 TCP / UDP ロードバランサには、少なくとも 1 つの転送ルールが必要です。転送ルールは内部 IP アドレスを参照します。
- IPv4 トラフィックの場合、転送ルールはプライマリ IPv4 サブネット範囲の IPv4 アドレスを参照します。
- IPv6 トラフィックの場合、転送ルールはサブネットの
/64内部 IPv6 アドレス範囲から内部 IPv6 アドレスの/96範囲を参照します。サブネットは、内部 IPv6 アドレス範囲（ipv6-access-typeをINTERNALに設定）を持つデュアル スタック サブネットである必要があります。
ファイアウォール構成
内部 TCP / UDP ロードバランサには、階層型ファイアウォール ポリシーと VPC ファイアウォール ルールに次の構成が必要です。
- IPv4 または IPv6 ヘルスチェックのソース範囲からの上り（内向き）を許可する。
- クライアントの IPv4 または IPv6 アドレスのソース範囲からの上り（内向き）を許可する。
詳細については、ファイアウォール ルールの構成をご覧ください。
転送ルール
転送ルールでは、ロードバランサがトラフィックを受け入れるポートとプロトコルを指定します。内部 TCP / UDP ロードバランサはプロキシではないため、同じプロトコルとポートでバックエンドにトラフィックを渡します。
内部 TCP / UDP ロードバランサには、少なくとも 1 つの内部転送ルールが必要です。同じロードバランサに対して複数の転送ルールを定義できます。
ロードバランサに IPv4 と IPv6 の両方のトラフィックを処理する場合は、IPv4（またはデュアルスタック）バックエンドを指す IPv4 トラフィック用のルールと、デュアルスタック バックエンドのみを指す IPv6 トラフィック用のルールの 2 つの転送ルールを作成します。IPv4 と IPv6 の転送ルールが同じバックエンド サービスを参照できますが、バックエンド サービスがデュアルスタック バックエンドを参照する必要があります。
転送ルールは、ロードバランサのバックエンド コンポーネントと同じ VPC ネットワークとリージョン内の特定のサブネットを参照する必要があります。この要件に関しては、次の点に注意してください。
- 転送ルールに指定するサブネットは、バックエンド VM で使用されるどのサブネットとも同じである必要はありません。ただし、サブネットは転送ルールと同じリージョンにある必要があります。
- IPv4 トラフィックの場合、内部転送ルールは、選択したサブネットのプライマリ IPv4 アドレス範囲からリージョン内部 IPv4 アドレスを参照します。この IPv4 アドレスは自動的に選択することも、静的（予約済み）IPv4 アドレスを使用することもできます。
- IPv6 トラフィックの場合、転送ルールはサブネットの内部 IPv6 アドレス範囲から IPv6 アドレスの
/96範囲を参照します。サブネットは、ipv6-access-typeがINTERNALに設定されたデュアルスタックのサブネットである必要があります。/96の IPv6 アドレス範囲は自動的に割り当てられます。これは範囲であるため、静的な予約済み IPv6 アドレスを作成することはできません。
転送ルールとグローバル アクセス
グローバル アクセスが有効な場合であっても、内部 TCP / UDP ロードバランサの転送ルールはリージョン単位です。グローバル アクセスを有効にすると、リージョンの内部転送ルールの allowGlobalAccess フラグが true に設定されます。
転送ルールとポートの仕様
内部転送ルールを作成する場合は、次のいずれかのポート指定を選択する必要があります。
- 1 個から 5 個までのポートを番号で指定する。
- すべてのポートにトラフィックを転送するには
ALLを指定する。
すべての TCP ポートまたはすべての UDP ポートのいずれかをサポートする内部転送ルールでは、バックエンド VM がそれぞれ別のポートで複数のアプリケーションを実行できます。特定のポートに送信されたトラフィックは、対応するアプリケーションに配信され、すべてのアプリケーションで同じ IP アドレスが使用されます。
5 つより多い特定のポートでトラフィックを転送する必要がある場合は、ファイアウォール ルールを転送ルールと組み合わせます。転送ルールを作成するときは、すべてのポートを指定してから、必要なポートへのトラフィックのみを許可する上り（内向き）allow ファイアウォール ルールを作成します。ファイアウォール ルールをバックエンド VM に適用します。
転送ルールは作成後に変更できません。指定したポートまたは内部転送ルールの内部 IP アドレスを変更する必要がある場合は、削除してから再度作成する必要があります。
単一のバックエンド サービスの複数の転送ルール
すべてが同じ内部バックエンド サービスを参照する複数の内部転送ルールを構成できます。内部 TCP / UDP ロードバランサには、少なくとも 1 つの内部転送ルールが必要です。
同じバックエンド サービスに複数の転送ルールを構成すると、TCP または UDP（両方ではない）のいずれかを使用して、次のことが可能になります。
ロードバランサに複数の IP アドレスを割り当てる。それぞれに一意の IP アドレスを使用した、複数の転送ルールを作成できます。各転送ルールでは、すべてのポートまたは最大 5 つのポートを指定できます。
同じ IP アドレスを使用する特定のポートセットをロードバランサに割り当てる。同じ IP アドレスを共有する複数の転送ルールを作成し、各転送ルールで特定の最大 5 つのポートを使用するように設定できます。単一の転送ルールですべてのポートを指定する代わりに、この方法を使用できます。
共通の内部 IP アドレスを共有する 2 つ以上の内部転送ルールに関するシナリオについては、同じ IP アドレスを持つ複数の転送ルールをご覧ください。
複数の内部転送ルールを使用する場合は、バックエンド VM で実行されるソフトウェアを、すべての転送ルール IP アドレスまたは任意のアドレス（IPv4 の場合は 0.0.0.0/0、IPv6 の場合は ::/0）にバインドするように構成します。ロードバランサを介して配信されるパケットの宛先 IP アドレスは、対応する内部転送ルールが関連付けられている内部 IP アドレスです。詳細については、TCP と UDP のリクエストと返信パケットをご覧ください。
バックエンド サービス
それぞれの内部 TCP / UDP ロードバランサには、バックエンドのパラメータと動作を定義するリージョン内部転送ルールが 1 つあります。バックエンド サービスの名前は、Google Cloud Console に表示される内部 TCP / UDP ロードバランサの名前です。
各バックエンド サービスは、次のバックエンド パラメータを定義します。
プロトコル。バックエンド サービスは、1 つ以上の内部転送ルールで指定されたポートで TCP トラフィックまたは UDP トラフィックのいずれか一方のみを受け取ります。バックエンド サービスでは、トラフィックが送信された同じポート上のバックエンド VM にトラフィックを配信できます。バックエンド サービス プロトコルは、転送ルールのプロトコルと一致する必要があります。
トラフィック分散。バックエンド サービスは、構成可能なセッション アフィニティに従ってトラフィックの分散を許可します。
ヘルスチェック。バックエンド サービスには、関連付けられたヘルスチェックが必要です。
各バックエンド サービスは単一のリージョンで動作し、1 つの VPC ネットワーク内でバックエンド VM のトラフィックを分散します。
1 つのバックエンド タイプ、1 つのリージョン。バックエンドは、インスタンス グループか、バックエンド サービスおよび転送ルールと同じリージョンにある
GCE_VM_IPエンドポイントを持つゾーン NEG です。インスタンス グループのバックエンドは、非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、またはリージョン マネージド インスタンス グループです。ゾーン NEG バックエンドではGCE_VM_IPエンドポイントを使用する必要があります。1 つの VPC ネットワーク。各インスタンス グループまたは NEG バックエンドは、まだバックエンド サービスに接続されていない場合でも、関連付けられた VPC ネットワークが存在します。ネットワークが各タイプのバックエンドにどのように関連付けられているかについては、インスタンス グループのバックエンドとネットワーク インターフェースとゾーン NEG バックエンドとネットワーク インターフェースをご覧ください。バックエンド サービス リソース自体にも関連付けられた VPC ネットワークがあり、このネットワークは、明示的または暗黙的に定義できます。バックエンド サービスのネットワークについて詳しくは、バックエンド サービスのネットワーク仕様とバックエンド サービスのネットワーク ルールをご覧ください。
インスタンス グループのバックエンドとネットワーク インターフェース
インスタンス グループに関連付けられた VPC ネットワークは、すべてのメンバー VM の nic0 ネットワーク インターフェースで使用される VPC ネットワークです。
- マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークがインスタンス テンプレートで定義されています。
- 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、非マネージド インスタンス グループに追加する最初の VM インスタンスの
nic0ネットワーク インターフェースで使用される VPC ネットワークとして定義されます。
特定の（マネージドまたは非マネージド）インスタンス グループ内で、すべての VM インスタンスの nic0 ネットワーク インターフェースが同じ VPC ネットワークに存在している必要があります。各メンバー VM は、インスタンス グループに関連付けられた VPC ネットワークとは異なる VPC ネットワーク内に追加のネットワーク インターフェース（nic1 から nic7）を任意で持つことができます。
ゾーン NEG バックエンドとネットワーク インターフェース
GCE_VM_IP エンドポイントを含むゾーン NEG に関連付けられた VPC ネットワークは、エンドポイントを追加する前に、ゾーン NEG を作成する際に指定されます。
特定の NEG 内では、各 GCE_VM_IP エンドポイントは実際にはネットワーク インターフェースを表します。ネットワーク インターフェースは、NEG に関連付けられた VPC ネットワークに存在する必要があります。Compute Engine インスタンスの観点から、ネットワーク インターフェースは任意の識別子（nic0 から nic7）を使用できます。NEG のエンドポイントであるという観点から、インターフェースはプライマリ IPv4 アドレスを使用することで識別されます。
GCE_VM_IP エンドポイントを NEG に追加するには、次の 2 つの方法があります。
- エンドポイントを追加するときに VM 名と IP アドレスの両方を指定する場合は、指定する IP アドレスは、VM のネットワーク インターフェースのいずれかのプライマリ内部 IPv4 アドレスである必要があります。このネットワーク インターフェースは、NEG に関連付けられている VPC ネットワークを使用する必要があります。
- エンドポイントを追加するときに VM 名のみ（IP アドレスなし）を指定する場合、Google Cloud では、VM のネットワーク インターフェースが NEG に関連付けられた VPC ネットワーク内に存在する必要があります。Google Cloud がエンドポイントに選択する IP アドレスは、NEG に関連付けられた VPC ネットワーク内のネットワーク インターフェースのプライマリ内部 IPv4 アドレスです。
バックエンド サービスのネットワーク仕様
バックエンド サービスの作成時に、--network フラグを使用して VPC ネットワークを明示的にバックエンド サービスに関連付けることができます。バックエンド サービスのネットワーク ルールはすぐに有効になります。
バックエンド サービスを作成するときに --network フラグを省略すると、Google Cloud は次のいずれかの適格なイベントを使用して、バックエンド サービスの関連 VPC ネットワークを暗黙的に設定します。設定後は、バックエンド サービスの関連 VPC ネットワークは変更できません。
バックエンド サービスにまだ関連付けられたバックエンドがなく、バックエンド サービスを参照するように最初の転送ルールを構成する場合、Google Cloud はバックエンド サービスの関連 VPC ネットワークを、この転送ルールで使用されるサブネットを含む VPC ネットワークに設定します。
バックエンド サービスにまだ参照している転送ルールがなく、最初のインスタンス グループのバックエンドをバックエンド サービスに追加すると、Google Cloud はバックエンド サービスの VPC ネットワークを、その最初のインスタンス グループのバックエンドに関連付けられたネットワークに設定します。つまり、バックエンド サービスの関連 VPC ネットワークは、最初のインスタンス グループのバックエンド内の各 VM の
nic0ネットワーク インターフェースで使用されるネットワークです。バックエンド サービスにまだ参照している転送ルールがなく、最初のゾーン NEG バックエンド（
GCE_VM_IPエンドポイントを含む）をバックエンド サービスに追加すると、Google Cloud はバックエンド サービスの VPC ネットワークを、その最初の NEG バックエンドに関連付けられた VPC ネットワークに設定します。
バックエンド サービスの VPC ネットワークが適格なイベントによって設定されたら、追加の転送ルール、バックエンド インスタンス グループ、または追加するバックエンド ゾーン NEG はすべてバックエンド サービスのネットワーク ルールに従う必要があります。
バックエンド サービスのネットワーク ルール
バックエンド サービスが特定の VPC ネットワークに関連付けられた後は、次のルールが適用されます。
バックエンド サービスを参照するように転送ルールを構成する場合、転送ルールはバックエンド サービスの VPC ネットワークのサブネットを使用する必要があります。ネットワークが VPC ネットワーク ピアリングで接続されていても、転送ルールとバックエンド サービスが異なる VPC ネットワークを使用することはできません。
インスタンス グループのバックエンドを追加するときは、次のいずれかを満たしている必要があります。
- インスタンス グループに関連付けられた VPC ネットワーク（インスタンス グループ内の各 VM の
nic0ネットワーク インターフェースによって使用されます）は、バックエンド サービスに関連付けられた VPC ネットワークと一致する必要があります。 - 各バックエンド VM は、バックエンド サービスに関連付けられた VPC ネットワークに
nic0以外のインターフェース（nic1～nic7）を持っている必要があります。
- インスタンス グループに関連付けられた VPC ネットワーク（インスタンス グループ内の各 VM の
GCE_VM_IPエンドポイントを使用してゾーン NEG バックエンドを追加する場合、NEG に関連付けられた VPC ネットワークは、バックエンド サービスに関連付けられた VPC ネットワークと一致する必要があります。
バックエンドのサブセット化
バックエンドのサブセット化は、トラフィックを分散するバックエンドの数を制限してパフォーマンスを向上させるオプションの機能です。
1 つのロードバランサで 250 台を超えるバックエンド VM をサポートする必要がある場合にのみ、サブセット化を有効にしてください。詳しくは、内部 TCP / UDP ロードバランサのバックエンドのサブセット化をご覧ください。
ヘルスチェック
ロードバランサのバックエンド サービスは、グローバルまたはリージョンのヘルスチェックに関連付けられている必要があります。VPC ネットワークの外側の特殊ルートを使用することで、ヘルスチェック システムとバックエンドとの間で容易に通信できます。
既存のヘルスチェックを使用することも、新たに定義することもできます。トラフィック分散での説明のとおり、内部 TCP / UDP ロードバランサは、ヘルスチェックのステータスを使用して、新しい接続をルーティングする方法を決定します。
次の任意のヘルスチェック プロトコルを使用できます。ヘルスチェックのプロトコルがロードバランサのプロトコルと一致する必要はありません。
- HTTP、HTTPS、HTTP/2。バックエンド VM が HTTP、HTTPS、または HTTP/2 を使用してトラフィックを処理する場合、HTTP ベースのヘルスチェックではそのプロトコルに適したオプションが提供されるため、それぞれのプロトコルと一致するヘルスチェックの使用をおすすめします。内部 TCP / UDP ロードバランサを介して HTTP タイプのトラフィックを処理すると、ロードバランサのプロトコルが TCP になります。
- SSL または TCP。バックエンド VM が HTTP タイプのトラフィックを処理しない場合は、SSL または TCP のヘルスチェックを使用する必要があります。
作成するヘルスチェックの種類に関係なく、Google Cloud は、ロードバランサのバックエンド サービスによって選択された VPC ネットワーク内のネットワーク インターフェースへの内部 TCP / UDP ロードバランサの転送ルールの IP アドレスに、ヘルスチェック プローブを送信します。これにより、ロードバランスされたトラフィックの配信方法がシミュレートされます。バックエンド VM 上で動作するソフトウェアは、ロード バランシングによって各転送ルールの IP アドレスに送信されるトラフィックとヘルスチェック プローブの両方に応答する必要があります（ソフトウェアはネットワーク インターフェースに割り当てられている特定の IP アドレスではなく 0.0.0.0:<port> をリッスンする必要があります）詳細については、プローブ パケットの宛先をご覧ください。
ヘルスチェックと UDP トラフィック
Google Cloud では、UDP プロトコルを使用するヘルスチェックを提供していません。UDP トラフィックを処理する内部 TCP / UDP ロードバランサを使用する場合、ヘルスチェック情報を提供する TCP ベースのサービスをバックエンド VM で実行する必要があります。
この構成では、クライアントのリクエストが UDP プロトコルを使用してロードバランスされ、TCP サービスが Google Cloud ヘルスチェック プローバーへの情報提供に使用されます。たとえば、Google Cloud に HTTP 200 レスポンスを返す単純な HTTP サーバーをバックエンド VM ごとに実行できます。この例では、バックエンド VM 上で実行する独自のロジックを使用して、UDP サービスが適切に構成され実行されている場合にのみ HTTP サーバーが 200 を返すようにする必要があります。
高可用性アーキテクチャ
内部 TCP / UDP ロードバランサは可用性が高く設計されています。高可用性のメカニズムは単一のデバイスや VM インスタンスに依存しないため、ロードバランサの可用性を高くするための特別な手順はありません。
バックエンド VM インスタンスが複数のゾーンにデプロイされるようにするには、次のデプロイに関する推奨事項に従ってください。
インスタンス テンプレートを使用してソフトウェアをデプロイできる場合は、リージョンのマネージド インスタンス グループを使用してください。リージョンのマネージド インスタンス グループは、複数のゾーン間にトラフィックを自動的に分散して、ゾーン内の潜在的な問題の回避に最適な手段を提供します。
ゾーンのマネージド インスタンス グループまたは非マネージド インスタンス グループを使用する場合は、同じバックエンド サービスに同じリージョン内の複数のゾーンの複数のインスタンス グループを使用します。複数のゾーンを使用すると、特定のゾーンの潜在的な問題から保護できます。
共有 VPC アーキテクチャ
次の表は、共有 VPC ネットワークで使用される内部 TCP / UDP ロードバランサのコンポーネント要件をまとめたものです。例については、共有 VPC のプロビジョニングのページで内部 TCP / UDP ロードバランサの作成をご覧ください。
| IP アドレス | 転送ルール | バックエンド コンポーネント |
|---|---|---|
| 内部 IP アドレスは、バックエンド VM と同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、Google Cloud 内部 IP アドレスは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、ホスト プロジェクト内の目的の共有 VPC ネットワーク内のサブネットを参照する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。 サービス プロジェクトで内部 IP アドレスを作成し、その IP アドレスのサブネットがサービス プロジェクトの VPC ネットワークにある場合、内部 TCP / UDP ロードバランサはサービス プロジェクトに対しローカルになります。共有 VPC ホスト プロジェクトに対してローカルではありません。 |
内部転送ルールは、バックエンド VM と同じプロジェクトで定義する必要があります。 共有 VPC ネットワークでロードバランサを使用できるようにするには、内部転送ルールは、バックエンド VM が配置されている同じサービス プロジェクト内で定義する必要があります。さらに、関連付けられている内部 IP アドレスが参照する同じサブネット（共有 VPC ネットワーク内）を参照する必要があります。 サービス プロジェクトで内部転送ルールを作成し、転送ルールのサブネットがサービス プロジェクトの VPC ネットワーク内にある場合、内部 TCP / UDP ロードバランサはサービス プロジェクトにローカルです。共有 VPC ホスト プロジェクトに対してローカルではありません。 |
共有 VPC のシナリオでは、バックエンド VM はサービス プロジェクト内にあります。そのサービス プロジェクトでは、リージョン内部のバックエンド サービスとヘルスチェックを定義する必要があります。 |
トラフィック分散
内部 TCP / UDP ロードバランサによる新しい接続の分散方法は、フェイルオーバーが構成されているかどうかによって異なります。
フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、内部 TCP / UDP ロードバランサによって正常なバックエンド VM に新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。
フェイルオーバーを構成している場合、内部 TCP / UDP ロードバランサは、構成したフェイルオーバー ポリシーに従って、アクティブ プール内の VM 間で新しい接続を分散します。すべてのバックエンド VM が正常でない場合は、次のいずれかの動作から選択できます。
- （デフォルト）ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
- ロードバランサは、トラフィックをドロップするように構成されています。
新しい接続の分散方法は、ロードバランサのセッション アフィニティの設定によって異なります。
ヘルスチェックの状態によって、新しい接続の分散が制御されます。デフォルトでは、TCP 接続は異常なバックエンドで維持されます。詳細とこの動作を変更する方法については、異常なバックエンドでの接続の永続性をご覧ください。
バックエンドの選択と接続トラッキング
内部 TCP / UDP ロードバランサでは、構成可能なバックエンドの選択と接続トラッキング アルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。内部 TCP / UDP ロードバランサでは、次のアルゴリズムを使用して、（フェイルオーバーを構成している場合は、アクティブ プール内の）バックエンド VM 間にパケットが分散されます。
- ロードバランサに、受信パケットの特性と一致する接続トラッキング テーブルがある場合、パケットは接続トラッキング テーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部とみなされるため、ロードバランサによって接続トラッキング テーブルに以前に決定され記録されたバックエンド VM に送信されます。
ロードバランサが対応する接続トラッキング エントリを持たないパケットを受信した場合、ロードバランサは以下のことを行います。
ロードバランサがバックエンドを選択します。ロードバランサは、構成されたセッション アフィニティに基づいてハッシュを計算します。このハッシュを使用してバックエンドを選択します。
- 少なくとも 1 つのバックエンドが正常な場合、ハッシュは正常なバックエンドのいずれかを選択します。
- すべてのバックエンドが異常な状態の場合で、フェイルオーバー ポリシーが構成されていない場合、ハッシュはいずれかのバックエンドを選択します。
- すべてのバックエンドが異常な状態で、フェイルオーバー ポリシーが構成されており、この状況でフェイルオーバー ポリシーがトラフィックをドロップするように構成されていない場合、ハッシュはプライマリ VM バックエンドの 1 つを選択します。
デフォルトのセッション アフィニティ
NONEは、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュを使用します。バックエンドの選択は、使用する情報が少ないハッシュ アルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッション アフィニティのオプションをご覧ください。
ロードバランサにより、接続トラッキング テーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。
TCP パケットと UDP パケットの場合、接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。
接続トラッキング ハッシュが 5 タプルの場合、TCP SYN パケットは常に接続トラッキング テーブルに新しいエントリを作成します。
デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。- トラッキング モードが
PER_CONNECTION（すべてのセッション アフィニティ）の場合。または - トラッキング モードが
PER_SESSIONであり、セッション アフィニティがNONEの場合。または - トラッキング モードが
PER_SESSIONであり、セッション アフィニティがCLIENT_IP_PORT_PROTOの場合。
接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキング モードをご覧ください。
さらに、次の点に留意してください。
- デフォルトでは、接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。アイドル タイムアウトをカスタマイズする方法については、アイドル タイムアウトをご覧ください。
- プロトコルによっては、バックエンドが正常な状態ではなくなると、ロードバランサによって接続トラッキング テーブルのエントリが削除される場合があります。この動作の詳細とカスタマイズ方法については、異常なバックエンドでの接続の永続性をご覧ください。
- トラッキング モードが
セッション アフィニティのオプション
セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。バックエンド VM がクライアントの状態情報を追跡する必要がある場合は、セッション アフィニティを設定します。これは、ウェブ アプリケーションの一般的な要件です。
セッション アフィニティはベストエフォート ベースで機能します。
内部 TCP / UDP ロードバランサは、バックエンド インスタンス グループではなく、内部バックエンド サービス全体に指定する次に示すセッション アフィニティのオプションをサポートします。
- なし（
NONE）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ - クライアント IP、宛先なし（
CLIENT_IP_NO_DESTINATION）。送信元 IP アドレスからのみ作成された 1 タプルハッシュ - クライアント IP（
CLIENT_IP）。送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュです。ネットワーク ロードバランサは、セッション アフィニティの「クライアント IP、宛先 IP」オプションを呼び出します。 - クライアント IP、宛先 IP、プロトコル（
CLIENT_IP_PROTO）。送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ - クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル（
CLIENT_IP_PORT_PROTO）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ
ロードバランサをカスタム静的ルートのネクストホップとして使用しない限り、パケットの宛先 IP アドレスは、パケットをロードバランサに配信するためのロードバランサ転送ルールの IP アドレスと一致する必要があります。ロードバランサをカスタム静的ルートのネクストホップとして使用する場合の考慮事項については、セッション アフィニティとネクストホップの内部 TCP / UDP ロードバランサをご覧ください。
セッション アフィニティとネクストホップの内部 TCP / UDP ロードバランサ
内部 TCP / UDP ロードバランサをカスタム静的ルートのネクストホップとして使用する場合、パケットの宛先はロードバランサの転送ルールの IP アドレスにはなりません。
パケットの宛先がカスタム静的ルートの宛先内にあり、カスタム静的ルートが適用可能なルートである場合、パケットはロードバランサに配信されます。
すべてのセッション アフィニティ オプション（クライアント IP、宛先なしを除く）では、パケットの宛先 IP アドレスが使用されます。ネクストホップが内部 TCP / UDP ロードバランサであるカスタム静的ルートを使用する場合:
ロードバランサに 1 つのバックエンド（フェイルオーバーを構成している場合はアクティブ プール）しかない場合、すべてのセッション アフィニティのオプションでバックエンドが選択されます。アクティブなプールにバックエンドが 1 つしかない場合、セッション アフィニティの選択は影響を受けません。
ロードバランサに複数のバックエンドがあり（フェイルオーバーを構成している場合はアクティブ プール内）、「クライアント IP、宛先なし」以外のセッション アフィニティ オプションを選択した場合、同じクライアントからルートの宛先の任意の IP アドレスに送信されたパケットが、同じバックエンドで処理されるとは限りません。これは、セッション アフィニティ ハッシュが、パケットの宛先 IP アドレス（ルートの宛先範囲内の任意のアドレス）を含む情報から計算されるためです。
同じクライアントからルートの宛先の任意の IP アドレスに送信されるすべてのパケットを、同じバックエンドで処理する必要がある場合は、セッション アフィニティのオプションで「クライアント IP、宛先なし」を使用する必要があります。
接続トラッキング モード
トラッキング モードでは、使用する接続トラッキング アルゴリズムを指定します。トラッキング モードには、PER_CONNECTION（デフォルト）と PER_SESSION の 2 つがあります。
PER_CONNECTION（デフォルト）。このモードでは、TCP トラフィックと UDP トラフィックはセッション アフィニティの設定に関係なく、常に 5 タプルごとにトラッキングされます。これは、接続トラッキングのキー（5 タプル）が、構成されたセッション アフィニティの設定（たとえば、CLIENT_IP_PROTO設定の 3 タプル）と異なることを意味します。その結果、セッション アフィニティが分割され、バックエンドのセットや状態が変更されたときに、セッションの新しい接続が別のバックエンドを選択する場合があります。PER_SESSION。このモードでは、構成されたセッション アフィニティに従って TCP と UDP のトラフィックを追跡します。つまり、セッション アフィニティがCLIENT_IPまたはCLIENT_IP_PROTOの場合、このモードを構成すると、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。これは、アフィニティの消失が高コストで、バックエンドの追加後も回避すべきシナリオでは望ましい場合があります。
セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO に設定されている場合、接続トラッキング モードの設定は冗長です。プロトコルごとに異なるセッション アフィニティが設定されているこれらのトラッキング モードの動作については、次の表をご覧ください。
| バックエンドの選択 | 接続トラッキング モード | ||
|---|---|---|---|
| セッション アフィニティの設定 | バックエンド選択のハッシュ方法 | PER_CONNECTION（デフォルト） |
PER_SESSION |
| デフォルト: セッション アフィニティなし
|
5 タプルハッシュ | 5 タプル接続トラッキング | 5 タプル接続トラッキング |
クライアント IP、宛先なし
|
1 タプルハッシュ | 5 タプル接続トラッキング | 1 タプル接続トラッキング |
クライアント IP
（ネットワーク ロードバランサのクライアント IP、宛先 IP と同じ） |
2 タプルハッシュ | 5 タプル接続トラッキング | 2 タプル接続トラッキング |
クライアント IP、宛先 IP、プロトコル
|
3 タプルハッシュ | 5 タプル接続トラッキング | 3 タプル接続トラッキング |
クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル
|
5 タプルハッシュ | 5 タプル接続トラッキング | 5 タプル接続トラッキング |
接続トラッキング モードを変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。
異常なバックエンドでの接続の永続性
正常でないバックエンドでの接続の永続性の設定は、バックエンドが異常になった後（バックエンドがロードバランサの構成済みバックエンド インスタンス グループに残っている限り）、選択したバックエンドで既存の接続を持続するかどうかを制御します。
このセクションで説明する動作は、バックエンド VM をインスタンス グループから削除する場合、またはインスタンス グループをバックエンド サービスから削除する場合には適用されません。このような場合、確立された接続はコネクション ドレインの有効化で説明されている内容に基づいてのみ維持されます。
使用できる接続の永続性に関するオプションは次のとおりです。
DEFAULT_FOR_PROTOCOL（デフォルト）NEVER_PERSISTALWAYS_PERSIST
次の表には、接続の永続性に関するオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードに対して接続を維持する方法をまとめています。
| 異常なバックエンド オプションでの接続の永続性 | 接続トラッキング モード | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） UDP: 異常なバックエンドで接続が持続することはありません |
TCP: セッション アフィニティが UDP: 異常なバックエンドで接続が持続することはありません |
NEVER_PERSIST |
TCP、UDP: 異常なバックエンドで接続が持続することはありません | |
ALWAYS_PERSIST
|
TCP、UDP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） このオプションは、高度なユースケースにのみ使用してください。 |
構成が不可能 |
接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。
アイドル タイムアウト
デフォルトでは、接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。このデフォルトのアイドル タイムアウト値は、接続トラッキングが 5 タプル未満の場合（つまり、セッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO に構成されている場合）にのみ変更できます。トラッキング モードは PER_SESSION です）。
構成可能なアイドル タイムアウトの最大値は 57,600 秒（16 時間）です。
アイドル タイムアウト値を変更する方法については、接続トラッキング ポリシーの構成をご覧ください。
1 つのクライアントから接続をテストする
単一のクライアント システムから内部 TCP / UDP ロードバランサの IP アドレスへの接続をテストする場合、次の点に注意します。
クライアント システムが負荷分散対象外の VM、つまりバックエンド VM でない場合、新しい接続がロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッション アフィニティのオプションが、少なくともクライアント システムの IP アドレスに依存するため、同じクライアントからの接続は、予測より頻繁に同じバックエンド VM に分散されることがあります。
実地面では、単一クライアントから内部 TCP / UDP ロードバランサに接続した場合、これを介したトラフィック分散を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。
クライアント VM がロードバランサのバックエンド VM の場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常にクライアント / バックエンド VM 自体が応答することになります。この現象は、バックエンド VM が正常であるかどうかにかかわらず、ロードバランサの内部転送ルールで指定されたプロトコルとポート上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。
詳細については、ロードバランスされた VM からのリクエストの送信をご覧ください。
UDP の断片化
内部 TCP / UDP ロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。- UDP パケットは Google Cloud VPC ネットワークに到達する前に断片化される場合があります。
- Google Cloud VPC ネットワークでは、到達した UDP フラグメントが（すべてのフラグメントの到達を待たずに）転送されます。
- Google Cloud 以外のネットワークとオンプレミス ネットワーク機器では、UDP フラグメントが到達すると転送される可能性、すべてのフラグメントが到達するまで断片化された UDP パケットが遅延される可能性、または断片化された UDP パケットが破棄される可能性があります。詳しくは、ネットワーク プロバイダまたはネットワーク機器のドキュメントをご覧ください。
断片化された UDP パケットを処理する可能性があり、それを同じバックエンドにルーティングする必要がある場合は、次の転送ルールとバックエンド サービスの構成パラメータを使用します。
転送ルールの構成: ロード バランシングされた IP アドレスごとに
UDP転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これで、すべてのフラグメントが同じ転送ルールに到達するようになります。断片化されたパケット（最初のフラグメント以外）には宛先ポートがありませんが、すべてのポートのトラフィックを処理する転送ルールを構成すると、ポート情報がない UDP フラグメントも受信するように構成されます。すべてのポートを構成するには、Google Cloud CLI を使用して--ports=ALLを設定するか、API を使用してallPortsをTrueに設定します。バックエンド サービスの構成: バックエンド サービスのセッション アフィニティを
CLIENT_IP（2 タプルハッシュ）またはCLIENT_IP_PROTO（3 タプルハッシュ）に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント（最初のフラグメント以外）に同じポートが選択されるようにします。バックエンド サービスの接続トラッキング モードをPER_SESSIONに設定して、接続トラッキング テーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して作成されるようにします。
フェイルオーバー
内部 TCP / UDP ロードバランサでは、一部のバックエンドをフェイルオーバー バックエンドとして指定できます。これらのバックエンドは、プライマリ バックエンド インスタンス グループの正常な VM の数が、構成可能なしきい値を下回る場合にのみ使用されます。デフォルトでは、すべてのプライマリ VM とフェイルオーバー VM が異常な状態になると、最後の手段として、Google Cloud はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。
内部 TCP / UDP ロードバランサのバックエンド サービスにバックエンドを追加すると、デフォルトでは、そのバックエンドがプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。
内部 TCP / UDP ロードバランサのフェイルオーバーの詳細なコンセプトについては、内部 TCP / UDP ロードバランサのフェイルオーバーをご覧ください。
割り当てと上限
割り当てと上限について詳しくは、ロード バランシングのリソースの割り当てをご覧ください。
次のステップ
- 内部 TCP / UDP ロードバランサを構成してテストする。内部 TCP / UDP ロードバランサを設定するをご覧ください。
- 内部 TCP / UDP ロードバランサの Cloud Monitoring を構成する。内部 TCP / UDP ロードバランサのロギングとモニタリングをご覧ください。
- 内部 TCP / UDP ロードバランサに関する問題のトラブルシューティングを行う。内部 TCP / UDP ロードバランサのトラブルシューティングをご覧ください。