Cloudflare

用 Zstandard 與 Pingora 節省 PB 級快取儲存:Cloudflare 的 Cache Transcoding 原型

Cloudflare 工程實習生打造 Cache Transcoding 原型,在 Pingora 快取內以 Zstandard 壓縮文字資產,用少量 CPU 換取可觀的儲存與跨資料中心頻寬節省。本文解析其取捨、設計與測試結果。

用 Zstandard 與 Pingora 節省 PB 級快取儲存:Cloudflare 的 Cache Transcoding 原型 — 文章封面

記憶體成本持續攀升,RAM 與硬碟價格在過去一年大幅上漲。對於營運大規模分散式儲存產品(例如 CDN)的 Cloudflare 而言,如何更有效率地運用既有記憶體,成為維繫服務的關鍵。

Cloudflare 工程實習生(參與 1.1.1.1 Intern Program)在實習期間打造了一個名為 Cache Transcoding 的原型系統,並在官方部落格公開了初步成果。這個系統在 Pingora 架構內,於快取寫入前以 Zstandard(zstd)壓縮符合條件的資產,換取儲存空間與跨資料中心頻寬的顯著節省。

壓縮的取捨:少量 CPU 換取可觀儲存

Cache Transcoding 的核心概念很直接:當一個符合條件的回應進入快取時,先以 zstd 編碼再寫入磁碟;資產在快取生命週期內維持壓縮狀態,並以壓縮形式在 Tiered Cache 層級間傳輸;直到要回應客戶端前才解碼。

根據 Cloudflare 的初步測試,這項編碼平均可將符合條件的資產縮減至原始磁碟大小的三分之一。代價是 CPU 使用率小幅上升,但 Cloudflare 認為這是值得的交易——編碼成本只在資產進入快取時支付一次,而儲存與頻寬的節省則在每次資產被重複使用時持續發生。

這個原型採用 zstd level 3,在壓縮率與速度間取得平衡。Cloudflare 先前測試顯示,zstd 壓縮速度比 Brotli 快 42%,且檔案大小幾乎相同;相較於 gzip,在相近速度下可產生小 11.3% 的檔案。

並非所有內容都值得壓縮

Cache Transcoding 並非壓縮所有內容。圖片、影片與字型通常已壓縮過,重複壓縮只會浪費 CPU。在 Cloudflare 的流量樣本中,這類媒體佔請求數 21.4%,卻佔位元組數 63.3%。

真正值得壓縮的是可壓縮的文字內容,例如 HTML、JSON、CSS 與 JavaScript。這些內容佔請求數 67.3%,位元組數 22.3%,其中約 71% 以未壓縮形式(Content-Encoding 未設定)抵達,且壓縮效果良好。在受控測試語料中,符合條件的資產壓縮率約為 2.8 倍。

因此,原型設定了嚴格的資格檢查:僅處理 200 OK 回應,且 Content-Encoding 未設定、Content-Type 為可壓縮文字、Content-Length 已知且至少 4 KiB。小於 4 KiB 的請求被排除,因為降低門檻只會增加每個物件的開銷,卻無法節省更多儲存空間。

設計細節:編碼一次,多次受益

Cache Transcoding 的運作流程如下:

  • 快取未命中:Pingora 代理在寫入磁碟前以 zstd 編碼 body,中繼資料記錄壓縮狀態並保留原始內容長度。回應離開代理前會解碼回原始表示。
  • 快取命中:從磁碟讀取 zstd 物件並解碼。若使用 Tiered Cache,壓縮表示會從上層傳輸至下層,僅在客戶端面向的 hop 解碼。
  • 完整未命中:上層從來源取得原始位元組,編碼一次後以 zstd 儲存,並以壓縮形式傳輸至下層。下層同樣儲存 zstd 表示,再於請求路徑解碼。
  • 下層未命中但上層已有物件:來源不參與,壓縮物件直接於快取層間移動,保持壓縮狀態直到下層解碼。
  • 下層已有物件:無需網路傳輸或編碼,直接讀取 zstd 位元組、解碼並傳遞。

儲存編碼標記可防止物件被重複編碼。接收來自其他層物件的快取層,可辨識其已使用 zstd 儲存,並維持該形式。

測試結果與未來方向

Cloudflare 透過受控測試區驗證原型,並將每個請求與請求日誌、Prometheus 指標及 Jaeger 追蹤關聯。效能測試傳送超過一百萬個請求,橫跨 10 台快取伺服器,一半停用 Tiered Cache,一半啟用,以分別測量本機快取行為與跨層傳輸。

測試資產約 195 KiB 與 272 KiB,壓縮率約 2.8 倍。Cloudflare 強調這是刻意選擇的可壓縮語料,用以驗證架構,並不代表網際網路上所有文字物件。若要將壓縮率視為全網路常數,需要更廣泛的語料測試。

初步結果顯示,在測試條件下,CPU 成本僅增加幾個百分點,而儲存與頻寬節省顯著。團隊原本考慮僅壓縮熱門內容,但發現這會降低儲存效益,卻無法等比例減少 CPU 開銷,因此最終採用更簡單的政策:壓縮所有符合條件的可壓縮文字(≥4 KiB)。

未來方向包括評估更高 zstd 等級、測試更多內容類型與物件大小、調整資格條件參數,以及研究 range requests、預壓縮來源回應,或直接將壓縮物件傳遞給支援的下游元件。

這個原型展示了 Cloudflare 在既有基礎設施上仍能挖掘的效率。對於產品建構者而言,重點在於理解取捨:壓縮並非免費,但若能找到「編碼一次、多次受益」的場景,少量 CPU 投資可能換來可觀的儲存與頻寬回報。

參考來源

本文由 AI 協助自上述來源整理,經人工審核後發布。

分享X電郵