Cloudflareのキャッシュトランスコーディング：Pingora内のZstdでペタバイトを節約

Cloudflareは、メモリコストの上昇に直面しています。RAMとハードディスクの価格は過去1年間で急騰しました。展開済みストレージをさらに活用するため、同社は1.1.1.1インターンプログラムのインターンシップ中に構築されたCache Transcodingと呼ばれるシステムを試作しました。アイデアは、対象アセットをキャッシュに書き込む前にZstandard（zstd）で圧縮し、ディスク上およびTiered Cache転送中は圧縮状態を維持し、クライアントへの配信時にのみデコードするというものです。

初期テストでは、このエンコーディングにより、対象アセットのディスク上のサイズが平均で元の約3分の1に縮小されました。トレードオフは、CPU使用率のわずかな増加です。これはキャッシュフィルごとに1回支払われますが、アセットが配信されるたびに蓄積されるストレージと帯域幅の大幅な節約と引き換えです。

なぜZstandardなのか？

Zstdは、2016年にFacebookがオープンソース化した可逆圧縮アルゴリズムです。圧縮率と速度のバランスを取ります。Cloudflareの以前のブラウザ圧縮テストでは、zstdはBrotliよりも42%高速にデータを圧縮し、ほぼ同じファイルサイズを生成し、同等の速度でgzipよりも11.3%小さいファイルを生成しました。プロトタイプはzstdレベル3を使用しており、キャッシュフィルをCPUボトルネックにすることなく、圧縮の利点のほとんどを提供します。

従来、Cloudflareはオリジンが提供するコンテンツエンコーディングを使用してアセットを保存します。オリジンが非圧縮バイトを送信する場合、それらのバイトはそのまま保存および転送されます。Cache Transcodingは、キャッシュ自体に圧縮を追加します。

すべてが圧縮に値するわけではない

画像、動画、フォントは通常すでに圧縮されています。Cloudflareのトラフィックサンプルでは、このメディア部分はリクエストの21.4%を占めましたが、バイト数の63.3%を占めました。これを再度圧縮するとCPUが無駄になります。圧縮可能なテキスト（HTML、JSON、CSS、JavaScript）は、リクエストの67.3%とバイト数の22.3%を占めました。そのテキスト部分のうち、約71%がContent-Encodingが設定されていない非圧縮で到着し、圧縮率が高くなっています。制御されたテストコーパスでは、対象アセットは約2.8倍に圧縮されました。

測定されたコスト：zstdレベル3でのエンコードは1バイトあたり4.31ナノ秒（約232 MB/s）で、フィルごとに1回支払われます。デコードは1バイトあたり1.56ナノ秒（約641 MB/s）で、配信のたびに支払われます。エンコードはバイトあたりのコストが高くなりますが、アセットはフィルよりもはるかに頻繁に配信されます。

圧縮コストを一度だけ支払う

圧縮は決して無料ではありません。重要な問題は、バイトの節約がCPUコストを正当化するかどうかです。zstdレベル3では、モデルはテストされたトラフィックと再利用の前提の下で、追加のCPUコストを数パーセントに抑えました。トランスコーディングを人気コンテンツに制限しても効果はありませんでした。デコードは配信のたびに行われるため、ホットアセットに機能を制限すると、CPUを比例的に削減せずにストレージの節約が減少しました。よりシンプルなポリシーの方が優れていました。4 KiB以上の圧縮可能なテキストをすべてトランスコードし、CPU予算内で測定されたストレージの利点のほぼすべてを獲得しました。

Cache Transcodingの仕組み

キャッシュミス時、Pingoraベースのプロキシはディスクに書き込む前にボディをzstdでエンコードし、保存された表現が圧縮されていることを記録し、元のコンテンツ長を保持します。キャッシュヒット時、保存されたzstdオブジェクトが読み取られ、デコードされます。Tiered Cacheを使用すると、圧縮された表現は圧縮形式のまま階層間を移動します。デコードはクライアント向けホップでのみ行われます。ストレージエンコーディングマーカーにより、オブジェクトが複数回エンコードされるのを防ぎます。

対象判定

プロトタイプは、Content-Encodingが設定されておらず、Content-Typeが圧縮可能なテキストであり、応答に既知のContent-Lengthが4 KiB以上ある場合にのみ、200 OK応答をトランスコードします。スライスサブリクエスト、アクティブなアップストリーム圧縮を使用する応答、レンジリクエスト、事前圧縮された応答、不明な長さのボディ、バイナリコンテンツは変更されません。4 KiBのしきい値により、多数の小さなリクエストが除外され、対象となるバイトの約1%のみが除外されました。

100万リクエスト以上のテスト

Cloudflareは、制御されたテストゾーンに対してプロトタイプを実行し、ログ、Prometheusメトリクス、Jaegerトレース全体でリクエストを関連付けました。あるパフォーマンスキャンペーンでは、10台のキャッシュサーバーに100万以上のリクエストを送信し、半分はTiered Cacheを無効にし、半分は有効にしました。2つのアセット（約195 KiBと272 KiB）は約2.8倍に圧縮されました。これは意図的に圧縮可能なコーパスであったため、測定された比率はフリート全体の定数ではありません。

一度圧縮すれば、何度も利益を得る

この実験は、Cloudflareのキャッシュサービスにまだ大きな効率性が残っていることを示しています。テストされた条件下ではトレードオフは有利であり、コンテンツを保持し、CPU予算内に収まります。次のステップには、より高いzstdレベルの評価、より広いコンテンツタイプとサイズの検討、レンジリクエスト、事前圧縮されたオリジン、圧縮オブジェクトをサポートするダウンストリームコンポーネントへの直接受け渡しの調査が含まれます。