This article brings together what identifiable third-party sources publish about WebAssembly's cold start compared to containers: a paper presented at USENIX NSDI, official documentation from Fastly, WasmEdge and Wasmer, and an academic research project on serverless isolation. No Aurabase figures are included. Our edge functions run well on Wasmtime, verified in the repository, but no cold start benchmark specific to our infrastructure has been published to date, a distinction detailed below. For the general benchmarking method applied elsewhere on this blog, see our pillar article onbenchmarking methodology.
必需品
- AWS Firecracker の論文 (Agache et al.、USENIX NSDI 2020) では、microVM の起動時間は 125 ミリ秒未満、メモリ オーバーヘッドは 5 MiB 未満であることが文書化されており、この記事で最も正確に定量化された参考資料です。
- Fastly は、2019 年に AOT Lucet ランタイム (その後、最適化が Wasmtime にマージされました) の WASM インスタンス化時間が 1 ミリ秒未満であることを文書化しました。これはサプライヤーによって公開された数値であり、ここで参照したソースで独自に再現されたことはありません。
- CNCF ガバナンスの下にあるプロジェクトである WasmEdge は、公式ドキュメントの中で、この記事で引用されている独立した対策なしでも、同等の Docker コンテナよりも起動とメモリのフットプリントが大幅に低いと主張しています。
- Wasmtime、Wasmer、および WasmEdge は同じ方法ではコンパイルできません (Cranelift、Singlepass/Cranelift/LLVM の選択、独自の AOT コンパイラー)。このバックエンドの選択により、ランタイムそのものだけでなく、公開されている数値間のギャップの大部分が説明されます。
- Aurabase は、実稼働環境でエッジ機能に Wasmtime を使用しており、
aura-functions/Cargo.tomlで検証されていますが、現在までのところ、独自のインフラストラクチャで測定されたコールドスタートの数値は公開されていません。
以下に引用されているサードパーティの情報源は、タイトル、著者または出版社、発行日によって識別できます。この調査は、執筆時点でのページのライブ クエリではなく、WebAssembly およびサーバーレス エコシステムで認知され広く文書化されている出版物に依存しています。正確な数値を十分な確実性をもって確認できない場合、この記事では正確な値ではなく桁を使用し、これを明示的に述べています。
WASM コールド スタートがサーバーレスの議論で大きなスペースを占める理由
コールド スタートとは、アプリケーション コードを実行する前に実行環境を初期化する必要がある場合に、リクエストによって発生する追加の遅延を指します。従来のエッジ機能やサーバーレス機能では、これは決して限界的なケースではありません。2 つのトラフィック ピークの間にインスタンスがゼロになるプラットフォームや、地理的に分散した数十のエッジ ノードに実行を分散するプラットフォームでは、最初のデプロイ時だけでなく、永続的にこのコストを支払うことになります。
「もし WASM+WASI が 2008 年に存在していれば、Docker を作成する必要はなかったでしょう。それだけ重要です。サーバー上の WebAssembly はコンピューティングの未来です。」 これは、評価された実践者の意見であり、測定ではありません。この主題がなぜ魅了されるのかを説明しています。ソースの図を置き換えるものではありません。
Aurabase は、エッジ関数用に 2 つのパスを提供します。Studio エディターは、Supabase 移行ガイドに記載されているように、Deno ランタイムでコードを実行します。もう 1 つは、Rust で記述され、Wasmtime 上の WASM にコンパイルされる関数の別のパスを目的とした aura functions deployCLI です。この記事では、まだ存在しないコールド スタートの図を示すことなく、この 2 番目のパスに光を当てます。
WASM モジュールが構造的にコンテナよりも速く起動する理由
この違いは、絶対的なランタイムの高速化によるものではなく、クエリとアプリケーション コードの間のステップのスタックの短縮によるものです。
コンテナーを起動すると、ホスト カーネルが動員されます。つまり、新しいプロセスの作成、プロセスを分離する cgroup と名前空間のセットアップ、イメージのレイヤーのマウント、次に内部のアプリケーション ランタイムの起動が行われます (たとえば、Node.js とその V8 エンジン自体には初期化コストがかかります)。各ステップでは、システム コールが追加され、ローカルで表示されないイメージについては、開始前にネットワーク ダウンロードが追加されます。
WebAssembly モジュールは、オペレーティング システム レベルではなく、仮想マシン言語レベルで分離されます。モジュールのインスタンス化とは、ホスト ランタイムのすでに開始されているプロセス内で、リニア メモリを割り当て、インポートをバインドし、エントリ ポイントにジャンプすることを意味します。新しいプロセス、イメージ レイヤー、デフォルトのファイル システム マウントはありません。
コンパイル モードを選択すると、変数が追加されます。 Wasmtime は、モジュールのロード時に Cranelift バックエンドを介して JIT にコンパイルします。または、 wasmtime compileを使用して事前にプリコンパイルすることもできます。これにより、すでにネイティブ マシン コードに変換された .cwasm ファイルが生成されます。早期コンパイル (AOT) は、リクエストのクリティカル パスからコンパイル ステップを削除します。これはまさに、コールド スタートに敏感なエッジ アーキテクチャがアクティブ化する必要があるレバーです。
これは開発ではなく本番環境の依存関係です。これにより、Wasmtime が実際に Aurabase エッジ機能の CLI パスで実行されることが確認されます。ただし、レイテンシの数値は確認されておらず、日付のベンチマークが公開されていない限り、これは真実のままです。
コンテナーと microVM: 最も正確に定量化されたリファレンス
この分野で最も有力な情報源は、マーケティング ブログ投稿ではなく、業界研究論文です。 Firecracker は、AWS によって開発され、特に Lambda と Fargate で使用される軽量の microVM テクノロジーであり、USENIX NSDI 2020 カンファレンスで Agache らによって発表されました。記事「Firecracker: サーバーレス アプリケーションのための軽量仮想化」。
このペーパーでは、同じ物理マシン上で数千の microVM を実行できる機能を備えた、起動時間が 125 ミリ秒未満、microVM あたりのメモリ オーバーヘッドが 5 MiB 未満であることが文書化されています。これは、査読済みの学術出版物を出典とした古い図 (2020 年) であり、それ以来、サーバーレス分離に関する文献で広く引用されています。
標準の Docker コンテナーは通常、イメージのサイズ、ダウンロードの必要性、組み込みアプリケーション ランタイムの起動時間に応じて、数百ミリ秒から数秒ほど長くなります。 Firecracker とは異なり、ここでは普遍的に引用される単一の数値はありません。コンセンサスを得るには、結果は単一の値についてテストされた画像に大きく依存します。
WebAssembly: Fastly、WasmEdge、および学術研究文書とは
3 つの情報源、3 つの異なるステータス: 歴史的なサプライヤー、財団ガバナンス下のプロジェクト、および研究論文。
Fastly は、2019 年に独自のプリコンパイル WASM コンパイラーおよびランタイムである Lucet 上で Compute@Edge を開始しました。今回の発表で、同社は WASM のインスタンス化時間が 1 ミリ秒未満であることを文書化しました。これは、業界における WASM コールド スタートの議論に永続的な影響を与えた桁違いです。 2021 年、Fastly は Lucet の自律開発を中止し、その取り組みを Wasmtime に方向転換しました。Wasmtime の Cranelift コンパイル バックエンドはこれらの最適化の一部を継承しました。これが、Wasmtime が今日このタイプの負荷のリファレンスであり続ける理由の 1 つです。
WasmEdge は、CNCF ガバナンス下の WASM ランタイム (当初は SSVM、Second State がサポート) で、公式ドキュメントでは、エッジと IoT の負荷に対する明示的な位置付けにより、同等の Docker コンテナよりも起動とメモリのフットプリントが大幅に低いと主張しています。これはプロジェクトの発行者自体が発行した図であり、独立した監査ではなく、製品の主張として解釈してください。
学術研究の面では、Faasm (Shillaker & Pietzuch、USENIX ATC 2020、こちらもプレパブリケーションで利用可能) は、WebAssembly 分離 (Wasmtime ではなく WAVM 経由) に依存するステートフル サーバーレス プラットフォームを構築します。これはまさに、コンテナーや VM ごとに分離するよりもはるかに低いコストで関数をインスタンス化できるためです。この論文は特に Wasmtime に関するものではありませんが、前のセクションの構造的議論に対する独立した学術的検証を提供します。
Wasmtime 対 Wasmer 対 WasmEdge: 公表された数字が一致しない理由
これら 3 つのランタイムを名前だけで比較すると、実際の変数、つまり起動速度と実行パフォーマンスのバランスが根本的に変化する選択されたコンパイル バックエンドが見えなくなります。
| ワサムタイム | Cranelift (デフォルトでは JIT) + wasmtime コンパイルによる AOT | Bytecode Alliance · オープン ガバナンス、Fastly、Shopify、Aurabase で使用 |
|---|---|---|
| ワスマー | シングルパス、クレーンリフト、LLVM のいずれかを選択 | シングルパスはコンパイル時間を最小限に抑えます。 LLVM は実行パフォーマンスを最大化します |
| ワズムエッジ | プロジェクト固有の AOT コンパイラ | CNCF · エッジ/IoT およびクラウドネイティブに位置付け |
Wasmer の最速のコンパイル バックエンドである Singlepass が存在するのは、同社のチームがコールド スタートを定常状態の実行パフォーマンスの明確な軸として特定したためです。Singlepass でコンパイルされたモジュールは、LLVM でコンパイルされた同じモジュールよりも起動が速くなりますが、ピーク負荷時の実行が遅くなります。これは許容された妥協策であり、隠れた欠陥ではありません。
Wasmer は、Wasmtime との独自のパフォーマンス比較を公開しました。これにより、使用された方法論とテストされたシナリオの比較可能性について WASM コミュニティで議論が巻き起こりました。これは悪意を告発するものではなく、構造的な注意喚起です。ランタイム編集者は、自分が勝てるシナリオを公開することに既得権益を持っているため、単一の数字に基づいてアーキテクチャの選択を決定する前に、独立した検証がさらに役立ちます。
比較表: 各ソースに記載されている内容と記載されていない内容
| ファイアクラッカー (AWS) | 起動時間 125 ミリ秒未満、オーバーヘッド 5 MiB 未満 査読済み研究論文 | Agache 他、USENIX NSDI 2020 |
|---|---|---|
| ルセット → ワズムタイム(高速) | ミリ秒未満のインスタンス化 (2019) サプライヤーの図、ここでは再現されていません | Compute@Edge を高速で発表 |
| ワズムエッジ | DockerPublisher 製品の主張と比較して、起動時およびメモリ フットプリントが小さい | WasmEdge の公式ドキュメント (CNCF) |
| ファズム（検索） | WASM 分離は、コンテナーよりもインスタンス化が大幅に安価です。Wasmtime ではなく WAVM を使用します。 | シラカー & ピーツッチュ、USENIX ATC 2020 |
| 標準の Docker コンテナ | 数百ミリ秒から数秒 単一のコンセンサス番号なし | 広く文書化された動作 |
These five lines do not read as a single classification: they come from different methodologies, dates and runtime generations. For a more in-depth methodological critique of the reliability of this type of WASM benchmark, our article on the limits of WebAssembly benchmarks goes further than the present comparison, which remains focused on what each source concretely asserts.
このギャップがエッジ アーキテクチャの選択で実際に変わること
WASM のコールド スタートの利点は、すべての負荷に均等に影響を与えるのではなく、最初のリクエストの遅延の影響を最も受けやすい負荷に最も大きく影響します。
特に、非常に不規則なエッジ トラフィック (バーストとその後の沈黙)、複数のリクエスト間で共有されるコンテナーごとではなくリクエストごとの分離、およびホット プールを永続的に維持するのではなく 2 つのピーク間で実際にインスタンスがゼロになるインフラストラクチャに重点が置かれます。安定した予測可能な負荷では、とにかくインスタンスがホットなままであるため、コールド スタートのギャップは構造的にそれほど重要ではありません。
WebAssembly は、コールド スタートとは異なる制約も維持します。つまり、ファイル システムまたはネットワークへのアクセスは WASI を経由し、インターフェイスはランタイムとそのバージョンに応じて進化し続けており、高速に起動するようにコンパイルされたモジュール (たとえば、Wasmer 側のシングルパス) は、高負荷時に確立されると必ずしも最速になるとは限りません。コールド スタートとピーク実行パフォーマンスは 2 つの異なる軸のままであり、同じコンパイル プロファイルで同時に最適化されることはほとんどありません。
この基準に基づいてエッジ アーキテクチャの選択を評価するために、サプライヤーに尋ねるべき 3 つの具体的な質問が Aurabase に含まれています。それは、どの正確なランタイムが使用されているか、どのコンパイル バックエンド (JIT または AOT) であるか、および高度なコールド スタートの数値が独立したサードパーティによって測定されているか、またはランタイム パブリッシャー自体によってのみ測定されているかどうかです。
よくある質問
For the database layer of this same problem, see our article on the serverless Postgres cold start.