📚 GCP PCA 学習: 2026-04-29

セクション: 1.4 マイグレーション計画の作成 前回からの繋がり: 1.3 では「Compute Engine / GKE / Cloud Run 何を使うか」を決め、1.4 では「既存システムをどの戦略で、どのツールで、何段階で移行するか」を計画する。これがアーキテクチャの「実現可能性」を左右する。

① 一言サマリー

「マイグレーション計画とは、オンプレ/他クラウドの既存システムを GCP に段階的に移行する戦略・工程・リスク対応を設計するプロセスです。」

② たとえ話

引っ越しに例えます。大きな家族が新しい家に引っ越すとき：

• Rehost（同じまま）: 今の家具・生活スタイルをそのまま持っていく。新しい家のサイズに合わせて配置するが、家具は変わらない。速いが、新しい家の利点を活かしきれない。
• Refactor（調整）: 家具を少し修理・調整して運び込む。例えば、大きすぎるソファを分割可能な椅子に変える。少し工夫するだけで、新しい家に最適化できる。
• Rearchitect（再構想）: 新しい家向けに、オーダーメイド家具を新調する。スペースを最大限活用でき、生活が大きく改善する。ただし時間とお金がかかる。
• Rebuild（再構築）: 新しい生活スタイルに合わせて、家具も家の構造も全て一から設計し直す。最適だが、一番費用と時間がかかる。
• Replace（置き換え）: 家族が引っ越しを機に、親戚の家にシェアハウスして、新しい家は要らないと判断。オンプレ運用を完全に止める。

ポイント: 「何をする」（ツール・技術）より「なぜそうするのか」（ビジネス制約・コスト・期間）が先。5R の選択は、ビジネス要件が決める。

③ 図解

5R 選定フロー

graph LR
    REQ["ビジネス要件
期間・コスト・スキル"]
    SPEED["移行期間
短い？"]
    COST["予算
限定的？"]
    SKILL["クラウド
スキル高い？"]
    COMPLEX["ワークロード
複雑？"]

    REQ --> SPEED
    SPEED -->|YES
3ヶ月以内| REHOST["🟢 Rehost
同じまま移行
リフト&シフト"]
    SPEED -->|NO
6ヶ月以上| COST
    COST -->|YES
コスト優先| REFACTOR["🟡 Refactor
軽微な調整
既存資産活用"]
    COST -->|NO
新規投資OK| SKILL
    SKILL -->|低| REARCHITECT["🔵 Rearchitect
アーキ再設計
部分モダン化"]
    SKILL -->|高| COMPLEX
    COMPLEX -->|複雑| REBUILD["🔴 Rebuild
完全再構築
新技術採用"]
    COMPLEX -->|単純| REPLACE["⚫ Replace
オンプレ廃止
SaaS/PaaS移行"]

移行ツール適用マトリクス

graph LR
    A["ワークロード
タイプ"]
    A -->|VM
オンプレ| MIGRATE_VM["Migrate for
Compute Engine
自動化度：高
テンプレート：VM"]
    A -->|コンテナ
既存K8s| MIGRATE_ANTHOS["Migrate for
Anthos
自動化度：中
テンプレート：K8s"]
    A -->|大容量
100TB+| TRANSFER["Transfer
Appliance
自動化度：低
テンプレート：物理"]
    A -->|DB
SQL系| DMS["Cloud DMS
or Database
Migration
Service"]
    A -->|データ
分析系| BQ_MIGRATE["BigQuery
Data Transfer
Service"]

マイグレーション段階プラン

sequenceDiagram
    participant Assess as 1. Assess
    participant Plan as 2. Plan
    participant Pilot as 3. Pilot
    participant Phase as 4. Phase 移行
    participant Optimize as 5. Optimize

    Assess->>Assess: 既存インベントリ調査
依存関係マッピング
コスト見積り
    Assess->>Plan: アセスメント完了
    Plan->>Plan: 5R 選定
ツール決定
工程表作成
    Plan->>Pilot: 計画完了
    Pilot->>Pilot: 小規模環境
テスト移行
ロールバック検証
    Pilot->>Phase: パイロット完了
    Phase->>Phase: 段階的本格移行
DNS切り替え
オンプレ・GCP 並走
    Phase->>Optimize: フェーズ完了
    Optimize->>Optimize: コスト最適化
スケーリング
オンプレ廃止

用語注釈: - Rehost: 一言で「ソースコード未変更のまま VM/コンテナ化」。たとえると「デパートで売られているそのまま購入」。Migrate for Compute Engine で自動化。 - Transfer Appliance: 一言で「物理的にデータを転送する NAS」。たとえると「荷物が多すぎるから、トラック借りて一気に運ぶ」。2026年4月時点で、VPC内プライベートIPのソース自動セットアップ対応。

④ 仕組みの深掘り

なぜ 5R なのか？

コストと期間の トレードオフ

• Rehost (リフト&シフト)
• コスト: 低（1～3ヶ月）
• 利点: 既存資産そのまま、リスク最小、スピード優先
• 欠点: クラウド技術をいかせない（高額ライセンスのまま）

• 適用: 「オンプレを緊急にクラウドに出す」「5年のライセンスが残ってる」

• Refactor (最小限の修正)

• コスト: 中（3～6ヶ月）
• 利点: Rehost より若干クラウド最適化、自動スケーリング可能に
• 欠点: 中途半端（本当の最適化ではない）

• 適用: 「Rehost できないほど複雑じゃない」「少し調整したら GCP で安くなる」

• Rearchitect (部分的再設計)

• コスト: 高（6～12ヶ月）
• 利点: マイクロサービス化、スケーラビリティ向上
• 欠点: 部分的 = ボトルネック残る、複雑性増加

• 適用: 「特定のレイヤーだけモダン化したい（API層は GKE、DB は Cloud SQL）」

• Rebuild (完全再構築)

• コスト: 最高（12ヶ月以上）
• 利点: クラウドネイティブ（無限スケール、従量課金）
• 欠点: 既存スキル・資産が活かせない、リスク大

• 適用: 「レガシー技術で身動き取れない」「ビジネスモデル自体を変える」

• Replace (置き換え・廃止)

• コスト: 最低（0～6ヶ月）
• 利点: 運用負担ゼロ（SaaS へ）
• 欠点: カスタマイズ不可、ベンダーロック
• 適用: 「自社ビジネスの中核ではない」「SaaS で十分」（例：メール→Google Workspace）

ネットワーク接続設計の重要性

Migrate for Compute Engine は ネットワーク接続がボトルネック になります。

• Cloud Interconnect (専用線)
• 帯域: 10～100 Gbps
• 遅延: ~1 ms
• コスト: ~¥30万/月

• 用途: 大規模エンタープライズ、オンプレ↔GCP の長期共存

• Cloud VPN (暗号化トンネル)

• 帯域: ~3 Gbps
• 遅延: ~50 ms
• コスト: ~¥1,000/月（スモール）

• 用途: 中小規模、テスト環境、一時的な接続

• Transfer Appliance (物理転送)

• 1回で 100～500 TB
• 遅延: なし（オフライン）
• コスト: ~¥50万/回
• 用途: 初期大容量転送（VPN では 1年かかる）

PCA 試験のポイント: 100 TB のデータを VPN で移行？→ 100 Mbps * 86,400 秒 = ~1 TB/日 → 100日かかる → Transfer Appliance を選ぶ。

⑤ 他サービスとの使い分け

Migrate for Compute Engine vs Migrate for Anthos

Migrate for Compute Engine vs Transfer Appliance

Google Cloud DMS vs BigQuery Data Transfer Service

• Cloud DMS: SQL Server / MySQL / PostgreSQL → Cloud SQL / Cloud Spanner（スキーマ + 初期データ）
• BigQuery Data Transfer Service: 定期的な増分データ同期（日次バッチ）

PCA 判断軸: 「オンプレ DB を管理 DB に一括移行」 → DMS。「毎日増えるデータを BQ に自動取り込み」 → Transfer Service。

⑥ 実務への応用

シーン 1: レガシー ERP システムの GCP 移行

背景: 製造業。SAP (Windows Server 2003 + DB2) がオンプレで動作中。保守期限終了迫る。期間: 6ヶ月以内。

判断: - ✅ Rehost を選定（SAP は複雑、Rearchitect は 18ヶ月） - ✅ Migrate for Compute Engine で自動テンプレート生成 - ✅ Cloud Interconnect で 10 Gbps 接続（SAP は同期 DB 要件が厳しい） - ✅ 段階: Pilot (Dev) → Phase 1 (Staging) → Phase 2 (Prod) - ❌ Transfer Appliance は不要（DB サイズ 2 TB、VPN で十分）

運用ポイント: - Migrate for Compute Engine は M4 マシンタイプ 推奨（SAP 認定） - ライセンス: SAP Licensing は Core ベース → GCP vCPU に再計算（安くなる） - DNS 切り替え: オンプレ DNS → Cloud DNS への段階的移行

シーン 2: Web スタートアップのマイクロサービス化

背景: Node.js / Python の Web アプリ。モノリシック。独立したコンテナ化したい。既存 Heroku から移行。期間: 3ヶ月。

判断: - ✅ Rearchitect を選定（モノリス → マイクロサービス） - ✅ Migrate for Anthos (GKE へ) - 既存コンテナ → GKE へ転送 - Service Mesh (Istio) で L7 トラフィック管理 - ✅ Cloud CDN + Cloud Armor で DDoS 対策 - ✅ Workload Identity で GCP API 認可（IAM 一元化）

運用ポイント: - CI/CD: Cloud Build + Cloud Deploy で カナリアデプロイ - 自動スケーリング: HPA (Horizontal Pod Autoscaler) + Node 自動スケーリング - コスト: Autopilot GKE なら k8s 管理不要（標準の 30% 増だが、時間節約）

シーン 3: 大規模データ移行（分析基盤）

背景: Hadoop on-prem (1.2 PB) → BigQuery へ。ネットワーク帯域制限（月 1 TB 枠）。

判断: - ✅ Replace を選定（Hadoop 廃止、BQ に一本化） - ✅ Transfer Appliance (100 TB × 12 台 = 1.2 PB) - 初回: Transfer Appliance で 3ヶ月で 1 PB 転送 - 増分: Cloud DTS で 毎日自動同期（Hive → BigLake） - ✅ BigQuery Omni (GCP 外データソースのクエリ) で過渡期対応

運用ポイント: - BigLake Tables (Apache Iceberg) で データカタログ一元化 - BigQuery Reservation で 年払い割引（40% 安） - Dataflow で ETL パイプライン自動化

⑦ よくある誤解・落とし穴

❌ 誤解 1: 「Rehost さえできれば OK」

罠: Rehost は速いが、ライセンスコストが下がらない。

• オンプレ: 物理 CPU 4 個で SAP ライセンス ¥100万/年
• Rehost (N2): 16 vCPU で実行 → ライセンス ¥400万/年（逆に高い！）
• 正解: Refactor (E2 マシンで負荷試験) → 4 vCPU で十分 → ライセンス ¥100万/年

PCA 試験対策: 「Rehost の自動化」だけでなく「その後の最適化」を含めた計画書を設計できるか。

❌ 誤解 2: 「Transfer Appliance は遅い」

罠: 申し込み → 納品 → データコピー → Google への返送 → 検証 で 4～8 週間かかる。

• VPN 3 Gbps で 1 PB: 100日
• Transfer Appliance: 6回 (100 TB × 6) で 初回 6週間 + その後は 4週間 × 5 = 26週間
• 正解: 「初回は遅いが、その後は毎月ローリング」で、トータルでは VPN より速い。

PCA 試験対策: 「単純に遅延で判断するな、初回コスト + 運用期間で判断」。

❌ 誤解 3: 「Cloud Interconnect は必須」

罠: Interconnect (¥30万/月) を導入したが、実際の VPN で十分だった（¥1,000/月）。

• 100 Mbps 帯域あれば VPN で十分
• Interconnect が必要: Rehost で 同期 DB レプリケーション / Live Migration
• 正解: VPN でテスト → 遅延問題が出たら → Interconnect 検討

PCA 試験対策: 「リスク低く、まず VPN」がスタート地点。

❌ 誤解 4: 「ライセンス移行は無視」

罠: Rehost して「ライセンスそのまま」→ 後から「オンプレのままのライセンス体系を GCP で払え」と言われる。

• Windows Server: Rehost → BYOL (Bring Your Own License) 申告必須
• Oracle DB: Socket → Core ライセンスに再計算（複雑）
• SAP: 物理 CPU → vCPU に再計算（単価は 1/4 だが、必要 vCPU が増えることが多い）

PCA 試験対策: マイグレーション計画には「ライセンス最適化パス」を含める。

❌ 誤解 5: 「段階移行は時間浪費」

罠: 一気に本格運用開始 → 問題が出ても引き返せない。

• パイロット: 信頼構築 + 学習（2～4週間）
• フェーズ 1-2: 部分導入 + 並走（1～3ヶ月）
• 本格運用: GCP 一本化（1ヶ月後）
• 正解: トータル 6ヶ月だが、問題早期発見で最終的には 3ヶ月で安定。

PCA 試験対策: 「見積期間」= 本格 + 検証 + ロールバック時間を含める。

⑧ 理解度チェック

問題 1

あるヘルスケア企業が、オンプレの病歴管理システム（Windows + SQL Server、HIPAA 準拠）を GCP に移行予定です。 - 既存 Windows ライセンス: 5 年分残ってる - ネットワーク: 100 Mbps 枠のみ - データサイズ: 5 TB - 期間: 9ヶ月以内 - 予算: 限定的

5R はどれを選びますか？理由も。

想定回答: - ✅ Refactor （正解） - 理由: Windows ライセンス残ってるので Rehost（Compute Engine）。ただし 5 TB を 100 Mbps VPN で移すと 5 日かかり、並走期間が長い。初期はパイロット (1 TB) で Interconnect 検討不要と判定。 - ネットワーク: VPN 十分 (5 TB / 100 Mbps = 5 日) - ツール: Migrate for Compute Engine + Cloud DMS (SQL Server → Cloud SQL) - セキュリティ: VPC Service Controls で HIPAA アウトバウンド制限 - 避けるべき: Rearchitect（HIPAA 更新が複雑）、Rebuild（医療ドメイン知識喪失）

問題 2

ある製造業の IoT センサーデータが、毎月 500 GB で増加中（合計 50 TB）。オンプレの Hadoop から BigQuery へ移行します。 - 既存ネットワーク: 10 Mbps のみ（社内ネットワーク共有） - レイテンシー: 1日遅延まで許容 - 初期データ: ASAP - 増分: 毎日

何のツールで、どう段階化しますか？

想定回答: - ✅ Transfer Appliance（初期） + Cloud DTS（増分） （正解） - 理由: 50 TB を 10 Mbps で移すと 50 × 10^12 / (10 × 10^6) / 86,400 = 58 日 → Transfer Appliance で初期 2～3 回 (100 TB × 3) で 6～8 週間で完了 - 増分: Dataflow (Hive → Avro → GCS → BigQuery) で毎日自動同期 - セキュリティ: 10 Mbps しかないから「ネットワーク負荷ゼロ」が Transfer Appliance の価値 - 避けるべき: Cloud Interconnect（月 ¥30万 × 6ヶ月 = ¥180万は過剰）

問題 3

ある SaaS スタートアップが、Heroku で動く Python + PostgreSQL のモノリスをマルチテナント・マイクロサービス化します。 - 既存ユーザー: 500 社 - スキル: GCP / Kubernetes 初心者 - 期間: 6ヶ月 - ダウンタイム: ゼロ（本番環境ライブ）

5R と移行ツール、段階プランは？

想定回答: - ✅ Rearchitect + Migrate for Anthos + GKE Autopilot （正解） - 理由: 既存モノリスを Refactor (Python 同じ) では不十分 → マイクロサービス化 = Rearchitect - ツール: Anthos GKE (Service Mesh + Istio で L7 トラフィック管理) - DB: Postgres → Cloud SQL for PostgreSQL (読み取りレプリカで Heroku と並走) - ステップ: 1. 開発: Heroku コード → GKE Autopilot でテスト 2. パイロット: 新規顧客 50 社を GKE 誘導、Heroku と並走 3. フェーズ 1: 既存顧客 50% に Blue-Green デプロイ 4. フェーズ 2: 残り 50% + Heroku サンセット - スキル: GKE Autopilot なら k8s 管理不要 (Google がやる) - 避けるべき: Rehost (Compute Engine) はモノリスのまま = スケーラビリティ改善なし

⑨ 深掘り補足（PCA 試験範囲外・オプション）

⚠️ Preview: BigLake Tables と Apache Iceberg でのメタデータマイグレーション

2026 年 4 月現在、BigQuery は 外部データカタログのメタデータを BigLake Iceberg テーブルに自動変換 できるようになっています。

Apache Hive Metastore（オンプレ）
    ↓ [自動スキーマ変換]
BigLake Tables（Iceberg 形式）in GCS
    ↓ [SQL 互換性]
BigQuery で Iceberg テーブルをネイティブクエリ

利点: - Hive → Iceberg: ACID トランザクション獲得 - Iceberg → BigQuery: クエリエンジン統一（Presto / Spark と互換） - Time Travel & Schema Evolution: オンプレでは実装困難な高度な機能

PCA 実務: Hadoop → BigQuery 移行時に「単なるデータコピー」ではなく「Iceberg 化」を含めると、ユーザーは既存ツール (Spark / Presto) をそのまま使える（学習コスト低い）。

⚠️ Preview: Memorystore for Valkey へのマイグレーション機能

2026 年 4 月現在、Memorystore for Valkey が Preview で「自管理 Redis / Valkey からのワークロード自動移行」機能を提供します。

セルフマネージド Redis (Compute Engine)
    ↓ [自動マイグレーション]
Memorystore for Valkey (マネージド)
    ↓ [ゼロダウンタイム・双方向同期]
GCP ネイティブ運用（バックアップ・レプリケーション・フェイルオーバー自動）

PCA 実務: キャッシュレイヤーの Rehost (Compute Engine Redis) を Refactor (Memorystore) に段階的に切り替えることで、 - 運用負荷 70% 削減 - ライセンス (Redis Enterprise 有償) 廃止 - フェイルオーバー自動化（RTO 秒単位）

Migrate for Compute Engine: VPC 内プライベートソース自動セットアップ

2026 年 4 月リリース: VPC 内プライベート IP のソース（自管理 DB / Compute Engine 内 SQL など）を、自動的に Migrate for Compute Engine で検出・セットアップ。

従来: IP ホワイトリスト + VPN / Interconnect を手動設定 新機能: VPC Peering / Private Service Connection で自動化

PCA 実務: Migrate for Compute Engine のセットアップ時間 30% 削減。大規模エンタープライズ（1000+ VM）では人月単位で節約。

次回: 2.1 ネットワークトポロジーの設定

実装フェーズへ入ります。1.4 では「何を・どう・いつまでに」を決めましたが、2.1 では「VPC / Cloud Interconnect / Cloud NAT を具体的に設定」します。