Private Service Connect のアーキテクチャとパフォーマンス

このページでは、Private Service Connect の仕組みについて説明します。

Private Service Connect は、 Google Cloud のソフトウェア定義ネットワーキング（SDN）である Andromeda（PDF）を使用して実装されます。Andromeda は、Google Cloud ネットワーキングの分散型コントロール プレーンとデータプレーンであり、Virtual Private Cloud（VPC）ネットワークに対するネットワーキングを可能にします。Andromeda のネットワーキング ファブリックは、VM をホストする物理サーバーでパケットを処理します。その結果、データプレーンは完全に分散され、中間プロキシやアプライアンスにボトルネックが集中することがなくなります。

Private Service Connect トラフィックは物理ホストで完全に処理されるため、プロキシ指向モデルに比べてパフォーマンスが大幅に向上します。

  • Private Service Connect によって課される追加の帯域幅制限はありません。送信元と宛先の VM インターフェースの合計帯域幅は、実際の Private Service Connect の帯域幅制限になります。
  • Private Service Connect は、トラフィックへのレイテンシを最小限に抑えます。トラフィック パスは、単一の VPC ネットワーク内の VM 間トラフィックと同一のものになります。宛先ホスト全体で行われる追加のトラフィック処理ステップは、トラフィックのネットワーク アドレス変換のみになります。

次の図は、コンシューマー VPC ネットワークとプロデューサー VPC ネットワーク間の Private Service Connect トラフィックの一般的なトラフィック パスを示しています。

物理ホストは、クライアント ロード バランシングを実行して、トラフィックの送信先のターゲット ホストを決定します（クリックで拡大）。

論理的には、コンシューマー Private Service Connect エンドポイントとプロデューサー ロードバランサが存在します。ただし、物理的な観点からは、トラフィックは、クライアント VM をホストする物理サーバーからプロデューサー ロードバランサ VM をホストする物理サーバーに直接送信されます。

以下の説明で示すように、Andromeda は Private Service Connect トラフィックにいくつかの機能を適用します。

  • クライアント側のロード バランシングが送信元ホスト（Host 1）により、トラフィックの送信先となるターゲット ホストが決まります。この決定は、ロケーション、負荷、ステータスに基づいて行われます。
  • VPC1 の内部パケットは、宛先ネットワーク VPC2 を含む Andromeda ヘッダーにカプセル化されます。
  • 宛先ホスト（Host 2）は、パケットの送信元 IP アドレス範囲としての NAT サブネットおよび宛先 IP アドレスとしてプロデューサー ロードバランサ IP アドレスを使用し、パケットに SNAT と DNAT を適用します。

リージョン間のトラフィック フローや非常に小規模、または断続的なトラフィック フローなど、中間ルーティング ホストによってトラフィックを処理するケースでは、例外が存在します。ただし、Andromeda は、最適なレイテンシとスループットを実現するため、直接的なホスト間のネットワーキングではトラフィック フローを可能な限り動的にオフロードします。

次のステップ