【Google Cloud Next Tokyo 26】Private Service Connectを支えるDouble NAT 〜3つの接続方式の使い分けとパケットフロー〜

はじめに

Google Cloud Next Tokyo 26のGoogleセッション「Private Service Connectで実現する今どきのシンプルかつセキュアなサービス接続」（D1-INF-02）のセッションレポートをお届けします。
複数のVPCにまたがるシステムの設計・運用に携わる際、VPCピアリングのIPアドレス設計や経路管理が悩みどころになります。接続先が増えるほどCIDRの調整と経路の棚卸しが必要になり、運用の負担として積み上がっていきます。本セッションは、その課題をネットワーク単位ではなくサービス単位の接続で解決するPrivate Service Connect（以下、PSC）を、動作原理まで踏み込んで扱う内容でした。

セッション概要

1. 従来のVPCピアリング・NCCが抱える課題

冒頭は「複数のVPC間にまたがるシステムで、VPCの外にあるサービスへアクセスさせたいとき、どう構成しますか」という会場への問いかけから始まりました。多くの方がVPCピアリング、あるいはNetwork Connectivity Center（NCC）を思い浮かべるのではないでしょうか。セッションでは、これらの方式でサービスやVPCが増えたときの課題が整理されていました。

続いて「本当にやりたかったことは何だったのか」と立ち戻る展開になります。VPCピアリングでVPC同士をつなぐことでも、ファイアウォールポリシーを設定することでもなく、必要なサービス間の接続を実現して新しい機能を早くリリースすることが本来の目的だったはずだ、という整理でした。このインテント（意図）に立ち返る流れが、セッション全体の軸になっています。

2. PSCが解決するアプローチ 〜ネットワーク単位からサービス単位へ〜

PSCは、このインテントベースでサービス間接続を実現するための機能だと説明されていました。サービス提供者はPSCでサービスを公開し、サービス利用者はPSCでそのサービスに接続する。これをVPCの構成やIPアドレスを意識することなく実現できる、というのが基本的な考え方です。「どうつなぐか」を管理するのがピアリングやNCCで、「何を公開し、何に接続するか」だけを管理するのがPSCというイメージです。

接続先は自組織の他のVPCにあるリソースだけではなく、Cloud SQLやBigQueryといったGoogleのサービス、サードパーティのDatadogやDatabricksなどもPSC対応サービスとして紹介されていました。セッション本編は「自組織の他のVPCにあるサービスにつなぎたい」というユースケースに絞って進められており、サービス提供者側の公開手順は、次の4ステップで整理されていました。

① 内部ロードバランサー（ILB）またはSecure Web Proxy（SWP）を構築する
② PSC専用のサブネットを作成する
③ サービスアタッチメントを作成する（ロードバランサー・サービス名称・PSCサブネット・接続承認オプションを指定）
④ 利用者からの接続リクエストを承認する

サービスアタッチメントのURIを利用者に伝え、利用者が接続を申請すると、提供者側に承認リクエストが届きます。接続先のプロジェクトが事前にわかっていれば、オプションにホワイトリスト形式で登録して自動承認にもできると説明されていました。なお②のPSCサブネットは、この時点では用途が明かされず、後半のパケットフローで役割が説明される構成になっています。

3. 3つの接続ポイント

利用者側に作る接続ポイントには3種類あります。

スライドではPSCエンドポイントがL4 PSC、PSCバックエンドがL7 PSCと併記されていました。ロードバランサーを挟むかどうかが、そのままレイヤーの違いとして整理されています。

4. PSCエンドポイントのパケットフロー 〜Double NATの動作原理〜

PSCエンドポイントを作ると、利用者VPC内にIPアドレスが払い出され、そこ宛に通信するだけでサービスが使えるようになります。その際、提供者側のVPCには存在しないはずのIPアドレスで、なぜ通信が成立するのか解説されていました。通信経路は以下となります。

① Compute EngineインスタンスがPSCエンドポイントのIPアドレス宛にパケットを送出（送信元IPはインスタンスのIP、宛先IPはPSCエンドポイントのIPで、いずれも利用者VPC内のアドレス）
② PSCの仕組みによって、パケットが提供者側のVPCに入る
③ 提供者側VPCには送信元IPも宛先IPも存在しないため、そのままでは通信が成立しない。ここでPSCサブネットが役割を果たす
④ Double NATが適用され、送信元IPはPSCサブネットのアドレスに、宛先IPは提供者側ロードバランサーのアドレスに変換される
⑤ 変換後のパケットが提供者VPC内でルーティングされ、ロードバランサーに到達する

スライドでは、具体的なIPアドレスを使って変換の前後が示されていました。

興味深かったのは、この例では提供者側のアプリケーション用サブネットも利用者側と同じ10.0.0.0/24で描かれている点です。CIDRが完全に重複した状態でも成立することを、あえて示す構成になっていました。

提供者側のロードバランサーからは、あたかもクライアントが自分のVPC内にいて、VPC内のIPアドレスから通信が来ているように見える、という説明でした。送信元と宛先の両方を書き換えるのでDouble NATであり、これによって利用者側と提供者側でIPアドレスが重複していても通信が成立することが分かります。IPアドレスの重複を「調整すべき制約」ではなく「気にしなくてよいもの」に変えている点が、PSCの本質だと感じました。この変換はGoogle CloudのSDNレイヤーであるAndromedaで実装されているため性能劣化は最小限で、ほぼワイヤーレートで通信できるとも説明されていました。

一方で、Double NATが入るということは、提供者側のログに残る送信元IPがPSCサブネットのアドレスになり、実際のクライアントを識別できないという点に注意が必要です。「どのクライアントからアクセスされたか」を追跡・監査したい要件がある場合、PSCエンドポイントを選んだ時点でその情報は失われることになります。

5. PSCバックエンド 〜リージョン冗長とロギングを足す〜

PSCエンドポイントの課題として、次の2点が挙げられていました。

• PSCはリージョナルリソースのため、提供者側のリージョン障害で接続できなくなる
• 利用者側で細かいセキュリティ制御を行ったり、リクエストを監視・ロギングしたりできない

これらを解決するのがPSCバックエンドで、利用者側にもロードバランサーを設置して経由させる構成です。ロードバランサーのバックエンドとしてPSCを接続し、ILB経由でサービスに接続する形になります。手順はBackend Serviceの作成、ILBの作成、提供者側での承認、サービス利用開始という流れで、PSC NEGのパラメータはPSCエンドポイントとほぼ同じ（名称・サービスアタッチメントのURI・プロキシサブネット）でした。リージョン冗長を行う場合は、PSC NEGを各リージョンに作成します。可視化・セキュリティの機能としては、Cloud Logging・Cloud NGFW・Cloud Armorがいずれも任意で組み込めるものとして示されていました。

パケットフローはDouble NATを使う点が同じで、利用者側の動きだけが異なります。リクエストはまず利用者側ロードバランサーに届き、そこでセキュリティやロギングの処理が実行され、PSC NEG経由で提供者側に送られるという流れでした。ここで運用上おさえておきたいのが、ロードバランサーを経由するためHTTPリクエストにX-Forwarded-Forヘッダーが付与される点です。PSCエンドポイントではDouble NATによって失われるクライアントの情報が、PSCバックエンドではヘッダーとして提供者側に届きます。

PSC NEGにはヘルスチェックがない

PSC NEG自体にヘルスチェック機能がないため、そのままでは提供者側のリージョン障害を検出できません。これを補うのがComposite Health Checkで、提供者側ロードバランサーが持つヘルスチェック情報を、利用者側ロードバランサーに同期する機能だと説明されていました。例として挙げられた提供者側の大阪リージョン障害では、提供者側ロードバランサーが検出した情報が同期されることで、利用者側は東京リージョンのみにトラフィックを流せる、という流れになります。利用者側はCross-Region ILBを立て、その配下に東京・大阪のPSC NEGをぶら下げる構成でした。

このほか、利用者側ロードバランサーのAuthorization PolicyやService Extensionsを使うことで、クライアントを認証し、許可されたリソースからのみサービスを利用させる構成も作れると紹介されていました。Authorization PolicyはIPアドレスやサービスアカウントに基づいたビルトインの認証、Service ExtensionsはIAPや外部サービスでの認証にあたります。スライドでは、同じサブネット内のCompute Engineインスタンスでも、付与されたサービスアカウントによって許可と拒否が分かれる例が示されていました。

PSCエンドポイントとPSCバックエンドの使い分け

登壇者によるまとめは、シンプルなものでした。

6. PSCインターフェース 〜提供者から利用者へ戻る経路〜

同じPSCという名前がついていますが、エンドポイントやバックエンドとは全くの別物として最後に扱われたのが、PSCインターフェースです。提供者側のサービスが、利用者側VPC内のリソースへアクセスするためのものになります。ユースケースとしては、Gemini EnterpriseのAgent Platformのエージェントランタイムから社内リソースにアクセスさせるケースと、Cloud SQLからオンプレミスのデータベースサーバーへレプリケーションさせるケースが紹介されていました。

PSCインターフェースは、Compute EngineのNICとして接続されます。利用者側で名称・接続先VPCのサブネット・受け入れ承認の設定を入れるとネットワークアタッチメントというリソースが作成され、提供者側はCompute Engineインスタンスの作成時に、セカンダリNICとしてそのURIを指定します。これでインスタンスから利用者側VPCへ抜けられるようになります。スライドでは、提供者側VPCに向くNIC #0と、利用者側VPCに向くNIC #1を持つApplication VMが描かれ、NIC #1側にはDHCPで配られる経路に加えて、オンプレミス側のサブネット宛の静的ルートを追加する例が示されていました。利用者側VPCの先にあるオンプレミスのリソースまで届かせるには、この静的ルートの設計が必要になります。

印象に残ったポイント

機能説明ではなく「設計の単位を変える」話

VPCピアリングの課題を並べたうえで「本当にやりたかったことは新しい機能を早くリリースすることだったはず」と立ち戻る展開が印象的でした。接続作業のコストは、技術的な問題ではなくリードタイムの問題として現れます。CIDRの調整や相手チームとの合意に時間がかかる状況を経験していると、この整理は納得感がありました。

Double NATは利点と副作用の両面がある

IPアドレスの重複を根本的に解消できるのは最大の利点ですが、同時に提供者側からクライアントを識別できなくなります。PSCバックエンドならX-Forwarded-Forが付与されるという非対称性は、セッション中で最も実務に効く情報でした。監査要件がある構成では、この時点で選択肢がPSCバックエンドに絞られることになります。

可用性はデフォルトでは担保されない

PSCがリージョナルリソースであること、PSC NEGにヘルスチェックがないことを課題として先に示したうえで、Composite Health Checkという解を提示する順序になっていました。つなげば冗長になるわけではなく、リージョン冗長は追加設計が必要である、と理解できる構成が非常に参考になりました。

AWSのPrivateLinkとの対応付け

本セッションで解説はされていませんが、AWSのサービスと比較すると以下のイメージになりそうです。

エンドポイント・サービス公開・承認という骨格はほぼ同型で、AWSでPrivateLinkを扱った経験がそのまま補助線になりました。一方、PSCインターフェースに相当する機能はPrivateLinkにはないため、ここだけは新しい概念として捉える必要がありそうです。エージェントランタイムから社内システムを叩く要件は今後増えていくと考えられ、この方向の接続手段を知っているかどうかが、設計の選択肢の幅を左右すると感じました。

さいごに

セッションを通じて、PSCは接続の設計単位をネットワークからサービスに変えるものであり、その結果としてIPアドレスの重複が制約でなくなる、と理解できました。また、Double NATという実装を知ったことで、なぜIP設計から解放されるのかが腹落ちしたことが大きいです。
同時に、PSCが万能ではないことも見えてきました。サービス単位で切り出せる一方向のアクセスには強い一方、L3全域の疎通が必要な運用系・監視系の通信や、送信元IPをそのまま保ちたい要件では、従来どおりピアリングやNCCのほうが扱いやすい印象も受けました。そのため、サービスごとの要件に応じて使い分ける選択肢として持っておきたいところです。

なお、本セッションでは料金体系への言及はありませんでした。PSCは接続ポイントを1つずつ作っていく仕組みである以上、エンドポイントの課金単位やデータ処理料金は、接続数が増えるほど効いてくる部分だと思います。ピアリングであれば発生しない費用でもあるため、どちらの方式を選ぶかを判断する際の基準の一つになりそうです。
また、気になったのはDouble NATの副作用としてのクライアントIPの扱いです。PSCエンドポイント経由とPSCバックエンド経由で、提供者側のロードバランサーのログに何が記録されるのか。これを比較すれば、監査要件がある構成での選択根拠を示せるのではないかと思います。PSCの利用を検討している方の参考になれば幸いです。