湖倉架構如何保持對雲故障的彈性

隨着AI代理工作負載的興起，雲基礎設施的可靠性面臨前所未有的挑戰。代理程序以比人類快4倍的速度創建數據庫，並要求服務器無服務器、自動擴展的基礎設施，同時將控制平面操作（如啓動數據庫）視為關鍵的數據平面工作。在Databricks的湖倉架構中，目前每天啓動數千萬個數據庫。

湖倉架構從設計之初就注重彈性，而非事後修補。無狀態Postgres計算與區域冗餘存儲相結合，意味着實例可以在沒有熱備或崩潰恢復的情況下即時替換。我們將熱路徑控制平面操作分離到專用服務中，最小化對雲提供商的依賴，並將每個區域劃分為自包含的單元。

我們通過測試和測量來證明可靠性，而非空頭承諾。每個版本都經過混沌測試，在進程、節點和可用區級別進行故障注入，並使用SqlLancer等開源工具進行驗證。我們跟蹤每個數據庫的可用性（而非集羣平均值），目標為99.99%的月度可用性，並公開發布達成情況。

過去一年，代理工作負載以新的使用模式考驗了雲基礎設施的極限：控制平面操作吞吐量更高、對按需基礎設施的需求更大、容量 crunch。這給平台構建者和雲提供商都帶來了挑戰。湖倉架構通過以下關鍵設計應對這些挑戰：

**高可用架構**：基於分離的計算和存儲架構，高可用性是核心設計原則。無狀態Postgres計算將所有持久數據存儲在遠程存儲服務中，因此計算進程不持有本地持久狀態。如果Postgres或硬件故障，可以立即替換，無需複製數據到熱備或執行崩潰恢復。區域冗餘存儲確保所有數據庫（無論層級和配置）都基於分佈式、區域冗餘的高可用存儲。

**控制平面即數據平面**：在傳統架構中，控制平面僅用於管理操作。但在代理和按需工作負載下，啓動數據庫的控制平面部分實際上成了數據平面。因此，我們正在將控制平面的關鍵部分分離為一個數據平面控制器服務，僅處理熱路徑操作（啓動/暫停），減少業務邏輯和外部依賴，從頭設計彈性、優雅降級和縱深防禦。

**謹慎處理關鍵路徑依賴**：我們通過預分配大型實例池、構建自定義垂直擴展虛擬化層、使用自己的區域彈性存儲而非雲塊存儲，大幅減少了關鍵數據庫流程中涉及的控制平面機制。

**單元化隔離**：湖倉將一個區域由一個或多個相同的單元組成。每個單元是完整的、自包含的堆棧。這有助於擴展和限制故障爆炸半徑。例如，在2026年5月8日的AWS事件中，故障僅影響一個單元，約13%的數據庫，而不是整個區域。

**故障模擬與注入**：每個版本在投產前都經過故障注入和混沌測試。我們在真實集羣上運行工作負載，同時殺死進程、關閉節點、注入網絡故障、擦除磁盤內容，並使用開源工具SqlLancer等驗證Postgres行為正確性。我們還進行整個可用區斷網模擬，目標是將任何工作負載的停機時間控制在30秒以內。

**測量與度量**：我們遵循“如果不能測量，就不是科學”的原則，測量所有系統組件的服務級別指標（SLI）並設定目標（SLO）。例如，我們跟蹤每個數據庫的可用性和數據庫啓動時間，確保個體用户不會因集羣平均可用性高而遭受停機。