Google PCD: クラウドネイティブアプリケーションアーキテクチャとサービス選択 — 学習ガイド

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

こちらの一部です： Google Professional Cloud Developer — 学習ガイド. 検証済みの解答で練習： Google試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Google Cloudにおけるクラウドネイティブなアプリケーションアーキテクチャは、水平にスケールするステートレスで回復性のあるサービスを構築し、運用上の手間を最小限に抑え、適切な場合にはマネージドサービスを積極的に採用することに重点を置いています。効果的なサービスの選択には、コントロール、ポータビリティ、パフォーマンス、コスト、運用責任の間のトレードオフを理解する必要があります。このセクションでは、グローバルなユーザーのために、予測可能な信頼性を持つアプリケーションを設計、モダナイズ、運用するのに役立つ原則とパターンを提示します。

クラウドネイティブの原則とアーキテクチャの選択

Twelve-Factor Appとステートレス設計
- コードベース、依存関係、ビルド・リリース・実行: 正確な依存関係を固定し、イミュータブルなアーティファクトを作成し、ビルドとリリースを分離します。コンテナイメージとCloud Buildパイプラインは、再現可能なリリースを強制します。
- 環境内の設定: 環境変数、Secret Manager、Kubernetes Secrets、またはCompute Engineのインスタンスメタデータを使用して、設定を外部化します。認証情報やデプロイごとの設定をイメージに含めないでください。Compute Engineのマネージドインスタンスグループでは、デプロイごとの値にインスタンステンプレートのメタデータを使用します。
- バックアップサービス: データベース、キュー、キャッシュをアタッチされたリソースとして扱います。運用負荷を軽減するために、マネージドサービス（Cloud SQL、Cloud Spanner、Firestore、Memorystore、Pub/Sub）を優先します。
- ステートレスなプロセス: インスタンスを追加してスケールし、セッション状態は外部（Memorystore for Redis、Firestore、またはSpanner）に保存します。ログは標準出力/標準エラー出力、またはCloud Loggingエージェントによって収集されるログファイルに書き込みます。
- 廃棄容易性: 高速な起動/シャットダウンにより、迅速なスケーリングとローリングアップデートが可能になります。SIGTERMを処理して、グレースフルシャットダウンを行います。
- イベントストリームとしてのログ: 構造化ログを出力し、取り込みにはCloud Loggingを、アラートにはCloud Monitoringを使用します。
アーキテクチャのトレードオフ
- モノリス
  - 長所: 開発/テストの簡素化、ネットワーク境界の削減、単一のデプロイメントユニット。
  - 短所: 独立したデリバリーの遅延、スケールの制約、ドメイン間の密結合。
  - 障害モード: 1つのホットパスが共有リソースを消費する可能性。リグレッションがすべての機能に影響を与える。
- モジュラーモノリス
  - 長所: 明確な内部モジュール境界、サービスへのリファクタリングパス、単一のデプロイ可能ファイル。
  - 短所: モノリシックなデプロイメントとデータベースによる制約が依然として残る。
  - サービスを抽出する前にドメイン境界を成熟させているチーム向け。
- マイクロサービス
  - 長所: 独立したデプロイ能力、対象を絞ったスケーリング、チームの自律性、適切なバルクヘッドによる障害分離。
  - 短所: 分散システムの複雑さ、一貫性、可観測性、および運用オーバーヘッド。
  - 障害モード: 同期呼び出しによる連鎖的な障害、スキーマのドリフト、過剰なネットワーク通信。
- イベント駆動
  - 長所: 疎結合、非同期による回復力、自然なバッファリング、ログ/ストリームによる監査可能性。
  - 短所: デバッグの複雑さ、結果整合性、順序性とexactly-onceセマンティクスの実現が困難。
  - Pub/Subはat-least-once配信を提供します。冪等なコンシューマを設計する必要があります。
- サーバーレス（Cloud Run、Cloud Functions、App Engine）
  - 長所: 最小限の運用、スケールトゥゼロ、リクエストごとのオートスケーリング、統合されたセキュリティとテレメトリ。
  - 短所: 実行時間と同時実行数の制限、コールドスタート、プラットフォーム固有の制約。
  - 突発的なワークロード、モバイル/Webバックエンド、イベント処理に使用します。

通信パターンとサービスの選択

同期呼び出しと非同期呼び出し
- 同期
  - 即時の結果を必要とするリクエスト/レスポンスAPIに使用します。
  - プロトコル: gRPC（HTTP/2、ストリーミング、コンパクトなProtobuf。モバイルの帯域幅と強力なコントラクトに最適）、HTTP/JSON（幅広い互換性、よりシンプルなデバッグ）。
  - リスク: 密結合とレイテンシの増幅。タイムアウト、ジッター付きリトライ、サーキットブレーカーを使用します。
- 非同期
  - 作業を遅延またはバッチ処理できる場合は、Pub/SubまたはCloud Tasksを使用します。
  - 利点: スパイクを平滑化し、障害を分離し、最終的な完了によってユーザーが体感するレイテンシを改善します。
  - リスク: 冪等性と補償アクションが必要です。実行中の作業の可視性を構築する必要があります。
Google Cloudでのサービス選択基準
- コントロールとポータビリティ
  - Compute Engine: 完全なVMコントロールとカスタムイメージ。運用負荷は高くなります。
  - GKE: ポータブルなコンテナとサービスメッシュのオプション。堅牢なオートスケーリング。共同責任モデル。
  - Cloud Run: 最小限の運用でコンテナの高いポータビリティを実現。スケールトゥゼロ。リクエスト指向。
  - App Engine: 組み込みのルーティングとスケーリングを備えた、オピニオンatedなPaaS。特定の言語で最速のパス。
- スケールとレイテンシ
  - エッジアクセラレーションのためのCloud CDNを備えたグローバルHTTP(S)ロードバランシング。
  - データストア:
    - Cloud Spanner: グローバルな一貫性、水平スケール、マルチリージョンでの99.999%の可用性。
    - Cloud SQL: マネージドリレーショナルDB、リージョン内、クロスリージョンを含むリードレプリカ。
    - Firestore: マルチリージョンでグローバルな可用性を備えたドキュメントDB、単一ドキュメントに対する強力な一貫性。
    - Cloud Bigtable: ワイドカラムのユースケース向けの低レイテンシ、大規模スケール。
    - Memorystore: ホットパスとセッションのための低レイテンシキャッシュ。
- 運用責任
  - コアな懸念事項（可用性、パッチ適用、バックアップ、アップグレード）については、マネージドサービスを優先します。
  - セルフマネージドは柔軟性を提供しますが、手間と障害発生箇所を増やします（例: 自己ホストのKafka vs Pub/Sub）。
- データ移動と統合
  - 低レイテンシでプライベートなアクセスのために、VPCネイティブ接続、Private Service Connect、および内部HTTP(S)ロードバランシングを使用します。
  - サービスディスカバリ: クラスタ内のKubernetes Service名。VM用のCompute Engine内部DNS。

Kubernetes Serviceの例（クラスタ内での名前解決）: apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

port: 80 targetPort: 8080 type: ClusterIP

境界、互換性、信頼性パターン

ドメインの境界と所有権
- ドメイン駆動設計を使用して、境界づけられたコンテキストを定義します。各サービスは自身のデータを所有し、契約としてAPIやイベントを公開します。
- サービス間でのデータベース共有は避け、明確に定義されたインターフェースとイベント伝播を使用します。
- 所有権には、サービスごとのオンコール、SLO、リリース頻度、予算に対する責任が含まれます。
API契約と後方互換性
- APIは明示的にバージョン管理します（例：パスやヘッダーにv1を含める）。破壊的なフィールドや振る舞いの変更は避け、追加的な変更を優先します。
- コンシューマー駆動契約テストとカナリアリリースを使用します。利用状況に関するテレメトリを収集し、タイムラインを設けて非推奨化します。
- モバイルクライアントでは、ロングテールのバージョンが残ることを想定し、複数のAPIバージョンを同時に維持します。
障害分離と回復性
- Bulkheads（隔壁）: サービスや優先度クラスごとにリソースを分離します（個別のノードプール、インスタンスグループ、クォータ）。ベストエフォート型の機能がクリティカルパスを枯渇させるのを防ぎます。
- Circuit breakers（サーキットブレーカー）: 依存先への連続した障害発生後に作動（トリップ）し、負荷を切り離して回復のための時間を与えます。サービスメッシュ（例：Envoy）、ゲートウェイのポリシー、またはライブラリを介して実装します。
- Timeouts and retries（タイムアウトとリトライ）: ジッター付きのトランケイテッドエクスポネンシャルバックオフを使用し、ハンドラーのべき等性を確保します。
- Graceful degradation（正常な機能低下）: タイムアウト時に重要でないUIコンポーネントを省略したり、エラーを返す代わりにキャッシュされたデータや近似データを提供したりします。
- Health checks and readiness probes（ヘルスチェックとReadinessプローブ）: 準備ができたインスタンスにのみトラフィックをルーティングし、自己修復のためにLivenessプローブを使用します。

トランケイテッドエクスポネンシャルバックオフの例（HTTP 429）:

undefined

グローバルおよび運用上の考慮事項

