Google ACE: 信頼性、バックアップ、災害復旧 — 学習ガイド

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

概要

Google Cloudにおける信頼性、バックアップ、ディザスタリカバリは、障害ドメイン、データ保護メカニズム、トラフィック管理、および運用の準備状況にわたる意図的な設計を必要とします。このセクションでは、ゾーンやリージョンをまたいでサービスを構成する方法、ステートフルなデータを保護および復元する方法、そして統制されたランブックと継続的な回復性テストによってリカバリ目標を検証する方法について説明します。また、定義された目標復旧時間 (RTO) と目標復旧時点 (RPO) の目標内でプラットフォームが回復できるようにするための、DR戦略のトレードオフとキャパシティプランニングの概要も説明します。

障害ドメインとリージョン設計

• ゾーン、リージョン、マルチリージョンサービス

  • ゾーンは独立した最小の障害ドメインです。単一のゾーン障害がリージョンサービスを中断させるべきではありません。
  • リージョンは、低レイテンシのリンクで接続された独立したゾーンをグループ化したものです。リージョン設計はゾーン障害には耐えられますが、必ずしも完全なリージョン規模のイベントに耐えられるわけではありません。
  • マルチリージョンサービスはリージョンをまたいで複製を行い、より高いコストと潜在的に高い書き込みレイテンシと引き換えに、リージョン全体の損失から保護します。
  • 設計原則: 考慮すべき最小の障害ドメインで単一障害点を回避します。RTO/RPOがゾーン障害からの復旧を要求する場合、少なくとも2つのゾーンにまたがってデプロイします。リージョンレベルの生存性のためには、複数のリージョンにアクティブなコンポーネントをデプロイするか、マルチリージョンサービスを利用します。

• マネージドインスタンスグループ (MIG) と自己修復

  • 1つのリージョン内の複数のゾーンにインスタンスを分散させるには、リージョンMIGを使用することを推奨します。これにより、個別のツールなしでゾーン障害の影響を緩和できます。
  • ロードバランサのヘルスチェックは、異常なVMをトラフィックから除外します。MIGの自動修復は、異常または無応答のVMを置き換えます。両方を使用してください。
  • 準備完了エンドポイントと依存関係を検証する、アプリケーションレベルのHTTP(S)ヘルスチェックを使用してください。TCPチェックはポートの到達可能性を検証するだけです。
  • 自動修復の誤設定による障害モード: ロードバランサのヘルスチェックのみを使用すると、問題のあるインスタンスへのトラフィックは停止しますが、インスタンスは再作成されません。インスタンスを置き換えるためにMIG自体のヘルスチェックを設定し、起動中の早すぎる再起動を避けるために初期遅延を設定してください。

例:

• 10秒間隔と3回の異常しきい値でアプリケーションのヘルスチェックを作成し、約30秒後に自己修復をトリガーします: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• 自動修復のために、リージョンMIGにヘルスチェックをアタッチします: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• マルチリージョンに関する考慮事項

  • Global external HTTP(S) Load Balancingは、ヘルスチェックに基づく自動フェイルオーバーを備えた、複数リージョンにまたがるバックエンドをサポートします。
  • リージョン間の状態同期は、重要なトレードオフです。アクティブ/アクティブ構成はスループットが高いですが、一貫性と競合解決を設計する必要があります。アクティブ/パッシブ構成はよりシンプルですが、フェイルオーバーが遅く、RPOが大きくなる可能性があります。

データ保護: データベース、ストレージ、コンピューティング

• Cloud SQL の高可用性とレプリカ
  • 高可用性構成では、スタンバイインスタンスを異なるゾーンに配置し、同期レプリケーションを行います。プライマリに障害が発生すると、自動フェイルオーバーが実行されます。RTO は通常数分です。RPO はリージョン内では ≈ 0 ですが、処理中のトランザクションを考慮する必要があります。
  • 読み取りレプリカは読み取り処理をオフロードし、DR のためにクロスリージョンに配置できます。これらは非同期であるため、レプリケーションラグとゼロではない RPO が予想されます。
  • バックアップと PITR
    • 自動バックアップとポイントインタイムリカバリ (PITR) を有効にします。MySQL の場合はバイナリロギングを有効にし、PostgreSQL の場合は PITR の保持期間を有効にします。
    • 復元フロー: データ破損やユーザーエラーの場合、特定のタイムスタンプで新しいインスタンスに復元し、アプリケーションやレプリカを復元されたインスタンスに向け、データを検証します。
  • 障害モードとトレードオフ
    • HA は論理的なデータ破損からは保護しませんが、バックアップと PITR は保護します。
    • クロスリージョンレプリカはリージョン全体の障害から保護しますが、ラグが発生する可能性があります。許容可能な RPO をテストしてください。

