グローバル外部パススルー ネットワーク ロードバランサの概要

グローバル外部パススルー ネットワーク ロードバランサは、複数の 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 リージョン Google Cloud のバックエンドに低レイテンシでトラフィックを配信する必要があります。

  • デプロイは、リージョンのバックエンドの障害と過負荷に対して復元力があり、使用可能な容量のある次に近いリージョンにトラフィックを自動的かつ正常にリダイレクトする必要があります。

グローバル外部パススルー ネットワーク ロードバランサを使用するには、デプロイが次の要件を満たしている必要があります。

  • TLS（SSL）トラフィックを処理する場合は、バックエンドで SSL トラフィックを終端する必要があります。グローバル外部パススルー ネットワーク ロードバランサは、SSL 終端をサポートしていません。

主な機能

グローバル外部パススルー ネットワーク ロードバランサは、次の主な機能をサポートしています。

高可用性を実現する設計

ロードバランサは、2 つのグローバル外部エニーキャスト IP アドレスを提供します。それぞれが、高可用性を実現するために、分離されたグローバル ロード バランシング コントロール プレーンとデータプレーンのサーバー インフラストラクチャ（可用性グループとも呼ばれます）によって提供されます。クライアントは、いずれかの IP アドレスを使用して、使用可能な容量を持つ最も近い正常なバックエンドに接続できます。

ロードバランサを使用すると、複数のリージョンにバックエンドがあるグローバル バックエンド サービスを作成するときに、サービスの可用性を向上させることができます。 Google Cloud 特定のリージョンのバックエンドが停止した場合、トラフィックは次に近いリージョンに正常にフェイルオーバーされます。

すべてのバックエンドを単一の Google Cloud リージョンで構成することはできますが、リージョン停止に対する復元性を確保するため、少なくとも 3 つの Google Cloud リージョンにバックエンドをデプロイすることをおすすめします。

レイテンシと負荷認識のバランシング

グローバル外部パススルー ネットワーク ロードバランサは、プレミアム ティアのみを使用します。プレミアム ティアでは、インターネットから受信したトラフィックが、ユーザーに最も近いポイント オブ プレゼンス（PoP）から Googleの高性能低レイテンシ ネットワークに入ります。同様に、アウトバウンド トラフィックは Googleのネットワークを通り、ユーザーに最も近い POP から出ていきます。

グローバルに分散された Maglev ロードバランサは、トラフィックがGoogleのネットワークに入る PoP に最も近いGoogle Cloud リージョンに受信トラフィックを転送します。ただし、そのリージョンに利用可能な容量を持つ正常なバックエンドがある場合に限ります。それ以外の場合、ロードバランサは、使用可能な容量を持つ正常なバックエンドがある次に近いリージョンにトラフィックを自動的かつ正常にスピルオーバーします。

パケット レイテンシとバックエンド効率を最適化するために、バックエンドのプレースメントと容量を決定します。バックエンドの容量は、最大受信 PPS（1 秒あたりのパケット数）レート、最大 CPU 使用率、またはその両方に基づいて設定できます。バックエンド サービスで構成されたバックエンド容量は、そのバックエンド サービスを参照するすべての転送ルールの IP アドレス間で公平に共有されます。

グローバル外部パススルー ネットワーク ロードバランサの仕組み

グローバル外部パススルー ネットワーク ロードバランサには、フロントエンド（転送ルール）とバックエンド（バックエンド サービスとそのバックエンド グループ）があります。バックエンド グループとしてインスタンス グループまたは GCE_VM_IP ゾーン NEG を使用できます。

アーキテクチャ

次の図は、複数の Google Cloud リージョンのバックエンドにトラフィックを分散するグローバル外部パススルー ネットワーク ロードバランサを示しています。ロードバランサが作成されると、 Google Cloud は、分離されたコントロール プレーンとデータプレーンのインフラストラクチャ（可用性グループ AG0 と AG1 とも呼ばれます）によって提供される 2 つのグローバル外部エニーキャスト IP アドレスを割り当てます。

2 つのコントロール プレーンとデータプレーンにより、すべてのグローバル外部パススルー ネットワーク ロードバランサで高可用性、フォールト トレランス、復元力が実現します。1 つのアベイラビリティ グループのコントロール プレーンまたはデータプレーンで障害が発生しても、他のアベイラビリティ グループには影響しません。正しく構成されたクライアントは、ロードバランサの両方の IP アドレスに接続できる必要があります。たとえば、クライアントが AG0 IP アドレスに接続できない場合は、代わりに AG1 IP アドレスに接続するように構成する必要があります。