グローバルユーザー向けのマルチリージョンパターン
- グローバルフロントエンド: グローバル外部 HTTP(S) ロードバランシングとエニーキャスト IP を使用し、静的コンテンツには Cloud CDN を利用します。ネガティブキャッシュと検証を設定して、オリジンの負荷を軽減します。
- データプレーン:
  - ファイブナイン (99.999%) のデータベース可用性とグローバルな読み取りレイテンシの最小化のために、マルチリージョンの Cloud Spanner インスタンス（例: nam-asia-eur1）を使用し、コンピューティングとクォーラム（本番環境では最低 3 ノード）に十分なノードをプロビジョニングします。
  - 厳格なグローバル整合性を必要としない読み取りヘビーなパターンでは、リージョナルプライマリとクロスリージョン読み取りレプリカを検討します。大陸間の書き込みレイテンシが高くなることを許容します。
- アプリケーションプレーン:
  - オートスケーリング（GKE または Cloud Run）を使用して、複数のリージョンにステートレスサービスをデプロイします。リージョンごとにバックエンドサービスとネットワークエンドポイントグループを使用します。
  - データレジデンシーとコンプライアンスの制約を遵守しつつ、レイテンシに基づいてルーティングします。
- キャッシュ: Memorystore またはエッジキャッシュをユーザーの近くに配置して、読み取りトラフィックを吸収し、オリジンを保護します。
マネージド vs セルフマネージド
- メトリクスには Cloud Monitoring、ログには Cloud Logging、レイテンシと CPU/メモリのホットスポットには Cloud Trace/Profiler を使用します。SLO バーンレートのアラートポリシーと、外部可用性のための稼働時間チェックを作成します。
- 既存のオブザーバビリティプラットフォームを正系のシステムとして維持する必要がある場合は、まず Cloud Logging で取り込んで低レイテンシのアラートを実現し、その後シンクを介して外部プラットフォームにエクスポートします。
モダナイゼーションと段階的移行
- ストラングラーパターン: モノリスの前にゲートウェイを配置し、特定のエンドポイントを新しいサービスにルーティングします。徐々に機能を置き換えていきます。
- 抽象化による分岐: 依存関係の周りにインターフェースを導入し、その背後で実装を交換します（例: データベースやストレージ）。
- 腐敗防止層: レガシーなデータモデルと新しい境界づけられたコンテキストとの間で変換を行います。
- データ移行: 検証付きのデュアルライトまたはイベントソーシングを使用してバックフィルします。バックプレッシャー制御を用いてカットオーバーを計画します。
- 段階的デリバリー: ビジネスリスクを最小限に抑えるために、機能を段階的に置き換えます。SLO を継続的に測定します。
設計レビューとトレードオフ評価
- セキュリティ: 脅威モデリング、IAM の最小権限、埋め込みキーの代わりにサービスアカウントを使用（GCE/GKE/Cloud Run では Application Default Credentials を使用）、必要な箇所での CMEK、プライベート接続、WAF とレート制限、脆弱性およびウェブセキュリティスキャン。
- 信頼性: SLO とエラーバジェットの定義、マルチリージョンフェイルオーバー計画、容量のヘッドルーム、カオス訓練、依存関係マップ。
- パフォーマンス: テールレイテンシ分析、エッジとオリジンでの負荷テスト、コネクションの再利用（HTTP/2, gRPC）、圧縮、キャッシング戦略。
- コスト: リソースのライトサイジング、オートスケーリングポリシー、確約利用割引、バースト的なワークロードのためのスケールトゥゼロ、下り（egress）と CDN オフロード。
- 運用: ランブック、ロールバック、プログレッシブデリバリー（カナリア、ブルー/グリーン）、Policy as Code、バックアップと DR テスト、インシデントレスポンスの統合。

実践的な問題シナリオ

Nimbus Retail は、パーソナライズされた画像、全世界で p95 で 200 ミリ秒未満という厳しいレイテンシ目標、そして注文データベースに 99.999% の可用性要件を持つグローバル e コマースプラットフォームを立ち上げようとしています。また、アラート速度を向上させつつ、既存の SIEM を維持する必要があります。

Cloud Spanner を使用してグローバルで高可用なデータベースを確立する

アクション: nam-asia-eur1 に最低 3 ノードのマルチリージョン Spanner インスタンスを作成し、局所性のためにテーブルを適切なインターリーブスキーマに分割します。
根拠: マルチリージョンの Spanner は、3 大陸のレプリカを介してファイブナインの可用性と低い読み取りレイテンシを提供します。3 つ以上のノードにより、十分なコンピューティング能力とレプリカのクォーラム容量が確保されます。

