1 サーバーに 100 万のサンドボックスを収容する AI インフラのスケーリング問題解決法

https://www.infoq.com/ | プレゼンテーション

1 つのサーバーに 100 万個のサンドボックスを詰め込むことで、AI インフラのスケーリング問題を解決する

プレゼンテーションを見る

再生時間:

ダウンロード

48:09

/presentations/unikraft-microvm-sandboxes-cloud-scaling/en/slides/slide-1787571366262.jpg)

概要

フェリペ・ウイシ氏は、Unikraft がどのようにして AI ワークロードのサンドボックス化においてミリ秒単位の起動、状態を保持したスケール・トゥ・ゼロ、そして極限までの高密度を実現しているかを解説します。彼は分離の仕組みや Linux カーネルの最適化、スナップショット技術について議論し、ハードウェアレベルのセキュリティを維持しながら Kubernetes 環境とシームレスに統合しつつ、大規模な運用でもサブ 10ms のパフォーマンスを維持する方法を実証しました。

登壇者略歴

フェリペ・ウイシ氏は、次世代クラウドプラットフォームを構築するスタートアップ「Unikraft」の CEO かつ共同創設者です。それ以前は NEC ラボラトリーズ・ヨーロッパでチーフ研究者として活躍していました。また、Linux Foundation が運営するオープンソースプロジェクト「Unikraft」の創設者の一人であり、メンテナーとしても活動しています。

コンファレンスについて

ソフトウェアが世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を力強く支えるイベントです。実践者が主導するこのカンファレンスは、チーム内でイノベーションを牽引する技術リーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象に設計されています。

INFOQ EVENTS

2026 年 9 月 17 日午後 1 時（EDT）## PR の向こう側：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン 登壇：モヒット・スーマン（Harness シニアプロダクトマネージャー）

2026 年 10 月 8 日午後 12 時（EDT）## AI が開発を加速させる時代、CI パイプラインは追いつけるのか？ 登壇：エリック・メタジ（Datadog ソフトウェアデリバリープロダクトマーケティングマネージャー）、ロヒン・チャンドラ（Datadog CI/CD オプティマイゼーションプロダクトマネージャー）

トランスクリプト

フェリペ・ウイシ： こんにちは、フェリペと申します。ユニクラフトの CEO 兼共同創業者です。私たちはクラウドプラットフォームを構築するソフトウェアを提供しており、その上で他社がクラウドプラットフォームを構築することも可能にしています。セキュリティが高く、仮想マシン（VM）も高速で動作することを目指しています。

本日は主に「サンドボックス」についてお話しします。これが今回のテーマの核心だからです。かつてサンドボックスはコンテナの一種として扱われていましたが、現在では AI の文脈で語られることが多くなっています。この用語の意味合いが再定義されたことを知っている方もいらっしゃるでしょうが、その点については後ほど詳しく触れます。

さて、仮想マシンのコールドブートにどれくらい時間がかかるか、ご存知ですか？いくつか選択肢を提示しましょう。ランチの時間があるか、コーヒーを飲む時間があるか、数秒かかるか、それとも数ミリ秒で済むか。もちろん、私が「速くできる」と説得しようとしているので、「数ミリ秒」と答えたいところですが、それが本当かどうかは後ほど確認しましょう。

次に、48コアのサーバーに仮想マシンをいくつ収容できるでしょうか？私はこう書きました。「Ubuntu ベースの 1 つ」「数十台」「冒険心があれば数百台」。もし使用していない時にスケールゼロを実現できれば、さらに高密度化も可能かもしれません。

クラウドで最も優れたマルチテナント隔離を提供するのは何でしょうか？選択肢は「仮想マシン」「コンテナ」「言語レベルのランタイム」、そして「サーバーへのケーブルを抜くこと」です。もちろん正解は後者ですが、ケーブルには何か有用な役割があるはずなので、元に戻す必要があります。その上で、私は仮想マシンこそが最適解だとお伝えしようと思います。

クラウドのスケーラビリティの道 - 隔離の基盤

今回の発表のテーマは「クラウドのスケーラビリティという、長く曲がりくねった道」です。ロンドンでの開催ということもあり、私はビートルズファンなので、その名曲にちなんだタイトルをつけました。

まず、後続の内容を理解していただくために、少し立ち止まって「分離（アイソレーション）の基礎技術」について振り返っておきましょう。コンテナや仮想マシン、ユニカーネル、マイクロVM、そしてアイソレートなど、さまざまな技術が存在します。まるで「分離のスープ」のような状態です。

そのためか、「分離されていれば中身はどうでもよい」と考える人も増えています。私は研究出身で図解が得意なため、いくつかの図を使って、これらの基礎技術を簡潔に解説しようと思います。

まず標準的な仮想マシンから見ていきましょう。ご存知の方も多いかと思いますが、サーバーを起点として話を進めます。

さらに、ハイパーバイザーと呼ばれるものをインストールします。これは非常に小さなオペレーティングシステムのようなもので、基本的な CPU や RAM のリソース共有を担当し、その上に仮想マシンを構築できます。

ホスト OS（通常は Linux）も用意されます。仮想化に詳しい方からは「Xen ハイパーバイザーもあるし、他のアーキテクチャもある」と指摘されるかもしれませんが、ここでは説明を簡略化しています。

このホスト OS 内には VMM（Virtual Machine Monitor：仮想マシンモニター）が存在します。QEMU や Firecracker をご存知の方もいらっしゃるでしょう。これらは実際に仮想マシンを起動する役割を果たします。

そして、ホストの上にゲストが置かれることになります。これが実際の仮想マシンです。通常はカーネル（Linux カーネルなど）とディストリビューション、アプリケーションなど、その上に載るすべての要素に分割されます。

これは仮想マシン（VM）の世界の話です。マイクロ VM という用語を聞いたことがある方はどれくらいいらっしゃるでしょうか？マイクロ VM は本質的に通常の VM と同じもので、違いはそれを起動する VMM（仮想マシン管理プログラム）、つまり「小さな箱」がファイアクラッカーである点だけです。

実はこの名前変更は、ファイアクラッカーチームの判断によるものです。彼らはより高速に VM を起動できる VMM を開発したため、「新しい名前が必要だ」と考え、こうしてマイクロ VM という呼称が生まれました。つまり、ファイアクラッカーによって起動された 16GB の Ubuntu インスタンスであっても、それはマイクロ VM と呼ばれるのです。

次に「ユニカーネル」についてです。ユニカーネルもまた VM の一種であり、ファイアクラッカーで起動可能です。したがって、「ユニカーネル・マイクロ VM」という形態も存在します。ここで重要なのは、内部の構造の違いです。

ユニカーネルの概念は以下の通りです。Web サーバーのようなアプリケーションを想定した場合、そのアプリが動作するために必要な機能だけを備えたカスタム OS を構築し、それをアプリと一体化（マッシュアップ）させます。余計な要素は一切含まれません。

これが主な違いです。コンテナは全く異なる世界で、ハイパーバイザーが存在せず、ハードウェアの上に直接ホスト OS（例えば Linux カーネル）が乗ります。その上には、カーネルへの悪影響を防ぐことを目指す「シャイム層」と呼ばれるコンテナランタイムが置かれますが、必ずしも完璧に機能するわけではありません。さらにその上には、実際のコンテナ、つまりアプリケーションが存在します。

もちろん、これらの要素を組み合わせて工夫することも可能です。まずはランタイムの分離について考えましょう。「アイソレート（isolate）」をご存知でしょうか？Node.js や JVM のような言語では、実行プロセスであるアプリケーションに対して言語レベルで分離機能を提供しています。つまり、主要なモデルは VM、コンテナ、そしてランタイム分離の 3 つです（多少簡略化して説明しています）。

これらを組み合わせることもできます。例えば、コンテナを VM の内部に配置すれば、VM の構成と同じスタックになります。ただし、VM の内部に入ると、そこで初めてコンテナランタイムとその上のアプリケーションが現れます。

これが ECS が採用しているアプローチです。コンテナ単体では安全性が十分でないため、VM 内に収容して分離を図り、「分離の中の分離」を実現しています。

もちろん、論理的に突き詰めれば、中心から「アイソレート→コンテナ→仮想マシン」という階層を逆転させることも可能です。その結果、あまり意味のない冗長な分離構造が積み重なり、パフォーマンスだけが低下する巨大なスタックが生まれることになります。

なぜ仮想マシンなのか？

なぜ仮想マシンなのか。ウィキペディアを調べてみると、「信頼できる計算基盤（Trusted Computing Base）」の定義が見つかります。これは、重要なコードの安全性は、そのコードが動作するソフトウェアの層全体に依存するという意味です。このソフトウェアの層こそが「信頼できる計算基盤」であり、これを可能な限り小さく保つ必要があります。なぜなら、一般的にコード量が増えるほどセキュリティ上の脆弱性も増す傾向があるからです。

先ほど紹介したモデルにおいて、これが具体的にどうなるのか考えてみましょう。仮想マシンの場合、信頼できる計算基盤とは、すべての異なる仮想マシンやアプリケーションに共通する部分です。つまり、ここが最も重要なポイントとなります。この場合、それはハイパーバイザー（hypervisor）のことです。ハイパーバイザーの利点は、完全なオペレーティングシステム全体よりも小さく、軽量である可能性が高いという点にあります。

一方、コンテナの世界ではハイパーバイザーは存在しません。代わりにホスト OS が機能します。つまり、信頼できる計算基盤として考えられるのは Linux カーネルのようなもので、コード量は数千万行に及びます。このカーネルとランタイムは、本来分離されるべきすべてのアプリケーションに共通して存在するため、結果的に信頼できる計算基盤の規模が大幅に拡大してしまうのです。

もちろん、言語ランタイムの例を見ればその方向性がわかります。現在、信頼できる計算基盤（Trusted Computing Base）は、ホスト OS だけでなく、言語ランタイム全体にまで広がっています。そして、その上にアプリケーションが構築されます。

ここで一つ質問です。もし VM の内部にコンテナを配置した場合、信頼できる計算基盤は何になるでしょうか？それはまるで通常の VM と同じように見えます。なぜなら、アプリケーション間で共有される層は依然としてハイパーバイザーだけだからです。それ以外の部分はすべて独立しています。各 VM は独自の OS を持ち、独自のランタイムも備えています。

この構成は一見非効率に見えますが、非常に高い分離性を保つことができます。では、この優れた分離性を維持しつつ、効率的にすることは可能でしょうか？

少し皮肉を込めて言いますが、「コンテナは実際には中身を含んでおらず」「アイソレーション（隔離）も完全ではない」というのが実情です。それでもなお、VM はクラウドにおける黄金基準として君臨し続けています。

最小限の VM

話を戻しましょう。数年前、私はロンドン大学ユニバーシティ・カレッジ（UCL）の博士課程に在籍していました。当時、イギリスの研究プログラムが仮想ルーターの開発を進めており、ソフトウェアによるパケット処理を仮想マシン（VM）内で高速化することを目的としていました。

その構想はこうでした。仮想マシンの内部にはハイパーバイザーがあり、ゲスト OS とゲストアプリケーションが存在します。このアプリケーションでソフトウェアベースのパケット処理を行いたい場合、どのようなアプローチが考えられるでしょうか？

UCL はケンブリッジ大学と非常に密接な関係にあり、ケンブリッジは「Xen」というハイパーバイザーの開発拠点でした（ご存知の方も多いでしょう）。彼らは私たちに、「ミニ OS」と呼ばれる非常に小さな参照用オペレーティングシステムがあるので、それを使ってみないか」と提案しました。

私たちのプロジェクトでは、マサチューセッツ工科大学（MIT）から提供された「Click Modular Router」というソフトウェアを採用し、これをミニ OS と組み合わせることで、高速かつ軽量な仮想マシンを実現することができました。

数年後、私たちは「ClickOS とネットワーク機能仮想化の芸術」という論文を発表しました。これにより、仮想マシンからソフトウェアで 10〜20 Gbps の処理が可能であることを示すことができました。もちろん、当時は驚異的な速度でしたが、現在ではその数値にゼロを一つ足してこそ印象的と言えるでしょう。

また、仮想マシン自体が非常に小さく、起動に数ミリ秒しかかからないという測定結果も得ています。これにより、従来の 48 台の Ubuntu インスタンスを超え、数百台規模での運用が可能になりました。これは、将来何が実現できるかの一端を垣間見せるものでした。

さらに数年が経ち、Docker の波が到来しました。Docker は私たち全員を救う救世主として登場し、「完璧な分離」「ミリ秒単位の起動」を実現すると期待されました。しかし、セキュリティ分野の専門家はすぐに警鐘を鳴らしました。「これはそれほど安全ではない」「速度も期待ほどではない」という指摘です。

もちろん、私たちは「私の VM はあなたのコンテナより軽量（かつ安全）だ」と題する白書も発表しました。ここでは Xen を徹底的に改造し、1 台のサーバー内に大量の仮想マシンを収容することを目指しました。グラフにあるように、8,000 個もの VM を動かすことに成功し、コールドブート時間をミリ秒単位で実現しています。

その後、コンテナランタイムとの比較を行いました。結果は明確です。適切なエンジニアリングを行えば、高い分離性と優れたパフォーマンスを両立できるのです。この白書は大きな反響を呼び、学術界では約 28,000 件の引用を集め、TikTok でバズったレベルの注目を集めました。

数年後には Hacker News でも話題になり、そこから私たちは独自の仮想マシン開発へと進みました。その一例がパケット処理用のものや、キャッシュ用「Minicache」、Python 実行環境用「Minipython」です。命名センスについては自虐的ですが、これらのプロジェクトは順調に進んでいました。

しかし、カンファレンスで発表すると、聴衆からは「素晴らしいですね。では、他のアプリケーションやサービスも動かせるのですか？」という質問が次々と寄せられました。

私たちは手作業でこれらすべてを構築していました。その答えは常に「不可能」でした。そこで、こうした専用仮想マシンを構築するための SDK を作るべきか考え始めました。これがきっかけとなり、Linux 財団のオープンソースプロジェクトが生まれました。これもまた、Xen の関係者たちの協力があってのことです。彼らはインキュベータープログラムへの参加を提案し、「ぜひ応募してください」と言ってくれたのです。その後、独立した Linux 財団プロジェクトとして立ち上げることも可能になりました。私たちが目指したのはまさにそれでした。それから約7年間、私たちはこの OS の構築に取り組んできました。

詳細については割愛しますが、主な目的の一つは Linux API との互換性を可能な限り保つことでした。そうすれば、修正を加えない既存のアプリケーションもそのまま動作させることができるからです。

数年後、私たちはそのオープンソースプロジェクトの成果をまとめた論文「Unikraft - Fast, specialized unikernels the easy way」を発表しました。しかし、引用数はわずか8,000件程度で、大きな話題にはなりませんでした。それでも Hacker News で再び取り上げられましたが、これが過去の歴史における最後の出来事でした。

Key Requirements

では、より最近の歴史である 2022 年頃の話に移りましょう。私たちは「素晴らしい成果だ」と考えました。画像を小さく軽量にでき、いくつかの実証実験も成功させたのです。それらの原則をすべて適用した場合、クラウドプラットフォームはどのような姿になるでしょうか。

効率性、スケーラビリティ、セキュリティを最優先の要素とすることを目指しました。これらいずれかを妥協したくはありませんでした。重要な要件はいくつかありました。もちろん、本日のテーマ通り、すべてのワークロードに対して強力な分離性を確保したいと考えていました。同時に、起動速度も非常に速いことが求められました。

なぜそれほどまでに高速である必要があるのでしょうか？それは、ユーザーがシステムがオフになったことに気づいてほしくないからです。ただし、アイドル状態のときは、何も作業を行っていないためシャットダウンできるようにし、必要なタイミングで素早く起動できるようにしたいと考えています。起動を迅速に行えれば、ユーザーはシステムがスリープに入ったことさえも感じないかもしれません。

再開する際は、必ず中断した時点から復元されるべきです。状態が失われるとユーザーに不具合として認識されてしまうため、それは避けなければなりません。

また、新しいワークロードを実行できることも重要な要件です。Dockerfile で定義できれば、それを実行可能である必要があります。機能性が最優先であり、実行したい処理ができない状態で性能を語っても誰も聞き入れません。機能ファースト、パフォーマンスはその後です。

もちろん、サーバーあたりの高密度化も目指します。1 台のサーバーにどれだけのリソースを詰め込めるかについては、後ほど詳しく説明しましょう。

まず着手したのは、Dockerfile を取り込み、オープンソースの CLI ツール「Unikraft」を活用することでした。このツールは Dockerfile からファイルシステムとバイナリを抽出し、仮想マシン（今回は AWS で試したため AMI 形式）に変換します。

これはインスタンス、つまり仮想マシンの作成を意味します。当初はローカルサーバーで得られていた 10 ミリ秒が目標でした。しかし、AWS のダッシュボードにある「起動」ボタンを押した際に実際にどれくらい時間がかかるか、皆さんはいくつと予想されるでしょうか？結果は約 30 秒でした。

これは明らかに素朴なアプローチであり、会場にいる多くの人々も「なぜそんなボタンを押す必要があるのか」と思ったはずです。実は、クラウドプラットフォームとは単に高速なイメージがあるだけではありません。その間には多くのコンポーネントが存在します。リクエストを送信するとまずロードバランサーが働き、次にプロキシを経由し、仮想マシンのライフサイクル管理を行うコントローラーが処理を行います。そして実際に VM を起動するのは Firecracker といった仮想マシンモニターです。最後にイメージが読み込まれます。

私たちが目指したのは、ユーザーからこの一連のチェーンを経て再びユーザーに戻るまでの全体をミリ秒単位で完了させることでした。

ユニカーネルの技術を活用して、すべてのコンポーネントで効率化を図り、ゼロから構築し直す必要があると考えました。リクエストが入るとまずプロキシが受け取り、その内容をバッファリングします。その後、コントローラーに「この接続IDについて何か知っていますか？」と問い合わせます。

コントローラーは「はい、存じています。以前稼働していたインスタンスで、現在はスリープ状態です。再開する必要があります」と応答し、Firecracker に「そのインスタンスを起動してください」と指示を出します。QEMU をご存知の方も多いでしょうが、こちらは採用していません。なぜなら処理が遅く、重たすぎるからです。

また、Intel Cloud Hypervisor も使わないことにしました。数千台の仮想マシンを同時に動かそうとした際、CPU に大きなジッター（揺らぎ）が発生し、パフォーマンスに悪影響が出たためです。

こうして実際の仮想マシンが起動すると、プロキシに対して「準備完了」のシグナルが返されます。プロキシはバッファリングしていたリクエストを解除し、インスタンスへ転送します。インスタンスはユーザーへの応答を行い、もしこの一連の流れが非常に高速に行われれば、ユーザーには何が起こったか気づかれず、「ただリクエストを送っただけで、以前から動いていたはずのサービスが即座に返事をした」という感覚だけが残ります。

エンドツーエンドでミリ秒単位の性能を実現する道程において、ロードバランサーもプロキシもコントローラーも VMM も高速化できていると確認しました。では、イメージはどうでしょうか。なぜなら、アプリケーション、特に厄介なアプリケーションが起動に 2 秒も 10 秒もかかってしまうことがあるからです。JVM が私の神経を逆なでています。なぜこれほど時間がかかるのか。どうすれば、せっかく達成したミリ秒単位の性能をアプリケーションが台無しにしてしまわないようにできるのでしょうか。

その解決策として提案するのが「スナップショット」です。スナップショットとは、実行中の仮想マシンの内部状態を任意の時点でコピーしたものです。利用可能なすべての仮想マシンモニターでこの機能を利用できます。Firecracker に対してスナップショット作成を要求する REST API コールが存在します。これは単にその瞬間の「写真」を撮り、ファイルとして保存するだけです。そうすれば、その時点での仮想マシンの全内容がすべて保存されます。

この技術で何ができるでしょうか。例えば、月に一度の CI/CD リリースがある場合、そこからイメージを配布し、VM を起動してアプリケーションが数秒から数分かけて準備されるのを待たなければなりません。しかし、実際にサービス開始の準備が整った時点でスナップショットを取得します。

その後、サービスを「利用可能」として公開しますが、実際の VM はそのスナップショットから事前初期化された状態で起動します。これにより、従来の 2 秒や 5 秒といった起動時間を完全に隠蔽できます。スナップショットからの起動は約 10 ミリ秒で完了するのです。

さらに、このスナップショットをテンプレートに変換することも可能です。そうすれば、そのテンプレートから同時に任意の数の仮想マシンを起動できるようになります。

スナップショット機能の恩恵はこれだけではありません。もちろん、これはステートフルなスケール・トゥ・ゼロを可能にするための基盤です。つまり、仮想マシンをシャットダウンしても、以前の状態から正確に復元して起動できます。

フォーク機能も利用可能です。実行中の仮想マシンに対して「フォークせよ」と指示することで、サブエージェントのようなものを生成できます。チェックポイント機能を使えば、「今すぐチェックポイントを」と指示し、必要に応じて何度でも記録を残せます。その後、例えば健全な状態まで巻き戻すことも可能です。

もちろん、移行も可能です。実行中の仮想マシンを別のサーバーへ移動させることができます。最後に挙げたアプリケーションのマスク化については、すでに説明しました。イメージ機能も同様です。今後はミリ秒単位の起動速度が求められています。

汎用的なワークロードはどうでしょうか？ユニカーネルは特定のアプリケーション向けですが、サンドボックスなら何でも実行できます。ヘッドレスブラウザなどもその一例です。これを実現するために、Linux カーネルを採用しつつ、ユニカーネルの原則を適用しました。

では、入手可能な最も小さく軽量な Linux カーネルとは何でしょうか？さらに、ディストリビューションを「distroless（ユーザー空間にほぼ何も含まない）」化することも可能です。これは、カーネル起動後に最初に実行される init プロセスに至るまで極限まで削ぎ落とした状態です。

