快速擴展線上儲存，服務超過 10 億名 ChatGPT 使用者（第二部分）

所有 OpenAI 產品都需要快速、可靠的資料存取，而這項能力由我們的儲存平台 Habitat 提供。它必須在毫秒內，回應遍布 40 個地理區域、超過 10 億名使用者的請求。我們的基礎架構面臨極為艱鉅的挑戰：既要支援爆炸性成長與新的使用情境，又要持續提升可靠性、效能，以及產品開發速度。為了克服這項挑戰，我們必須重新思考線上儲存平台的設計與維運方式。我們持續評估各種取捨，依循的順序是：先達到足以承載關鍵產品流量的可靠性，再提供全球使用者所需的速度，最後實現超大規模下的靈活維運。

這個分為兩部分的系列，說明我們如何將 Habitat 從簡單的用戶端程式庫與資料庫，發展成承載超過 500 PB 資料的全球分散式儲存平台。第一部分聚焦於 Habitat 如何從 Python 用戶端演進為一項服務。其中也介紹了我們採用的技術，如何讓以 Python 為基礎的服務，遠遠突破許多人認為實務上可行的極限。

本文是系列的第二部分，將帶您了解我們如何擴展底層儲存元件 Azure Cosmos DB。透過與 Azure 團隊密切合作，我們找到了可行的多租用戶方案，以共同管理的容器，在全球超大規模下提供優異的讀取效能。

隨著公司規模擴大，基礎架構團隊往往會從維運單一租用戶系統，轉向多租用戶系統。在單一租用戶架構中，各產品功能團隊各自維護系統，能縮小故障影響範圍，也容易劃分權責、隔離工作負載。但隨著團隊與產品功能增加，維運成本也會變得高昂。單一租用戶架構讓每個產品團隊都得負責容量規劃，而且往往導致大量資源超額佈建。

相對地，多租用戶架構將控制權集中在資料庫團隊手上，由具備更豐富知識與經驗的團隊負責資源佈建。但多租用戶架構也有自己的問題，例如吵鬧鄰居問題：某個租用戶消耗異常大量的資源，損及其他租用戶。

在 Habitat 中，我們必須權衡這些取捨，才能設計出可靠、高效率的大規模儲存系統。如今，Habitat 是多項 OpenAI 產品的多租用戶資料庫層。但我們曾經繞了一圈：從使用單一的多租用戶 Azure Cosmos DB 容器，到佈建單一租用戶的底層容器，最後又回到預設採用多租用戶容器。Habitat 的多租用戶發展仍處於非常早期的階段。我們雖然支援大量使用情境，但盡可能運用 Azure Cosmos DB 內建的基礎機制，因此得以延後在這個領域的投入。

在介紹我們使用 Azure Cosmos DB 的歷程前，先說明一些基本概念：

• 一個 Azure Cosmos DB 帳戶定義了一組容器與複寫原則

• 每個容器都會佈建一定的吞吐量，以每秒要求單位（RU/s）計量

• 每個容器中的資料，都採用常見的依指定邏輯分割區索引鍵分片的方式儲存；文件中載明了每個邏輯分割區索引鍵的儲存與吞吐量上限

• Azure Cosmos DB 負責將邏輯分割區索引鍵分布到數量較少的底層實體分割區。當儲存量超過閾值，或容器需要更多實體分割區來支撐已佈建的吞吐量時，就會將實體分割區分裂為多個

起初，我們允許所有用戶端負載通過，仰賴文件所述每個邏輯分割區索引鍵 1 萬 RU/s 的上限來產生背壓。剛開始時，我們在每個帳戶中也只使用一個預設的 Azure Cosmos DB 容器。這種做法起初還算可行，但後來因幾個原因出現問題：

由於早期的 API 設計選擇，我們讓用戶端直接選擇邏輯分割區索引鍵。結果，不同產品使用情境經常在 user_id 或 workspace_id 等常用分割區索引鍵上發生衝突。由於這些使用情境共用同一邏輯分割區索引鍵的 Azure Cosmos DB 額度，這項設計限制了單一使用者的整體吞吐量。

在轉用 Habitat 和 Azure Cosmos DB 之前，我們擴展 Postgres 時經常面臨一個問題：來自極熱門組織或熱門索引鍵的大量請求，也就是單一租用戶產生不成比例的高負載，可能拖垮整個資料庫。我們共同投入大量心力來快取這些索引鍵，並在快取未命中時引入租約機制，避免未命中所產生的負載壓垮底層資料庫。

雖然文件記載的資料大小與吞吐量上限適用於邏輯分割區索引鍵，但實際執行限制的層級是實體分割區。實務上，這表示邏輯分割區無法達到 10,000 RU/s。它們必須與同一實體分割區中的所有其他邏輯分割區索引鍵，共用該實體分割區的額度。

因此，吵鬧鄰居會影響許多互不相關的邏輯分割區索引鍵，甚至讓處理小眾產品功能資料的工作負載，干擾核心登入與註冊流程。

單一實體分割區的吞吐量上限也會變動，取決於分配給 Azure Cosmos DB 容器的總吞吐量。容器佈建的吞吐量會大致平均分配到該容器的各個實體分割區。

隨著資料量增加，實體分割區會分裂，分割區總數隨之增加，但佈建的總吞吐量維持不變。結果就是，資料量越大，每個分割區實際可用的吞吐量上限反而越低。

對於最耗儲存空間、類似 Blob 儲存的使用情境，這會形成一種故障模式：即使請求速率與使用量保持穩定，光是儲存資料增加，就足以降低執行中工作負載可用的吞吐量容量。

使用獨立容器，有助於部分解決這些分割區索引鍵限制與吵鬧鄰居問題。採用獨立容器後，每個容器都能獲配自己的獨立實體分割區；只有同一容器內的不同工作負載，才可能成為吵鬧鄰居，或使用重疊的分割區索引鍵。缺點是佈建新容器仍有額外成本：每個容器都需要個別進行容量規劃。因此，我們希望只依合理的服務或使用情境界線建立容器。

對於最關鍵且需要強隔離的新使用情境，我們開始採用獨立的 Azure Cosmos DB 容器。此外，我們也透過指令碼，讓各容器佈建的總吞吐量隨實體分割區數量同步調整，以處理分割區吞吐量不足的問題。這兩項措施幫助我們避開了當時面臨的絕大多數問題。

然而，由於一開始使用的是預設容器，許多既有的關鍵使用情境若不進行資料移轉，就只能繼續留在其中。為了保護仍依賴共用預設容器中資料的關鍵服務，我們經常建議團隊為新服務或重大產品功能建立獨立容器。隨著規模擴大，預設容器承受的壓力日益增加，正式環境中的事件也越來越多。我們開始為所有新服務或大型產品功能佈建容器，單純為了避免預設容器承受更多負載。

這讓我們避免了許多全站中斷，將故障影響範圍限縮為個別功能或服務的效能下降與中斷。然而，佈建新容器的額外負擔，最終還是成了問題：

在原本共用的預設容器中，任何單一新使用情境從 0 QPS 成長到 100 萬 QPS，都不太可能大幅改變整體總使用量。但在獨立容器中，新使用情境從 0 成長到 100 萬 QPS，負載可能達到僅供內部試用時基準值的 1,000 倍。

採用專用容器後，團隊必須記得在推出產品前，依預期吞吐量預先佈建容器。產品團隊往往將功能發布到正式環境，卻忘了預先擴充容量，於是我們得在上線當天待在重大事件應變室裡，臨時設法擴充容器。

混合工作負載能平滑整體用量，這原本是多租用戶系統的核心優勢；但採用這種容器策略後，我們為了更好的隔離性，犧牲了這項優勢。

隨著時間推移，監控專用容器的使用量，也需要深入了解產品，才能掌握流量何時會轉移或成長。

我們可以提供基本的控制平面指令碼，依成長趨勢提高各容器佈建的吞吐量；但缺乏穩定的整體成長後，要正確擴充容量，基本上就得讓 OpenAI 的每個產品團隊都參與容量規劃。

這種做法無法隨組織規模擴展，因為各服務負責團隊對 Azure Cosmos DB 佈建工作的投入程度差異很大。

隨著組織成長，這些維運問題越來越難以應付。沒有單一的中央團隊統籌規劃，導致許多團隊規劃不周。因此，我們最終轉回多租用戶方案，並與 Azure 團隊密切合作，透過共用租用戶設計，為原先的多租用戶問題打造解決方案：

優先對最熱門的索引鍵限流，可防止吵鬧鄰居耗盡某個實體分割區的所有可用吞吐量。這能減輕吵鬧鄰居效應，避免單一熱門索引鍵波及全站。

依請求分級的 QoS，同樣能防止大量插入或資料擷取等離線工作負載，耗盡某個實體分割區的所有吞吐量。將這些工作負載的請求設為較低優先順序，就能先對它們限流，避免服務終端使用者、優先順序較高的互動式請求受到限流。

Azure Cosmos DB 原本就有無伺服器模式，能解決我們在佈建模式下面臨的分割區吞吐量不足問題。然而，它有個重大缺點：只能根據儲存使用量擴展，並將每個實體分割區的 RU 使用量限制在 5,000 RU/s。這雖然能解決分割區吞吐量不足的問題，卻也讓我們無法擴展 RU 用量高的使用情境。

Azure Cosmos DB 團隊為我們打造了改良版的無伺服器模式，讓每個實體分割區都能擴展至 1 萬 RU/s。除了根據儲存使用量分裂，也新增了依 RU 使用量分裂的機制，讓我們不再需要手動監控與擴充容器。

有了這些改進，我們得以回到使用單一共用容器，在維持工作負載隔離的同時，大幅簡化產品團隊事前與持續進行容量規劃的工作。此後數月，儘管產品開發加速，我們仍未發生任何資源佈建或吵鬧鄰居相關事件。

當公司成長到 OpenAI 這樣的規模，受控服務就不再那麼能「代為管理」了。許多工作負載在雲端供應商的基礎架構中，已屬於異常規模的案例。當 OpenAI 成為 Azure Cosmos DB 最大的使用者之一，要成功維運就需要不同的模式：共用測試、共用儀表板、直接的工程溝通管道，以及共同負責那些只會在我們這種規模下出現的故障模式。如今，我們最大的 Azure Cosmos DB 帳戶儲存了數十 PB 的資料，處理超過 2,000 萬 QPS。據我們所知，我們是唯一以這種規模部署 Azure Cosmos DB 的公司。

2024 年底的一次區域中斷事件，清楚說明了這種合作為何不可或缺。當時，我們其中一個最大的 Azure Cosmos DB 帳戶所在的 Azure 主要區域發生停電。在隨後的容錯移轉作業中，我們發現最大的幾個帳戶需要數小時才能切換到次要區域；我們和 Azure Cosmos DB 團隊都不曾在這樣的規模下測試過這項操作。

約一個月後，在將這些帳戶容錯回復至原始區域時，我們又觸發了另一次嚴重中斷。大量連線同時湧向原始區域，壓垮了該區域的 Azure Cosmos DB 閘道。閘道模式的 Azure Cosmos DB 用戶端在處理容錯移轉時有一項特殊行為：即使只有部分實體分割區移回原始區域，所有用戶端仍會立即與該區域建立連線並傳送請求。

每次中斷發生後，OpenAI 與 Azure 都依循各自的事件管理流程，找出多項根本原因並部署修正。但這些中斷其實是更大系統性問題的徵兆，反映出我們與 Azure Cosmos DB 團隊在維運和測試方式上的落差。起初，使用受控服務讓我們能快速推進，專注於業務目標。規模擴大後，受控服務能代為管理的程度降低，從設計到維運的每個層面，都需要與服務供應商深度整合。

如今，Habitat 與 Azure 工程團隊共同監控 Habitat 的每一層，從我們的服務層，一路深入 Azure Cosmos DB 的實體儲存層。我們使用一個規模與正式環境相當、但不承載正式服務的 Azure Cosmos DB 帳戶，進行操作與變更測試。我們共同測試並迭代 SDK，也一起訂定 Azure Cosmos DB 帳戶擴展與容量配置的最佳做法。雙方工程團隊可透過 Teams 直接聯繫，甚至建立了不必經過各層支援流程，就能直接呼叫對方值班人員的管道。

過去一年，我們投入大量協作工作，提升 Azure Cosmos DB 控制平面與閘道的擴展能力。我們在閘道中加入負載保護機制，並快取各種 Azure Cosmos DB 中繼資料，以保護其中繼資料分割區；透過連線集區與提高連線重用率，減輕 Python habitat-service 程序群帶來的壓力；盡可能將工作負載部署在同一位置，並透過不同的 VPC 將關鍵工作負載與離線工作負載隔離。

這種深度的協同開發，對過去一年 Azure Cosmos DB 的穩定性至關重要。任何規模夠大或重要性夠高的系統，都需要這樣的團隊合作：打破權責壁壘，跨越組織界線協作。

如第一部分所述，我們的核心理念是：先讓系統能用，再讓它變快，最後降低成本。可靠性第一，其次是效能，最後是效率。Habitat 已成為 OpenAI 的關鍵基礎架構，因此首要任務就是確保它可靠運作。2025 年，隨著系統趨於穩定，OpenAI 的業務也拓展至全球，延遲成了使用者和產品團隊面臨的下一個瓶頸。

運算與儲存資源經常位於不同區域，因此無法避免跨區域請求。

資料儲存位置與請求處理位置不同，延遲也會有很大的差異。為了提升 Habitat 請求的效能，產品開發人員得額外加入用戶端快取、批次處理請求、盡量減少資料庫讀寫，並盡可能將工作移出關鍵路徑。這雖然催生了一些有意思的產品設計，讓產品更能承受資料庫問題，卻也增加了產品複雜度、拖慢了迭代速度，未能達成 Habitat 的初衷：讓開發人員無須深入了解資料庫，就能快速開發產品。

這是我們 2026 年的重點工作之一。我們已制定分層策略，最佳化占 Habitat 請求總量 90% 以上的讀取請求效能：

我們在全球不同 Azure 區域設有多個 Azure Cosmos DB 帳戶，以滿足有資料駐留需求的使用者。即使使用者沒有嚴格的資料駐留需求，將資料存放在使用者附近，也能降低延遲、改善體驗。

實務上，受限於雲端的實體容量，除了資料駐留的使用情境之外，我們還無法普遍做到這一點。我們的資料集規模龐大，許多區域無法提供足夠的儲存空間，來容納與其使用者流量占比相應的資料量。

在資料中心容量、電力或冷卻能力有限的區域，我們有時必須直接取捨：保留容量供同地儲存使用，以降低 Habitat 延遲；或將容量用於增加服務請求的運算資源，並把儲存請求導向更遠的位置。

因此，資料放置決策往往涉及兩方面的產品取捨：A）最佳化不同產品與使用者群體的延遲，以及 B）實際可用的儲存與運算容量。

對於延遲要求最嚴格的工作負載，例如每個請求都需要的驗證中繼資料，我們使用具備多個次要區域、高度複寫的 Azure Cosmos DB 帳戶，縮短運算端與 Habitat 之間的往返時間（RTT）。有些帳戶會複寫到我們處理流量的全部 40 個 Azure 區域；其他帳戶則至少複寫到各大洲的一個區域。

為了在複寫拓撲不同的帳戶之間移動資料集，我們不得不比原先預期更早，在 Habitat 中建置一個對使用端透明的資料移動與路由層。

不過，這個方法終究也受容量限制，因此只能用於少數精選的資料集。

Habitat 的工作負載以讀取為主，應用程式不斷取得設定、狀態及其他屬性；其中，相對少量、經常存取的資料類型所構成的工作集，占了極大比例的流量。這讓系統特別適合採用分散式快取。快取在單一區域的基礎架構中就能提升效能，而在跨區域運作時，效益更為顯著，因為它能「隱藏」跨區域延遲。

我們已在 Habitat 中整合了分散式旁路快取層。它會將近期存取的物件與邊的副本，儲存在基礎架構中的 Valkey 伺服器上，位置靠近處理使用者請求的地方。這類快取通常會透過存留時間（TTL），在命中率與資料過時程度之間取捨。較短的 TTL 能降低資料過時程度，但也會削弱快取效益，因為項目很快就會過期移出快取，必須更頻繁地重新擷取。較長的 TTL 則能提高命中率，卻會持續較長時間提供過時資料，造成不佳的使用者體驗與難以預測的產品行為。

另一種做法，是在應用程式寫入同一份底層資料時，明確執行快取失效操作。這能大幅提升快取資料的新鮮度，但要正確實作並不容易。它仍會受到部分失敗等多種邊界情況影響，讓過時資料繼續留在快取中。多區域部署會讓這些問題更加嚴重：跨區域網路較不可靠，快取更新也可能與底層儲存的複寫產生競態條件。搭配 TTL 可以限制資料過時的最長時間，但仍無法避開前述 TTL 本身的取捨。

我們借鏡 Meta 的 TAO 等系統，採用了更進階的快取失效方法。Habitat 的整合式快取透過 Azure Cosmos DB 的變更摘要進行變更資料擷取（CDC），在數秒內將失效通知傳播到全球，同時達到高命中率與低資料過時程度。我們基礎架構中的一項服務會讀取此變更摘要，在底層資料更新時，對本地快取執行失效操作。如此一來，下次讀取資料時就會發生快取未命中，並以最新版本的資料重新填入快取。

我們也將程式碼改用比原本 Python 效能更好的 Rust 重寫，消除 Habitat 服務本身的額外負擔，大幅降低延遲。

這些改進共同將全球整體讀取延遲的 p50 從約 120 毫秒降至約 10 毫秒。自今年稍早開始專注改善效能以來，讀取速度已提升至原來的 12 倍。

雖然快取大幅降低了延遲中位數，但最慢的請求仍需從底層儲存擷取未快取的資料，而且往往要跨越相距遙遠的區域。隨著更多容量上線，以及儲存效率提升，我們計劃解決更根本的挑戰：從一開始就將資料放在更靠近存取來源的位置。

可靠且可擴展的 CDC，也就是將資料庫變更傳播至下游系統的能力，不只是 Habitat 快取策略中的關鍵元件。每秒從數千個容器、數百萬個容器分割區擷取的數百萬筆變更，會流經一百多個 Kafka 主題，同時支援最終一致性的次要索引、資料移動管線、離線分析，以及其他即時產品功能。隨著底層基礎架構拓展至全球，監聽資料列變更也變得越來越複雜。如果用戶端想註冊回呼函式，在其資料類型的資料列每次變更時執行，就必須先確認資料位於哪些 Cosmos 帳戶與容器、各區域中哪個 CDC 服務部署正在監聽這些容器，並適當擴展 CDC 服務的背景工作程序群、Kafka 及其取用端；這還只是其中一部分工作。我們的 CDC 平台旨在讓產品開發人員無須處理這些細節，改為提供簡單的介面：用戶端只要註冊想在資料列變更時呼叫的函式，所有底層串接與擴展工作都由我們處理。

內部控制平面會持續確保所有必要容器的變更都納入擷取，選擇要讀取的 Cosmos 區域，並將工作有效分配給跨多個地理區域的數千個背景工作程序。透過使用複本區域，並以較低優先順序讀取變更摘要，能保護對延遲敏感的 Habitat 流量，避免受到背景擷取工作負載影響。在如此龐大的程序群中，背景工作程序當機、容器問題、租約儲存錯誤、無效設定，以及目的端故障，都是持續發生的狀況。我們強化了 CDC 背景工作程序的生命週期與租約處理機制，隔離不同串流間的故障，並為設定變更與部署建立防護措施。我們使用無法傳遞佇列，避免永久性傳遞失敗造成隊首阻塞。發生區域中斷時，我們會將讀取端切換到其他 Cosmos 區域，讓系統持續運作。在我們的規模下，甚至必須修改 Azure 的 CDC SDK，將檢查點先在記憶體中批次彙整，再定期寫出，以提升檢查點機制的效率。

雖然 Habitat 內部使用 Azure Cosmos DB 的方式相當複雜，但它的核心價值始終是讓產品開發人員無須關心基礎架構細節，藉此加快產品開發；我們的 CDC 平台也不例外。

我們刻意讓儲存 API 維持精簡、持續擴展 Python 服務，並優先處理最迫切的工程挑戰，讓小型團隊也能支撐快速成長的儲存平台。我們先專注於關鍵產品流量的可靠性，再改善全球使用者的讀取效能，最後提升大規模維運的效率。這種做法讓我們得以支援快速成長與新使用情境，同時提升可靠性、效能及產品開發速度。

為了擴展 Habitat 與對話儲存，服務接下來的 10 億名使用者，我們需要克服在更大規模下，跨基礎架構複寫資料的難題。為了提前因應，我們一直在自主開發客製化的 EB 級線上儲存系統，專為體積龐大的 Habitat 資料類型進行最佳化。這個開發中的系統，結合了 Rockset 的 RocksDB Cloud 核心與以 Raft 為基礎的複寫機制。它採用與 Azure Cosmos DB 相同的文件資料模型，但使用分離式儲存與實體複寫，以降低峰值 QPS 為代價，減少所需的快閃儲存容量。

如果您有興趣參與這類挑戰規模極限的資料基礎架構工作，歡迎查看我們的職缺⁠。