← 2026-06-18 の一覧へ戻るホーム
EC2 内で Firecracker VM を起動し、1 秒未満でブラウザを開始する方法

2026/06/17 0:15

EC2 内で Firecracker VM を起動し、1 秒未満でブラウザを開始する方法

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Browser Use は、Firecracker を採用してクラウドブラウザのインフラストラクチャを再構築し、セッション開始時間を 1 秒未満（p50：825ms、p99：1.35s）に達成するとともに、コストをブラウザー時間あたり $0.02 に大幅に削減しました。このアップグレードでは、トラフィック急増時に 45 分の停電を引き起こした Unikraft を基盤とした不安定な手動システムから、通常の Amazon EC2 インスタンス上で動作する自動制御プレーンへの切り替えを行いました。最適化戦略としては、4KB から 2MB のメモリページへの変更とカスタムハンドラーの実装を行い、メモリ起動遅延を約 10 秒から僅か 3 秒以上に削減し、ページフォルトを 91 倍削減しました。CPU ボトルネックに対処するため、システムは起動バースト中に vCPU をアンピンし、その後安定したコアにピン留めすることで、ハイパースレッドを適切に管理し、大規模テストにおけるセッション損失を 17% からゼロに解消しました。現在はエッジルーターを介してホスト故障を自動的に処理し、内部ベンチマークで約 82% の時間でアンチボットブロックを回避するヘッドレスブラウジングソリューションを提供しています。今後の取り組みでは、Chromium が初期化された後に VM をスナップショットすることで残りの起動遅延を完全に省略し、Web オートメーション用の堅牢かつ拡張可能な基盤を提供します。

本文

クラウドブラウザ「Browser Use」の高速化と低コスト化を実現した技術革新

クラウドブラウザの実現には、以下の 3 つの要件を同時に満たす必要があります。

  • 迅速性: 起動が早ければ早いほどユーザー体験が向上します。
  • 孤立性: ブラウザ同士もホスト間でも完全な隔離（セキュリティ）が必要となります。
  • 低コスト: コストを抑えなければスケーリングが困難です。

これらを達成するために、私たちはインフラを再構築し、セッション開始時間を 1 秒未満に、かつコストを従来の $0.06 から $0.02 に削減することに成功しました。ブラウザには Chromium エンジン、ファイルシステム、キャッシュ、セキュリティ設定など多様なコンポーネントが含まれており、これらを扱うことは極めて困難な課題です。

基本コンセプト：Firecracker を用いた軽量 VM アプローチ

通常、クラウド向けブラウザでは「隔離性」と「安全性」を確保するために仮想マシン（VM）が採用されます。VM は独自の CPU、メモリ、ディスクを持ち、他との完全な分離が可能ですが、従来の VM はインスタンス作成や廃棄にかかるオーバーヘッドが高く、コストと速度の面で不利でした。

なぜ「VM 内の VM」を採用したのか？

標準的な AWS EC2 インスタンス（通常は他の VM の上にある）の上にさらに Firecracker という軽量 VM システムを動作させる構成、「ネスト型 VM」とは言えますが、これはコスト削減と高速スケーリングを目的とした独自の選択です。

  • メタルサーバーではなく EC2 を採用した理由
    • 物理機全体をレンタルする「メタル（裸金属）」サーバーを使用する場合、セットアップに時間がかかり維持費が高騰します。
    • 我々は既に VM の中にある通常の EC2 インスタンス をホストとして使用し、その上に Firecracker VM を構築しています。
  • 得られる効果
    • 高速なスケーリング: ホストが既存の EC2 であれば、ブラウザインスタンスを数秒単位で作成・停止できます。
    • コスト削減: アイドル時のリソース保持コストを抑えられ、顧客への転嫁コストを大幅に低下させることができます。
  • 課題と解決
    • ネスト型 VM はレイテンシーやページフォルト（メモリアクセスの遅延）を引き起こすため、この構成は理論的には非効率に見えます。
    • しかし、我々はこれを「高速なスケールアップ」と「低コスト」を実現するためのトレードオフとして受け入れ、Firecracker の最適化に重点を置きました。

技術的課題の解決策

ブラウザ作成のリクエストから実行可能な状態になるまでのプロセスには、以下の 3 つのボトルネックが存在しました。

1. インフラストラクチャの再構築：Unikernel を見送る

以前は起動が速くシャットダウンも可能な「ユニークアネル（unikernel）」技術を採用していましたが、トラフィックの急増（バースト）時に自動でスケールできない弱点がありました。

  • 事故の教訓: 負荷テスト中に本番環境が45 分間もダウンするという大規模障害が発生しました。
  • Firecracker の採用理由:
    • Unikraft（ユニークアネル）はエンジニアの手動操作に依存し、突発的な需要に対応できませんでした。
    • Firecracker は VM の作成・監視・実行を自動化でき、リソース割り当てと完全な隔離を保証します。
    • 再構築後のインフラは、需要に合わせて自動的に容量を拡張・縮小できます。

