ちょっと気になる隣の技術畑

第11回プラットフォームを超えるWebAssembly

本コーナーでは技術へのタッチポイントを増やすことを目標に、各分野で活躍されている方をお迎えします。今回はWebAssemblyです。高速安全に動作する特徴やブラウザでの利用を超えていく将来の展望など、あんどうさんとざっくばらんに紹介します。

話し手 あんどうやすし ANDO Yasushi

【話し手】
あんどうやすし ANDO Yasushi

㈱ Cogent Labs所属。おもしろそうなWeb系フロントエンド技術について翻訳したり執筆したり。だけど最近興味があるのはAI倫理。
やはり倫理……! 倫理はすべてを解決する……!!
Twitter @technohippy
GitHub technohippy

WebAssemblyとは

日高: 今回はWasm(WebAssembly)をテーマにお話を伺います。よろしくお願いします。あんどうさんといえば多くの技術書を執筆、翻訳していますよね。

あんどう: 主にオライリー・ジャパンで執筆、翻訳を手がけています。JavaScriptやWebGL、TensorFlow.jsといったWeb関係書籍です[1]

日高: 私も書棚でお名前を目にしたことがあります。

あんどう: ちょっとおもしろそうなWeb技術を見つけたら編集者さんにお声がけして翻訳させてもらっていますね。

日高: 新しい技術を吸収できていいですね。技術書典でもWasmの書籍[2]を執筆されていますが、どのような形で興味を持ったのでしょうか?

あんどう: Wasmは、登場当初から注目を浴びていたように思います。ついにJavaScript以外のブラウザ上で使える言語が登場したということで。

日高: 登場した2015年[3]はブラウザで動くスクリプト言語の高速化についてasm.jsやDartで試行錯誤があったころだと記憶しています。

あんどう: Dartをブラウザに組み込む話がなくなったのは残念でした。Wasmはasm.jsの考え方を引き継いで一から開発された言語ですが、それゆえにJavaScriptでは難しかった高速化を実現できたんだと思います。

日高: ブラウザ上でのJavaScript実行速度の向上は今でも大きな課題ですよね。

あんどう: 2015年当時、ブラウザベンダーはJavaScriptの言語仕様に限界を感じていたのではないでしょうか。どうしたって型があってコンパイルできる言語のほうが高速化しやすいですから。

日高: 現在はWasmも普及してブラウザ上で動く2番目の汎用言語だと認知を得ています。どんな利点が喜ばれたのでしょうか?

あんどう: 私のような普通のWebエンジニアは、すでに用意されたWasmモジュールをJavaScriptから関数として呼び出して高速化の恩恵を受けるだけです。それはそれでうれしいのですが、本当にWasmに興奮しているのはそういうパフォーマンス要件がシビアで高速化が要求される処理を実装しなければいけない側の人たちだと思います。

日高: たしかにWasmを使って処理時間を短縮したいパートは、ライブラリやほかのプラットフォームからの移植作業が思い浮かびます。

あんどう: WasmはCやC++、Rust言語などのコンパイルターゲットとしてモジュールを出力し、ブラウザ上で動かすという使い方が多く、コンパイラ基盤のLLVMもWebAssembly Backendをサポートしていてそのためのツールも充実しています。

高速化のための仕様

日高: Wasmの高速化のしくみには、どのような特徴があると考えますか。

あんどう: Wasmは実行に先立ってネットワーク経由でコードが送られてくることが想定されているので、実行そのものの高速化と、処理開始までのリードタイムの短縮を考える必要があります。

日高: ロードと実行処理、2つの観点があると。

あんどう: 実行の高速化については単純にコードがバイナリであること、変数に型が指定できること、その型が数値型しかないことが大きいと思います。

日高: 仕様が単純だから高速なんですね。

あんどう: おもしろいのはリードタイムの短縮で、Wasmモジュールはファイルをすべてダウンロードしなくても、ストリーミングで読み込めるようになっています。

日高: ブラウザでダウンロード完了を待たずに処理を始めることができる。

