ACE 情境題拆解

MIG + Autoscaler 方向正確，但 Cloud SQL 單純升級機型無法處理 10 倍流量的讀取壓力。缺少讀取副本和快取層，資料庫仍會成為瓶頸。

Cloud Run 的擴展速度很快，但將現有 MySQL 應用遷移到 Firestore (NoSQL) 是一個重大的資料模型改造，在黑色星期五前不切實際，風險過高。

手動擴展缺乏彈性，無法精確預測所需容量，且活動期間流量波動大。固定數量的 VM 可能過多（浪費成本）或過少（服務中斷），不符合雲原生思維。

預設 Google 管理的加密金鑰不符合「公司自行管理金鑰」的合規要求。金管會要求的是 CMEK 或 CSEK，不能使用預設加密。

Cloud Logging 預設只保留 30 天（_Default bucket），遠不符合 7 年的要求。此外，Cloud SQL 的磁碟加密預設是 Google-managed key，需要額外設定 CMEK。

CSEK 雖然提供最高控制權，但金鑰管理負擔極大（不支援自動輪換、遺失金鑰等同資料永久遺失），且 CSEK 僅支援部分服務。對多數金融場景，CMEK 是更平衡的選擇。

各區域獨立的 Cloud SQL 無法提供全球強一致性，應用層同步容易造成資料衝突和延遲。排行榜資料可能出現不同區域看到不同結果的情況。

CDN 只能加速靜態資源，無法降低即時對戰的後端 API 延遲。單區域叢集對海外玩家仍然有高延遲問題。Memorystore 也不支援全球自動複製。

Firebase Realtime Database 是最終一致性模型，無法滿足排行榜的強一致性要求。且 Serverless 架構（如 Cloud Functions）的冷啟動延遲不適合即時對戰的低延遲需求。

Preemptible/Spot VM 隨時可能被回收，用在正式環境會影響可用性。Cloud SQL 降級到 db-f1-micro 效能太差，直接影響用戶體驗。這個方案犧牲了品質。

遷移到 Cloud Run 和 Firestore 需要重大的應用改造成本（時間和人力），且 Firestore 免費額度有限，超過後成本未必更低。對新創而言，大規模重構不是最經濟的做法。

Sole-tenant Node 是為了合規需求（如 BYOL 授權、隔離要求）而設計，成本反而比一般 VM 更高。這完全是反向操作，會讓帳單更貴。

單一專案內只靠 IAM 區隔不夠嚴謹。資源共用同一專案容易發生設定錯誤導致跨院存取，且合規稽核時難以明確劃分資料邊界。不符合醫療資料隔離的最佳實踐。

5 個獨立 Organization 管理成本極高，無法統一安全政策，也無法共用稽核基礎設施。跨院會診的實作會變得極為複雜，且 Organization 的建立需要獨立的 Workspace/Cloud Identity。

Firestore Security Rules 主要設計給前端直連場景（如行動 App），不適合作為企業級的病歷系統存取控制。且 Security Rules 無法提供合規等級的稽核能力，也缺乏 VPC 層級的網路隔離。

單一 Cloud Function 處理所有步驟會遇到執行時間限制（第 1 代 9 分鐘、第 2 代 60 分鐘），影片轉檔通常需要更長時間。且無法平行處理三種解析度，整體效率低下。

輪詢（polling）模式效率低，固定規格 VM 無法應對上傳量波動。單點故障風險高，VM 掛掉整條管線就停擺。且沒有內建的內容審核能力。

Dataflow 擅長的是資料（數據）的串流處理和批次 ETL，不是影片轉檔。影片轉檔需要的是運算密集型的容器作業，不是資料管線。工具選擇不對。

Cloud IoT Core 已於 2023 年停用。Cloud SQL 不適合處理每秒 10 萬筆的高頻寫入。Cron 輪詢無法在 5 秒內偵測異常。這個方案在多個環節都有根本性問題。

BigQuery Streaming Insert 成本高（每 GB $0.05），10 萬筆/秒的寫入費用驚人。Scheduled Query 是排程查詢，最短間隔 15 分鐘，無法達到 5 秒內的即時告警需求。

自建 Kafka + Spark 的管理負擔極大，需要專人維護。GCP 已有 Pub/Sub + Dataflow 這樣的全託管替代方案，功能相同但營運成本更低。除非有特殊需求（如既有 Kafka 生態整合），否則不應選擇此方案。

將 ERP 系統重構為微服務違反了「不能做任何改動」的要求，且 6 個月內完成 20 台伺服器的全面重構不切實際。風險過高、時間不夠。

雖然最快最保險，但 Lift-and-Shift 所有系統意味著無法享受雲原生的好處（自動擴展、按量付費）。內部網站和檔案伺服器其實可以用更適合的雲原生服務，長期成本和維運更優。

平行運行意味著 3 個月的雙倍成本（機房 + GCP），且需要解決資料同步問題（特別是 ERP 和資料庫）。資料一致性風險高，ERP 的資料同步尤其困難。

單一專案無法實現真正的環境隔離和權限分離。Labels 只是標記，不能阻止開發者存取正式環境的資源。一個團隊的失誤可能影響所有人。

12 個團隊 12 個 Organization 管理成本極高。跨 Organization 的 VPC Peering 設定複雜，且無法統一安全政策。每個 Organization 需要獨立的 Workspace/Cloud Identity，身份管理碎片化。

Firebase 專案底層雖然是 GCP 專案，但 Firebase 主要為行動和 Web 應用設計，不適合作為企業級的組織架構管理方案。缺乏 Folder 層級的階層管理和 Organization Policy 的支援。

自建 GPU VM 的管理負擔大（driver 版本、CUDA 相容性），手動擴展無法應對 50 倍的流量波動。模型版本管理和 A/B testing 都需要自行實作，開發成本高。

Cloud Run GPU 支援仍在演進中，且冷啟動載入 2GB 模型可能需要數十秒，無法保證 200ms 的延遲要求。Cloud Run 目前的 GPU 支援不如 Vertex AI Prediction 成熟，缺乏原生的 A/B testing 流量分割功能。

GKE + GPU 技術上可行，但需要自行管理 Kubernetes 叢集、GPU driver DaemonSet、HPA 設定、Istio 配置等。對於單一模型的部署來說，營運複雜度過高。除非公司已有成熟的 K8s 團隊，否則 Vertex AI 是更好的選擇。