2. ブラウザ艦隊の自律管理（コントロールプレーン）

どの VM をどこに配置し、いつ追加すべきかを自動化するため、独自開発の**「コントロールプレーン（管理平面的な制御装置）」**を開発しました。

  • 自動スケーリングの仕組み
    • コントロールプレーンはブラウザ艦隊全体をリアルタイムで監視します。
    • トラフィック増：空きのある EC2 ホストを選択し、新しいマシンを起動してトラフィックを分散。
    • トラフィック減：不要なホストへの割り当てを停止し、マシンのシャットダウンを開始。
  • 一般的なモニタリングより速い反応
    • CloudWatch などの標準サービス（1 分単位の反応）に依存せず、独自の状態管理によりミリ秒単位での判断が可能です。
    • 起動中のブラウザや除去対象のホストといった詳細なメトリクスを監視しています。

3. 第一のボトルネック解決：メモリ最適化

VM の復元（スナップショットからの再開）時に発生する「ページフォルト」を解消しました。初期段階では VM メモリの約72% がページフォルトによって失われており、起動に 9.8 秒かかっていました。

  • メモリマッピングの拡大
    • 従来の 4KB ページ単位での読み込みから、2MB ページ単位のマッピングに変更しました。
    • メモリ処理量が 512 倍大きくなったことで、ページフォルトの発生回数が激減し、ネスト型 VM の通信オーバーヘッドを大幅に削減。
  • ユーザー_faultfd API の活用
    • Linux の 
      userfaultfd
      API を使用したカスタムハンドラを導入。
    • Chromium が最初にアクセスすると予想されるメモリ領域（ホットページ）を事前にロードし、起動直後の大量のページフォルトを防ぎます。
  • 結果
    • 起動までの時間を9.8 秒 → 3.1 秒に短縮。
    • メモリ不足エラー発生回数を約91 倍削減（10 万回→1,100 回）。

4. 第二のボトルネック解決：CPU パフォーマンスとスケジューリング

Chromium の起動時に多くのプロセスを生成するため、CPU リソースを効率的に配分する仕組みを導入しました。

  • 動的な vCPU ピン留め
    • 起動フェーズ（混雑時）: vCPU を固定せず、Linux が負荷に応じてコア間を柔軟に分散させます。これで同時起動の失敗を防ぎました。
    • 安定フェーズ（準備完了後）: ブラウザが準備できた時点で vCPU を特定のコアへピン留めし、スループットを増加。
  • ハイパースレッド対策
    • 物理コアを共有する論理スレッドの競合を防ぐため、各ブラウザ VM は物理コアの両方の sibling スレッドを使用するように割り当て。
    • これにより、起動失敗率を**17% → 0%**に改善。
  • リアルタイム優先順位
    • ピン留めされたスレッドにリアルタイム優先度を付与し、他の低優先度タスクよりもすぐに処理を実行させる仕組み化しました。

5. サードボトルネック解決：ステルス性の確保（ヘッドレス対策）

画面なし（ヘッドレス）ブラウザは、自動化ツールとして見抜かれやすく、ブロックされやすい弱点があります。

  • ヘッドフルブラウザへの追従
    • 多くのプロバイダは「描画サーバー」「GPU」「コンポジタ」のコストをかけて画面を表示していますが、我々は完全なヘッドレス環境で同等の結果を出しました。
  • 技術的アプローチ
    • Chromium フォークとパッチ: JavaScript による自動化検知対策（例：
      navigator.webdriver
      の改ざん）を回避するように最小限に修正しています。
    • フィンガープリンティングの活用: macOS、Windows、Linux など実在のユーザーの環境情報を使い、ボットとの区別がつかないように設計。
  • 結果
    • ステルスベンチマークで81% のブロック回避率。
    • 業界トップクラスの「Halluminate BrowserBench」では**84.8%**を記録し、他社を凌駕する性能を発揮しました。

6. 接続とルーティングの最適化

ブラウザが準備完了した時点で、ユーザーエージェントは公開 URL を経由して WebSocket 経由で Chromium に接続します。

  • エッジルーターによる負荷分散
    • ブラウザ艦隊の前には単純なエッジルーターを設置。
    • ルーターはコントロールプレーンに問い合わせ、存在する VM の場所を確認し、トラフィックを転送するだけの仕組みです（接続先決定はコントロールプレーンの役割）。
    • 一部のホストが障害となった場合でも、別のルーターや VM が即座に接続を引き継ぎます。

最終的な成果とインフラスペック

再構築された「Browser Use Cloud」の実績は以下の通りです。

  • 起動速度: コールドスタート（完全ゼロからの起動）が400ms未満。
    • p50（中央値）: 825ms
    • p99（上位 1% の遅延）: 1.35 秒
  • コスト: クロック当たり使用料 $0.02（従来の $0.06 から 7 割削減）。
  • 信頼性: Independent leaderboard「BrowserArena」で、100% の利用可能性を記録しランキング第 1 位を獲得。
  • 構成概要:
    • AWS EC2 上で動作する軽量 Firecracker VM。
    • その中でスナップショットから復元されたヘッドレス Chromium を実行。

今後の展望：Chromium の起動をスキップ

現在も、最大の課題である「Chromium 自体の起動コスト（約 545ms）」への挑戦が続いています。

  • 次のステップ:
    • 既存の VM をスナップショット化してすぐに起動させるのではなく、Chromium が既に動作している状態でセッションを開始する。
    • これにより、ブラウザをゼロから立ち上げる時間を完全に省略できます。
  • 技術的難しさ:
    • 稼働中のブラウザにはデバイス情報、タイマ状態、グラフィック描画、ネットワーク接続など多くの要素が存在します。これらを安全に「凍結」する技術を確立する必要があります。
    • さらに、復元後の各セッションが独立したブラウザとして認識されるよう、個性的な状態管理が必要です。

この開発により、最も速く、かつ低コストで動作するクラウドブラウザを実現しました。詳細については cloud.browser-use.com でご体験いただけます。

同じ日のほかのニュース

一覧に戻る →

2026/06/17 23:30

Lore：拡張性を備えたオープンソースのバージョン管理システムのためのストーリー

## Japanese Translation: Epic Games は、大規模なバイナリ資産と従来のコードを扱うゲーム開発者およびデジタルアーティストにとっての主要なスケーラビリティ課題を解決するために設計された新しいプラットフォーム「Lore」を発表しました。標準的なツールとは異なり、Lore は複合データタイプを含む複雑なワークフローに最適化されており、創意工夫のチームが抱える困難なプロジェクト特有のボトルネックに直接取り組んでいます。堅牢な開発ユーティリティで知られる主要な業界リーダーによって維持されるこのソリューションは、大規模なエンターテインメント制作を管理する組織にとって前例のない成長の可能性をもたらします。Lore の高容量アーキテクチャを実装することで、企業は現在のデータ管理の制限に縛られずに効率的性を大幅に向上させることができます。この転換により、プロのアーティストや開発者は業務を効果的にスケーリングすることができ、以前はストレージまたは処理の制約によって妨げられていた野心的なビジョンを実現できるより大きな協業チームを育成することができます。業界がより複雑なプロジェクトへと進化していく中で、Lore はプロジェクトの複雑性が劇的に増大してもクリエイティブなワークフローが流体性を保つことを保証する重要な前進を示しています。

2026/06/18 6:49

ストーリード・カラーズ——命名された色のカタログ

## Japanese Translation: 要旨は、カラーインデックスという出版物が、2026 年に立ち上げられ、特定の色の起源、化学組成、および資金出所を追跡するユニークな非商業的な刊行物であるということにある。広告収入に頼る通常の業界雑誌とは異なり、このニッチな索引は専門的な焦点を維持するために広告収益を一切排除し、学術的な分野や収集家を対象としている。本文では、6 月 15 日から 21 日までの入稿を扱った最新の号について記述されており、各 distinta な色調の詳細な歴史的および科学的注釈と資金源が添えられている。「最近の acquisitions」セクションには、この期間に含まれる全 252 件のうち 6 件が紹介されている。また、不定期のカラムである「書簡」では、新たな発見や争点となっている帰属問題を扱っている。関心のある購読者には、初号発送時に通知を受け取るための特定のオプションが用意されている。この最初の配信以降、出版物は将来の日時または主要な developments の概要を述べておらず、外部の宣伝的影響に頼ることなく、厳格なデータのみを対象とした継続的なリリーススケジュールを表明している。この構成により、ユーザーは真剣な研究や収集の目的に不可欠な純粋で検証済みの色彩情報を入手できるようになる。

2026/06/18 6:31

リークされた財務文書により、OpenAI が年間に数億ドルを失っていることが判明した

## Japanese Translation: ## まとめ： OpenAI は、金融時報（The Financial Times）とジャーナリストのエド・ジトロンが検証した漏洩された監査済み財務諸表の公開後、上場初回公開（IPO）へと進展しています。これらの文書は驚くべき成長を明らかにしています：収益は 2024 年の 37 億ドルから 2025 年の 130.7 億ドルに大幅に増加しました。これは主に積極的なスケーリングによるものであり、研究開発費は 78 億ドルから 191 億ドルへ急増しました（その内訳にはマイクロソフトへのモデル学習費用として 106 億超が計上されています）。この成長にもかかわらず、営業損失は 87.8 億ドルから 209.2 億ドルへと大幅に拡大しましたが、同社は損益対収益比率の改善により効率性が向上したと指摘しており、その比率は 237% から 160% に低下しました。研究、販売、マーケティングにおけるコストの上昇に伴い、OpenAI は 2030 年までに利益化を目指すことを約束しており、これは資本集約的な成長を経てから収益化するビジネスモデルを表明しています。