流程定位

Serverless 的風險集中在觸發條件。函式部署成功只代表新版本存在，實際風險會在 HTTP request、queue message、topic event、scheduled job 或 edge request 觸發時出現。發布流程要能區分「版本建立成功」「alias 切流量成功」「事件來源行為正確」三件事。

Package 階段負責產生可執行 bundle。Serverless 常見失敗是本機 dependency 可用，但打包後缺檔、runtime target 不符、native extension 不相容或 layer 版本漂移；CI 應在接近目標 runtime 的環境做 smoke test。

Version 階段負責建立不可變版本。直接覆蓋 $LATEST 會讓事故追溯困難；正式流量應指向 version 或 Function Alias，讓 rollback 能把 alias 切回前一個已知版本。

Function Alias / traffic 階段負責控制流量切換。HTTP function 可以用少量權重 canary；queue trigger 則要觀察 batch failure、retry、dead-letter 與 downstream side effect，因為同一個錯誤 event 可能被重試多次。

Permission 階段負責限制 blast radius。Serverless 函式容易因部署方便而累積過大 IAM 權限；每個 function 應只拿到必要 resource、secret 與 network access，並把 production secret 與 preview / staging 隔離。

Event Source 階段負責定義失敗重送語意。Queue、topic、object storage、HTTP 與 scheduler 的錯誤行為不同；CI/CD 文件要記錄 retry 次數、dead-letter destination、batch size、concurrency limit 與 replay 條件。

Recovery 階段負責止血。Serverless 常見止血方式是 alias rollback、停用 trigger、降低 concurrency、清理毒訊息、重放事件或 forward fix；只回退 code 版本不一定能處理已經排入 queue 的事件。

事件來源判讀

事件來源判讀的責任是找出失敗是否可重試。Serverless 常被誤判為「函式自己失敗」，但實際根因可能是 event schema、權限、上游重試或下游限流。

這張表讓 release failure 能被導向正確 owner。若 event schema 變了，修 function 可能只是表面補丁；真正的 gate 要加在 publisher contract 或 sample event validation。

最小發布 gate

Serverless workflow 的最小 gate 應覆蓋 package、permission、event 與 alias。缺其中一段，部署成功就可能只是建立了一個尚未被驗證的函式版本。

1. Package bundle，固定 runtime target 與 dependency。
2. 對 bundle 執行 unit / contract / sample event test。
3. 用 least privilege policy 做 deploy dry run 或 policy diff。
4. 發布 immutable function version。
5. 用 alias 將少量流量導向新版本。
6. 觀察 error、latency、retry、DLQ 與 downstream 指標。
7. 指標穩定後提高 alias 權重或完成切換。
8. 指標觸發 tripwire 時切回 alias、停用 trigger 或啟動 repair。

這個流程把 Serverless 發布從「上傳函式」提升成可回復流程。對事件驅動函式而言，trigger 與 retry policy 是發布契約的一部分。

下一步路由

• Serverless 部署總覽：回 Serverless 部署 CI/CD。
• Rollout 概念：讀 Rollout Strategy。
• 失敗處理：讀 CI 失敗到修復發布流程。

自架 vs 商業的判斷決策表用四個維度（使用者數 / 網路範圍 / 功能需求 / 合規）做二元分流。本章把光譜展開成四條路徑，讓中間的 BaaS 和 PaaS 選項浮現。Backend 選型模組已建立了完整的交付形態光譜（交付形態選型）和逐能力判斷外包深度的框架（能力級買 vs 建）。本章把那個框架特化到監控場景。

四條路徑

路徑 A 和 D 分別是光譜的兩端 — Sentry 深入、Firebase 套件和模組四 Collector 設計已完整討論。以下展開路徑 B 和 C。

路徑 B：BaaS + Serverless

APP 上線初期用 Supabase + Vercel（或 Cloudflare Workers）搭監控後端：serverless function 接收 SDK 送來的事件、驗證 schema 後寫入 Supabase 的 PostgreSQL。整條鏈路在免費方案額度內可以零成本運作。

架構差異

Serverless function 沒有常駐 process。模組四假設的 Go single binary 架構 — channel 背壓、single-writer goroutine pattern、in-memory buffer — 在 serverless 環境都不適用。每個 HTTP request 是獨立的 function invocation，沒有跨 request 的記憶體狀態。

背壓機制需要重新設計：Go collector 用 channel 容量做背壓（channel 滿回 429），serverless 版改用 DB-level 的 rate limit（PostgreSQL 的 advisory lock 或外部 rate limiter 如 Upstash Redis）或 platform-level 的 quota（Vercel 的 concurrency limit）。SDK 端的 429 處理邏輯不需要改 — 不管背壓訊號來自 channel 還是 DB quota，SDK 都是收到 429 後降採樣。

Downsample 和 purge 在 Go collector 是 background goroutine 定期執行。Serverless 沒有 background job — 需要外部 cron trigger（Vercel Cron / Supabase pg_cron / GitHub Actions scheduled workflow）。

免費方案限額

以下為 2026-06 查詢的各平台免費方案限額。平台定價會變動，決策前以官方定價頁為準。

Audit date: 2026-06。平台免費方案限額可能調整，決策前以官方定價頁為準。

適合情境

路徑 B 適合以下組合：APP 上線初期（使用者數 < 100）、團隊熟悉前端和 SQL 但不想管 server、想保留自訂 schema 和查詢彈性（商業 SaaS 的 schema 是 vendor 定義的）、零成本起步但未來可能遷到自架。

撞牆訊號

以下訊號出現時，代表路徑 B 的天花板已到、該評估遷到路徑 C 或 D：

連線數瓶頸：Supabase Free 的 PostgreSQL 約 20 個 concurrent connection。Serverless function 每次 invocation 開新連線，高併發時可能耗盡連線池。Supabase 內建 PgBouncer 做 connection pooling 可緩解，但免費方案的 pooler 有自己的連線上限。

Cold start 延遲：Vercel serverless function 的 cold start 約 200ms、Supabase Edge Function 約 100ms。對監控 ingestion（不是使用者面向 API）通常可接受，但如果 SDK 的 flush timeout 設得很短（< 1s），cold start 可能造成偶發超時。

Background job 限制：Downsample 和 purge 需要外部 cron。Vercel Hobby 支援最多 2 個 cron job、每個最頻繁每天觸發 1 次 — 如果需要每小時 downsample，要用 Supabase pg_cron（Free 方案支援）或外部 scheduler。

免費額度耗盡：Supabase 的 500K Edge Function invocations/月 ≈ 每天 16K requests。如果每個 request 攢批 100 筆事件，可處理每天 160 萬筆事件。超過後進入按量付費。Vercel Hobby 無明確 invocation 上限、瓶頸在 bandwidth（100GB/月）和 execution duration。

合規限制：Supabase Free 的 PostgreSQL 部署在特定 region。有 GDPR data residency 需求的 app（歐盟使用者的資料必須留在 EU）需確認 vendor 的 region 支援 — 免費方案的 region 選擇可能有限。

路徑 C：PaaS

PaaS 跑的是和完全自架相同的 Go collector 原始碼，差異只在部署方式。git push 觸發自動 build 和 deploy，平台管 server provisioning、TLS 憑證、process supervision。Collector 的 channel 背壓、single-writer pattern、SQLite storage 全部適用 — 和本機開發環境的行為一致。

