WebAssemblyを進化させる「WASI Preview 2」が安定版に到達。OSや言語に依存しないコンポーネントモデルを実現

2024年1月29日

WebAssembly関連仕様の標準化を行っているW3C WebAssembly Community GroupのWASI Subgroupミーティングにおいて、2024年1月25日に行われた投票で「WASI Preview 2」（もしくはWASI 0.2.0）仕様が承認され、安定版に到達したことが明らかになりました。

WASI Preview 2では、WebAssemblyアプリケーションがOSなどのプラットフォームに依存せず、さまざまなプログラミング言語で開発したWebAssemblyコンポーネントを組み合わせて開発できるように、「コンポーネントモデル」とそのインターフェイスを記述するIDL（Interface Definition Language）である「WIT（WebAssembly Interface TypeもしくはWasm Interface Type）」を基盤にしたものになっています。

WASI Preview 2登場の背景

WASI Preview 2がどのような背景の下で登場したのか、簡単にこれまでのWebAssemblyの歴史を振り返ってみましょう。

プロセッサ非依存のバイナリフォーマットとして登場
WebAssemblyはもともと、Webブラウザ上で高速に実行可能なバイナリフォーマットとして登場し、2019年12月にW3Cの勧告に到達し、Google Chrome、Firefox、Safariなど事実上全てのモダンブラウザが対応しました。

これによりWebAssemblyはプロセッサのアーキテクチャに依存せず、x86プロセッサでもArmプロセッサでもRISC-Vプロセッサでも高速に実行可能な、ユニバーサルなバイナリフォーマットとして知られるようになります。

また、RustやGoなどさまざまなプログラミング言語がWebAssemblyバイナリを生成可能です。このような多言語対応もWebAssemblyの特徴の1つです。

WASIによりOS非依存のクロスプラットフォーム対応に
WebAssemblyをWebブラウザだけでなくOS上のスタンドアロンなWebAssemblyランタイムでも実行可能にしようと、OSのAPIを抽象するために登場したのがWASI（WebAssembly System Interface：現在のWASI Preview 1）です。

WASI Preview 1の登場で、例えばOSによって異なるファイルシステムへのアクセスなどが抽象化されました。WASI Preview 1に対応したWebAssemblyアプリケーションであれば、WASI Preview 1対応ランタイムを用いることでWebブラウザでもmacOSでもLinuxでもWindowsでも、そのまま実行可能になりました。

そしてWasmtimeやWasmer、Cloudflare Workers、Fastly Compute@Edgeなど主要なWebAssemblyランタイムがWASI Preview 1に対応したことで、WebAssemblyは単一アプリケーションでのクロスプラットフォーム対応を実現したのです。

ガベージコレクション機能で対応言語がさらに拡大
また2023年にはWebAssemblyのガベージコレクション機能がGoogle Chromeを始めとするWebAssemblyランタイムに実装されるようになりました。

これによりプログラミング言語をWebAssemblyに対応させる際に、プログラミング言語自身でガベージコレクタを実装する必要がなくなります。つまり以前より容易にさまざまなプログラミング言語がWebAssemblyに対応可能になりました。

このガベージコレクション機能を利用して、KotlinやDartといったプログラミング言語がWebAssembly対応を進めています。今後さらに多くのプログラミング言語がWebAssembly対応になると見られます。

こうして着実に進化してきたWebAssemblyですが、WASI Preview 1にはいくつかの課題がありました。

WASI Preview 1の課題

WASI Preview 1にはOSのAPIを抽象化するという目的があったため、UNIXをベースにしたAPIの標準規格であるPOSIX（Portable Operating System Interface）の主要なAPIを手本としてWASI Preview 1が実装されました。その後、WASIの仕様を拡張してさまざまな機能を拡充していく際にはモジュール的にAPIを追加していく予定でした。

しかしUNIXがCで実装されたOSであるという歴史的経緯からPOSIXもC言語を指向したAPIとなっています。WASI Preview 1はこのPOSIXを手本にしたことで、多言語でインターフェイスを実装するのに向いていないこと、ソケットは十分にサポートできず、インターフェイスの仮想化も困難、コンポーネントを組み合わせるためのインターフェイスとして用いるのが困難、などの課題が浮かび上がりました。

これについてはWASIの実装と普及を推進する団体であるBytecode Allianceが2月1日に公開した動画「Bytecode Alliance Community Meeting」で説明しています。下記はその動画内で説明に使われたスライドです。

そこで、さまざまなプログラミング言語に対応するなどのWebAssemblyの特徴を活かすため、多言語に対応したコンポーネントによる機能拡張やアプリケーションの構築を実現すべく、WASI Preview 1を刷新して新たにコンポーネントモデルとそのためのインターフェイスであるWITをベースに開発されたのが、今回安定版となった「WASI Preview 2」（もしくはWASI 0.2.0）なのです。

コンポーネントモデル、WIT、Worlds

WASI Preview 2は前述の通り、コンポーネントモデルとそのインターフェイスを記述するIDL（Interface Definition Language）である「WIT（WebAssembly Interface TypeもしくはWasm Interface Type）を基盤にしています。

コンポーネントモデルによるコンポーネントとは、実体はWebAssemblyファイルであり、そのなかに1つから複数のWebAssemblyモジュールを含んでいます。

WITで表現されるコンポーネントのインターフェイスは、プロセッサのアーキテクチャやOS、開発に用いられたプログラミング言語に依存せず相互に通信できるようになっています。

WITは、コンポーネントのインターフェイスを主にfunction（関数）とType（型）によって記述することで、コンポーネントの入出力を定義します。

下記はそのサンプルコードです。hostというインターフェイスにはlogという関数があり、その関数はstring型の引数が1つとなっている、といったことが記述されています。

package local:demo;

interface host {
  log: func(msg: string);
}

このWITを基に、さまざまなプログラミング言語に対応したコンポーネントの初期コードの生成を可能にするツールなども用意される予定です。

また、WITを複数束ねて名前を付けた「WIT Worlds」もWASI Preview 2の大きな特徴です。

WIT Worldsによってコンポーネントの外部のアプリケーションとの入出力についてより上位のレベル、例えば「HTTPプロキシ」としてのやりとりや「コマンドラインツール」としてのやりとりを記述できます。コンポーネントとは、このWIT Worldsの実装を内部定義したものとも言えます。今後さまざまなWorldを実装したコンポーネントが登場することが期待されます。

WASI Preview 2は、このコンポーネントモデルとWITを基盤に次の7つのシステムインターフェイスも公開されました。