今回も、私がProfessional Cloud Developer試験の合格に向けて学習した内容をアウトプットとして解説します。
Professional Cloud Developer 試験では、単にコードを書く能力だけでなく、Google Cloud 上で安全かつスケーラブルなアプリケーションを設計する力が求められます。
特に重要になるのが、次の3つの設計要素です。
- API Gateway を利用したセキュアな API 公開
- Cloud Service Mesh を利用したサービス間通信の制御
- Pub/Sub を利用した疎結合でスケーラブルなイベント駆動アーキテクチャ
これらは試験対策として重要であるだけでなく、実務のクラウドネイティブ開発でも頻繁に登場する設計パターンです。
この記事では、Professional Cloud Developer を目指す開発者向けに、Google Cloud における セキュリティ・通信制御・非同期処理の重要ポイントを整理します。
是非、最後までご覧いただけると嬉しいです。
API Gateway の認証とサービスアカウント管理の鉄則
Google Cloud でスケーラブルな API を構築する際、API Gateway は「玄関口」の役割を果たします。開発者は、どのユーザーやシステムがアクセスを許可されているかを正確に制御しなければなりません。
1. API Gateway で利用可能な認証メソッド
API Gateway では、用途に応じて複数の認証方法を選択できます。試験では「どのシナリオでどの認証を選ぶべきか」が問われます。
| 認証メソッド | 主なユースケース | 特徴 |
| API キー | 公開データへのアクセス制限 | 非常にシンプルだがセキュリティは低い。割り当て制限（クォータ）の管理に便利。 |
| Firebase Auth | モバイル/Web アプリの一般ユーザー | Google、Facebook、メール/パスワードなど多様なログイン手段をサポート。 |
| Google ID トークン | Google アカウントを持つユーザー/サービス | OpenID Connect (OIDC) に基づく標準的な認証。 |
| サービスアカウント (JWT) | サーバー間通信 (M2M) | ユーザーの介入なしで、システム同士が安全に通信する場合に使用。 |
2. サービスアカウントによる認証の仕組み（JWT）
特に「Professional Cloud Developer」として理解しておくべきは、サービスアカウントを用いた JWT (JSON Web Token) 認証です。
認証のフロー
- トークンの作成：クライアント側でサービスアカウントの秘密鍵を使用し、自己署名 JWT を作成します。
- API への送信：HTTP リクエストの
Authorization: Bearer <JWT>ヘッダーにトークンを含めます。 - Gateway での検証：API Gateway はサービスアカウントの公開鍵を使用して JWT を検証し、有効であればバックエンドへリクエストを転送します。
3. サービスアカウント キー管理のベストプラクティス
試験では、技術的な実装だけでなく「最もセキュアな運用方法はどれか」というベストプラクティスも頻繁に問われます。サービスアカウントキーは「漏洩＝全権掌握」のリスクがあるため、管理には細心の注意が必要です。
鍵を作成・ダウンロードしない（最優先）
- Workload Identity の利用：GKE や Google Cloud 外部のワークロード（AWS/Azureなど）からは、直接キーを発行するのではなく、Workload Identity を使用して短期間有効なトークンを取得します。
- アタッチによる利用：Compute Engine や Cloud Run では、リソース自体にサービスアカウントをアタッチし、メタデータサーバーから自動的にトークンを取得します。
どうしても鍵が必要な場合の運用ルール
- ソースコードに含めない：
.envファイルや Git リポジトリへのコミットは厳禁です。 - 最小権限の原則 (PoLP)：その鍵に必要以上のロール（オーナー権限など）を付与せず、特定の API 操作のみを許可します。
- 定期的なローテーション：少なくとも 90 日ごとに鍵を新しく作成し、古いものを無効化します。
- 不要な鍵の削除：使用していないキーは即座に無効化・削除します。
API Gateway の認証とサービスアカウント管理の鉄則のまとめ
API Gateway は、Google Cloud における API の「玄関口」として、適切な認証方式を選択することが重要です。用途に応じて API キー、Firebase Auth、Google ID トークン、サービスアカウントなどを使い分けることで、安全なアクセス制御を実現できます。特にサーバー間通信では、サービスアカウントを用いた JWT 認証の仕組みを理解しておくことが Professional Cloud Developer に求められます。
また、サービスアカウントキーは漏洩時のリスクが非常に高いため、可能な限り鍵を作成せず、Workload Identity やサービスアカウントのアタッチを利用する設計が推奨されます。やむを得ず鍵を利用する場合でも、最小権限の原則と定期的なローテーションを徹底し、安全な運用を心がけることが重要です。
Cloud Service Mesh の基本とゲートウェイの実装
モダンなアプリケーション開発では、サービスが増えるほど「どのサービスがどこにあり、どう通信しているか」の管理が困難になります。Cloud Service Mesh は、Istio をベースとしたマネージドサービスで、コードを変更することなくこれらの課題を解決します。
1. Cloud Service Mesh とは何か？
Cloud Service Mesh は、複雑なマイクロサービス環境において以下の3つの柱を提供します。
- トラフィック管理：カナリアリリース、ブルー/グリーンデプロイ、トラフィック分割（A/Bテスト）の実現。
- セキュリティ：サービス間通信の自動的な mTLS（相互 TLS） 暗号化と、厳格な認証・認可。
- オブザーバビリティ：サービス間のレイテンシ、エラー率、トラフィック量を可視化し、分散トレーシングを提供。
2. トラフィックの入り口：Ingress Gateway の準備
外部からのトラフィックをメッシュ内に安全に取り込むために、Gateway の設定が必要です。最新の Google Cloud 実装では、従来の Kubernetes Ingress よりも柔軟な Gateway API の利用が標準となっています。
ゲートウェイ準備のステップ
- API の有効化：
meshconfig.googleapis.comやgkehub.googleapis.comなど、必要な API を有効にします。 - IAM 権限の付与：ゲートウェイをデプロイするユーザーやサービスアカウントに、
roles/container.adminなどの適切な権限を付与します。 - フリート（Fleet）への登録：GKE クラスターを「フリート」という管理単位に登録することで、マルチクラスター環境でも一貫したメッシュ管理が可能になります。
3. Gateway API vs Kubernetes Ingress
試験では、どちらの抽象化レイヤーを選択すべきか問われることがあります。
| 機能 | Kubernetes Ingress | Gateway API (推奨) |
| 設計思想 | 単一リソースで完結（シンプル） | 役割に応じた分離（スケーラブル） |
| 役割の分離 | 開発者がすべて設定 | インフラ担当（Gateway）と開発者（Route）で分離可能 |
| 柔軟性 | 限定的（アノテーションに依存） | 高度なトラフィック制御（HTTPRoute 等）を標準サポート |
4. セキュリティ：ゼロトラストの実現
CSM を導入する最大のメリットの一つは、アプリケーションコードを一切触らずに mTLS を有効化できる点です。
- ピア認証 (PeerAuthentication)：メッシュ内のサービス同士がどのように通信を証明するかを定義します（STRICT モードにすると暗号化されていない通信を拒否します）。
- リクエスト認証：JWT（JSON Web Token）などを使用して、エンドユーザーの身元を確認します。
- 認可ポリシー (AuthorizationPolicy)：「サービスAからサービスBへの POST リクエストのみ許可する」といった細かい制御を行います。
Cloud Service Mesh の基本とゲートウェイの実装のまとめ
Cloud Service Mesh は、マイクロサービス環境における通信管理・セキュリティ・可観測性を統合的に提供するサービスです。トラフィック管理や mTLS による暗号化、分散トレーシングなどを、アプリケーションコードを変更せずに実装できる点が大きな特徴です。外部からのアクセスを安全に取り込むためには、Ingress Gateway を構成し、適切な IAM 権限やフリート管理を設定する必要があります。また、最新の環境では Kubernetes Ingress よりも柔軟な Gateway API を利用する設計が推奨されています。
さらに、PeerAuthentication や AuthorizationPolicy を活用することで、ゼロトラストに基づいた厳格なサービス間通信制御を実現できます。
Pub/Sub 高度な配信制御とサブスクライバーの最適化
Pub/Sub はデフォルトで「1回以上の配信（At-least-once）」を保証しますが、エンタープライズ向けのシステムでは「正確に1回（Exactly-once）」や「順序の維持」が求められます。開発者としてこれらをどう制御すべきか、見ていきましょう。
1. Exactly-once delivery（正確に1回限りの配信）
分散システムにおける最大の課題は、ネットワークの遅延やリトライによってメッセージが重複することです。Pub/Sub の Exactly-once delivery 機能は、この問題をプラットフォーム側で解決します。
- 仕組み：サブスクリプション側でこの機能を有効にすると、Pub/Sub はメッセージが正常に確認応答（Ack）されるまで、再配信を抑制します。
- Ack 期限の自動延長：メッセージを処理中に Ack 期限（Ack Deadline）が切れそうな場合、Pub/Sub が自動的に期限を延長し、処理中のメッセージが他へ再配信されるのを防ぎます。
- 試験のポイント
- 「重複を最小限に抑えたい」という要件に対し、アプリケーション側で複雑な「べき等性（Idempotency）」の実装を減らせるソリューションとして提案されます。
- ただし、パフォーマンス（スループット）への影響や、完全に 0 になるわけではない（極稀なエッジケースでの重複可能性）という制約を理解しておく必要があります。
2. メッセージの順序保証（Ordering Keys）
通常、Pub/Sub はメッセージを並列で高速に処理するため、送信順序は保証されません。しかし、銀行の取引データやステータス更新のように、順番が重要なケースでは Ordering Keys を使用します。
- 実装方法：メッセージ送信時に
ordering_keyという属性を付与します。 - 動作：同じ
ordering_keyを持つメッセージは、パブリッシュされた順序でサブスクライバーに配信されます。 - 再試行の挙動：あるメッセージの配信に失敗した場合、同じキーを持つ後続のメッセージは、失敗したメッセージが成功（Ack）するまで配信が保留されます。
- コード例（Python）：
publisher.publish(topic_path, data, ordering_key="user_123")
3. サブスクライバーの設計：Pull vs Push
試験では、ワークロードに応じて Pull型 と Push型 のどちらが適切かを判断する問題が頻出します。
| 比較項目 | Pull サブスクリプション | Push サブスクリプション |
| 制御性 | サブスクライバー側で取得頻度を制御可能（バッチ処理向け） | Google Cloud が即座に送信（リアルタイム向け） |
| スケーリング | 大量のメッセージを効率的に処理 | App Engine や Cloud Run のオートスケールと相性が良い |
| ネットワーク | サブスクライバーがインターネット経由で Pub/Sub に接続 | Pub/Sub が Webhook エンドポイントに HTTPS リクエスト |
| Ack管理 | 明示的な acknowledge() 呼び出しが必要 | HTTP 200 OK レスポンスが自動的に Ack となる |
4. ベストプラクティス：フロー制御とリースの管理
サブスクライバーが処理能力を超えたメッセージを受け取ると、システムが過負荷になります。これを防ぐのが フロー制御（Flow Control） です。
- 最大未処理メッセージ数：メモリ溢れを防ぐため、クライアントライブラリ側で同時に処理するメッセージ数を制限します。
- べき等性の設計：Exactly-once を有効にしていても、分散システムの原則として、アプリケーション側は常に「同じメッセージを2回受け取っても問題ない」ように設計（べき等な処理）することが推奨されます。
- デッドレター トピック（Dead Letter Topics）：何度リトライしても処理できない「毒メッセージ」を隔離するために設定します。
Pub/Sub 高度な配信制御とサブスクライバーの最適化のまとめ
Pub/Sub では、アプリケーション要件に応じて配信制御を適切に設計することが重要です。Exactly-once delivery を利用することで、メッセージの重複を最小限に抑え、分散システムの処理をより安全に実行できます。また、Ordering Keys を活用すれば、特定のキー単位でメッセージの順序を保証することが可能です。
さらに、ワークロードの特性に応じて Pull サブスクリプションと Push サブスクリプションを使い分けることが、効率的なシステム設計につながります。フロー制御やデッドレタートピックを活用し、過負荷や処理不能メッセージに備えた堅牢な設計を行うことが、Professional Cloud Developer に求められる重要なポイントです。
まとめ
今回は、下記３点について説明しました。
- API Gateway の認証とサービスアカウント管理の鉄則
- Cloud Service Mesh の基本とゲートウェイの実装
- Pub/Sub 高度な配信制御とサブスクライバーの最適化
今回の記事では、Professional Cloud Developer として押さえておくべき、Google Cloud の重要なアーキテクチャ要素を整理しました。
API Gateway は、バックエンドサービスを外部から直接公開せず、共通の認証・認可基盤を提供する重要なコンポーネントです。特にサービスアカウントの鍵管理はシステムのセキュリティを大きく左右するため、鍵を極力作らない設計、最小権限の原則、定期的なローテーションを徹底することが重要です。
また、Cloud Service Mesh を利用することで、アプリケーションのロジックと通信・セキュリティを分離する設計が可能になります。特に マネージドコントロールプレーンと Gateway API の組み合わせは、Google Cloud におけるモダンなマイクロサービス開発の基本パターンとして理解しておくべきポイントです。
さらに、Pub/Sub を利用したイベント駆動アーキテクチャでは、Exactly-once 配信や Ordering Keys を適切に使い分けることで、複雑な同期処理をアプリケーションから切り離すことができます。
Professional Cloud Developer 試験では、これらのサービスを単体で理解するだけでなく、「いつ・なぜ・どのように組み合わせるか」を問われます。
今回解説した設計思想を整理しておくことが、合格だけでなく実務におけるクラウドネイティブ開発の理解にもつながるでしょう。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
