はじめのProfessional Cloud Developer認定取得講座⑬gRPCとHTTP/2による超低レイテンシ通信の実装ガイド、GKEからCloud Storageへ安全にアクセスするWorkload Identity構築ガイド、Cloud SQL for PostgreSQLからAlloyDBに移行する方法を説明します！

クラウド

Google Cloud の Professional Cloud Developer 認定試験では、単なるアプリケーション開発だけでなく、「高速通信」「安全な認証」「高性能データベース移行」まで含めたクラウドネイティブ設計が重要なテーマとなります。

本記事では、Cloud Run における gRPC と HTTP/2 を活用した超低レイテンシ通信、GKE の Workload Identity を用いた安全な認証基盤、そして Cloud SQL for PostgreSQL から AlloyDB への移行手法について解説します。
これらはいずれも、実務で求められるスケーラビリティ・セキュリティ・運用性を高いレベルで両立するための重要技術です。

また、Professional Cloud Developer 試験でも頻出となる「マイクロサービス設計」「IAM」「データベース移行」「クラウドネイティブアーキテクチャ」の理解にも直結します。

単なるサービス紹介ではなく、実装時の注意点や Google 推奨のベストプラクティスまで踏み込みながら、実践的に整理していきます。

今回も音声ファイルも挿入していますので、ブログの内容を音声でご確認いただけます。通勤中などにご利用いただければと思います。

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

gRPCとHTTP/2による超低レイテンシ通信の実装ガイド

マイクロサービス化が進むにつれ、サービス間通信のレイテンシはシステム全体の性能を左右する重要な要素になります。特に Cloud Run 同士で大量のAPI通信を行う場合、HTTP/1.1ベースの実装では接続確立や待ち時間がボトルネックになりがちです。

そこで注目されているのが、HTTP/2 のマルチプレクシングと Protocol Buffers の軽量シリアライズを組み合わせた gRPC です。

Cloud Run では HTTP/2 を有効化することで、少ない接続数で高スループットな通信を実現でき、リアルタイム処理や高頻度アクセスにも強い構成を構築できます。さらに、proto3 による型安全なAPI設計やコネクション再利用を組み合わせることで、レイテンシと運用性を両立したマイクロサービス基盤が完成します。

本記事では、Cloud Run における gRPC / HTTP/2 通信の実装方法から、Google推奨の proto3 設計、低レイテンシ化の運用ポイントまでを実践的に解説します。

1. 基盤の構築：Cloud RunでHTTP/2を有効にする

Cloud RunでgRPCや高速なストリーミング通信を行うためには、まずコンテナへのトラフィックをHTTP/2で受け取れるように明示的に構成する必要があります（デフォルトではHTTP/1.1にダウングレードされる場合があります）。

設定方法

Cloud Runサービスをデプロイ、または更新する際に --use-http2 フラグを付与するか、Google Cloudコンソールの「コンテナ」設定からHTTP/2を有効にします。

＜gcloudコマンド＞

gcloud run deploy [SERVICE_NAME] \
    --image=[IMAGE_URL] \
    --use-http2 \
    --port=50051
⚠️ 重要：コンテナはh2c（クリアテキスト）のみ対応が必要

Cloud RunはTLSをフロントエンドで終端した後、コンテナにはHTTP/2クリアテキスト（h2c）形式でリクエストを転送します。コンテナはトランスポート層のセキュリティを直接実装すべきではありません。TLSはCloud Runが処理し、コンテナにはTLSなしでリクエストが届きます。

したがって、アプリケーション（コンテナ内部）は指定したポートで h2c（HTTP/2クリアテキスト）形式のみ をリッスンするよう実装してください。コンテナ内でTLSを直接終端する実装は不要かつ不正確です。

ローカルでの動作確認は以下のコマンドで行えます：

＜Bashコマンド＞

curl -i --http2-prior-knowledge http://localhost:[PORT]

2. データの高速道路：gRPCの導入

HTTP/2という高速道路を通す準備ができたら、その上を走るデータをgRPC（Protocol Buffers）に切り替えます。JSONのようなテキストベースのデータ形式に比べ、バイナリ形式でシリアライズされるProtocol Buffersはデータサイズが圧倒的に小さく、CPUによるパース処理も劇的に高速です。

Cloud RunでgRPCを使うメリット

  • 双方向ストリーミング：大量の株価データやログ、リアルタイムメッセージなどのストリーミング処理が、サーバーレス環境でも容易に実現できます。
  • 強力な型安全：クライアントとサーバーのコードが同じ .proto ファイルから自動生成されるため、通信の型崩れによるバグが発生しません。

3. Google推奨のAPI設計：Proto3構文（AIP-191）の遵守

gRPCのAPI（.proto ファイル）を設計する際、開発者ごとに書き方がバラバラだとメンテナンス性が低下します。GoogleのAPI設計ガイドラインであるAIP-191では、クリーンでスケーラブルなAPIを作るための標準構文（proto3）のルールが定義されています。

① syntax = "proto3"; の明示

ファイルの先頭で必ず proto3 の使用を宣言します。古い proto2 に比べ、フィールドの存在チェックの仕様がクリーンになり、マイクロサービス間での前方・後方互換性が維持しやすくなります。

② フィールド番号の適切な割り当て

Protocol Buffersでは、フィールド名（例：user_name）ではなくフィールド番号（1, 2, 3…）を使ってバイナリデータを識別します。

  • 1〜15番の番号：バイナリにエンコードした際、わずか「1バイト」で表現できます。最も頻繁に通信される、スループットに影響するフィールドには1〜15番を割り当てるのが鉄則です。
  • 16〜2047番の番号 は2バイトを消費します。
良い設計例（AIP-191準拠）

＜Protobuf＞

syntax = "proto3";

package google.example.v1;

message GetUserRequest {
  // 頻繁に使うIDは1バイトで収まる1番を割り当て
  string user_id = 1;
}

message User {
  string user_id = 1;
  string display_name = 2;
  string email = 3;
}

4. マイクロサービス間通信を成功させる運用のコツ

コネクションの使い回し（Connection Pooling）

Cloud Runはリクエストがないとインスタンスがゼロになる（コールドスタート）特性があります。呼び出し側のマイクロサービスでは、リクエストごとに毎回gRPCのクライアント（Channel）を作り直すのではなく、一度作成したChannelをアプリケーションの生存期間中に使い回すように設計してください。これにより、接続遅延をさらに数ミリ秒削ることができます。

リトライとタイムアウトの制御

HTTP/2マルチプレクシングは強力ですが、ネットワークの一時的な瞬断に備え、クライアント側には必ず「指数バックオフによるリトライロジック」と「デッドライン（タイムアウト設定）」を仕込んでおくのがSRE観点でのベストプラクティスです。

gRPCとHTTP/2による超低レイテンシ通信の実装ガイドのまとめ

Cloud Run における超低レイテンシ通信を実現するには、HTTP/2 と gRPC の組み合わせが非常に効果的です。
HTTP/2 のマルチプレクシングにより、複数リクエストを単一接続で並列処理でき、接続待ちによるオーバーヘッドを大幅に削減できます。

さらに、Protocol Buffers を利用した gRPC は、JSON より軽量かつ高速なデータ通信を可能にし、高スループットなマイクロサービス通信を実現します。また、Cloud Run の h2c 対応や、AIP-191 に準拠した proto3 設計を理解することで、将来的な拡張性や互換性も確保できます。

加えて、Connection Pooling やタイムアウト制御、リトライ設計を組み合わせることで、実運用でも安定した通信基盤を維持できます。

これらを実践することで、Cloud Run 上でもリアルタイム性とスケーラビリティを両立した、高性能なクラウドネイティブアーキテクチャを構築できます。

GKEからCloud Storageへ安全にアクセスするWorkload Identity構築ガイド

GKE 上のアプリケーションから Cloud Storage へアクセスする際、JSON形式のサービスアカウン キーをPodへ配布していませんか？この方法は管理負荷が高いだけでなく、鍵漏洩のリスクも抱えるため、現在の Google Cloud では推奨されていません。

そこで重要になるのが、GKE ネイティブの認証機構である Workload Identity です。

Workload Identity を利用することで、Pod に永続的な秘密鍵を保持させることなく、安全に Cloud Storage や各種 Google Cloud API へアクセスできるようになります。また、Kubernetes サービスアカウント（KSA）と Google サービスアカウント（GSA）を適切に紐付けることで、最小権限に基づいた安全なアクセス制御も実現できます。

本記事では、Workload Identity の仕組みから、GKE と Cloud Storage を安全に接続する具体的な設定手順、さらに運用時のベストプラクティスまでを実践的に解説します。

1. 2つのサービスアカウントの役割

