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

外部パススルー ネットワーク ロードバランサは、ロードバランサと同じリージョン内のバックエンド(インスタンス グループまたはネットワーク エンドポイント グループ(NEG))間で外部トラフィックを分散するレイヤ 4 リージョン ロードバランサです。これらのバックエンドは同じリージョンとプロジェクトに存在する必要がありますが、異なる VPC ネットワークに配置できます。

外部パススルー ネットワーク ロードバランサは、TCP、UDP、ESP、GRE、ICMP、ICMPv6 のトラフィック用に構成できます。

外部パススルー ネットワーク ロードバランサは、以下のトラフィックを受信できます。

  • インターネット上のすべてのクライアント
  • 外部 IP を持つ Google Cloud VM
  • Cloud NAT またはインスタンス ベースの NAT 経由でインターネットにアクセスできる Google Cloud VM

外部パススルー ネットワーク ロードバランサには次の特性があります。

  • 外部パススルー ネットワーク ロードバランサは、Andromeda 仮想ネットワークGoogle Maglev を使用して実装されたマネージド サービスです。
  • 外部パススルー ネットワーク ロードバランサのスコープはリージョンです。つまり、ロードバランサが複数のリージョンにまたがることはできません。ロードバランサは単一リージョン内のすべてのゾーンにサービスを提供します。
  • 外部パススルー ネットワーク ロードバランサはプロキシではありません。
    • ロード バランシングされたパケットは、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコル(プロトコルがポートベースの場合は、送信元ポートと宛先ポートは変更されていません)を持つバックエンド VM によって受信されます。
    • 負荷分散接続はバックエンド VM によって終端されます。
    • バックエンド VM からのレスポンスは、ロードバランサを経由せず、クライアントに直接送信されます。これを業界用語で Direct Server Return(DSR)といいます。

次の図は、転送ルールに 120.1.1.1 という IP アドレスがある外部パススルー ネットワーク ロードバランサを示しています。外部パススルー ネットワーク ロードバランサは、us-central1 リージョンで構成され、バックエンドは同じリージョンにあります。

外部パススルー ネットワーク ロードバランサは本質的にリージョン単位であり、構成済みのフロントエンドと同じリージョン内のバックエンドのみをサポートします。ただし、ロードバランサの IP アドレスがプレミアム ティアであるかスタンダード ティアであるかにかかわらず、外部パススルー ネットワーク ロードバランサへのパケットはインターネット上のどこからでも送信できます。ロードバランサの IP アドレスがプレミアム ティアにある場合、トラフィックは Google の高品質グローバル バックボーンを通過し、パケットはクライアントに可能な限り近い Google エッジ ピアリング ポイントを通過します。ロードバランサの IP アドレスがスタンダード ティアにある場合、トラフィックは、ロードバランサが構成されている Google Cloud リージョンに最も近いピアリング ポイントで Google ネットワークに出入りします。

次の図では、トラフィックがシンガポールのユーザーから us-central1(転送ルールの IP アドレス 120.1.1.1)の外部パススルー ネットワーク ロードバランサにルーティングされています。

asia-southeast1 に近いシンガポールのユーザーが、us-central1 リージョンの外部パススルー ネットワーク ロードバランサにアクセスしている。
シンガポールのユーザーの外部パススルー ネットワーク ロードバランサの例(クリックして拡大)

次の図では、トラフィックがアイオワのユーザーから us-central1 の外部パススルー ネットワーク ロードバランサ(転送ルールの IP アドレス 120.1.1.1)にルーティングされています。

us-central1 に近いアイオワのユーザーが、同じ us-central1 リージョン内のネットワーク ロードバランサにアクセスしている。
アイオワのユーザーの外部パススルー ネットワーク ロードバランサの例(クリックして拡大)

ユースケース

外部パススルー ネットワーク ロードバランサは、次のような状況で使用します。

  • TCP 以外のトラフィックのロード バランシングが必要な場合。または、他のロードバランサでサポートされていない TCP ポートのロード バランシングが必要な場合。
  • ロードバランサではなく、バックエンドで SSL トラフィックの復号を行う場合。外部パススルー ネットワーク ロードバランサはこのタスクを実行できません。SSL トラフィックをバックエンドで復号すると、VM の CPU 使用量が非常に多くなります。
  • バックエンド VM の SSL 証明書を自己管理する場合。Google マネージド SSL 証明書は、外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサでのみ使用できます。
  • プロキシを経由せずに元のパケットを転送する必要がある場合。たとえば、クライアントの送信元 IP を保持する必要がある場合など。
  • 既存の環境でパススルー ロードバランサを使用していて、これを変更せずに移行する場合。
  • 外部パススルー ネットワーク ロードバランサに、高度なネットワーク DDoS 対策が必要な場合。詳細については、Google Cloud Armor を使用して高度なネットワーク DDoS 対策を構成するをご覧ください。

GKE アプリケーションのロード バランシング

GKE でアプリケーションを構築する場合は、組み込みの GKE Service コントローラを使用することをおすすめします。このコントローラは GKE ユーザーに代わって Google Cloud ロードバランサをデプロイします。これは、スタンドアロンのロード バランシング アーキテクチャと同じですが、ライフサイクルが GKE によって完全に自動化、制御される点で異なります。

関連する GKE のドキュメント:

アーキテクチャ

外部パススルー ネットワーク ロードバランサのアーキテクチャは、バックエンド サービス ベースの外部パススルー ネットワーク ロードバランサと、ターゲット プールベースの外部パススルー ネットワーク ロードバランサのどちらを使用するかによって異なります。

バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ

ロードバランサの動作とバックエンドへのトラフィックの分散方法を定義するリージョン バックエンド サービスを使用して、外部パススルー ネットワーク ロードバランサを作成できます。バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、IPv4 / IPv6 トラフィック、複数のプロトコル(TCP、UDP、ESP、GRE、ICMP、ICMPv6)、マネージド / 非マネージド インスタンス グループ バックエンド、GCE_VM_IP エンドポイントを使用するゾーン NEG バックエンド(複数のネットワーク インターフェースに対するサポートを含む)、きめ細かいトラフィック分散コントロール(接続トラッキングコネクション ドレイントラフィック ステアリング重み付きロード バランシングフェイルオーバー ポリシー)をサポートしています。これにより、分散するトラフィックのタイプ(TCP、SSL、HTTP、HTTPS、HTTP/2)に一致する非レガシー ヘルスチェックを使用できます。

アーキテクチャの詳細については、リージョン バックエンド サービスを使用した外部パススルー ネットワーク ロードバランサをご覧ください。

既存のターゲット プール ベースの外部パススルー ネットワーク ロードバランサを移行して、バックエンド サービスを使用することもできます。手順については、外部パススルー ネットワーク ロードバランサのターゲット プールからバックエンド サービスへの移行をご覧ください。

ターゲット プール ベースの外部パススルー ネットワーク ロードバランサ

ターゲット プールは、Google Cloud の外部パススルー ネットワーク ロードバランサでサポートされているレガシー バックエンドです。ターゲット プールでは、ロードバランサから受信トラフィックを受け取るインスタンスのグループを定義します。

ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、TCP または UDP のいずれかのトラフィックをサポートします。ターゲット プール ベースの外部パススルー ネットワーク ロードバランサの転送ルールは、外部 IPv4 アドレスのみをサポートします。

アーキテクチャの詳細については、ターゲット プール バックエンドを使用した外部パススルー ネットワーク ロードバランサをご覧ください。

外部パススルー ネットワーク ロードバランサと他の Google Cloud ロードバランサの比較

他の各種 Google Cloud ロードバランサとの相違点については、次のドキュメントをご覧ください。