ACE 情境題拆解

保留既有平台是合理的，但這個選項沒有處理重複商品讀取的快取需求，也沒有安排活動前的容量驗證。升級資料庫能否支撐負載仍要量測，不能把單一機型升級當成完整擴展策略。

這需要更換運算平台與關聯式資料模型，與活動前沿用 Compute Engine、MySQL 並降低遷移風險的要求不符。Cloud Run 與 Firestore 可以用於其他設計，但本題沒有要求重做平台。

沒有依壓力測試決定容量，也沒有處理讀取瓶頸或自動縮減。固定開啟大量 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 Run functions，原 Cloud Functions）的冷啟動延遲不適合即時對戰的低延遲需求。

直接把全部正式 VM 改為可中斷的 Spot，再將資料庫縮到小規格，沒有使用率、故障恢復或負載證據，無法支持不影響品質的要求。Spot 可作合適工作負載的候選，但不能只憑折扣批准本題的全面變更。

題目沒有硬體專用、授權或隔離需求，也未提供可證明 Sole-tenant 更省的使用率與估價。不能把專用主機當成通用的成本折扣方案；仍須先比較需求與完整成本。

題目未提供應用介面、資料模型與遷移成本，不能證明全部服務都適合這次改造。免費額度也不是整體成本保證。應先定位主要成本與可驗證的改善，再評估是否值得遷移。

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

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

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

把所有步驟綁在單次函式呼叫，不利於獨立重試、分派容量與追蹤每個轉檔步驟。若透過 Functions v2 API 建立事件函式，還有最長 9 分鐘的限制；其他部署與觸發方式須另查 timeout。函式內可以寫並行程式，但不會因此自動得到三個可獨立管理的工作；本題的 Workflows + Cloud Run Jobs 更直接符合分派與狀態追蹤需求。

輪詢（polling）模式效率低，影片要等下一輪掃描才開始處理。單一 VM 依序轉檔，無法平行處理三種解析度，固定規格也應付不了上傳量波動。單點故障風險高，VM 掛掉整條管線就停擺，記在本機的進度也跟著查不到。

Dataflow 擅長的是資料（數據）的串流處理和批次 ETL，不是影片轉檔。影片轉檔需要的是運算密集型的容器作業，不是資料管線。Dataflow 的作業監控呈現的是整條管線與各步驟的狀態，也不是每支影片的處理進度。工具選擇不對。

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

BigQuery Storage Write API (REST)（原 legacy 串流寫入 tabledata.insertAll）成本高（每 GB $0.05），10 萬筆/秒的寫入費用驚人。Scheduled Query 是排程查詢，最短間隔 5 分鐘，無法達到 5 秒內的即時告警需求。

Kafka on GKE 得自己維運 Kafka 和 GKE，Spark 這段雖然是託管服務，全年不停的串流作業通常得放在長駐叢集上、自己開叢集管叢集（serverless 部署的單一批次工作最長 14 天），而且叢集的自動擴縮不支援 Spark Structured Streaming，管理負擔比 Pub/Sub + Dataflow 這種全託管組合大。路徑裡也沒有即時告警和儀表板的環節，結果先寫進 Cloud Storage 再進 BigQuery，看不出怎麼在 5 秒內告警。除非有特殊需求（如既有 Kafka 生態整合），否則不應選擇此方案。

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

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

搬遷本身最單純，也符合 ERP 不能改動的限制；但 20 台伺服器全部照搬成 VM，上雲後每一台仍要自行修補與維運，不符合降低維運負擔的要求，也用不到自動擴展、按量付費這些雲端特性。內部網站和檔案伺服器可以改用 Cloud Run、Filestore 這類代管服務。

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

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

Firebase 專案本身就是 Google Cloud 專案，問題不在 Firebase，而在架構：每個團隊的開發、測試與正式環境共用同一個專案，做不到環境完全隔離；專案直接放在 Organization 底下、沒有 Folder 分層，也無法依區域或環境分別套用政策。

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

Cloud Run 的 GPU 支援已正式推出（GA），也能用 revision 流量分配做 A/B testing，所以這是可行的方案。但載入 2GB 模型會拉長冷啟動，要設定最小執行個體保持暖機才守得住 200ms（閒置時仍按全額計費）；GPU 配額也要先申請。模型註冊、版本管理與線上推論監控都得自建，在這題需要這些功能的條件下，營運負擔高於 B。

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