深入 Neon 的 Lakebase 架構：無狀態運算與單元隔離如何在 AWS 故障中存活

以單元為基礎的隔離：一個區域不代表只有一個故障域

Neon 的區域部署並非單體式架構。每個區域由一或多個形狀相同的「單元」組成，單元內捆綁了自身的 Kubernetes 控制平面、運算池與儲存資源 。這種劃分方式意味著，某個單元的故障——無論是因為雲端供應商中斷、軟體錯誤還是資源耗盡——不會擴散到同一區域的其他單元。

在 2026 年 5 月 AWS 美東一區（us-east-1）的中斷事件中，雲端供應商的故障具體影響了其配置新執行個體與分配 IP 位址的能力 。對單單元架構來說，這會是一場波及整個區域的事件。但在 Neon 以單元為基礎的設計裡，只有那些耗盡預先配置運算緩衝區的單元受到影響，其他保有足夠已分配執行個體緩衝區的單元，則繼續不受干擾地運作 。

這個結果反映了深思熟慮的設計選擇：每個單元的大小經過規劃，確保沒有任何單元的資源上限會成為區域瓶頸。更早的架構經驗教訓強化了這個想法。在移往以單元為基礎的隔離之前，Neon 每個區域只運行單一 Kubernetes 叢集，測試顯示，由於 EKS etcd 記憶體上限、網路配置限制以及 Kubernetes API 速率限制等因素，超過 10,000 個並行資料庫就會導致服務降級 。單元式架構則透過將負載分散到獨立、互不互動的單元之間，徹底消除了這些單一叢集的天花板。

透過預先配置與自訂虛擬化，降低對雲端供應商的依賴

Neon 刻意與底層雲端供應商保持一定的距離。每當有資料庫需要啟動時，Neon 不會隨需呼叫 EC2 API，而是預先分配大型——通常是裸機——執行個體的池子，並維持緩衝容量以吸納資源配置中斷 。這個緩衝區不是為了優先租戶而準備的小型暖備援池；它是系統排程運算資源時的結構性組件。

在這些預先配置的執行個體之上，Neon 運行自家可垂直自動擴展的虛擬化層，將多個 Postgres 執行個體封裝到單一實體主機上。此舉同時繞過了兩項雲端供應商依賴：VM 資源配置 API（執行個體已經在運行）以及區塊儲存掛接路徑（Neon 的運算節點不使用雲端區塊儲存磁碟區）。

資料耐久性也遵循相同模式。所有資料庫內容都存放在 Neon 自家具備區域韌性的儲存服務中，其後端是像 Amazon S3 或 Azure Blob Storage 這類物件儲存，而非雲端供應商的區塊裝置 。物件儲存 API 的故障模式與 VM 資源配置 API 不同，而且在實務上，區域性控制平面中斷期間，物件儲存的耐久性已被證明具有顯著更高的韌性。當 pageserver 或 safekeeper 節點故障時，不會遺失任何持久性狀態——另一個節點可以從 WAL 與物件儲存中重建必要的頁面 。

跨區域冗餘儲存是基石，而非高貴的附加選項

在許多託管資料庫服務中，多可用區儲存複寫是一項需要額外設定的付費功能。但在 Neon 中，每個資料庫——無論定價層級——都由分散式、跨區域冗餘的物件儲存所支撐，並搭配散佈在多個可用區的 NVMe SSD 快取 。這讓跨區域的實體複寫不再是需要單獨考量的課題，因為儲存層本身就具備固有的複寫能力。

其 WAL 複寫設計提供了具體的耐久性保證：寫入會同步複寫至 safekeepers，並有法定人數要求（已發布的一種配置為六向複寫，加上四取六的寫入法定人數），這意味著即使整個可用區再加上一個額外複本故障，也不會遺失資料 。這不是理論上的韌性，而是寫入路徑的特性，必須在向客戶端確認交易之前就獲得滿足。

特別是對運算可用性而言，共享儲存模型提供了一項傳統主從式複寫架構無法比擬的優勢：因為所有運算執行個體都共享同一份持久性儲存歷史記錄，替換用的運算節點不須透過實體複寫來追上進度。它掛接到現有的歷史記錄上，並在幾秒到幾分鐘內開始提供查詢服務，具體時間取決於工作負載與快取工作集的大小 。

可用性目標與數據實證

針對 Neon lakebase 架構所發布的可用性 SLI，大約落在 99.93% 至 99.96% 之間 。這些數字反映了一種設計：運算故障是透過替換無狀態節點來恢復，而非容錯移轉至閒置的熱備援；儲存耐久性則是透過物件儲存支援的複寫來達成，而非同步磁碟鏡像。

Neon 自身的事件記錄為這些目標提供了實用的校準。2025 年 5 月在美東一區（us-east-1）發生的事件，於兩次獨立的故障中累計造成 5.5 小時的資料庫啟動與建立作業無法使用，但作用中的資料庫則不受影響 。其根本原因——由控制平面過載與 AWS CNI 錯誤配置所觸發的 Kubernetes 子網路 IP 位址耗盡——暴露了一項擴展限制，而單元式架構正是為了防止這類問題而設計的 。更早之前，2024 年 8 月，美東一區（us-east-1）發生 pageserver 中斷，大約 0.4% 的客戶專案在一個 EC2 執行個體故障後，受到長達兩小時的影響；因為 pageserver 的作用就像是以 S3 為後盾的本地磁碟快取，失去 pageserver 意味著暫時無法使用，而非永久性資料遺失 。

這些事件凸顯了一點：無狀態運算與共享儲存能降低故障的嚴重性，但無法完全消除故障。該架構的韌性特質——運算故障不遺失資料、透過重新掛接自動恢復、爆炸半徑侷限於單元內——在真實故障條件下經得起考驗，但系統並非對軟體缺陷、資源耗盡，或尚未完全解耦的雲端供應商依賴（例如 IP 位址分配）具有免疫力。

韌性測試：Neon 如何驗證設計

Neon 的工程部落格指出，系統會針對真實世界的故障情境進行測試，包括雲端供應商資源配置中斷，以及模擬整個可用區斷線 。這些測試會對預先配置的執行個體緩衝區，以及理應能限制爆炸半徑的單元隔離邊界進行演練。Neon 所描述的混沌工程大致形式反映了既有的實務做法：針對系統在故障下應如何表現，定義一套穩態假設；注入受控制的故障（例如中斷整個可用區的連線，或耗盡運算緩衝區）；觀察假設是否成立；並在假設不成立時，迭代改善架構 。

雖然除了架構部落格的概述之外，Neon 並未發布詳細的混沌工程方法論或具體的實驗結果，但現有證據顯示，這些測試直接瞄準了該系統與眾不同的韌性主張。Neon 描述的測試——模擬資源配置中斷與可用區故障——正是無狀態運算與單元隔離理應比傳統託管資料庫架構具有最大優勢的情境。2026 年 5 月的 AWS 中斷，實際上就是對這些相同機制的一次未經計畫的驗證，而爆炸半徑受到控制的結果，也與預先配置與單元隔離設計所要達成的目標一致。

這對評估無伺服器 Postgres 的團隊意味著什麼

Neon 的架構提供了一種特定的韌性取捨：它接受運算資源是短暫的，並以快速替換來取代不惜代價維持運算運行，同時則大力投資於儲存耐久性與故障域隔離。對於可以接受偶發性亞分鐘級查詢中斷、主要關切資料安全性的工作負載來說，此模式消除了維護熱備援的成本與複雜度。至於那些要求連續查詢可用性、不容絲毫中斷的工作負載，雖然有其他多運算節點配置可供選擇，但成本也相對較高。

此架構也迫使我們誠實盤點對雲端的依賴。沒有任何資料庫服務能真正獨立於其底層的雲端供應商，但耦合的程度卻有著天壤之別。Neon 決定預先配置容量、使用自家的虛擬化層，並將資料儲存在物件儲存而非區塊儲存磁碟區上，縮減了資料庫層運作所必須仰賴的雲端供應商 API 表面積。在 2026 年 5 月的 AWS 中斷期間，這縮減後的依賴表面積帶來了回報：那些保有足夠預先配置緩衝區的單元，撐過了原本會讓耦合度較高的架構面臨區域性全面中斷的故障。

對於在無伺服器基礎設施上構建服務的團隊來說，Neon 的做法證明了爆炸半徑的控制並非事後才想到的補救措施——它是早在故障發生之前，就在儲存與運算邊界以及故障域結構上做出的架構決策之產物。