Railway 和 Fly.io 都支援 persistent volume — Railway Hobby 含 1GB、Fly.io Free 含 1GB（限單 region）。SQLite 的 WAL 檔案需要持久化，persistent volume 是必要條件。Render 的免費方案沒有 persistent disk — SQLite 在每次 deploy 後重置，不適合需要保留歷史事件的場景。PaaS 平台以 container 形式運行 collector，SQLite 在 container 中的 I/O 和持久化考量見 Container 部署設計。

路徑 C 適合：想用自架 collector 但不想管 server / TLS / systemd 的團隊。程式碼完全相同，遷到自架（路徑 D）的成本接近零 — 把 binary 複製到 VPS、設定 systemd service 就完成。

路徑 C 的天花板在平台定價 — Railway Hobby 有 $5/月的資源上限、Fly.io Free 有 3 個 shared VM。流量成長到免費額度不夠時，PaaS 的按量付費和 VPS 月租費的交叉點是遷到自架的判讀訊號。

路徑間的遷移

遷移成本取決於起點和終點之間有多少層需要重寫。

路徑 B → C 或 B → D 的遷移代價主要在 collector 邏輯的重寫 — serverless function 的 request-level 處理和 Go binary 的 channel-based pipeline 是不同的架構，不能直接搬。資料層的遷移代價較低 — Supabase 的 PostgreSQL 資料可以用 pg_dump 匯出、匯入自管 PostgreSQL。

交付形態遷出的通用框架（資產線盤點、並行期設計、回切窗口）見 託管形態遷出。

外包深度對照

用 外包深度 的三層框架（managed 基礎設施 / feature SaaS / BaaS bundle）看四條路徑：

路徑 B 在外包深度上介於 managed 基礎設施和 BaaS bundle 之間 — DB 和 runtime 交給平台，但 collector 邏輯和 schema 仍由開發者控制。這和 BaaS 的「前端 SDK 直連平台資料庫」模式不同 — 監控場景的路徑 B 仍然有一個自己寫的中間層（serverless function），只是這個中間層跑在平台上而非自己的 server。

選擇建議

APP 上線初期選 B 或 A 取決於自訂需求 — 需要自訂 schema 和查詢邏輯（例如自定義 error fingerprint、行為事件命名規範）選 B，只需要開箱即用的 error tracking 或行為分析選 A。B 保留遷到自架的彈性（資料在自己的 PostgreSQL），A 的功能完成度更高（dashboard、告警、session replay 開箱即用）。

下一步路由

• 自架 vs 商業的詳細決策 → 自架 vs 商業的判斷決策表
• 自架 collector 的完整設計 → 模組四 Collector 設計
• Backend 交付形態光譜 → 交付形態選型
• 能力級買 vs 建判斷 → 能力級買 vs 建
• 外包深度概念 → 外包深度
• BaaS 概念 → BaaS
• 遷出劇本 → 託管形態遷出
• Vendor lock-in 概念 → Vendor Lock-In

場域定位

Serverless 發布通常以函式版本為單位，並透過 Function Alias 或流量權重切換。部署步驟看起來短，但對權限、Event Source、重試政策與 observability 欄位要求很高。

常見注意事項

• 部署前要先驗證 runtime 與依賴版本，避免 deploy 成功但 invocation 失敗。
• 事件觸發型函式要明確設定 retry、dead-letter 或回放策略。
• 權限設定要收斂到最小範圍，避免函式擴權風險。
• 冷啟動與併發上限要納入發布後觀測指標。

學習路線

下一步路由

• Serverless 發布主流程：讀 Serverless function 版本、事件來源與回復流程。
• Gate 原理：讀 CI gate 與 workflow 邊界。
• 失敗處理：讀 CI 失敗到修復發布流程。
• Backend 相關概念：讀 Serverless / worker 相關知識卡。

本章目標

讀完本章後、你應該能：

1. 區分四種 RAG deployment 方案（純前端 / edge serverless / RAG SaaS / 純文字 search）。
2. 對自己場景判斷該選哪個方案、看資料量 / 隱私 / 預算。
3. 認識靜態場景特有的資安議題：API key 暴露、CORS、abuse、第三方 SaaS 供應鏈、client-side 模型完整性。
4. 知道哪些資安議題在 模組六 已覆蓋、哪些是本章獨有。

為什麼這個議題重要

傳統 RAG 教材預設架構：

1User → backend server → embedding API → vector DB → LLM API → response

需要 backend 可執行 server-side code、藏 API key、控制 rate limit。但個人開發者場景常見的 deployment：

這些場景跟「個人 dev 跑本地 LLM」並列、是教材的合理覆蓋面。

四種 deployment 方案總覽

1                          embedding   vector       LLM call
2                          搜尋          DB
3方案 1 純前端            browser       browser     browser（WebLLM）或 user-key 直 call
4方案 2 edge serverless   edge fn       edge DB     edge fn → LLM API
5方案 3 RAG SaaS          SaaS          SaaS        SaaS（或自 call）
6方案 4 純文字 search     N/A           static idx  N/A（不是 RAG）

四方案快速對比：

方案 1：純前端 RAG（browser-side everything）

整個 RAG pipeline 都跑在使用者瀏覽器：

 1Build time（Hugo build / CI pipeline）：
 2  content/*.md
 3    ↓ 抽段、chunk
 4    ↓ embedding model（Node.js 版 sentence-transformers）
 5  embeddings.json（每個 chunk 一個 vector）
 6    ↓ 跟 HTML 一起 deploy
 7
 8Runtime（user browser）：
 9  User query
10    ↓ load @xenova/transformers + embeddings.json（首訪載 ~50MB）
11    ↓ embed query in browser
12    ↓ cosine similarity vs embeddings.json
13  top-K chunks
14    ↓ LLM call（兩條子路線、見下）
15  Response in browser

LLM 的兩條子路線：

實作概要：

1# Build time（Node.js script）
2npx @xenova/transformers-cli embed content/*.md > static/embeddings.json
3
4# Frontend（簡化版）
5import { pipeline } from '@xenova/transformers';
6const embedder = await pipeline('feature-extraction', 'nomic-embed-text-v1.5');
7const queryVec = await embedder(userQuery, { pooling: 'mean' });
8const ranked = embeddings.map(c => ({ ...c, score: cosineSim(c.vec, queryVec.data) }))
9                          .sort((a,b) => b.score - a.score).slice(0, 5);

規模上限：

• < 1000 chunks：embeddings.json ~ 4MB（1024-dim float32）、輕鬆
• 1K-10K：~40MB、首訪載入慢但可接受
• 10K+：純前端開始勉強、考慮方案 2

適合場景：個人 blog、docs site、demo、隱私敏感、規模 < 10K chunks。

方案 2：靜態 + edge serverless

「靜態主站 + edge function 處理動態請求」：

 1靜態前端（HTML / JS、Hugo / Astro）
 2   ↓ fetch /api/rag
 3Edge function（Cloudflare Workers / Vercel Edge / Netlify Functions）
 4   ↓
 5Embedding API（OpenAI / Voyage）
 6   ↓
 7Vector DB（Cloudflare Vectorize / Pinecone / Turso vector / Upstash Vector）
 8   ↓
 9LLM API（OpenAI / Anthropic / Cloudflare AI Gateway）
10   ↓ response
11靜態前端

對使用者體感跟「有 backend」一樣、但你不用維護 server / 不用 sysadmin。

主流元件搭配：

關鍵特性：

1. API key 不暴露在 browser：edge function 內讀環境變數、安全
2. 可加 rate limit：edge function 內判斷 client IP / user agent、避免 abuse
3. Build-time index 仍重要：embedding ingestion 通常在 build 階段、不在 runtime
4. Edge cold start：第一次 query latency 略高（~100ms 額外）、後續 hot 路徑快

適合場景：規模 1K-100K chunks、想保留近 backend 體驗、可接受少量 cost。這條路線一旦升級到有 backend 的 vector DB、storage 選型（index 結構、維度、成本）就回到 4.22 RAG storage 工程 的判讀。

方案 3：靜態 + RAG SaaS

把整個 RAG stack 外包：

API key 設計：

• search-only key：只能查詢、無寫入權限、可安全暴露在 browser（這是設計支援的）
• admin key：build time CI 用、有寫入權限、必須藏 server-side

前端範例（Algolia）：

1const client = algoliasearch('APP_ID', 'SEARCH_ONLY_KEY');  // 可公開
2const index = client.initIndex('my-blog');
3const { hits } = await index.search(userQuery, { hitsPerPage: 5 });

適合場景：想最快上線、不在乎 vendor lock-in、規模中小、retrieval-only（不需要 LLM 對話）。

方案 4：靜態 + 純文字 search（不是真 RAG）

Pagefind、Stork、lunr.js、FlexSearch — build time 產靜態 search index、純前端查詢。

這不是 RAG：

1. 無 embedding similarity：keyword / fuzzy match、不是語意相似
2. 無 LLM augmentation：只列文章連結、不生成回答
3. 算 retrieval 的「字面」變體：見 4.1 RAG 的「語意 vs 字面」段

適合場景：blog 內搜尋只需要找文章、不需要對話、極致 zero-cost。

規模門檻：什麼時候該升級方案

1< 1K chunks                    → 方案 1 純前端、最簡單
21K - 10K chunks                → 方案 1 或 方案 4
310K - 100K chunks              → 方案 2 edge serverless
4100K+ chunks                   → 完整 backend RAG（不再是「靜態」場景）
5非 RAG、只要找文章             → 方案 4（Pagefind 等）

靜態場景特有的資安議題

本章節最重要的部分。靜態 / serverless RAG 有些議題模組六沒覆蓋、要在本章補。

1. API key 暴露 — 靜態場景的根本問題

核心衝突：靜態網站沒 server-side runtime、藏不了 secret。任何寫在前端 JS / 編進 HTML 的東西、使用者按 F12 都看得到。

對應到 RAG：

如果要 LLM 對話功能、三條合法路線：

1. 使用者自帶 API key（如 Anthropic / OpenAI）、存 localStorage、前端直接 call API — 適合 power user、需要使用者授信
2. WebLLM / wllama 跑前端 LLM — 模型在 browser、不需 server-side key
3. 方案 2 edge serverless — key 藏在 edge function、就不是純靜態了

寫死 API key 在前端 JS 等於把 key 公開、會被 scraper 撿走燒爆 quota — 這是 anti-pattern、跟 6.4 跨雲端 / 本地資料邊界 提到「API key 寫死 config」的延伸版（前端更嚴重、所有訪客都看得到）。

2. User query 隱私

靜態場景的 query 走向：

對應 framing 跟 0.7 隱私資料流 同源 — 但靜態場景的特殊性是「前端直接出去」、不像 backend 場景可以加一層中介控制。

特別注意：

1. 方案 3 SaaS 的 query 隱私：Algolia / Pinecone 都會 log query、依政策可能用於改進服務；對隱私敏感場景不適合
2. Edge provider 的 region：Cloudflare Workers 的 edge node 可能在跟使用者不同 region 處理、跨境資料法規（GDPR 等）要考慮
3. Browser extension 偷 query：使用者裝的 plugin 可能 access 整個頁面、包含 RAG 介面內的 query

3. CORS / 同源策略 — Browser 特有的安全模型

靜態前端 call 任意 API 會撞 CORS（Cross-Origin Resource Sharing）：

1靜態網站：https://my-blog.com
2要 call：https://api.openai.com/v1/...
3   ↓
4Browser 檢查 OpenAI 是否在 Access-Control-Allow-Origin 含 my-blog.com
5   ↓
6OpenAI 預設允許所有 origin（為了讓前端 SDK 能用）→ 通過
7某些 API（Anthropic 早期版本）不允許 browser 直 call → 失敗、必須走 edge

判讀：

• 能在 browser 直 call 的 API：OpenAI、Voyage、Algolia（search-only）等明確設計 browser-friendly 的服務
• 不能 browser 直 call、要 edge proxy：許多企業 LLM API、私有 vector DB、需要 server-only credentials 的服務

CORS 不是「資安漏洞」、是 browser 對「JS 從一個網站 call 另一個網站」的設計約束、用來保護使用者。要繞 CORS 要嗎服務商配合（設 ACAO）、要嗎用 edge function proxy。

4. 第三方 SaaS 信任 — 跟 6.0 同源、對象換

6.0 模型供應鏈與信任邊界 處理的是「模型權重的信任」。靜態 RAG SaaS（Algolia / Pinecone / Weaviate Cloud）引入另一條供應鏈：

 1模型供應鏈（6.0 覆蓋）：
 2  原作者 → quantizer → registry → 你機器
 3
 4RAG SaaS 供應鏈（本章新增）：
 5  你的 content → SaaS embedding service → SaaS vector DB → SaaS retrieval
 6    └──────── 全程在 SaaS 內、你信任 SaaS 沒做以下事 ────────┘
 7              - 把你 index 用於訓練他們自己的模型
 8              - 把你 query log 賣給第三方
 9              - 沒做適當 isolation（你跟其他客戶的資料）
10              - 沒處理好 supply chain（他們用的 base embedding model）

判讀類似 0.7 物理 vs 合約保證：本地方案是物理保證（資料不離 browser）、SaaS 方案是合約保證（信 SaaS 的 ToS）。

5. Rate limit / abuse — 前端被 scrape 後濫用

靜態 RAG 的特殊 abuse 路徑：

1攻擊者掃到你的 demo blog
2   ↓ 找到前端載入的 embedding endpoint / LLM endpoint
3   ↓ 直接從攻擊者 server 重複 call（不經 browser）
4   ↓ 你的 LLM API quota 燒爆 / SaaS 配額耗光

緩解：

1. 方案 2 edge + 加 rate limit by IP / token bucket：edge function 內 reject 過量請求
2. 方案 1 純前端 + WebLLM：根本沒 server-side endpoint 可被 abuse、最安全
3. 方案 3 SaaS + 用 search-only key 並設 query 上限：SaaS 通常內建 quota
4. CAPTCHA / Turnstile：邊緣防護

絕對不該做：把 OpenAI / Anthropic API key 寫在前端 JS、想用 rate limit 阻擋 — 攻擊者拿到 key 後不會經過你的 rate limit。

6. Client-side LLM 的模型完整性

Client-side LLM 把幾 GB 模型權重下載到 browser、引入新的供應鏈面：

1你的網站
2   ↓ <script> 載入 WebLLM runtime（CDN）
3   ↓ runtime 從 HuggingFace CDN 抓 model weights
4   ↓ 使用者 browser 跑模型

風險：

1. CDN 被 compromise：WebLLM runtime 或 model weights 在 CDN 上被換、注入 backdoor
2. HTTPS 之外無額外驗證：不像本地 GGUF + hash 比對、browser 載模型純信 CDN + HTTPS
3. 使用者本機沒 inventory 記錄：跟 6.0 推薦的「下載後記 hash」對比、browser 沒這機制

緩解：

1. Subresource Integrity（SRI）：HTML 的 <script integrity="sha384-..."> 屬性、browser 自動驗證 hash
2. CSP（Content Security Policy）：限制可載入的 script / image source、減少 supply chain attack 面
3. 挑大廠 CDN：Cloudflare / jsdelivr / unpkg 等被 compromise 的歷史紀錄較少

跟 6.0 的關係：6.0 講「本機跑的 GGUF 模型供應鏈」、本章補「browser 跑的 client-side 模型供應鏈」— 兩種場景的 framing 一致、但具體威脅面跟工具不同。

跟模組六的 routing

本章資安段跟既有 模組六 的對應：

判讀流程

 1你的場景：
 2  ├─ 有 backend？
 3  │    └─ 是 → 用 4.0 RAG + 4.8 embedding 主章節、本章不適用
 4  │    └─ 否 → 繼續
 5  │
 6  ├─ 規模？
 7  │    ├─ < 1K chunks → 方案 1 純前端
 8  │    ├─ 1K-10K → 方案 1（embeddings.json ~ 40MB 仍可接受）
 9  │    ├─ 10K-100K → 方案 2 edge serverless
10  │    └─ 100K+ → 不再是靜態場景、回 backend
11  │
12  ├─ 需要 LLM 對話、不只 retrieval？
13  │    ├─ 是 + 隱私第一 → 方案 1 + WebLLM
14  │    ├─ 是 + 品質第一 → 方案 1 + user-key 或 方案 2
15  │    └─ 否（只要找文章） → 方案 4 純文字 search
16  │
17  └─ 預算 / vendor lock-in 容忍度？
18       ├─ 完全 zero-cost、無 vendor → 方案 1 純前端
19       ├─ 接受少量 cost、不想自己寫太多 → 方案 3 SaaS
20       └─ 接受少量 cost、想自己控 → 方案 2 edge

不在本章內的主題

1. 完整 backend RAG：see 4.1 RAG 原理 跟 4.12 embedding model
2. 具體 SaaS API 教學：Algolia / Pinecone 等 API 細節隨版本變、見各 SaaS 文件
3. WebGPU 內部細節：GPU shader、WebGPU API 設計屬 web platform 議題、不在 LLM 教材範圍
4. Production 多租戶 RAG 服務：屬 backend/07、本章 framing 是「個人 / 小團隊靜態網站」
5. 企業合規 deployment：HIPAA / GDPR / SOC 2 跟具體 SaaS / cloud provider 強相關、見 backend/07 合規卡片 跟 6.4 跨雲端

何時過時 / 何時不過時

不會過時的部分：

• 四方案分類（純前端 / edge / SaaS / 純文字 search）
• 「靜態場景藏不了 secret」這個根本特性
• API key 暴露 / CORS / abuse / 供應鏈 / 模型完整性 五大資安議題分類
• 跟 模組六 的 routing 關係

會變的部分：

• 具體 SaaS / edge provider（Cloudflare Vectorize / Pinecone / Algolia 等持續演化）
• Client-side LLM runtime（WebLLM / wllama / transformers.js）的能力上限
• WebGPU 支援度跟 browser 標準
• 哪些 LLM vendor 允許 browser 直 call（CORS 政策會變）
• 純文字 search 工具（Pagefind 等持續改進）

下一步

本章是 模組四 最後一章。讀完整個模組四、完整覆蓋 LLM 作為系統元件的設計取捨。下一步可進入 模組五 PC 獨立 GPU 或 模組六 安全 補本地 dev 視角的安全議題。

概念位置

Function Alias 位在 function version、traffic weight、event source 與 invocation entrypoint 之間，常見於 Lambda alias 或其他 serverless 平台的版本別名。

可觀察訊號

• 新舊 function version 需要短暫共存。
• 部分流量需要導向新版本做 canary。
• 事故時需要把入口切回上一個版本。

接近真實服務的例子

HTTP function 的 prod alias 先把 5% 流量導向 version 42。若錯誤率穩定，逐步提高權重；若錯誤率升高，alias 切回 version 41。

設計責任

Function Alias 要定義版本命名、流量權重、觀測指標、事件來源綁定與回復條件，讓函式發布具備可控入口。

概念位置

Event Source 位在 queue、topic、HTTP gateway、object storage、scheduler 與 function / worker 之間，負責把外部事件轉成執行請求。

可觀察訊號

• 函式部署成功，但 invocation 因 trigger 設定失敗。
• Queue event 重試造成同一筆資料被重複處理。
• 事件 schema 漂移導致 subscriber 解析失敗。

接近真實服務的例子

Queue 觸發的 function 以 batch 方式處理訊息。新版本解析失敗時，訊息進入 dead-letter queue；團隊先停用 trigger，再修復 function 或重放事件。

設計責任

Event Source 要定義 trigger 條件、batch size、retry、dead-letter、replay、權限與 schema 契約，讓事件驅動發布具備可觀測回復路徑。

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 Serverless v2 的容量機制、設定與適用邊界的實作層教學。

核心機制：ACU 與秒級擴縮

Serverless v2 的容量單位是 ACU（Aurora Capacity Unit），一個 ACU 對應一組固定比例的記憶體與運算資源。cluster 不再綁定一個 instance class，而是設一個 ACU 區間（min / max），Aurora 依即時負載在區間內伸縮：

擴縮行為：

• 負載上升時 ACU 平滑增加、不需要切換 instance、無連線中斷
• 負載下降時縮回低水位、但受 min ACU 下限約束
• min ACU 決定離峰的最低成本與「保留多少暖容量」；max ACU 決定尖峰的上限與成本天花板

Scope warning：「ACU 對應的記憶體比例」「serverless v2 是否能縮到 0」「最小 ACU 粒度」這些屬 AWS vendor 規格、會隨版本演進（auto-pause 等能力陸續調整）、實作時 cross-verify 官方 doc 當前值。本文不含 production case 揭露的 ACU 配置數字。

對應 knowledge card：peak forecast、cost per request。

min / max ACU 的設定權衡

min 與 max ACU 不是隨便設，兩端各自承擔不同風險。

min ACU 太低：離峰省錢，但流量回升時從很低的水位往上爬、爬升期間可能容量不足、且 buffer cache 在低 ACU 時被壓縮、回升後 cache 重新暖機、query latency 短暫升高。對延遲敏感、又有規律日週期的 workload，min ACU 不要壓到極限。

max ACU 太低：尖峰被天花板卡住、等同 provisioned 的 instance class 上限問題又回來。max ACU 要按「預期尖峰 + 餘量」設，並把它當成成本天花板來監控——max 設太高雖然不會平時就花錢，但失控 query（如缺索引的全表掃描）可能把 ACU 一路推到 max、帳單尖峰。

暖容量考量：min ACU 同時決定「保留多少隨時可用的暖容量」。完全不可預測、且要求第一個請求就低延遲的場景，min ACU 要留足暖機水位，不能為了省錢設到最低。

混合 cluster：serverless + provisioned 並存

Serverless v2 不是「整個 cluster 要嘛全 serverless、要嘛全 provisioned」。同一個 Aurora cluster 可以混用：writer 用 provisioned 保穩定、read replica 用 serverless v2 吸收讀取尖峰；或反過來。這讓 workload 的不同部分各取所需：

• 穩定的寫入路徑用 provisioned instance、成本可預測
• 間歇的讀取分析、報表副本用 serverless v2、平時縮到低水位
• failover 目標可指定 provisioned 或 serverless，依可用性需求

混合配置的判讀是把 cluster 內每個角色當獨立的負載形狀評估，而非整個 cluster 一刀切。

操作流程

從負載形狀評估到上線的 6 步流程。

Step 1：判斷負載形狀

用 CloudWatch 過去 30 天的 CPU / connection / IOPS，看負載是穩定平緩、規律日週期、還是不規則突發：

• 穩定高負載（平均使用率高、波動小）→ provisioned 通常更划算
• 間歇 / 突發 / 開發測試 / 多租戶各自小 DB → serverless v2 適合
• 規律日週期（白天高晚上低）→ serverless v2 或 provisioned + scheduled 都可，算成本 crossover

Step 2：估 min / max ACU

min 依離峰最低負載 + 暖容量需求；max 依尖峰負載 + 餘量。第一次設保守一點、上線後依實際 ACU 曲線收斂。

Step 3：建立或轉換

1# 新 cluster 指定 serverless v2 capacity range
2aws rds create-db-cluster \
3  --db-cluster-identifier my-cluster \
4  --engine aurora-postgresql \
5  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=32

既有 provisioned cluster 可加 serverless v2 reader、逐步驗證再調整 writer。

Step 4：觀察 ACU 曲線

上線後盯 ServerlessDatabaseCapacity（即時 ACU）與 ACUUtilization，確認伸縮符合負載、min/max 設定合理。

Step 5：成本對照

把實際 ACU-秒換算的帳單，跟「同等 provisioned instance 全時段開機」對照。若 serverless 帳單接近或超過 provisioned，代表負載其實夠穩定、該回 provisioned。

Step 6：驗證點

1# 驗證離峰真的縮到 min ACU（看 ServerlessDatabaseCapacity 低谷）
2# 驗證尖峰沒撞 max ACU 天花板（看是否長時間貼著 max）
3# 驗證回升期 latency 可接受（min ACU 暖容量是否足夠）

Rollback boundary：serverless v2 與 provisioned 可互轉、reader 先轉驗證再動 writer；轉換本身有短暫中斷，要排 maintenance window。

失敗模式

production 常見的 5 個踩雷：

Case 1：穩定高負載用 serverless 反而更貴

把一個 7x24 高使用率的 cluster 改 serverless「以為省錢」，實際 ACU 幾乎全時段貼近高水位、按 ACU-秒計費比固定 instance 貴。修法：穩定高負載用 provisioned；serverless 的省錢前提是「有顯著的離峰可以縮」。

Case 2：min ACU 設太低、回升期 latency 尖刺

離峰縮到極低、早上流量回來時 cache 冷、ACU 從低水位爬、前幾分鐘 query 變慢。修法：規律日週期的 workload，min ACU 留足暖容量；或用 provisioned + scheduled scaling 處理可預測的日週期。

Case 3：max ACU 沒當成本天花板監控

缺索引的 query 觸發全表掃描、ACU 一路衝到 max、帳單尖峰才發現。修法：max ACU 設合理上限 + CloudWatch alarm 盯 ACU 長時間貼 max（那是 query 或容量問題的訊號，不是正常擴縮）。

Case 4：把 serverless 當「不用做容量規劃」

以為 serverless 自動伸縮就不必估容量、min/max 隨便設。修法：serverless 改變的是「不用手動切 instance」，不是「不用理解負載形狀」；min/max 仍要基於負載曲線設定。

Case 5：對延遲極敏感的 OLTP 全 serverless

核心交易路徑要求穩定低延遲、卻用會伸縮的 serverless writer、伸縮邊界期間 latency 抖動。修法：穩定低延遲的核心寫入用 provisioned writer，serverless 留給可容忍伸縮抖動的讀取 / 分析副本（混合 cluster）。

Anti-recommendation：負載穩定、使用率長期偏高、或對延遲抖動零容忍的核心 OLTP → 用 provisioned；serverless v2 的價值在「間歇、突發、難預測、或有大量離峰」的負載，沒有離峰可縮就沒有省錢空間。

容量與觀測

CloudWatch metric：

• ServerlessDatabaseCapacity：即時 ACU、看伸縮曲線
• ACUUtilization：ACU 使用率、判斷 min/max 設定是否合理
• CPUUtilization / DatabaseConnections：底層負載、對照 ACU 是否跟得上

判讀：

• ACU 長時間貼近 max → max 設太低或有失控 query，要查
• ACU 長時間貼近 min 且使用率低 → 負載其實很輕，min 可能可再降、或這個 cluster 適合更小配置
• ACU 幾乎不波動且水位高 → 負載穩定，serverless 沒發揮價值，評估改 provisioned

Scope warning：本文未引用 production case 的 ACU 數字；上述 metric 與判讀屬 vendor 規格 + 通用容量工程。

接回 9.6 容量規劃模型、Aurora 容量規劃要點。

邊界與整合

Serverless v2 vs provisioned + scheduled scaling

兩者都能處理「負載隨時間變」，但適用場景不同：

• scheduled scaling（provisioned）：負載 可預測（已知的日週期、已知大活動）→ 預先排程改容量，成本最可控
• serverless v2：負載 不可預測（突發、不規則）→ 自動伸縮吸收，不需預測

可預測的尖峰用 scheduled、不可預測的用 serverless，這跟 DynamoDB capacity mode 的 predictable-peak vs flash-sale 判讀同源。

Sibling 與 cross-link

• storage-architecture — serverless 只改 compute 層容量、storage 層 quorum 設計不變
• read-replica-scaling — serverless reader 吸收讀取尖峰、與 fleet 治理結合
• Aurora I/O-Optimized cost — serverless 算的是 compute（ACU）成本、I/O-Optimized 算的是 storage I/O 成本，兩個成本軸獨立、要分開評估
• rds-proxy-connection-pooling — serverless + Lambda 場景的連線管理
• 替代路由：負載穩定且高 → provisioned；KV access pattern → DynamoDB
• 跟 Netflix 9.C23 互引：polyglot 架構下不同 workload 用不同 Aurora 配置（穩定 OLTP provisioned、間歇副本 serverless）

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 RDS Proxy 連線管理機制與陷阱的實作層教學。

核心機制：connection multiplexing

RDS Proxy 維護一個到 Aurora 的後端連線池，多個 client 連線共享這些後端連線。當 client 連線閒置（交易之間沒有活動），proxy 可以把對應的後端連線釋放回池子給其他 client 用：

multiplexing 生效的前提是 client 連線「閒置時可以被借走」。這只在連線處於 交易之間 的乾淨狀態時成立——一旦連線帶了交易內狀態，proxy 不能把它借給別人，這就是 pinning。

Scope warning：「RDS Proxy 支援的 engine / 連線數上限 / IAM 認證細節」屬 AWS vendor 規格、實作時 cross-verify 官方 doc 當前值。本文不含 production case 揭露的 proxy 配置數字。

對應 knowledge card：connection pool。

Pinning：multiplexing 失效的主因

Pinning 是 RDS Proxy 最常被忽略、卻直接決定省連線效果的機制。當 client 在連線上做了「跨交易持續的 session 狀態」操作，proxy 無法安全地把這條後端連線借給其他 client，於是把它 pin（綁定）到該 client 直到連線關閉——這條後端連線在 pin 期間不參與 multiplexing。

常見觸發 pinning 的操作：

• session 層級的變數設定（SET 某些 session variable）
• 建立 temp table
• prepared statement（某些情況）
• advisory lock、保持開啟的交易
• 部分 session 層級的設定語句

pinning 的後果是「明明裝了 RDS Proxy、後端連線數卻沒降下來」。若大量 client 都觸發 pinning，等於退化回「一個 client 一條後端連線」、proxy 白裝。

判讀與修法方向：

• 監控 DatabaseConnectionsCurrentlySessionPinned，看 pinning 比例
• application 端避免不必要的 session 狀態（少用 session variable、temp table；改用交易內可清理的方式）
• 真的需要 session 狀態的 workload，接受該連線會 pin、或評估這類 workload 是否適合走 proxy

Scope warning：「哪些具體語句觸發 pinning」隨 RDS Proxy 版本與 engine 演進、實作時以 AWS doc 當前清單為準；本段列舉是常見類型、非完整或固定清單。

Failover 加速

RDS Proxy 的第二個價值是縮短 failover 對 application 的中斷。沒有 proxy 時，writer failover 會讓所有 client 連線斷掉、application 要偵測、重連、重建連線池；有 proxy 時，proxy 保持與 client 的連線、在後端把流量切到新 writer，client 端感知到的中斷時間縮短。

這對連線建立成本高、或 failover 期間不能大量重連的 workload 特別有價值。但 proxy 不消除 failover 本身——in-flight 的交易仍會失敗、application 仍要有 retry；proxy 縮短的是「重建連線」這段，不是「交易不中斷」。

操作流程

從連線壓力判讀到上線的 6 步流程。

Step 1：確認是不是連線問題

先區分「Aurora 容量不夠」vs「連線管理問題」。看 DatabaseConnections 是否逼近上限、且 CPU/IOPS 還有餘量——後者是典型的連線數問題、proxy 能解；若是 CPU/IOPS 飽和，proxy 不解。

Step 2：判斷 workload 是否適合 proxy

• serverless / Lambda / 高並發短連線 → 適合（連線爆炸是主問題）
• 少量長連線、穩定的 application server → proxy 效益有限（連線數本就可控）
• 大量 session 狀態 workload → pinning 會吃掉 multiplexing 效益、要先評估

Step 3：建立 proxy

1aws rds create-db-proxy \
2  --db-proxy-name my-aurora-proxy \
3  --engine-family POSTGRESQL \
4  --auth ... \
5  --role-arn ... \
6  --vpc-subnet-ids ...

application 連到 proxy endpoint 而非直連 cluster endpoint。

Step 4：減少 pinning

review application 的 session 狀態使用、移除不必要的 SET / temp table；連線池設定避免長時間持有閒置連線。

Step 5：驗證 multiplexing 生效

1# 對照後端連線數：裝 proxy 後 Aurora 的 DatabaseConnections 應顯著低於 client 並發數
2# 看 DatabaseConnectionsCurrentlySessionPinned：pinning 比例高代表 multiplexing 沒發揮

Step 6：驗證 failover 行為

主動觸發一次 failover、測量 application 感知到的中斷時間、確認 retry 邏輯能吸收 in-flight 交易失敗。

Rollback boundary：application 可在 proxy endpoint 與直連 cluster endpoint 間切換、proxy 出問題時改回直連（但直連會回到連線爆炸風險，要先確認後端撐得住）。

失敗模式

production 常見的 5 個踩雷：

Case 1：裝了 proxy 但 pinning 比例高、連線沒降

application 大量用 session variable / temp table、多數連線被 pin、後端連線數沒降、proxy 白裝。修法：監控 pinning 比例、減少 session 狀態；理解 proxy 的省連線前提是連線可被借走。

Case 2：把 proxy 當「Aurora 容量擴充」

連線數沒問題、是 CPU/IOPS 飽和、卻裝 proxy 期待變快。修法：proxy 解連線管理、不解運算容量；容量問題要擴 instance / 加 replica。

Case 3：以為 proxy 讓 failover 零中斷

裝了 proxy 就拿掉 application 的 retry、failover 時 in-flight 交易失敗沒處理。修法：proxy 縮短重連時間、不保證交易不中斷；application 仍要 retry in-flight 交易。

Case 4：少量長連線 workload 強裝 proxy

穩定的 application server 連線數本就可控、裝 proxy 多一跳延遲、效益有限。修法：proxy 的價值在連線爆炸場景（serverless / 高並發短連線）；連線可控的 workload 不必加。

Case 5：proxy 與自管 pooler 疊加未理清責任

application 已有自管連線池（如語言層 pool）、又加 RDS Proxy、兩層 pool 互相打架、連線數行為難預測。修法：理清兩層職責——application 層 pool 管「app 到 proxy」、proxy 管「proxy 到 Aurora」；兩層設定要協調、不是各設各的。

Anti-recommendation：連線數本就可控的少量長連線 workload、或 workload 大量依賴 session 狀態（pinning 會吃掉效益）→ 不必上 RDS Proxy；它的價值集中在 serverless / Lambda / 高並發短連線的連線爆炸場景。

容量與觀測

CloudWatch metric：

• DatabaseConnections（Aurora 端）：裝 proxy 後應顯著低於 client 並發數
• DatabaseConnectionsCurrentlySessionPinned：pinning 數、判斷 multiplexing 效益
• ClientConnections（proxy 端）：client 側連線數、對照後端收斂比例
• QueryDatabaseResponseLatency：proxy 多一跳的延遲影響

判讀：

• 後端連線數沒因 proxy 下降 → pinning 比例高或 workload 不適合
• pinning 數持續高 → application session 狀態過多、需 review
• proxy 延遲明顯 → 評估這一跳對延遲敏感路徑是否值得

Scope warning：本文未引用 production case 的 proxy metric 數字；上述指標與判讀屬 vendor 規格 + 通用連線管理工程。

接回 9.5 瓶頸定位流程、1.1 高併發下的 SQL 讀寫邊界。

邊界與整合

RDS Proxy vs 自管 pgbouncer

兩者都是 connection pooler，責任切分在「managed vs 自管」：

• RDS Proxy：AWS managed、跟 Aurora / IAM / Secrets Manager 整合、零運維、含 failover 加速；綁 AWS
• 自管 pgbouncer / pgcat：自己部署運維、pooling 模式（session / transaction / statement）可細調、跨雲可攜；運維責任自負

PostgreSQL 的通用連線池機制與 pgbouncer 細節主寫於 pgbouncer-config 與 connection-pooler-comparison；本篇聚焦 RDS Proxy 這個 AWS managed 方案的機制與 pinning 陷阱。要細調 pooling 模式、或需要跨雲可攜 → 評估自管 pooler；要零運維 + Aurora 原生整合 + failover 加速 → RDS Proxy。

Sibling 與 cross-link

• serverless-v2-scaling — serverless + Lambda 場景的連線管理常與 RDS Proxy 一起出現
• cross-az-failover-rto — proxy 縮短 failover 重連時間、與 RTO 目標結合
• pgbouncer-config / connection-pooler-comparison — 通用連線池 SSoT、自管方案對照
• 1.1 高併發下的 SQL 讀寫邊界 — 連線池與 transaction 範圍控制
• 替代路由：需要細調 pooling 模式 / 跨雲 → 自管 pgbouncer

本文是 CockroachDB vendor overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。本文聚焦 Cockroach Cloud serverless 與 dedicated 的取捨判讀、RU 計費結構、冷啟動 / scale 行為、何時用 serverless。Self-managed 規模化的運維責任（Netflix Platform Team 養 380+ cluster）跟賽季型擴縮（Hard Rock 100 ↔ 33 node）作為 對照軸 引用、不重展 self-host 運維細節。

問題情境：要 managed CockroachDB、但 serverless 跟 dedicated 該選哪個

團隊決定不自管 Raft / backup / upgrade，改走 Cockroach Cloud managed，接著面對的是 serverless 跟 dedicated 兩種 managed 形態的取捨。這個取捨不是「哪個比較好」，而是 容量壓力的形狀對應哪種計費與 scale 模型。

Cockroach Cloud serverless 是 把容量決策從「預先 provision 節點」換成「按實際用量計費 + 自動 scale」 的 managed 形態。它消去了 cluster sizing 這個決策 — 沒有「要開幾個 node」的問題，資源隨 workload 自動伸縮，甚至閒置時 scale 到接近零。代價是計費單位變成抽象的 Request Unit（RU），用量暴衝時成本跟著暴衝，且共享底層資源帶來冷啟動與性能可預測性的取捨。

dedicated 則保留 固定的 cluster 容量 + 可預測的計費，由 vendor 代管運維但容量仍是團隊決策。

讀者進來最常卡的三題：

• serverless 的 RU 計費到底計什麼、怎麼估自己的 workload 會花多少？
• serverless 閒置會 scale 到零，那冷啟動會不會讓第一個請求變慢？
• 什麼 workload 適合 serverless、什麼時候該選 dedicated 或乾脆 self-managed？

這三題的共同核心是 把 workload 的流量形狀（穩定 vs 突發、可預測 vs 不可預測、高峰 vs 長尾）翻譯成計費與 scale 模型。

問題情境的對照 trigger 來自兩個 self-managed 規模的 case，它們界定了「什麼時候 serverless / dedicated 都不對、要 self-host」的邊界。

9.C40 Netflix 是 self-managed 380+ cluster（case 揭露 380+ 為含非 production 的總數、production cluster 160+），case 明確揭露這需要 專屬 Database Platform Team（backup、upgrade、incident response、capacity review），並警示「沒這量級團隊就走 Cockroach Cloud managed、不要 self-host」。這條判讀的反向就是本文的入口 — 大多數團隊沒有 Platform Team，managed 才是合理起點，問題只剩 serverless 還是 dedicated。

9.C41 Hard Rock Digital 是 self-managed、賽季型擴縮（高峰 ~100 node、淡季 ~33 node，case 觀察段揭露）。這個 100 ↔ 33 的擺盪是 已知時間點的年度循環（NFL / NBA 賽季切換），不是不可預測的突發。case 還揭露合規驅動需要 AWS Outposts 把運算放進州內 — 這把它鎖死在 self-managed。Hard Rock 的形狀正好對照出 serverless 的適配範圍：serverless 擅長 不可預測 的突發與長尾閒置，而非 可預測且需要特定部署位置 的賽季擴縮。

核心機制：RU 計費 + 自動 scale + 冷啟動

Request Unit：把多維資源用量折算成單一計費單位

serverless 的計費核心是 Request Unit（RU）— 一個把 CPU、IO、network、storage 存取 等多維資源用量折算成的抽象單位。每個 SQL 請求依其實際消耗的資源換算成若干 RU，帳單按 RU 總量計。這跟 dedicated「按 provision 的節點數 × 時間」計費是兩種不同的成本心智模型。

RU 模型的好處是 用多少付多少 — 閒置時段不付運算費。風險是 RU 跟「人類直覺的請求數」不是線性對應：一個全表掃描的 query 可能吃掉相當於上千個點查的 RU。estimate workload 成本時，要以 資源消耗 為單位思考，不是以「請求數」。

Scope warning：RU 的具體換算係數、serverless 免費額度、scale-to-zero 的觸發閒置時間、冷啟動延遲量級、serverless 的 region / 一致性 / 規模上限，都屬 Cockroach Cloud 的計費與規格、且隨方案版本演進，三個 anchor case（DoorDash / Netflix / Hard Rock 全為 self-managed）都未揭露 serverless 計費數字。本文只給結構性判讀（RU = 多維資源折算、scale-to-zero 帶來冷啟動），具體數值與當前方案邊界需 cross-verify Cockroach Cloud Pricing 文件 與官方計費頁。

自動 scale 與 scale-to-zero

serverless 隨 workload 自動伸縮資源，無需團隊 provision。閒置時可 scale 到接近零，這正是「閒置不付運算費」的來源。對 突發 + 長閒置 的 workload（開發 / 測試環境、低流量 side project、流量極不均的早期產品），這個模型把成本壓到只反映實際活躍時段。

scale-to-zero 的代價是冷啟動 — 從近零狀態接到請求時，要先把資源拉起來，第一個請求的延遲高於 warm 狀態。對開發環境這通常可接受；對「閒置後第一個用戶請求就要快」的面向用戶 production 路徑，冷啟動是要先評估的取捨。

serverless vs dedicated 的責任與成本對照

每一行都要回到 workload 形狀判讀。

容量決策這一行是兩種模型的根本差異：serverless 把「要開幾個節點」這個決策從團隊手上拿走，對沒有容量規劃經驗或流量極不可預測的場景能降低團隊的容量規劃負擔；但對流量已知、需要性能可預測的 production，dedicated 的「自己定容量」反而是想要的控制權。

成本可預測性這一行是 serverless 的主要風險面。RU 隨用量浮動意味著 一次失控的查詢模式、一波爬蟲、一個沒加 LIMIT 的全表掃描 都會把帳單推高，而 dedicated 的成本上限就是 provisioned 容量。流量可預測的 production，dedicated 的可預算性往往比 serverless 的「用多少付多少」更重要。

操作流程：選型判讀、配置、用量驗證

第一步：用流量形狀做 serverless / dedicated 初判

選型的判讀軸是 workload 的 流量形狀，不是規模大小。

• 流量突發 + 長閒置（dev / test、低流量產品、不可預測早期 workload）→ serverless 的 scale-to-zero 與按用量計費直接受益。
• 流量穩定 + 可預測 + 需要性能可預測 → dedicated 的固定容量與可預算成本更合適。
• 流量大 + 有專屬 Platform Team + 需要跨雲 / on-prem / 特定部署位置（如 Hard Rock 的合規 Outposts）→ 兩種 managed 都不對，走 self-managed（見 vendor overview 的容量規劃段）。

判讀訊號：把過去一段時間的 QPS 畫成時間序列，看「活躍時段佔比」與「峰谷比」。活躍佔比低、峰谷比高 → serverless;活躍佔比高、波動平緩 → dedicated。

第二步：serverless 建立 cluster 並設成本上限

serverless 的成本風險來自用量浮動，所以建立後第一件事是設 消費上限，把「用量暴衝 = 帳單暴衝」的尾部風險封住。

驗證點：cluster 建立後，確認消費上限已設、且設了接近上限的告警閾值（例如達上限 80% 告警）。沒設上限的 serverless cluster 等於把成本曝險完全交給 workload 行為。

第三步：驗證 RU 消耗與預期一致

上線後監控 RU 消耗速率，對照第一步的流量形狀預估。

驗證點：RU 消耗速率若遠高於預估，通常是某類 query 的資源消耗被低估（全表掃描、缺索引、N+1 查詢）。這時要回到 query 層優化，而非直接加預算 — serverless 的計費把「低效 query」直接翻譯成「高帳單」，是一個比 dedicated 更直接的成本訊號。

第四步：評估冷啟動對 production 路徑的影響

若 serverless cluster 服務面向用戶的 production 路徑，驗證閒置後第一個請求的延遲是否在 SLO 內。

驗證點：模擬閒置後的首請求延遲，對照面向用戶路徑的 latency SLO。超出 SLO 代表這條路徑不適合 scale-to-zero，要嘛保持一定 warm 流量、要嘛改 dedicated。

失敗模式：成本失控與選型誤判

RU 用量暴衝、帳單失控（高代價情境的回退敘事）

serverless 最常見的事故是 帳單暴衝 — 一波非預期流量、一個低效查詢上線、一次爬蟲，把 RU 消耗推到遠超預算。跟 dedicated「成本上限 = provisioned 容量」不同，serverless 的成本上限要靠人為設定，沒設就沒有天花板。

這個情境的回退代價特殊之處在於 成本已經發生：rebalance 可以暫停、locality 可以改回，但已計的 RU 帳單不會退回。所以 serverless 成本失控的「回退」重點在 事前封頂 與 事中熔斷，而非事後補救。

回退與防護要素：

• 事前一定設消費上限與分級告警（接近上限前就要收到訊號），把尾部風險封在可承受範圍。
• 事中發現 RU 暴衝，先定位來源 — 是流量真的漲（業務事件），還是某個 query 模式失控（缺索引、全表掃描、無 LIMIT）。前者考慮是否該轉 dedicated，後者回 query 層修。
• 設「RU 消耗速率超過閾值就告警 + 自動限流」的 tripwire，避免單一失控 query 在無人值守時段燒完整月預算。
• 若 workload 已穩定成長到「serverless 浮動成本 > dedicated 固定成本」的交叉點，規劃轉 dedicated。

serverless → dedicated 遷移的代價

當 workload 從「突發長尾」成長為「穩定高量」，serverless 的按用量成本會超過 dedicated 的固定成本，此時要遷移。這個遷移不是改個開關 — serverless 與 dedicated 是不同的 cluster 形態，遷移意味著資料搬遷與 cutover，要走 backup / restore 或資料複製流程，並承擔 cutover 窗口。

回退敘事：把 serverless → dedicated 當成一次小型 migration 規劃 — 估資料量與遷移窗口、雙寫或 backup/restore 路徑、cutover 條件與回退條件，而非「線上無痛切換」。提早在用量逼近成本交叉點時規劃，避免在帳單已經失控時倉促遷移。

Anti-recommendation：不要因為「serverless 聽起來更現代」就把已知穩定、可預測、高流量的 production workload 開在 serverless。這類 workload 的可預算性與性能可預測性，dedicated 給得更直接，serverless 反而引入成本浮動與冷啟動兩個非必要風險。

把賽季型 / 可預測擴縮誤當 serverless 場景

可預測的擴縮（如 Hard Rock 的 NFL / NBA 賽季 100 ↔ 33 node 年度循環）不是 serverless 的適配範圍。serverless 擅長 不可預測 的突發，而可預測的擴縮可以用 dedicated 的計畫內 scale 直接規劃容量、保留性能可預測性。把可預測擴縮交給 serverless，是用「成本浮動 + 冷啟動」換一個本來就能用排程解決的問題。

修法：可預測的容量循環，用 dedicated + 排程 scale；只有真正不可預測的突發長尾才用 serverless。

冷啟動拖垮面向用戶路徑

scale-to-zero 的 serverless cluster 服務面向用戶 production，閒置後首請求冷啟動延遲超出 SLO，用戶感受到第一次訪問特別慢。

修法：面向用戶且對首請求延遲敏感的路徑，要嘛維持低頻 warm 流量避免完全 scale-to-zero，要嘛改 dedicated；scale-to-zero 留給容忍冷啟動的 dev / test / 後台 batch 路徑。

容量與觀測

必看 metric

• RU 消耗速率：serverless 成本的直接訊號，速率異常上升要立刻定位 query 來源。
• 當期累計消費 vs 上限：成本封頂的剩餘空間，逼近上限要告警。
• 冷啟動 / 首請求延遲：scale-to-zero 對面向用戶路徑的影響。
• query 資源消耗分佈：哪些 query 吃掉最多 RU，是 serverless 成本優化的入口。

容量與成本判讀

• serverless 月成本 ≈ Σ(各 query RU × 頻率)，所以成本優化等於 query 效率優化 — 缺索引、全表掃描在 serverless 直接體現為帳單。
• serverless / dedicated 成本交叉點 ≈ 「serverless 浮動成本」與「dedicated 固定容量成本」相等的用量水準，逼近交叉點是規劃遷移的訊號。
• dedicated 的容量規劃回到節點數 × replica × latency budget（見 vendor overview 容量規劃段）。

Scope warning：RU 換算係數、免費額度、serverless 的規模 / region / 一致性上限、serverless ↔ dedicated 成本交叉點的具體用量水準，均為 Cockroach Cloud 計費與規格、隨方案版本變動，非 case 揭露數字，成本建模前以 Cockroach Cloud 文件 cross-verify。

回路徑

• 9.6 容量規劃模型 流量形狀 → 計費模型對應。
• 9.7 成本邊界與 efficiency managed vs self-managed 的人力 + 資源成本權衡。

邊界與整合

Sibling deep articles

• survival goals：managed 形態下 survival goal 仍是團隊決策 — serverless / dedicated 都要對齊業務 RTO / RPO，存活機制以該文為 SSoT。
• multi-region table config：serverless 與 dedicated 對 multi-region table locality 的支援邊界不同，跨 region 強一致需求要先確認所選 managed 形態是否覆蓋。
• aurora-dsql-spanner-decision-tree：Aurora DSQL 本身是 serverless distributed SQL，三家 managed distributed SQL 的選型對比以該文為 SSoT，本文不重展。

跟 Aurora DSQL / Spanner serverless 對照

Aurora DSQL（AWS）以 serverless 為核心形態、AWS-only；Spanner 提供 managed 但計費與 scale 模型不同。三家在 serverless / managed 維度的完整對比是 aurora-dsql-spanner-decision-tree 的 SSoT，本文只處理 Cockroach Cloud 自身的 serverless / dedicated 取捨。

跟 self-managed 對照

self-managed（如 Netflix 380+ cluster、Hard Rock 合規 Outposts）給最大控制權（跨雲 / on-prem / 特定部署位置），代價是專屬 Platform Team 的運維責任。判讀軸：沒有 Platform Team → managed（serverless / dedicated）；有 Platform Team + 需要特定部署位置或跨雲 → self-managed。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游選型。
• PostgreSQL → CockroachDB migration — 從 PostgreSQL 遷入後再選 managed 形態。

何時不用本文

• 已決定 self-managed（有 Platform Team 或需要 on-prem / 合規 Outposts）→ 看 vendor overview 容量規劃段與 self-host 運維，本文的 serverless / dedicated 取捨不適用。
• single-region 小 workload 且 PostgreSQL 已夠用 → 先確認是否真需要 distributed SQL，見 vendor overview 不適用場景。

相關連結

• CockroachDB vendor overview
• 9.C40 Netflix（self-managed 需 Platform Team 的反向 = managed 入口）
• 9.C41 Hard Rock Digital（可預測賽季擴縮 vs serverless 突發適配範圍的對照）
• distributed SQL 卡
• 官方：Cockroach Cloud Documentation / Plan Your Cluster