Cloudflare、巨大CDN「cdnjs」を自社プラットフォームへ完全移行：90億リクエストを支える新アーキテクチャを公開
Cloudflareは、JavaScriptおよびCSSライブラリのオープンソースCDNであるcdnjsを、自社のDeveloper Platformへ完全に移行したことを発表しました。この移行は、これまでCloudflareとGoogle Cloud Platform（GCP）に分散していた公開インフラを、Workers、R2、Workflows、KVなどのネイティブサービス群に集約するものです。
cdnjsは現在、1日あたり約90億件という膨大なリクエストを処理しており、330か所を超えるデータセンター全体で平均毎秒10万8,000件のリクエストを処理しています。このサービスはキャッシュヒット率98.6％を誇り、約12％のWebサイトで利用されている巨大なインフラです。
今回の移行の目的は、広く利用される公開サービス規模でDeveloper Platformを実運用する「ドッグフーディング」の事例として、インフラの単一化と効率化を図ることです。旧システムでは、パッケージ公開の処理経路が分散しており、Google Cloud FunctionsやGoogle Cloud Storage、Pub/Subなどが複雑に連携していました。また、公開済みファイルはGitHubとKVの両方で管理され、システムが複雑化していました。
新しいアーキテクチャでは、公開済みファイルの単一の正確な情報源（source of truth）としてCloudflare R2が採用されています。パッケージのメタデータやバージョン情報、Subresource Integrity（SRI）ハッシュはKVに保存され、リクエスト処理はWorkersが担います。パッケージの取り込み（オーケストレーション）はCloudflare Workflowsによって管理され、npmやGitHubのリリース確認、パッケージの取得、R2への格納、メタデータ更新、Algolia検索インデックスの更新といった一連の処理パイプラインが実行されます。特に、圧縮処理にはメモリ制約からContainersが利用されていますが、将来的にはWorkersへの移行も検討されています。
この移行に伴い、Cloudflareはプラットフォームの制限を引き上げ、Workerのサブリクエスト数上限を1,000件から1,000万件へ、Workflowのステップ数上限を1,024から10,000ステップ（最大25,000ステップ）へと大幅に引き上げました。これにより、cdnjsはR2を成果物保存、KVをメタデータ管理、Workersをコンテンツ配信、Workflowsを公開処理という形で、Cloudflareのネイティブスタック全体を活用する、極めて堅牢でスケーラブルなシステムへと生まれ変わりました。
背景
cdnjsは、Web開発において必須のJavaScript/CSSライブラリを配信する、極めて大規模で重要な公開インフラです。これまで、その運用はCloudflareとGoogle Cloud Platform（GCP）という異なるクラウド環境に分散しており、システムが複雑化し、管理上の課題を抱えていました。今回の移行は、この分散した巨大なサービスを、Cloudflareの最新かつ統合された開発者プラットフォーム上に再構築する試みです。
重要用語解説
- R2: Cloudflareが提供するオブジェクトストレージサービス。本件では、cdnjsの公開済みパッケージファイル群の「単一の正確な情報源（source of truth）」として採用され、成果物の保存に利用されています。
- Workers: Cloudflareが提供するサーバーレスコンピューティングプラットフォーム。リクエスト処理の実行層として機能し、cdnjsのコンテンツ配信の核となり、高いスケーラビリティを提供します。
- Workflows: Cloudflareのワークフローオーケストレーションツール。npmやGitHubのリリース確認から、パッケージの取得、R2への格納、メタデータ更新に至る一連の複雑な公開処理パイプラインを自動で管理・実行します。
今後の影響
本移行は、単なるインフラの移転に留まらず、Cloudflareが自社の開発者プラットフォームの能力（R2, Workers, Workflows）を、世界規模の公開サービスで実証する「ドッグフーディング」の成功事例となります。これにより、開発者コミュニティに対し、単一のクラウドスタックで巨大な分散型サービスを構築・運用できるという信頼性と技術的な優位性を強くアピールすることになります。