この仕組みを用いて、Dockerfile に記述されたアプリケーションを実際に起動します。その結果、Linux ベースの最も小さなディストリビューションが完成し、あらゆるワークロードを高速に実行できるようになります。

要件についてはすべてクリアできました。次に、サーバー密度について触れておきましょう。

標準的なサーバーで標準的な仮想マシン（VM）を使用する場合、収容できる VM の数は限られます。その中には「緑色」の VM もあれば、「灰色」の VM もあります。「緑色」とは実際に有用な作業を行っている VM を指し、「灰色」とは何もしていないアイドル状態の VM です。これが従来の一般的なパターンでした。

ここで提案するアイデアは、VM の起動・停止をミリ秒単位でスケールできる仕組みを作ることです。これにより「チート」が可能になり、アイドル状態の VM は即座にスリープさせ、その分のリソースを他の用途に転用できます。結果として、1 台のサーバーに収容できるリソース量を大幅に増やすことが可能になります。

例えば、1,000 ユーザーが登録されているサービスでも、同時にアクティブなのはたったの 10〜20 人だけというケースは珍しくありません。残りの 800 人以上のユーザーについては、使用していない間はリソースをゼロにスケールダウンし、その空き容量を他の VM に割り当てることができます。これにより、サーバーあたりの密度を劇的に向上させることが可能になるのです。

ゼロからスケールする環境でも、いかに密度を高めるか。我々は多くのコンポーネントをスケーラブルに設計し、5,000 台、10,000 台へと増やしては喜んでいましたが、それでもどこかで必ず破綻しました。

Linux ホストが激しく困ったのは、各仮想マシン（VM）ごとに TAP デバイスを割り当てていたことです。Linux カーネルも「いったい何をしているのか？なぜ 50,000 個もの TAP デバイスが必要なのか」と叫ぶような状態でした。カーネルロックがフリーズし、NTP や SSH といったサービスも機能不全に陥りました。

また、Tail Scale を実行していましたが、起動時にクラッシュする問題が発生しました。これらを解決するためには、多くの調整を余儀なくされました。さらに、Linux ブリッジに割り当て可能なポート数にも上限があるため、その点についても対策が必要でした。

IPv6 のロック競合やスナップショットの問題も存在します。スナップショットを作成することは可能ですが、ディスク容量を消費してしまいます。そのため、私たちは高速アクセスを実現するために NVMes を採用しています。ストレージは無限ではないため、毎回フルスナップショットを取るのではなく、インスタンスが起動・終了する際の差分のみを取得する「差分スナップショット」を採用する必要があります。圧縮されたスナップショットを作成する方法を開発しましたが、その際にも、スナップショットを圧縮しても高速に起動できること、およびテンプレートへの参照リンクなどの機能が正常に動作することを保証する必要がありました。

なお、プラットフォームの詳細や、プロキシがコントローラーと通信する仕組みなどについては深く掘り下げませんが、ネットワーク経由での通信が非常に遅延していたため、すべての通信をネットワークプロトコルに依存せず、共有メモリベースで実装し直す必要がありました。

数字で見てみましょう。10 万台の VM（仮想マシン）におけるコールドスタート時間を測定したグラフがあります。線が多いことについては気にしすぎないでください。主に紫色のラインがコールドブート時間、一番上のラインは最初のパケット到達までの時間です。単純化のためにこう考えてください。

肝心な点は、起動に約 10 ミリ秒かかることです。スケールアップしてもこの時間はほぼ一定です。最初のパケット到達までの時間はわずかに長いですが、それでも安定しています。CPU やメモリ使用率も測定しましたが、もちろんスケーリングは機能します。システムが立ち上がり、処理を行い、必要なくなればゼロまでスケールダウンします。その状態では CPU 消費量はほとんどありません。

コントローラーのメモリ使用量は約 12GB です。これは、コントローラーが事前に 100 万台分の VM をサイズ調整しているためです。また、スリープ中の VM 1 台あたり数 KB のメタデータを使用します。

もちろん、スナップショットストレージの使用量は線形に増加します。圧縮や差分スナップショットなどの工夫を施しましたが、100 万台分を維持するには約 12TB の容量が必要です。これは十分に実現可能です。最近のサーバーには安価なモデルでも 2TB の NVM（不揮発性メモリ）が 2 基搭載されており、さらに増設も可能です。

さて、要件に戻りましょう。最後の項目はクリアしました。

ユースケース

この技術が何に役立つのか、疑問に思われるかもしれません。もちろん、サンドボックスの話です。これについては後ほど詳しく説明します。

ヘッドレスブラウザをご存知の方はどれくらいいらっしゃるでしょうか？これはエージェントの主力となるツールです。エージェントがウェブ上の情報を取得する際、通常は Chromium ベースのヘッドレスブラウザを使用します。しかし、Chromium には大きな問題があります。起動に非常に時間がかかるのです。30 秒から 1 分かかることも珍しくありません。

そのため、即応性を持たせたり、多数のインスタンスを運用したりするには、常時稼働させておくしかありません。ところが、ヘッドレスブラウザはメモリ消費量が膨大で、1 インスタンスあたり 4GB、8GB、あるいは 16GB を消費します。各インスタンスが 16GB のメモリを必要とする場合、サーバーにどれほどの数を詰め込めるか想像してみてください。決して多くはありません。

そこで本稿のアイデアです。スケールダウンしてゼロまでリソースを削減できれば、起動はわずか 10 ミリ秒で完了し、必要なタスクを実行した後はすぐにスリープ状態に戻ります。

もちろん、機能です。ビルドやテスト環境も同様です。コールドブートを排除できれば、ビルド環境の起動に 30 秒から数分かかり、その後にビルドにさらに 1 分かかることもあります。これは比率としてあまり良くありません。

そして、他の要素としてサンドボックスがあります。サンドボックスとは何でしょうか？本質的には、フルアクセス権限があり何でも実行できる仮想マシンのことです。もちろん、強力な分離が必要です。なぜなら、最近の AI エージェントを信頼する人はほとんどいないからです。彼らは予測不能で、暴走する可能性さえあります。

これらの環境は断続的に使用されます。ユーザーがエージェントと対話しているか、あるいはエージェント同士がやり取りしている場合もありますが、しばらくの間は非アクティブな状態になることもあります。そのため、使わないときはスリープ状態にして、必要な時に素早く復元できるようにするのが望ましいです。また、各セッションで何が行われたかの状態を保持しておく必要があります。

もちろん、サンドボックスを提供する企業にとってはスケールが重要です。世界中に大量の環境が存在しているからです。

デモを始めましょう。ここで紹介する内容はすべて Dockerfile に基づいています。まずは nginx を使って仕組みを説明します。イメージに含めるべき最適化を施したため、今回は軽量な nginx イメージを使用しますが、標準的な Dockerfile を使用しても問題ありません。

次に、このイメージから仮想マシンを 1 つ作成し、スケールゼロ（必要時にのみ起動）の設定を行います。ここでは「nginx-0」という名前で登録します。監視機能も設定済みです。まだ準備が整っていないため、まずは起動させましょう。

起動後、ステータスを確認すると「スタンバイ中」と表示されます。これはスケールゼロの状態を意味し、メモリも CPU も一切消費していないことを示しています。それでは、実際にこのインスタンスにアクセスしてみましょう。

すぐに返答が返ってきました。もしかすると、少し速すぎたかもしれません。スタンバイ状態を注意深く見守ってください。一瞬だけ「実行中」になり、応答し、再びスタンバイに戻る様子を確認できるはずです。私が試すたびに、必ず上昇して応答し、その後下降します。もう少し素早くやってみましょう。実行中のまま維持されるはずですが、最終的にはまた下降するでしょう。これが基本的なワークフローです。これは単に Nginx の動作を示しているだけです。少し退屈かもしれませんね。

では、サンドボックスを見てみましょう。もちろん、最近の文脈で「サンドボックス」と言えば Claude を指します。それでは、このデモを始めましょう。画面の右側を見ると、箱には大量の OpenClaw がロードされているのが確認できます。それぞれが仮想マシンです。すべてはゼロにスケールされています。私がこれから行うのは、一つを起動することです。

この場合、番号 42 のものが実行中になっているのがわかります。これはまさに再開された状態です。実は、私はこれに対して質問しました。「ロンドンは今日晴れていますか？」という天候スキルに関する問いかけです。少しやりすぎたかもしれませんね。単に「晴れていません」と教えてほしかったのですが、モデルは私のためにスキルを作成してしまいました。かなりクールですね。右側の緑色のインジケーターが実行中になっているのが確認できます。その後、私はそれを終了しました。すると、すぐに消えました。

もう一つ試してみましょう。同じものを再度起動します。再開される様子を確認してください。では、41 番に行きましょう。42 番はスリープ状態になりました。41 番が稼働しています。さて、QCon とは何でしょうか？このインスタンスには API キーがありません。別のものを試してみましょう。「イギリスの料理で一番美味しいものは何ですか？」と聞いてみます。フィッシュ・アンド・チップスか、インド料理か？皆さんはどう思いますか？

まずはフィッシュアンドチップス。素晴らしいですね、本当にクールです。その後、ご覧いただいた通り、システムは復元されます。

次に私が行うのは、これらすべてを一度に起動する試みです。すべての対象を順次処理する小さなスクリプトを用意しました。このスクリプトは簡易的なクエリを実行し、対象を起動して処理が完了すると即座にシャットダウンします。その結果、蛇のような動き（スネーク効果）が発生します。これがスケールする様子です。

デモの最後の部分では、箱の中身をお見せしたいと考えています。ここには 1024132 のゼロから起動した仮想マシンが稼働しています。これらは一連の nginx インスタンスを実行中です。例えばインスタンス番号 939933 は「QCon Rocks」と応答しています。

では、すべてをまとめて確認しましょう。「111111」と入力しますね（数字は合っているはずです）。ダッシュを入力します。

はい、これで確認できました。これが 100 万番目のインスタンスです。nginx を実行し、「QCon Rocks」と応答しています。

Kubernetes

Kubernetes は確かに重厚で、ミリ秒単位での動作には向いていません。しかし、その有用性は疑いようがありません。高可用性（HA）や自己修復機能、スケーラビリティなど、多くの人が Kubernetes を採用する理由がそこにあるのです。Helm チャートを投入するだけでインフラが構築できるほど手軽さも魅力です。

では、Kubernetes の素晴らしい特性や誰もが使い方を理解しているという利点を保ちつつ、ミリ秒単位のセマンティクスも維持する方法はないのでしょうか？

私たちが行ったのは、仮想 Kubelet を構築することでした。これは既存のクラスターにノードとして追加するだけで機能します。Kubernetes に対して「ここで Pod をスケジューリングしてください」と伝えると、Kubernetes はその要求を受け入れ、「この Pod をスケジューリングして」と指示します。しかし、私たちは実際にコンテナを起動するのではなく、背後で Firecracker を使用しているため、マイクロ VM をスケジューリングします。

Kubernetes 側は「Pod がスケジューリングされた」と判断し、満足します。次に、「実行中ですか？」と Kubernetes が問いかけてきたら、私たちは常に「はい、常に実行中です」と答えます。実際には内部では上下に切り替わっている状態ですが、数ミリ秒以内に応答できるのであれば、システムが実際にスリープしているかどうかを誰かが気にすることはありません。

これが、高速であるかのように見せかけつつ、Kubernetes の恩恵もすべて享受する方法です。

要点

クラウドインフラにおける最終的な結論は、従来「速度」「スケーラビリティ」「強力な分離」のいずれか2つしか選べない状況でした。しかし、エンジニアリングを慎重に行えば、これら3 つを同時に実現できるという考え方が生まれました。

質疑応答

参加者 1: マルチテナント環境で、実際のハードウェアが即座に起動可能なリソース数を超える場合、どのように対応しますか？

Felipe Huici: もちろん、すべてには限界があります。サーバーが 48 コアの場合、その 48 コアが 100% で稼働している状態では、リクエストをキューイングする以外に打つ手はありません。重要なのは、常にピーク時の負荷に合わせてシステムを設計するのではなく、最大同時アクティブユーザー数に基づいてシステム規模を決定できる点です。

参加者 2: AI エージェントをサンドボックスで実行する場合、ルートアクセスを取得されないよう分離性を確保したいと考えています。このアプローチはその要件を満たすものと思われますが、マイクロ VM からプライベートコードや認証情報が漏洩するのを防ぐ方法はありますか？また、ネットワークの監視や制限は可能でしょうか？

フェリペ・ウイシ氏：まず、悪意のあるエージェントが Linux カーネルとユーザー空間の境界を突破した場合、ルートアクセスを取得する可能性があります。ただし、取得できるのは自分自身のカーネルへのアクセスのみで、他の誰かのカーネルにはアクセスできません。これが第一のレベルです。

第二のレベルとして、非常に有用な機密情報をエージェントに与えてはいけません。クレジットカード情報を渡すようなことは避けるべきです。実際にそのような行為を行っている人々がいると聞いて驚きました。この話題を最初に読んだときは「これは冗談なのか？」と思いましたし、今でも「本気で行われているのか」と信じられない思いですが、Anthropic のキーをエージェントに与えてはいけません。

現在のベストプラクティスは急速に変化しており、毎月のように更新されています。機密情報はエージェントの外部、おそらくプロキシが配置されたホスト上に保持すべきです。このプロキシはリクエストが入ってくる際に認証情報を注入し、ファイアウォールルールによってリクエストが妥当かどうかを判断します。ただし、エージェントはこのプロキシにはアクセスできません。

参加者 3 氏：Kubernetes では KubeVirt という技術についてよく耳にしますが、これは VM を利用するための試みでした。あなたが実施したアプローチでは、Pod のセマンティクスに基づいて動作し、特別な設定は行っていないと理解しています。

フェリペ・ウイシ: はい、ほぼその通りです。正確には、Kubelet を用いて Kubernetes の Pod スケジューリング API に準拠しました。過去に KubeVirt で多くの作業を行いましたが、速度が遅いことが判明しました。そこで各部の計測を開始し、遅延の原因を特定するとともに、どのコードを修正すべきか関係者と議論しましたが、すぐに複雑化してしまいました。

参加者 3: CNI（Container Network Interface）部分にもアクセスする必要がありましたか？

フェリペ・ウイシ: 今回は不要でしたが、一部の顧客は CNI を必要とする場合があります。その際は、サイド CNI をプラグインとして接続することも可能です。製品の詳細については深入りしたくありませんでした。

参加者 4: グラフの一つにネットブートがありましたが、非常に早い段階でピークが見られました。その理由は何でしょうか？

フェリペ・ウイシ: 正確な理由は分かりません。このグラフを作成したのは私の優秀なフィールドエンジニアの一人だからです。考えられるのは、バッチサイズを大きく設定したことです。つまり、1 ミリ秒あたり 100 台ではなく、200 台や 500 台の VM を同時に起動させたことでスパイクが発生したのでしょう。通常はそんなことが起こります。

参加者 4: 他のグラフと同じく、フラットなラインになるとお考えでしたか？

フェリペ・ウイシ: 100 万台をロードするには時間がかかるため、デモが迫っていたこともあり、「とにかく最速で読み込んでほしい」と指示しました。彼は全力で処理を進めていました。1 秒ごとに 1 台ずつ起動するのではなく、バッチ処理で一気に進めたのです。

参加者 5: スナップショットの復元はどの程度透明性（トランスペアレンシー）があるのでしょうか？アプリケーション側で、スリープから復帰する処理をカスタマイズする必要はあるのでしょうか？そこには何か障壁がありますか？

フェリペ・ウイキ： いいえ、全く透明です。最近では週末のうちに Firecracker でコードを書き上げることも可能です。ぜひ今週末は Firecracker を使った楽しいプロジェクトに挑戦してみてください。REST API 経由で操作できるのです。実際、Firecracker を使って REST API を構築すれば、自分もインフラ企業になった気分になれます。問題はそこから先です。スケールして本番環境に移行し、複雑な課題に直面したときが本当の難所になります。

原理的には、REST API でスナップショットを取得し、別の REST API でそのスナップショットから復元するだけで済みます。これは透明な仕組みです。Firecracker 側は仮想マシン（VM）の中身を知りませんし、気にもしません。

参加者 5: スナップショットのメモリをディスクに書き出す場合、頻繁にスワップすると帯域幅の問題が発生しませんか？

フェリペ・ウイキ： はい、それが問題です。だからこそ、「週末に Firecracker をいじってみよう」という軽い気持ちでやると失敗します。先ほど「週末のプロジェクトはおすすめしない」と言ったのはそのためです。

そこで登場するのが差分スナップショットや圧縮スナップショットです。私たちは NVMe から SSD までをまたぐマルチティアのスナップティングシステムを構築し、さまざまな工夫を施しました。例えば、メモリ解放領域がある場合はそこをスナップショットに含めないようにする重複排除（デデュプリケーション）などです。

この規模と速度でスナップショットを実現するには、こうした多くの要素が絡み合っています。もちろん、複数の NVMe ドライブを用意しておくことも有効な対策の一つです。

参加者6：Firecrackerについて考えていました。私は主に、AWS Lambdaの背後にあるマイクロVMとして知っています。サーバーレス関数を実行することが、ハイパースケールクラウドではなく自社のマシン上でUnikraftを主に実行することと比較してどうなのか、あるいはそれ以外の根本的な違いは何なのか、お聞きしたいです。

フェリペ・ウイシ：自社クラウド上でも実行可能です。オンプレミスやその他の環境でも問題なく動作します。技術的な話に戻りましょう。はい、FirecrackerはAWS Lambdaから始まりましたが、これは汎用的な仮想マシンモニター（VMM）です。その特徴はLinux VMのみを起動できる点にあります。そのため、QEMUのようなツールでは削減できない多くのコードを削ぎ落とし、高速化を実現しました。それ以外のことについては、本質的には関数しか実行できないわけではありません。単にVMを起動し、停止し、どの程度実行するかを決めるだけです。これらはすべてLambdaプロダクトの設計やスケールに関する制限によるものであり、Firecracker自体の根本的な制約ではありません。週末の個人プロジェクトでFirecrackerを使用する場合でも、「30秒間実行したので停止します」というような制限が内在しているわけではありません。

参加者7：コア数よりも需要の方が多い場合、スケジューリングはどこで行われるのですか？

フェリペ・ウイシ氏: もちろん、48 コアのサーバーに 48 個以上の Ubuntu インスタンスを起動し、そこからさらに 100 件のリクエストが殺到したと想像してみてください。その場合、パフォーマンスの低下は避けられません。ブート時間も長くなります。多くの場合、許容できる性能低下の範囲を計算し、それを超えた分はキューイングする判断を下します。あるいは水平方向へのスケール（増強）を行うことも可能です。

また、AWS などのクラウド環境であれば、停止状態にある EC2 インスタンスを AMI に紐付けて待機させておくことができます。ピークがベースサーバーの容量を超え始めたら、約 15〜20 秒で起動し、数千台の VM を再度実行できるプラットフォームを追加できます。

参加者 7 氏: その点について補足します。VM 内でコンテナを運用し始めた初期段階では、VMware が「vSphere のスケジューラーは Linux カーネルのスケジューラーよりも効率的であり、VM 内でのコンテナ実行の方が密度が高く効率が良い」と主張していました。一方で、ベアメタル上でもコンテナを実行可能です。

このスケジューリングの仕組みにおいて、Linux カーネルのスケジューラーと vSphere のスケジューラーを比較した場合、どちらが上位に位置すると考えられるでしょうか？

フェリペ・ウイシ氏：結論から言うと、スケジューリングは Linux カーネルが行います。Firecracker はプロセスとして動作するためです。もちろん、Linux カーネルのスケジューリング機能は大幅に改善されており、Firecracker もその上で非常に良く動作します。そのため、多数のインスタンスをスケジュールして問題なく実行することが可能です。

ただし、仮想マシン内で何を実行するかは事前にわからないため、状況によっては難易度が高くなります。CPU を多く消費するワークロードもあれば、そうでないものもあります。そのため、パフォーマンスにはばらつきが生じます。その点でも、ベースとなるスケジューラーを可能な限り最適化することが不可欠です。

これが、Intel Cloud Hypervisor を採用しなかった理由の一つでもあります。私たちは一連のベンチマーク（合成テストを含む）を実施しましたが、その結果、同社のスケジューラーは性能が劣り、アイドル状態でも CPU 消費量が多いため、ジッター（振動・不安定さ）が発生することが判明しました。

さらに重要な点として、システムには負荷の上限があり、無限に処理し続けることは物理的に不可能です。

フェリペ・ウイシ：Granulate や同様の企業はそうしたアプローチを取っていますが、私たちが目指しているのは監視機能です。スケールゼロのダイナミクスにより 1 台のサーバーが膨大な容量を提供しますが、需要が落ち込んだ際には EC2 や他プロバイダー上で追加の VM を瞬時に起動し、15 秒以内に新たなホスト群を確保・利用できるようにします。その後、不要になればすぐに縮小できる仕組みです。これは「VM 内の VM」という異なるエンジニアリング領域であり、パフォーマンスが著しく低下しないよう、多くの工夫が必要でした。

参加者 8：Kata Containers はこの文脈でどう位置づけられるのでしょうか？

フェリペ・ウイシ：Kata Containers のコンセプトは、コンテナを実行するために特別に設計された仮想マシンディストリビューションを構築することです。つまり、「私のアプリケーションはコンテナランタイムとして動作する」という前提のもと、必要な機能だけを備えた最小限のディストリビューションを作るという考え方です。これは非常に優れたアイデアです。実際、ECS では同様のアプローチが取られており、VM 内にコンテナを格納しています。であれば、その効率性を最大化すべきでしょう。

私の個人的な見解としては、コンテナ自体は不要で、アプリケーションを直接仮想マシン上に配置する方が効率的だと考えています。Docker やコンテナ技術はローカル開発やテスト環境では非常に有用であり、日常的に活用していますが、本番環境においてはやや控えめな立場です。

詳細は トランスクリプト付きのプレゼンテーション をご覧ください。

録画日時：2026 年 9 月 9 日