Facebook為何放棄ZooKeeper轉用自研配置管理系統？

作者 | Facebook Code

譯者 | 小大非

Facebook 分布在不同地理區域的數據中心承載著數百萬台伺服器，每天還會向伺服器推送數千個配置更改，伺服器執行數萬億次配置檢查是相當常見的。作為取代 ZooKeeper 的新對等系統，位置感知分發系統 (Location-Aware Distribution, LAD) 是 Facebook 設計面向未來應用的一個系統，現已經部署應用處理對數百萬台伺服器的配置更改的分發任務。

Facebook 的基礎設施由許多分布在不同地理區域的數據中心組成，它們承載著數百萬台伺服器。這些伺服器運行許多系統，從前端 web 伺服器到新聞摘要聚合器，再到我們的消息和實時視頻應用程序。除了常規的代碼推送之外，我們每天還會向伺服器推送數千個配置更改。因此，我們的伺服器執行數萬億次配置檢查是相當常見的。配置檢查的其中一項是 web 伺服器個性化用戶體驗，例如它文本對一個用戶以英文顯示，對另一個用戶以葡萄牙語顯示。

在本文中，我們將介紹位置感知分發系統 (Location-Aware Distribution，LAD)，這是一個新的對等系統，用於處理對數百萬台伺服器的配置更改的分發。我們發現，LAD 在發布大型更新方面明顯優於之前的程序系統，支持文件現在是 100MB，而之前為 5MB，同時每個發布者支持約 40000 個訂閱者，而之前為 2500 個訂閱者。

在 LAD 之前，我們如何分發配置?

正如我們在 SOSP 2015 年的論文中所描述的，Facebook 的配置管理系統 (稱為 Configerator) 使用開源的分散式同步服務 ZooKeeper 來分發配置更新。

ZooKeeper 中的所有數據都存儲在一個統一的數據存儲中。每個 ZooKeeper 節點 (znode) 可以包含數據或其他子 znode。可以使用分層路徑 (例如 /root/znode/my-node) 訪問每個 znode。從 ZooKeeper 中讀取數據的客戶端可以在 znode 上設置觀察器；當 znode 被更新時，ZooKeeper 會通知這些客戶端，以便他們可以下載更新。

ZooKeeper 強大的數據一致性和嚴格的分發保證是我們可靠地擴展和運行系統的關鍵。然而，隨著我們的基礎設施發展到數百萬台機器，我們發現 ZooKeeper 變成了瓶頸。

• 嚴格的排序保證

  ：ZooKeeper 的一個關鍵特性是它提供了嚴格的排序保證，這意味著寫操作總是被一個線程按順序處理。為了確保讀操作不被中斷，ZooKeeper 會交叉進行讀和寫處理。我們發現，對特定 znode 的更新可能會觸發大量的監控，而這反過來又可能觸發大量來自客戶端的讀取動作。一些這樣的寫操作可能導致更新阻塞。




• 巨大的集群

  ：當數據 znode 被更新時，ZooKeeper 會通知所有感興趣的客戶端。當傳入的客戶端請求大於 ZooKeeper 處理能力時，這可能會引發一個巨大的集群問題。




• 大型更新可能會使 NICs 飽和

  ：我們的一些配置文件的大小最多為 5 MB。給定一個 10gb /s NIC，我們發現一個盒子只能服務大約 2000 個客戶。如果經常更新這樣的文件，我們發現更新文件可能需要 10 秒的時間傳播到所有需要的客戶端。

為未來設計一個系統

當我們開始設計新的分發系統時，我們提出了幾個要求，包括：

• 支持大型更新：將文件大小從 5 MB 增加到 100 MB。




• 獨立的數據存儲：ZooKeeper 將一個數據存儲與它的分發框架結合在一起。我們希望將數據存儲和分發組件分開，以便我們能夠分別對每個組件進行大小和規模的調整。




• 分發能力：可以支持數百萬客戶。




• 延遲：將發布延遲限制在 5 秒以內。




• 配置文件：相較於我們以前基於 zookeeper 的系統，這個系統支持 10x 配置文件的數量，




• 可以滿足巨量集群和更新率激增的情況。

介紹位置感知分發系統 (LAD)

LAD 由兩個主要組件組成，它們通過 Thrift RPC 相互通信:

• 代理：每個機器上運行的守護進程，為任何有需要的應用程序提供配置文件。




• 分發器：該組件擔當兩個角色。首先，它對數據存儲進行輪詢以獲取新的更新。其次，它為一組對更新感興趣的代理構建一個分發樹。

上圖顯示了 LAD 如何將代理組織到一個分發樹中，它本質上是一個組織良好的對等網路。如步驟 1 所示，代理代表運行在該框上的應用程序向分發伺服器發送「訂閱」請求。分發伺服器通過發送「添加對等點」請求 (步驟 2) 將代理添加到分發樹中。一旦代理被添加到樹中，它就開始接收元數據 (步驟 3) 更新。這些內容被過濾，代理通過內容請求進行響應 (步驟 4)。如果父類擁有內容，它將立即將其發送給子類；否則，它將從父伺服器下載內容 (步驟 5)。

通過對樹的使用，LAD 確保更新只推送給感興趣的代理，而不是隊列中的所有機器。此外，父機器可以直接向子機器發送更新，從而確保根伺服器附近的任何一台機器都不會過載。

我們在使用 ZooKeeper 上的一個重要經驗是將元數據更新和發布從內容分發中分離出來。LAD 的架構依賴於代理不斷接收元數據更新。如果每個代理都接收所有元數據更新，那麼請求的數量就會太高。我們通過使用 shards 來解決這個問題：我們沒有將整個數據樹作為一個分發樹的一部分，而是將它分割成較小的分發樹，每個分發樹都服務於數據樹的一部分。

我們實現分片設計的方法是讓每個分片位於目錄結構中的一個特定點，並遞歸地包含它下面的所有對象。分片為訂閱提供了一個可靠的媒介：它限制了樹的總數，同時平衡了每個代理接收的元數據量。

控制數據流

控制平面 (上圖左) 是分發者和每個訂閱者之間的輕量級的 Thrift RPC。分發伺服器使用它來發送樹命令，這些命令通知父節點與其相關的新子節點，並檢查訂閱者的活躍度。訂閱伺服器還使用控制平面向分發伺服器發送訂閱請求。分發伺服器將這些請求映射到該訂閱所屬的分片，並將訂閱伺服器添加到分發樹中。

數據流平面 (在上圖右側) 是位於分發樹對等點間的 Thrift RPC，它任務非常艱巨。父節點用它向子節點發送來自分發伺服器的元數據更新。數據流平面也會被用來接收來自子節點的內容請求。

擁有獨立的控制和數據流平面後，每個分發伺服器可以處理大約 40,000 個訂閱者；而 ZooKeeper 只能處理大約 2500 個訂閱者。

經驗教訓

我們在構建和部署 LAD 時學到了一些有用的經驗。以下是一些重點總結:

• 工具化和可監控對於生產部署至關重要。從經驗來看，基於 P2P 的系統在操作和調試方面很具有挑戰性，因為不清楚給定請求的發送或接收路徑中有哪些節點。




• 故障提醒和災備測試在規模上是至關重要的。除了文檔化良好的操作過程之外，我們還發現運行一些測試用例及開發策略，有利於在出現問題時有效地做出反應。具體來說，我們運行了一系列測試，引入了各種類型的應用程序、主機、網路和集群級別的故障，以在不影響任何客戶機的情況下驗證 LAD 的彈性。這是一次令人滿意的過程，因為我們發現了程序和工具中的 bug 及不足點。




• 連續和定期測試對系統的長期可靠性至關重要。僅僅只將上面列出的測試運行一次是不夠的，因為在 Facebook 上事情發展變化很快，關於系統或工具的假設可能不會一直成立。我們正在對測試過程進行自動化，以便能夠及時發現並處理系統產生的問題。

LAD 下一步規劃是怎樣的?

現在，作為配置管理系統的數據分發框架，LAD 已經被部署到生產環境中。我們也在評估發現其他優秀的大規模內容分發應用程序。

參考鏈接：

https://research.fb.com/publications/holistic-configuration-management-at-facebook/

https://code.fb.com/data-infrastructure/location-aware-distribution-configuring-servers-at-scale/

今日薦文

點擊下方圖片即可閱讀

阿里巴巴為什麼不用 ZooKeeper 做服務發現？

在進入機器學習和人工智慧的時代，大量數據的彙集、廉價的存儲、彈性計算和演算法的進步，尤其是在深度學習的研究，促使企業的基礎架構平台不斷創新，為智能系統提供構建模塊。12 月 7 日北京 ArchSummit 會議，正在邀請菜鳥網路、百度、Netflix 的專家來分享相應的技術沉澱，希望對大家有幫助。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！