設定を進める前に、混同しやすい2つのアカウントを整理しておきましょう。

  • Kubernetes サービスアカウント（KSA）：GKEクラスター内部で作成されるアカウント。Podに割り当てられます。
  • Google サービスアカウント（GSA）：Google Cloudプロジェクト側で作成されるアカウント。GCSバケットの読み書き権限（例：roles/storage.objectViewer）を付与されます。

2. Workload Identityの設定手順

GKEからGCSバケットへのアクセスを許可する手順をステップごとに解説します。

ステップ1：クラスターでWorkload Identityを有効化

＜gcloudコマンド＞

# 新規クラスター作成時
gcloud container clusters create [CLUSTER_NAME] \
    --workload-pool=[PROJECT_ID].svc.id.goog \
    --zone [ZONE]

# 既存クラスターへの有効化
gcloud container clusters update [CLUSTER_NAME] \
    --workload-pool=[PROJECT_ID].svc.id.goog \
    --zone [ZONE]

ステップ2：Google サービスアカウントの作成と権限付与

＜gcloudコマンド＞

# GSAの作成
gcloud iam service-accounts create gcs-reader-gsa \
    --display-name="GCS Reader GSA"

# GCSバケットへの読み取り権限を付与
gcloud storage buckets add-iam-policy-binding gs://[BUCKET_NAME] \
    --member="serviceAccount:gcs-reader-gsa@[PROJECT_ID].iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

ステップ3：Kubernetesサービスアカウントの作成

＜gcloudコマンド＞

# 名前空間の作成（存在しない場合）
kubectl create namespace my-app-ns

# KSAの作成
kubectl create serviceaccount gcs-reader-ksa \
    --namespace my-app-ns

ステップ4：KubernetesサービスアカウントとGoogle サービスアカウントの紐付け

Kubernetes サービスアカウントがGoogle サービスアカウントを借用（impersonate）できるよう、roles/iam.workloadIdentityUser ロールのIAMポリシーバインディングを作成します。

＜gcloudコマンド＞

gcloud iam service-accounts add-iam-policy-binding \
    gcs-reader-gsa@[PROJECT_ID].iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:[PROJECT_ID].svc.id.goog[my-app-ns/gcs-reader-ksa]"

ステップ5：Kubernetesサービスアカウントにアノテーションを追加

Kubernetesサービスアカウント側にも、対応するGSAを示すアノテーションを付与します。

＜gcloudコマンド＞

kubectl annotate serviceaccount gcs-reader-ksa \
    --namespace my-app-ns \
    iam.gke.io/gcp-service-account=gcs-reader-gsa@[PROJECT_ID].iam.gserviceaccount.com

3. アプリケーション（Pod）での利用方法

設定が完了したら、PodのマニフェストでKubernetes サービスアカウントを指定するだけです。アプリケーションコードに特別な認証ロジックを書く必要は一切ありません。Google CloudのSDKが自動的にWorkload Identityの認証情報を検出します。

＜YAMLファイル＞

apiVersion: apps/v1
kind: Deployment
metadata:
  name: storage-app
  namespace: my-app-ns
spec:
  replicas: 1
  selector:                         # 必須フィールド
    matchLabels:
      app: storage-app
  template:
    metadata:
      labels:
        app: storage-app
    spec:
      serviceAccountName: gcs-reader-ksa    # Kubernetes サービスアカウントを指定
      containers:
      - name: app-container
        image: gcr.io/[PROJECT_ID]/my-app:v1

4. Googleが推奨するセキュリティ・ベストプラクティス

  • 最小権限の原則（Least Privilege）：1つの巨大なGoogle サービスアカウントをすべてのPodで使い回すのではなく、役割（例：ログ書き込み用、画像読み込み用）ごとに個別のKubernetesサービスアカウントとGoogle サービスアカウントのペアを作りましょう。
  • 名前空間による隔離：Kubernetesの名前空間（Namespace）を利用して、開発環境（dev）と本番環境（prod）で同じKubernetesサービスアカウント名であっても異なるKubernetesサービスアカウントを紐付けるように設計します。これにより、環境間のリソース混同を防ぐことができます。
  • メタデータサーバーの保護：ネットワークポリシーなどを利用して、不要なPodからGKEの内部メタデータサーバーへのアクセスを制限し、クラスタ全体のセキュリティをより強固にします。

GKEからCloud Storageへ安全にアクセスするWorkload Identity構築ガイドのまとめ

Workload Identity を導入することで、GKE から Cloud Storage へのアクセスを、秘密鍵不要かつ安全に実現できます。特に、Kubernetesサービスアカウント と Google サービスアカウント を適切に紐付けることで、Pod ごとに最小権限の IAM 設計を適用できる点が大きなメリットです。

また、JSON鍵の配布・保管・ローテーションが不要になるため、セキュリティリスクと運用負荷を大幅に削減できます。

さらに、アプリケーション側では serviceAccountName を指定するだけで認証が自動化されるため、実装も非常にシンプルです。名前空間による環境分離や、roles/iam.workloadIdentityUser の適切な設定を組み合わせることで、より堅牢なGKE運用基盤を構築できます。

これらを実践することで、Google Cloud が推奨するクラウドネイティブな認証アーキテクチャへ、安全かつ効率的に移行できます。

Cloud SQL for PostgreSQLからAlloyDBに移行する方法

Cloud SQL for PostgreSQL は、多くのシステムで安定したマネージドデータベースとして利用されています。しかし、アクセス数の増加や分析処理の高度化に伴い、「より高いスループット」や「大規模クエリの高速化」が求められる場面も増えてきます。

そこで次の選択肢として注目されているのが、Google Cloud の次世代 PostgreSQL 互換データベースである AlloyDB for PostgreSQL です。

AlloyDB は、PostgreSQL 完全互換を維持しながら、ストレージとコンピューティングを分離したモダンアーキテクチャにより、圧倒的な性能向上を実現しています。さらに、カラムナエンジンによる高速分析処理や、ほぼゼロ遅延のリードレプリカなど、大規模システム向けの機能も標準搭載されています。

本記事では、Cloud SQL から AlloyDB へ安全かつ最小ダウンタイムで移行するための手順と、移行時に押さえるべき重要ポイントを実践的に解説します。

1. なぜAlloyDBなのか？（Cloud SQLとの違い）

AlloyDBは、ストレージとコンピューティングを分離したモダンなアーキテクチャを採用しています。これにより読み取り・書き込みの双方が劇的に高速化されるだけでなく、分析クエリを高速化する「カラムナエンジン（列指向エンジン）」も搭載されています。

特徴Cloud SQL for PostgreSQLAlloyDB for PostgreSQL
互換性PostgreSQL標準完全なPostgreSQL互換
アーキテクチャ従来のインスタンス型ストレージ・コンピューティング分離型
分析クエリ高速化インデックス等による最適化が必要自動カラムナエンジンによる高速処理
スケーラビリティリードレプリカの追加による拡張超高速な読み取りレプリカの追加（遅延ほぼゼロ）

パフォーマンス比較（標準PostgreSQL比）

AlloyDBは分析クエリにおいて標準PostgreSQLと比べて最大100倍高速です。トランザクション処理においても標準PostgreSQLと比べて最大4倍のパフォーマンス向上が確認されています。 

⚠️ 注意： 上記は「Cloud SQL比」ではなく「標準PostgreSQL比」の数値です。Cloud SQLとの直接比較は公式には公開されていません。

セキュリティとコンプライアンス

AlloyDBは、データの自動暗号化はもちろん、顧客管理暗号鍵（CMEK）への対応、IAMによる厳格なアクセス制御など、エンタープライズが必要とする高度なセキュリティ・プライバシー基準（HIPAA、PCI-DSSなど）を標準で満たしています。

2. 移行前の重要チェック：拡張機能（Extensions）

PostgreSQLの強力なエコシステムを支えるのが「拡張機能（Extension）」です。AlloyDBはPostgreSQLの主要な拡張機能を幅広くサポートしています。

  • PostGIS（位置情報データ処理）
  • pg_stat_statements（クエリパフォーマンス分析）
  • uuid-ossp（UUID生成）

移行前に、現在使用している拡張機能がAlloyDBのサポート対象に含まれているかを公式ドキュメントのリストで突合しておきましょう。ほとんどの一般的な拡張機能はそのまま動作するため、アプリケーションコードの修正はほぼ不要です。

3. Cloud SQLからAlloyDBへの移行ステップ

Google Cloud公式ではDatabase Migration Service（DMS）を使った移行が推奨されています。DMSはネットワーク設定の自動化、初期スナップショットの作成、継続的なレプリケーションの管理、ステータス更新を一元的に処理します。特にCloud SQLがプライベートIPで構成されている場合は、クイックスタート移行フローも利用できます。

ステップ1：移行元の準備（Cloud SQL）

Cloud SQL側で論理レプリケーションを有効にする必要があります。具体的には、pglogical 拡張のインストール、shared_preload_libraries への pglogical の追加、cloudsql.logical_decoding を on に設定、max_replication_slots の適切な設定が必要です。またレプリケーション用の十分な権限を持ったユーザーを用意します。

