1日あたり数百万枚の画像を提供する動画ホスティングサイトにおいて、サムネイル生成をPHPバックエンドからCloudflare Workersへ移行したことで、オリジンサーバーのCPU負荷を完全に解消しました。この切り替えにより、画像処理のレイテンシがデータセンターからエッジへと移動し、レスポンスタイムが大幅に短縮されるとともに、帯域幅コストの予測可能性も向上しました。

旧モデルが破綻した理由

数万本の動画を表示するプラットフォームであるこのサイトでは、1ページに最大40枚のサムネイルが埋め込まれています。各サムネイルは、PHPスクリプトが元のファイルを読み込んでリサイズを行うことで、オンデマンドで生成されていました。そのため、クローラーがサイトを巡回すると、バックエンドサーバーが停止してしまうことがありました。

エッジ処理が5つの核となる要件を解決する

本番環境レベルのサムネイルAPIには、以下の対応が求められます。

  • Fan-in – 多数のサードパーティホストからソース画像をプルすること。
  • Fan-out – 複数のサイズ（例：320pxのカード、640pxのヒーロー画像）を生成すること。
  • Format negotiation – 帯域幅を削減するため、ブラウザが対応している場合にWebPやAVIFを提供すること。
  • Cache – 初回のリクエストにはコストがかかっても、それ以降のリクエストを無料（低コスト）にすること。
  • Security – 任意の画像を処理するためにサービスが悪用されるのを防ぐこと。

Cloudflare Workersは、オリジンのCPUに負荷をかけることなく、これらの各ポイントに対処します。

  1. Proximity（近接性） – Workersはユーザーに近いデータセンターで実行されるため、処理された画像が移動する経路が短くなります。
  2. Built-in Image Resizing – プラットフォームのImage Resizing機能がピクセル処理を行うため、カスタムライブラリが不要になります。
  3. Cache API – Workersはリサイズされた画像をエッジに保存します。初回リクエスト以降は、エッジから直接配信されます。
  4. Programmable security – 小規模なスクリプトでHMAC署名を検証し、ホスト名と幅の許可リスト（allow-list）を適用し、キャッシュポイズニングを防ぐためにキャッシュキーを正規化します。

システムの仕組み

  1. Originが署名付きURLを作成 – バックエンドが秘密鍵を保持し、すべてのサムネイルリクエストにHMAC署名を付与します。URLには、希望する幅とフォーマットも含まれます。
  2. Workerが署名を検証 – リクエストを受け取ると、Workerは共有シークレットを使用してHMACを再計算します。署名がない、または誤っている場合はリクエストが拒否され、悪用を防ぎます。
  3. 許可リストの適用 – スクリプトが、ソースのホスト名が定義済みのリストに含まれているか、およびリクエストされた幅がサポートされているサイズの一つであるかを確認します。これにより、悪意のあるホストがキャッシュされるのを防ぎます。
  4. キャッシュキーの正規化 – キャッシュキーから署名自体が取り除かれます。キーにはソースURL、幅、フォーマットのみが含まれます。これにより、同じ画像をリクエストする異なるユーザーが、同じキャッシュエントリにヒットする