はじめのProfessional Cloud Developer認定取得講座④Cloud SQL Auth Proxy 接続ガイド、Cloud Workstations × VPC SC、App Engine & Cloud Run移行術を説明します！

クラウド

Professional Cloud Developer 試験では、アプリケーションの実装だけでなく、安全でスケーラブルなクラウドアーキテクチャを設計する能力が問われます。

重要になるのが次の3つのテーマです。

  • Cloud SQL Auth Proxy を利用したセキュアなデータベース接続
  • Cloud Workstations と VPC Service Controls を組み合わせた 安全な開発環境
  • コンテナ化を前提とした App Engine から Cloud Run へのモダンな移行戦略

これらは試験対策として頻出であるだけでなく、実際のエンタープライズ開発でも重要なベストプラクティスです。

本記事では、Professional Cloud Developer を目指す開発者向けに、Google Cloud における セキュリティ・開発環境・アプリケーション移行の重要ポイントを整理します。

是非、最後までご覧いただけると嬉しいです。

Cloud SQL Auth Proxy 接続ガイド

Google Cloud では、データベースへの接続時にパスワードをハードコードしたり、複雑なSSL証明書を手動で管理したりすることを推奨していません。その代わりに、Cloud SQL Auth Proxy を使用して、IAM（Identity and Access Management）による認証と、自動的な通信暗号化を両立させます。

1. なぜ Cloud SQL Auth Proxy なのか？

Professional Cloud Developer試験の選択肢に「SSL証明書をダウンロードして配布する」というものがあれば、多くの場合それは「不正解」です。Auth Proxy を使うべき理由は以下の3点に集約されます。

  • 全通信の自動暗号化：プロキシが Cloud SQL インスタンスとの間に 256ビット AES 暗号による相互 TLS（mTLS）トンネルを自動で構築します。
  • IAM データベース認証：データベース固有のパスワードの代わりに、Google Cloud の IAM 権限を使用してログインできます。
  • IP制限の回避：インスタンスにパブリック IP が割り当てられていなくても（プライベート IP のみでも）、適切な権限があればローカルから接続可能です。

2. 事前準備：IAM 権限の設定

「認証させた状態」を保つためには、ローカルで使用する Google アカウント（またはサービスアカウント）に適切なロールを付与する必要があります。

  1. Cloud SQL クライアント (roles/cloudsql.client)：プロキシがインスタンスに接続するために必須。
  2. Cloud SQL インスタンス利用者 (roles/cloudsql.instanceUser)：IAM 認証を使用してデータベースにログインするために必要。
試験対策ポイント：データベース自体のユーザー作成時、認証タイプを「IAM」に設定しておく必要があります（インスタンスで IAM データベース認証を有効にするには、cloudsql_iam_authentication フラグを使用します）。

3. ローカル環境での Auth Proxy のセットアップ

ローカル開発マシンでプロキシを起動し、アプリケーションからのリクエストを待ち受けます。

Cloud SQL Auth Proxy をダウンロードしてインストールする

以下のリンクを参照して、開発環境のOSに応じて、Cloud SQL Auth Proxy をダウンロードしてインストールします。

Cloud SQL Auth Proxy について  |  Cloud SQL for MySQL  |  Google Cloud Documentation
docs.cloud.google.com

プロキシの起動コマンド（IAM認証有効化）

Cloud SQL Auth Proxy では、--auto-iam-authn オプションを利用することで、Cloud SQL の IAMデータベース認証を使用できます。

./cloud-sql-proxy --auto-iam-authn --port 5432 [INSTANCE_CONNECTION_NAME]

＜各オプションの説明＞

・–auto-iam-authn

Cloud SQL の IAM Database Authentication を有効化するオプションです。
このオプションを使用すると、Cloud SQL Auth Proxy が Google Cloud の認証情報を利用して短期間有効なデータベース認証トークンを自動生成します。

その結果、静的なデータベースパスワードを管理する必要がなくなり、より安全な認証方式を利用できます。

・INSTANCE_CONNECTION_NAME

接続する Cloud SQL インスタンスを指定します。
形式は以下の通りです。

project-id:region:instance-id

4. App Engine アプリケーションからの接続（ローカルテスト）

App Engine 向けのアプリケーションをローカルでテストする場合、環境変数などを利用して接続先を切り替えます。

  • 本番環境：App Engine の標準的な接続方法（Unix ドメインソケットなど）を使用。
  • ローカル環境：Auth Proxy が待ち受けている localhost:5432（PostgreSQL の場合）または localhost:3306（MySQL の場合）に接続。

5. セキュリティとベストプラクティスの深掘り

試験で問われやすい「一歩進んだ」知識を整理します。

  • シークレット管理：IAM 認証を使うことで、app.yaml やソースコードにデータベースのパスワードを記述するリスクを完全に排除できます。これは 12-Factor App の原則にも合致するモダンな手法です。
  • SSL/TLS 証明書の更新：手動で SSL を設定すると証明書の期限切れ（通常2年）に悩まされますが、Auth Proxy は 1時間ごとに有効期限が切れる短命な証明書を自動発行・更新します。運用負荷の低減として非常に強力です。
  • ポートの競合：ローカルに PostgreSQL が既にインストールされている場合は、--port 5433 のようにプロキシの待ち受けポートをずらす必要があります。

Cloud SQL Auth Proxy 接続ガイドのまとめ

Cloud SQL Auth Proxy は、Google Cloud におけるデータベース接続を安全かつ簡単に実現するための推奨手法です。IAM 認証と自動暗号化通信により、パスワード管理や SSL 証明書の手動運用といった負担を大幅に削減できます。適切な IAM ロールを設定することで、ローカル環境からでも安全に Cloud SQL へ接続することが可能になります。また、Auth Proxy を活用することでシークレット管理のリスクを低減し、モダンなアプリケーション開発のベストプラクティスにも適合します。試験対策としても、SSL 証明書の手動管理より Auth Proxy を利用するアーキテクチャが推奨される点を理解しておくことが重要です。

Cloud Workstations × VPC Service Controls

モダンなクラウド開発者にとって、開発環境は「個人のPC」から「管理されたクラウド上のリソース」へとシフトしています。試験では、エンタープライズレベルでの開発ガバナンスをどう実現するかが問われます。

1. Cloud Workstations：一貫性のある開発基盤

Cloud Workstations は、Google Cloud 上で提供される完全に管理された開発環境です。

  • 「自分のマシンでは動く」の解消：管理者があらかじめ定義したコンテナイメージを使用してワークステーションを作成するため、ライブラリのバージョンやツールチェーンがチーム全員で完全に一致します。
  • 迅速なオンボーディング：新しいメンバーが加わっても、環境構築に数日かける必要はありません。数分で、設定済みの IDE（VS Code, IntelliJ, PyCharm など）にブラウザ経由でアクセスできます。
  • コストと管理の最適化：アイドル時の自動停止機能により、未使用時のコストを抑えつつ、一元的なパッチ適用やセキュリティ設定が可能です。

2. VPC Service Controls：データの外出しを許さない境界線

開発環境がクラウドにあるということは、機密データにアクセスしやすくなる反面、持ち出しのリスクも高まります。そこで登場するのが VPC Service Controls (VPC SC) です。

  • サービス境界（Service Perimeter）：Cloud Storage や BigQuery などの Google Cloud サービスを「境界」の中に閉じ込めます。これにより、たとえ有効な認証情報を持っていても、境界の外（許可されていないネットワーク）からはデータにアクセスできなくなります。
  • データエクスフィルトレーション（データ漏洩）の防止：悪意のあるユーザーや設定ミスによって、本番環境のデータが個人のストレージにコピーされるのを防ぎます。
  • 試験のポイント：PCD試験では「高度なセキュリティ要件を満たしつつ、開発者が自由にツールを使える環境はどれか」という文脈で、VPC SC と Cloud Workstations の組み合わせが正解となるケースが多いです。

3. 一貫性と DX を向上させる統合設計

これら 2 つを組み合わせることで、開発者は「安全で、かつ何も気にせず開発に没頭できる」環境を手に入れます。

理想的な開発フローの構築

  1. 境界内の開発：Cloud Workstations を VPC SC の境界内に配置します。
  2. 安全なアクセス：開発者は境界の外からでも、Identity-Aware Proxy (IAP) 経由で安全に自分のワークステーションにログインします。
  3. シームレスなデプロイ：開発環境から直接、境界内の Cloud Build や Artifact Registry を叩き、本番同様のパイプラインをテストできます。

4. 試験で狙われる「開発者体験」の重要トピック

課題ソリューションメリット
環境の不一致Cloud Workstations (カスタムイメージ)バグの再現性が高まり、デバッグ時間が短縮される。
セキュリティ制約による不便さCloud Workstations + IAPVPN 不要で、場所を選ばずセキュアに開発可能。
機密データの取り扱いVPC Service Controls開発者に強い権限を与えても、物理的にデータの持ち出しを制限できる。

Cloud Workstations × VPC Service Controlsのまとめ

Cloud Workstations は、管理されたクラウド開発環境を提供し、チーム全体で一貫した開発基盤を実現します。これにより、環境差異によるトラブルを防ぎ、迅速なオンボーディングや効率的な運用が可能になります。さらに、VPC Service Controls を組み合わせることで、機密データの外部流出を防ぐ強固なセキュリティ境界を構築できます。Cloud Workstations を VPC SC の境界内に配置し、Identity-Aware Proxy を通じて安全にアクセスすることで、安全性と開発者体験を両立した開発環境が実現します。エンタープライズ開発では、このような統合設計が重要なベストプラクティスとなります。

App Engine & Cloud Run移行術

オンプレミスで動いているウェブ API を移行する場合、単純な「Lift & Shift（そのまま移す）」だけでは、廃止予定の技術を延命させるだけになってしまいます。PCDとして提案すべきは、「コンテナ化」を橋渡しにしたモダナイズです。

1. App Engine フレキシブル環境：レガシーへの「最後の救済措置」

もしそのAPIが、特定のOSライブラリに依存していたり、標準的なランタイム（Python 3.12など）では動かない古い言語バージョンを使用しているなら、まずは App Engine フレキシブル環境（Flex） を検討します。

  • なぜ Flex か？：Dockerコンテナが動く環境であれば、中身がどれほどレガシーでも動作します。バックエンドでは Compute Engine の VM が動いているため、SSHでのデバッグや、非標準的なネットワーク構成にも対応可能です。
  • 移行のメリット：オンプレミスからの「最小限の修正」でクラウドへ持ち込めます。インフラ管理（パッチ適用など）をGoogleに任せつつ、既存のコードをそのまま動かせるため、期限優先の状況に強いです。

2. Cloud Run：モダナイズの「本命」ソリューション

移行と同時に「APIをモダンに作り変えたい」のであれば、現在のGoogle Cloudにおける開発者体験の頂点、Cloud Run が最良の選択肢です。

  • サーバーレスの極致：リクエストが来ない時はインスタンスがゼロになる「0へのスケーリング」が可能で、コスト効率が抜群です。
  • Knative ベース：特定のベンダーロックインを避けつつ、業界標準のコンテナ技術でAPIをデプロイできます。
  • 移行のポイント：オンプレミスで動いていたAPIを Dockerfile でパッケージ化さえできれば、Cloud Run への移行は一瞬です。これにより、サーバー管理の苦労から永遠に解放されます。

3. 試験で問われる「環境の選択」：Standard vs Flexible vs Cloud Run

試験では「どの環境が最適か」を瞬時に判断する必要があります。以下の比較表を頭に叩き込んでください。

特徴App Engine スタンダードApp Engine フレキシブルCloud Run (推奨)
起動速度数秒（爆速）数分（VMの起動待ち）数秒（高速）
スケーリング0までスケール可能最低 1 インスタンス必要0までスケール可能
自由度制限あり（特定言語のみ）非常に高い（Docker）高い（Docker）
主な用途標準的なWebアプリレガシー/重い処理モダンなWeb API
試験のヒント：「廃止予定のAPI」というワードが出た場合、将来的な拡張性やメンテナンス性を考慮して、Cloud Run への移行（コンテナ化）を第一候補として考え、それが技術的に困難（長時間実行が必要、OSへの特殊なアクセスが必要など）な場合にのみ Flex を選ぶのがPCD的な正解ルートです。

4. 移行を成功させる具体的なステップ

  1. コンテナ化（Dockerize）：オンプレミスのAPIをコンテナ化します。これが Flex と Cloud Run 両方への「共通チケット」になります。
  2. Artifact Registry への登録：ビルドしたイメージを Google Cloud 上で管理します。
  3. トラフィックの切り替え：Cloud SQL などのマネージドデータベースへ接続先を変更し、徐々にトラフィックをオンプレミスから Google Cloud へ流します（カナリアリリース）。

App Engine & Cloud Run移行術のまとめ

オンプレミスの Web API をクラウドへ移行する際は、単なる Lift & Shift ではなく「コンテナ化」を軸としたモダナイズが重要です。レガシーな依存関係が強い場合は、柔軟な実行環境を提供する App Engine フレキシブル環境が一時的な移行先として有効です。一方で、モダンな API 基盤としてはサーバーレスで高いスケーラビリティを持つ Cloud Run が最も推奨される選択肢となります。コンテナ化を行うことで両環境への移行が可能になり、段階的なクラウド移行を実現できます。PCD試験では、将来の拡張性や運用効率を考慮して Cloud Run を第一候補として判断することが重要です。

まとめ

今回は、下記３点について説明しました。

  1. Cloud SQL Auth Proxy 接続ガイド
  2. Cloud Workstations × VPC Service Controls
  3. App Engine & Cloud Run移行術

今回の記事では、Professional Cloud Developer として理解しておくべき Google Cloud の開発基盤とアーキテクチャ設計について整理しました。

Cloud SQL Auth Proxy を利用することで、IAM ベースの認証と暗号化通信を実現し、安全かつシンプルなデータベース接続を構築できます。また、Cloud Workstations と VPC Service Controls を組み合わせることで、機密データを保護しながら統一されたクラウド開発環境を提供することが可能になります。

さらに、オンプレミスアプリケーションのクラウド移行では、単なる Lift & Shift ではなく コンテナ化を軸としたモダナイズが重要です。特に Cloud Run はスケーラビリティと運用効率の観点から、モダンな API 基盤として最も推奨されるサービスです。

Professional Cloud Developer 試験では、これらのサービスを個別に理解するだけでなく、セキュリティ・開発体験・スケーラビリティを考慮した最適なアーキテクチャを選択できるかが問われます。今回のポイントを整理しておくことが、試験合格と実務でのクラウド開発力向上の両方につながるでしょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました