🔗

CloudSQL 等で出てくる Private Service (Connect|Access)ってどう違うの？

2024/03/29に公開

Google Cloud

はじめに

こんにちは、クラウドエース SRE 部所属の亀梨です。

クラウドサービスを利用していると、「途中まで名前が同じ複数のサービス」に遭遇する頻度が高くないですか？
何々 flow とか、Data 何々とか、Big 何々とか…。紛らわしいですよね。
Cloud SQL 内部接続の文脈において、同僚との会話の中で「PSC」「PSA」という略語が出てきたとき、どっちがどっちなんだっけ？と混乱しました。
どちらも「プライベート・サービス・何々」という名前をしています。名前の2/3が共通しているので、何々 flow (1/2)よりも共通度が高いです。

この記事では、PSC、PSA と聞いた時に、どっちがどっちなのか分かる！ことを目指します。
なお、PSC には接続先が「利用者によってホストされたサービス」となる「for ILB」構成パターンもございますが、本記事では割愛いたします。

TL;DR この記事の要約

VPC ピアリングによって別 VPC からの接続性を得るのが Private Service Access
- VPC ピアリング特有の制約(推移的ピアリング不可など)を受ける
- PSA 専用サブネットワーク(/24)の割り当てが必要
- 設定が簡潔(Cloud DNS 等が必要ない)
- 既存のインスタンスを削除せずに設定可能
- 追加費用なし
Global forwarding Rule を用いた NAT によって別 VPC からの接続性を得るのが Private Service Connect
- 複数の VPC ネットワークから接続させることが可能
- 単一のエンドポイント IP アドレス(/32)が必要
- 設定が複雑( Cloud DNS 等の設定が必要)
- Cloud SQL インスタンスの作成時にのみ導入が可能
- PSC 自体にわずかな費用がかかる

公式ドキュメントの要約を見てみよう

両サービスの具体的な技術に入る前に、ざっくりと特徴を伝えてくれる公式ドキュメントの概要説明を見比べてみましょう。

Private Service Access

プライベートサービスアクセスは、お客様の VPC ネットワークと基盤となる Google Cloud の VPC ネットワーク（Cloud SQL インスタンスが存在するネットワーク）との間の VPC ピアリング接続として実装されます。プライベート接続を使用すると、VPC ネットワーク内の VM インスタンスとアクセスするサービスで、内部 IP アドレスを使用して排他的に通信できるようになります。VM インスタンスは、インターネットアクセスまたは外部 IP アドレスがなくても、プライベートサービスアクセスを介してサービスにアクセスできます。
https://cloud.google.com/sql/docs/mysql/configure-private-services-access?hl=ja

Private Service Connect

異なるグループ、チーム、プロジェクト、組織に属する複数の Virtual Private Cloud ネットワークから Cloud SQL インスタンスに接続できます。Private Service Connect を使用して、プライマリインスタンスまたはそのリードレプリカのいずれかに接続することもできます。
https://cloud.google.com/sql/docs/mysql/configure-private-service-connect?hl=ja

PSA の説明文を読むと、「VPC ピアリング」を用いて接続性を得るサービスであることがわかります。
一方、PSC は「複数の VPC ネットワークから Cloud SQL インスタンスに接続できる」ことがわかります。

Private Service Access とは

PSAは VPC ピアリング技術に基いた接続方法です。
2つの異なる VPC、ここではユーザー VPC と、Cloud SQL の属する Google VPC のネットワーク全体をピアリングすることで、相互通信を可能にします。

VPC ピアリングの大きな特徴のひとつに、推移的ルーティングをサポートしない、という点があります。
ざっくり説明すると、3つの VPC A、B、Cがあり、AとB、BとCがピアリングしている場合に、CからAへの通信はできないよ、というのが推移的ピアリング制約です。

Private Service Connect とは

接続元側に1つの内部 IP アドレスだけを用意し、そこから Cloud SQL に直接繋ぎに行く方式です。
正確には、Private Service Connect には3種類の接続タイプが存在し、そのうち Cloud SQL は以下リンクの図で解説されている「エンドポイント」タイプに合致します。

PSA がピアリングで実現されている一方で、PSC は VPC ピアリングを使わず、転送ルールを用いて NAT をかけることで2つの VPC 間の橋渡しを可能にします。
この NAT を構成するために、「サービスアタッチメント」( Google のマネージドサービスにおいては自動生成されます)をサービス提供側に構成する必要があります。
このサービスアタッチメントが、どの接続元に対して許可するのかを制御します。

Cloud SQL の場合、 gcloud sql instances (create|patch) コマンドを使用して、サービスアタッチメントに許可してよい接続元プロジェクトを指定します。

Cloud SQL 以外での使われ方

ここまで、Cloud SQL の利用という文脈で PSC を紹介しましたが、 PSC は意外と広く、Google Cloud の VPC ネットワーク系マネージドサービスで使われています。
これまで PSA で提供されていたサービスが、PSC での提供に置き換わっていく傾向にあるようです。

GKE コントロールプレーンとノードプール間の接続

GKE のコントロールプレーンとノードプールの接続には、VPC ピアリングが用いられていましたが、2022年3月からは PSC を利用するように変更されました。

Memorystore for Redis への GCE VM からの接続(プレビュー)

VPC ネットワークから各種マネージドサービスへアクセスさせる手段として、PSC は今後主流になっていきそうです。

ほかサービス

Apigee

Cloud Composer

コスト比較

PSC は Global Forwarding Rule を使用したサービスのため、1時間あたり $0.01 (2024年3月現在)の課金が固定で発生します。

加えて、Service Directory 名前空間機能も使用しているため、1エンドポイントごとに1月あたり$0.10、加えて Service Directory API の呼び出し100万回/月あたり $1.00 が発生します。

一方、PSA を利用することで新たに発生する費用はありません。

まとめ

設定の簡便さ、追加費用がないことから、PoC など初期段階での手早い構築には PSA を。
多プロジェクト・多 VPC からのアクセス、また IP アドレス設計の制約を受ける実運用には PSC を採用、と使い分けるのがよいのかなと感じました。
Cloud SQL 公式ドキュメントの「内部 IP アドレス設定」箇所の記述は、2024年3月現時点で PSA を使うことを前提とした記述になっていますが、今後は PSC が主体になっていくのだろうと思います。