GCP 雲端遷移簡介
遷移是一段旅程，而非單一事件。對於一位 Professional Cloud Architect 來說，規劃遷移需要深入了解源環境、目標 GCP 服務以及商業約束（停機時間、預算和風險）。
成功的遷移遵循 Google Cloud 遷移框架 (Migration Framework)：
- 評估 (Assess): 發現並分析當前環境。
- 規劃 (Plan): 建立登陸區 (Landing Zone) 並確定工作負載的優先順序。
- 部署 (Deploy): 遷移工作負載。
- 優化 (Optimize): 為雲端原生特性改進架構。
Google Cloud 上的統一平台，幫助您發現、評估並規劃從地端或其他雲端遷移到 GCP 的路徑。參考：https://cloud.google.com/migration-center/docs/overview
白話文解釋 遷移策略 (Migration Strategy)
搬到雲端通常被比作將全家搬到另一個城市的新房子。
類比 1 — 搬新家 (重新託管、重新平台化、重構)
- 重新託管 (Rehost/Lift and Shift): 您將所有東西原封不動地裝進箱子，搬到新家。速度很快，但您那些過時且低效的舊家具仍然佔用空間。
- 重新平台化 (Replatform/Lift and Optimize): 您搬動東西，但為新家購買了更高效的新暖氣系統。您保留了核心結構，但升級了關鍵組件。
- 重構 (Refactor/Modernize): 您賣掉了舊房子和家具，重新設計了一間智慧屋。工作量最大，但您能充分享受現代生活的便利。
類比 2 — 機場物流 (遷移波次 Migration Waves)
遷移就像是翻修一座繁忙的國際機場。您不能直接關閉機場一個月。您一次移動一個航廈（遷移波次）。您先從一個流量小、風險低的航廈（試點/沙盒）開始測試流程，等有信心後再移動主要樞紐。
類比 3 — 語言沉浸 (現代化)
將單體應用 (Monolithic App) 遷移到微服務就像是透過沉浸式學習一門新語言。您可以逐字翻譯（重新託管），但您不會說得流利。要真正從新文化中獲益（雲端原生），您需要改變思考和表達的方式（架構）。
在 PCA 考試中，如果目標是「最快遷移」且「程式碼改動最小」，答案通常是使用 Migrate to Virtual Machines 進行 重新託管 (Rehost)。參考：https://cloud.google.com/architecture/migration-framework
使用 Migration Center 進行遷移評估
在移動任何位元之前，您必須了解自己擁有什麼。
- 資產發現 (Inventory Discovery): 自動掃描 vSphere、Hyper-V 或實體伺服器。
- TCO 分析: 比較當前環境與 GCP 的成本。
- 資產映射: 了解應用程式與資料庫之間的依賴關係。
遷移模式：6 個 R
- 重新託管 (Rehost/Lift and Shift): 使用 Migrate to Virtual Machines 原樣遷移 VM。
- 重新平台化 (Replatform/Lift and Reshape): 遷移到託管服務，例如將自管 SQL 遷移到 Cloud SQL。
- 重構 (Refactor/Rewrite): 重新架構為微服務或無伺服器 (Cloud Run)。
- 重新購買 (Repurchase): 從授權軟體轉向 SaaS 等價物（如 Google Workspace）。
- 保留 (Retain): 由於延遲或合規性原因，將部分工作負載保留在地端。
- 停用 (Retire): 關閉不再需要的遺留系統。
資料遷移工具
移動資料通常是最大的瓶頸。
- Storage Transfer Service: 用於將大量資料從 S3、Azure Blob 或地端移動到 GCS。
- 資料庫遷移服務 (DMS): 用於將 MySQL、PostgreSQL 和 SQL Server 輕鬆遷移到 Cloud SQL 或 AlloyDB 的無伺服器工具。
- Transfer Appliance: 一種實體設備，用於在頻寬有限的情況下進行 PB 級遷移。
對於「最小停機時間」的資料庫遷移，請使用 DMS 提供的 CDC (異動資料擷取)，在最終切換前保持來源與目標同步。參考：https://cloud.google.com/database-migration-service/docs/overview
PCA 7 R's 決策捷徑：S3/Azure Blob/NFS 上的物件資料 → Storage Transfer Service（線上）或 Transfer Appliance（離線、PB 級、頻寬受限）；整台 VM → Migrate to Virtual Machines（Rehost 重新託管）；自管 MySQL/PostgreSQL/SQL Server → Database Migration Service 遷往 Cloud SQL/AlloyDB（Replatform 重新平台化）；可容器化的單體 VM → Migrate to Containers 目標為 GKE 或 Cloud Run（Refactor 重構）。
「Storage Transfer Service」和「Migrate to Virtual Machines」聽起來可以互換，其實不行。Storage Transfer Service 只能將物件/檔案搬到 Cloud Storage，無法啟動 VM、保留作業系統、或遷移掛在伺服器上的磁碟。如果情境保留完整的客體作業系統與應用程式（Rehost 重新託管），正解是 Migrate to Virtual Machines 遷入 Compute Engine，而不是 Storage Transfer Service。
最小停機時間規劃
停機就是金錢。策略包括：
- 藍綠部署 (Blue-Green Deployment): 同時運行新舊系統並切換流量。
- 階段性切換 (Phased Cutover): 小批量移動用戶。
- 資料庫同步: 使用複製技術確保切換期間不遺失資料。
工作負載優先級與波次 (Waves)
不要一次移動所有東西。
- 第 0 波 (登陸區): 設置 VPC、IAM 和共享 VPC。
- 第 1 波 (試點): 簡單、低風險的 App，用於測試流程。
- 第 2 波 (擴展): 商業關鍵但複雜度較低的 App。
- 第 3 波 (困難部分): 複雜的單體架構和遺留資料庫。
授權流動性與成本管理
- 自備授權 (BYOL): 在 GCP 上使用現有的 Windows 或 SQL Server 授權（通常需要專屬節點 Sole-Tenant Nodes）。
- 包含授權 (License-Included): 作為 VM 成本的一部分支付授權費用。
- 承諾使用折扣 (CUDs): 透過承諾 1 年或 3 年的使用量來降低成本。
遷移後驗證與測試
- 性能基準測試: 應用程式在雲端是否與在地端一樣快？
- 安全審計: 防火牆規則和 IAM 政策是否正確？
- DR 測試: 容錯移轉在新環境中是否有效？
遷移遺留資料庫
遺留資料庫通常具有專有特性。
- Oracle 轉 Bare Metal Solution: 適用於無法輕鬆遷移到 Cloud SQL 的情況。
- SQL Server 轉 Cloud SQL: 使用 DMS 獲得託管體驗。
- Spanner: 適用於全球性、可水平擴展的關聯式需求。
單體架構現代化
最終目標通常是「雲端原生」。
- 絞殺者模式 (Strangler Fig Pattern): 逐漸用微服務替換單體架構的部分組件。
- 容器化: 使用 GKE 或 Cloud Run 提高便攜性和擴展性。
當 PCA 情境寫到「將這個 Linux/Windows VM 工作負載現代化為容器，且不重寫應用程式」，預期答案是 Migrate to Containers（前稱 Migrate for Anthos） 目標為 GKE（無狀態服務則為 Cloud Run），而不是 Migrate to Virtual Machines（那是 Rehost 而非現代化），也不是完整 Refactor 重寫。參考：https://cloud.google.com/migrate/containers/docs/concepts/overview
FAQ — 遷移策略與規劃
Q1. "Migrate to Virtual Machines" 和 "Storage Transfer Service" 有什麼區別？
Migrate to Virtual Machines 用於將整個 VM 映像（作業系統 + 應用程式）移動到 Compute Engine。Storage Transfer Service 用於將文件和對象移動到 Cloud Storage。
Q2. 我該如何選擇重新託管 (Rehosting) 還是重構 (Refactoring)？
追求速度和低風險時選擇重新託管。為了長期的擴展性、成本效益以及利用自動擴展等雲端原生特性時選擇重構。
Q3. 什麼是「登陸區」(Landing Zone)？
登陸區是基礎的 GCP 環境（VPC、資料夾、IAM、日誌），已根據最佳實踐預先配置，以便安全地接收遷移的工作負載。
Q4. 如何透過 100Mbps 的連接移動 100TB 的資料？
透過 100Mbps 傳輸 100TB 需要數月時間。在這種情況下，請使用 Transfer Appliance 將資料實體運送到 Google。
Q5. 什麼是「遷移後優化」？
這是在初始遷移後，透過調整 VM 大小、實施自動擴展以及切換到託管服務，進一步降低成本和維運開銷的階段。
最終架構師提示
遷移中最大的失敗不是技術問題，而是缺乏發現 (Discovery)。在評估 (Assess) 階段花費的時間應該比您預想的更多。使用 Migration Center 揭示隱藏的依賴關係，否則您會在切換期間以痛苦的方式發現它們！