Google PCA: コンピュート、アプリケーションプラットフォーム、ワークロードアーキテクチャ — 学習ガイド

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

概要

このドメインでは、Google Cloud 上でコンピューティングプラットフォームを選択・設計する方法、アプリケーションをパッケージ化・デプロイする方法、そして信頼性、パフォーマンス、セキュリティ、コスト効率を考慮してワークロードを運用する方法について説明します。仮想マシン、Kubernetes、サーバーレスランタイム、ロードバランシング、ロールアウト戦略、ステートフルおよび特殊なコンピューティング、そして変化する需要に対応しながら技術的負債を削減するモダナイゼーションパターンなど、幅広いトピックを扱います。

Compute Engine と VM ベースのアーキテクチャ

Compute Engine は、オペレーティングシステム、ネットワーキング、マシンシェイプに対する詳細な制御を提供します。ワークロードの特性に基づいてマシンファミリーを選択します:

E2: コスト最適化された汎用。開発/テスト、バースト的なアプリに適しています。
N2/N2D: ほとんどの本番ワークロードに対応する、価格とパフォーマンスのバランスが取れたタイプ。N2D は、強力なメモリ帯域幅を持つ AMD CPU を使用します。
C2/C2D/C3: CPU バウンドなタスク（例: 高 QPS の API、バッチコンピューティング）向けにコンピューティングが最適化されたタイプ。
M3: 大規模なインメモリデータセット（キャッシュ、インメモリ分析）向けにメモリが最適化されたタイプ。
A3: トレーニング/推論向けに GPU（NVIDIA）が最適化されたタイプ。他のファミリーにも GPU をアタッチできます。
Confidential VM（サポートされている CPU 上）は、最小限のコード変更で使用中のデータを暗号化します。

マネージドインスタンスグループ（MIG）は、弾力性と回復性をもたらします:

不変の構成にはインスタンステンプレートを使用し、ゾーンをまたいで水平にスケールさせるには MIG を使用します。
自動スケーリングポリシー: CPU、ロードバランサ使用率、Cloud Monitoring メトリクス、またはカスタムメトリクスによるキューの深さ。バースト的な負荷下でのスラッシングを避けるため、最小/最大レプリカ数とクールダウン期間を設定します。
ローリングアップデートとカナリアリリースはリスクを低減します。ステートフルなサービスやコールドスタートが重いサービスでは、surge と unavailable の設定を控えめに保ちます。

ロードバランシングとヘルスチェック:

グローバル外部 HTTP(S) ロードバランサは、TLS を終端し、URL マッピングをサポートし、Web API の標準的なフロントエンドです。内部 HTTP(S) LB は east-west トラフィック用です。
ヘルスチェックはバックエンドに到達できなければなりません。一般的な障害は、プローブがブロックされ、インスタンスの永続的な再起動とトラフィックのドロップを引き起こすことです。VPC ファイアウォールルールとターゲットタグを使用して、ヘルスチェックのソース範囲からバックエンドポートへのアクセスを許可します。

MIG への HTTP ヘルスチェックを許可する例:

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

VM のライフサイクルに関する考慮事項:

起動スクリプトまたはイメージのメタデータを使用してブートストラップします。ランタイム構成はイメージに焼き込まず、Secret Manager に保存します。
プリエンプティブル/Spot VM の場合、終了通知時に作業をドレインするためのシャットダウンスクリプトを追加します。
構成のドリフトを避けるため、イメージを焼き直してローリングリプレースメントによってパッチを適用します。
永続ディスクのリサイズはオンラインで実行できます。ディスクサイズを増やした後、最小限のダウンタイムでファイルシステムを拡張します（例: ext4 上の resize2fs）。

PD リサイズの例:

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

セキュアなアイデンティティとオブザーバビリティ:

最小権限のサービスアカウントをインスタンスにアタッチします。静的な認証情報を埋め込まないでください。
Cloud Logging と Cloud Monitoring のために Ops エージェントをインストールします。Cloud Trace と Cloud Profiler を使用して、テールレイテンシとホットスポットを削減します。
監査データとメトリクスデータを BigQuery または Cloud Storage にエクスポートして、長期的な保持と分析を行います。

バッチと特殊なコンピューティング:

