Private Service Connectの設定:課題共有
Private Service Connect 設定時の知見を共有したい
みなさん、こんにちは。
クラウドエースでいつだってごきげん
をキャッチフレーズにSREをしている、長野と申します。
今回は案件でPrivate Service Connect(以降、PSCと略)を設定することになったので、そこで調査したことを共有したいと思います。
特に今回はいざ設定をするぞ、となった時に課題として出てきた3点について、その課題意識を共有できればと思います。
今回のPSCのユースケース
そもそもPSCとは、外部IP(Public IP) を持たないVMやオンプレミスのクライアントからプライベートネットワーク経由でGoogleCloudのAPI群へアクセスできるようにするための仕組みです。
Private Service Connect | VPC | Google Cloud
今回担当した案件では、専用線経由でGoogleのAPI系サービス(今回はPub/SubとCloud Storage)に接続したい
という要件でしたので、PSCの利用を検討した、ということになります。
なぜPSC?
専用線経由でGoogleのAPI系サービスを利用したい、ということであれば必ずしもPSCが必要ではなく、Private Google Access for オンプレミスホスト
でもよいのです。しかし、今回はPSCを選択することになりました。
オンプレミス ホスト用の限定公開の Google アクセス | VPC | Google Cloud
PSCを選んだ理由は以下からです。
- 各拠点のネットワークがデータセンターを経由する関係上、
オンプレミス ホスト用の限定公開の Google アクセス
である 199.36.153.4/30 や 199.36.153.8/30 といったIPアドレスをアドバタイズさせたくない。
もう少し詳しく説明すると、拠点によっては今回のように専用線経由ではなくインターネット経由でGoogleのAPI系サービスを利用する可能性がある中で、199.36.153.4/30 や 199.36.153.8/30 といったIPアドレスをアドバタイズすると、インターネット接続をさせたいプロジェクトの通信に影響を与える可能性が出てくるので、他のプロジェクトへの影響はないような設定(つまり自分たちで払い出したIPアドレスを利用)にしたい、ということでPSCを選定することになりました。
ちなみにDNSの問題はhostsで対応
上記のように各拠点のネットワークがデータセンター経由であることに付随して、以下の問題もありました。
- 名前解決はデータセンターにあるDNSサーバーが行っている
PSCを利用することで任意のIPアドレスを払い出したとしても、その名前解決がデータセンターで中央集権的に行われていると、結局はインターネット接続をさせたいプロジェクトに影響を与える可能性が出てきます。
この問題の対応として、名前解決はhostsでする
ことを選択しました。
あらためて課題意識の共有
ここまでで、決まったことをまとめると以下のようになります。
- 専用線経由のAPI系サービスの利用には、任意のIPを払い出せるPSCを利用する
- 名前解決にはhostsを利用する
では、上記の条件で設定を進めるとなった時の課題は何かというと
- PSCを設定するVPCは共有VPCにしないといけない?
- 名前解決をhostsで対応することは可能?
- ルーティングはどんな設定をする必要がある?
調査結果を先に記載しておきます。
- 共有VPCは不要
- hostsでの対応が可能
- PSCのIPアドレスをカスタムルートアドバタイズする
詳細については次回に記載します。
同じような状況、課題を抱えてる方の助けになれば幸いです。
Discussion