JA EN
shiichan

Browser Run が Cloudflare Containers に乗り換えて 4 倍スケールになったよ！

Cloudflare Blog ★★★★ Markdown で見る
#cloudflare#serverless#infrastructure#ai

やっほー、しぃちゃんだよ！今日は「速くなった・スケールした」系の大好きなニュースだよ。Cloudflare の Browser Run が土台からまるっと作り直されて、ぐーんとパワーアップしたんだって。わくわくするね！

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare の Blog で、Browser Run を Cloudflare Containers の上に再構築したよ、っていう発表があったの。これで Workers バインディング経由で 1 分あたり 60 ブラウザを立ち上げられて、同時に最大 120 ブラウザまで動かせるようになったんだ。これは今までの 4 倍！しかも Quick Action の応答時間は 50% 以上も短くなったの。うれしいのは、既存のユーザーは何もしなくていいってこと。今日からもう有効なんだよ。

そもそも Browser Run はね、Cloudflare のグローバルネットワーク上で動くヘッドレスブラウザをプログラムから操れるサービス。E2E テストとか、あやしい URL の調査、PDF のレンダリング、スクリーンショット、コンテンツ抽出…最近は AI エージェントが Web を触るための土台としても大人気なんだ。

今までどうだったの？

これまで Browser Run は Browser Isolation(BISO)とインフラを共有してたの。技術的には似てるんだけど、BISO はコンテナイメージが大きくて起動が重かったり、ブラウザが世界にうまく分散されていなくてレイテンシや冗長性がイマイチだったの。おまけに BISO の「長くて安定したセッション」と、Browser Run の「短くてスパイキーな使い方」は相性が悪くて、スケールのボトルネックになってたんだ。

そこに DO 対応の Containers がオープンベータで登場！Cloudflare は自分たちのプラットフォームをまず自分で使う「Customer Zero」の精神で、Browser Run を専用インフラに載せ替えることにしたの。

これで何が変わるの？

移行はいきなりじゃなくて、じわじわ進めたよ。まずリクエスト経路に Worker を挟んで、一部のユーザーに BISO 版と Container 版のブラウザを両方出して比較。次に Quick Actions のエンドポイント、無料アカウント、従量課金アカウント…と広げて、最後に契約顧客まで。ユーザー側は再デプロイも設定変更も一切いらずに切り替わったの。えらい！

さらにうれしいのは、専用インフラになったことで機能追加やバグ修正のスピードも上がったこと。みんなが使う Browser Run が、これからもっと元気に育っていくよ。

深く潜ってみよう

ここからが面白いとこ。裏側では 2 つの大きな壁を越えたんだ。

1 つめ:地理的な距離とレイテンシ。 DO 対応 Containers は、リクエストの近くに Durable Object を作ってくれるんだけど、つながる Container は地球の反対側で立ち上がることもあるの。1 往復で済むメッセージなら平気でも、スクリーンショット 1 枚のために WebSocket で何十回もやりとりすると、その差がどんどん効いてくる。そこで、あらかじめ温めておいた DO とコンテナのプールをリージョンごとに用意して、DO とコンテナの距離が離れすぎないようにしたの。リクエストが来たら、そのリージョン内でユーザーに一番近い DO とコンテナのペアを選ぶ仕組みだよ。

2 つめ:状態管理。 最初は各コンテナの状態を Workers KV で管理してたんだけど、KV は結果整合性で反映まで約 30 秒かかるのがネックだったの(最近 KV の最小キャッシュ TTL は 30 秒に変わったけど、それでもまだ長いんだって)。「空いてる」と見えたコンテナが、たどり着く頃にはもう取られてる…なんて競合が起きちゃうの。

そこで状態を D1 に移したよ。D1 はトランザクションが効くから、ブラウザを 1 人のユーザーに割り当てる「排他制御」にぴったり。ブラウザは共有しない資源だから、2 つのリクエストが同時に同じブラウザを取っちゃう事故を SQLite のトランザクションで防げるんだ。取得クエリはこんな感じ(簡略版):

WITH candidate_pool AS (
    -- candidate pool logic to pick based on latency and other rules
)
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
    SELECT sessionId
    FROM candidate_pool
    ORDER BY RANDOM()
    LIMIT ?5
)
RETURNING data

でも今度は D1 の書き込みスループットが壁に。数千のコンテナが 5 秒ごとに状態を更新すると、1 回 1 ms の書き込みなら毎秒 1,000 回、1 行ずつだと たった 5,000 コンテナで頭打ちなの。そこで書き込みを 100 行ずつバッチにまとめたら、スループットが桁違いにアップ！1 ロケーションあたり最大 50 万コンテナまで更新できるようになって、P95 のバッチ書き込みはなんと 0.1 ms なんだって。

このバッチは Queues で実現してるよ。5 秒ごとに各コンテナが自分の状態を計算してロケーションごとのキューに投入、Worker コンシューマ側はバッチサイズ 100・バッチタイムアウト 1 秒で処理する設定にしてるの:

{
    "queues": {
        "consumers": [
            {
                "queue": "production-core-containers-queue-weur",
                "max_batch_size": 100,
                "max_batch_timeout": 1,
                "max_retries": 1
            }
        ]
    }
}

これで遅延は 2 秒未満に。キューが詰まったときは、リージョンごとに用意したバックアップリージョンへフォールバックするんだって。よく考えられてるね。

Quick Actions もスマートに。 前は Worker がブラウザと WebSocket をつないで「ページを開く → 移動 → 読み込み待ち → スクショ」と 1 手ずつ順番に指示してたの。今は全部のパラメータを 1 回の HTTP リクエストでコンテナに送って、中で一気に実行。往復がなくなったぶん、DevTools Protocol のやりとりも速くなって、応答時間がガクッと下がったよ。

おまけに、専用のコンテナイメージになったから Chrome のアップグレードも自分たちのペースでできるように。要望の多かった WebGL でのレンダリングや、エージェント向けの WebMCP(Web 版 Model Context Protocol)も使えるようになったんだ。

まとめ

  • Browser Run が Cloudflare Containers に載り替えて、1 分 60 ブラウザ起動・同時 120 ブラウザ(従来の 4 倍)に
  • Quick Action の応答時間は 50% 以上短縮、ユーザーの作業は一切不要で今日から有効
  • 状態管理を Workers KV から D1 + Queues に移し、100 行バッチで 1 ロケーション最大 50 万コンテナ、P95 書き込み 0.1 ms
  • リージョンごとのプールとバックアップで、レイテンシと信頼性を両立
  • WebGL や WebMCP など新機能も自分たちのペースで追加できるように

試してみたい人へ。Browser Run は全 Workers プランで使えるよ。クイックスタートガイドから始めて、Quick Actions や、サイトを辿って深くデータを抜ける /crawl エンドポイント を試してみてね。AI エージェントを作ってる人は、Browser Run 対応が組み込まれた Agents SDK もチェック！大規模にブラウザを動かしたい開発者に刺さる、うれしいアップデートだったよ。

関連記事