案例實戰：架構設計工作坊

這課怎麼做？

這是本站原創的 CloudMart 合成演練，不是 Google 官方案例或唯一標準答案。先下載工作紙，寫下第一輪初稿，再用六張證據卡修訂決策，最後交付四份成果。若還不熟悉需求、遷移與 ADR，可先讀八步示範。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

可分兩次完成；前置補讀與真正部署演練另計。這一課只做文件與資料判讀，不需雲端帳號，不會代你建立資源、切換資料庫或核准上線。若需求分析、SLO 或 DR 還不熟，先回需求分析、可觀測性與 SRE或高可用與災難復原補強。

先準備一份可以修訂的工作紙

，用自己的編輯器填寫。工作紙帶有本輪事實、目標、全部證據與四份空白交付區，不含下方的參考判讀；先保留初稿，再新增修訂理由。

也可在架構師設計工作坊自行建立一份草稿，或寫在自己的文件裡。下載與閱讀不會替你新增、匯入或覆寫既有工作坊答案；本站課程筆記適合記錄待查事項，四份交付物請自行保存。

工作坊要交付的不是一張漂亮架構圖

這次練習要產出四樣東西：

1. 可驗證的 requirement／constraint matrix。
2. 至少兩個候選方案與 trade-off。
3. 一份寫清楚理由、假設和後果的 ADR。
4. Migration 與 production validation plan。

考試不會要求你真的提交這些文件，但這套思路能幫你看出選項少說了什麼。Architecture diagram 只能顯示元件，無法代替一致性、failure、security 和 operation semantics。

模擬案例：CloudMart

CloudMart 是總部位於台灣的 online retailer，目前服務台灣與部分東南亞客戶，計畫在 18 個月內進入更多亞太市場，之後評估歐洲。

現況

• Java monolith 跑在地端 VMware，部分 HTTP service 已能 containerize。
• 單一 MySQL 8.0，約 2 TB，order、inventory 和 catalog 共用 schema。
• Product image 放在 NAS，分析資料每天夜間 ETL。
• 每月人工發布一次，回滾需由 DBA 與 application team 協調。
• 團隊熟悉 Java、SQL 和 Docker，只有少數人維護過 Kubernetes。
• 促銷尖峰約為平日 10 倍，最近一次因 database connection 耗盡而停止結帳。

管理層提出的目標

• 台灣與東南亞使用者「都要很快」。
• 促銷期間不能再停止結帳。
• Inventory 不可超賣。
• 半年後開始提供個人化推薦。
• 未來進入歐洲時要符合 privacy 與 data-residency 要求。
• 不希望一次重寫整套系統，也不能中斷現有營運。

注意，這些句子還不能直接選服務。「很快」沒有 percentile；「不可超賣」沒說 reservation workflow；歐洲的實際資料落地義務也尚未由 legal 確認。

第一輪：先寫初稿，保留未知

先不採用後面的範例 ADR。用上面的案例寫至少六列需求／限制，將每列標為「事實、目標、假設、未知」，並列出負責人與取得證據的方法。管理層說「很快」時，不能自行填入已核准的數值。

接著提出至少兩個 Phase 1 候選，列出相容性、容量、資料一致性、失敗處理、團隊與成本的待驗證條件。先將 ADR 狀態設為 Proposed／待驗證，寫下目前傾向與何時會改變決策。

保存這份初稿，再看八步示範或直接進證據回合。先寫出的答案可以不完整；要保留的是未知與推翻條件，不是堅持第一次選的產品。

第一步：把事實、目標、假設分開

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

考試題通常會把 unknown 補成明確條件。在真實工作中，架構師不能擅自把它們變成需求。

flowchart TD
  A["案例中的一句陳述"] --> B{"它是哪一類？"}
  B -->|"Fact"| F["量測、盤點<br/>建立 current baseline"]
  B -->|"Outcome"| O["定義 KPI／SLI<br/>與 business owner"]
  B -->|"Constraint"| C["成為方案篩選條件<br/>不能被最佳化掉"]
  B -->|"Unknown"| U["找 owner 確認<br/>不擅自補答案"]
  B -->|"Assumption"| P["設 spike／PoC<br/>定義失敗條件"]
  F --> R["Requirement／constraint matrix"]
  O --> R
  C --> R
  U --> R
  P --> R
  R --> V["每一列都有範圍、數值<br/>owner 與驗證方式"]

先問這些問題

• 哪個 user journey 最重要：browse、add to cart、checkout 還是 order tracking？
• Latency 是 client-observed 還是 server-side，在哪個 region、哪個 percentile？
• Inventory 是看到的數量不能過時，還是確認訂單時不能超賣？Reservation 可保留多久？
• Payment 已成功但 order commit timeout 時，如何 reconciliation？
• 可接受多少 downtime 和 data loss？各流程是否不同？
• 哪些資料屬於個資？Legal 要求是儲存地、處理地，還是跨境 transfer control？
• Peak traffic 的 request mix、duration、payload 與 database write ratio 是多少？
• VMware lease、license、network bandwidth 和 migration deadline 有沒有硬限制？

第二步：把需求寫成可測試條件

假設 stakeholder 確認後，得到以下 initial target：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這些數字只是本工作坊假設，不是通用建議。真正價值是每個目標都有 measurement。

第三步：不要把 target architecture 當第一個 migration step

CloudMart 需要兩條時間線：先移除 data-center／capacity risk，再逐步調整 application boundary。

Phase 0：盤點與建立 baseline

• 用 dependency discovery、traffic capture、query analysis 和 cost model 了解現況。
• 先補 application／database telemetry，量 peak、connection、slow query、failure 和 batch window。
• 建立 landing zone、identity、network、logging、budget 和 policy guardrail。
• 驗證 migration throughput、database compatibility、rollback 與 cutover window。

Phase 1：先搬可搬的，不承諾全面微服務化

若 monolith 能以 container 執行，候選 compute 包括：

• Cloud Run：適合 HTTP-driven、stateless、能配合 request／instance lifecycle 的 workload，團隊 operation 負擔較低。
• GKE Autopilot／Standard：明確需要 Kubernetes API、特定排程／叢集網路或 workload control 時再評估，並分別核對兩種模式的限制。
• Compute Engine MIG：若 application 對 VM、OS、filesystem 或 legacy agent 有相依，可能是期限內風險較低的 rehost step。

不能只因「核心交易很重要」就選 GKE，也不能只因「Cloud Run 是 serverless」就忽略 long-running process、local state、connection 和 scaling behavior。先用 application assessment 排除不相容項。

Phase 2：逐步建立 service boundary

從變更頻率高、domain boundary 清楚且能獨立驗證的能力開始，例如 product catalog read 或 notification。用 facade／routing 將新 request 導向新 service，其餘仍回 monolith。

Order 與 inventory 共用 transaction，通常不是第一個隨意拆開的地方。拆分前要先定義 reservation、idempotency、event ordering、outbox 和 reconciliation，否則只是把 database transaction 變成 distributed inconsistency。

flowchart TB
  P0["Phase 0<br/>dependency、traffic、query、cost baseline"] --> G["Landing zone<br/>identity、network、logging、policy"]
  G --> C["Compatibility、throughput<br/>cutover／rollback PoC"]
  C --> D{"候選 workload<br/>可安全遷移？"}
  D -->|"否"| R["保留現況或 rehost<br/>修正 blocker"]
  R --> C
  D -->|"是"| P1["Phase 1<br/>搬移 monolith／可搬 workload"]
  P1 --> V["Production-like load<br/>journey 與 failure validation"]
  V --> P2["Phase 2<br/>facade／routing 漸進抽離"]
  P2 --> B{"Domain boundary 與<br/>transaction semantics<br/>清楚？"}
  B -->|"否"| P1
  B -->|"是"| S["獨立 service<br/>canary、reconciliation、rollback"]

第四步：資料庫要比較「現在能搬」與「未來要擴」

候選 A：Cloud SQL for MySQL

優點是 engine compatibility 較高，能縮短 migration；可先建立 regional HA、PITR／backup、connection management 和 cross-region DR plan。限制是單一 primary 的 write scale 與 cross-region asynchronous replication，無法直接滿足任何想像中的全球 multi-writer requirement。

候選 B：Spanner

Spanner 適合需要水平擴展 relational transaction、strong consistency 與符合其 configuration 的跨區可用需求。不過它不是 MySQL 的 drop-in replacement：schema、key、query、transaction 和 application access pattern 都需要評估，migration 成本可能高。

本階段的決策

根據「不能一次重寫」與 2 TB MySQL 現況，Phase 1 先以 Cloud SQL 作為低變更 migration candidate，完成 compatibility／performance／cutover PoC。這不是宣告永遠使用 Cloud SQL。