コストを削減するため、フォールトトレラントなバッチ処理には Cloud Batch またはプリエンプティブル VM を使用した MIG を利用します。チェックポイントを実装してください。
ML アクセラレーションが必要な場合は GPU/TPU をアタッチします。コンプライアンス/分離要件を満たすために、専用のノードプールまたはソウルテナントノードを使用します。
Confidential VM はメモリ内の機密データを保護します。要件に対してオーバーヘッドを測定してください。

状態に関する考慮事項:

アプリケーションインスタンスはステートレスに保ちます。スケーリング時にユーザーに見える異常を避けるため、セッションは共有ストア（例: Memorystore, Cloud SQL）に外部化します。
VM にバインドされた状態については、リージョン永続ディスクまたはレプリケートされたデータベースを使用します。フェイルオーバーパスをテストしてください。

Kubernetes とコンテナプラットフォーム (GKE)

GKE は、マネージドコントロールプレーンと柔軟なワーカーノードプールを提供します:

リージョンクラスタは、高可用性のためにコントロールプレーンとノードを複数のゾーンに複製します。一方、ゾーンクラスタは、低コストとレイテンシ要件のためにリソースを単一ゾーンに集中させます。
複数のノードプールを使用してワークロードをセグメント化します (例: 汎用、GPU、高メモリ、spot)。taint/toleration と affinity/anti-affinity を適用して、配置を制御し、ノイジーネイバー効果を低減します。
オートスケーリングのレイヤー: クラスタオートスケーラーはノードを追加/削除します。Horizontal Pod Autoscaler (HPA) は CPU/カスタムメトリクスに基づいてレプリカをスケールします。Vertical Pod Autoscaler (VPA) は request を適正なサイズにします。HPA とクラスタオートスケーラーを組み合わせて、弾力性を確保します。

ワークロードのスケジューリングとサービス:

CPU/メモリの request/limit を適正なサイズに設定し、eviction のリスクを最小限に抑え、ビンパッキング効率を最大化します。
PodDisruptionBudget を使用して、アップグレード中の可用性を維持します。
Service のタイプ: ClusterIP (クラスタ内)、NodePort/LoadBalancer (ノースサウス)、およびグローバル LB を使用した HTTP(S) ルーティングのための Ingress。カナリアリリースでは、個別の Service/Ingress バックエンドまたはサービスメッシュを介してトラフィックを誘導します。

アップグレードと回復性:

surge upgrade と maxUnavailable を使用してチャーンを制御します。クリティカルなワークロードは、複数のゾーンとプールに固定します。
ビジネスクリティカルな期間には、メンテナンスウィンドウ/除外を設定します。
広範囲なロールアウトの前に、本番前環境とカナリアノードプールで検証します。

イメージとセキュリティ:

コンテナイメージは Artifact Registry に保存します。脆弱性スキャンを有効にし、来歴（provenance）のために Binary Authorization または attestations を設定します。
Workload Identity を使用して GSA を KSA にマッピングし、Google API への認証情報なしの最小権限アクセスを実現します。
CSI ドライバを介して Secret Manager からランタイム構成を取得します。機密性の高い値については、CMEK で暗号化され、RBAC が厳格でない限り、Kubernetes Secret の使用を避けます。

ロールアウトとロールバック:

小さなステップとヘルスプローブを備えた Deployment のローリングアップデートが推奨されます。低許容度のシステムでは、単一の Service の背後にある 2 つの Deployment を使用し、ラベル/セレクタを切り替えるブルーグリーン方式を使用します。
readiness プローブと liveness プローブを常に定義します。プローブの設定を誤ると、ロールアウト中に連鎖的な再起動やブラックホールが発生します。

サーバーレスとイベント駆動プラットフォーム

Google Cloud のサーバーレスは、インフラストラクチャを抽象化しつつ、スケール、セキュリティ、コストに対する強力な制御を提供します:

Cloud Run: コンテナネイティブで、HTTP リクエストまたは Eventarc によってトリガーされます。スケールトゥゼロに対応し、同時実行数は設定可能で、リビジョンごとのトラフィック分割によりカナリアリリースとロールバックが可能です。レイテンシに敏感なエンドポイントでは、最小インスタンスを設定してコールドスタートを削減します。プライベートな下り（egress）通信には、Serverless VPC Access を介して VPC と統合します。
App Engine: 独自の思想を持つ PaaS。Standard は、言語ごとに迅速なスケーリングとリクエストごとの同時実行数制約を提供します。Flexible は、より多くの制御が可能な VM 上でコンテナを実行します。インスタンスローカルのセッション状態は避け、共有ストレージに外部化して、負荷時に古いまたは重複したユーザーエクスペリエンスを防ぎます。
Cloud Functions: イベント駆動ロジックのための関数レベルの粒度。軽量なマイクロオペレーションには、Pub/Sub、Cloud Storage、または Eventarc トリガーを使用します。関数はべき等かつステートレスに保ちます。既存のコードがないバッチ/ストリームの複合パイプラインには、Dataflow がオートスケーリング付きの統合処理を提供します。

