「プロジェクト間のサービス連携、どうしてる？」PSC公開サービスでIP重複や管理の手間を解決！


前回のGoogle API編に続き、今回はプロジェクト間でサービスを安全に連携させるPrivate Service Connectの「公開サービス」編です。VPCピアリングを使わずに、サービス提供側と利用側を疎結合で繋ぐ具体的な設定手順を解説します。

はじめに

前回の記事では、Private Service Connect (PSC) を使ってGoogleのAPIへプライベートに接続する方法をご紹介しました。今回はその応用編として、自組織の別プロジェクトで公開されているサービスへ安全に接続する方法を解説します。

通常、プロジェクト間でプライベート通信を行うにはVPCピアリングを利用しますが、IPアドレス範囲の重複が許されないなど、設計上の制約がありました。PSCの「公開サービス」機能を使えば、サービス提供側（プロデューサー）と利用側（コンシューマー）のネットワークを完全に分離したまま、必要なサービスのみを安全に連携させることができます。

PSC公開サービスの概要

2.1 PSC公開サービスとは？

PSC公開サービスは、あるプロジェクト（プロデューサー）内の内部ロードバランサを、別のプロジェクト（コンシューマー）からプライベートに利用できるようにする仕組みです。プロデューサーはサービスを「サービスアタッチメント」として公開し、コンシューマーはVPC内に「エンドポイント」を作成してそのサービスに接続します。

2.2 Google API接続との違い

前回のGoogle API接続と最も異なる点は、IPアドレスの扱いです。

Google API接続: エンドポイントのIPは、VPC内のどのサブネットとも重複しないアドレス空間から指定しました。

公開サービス接続: エンドポイントのIPは、コンシューマーVPC内の既存のサブネットから払い出します。

実践！PSC公開サービスの設定手順

3.1 今回の構成ゴール

サービス提供側であるSpokeBプロジェクト（プロデューサー）で公開されているWebサービス（内部ロードバランサ）に対し、サービス利用側のJITHUBプロジェクト（コンシューマー）を経由して、オンプレミス環境からプライベートにアクセスする構成を構築します。

3.2 サービス提供側（プロデューサー）の設定

まず、サービスを公開するSpokeBプロジェクトで設定を行います。

3.2.1 サービスの公開（サービスアタッチメントの作成）

SpokeBプロジェクトの[Private Service Connect] - [公開サービス]画面で、[+サービスを公開]を選択します。

公開したい既存の内部ロードバランサ（今回はhttplb01）を選択します。

PSC用のNATサブネットを予約します。このサブネットのIPアドレスは、コンシューマーからのトラフィックをバックエンドのVMへ転送する際に、送信元NATとして使用されます。

接続設定（今回は全接続を自動承認）を選択し、サービスを追加します。

作成後、**サービスの接続情報（サービスアタッチメントURI）**をコピーしておきます。これがコンシューマー側からの接続先ターゲットになります。

3.3 サービス利用側（コンシューマー）の設定

次に、サービスを利用するJITHUBプロジェクトで設定を行います。

3.3.1 接続エンドポイントの作成

JITHUBプロジェクトの[Private Service Connect] - [接続エンドポイント]画面で、[+エンドポイントを接続]を選択します。

ターゲットを「公開済みのサービス」に設定し、ターゲットサービス欄に先ほどコピーしたサービスアタッチメントURIを貼り付けます。

エンドポイントを配置するサブネット（今回はsubnet-psc）を選択します。

エンドポイントのIPアドレスを、選択したサブネットの範囲内から指定（今回は10.24.6.100）して予約します。

設定内容を確認し、エンドポイントを作成します。

動作確認

4.1 オンプレミスからの接続確認

オンプレミス環境の端末から、コンシューマーVPC内に作成したエンドポイントのIPアドレス（10.24.6.100）へブラウザでアクセスします。プロデューサー側のWebページが正常に表示されることを確認します。

4.2 プロデューサー側での接続状況確認

プロデューサー（SpokeB）プロジェクトの公開サービス画面で、接続カウンターがカウントアップしていることを確認します。これにより、コンシューマーからの接続が確立されていることがわかります。

4.3 バックエンドサーバーでの通信確認

プロデューサー側のバックエンドVMでtcpdumpを実行し、Webサーバーへのアクセス元IPアドレスを確認します。
続いて、送信元がプロデューサー側で設定したPSC用NATサブネットのIPアドレス（10.168.30.5）になっていることがわかります。
これにより、コンシューマー側の実際のIPアドレスが隠蔽され、ネットワークが分離されていることが証明されます。 

  1. hisato@instance-20240413-072312:~$ sudo tcpdump -i ens4 -nn -tttt port 80 | grep 10.168.30.
  2. tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
  3. listening on ens4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
  4. 2024-05-13 15:02:51.875693 IP 10.168.30.5.51372 > 10.168.10.4.80: Flags [S], seq 3500136751, win 65535, options [mss 1420,sackOK,TS val 4074246423 ecr 0,nop,wscale 8], length 0
  5. 2024-05-13 15:02:51.875730 IP 10.168.10.4.80 > 10.168.30.5.51372: Flags [S.], seq 4091605353, ack 3500136752, win 65160, options [mss 1460,sackOK,TS val 4197213757 ecr 4074246423,nop,wscale 7], length 0

まとめ

本記事では、Private Service Connectの「公開サービス」機能を利用して、異なるプロジェクト間でサービスをプライベートに接続する方法を解説しました。この機能は、特に以下のような場合に強力な選択肢となります。

サービス提供側と利用側でIPアドレス空間の重複を気にせず接続したい場合。
サービス提供側のネットワーク構成を利用側に隠蔽したい場合。
VPCピアリングを使わずに、特定のサービスのみを安全に公開・利用したい場合。

PSCを適切に活用することで、セキュアで疎結合なマルチプロジェクトアーキテクチャをシンプルに実現できます。

次回は、Private Service Connect インターフェースを使用した、独立したプロジェクトからGoogle Cloud内やオンプレミス環境へのアクセス方法について紹介します。

富士ソフトでは、SaaS基盤の構築や、マルチテナント環境におけるセキュアなサービス連携など、高度なGoogle Cloudアーキテクチャの設計・構築をご支援しています。Private Service Connectの活用やプロジェクト間のネットワーク設計でお困りの際は、ぜひお気軽にご相談ください。