Uber 資料庫超載防護演進：從靜態限流到 PID 調節的智慧負載管理
Uber Engineering Blog · 2026-04-20
Uber 工程部落格於 2026 年 4 月 20 日公開了其資料庫負載管理系統的完整演進歷程，從早期的配額式限流，到基於 CoDel（Controlled Delay）佇列與 Scorecard 規則引擎，最終演進至以 PID 控制器為核心的優先感知（priority-aware）負載卸載架構 Cinnamon。
第一代：配額式 Rate Limiting 的失敗
初始方案在無狀態查詢引擎層實作，以處理位元組數為計費單位，配額用量存入 Redis，超額請求回 429。此方案因三個結構性問題失效：每次請求都需向 Redis 查詢，增加延遲並引入單點故障；全表掃描僅返回一行與單行精確查詢計費相同，代價模型嚴重失真；靜態配額需要持續人工調整。更根本的問題是：無狀態路由層看不到數千個分區的實時健康狀態。
並發量作為超載訊號：Little's Law 的應用
轉折點在於採用「當下飛行中的操作數」（concurrency）取代 QPS 作為超載訊號。根據 Little's Law：Concurrency = Throughput × Latency。並發量直接反映有狀態系統的實際資源消耗，天然感知延遲抖動。
第二代：CoDel 佇列 + Scorecard 引擎
Uber 將 CoDel 演算法從網路層引入資料庫佇列管理。傳統 FIFO 佇列在壓力下等同 buffer bloat（緩衝膨脹），舊請求佔用資源卻已逾時失效。CoDel 改為：
- 分離讀、寫、慢操作佇列
- 壓力下從 FIFO 切換為 LIFO，優先處理最新請求
- 透過最小延遲目標動態調整丟棄率
Scorecard Engine 則是規則型 admission control，對每個租戶強制執行並發上限，在多租戶競爭時隔離異常行為者，不影響其他租戶。可插拔的 Regulator 元件（寫位元組、分區鍵、記憶體、Goroutine）提供多維度信號採集。
第三代：Cinnamon 優先感知負載卸載器
CoDel 的缺陷在於平等對待所有請求。Cinnamon 引入流量優先層級（tier-0 到 tier-5）並以 PID 控制器動態調整佇列逾時與飛行中請求上限：
- PID 控制：根據實時延遲平滑調整閾值，避免突發拒絕造成 thundering herd
- 自動調優器：閾值自適應，取代人工固定值
- 廣域卸載（按優先層級）與精確卸載（按調用方）兩種模式
統一負載卸載引擎
最終架構以「Bring Your Own Signal」框架整合本地健康訊號（並發量、記憶體、Goroutine）與遠端訊號（follower commit lag），所有決策通過優先感知控制路由，在儲存層（而非路由層）執行卸載決策。
結果
在超載壓測條件下，最終系統與初始方案相比：
- 吞吐量提升 80%（5,400 QPS vs. 3,000 QPS 均值）
- upsert P99 延遲降低約 70%（1.0 s vs. 3.1 s）
- 峰值 Goroutine 數降低約 93%（10,000 vs. 150,000）
- 最大堆記憶體用量降低約 60%（1 GB vs. 5–6 GB 峰值）
Uber 混合 CPU 核心分配：Linux cpu.shares 與 NUMA 感知解決過度預留問題
Uber Engineering Blog · 2026-04-21
Uber 容器編排系統 Odin 於 2026 年 4 月 21 日公開了其 CPU 分配架構演進，從純 dedicated core 模式演進為混合分配（Hybrid Core Allocation）模型，以解決突發性工作負載的資源過度預留問題。
舊架構的問題
舊系統假設 CPU 用量能以一分鐘均值準確衡量，且核心為完全專用。垂直 CPU Scaler 基於此假設動態調整配置，但對突發流量模式（bursty traffic patterns）反應不足——一分鐘均值會大幅低估峰值需求，導致實際配置要麼過度預留，要麼在峰值時 throttle。
混合分配模型
新架構將 CPU 資源分為兩類：
- Dedicated cores：保留給基線效能的專用核心
- Shared cores：過度訂閱的共享池，用於吸收流量峰值
共享核心的分配以 Linux 核心的 cpu.shares 機制實現。公式為：
cpu.shares = round((dedicated_CPUs + shared_CPUs_for_contention) × 100)乘以 100 的因子使分數 CPU 可以用整數表示。在競爭（contention）狀態下，cpu.shares 按比例分配共享池，確保高優先度容器獲得更多時間片，而非完全餓死低優先度容器。
NUMA 感知配置
Host Agent 在配置核心時考慮 NUMA 拓撲：dedicated cores 在同一 NUMA 節點內分配以最佳化記憶體局部性，shared cores 則分散在多個 NUMA 節點。這樣的設計降低跨 NUMA 記憶體存取延遲，同時保持共享池的靈活性。
就地垂直縮放
有狀態工作負載（本地儲存）無法遷移，舊架構面臨縮放需搬移資料的難題。新架構支援 In-Place Vertical Scaling：在不重新排程的情況下動態調整 dedicated 與 shared core 的比例，直接更新 cgroup 參數，消除資料遷移的操作成本。
此方案最終降低了突發工作負載的過度預留、提升艦隊整體 CPU 利用率，同時維持服務層級的效能保證（SLO），並消除有狀態服務縮放時的昂貴資料遷移。
Meta 如何用 AI Agent 在超大規模下回收數百 MW 電力：FBDetect 與機會解析平台
Meta Engineering Blog · 2026-04-16
Meta 工程部落格於 2026 年 4 月 16 日揭露其容量效率平台架構，以統一的 AI Agent 框架同時執行防禦性（效能迴歸偵測）與攻擊性（主動優化機會發掘）兩類操作，在超大規模資料中心環境中回收數百 MW 的電力。
雙層架構：MCP 工具 + Skills
平台分為兩層：
- MCP Tools：標準化 LLM 介面，負責 profiling 查詢、實驗擷取、設定歷史追蹤、程式碼搜尋、文件萃取
- Skills：高階工程師領域知識的編碼化推理模式，例如「查詢 GraphQL 端點的延遲迴歸前幾名」或「檢查序列化函數的 schema 變更」
防禦性與攻擊性操作使用相同工具集，但套用不同的 skills 集合，共享底層推理基礎設施。
防禦性操作：FBDetect + AI Regression Solver
FBDetect 是 Meta 的效能迴歸偵測系統，能識別生產環境中低至 0.005% 的效能退化。當偵測到迴歸時，AI Regression Solver 自動：
- 彙整迴歸症狀與根因 pull request
- 套用緩解策略（如提高 logging sampling rate）
- 生成供工程師審閱的 pull request
目前每週自動偵測並處理數千個迴歸案例，將約 10 小時的人工調查壓縮至 30 分鐘。
攻擊性操作：機會解析
工程師提出效率改善機會（efficiency opportunity）時，AI Agent 自動：
- 擷取機會元資料、相關文件與類似案例
- 套用該優化模式的專用 skill
- 產生候選修復方案，包含語法驗證與安全護欄
規模效益
該平台已在 Meta 資料中心規模下實現：數百 MW 的電力回收、每週數千個迴歸自動偵測、工程調查時間 20× 壓縮（10 小時→30 分鐘）。平台同一框架延伸至對話式助理、容量規劃 Agent 與個性化推薦，無需重新設計底層工具鏈。