RubyがWebAssemblyのWASI対応へ前進。ブラウザでもサーバでもエッジでもどこでもWebAssembly版Rubyが動くように

今回は「RubyがWebAssemblyのWASI対応へ前進。ブラウザでもサーバでもエッジでもどこでもWebAssembly版Rubyが動くように」についてご紹介します。

関連ワード （ブラウザ、実装、発生等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

Ruby言語のリファレンス実装、すなわち事実上の標準となっているRubyインタプリタはC言語で実装されています。そのため、このRubyインタプリタもしくはそのソースコードは一般に「CRuby」（もしくは、まつもとゆきひろ氏による実装という意味でMRI：Matz’ Ruby Implementation）と呼ばれています。

CRubyのソースコードをコンパイルすることで、Windows対応Rubyインタプリタのバイナリ形式やLinux対応Rubyインタプリタのバイナリ形式などが生成されるわけです。

今年、2022年1月7日、このCRubyのソースコードに対する要望チケット「Proposal to merge WASI based WebAssembly support」が提起されました。

これはCRubyのソースコードを、WASI対応のWebAssemblyバイナリ形式にコンパイル可能にするための変更を要求するものです。

そして約1週間後の1月15日、このチケットがRubyのパパであるまつもとゆきひろ氏によって承認されました。

これは何を意味するのでしょうか？

WASI対応のWebAssemblyバイナリはOSに依存しなくなる

WebAssemblyはもともとWebブラウザ上で高速に実行できるバイナリフォーマットとして開発されました。

その後、WebブラウザからWebAssemblyのランタイムを切り離してOS上で実行可能にしたランタイム、例えばLucetやWasmerといったWebAssemblyランタイムが登場します。

これによりWebAssemblyバイナリはWebブラウザだけでなく、WindowsやmacOSやLinuxなどのOS上でも実行可能になりました。

しかしWebAssemblyで現実的なアプリケーションを作る場合、ほぼ必ずOSのファイルシステムへのアクセスなどが発生します。すると、アプリケーションからOSのシステムコールを呼ぶことになります。

アプリケーションからOSを呼び出すAPIはOSに依存するため、アプリケーションをOSの作法に合わせて記述することになります。これではOSに依存しないポータブルなWebAssemblyアプリケーションの実装は困難です。

そこで登場したのが、WebAssemblyのアプリケーションに対してOSのシステムコールを抽象化することでOS依存をなくし、ポータブルなWebAssemblyアプリケーションを実現する業界標準仕様のAPI「WebAssembly System Interface」（WASI）です。

WebAssemblyランタイムがWASIに対応し、WebAssemblyアプリケーションがWASIを呼び出せるように作られていれば、そのWebAssemlbyアプリケーションはWebブラウザでもWindowsやMacなどのデスクトップでも、Linuxなどのサーバサイドやエッジでも動くポータブルなもの（WebAssemblyバイナリ）となります。

WASIはWebAssemblyバイナリをポータブルにするためのAPIなのです。

そして現在、多くのWebAssemblyランタイムがWASI対応を実現しており、ファイルシステムを持たないWebブラウザであっても仮想ファイルシステムを持たせてWASI対応を実現する、というランタイムが登場しています。

参考：WebAssemblyランタイム「Wasmer 2.1」リリース。WASI用に仮想ファイルシステムを実装し、ブラウザでもWASIが利用可能に

WASI対応WebAssemblyバイナリがポータブルであるという世界は、かなり現実的になってきています。

どこでもRubyコードが実行できるようになる

今回承認されたチケットは、CRubyのソースコードをwasi-sdkと呼ばれるWebAssemblyのビルドツールを用いてビルドすることにより、WASI対応のWebAssemblyバイナリの生成が出来るようにするための変更です。

このWebAssemblyバイナリが1つあれば、WASI対応のWebAssemblyランタイムがあるところであればどこでも、Webブラウザでもサーバサイドでもエッジでも、Rubyインタプリタが実行できるようになり、どこでもそのインタプリタ上でRubyのコードを実行できるようになるわけです。

RubyのアプリケーションをWebAssemblyバイナリにしてWebAssemblyランタイム上で動かすのではなく、RubyインタプリタそのものをWebAssemblyバイナリにするところが最大のポイントです。こうすることで、既存のRubyアプリケーションのコードを再コンパイルすることなく、そのまま動かせるようになるのです。

こうした、WebAssembly上にプログラミング言語のランタイムを実装する取り組みは、すでにRuby以外の言語でも行われています。

PythonにはPyodideと呼ばれるPythonランタイムのWebAssemblyによる実装があり、WebブラウザやNode.jsでPythonコードを走らせることができるようになっています。

マイクロソフトのBlazor WebAssemblyはさらに大がかりなアプローチといえます。WebAssemblyの上に.NETフレームワークを実装することで、Webブラウザ上でC#など.NETのアプリケーションを実行可能にしています。

これにより.NETプログラマはJavaScriptが書けなくてもWebアプリケーションが書けるのです。

参考：［速報」Blazor WebAssemblyが正式リリース。C#/.NETでWebアプリケーションを開発可能に。Microsoft Build 2020

RubyもCRubyがEmscriptenと呼ばれるWebAssemblyのコンパイラには対応しているとされています。

しかしいずれもWASI対応はまだのようで、今回のRubyによるWASI対応は先進的な取り組みではないかと思われます。

おおよその作業は完了、残る課題は

Publickeyでは、今回のチケットを起案したkatei (Yuta Saito)氏に、現状や見通しなどをうかがいました。

Katei氏によるとCRubyの移植自体に関してはおおよその作業は完了しており、残る課題は実行パフォーマンスの改善、RubyGemsやBundlerなど周辺ツールとの連携が主になるとのこと。

さらに、現在WebAssemblyバイナリに埋め込み可能なVFS（仮想ファイルシステム）を開発しており、ここに「.rb」ファイルを埋め込むことで、シングルファイルでRubyアプリケーションまでデプロイ可能にする、という開発も進めているとのことです。

このVFSはRuby以外にも適用可能だそうで、さまざまな用途に利用できそうです。

Webブラウザやサーバサイド、エッジなどで気軽にRubyが実行できるようになるとき、また新たなRubyの用途が開けていくかもしれません。期待したいところです。