企業上雲：不是搬家，是重新設計生活
遷移上雲是 PCA 考試中權重最高的領域之一，也是企業數位轉型的核心挑戰。作為架構師，你的任務不只是「把東西搬上去」，而是根據業務目標、技術債務和風險承受度，制定最適合的遷移策略。這一課我們將從策略框架到工具鏈，完整走一遍 GCP 遷移與混合雲的知識體系。
遷移的六大策略（6R Framework）
Google Cloud 採用業界通用的 6R 遷移策略框架，每種策略適用於不同的應用特性和業務目標：
| 策略 | 英文 | 說明 | 適用場景 | GCP 工具 |
|---|---|---|---|---|
| 原封搬遷 | Rehost (Lift & Shift) | 原樣搬移至雲端，不修改程式碼 | 時間緊迫、應用穩定 | Migrate to Virtual Machines、VMware Engine |
| 優化搬遷 | Replatform (Lift & Optimize) | 搬遷時做小幅調整以利用雲端功能 | 想快速獲得雲端好處但不大改 | Cloud SQL（取代自建 MySQL）、GKE |
| 重新架構 | Refactor (Re-architect) | 重寫應用以充分利用雲原生服務 | 長期投資、需要彈性與擴展性 | Cloud Run、Firestore、Pub/Sub |
| 替換採購 | Repurchase (Replace with SaaS) | 用 SaaS 取代自建系統 | 非核心業務系統 | Google Workspace、Looker |
| 淘汰退役 | Retire (Decommission) | 關閉不再需要的系統 | 冗餘或過時的應用 | — |
| 保留不動 | Retain (Keep on-premises) | 維持地端運行 | 法規限制、遷移成本過高 | Cloud Interconnect（混合連線） |
💡 考試小提示：PCA 題目常給你一個應用的特性（如「必須在 2 週內完成遷移」或「需要水平擴展至全球」），要你判斷該用哪種 R 策略。關鍵是辨別時間壓力和長期架構目標之間的權衡。
策略選擇的決策邏輯
選擇策略時，依序評估以下因素：
- 業務關鍵性 — 這個應用對營收影響多大？
- 技術債務程度 — 程式碼品質和可維護性如何？
- 遷移時間窗口 — 有多少時間可以完成？
- 團隊能力 — 團隊具備雲原生開發經驗嗎？
- 合規需求 — 資料有地域限制或產業法規嗎？
Migration Center：遷移的起點
Migration Center 是 Google 的統一遷移評估與規劃平台（整合了原本的 StratoZone 和 Migrate for Compute Engine 的評估功能）。它在遷移旅程中扮演三個關鍵角色：
- Discovery（發現） — 自動掃描地端環境，盤點所有伺服器、資料庫和應用的依賴關係
- Assessment（評估） — 分析每個工作負載的雲端適配度，產生遷移建議和風險報告
- TCO Analysis（總成本分析） — 比較地端維運成本與雲端成本，產出財務評估報告供決策者參考
💡 考試小提示：當題目提到「評估現有環境」或「規劃遷移」時，Migration Center 幾乎一定是正確答案。它取代了所有舊版的評估工具。
遷移工具鏈
根據遷移對象的不同，GCP 提供了專門的工具：
運算遷移
- Migrate to Virtual Machines — 將地端或其他雲端的 VM 遷移至 Compute Engine，支援最小停機時間的連續複製
- VMware Engine — 在 GCP 上運行原生 VMware 環境，適合大量 VMware 工作負載的 Lift & Shift，無需重新授權或修改應用
資料遷移
- Database Migration Service（DMS） — 支援 MySQL、PostgreSQL、SQL Server 到 Cloud SQL 或 AlloyDB 的持續複製遷移，幾乎零停機
- Storage Transfer Service — 從其他雲端（AWS S3、Azure Blob）或地端搬遷物件儲存資料至 Cloud Storage
- Transfer Appliance — 硬體設備，適合網路頻寬不足時搬遷 PB 級資料
- BigQuery Data Transfer Service — 自動化排程從 SaaS 平台（Google Ads、YouTube）或其他資料倉儲匯入 BigQuery
混合雲架構模式
實務上，純公有雲並非所有企業的終點。PCA 考試會考你對以下混合雲模式的理解：
| 模式 | 說明 | 典型場景 |
|---|---|---|
| 分層混合（Tiered Hybrid） | 開發/測試在雲端，生產在地端（或反之） | 漸進式遷移過渡期 |
| 分區多雲（Partitioned Multi-cloud） | 不同工作負載放在不同雲端 | 避免供應商鎖定、取各家之長 |
| 分析混合（Analytics Hybrid） | 資料留在地端，分析在雲端進行 | 資料主權限制但需要 BigQuery 分析能力 |
| 邊緣混合（Edge Hybrid） | IoT/邊緣裝置在地端收集資料，雲端進行處理和訓練 | 製造業、自駕車、零售門市 |
Strangler Fig Pattern：漸進式遷移的最佳實踐
Strangler Fig Pattern（絞殺者模式）是將單體應用逐步遷移至微服務的經典策略，名稱源自絞殺榕逐漸包覆宿主樹的生長方式：
- 識別邊界功能 — 挑選單體應用中相對獨立的模組（例如用戶認證、通知服務）
- 建立新服務 — 在 GCP 上用 Cloud Run 或 GKE 實作該模組的雲原生版本
- 路由切換 — 透過 API Gateway 或負載平衡器，將流量逐步從舊模組導向新服務
- 驗證與退役 — 確認新服務穩定後，關閉舊模組
- 重複循環 — 對下一個模組重複以上步驟
這個模式的核心優勢是風險可控——每次只遷移一小部分，失敗時可以快速回滾。
GKE Enterprise 與多雲管理
GKE Enterprise（前身為 Anthos）是 Google 的多雲與混合雲管理平台，讓你在地端、GCP、AWS 和 Azure 上統一管理 Kubernetes 工作負載：
- 統一控制平面 — 在 Google Cloud Console 集中管理所有叢集
- Config Management — 透過 GitOps 方式同步所有叢集的策略與配置
- Cloud Service Mesh — 基於 Istio 的全託管服務網格（原 Anthos Service Mesh），提供跨叢集的流量管理、可觀測性和 mTLS 安全性
什麼時候該用 GKE Enterprise？
- 需要在多個環境（地端 + 雲端）統一管理容器工作負載
- 已有大量 Kubernetes 投資，想要一致的管理體驗
- 需要跨環境的統一安全策略和可觀測性
如果工作負載只在 GCP 上運行，使用標準的 GKE 就夠了，不需要 GKE Enterprise 的額外成本。
混合連線選項概覽
混合雲架構需要穩定的網路連線。GCP 提供兩大連線方案（詳細內容會在 L08 網路架構課中深入探討）：
| 面向 | Cloud Interconnect | Cloud VPN（HA VPN） |
|---|---|---|
| 頻寬 | 10 Gbps - 200 Gbps | 最高 3 Gbps/通道 |
| 延遲 | 低且一致 | 依網際網路品質而定 |
| 加密 | 預設不加密（可加 MACsec） | IPsec 加密 |
| 成本 | 較高（月費 + 頻寬費） | 較低 |
| 適用場景 | 大量資料傳輸、延遲敏感 | 一般連線、備援通道 |
| 類型 | Dedicated / Partner | HA VPN（99.99% SLA） |
💡 考試小提示：題目出現「大量資料傳輸」或「低延遲需求」就選 Cloud Interconnect；「成本敏感」或「快速建立連線」就選 HA VPN。兩者可以並用——Interconnect 為主要連線，VPN 為備援。
實戰情境
情境一：傳統單體應用上雲
背景：一家醫療機構（類似 EHR Healthcare 案例）有一套 10 年歷史的病歷管理系統，運行在地端 VMware 環境，需要符合 HIPAA 合規。
架構決策：
- 第一階段：使用 VMware Engine 進行 Lift & Shift，快速搬遷至 GCP，確保業務不中斷
- 第二階段：採用 Strangler Fig Pattern，逐步將病歷查詢、預約排程等模組重構為 Cloud Run 微服務
- 資料遷移：使用 Database Migration Service 將 PostgreSQL 遷移至 Cloud SQL，零停機切換
情境二：多雲資料整合
背景：一家汽車製造商（類似 KnightMotives Automotive 案例）的 IoT 感測器資料散落在 AWS 和地端。
架構決策：
- 邊緣混合架構：工廠端的即時控制留在地端，資料透過 Cloud Interconnect 傳輸至 GCP
- 資料整合：使用 Storage Transfer Service 定期從 AWS S3 同步資料至 Cloud Storage
- 分析平台：所有資料匯入 BigQuery 進行跨來源分析和 ML 模型訓練
- 統一管理：透過 GKE Enterprise 管理地端和雲端的 Kubernetes 工作負載
情境三：資料中心整併
背景：企業需要在 18 個月內關閉兩座資料中心，搬遷 500 台 VM。
架構決策：
- 使用 Migration Center 完成全面盤點和 TCO 分析
- 核心業務系統：Replatform 至 Cloud SQL + GKE
- 穩定但低價值系統：Rehost 至 Compute Engine
- 冗餘系統：Retire 直接淘汰
- 使用 Transfer Appliance 搬遷 PB 級的歷史備份資料
重點整理
- 6R 策略框架是遷移規劃的基礎——根據時間、成本、技術債務選擇合適的策略
- Migration Center 是所有遷移專案的起點，提供發現、評估和 TCO 分析
- Strangler Fig Pattern 是單體應用漸進式遷移的最佳實踐，風險可控且可回滾
- 混合雲模式有分層、分區、分析、邊緣四種，根據業務需求選擇
- GKE Enterprise 適合多環境 Kubernetes 管理，純 GCP 環境用標準 GKE 即可
- VMware Engine 是 VMware 工作負載的快速上雲方案，在 PCA 考試範圍內
- 連線方案：大頻寬選 Interconnect，成本敏感選 HA VPN
下一步
在下一課中，我們將深入 VPC 網路架構與設計，包括 Shared VPC、負載平衡策略、Cloud Armor 防護與 Private Service Connect，這些是管理雲端基礎架構的核心網路知識。