Cloudflareは8月12日、ブログのEmDashへの移行を完了した。EmDashはAstroおよびCloudflareと連携するよう構築されたコンテンツ管理システムであり、このプロジェクトは単なるインターフェースの再設計にとどまらなかった。同社は自社ブログを新しいプラットフォームの「ゼロ号顧客」として利用し、実際の本番トラフィックでプラットフォームをテストするとともに、スケーラビリティ、応答速度、旧システムからの安全な移行に重点を置いた。
Cloudflareによると、移行プロセスによって、ブログの規模と複雑さに関連するニーズが明らかになり、チームはEmDashをより広範に展開する前に改善できた。結果と測定値は同社自身が示したものであるため、これは一社が公開した運用上の事例であり、プラットフォームに対する独立したテストではない。
性能テストの前にプラットフォームをテスト
チームはまず、実務的な問いから始めた。EmDashは本当にCloudflareのニーズに対応できるのか。そこで、投稿の作成、公開、非公開化、予約公開、メディアの追加といった基本的なワークフローに加え、コンテンツエンティティの検索や著者名の管理をテストした。
最大のギャップは、大量のメディアとコンテンツの扱い、翻訳、検索エンジン最適化、コンテンツセキュリティポリシー（CSP）の詳細に現れた。管理エディターについても、カスタムHTMLブロックの発見、コンテンツエディター内のエラー処理、長い投稿の編集中に書式設定バーを表示し続けることに関する改善が必要だった。
発見された最大の問題は予約公開された投稿だった。EmDash 0.19.0のリリース時点でも機能していなかった。この点は、新しいシステムに依存する前に運用ワークフロー全体をテストする価値を示している。というのも、この不具合はコンテンツの作成や即時公開のテストでは必ずしも発見できなかったからだ。
変動するトラフィックを模した負荷テスト
Cloudflare Blogの通常のトラフィックは毎秒約75リクエストだが、新しい投稿の拡散に伴って、あるいは投稿時刻とは無関係な急増によって、毎秒5,000リクエストを超えることがある。そのためチームは、オープンソースツールのk6を使ってテストを設計した。テストには、ベースラインの3倍まで負荷を段階的に増加させるもの、10分間でゼロから毎秒100リクエストまで到達させるもの、毎秒7,000リクエストを1分間発生させる即時バーストテストが含まれた。
失敗基準は3つの指標に基づいていた。HTTP 5xxエラーの割合を0.01%以下にすること、リクエストの95%の応答時間を500ミリ秒以下にすること、99%の応答時間を1秒以下にすることだ。これらの基準により、「プラットフォームは速いのか」という問いは、測定可能な運用条件へと変わった。
多層構成と明確なフォールバック経路
Cloudflareは、Workers Cacheの背後でCloudflare Worker上にEmDashを稼働させる構成を選択した。また、Workers KVを基盤とするEmDashの新しいオブジェクトストレージを使用し、PlanetScaleとはHyperdriveを統合した。同社のデータによると、キャッシュ層により静的ファイルの99.5%がキャッシュから提供され、全リクエストの約70%もキャッシュから処理されたため、データベースへの負荷が軽減された。
移行中のサービス停止を防ぐため、チームは旧ブログと新サイトの間でリクエストを振り分けるProxy Workerを作成した。テスト対象のバージョンはCookieによって判定され、新サイトで500エラーが発生した場合には、リクエストを旧システムへ戻せるようにした。また、公開ドメイン、DNSおよびTLS処理、外部HTTP接続を経由することを避けるため、NEW_BLOGサービスバインディングを使用してWorkers間を直接接続した。
段階的なリリースはトラフィックの1%から始まり、その後5%、15%へと増加し、同日の終わりに100%へ到達した。これにより、読者の大半を不安定な変更にさらすことなく、実際の負荷を監視し、エッジケースを発見できた。
実際に何が変わったのか
Cloudflareによると、新しい構成は以前のプラットフォームと比べてより安定した応答時間を維持し、毎秒最大850リクエストを処理する間も、性能向上と限定的なエラーを実現した。Agents Weekの期間中には、9日間で18本のブログ記事が公開され、約300万回閲覧された。新しいWorkerは目立った問題なく、毎秒最大450リクエストを処理した。また、同社によると、組み込みのDDoS保護は8月10日に毎秒28,000リクエストに達する攻撃を吸収した。
変更にはインターフェースも含まれていた。インターフェースはKumoデザインシステムのパターンに従って再構築され、システム設定と手動の切り替えスイッチに基づくライトモードとダークモードを標準でサポートした。メール購読の呼びかけは記事の末尾へ移され、「このページの内容」目次と「オンラインで議論」オプションが追加され、ナビゲーションと共有性が改善された。
EmDashの新しいAPIとAI検索エンドポイントにより、Cloudflare Blog用のMCPサーバーを数時間で作成できた。これには、投稿の検索、一覧表示、取得、タグの一覧表示を行うツールが含まれる。また、情報源によると、EmDash専用のMCPサーバーを使えば、追加費用なしで、執筆者がコンテンツの閲覧、作成、編集、公開、予約公開、ファイルの削除を行える。
編集体験自体はまだ完成していない。Cloudflareは小さな問題や予約公開された投稿に関連するエラーの記録を続けており、それらをEmDashチームに報告し、Birthday Weekまでに修正されることを期待しているという。したがって、この事例はプラットフォームに制約がないことを示すものではない。しかし、コンテンツのワークフローを性能の前にテストし、明確な失敗基準を定め、フォールバック経路を構築し、全面的な一括移行ではなく段階的にデプロイを拡大するという、適用可能な実践を示している。