Google PCA: 遷移、現代化與混合雲策略 — 學習指南

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

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

一個成功的遷移、現代化與混合雲策略，會將平台選擇與業務成果對齊，同時管理可用性、資料完整性、延遲、安全性與成本的風險。這個路徑會在快速的 rehost (直接遷移) 以降低資料中心風險，以及針對性的 refactor (重構) 以獲取雲端效益之間取得平衡。營運模式必須與技術一同演進，才能維持持續的改進。本節為評估與分批規劃、決策框架、遷移機制、混合雲整合、現代化模式、政策與多雲考量，以及遷移後優化，提供了一個務實的藍圖，並特別強調失敗模式與權衡取捨。

評估、整備與分批規劃

• 探索與相依性分析

  • 盤點工作負載、版本、作業系統核心、儲存、IAM 與資料分類。繪製出跨 web→API→DB 流程、共享服務 (LDAP/AD, DNS, NTP)、批次處理管道與外部 API 的相依性地圖。
  • 在遷移前的環境中使用應用程式剖析與分散式追蹤，以揭露隱藏的相依性與長尾延遲。開啟 VPC Flow Logs 與應用程式層級的檢測工具 (Cloud Logging, Cloud Monitoring, Cloud Trace)。
  • 識別狀態邊界與資料引力：規模大小、存取模式 (讀寫混合比例)、一致性期望與複寫拓撲。

• 整備與技能

  • 評估雲端基礎、IaC、CI/CD、SRE、安全性、網路與資料庫技能。定義一個基於角色的訓練與認證路線圖，並為技能提升和影子 on-call (shadow on-calls) 安排時間預算。
  • 在第一批遷移開始前，建立一個 landing zone (包含 projects、folders、Shared VPC、組織政策、稽核匯出點、CMEK 策略)。

• 遷移分批規劃

  • 根據關聯性與爆炸半徑將應用程式分批：共享資料、同步相依性與變更時間窗。將高風險的相依項目拉到同一個批次中，或用定義明確的 API 合約來建立樁腳 (stub)。
  • 為每一批次定義 SLOs、RTO/RPO、回滾標準與驗證關卡 (schema 檢查、綜合使用者旅程、效能閾值)。
  • 準備 runbook (執行手冊) 與變更管理：切換步驟、檢查點、回滾，以及為簽核收集證據。

• 相容性、授權與效能基準線

  • 驗證 Compute Engine 與託管服務中對作業系統和中介軟體的支援。檢查商業授權條款、BYOL 限制、核心模組需求與硬體親和性。
  • 擷取 CPU、記憶體、IOPS、吞吐量與延遲的基準線，包含峰值與第 95 百分位數值，以規劃目標資源的規模並驗證效益。

• 資料治理

  • 對 PII/PCI 資料進行分類。規劃在擷取資料時使用 Cloud DLP 進行去識別化或權杖化。在儲存第一筆生產環境日誌之前，定義好稽核、保留與匯出政策。

常見失敗模式：未知的同步相依性在切換後導致連鎖超時；重疊的 IP 範圍阻擋了連線；授權合規性差距；缺乏回滾對等性，導致資料變動無法被復原。

遷移模式、資料移動與切換

• 決策框架 (6R)

  • Rehost (重新託管)：維持原樣搬遷至 Compute Engine。上雲時間最快，變更最少。風險：會帶來技術債與規模配置效率不彰的問題。
  • Replatform (重新平台化)：進行小幅變更以採用代管服務 (例如 Cloud SQL、Cloud Load Balancing)。以低程式碼變更的代價，更快獲得維運效益。
  • Refactor (重構)：為 GKE/Cloud Run 進行拆解或容器化；採用事件驅動模式。長期效益最高，但有交付風險。
  • Retire (汰除)：在確認使用率與相依性皆不存在後，汰除未使用的系統。
  • Retain (保留)：基於法規或延遲考量而保留在地端；透過混合雲進行整合。
  • Relocate (重新遷移)：將 vSphere 工作負載搬遷至 Google Cloud VMware Engine；保留既有工具並將變更降至最低。

• 運算與資料庫遷移工具

  • Migrate to Virtual Machines 可加速 Rehost 遷移至 Compute Engine 的過程，同時保留磁碟與網路設定。需驗證客體作業系統的支援性與核心驅動程式。
  • Database Migration Service 提供同質資料庫 (例如 MySQL、PostgreSQL) 到 Cloud SQL 的線上複製，停機時間極短。需確保 binlog/複製設定正確，且網路延遲能支援近乎即時的資料追趕。
  • 選擇符合工作負載的資料庫：
    • Cloud SQL 適用於代管式關聯資料庫需求；啟用自動儲存空間擴增，並監控每個核心的 CPU 使用率是否接近 75%；追蹤複製延遲，若接近閾值則進行分片或擴展規模。
    • Bigtable 適用於低延遲、高吞吐量的時間序列資料擷取 (例如感測器資料)。
    • Spanner 適用於全球規模與強一致性；需了解其廠商鎖定與可攜性之間的權衡。
  • 資料移動
    • Storage Transfer Service 適用於持續性或排程傳輸；具備平行化與重試機制。
    • Transfer Appliance 適用於大量 (數十到數百 TB) 的一次性載入，以減少網路傳輸時間與風險。
    • gsutil 與平行複合上傳適用於中小型資料集。

• 線上與離線遷移

  • 線上：持續複製搭配短暫的切換時間。優點：停機時間最短；缺點：需要穩定的延遲與頻寬；需謹慎避免雙寫問題。
  • 離線：快照與大量匯入。優點：簡單且可預測；缺點：停機時間等於複製所需的時間。

• 切換規劃、復原與停機時間控制

  • 在切換前幾天降低 DNS TTL，凍結非必要的變更，並安排維護時段。
  • 執行驗證關卡：schema 一致性、總和檢查碼或資料列計數、應用程式煙霧測試、金絲雀流量與效能探測。
  • 復原：確保 schema 變更具備向下相容性、使用功能旗標，並保留真實來源資料。在穩定性被證實前，避免不可逆的寫入操作。
  • 以最短停機時間擴展 VM 磁碟的範例：
    • 在 Console 或 CLI 中調整磁碟大小：

undefined

- 在 Linux ext4 上：

undefined

• 對 GKE 進行影響最小的滾動式應用程式更新：

undefined

常見的失敗模式：透過 Cloud VPN 傳輸時發生封包遺失，導致資料庫複製中斷 (應使用 Dedicated Interconnect 或 Partner Interconnect)、切換期間發生雙寫資料分歧、缺少健康狀態檢查導致滾動式更新停滯。

混合身分、連線能力與地端整合

• 身分識別

  • 保留 Active Directory 作為真實來源。使用 Google Cloud Directory Sync 進行帳號與群組同步，並設定 SAML SSO 讓使用者存取 Google Cloud。
  • 透過角色授予最小權限 IAM，為工作負載使用服務帳號，並優先選擇 Workload Identity Federation 而非長期有效的金鑰。

• 混合連線與路由

  • 初期的低吞吐量需求與測試可使用 Cloud VPN；若需持續性的頻寬、更低的延遲與可預測的複製效能，則應改用 Dedicated Interconnect。部署備援的 VLAN attachment 與 HA VPN 或雙 Interconnect 以提高彈性。
  • 確保 Google Cloud 的 IP 範圍不與地端 CIDR 重疊，以維持端到端的連線能力。

  • 使用防火牆規則與標籤來強制執行分層存取。僅允許 web→API 的範例如下：

undefined

• 使用 Private Service Connect 與 private Google access 進行服務對服務的通訊，無需透過公用出口；在適當情況下，使用 VPC Service Controls 進行區隔。

• 混合式 DNS：使用 Cloud DNS 搭配轉送以及輸入/輸出政策，來解析地端與雲端的名稱。

• 地端整合與延遲

  • 讓狀態與運算資源彼此靠近，反之亦然；如果地端資料庫必須維持為權威來源，可考慮使用 App Engine flexible 或 Compute Engine 搭配 Cloud VPN/Interconnect 進行私有存取。
  • 導入快取與佇列來解耦同步路徑並吸收延遲抖動；測量 p95/p99 延遲，而不僅是平均值。

常見的失敗模式：CIDR 重疊導致路由被阻擋、BGP 會話備援不足、公用 DNS 或出口流量洩漏導致私有服務被暴露、未預期的多話協定在高延遲鏈路上效能不佳。

現代化、營運模式與最佳化

• 傳統系統現代化模式

  • 絞殺榕模式 (Strangler fig)：在單體式架構前放置一個 API 門面 (facade)，並將各個領域 (domain) 漸進式地路由到新的服務。
  • 容器化：標準化基礎映像檔（若相容，優先選擇如 Alpine 等輕量級映像檔）、調整 Dockerfile 圖層順序以在複製原始碼前快取相依套件的安裝，藉此縮短建置時間，並採納具備自動化預備環境 (staging) 測試的 CI/CD 管線。
  • 託管資料：將營運資料庫移轉至託管資料庫；依據各領域需求選擇：Cloud SQL 用於交易型工作負載、Bigtable 用於時間序列資料、Spanner 用於全域一致性工作負載。

• 應用程式相容性、一致性與效能驗證

  • 確認作業系統和中介軟體支援、執行緒和連線限制，以及檔案系統語意。驗證授權的可攜性與用量計費方式。
  • 定義資料一致性需求（讀取己寫、單調讀取、最終一致性 vs. 強一致性）。使其與目標資料庫和存取模式對齊。
  • 透過負載測試和綜合使用者歷程來驗證效能；確保遷移後 SLO 預算仍可達成。

• 可觀測性與合規性

  • 使用 Cloud Logging、Monitoring 和 Trace 來檢測應用程式，以定位跨微服務的延遲問題。
  • 將稽核日誌和 IAM 政策變更匯出至 BigQuery，並透過視圖 (view) 和資料集層級的 IAM 與稽核人員共享。將長期指標匯出至 Cloud Storage，以滿足多年的保留要求。

• 營運模式與權責歸屬

  • 採納 SRE 實務：SLO、錯誤預算、事件應變和無咎責的事後檢討 (blameless postmortems)。定義服務的權責歸屬、操作手冊 (runbook) 和待命輪值表。
  • 使用 IaC (例如 Terraform) 來一致地配置基礎架構。請注意，Deployment Manager 是 Google 專屬的，可能會限制多雲資源的自動化，且許多工程師對其不熟悉。
  • 透過 Organization Policy、IAM Conditions、Config Sync 和 Policy Controller (OPA Gatekeeper) 在跨專案和環境中自動化政策的一致性。

• 多雲策略與鎖定權衡

  • 透過 Kubernetes、12-factor app 實務、OpenAPI 定義的合約以及資料出口抽象化來提高可攜性。在可攜性與營運負擔及效能之間取得平衡；託管服務可減少繁瑣工作，但可能會增加轉換成本。

• 成本與效能最佳化；除役

  • 使用託管執行個體群組 (MIG) 和自動擴展來擴展無狀態的 Compute Engine；對於能從「縮減至零」中獲益的突發性或 MVP 工作負載，選擇無伺服器方案（Cloud Functions 或 Cloud Run）。
  • 適當調整 VM 規模、在 GKE 上啟用自動擴展、應用承諾使用折扣 (CUD)，並除役未使用的產物。透過 KPI（可用性、延遲、服務成本）追蹤效益實現情況。
  • 在地端系統經過一段冷卻期並確認相依性後，將其除役。根據保留政策封存或刪除資料，並更新 CMDB。

實務問題情境

Acme Weather Networks 必須將其即時感測器平台和一個舊有的 J2EE 管理 UI 從地端資料中心遷移到 Google Cloud。該系統每秒從 50,000 個感測器擷取 10 筆讀數，並儲存五年份的歷史資料（75 TB）。在過渡期間，它必須維持對地端 ERP 和 Active Directory 的私有存取，將地端 MySQL 資料庫的停機時間降至最低，並消除透過 VPN 觀察到的間歇性複寫失敗問題。

1. 建立一個安全的落地基礎區 (landing zone)

   • 建立組織、資料夾以及生產/非生產專案。設定一個 Shared VPC，其 IP 範圍不與地端重疊，以確保可透過混合式連線觸達地端。套用組織政策，並將稽核日誌集中匯出至 BigQuery，同時設定最低權限存取。
   • 理由：在工作負載進駐前，預防路由衝突並強制執行基礎的治理原則。

2. 實作混合身分

   • 設定 Google Cloud Directory Sync 以鏡像 AD 的身分和群組，並設定 SAML SSO。為平台和工作負載使用服務帳戶和 IAM 自訂角色。
   • 理由：保留企業身分作為信任來源，並實現最低權限存取控制。

3. 配置連線能力並規劃效能

   • 開發/測試階段先使用 HA Cloud VPN。對於生產環境的資料庫複寫和穩定的感測器資料擷取，則配置 Dedicated Interconnect，並搭配雙 VLAN attachment 和 BGP 會話。
   • 理由：Interconnect 比 VPN 提供更低的延遲和更少的封包遺失，能穩定 MySQL 複寫和串流擷取。

4. 高效率地搬移歷史資料

   • 訂購 Transfer Appliance，在地端載入 75 TB 的資料集，運送後再將資料還原至 Cloud Storage。若有需要，可使用 Storage Transfer Service 進行持續的增量更新。在將支援日誌存入 Bigtable 或 BigQuery 之前，先用 Cloud DLP 進行處理以去除 PII（個人識別資訊）。
   • 理由：離線大量傳輸可降低系統切換期間的風險，並避免佔滿線路頻寬。

5. 將 J2EE 管理 UI 直接遷移 (Rehost)

   • 使用 Migrate to Virtual Machines 將 J2EE VM 直接遷移 (lift-and-shift) 至 Compute Engine。將執行個體放置在一個託管執行個體群組中，並置於 HTTP(S) 負載平衡器之後。透過標籤 (tag) 套用防火牆規則，以強制執行僅限 web→API→DB 的流量走向。例如：

undefined

• 理由：在熟悉的執行環境中快速降低風險，同時強制執行最低權限的網路路徑。

6. 以最短停機時間將 MySQL 遷移至 Cloud SQL

   • 在來源端建立效能基準並啟用二進位日誌 (binary logging)。使用 Database Migration Service 設定對 Cloud SQL 的持續複寫。啟用儲存空間自動增加功能，並建立 CPU 接近 75% 和複寫延遲低於 60 秒的警示。
   • 理由：線上遷移可實現低停機時間；託管 SQL 可減少繁瑣工作並強制執行營運 SLO。

7. 執行受控的系統切換

   • 在 48 小時前降低 DNS TTL，凍結結構描述變更，並安排維護時段。停止地端的寫入操作，確保 DMS 延遲為零，執行校驗和 (checksum) 與應用程式冒煙測試，然後將用戶端指向 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，並分享限定稽核人員範圍的視圖。將長期指標匯出至 Cloud Storage，以滿足五年的保留要求。
    • 理由：全保真的遙測資料可支援 SLO 和合規性要求。

11. 最佳化與除役

    • 在 MIG 和 GKE 上啟用自動擴展、適當調整執行個體規模、應用承諾使用折扣，並將非 24x7 的工作負載（例如輔助性任務）安排在無伺服器平台上（如 Cloud Functions）以實現縮減至零。在系統穩定並經過一段冷卻期後，除役地端系統，更新 CMDB，並公布已實現的效益。
    • 理由：在消除雙重運營成本的同時，獲取成本和營運效率。

12. 落實營運與訓練

    • 完成操作手冊、RACI、待命輪值表和 SLO/錯誤預算的定案。提供目標明確的訓練和認證計畫以彌補技能差距。優先使用 Terraform 進行 IaC；注意 Deployment Manager 是 Google 專屬的，可能無法處理非 Google 的資源。
    • 理由：成熟的營運模式能在遷移事件結束後，持續維持系統的可靠性和開發速度。

← 可靠性、災難復原與業務連續性 · 所有領域 · 維運、可觀測性與平台自動化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →