Google PCA: 信頼性、ディザスタリカバリ、事業継続性 — 学習ガイド

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

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

概要

信頼性、障害復旧 (DR)、事業継続性は、コンポーネント、ゾーン、またはリージョンで障害が発生した場合でも、サービスが合意された目標を達成し続けることを保証します。Google Cloud では、障害ドメイン (ゾーン、リージョン、グローバル) の理解、復旧目標 (RTO/RPO) の定義、回復力のあるサービスアーキテクチャ (例: アクティブ/アクティブ) の選択、および復旧計画の厳密なテストによって信頼性が設計されます。設計では、サービスの重要度を、可用性、一貫性、コスト、および運用上の複雑さのバランスを取りながら、明確な可用性ターゲット、耐久性の保証、および検証済みの復旧パスにマッピングする必要があります。主要なテーマには、単一障害点の分離、可能な限りマネージドレプリケーションの使用、フェイルオーバー決定の自動化、および本番環境に近い条件で前提条件が有効であることの継続的な検証が含まれます。

障害ドメイン、ロケーション、マルチリージョンサービス

アベイラビリティゾーンとリージョン:
- ゾーンは、リージョン内の独立した障害ドメインです。ゾーン障害は、設計対象となる最も一般的な大規模イベントです。
- リージョンは、低レイテンシのリンクで接続されたゾーンの集合です。リージョン障害はまれですが、重要度の高いシステムでは考慮する必要があります。
- 設計パターン:
  - リージョン内: リージョンマネージドインスタンスグループ (MIG) を介して、少なくとも 2 つのゾーンにステートレスコンピューティングを配置します。
  - リージョン間: リージョンの損失を許容できない重要なサービスのために、状態を複製し、トラフィックをフェイルオーバーさせます。
マルチリージョンおよびグローバルサービス:
- グローバルコントロールプレーン: VPC ネットワーク、Cloud DNS、グローバル外部 HTTP(S) ロードバランシング、および Cloud IAM は、リージョン間の結合を減らすために使用されるグローバルスコープのサービスです。
- データプレーンの配置が重要:
  - Cloud Storage: アクセスパターンと DR のニーズに合わせて、リージョン、デュアルリージョン、またはマルチリージョンのバケットを選択します。
  - BigQuery: データセットはリージョンまたはマルチリージョンに存在します。マルチリージョンは分析面の可用性を向上させますが、外部結合のためのデータ所在地と下り (egress) を考慮してください。
  - Spanner: インスタンス構成 (リージョンまたはマルチリージョン) が、レプリカのトポロジと一貫性の動作を定義します。
障害ドメイン分析:
- すべてのコンポーネントをその影響範囲 (blast radius) にマッピングします。例:
  - ゾーン: 単一の VM、ゾーン GKE ノードプール、ゾーン SSD PD。
  - リージョン: Cloud SQL HA のプライマリ+スタンバイはリージョン単位です。一部のメンテナンスイベントはリージョンに影響を与える可能性があります。
  - グローバル: IAM または Cloud DNS の設定ミスは、すべてのリージョンに影響します。
- 共有依存関係 (例: 1 つの NAT ゲートウェイ、1 つの Memorystore インスタンス) や、人為的なリスク (共有サービスアカウント、単一の Terraform state) などの相関障害を特定します。
- 割り当て (quota) を障害ドメインとして考慮します。リージョンの割り当て上限に達したオートスケーラーは、機能的に停止しています。

トレードオフ:

クロスゾーンレプリケーションはダウンタイムを削減しますが、ゾーン間のトラフィックとコストが増加します。
クロスリージョン設計は RTO を短縮しますが、レイテンシ、複雑さ、および費用が増加します。
グローバルエニーキャストロードバランシングはフェイルオーバーを簡素化しますが、ヘルスチェックが正確である場合にのみ、異常なバックエンドをマスクします。

目標、依存関係のマッピング、DR 検証

RTO と RPO:
- 目標復旧時間 (RTO): サービスを復旧するまでの目標時間。自動化の深度、スタンバイの態勢、ランブックの詳細度を決定します。
- 目標復旧時点 (RPO): 許容可能なデータ損失期間。レプリケーションの選択とバックアップの頻度を決定します。
サービスの重要度と階層化:
- ターゲット SLO、RTO/RPO、およびテスト頻度とともに階層 (例: Tier 0: 安全性/財務への影響、Tier 1: 収益、Tier 2: 内部ツール) を定義します。
- 費用と複雑さを階層に結び付けます。すべてのサービスがクロスリージョンを必要とするわけではありません。
依存関係のマッピング:
- アップストリームとダウンストリームの依存関係を棚卸しします: ID (Cloud IAM, SAML IdP)、シークレット (Secret Manager, KMS)、ネットワーキング (DNS, Cloud Interconnect/VPN)、ストレージと DB、オブザーバビリティ、CI/CD、およびサードパーティ API。
- 各依存関係のリージョン、ゾーン、SLA を文書化し、脆弱なリンクに対する補完的な制御を定義します。
復旧計画:
- フェイルオーバー/フェイルバック、データリストア、および構成の昇格 (DNS、ロードバランサのバックエンド、ファイアウォール) のためのランブックと自動化を作成します。
- 権限とサービスアカウントを事前にプロビジョニングし、インフラストラクチャ定義をステージングして手動のゲートを排除します。
- 監査可能な権限昇格を伴う緊急アクセス (break-glass access) を維持します。
復旧テスト:
- ステートフルなシステム (例: Cloud SQL HA) の定期的なフェイルオーバーをスケジュールし、昇格と接続の再ネゴシエーションを検証します。
- ゾーンまたはリージョンの停止をシミュレートするゲームデイを実施します。アップストリームプロバイダーや IAM/KMS の障害も含めます。
- 障害注入を使用して、サーキットブレーカー、タイムアウト、リトライを検証します。オートスケーリングとバックプレッシャーが意図したとおりに機能することを確認します。
- テスト中に RTO/RPO を継続的に測定し、目標が達成されない場合はアーキテクチャを調整します。

回復性を備えたコンピューティング、データベース、ストレージのパターン

リージョンMIGとロードバランシングによる自己修復コンピューティング：
- リージョンMIGを使用して、オートスケーリングと自動修復を備えたインスタンスを複数のゾーンに分散させる。
- グローバル外部HTTP(S)ロードバランサーをフロントエンドに配置し、バックエンドサービスのヘルスチェックを真の準備状態（例：/healthzが依存関係をチェックする）に合わせる。
- 継続的なVMの再起動を避けるため、ファイアウォールでヘルスチェックを許可する：

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - ローカルな状態を避け、セッションをMemorystoreやデータベースに外部化する。スケールイン中に進行中のリクエストを維持するため、バックエンドでコネクションドレイニングを使用する。
  - 一般的な障害モード：不適切なヘルスチェック（チェック項目が多すぎる、または少なすぎる）、ファイアウォールルールの欠落、不健全なダウンストリームに依存するブートストラップ。
- Cloud SQLの回復性：
  - 高可用性：プライマリとスタンバイを別々のゾーンに配置し、同期ディスクレプリケーションと自動フェイルオーバーを実現する。メンテナンスウィンドウを選択し、フェイルオーバーをテストする。
  - リードレプリカ：同一リージョンまたはクロスリージョンのリードレプリカを追加して読み取りをオフロードし、リージョンイベントに対するRTOを削減する。DR時にレプリカを昇格させる。
  - バックアップとPITR：
    - 自動日次バックアップとポイントインタイムリカバリ（PITR）を有効にする。コンプライアンスとRPOのために十分な保持期間を持つバイナリ/トランザクションログを使用する。
    - 本番環境以外でリストアを検証し、昇格手順とアプリケーションの接続文字列の更新をリハーサルする。
  - ネットワーク：本番環境ではプライベートIPを推奨する。フェイルオーバーテストでDNS/コネクションプーリングの動作を検証する。
  - 運用上のヒント：定期的に制御されたフェイルオーバーを実行し、アプリケーションプールがクリーンに再接続することを確認する。

gcloud sql instances failover prod-sql
```

Spannerの構成と回復性：
- リージョンインスタンスは、ゾーン間でPaxosを使用し、リージョン内で低レイテンシかつ強整合性のある読み取り/書き込みを提供する。
- マルチリージョンインスタンスは、同期クォーラム書き込み（グローバルな強整合性）とオプションの読み取り専用レプリカを用いてリージョン間でレプリケートする。書き込み元に近いリーダーリージョンを選択する。
- トレードオフ：マルチリージョンはRTO/RPOと読み取り可用性を向上させるが、書き込みレイテンシとコストが増加する。強整合性が必要なグローバル分散型で書き込み負荷の高いワークロードに使用する。それ以外の場合は、リージョンSpannerまたはレプリカ付きのCloud SQLを検討する。
Cloud Storageの耐久性とリカバリパターン：
- ロケーション戦略：コンピューティングの局所性にはリージョン、2つのリージョンにまたがるアクティブ/アクティブにはデュアルリージョン、グローバルユーザーへの広範な可用性にはマルチリージョン。
- バージョニング：オブジェクトのバージョニングを有効にして、削除や破損から回復する。ライフサイクルルールと組み合わせてコストを管理する。
- リテンション：バケットレベルのリテンションポリシーを適用し、必要に応じてコンプライアンスのためにリテンションロックを適用する。記録管理にはイベントベースのホールドを使用する。
- バックアップパターン：プロジェクトをまたぎ、管理者を分離したバケットは、偶発的な削除や権限昇格を軽減する。データベースの場合、論理バックアップを別のプロジェクトのCloud Storageにエクスポートする。
- 90日より古いバージョンを削除するライフサイクルルールの例：

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    適用コマンド：

gsutil lifecycle set lifecycle.json gs://prod-backups
```

リカバリ：重要なオブジェクトのカタログを維持し、リストアをテストする。大規模なデータセットの場合、名前の衝突を避けて整合性を検証するために、一時的なバケットにリストアをステージングする。

トラフィック管理、マルチサイト戦略、および継続的なレジリエンス

マルチサイト戦略:
- アクティブ/アクティブ: 複数のリージョンから同時にトラフィックを処理。対称的なデータレプリケーションと競合のない書き込みが必要。最高のRTO/RPOを達成できるが、コストと複雑性が最も高い。
- アクティブ/パッシブ: ホットなプライマリと準備完了のセカンダリ構成。データは継続的にレプリケートされ、障害発生時にトラフィックが切り替えられる。コストとRTOのバランスが良い。
- ウォームスタンバイ: 事前に同期されたデータを保持する、スケールダウンされたセカンダリ構成。フェイルオーバー時にスケールアップが必要。中程度のRTOとコスト。
- パイロットライト: 最小限の重要なデータレプリケーションとインフラ定義のみを保持。ほとんどのコンポーネントはフェイルオーバー時にプロビジョニングされる。RTOは長いが、定常コストは低い。
- コールドスタンバイ: 定期的なバックアップのみ。障害発生時に復元する。RTOは最も長く、コストは最も低い。
DNSとトラフィック管理のフェイルオーバー:
- グローバル外部HTTP(S)ロードバランサーを使用したレイヤー7でのヘルスベースのルーティングを推奨します。これにより、バックエンドごとのヘルスチェックが実行され、DNSの変更なしに、異常なゾーンやリージョンからトラフィックを自動的に迂回させます。
- 低TTLのDNSレコードは、大まかなフェイルオーバー制御や、互いに素なロードバランサーVIP間の切り替えにのみ使用してください。DNSキャッシュのため、フェイルオーバーは瞬時に行われないことを理解しておく必要があります。
- プライベートサービスには、内部HTTP(S)ロードバランシングをリージョンフェイルオーバーパターンと組み合わせて使用し、必要に応じてプログラムで更新できるプライベートDNSを利用します。
グレースフルデグラデーションのパターン:
- 機能フラグを実装して、高負荷時に重要でない機能を無効化します。
- サーキットブレーカー、タイムアウト、ジッター付きリトライ、バルクヘッドを使用して、障害を局所化します。
- 書き込みパスに障害が発生した場合は、読み取り専用モードを提供します。書き込みはキューに入れ、後で調整します。
- クライアントをレートリミットし、バックプレッシャーを適用して、連鎖的な障害を防ぎます。
カオス試験と継続的改善:
- ネットワーク（レイテンシ、パケットロス）およびアプリケーションレイヤーでの障害注入により、レジリエンス制御が設計どおりにトリガーされることを検証します。
- ゲームデーは、チーム横断での復旧作業を実践する場です。ページング、ランブックの実行、具体的な是正措置を伴うポストモーテム（事後検証）を含みます。
- エラーバジェットとSLOを追跡し、データに基づいてキャパシティ、リトライ戦略、レプリケーション構成を調整します。
可用性、一貫性、コスト、複雑性のトレードオフ:
- 可用性 vs. 一貫性: 強力なグローバル一貫性（例: Spannerマルチリージョン）は書き込みレイテンシを増加させる可能性があります。結果整合性（例: 非同期レプリカ）はレイテンシを改善するかもしれませんが、古いデータを読み取るリスクがあります。
- コスト vs. RTO/RPO: デュアルリージョンストレージやマルチリージョンデータベースはコストを増加させますが、データ損失とダウンタイムを最小限に抑えます。
- 複雑性 vs. 信頼性: すべてのフェイルオーバーメカニズム、レプリケーションストリーム、ルーティングルールは、運用およびテストが必要です。目標を達成するために必要な限り、設計をシンプルに保ちます。

実践的な問題シナリオ

急成長中のオンラインチケット会社であるAcme Ticketsは、購入APIとイベントカタログについて、リージョン障害時にも継続的な運用を保証する必要があります。その際、厳しいRTO/RPO（RTO ≤ 5分、RPO ≤ 1分）を維持しなければなりません。スタックには、ステートレスなマイクロサービス、リレーショナルな注文データベース、分析パイプライン、静的メディアアセットが含まれています。

サービスティア、SLO、および復旧目標を定義する

理由: 購入APIと注文DBをティア0（RTO 5分、RPO 1分）、カタログをティア1（RTO 15分、RPO 5分）、分析をティア2（ベストエフォート）に分類します。これにより、コストと複雑性をビジネスインパクトに合わせます。

リージョン配置とマルチサイト戦略を選択する

理由: ステートレスサービスにはus-central1とus-east1にまたがるアクティブ/アクティブ構成を展開してRTOを最小化し、注文データベースにはアクティブ/パッシブ構成を使用して書き込みレイテンシとコストのバランスを取ります。

リージョンMIGとグローバルHTTP(S)ロードバランシングを実装する

理由: 2つのリージョンMIG（各リージョンに1つ）を、それぞれ少なくとも2つのゾーンに分散させます。単一のグローバルエニーキャストVIPが、ヘルスチェックされたバックエンドサービスを介してトラフィックをルーティングし、異常なリージョンを自動的に切り離します。

状態を外部化し、自己修復を構成する

理由: セッションはMemorystoreに保存し、カタログ用にクロスリージョンのリードレプリカを構成します。サービスはステートレスに保ち、MIGの自動修復とローリングアップデートを安全に実行できるようにします。ヘルスチェックは、重要なダウンストリームを検証する/healthzに向けます。

HA構成とクロスリージョンリードレプリカを持つCloud SQL for PostgreSQLをプロビジョニングする

理由: プライマリリージョンでHAを使用してゾーンのレジリエンスを確保し、十分な保持期間でPITRを有効にします。セカンダリリージョンにクロスリージョンリードレプリカを作成し、テスト済みのランブックを用意してリージョン障害時に昇格させ、最小限の書き込み損失でRPO ≤ 1分を満たします。

定期的なデータベースフェイルオーバーテストをスケジュールする

理由: 月次で制御されたフェイルオーバーを実行し、アプリケーションの再接続動作とレプリカの昇格を検証します。これは、実際のインシデント中にレプリカが昇格されないという一般的な障害モードに対処します。

静的メディアを、バージョニングとリテンションが設定されたデュアルリージョンのCloud Storageバケットに配置する

理由: デュアルリージョンは2つのリージョンにまたがるオブジェクトの可用性を保証します。バージョニングは偶発的な上書き/削除から保護します。ライフサイクルルールを適用して古いバージョンを期限切れにし、コストを管理します。

ファイアウォールとクォータでヘルスチェックとエグレスを保護する

理由: ロードバランサーのヘルスチェック用に明示的なファイアウォールルールを作成し、リージョンのインスタンスクォータを監視して、フェイルオーバー中のオートスケーラーの停止を防ぎます。

低TTLのDNSを大まかな制御として実装する

理由: グローバルロードバランサーがヘルスベースのルーティングを処理する一方で、緊急時の手動切り替え用にスタンバイVIPへの低TTLのAレコードを維持します。ただし、DNSキャッシュの制限は理解しておきます。

DRランブックを自動化し、ゲームデーを通じて検証する

理由: Cloud Schedulerを使用して合成トラフィックをトリガーし、Cloud MonitoringのSLOを使用して、四半期ごとのゲームデーでの動作を確認します。その際、障害（例: リージョン間トラフィックのブロック、ノードの終了）を注入します。RTO/RPOメトリクスを収集し、手順を改善します。

バックアップを保護し、分離する

理由: 注文DBの日次論理バックアップを、リテンションロックが設定された別のプロジェクトのCloud Storageバケットにエクスポートします。定期的にステージングインスタンスにリストアして、整合性と所要時間を検証します。

グレースフルデグラデーションを実装する

理由: 注文DBが劣化した場合は、カタログを読み取り専用に切り替え、書き込みを後で調整するためにキューに入れ、重要でない機能を停止させます。これにより、連鎖的な障害を防ぎ、部分的なサービスを維持します。

このアーキテクチャは、ステートレスサービスに対する自動化されたリージョンフェイルオーバー、ステートフルコンポーネントに対する制御されテストされたフェイルオーバー、そしてAcme Ticketsの事業継続目標を満たす検証済みの復旧プロセスを提供します。

← セキュリティ、コンプライアンス、データ保護アーキテクチャ · すべてのドメイン · 移行、モダナイゼーション、ハイブリッドクラウド戦略 →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

試験に合格する →

Googleを閲覧 →