Cloudflare、自社製品を実食：ブログをWorkers上のEmDash CMSに移行

Cloudflareのブログ再設計は、単なる塗り替えではなかった。それは、より大きな移行の公の顔だった。ブログは現在、AstroとCloudflare向けに特別に構築されたCMSであるEmDash上で動作している。Cloudflareは自らをCustomer Zeroと呼んでいる——自社製品の最初の要求の厳しい顧客である。

Customer Zero：大規模なドッグフーディング

Cloudflareの社内エンジニアリング標準であるCodexは、同社がCloudflare自身を動かす製品を構築することを義務付けている。ブログ移行はその教科書的な例だ。チームは2つの質問から始めた：EmDashは我々に機能するか、そしてスケールできるか？

ユーザビリティテストにより、ギャップが明らかになった——メディア処理、コンテンツ検索、著者名、ローカライゼーション、SEO、コンテンツセキュリティポリシー。最大の見落としは、スケジュール投稿がEmDash 0.19.0まで機能しなかったことだ。これは、投稿が公開された後に発見したくない類のことだ。

5,000 RPS（およびそれ以上）へのスケーリング

ブログのトラフィックは変動が激しい。通常の負荷は1秒あたり約75リクエストだが、スパイクは5,000 RPSに達することがある——時にはバイラル投稿によるもの、時にはエッジを探る人々によるものだ。チームは、ランプ、ブレークポイント、バースト条件をシミュレートするk6テストシナリオを構築し、厳格なしきい値を設定した：P95レイテンシは500ms未満、P99は1000ms未満、障害率は0.01%未満。

結果として生まれた本番アーキテクチャは、層状のキャッシュスタックである：

• Cloudflare Worker上で動作するEmDash
• 新しいWorkers Cacheの背後（これを使用する最初の主要サイト）
• このユースケースのためにカスタム構築された、Workers KV上に構築されたEmDashオブジェクトキャッシュ
• PlanetScaleとのCloudflareファーストパーティHyperdrive統合

このセットアップは、静的ファイルの99.5%をキャッシュから提供し、リクエストの70%をキャッシュから提供し、データベース負荷を削減し、フロントエンドのパフォーマンスを向上させる。

フロントエンド再設計：ダークモード以上のもの

移行は、ブログをCloudflareのKumoデザインシステムに合わせる口実となった。ネイティブのライト/ダークモードが現在実装され、トグルとシステム設定の検出が備わっている。読者が検索バーと誤解していたメール購読フォームは、投稿の下部に移動した。新しいサイドバー機能には、「このページについて」の目次と「オンラインで議論」セクションが含まれる。

プロキシWorkerによる安全な展開

ダウンタイムを回避するため、CloudflareはバージョンCookieに基づいてレガシーブログと新しいEmDashサイト間でトラフィックをルーティングするプロキシWorkerを展開した。新しいサイトが500エラーを返す場合、トラフィックはレガシーブログにフォールバックする。ワーカー間サービスバインディングは、パブリックホスト名とDNSラウンドトリップを回避することでレイテンシを低く保つ。

この移行は、大規模なドッグフーディングの堅実なケーススタディである。また、Cloudflareが自社製品——Workers Cache、Hyperdrive、EmDash——を本番グレードの領域に押し上げている方法も示している。ブログは今やその証明点である。