ステップ2：移行先クラスターの作成（AlloyDB）

AlloyDB側で新しいクラスターとプライマリインスタンスを作成します。Cloud SQLと同等以上のリソース（CPU/メモリ）を持つマシンスペックを選択し、VPCネットワークが正しく疎通できるように構成します。

ステップ3：Database Migration Serviceの設定と初期同期

DMSのコンソールから接続プロファイルを作成し、マイグレーションジョブを設定します。DMSがCloud SQLの既存スキーマとデータをAlloyDBへ一括転送します。

ステップ4：継続的なレプリケーション（CDC）

初期データ転送後、Cloud SQLで発生するリアルタイムの更新（DML: INSERT/UPDATE/DELETE）をDMSが継続的にAlloyDBへ同期します。

⚠️ 重要：DDL変更は自動同期されません DDL変更（テーブル構造の変更など）はDMSによって自動的にレプリケーションされません。移行中にDDLを適用する場合は、ソースとデスティネーションの両方で手動実行するか、pglogical.replicate_ddl_command を使用する必要があります。移行期間中はスキーマ変更を避けるか、事前に手順を確立しておくことを強く推奨します。

ステップ5：切り替え（カットオーバー）

レプリケーション遅延がほぼゼロになったことを確認したら、アプリケーションを一時的にメンテナンスモードにしてCloud SQLへの書き込みを停止します。AlloyDBが完全に最新状態に追いついたのを確認後、レプリケーションを解除してAlloyDBをスタンドアロンのデータベースに昇格させ、アプリケーションの接続先をAlloyDBに切り替えます。

4. 運用のベストプラクティス

  • 十分なテスト期間の確保：移行前に、本番環境と同等のワークロードをテスト用AlloyDBにかけ、クエリ実行速度やリソース消費傾向を検証環境で十分に確認してください。
  • バックアップとロールバックプラン：切り替え後に予期せぬ問題が発生した場合に備え、即座にCloud SQL側に戻せる手順を事前にドキュメント化しておくことが鉄則です。
  • 移行中のDDL変更を最小化：移行中のスキーマ変更はレプリケーションの整合性を損なうリスクがあります。可能な限り移行期間中のDDL変更は凍結してください。

Cloud SQL for PostgreSQLからAlloyDBに移行する方法のまとめ

Cloud SQL for PostgreSQL から AlloyDB への移行は、PostgreSQL 完全互換であることから、比較的低リスクで実施できるのが大きな特徴です。

特に、Database Migration Service（DMS）を利用することで、継続的レプリケーションによる最小ダウンタイム移行を実現できます。また、AlloyDB のカラムナエンジンや高速リードレプリカを活用することで、分析クエリ性能とスケーラビリティを大幅に向上できます。

一方で、移行前には拡張機能の互換性確認や、DDL変更が自動同期されない点を十分に理解しておく必要があります。さらに、ロールバック手順や検証環境での負荷テストを事前に準備することで、移行時のリスクを最小限に抑えられます。

これらを実践することで、従来の Cloud SQL 環境から、より高性能でスケーラブルな AlloyDB 基盤へ安全にステップアップできます。

まとめ

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

  1. gRPCとHTTP/2による超低レイテンシ通信の実装ガイド
  2. GKEからCloud Storageへ安全にアクセスするWorkload Identity構築ガイド
  3. Cloud SQL for PostgreSQLからAlloyDBに移行する方法

Cloud Run では、HTTP/2 と gRPC を組み合わせることで、低レイテンシかつ高スループットなマイクロサービス通信を実現できます。また、GKE の Workload Identity を利用することで、JSON 鍵を使わずに Cloud Storage へ安全にアクセスでき、クラウドネイティブな認証基盤を構築可能です。

さらに、Cloud SQL for PostgreSQL から AlloyDB への移行では、DMS を活用した継続的レプリケーションによって、最小ダウンタイムでの移行を実現できます。加えて、AlloyDB のカラムナエンジンや高速レプリカを活用することで、大規模データ処理や分析性能を大幅に向上できます。

これらの技術は、Google Cloud が推奨するモダンなアーキテクチャ設計そのものであり、Professional Cloud Developer 試験対策としても非常に重要です。設計思想から実装・運用まで理解を深めることで、実務でも通用するクラウドネイティブ開発力を身につけることができます。

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

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

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