Google Cloud Professional Cloud Architect
最終確認：2026年5月
PCA 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
グローバルなアプリケーションにおいて、世界中のユーザーに対して低レイテンシと高可用性が必要です。
マルチリージョンのバックエンド (MIG/GKE) を備えたグローバル HTTP(S) ロードバランサ、静的コンテンツ用の Cloud CDN、および DDoS 保護用の Cloud Armor を使用します。
理由: グローバルロードバランサは、ユーザーを最寄りの正常なバックエンドにルーティングする単一のAnycast IPを提供します。CDNはエッジでコンテンツをキャッシュし、オリジンへの負荷とレイテンシを軽減します。
IoTデバイスから高スループットのリアルタイムデータを取り込み、即時分析のために処理します。
スケーラブルなメッセージ取り込みに Pub/Sub を、リアルタイム処理と異常検出に Dataflow ストリーミングパイプラインを、分析結果の書き込みに BigQuery を使用します。
理由: これはリアルタイムデータの典型的なサーバーレスパターンです。Pub/Sub は取り込みを分離し、Dataflow は自動スケーリングで複雑な処理を扱い、BigQuery はリアルタイム分析のためのストリーミング挿入をサポートします。
ゲームのバックエンドは、サブミリ秒の読み取りレイテンシと高スループットでプレイヤーの状態とリーダーボードを保存する必要があります。
ゲームの状態とリーダーボードには Cloud Bigtable を、セッションキャッシュには Memorystore (Redis) を使用します。
理由: Bigtable は高スループットの読み取り/書き込みに対して1桁ミリ秒のレイテンシを提供し、時系列データや大規模な分析データセットに理想的です。Memorystore はセッション状態に対してマイクロ秒のレイテンシを提供します。
グローバルに分散されたアプリケーションには、強力なトランザクションの一貫性と水平スケーラビリティを備えたデータベースが必要です。
マルチリージョン構成で Cloud Spanner を使用します。
理由: Spanner は、SQL セマンティクスと水平スケーラビリティを備えた、グローバルで強力な一貫性のあるトランザクションを提供する唯一のサービスです。Cloud SQL は、この規模では手動でのシャーディングが必要です。
高可用性、パフォーマンス、および最小限のリファクタリングを必要とする、要求の厳しいオンプレミス Oracle または PostgreSQL データベースを移行します。
AlloyDB for PostgreSQL を使用します。
理由: AlloyDB は、優れたパフォーマンス、99.99% の可用性、および Oracle 互換機能を備えたフルマネージドの PostgreSQL 互換データベースであり、エンタープライズ移行に理想的です。
一貫した低レイテンシ (<10ms) と高帯域幅 (10+ Gbps) の要件で、オンプレミスデータセンターを GCP に接続します。
冗長接続を備えた Dedicated Interconnect を使用します。
理由: Dedicated Interconnect は、プライベートで高帯域幅、低レイテンシの物理接続を提供します。Cloud VPN はパブリックインターネット経由で動作するため、このレベルのレイテンシや帯域幅の SLA を保証することはできません。
一元的なネットワーク管理と分散されたプロジェクト所有権を必要とする複数のチーム/プロジェクト向けにネットワークを設計します。
Shared VPC を使用してハブアンドスポークモデルを実装します。中央のネットワークチームがホストプロジェクトを管理し、アプリケーションチームがサービスプロジェクトを使用します。
理由: Shared VPC は、ネットワークリソース（サブネット、ファイアウォール）の一元管理を可能にしつつ、サービスプロジェクトでのリソース管理を委譲します。これは VPC ピアリングよりもスケーラブルで安全です。
Google Cloud、AWS、Azure、およびオンプレミス環境全体で Kubernetes クラスターを一貫して管理します。
Anthos を使用して、マルチクラウドおよびハイブリッドクラスター管理、ポリシー適用、および可観測性のための統合コントロールプレーンを提供します。
理由: Anthos は GKE を他の環境に拡張し、フリート全体で一貫した運用と GitOps ベースの構成管理 (Config Management) を可能にします。
データサイエンスチームは、インフラストラクチャを管理せずに GPU アクセラレーションを使用して複雑な ML モデルをトレーニングする必要があります。
カスタムコンテナを使用する Vertex AI Training と、モデルのイテレーションを追跡するための Vertex AI Experiments を使用します。
理由: Vertex AI は、インフラストラクチャのプロビジョニング、スケーリング、GPU 管理を処理するフルマネージドのトレーニングサービスを提供します。モデルのパフォーマンスを追跡および比較するための実験と統合されています。
自動スケーリング可能で、低レイテンシと高可用性で大規模な ML モデルを提供します。
カスタムコンテナを使用する Vertex AI Prediction を、自動スケーリングが有効なマネージドエンドポイントにデプロイします。
理由: Vertex AI Prediction は、低レイテンシのモデル提供に最適化されています。自動スケーリング、トラフィックスプリット（A/B テスト用）、インフラストラクチャ管理を処理し、開発者からの複雑さを抽象化します。
Cloud Function または Cloud Run サービスが、プライベート IP を持つ Cloud SQL インスタンスに安全に接続する必要があります。
サーバーレス環境を VPC に接続するために、Serverless VPC Access Connector を構成します。
理由: このコネクタは VPC 内にトンネルを作成し、サーバーレスサービスが内部リソースにプライベート IP アドレスでアクセスできるようにします。これにより、リソースがインターネットに公開されることを防ぎます。
ローカルセッションストレージを使用するステートフルアプリケーションを、Cloud Run や GKE のようなステートレスで自動スケーリングするプラットフォームに移行します。
セッション状態を Memorystore (Redis) のようなマネージドなインメモリストアに外部化します。
理由: ステートレスなコンピューティングでは、どのインスタンスでもどのユーザーリクエストも処理できるように、セッションデータを外部に保存する必要があります。Memorystore は、このための共有された低レイテンシソリューションを提供します。
承認を伴う複数の環境（ステージング、本番）間でリリースを昇格させるためのマネージド継続的デリバリーパイプラインを作成します。
Cloud Deploy を使用して、組み込みの承認ゲートを備えたターゲット環境（GKE、Cloud Run）へのデプロイをオーケストレーションするデリバリーパイプラインを定義します。
理由: Cloud Deploy は CD のためのフルマネージドサービスであり、Spinnaker のようなツールをセルフホストする運用オーバーヘッドなしに、リリース管理、監査性、および自動ロールバック機能を提供します。
運用および管理のオーバーヘッドを最小限に抑え、本番環境対応の Kubernetes クラスターにコンテナ化されたアプリケーションをデプロイします。
GKE Autopilot クラスターを使用します。
理由: Autopilot は、プロビジョニング、スケーリング、セキュリティ強化を含むクラスターのコントロールプレーンとノードを管理します。リクエストした Pod リソースに対してのみ料金が発生するため、運用とコスト管理の両方が簡素化されます。
大規模なモノリシックアプリケーションを、最小限のリスクとダウンタイムで、マイクロサービスアーキテクチャに段階的に移行します。
ストランギュラーパターンを適用します。モノリスの前にプロキシを配置し、特定の機能のトラフィックを、構築および検証された新しいマイクロサービスに徐々にリダイレクトします。
理由: このパターンは、段階的で制御された移行を可能にすることで、リスクの高い「ビッグバン」な書き換えを回避します。新しいサービスがモノリスの機能を徐々に引き継ぐにつれて、モノリスはゆっくりと「絞め殺されます」。
多数のオンプレミス VM を、最小限のダウンタイムで Google Cloud に移行します。
Migrate to Virtual Machines（旧称 Migrate for Compute Engine）を使用して、オンプレミスから GCP への継続的なブロックレベルレプリケーションを実行し、その後迅速な切り替えを行います。
理由: このツールは、リフトアンドシフト移行向けに設計されており、最終的な切り替えまでソースとターゲットの VM を同期させることで、ダウンタイムを数分に最小限に抑えます。
あるチームが SRE の原則を採用しており、初期の SLO を確立する必要があります。
まずユーザー中心のサービスレベル指標 (SLI) を定義します（例: 可用性、レイテンシ）。過去のパフォーマンスデータを分析して、現実的な初期のサービスレベル目標 (SLO) を設定します。
理由: SLO はユーザーエクスペリエンス（SLI）に基づいており、達成可能である必要があります。過去のデータに基づいて設定することで、初期のエラーバジェットが現実的であり、すぐに侵害されないことが保証されます。
標準化された構成（API、IAM、ネットワーク、セキュリティ）で新しい GCP プロジェクトの作成を自動化します。
Cloud Build によってトリガーされる Terraform モジュールを使用した「プロジェクトファクトリ」パターンを使用します。セルフサービスインターフェースを提供するために Service Catalog を使用します。
理由: これにより、すべての新しいプロジェクトが組織の標準とセキュリティベースラインに準拠し、手動作業と構成のドリフトを削減します。これにより、大規模なガバナンスが可能になります。
Terraform で管理されているインフラストラクチャに対する手動変更（構成ドリフト）を防ぎます。
すべての適用に CI/CD パイプライン（例: Cloud Build）を、Terraform 状態ロック（GCS バックエンド経由）を、コンソールアクションを制限するための組織ポリシーを、そして定期的なドリフト検出を使用します。
理由: 多層的なアプローチが必要です。パイプラインは変更のための単一のパスを強制し、ロックは同時適用を防ぎ、組織ポリシーは予防的なガードレールを提供します。
共有モジュールを使用しつつ、異なる構成を持つ複数の環境（開発、ステージング、本番）向けにインフラストラクチャコード（Terraform）を管理します。
再利用可能な Terraform モジュールの単一セットを使用し、環境固有の構成を別個の `.tfvars` ファイルまたはワークスペースを通じて提供します。
理由: これは Don't Repeat Yourself (DRY) の原則に従います。モジュールは一貫性を確保し、変数ファイルは各環境をカスタマイズするための柔軟性を提供します。
Git リポジトリから Kubernetes マニフェストを GKE クラスターに自動的にデプロイするための GitOps ワークフローを実装します。
Anthos Config Management（またはスタンドアロンの Config Sync）を使用して、クラスターの状態を Git リポジトリの構成と継続的に調整します。
理由: Config Sync は、構成ドリフトを検出し修正するフルマネージドの GitOps ソリューションを提供し、Git リポジトリがクラスターの状態に対する唯一の信頼できる情報源であることを保証します。
ゼロダウンタイムと即時ロールバック機能を備えた Web アプリケーションのブルー/グリーンデプロイメントを実装します。
HTTP(S) ロードバランサの背後に2つの同一のマネージドインスタンスグループ（または GKE デプロイメント）を使用します。ロードバランサのバックエンドサービスでトラフィックをリダイレクトすることにより切り替えを実行します。
理由: ロードバランサレベルでのトラフィックスプリットは瞬時であり、トラフィックを元のバックエンドに切り替えるだけで簡単にロールバックできます。これは、より遅い DNS ベースの方法よりも優れています。
アプリケーションの API キーやデータベースパスワードなどのシークレットへのアクセスを安全に保存、管理、および監査します。
アクセス制御のために IAM を備えた Secret Manager を、GKE/Cloud Run からのキーレス認証のために Workload Identity を使用します。
理由: Secret Manager は、バージョン管理、ローテーションポリシー、および監査ロギングを備えた集中管理型サービスです。Workload Identity を使用すると、サービスアカウントキーの管理と配布が不要になります。
BigQuery や Cloud Storage などのサービス内の機密データが、許可されていないプロジェクトや場所にアクセスまたはコピーされるのを防ぎます。
VPC Service Controls を使用して、機密性の高いプロジェクトの周囲にサービス境界を作成し、データフローを制限します。
理由: VPC Service Controls は、Google マネージドサービスのためのファイアウォールとして機能し、API レベルでのデータ漏洩を防ぎます。これは、IAM とネットワークファイアウォールを超えた、重要な多層防御レイヤーです。
Google Cloud サービスに保存されているデータを、暗号化キーを完全に制御した状態で暗号化します。
Cloud KMS に保存および管理されているキーとともに、カスタマーマネージド暗号化キー (CMEK) を使用します。
理由: CMEK を使用すると、Cloud KMS を介して独自のキーを使用して他の GCP サービス内のデータを保護できます。キーのローテーションを制御し、キーを無効にすることでアクセスを取り消すことができ、暗号消去を提供します。
HIPAA に準拠して保護された医療情報 (PHI) を扱うためのアーキテクチャを設計します。
暗号化制御には CMEK を、データ漏洩防止には VPC Service Controls を、コンプライアンス境界には Assured Workloads を、監査には Cloud Audit Logs と Access Transparency を使用します。
理由: HIPAA は技術的な制御の組み合わせを要求します。CMEK はキー制御を提供し、VPC-SC はデータ漏洩を防ぎ、広範なロギング（監査ログ、アクセス透過性）は必要な監査性を提供します。
GKE Pod が、パスワードやサービスアカウントキーを管理せずに、Cloud SQL データベースに安全に接続する必要があります。
Workload Identity を使用して、Kubernetes サービスアカウントを Google サービスアカウントにバインドします。Cloud SQL Auth Proxy サイドカーと IAM データベース認証を使用して接続します。
理由: この「パスワードレス」パターンは最も安全です。Workload Identity はキーレス認証を提供し、Auth Proxy はトラフィックを暗号化し、IAM DB 認証は静的クレデンシャルの代わりに IAM をデータベースアクセスに使用します。
すべてのクラウド リソースを特定の地理的リージョン（例: EU）でのみ作成する必要があるポリシーを適用します。
組織またはフォルダレベルで組織ポリシーの制約（`gcp.resourceLocations`）を設定し、許可されるリージョンを指定します。
理由: これは、API レベルでコンプライアンス違反のリソース作成をブロックする予防的制御です。組織全体でデータ所在地ポリシーを強制する権威ある方法です。
信頼され、スキャンされ、承認されたコンテナイメージのみが本番 GKE クラスターにデプロイされるようにします。
脆弱性スキャンには Artifact Registry を、有効なアテステーション（署名）を必要とするデプロイポリシーを適用するには Binary Authorization を使用します。
理由: これにより、安全なソフトウェアサプライチェーンが作成されます。Artifact Registry は脆弱性をスキャンし、Binary Authorization はポリシー適用ポイントとして機能し、イメージが必要なすべてのチェックに合格したことを暗号的に検証します。
従来の VPN を使用せずに、リモート従業員向けに内部 Web アプリケーションへの安全でコンテキストアウェアなアクセスを提供します。
Identity-Aware Proxy (IAP)、ポリシー用の Access Context Manager、およびデバイスの姿勢用の Endpoint Verification を備えた BeyondCorp Enterprise を使用します。
理由: これは、アクセスがネットワークロケーションではなく、ユーザーIDとデバイスの信頼に基づいて付与されるゼロトラストモデルを実装します。IAP はすべてのリクエストに対して認証プロキシとして機能します。
規制されたワークロードでは、暗号化キーを FIPS 140-2 Level 3 認定のハードウェアセキュリティモジュール (HSM) 内に保存および処理する必要があります。
キーの保護レベルとして `HSM` を指定した Cloud KMS を使用します。
理由: Cloud HSM は、FIPS 140-2 Level 3 認定 HSM を提供するフルマネージドサービスです。この保護レベルで生成されたキーは、HSM 境界を平文で離れることはありません。
Cloud Storage または BigQuery 内の機密データ（PII など）を自動的に検出し、非識別化します。
Cloud Data Loss Prevention (DLP) を使用して、機密データをスキャンし、マスキング、トークン化、または匿名化などの非識別化技術を適用します。
理由: DLP は、幅広い機密データ型に対応する事前構築済みおよびカスタムの検出器を提供し、カスタムスクリプトなしで自動化されたスケーラブルなデータ保護を可能にします。
複数の ID プロバイダ（例: Okta、Azure AD）からの従業員が、Google アカウントを作成せずに Google Cloud リソースにアクセスできるようにします。
Workforce Identity Federation を使用して、外部 ID プロバイダを Google Cloud IAM に接続します。
理由: これにより、既存の ID システムを信頼できる情報源として活用でき、ユーザーの同期や従業員のための個別の Google ID の管理が不要になります。
使用中（メモリ内）であってもデータが暗号化されたままである必要がある、極めて機密性の高いデータを処理します。
機密 VM を使用します。
理由: Confidential Computing は、専用のハードウェア機能 (AMD SEV) を使用して、処理中にデータを暗号化します。これにより、メモリスクレイピング攻撃から保護され、機密性の高いワークロードに追加のセキュリティレイヤーが提供されます。
大規模なデータウェアハウス向けに BigQuery のコストとパフォーマンスを最適化します。
日付によるパーティショニングと、頻繁にフィルタリングされる列に対するクラスタリングを実装します。ダッシュボードには BI Engine を、一般的でコストのかかる集計にはマテリアライズドビューを使用します。
理由: パーティショニングとクラスタリングは、クエリごとにスキャンされるデータ量を減らすための基本であり、直接コストを削減し速度を向上させます。BI Engine と MVs は冗長な計算を削減します。
可能な限り低いコンピューティングコストで、大規模でフォールトトレラントなバッチ処理ジョブを実行します。
マネージドインスタンスグループで Spot VM を使用します。アプリケーションがフォールトトレラントであり、プリエンプションを処理できることを確認します。
理由: Spot VM は、オンデマンドインスタンスと比較して最大91%の節約を提供します。これらは、多くのバッチ処理タスクのように、停止および再起動できるステートレスでフォールトトレラントなワークロードに最適です。
異なるチームや部門にコストの可視性と説明責任を提供するために FinOps のプラクティスを実装します。
リソース階層（チームごとのフォルダ）を使用し、コスト配分にラベルを適用し、詳細な請求データを BigQuery にエクスポートして Looker Studio で分析および可視化します。
理由: この組み合わせは、リソースを整理するための構造化された方法、ラベルを介してコストをきめ細かく追跡する方法、およびショーバック/チャージバック用のカスタムのチーム固有のダッシュボードを構築する方法を提供します。
変動する負荷を持つアプリケーション向けに GKE クラスターのコストとパフォーマンスを最適化します。
メトリクスに基づいて Pod をスケーリングするために Horizontal Pod Autoscaler (HPA) を、必要に応じてノードを追加/削除するために Cluster Autoscaler を使用します。
理由: この2段階の自動スケーリングアプローチにより、アプリケーション（Pod）とインフラストラクチャ（ノード）の両方が需要と同期してスケーリングされ、過剰なプロビジョニングを防ぎ、パフォーマンスを確保します。
ML トレーニングジョブで GPU 使用率が低い（30%未満）場合、ボトルネックを示しています。
データ入力パイプラインを診断し、最適化します。プリフェッチと並列読み取りを備えた `tf.data`、または I/O パフォーマンスを向上させるために Cloud Storage FUSE を使用します。
理由: GPU 使用率が低いのは、ほとんどの場合データ I/O ボトルネックです。GPU は次のデータバッチを待っている間アイドル状態になります。データロードの最適化は、トレーニング効率を向上させるための最初のステップです。
インターネットへのデータ提供やリージョン間でのネットワーク下り（エグレス）コストが高いのを削減します。
静的コンテンツのキャッシュに Cloud CDN を使用します。リージョン間トラフィックの場合、レイテンシに敏感ではないワークロードには Standard Network Service Tier を使用します。
理由: CDN はエッジからデータを配信するため、オリジンからの下りよりも安価です。Standard Tier は Google のプレミアムネットワークではなくパブリックインターネット経由でトラフィックをルーティングするため、大量データ転送のコストを低く抑えられます。
営業時間中のみ必要な開発/テスト用 VM のコストを削減します。
Cloud Scheduler を使用して、事前に定義されたスケジュールでインスタンスを自動的に起動および停止する Cloud Functions をトリガーします。
理由: この「インスタンススケジューリング」パターンは、リソースが使用されていないときにシャットダウンするプロセスを自動化し、非本番環境のコストを大幅に削減します。
重要なアプリケーションでは、ゾーン障害が発生した場合に自動フェイルオーバーが可能なリレーショナルデータベースが必要です。
Cloud SQL インスタンスを高可用性（HA）オプションで構成します。
理由: HA 構成は、異なるゾーンに同期レプリケーションを備えたスタンバイインスタンスを作成します。プライマリインスタンスまたはゾーンの障害が発生した場合、フェイルオーバーは自動で行われ、通常60秒以内に完了します。
応答しない、または失敗した Compute Engine インスタンスを自動的に検出して回復します。
マネージドインスタンスグループ (MIG) 内にインスタンスをデプロイし、アプリケーションベースのヘルスチェックで自動修復を構成します。
理由: MIG の自動修復は、各インスタンス上のアプリケーションを積極的にプローブします。アプリケーションがヘルスチェックに失敗した場合、MIG はインスタンスを自動的に再作成し、サービスの信頼性を確保します。
RTO が1時間未満、RPO が15分未満の災害復旧計画を設計します。
セカンダリリージョンでウォームスタンバイを実装します。Cloud SQL のクロスリージョンレプリカ、マルチリージョン Cloud Storage、およびコンピュート用の事前構成済みインスタンステンプレートを使用します。
理由: このアプローチは、コストとリカバリ時間のバランスを取ります。データは RPO を満たすためにほぼ同期的にレプリケートされ、RTO を満たすための迅速なスケールアップを可能にするために最小限のインフラストラクチャが（ウォームで）稼働しています。
迅速なトラブルシューティングを可能にするため、マイクロサービスアプリケーションに包括的な可観測性を実装します。
相関ID付きの構造化ロギング、分散トレーシング用の Cloud Trace、メトリクス用の Cloud Monitoring、自動エラーグループ化用の Cloud Error Reporting を使用します。
理由: ログ、トレース、メトリクス（「可観測性の3つの柱」）の組み合わせが不可欠です。相関IDと分散トレーシングは、複数のサービスを横断する単一のリクエストを追跡するために重要です。
あるマイクロサービスでの障害が、アプリケーション全体にカスケード障害を引き起こすのを防ぎます。
各サービス間通信ポイントで、サーキットブレーカー、指数バックオフ付きリトライ、アグレッシブなタイムアウトなどの回復性パターンを実装します。
理由: これらのパターンは障害を隔離します。サーキットブレーカーは、障害のあるサービスへの呼び出しを停止し、呼び出し元サービスがリソースを使い果たして次々に障害が発生するのを防ぎます。
新しいデプロイによって引き起こされる本番環境の停止のリスクを軽減するために、SRE のベストプラクティスを実装します。
カナリアデプロイメントを使用して変更を段階的に展開し、フィーチャーフラグを使用してデプロイメントとリリースを分離し、SLO 監視に基づいた自動ロールバックトリガーを使用します。
理由: これらのプラクティスは、不適切なデプロイの「爆破半径」を制限します。カナリアは最初に少数のユーザーに新しいバージョンを公開し、自動ロールバックは平均復旧時間（MTTR）を最小限に抑えます。
SRE エラーバジェットを使用して、機能の速度と信頼性のバランスを取ります。
エラーバジェットポリシーを定義します。バジェットがほぼ消費されたら、新しい機能のデプロイを凍結し、信頼性を向上させる作業を優先します。
理由: エラーバジェットは、トレードオフの意思決定を行うためのデータ駆動型メカニズムです。バジェットが健全な場合はチームがリスクを取ることを許可し、そうでない場合は安定性に焦点を当てることを強制します。
Cloud Spanner を使用するグローバル分散アプリケーションで、特定のリージョンでの書き込みレイテンシが高くなります。
アプリケーションの書き込みパターンを分析し、Spanner インスタンスのリーダーリージョンがほとんどの書き込み操作の地理的に近くになるように構成します。
理由: Spanner では、すべての書き込みは一貫性を確保するためにリーダーリージョンを介してルーティングされます。リーダーリージョンを書き込みの主要ソースの近くに配置することで、それらのトランザクションのネットワークレイテンシを最小限に抑えます。