あんどう: 全部読み込むまで待つのはつらいですからね。このあたりは、新規に言語を設計したおかげで仕様を簡潔にまとめられた部分だと思います。

日高: 設計者の意図が伝わってきます。

あんどう: Wasmバイナリフォーマットもわかりやすい。構造の最上位にモジュール、その中にさまざまな機能を持つセクションがあります。セクションごとにパースしたりチェックしたり、コンパイル処理が可能です。

日高: このあたりはダウンロードという感覚がないと作れないフォーマットだと感じます。動画や音声などのメディアファイルに似ていますね。

あんどう: たしかに。効率的でポータブルなコードを実現する工夫ですよね。セクションのヘッダにはそのセクションのサイズが書かれているので、とにかくサイズ分を読み込めば処理を進められるわけです。

日高: 考えられたバイナリ仕様ですね。

あんどう: 私がWasmの書籍を書いてみたのもそのあたりの言語仕様への興味からでした。

日高: シンプルだとしても仕様を読むだけでWasmの理解は難しそうですが。

あんどう: 実際に仕様を読んでコードを書いてみるという経験が理解につながります。書籍もその流れでまとめているつもりです。

日高: 理解するために実際にコードを書いてみたいと思うのはエンジニアあるあるですね。

あんどう: Wasmのバイナリはスタックベースの仮想マシン上で動作することを想定しています。ですので書籍では自分で実行ランタイムを作って覚えるという体裁になっています。

日高: 実行ランタイムってそんなに簡単に作れるものでしょうか?

あんどう: スタックマシンは単純なので、機能を最低限に絞れば大丈夫ですよ。

日高: なるほど。最低限の機能を実装してみるというのは、実際の理解に役立ちますね。

あんどう: 私の場合、遊びでRubyに機能を追加するなど昔から言語そのものへの興味が強かった背景が影響しているのかも。まぁ自分が遊びで使う分には、何をしても誰も怒らないですよ。そうやって実際に作ってみることが理解することに直結すると思います。

聞き手 日高正博
画像

広がるユースケース

日高: Wasmのユースケースには、どのようなものが考えられるでしょうか。

あんどう: 以前の職場の話ですがJavaScriptでは重たい処理があったのでWasmを使って高速化したことがあります。

日高: どのようにして実装しましたか。

あんどう: Go言語で書いてWasmに出力しました。これは意外と面倒くさかったですね(笑⁠⁠。

日高: 苦労があったと。

あんどう: ええ、そのころのGo言語は今と違ってWasmサポートが限定的でしたから。技術的興味が高じての導入でしたが、最終的にはちゃんと高速化できて良かったです。

日高: 最近はWasmを使うならRustが主流になっているようですね。

あんどう: というか、当時からRustだった気がします。海外で出版されているWasmの技術書のうち7~8割はRustを使っているのかなと。私が知っている限りですが。

日高: RustのWasmサポートが手厚いからかな。

あんどう: そうですね、昔から手厚かったように思います。

日高: Wasmを用意する手間やJavaScriptからの呼び出しなどの準備をしてまで高速化することは、どのあたりにモチベーションがあるんでしょう。

あんどう: ブラウザで本格的に重たい処理をしたければWasmかWebGLがパッと選択肢に挙がるのではないでしょうか。WebGLも良いと思いますが汎用計算のための手段とは言いにくいです。

日高: WebGLはコンピュータグラフィックスのレンダリング処理が主眼ですよね。

あんどう: そうすると、残るのはWasmです。Wasmが実際に利用されている良い例は、オンラインミーティングツールのGoogle Meetかな。背景ぼかし機能にWasmを使っています。

日高: ちょうど我々のインタビューでも使っていますね(笑⁠⁠。

あんどう: 背景ぼかし機能では、WasmのSIMD命令(並列処理)を利用するとともに、多くの処理をWasmランタイム内で完結させることで高速化しているようです。

日高: JavaScriptとWasmランタイムを行ったり来たりしなくて済むし、レンダリング部分はWebGLに任せればいい。適材適所の役割分担ですね。

あんどう: ゲームなどでアプリケーション全体をWasmにする場合を除けば、現在だとWasmの使いどころとしては画像、特に動画配信などメディア処理が多いのではないでしょうか。

日高: ブラウザベースの重たい処理がメインターゲットとなると。

あんどう: ブラウザから少し離れたところだと、セキュリティサンドボックスが利用できることから、エッジコンピューティングにWasmが採用されたというニュースがありますよ。

日高: 分散処理にも使うんですか?

あんどう: FastlyのCompute@EdgeというサービスでWasmが使われていますし、CloudflareのCloudflare WorkersでもWasmを利用できます。コンパクトでセキュアという特徴から、Wasmはブラウザから離れたところでも活躍しています。

日高: ユーザーの近くで応答してネットワークレイテンシを下げるだけでなく、安全かつ高速なWasmを使ってさらに体験を良くする。Wasmの特徴が活かされていると思います。

写真1 リモートでインタビューを行いました
写真1

言語との付き合い方

あんどう: いろいろなところで使われているWasmですが、仕様がとてもシンプルでわかりやすいのが良いところです。私でも部分的に作れるぐらいですので気楽に仕様書を読んでみてもいいのでは。

日高: おもしろそうです。私は古くからあるプログラミング言語を使ってきたので仕様書に対して読み切れるという印象がなく、身構えてしまいますけども(笑⁠⁠。

あんどう: 今のところはとても単純なので、プログラミング言語の内側を知るという意味でもお勧めです。ただし、Wasmは現在GC(ガベージコレクション)の試験導入が進んでいます。今後は複雑な機能が増えていくのかもしれません。

日高: GCは2023年3月時点で仕様策定段階と聞いています。これはJavaなど仮想マシンにメモリ管理機能がある高級言語でのWasm対応を見据えていそうです。複雑になると利用する側も注意すべき点が増えるかもしれませんね。

あんどう: はい。最初に出てきたWasm 1.0はMVPMinimum Viable Productを実現したものだったと思います。2.0以降はより実践的な機能が追加されていきそうです。

日高: 最小限の機能で作ってから、機能言語との付き合い方を追加していくというのはよくある手法です。

あんどう: 発表当時の2015年を振り返ると、過去の手法とは異なる新しい技術としてWasmを生み出したわけです。結果的にasm.jsによる高速化やNative Clientのサンドボックス化技術など目指すべき方向性を受け継ぎつつ、小さく一から始められたことが幸いして、現在のように広く受け入れられたのだと思います。

日高: 高速性と安全性を両立できたと。

あんどう: WASIWebAssembly System Interfaceのおかげでマルチプラットフォームで動作するのも良いですね。

日高: WASIと言えば最近ではマルチスレッドによる並列処理を実現する仕様提案(wasi-threads)もでていますね。

あんどう: その仕様を提案したByteCode AllianceはWasmの開発を推進する組織です。先ほど話題にあがったFastlyやMicrosoft、Mozilla、Google、Intelなどが参画しており、幅広い用途でWasmを使えるようにという趣旨なのでしょう。

日高: 将来のユースケースを想定して、どんどんと仕様が提案されている。言語仕様も作って終わりではなくて進化していく時代だと感じます。

あんどう: エッジコンピューティングで使うというのも当初は考えていなかったはずですよね。

日高: お話を聞いていると課題を解決できることと、それによって新しい使い方が生まれてくること、言語が普及するタイミングには、これらの要素が二人三脚のように関係している気がします。

あんどう: そうですね。技術者として新しい技術で遊ぶのも楽しいですが、どのように技術を利用するのか、最後は人に委ねられています。うまく使いたいものですね。

日高: 新しいユースケースを発見し、それを実現するために模索する。Wasmの将来性とともにエンジニアの仕事の醍醐味を感じました、本日はありがとうございました。

おすすめ記事

記事・ニュース一覧