例:

• バイナリロギング (MySQL) と自動バックアップを有効にする: gcloud sql instances patch my-mysql
  –enable-bin-log
  –backup-start-time=03:00 –retained-backups=7

• Persistent disk (PD) のスナップショットとマシンイメージ

  • PD スナップショットは、ディスクの増分的なクラッシュコンシステントなバックアップです。ストレージの場所を設定可能で、スナップショットのロケーションスコープ内の任意のゾーンで新しいディスクを作成するために使用できます。
  • アプリケーション整合性のあるバックアップを実現するには、ファイルシステムとアプリケーションを静止させるか、データベース固有のバックアップメカニズムとスナップショットを連携させます。
  • マシンイメージは、ディスクとインスタンスのメタデータ (ブートディスク、アタッチされたディスク、インスタンスのプロパティ) をキャプチャします。マシンイメージを使用して、フリートの迅速な復旧や、ゴールデンサーバー構成のクローンを作成します。
  • スナップショットスケジュールポリシーは、バックアップを自動化し、保持期間を強制します。重要なディスクにはそれに応じてタグを付けます。
  • 復元ワークフロー: スナップショットからディスクを作成し、新しいインスタンスにアタッチし、起動スクリプトとサービスアカウントを更新した後、トラフィックを再導入する前にアプリケーションの整合性を検証します。

例:

• スナップショットを作成し、新しいディスクに復元する: gcloud compute disks snapshot vm-boot –snapshot-names=boot-2024-09-01 gcloud compute disks create restored-boot –source-snapshot=boot-2024-09-01 –zone=us-central1-a

• Cloud Storage のレプリケーション、バージョニング、保持

  • ストレージクラスの選択肢: Standard はホットデータ用、Nearline は月 1 回程度の低頻度アクセス用、Coldline は四半期に 1 回程度のアクセス用 (バックアップや DR に推奨)、Archive は長期間ほとんどアクセスされないデータ用です。
  • Regional、Dual-Region、Multi-Region バケットは、レプリケーションによって耐久性を提供します。ターボレプリケーションを備えた Dual-Region は、新しく書き込まれたオブジェクトのレプリケーション RPO を短縮できます。Multi-Region は広範な地理的耐障害性を提供します。
  • オブジェクトのバージョニングは、古いバージョンを保持することで、偶発的な削除や上書きから保護します。保持ポリシーやバケットロックと組み合わせて、WORM (Write Once, Read Many) 保持を強制します。
  • 偶発的な削除からの保護: オブジェクトのバージョニングを有効にし、ロック付きの保持ポリシーを使用し、法的または処理上のゲートとしてイベントベースのホールドを実装し、IAM と均一なバケットレベルのアクセスを通じて削除を制限します。外部からの期限付きアクセスには、厳密な有効期限を持つ署名付き URL を使用します。

90 日後に Coldline に移動し、365 日後に削除するライフサイクルの例:

• lifecycle.json { “rule”: [ { “action”: { “type”: “SetStorageClass”, “storageClass”: “COLDLINE” }, “condition”: { “age”: 90 } }, { “action”: { “type”: “Delete” }, “condition”: { “age”: 365 } } ] }
• 適用: gsutil lifecycle set lifecycle.json gs://my-bucket

トラフィック、キャパシティ、依存関係の回復性

• DNS とトラフィック管理によるフェイルオーバー

  • インターネット向けサービスには、グローバル外部 HTTP(S) ロードバランシングを推奨します。これはエニーキャスト IP を使用し、ヘルスチェックに基づいてリージョン間でフェイルオーバーを実行します。
  • プライベートサービスには、内部 HTTP(S) または TCP/UDP ロードバランサを使用します。複数のバックエンドを用意し、ゾーン間の独立性を考慮して設計します。
  • DNS TTL のトレードオフ: TTL を低く設定するとフェイルオーバーは高速になりますが、クエリ負荷が増加し、一部のリゾルバではキャッシュ動作により無視される可能性があります。ヘルスチェックベースの LB フェイルオーバーは、DNS のみのフェイルオーバーよりも高速で確定的です。
  • 加重またはフェイルオーバー DNS ポリシーは、リージョン退避のための最終手段のコントロールプレーンとなり得ますが、キャッシュの有効期限に依存します。

• キャパシティプランニングと割り当ての設計

  • ゾーンおよびリージョンごとに、正常な状態を維持するための最小キャパシティを特定します。フェイルオーバーのためのヘッドルームバッファを適用します (「N+1 ゾーン」キャパシティ)。
  • 重要な Compute Engine シェイプには、リージョン予約を使用して、スケールイベントやフェイルオーバー中のキャパシティを保証します。
  • IP アドレス、転送ルール、Cloud NAT のキャパシティ、コネクショントラッキング、SSL 証明書を事前にプロビジョニングして、復旧中のコントロールプレーンの遅延を回避します。
  • 割り当ての増加は、必要になるかなり前にリクエストします。セカンダリリージョンや、すべての依存関係 (例: リージョンごとの Cloud SQL インスタンス数、VPC ごとの転送ルール数、Pub/Sub スループット、Cloud KMS QPS) の割り当てを検証します。
  • オートスケーリングに関する考慮事項: クールダウン期間を設定し、必要に応じて予測オートスケーリングを使用し、ポリシーによってインスタンスを 1 つだけ維持する必要がある場合は最小/最大境界を設定します。

• 依存関係の回復性

  • アップストリームおよびダウンストリームのサービスを棚卸しします。それぞれについて、障害時の動作とフォールバック (キャッシュされた構成、機能縮退モード、サーキットブレーカー、デッドレタートピック付きのキュー、バックプレッシャー) を定義します。
  • 復旧リージョンで IAM とサービスアカウントのスコープを検証します。DR イベント中にロールが不足していると、サイレント障害の原因となることがよくあります。
  • 暗号化キー: Cloud KMS キーのレプリカまたはマルチリージョンキーがデータの場所と一致していることを確認します。セカンダリリージョンでのキーリングの局所性と IAM を計画します。

レジリエンス運用と継続的改善

• RTO、RPO、復旧計画、ランブック

  • RTOはサービスをどれだけ迅速に再開しなければならないかを定義し、RPOは許容可能なデータ損失を定義します。これらはビジネス影響分析から導き出します。
  • 各システムコンポーネントを、RTO/RPOを満たす特定のメカニズムに対応付けます。ゾーン障害に対するHA、リージョン障害に対するクロスリージョンレプリケーション、破損に対するバックアップ、耐久性のためのストレージクラス/レプリケーションなどです。
  • ランブックを維持します。正確な手順、コマンド、認証情報へのアクセス、健全性検証チェック、デシジョンツリーを含みます。バージョン管理され、アクセス制御されたリポジトリに保存し、定期的にリハーサルを実施します。
  • 復旧検証：実際のRTO/RPOを測定し、データの整合性を検証し、改善アクションを収集するために訓練を計画します。小規模な復元（テーブル、ディスク）と完全なサイトリカバリの両方をテストします。

• DR戦略とトレードオフ

  • アクティブ/アクティブ：すべてのリージョンがトラフィックを処理します。データ同期が正しく設計されていれば、RTOは最小限、RPOは低くなります。複雑性とコストが高くなります。競合解決とグローバル負荷分散が必要です。
  • アクティブ/パッシブ：プライマリリージョンがアクティブで、セカンダリはウォーム状態でレプリケートされたデータを受信します。コストは中程度です。RTOは数分から数十分です。RPOはレプリケーションに依存し、ゼロではありません。
  • パイロットライト：セカンダリでは最小限の重要なサービス（データベースレプリケーション、最小限のアプリフットプリント）が実行されます。RTOは数時間です。コスト効率が高いです。フェイルオーバー中にコンピューティングをスケールアップするために慎重なオーケストレーションが必要です。
  • コールドスタンバイ：インフラストラクチャはコードとして定義されていますが、プロビジョニングはされていません。RTOは数日です。コストは最も低いです。ドリフト、クォータ、容量不足による予期せぬ事態のリスクがあります。

• カオス試験と障害シミュレーション

  • インスタンスのクラッシュ、プロセスのハング、ヘルスチェックの失敗、ディスクフル状態、依存関係の停止を定期的にシミュレートします。ツールやスクリプトを使用して、インスタンスを終了させたり、バックエンドへの下り（egress）をブロックしたり、プロキシレイヤーでレイテンシを注入したりします。
  • MIGの自動修復とLBからの切り離しを検証するために、意図的にヘルスチェックエンドポイントを失敗させます。代替インスタンスの動作と復旧タイムラインを確認します。
  • リージョン退避を実践します。あるリージョンのバックエンドをドレインし、グローバルロードバランサのフェイルオーバーを観察し、セカンダリリージョンのステートフルな依存関係を検証します。
  • 継続的改善：テスト中の平均検出時間、フェイルオーバー時間、データ損失のメトリクスを記録します。RTO/RPOを削減し、手動ステップを排除する修正を優先します。

