Cloudflareは、新たなハードウェアを追加せずに同社のキャッシュネットワークの実効容量を増やす方法をテストしています。Pingoraを基盤とするアーキテクチャ内で、Zstandardアルゴリズムを使用して一部のテキストアセットを圧縮する方法です。同社がCache Transcodingと名付けたこのプロトタイプは、ディスク上でデータが占める容量と、キャッシュ層およびデータセンター間で転送されるデータ量の削減を目的としています。
対象となるレスポンスがキャッシュに入ると、そのデータはディスクに書き込まれる前にzstdを使用した圧縮表現へ変換されます。アセットはキャッシュ内に存在する間も、Tiered Cacheを通過する間もこの形式で保持され、クライアントへ送信される前に展開されます。これによりファイル自体の内容は変わりません。Zstandardは可逆圧縮アルゴリズムであり、展開後にはすべてのバイトが元の状態に戻るためです。
処理コストを限定しながら大きな効果
初期テストでは、対象アセットのディスク上のサイズが平均で元のサイズの約3分の1まで減少しました。制御されたテストセットにおける圧縮率は2.834倍でした。エンコードのコストは1バイト当たり4.31ナノ秒、つまり毎秒約232メガバイトで、キャッシュへの格納時に1回だけ発生します。一方、展開のコストは1バイト当たり1.56ナノ秒、つまり毎秒約641メガバイトで、提供処理のたびに発生します。
この試験では、実行速度と出力サイズのバランスが取れたZstandardのレベル3を使用しています。Cloudflareのモデルによると、同社がテストしたトラフィック量と再利用率の前提では、プロセッサー消費量の増加は数パーセントにとどまりました。また、データサイズを削減することで、各サーバーはより多くのアイテムを保持でき、必要以上の容量を消費する有用なコンテンツがキャッシュから追い出される可能性も低くなります。
なぜCloudflareはすべてを圧縮しないのか？
この仕組みは、あらゆる種類のコンテンツを対象とするわけではありません。画像、動画、フォントは通常すでに圧縮されており、トラフィックサンプルではリクエストの21.4%を占めた一方、総バイト数の63.3%を占めていました。これらのデータを再圧縮しても、実質的な節約なしにプロセッサーを消費する可能性があります。
一方、HTML、JSON、CSS、JavaScriptは、リクエストの約67.3%、バイト数の22.3%を占めました。これらのテキストレスポンスの約71%はContent-Encodingなしでオリジンから到着しており、圧縮の候補となりました。このプロトタイプは、Content-Encodingを指定していない200 OKレスポンスで、圧縮可能なテキストコンテンツタイプを持ち、既知の長さが4 KiB以上であるものに限定されています。
部分範囲リクエスト、オリジンが事前に圧縮したレスポンス、範囲リクエスト、長さが不明なボディ、バイナリコンテンツは変更されません。Cloudflareは、4 KiBのしきい値によって多数の小さなリクエストが対象外になる一方、それ以外で対象となっていたバイト数の約1%しか除外されないことを確認しました。
キャッシュ層をまたいで仕組みはどのように動作するのか？
キャッシュが完全にミスした場合、上位層はオリジンから非圧縮データを取得し、それを1回だけ圧縮してzstd形式で保存します。この圧縮形式は下位層へ移され、下位層はそれを保持し、クライアントへ向かうリクエスト経路上でのみ展開します。アイテムが上位層にのみ存在する場合は、オリジンへ戻ることなく下位層へ移動できます。
アイテムが下位層に存在する場合、ネットワーク転送も新たなエンコードも必要ありません。ディスクからzstdデータを読み出して展開し、レスポンス経路へ渡すだけです。システムはメタデータにアイテムが圧縮形式で保存されていることを記録し、キャッシュ層間を移動する際に再度圧縮されるのを防ぎます。
certi.newsの見解：この試験が実際に証明すること
この試験は、キャッシュへの格納処理だけを改善するよりも、ストレージ層そのもののデータサイズを削減する方が、累積的に大きな効果をもたらす可能性を示しています。圧縮のコストはアイテムが入る時点で支払われますが、ストレージ容量と帯域幅の節約効果は、アイテムが再利用されるたびに繰り返し得られます。これは特に大規模な配信ネットワークの運用者にとって重要です。ローカル容量は保持できるコンテンツ量に結び付き、層間のデータ転送は内部ネットワークの消費に結び付くためです。
ただし、2.8倍という比率がインターネット上のすべてのコンテンツやCloudflareのすべてのインフラを代表するわけではありません。性能テストは10台のキャッシュサーバーを通過する100万件超のリクエストに基づいていましたが、サイズが約195 KiBと272 KiBで、明確に圧縮可能な2つのアイテムを実験用のオリジンとして使用していました。同社は、この比率をフリート全体の代表値とみなすには、より幅広いコンテンツタイプとサイズを対象にする必要があると認めています。
Cloudflareは、zstdのより高いレベルのテスト、コンテンツタイプとサイズの範囲の拡大、対象条件の調整、範囲リクエストおよび事前圧縮されたレスポンスの調査を計画しています。したがって、現時点の資料におけるCache Transcodingは、特定の条件下で成功したプロトタイプであり、Cloudflareのすべてのトラフィックへの最終的な全面展開を発表するものではありません。