グローバル外部パススルー ネットワーク ロードバランサは、複数の Google Cloud リージョンに存在するバックエンド（インスタンス グループまたはネットワーク エンドポイント グループ）間で外部トラフィックを分散するレイヤ 4 パススルー ロードバランサです。これらのロードバランサは、グローバルに分散している Maglev 上に構築され、Google のグローバル ネットワークとコントロール プレーンを使用して連携します。
グローバル外部パススルー ネットワーク ロードバランサは、ユーザー トラフィックがGoogleのグローバル ネットワークに入るポイントに最も近いバックエンド リージョンにトラフィックを自動的に転送します。
適格なバックエンドが 2 つ以上のリージョンで構成されている場合:
リージョンが容量に達している場合、ロードバランサは、リージョンの容量を超える新しいユーザー接続の一部を、容量が利用可能な次に近いリージョンに自動的にスピルオーバーし、既存の接続は現在のリージョンに保持します。
リージョンがダウンした場合、ロードバランサは、使用可能な容量を持つ次に近いリージョンにトラフィックを自動的にフェイルオーバーします。
グローバル外部パススルー ネットワーク ロードバランサは、次のトラフィックを受信できます。
- インターネット上のすべてのクライアント
- 外部 IP のあるGoogle Cloud VM
- Cloud NAT またはインスタンス ベースの NAT 経由でのインターネット アクセスに対応したGoogle Cloud VM
グローバル外部パススルー ネットワーク ロードバランサは、次のような状況で使用します。
TCP、UDP、ESP、GRE、ICMP、ICMPv6 のトラフィック用に高パフォーマンスのパススルー レイヤ 4 ロードバランサが必要な場合。ロードバランサは、IPv4 トラフィックと IPv6 トラフィックの両方を処理できます。
プロキシを経由せずに元のパケットを受信する必要がある場合。たとえば、クライアントの送信元 IP アドレスを保持する必要がある場合など。
同じエニーキャスト IP アドレスを使用して、複数の Google Cloud リージョン のバックエンドに低レイテンシでトラフィックを配信する必要があります。
デプロイは、リージョンのバックエンドの障害や過負荷に対して復元力があり、トラフィックを空き容量のある次に最も近いリージョンに自動的かつ正常にリダイレクトする必要があります。
グローバル外部パススルー ネットワーク ロードバランサを使用するには、デプロイが次の要件を満たしている必要があります。
- TLS（SSL）トラフィックを処理する場合は、バックエンドで SSL トラフィックを終端する必要があります。グローバル外部パススルー ネットワーク ロードバランサは、SSL 終端をサポートしていません。
主な機能
グローバル外部パススルー ネットワーク ロードバランサは、次の主な機能をサポートしています。
高可用性を考慮した設計
ロードバランサは、2 つのグローバル外部エニーキャスト IP アドレスを提供します。それぞれは、高可用性を実現するために、分離されたグローバル ロード バランシングのコントロール プレーンとデータプレーンのサーバー インフラストラクチャ（可用性グループとも呼ばれます）によって提供されます。クライアントは、いずれかの IP アドレスを使用して、使用可能な容量を持つ最も近い正常なバックエンドに接続できます。
ロードバランサを使用すると、複数のリージョンにバックエンドがあるグローバル バックエンド サービスを作成するときに、サービスの可用性を向上させることができます。 Google Cloud 特定のリージョンのバックエンドが停止した場合、トラフィックは次に近いリージョンに正常にフェイルオーバーされます。
すべてのバックエンドを単一の Google Cloud リージョンで構成することはできますが、リージョン停止に対する復元力を確保するため、少なくとも 3 つの Google Cloud リージョンにバックエンドをデプロイすることをおすすめします。
レイテンシとロードアウェア バランシング
グローバル外部パススルー ネットワーク ロードバランサは、プレミアム ティアのみを使用します。プレミアム ティアでは、インターネットからのトラフィックが、ユーザーに最も近いポイント オブ プレゼンス（PoP）から Googleの高性能低レイテンシ ネットワークに入ります。同様に、アウトバウンド トラフィックは Googleのネットワークを通り、ユーザーに最も近い PoP から出ていきます。
グローバルに分散された Maglev ロードバランサは、トラフィックがGoogle Cloud のネットワークに入る PoP に最も近いGoogleリージョンに受信トラフィックをルーティングします。ただし、そのリージョンに利用可能な容量を持つ正常なバックエンドがある場合に限ります。それ以外の場合、ロードバランサは、使用可能な容量を持つ正常なバックエンドがある次に近いリージョンにトラフィックを自動的かつ正常にスピルオーバーします。
パケット レイテンシとバックエンド効率を最適化するために、バックエンドの配置と容量を決定します。バックエンドの容量は、最大受信 PPS（1 秒あたりのパケット数）レート、最大 CPU 使用率、またはその両方に基づいて設定できます。バックエンド サービスで構成されたバックエンド容量は、そのバックエンド サービスを参照するすべての転送ルールの IP アドレス間で公平に共有されます。
グローバル外部パススルー ネットワーク ロードバランサの仕組み
グローバル外部パススルー ネットワーク ロードバランサには、フロントエンド（転送ルール）とバックエンド（バックエンド サービスとそのバックエンド グループ）があります。バックエンド グループとしてインスタンス グループまたは GCE_VM_IP ゾーン NEG を使用できます。
アーキテクチャ
次の図は、複数の Google Cloud リージョンのバックエンドにトラフィックを分散するグローバル外部パススルー ネットワーク ロードバランサを示しています。ロードバランサが作成されると、 Google Cloud は、分離されたコントロール プレーンとデータプレーンのインフラストラクチャ（可用性グループ AG0 と AG1 とも呼ばれます）によって提供される 2 つのグローバル外部エニーキャスト IP アドレスを割り当てます。
2 つのコントロール プレーンとデータプレーンにより、すべてのグローバル外部パススルー ネットワーク ロードバランサで高可用性、フォールト トレランス、復元力が実現します。1 つのアベイラビリティ グループのコントロール プレーンまたはデータプレーンで障害が発生しても、他のアベイラビリティ グループには影響しません。正しく構成されたクライアントは、ロードバランサの両方の IP アドレスに接続できる必要があります。たとえば、クライアントが AG0 IP アドレスに接続できない場合は、代わりに AG1 IP アドレスに接続するように構成する必要があります。
ロードバランサは、次の構成コンポーネントで構成されています。
2 つのグローバル外部 IP アドレス。それぞれのアベイラビリティ グループ（AG0 と AG1）から 1 つずつ。静的またはエフェメラルにできます。詳細については、IP アドレスをご覧ください。
2 つのグローバル外部 IP アドレス（各アベイラビリティ グループ（AG0 と AG1）から 1 つずつ）を指定する 1 つのグローバル転送ルール。この転送ルールを作成すると、 Google Cloud は高可用性を確保するために、可用性グループごとに 1 つずつ、2 つの読み取り専用の子転送ルールを生成します。詳細については、転送ルールをご覧ください。
複数のGoogle Cloud リージョンのバックエンドにトラフィックを分散する方法を定義する 1 つのグローバル バックエンド サービス。バックエンド グループは、すべてのインスタンス グループ（ゾーン マネージド インスタンス グループまたはゾーン非マネージド インスタンス グループ）またはすべてのゾーン NEG バックエンド（
GCE_VM_IPエンドポイントを含むゾーン NEG）のいずれかになります。詳細については、バックエンド サービスをご覧ください。バックエンド サービスに関連付けられたグローバル ヘルスチェック。詳細については、ヘルスチェックをご覧ください。
ロード バランシング トラフィックとヘルスチェック プローブがバックエンド VM に到達することを許可するファイアウォール ルール。詳細については、ファイアウォール ルールをご覧ください。
ダイレクト サーバー リターン
他のパススルー ネットワーク ロードバランサと同様に、グローバル外部パススルー ネットワーク ロードバランサはプロキシではありません。ロードバランサ自体はユーザー接続を終端しません。ロードバランスされたパケットは、元の送信元 IP アドレス、宛先 IP アドレス、プロトコル、ポート（該当する場合）のままバックエンド VM に送信されます。その後、バックエンド VM がユーザー接続を終端し、戻りパケットをクライアントに直接送信します。レスポンスはロードバランサを経由して戻りません。このプロセスはダイレクト サーバー リターン（DSR）といいます。
ロードバランサの IP アドレスのローカル ルーティング
グローバル外部パススルー ネットワーク ロードバランサは、他のパススルー ネットワーク ロードバランサと同様に、IP アドレスまたはポートの送信元 NAT または宛先 NAT を実行しません。
Google Cloud ゲスト環境は、各バックエンド VM をロードバランサの IP アドレスで構成します。VM のローカル ルーティング テーブルのエントリは、バックエンド VM のロード バランシングされたネットワーク インターフェース コントローラ（NIC）が、宛先 IP アドレスが各転送ルールの IP アドレスと一致するパケットを受け入れるように構成します。詳細については、ロードバランサの IP アドレスのローカル ルーティング テーブルを確認するをご覧ください。
リクエスト パケットと返信パケットの IP アドレス
バックエンド VM がクライアントからロードバランスされたパケットを受信すると、パケットの送信元と宛先は次のようになります。
- 送信元: クライアント、 Google Cloud VM、またはインターネット上のシステムに関連付けられている外部 IP アドレス。
- 宛先: ロードバランサの転送ルールの IP アドレスのいずれか。
ゲスト環境は、ロードバランサの IP アドレス宛てのトラフィックを VM のオペレーティング システムが受け入れるようにローカル ルートを自動的に構成しますが、アプリケーションが VM の割り当てられた内部 IP アドレスのみをリッスンするように構成されている場合、オペレーティング システムはこれらのパケットをアプリケーションに配信できません。
オペレーティング システムがパケットをアプリケーションに配信するようにするには、バックエンド VM で実行されているアプリケーションを次のように構成します。
- ロードバランサの転送ルールの IP アドレスまたは任意の IP アドレス（
0.0.0.0または::）をリッスン（バインド）する
- ロードバランサの転送ルールのプロトコルがポートをサポートしている場合は、ロードバランサの転送ルールのポートをリッスン（バインド）する
戻りパケットは、ロードバランサのバックエンド VM からクライアントに直接送信されます。戻りパケットの送信元 IP アドレスはプロトコルによって異なります。
- TCP は接続指向のため、バックエンド VM は、送信元 IP アドレスがリクエスト パケットの宛先 IP アドレスと一致するパケットで応答する必要があります。これにより、クライアントがレスポンス パケットを適切な TCP 接続に関連付けることができます。
- UDP、ESP、GRE、ICMP、ICMPv6 はコネクションレスです。バックエンド VM は、送信元 IP アドレスが転送ルールの IP アドレスまたは VM に割り当てられた外部 IP アドレスと一致するレスポンス パケットを送信できます。ほとんどのクライアントは、パケットの送信元と同じ IP アドレスからのレスポンスを想定しています。
次の表は、レスポンス パケットの送信元 IP アドレスと宛先 IP アドレスをまとめたものです。
| トラフィックの種類 | 送信元 | 宛先 |
|---|---|---|
| TCP | リクエスト パケットの宛先 | リクエスト パケットの送信元 |
| UDP、ESP、GRE、ICMP、ICMPv6 | ほとんどの場合、リクエスト パケットの宛先1 | リクエスト パケットの送信元 |
1 VM に外部 IP アドレスがある場合、または Cloud NAT を使用している場合は、レスポンス パケットの送信元 IP アドレスを VM NIC のプライマリ内部 IPv4 アドレスに設定することもできます。 Google Cloud または Cloud NAT は、レスポンス パケットの送信元 IP アドレスを NIC の外部 IPv4 アドレスまたは Cloud NAT 外部 IPv4 アドレスに変更して、レスポンス パケットをクライアントの外部 IP アドレスに送信します。クライアントはリクエスト パケットの宛先 IP アドレスと一致しない外部 IP アドレスからレスポンス パケットを受信するため、転送ルールの IP アドレスを送信元として使用しないのは高度なシナリオです。
コンポーネント
以降のセクションでは、グローバル外部パススルー ネットワーク ロードバランサの各構成コンポーネントについて詳しく説明します。
IP アドレス
グローバル外部パススルー ネットワーク ロードバランサは、高可用性を提供するために 2 つのグローバル外部 IP アドレスを必要とします。ロードバランサの転送ルールは、これらのアドレスを使用して受信トラフィックを受け入れます。これらのアドレスは、同じ IP バージョン（IPv4 または IPv6）に属している必要があります。 Google Cloud は、全世界のすべてのポイント オブ プレゼンスからロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスは、プレミアム ティアでのみサポートされるグローバル エニーキャスト IP アドレスです。
2 つの IP アドレスはそれぞれ、異なる可用性グループに属するグローバル外部 IP アドレス プールから取得する必要があります。IP アドレスは VPC ネットワーク内のサブネットに関連付けられていません。API では、可用性グループは globalAddresses リソースの purpose フィールドを使用して表されます。
PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP0: 可用性グループ 0 のアドレス。PASSTHROUGH_LOAD_BALANCER_AVAILABILITY_GROUP1: アベイラビリティ グループ 1 のアドレス。
転送ルール リソースの IPAddresses フィールドには、0 個、1 個、または 2 個の IP アドレスが指定されています。
- 省略すると、 Google Cloud は各可用性グループから 1 つずつ、2 つのエフェメラル IP アドレスを割り当てます。
- 1 つの可用性グループの既存の静的 IP アドレス リソースを参照する IP アドレスを 1 つ指定すると、 Google Cloud は他の可用性グループからエフェメラル IP アドレスを割り当てます。
- 既存の静的 IP アドレス リソースを参照する 2 つの IP アドレスを指定する場合は、異なるアベイラビリティ グループに属している必要があります。
転送ルールを削除した後もプロジェクトに関連付けたアドレスを保持しておく必要がある場合や、同じ IP アドレスを参照する複数の転送ルールが必要な場合は、転送ルールに予約済み静的 IP アドレスを使用します。
グローバル外部パススルー ネットワーク ロードバランサの転送ルールの場合、IP アドレスは次のいずれかになります。
- Google 所有のグローバル IP アドレスプールからの静的またはエフェメラル IPv4 アドレス。
- Google 所有のグローバル IP アドレス プールからの外部 IPv6 アドレスの静的またはエフェメラル
/96範囲。 - グローバル パブリック委任プレフィックスの静的 IPv4 BYOIP アドレス。
グローバル外部パススルー ネットワーク ロードバランサは、IPv4 アドレスの Bring your own IP addresses（BYOIP）のみをサポートします。サポートは v1 BYOIP API に限定されます。新しい IPv4 範囲のプロビジョニングには最大 4 週間かかることがあります。また、BGP アドバタイズメントのステータスを制御できる API はありません。詳細については、お客様所有 IP アドレスの使用をご覧ください。
転送ルールの IPAddresses フィールドは作成時にのみ設定でき、更新することはできません。
Google Cloud のグローバル外部 IP アドレスは、その発信元（Google 所有または BYOIP）に関係なく、次の 3 種類のグローバル外部 IP アドレスプールのいずれかから取得されます。
- グローバル外部パススルー ネットワーク ロードバランサが可用性グループ AG0 に使用する IP アドレス プール
- グローバル外部パススルー ネットワーク ロードバランサが可用性グループ AG1 に使用する IP アドレス プール
- グローバル外部プロキシベースのロードバランサで使用される IP アドレスプール
そのため、グローバル外部パススルー ネットワーク ロードバランサは、他のグローバル ロードバランサやリージョン ロードバランサと IP アドレスを共有できません。
グローバル転送ルール
グローバル外部パススルー ネットワーク ロードバランサの転送ルールは、ロードバランサのフロントエンドを形成し、ロードバランサがトラフィックを受け入れる宛先 IP アドレス、プロトコル、ポートを指定します。グローバル外部パススルー ネットワーク ロードバランサはプロキシではないため、プロトコルにポート情報が含まれている場合は、送信元 IP アドレス、宛先 IP アドレス、プロトコル、ポートを変更せずにバックエンドにトラフィックを転送します。
構成するグローバル外部パススルー ネットワーク ロードバランサの転送ルールでは、次の内容を指定します。
- ロード バランシング スキームは
EXTERNAL_PASSTHROUGHに指定されています。 IPAddresses[]フィールドのグローバル IP アドレスのペア（各アベイラビリティ グループから 1 つずつ）。- プロトコル（
TCP、UDP、L3_DEFAULT）とポート。
作成するグローバル外部パススルー ネットワーク ロードバランサの転送ルール（親転送ルールとも呼ばれます）ごとに、 Google Cloudはロード バランシング スタック（AVAILABILITY_GROUP0 と AVAILABILITY_GROUP1）ごとに 2 つの読み取り専用の子転送ルールを生成します。子転送ルールには、親転送ルールと同じ IP プロトコル、ポート、バックエンド サービスの設定がありますが、親転送ルールの 2 つの IP アドレスのうちの 1 つのみが含まれています。
子転送ルールは、親転送ルール名に -ag0 と -ag1 が付加されているため、一意に識別できます。追加の割り当てを消費したり、追加の費用が発生したりすることはありません。モニタリング指標と健全性ステータスは、子転送ルールレベルで報告されます。
受信トラフィックは転送ルールと照合されます。パケットの宛先 IP アドレス、プロトコル、ポートが、転送ルール フィールド（2 つの IP アドレス、プロトコル、プロトコルがポートベースの場合はポート、ポート範囲、またはすべてのポート）の組み合わせと照合されます。その後、この転送ルールによって、ロードバランサのバックエンド サービスにトラフィックが転送されます。
グローバル外部パススルー ネットワーク ロードバランサの転送ルールは、IPv4 アドレスまたは IPv6 アドレスで構成できます。ロードバランサに IPv4 と IPv6 の両方のトラフィックを処理する場合は、次の 2 つの転送ルールを作成します。
IPv4 のみまたはデュアルスタック バックエンドを指す IPv4 トラフィックの転送ルール
IPv6 のみまたはデュアルスタック バックエンドを指す IPv6 トラフィックの転送ルール
IPv4 と IPv6 の転送ルールが同じバックエンド サービスを参照できますが、バックエンド サービスがデュアルスタック VM ネットワーク インターフェースを持つバックエンドを参照する必要があります。
転送ルールの IP バージョンは、バックエンド VM ネットワーク インターフェースのスタックタイプと一致する必要があります。
| バックエンド VM ネットワーク インターフェースのスタックタイプ | 転送ルール |
|---|---|
IPv4 専用（IPV4_ONLY）VM ネットワーク インターフェース |
IPv4 転送ルールのバックエンドのみにできます。 |
IPv6 専用（IPV6_ONLY）VM ネットワーク インターフェース |
IPv6 転送ルールのバックエンドのみにできます。 |
デュアルスタック（IPV4_IPV6）VM ネットワーク インターフェース |
IPv4 転送ルール、IPv6 転送ルール、またはその両方のバックエンドにできます。 |
転送ルール プロトコル
グローバル外部パススルー ネットワーク ロードバランサは、転送ルールごとに TCP、UDP、L3_DEFAULT のプロトコル オプションをサポートしています。
TCP または UDP ロード バランシングを構成するには、それぞれ TCP オプションと UDP オプションを使用します。L3_DEFAULT プロトコル オプションを使用すると、グローバル外部パススルー ネットワーク ロードバランサは TCP、UDP、ESP、GRE、ICMP、ICMPv6 のトラフィックをロードバランスできます。
TCP と UDP 以外のプロトコルがサポートされるだけでなく、L3_DEFAULT では 1 つの転送ルールで複数のプロトコルを処理できます。たとえば、IPsec サービスは通常、ESP と UDP ベースの IKE、NAT-T のトラフィックの組み合わせを処理します。L3_DEFAULT オプションを使用すると、これらのプロトコルをすべて処理する単一の転送ルールを構成できます。
L3_DEFAULT プロトコルを使用している場合は、すべてのポートでトラフィックを受け入れるように転送ルールを構成する必要があります。L3_DEFAULT は包括的なルールであるため、セキュリティのベスト プラクティスとして、必要な IP プロトコルとポートのみを許可する上り（内向き）許可のファイアウォール ルールを構成する必要があります。
複数の転送ルール
複数の転送ルールを構成できます。転送ルールには次の 2 種類があります。
同じ IP アドレスに対する複数の転送ルール。同じプロトコルとポートの組み合わせを使用する転送ルールが 2 つない限り、同じ IP アドレス ペアに複数の転送ルールを構成できます。各転送ルールに異なるバックエンド サービスを指定することも、複数の転送ルールに同じバックエンド サービスを指定することもできます。
同じバックエンド サービスを参照する複数の転送ルール。同じバックエンド サービスを参照する複数の転送ルールを構成できます。最初のポイントで説明した条件に従って、2 つ以上の転送ルールで同じ IP アドレス ペアを使用することも、各転送ルールで一意の IP アドレス ペアを使用することもできます。同じバックエンド サービスを参照するすべての転送ルールのすべての IP アドレスのトラフィックは、バックエンド ターゲット容量を公平に共有します。
ただし、グローバル外部パススルー ネットワーク ロードバランサとグローバル外部アプリケーション ロードバランサまたはグローバル外部プロキシ ネットワーク ロードバランサの間で同じグローバル外部 IP アドレスを共有することはできません。
複数の転送ルールを使用する場合は、バックエンド VM で実行されるアプリケーションを、ロードバランサの転送ルールのすべての外部 IP アドレスにバインドされるように構成します。
複数の転送ルールを構成すると、次のような場合に便利です。
- 同じバックエンド サービスに複数の外部 IP アドレスのペアを構成する必要がある。たとえば、IPv4 アドレス用の転送ルールと IPv6 アドレス用の転送ルールなどです。
- 同じ外部 IP アドレス ペアに対して、異なるプロトコルまたは重複しないポートまたはポート範囲を使用して複数の転送ルールを構成する必要があります。転送ルールでは、同じバックエンド サービスまたは異なるバックエンド サービスを使用できます。
複数の転送ルールのプロトコルとポートの制約
Google Cloud は、受信パケットを処理する転送ルールを最大 1 つ選択します。同じグローバル外部 IP アドレス ペアを使用する 2 つ以上の転送ルールには、制約に応じて一意のプロトコルとポートの組み合わせを設定する必要があります。1 つのプロトコルのすべてのポートに 1 つの転送ルールを構成すると、同じプロトコルと IP アドレスのペアを使用して他の転送ルールが作成できなくなります。
TCPプロトコルまたはUDPプロトコルを使用した転送ルールは、すべてのポートを使用するように構成することも、特定のポートに対して構成することもできます。たとえば、IP アドレス ペア
136.124.69.214と136.124.83.205、TCPプロトコル、すべてのポートを使用して転送ルールを作成する場合、同じ IP アドレス ペアとTCPプロトコルを使用して、他の転送ルールを作成することはできません。それぞれ一意のポートがあるか、重複しないポート範囲がある場合は、IP アドレス ペアと
TCPプロトコルを使用して 2 つの転送ルールを作成できます。たとえば、同じ IP アドレス ペアとTCPプロトコルを使用して 2 つの転送ルールを作成できますが、1 つの転送ルールのポートは80,443を使用し、もう 1 つはポート範囲81-442を使用します。IP アドレスのペアごとに作成可能な
L3_DEFAULT転送ルールは 1 つだけです。これは、
L3_DEFAULTプロトコルが定義上すべてのポートを使用するためです。ここで、「すべてのポート」という用語にはポート情報のないプロトコルも含まれます。1 つの
L3_DEFAULT転送ルールは、特定のプロトコル（TCPまたはUDP）と同一の IP アドレス ペアを使用する他の転送ルールと共存できます。IP アドレスのペアに特定の TCP または UDP 転送ルールが関連付けられている場合は、同じ IP アドレスのペアに
L3_DEFAULT転送ルールを関連付けて、特定の転送ルールと一致しないトラフィックのフォールバックとして機能させることもできます。L3_DEFAULT転送ルールは、パケットの宛先 IP アドレス、プロトコル、宛先ポートがプロトコル固有の転送ルールと一致しない場合にのみ、宛先 IP アドレスに送信されるパケットを処理します。次の 2 つのシナリオについて考えてみましょう。どちらのシナリオでも、転送ルールは同じ IP アドレス ペア（
136.124.69.214と136.124.83.205）を使用します。シナリオ 1: 最初の転送ルールは
L3_DEFAULTプロトコルを使用します。2 つ目の転送ルールは、TCPプロトコルとすべてのポートを使用します。いずれかの IP アドレスの宛先ポートに送信された TCP パケットは、2 番目のより具体的な転送ルールによって処理されます。異なるプロトコルを使用するパケットは最初の転送ルールによって処理されます。シナリオ 2: 最初の転送ルールは
L3_DEFAULTプロトコルを使用します。2 つ目の転送ルールは、TCPプロトコルとポート8080を使用します。いずれかの IP アドレスのポート 8080 に送信された TCP パケットは、2 番目の転送ルールによって処理されます。別の宛先ポートに送信された TCP パケットなど、他のパケットはすべて最初の転送ルールによって処理されます。
転送ルールの選択
Google Cloud は、次の除外プロセスを使用して、パケットの宛先 IP アドレスに一致する転送ルールの候補の中から、受信パケットを処理する 1 つまたは 0 個の転送ルールを選択します
L3_DEFAULT転送ルールを除き、プロトコルがパケットのプロトコルと一致しない転送ルールを除外します。L3_DEFAULTプロトコルを使用した転送ルールは、L3_DEFAULTがすべてのプロトコルと一致するため、このステップで除外されることはありません。たとえば、パケットのプロトコルが TCP の場合、UDPプロトコルを使用する転送ルールのみが除外されます。ポートがパケットのポートと一致しない転送ルールを除外します。すべてのポート転送ルールは任意のポートと一致するため、このステップですべてのポートに構成された転送ルールが除外されることはありません。
この時点で、残りの転送ルールの候補は次のいずれかに分類されます。
L3_DEFAULT転送ルールとプロトコル固有の転送ルールの 2 つの転送ルールが残ります。プロトコル固有の転送ルールを使用してパケットを転送します。L3_DEFAULT転送ルールまたはプロトコル固有の転送ルールのいずれか 1 つの転送ルールが残ります。パケットのルーティングに使用されます。転送ルールの候補は残り、パケットは破棄されます。
グローバル バックエンド サービス
グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスは、複数の Google Cloud リージョンに存在するアタッチされたバックエンドに受信トラフィックを分散します。各バックエンドは、インスタンス グループまたはネットワーク エンドポイント グループと、バックエンドの処理能力に関する情報で構成されます。バックエンドの処理能力は、CPU 使用率、1 秒あたりの受信パケット数（PPS）、またはその両方に基づいて設定できます。バックエンド サービスは、構成されたアフィニティと容量の設定に従ってトラフィック分配を管理します。
バックエンド サービスは、次のバックエンド パラメータを定義します。
ロード バランシング スキーム。グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスを指定するには、ロード バランシング スキームを明示的に
EXTERNAL_PASSTHROUGHに設定する必要があります。プロトコル。バックエンド サービス プロトコル フィールドは冗長であり、
UNSPECIFIEDにのみ設定できます。UNSPECIFIEDプロトコルのバックエンド サービスは、転送ルール プロトコルに関係なく、どの転送ルールでも使用できます。トラフィック分散。バックエンド サービスは、構成されたセッション アフィニティ、接続トラッキング ポリシー、ロード バランシング モードとバックエンド容量、ロード バランシング局所性ポリシーに従ってトラフィックを分散します。コネクション ドレインを有効にして、バックエンド容量を減らすように、バックエンド サービスを構成することもできます。これらの設定のほとんどにはデフォルト値が用意されているため、直ちに利用を開始できます。
ヘルスチェック。バックエンド サービスには、関連付けられたヘルスチェックが必要です。
バックエンド: バックエンドは、ロードバランスされたトラフィックを受信する実際のエンドポイントです。グローバル外部パススルー ネットワーク ロードバランサは、複数の Google Cloud リージョンにあるインスタンス グループまたはゾーン NEG にトラフィックを分散できます。
インスタンス グループを選択した場合は、ゾーン マネージド インスタンス グループ、ゾーン非マネージド インスタンス グループ、またはインスタンス グループ タイプの組み合わせを使用できます。インスタンス グループは、ロード バランシング モードとして
RATEとUTILIZATIONの両方をサポートしています。ゾーン NEG を選択する場合は、
GCE_VM_IPゾーン NEG を使用する必要があります。NEG は、ロード バランシング モードとしてRATEのみをサポートします。
転送ルールとの VM ネットワーク インターフェースの互換性
グローバル外部パススルー ネットワーク ロードバランサはトラフィックを終端または変換しないため、バックエンド VM のネットワーク インターフェースのスタックタイプは、転送ルールの IP アドレス バージョンと互換性がある必要があります。
| 転送ルール | バックエンド VM のネットワーク インターフェースのスタックタイプ |
|---|---|
| IPv4 転送ルールのみ | IPv4 のみ（IPV4_ONLY）またはデュアルスタック（IPV4_IPv6） |
| IPv6 転送ルールのみ | IPv6 のみ（IPV6_ONLY）またはデュアル スタック（IPV4_IPv6） |
| IPv4 と IPv6 の転送ルール | デュアルスタック（IPV4_IPv6） |
バックエンド VM のネットワーク インターフェースと VPC サブネットの互換性
上記の表に示すように、IPv4 のみのインターフェース、デュアルスタック インターフェース、IPv6 のみのインターフェースを含むバックエンドを持つように、グローバル外部パススルー ネットワーク ロードバランサを構成できます。次の表に、各 VPC サブネット スタックタイプと互換性のあるバックエンド VM のネットワーク インターフェース タイプをまとめます。
| VPC サブネットのスタックタイプ | バックエンド VM のネットワーク インターフェースのスタックタイプ |
|---|---|
IPV4_ONLY（シングルスタック）IPv4 サブネット範囲のみ |
IPv4 のみ（IPV4_ONLY） |
IPV4_IPV6（デュアル スタック）IPv4 と IPv6 の両方のサブネット範囲 |
IPv4 のみ（IPV4_ONLY）、デュアル スタック（IPV4_IPv6）、IPv6 のみ（IPV6_ONLY） |
IPV6_ONLY（シングルスタック）IPv6 サブネット範囲のみ |
IPv6 のみ（IPV6_ONLY） |
次の点にご注意ください。
VM ネットワーク インターフェースに割り当てられた IP アドレスは、基盤となる VPC サブネットから直接割り当てられます。
IPv6 接続の場合、VM ネットワーク インターフェースが IPv6 対応の
/64サブネットに割り当てられると、 Google Cloud はサブネットの/64外部 IPv6 アドレス範囲の前半（/65）から VM ネットワーク インターフェースに/96アドレス範囲を割り当てます。詳細については、外部 IPv6 仕様をご覧ください。VM ネットワーク インターフェースのスタックタイプがデュアルスタック（
IPV4_IPv6）または IPv6 専用（IPV6_ONLY）の場合、VPC サブネットの--ipv6-access-type設定をEXTERNALまたはINTERNALに構成して、VM ネットワーク インターフェースの IPv6 アドレスに到達する方法を選択する必要があります。サブネットの--ipv6-access-typeがEXTERNALに設定されている場合は、VM のネットワーク インターフェースの--ipv6-network-tierもPREMIUMに設定する必要があります。詳細については、IPv6 サブネットの範囲をご覧ください。
インスタンス グループのバックエンドとネットワーク インターフェース
インスタンス グループに関連付けられている VPC ネットワークとサブネットは、インスタンス グループのバックエンドとネットワーク インターフェースの説明に従って暗黙的に設定されます。
ロードバランスされたトラフィックをnic0 以外のロードバランサ ターゲット インターフェースに分散する場合、インスタンス グループのバックエンドは使用できません。代わりに GCE_VM_IP エンドポイントを使用するゾーン NEG を使用してください。詳細については、バックエンド サービスと VPC ネットワークをご覧ください。
ゾーン NEG バックエンドとネットワーク インターフェース
GCE_VM_IP エンドポイントを含むゾーン NEG に関連付けられた VPC ネットワークとサブネットは、NEG の作成時に設定されます。エンドポイントの詳細とルールについては、GCE_VM_IP ゾーン NEG バックエンドとネットワーク インターフェースをご覧ください。
バックエンド サービスと VPC ネットワーク
バックエンド サービスは VPC ネットワークに関連付けられていませんが、先ほど説明したとおり、各バックエンド インスタンス グループまたはゾーン NEG は VPC ネットワークに関連付けられています。すべてのバックエンドが同じプロジェクトに存在し、すべてのバックエンドが同じタイプ（インスタンス グループまたはゾーン NEG）である限り、ロードバランサとそのバックエンドは同じ VPC ネットワークに存在しても、異なる VPC ネットワークに存在してもかまいません。
nic0 以外のインターフェースにパケットを配信するには、次の両方の要件を満たす必要があります。
インスタンス グループではなく、ゾーン NEG（
GCE_VM_IPエンドポイントを使用）を使用する必要があります。nic0以外のインターフェースは、ロードバランサ ターゲット インターフェースである必要があります。詳細については、GCE_VM_IPゾーン NEG バックエンドとネットワーク インターフェースをご覧ください。
ヘルスチェック
ヘルスチェック情報は、新しい接続の適格なバックエンドを特定し、異常なバックエンドで既存の接続を維持するかどうかを制御するために使用されます。ロードバランサは、転送ルールの IP アドレスごとにヘルスチェック プローブを個別に送信します。したがって、2 つの IP アドレスを持つグローバル外部パススルー ネットワーク ロードバランサの転送ルールは、各 IP アドレスに対してプローブされ、各バックエンドのプローブ頻度が 2 倍になります。詳細については、複数のプローブと頻度をご覧ください。
ヘルスチェックのタイプ、プロトコル、ポート
ロードバランサのバックエンド サービスは、サポートされている任意のヘルスチェック プロトコルとポートを使用して、グローバル ヘルスチェックを参照する必要があります。ヘルスチェック プロトコルとポートの詳細は、転送ルールのプロトコルとポートの情報に一致する必要はありません。
サポートされているすべてのヘルスチェック プロトコルは TCP に依存しているため（UDP ヘルスチェックはサポートされていません）、グローバル外部パススルー ネットワーク ロードバランサを使用して他のプロトコルの接続とトラフィックをバランシングする場合は、バックエンド VM で TCP ベースのサーバーを実行してヘルスチェック プローバーに応答する必要があります。たとえば、HTTP ヘルスチェックと、各バックエンド VM での HTTP サーバーの実行を組み合わせて使用できます。この例では、スクリプトまたはソフトウェアが HTTP サーバーを構成し、ロード バランシングされた接続をリッスンするソフトウェアが動作している場合にのみステータス 200 を返すようにします。
サポートされているヘルスチェック プロトコルとポートの詳細については、ヘルスチェックのカテゴリ、プロトコル、ポートとヘルスチェックの仕組みをご覧ください。
ヘルスチェック パケット
インスタンス グループのバックエンドの場合、ヘルスチェック プローバーは各バックエンド VM の nic0 ネットワーク インターフェースにパケットを送信します。GCE_VM_IP ゾーン NEG バックエンドの場合、ヘルスチェック プローバーは NEG の VPC サブネットワーク内のネットワーク インターフェースにパケットを送信します。ヘルスチェック パケットには次の特性があります。
- 関連するヘルスチェック プローブ IP 範囲の送信元 IP アドレス。
- グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスを参照する転送ルールの 2 つの IP アドレスのいずれかと一致する宛先 IP アドレス。ヘルスチェック パケットは両方の IP アドレスに送信されます。
- ヘルスチェックで指定したポート番号と一致する宛先ポート。
バックエンド VM で実行されるアプリケーションは、関連 IP アドレスと関連ポートの組み合わせにバインドしてリッスンする必要があります。これを行うには、VM の IP アドレス（0.0.0.0 または ::/0）の関連ポートにバインドしてリッスンするようにアプリケーションを構成します。詳細については、プローブ パケットの宛先をご覧ください。
ファイアウォール ルール
グローバル外部パススルー ネットワーク ロードバランサはプロキシではないため、プロトコルにポート情報が含まれている場合、送信元 IP アドレス、宛先 IP アドレス、プロトコル、ポートを変更せずにトラフィックをバックエンド VM に渡します。したがって、ロードバランサのバックエンド VM へのアクセスを制御するには、上り（内向き）許可のファイアウォール ルールまたは上り（内向き）許可の階層型ファイアウォール ポリシーを作成する必要があります。具体的には、ヘルスチェックとロード バランシングするトラフィックを許可します。それ以外の場合、上り（内向き）をすべて拒否する暗黙のファイアウォール ルールによって、すべての外部送信元 IP アドレスからの受信パケットがブロックされます。
転送ルールと上り（内向き）許可のファイアウォール ルールまたは階層型ファイアウォール ポリシーは、次のように連携します。転送ルールでは、バックエンド VM に転送するために、パケットが適合する必要がある宛先 IP アドレス、プロトコル、ポート要件（定義されている場合）が定義されます。上り（内向き）許可のファイアウォール ルールでは、転送されたパケットを VM に配信するか、ドロップするかを制御します。 Google Cloud のデフォルト VPC ネットワークには、事前入力された上り（内向き）許可のファイアウォール ルールが一部含まれています。
インターネット上の任意の IP アドレスからのトラフィックを受信するには、
0.0.0.0/0または::/0ソース範囲を使用して上り（内向き）許可ファイアウォール ルールを作成する必要があります。特定の IP アドレス範囲からのトラフィックのみを許可するには、使用するソース範囲の制限を厳しくします。セキュリティのベスト プラクティスとして、上り（内向き）許可のファイアウォール ルールでは、必要な IP プロトコルとポートのみを許可してください。プロトコルが
L3_DEFAULTに設定されている転送ルールを使用する場合は、プロトコル（および可能であればポート）の構成を制限することが特に重要です。L3_DEFAULT転送ルールによって、サポートされているすべての IP プロトコルのパケットが転送されます（プロトコルとパケットにポート情報が存在する場合は、すべてのポート上で転送されます）。グローバル外部パススルー ネットワーク ロードバランサは Google Cloud ヘルスチェックを使用します。したがって、ヘルスチェックの IP アドレス範囲からのトラフィックは常に許可する必要があります。これらの上り（内向き）許可ファイアウォール ルールは、ロードバランサのヘルスチェックのプロトコルとポートに固有のルールとして構成できます。
トラフィック分散
グローバル外部パススルー ネットワーク ロードバランサの場合、トラフィック分配は、セッション アフィニティ、接続トラッキング ポリシー、ロード バランシング モードとバックエンド容量、ロード バランシングの局所性ポリシーなどのさまざまな属性の関数です。これらはすべて、信頼性の高いパフォーマンスと効率的なリソース使用率を実現するためにロード バランシング構成を最適化する、調整されたワークフローの一部として機能します。
共有 VPC アーキテクチャ
グローバル外部パススルー ネットワーク ロードバランサの共有 VPC アーキテクチャについては、次の点に注意してください。
IP アドレス リソースを除き、グローバル外部パススルー ネットワーク ロードバランサに関連付けられた他のすべてのリソース（転送ルール、バックエンド サービス、ヘルスチェック、バックエンド グループ（インスタンス グループまたは NEG））は、同じプロジェクトに存在する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。
ロード バランシング リソースがホスト プロジェクトに存在する場合、IP アドレス リソースもホスト プロジェクトに存在する必要があります。
ロード バランシング リソースがサービス プロジェクトに存在する場合、IP アドレス リソースは同じサービス プロジェクトまたはホスト プロジェクトに存在できます。
次の表は、共有 VPC アーキテクチャにおけるグローバル外部パススルー ネットワーク ロードバランサのさまざまなコンポーネントの存在場所を示しています。
| ロード バランシング リソースのロケーション1 | IP アドレス リソースの必要なロケーション |
|---|---|
| ホスト プロジェクト | ホスト プロジェクト |
| サービス プロジェクト | サービス プロジェクトまたはホスト プロジェクト |
1 転送ルール、バックエンド サービス、ヘルスチェック、バックエンド（インスタンス グループまたは NEG）が含まれます。
制限事項
バックエンドは、次の Google Cloud リージョンにのみデプロイできます。
- 北米:
us-west1、us-west4、us-east4、us-east5 - ヨーロッパ:
europe-west2、europe-west3 - アジア:
asia-southeast1、asia-south1、asia-northeast1 - 南米:
southamerica-east1 - アフリカ:
africa-south1 - オーストラリア:
australia-southeast1
- 北米:
グローバル外部パススルー ネットワーク ロードバランサは、プレミアム ティアでのみ構成できます。
Google Cloud コンソールを使用してグローバル外部パススルー ネットワーク ロードバランサを構成することはできません。代わりに、Google Cloud CLI または REST API を使用してください。
リージョン マネージド インスタンス グループのバックエンドは使用できません。ゾーン マネージド インスタンス グループ、ゾーン非マネージド インスタンス グループ、
GCE_VM_IPエンドポイントを含むゾーン NEG を使用できます。既存のバックエンド サービスでインスタンス グループを使用する場合の制限とガイダンスは、グローバル外部パススルー ネットワーク ロードバランサにも適用されます。グローバル外部パススルー ネットワーク ロードバランサとリージョン パススルー ネットワーク ロードバランサ（リージョン外部パススルー ネットワーク ロードバランサまたは内部パススルー ネットワーク ロードバランサ）間で共有されるインスタンス グループは、グローバル外部パススルー ネットワーク ロードバランサで
RATEバランシング モードを使用するように構成する必要があります。リージョン パススルー ネットワーク ロードバランサは常にCONNECTIONバランシング モードを使用します。構成されたプロトコルとポートが競合しない限り、複数のグローバル外部パススルー ネットワーク ロードバランサ転送ルール間で同じグローバル外部 IP アドレスを共有できます。ただし、グローバル外部パススルー ネットワーク ロードバランサとグローバル外部アプリケーション ロードバランサまたはグローバル外部プロキシ ネットワーク ロードバランサの間で同じグローバル外部 IP アドレスを共有することはできません。
グローバル外部パススルー ネットワーク ロードバランサは、IPv4 アドレスの Bring your own IP addresses（BYOIP）のみをサポートします。サポートは v1 BYOIP API に限定されます。新しい IPv4 範囲のプロビジョニングには最大 4 週間かかることがあります。また、BGP アドバタイズメントのステータスを制御できる API はありません。詳細については、お客様所有 IP アドレスの使用をご覧ください。
プロジェクトで作成できる転送ルールは 10 個までです。また、バックエンド サービスに追加できるバックエンド グループは 25 個までです。詳細については、割り当てと制限をご覧ください。
GKE にグローバル外部パススルー ネットワーク ロードバランサをデプロイすることはできません。
Google Cloud Armor を使用して、グローバル外部パススルー ネットワーク ロードバランサに高度なネットワーク DDoS 対策を提供することはできません。詳細については、高度なネットワーク DDoS 対策を構成するをご覧ください。
ロードバランサのバックエンド サービスで構成されたロード バランシング局所性ポリシーは、
WEIGHTED_MAGLEVオプションをサポートしていません。グローバル外部パススルー ネットワーク ロードバランサの場合、MAGLEVのみがサポートされます。PER_SESSION接続トラッキング モードはサポートされていません。PER_CONNECTION接続トラッキング モードのみがサポートされています。サポートされているのは、次のロード バランシング モードのみです。
RATEとUTILIZATION。レートは、1 秒あたりのリクエスト数ではなく、1 秒あたりの受信パケット数で定義されます。インスタンス グループはRATEとUTILIZATIONの両方をサポートしますが、NEG はRATEのみをサポートします。ステアリング転送ルール（送信元 IP ベースのトラフィック ステアリング）はサポートされていません。
バックエンド サービスに接続されているすべてのバックエンドは同じタイプである必要があります。バックエンド サービスにインスタンス グループとゾーン NEG を混在させることはできません。
モニタリング指標は、親グローバル転送ルールを使用してクエリまたはフィルタできません。 Google Cloudで生成された子転送ルールを使用してクエリする必要があります。
料金
料金については、ネットワーク料金: Cloud Load Balancing をご覧ください。
次のステップ
- VM インスタンス グループのバックエンドを使用してグローバル外部パススルー ネットワーク ロードバランサを設定する
- ゾーン NEG バックエンドを使用してグローバル外部パススルー ネットワーク ロードバランサを設定する
- パススルー ネットワーク ロードバランサのバランシング モード
- グローバル外部パススルー ネットワーク ロードバランサのターゲット容量の仕様
- Cloud Load Balancing API と gcloud CLI のリファレンス