同時把 order／inventory access pattern 收集起來。若未來確認多區 write、scale 與 consistency 真的超出 Cloud SQL 能力，再為該 bounded context 評估 Spanner，並把 application rewrite、dual-run validation 和 data reconciliation 列入成本。

Inventory 不超賣可以先靠單一 authoritative transaction、reservation table、idempotency key 和正確 locking／optimistic concurrency 解決，不需要因一句「全球庫存」立即更換所有 database。

flowchart TB
  A["現況：2 TB MySQL<br/>monolith 共用 schema"] --> B{"現在能承擔 schema<br/>與 application rewrite？"}
  B -->|"否"| C["Phase 1：Cloud SQL candidate<br/>compatibility／load／cutover PoC"]
  B -->|"是"| D{"已核准 horizontal scale、<br/>跨區 write 與 consistency requirement？"}
  D -->|"否"| C
  D -->|"是"| S["Spanner assessment<br/>key、query、transaction、topology"]
  C --> V["HA、PITR、connection<br/>cross-region DR 驗證"]
  V --> T{"Review trigger 出現？<br/>scale 或 observed RTO／RPO 不達標"}
  T -->|"否"| K["維持並持續量測"]
  T -->|"是"| S
  S --> X["Migration／dual-run<br/>reconciliation 與成本驗證"]
  X --> Y{"收益足以承擔改造？"}
  Y -->|"否"| K
  Y -->|"是"| Z["只遷移需要該能力的<br/>bounded context"]

第五步：讀取路徑與寫入路徑分開設計

• Product image 遷到 Cloud Storage，依 cacheability 搭配 external Application Load Balancer／Cloud CDN；personalized response 不進 shared cache。
• Catalog read 可用 cache 降低 database load，但 inventory confirmation 仍回 authoritative service。
• Public API 經 load balancer、Cloud Armor 與適合的 identity control；backend 不開 bypass path。
• Cloud Interconnect 或 HA VPN 的選擇以 migration traffic、availability、lead time 和 cost 為依據，並建立 redundant path／route test。
• Global frontend 能降低 edge latency，不代表 regional database write 也會變成 local latency；用 latency budget 找真正 critical path。

第六步：分析管線不能靠 application dual write

Order transaction 同時寫 operational database 和 BigQuery，任一步失敗就會不一致。較安全的方向是：

1. Order 先在 authoritative transaction commit。
2. 以 outbox、CDC 或支援的 integration 產生可重放 event。
3. Pub/Sub 解耦 consumers，consumer 做 idempotency／deduplication。
4. Dataflow 或其他 processing 將資料整理後寫入 BigQuery。
5. 設 data quality、late event、schema evolution 和 reconciliation 指標。

BigQuery 是 analytics system，不拿來做即時扣庫存。Recommendation feature 也不直接讀 raw production tables，先建立有 consent、lineage、feature freshness 和 access control 的 training／serving data flow。

sequenceDiagram
  autonumber
  participant A as Order service
  participant D as Operational DB
  participant O as Outbox／CDC
  participant P as Pub/Sub
  participant F as Processing
  participant B as BigQuery
  A->>D: 同一 transaction 寫 order 與 outbox record
  D-->>A: Commit authoritative state
  O->>D: 讀取 committed change
  D-->>O: 可重放 event
  O->>P: Publish event
  P->>F: At-least-once delivery
  F->>F: Idempotency、schema、late-event handling
  F->>B: 寫入 analytics table
  B-->>F: Load result
  F->>D: Reconciliation 只回報差異，不雙寫 order

第七步：AI 專案先做 baseline 與 evaluation

「個人化推薦」可以是 rule-based、prebuilt search／recommendation capability、BigQuery ML，或 Gemini Enterprise Agent Platform（簡稱 Agent Platform，原 Vertex AI）上的 custom model。選擇前確認：

• 目前有沒有足夠的 view、click、cart、purchase 和 product metadata？
• 要最佳化 click-through、conversion、revenue，還是 customer satisfaction？
• Cold-start、新商品、季節性和 bias 怎麼處理？
• Online inference latency／availability 是否在 checkout critical path？
• Personalization 是否取得適當 consent，使用者能否 opt out？

先以熱門商品或簡單 ranking 做 baseline，再進 offline evaluation、shadow／A/B test。Agent Platform Pipelines（原 Vertex AI Pipelines）可編排 training workflow，Model Registry 管理 model version，endpoint／batch prediction 則依 serving need 選擇。Model Garden 是尋找 model 的入口，不是所有 custom TensorFlow workflow 的 version registry。