プラットフォーム選択のトレードオフ:

運用管理の自由度: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions。
可搬性: コンテナベース (GKE/Cloud Run/App Engine Flex) > VM イメージ > 関数および App Engine Standard。
レイテンシ: 低いテールレイテンシには、最小インスタンスを設定した Cloud Run または GKE を使用します。インタラクティブなワークロードではコールドスタートを避けます。
スケーリング: Cloud Functions/Run が最も速くスケールします。次に GKE の HPA とクラスタオートスケーラー。MIG はウォームアップとヘルスチェックが必要です。
コスト: スパイクがある/定常状態が低いワークロードにはサーバーレスの従量課金。安定的で高スループットのサービスには確約利用割引を適用した GKE/VM。バッチ処理にはプリエンプティブル/Spot。

ID と構成:

各サービスは、最小権限を持つ専用のサービスアカウントを使用すべきです。Cloud Run と Functions では、ランタイムサービスアカウントを明示的に設定します。
シークレットは Secret Manager に保存し、IAM を介してアクセスをバインドします。環境変数またはボリュームマウントを介して注入します。

アーキテクチャパターン、デリバリー、および運用

サービスの分割と境界:

モノリス: 最もシンプルなデプロイとトランザクションですが、独立したスケーリングや影響範囲（ブラスト半径）の制御を制限します。コールチェーンの奥深くにあるパフォーマンス問題を隠蔽する可能性があります。
モジュラーモノリス: 明確な内部モジュール、共有プロセス。分散によるペナルティなしにインターフェースを強制する、優れた中間ステップです。
マイクロサービス: 独立したデプロイとスケーリングが可能です。ネットワークレイテンシー、分散トランザクション、一貫性の課題を伴います。明確な境界づけられたコンテキストとデータの所有権を定義し、結合を防ぐために共有データベースを避けます。

モダナイゼーションパターン:

ストラングラー（絞め殺し）パターン: トラフィックの一部を段階的に新しいコンポーネントにルーティングし、レガシーなエンドポイントを徐々に廃止します。
リフト＆シフト: まずコンテナ化またはVM移行で安定させてから、リファクタリングします。
腐敗防止層/ファサード: 新しいサービスを構築する間、レガシーな契約を隔離します。
ビジネス価値を最大化し、リスクを低減するために、変更頻度が高く、摩擦の大きいドメインを最初に優先します。

デリバリーとロールアウト:

自動テストとステージング環境を備えたCI/CDは、ロールバックを削減します。カナリア分析、エラーバジェット、プログレッシブデリバリーを追加します。
ブルーグリーン: 2倍のキャパシティを犠牲にすることで、ダウンタイムを最小限に抑え、ロールバックを簡素化します。
トラフィックスプリッティング: Cloud Run/App Engineは、リビジョン/バージョン間でのパーセンテージベースのルーティングをサポートします。厳しいSLOエラーバジェットのもと、実際のトラフィックでテストします。

ロードバランシングとヘルスチェック:

HTTPにはグローバルL7を、非HTTPプロトコルにはTCPプロキシを使用します。プライベートサービスには内部LBを使用します。セッションアフィニティは必要な場合にのみ設定し、セッション状態は外部化します。
ヘルスチェックはアプリの可用性（例：依存関係の健全性）を反映すべきです。データストアの障害を隠蔽する単純な200 OKは、不適切なトラフィックステアリングを引き起こす可能性があります。

可観測性（オブザーバビリティ）とガバナンス:

サービス間のエンドツーエンドのレイテンシー特定のためにトレースを計装します。ログとトレースを関連付けるためにリクエストIDのロギングを有効にします。
保持および監査のニーズのために、ログ/メトリクス/監査証跡をBigQueryまたはCloud Storageにエクスポートします。ビューとIAMを介してアクセスを保護します。
VMログにはOps Agentをインストールします。コストとコンプライアンスを管理するために、保持期間とシンクを定義します。

セキュアなソフトウェアサプライチェーン: