EC2上でFirecracker VMを爆速起動！ブラウザを1秒未満で立ち上げる技術の裏側

EC2環境にてFirecracker VMを運用し、ブラウザを1秒未満という驚異的な速度で起動させるための実装手法と最適化の知見を解説します。

userfaultfd の活用例が増えてきて最高だね。ページフォルトが発生した際に、メモリをどこから、どのようにロードするかを完全に制御できる強力なAPIだよ。

素のヘッドレスChromiumは、ボット対策を行っているWebサイトなら簡単に検知できる。我々のステルスベンチマークによると、対策済みのサイトでブロックを回避できたのはわずか2%だった。

我々のブラウザは同ベンチマークで81%、Halluminate BrowserBenchでは84.8%の回避率を記録しており、業界最高レベルだ。

これってかなり非倫理的じゃない？一体誰がこんなサービスを使うんだ？ボット対策ってそもそもボットを排除するためのものだし、歓迎されてないってことだよね。

こういうサービスはWebをより人間にとって使いづらく、コストのかかる場所にするだけだ。サイト側は自動アクセスへの対抗を強めるだろうから、コンテンツへのアクセス障壁はますます高くなる。

WebでのID認証が推し進められているのも、年齢制限や「子供の保護」だけでなく、サイトをボットから守り、広告収益を維持するためなのは間違いないだろうね。（支持しているわけじゃないよ、ただ明白な高次の影響としてそう見えるって話）

これだけやっておきながら、まだChromiumに固執しているのが少し意外。

うちはもっとシンプルな構成のWebアクセス用MCPサーバー0を使ってる。ブラウザインスタンスをサブプロセスとして立ち上げているんだけど、ChromeからLightpanda1に切り替えたのが、安定性とCPU・メモリ使用量において最大の成果だったよ。

記事の最後にある通り、起動が速いブラウザっていうのは、そもそもメモリの確保量が少ないブラウザなのかもしれない。

うちはスクリーンショットAPI（ApiFlash）で、EC2上のFirecrackerではなく、AWS LambdaのコンテナイメージにChromiumをパッケージングして運用している。Lambdaなら隔離環境もオートスケーリングも無料でついてくるから、スクリーンショットみたいなスパイクが発生しやすいステートレスな処理には理想的だね。browser-use系ソリューションとほぼ同じメリットを、ずっとシンプルなアーキテクチャで享受できていると思う。トレードオフはLambdaのコールドスタートだけど、実際には連続して呼び出せばホットな関数が再利用される。結果として、ある程度のボリュームがあれば負荷のスパイクは均されるし、コールドスタートもそこまで頻繁には起こらないよ。

ここで触れられていないけど、通常のEC2インスタンスでネストされた仮想化が可能になったのは今年の2月から[1]なんだよね。それまではFirecracker VMを動かすにはベアメタルなEC2インスタンスを使うしかなかった。

Firecrackerって何のために必要なの？コンテナで直接動かせないの？隔離の懸念はわかるけど、ブラウザとコンテナの脱獄（ブレイクアウト）なんて数億ドル規模のCVE（脆弱性）じゃない？

次：Chromiumの起動をスキップする
ブラウザは実行中にデバイス、タイマー、グラフィック状態、ネットワーク状態、フィンガープリント状態などを保持しているため、これは複雑だ。

うーん、リクエストが来たら即座に割り当てられるように、あらかじめ起動しておいたブラウザのプール（ウォームプール）を持っておけばいいんじゃない？ユーザーにとってはレイテンシがほぼゼロになるし。トラフィックパターンに基づいてプールの規模を調整する予測ロジックは必要だけど、それが一番簡単な解決策に思える。

中身は薄くて、誇張が多いね。9.8秒から3.1秒になったのはuserfaultd + hugepagesのおかげで、500msはPS/2マウスの件でしょ……で、400msまで削るための残りの時間はどこに行ったんだ？

Firecrackerは素晴らしい技術だよ。自分の面接用スタートアップで、コーディング面接用の隔離されたランタイム（や個人用ワークスペース）を動かすのに使ってるけど、すごく頑丈で超軽量。Go SDKを通じた連携もめちゃくちゃ簡単だった。

起動を高速化するためにブラウザ起動前の状態を保存するのは面白いけど、どうやって設定するの？もしかして設定しないのか、それとも起動後に設定する感じ？