グローバル外部パススルー ネットワーク ロードバランサは、`us-west1` リージョンと `europe-west2` リージョンにデプロイされた VM インスタンス グループのバックエンドにトラフィックを送信します。
グローバル外部パススルー ネットワーク ロードバランサのアーキテクチャ（クリックして拡大）

ロードバランサは、次の構成コンポーネントで構成されています。

  • 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 のローカル ルーティング テーブルのエントリは、宛先 IP アドレスが各転送ルールの IP アドレスと一致するパケットを受信するように、バックエンド VM のロード バランシングされたネットワーク インターフェース コントローラ（NIC）を構成します。詳細については、ロードバランサの IP アドレスのローカル ルーティング テーブルを確認するをご覧ください。

リクエスト パケットと返信パケットの IP アドレス

バックエンド VM がクライアントからロードバランスされたパケットを受信すると、パケットの送信元と宛先は次のようになります。

  • 送信元: クライアント、 Google Cloud VM、またはインターネット上のシステムに関連付けられている外部 IP アドレス。
  • 宛先: ロードバランサの転送ルールの 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 サブネットの範囲をご覧ください。

インスタンス グループのバックエンドとネットワーク インターフェース

特定の（マネージドまたは非マネージド）インスタンス グループ内で、各メンバー VM の nic0 ネットワーク インターフェースは常に同じ VPC ネットワークに存在します。

  • マネージド インスタンス グループ（MIG）の場合、インスタンス グループの VPC ネットワークは、インスタンス テンプレートで定義された nic0 インターフェースから取得されます。
  • 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、非マネージド インスタンス グループに追加する最初の VM インスタンスの nic0 ネットワーク インターフェースで使用される VPC ネットワークに設定されます。グループに追加した最初のインスタンスを削除しても、インスタンス グループの VPC ネットワークを後で変更することはできません。

メンバー VM は、追加のネットワーク インターフェース（vNIC または Dynamic Network Interface）を持つことができます。nic0 以外の各インターフェースは、インスタンス グループの VPC ネットワーク（nic0 インターフェースで使用されるネットワーク）または別の VPC ネットワークに存在できます。

ロードバランスされたトラフィックを nic0 以外のネットワーク インターフェースに分散する場合、インスタンス グループ バックエンドは使用できません。代わりに GCE_VM_IP エンドポイントを使用するゾーン NEG を使用してください。詳細については、バックエンド サービスと VPC ネットワークをご覧ください。

ゾーン NEG バックエンドとネットワーク インターフェース

GCE_VM_IP エンドポイントを含む新しいゾーン NEG を作成する場合は、NEG にエンドポイントを追加する前に、NEG を VPC ネットワークのサブネットワークに明示的に関連付ける必要があります。NEG の作成後にサブネットと VPC ネットワークを変更することはできません。

特定の NEG 内では、各 GCE_VM_IP エンドポイントは実際にはネットワーク インターフェースを表します。ネットワーク インターフェースは、NEG に関連付けられたサブネットワークに存在する必要があります。Compute Engine インスタンスの観点からは、ネットワーク インターフェースは任意の識別子を使用できます。NEG のエンドポイントであるという観点からは、ネットワーク インターフェースはプライマリ内部 IPv4 アドレスを使用して識別されます。詳細については、GCE_VM_IP エンドポイントを含む NEG をご覧ください。

GCE_VM_IP エンドポイントを NEG に追加するには、次の 2 つの方法があります。

  • エンドポイントを追加するときに VM 名のみ（IP アドレスなし）を指定する場合、 Google Cloud では NEG に関連付けられたサブネットワーク内に VM のネットワーク インターフェースが存在している必要があります。 Google Cloudがエンドポイントに選択する IP アドレスは、サブネットワーク内で NEG に関連付けられた VM のネットワーク インターフェースのプライマリ内部 IPv4 アドレスです
  • エンドポイントを追加するときに VM 名と IP アドレスの両方を指定する場合は、指定する IP アドレスは、VM のネットワーク インターフェースのいずれかのプライマリ内部 IPv4 アドレスにする必要があります。このネットワーク インターフェースは、NEG に関連付けられたサブネットワーク内に存在する必要があります。NEG に関連付けられたサブネットには 1 つのネットワーク インターフェースしか存在しないため、IP アドレスを指定しても冗長になります。

バックエンド サービスと VPC ネットワーク

バックエンド サービスは VPC ネットワークに関連付けられていませんが、先ほど説明したとおり、各バックエンド インスタンス グループまたはゾーン NEG は VPC ネットワークに関連付けられています。すべてのバックエンドが同じプロジェクトに存在し、すべてのバックエンドが同じタイプ（インスタンス グループまたはゾーン NEG）である限り、ロードバランサとそのバックエンドは同じ VPC ネットワークに存在しても、異なる VPC ネットワークに存在してもかまいません。

nic0 以外のインターフェースにパケットを配信するには、次の両方の要件を満たす必要があります。

  • インスタンス グループではなく、ゾーン NEG（GCE_VM_IP エンドポイントを含む）を使用する必要があります。

  • 非 nic0 ネットワーク インターフェースと nic0 ネットワーク インターフェースは、異なる VPC ネットワークに存在する必要があります。（NEG の VPC ネットワークに nic0 インターフェースと目的の非 nic0 インターフェースを含めることはできません）。

優先バックエンド

特定のバックエンドを優先バックエンドとして指定できます。これらのバックエンドが容量（バックエンドのバランシング モードで指定されたターゲット容量）に達するまで使用されると、残りのバックエンドにリクエストが送信されます。

グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスには、優先バックエンド グループを 1 つだけ設定できます。また、同じ Google Cloud リージョンに優先バックエンドと非優先バックエンドを設定することはできません。

詳細については、高度なロード バランシングの最適化をご覧ください。

ヘルスチェック

ヘルスチェック情報は、新しい接続の適格なバックエンドを特定し、異常なバックエンドで既存の接続を維持するかどうかを制御するために使用されます。

ロードバランサは、転送ルールの IP アドレスごとにヘルスチェック プローブを個別に送信します。したがって、2 つの IP アドレスを持つグローバル外部パススルー ネットワーク ロードバランサの転送ルールは、各 IP アドレスに対してプローブされ、各バックエンドのプローブ頻度が 2 倍になります。詳細については、複数のプローブと頻度をご覧ください。

ヘルスチェックのタイプ、プロトコル、ポート

ロードバランサのバックエンド サービスは、サポートされている任意のヘルスチェック プロトコルとポートを使用して、グローバル ヘルスチェックを参照する必要があります。ヘルスチェック プロトコルとポートの詳細は、転送ルールのプロトコルとポートの情報に一致する必要はありません。

サポートされているすべてのヘルスチェック プロトコルは TCP に依存しているため（UDP ヘルスチェックはサポートされていません）、グローバル外部パススルー ネットワーク ロードバランサを使用して他のプロトコルの接続とトラフィックをバランシングする場合は、バックエンド VM で TCP ベースのサーバーを実行してヘルスチェック プローバーに応答する必要があります。たとえば、HTTP ヘルスチェックと、各バックエンド VM での HTTP サーバーの実行を組み合わせて使用できます。この例では、スクリプトまたはソフトウェアが HTTP サーバーを構成し、ロード バランシングされた接続をリッスンするソフトウェアが動作している場合にのみステータス 200 を返すようにします。

サポートされているヘルスチェック プロトコルとポートの詳細については、ヘルスチェックのカテゴリ、プロトコル、ポートとヘルスチェックの仕組みをご覧ください。

ヘルスチェック パケット

インスタンス グループのバックエンドの場合、ヘルスチェック プローバーは各バックエンド VM の nic0 ネットワーク インターフェースにパケットを送信します。GCE_VM_IP ゾーン NEG バックエンドの場合、ヘルスチェック プローバーは NEG の VPC サブネットワーク内のネットワーク インターフェースにパケットを送信します。ヘルスチェック パケットには次の特性があります。

  • グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスを参照する転送ルールの 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 個までです。詳細については、割り当てと制限をご覧ください。

  • グローバル外部パススルー ネットワーク ロードバランサのバックエンド サービスには、最大で 1 つの PREFERRED バックエンド グループを設定できます。同じ Google Cloud リージョンに PREFERRED バックエンド グループと PREFERRED 以外のバックエンド グループを配置することはできません。

  • 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 をご覧ください。

次のステップ