CloudflareがCDNキャッシュを「約3分の1」に圧縮へ、数PBの容量を生み出す「Cache Transcoding」とは？

🚀 Cloudflareが「ストレージを増設せずに容量を増やす」新技術を試作
⚙️ なぜCDN内部のデータをわざわざ圧縮するのか？
🗜️ なぜ「Zstandard」なのか？圧縮率だけでなくCPU負荷とのバランスが重要
📊 約2.8倍の実効容量、ただし「まだ実験段階」なのが重要
🌍 まとめ：ハードウェアを増やすのではなく「ソフトウェアで数PBを作る」
1. 📚 参考・出典

🚀 Cloudflareが「ストレージを増設せずに容量を増やす」新技術を試作

世界規模のCDNを運営するCloudflareが、既存のキャッシュストレージを実質的に大容量化する新技術「Cache Transcoding」を試作しています。CDNはHTML、JavaScript、CSSなどのコンテンツを利用者に近いサーバーへ一時保存し、オリジンサーバーまで毎回取りに行く必要をなくすことでWebサイトを高速化する仕組みです。しかしCloudflareほど巨大なネットワークでは、キャッシュとして保存するデータそのものが膨大になり、ストレージ容量やデータセンター間通信のコストが問題になります。CloudflareはRAMとHDDの価格上昇を背景として、ハードウェアを追加するだけでなく、すでに設置済みの設備をさらに効率よく利用する方法を検討。その結果生まれたのが、キャッシュするデータそのものを圧縮して保存するCache Transcodingです。初期実験では対象データのサイズを平均約2.8分の1に圧縮でき、Cloudflare全体では数PB規模の実効容量を新たに生み出せる可能性が示されています。

⚙️ なぜCDN内部のデータをわざわざ圧縮するのか？

Web通信ではgzipやBrotliなどによる圧縮がすでに一般的ですが、重要なのは**「利用者へ送信するデータの圧縮」と「CDN内部で保存するデータの圧縮」は別の問題**だという点です。従来のCloudflareでは基本的にオリジンサーバーから受信した表現をキャッシュしていたため、オリジンが未圧縮のコンテンツを返せば、その大きなデータがキャッシュストレージに保存され、キャッシュ階層間でも転送されるケースがありました。Cache Transcodingでは、この部分をCloudflare自身が管理する内部圧縮形式へ変換します。Cloudflareが独自開発したRust製プロキシ基盤「Pingora」に圧縮処理を組み込み、キャッシュミス時にオリジンから取得した対象コンテンツをZstandard（zstd）で圧縮して保存する設計です。PingoraはCloudflareがNGINXベースの旧基盤を置き換えるために開発したシステムで、現在ではCDNを含む同社の多数のネットワークサービスを支える重要な基盤となっています。

Cache Transcodingの処理を簡単に整理すると、次のようになります。

🌐 ① キャッシュミス → Cloudflareがオリジンサーバーからコンテンツを取得
🗜️ ② zstdで圧縮 → Pingora内部で対象データを圧縮
💾 ③ 圧縮状態で保存 → キャッシュストレージの消費容量を削減
🔄 ④ CDN内部でも圧縮状態を維持 → Tiered Cache間の通信量も削減
📤 ⑤ 必要な段階で変換・展開 → クライアントへ適切な形式でレスポンス

ポイントは、キャッシュへ格納するときの圧縮処理は基本的に最初の1回で、その後キャッシュがヒットするたびに小さくなったデータを再利用できることです。CPUによる圧縮コストを一度支払う代わりに、ストレージ容量と内部ネットワーク帯域の節約効果を繰り返し受け取るという設計思想になっています。

🗜️ なぜ「Zstandard」なのか？圧縮率だけでなくCPU負荷とのバランスが重要

Cache Transcodingでは圧縮アルゴリズムとして「Zstandard（zstd）」が採用され、試作段階では圧縮レベル3が使われています。ZstandardはMeta（旧Facebook）で開発された可逆圧縮方式で、展開後に元データを完全に復元できるほか、高速な圧縮・展開と高い圧縮率を両立させやすいことが特徴です。現在はRFC 8878としてフォーマットやapplication/zstdメディアタイプなども文書化されています。CDNでは圧縮率を限界まで高めればよいわけではありません。世界中から大量のリクエストを処理するため、1件当たりでは小さなCPU負荷でも、ネットワーク全体では巨大な計算コストになるからです。そのためCloudflareは「どれだけ小さくできるか」だけではなく、圧縮に必要なCPU時間・展開速度・ストレージ削減量を総合的に考える必要があるとしています。

この発想は大規模インフラならではです。例えば100TBのデータを50TB削減できても、小規模なサービスならHDDを追加した方が簡単かもしれません。しかし数PB、さらにその上の規模になれば話は変わります。圧縮によってキャッシュ密度が高くなると、単にディスク購入費を節約できるだけでなく、同じサーバーにより多くの人気コンテンツを残せるため、キャッシュヒット率を改善できる可能性があります。キャッシュから追い出されるデータが減ればオリジンサーバーへの再取得も減少し、ストレージ、ネットワーク、オリジン負荷という複数の領域へ効果が波及します。

📊 約2.8倍の実効容量、ただし「まだ実験段階」なのが重要

Cloudflareの初期テストでは、Cache Transcodingによって対象データを平均約2.8分の1のサイズまで縮小できました。さらにCloudflareのモデルでは、zstdレベル3を使用した場合のCPU負荷増加を数％程度に抑えながら、ネットワーク全体では数PB相当のキャッシュ容量を生み出せる可能性があるとされています。これは新しいHDDを数PB追加するのではなく、ソフトウェアの変更によって既存ハードウェアから数PB分の余力を引き出すという点が非常に興味深いところです。

ただし「Cloudflareの全キャッシュが3分の1になる」と理解するのは正確ではありません。実験では10台のキャッシュサーバーに100万件以上のリクエストを送りましたが、テスト対象となった約195KiBと272KiBのコンテンツは意図的に圧縮しやすいデータでした。そのためCloudflare自身も、この結果をそのまま本番環境全体へ適用できるとはしていません。JPEG、WebP、動画、ZIPなどはすでに高度に圧縮されているため再圧縮によるメリットが小さく、逆にHTML、CSS、JavaScript、JSONなどは大きな削減余地を持つ可能性があります。またHTTPのRangeリクエストでは圧縮されたストリームの一部分だけを効率的に取り出すことが難しくなるなど、実運用では追加の課題もあります。Zstandard自体も標準仕様では任意位置へのランダムアクセスを目的とした形式ではありません。

🌍 まとめ：ハードウェアを増やすのではなく「ソフトウェアで数PBを作る」

Cache Transcodingの面白さは、新しい圧縮アルゴリズムを発明したことではなく、既存のZstandardとPingoraを世界最大級のCDNのキャッシュ階層そのものへ組み込もうとしている点にあります。Cloudflareは以前から、膨大な回数実行される処理では数％、数十バイト単位の改善であってもネットワーク全体では巨大な節約になるという考え方でインフラを最適化してきました。Pingoraについても、旧プロキシ基盤から移行した際にCPU・メモリ効率を大幅に改善したと報告しており、Cache Transcodingはその延長線上にある取り組みといえます。

Cache Transcodingはまだ試作段階であり、Cloudflareは今後、より多様なコンテンツやファイルサイズ、圧縮済みオリジンレスポンス、より高いzstd圧縮レベル、Rangeリクエストなどを検証するとしています。それでも、CPUを数％余分に使う代わりにストレージと内部帯域を大幅に削減できれば、「サーバーを増設して性能を伸ばす」だけではなく、「既存サーバーに入る情報量そのものを増やす」という新たなスケーリング手段になります。世界規模のインターネットインフラでは、小さなソフトウェア最適化が数PBという物理的なハードウェアに匹敵する価値を生み出す好例といえそうです。