WebAssemblyの“Openさ”は多様な応用先を生む源泉　自分だけのWasm Embedding Interfaceを考えよう

WASIはOSの上でWasm executableを動かすためのPortableなAPI／ABI

佐伯学哉氏（以下、佐伯）：そういう特徴があると、かなりうれしいことがわかったんですが、具体的に何に使われているのか特にWASI（WebAssembly System Interface）とProxy-Wasm（Web Assembly for Proxies）について話したいと思います。

WASIはWebAssembly System Interfaceの略で、OSの上でWasm executableを動かすためのPortableなAPI、またはABIです。API/ABIという書き方をしているんですが、WebAssemblyでは関数呼び出しとかのABIが最初から決まっているので、APIを決めたらABIも決まってしまいます。なので、API/ABIと書いています。だいたいPOSIXと同じか、少し下くらいのレイヤーです。

WASIはWebAssemblyがSafeであって、Portableであることを利用しているフォーマットです。パソコンの上で直接WebAssemblyを動かすインターフェイスになるのでかなり直感的で、名前を聞いたことがある方も多いんじゃないかと思っています。

これはBytecode Allianceというコミュニティによって仕様がメンテナンスされていて、Bytecode AllianceにはMozillaとか、LucetのFastlyとか、Intelとか、Redhatとかが入っています。

WASI APIの例です。例をドドーンと出しても仕方がないので、本当にちょっとだけ紹介します。ファイルシステムやプロセスなど、およそOSの上でなにかを動かすために必要そうなものはWASIで決まっています。

左の図に書いてあるのは、いわゆるライブラリのオープン関数をどうやってWASIで実装するかという話です。中身はwasi_path_openというAPIとして決まっているという話ですね。GitHubに全関数がドドーンとあるので見ることができます。

Wasmの安全性はAPIの安全性に依存する

WASIのセキュリティについてですが、WASIはWasmに加えて独自のセキュリティ機構をもつ、もしくはもつ予定です。WASIは策定中なので、いろいろと未熟だったりstableじゃなかったりします。

先ほどWasmはSafeでIsolatedでうれしいみたいな話をしたんですが、本当か？　という話なんですね。これは実は語弊があって、Wasmが全部のLinuxのシステムコールを呼べれば、自由に変なことができたり、いろいろな副作用があったりするので、ぜんぜん安全ではありません。

Wasmの安全性は、ホストが提供するAPIの安全性に依存します。なので、本当にセキュアなランタイムインターフェイスを定義しようと思ったら、そこをケアする必要があります。

具体的にWASIがどうしようとしているかという話になるのですが、策定中の仕様ではCapability Baseのセキュリティ機構を導入することが決まっています。例えばファイルシステムのアクセスは、ディレクトリごとにcapabilityを取得する必要があって、POSIXとかよりもかなり粒度が細かいです。このcapcabilityの話は、microkernelとかを想起する機構、最近だとFuchsiaがそうらしいです。

いずれスマホアプリのような、セキュリティモデルがネイティブデスクトップで実現できるようになるかもというイメージです。ネイティブバイナリみたいに、Seccompでガチガチに固めなくていいのでうれしいですね。

「Portable」「Safe」「Open」を利用するProxy-Wasm

Proxy-Wasmというのがもう1個の例なんですが、これはPortable、Safe、Openさを利用して、プロキシにやってきたL4/L7のリクエストやレスポンスを、WebAssemblyのロジックでこねくり回すためのインターフェイスです。Envoy周りの人たちがコミュニティ主導でメンテナンスしています。

どういうことかというと、パケットやHTTP通信が来た時に呼ばれる関数をWasm側からexportして、Envoyなどのプロキシは通信が発生した際にその関数を呼びます。呼ばれた側のWasmは、さらにプロキシ側が定義したAPIを呼び出して、ログを書くなり、レスポンスを返すなりします。

これはWasmのオブジェクトファイルで決まっている双方向のImport/Exportができることで実現されている機能です。

そんなことをして何がうれしいのかという話ですが、Envoyは以前は同じ仕組みを前からC++で書いたstatic libraryを差し込むことで実現していました。

それと比較した時のWasmの利点は、まずSafeであることです。Untrustedなコードを実行できます。C++はただのプログラムなので、なんでも悪いことができてしまうんですよね。しかも、Portableです。

また、Language-independentなのでC++だけではなくて、RustやGoでもEnvoyのプロキシを実現できるようになります。これはかなり便利な一般化ができるという話で、現在だとLuaくらいしかやっていないフィールドです。

いろいろなユースケースが考えられるWasmの活用

Proxy-Wasmのモチベーションを一般化するといろいろなことがわかって、双方向のAPIが欲しくて、SafeでPortable、Fastに動いてほしい場所があるならば、実はそこはWasmの適任の場所であるという話があります。

In-kernel executableとかEthereumとか、一般のプラグイン機構とかもうまくWasmを利用できるかもという話があるんですね。みなさんも「これをWasmでもっとうまくやれるんじゃない？」というケースがあったら考えてみましょう。特定の言語を使っているとか、APIが言語決め打ちとか、Vimとか、Vimのエディタプラグイン機構とか、ETLとか、いろいろなものがユースケースとしてあり得ると思っています。

Proxy-WasmはFastlyのCDNなどかなり似た事例が存在します。

これはちょっと余談なのですが、実はProxy-WasmをメンテナンスしているTetrateに最近転職しました。Proxy-Wasmの開発にかかわっています。Enterprise Service Meshをやっている会社で、サンフランシスコにリモート勤務しているので最近はドル円の動きに一喜一憂しています。

WASI的なモチベーションも同じように一般化できて、SafeでPortableな場所が欲しいところにはWasmが使えるという話です。

エコシステムは羅列をするだけなので、サラッと流していきたいと思います。ランタイムはWasmtime、Wasmer、Lucet、WAVM、Wasm3、V8などいっぱいあります。しかもこれで全部ではないので、興味があればみなさんも自分だけのランタイムを探してみてください。

Toolchainは、最初に言ったように言語ネイティブのToolchainがバックエンドとしてサポートすることが多いので、かなり多くの言語がWasmをサポートしています。

自分だけのWasm Embedding Interfaceを考えてみよう

一方で、Wasmはまだまだ未熟なので整備中ものがたくさんあります。例えばDynamic linkや、デバッグのDwarf/Debugger仕様や、Inter-Language Type Procedureなどが今策定し直されていて、今の時代に低レイヤーの仕様が開発されるのを見るのは楽しいなと思います。

まとめです。Wasmは複合的なアツさをもっています。Javaが目指したもの、CLIが目指したもの、NaClが目指したもの、あとLuaがやっていることなど、いろいろなことをカバーしていて、アツいよという話が伝わっていればうれしいです。

特にOpenさが多様な応用先を生む源泉になっています。これからもいろいろな分野で応用されていくはずなので、「みなさんも君だけのWasm Embedding Interfaceを考えよう」というまとめをさせてもらいたいなと思います。以上です。

司会者：ありがとうございました。質問が来ています。「Proxy-Wasmという存在と、EnvoyのプラグインをWasmで書くというのはどう違うのでしょうか？　それとも同じでしょうか？」　

佐伯：絶妙な質問ですね。僕も同じと言い切っていいのかちょっと自信がないんですが、ほぼ同じです。Proxy-Wasmはプロキシがプラグインを書きたかったらどういうAPIをImportして、どういうAPIをExportすればいいかという仕様が決まっていて、Envoyはそれに準拠したProxy-Wasmの実装をもっています。

しかも現状Envoyは、一切Proxy-Wasmを拡張していないので、今は同じだと言っていいと思います。Proxy-Wasmが仕様で、Envoyはそれを実装しているという話になりますね。

司会者：ありがとうございました。