copied!

ブラウザの外で WebAssembly を動かして見えたコンテナとの違いと実用上の課題

Sreake事業部

2026.7.28

copied!

はじめに

WebAssembly（以下、Wasm）は、ブラウザ上で高い実行性能を得るために生まれた技術です。
近年は、軽量性や可搬性、サンドボックスによる分離といった特徴から、ブラウザの外でも活用が広がっています。なかでも、Linux コンテナを補完する新たな実行基盤として注目されています。

本記事では、Wasm を使った Web アプリケーションとバッチ処理を実装し、Linux コンテナとの実行時間の違いや、Wasm 化する際の言語・ライブラリ依存について検証します。

自己紹介

Sreake 事業部で期限付きインターンをしている鳥海（とりうみ）です。

なぜ Wasm をブラウザの外で使うのか

Wasmとは

Wasm は、スタックマシンを対象としたバイナリ命令形式です。C/C++ や Rust などのコンパイルターゲットとして利用でき、ネイティブバイナリに近いパフォーマンスでセキュアに実行できるよう設計されています。

コンテナとの差別化

コンテナはプロセス毎にユーザランドや名前空間を分離して行う仮想化技術です。
一般的なコンテナイメージには、アプリケーション本体に加えて OS のユーザーランドや各種ライブラリが含まれます。そのため、ベースイメージや依存パッケージの脆弱性にも気をつける必要があります。
一方、Wasm は特定の OS や CPU アーキテクチャに強く依存しない可搬性を持ち、ホストが許可した機能だけにアクセスするサンドボックス内で動作します。こうした特徴から、「コンテナの次」としてブラウザの外で使うWasmが期待されています。

どうやって Wasm をブラウザの外で使うのか

Wasm をブラウザ上で実行する場合、利用できる機能はブラウザが提供する API に制限されます。そのため、ホスト環境であるブラウザのセキュリティモデルに従い、サンドボックス化された環境で動作します。

一方、Wasm をブラウザの外で動かすには、汎用 OS や組み込み OS など、さまざまなプラットフォーム上でシステム機能を扱うための仕組みが必要です。そこで、ファイルシステムや標準入出力などへアクセスするための標準インターフェースとして、WASI（WebAssembly System Interface）が策定されています。Wasmtime などのランタイムは WASI を実装し、Wasm プログラムとホスト環境の橋渡しをします。

2026 年 6 月 11 日に WASI 0.3（Preview 3）がリリースされました。WASI 0.3 では Component Model にネイティブな非同期処理が加わり、async func、stream<T>、future<T> などを利用できるようになりました（WASI P3 の概要）。

WASI 0.1（Preview 1）では、POSIX の影響を受けた API を通じて、複数のランタイムで動作する Wasm モジュールを作成できました。一方、Core Wasm の関数境界で直接扱える型は数値型に限られ、異なる言語で作られたモジュール同士の連携には追加の取り決めが必要でした。

WASI 0.2（Preview 2）は Component Model を基盤としています。Component Model では、WIT（WebAssembly Interface Type）というインターフェース記述言語を使い、型や関数シグネチャを定義できます。これにより、異なる言語で作られたコンポーネント同士を、共通のインターフェースを介して連携させやすくなりました。

環境

検証は、Amazon EC2 上の Amazon Linux 2023 環境で行いました。CPU アーキテクチャは aarch64 で、2 vCPU の ARM インスタンスを使用しています。

項目	内容
実行環境	Amazon EC2
リージョン	ap-northeast-1
OS	Amazon Linux 2023.11.20260511
カーネル	6.1.170-210.320.amzn2023.aarch64
アーキテクチャ	aarch64
rustc	rustc 1.95.0
cargo	cargo 1.95.0
python	Python 3.11.15
clang	clang version 22.1.0-wasi-sdk
wasmtime	wasmtime 44.0.1
docker	Docker version 25.0.14, build 0bab007

アプリケーションの開発

Wasm を用いたアプリケーション開発を通じて、一般的なアプリケーション構成との相性について考察を行いました。

Web アプリケーションの開発
Spin を利用し、Web、API、データベースからなる簡単な 3 層アプリケーションを構築しました。Spin は、Wasm コンポーネントを使ってイベント駆動型のアプリケーションを構築するためのフレームワークで、Rust や Go など複数の言語を利用できます。