実践的な問題シナリオ

Brightlane Retailは、us-central1でeコマースプラットフォームを運用しており、厳しい可用性要件と注文データに対して4時間のRPOが求められています。経営陣は、ゾーン障害をダウンタイムなしで、リージョン障害を最小限の顧客影響で乗り切ることを要求しています。

アプローチ：

1. HTTP自動修復を備えたリージョンMIGとグローバルHTTP(S) Load Balancerを実装する
   • 根拠：リージョンMIGはインスタンスを複数のゾーンに分散させ、アプリケーションレベルのHTTPヘルスチェックにより、10秒間隔のチェックが3回失敗した後に自己修復が可能になります。グローバルロードバランサは、異常なVMを自動的に切り離し、正常なゾーンにトラフィックをフェイルオーバーさせます。
   • コマンド：

undefined

undefined

2. Cloud SQL HAをクロスリージョンリードレプリカとPITRで有効化する
   • 根拠：リージョンHAは、自動フェイルオーバーによるゾーンレベルの生存性を提供します。us-east1のリードレプリカは、ゼロではないが限定的なRPOでリージョンDRを提供します。PITR（MySQLのバイナリロギング）を有効にすると、特定の時点への復元が可能になり、論理的な破損に対応できます。
   • コマンド：

undefined

undefined

3. Dual-Region Cloud Storageとライフサイクルポリシーでオブジェクトアセットを保護する

   • 根拠：製品画像や静的アセットは、リージョンレベルのレジリエンスのためにデュアルリージョンバケットに保存されます。ライフサイクル移行により、古いアーティファクトをColdlineに移動してコストを最適化し、バージョニングと保持ポリシーにより、重要アセットの偶発的な削除を防ぎます。
   • 手順：オブジェクトのバージョニングを有効にし、重要なバケットに30日間の保持ポリシーを設定し、重要でないビルドアーティファクトについては90日後にColdlineに移行し、1年後に削除するライフサイクルルールを適用します。

4. PDスナップショットをスケジュールし、ステートフルサービス用のマシンイメージを作成する

   • 根拠：VMディスクの増分スナップショットは、高速なクラッシュコンシステントな復元オプションを提供します。マシンイメージは、起動と設定情報をキャプチャし、リージョンフェイルオーバー時のアプリサーバーの再構築を加速します。スナップショットスケジュールは、一貫性のあるポリシー主導のバックアップを保証します。
   • コマンド：

undefined

undefined

undefined

5. RTO/RPOを定義し、DRランブックとIaCをコード化する

   • 根拠：Web/APIに対して15分のサービスレベルRTO、注文に対して4時間のRPOを設定します。ランブックには、トラフィックのフェイルオーバー手順、Cloud SQLリードレプリカの昇格、DNSの緊急時対応策、および検証ステップを明記します。Infrastructure as Code (Terraform/Deployment Manager)は、決定論的な再構築を保証し、手動エラーを削減します。

6. セカンダリリージョンにキャパシティとクォータをプロビジョニングする

   • 根拠：重要なVMシェイプの予約を作成し、スタンバイのロードバランサバックエンド、SSL証明書、NATキャパシティを事前にプロビジョニングし、us-east1のCompute、SQL、転送ルール、KMSのクォータを確認します。これにより、フェイルオーバー中のキャパシティ不足を防ぎます。

7. カオス訓練を通じて復旧を検証し、改善点を文書化する

   • 根拠：四半期ごとのゾーン障害訓練でMIGとLBの動作を検証します。半期ごとのリージョン退避では、us-east1のリードレプリカを昇格させ、グローバルLBをus-east1のバックエンドに向け、RTO/RPOを測定します。発見事項は、手動ステップの削減やレプリカキャパシティの増強などの改善を推進します。

これらの手順に従うことで、Brightlane Retailは、自動自己修復を備えたゾーンレベルの高可用性と、定義されテストされたランブックを持つリージョンDR体制を実現し、注文データが4時間のRPOを満たし、アプリケーションサービスが目標RTO内で復旧することを保証します。

← セキュリティ、コンプライアンス、データ保護 · すべてのドメイン · コスト管理、パフォーマンス、容量の最適化 →

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

Googleを閲覧 →