flowchart TB
  K["定義 business KPI<br/>conversion／revenue／satisfaction"] --> B["熱門商品或簡單 ranking<br/>建立 baseline"]
  B --> D["準備有 consent、lineage<br/>freshness 的資料"]
  D --> M["訓練／選擇 candidate"]
  M --> O{"Offline quality、<br/>bias<br/>與 safety 達標？"}
  O -->|"否"| D
  O -->|"是"| S["Shadow／小流量 canary<br/>驗證 latency 與 availability"]
  S --> A["A/B 或 holdout experiment"]
  A --> G{"Online KPI 顯著改善<br/>且 guardrail 正常？"}
  G -->|"否"| R["Rollback／保留 baseline<br/>記錄失敗原因"]
  R --> D
  G -->|"是"| P["逐步 rollout<br/>監控 drift、品質與成本"]

第八步：可靠性、安全與成本放進同一份決策

Reliability

• Checkout、database、payment 與 queue 分別定義 SLO／failure behavior。
• Autoscaling 設 maximum 與 downstream connection budget，促銷前跑 peak／soak test。
• Cloud SQL HA 處理 zone failure；region DR 用 replica／backup、runbook 和 game day 驗證 observed RTO／RPO。
• Release 用 immutable artifact、canary、synthetic checkout 和 database-compatible rollback。

Security／privacy

• Human 與 workload identity 分開，使用 least privilege 和短效 credential。
• 個資先分類；log、analytics 和 AI dataset 各有 purpose、retention 與 access policy。
• CMEK 只有在 control／regulation 需要時使用，並設 key availability、rotation 和 recovery。
• VPC Service Controls 適用於支援服務的 data exfiltration defense，不會取代 IAM、application authorization 或 internet egress control。
• 歐洲資料設計等 legal 釐清後再定案，不自行把 GDPR 解讀為所有資料必須留在歐洲。

Cost

• 用 billing export 把成本分到 environment／service／journey，並計算每筆成功訂單成本。
• 比較 migration、parallel run、egress、support、license 和 training，不只看 compute list price。
• CUD 只套在已觀察到的穩定 baseline；promo burst 保留彈性 capacity。

範例 ADR：Phase 1 database

**評審前草案：**這是第一輪候選，不是已通過證據回合的決策。

Status: Proposed — 待相容性、容量、DR 與切換／回復證據核對。
Decision: Phase 1 將 MySQL workload 遷到 Cloud SQL for MySQL，暫不直接改為 Spanner。

Context:
- 2 TB MySQL 與 monolith 共用 schema。
- 18 個月內要擴張，但目前沒有已核准的全球 multi-writer requirement。
- 團隊不能承擔一次 application／database rewrite。

Alternatives:
- Cloud SQL: compatibility 較高，write-scale 與跨區 DR 有限制。
- Spanner: 長期 scale／consistency 能力較強，需 schema 與 application 改造。
- Self-managed MySQL on Compute Engine: control 高，operation burden 也高。

Consequences:
- 先完成 compatibility、load、DMS／cutover 和 rollback PoC。
- 設 regional HA、backup／PITR、cross-region DR 與 restore test。
- 收集 order／inventory access pattern，於 expansion gate 重新評估 Spanner。

Review trigger:
- Sustained write／storage growth超過已驗證容量。
- 核准跨區 write 與 consistency requirement。
- Observed RTO／RPO 無法滿足業務目標。

好的 ADR 不假裝選擇沒有缺點，也會寫明何時重新評估。這份是收到後面 E1–E6 之前的候選草案；讀完新證據，必須修訂狀態、未通過條件與後續驗證，不能原封不動當成已核准答案。

flowchart TB
  C["Context<br/>事實、目標、constraints"] --> A["Alternatives<br/>至少兩個可行候選"]
  A --> T["Trade-off<br/>能力、風險、成本、operation"]
  T --> D["Decision<br/>理由與 assumptions"]
  D --> Q["Consequences<br/>接受的限制與後續工作"]
  Q --> V["Validation plan<br/>PoC、load、cutover、rollback"]
  V --> E{"Evidence 支持決策？"}
  E -->|"否"| A
  E -->|"是"| M["Monitor review triggers<br/>scale、requirement、<br/>RTO／RPO"]
  M -->|"trigger 出現"| C
  M -->|"未出現"| K["維持決策並持續記錄"]

第二輪：用證據修訂決策

本輪資料與目標

以下是評審回合提供的補充條件；已核准目標與未知要分開記錄。E1、E2、E4 的時間窗各自獨立；不能把不同批次混成一份 production 成績。

案例事實

• 台灣電商，服務台灣與部分東南亞客戶，18 個月內規劃擴張亞太市場。
• 地端 VMware 上的 Java 單體、2 TB MySQL 8.0；訂單、庫存與商品共用 schema。
• 團隊熟悉 Java、SQL、Docker，Kubernetes 經驗有限；不能一次重寫整套應用。
• 促銷尖峰約為平日十倍；曾因資料庫連線耗盡停止結帳。
• 下列證據是不同測試或決策回合，E1 與 E2 不是同一批流量，不能合併分母。

本輪已核准的演練目標

• 成功率：30 天有效邏輯結帳的 99.95%。以 checkout_id 去重，明確使用者輸入錯誤才排除；5xx 與尚未確認結果的逾時仍納入失敗。
• 延遲：尖峰時台灣與新加坡各自的端到端結帳 p95 都小於 800 ms。E2 使用 nearest-rank：將 n 筆排序，取第 ceil(0.95 × n) 筆。
• 資料完整性：確認訂單不得讓權威庫存低於零；付款、訂單與庫存結果需可對帳。
• 區域災害：故障後 60 分鐘內恢復新單，且完成本輪定義的未決付款／庫存對帳；可復原資料點落後故障時刻不超過 5 分鐘。
• 上述是本次假設業務負責人已核准的演練條件。資料落地、法規適用、變更窗口與新市場細部延遲仍須另行確認，不能推定已核准。

產品行為核對

本輪的數字是合成資料；產品能力另依第一方文件確認：

• Google SRE：實作 SLO：先固定有效事件與成功事件，再看對應視窗。
• Cloud SQL for MySQL HA與跨區副本與 DR：區內故障與區域災害的範圍不同，非同步複寫仍需核對資料與復原結果。
• 資料庫連線管理與Cloud Run maximum instances：限制設定、pool 與容量保護需要一起驗證。
• 架構決策紀錄：保留情境、候選、後果與狀態變更，讓取捨可追溯。

最後交付：四份成果都要對回證據

考試中怎麼縮短這套流程

不必在腦中畫完整 CloudMart。只做四件事：

1. 找動詞：題目要你 assess、migrate、design、secure 還是 troubleshoot？
2. 找硬約束：existing skill、deadline、protocol、RTO／RPO、consistency、compliance。
3. 每個選項問一句：它滿足哪個約束，又新增什麼沒有被要求的負擔？
4. 最後檢查：是否把未提供的假設當成事實？

若題目要求「先做什麼」，正確答案可能是 assessment，也可能是立即隔離 compromised credential。順序取決於風險與題目狀態，沒有「FIRST 永遠先規劃」這種規則。

課後檢查

先確認四份成果與 E1–E6 的修訂都已保存，再回答這幾題；答不出來，括號裡是該回去重讀的那一節。只有讀解答或尚未完成的部署驗證，請另外記在待補證據中。

• 一條 requirement 要補上哪些東西，才算可以測試？（回〈第二步：把需求寫成可測試條件〉）
• 為什麼不讓 application 同時寫 operational database 和 BigQuery？（回〈第六步：分析管線不能靠 application dual write〉）
• Phase 1 為什麼先用 Cloud SQL、暫不改 Spanner？什麼訊號出現要重新評估？（回〈範例 ADR：Phase 1 database〉）

本課重點

• Fact、outcome、constraint、unknown 和 assumption 要分開。
• Requirement 要有 owner、範圍、數值與驗證方法。
• Migration landing architecture 與長期 target architecture 可以不同。
• GKE、Cloud Run 和 Compute Engine 按 workload／team／control 選，不按重要性排序。
• Cloud SQL compatibility 較高；Spanner 能力不同但需要 migration／application 成本。
• Inventory integrity 先定義 transaction、reservation、idempotency 和 reconciliation。
• Analytics 用可重放 pipeline，不讓 application 對 operational／warehouse 雙寫。
• AI 先做 baseline、evaluation、privacy 和 fallback，再談 model platform。
• ADR 要記 alternative、consequence、validation 和 review trigger。

下一步

想拿自己的案例從頭走一遍，站內的 架構師設計工作坊 有 13 個步驟可以逐步填寫。

下一課會把這套決策方法帶進考場：先核對官方考試規格，再用原創題練習如何排除「技術上能做、但不符合題目」的選項。