まず、Web サーバーへアクセスできることを確認します。

$ curl http://127.0.0.1:3000/
<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Container Demo</title>
  <style>
    body { font-family: sans-serif; max-width: 600px; margin: 40px auto; padding: 0 20px; }
    button { padding: 8px 20px; cursor: pointer; }
    #result { margin-top: 20px; padding: 16px; background: #f4f4f4; border-radius: 8px; white-space: pre-wrap; }
  </style>
</head>
<body>
  <h1>🐳 Container Demo</h1>
  <p>Web → API → DB の3層構成テスト</p>

  <button onclick="fetchUsers()">ユーザー一覧を取得（GET /api/users）</button>
  <button onclick="fetchHealth()">ヘルスチェック（GET /api/health）</button>

  <div id="result">ここに結果が表示されます</div>

  <script>
    async function fetchUsers() {
      const res = await fetch('/api/users');
      const data = await res.json();
      document.getElementById('result').textContent = JSON.stringify(data, null, 2);
    }
    async function fetchHealth() {
      const res = await fetch('/api/health');
      const data = await res.json();
      document.getElementById('result').textContent = JSON.stringify(data, null, 2);
    }
  </script>
</body>
</html>

続いて、ユーザーの登録と取得を行い、API サーバーからデータベースまでの経路を確認します。

$ curl -X POST http://localhost:3000/api/users -H "Content-Type: application/json" -d '{"name": "charlie", "email": "charlie@charlie.com"}'
{"id":3,"name":"charlie","email":"charlie@charlie.com"}

$ curl -s http://127.0.0.1:3000/api/users | jq
[
  {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com"
  },
  {
    "id": 2,
    "name": "Bob",
    "email": "bob@sample"
  },
  {
    "id": 3,
    "name": "charlie",
    "email": "charlie@charlie.com"
  }
]

Web サーバーやデータベースには成熟したソフトウェアが存在するため、特別な要件がない限り、Wasm で一から実装するよりも既存のソフトウェアをコンテナ上で動かすほうが現実的だと思いました。一方、軽量性や起動時間を重視する API サーバーでは、Wasm が選択肢になり得ると感じました。

ただし、フレームワーク固有の実装や構成に依存すると、Wasmの利点である可搬性が損なわれてしまう可能性があります。

バッチ処理

検証 1：JSON ファイルの生成

100 万〜1,000 万件のレコードを持つ JSON ファイルを生成するプログラムを作成しました。(一部省略)

use std::fs;
use std::time::{Duration, Instant};

fn main() {
    let count: u32 = 1000000;
    let output_file = "output.json";

    let start_gen = Instant::now();
    let json_array = generate_json(count);
    let elapsed_gen = start_gen.elapsed();

    let start_io = Instant::now();
    fs::write(output_file, &json_array)
        .unwrap_or_else(|e| panic!("Failed to write {}: {}", output_file, e));
    let elapsed_io = start_io.elapsed();

    print_result(count, json_array.len(), elapsed_gen, elapsed_io, output_file);
}

fn generate_json(count: u32) -> String {
    let records: Vec<String> = (0..count).map(build_record).collect();
    format!("[\n{}\n]", records.join(",\n"))
}

fn build_record(i: u32) -> String {
    ...
}

fn print_result(
    count: u32,
    size: usize,
    elapsed_gen: Duration,
    elapsed_io: Duration,
    output_file: &str,
) {
    let total = elapsed_gen + elapsed_io;
    let io_pct = elapsed_io.as_secs_f64() / total.as_secs_f64() * 100.0;
    let gen_pct = 100.0 - io_pct;

    println!("===== Batch Result =====");
    ...
}

コンパイルターゲットをネイティブと wasm32-wasip2 に切り替え、それぞれリリースビルドして実行しました。ネイティブ版は Docker コンテナ内で、Wasm 版は Wasmtime 上で動かしています。

$ time sudo docker run --rm -v $(pwd)/output:/data batch-gen
===== Batch Result =====
Target  : native (linux)
Records : 1000000
Size    : 204066670 bytes
------------------------
Gen     : 302.805373ms (85.4%)
I/O     : 51.679812ms (14.6%)
Total   : 354.485185ms
------------------------
Output  : output.json
        Command being timed: "gen"
        User time (seconds): 0.16
        System time (seconds): 0.22
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.38
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 767384
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 191519
        Voluntary context switches: 1
        Involuntary context switches: 12
        Swaps: 0
        File system inputs: 0
        File system outputs: 398568
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

real    0m1.526s
user    0m0.003s
sys     0m0.016s

$ /usr/bin/time -v wasmtime run --dir=. target/wasm32-wasip2/release/gen.wasm

===== Batch Result =====
Target  : wasm32-wasip2
Records : 1000000
Size    : 204066670 bytes
------------------------
Gen     : 560.627362ms (48.9%)
I/O     : 586.577637ms (51.1%)
Total   : 1.147204999s
------------------------
Output  : output.json
        Command being timed: "wasmtime run --dir=. target/wasm32-wasip2/release/gen.wasm"
        User time (seconds): 0.45
        System time (seconds): 0.25
        Percent of CPU this job got: 56%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.24
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 974156
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 240352
        Voluntary context switches: 673
        Involuntary context switches: 20
        Swaps: 0
        File system inputs: 0
        File system outputs: 398576
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

real    0m1.259s
user    0m0.390s
sys     0m0.318s

指標	Linux コンテナ	Wasm + Wasmtime
プログラム内部の合計	約 354 ms	約 1.15 s
起動を含む wall time	約 1.53 s	約 1.26 s

プログラム内部で計測した処理時間は、ネイティブ版が約 354 ms、Wasm 版が約 1.15 s で、Wasm 版は約 3.2 倍の時間を要しました。特に書き込み処理は、ネイティブ版の約 52 ms に対して Wasm 版は約 587 ms で、約 11 倍の差がありました。

一方、プロセスの起動から終了までを外側から計測した wall time は、Linux コンテナが約 1.53 s、Wasm 版が約 1.26 s でした。この測定ではコンテナの起動・終了やボリュームのマウントも含まれるため、処理が軽いほど固定オーバーヘッドの影響が相対的に大きくなります。

Wasmtime の事前コンパイルも試しましたが、今回の処理規模と測定条件では、起動から終了までの時間に明確な差は確認できませんでした。

検証 2：JSON ファイルの変換

検証 1 で作成した JSON ファイルをストリーム処理し、レコードを加工して別のファイルへ保存するプログラムを用意しました。主要部分だけ抜粋すると、次のようになります。

// 1,000 万件の JSON 配列を、全件メモリに載せずに変換する処理の抜粋
const CHUNK_RECORDS: usize = 1000;

// import、RecordArraySeed、Stats などの定義は一部省略
#[derive(Deserialize)]
struct Record {
    id: u64,
    name: String,
    value: u64,
    active: bool,
    tags: Vec<String>,
    metadata: Metadata,
}

fn run() -> Result<(), Box<dyn Error>> {
    let input_reader = BufReader::new(File::open("output.json")?);
    let output_writer = BufWriter::new(File::create("transformed.json")?);
    let mut writer = CountingWriter::new(output_writer);

    let mut stats = Stats::default();
    let mut deserializer = serde_json::Deserializer::from_reader(input_reader);

    RecordArraySeed {
        writer: &mut writer,
        stats: &mut stats,
        first_output: true,
        chunk: Vec::with_capacity(CHUNK_RECORDS),
    }
    .deserialize(&mut deserializer)?;

    Ok(())
}

impl<'de, 'a, W: Write> Visitor<'de> for RecordArraySeed<'a, W> {
    type Value = ();

