WASM at the Edge

edge-computingwebassemblywasmruntime

WebAssembly を Edge Computing の実行モデルとして使うアプローチ。V8 Isolates と並ぶ Edge の二大実行モデルの一つ。AOT コンパイルによる 35-50μs の Cold Start、リニアメモリによる構造的なセキュリティ分離、言語非依存性が技術的優位。Fastly Compute が先駆者で、Akamai の Fermyon 買収 (2025) によりエンタープライズ採用が加速。

なぜ Edge で WASM か

優位性詳細
Cold Start35-50μs (AOT)。V8 Isolates (0.4ms) より桁違いに速い
バイナリサイズ2-5MB。Docker イメージ (100-200MB) の 50-75x 小さい
セキュリティリニアメモリによるサンドボックス。リクエスト間でメモリ非共有 → 情報漏洩を構造的に排除
言語非依存Rust, C/C++, Go, JS, Python。WASM にコンパイルできる任意の言語
予測可能な性能AOT コンパイル → JIT warmup / deoptimization なし。p99 レイテンシの分散が小さい

Solomon Hykes (Docker 共同創設者): “If WASM+WASI existed in 2008, we wouldn’t have needed to create Docker.” ただし2026年現在は「置換」ではなく「補完」。

V8 Isolates との比較

特性WASM (Wasmtime)V8 Isolates (Cloudflare)
Cold Start35-50μs0.4ms (p50)
隔離モデルリクエストごとに独立リニアメモリ共有 V8 内の Isolate
クロスリクエスト漏洩構造的に不可能理論的に可能 (共有ランタイム)
言語言語非依存JS/TS ネイティブ + WASM
JITなし (AOT)あり (段階的コンパイル)
開発体験Rust 中心。JS は二級JS/TS + npm 直接利用

Cloudflare は V8 内で WASM を実行する「ハイブリッド」を採用。Workers デプロイの 34% が WASM を含む (2023: 12%)。V8 を捨てるのではなく共存する方向。

主要プラットフォーム

Fastly Compute

WASM-native Edge の先駆者。Wasmtime ベース (元は独自の Lucet → Wasmtime に統合)。

項目値
ランタイムWasmtime (Bytecode Alliance)
Cold Start35-50μs (AOT プリコンパイル)
PoP90+
言語Rust, Go, JS (StarlingMonkey)
CPU 時間50ms/リクエスト
メモリ128MB/実行
パッケージ上限100MB/サービス

Cold Start が速い理由:

  1. AOT プリコンパイルで実行時コンパイルをクリティカルパスから除去
  2. Pooling Allocator でインスタンス化を高速化
  3. per-request isolation: リクエストごとに新しいサンドボックスを起動

Cloudflare Workers での WASM

V8 エンジン内の WASM 実行パスを使用。workerd (OSS ランタイム) が基盤。

Fermyon Spin (Akamai)

Component Model を全面採用した WASM FaaS。2025年に Akamai が買収。

その他

プラットフォーム特徴
Wasmer EdgeWASIX (WASI の POSIX 拡張) ベース。マイクロ秒起動
wasmCloudCNCF Incubating。NATS メッセージングバックボーン
WasmEdgeCNCF Sandbox。Edge AI 特化 (WASI-NN, TensorFlow Lite, llama.cpp)

WASI (WebAssembly System Interface)

WASM にシステムリソースへのアクセスを提供する標準インターフェース。Bytecode Alliance が主導。

Preview 1 vs Preview 2

特性Preview 1 (2019)Preview 2 / WASI 0.2 (2024)
API 設計フラットな POSIX-like 関数群Component Model ベースの「worlds」
ネットワーキングなしwasi-sockets (TCP/UDP), wasi-http
構成単位Core ModuleComponent
Rust ターゲットwasm32-wasip1wasm32-wasip2

Preview 1 の最大の問題: ネットワーキングの欠如。HTTP サーバすら構築できなかった。

Component Model

WASM モジュールを LEGO ブロックのように組み合わせ可能にする仕様。

WIT (WebAssembly Interface Types) がインターフェース定義言語:

package my:app;

world edge-handler {
  import wasi:http/types@0.2.0;
  export wasi:http/incoming-handler@0.2.0;
}

WASI Preview 3 (策定中)

フォーカス: async I/O。2026年中〜2027年にかけて策定予定。

ランタイム比較

ランタイムCold Start実行時間メモリ特徴
Wasmtime5.2ms10.4ms15MB標準準拠。Component Model リーダー。Fastly の基盤
Wasmer6.8ms12.1ms12MBWASIX 独自拡張。JIT/AOT
WasmEdge8.1ms15.3ms8MBEdge AI 特化。最小メモリ
Wazero4.5ms18.7ms-Pure Go。CGO 不要
Wasm32.1ms45.2ms-インタプリタ。最速起動

Rust/Almide → WASM → Edge パイプライン

Almide の自然なパス: *.almd → Almide コンパイラ → *.rs → cargo-component → *.wasm

ビルドとデプロイ

# Preview 2 / Component Model (推奨)
cargo install cargo-component
cargo component new my-edge-app
cargo component build --release

# サイズ最適化
wasm-opt -Oz target/wasm32-wasip2/release/app.wasm -o app.opt.wasm

# Fastly Compute へデプロイ
fastly compute build && fastly compute deploy

# Fermyon Spin (Akamai) へデプロイ
spin build && spin deploy

# SpinKube (Kubernetes) へデプロイ
spin registry push ghcr.io/org/app:latest
kubectl apply -f spinapp.yaml

バイナリサイズと DCE: WASM の明示的なインポート/エクスポート構造により DCE がネイティブバイナリより効果的。wasm-opt -Oz で典型的に 10-30% 削減。Edge の Cold Start はバイナリサイズに直結するため、DCE の質がそのままユーザー体験に影響する。

ユースケース

分野Workers での利用率詳細
データ変換28%JSON/XML 変換、データパイプライン
暗号処理22%JWT 検証、HMAC、暗号化/復号化
画像処理19%リサイズ、フォーマット変換、圧縮
ML 推論成長中WASI-NN (ONNX, TF Lite, llama.cpp)
プラグインシステム-サードパーティコードの安全な実行 (Figma, Shopify)
マルチテナント SaaS-高密度 (数千インスタンス/マシン) でテナント隔離

課題と制限

課題詳細
スレッド不在WASI にネイティブスレッディングなし。並列計算、DB、高スループット処理が制約。Preview 3 待ち
デバッグの未熟さスタックトレース不透明、IDE 統合限定的、成熟した APM なし。コンテナに10年遅れ
Rust 以外のツールチェーンRust は洗練されているが他言語は二級市民。Java は公式 WASM ターゲットなし (2026年初頭)
仕様チャーンWASI Preview 間の API 名・crate 名の変更。エンタープライズの躊躇を招く
JS 相互運用コストJS-WASM 境界越えのマーシャリングオーバーヘッド。小関数は純 JS より遅い
ステートフルの困難スレッド不在 + 永続化 API の未成熟

「三年間の almost ready」問題: Edge FaaS とプラグインサンドボックスでは成功。ステートフルサービスと汎用バックエンドには不向き。

市場動向 (2025-2026)

押さえどころ（カード化候補）

関連

Graph

Backlinks