Google PCA: 移行、モダナイゼーション、ハイブリッドクラウド戦略 — 学習ガイド

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

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

概要

移行、モダナイゼーション、ハイブリッドクラウド戦略を成功させるには、プラットフォームの選択をビジネス成果と整合させつつ、可用性、データ整合性、レイテンシー、セキュリティ、コストへのリスクを管理する必要があります。その道のりは、データセンターのリスクを削減するための迅速なリホストと、クラウドの利点を享受するための的を絞ったリファクタリングとのバランスを取るものです。改善を持続させるためには、テクノロジーと並行して運用モデルも進化させる必要があります。本セクションでは、アセスメントとウェーブ計画、意思決定フレームワーク、移行の仕組み、ハイブリッド統合、モダナイゼーションのパターン、ポリシーとマルチクラウドに関する考慮事項、そして移行後の最適化について、特に障害モードとトレードオフに重点を置いて、実践的な青写真を提供します。

アセスメント、準備、ウェーブ計画

• 検出と依存関係分析

  • ワークロード、バージョン、OSカーネル、ストレージ、IAM、データ分類のインベントリを作成します。web→API→DBのフロー、共有サービス (LDAP/AD, DNS, NTP)、バッチパイプライン、外部APIにわたる依存関係をマッピングします。
  • 移行前の環境でアプリケーションプロファイリングと分散トレーシングを使用して、隠れた依存関係やロングテールのレイテンシーを明らかにします。VPC Flow Logsとアプリケーションレベルの計装 (Cloud Logging, Cloud Monitoring, Cloud Trace) を有効にします。
  • ステートの境界とデータのグラビティ（サイズ、アクセスパターン（R/W比）、一貫性の要件、レプリケーションのトポロジー）を特定します。

• 準備とスキル

  • クラウドの基礎、IaC、CI/CD、SRE、セキュリティ、ネットワーキング、データベースのスキルを評価します。役割ベースのトレーニングと認定資格のロードマップを定義し、スキルアップとシャドーオンコールのための時間を予算に計上します。
  • 最初のウェーブの前に、ランディングゾーン（プロジェクト、フォルダ、Shared VPC、組織のポリシー、監査シンク、CMEK戦略）を確立します。

• 移行ウェーブ計画

  • 親和性と影響範囲（共有データ、同期的な依存関係、変更ウィンドウ）によってアプリケーションをウェーブにグループ化します。リスクの高い依存関係は同じウェーブに含めるか、明確に定義されたAPIコントラクトでスタブ化します。
  • ウェーブごとにSLO、RTO/RPO、ロールバック基準、および検証ゲート（スキーマチェック、合成ユーザージャーニー、パフォーマンスのしきい値）を定義します。
  • ランブックと変更管理を準備します：カットオーバーの手順、チェックポイント、ロールバック、および承認のための証跡収集。

• 互換性、ライセンス、パフォーマンスのベースライン設定

  • Compute EngineおよびマネージドサービスでのOSとミドルウェアのサポートを検証します。商用ライセンスの条件、BYOLの制約、カーネルモジュールの要件、ハードウェアアフィニティを確認します。
  • ターゲットリソースのサイジングとメリットの検証のために、CPU、メモリ、IOPS、スループット、レイテンシーのベースラインをピーク値と95パーセンタイル値で取得します。

• データガバナンス

  • PII/PCIデータを分類します。Cloud DLPを使用して、取り込み時に非識別化またはトークン化を計画します。
  • 最初の本番ログが保存される前に、監査、保持、エクスポートのポリシーを定義します。

一般的な障害モード：カットオーバー後に未知の同期的依存関係が連鎖的なタイムアウトを引き起こす、IP範囲の重複が接続をブロックする、ライセンスコンプライアンスのギャップ、データの変更が元に戻せないことによるロールバックの不整合など。

移行パターン、データ移動、カットオーバー

• 意思決定フレームワーク（6R）

  • リホスト：Compute Engineにそのまま移行する。クラウドへの移行時間が最も速く、変更は最小限。リスク：技術的負債と非効率なサイジングを引き継ぐ可能性がある。
  • リプラットフォーム：マネージドサービス（例：Cloud SQL、Cloud Load Balancing）を採用するために小さな変更を加える。少ないコード変更で、運用上のメリットを迅速に得られる。
  • リファクタリング：GKE/Cloud Run向けに分解またはコンテナ化し、イベント駆動パターンを採用する。長期的なメリットは最も高いが、デリバリーリスクが伴う。
  • リタイア：使用状況と依存関係がないことが証明された後、未使用のシステムを削除する。
  • リテイン：規制やレイテンシの理由でオンプレミスに維持し、ハイブリッド経由で統合する。
  • リロケート：vSphereワークロードをGoogle Cloud VMware Engineに移動し、ツールを維持し、変更を最小限に抑える。

• コンピューティングとデータベースの移行ツール

  • Migrate to Virtual Machinesは、ディスクとネットワーク構成を維持しながら、Compute Engineへのリホストを加速する。ゲストOSのサポートとカーネルドライバを検証すること。
  • Database Migration Serviceは、低ダウンタイムでCloud SQLへの同種オンラインレプリケーション（例：MySQL、PostgreSQL）を提供する。binlog/レプリケーション設定が正しく、レイテンシがほぼリアルタイムのキャッチアップをサポートしていることを確認する。
  • ワークロードに合わせてデータベースを選択する：
    • Cloud SQLはマネージドリレーショナルニーズに対応。ストレージの自動増量を有効にし、コアあたり75%近くのCPUを監視する。レプリケーションラグを追跡し、しきい値に近づいている場合はシャードまたはスケールアップする。
    • Bigtableは低レイテンシ、高スループットの時系列データ（例：センサーデータ）の取り込みに対応。
    • Spannerはグローバルスケールと強力な整合性に対応。ロックインとポータビリティのトレードオフを理解する。
  • データ移動
    • Storage Transfer Serviceは、継続的またはスケジュールされた転送に対応。並列化され、リトライに対応している。
    • Transfer Applianceは、ネットワーク時間とリスクを削減するための大規模な一括ロード（数十から数百TB）に対応。
    • gsutilと並列複合アップロードは、小〜中規模のデータセットに対応。

• オンライン移行とオフライン移行

  • オンライン：短いカットオーバーを伴う継続的なレプリケーション。利点：ダウンタイムが最小限。欠点：安定したレイテンシと帯域幅が必要。慎重なデュアルライトの回避が求められる。
  • オフライン：スナップショットと一括インポート。利点：シンプルで予測可能。欠点：ダウンタイムがコピー時間に等しい。

• カットオーバー計画、ロールバック、ダウンタイム制御

  • カットオーバーの数日前にDNSのTTLを下げ、必須でない変更を凍結し、メンテナンスウィンドウをスケジュールする。
  • 検証ゲートを実行する：スキーマのパリティ、チェックサムまたは行数、アプリケーションのスモークテスト、カナリアトラフィック、およびパフォーマンステスト。
  • ロールバック：下位互換性のあるスキーマ変更、機能フラグ、および真のソースデータの維持を保証する。安定性が証明されるまで、不可逆的な書き込みを避ける。
  • 最小限のダウンタイムでのVMディスク拡張の例：
    • コンソールまたはCLIでディスクをリサイズ：gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
    • Linux ext4の場合：sudo resize2fs /dev/sdb
  • GKEでの影響を最小限に抑えたローリングアプリ更新：
    • kubectl set image deployment/echo-deployment echo-container=gcr.io/project/echo:v2

一般的な障害モード：Cloud VPN経由のパケットロスによるデータベースレプリケーションの中断（Dedicated InterconnectまたはPartner Interconnectを使用）、カットオーバー中のデュアルライトの不整合、ヘルスチェックの欠落によるローリングアップデートの停止。

ハイブリッドID、接続性、オンプレミス統合

• ID

  • Active Directoryを信頼できる情報源として維持する。アカウントとグループの同期にはGoogle Cloud Directory Syncを使用し、ユーザーがGoogle CloudにアクセスするためのSAML SSOを構成する。
  • ロールを介して最小権限のIAMを付与し、ワークロードにはサービスアカウントを使用し、長期間有効なキーよりもWorkload Identity Federationを優先する。

• ハイブリッド接続とルーティング

  • 初期の低スループットニーズやテストにはCloud VPNを使用し、持続的な帯域幅、低レイテンシ、予測可能なレプリケーションパフォーマンスのためにはDedicated Interconnectに移行する。回復力のために冗長なVLANアタッチメントとHA VPNまたはデュアルインターコネクトをデプロイする。
  • エンドツーエンドの到達可能性を維持するために、Google CloudのIP範囲がオンプレミスのCIDRと重複しないようにする。
  • ファイアウォールルールとタグを使用して階層型アクセスを強制する。Web→APIのみを許可する例：
    • gcloud compute firewall-rules create allow-web-to-api –network=prod-vpc –direction=INGRESS –action=ALLOW –rules=tcp:8443 –source-tags=web –target-tags=api
  • パブリックな下り（egress）なしでサービス間通信を行うにはPrivate Service ConnectとプライベートGoogleアクセスを使用し、必要に応じてVPC Service Controlsでセグメント化する。
  • ハイブリッドDNS：オンプレミスとクラウドの両方の名前を解決するために、転送およびインバウンド/アウトバウンドポリシーを持つCloud DNSを使用する。

• オンプレミス統合とレイテンシ

  • ステートをコンピューティングの近くに置くか、その逆を行う。オンプレミスのDBが権威を保つ必要がある場合は、プライベートアクセスのためにCloud VPN/Interconnectを備えたApp Engineフレキシブル環境またはCompute Engineを検討する。
  • 同期パスを分離し、レイテンシのジッターを吸収するためにキャッシュとキューを導入する。平均だけでなく、p95/p99レイテンシを測定する。

一般的な障害モード：CIDRの重複によるルートのブロック、BGPセッションの冗長性不足、パブリックDNSまたは下り（egress）のリークによるプライベートサービスの公開、高レイテンシリンク上での予期せぬチャッティなプロトコルによるパフォーマンス低下。

モダナイゼーション、運用モデル、最適化

• レガシーモダナイゼーションのパターン

  • ストラングラーFig (絞め殺しのイチジク) パターン: モノリシックなアプリケーションの前にAPIファサードを配置し、ドメインを段階的に新しいサービスにルーティングする。
  • コンテナ化: ベースイメージを標準化し（互換性がある場合はAlpineなどのスリムなイメージを優先）、Dockerfileのレイヤーを順序付けて依存関係のインストールをキャッシュしてからソースをコピーすることでビルド時間を短縮し、ステージングでの自動テストを含むCI/CDパイプラインを導入する。
  • マネージドデータ: オペレーショナルストアをマネージドデータベースに移行する。ドメインごとに選択する: トランザクションにはCloud SQL、時系列にはBigtable、グローバルに一貫性のあるワークロードにはSpanner。

• アプリケーションの互換性、一貫性、パフォーマンスの検証

  • OSとミドルウェアのサポート、スレッドと接続の制限、ファイルシステムのセマンティクスを確認する。ライセンスのポータビリティと使用量測定を検証する。
  • データ整合性の要件（ライト後の読み取り、単調読み取り、結果整合性 vs 強整合性）を定義する。それらをターゲットデータベースとアクセスパターンに合わせる。
  • 負荷テストと合成ユーザージャーニーでパフォーマンスを検証し、移行後にSLOバジェットが達成可能であることを確認する。

• オブザーバビリティとコンプライアンス

  • Cloud Logging、Monitoring、Traceを使用してアプリケーションを計装し、マイクロサービス間のレイテンシを特定する。
  • 監査ログとIAMポリシーの変更をBigQueryにエクスポートし、データセットに対するビューとIAMを介して監査人と共有する。複数年の保持要件を満たすために、長期的なメトリクスをCloud Storageにエクスポートする。

• 運用モデルと所有権

  • SREプラクティス（SLO、エラーバジェット、インシデント対応、非難のないポストモーテム）を導入する。サービスの所有権、ランブック、オンコールローテーションを定義する。
  • IaC（例: Terraform）を使用してインフラストラクチャを一貫してプロビジョニングする。Deployment ManagerはGoogle固有であり、マルチクラウドのリソース自動化を制限する可能性があり、多くのエンジニアにとって馴染みがないことに注意する。
  • Organization Policy、IAM Conditions、Config Sync、Policy Controller (OPA Gatekeeper) を使用して、プロジェクトや環境全体でポリシーの一貫性を自動化する。

• マルチクラウド戦略とロックインのトレードオフ

  • Kubernetes、12-Factor Appプラクティス、OpenAPIで定義されたコントラクト、データエグレスの抽象化により、ポータビリティを高める。ポータビリティと運用負荷およびパフォーマンスのバランスを取る。マネージドサービスは労力を削減するが、切り替えコストを増加させる可能性がある。

• コストとパフォーマンスの最適化、および廃止

  • ステートレスなCompute Engineをマネージドインスタンスグループとオートスケーリングでスケールさせる。スケールトゥゼロの恩恵を受けるバースト的なワークロードやMVPワークロードには、サーバーレス（Cloud FunctionsまたはCloud Run）を選択する。
  • VMをライトサイジングし、GKEでオートスケーリングを有効にし、確約利用割引を適用し、未使用のアーティファクトを廃止する。KPI（可用性、レイテンシ、サービス提供コスト）を介してメリットの実現を追跡する。
  • クーリング期間と依存関係の確認後、オンプレミスシステムを廃止する。保持ポリシーに従ってデータをアーカイブまたは削除し、CMDBを更新する。

実践的な問題シナリオ

Acme Weather Networksは、リアルタイムセンサープラットフォームとレガシーなJ2EE管理UIを、オンプレミスのデータセンターからGoogle Cloudに移行する必要があります。このシステムは、毎秒10回の測定値を送信する50,000個のセンサーからデータを取り込み、5年分の履歴データ（75 TB）を保存します。移行期間中、オンプレミスのERPおよびActive Directoryへのプライベートアクセスを維持し、オンプレミスのMySQLデータベースのダウンタイムを最小限に抑え、VPN経由で観測されていた断続的なレプリケーションの失敗を解消する必要があります。

1. 安全なランディングゾーンの確立

   • 組織、フォルダ、本番/非本番プロジェクトを作成する。ハイブリッド接続を介したオンプレミスへの到達可能性を確保するために、重複しないIP範囲を持つ共有VPCを設定する。組織のポリシーと、最小権限アクセスを持つBigQueryへの中央集権的な監査ログのエクスポートを適用する。
   • 理由: ワークロードが導入される前に、ルーティングの競合を防ぎ、ベースラインのガバナンスを強制するため。

2. ハイブリッドIDの実装

   • Google Cloud Directory Syncを設定してADのIDとグループをミラーリングし、SAML SSOをセットアップする。プラットフォームとワークロードには、サービスアカウントとIAMカスタムロールを使用する。
   • 理由: 企業のIDを信頼できる唯一の情報源 (Source of Truth) として維持し、最小権限のアクセス制御を可能にするため。

3. 接続のプロビジョニングとパフォーマンスの計画

   • 開発/テスト用にHA Cloud VPNから始める。本番のデータベースレプリケーションと安定したセンサー取り込みのために、デュアルVLANアタッチメントとBGPセッションを持つDedicated Interconnectをプロビジョニングする。
   • 理由: InterconnectはVPNよりも低レイテンシでパケットドロップが少なく、MySQLのレプリケーションとストリーミング取り込みを安定させるため。

4. 履歴データの効率的な移動

   • Transfer Applianceを注文し、オンプレミスで75 TBのデータセットをロードし、発送してCloud Storageに復元する。必要に応じて、継続的な増分更新のためにStorage Transfer Serviceを使用する。BigtableやBigQueryに保存する前に、サポートログに対してCloud DLPを実行し、PIIを非識別化する。
   • 理由: オフラインでの一括転送は、カットオーバーウィンドウのリスクを低減し、回線の飽和を回避するため。

5. J2EE管理UIのリホスト

   • Migrate to Virtual Machinesを使用して、J2EE VMをCompute Engineにリフト＆シフトする。インスタンスをHTTP(S)ロードバランサーの背後にあるマネージドインスタンスグループに配置する。タグを使用してファイアウォールルールを適用し、web→API→DBのフローのみを強制する。例:

undefined

• 理由: 最小権限のネットワークパスを強制しつつ、使い慣れたランタイムで迅速にリスクを低減するため。

6. 最小限のダウンタイムでMySQLをCloud SQLに移行

   • ソースでパフォーマンスのベースラインを取得し、バイナリロギングを有効にする。Database Migration Serviceを使用して、Cloud SQLへの継続的なレプリケーションを設定する。ストレージの自動増加を有効にし、CPUが75%に近づいた場合やレプリケーションラグが60秒未満の場合にアラートを作成する。
   • 理由: オンライン移行は低いダウンタイムを実現し、マネージドSQLは運用上の労力を削減し、運用SLOを強制するため。

7. 制御されたカットオーバーの実行

   • 48時間前にDNSのTTLを下げ、スキーマの変更を凍結し、メンテナンスウィンドウをスケジュールする。オンプレミスでの書き込みを停止し、DMSのラグがゼロであることを確認し、チェックサムとアプリケーションのスモークテストを実行してから、クライアントをCloud SQLに向ける。検証が失敗した場合に書き込みをオンプレミスにリダイレクトできるロールバック計画を維持する。
   • 理由: 決定論的な手順により、RTOを制限し、データの一貫性を維持するため。

8. リアルタイムテレメトリのための取り込みの構築

   • Pub/Subを介して取り込み、Dataflowで処理し、時系列データをBigtableに保存して低レイテンシの書き込みと読み取りを実現する。ERP統合はInterconnect経由でプライベートに保つ。
   • 理由: Bigtableは高スループットの時系列プロファイルに適合し、Pub/Subはバースト的なプロデューサーをコンシューマーから分離するため。

9. サービスのコンテナ化とCI/CDの導入

   • GKE用にステートレスサービスをコンテナ化する。スリムなベースイメージを使用し、依存関係のインストールがソースのコピーより前に行われるようにレイヤーを順序付けることで、Dockerfileを最適化する。ステージングでの自動テストとカナリアリリースを含むCI/CDパイプラインを実装する。最小限のダウンタイムで更新する:

undefined

• 理由: 大規模な一斉書き換えなしに、デプロイの速度、信頼性、スケーラビリティを向上させるため。

10. オブザーバビリティと監査の強化

    • Cloud Logging、Monitoring、Traceを計装して、マイクロサービス間のレイテンシを特定する。監査ログをBigQueryにエクスポートし、監査人向けのスコープ付きビューを共有する。5年間の保持要件を満たすために、長期的なメトリクスをCloud Storageにエクスポートする。
    • 理由: 完全な忠実度のテレメトリは、SLOとコンプライアンスをサポートするため。

11. 最適化と廃止

    • MIGとGKEでオートスケーリングを有効にし、インスタンスをライトサイジングし、確約利用割引を適用し、24時間365日稼働でないワークロードをサーバーレス（例: 補助タスク用のCloud Functions）にスケジュールしてスケールトゥゼロを実現する。安定性とクーリング期間の後、オンプレミスシステムを廃止し、CMDBを更新し、実現したメリットを公開する。
    • 理由: 二重運用の費用を排除しつつ、コストと運用の効率性を確保するため。

12. 運用化とトレーニング

    • ランブック、RACI、オンコールローテーション、SLO/エラーバジェットを最終決定する。スキルギャップを埋めるために、ターゲットを絞ったトレーニングと認定プランを提供する。IaCにはTerraformを優先する。Deployment ManagerはGoogle固有であり、Google以外のリソースに対応できない場合があることに注意する。
    • 理由: 成熟した運用モデルは、移行イベント後も信頼性とベロシティを維持するため。

← 信頼性、ディザスタリカバリ、事業継続性 · すべてのドメイン · オペレーション、オブザーバビリティ、プラットフォームの自動化 →

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

Googleを閲覧 →