    fn visit_seq<A>(mut self, mut seq: A) -> Result<(), A::Error>
    where
        A: SeqAccess<'de>,
    {
        self.writer.write_all(b"[\n").map_err(de::Error::custom)?;

        loop {
            let record: Option<Record> = seq.next_element()?;
            let Some(record) = record else {
                break;
            };

            self.stats.input_records += 1;

            if !record.active {
                self.stats.inactive_records += 1;
                continue;
            }

            // active なレコードだけ集計し、出力用の形へ変換する
            self.stats.active_records += 1;
            self.stats.sum_value_active += record.value as u128;

            let transformed = TransformedRecord {
                id: record.id,
                name_upper: record.name.to_ascii_uppercase(),
                value: record.value,
                value_bucket: value_bucket(record.value),
                tag_count: record.tags.len(),
                metadata_index_matches_id: record.metadata.index == record.id,
                checksum: checksum_record(&record),
            };

            self.chunk.push(transformed);

            if self.chunk.len() >= CHUNK_RECORDS {
                self.flush_chunk().map_err(de::Error::custom)?;
            }
        }

        if !self.chunk.is_empty() {
            self.flush_chunk().map_err(de::Error::custom)?;
        }

        self.writer.write_all(b"\n]\n").map_err(de::Error::custom)?;
        Ok(())
    }
}

impl<'a, W: Write> RecordArraySeed<'a, W> {
    fn flush_chunk(&mut self) -> Result<(), Box<dyn Error>> {
        let mut buffer = Vec::with_capacity(self.chunk.len() * 160);

        for record in self.chunk.drain(..) {
            if !self.first_output {
                buffer.extend_from_slice(b",\n");
            }

            serde_json::to_writer(&mut buffer, &record)?;
            self.first_output = false;
        }

        self.writer.write_all(&buffer)?;
        Ok(())
    }
}

検証 1 と同様に、ネイティブ版と Wasm 版をリリースビルドして実行しました。まず、1,000 万件のレコードをネイティブ版で処理した結果を示します。

===== ETL Stream Chunked Result =====
Target        : native (linux)
Input         : /data/output.json
Output        : /data/docker_trans_chunked.json
Input Records : 10000000
Active        : 5000000
Inactive      : 5000000
Input Size    : 2080566670 bytes
Output Size   : 820812629 bytes
Chunk Records : 1000
-----------------------------
Parse         : 8879.324619ms
Transform     : 414.402265ms
Serialize     : 701.872349ms
Write         : 199.750193ms
Total         : 11193.349553ms
-----------------------------
Sum Active    : 2499999500000000
Avg Active    : 499999900.000
        Command being timed: "/app/etl /data/output.json /data/docker_trans_chunked.json /data/docker_summary_chunked.json"
        User time (seconds): 10.47
        System time (seconds): 0.45
        Percent of CPU this job got: 97%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:11.19
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 1916
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 4
        Minor (reclaiming a frame) page faults: 226
        Voluntary context switches: 566
        Involuntary context switches: 308
        Swaps: 0
        File system inputs: 116328
        File system outputs: 1603160
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

real    0m13.229s
user    0m0.016s
sys     0m0.005s

続いて、同じ 1,000 万件のレコードを Wasm 版で処理した結果です。Wasmtime で事前コンパイルした etl.cwasm を実行しています。

===== ETL Stream Chunked Result =====
Target        : wasm32-wasip2
Input         : output.json
Output        : wasm_trans.json
Input Records : 10000000
Active        : 5000000
Inactive      : 5000000
Input Size    : 2080566670 bytes
Output Size   : 820812629 bytes
Chunk Records : 1000
-----------------------------
Parse         : 14674.735181ms
Transform     : 1348.216435ms
Serialize     : 1813.669283ms
Write         : 315.929614ms
Total         : 21722.474180ms
-----------------------------
Sum Active    : 2499999500000000
Avg Active    : 499999900.000
        Command being timed: "wasmtime --allow-precompiled --dir=. etl.cwasm output.json wasm_trans.json wasm_summary.json"
        User time (seconds): 20.98
        System time (seconds): 0.65
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:21.76
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 17340
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 3
        Minor (reclaiming a frame) page faults: 1385
        Voluntary context switches: 10149
        Involuntary context switches: 493
        Swaps: 0
        File system inputs: 54144
        File system outputs: 1603168
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

real    0m21.768s
user    0m20.986s
sys     0m0.651s

指標	ネイティブ版	Wasm 版
入力レコード数	1,000 万件	1,000 万件
入力サイズ	約 2.08 GB	約 2.08 GB
パース	約 8.88 s	約 14.67 s
データ変換	約 0.41 s	約 1.35 s
シリアライズ	約 0.70 s	約 1.81 s
書き込み	約 0.20 s	約 0.32 s
プログラム内部の合計	約 11.19 s	約 21.72 s
起動を含む wall time	約 13.23 s	約 21.77 s

同じ約 2.08 GB の入力を処理したところ、プログラム内部の合計時間はネイティブ版が約 11.19 秒、Wasm 版が約 21.72 秒でした。今回の条件では、Wasm 版はネイティブ版の約 1.9 倍の時間を要しています。

両者とも最も時間がかかったのは JSON のパースです。Wasm 版は、パースが約 1.7 倍、データ変換が約 3.3 倍、シリアライズが約 2.6 倍、書き込みが約 1.6 倍となりました。特定の処理だけではなく、各処理でネイティブ版より時間がかかっています。

検証 1 では、プログラム内部の処理時間はネイティブ版が短い一方、起動を含む wall time は Wasm 版がわずかに短くなりました。これに対し、処理量の大きい検証 2 では固定の起動オーバーヘッドが相対的に小さくなり、内部処理時間、wall time ともにネイティブ版が短い結果となりました。

Wasm 化する際の言語やライブラリ依存

Wasm は特定のプログラミング言語に限定されず、Rust、C/C++、Go など、さまざまな言語のコンパイルターゲットとして利用できます。ここでは、Wasm 化した際に生じる言語ランタイムやライブラリへの依存を調査しました。

Rust

Rust のツールチェーンには wasm32-unknown-unknown、wasm32-wasip1、wasm32-wasip2 などのターゲットが用意されており、Cargo から直接ビルドできます。

以前は、インターフェースの取得や WIT からのコード生成などを担う cargo-component が推奨されていましたが、ネイティブツールで代替できるようになったため、現在は非推奨化が進められています（Building a simple component (Rust)）。cargo-component を前提とした既存プロジェクトでは、移行コストに注意が必要です。

C/C++

wasi-sdk を使って次のようにコンパイルし、Wasmtime 上で実行できました。

$ cat main.cpp
#include <cstdio>
#include <iostream>
#include <string>

int main() {
    std::string str = "hello wasi-sdk!";
    std::cout << str << std::endl;
    std::printf("%s\n", str.c_str());

    return 0;
}
$ /opt/wasi-sdk-33.0-arm64-linux/bin/wasm32-wasi2-clang++ --sysroot=/opt/wasi-sdk-33.0-arm64-linux/share/wasi-sysroot main.cpp -o build/sample.wasm
$ wasmtime run build/sample.wasm
hello wasi-sdk!
hello wasi-sdk!

Python

Python では、componentize-py を使ってアプリケーションを Wasm コンポーネントへ変換できます。Building a Component with componentize-py を参考に、フィボナッチ数列を求めるプログラムを次の 3 種類で用意し、実行時間を比較しました。

Python で直接実行する実装
Rust のネイティブ実装
componentize-py で Wasm コンポーネント化し、Rust のホストから呼び出す実装

# Python 実装
$ time python main.py
63245986

real    0m14.259s
user    0m14.259s
sys     0m0.000s
# Rust 実装
$ time ./target/release/rs
63245986

real    0m0.145s
user    0m0.145s
sys     0m0.000s
# Python コードを Wasm 化した実装（Rust から呼び出し）
$ time ./target/release/wasm_host
63245986

real    0m20.492s
user    0m23.405s
sys     0m0.120s

Rust のネイティブ実装が最も速く、Python を Wasm コンポーネント化した実装は、Python で直接実行した場合よりも時間がかかりました。

componentize-py は Python のソースコードをネイティブコード相当へ変換するものではなく、Wasm 化した CPython とともにアプリケーションをコンポーネント化します。そのため、Wasm 化するだけで Python コードの実行が速くなるわけではないようです（componentize-py の issue #98）。

# componentize-py で作成したコンポーネントを呼び出し
$ time ./target/release/host
engine:        73.807µs
component:     3.264312132s
linker/wasi:   122.971µs
store:         45.106µs
instantiate:   3.682516ms
call_calc:     17.206531161s
result:        63245986
total:         20.474861541s

