本文へ
ハクソク

世界を動かす技術を、日本語で。

EC2内で「Firecracker」VMを運用し、1秒未満でブラウザを起動する方法

元記事: 原文(browser-use.com)

概要

  • クラウドブラウザ の高速起動、強力な 分離性、低コスト化の実現
  • Firecracker による軽量VM採用と EC2上でのネスト仮想化 運用
  • Unikraft からの移行理由と 自動スケーリング制御プレーン の開発
  • メモリ管理・CPU割り当て・ステルス性向上 によるパフォーマンス最適化
  • 運用コスト削減 と ユーザー体験向上 の両立

クラウドブラウザ基盤の再構築

  • 高速起動、 分離性、 低コスト の同時実現が課題
  • 新セッション開始が 1秒未満、コストが $0.02/時間 に削減（従来の1/3）
  • ブラウザごとに Chromium・ファイルシステム・クッキー・キャッシュ・プロキシ設定 等を個別管理
  • VM（仮想マシン） による完全分離を採用、情報漏洩リスクの低減
  • 通常VMは重いため、 Firecracker ベースの軽量VMを選択

FirecrackerとEC2によるネスト仮想化

  • 各ブラウザセッションを 独立したFirecracker VM で実行
  • Firecrackerは通常 ベアメタルサーバ で利用されるが、コスト削減のため EC2上で運用
  • EC2自体がVM であるため、 VM in VM 構成で運用
  • ネスト仮想化は レイテンシ増加 の懸念があるが、 高速化技術 で克服

UnikraftからFirecrackerへの移行理由

  • 以前は Unikraft のユニカーネルで運用、起動は早いが 自動スケーリング に課題
  • トラフィック急増時に エンジニアの手動対応 が必要で、障害発生リスク
  • Firecracker ＋独自制御プレーンで 自動スケーリング を実現
  • 制御プレーンが リアルタイム監視 で適切なVM数を自動調整
  • CloudWatch よりも素早い反応で柔軟なリソース運用

ネスト仮想化のトレードオフと最適化

  • .metalインスタンス ではなく 通常EC2 を採用、 迅速なスケールアップ と低コストを優先
  • ホスト起動から 30秒以内 でサービス提供開始
  • ネスト仮想化での ページフォールトコスト増 を 2MBページ割当 と userfaultfdカスタムハンドラ で最適化
  • メモリ復元 の高速化で、ブラウザ起動時間を 9.8秒→3.1秒 に短縮
  • 不要なデバイスチェックの無効化 や vsockによる高速通知 で追加最適化

Chromium起動とCPUリソース管理

  • Chromium起動時 はCPU負荷が高いが、起動後は 待機時間が大半
  • 起動フェーズは vCPUをunpinned で分散、起動完了後に pinned で安定配置
  • ハイパースレッド の競合を避け、各ブラウザに 物理コアの両スレッド を割当
  • リアルタイム優先度 設定で、VMの即時実行を保証
  • これらの工夫で セッション失敗率を大幅削減

ステルス性（検知回避）とヘッドレス運用

  • ヘッドレスブラウザ は通常、Webサイトの ボット検知 に弱い
  • 従来のヘッドレスChromiumは 2% しかブロック回避できなかったが、 ヘッドフル では 50% 回避
  • 独自Chromiumフォーク でステルスパッチを低レイヤーで適用
  • JavaScriptインジェクションではなく、 ブラウザ本体で自動化検知情報を隠蔽
  • GPUやディスプレイサーバ不要 で、完全ヘッドレスかつ高いステルス性を実現

まとめと今後の展望

  • Firecracker＋EC2ネストVM の組み合わせで 高速・分離・低コスト を達成
  • 自動スケーリング制御プレーン による柔軟な運用
  • メモリ・CPU・ステルス性 の最適化で ユーザー体験 と セキュリティ を両立
  • 今後も パフォーマンス改善 と コスト最小化 を追求

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

通常のEC2はすでにVMだから、ちょっとしたトリックがあるんだ。AWSはホストを独自の隔離レイヤー内で動かして、その中でブラウザのVMを動かしてるってわけ。つまり、ブラウザはVMの中のVMってことだね。そうなんだけど、特定のEC2にはハイパーバイザーアクセスがあって、ファイアクレーカーも使えるのがあると思うんだけど、間違ってたら誰か教えて？

└

そう、c8i、m8i、r8iインスタンスタイプだけがそれをサポートしてるよ。これはネストされた仮想化って呼ばれてるんだ。[1] [1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...

└

大きなマシン（AWSメタルインスタンス）が必要だった時、メタルと同じサイズのVMのパフォーマンス差は、CPU集約型のワークロードで10-20%だったよ。

userfaultfdの利用が増えてるのはすごくいいね。これは本当に強力なAPIで、ページフォルトの時にメモリがどこからどう読み込まれるかを完全にコントロールできるんだ。

普通のヘッドレスChromiumは、アンチボット対策をしているウェブサイトに簡単に検出されちゃうよ。普通のヘッドレスChromiumは、私たちのステルスベンチマークによると、ウェブサイトにブロックされるのをたった2%の確率でしか回避できなかった。 > 私たちのブラウザは、ステルスベンチマークで81%、Halluminate BrowserBenchでは84.8%の確率でブロックを回避してる。これは他のプロバイダーの中で最高だよ。これって、すごく倫理的じゃないよね？こんなサービスプロバイダーを使うのは誰なんだろう？アンチボット対策の目的はボットを排除することなのに、そこにいるのは歓迎されてないよ。こういうサービスは、必然的にウェブを人間にとって敵対的で高くさせるんだ。ウェブサイトは自動使用に対してますます抵抗を示すだろうし、コンテンツにアクセスするためのハードルが高くなる。だから、ウェブ上での本人確認の推進があるのも納得できる。年齢制限や「子供を守る」だけじゃなくて、ボットからサイトを守るためでもあるし、広告収入を守るためでもある（支持の発言ではないけど、明らかに高次の効果だと思う）。

└

こんなサービスプロバイダーを使うのは誰なんだろう？ヘッドレスブラウザがブロックされるのを避けたい人たち？

└

すごく倫理的じゃないよね？こんなサービスプロバイダーを使うのは誰なんだろう？アンチボット対策の目的はボットを排除することなのに、そこにいるのは歓迎されてないよ。倫理的じゃないのは、誰かが望まないことをするから？それは理由や意図によると思う。イベントのチケットを取るために24時間パソコンの前に座ってる時間なんてないから、自分のボットを使って好きなバンドのチケットを買うのが倫理的じゃないってことにはならないと思う。多分ね。でも、転売目的でやったら？そしたら、倫理的じゃないって同意するよ。アンチボット対策の目的は、他の人が自動化すべきじゃないと思っていることでもできるようにすることだから、ハッカーニュースの読者の中には、そういうことに関わったことがある人も多いと思う。利益のためだけにやるのはもちろん良くないけど、転売業者に対抗するための手段として使うなら、まあOKじゃないかな。

└

（まだ試してないけど）私の使い方は、HNのストーリーのスナップショットを取ることなんだ。これが意外と難しいんだよね。ほとんどのウェブサイトはボットによるそれを防いでるから。例えば、クロードはHNのフロントページを読むのにすごく苦労してる。HN自体は大丈夫なんだけど、記事を選ぼうとすると、しばしば詰まっちゃう。ウェブサイトが確認用のキャプチャを出したり、ペイウォールがあったりするんだ。ペイウォールはHNのコメントを読んでアーカイブリンクを探すことで回避できるけど、そのアーカイブもボットをブロックすることが多いから、また最初からやり直しになる。倫理的かどうかは面白い問題だね。私は、虐待しない限り、インターネットのコンテンツを自分の好きなように使う権利があると思ってる。単にボットを持ってるだけじゃ虐待じゃないよ。ボットがサーバーを叩いたり、トレーニングデータを吸い上げたりしてるなら別だけど、今のところボットを持つのはすごく難しい。だから、このサービスに注目したのは、私が直面している問題を解決できるかもしれないからなんだ。HNにヒットした記事のスナップショットを取るのはそんなに難しくないはずなのに、実際は難しい。HNはウェブサイトに何百万ものビューを送ってるし、1つのボットがスナップショットを取ったところで大した違いはないと思う。ウェブサイトのオーナーの意向に反しているからって「倫理的じゃない」とは思わないよ。インターネットにコンテンツを投稿する時は、そのコンテンツをみんなと共有することに同意したことになるし、robots.txtで禁止されているもの以外はね。robots.txtでブラックリストに載っていなければ、ちゃんとしたボットがアクセスできるはずだと思う。ここにいる人たちが可哀想なボットクリエイターに興味を持つとは思わないけど、大半のボットクリエイターは悪意があるしね。でも、私はブラウザから情報を自由に処理できるプログラムを書くことができなくなったことを残念に思ってる。できるべきなのに、ウェブサイトのオーナーが「このコンテンツはGoogleのような承認されたボットだけがアクセスできて、他の人は立ち去れ」と言うのが許されるという考えに賛同してしまっている。HNはそんな風である必要がないことを証明してる。HNは1日に何千万ものページビューを持っていて、その多くはボットトラフィックだ。HNはアカウント作成やログインの時だけキャプチャを使ってる。robots.txtに指定された30秒のクロール遅延を尊重すれば、どんなコンテンツでもスクレイピングできるし、人間が取る行動（お気に入りに追加したり、投票したり）をするリンクにはアクセスしない限り、自由なんだ。これがインターネットのあるべき姿だと思う：ただコンテンツを届けるだけ。

└

これってすごく倫理的じゃないよね？こんなサービスプロバイダーを使う人っているの？アンチボット対策の目的はボットを排除することなのに、君はそこに必要とされてないよ。ウェブ経由でしかアクセスできないソフトウェアに自動化をかけてる会社を知ってるけど、APIのサポートが悪いか全くない場合が多いんだ。彼らはそのソフトウェアにお金（たいていはかなりの額）を払っていて、ログインを守るためにキャプチャが組み込まれてることが多い。彼らはキャプチャを外してもらうほどの大口顧客じゃないから、単にその制限を回避してるだけなんだよね。

└

これってすごく倫理的じゃないよね？文脈を考えずに倫理的に判断するのは難しいと思う。大量の自動スクレイピングの話をしてるの？それとも、個人的な必要のために地元の中古車ディーラーのリストを1日1回スクレイピングしてお得な情報を探してるってこと？前者は明らかに倫理的じゃないけど、どちらもCloudflareにブロックされる可能性があるよね。個人的にはそんなサービスを喜んで使うけど。

└

公開されているウェブサイトをスクレイピングすることが倫理的かどうかは議論の余地があるかもね。少なくともいくつかのケースでは、裁判所が合法だと判断したこともあるし、サイトが技術的な障壁を設けたり、停止命令を出してもね。おそらく倫理的に問題なのは、彼らが住宅用プロキシを提供していること。そういったプロキシの住宅提供者は、そんなサービスを提供するためにオプトインされていることを知らないことが多いんだ。

└

どのくらいの割合が「正当な」使用ケースで、どれが道徳的に疑わしいのかはわからないけど、うちの場合はCMSを使っていて、コンテンツチームが外部リンクを含めることができるんだ。そのリンクがちゃんと機能しているか定期的に確認する必要があるけど、クライアントでGETリクエストを送るだけでは簡単じゃないんだよね。

Hacker Newsで議論の続きを見る