次世代クラウド基盤「Wasm」の可能性と課題を探る

CloudNative Days Summer 2024にて、京都大学大学院の上田 蒼一朗氏と東京大学大学院の野崎 愛氏による「次世代のクラウドネイティブ基盤Wasmの今と未来」と題したセッションが行われた。セッションでは、Wasm（WebAssembly）の基礎から、開発者体験、そして今後の展望までが詳細に語られた。Wasmはブラウザーでの使用にとどまらず、サーバーやクラウドネイティブな領域での新たな可能性を切り開いている。

ブラウザーからサーバーへと拡張する技術「Wasm」

Wasm（WebAssembly）は、もともとブラウザー上で実行可能な仮想命令セットアーキテクチャとして登場した。セッション冒頭、上田氏は「Wasmはブラウザーのみならず、今やサーバー上でも実行可能となり、その用途は大幅に拡張しています」と語り、Wasmが進化し続ける技術であることを強調した。

WebAssemblyとは

Wasmの強みは三つある。まずポータビリティである。単一のバイナリファイルが複数のCPUアーキテクチャやOS上で実行できる点で、異なる環境への移植が容易となる。次にセキュリティだ。Wasmはサンドボックス内で実行されるため、外部との不正なやり取りが制限され、堅牢なセキュリティが提供される。そして最後に軽量性が挙げられる。Wasmのバイナリサイズは小さく、起動時間も短いため、リソースを効果的に活用できる。

上田氏はWasmが単にブラウザー上でJavaScriptに代わる技術であるにとどまらず、クラウドやサーバーサイドでも活用される可能性について「Dockerの創始者であるソロモン・ハイクスが『もしWasmが当時あったなら、Dockerは作られなかっただろう』と言及したほど、Wasmには画期的なポテンシャルがある」と語り、技術の今後の発展に期待を寄せた。

スタックマシンとリニアメモリ

Wasmの内部動作について、上田氏は「Wasmは基本的にスタックマシンとして動作し、各命令はスタックに対して操作を行う仕組みとなっています」と解説した。例えば、Wasmの命令である「local.get」は引数をスタックに積み、「i64.add」ではスタック上の二つの値を取り出して加算を行い、その結果を再度スタックに積む。このスタックマシン構造により、Wasmは効率的に演算を行うことができるという。

さらにWasmはスタックマシンでありながら、Linear Memoryというランダムアクセス可能なメモリ空間を持っている。このLinear Memoryは、Wasmランタイムによって動的にサイズを変更できるため、柔軟にメモリ操作を行うことが可能である。

Wasmのもう一つの特徴は、I/O操作を直接行わない点である。これに対してWASI（WebAssembly System Interface）という標準化されたAPIが提供され、ファイル操作やネットワークアクセスといったI/O処理を可能にする仕組みが整備されている。最新バージョンのWASIは2024年1月にリリースされたPreview2であり、今後の進展が期待されている。

多言語対応とコンテナ統合

続いて、野崎氏はWasmの開発者体験について「WasmはC、Rust、Goなどさまざまなプログラミング言語でコーディング可能であり、各言語のコンパイラを通じてWasmバイナリに変換することができる」と説明した。Wasmの多言語対応は日々進化しており、開発者にとって非常に柔軟な選択肢を提供している。

Wasmをどうやって書く？

またWasmの実行環境についても多様化が進んでおり、代表的なものとしてWasmtimeやWAMRなどのWasmランタイムが存在する。さらに最近ではコンテナエコシステムとの統合も進んでおり、containerd-shimというプロセスを通じてWasmランタイムを簡単に操作できるようになっている。この技術により、Wasmはコンテナランタイムと同様の操作感で運用可能となり、クラウドネイティブな環境でのデプロイも容易になっている。

野崎氏は「Wasmをデプロイできるサービスは増えてきており、例えばMicrosoftではWasm用のハイパーバイザーを開発していると言われています」と語り、今後の技術的な展開に期待を示した。

Component Modelとその可能性

次にWasmの未来について野崎氏は「現在、Wasmで最も注目されている話題はComponent Modelです」と述べた。従来のWasmは、外部モジュールとのインポートやエクスポートが不得意であり、型の表現が制限されていた。これに対しComponent Modelが導入され、モジュール間での型のやり取りが容易になったという。

Component Modelの登場

Component Modelとは、複数のWasmモジュール間でのデータや機能のやり取りを、より柔軟かつ効率的に行えるようにするための仕様である。従来のWasmは、モジュール間のデータ交換において、各モジュールが扱うデータの形式（例：整数や浮動小数点数）を厳密に揃えなければならず、異なる言語で作成されたモジュール間でのデータ交換は容易ではなかった。これを解決するために導入されたのが、WIT（Wasm Interface Types）とCanonical ABIである。

WITは、Wasmモジュール間で使用するインターフェース（関数やデータ型）の定義を記述するための言語であり、これにより異なるプログラミング言語で書かれたモジュール間のデータ型や関数のやり取りがスムーズに行えるようになる。これを使うことで、例えばRustで作成されたモジュールとJavaScriptで作成されたモジュールとの間で相互にデータをやり取りする際の型変換が自動化され、開発者が複雑なデータのマッピングを手動で行う必要がなくなる。

またCanonical ABIは、モジュール間のデータの表現規約を定め、データのやり取りをバイナリレベルで保証するものである。これにより異なるプログラミング言語や実行環境であっても、共通の方法でデータを交換できる。たとえば文字列の扱い方が言語間で異なる場合でも、Canonical ABIを使えば、Wasmモジュール間で一貫した方法でデータをやり取りできる。

このような仕組みを導入することで、従来のWasmでは課題となっていたモジュール間の連携が飛躍的に向上し、より高度なモジュールの再利用が可能となる。たとえば、ある言語で作成されたライブラリを別の言語でそのまま利用できるようになるため、開発者は一度作成したモジュールをさまざまな言語やプロジェクトで活用できるという大きな利点がある。

野崎氏は「Rustで作成したコンポーネントをJavaScriptから呼び出す例では、ユーザー側が型変換の詳細を意識することなく相互運用ができます。このような仕組みが、今後のWasm開発をさらに促進します」と述べ、コンポーネントモデルの実用性と将来性を強調した。

ただしWasmには依然として課題も残されている。とくに共有手段の未成熟さやバイナリサイズの最適化が求められており、これらの課題を解決するための技術的な進展が期待される。セッションの締めくくりとして、野崎氏は「Wasmはまだ発展途上の技術ですが、その可能性は非常に大きいです。今後も注目していくべき技術です」と語り、技術の未来を見据えていた。