WebAssemblyが目指していること。ナノプロセスモデルの実現、システムインターフェイス、実行時リンクの実装など

Webブラウザ上でネイティブコードのように高速に実行できるバイナリフォーマット「WebAssembly」は、すでにChromeやFirefox、Edge、Safariなどの主要ブラウザでサポートされ、2019年12月にはW3Cの勧告にも到達しました。

参考：WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ

このWebAssemblyをWebブラウザだけでなく、デスクトップPCやサーバ、IoTデバイスなどのあらゆる環境でセキュアに実行できるように、エコシステムの実現を推進しているのが、Mozilla、Fastly、Intel、Red Hatらによって設立された「Bytecode Alliance」です。

参考：WebAssemblyをあらゆるプラットフォームでセキュアに実行できるようにする「Bytecode Alliance」発足。インテル、Mozilla、Red Hatなど

Bytecodeの設立は今から1年前の2019年11月です。設立から1年を迎え、現時点での進捗を紹介する記事「Bytecode Alliance: One year update」が公開されています。

この記事を参照しつつ、あらためてBytecode AllianceがWebAssemblyで目指していることは何なのか、まとめてみましょう。

Nanoprocessモデルをどうやって実現するか

前述したように、Bytecode Allianceが設立された目的は、WebAssemblyをWebブラウザだけでなく、デスクトップPCやサーバ、IoTデバイスなどのあらゆる環境でセキュアに実行できるようにすることです。

そのためにBytecode Allianceが実現しようとしているのがNanoprocessモデル（ナノプロセスモデル）です。

Nanoprocessはその名の通り、WebAssemblyのモジュールごとに小さな仮想マシンのようなものを用意し、モジュールを独立したメモリ空間で分離することで、他のプロセスやモジュールからの影響を受けずに実行する、という仕組みです。

ただし単にモジュールを分離させるだけでは、安全にはなってもモジュール間連携が面倒になるだけで、エコシステムをその上に構築することも難しくなります。

ナノプロセスモデルを実現するための3つの技術的要素

そこで、このナノプロセスモデルを基盤としたエコシステムとして成立させるために、さらに3つの技術的要素の実現に取り組んでいると「Bytecode Alliance: One year update」では説明しています。

1つ目は、WebAssemblyモジュールからホストOSなどの機能へ安全かつ透過的ににアクセスするためのインターフェイスを規定する「WebAssembly System Interface」（WASI）。

2つ目は、複数のWebAssemblyモジュールを連係させる「Module linking」です。

3つ目は、WebAssemblyのモジュール間もしくはモジュールとOSのあいだで情報をやりとりするためのインターフェイスを規定する「Interface types」です。

WASI：WebAssemblyからファイルやネットワークにアクセス

「WASI」はどのOSやホストシステムでWebAssemblyモジュールが実行されていたとしても、安全かつ透過的に共通のAPIでOSやホストシステムの機能を呼び出すための仕様です。

最終的には幅広いAPIが策定されることになりますが、まず最初に策定されるwasi-coreは、POSIXの基本的な要素にならってファイル、ネットワーク接続、クロック、ランダム番号生成などが含まれます。

さらに、OSなどの低レベルな機能だけでなく、高レベルな機能としてニューラルネットワークによる機械学習機能を呼び出せる「wasi-nn」などの策定も進んでいるとのことです。

Module linking：リンクによる複数モジュールの連係

さまざまなモジュールを組み合わせてアプリケーションを構築できることで、コードやモジュールの再利用性を高めることはアプリケーションの品質や生産性の向上につながります。

「Module linking」はWebAssemblyにおいてそうしたモジュールのリンク機能を高度化していこうという試みです。

現時点でもlinker APIを記述することでモジュールのリンクが実現されますが、Bytecode Allianceではこれをより宣言的にすることで使いやすくするとともに、現在はWebAssemblyモジュールのロード時にリンクが行われるような仕様の策定と実装に取り組んでいるとのこと。

将来的には実行時の動的なリンクも実現しようとしています。

こうしたWebAssemblyモジュール間やホストOSとの情報の受け渡しについて策定しているのが「Interface types」です。すでにReference Types、multi-value、multi-memory supportなどが実装されています。

WebAssemblyランタイム、LucetとWasmtimeは統合へ

ByteCode Allianceを中心に行われているこれら仕様策定と同時に、実際に仕様をWindows/Linux/Mac上で実行可能なWebAssemblyランタイムとして実装することも進められています。

その代表的が、Fastlyの「Lucet」とMozillaの「Wasmtime」です。

参考：Fastly CTOに聞く、同社がWebAssembly実行環境の「Lucet」をエッジコンピューティング環境として開発している理由とは？

そして今回、MozillaのWasmtime開発チームがFastlyへ移籍したことも発表されました。

もともとLucetとWasmtimeはマージが計画されていましたが、Wasmrime開発チームの移籍によりその実現がさらに近づくことになります。これが今後、WebAssemblyのstand-alone環境におけるリファレンスランタイムになることは間違いないでしょう。

Mozillaは収益不振から8月に大規模なリストラを行っており、もしかしたらこれが移籍のきっかけに作用したのかもしれません。

参考：Mozillaが大規模リストラ。「すべてが無料だった古いモデルには結論が出た」として今後は新たなビジネスモデルを模索すると

WebAssemblyのエコシステム充実に期待

WebAssemblyは注目されている技術ながら、フレームワークやライブラリ、開発ツールなどのエコシステムが充実しているとはいえません。

Bytecode Allianceが進めている仕様や実装を基盤に、これからそうしたエコシステムが揃っていくことを期待したいところです。

関連記事

WebAssemblyではそのほかにも下記のような興味深いプロジェクトも進められています。あわせてぜひご覧ください。

• KubernetesのノードとしてWebAssemblyランタイムを用いる「Krustlet」、マイクロソフトが公開
• ［速報」Blazor WebAssemblyが正式リリース。C#/.NETでWebアプリケーションを開発可能に。Microsoft Build 2020