real    0m20.492s
user    0m23.405s
sys     0m0.120s

# Cargo で作成したコンポーネントを呼び出し
$ time ./target/release/host
engine:        108.934µs
component:     42.803586ms
linker/wasi:   113.557µs
store:         43.047µs
instantiate:   114.034µs
call_calc:     276.46852ms
result:        63245986
total:         319.723232ms

real    0m0.322s
user    0m0.290s
sys     0m0.000s

内訳を見ると、componentize-py で作成したコンポーネントは、関数の実行時間（call_calc）だけでなく、コンポーネントのロードにも時間がかかっています。これは、Wasm 化した CPython ランタイムを含むことと整合する結果です。
同じ動的言語であるJavaScriptもコンポーネントを構築するための ComponentizeJS がありますが、Pythonと同様にJS向けのランタイムをコンポーネントに含める必要があるようです。

個人的な考えですが、異なる言語やプラットフォームでセキュアに運用を可能にするためのABIとしてWasmは作られていると思っていて、Wasmのセキュリティが「サンドボックス環境での実行」「環境ごとのポリシー準拠」「Capability-Based Security」で保証されてるとはいえ、プログラム自体のバグは防げないので、Rustのような言語仕様とコンパイラレベルでの安全性を持っている言語との相性が良さそうだなと思いました。

ライブラリ依存について

プラットフォームや OS 固有の機能に依存するライブラリは、対象とする WASI のバージョンやランタイムが必要な API を提供していない場合、Wasm へのコンパイル時または実行時に問題が生じます。代表例は、プロセスの fork を前提とする処理です。

WASI は Wasm から OS 風の機能へアクセスするための標準インターフェースを提供しますが、POSIX 互換を完全に実現するものではありません。そのため、既存の POSIX 前提のソフトウェアやライブラリをそのまま Wasm 化しようとすると、未対応の API によってコンパイルエラーや実行時制約が発生することがあります。

こうした機能を補うため、Wasmer は WASI を拡張した WASIX を提供しており、スレッド、ソケット、fork などを扱えるようにしています。ただし、ランタイムやエコシステム固有の機能に依存すると、実行環境の選択肢が狭まり、Wasm の可搬性を生かしにくくなる可能性があります。

既存エコシステムとの統合

Wasm を本番環境へ段階的に導入する方法の 1 つが、既存のコンテナエコシステムとの統合です。

たとえば runwasi を利用すると、containerd から Wasm ワークロードを実行できます。下図のように、containerd と Wasm ランタイムの間を shim が仲介することで、Wasm ワークロードをコンテナと同様の操作体系で扱えます。

出典：[Docker + Wasm Technical Preview]

これにより、Kubernetes や Docker など、既存の運用基盤を生かしながら Wasm を導入できます。
docker-composeを用いてMySQL + Wasmアプリケーションを動かすというサンプルも存在しています。(参考 : microservice-rust-mysql)

まとめ

今回の検証から、Wasm は単純にコンテナを置き換えるものではなく、処理内容や運用要件に応じて使い分ける実行方式だと分かりました。

軽量な処理では、Wasm ランタイムの起動オーバーヘッドの小ささを生かせる可能性がある
Component Model と WIT により、異なる言語で作成したコンポーネントを連携させやすい
言語ランタイムや OS 固有の API に依存するアプリケーションでは、実行速度、バイナリサイズ、互換性を個別に確認する必要がある
既存のコンテナ基盤と統合すれば、ワークロード単位で段階的に導入できる

現時点では、短時間で起動する API、プラグイン、イベント駆動の処理などが Wasm の特徴を生かしやすい用途だと思いました。一方、成熟したミドルウェアや OS 機能への依存が強い処理は、引き続きコンテナのほうが扱いやすい場面が多そうです。

また、KubernetesやDockerなどのエコシステムとの統合により、コンテナとWasmの課題を両者の強みで補うような構成も実現できます。たとえば、ステートフルなサービスや大規模な処理はコンテナで行い、認証や検証などの軽量な処理はWasmで行うといったハイブリッドな構成です。

参考

vCluster と Grafana Alloy によるマルチテナント Kubernetes 環境のオブザーバビリティ基盤