JA EN
shiichan

Cloudflare のキャッシュ、Zstandard で 2.8 倍圧縮できるって知ってた？

Cloudflare Blog ★★★ Markdown で見る
#cloudflare#infrastructure#web

こんにちは、しぃちゃんだよ！今日は Cloudflare のブログで見つけた、地味だけどすごく効きそうな話を紹介するよ。

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare の Blog によると、キャッシュ内のコンテンツを圧縮する「Cache Transcoding」というプロトタイプを試したんだって。インターンシップ期間中に検証したもので、既存のハードウェアのままキャッシュの保存容量を大きく増やせるかもしれない、という成果が報告されているよ。

なぜ重要なの？

Cloudflare のように大規模な分散ストレージを運用していると、RAM やストレージのコストが上がるほど負担が大きくなるの。ハードウェアを増やさずに同じ容量でより多くのデータをキャッシュできれば、コストの伸びを抑えられるから、この検証は注目されているんだって。

深く潜ってみよう

圧縮アルゴリズムには Zstandard(zstd)が選ばれたよ。記事では、zstd は Brotli より 42 %高速に圧縮しながらほぼ同等のファイルサイズを実現し、gzip より 11.3 %小さいファイルを同等の速度で作れるとされていて、プロトタイプでは速度とサイズのバランスを取って zstd レベル 3 が使われたの。

実装は Cloudflare 自社開発のプロキシ「Pingora」のキャッシュレイヤーに組み込まれているよ。動きはこんな感じ。

  • キャッシュミス時: オリジンからの応答を zstd で符号化してディスクに書き込み、クライアントに送る前に元の形式へデコードする
  • キャッシュヒット時: ディスクから圧縮されたオブジェクトを読み込んでデコードする。Tiered Cache を使う多層キャッシュの場合、データセンター間の転送では圧縮された形式のまま送り、最後にクライアントへ渡すホップでだけデコードする

テストでは、195 KiB と 272 KiB のテキスト資産がどちらも約 2.834 倍に圧縮されたよ。エンコードのコストは 1 バイトあたり 4.31 ナノ秒(約 232 MB/s)、デコードは 1 バイトあたり 1.56 ナノ秒(約 641 MB/s)で、CPU への追加負荷は数パーセント程度に収まったんだって。10 台のサーバーで 100 万件以上のリクエストを使って検証されたよ。

圧縮の対象になるのは、HTML・JSON・CSS・JavaScript のようなテキスト系コンテンツで、記事の実測ではリクエスト数の 67.3 %、バイト数の 22.3 %を占めていたの。その約 71 %はもともと未圧縮の状態で届いていたから、圧縮の伸びしろが大きかったみたい。一方で、次のようなコンテンツは対象外にされているよ。

  • 画像・動画・フォントなど、すでに圧縮済みのコンテンツ(リクエスト数の 21.4 %、バイト数の 63.3 %)
  • すでに Content-Encoding が設定されているレスポンス
  • Content-Length が 4 KiB 未満のテキスト(圧縮のオーバーヘッドが見合わない)

また、今回の検証ではスライスされたサブリクエストやレンジリクエスト、事前圧縮済みのレスポンス、長さが不明なボディは対象外だったよ。記事も「特定の範囲のコンテンツで意図的に検証したので、より広いコンテンツで確かめてから数値を全体の定数として扱うべき」と釘を刺していて、今後はより高い圧縮レベルの評価や、対応コンテンツ範囲の拡大、レンジリクエストへの対応などを検討していくとのことだよ。

まとめ

  • Cloudflare がキャッシュ内のテキストを Zstandard で圧縮する「Cache Transcoding」をプロトタイプ検証
  • Pingora のキャッシュレイヤーに組み込み、ミス時に圧縮して保存、ヒット時にデコードして返す
  • テキスト資産で約 2.834 倍の圧縮率、CPU 追加コストは数パーセント程度
  • 画像・動画や 4 KiB 未満の小さいテキストは対象外
  • まだプロトタイプ段階で、今後さらに広いコンテンツ範囲での検証が予定されている

CDN やキャッシュのインフラ設計に興味がある人、大規模ストレージのコスト最適化の工夫を覗いてみたい人にとって面白い読み物だよ！

関連記事