Example: gcloud spanner instances create nimbus-orders
–config=nam-asia-eur1 –description=“Global orders” –nodes=3

フロントエンドと API のグローバルデプロイメント

アクション: グローバル外部 HTTP(S) ロードバランシングを使用し、静的アセットには Cloud CDN を、リージョナルバックエンド（us-central1, europe-west1, asia-east1 の GKE サービス）への動的ルーティングにはこれを利用します。
根拠: エニーキャスト VIP が RTT を最小化し、CDN がユーザーの近くに画像をキャッシュします。バックエンドサービスは、最も近い正常なリージョンにリクエストを分散します。

GKE 上のステートレスサービスとクラスタ内検出

アクション: 水平ポッドオートスケーリングと、クラスタ内での名前ベースアクセスのための ClusterIP Service を使用して、画像リサイズおよび API サービスを GKE にデプロイします。Ingress を介してパブリックエンドポイントを公開します。
根拠: ステートレスなポッドは弾力的なスケーリングを可能にします。Kubernetes Service はポッドの IP を抽象化し、安定した DNS を提供することで、クライアントの結合度を低減します。

イベント駆動の画像処理

アクション: 画像処理タスクを Pub/Sub にパブリッシュします。プッシュサブスクリプションを介して、Cloud Storage に保存されたオブジェクトを処理する Cloud Run サービスを実行します。GCS の 429/5xx エラーに対して、ジッター付き打ち切り指数バックオフを実装します。
根拠: Pub/Sub はスパイクをバッファリングし、障害を分離します。Cloud Run はメッセージごとにスケールします。バックオフはエラーの増幅を減らし、バケットが徐々にウォームアップするのを助けます。

オブザーバビリティと迅速なアラート

アクション: Cloud Logging と Cloud Monitoring を使用してログとメトリクスを取り込み、API の稼働時間チェックを定義し、エラーレートとレイテンシに関するアラートポリシーを作成します。既存の SIEM にエクスポートするためのログシンクを設定します。
根拠: ネイティブのテレメトリは低レイテンシのアラートとマネージドの稼働時間チェックを提供します。エクスポートにより、アラート速度を犠牲にすることなく、一元化された SIEM を維持できます。

外部化された設定とシークレット

アクション: シークレットでない設定は ConfigMaps に保存します。シークレットと API キーは Secret Manager に保存し、GKE には Workload Identity を使用します。Compute Engine ベースのジョブについては、デプロイごとの値にインスタンスメタデータを使用します。
根拠: 外部化された設定は、イミュータブルなイメージと環境固有の設定を可能にします。シークレットの埋め込みを回避します。メタデータは、コード変更なしで VM の差異をサポートします。

障害分離とグレースフルデグラデーション

アクション: ベストエフォートのパーソナライゼーションワークロード用に、個別のノードプールでバルクヘッドを適用します。パーソナライゼーションサービスにはリクエストバジェットとサーキットブレーカーを強制します。UI では、依存関係のタイムアウト時に重要でないウィジェットを省略します。
根拠: 容量を分離することで、ベストエフォート機能がチェックアウトプロセスを枯渇させるのを防ぎます。サーキットブレーカーは障害の影響範囲（blast radius）を限定します。グレースフルデグラデーションはコアとなるユーザージャーニーを維持します。

API 契約と互換性

アクション: モバイルクライアント（v1）向けに gRPC 契約を定義し、ウェブ向けには HTTP/JSON トランスコーディングを使用します。追加的な変更を採用し、モバイルのロールアウト中は少なくとも 2 つのバージョンを維持します。
根拠: gRPC は帯域幅を削減し、強力な型付けを提供します。トランスコーディングはブラウザやパートナーとの統合を容易にします。バージョニングは下位互換性を維持します。

セキュリティとアイデンティティ

アクション: サービスごとに最小権限の IAM を持つ Google サービスアカウントを使用し、Application Default Credentials に依存します。エッジ保護のために Cloud Armor を有効にし、すべての通信で TLS を強制します。
根拠: Workload Identity はキー管理のリスクを排除します。WAF とレート制限は不正利用を緩和します。転送中の暗号化はデフォルトであり、必須です。

継続的デリバリーとリリースの安全性

アクション: ロードバランサーでのパーセンテージベースのトラフィックスプリットによるカナリアリリースと、SLO バーンアラートに基づく自動ロールバックを実装します。リージョンごとにブルー/グリーン環境を維持します。
根拠: プログレッシブデリバリーはリスクを限定します。リージョナルなブルー/グリーンはロールバックを高速化し、バージョン管理された API と連携した安全なスキーマ移行を可能にします。

すべてのドメイン · コンピューティング、コンテナ、サーバーレスランタイムプラットフォーム →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →