本文へスキップ
MameTechNews
バックエンド

Cloudflare、大容量ファイルのRange配信を全プランで設定可能に

## POINTS

  • Rangeのサイズ調整は不要になり、全プランのCache RulesかAPIで対象トラフィックだけを有効にする。
  • R2ではp99の先頭バイト時間がおよそ半分、階層キャッシュの通信量は同種負荷で約6%減った。
  • キャッシュ可否は変わらない。オリジンがバイト範囲に応えられないと部分取得の効果は出ない。

Cloudflareは10月23日、Origin Range Requestsを全プランで利用可能にした。動画のシーク、ダウンロードの再開、パッケージやモデルファイルの部分取得のように、クライアントがRangeでファイルの一部だけを求める配信が対象だ。クライアントの要求そのものは変えず、Cloudflareがオリジンからどう埋めるかを変える。

従来のRangeキャッシュは、ゾーンごとに固定した範囲へ要求を丸めていた。設定値は数十キロバイトから数十ギガバイトまであり、小さいとオリジンへの細かい要求が増え、大きいと求めた以上を取得してデータセンタ間を運んだ。nginxベースでは、Rangeキャッシュと転送中の同時読み出しを併用すると応答が途中で切れた。

新しい実装は、Pingoraがディスクに置く固定サイズの塊に要求を揃える。足りない部分だけをオリジンから取り、クライアントへは要求されたバイトだけを返す。すでにディスクにある部分と取得中の部分を一つの応答へまとめ、同じ範囲を待つ別の要求はその取得へ相乗りする。If-Rangeが一致しなければ全体を返し、圧縮を解く直前の表現は範囲を合成しない。通常のキャッシュ可否は変わらず、オリジンがバイト範囲に応える必要がある。

社内で最も負荷の高かったR2は、旧設定の範囲が64MiBだった。境界をまたぐ小さい読み出しは、データセンタ間で128MiBを運ぶことがあった。新実装のあと、R2の各リージョンでキャッシュの当たりも外れも、p99の先頭バイト時間がおよそ半分になった。ディスク上のバイトと上流のバイトを一つの応答で返す変更で、R2と同種の負荷の階層キャッシュ通信量は前週比約6%減った。

有効化はCachingのCache Rulesで対象を選び、Origin Range RequestsをOnにする。APIではorigin_range_requestsのmodeをonにする。動画、大きなダウンロード、ソフト配布、ディスクイメージ、モデルの一部取得が想定用途だ。