主要要點

  • 幣安利用容量管理來應對高波動性造成的計劃外流量激增，確保及時提供充足且符合業務需求的基礎設施和計算資源。

  • Binance 在生產環境（而非暫存環境）中進行負載測試，以獲得準確的服務基準。此方法有助於驗證我們的資源分配是否足以滿足定義的負載。

Binance 的基礎設施處理大量流量，維護用戶可以依賴的服務需要適當的容量管理和自動負載測試。

爲什麼幣安需要專門的容量管理流程？

容量管理是系統穩定性的基礎。它需要以正確的成本根據當前和未來的業務需求合理調整應用程序和基礎設施資源的大小。爲了實現這一目標，我們構建了容量管理工具和管道，以避免過載並幫助企業提供流暢的用戶體驗。

加密貨幣市場通常比傳統金融市場更頻繁地經歷波動。這意味着幣安的系統必須承受用戶對市場波動做出反應時不時出現的流量激增。通過適當的容量管理，我們可以保持足夠的容量來滿足一般業務需求和這些流量激增的情況。這一關鍵點正是幣安容量管理流程獨特且具有挑戰性的原因。

讓我們看看哪些因素經常會阻礙這一過程並導致服務緩慢或不可用。首先，我們遇到過載，這通常是由於流量突然增加造成的。例如，這可能是營銷活動、推送通知，甚至是 DDoS（分佈式拒絕服務）攻擊造成的。

 流量激增和容量不足會影響系統功能，因爲：

  1. 服務承擔的工作越來越多。

  2. 響應時間增加到無法在客戶端超時內響應任何請求的程度。這種性能下降通常是由於資源飽和（CPU、內存、IO、網絡等）或服務本身或其依賴項的長時間 GC 暫停造成的。

  3. 結果是該服務將無法及時處理請求。

分解流程

既然我們已經討論了容量管理的一般原則，讓我們看看幣安如何將其應用於其業務。以下是容量管理系統的架構和一些關鍵工作流程。

  • 通過從配置管理數據庫 (CMDB) 獲取數據，我們生成基礎設施和服務配置。這些配置中的項目是容量管理對象。

  • 指標收集器從 Prometheus 獲取業務和服務層數據、從基礎設施監控獲取資源層指標、從調用跟蹤分析系統獲取跟蹤信息。指標收集器將數據存儲在容量數據庫 (CDB) 中。

  • 負載測試系統對服務進行壓力測試，並將基準數據存儲在CDB中。

  • 聚合器從 CDB 獲取容量數據，並按每日和歷史最高 (ATH) 維度進行聚合。聚合後，它將聚合數據寫回到 CDB。

  • 後端API通過處理來自CDB的數據，爲容量儀表板、警報和報告提供接口，以及其他用於集成的API和相關容量數據。

  • 利益相關者通過容量儀表板、警報和報告瞭解容量情況。他們還可以使用其他相關係統，包括使用 Swagger 的容量管理系統提供的 REST API 監控獲取服務的容量數據。

戰略

我們的容量管理和規劃策略依賴於峯值驅動處理。峯值驅動處理是服務資源（Web 服務器、數據庫等）在峯值使用期間所承受的工作負載。

2023 年 3 月美聯儲加息後流量激增

我們分析週期性峯值，並利用它們來推動產能軌跡。與任何受峯值驅動的資源一樣，我們希望找出峯值何時發生，然後探索這些週期內實際發生的情況。

除了防止過載之外，我們考慮的另一個重要事項是自動擴展。自動擴展通過使用更多服務實例動態增加容量來處理過載。然後分配多餘的流量，並且單個服務實例（或依賴項）處理的流量仍然可控。

自動縮放有其用武之地，但單獨處理過載情況則有不足之處。它通常無法對流量的突然增加做出足夠快的反應，只有在流量逐漸增加時才能發揮最佳作用。

測量

測量在幣安的容量管理工作中起着至關重要的作用，收集數據是我們的第一步測量步驟。基於信息技術基礎架構庫 (ITIL) 標準，我們在容量管理子流程中收集數據進行測量，即：

  1. 資源 - 由應用程序/服務使用情況驅動的 IT 基礎設施資源消耗。重點關注物理和虛擬計算資源的內部性能指標，包括服務器 CPU、內存、磁盤存儲、網絡帶寬等。

  2. 服務。業務活動產生的應用程序級性能、SLA、延遲和吞吐量指標。重點關注基於用戶對服務的感受的外部性能指標，包括服務延遲、吞吐量、峯值等。

  3. 業務。收集衡量目標應用程序處理的業務活動的數據，包括訂單、用戶註冊、付款等。

僅基於基礎設施資源利用率的容量管理將導致不準確的規劃。這是因爲它可能無法代表推動我們基礎設施容量的實際業務量和吞吐量。

預定的活動是進一步討論這一問題的絕佳場所。參加幣安直播上的 Watch Web Summit 2022，分享高達 15,000 BUSD 的 Crypto Box 獎勵活動。除了底層資源和服務層指標外，我們還需要考慮業務量。我們根據業務指標（例如估計的直播觀衆數量、Crypto Box 的最大飛行中請求、端到端延遲和其他因素）進行容量規劃。

收集數據後，我們的容量管理流程會彙總並總結針對特定容量驅動因素收集的大量數據點。指標的彙總值是一個單一值，可用於容量警報、報告和其他與容量相關的功能。

我們可以將多種數據聚合方法應用於週期性數據點，例如總和、平均值、中位數、最小值、最大值、百分位數和歷史最高值（ATH）。

我們選擇的方法決定了容量管理流程和由此產生的決策的輸出。我們根據不同的場景選擇不同的方法。例如，對於關鍵服務和相關數據點，我們使用最大值方法。爲了記錄最高流量，我們使用 ATH 方法。

對於不同的用例，我們使用不同的粒度類型進行數據聚合。在大多數情況下，我們使用分鐘、小時、天或 ATH。

  • 我們以微小的粒度來測量服務的工作量，以便及時發出過載警報。

  • 我們使用每小時彙總數據來構建每日數據，並將每小時數據彙總來記錄每日峯值。

  • 通常我們使用每日數據來製作容量報告，並利用 ATH 數據進行容量建模和規劃。

容量管理的核心指標之一是服務基準測試。這有助於我們準確衡量服務性能和容量。我們通過負載測試獲得服務基準，稍後我們將更詳細地介紹這一點。

基於優先級的容量管理

到目前爲止，我們已經瞭解瞭如何收集容量指標並聚合不同粒度類型的數據。另一個需要討論的關鍵領域是優先級，這在警報和容量報告的背景下很有用。對 IT 資產進行排名後，有限的基礎設施使用和計算資源將優先考慮，並首先提供給關鍵服務和活動。

定義服務和請求關鍵性的方法有很多種。一個有用的參考資料是 Google。在 SRE 書中。他們將關鍵性級別定義爲 CRITICAL_PLUS、CRITICAL、SHEDDABLE_PLUS 等。同樣，我們定義了多個優先級別，例如 P0、P1、P2 等等。

我們定義優先級別如下：

  • P0：對於最關鍵的服務和請求，如果它們失敗，將導致嚴重的、用戶可見的影響。

  • P1：對於那些會對用戶產生可見影響，但影響小於 P0 的服務和請求。P0 和 P1 服務預計會配置足夠的容量。

  • P2：這是批處理作業和離線作業的默認優先級。這些服務和請求如果部分不可用，可能不會對用戶造成可見的影響。

什麼是負載測試？爲什麼我們在生產環境中使用它？

負載測試是一種非功能性軟件測試過程，其中應用程序的性能在特定工作負載下進行測試。這有助於確定應用程序在被多個最終用戶同時訪問時的行爲方式。

在幣安，我們創建了一個解決方案，使我們能夠在生產環境中運行負載測試。通常，負載測試是在暫存環境中運行的，但根據我們的總體容量管理目標，我們無法使用此選項。在生產環境中進行負載測試使我們能夠：

  • 收集實際負載條件下我們服務的準確基準。

  • 增強對系統及其可靠性和性能的信心。

  • 在生產環境中出現系統瓶頸之前識別它們。

  • 實現對生產環境的持續監控。

  • 通過定期進行的標準化測試周期實現主動容量管理。

下面您可以看到我們的負載測試框架和一些關鍵要點：

  • Binance 的微服務框架有一個基礎層來支持配置驅動和基於標誌的流量路由，這對於我們的 TIP 方法至關重要。

  • 我們採用自動金絲雀分析 (ACA) 來評估我們正在測試的實例。它會比較監控系統中收集的關鍵指標，因此如果發生任何意外問題，我們可以暫停/終止測試，以最大限度地減少對用戶的影響。

  • 在負載測試期間收集基準和指標，以生成有關行爲和應用程序性能的數據洞察。

  • 通過開放API，在容量管理、質量保證等多種場景下共享有價值的性能數據，構建開放的生態系統。

  • 我們創建自動化工作流程，從端到端測試的角度協調所有步驟和控制點。我們還提供與其他系統集成的靈活性，例如 CI/CD 管道和操作門戶。

我們的生產測試 (TIP) 方法

傳統的性能測試方法（在具有模擬或鏡像流量的暫存環境中運行測試）確實提供了一些好處。 但是，在我們的環境中，部署類似於生產的暫存環境有更多缺點：

  • 這幾乎使基礎設施成本和維護工作量翻了一番。

  • 在生產中進行端到端工作非常複雜，特別是在跨多個業務部門的大規模微服務環境中。

  • 它增加了更多的數據隱私和安全風險，因爲不可避免地，我們可能需要在暫存過程中複製數據。

  • 模擬流量永遠不會複製生產中實際發生的情況。在暫存環境中獲得的基準不準確且價值較低

生產測試（也稱爲 TIP）是一種右移測試方法，其中在生產環境中測試新代碼、功能和版本。我們採用的生產負載測試非常有益，因爲它可以幫助我們：

  1. 分析系統的穩定性和魯棒性。

  2. 發現不同流量水平、服務器規格和應用程序參數下應用程序的基準和瓶頸。

基於 FlowFlag 的路由

我們嵌入在微服務基礎框架中的基於 FlowFlag 的路由是實現 TIP 的基礎。這適用於特定情況，包括使用 Eureka 服務發現進行流量分配的應用程序。

如圖所示，幣安網絡服務器作爲入口點，使用 FlowFlag 標頭標記配置中指定的一定百分比的流量，在負載測試期間，我們可以選擇特定服務的一臺主機並將其標記爲配置中的目標 perf 實例，然後那些標記的 perf 請求在到達服務進行處理時最終將被路由到 perf 實例。

  • 它是完全配置驅動和熱加載的，我們可以使用自動化輕鬆調整工作負載百分比，而無需部署新版本

  • 它可以廣泛應用於我們的大多數服務，因爲該機制是網關和基礎包的一部分

  • 單點變更還意味着輕鬆回滾以降低生產風險

在將我們的解決方案轉變爲更加雲原生的同時，我們也在探索如何建立類似的方法來支持公共雲提供商或 Kubernetes 提供的其他流量路由。

自動化金絲雀分析，最大限度降低用戶影響風險

金絲雀部署是一種部署策略，旨在降低將新軟件版本部署到生產環境中的風險。它通常涉及向一小部分用戶部署軟件的新版本（稱爲金絲雀版本），同時部署穩定運行的版本。然後，我們在兩個版本之間拆分流量，以便將一部分傳入請求轉移到金絲雀版本。

然後，通過所謂的金絲雀分析來評估金絲雀版本的質量。這會比較描述新舊版本行爲的關鍵指標。如果指標明顯下降，則會中止金絲雀版本，並將所有流量路由到穩定版本，以最大限度地減少意外行爲的影響。

我們使用相同的概念來構建我們的自動負載測試解決方案。該解決方案使用 Kayenta 平臺通過 Spinnaker 進行自動金絲雀分析 (ACA)，以實現自動金絲雀部署。遵循此方法時，我們的典型負載測試流程如下：

  1. 通過工作流程，我們按照指定的方式逐步向目標主機添加流量負載（例如 5%、10%、25%、50%），直到達到其臨界點。

  2. 在每次負載下，使用 Kayenta 重複運行金絲雀分析一段時間（例如 5 分鐘），以比較被測主機的關鍵指標，以預加載期爲基線，以當前後加載期爲實驗。

  3. 比較（金絲雀配置模型）重點檢查目標主機是否：

    1. 達到資源限制，例如 CPU 使用率超過 90%。

    2. 失敗指標顯著增加，例如錯誤日誌、HTTP 異常或速率限制拒絕。

    3. 核心應用程序指標仍然合理，例如 HTTP 延遲小於 2 秒（可針對每個服務進行定製）

  4. 對於每次分析，Kayenta 都會向我們提供一份報告來表明結果，並且一旦失敗，測試就會立即終止。

  5. 這種故障檢測通常需要不到 30 秒的時間，大大降低了影響最終用戶體驗的可能性。

實現數據洞察

收集有關前面描述的所有流程和測試執行的足夠信息至關重要。最終目標是提高系統的可靠性和穩健性，而如果沒有數據洞察，這是不可能的。

總體測試摘要會捕獲主機能夠處理的最大負載百分比、峯值 CPU 使用率以及主機的 QPS。在此基礎上，它還會根據服務的最高 QPS 估算出我們可能需要部署的實例數量，以滿足我們的容量預留。

其他有價值的分析信息包括軟件版本、服務器規格、部署數量以及監控儀表板的鏈接，我們可以在儀表板上回顧測試期間發生的情況。

基準曲線表明過去三個月內性能的變化情況，因此我們可以發現與特定應用程序版本相關的任何可能的問題。

CPU 和 QPS 趨勢顯示 CPU 使用率與服務器必須處理的請求量之間的關係。此指標可幫助估算服務器對傳入流量增長的餘量。

API 延遲行爲可以捕獲前五個 API 在不同負載條件下的響應時間變化情況。然後，我們可以根據需要在單個 API 級別優化系統。

API 負載分佈指標幫助我們瞭解 API 組成如何影響服務性能，並對改進領域提供更多見解。

規範化和產品化

隨着我們的系統不斷髮展和改進，我們將繼續跟蹤和改進服務的穩定性和可靠性。我們將通過以下方式繼續努力：

  • 對關鍵服務制定定期的、既定的負載測試計劃。

  • 自動負載測試作爲我們 CI/CD 管道的一部分。

  • 提高整個解決方案的產品化，爲更廣泛的組織大規模採用做好準備。

限制

當前的負載測試方法存在一些侷限性：

  • 基於 FlowFlag 的路由僅適用於我們的微服務框架。我們希望通過利用雲負載均衡器或 Kubernetes Ingress 的常見加權路由功能將該解決方案擴展到更多路由場景。

  • 由於我們根據生產環境中的實際用戶流量進行測試，因此我們無法針對特定 API 或用例執行功能測試。此外，對於流量非常小的服務，由於我們可能無法確定其瓶頸，因此價值會受到限制。

  • 我們針對單個服務執行這些測試，而不是覆蓋端到端調用鏈。

  • 生產測試有時會在發生故障時影響真實用戶。因此，我們必須具有完全自動化的故障分析和自動回滾功能。

結束語

我們必須考慮激增流量的情況，以防止系統過載並確保其正常運行時間。這就是我們構建本文中描述的容量管理和負載測試流程的原因。總結一下：

  1. 我們的容量管理以峯值爲驅動力，嵌入到服務生命週期的每個階段，通過測量、設置優先級、警報和容量報告等活動防止超負荷。與典型的容量管理情況相比，這最終使得幣安的流程和需求獨一無二。

  2. 通過負載測試獲得的服務基準是容量管理和規劃的重點。它準確地確定了支持當前和未來業務需求所需的基礎設施資源。這最終必須在生產中通過幣安構建的獨特解決方案來執行，該解決方案使我們能夠滿足我們的特定需求。

綜合以上所有，我們希望您能夠看到，良好的規劃和完善的框架有助於打造幣安用戶所瞭解和享受的服務。

參考

  1. Dominic Ogbonna，《容量管理從 A 到 Z：實施企業 IT 監控和容量規劃的實用指南》，第 4 章、第 6 章

  2. Luis Quesada Torres、Doug Colish，容量管理的 SRE 最佳實踐

  3. Alejandro Forero Cuervo、Sarah Chavis，Google SRE 書籍，第 21 章 - 處理過載

進一步閱讀

  • （博客）幣安賬本如何增強您的幣安體驗

  • （博客）介紹幣安 Oracle VRF：下一代可驗證隨機性

  • （博客）幣安加入 FIDO 聯盟，爲 Passkey 實施做準備