Rust/WASM Edge Functions と Cloudflare および Vercel Edge の比較

V8 アイソレートは、同じ V8 エンジン内の軽量の JavaScript 実行コンテキストです。新しいシステム プロセスや新しいカーネルを開始する必要はありません。これは、Cloudflareが最初にWorkers向けに公開したメカニズムであり、VercelがEdge Runtimeに再利用しています。目的はどちらの側でも同じです。つまり、リクエストごとにコンテナまたは VM のコストを回避することです。

A WebAssembly module meets the same need through a different mechanism. The WASM bytecode runs in a bounded linear memory, defined by the specification itself. The guest module cannot address outside this area, regardless of the source language (Rust, C, Go…) that produced the binary. It is this model that Wasmtime applies in the wasm mode of Aurabase, detailed below. For startup measurements between the two mechanics, see our file on WebAssembly cold start benchmarks.

各 Aurabase 関数には、 "wasm" または "deno"に相当する runtime フィールドがあります。呼び出しエンジンはそれに応じて実行パスを選択します。

// ランタイムに応じたディスパッチ: WASM (wasmtime) または Deno (エッジランタイム経由の V8 分離)
let resp = if func.runtime == "wasm" {
    state.runtime.invoke(&wasm_bytes, &func.code_hash, req).await?
} else {
    // aura-edge-runtime へのプロキシ — V8 分離 (supabase/edge-runtime、MIT)
    proxy_to_edge_runtime(&state.config.edge_runtime_url, …).await?
};

サンドボックスは、3 つの Wasmtime メカニズムを組み合わせて利用しています。 CPU バジェットは「燃料」としてカウントされます。各 WASM 命令がそれを消費します。エポック増分で適用されるタイムアウト: 専用スレッドは、設定された遅延の後に Wasmtime クロックを増加させ、現在の実行を中断します。 StoreLimitsによって設定されたメモリ制限。 3 つのターミナルは、エンジンがインスタンス化されるときに構成されます。

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);

// StoreLimits によって制限されたメモリ、初期燃料 = max_fuel、
// timeout = timeout_secs 後のエポック増分 (専用スレッド)

コンパイルされたモジュールは code_hashによってキャッシュされます。デプロイされた同じバイナリは呼び出しごとに再コンパイルされません。ただし、各呼び出しでは、新しい Store とインスタンスがインスタンス化されます。ある呼び出しから次の呼び出しに状態が漏洩することはありません。ゲスト モジュールに公開される表面積は意図的に最小限に抑えられており、合計 5 つのホスト関数: aura.log、 aura.get_input、 aura.set_output、 aura.get_env と、AssemblyScript 互換性のためのスタブ env.abort です。現時点では、発信ネットワーク呼び出しを公開するホスト機能はありません。

デプロイメント側では、CLI は送信前にクレートをローカルでコンパイルします。 aura functions new はクレート cdylibをスキャフォールドし、 aura functions deploy はそれをコンパイルして送信します。

# スキャフォールディング: aurabase/functions/<name>/ を作成します (Cargo.toml crate-type = cdylib)
aura functions new my-fn

# カーゴビルド --target wasm32-unknown-unknown --release、アップロード
# POST /v1/functions/:project_id { ランタイム: "wasm"、コード: <base64 の wasm> }
aura functions deploy my-fn

Cloudflare Workers は、Cloudflare のグローバル ネットワーク全体に分散された V8 分離で JavaScript と TypeScript をネイティブに実行します。 WebAssembly はプラットフォームの初期から第一級市民であり、.wasm モジュールは他のモジュールと同様にワーカーに直接インポートできます。

Rust で完全に Worker を記述する場合、最もよく使用されるルートは、コードを wasm32-unknown-unknown にコンパイルし、Workers ランタイムで実行するコミュニティ SDK workers-rsです。 Aurabase の wasm モードとの違いは、利用可能な表面積です。この SDK を介して Rust で作成されたワーカーは、完全なワーカー環境で実行されるため、fetch または他のプラットフォーム バインディングを呼び出すことができます。 Aurabase の wasm モードは、意図的に縮小されたホスト サーフェスから開始します (前のセクション)。

Vercel の Edge ランタイムは、完全な Node.js 環境ではなく、標準 Web API (fetch、 Request/Response、 crypto.subtle…) のサブセットを使用して、V8 分離でコードを実行します。そこには、ネイティブ ノード モジュールや任意のコンパイル ツールチェーンが入る余地はありません。

WebAssembly オブジェクトはこのサブセットの一部です。.wasm バイナリをロードし、JavaScript または TypeScript 関数から手動でインスタンス化することを妨げるものはありません。しかし、私たちの知る限り、Cloudflare 側の workers-rs や Aurabase 側の aura functions deploy とは異なり、Vercel は Rust で Edge 関数を直接記述するための公式 SDK や CLI を公開していません。このパスは引き続き可能ですが、専用ツールを使用せずに完全に手動で行われます。

V8 アイソレートは、同じエンジン プロセス内の専用ヒープと独自のコンテキストによって実行されるコードを分離します。これは、Cloudflare と Vercel で 1 秒あたり数百万リクエストの規模で実績のあるメカニズムですが、単一の JavaScript エンジン内のソフトウェア分離メカニズムのままです。

WASM モデルの分離方法は異なります。各インスタンスは独自のリニア メモリ、つまりバイナリ フォーマット自体の構築により外部にアクセスできない連続バッファを、それを実行するエンジンから独立して取得します。 Aurabase ランタイムでは、ゲストモジュール (aura.log、 aura.get_env…) によって提供されるポインタを操作する各ホスト関数は、メモリアクセスの前に境界を明示的に再検証します。これは、悪意のあるモジュールまたはバグのあるモジュールに対する追加の多層防御です。

Aurabase ランタイムの仕様。 Cloudflare および Vercel の列は、各プラットフォームの文書化されたパブリック アーキテクチャから説明されています (V8、WebAssembly をビルド ターゲットとして分離します)。

ネットワーク呼び出しを行わない純粋な計算: スキーマ検証、データ変換、スコアリング、軽量イメージ生成。 Aurabase の wasm モードは、厳密なメモリ サンドボックス、明示的な CPU バジェットを備え、外部サービスに依存せずに直接適しています。

サードパーティ API (支払い、電子メール、送信 Webhook) を呼び出す関数。 Aurabase の deno モードは、従来の Cloudflare Worker または Vercel Edge Function がネイティブに fetch に依存しているのと同じように、現在でもデフォルトの選択肢のままです。

チームはすでに Cloudflare エコシステム (KV、Durable Objects、R2) に投資しています。 Workers に留まるのは理にかなっています。 workers-rs を使用すると、プラットフォームを変更せずに Rust を段階的に導入できます。

Need a native Rust runtime managed end-to-end, with a dedicated CLI and the same language as the rest of the backend. This is the angle that documents in our Wasmtime vs Wasmer comparison, on the choice of the WebAssembly engine itself.