Private Service Connect を使用した Cloud SQL へのアクセス

※この投稿は米国時間 2023 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

Private Service Connect（PSC）を使用すると、異なるグループ、チーム、プロジェクト、組織に属する VPC ネットワーク全体でサービスをプライベートに利用できます。これは場合によっては、VPC ピアリングや共有 VPC といったプライベート接続の方法よりもはるかに優れた代替手段となり得ます。このブログ投稿では、PSC を使用して Cloud SQL にアクセスするための対処法について説明します。また、このソリューションは、Memorystore や AlloyDB、接続をプライベート サービス アクセス（PSA）に依存している他のいくつかのサービスなど、PSC をネイティブにサポートしていない他のマネージド サービスにも適用できます。

背景

大半のお客様は、Cloud SQL インスタンスを使用するリソースが別の VPC ネットワークや GCP プロジェクトにあるアーキテクチャを採用しなければならない要件を抱えています。Cloud SQL は推移的ピアリングをサポートしていないため、VPC のピアリングはそのままでは機能せず、IP 範囲の計画も多数必要になるため、望ましくありません。

PSC のソリューション設計

企業環境では、分離されたアーキテクチャを使用して、異なるチーム間で責任を切り分けるのが一般的です。複数のアプリケーション チームが、それぞれのアプリケーション gcp プロジェクト（図の左側）の所有権を管理していると仮定します。データベース チームは、データベース gcp プロジェクト内（図の右側）にある複数のアプリケーションのデータベース リソースをすべて管理しています。これらの各チームは、独自の VPC ネットワークにリソースをデプロイし、高度な自律性と柔軟性を実現しています。このようなアーキテクチャでは、データベース チームはさまざまなアプリケーションにデータベースをサービスとして公開する必要があります。

上の図では、わかりやすくするために、コンシューマーとプロデューサーが 1 対 1 の組み合わせのみを表示していますが、実際には、これが多対多の関係になる可能性もあります。つまり、各サービス アタッチメントは、同じ、または異なる gcp プロジェクトに複数の psc エンドポイントを持つことができます。

クライアント アプリケーションが GCE / GKE で実行され、永続ストアが Cloud SQL for MySQL データベース インスタンスであるシナリオを想像してみましょう。図 1 を見ると、クライアント アプリケーションのデータベース リクエストは 172.168.32.2:3306（PSC エンドポイント）に接続しています。この IP は、クライアント VPC のアドレス空間からのものです。GKE クラスタ内から発生したリクエストは、サブネットワークのルートを通過して PSC エンドポイントに到着します。基本的に、PSC エンドポイントは、プロデューサー プロジェクトに存在する PSC サービス アタッチメントへの転送ルールです。

注: アプリケーションは、Cloud SQL へのプライベート接続が可能な他のクライアント プラットフォームでもかまいません。また、データベース エンジンは、PostgreSQL / Microsoft SQL Server または MySQL を実行できる Cloud SQL を使用できます。

DNS のオーバーレイ

企業では一般的に、データベースの IP アドレスにわかりやすいドメイン名を付けます。プロデューサー ネットワークとコンシューマ ネットワークの両方を分離した状態に保つには、各 VPC ネットワークに個別のプライベート クラウド DNS インスタンスを作成するのが最適です。次に、規則として、両方のネットワークで同じ論理リソース（ターゲット データベース）に、類似した DNS 名を割り当てます。類似の名前を使用することで、両チームがより効率的にやりとりすることができます。

たとえば、アプリケーション VPC（コンシューマ）には、IP アドレス 172.168.32.2 に解決される DNS エントリ db-inst1.app1.acemy.com があります。そのため、アプリケーションは db-inst1.app1.acemy.com:3306 という URI を使用して接続します。同様に、データベース VPC（プロデューサー）には、Cloud SQL インスタンスの IP アドレスに解決されるエントリ db-inst1.dbs.acemy.com があります。なお、DNS のサブドメインに微妙な違い（app1 と dbs）がある点に注意してください。db-inst1.dbs.acemy.com の DNS 名は、（Cloud SQL IP の代わりに）IP テーブルの構成で使用できます。

両方のネットワークでまったく同じ DNS 名を使用することは可能ですが、デバッグや人間によるコミュニケーションの問題が生じる可能性があります。

複数のデータベース インスタンスへの接続を管理

データベース チームは、複数の異なるアプリケーションにサービスを提供し、複数の異なるデータベース エンジンをホストすることができます。各データベース インスタンスへの接続を提供するには、PSC、ILB、VM の各リソースが必要になります。これは、以下のアーキテクチャのどちらか、または両方を組み合わせて対応できます。

1. シンプルなデプロイ

このアーキテクチャでは、Cloud SQL インスタンスごとに接続のための gcp リソースが個別にプロビジョニングされます。マルチテナントのアプリケーションや、ノイジー ネイバーの問題のリスクがある場合に適しています。そのため、このアーキテクチャの使用をおすすめします。

2. 共有リソースを使用したデプロイ

このアーキテクチャでは、青色（ポート 3316）とオレンジ色（ポート 3317）で示されるように、クライアント アプリケーションは Cloud SQL インスタンスごとに異なるポートを使用して接続する必要があります。PSC エンドポイントとサービス アタッチメントには、ポート バインディングがありません。そのため、許可されたポートに対して同じ ILB を通過させることができます。VM は、それぞれの Cloud SQL インスタンスへの各ポートの IP テーブルルートを使用して構成する必要があります。

リソースの共有には、費用面でのメリットがありますが、実装する前に考慮すべきいくつかの要因があります。

• すべてのアプリケーションが、すべての Cloud SQL インスタンスへのネットワーク パスを持つことになるため、これが懸念される可能性がある。

• 新しい Cloud SQL インスタンスがオンラインになると、ip-tables の更新が複雑になる。

• ノイジー ネイバーの問題。あるデータベース インスタンスが高いトラフィックを発生させると、共通のインスタンス グループが詰まってしまう可能性がある。

推奨事項とベスト プラクティス

• PSC ベースのソリューションには、インスタンス グループの VM で発生するホップ（クライアント アプリケーションから Cloud SQL インスタンスへのパス）が 1 つしかありません。そのため、レイテンシのオーバーヘッドを最小限に抑えることができます。これは、PSC と ILB が GCP の VPC ネットワークのソフトウェア定義構造の一部であるためです。

• インスタンス グループの VM ネットワーク パフォーマンスはマシンタイプによって異なるため、帯域幅の要件を考慮し、それに応じて VM サイズを選択します。

• 攻撃対象を軽減して、OS のパッチ適用の頻度を減らすために、フットプリントが最小の VM オペレーティング システム（Ubuntu Minimal LTS など）を使用することをおすすめします。

• 高可用性を実現するためにマネージド インスタンス グループを使用し、ゾーン障害から自動的に回復するようにします。

• データベース接続が長時間ステートフル（キャッシュ接続プールなど）で実行されている場合、IP テーブルを使用して VM を頻繁に再起動しないようにします。同様に、頻繁に自動スケーリング（そして縮小）を発生させるような構成も避けるようにします。