Wasmtime と Wasmer (本番環境 Edge Functions) の比較

WebAssembly は長い間、ブラウザーのランタイム形式を指定してきました。数年間、サーバー側またはエッジでサンドボックス コードを実行するためにも使用されてきました。バイトコードは一度コンパイルされ、任意のホスト マシンに移植可能で、コンテナや完全な仮想マシンなしでデフォルトで分離されます。 Wasmtime と Wasmer はこの拡張機能をブラウザの外に持ち出し、どちらも Rust で書かれており、同じ .wasmファイルを実行できます。

Wasmtime は、Cranelift コンパイラを含む WebAssembly サーバー エコシステムのいくつかのコンポーネントを管理する組織である Bytecode Alliance がホストするプロジェクトです。 Wasmer は、ランタイムをオープンソースとして公開し、その周りの補完的なサービス (エッジ展開、ツール) をマーケティングしている会社、Wasmer Inc. によって開発されています。 2 つの異なるガバナンス モデル。どちらかが生成したコードの品質については判断がありません。

この記事の残りの部分では、4 つの検証可能なフィールド、ライセンスとガバナンス、利用可能なコンパイラ、WASI 標準とコンポーネント モデル、セキュリティ モデルを比較し、サポートするコードを使用して、Aurabase の Rust コア が Edge Functions エンジンで Wasmtime を実行する理由を説明します。

Wasmtime は、コンパイラ エコシステムで一般的な寛容なライセンスである LLVM 例外を含む Apache-2.0 ライセンスに基づいてリリースされます。そのガバナンスは Bytecode Alliance モデルに従っています。いくつかの組織がプロジェクトに貢献しており、単独でプロジェクトを所有している組織はありません。

Wasmer は MIT ライセンスに基づいて公開されており、紙面ではさらに寛容ですが、その技術的方向性は依然として単一の出版社、Wasmer Inc. に集中しています。これ自体は問題ではありません。成功したオープンソース プロジェクトの多くがこのモデルに従っています。組織が複数のエンティティにわたる分散ガバナンスを重視する場合、これは単に異なるリスク プロファイルになります。

Wasmtime は、同じく Bytecode Alliance のコード ジェネレーターである Cranelift を介して本番環境でコンパイルされます。このクレートには、起動に敏感な場合に Cranelift と比較してコンパイル時間を短縮するように設計された追加のコンパイラー Winch も記載されています。オーラ関数 の Cargo.toml は、cranelift 機能のみをアクティブにします。このコンパイラーのみが、実稼働環境にロードされた各 WASM モジュールを処理します。

Wasmer は、3 つの交換可能なバックエンドという逆の道を歩みます。シングルパスは、最適化されていないマシンコードを犠牲にして、単一パスでほぼ瞬時にコンパイルします。クレーンリフトはバランスの取れた妥協点を提供します。 LLVM は、3 つの中で最も長いコンパイル時間で、可能な限り最高の実行スループットを目指しています。単一のランタイム、構成中に選択された 3 つの妥協プロファイル。

WASI (WebAssembly System Interface) は、ブラウザに依存せずに、WASM モジュールからファイル、クロック、ネットワークへのアクセスを標準化します。その最新バージョンである WASI Preview 2 は、コンポーネント モデルに基づいています。これは、各ランタイムに固有のバイナリ形式ではなく、共有型インターフェイスを使用して、さまざまな言語で書かれたモジュールを構成するためのメカニズムです。 Wasmtime と Wasmer は両方とも、それぞれのペースでこの標準の実装に取り​​組んでいます。

Wasmer はさらに、スレッドやより包括的なネットワーク ソケットなど、公式の WASI 標準ではまだカバーされていない POSIX プリミティブをカバーすることを目的とした拡張機能である WASIX についても文書化しています。これは WebAssembly ワーキング グループによってサポートされている標準ではなく、Wasmer エコシステムに固有の拡張機能です。

どちらのランタイムも、明示的にインポートされた関数以外のホスト システムに直接アクセスすることなく、各モジュールを独自のリニア メモリに分離します。これは WebAssembly セキュリティ モデルの基礎であり、両方のプロジェクトに共通です。

Wasmtime はネイティブ実行フッテージ API fuelも公開しています。各命令は事前に固定されたバジェットを消費し、このバジェットが使い果たされると実行は適切に停止します。 2 番目の API である epoch割り込みを使用すると、待機中にエンジンをブロックせずにタイムアウトを課すことができます。 Wasmer は、計測とインスタンスごとのメモリ制限に関する彼自身の仕組みを文書化しています。この記事では、サードパーティのリポジトリでそれらを検証していないため、図ごとに説明しません。

これはまさに Aurabase の aura-functions サービスが可能にするものであり、実際のソースコードを使用して次のセクションで詳しく説明します。

aura-functions サービスは、非アクティブ化コメントや開発依存関係の構成なしで、wasmtime を運用依存関係として宣言します。リポジトリ内のファイルは、Cargo.toml ファイルも .rsファイルも、Wasmer について言及していません。

# WASM ランタイム
wasmtime = { version = "43", features = ["async", "cranelift"] }

初期化コードは明示的に燃料をアクティブ化し、エポックごとに割り込みを行ってから、 StoreLimitsの呼び出しによってメモリを制限します。

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// 呼び出しにより:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

3 つの制限はすべて環境変数ごとに構成可能で、デフォルト値は config/mod.rsでチェックされます: WASM_MAX_MEMORY_MB は 64、WASM_TIMEOUT_SECS は 10、WASM_MAX_FUEL は 10 億単位です。タイムアウトはバックグラウンドでトリガーされます。tokio::spawn は、待機中に現在の実行をブロックすることなく、設定された期間待機してからエンジン エポックを増分します。

ゲスト モジュールに公開される ABI は、意図的に最小限のままです。4 つのホスト関数、 aura.log、 aura.get_input、 aura.set_output および aura.get_envは、 linker.func_wrap経由で登録されます。これはコンポーネント モデルでも WASI プレビュー 2 でもありません。これは社内契約であり、より限定的で、単一使用向けに設計されており、HTTP エッジ関数を実行し、その JSON 応答を回復します。

この wasm モードは、グローバルな切り替えではなく、機能ごとの選択です。 Aurabase アーキテクチャの概要 では、別のサービスで JavaScript/TypeScript を実行するもう 1 つのパス、デフォルトの denoモードについて詳しく説明します。両方が同じ aura-functionsサービス内に共存します。

出典: Aurabase リポジトリの Cargo.toml および wasm/mod.rs、2026 年 8 月 24 日に直接検証。一般的な Wasmtime および Wasmer の特性は各プロジェクトの公開ドキュメントから取得。この表にはサードパーティのベンチマーク数値は再掲載されていません。

既存の依存関係を持たずに、新しい Edge ランタイムを開始します。 Wasmtime はマルチベンダー基盤によってサポートされているため、プロジェクトの将来を単一の発行者に依存するリスクが軽減されます。

コールド スタートが頻繁に発生し、持続時間が短くなります。 Wasmer の Singlepass バックエンドは、あまり最適化されていないマシン コードを犠牲にして、このニーズに直接応答し、ほぼ瞬時にコンパイルします。

現在の標準 WASI を超える POSIX プリミティブが必要です。 Wasmer 拡張機能である WASIX は、WASI Preview 2 だけではまだカバーされていないスレッドと拡張ソケットをカバーします。

サードパーティのミドルウェアを使用せずに、ネイティブの映像とタイムアウト API が必要です。 Wasmtime は、fuel および epoch をクレート内で直接公開します。これは、まさに aura-functions が Aurabase で有効にするものです。