CDNとWasm、WasmになってるCRubyはそれ自体が素晴らしい。深掘りRubyKaigi 2024 文字起こしレポート vol.3

2024年6月20日に『深掘りRubyKaigi 2024 with kateinoigakukun & ledsun & remore』を開催しました。イベントの内容をほぼ全文文字起こし形式でお届けします。この記事は第3部です。

hey.connpass.com

イベントのアーカイブはYouTubeでも公開しています。

登場人物

ゲスト

kateinoigakukun/齋藤さん
ledsun/中島さん
remore/澤田さん

STORES

fujimura/藤村大介
mame/遠藤侑介

CDNとWasm

fujimura：ではremoreさんのパートに入ります。よろしくお願いします。また同じことを聞くんですけど、プログラミング、Ruby、Wasm歴や出会いを教えていただけたらと思います。

remore：プログラミングはいつなんだろう。でもledsunさんに似てて、やっぱり小さい頃MSXとか触ってました。中学校とか高校の頃はコンパイラが高くて買えなかったので、体験版のBorland CとかDelphiをインストールしてちょっとやってみる、みたいなことをしていました。大学になってバイトして買えるようになって、大学のバイトではシステム開発をしてたので、そこが多分本格的な始まりです。

はじめに入った会社はWebの開発も組み込みの開発もやっていて、いろんな言語を触らせてもらいました。本格的にWebに入ったのは2011年で、ソーシャルゲームの開発に携わったのが初めてでした。PHPの開発現場だったんですが、より良い開発をしようとするとすごい引力でRubyにすわれていって、テストもちゃんと書こうという流れになりました。2014年には趣味で作ったゲームの開発チームで発表もさせてもらいました。そんなふうに過ごしています。

fujimura：Wasmはいつ頃からですか？

remore：Wasmは去年、1年ぐらい前からですね。今の仕事でちょうどWebAssemblyを使って、エッジでWebAssemblyのプログラムを動かすことをお手伝いするような仕事なので、それが初めて本格的に使ったきっかけです。それまではプライベートでも仕事でも、Wasmを動かすことはほとんどなくて、動くんだぐらいの感覚でビルドはしても、真剣にはやっていませんでした。

fujimura：ありがとうございます。それでは改めて、発表の概要をざっくりと教えていただけないでしょうか。

remore：2022年のkateiさんの発表でruby.wasmができたんだ、イェーイってなったときに、kateiさんがWasmもブラウザでも動くし、ブラウザの外でもWASIでも動くぜって取り上げてくれたんです。WASIでも動くぜって部分が、Fastlyのインフラを使ってエッジでデプロイして、Hello Worldレベルでサクッと動くっていうのを見て、すごいじゃんって。仕事としてはRubyはサポートされていない言語で、Rust、Go、JavaScriptがサポートされていて、日中はそっちを触っているんですね。プライベートの時間でゆっくりパソコンを開いたときはRubyを触っていて、kateiさんもやってたし、試してみようかなと。それがきっかけで、Rubyのプログラムをエッジで動かせるなら、僕のブログのアプリも動かせるかを試してみましたという内容です。

rubykaigi.org

fujimura：ありがとうございます。2022年のkateiさんの発表からruby.wasmの輪が広がってますね。素人質問コーナーとして、エッジコンピューティングについて聞いてみようと思います。CDNを使ったことがある方も多いと思いますが、CDNのエッジで計算をするって何が嬉しいんでしょうか？

remore：謎ですよね。僕も仕事を始める前まで謎だと思ってました。エッジでWebAssemblyでプログラムを書けるのが謎でした。質問のポイントとしてはどのあたりをお話しすればいいですか？

fujimura：エッジコンピューティングの何が嬉しいんでしょうか？

remore：ありきたりなことを言うと、エッジなのでユーザーに一番近いところで動くっていうのが簡単なお話なんですね。例えば普通にプログラムを書いて、AmazonやGoogleのコンソールを開いて「デプロイするぞ」とやるときに、普通のIaaSなどのサービスを使うと、ビルドしてデプロイするときにメモリの使用量やディスク容量を指定して、リージョンも東京やアメリカなどと指定するじゃないですか。これは一般的な開発のデプロイのフローだと思います。そこを設計したり戦略をたてることも過程としてあると思うんですけど、エッジでやるときにすごく便利だなと思ったのは、ビルドしてデプロイするときにリージョンの指定もリソースの指定もせずにデプロイできる。ホスティングサービスによるとは思いますが、例えばFastlyだと、全世界に約100カ所のホップがあり、デプロイした瞬間から全世界のホップで自動的に動くんです。細かいことを気にしなくて済むのと、リクエストがたくさんきても捌けるのか心配しなくていい。僕が発表したSinatraのアプリでは、前段にNginxのリバースプロキシを置いてチューニングして、負荷テストをかけてとか（昔は）やってたんですね。ブログなのでそんなにアクセスくることないんですけど、心配性なんでやってたんですよ。そういったことをやらなくていいんだってところが便利だなと思います。

fujimura：本当に気にしなくていいことが何個か増えるっていうのがすごい体験だなって思ってました。これは僕の趣味みたいな質問ですが、お答えできる範囲で大丈夫なんですが、CDNのエッジには何が置いてあるんだろう。

remore：謎ですよね。公開されている情報だけで話しますが、例えばFastlyの場合、まずH2Oというウェブサーバがあって、ウェブの接続や処理を行っています。その後ろにVarnishというキャッシュサーバが元々いたんですよね。そこをよりよいバージョンというか、もっと色んなことができるものとしてWebAssemblyがでてきた。なので、（流れを整理すると）H2Oでリクエストを受けた後、その処理がVarnishにいくのは既存のサービスだし、最近出てきてるのは（Varnishではなく）そこをWasmtimeというWebAssemblyのランタイムを積んだプロセスが動いてて、（エッジコンピューティングの場合は）そこで処理されるようになっています。そこで動かしているのは、一般的なサーバで動いているという感じです。

fujimura：異常テクノロジーが使われているわけではなく、普通の技術で動いているということですね。

remore：そうですね、変なコンピュータが動いてるとかってことはなくて。細かいところは公開されてなかったりするし、ネットワークとかいろいろあると思うんですよね。ただ大まかに言うとそういう流れで動いてます。

fujimura：ありがとうございます。早速ですが、エッジコンピューティングでruby.wasmを使ってみての要望や感想があれば聞きたいです。

remore：Kaigi中にkateiさんに話させてもらって、パフォーマンスを上げたいという話をしました。ledsunさんのお話とは対照的で、ledsunさんはパッケージのサイズ、バイナリのサイズに関心があると思うんですね。WASIやエッジで動かす場合、サイズも小さいと嬉しいけど、どちらかというと実行速度。エッジコンピューティングって近くで動かすので早く動かしたい。スライドの最後の方で発表したんですが、Rackのアプリをエッジで動かそうとすると、レスポンスタイムが1秒かかることがあり、きついなと感じました。

fujimura：kateiさん、どうですか？

kateinoigakukun：どこがボトルネックなんですか？インタープリタの起動が遅い、Rack周辺のRubyコードの読み込みが遅い、リクエストのハンドリングが遅いのか、どれでしょうか？

remore：多分インタープリタの起動が遅いのか、Rubyコードの読み込みが遅いのかですが、宿題でissueで送りますね。ちゃんと精査してないので。

kateinoigakukun：前段であれば、スナップショットの技術で解決できると思います。JavaScriptのエッジでの実行はスナップショットの仕組みを利用してだいぶ速くなっているので、同じようにできるはずだと考えています。

fujimura：ホカホカになった状態のRackアプリを送ることができればいいですね。

エッジでRails、エッジのデータベース

fujimura：これも素朴な質問なんですが、エッジでRubyを動かせるようになると、可能性が広がる部分もあるし、エッジ故の制約もあります。どんなことができると嬉しいか、想像、妄想や野望があれば聞きたいです。

remore：gemがたくさん使えると嬉しいなと思っていて、kateiさんがC拡張がプリインストールの形で動かせると話してくれたので、それがsoonとKaigiではお話されていた。実現できると非常に嬉しいです。

kateinoigakukun：soonと言ってた頃は1ヶ月くらいで動かせると思っていたんですけど、大学のほうで立て込んでしまってできてないんですけど、もうちょっとです。今日も周辺ツールを1個直して一歩進んでるんで、しばしお待ちください。

remore：ありがとうございます。

fujimura：素朴な疑問なんですが、FastlyでRailsが動くってことは起きるんでしょうか？

remore：できてほしいですよね。僕の夢ですね。

kateinoigakukun：Railsなんですか？Railsって基本的に長く起動するプロセスじゃないですか。それに対してエッジで動かすものって、1リクエストごとに新しいプロセスを立てる。と思うと、Railsより短命なプロセスに特化したものがあるんじゃないかなと思っていて。今のRailsで表現できるものなのかなと思っています。Railsをちゃんと書いたことがないのでわからないんですけど。

remore：すごく面白いポイントだと思っていて、おっしゃる通りだと思うんです。Railsは起動に時間がかかって、そういうモデルで動かすので、それがエッジに本当に合うのかということだと思うんです。妥当な指摘で、おっしゃる通りだと思いました。

そういうことをするなら短命のプロセスに特化したフレームワークがあったほうがいいし、それは一つ欲しいなと思いました。でもこれは僕の個人的な欲望なんですけど、mameさんがWasmを考えるときに、コンテナの歴史とかも含めていろいろおっしゃっていたところに共感できるところがあって、今後WebAssemblyがコンテナを置き換えるのかどうかという文脈で、僕的には補完してほしいなと思っています。置き換えるのではなく、共存して補完してほしい。

僕はユーザーとしてコンテナを使っていた立場や、企業のコンテナを使いやすくするためにk8sクラスタ導入を手伝う立場もやってました。いろんな会社で見たときに、コンテナはさまざまな使われ方をしています。うまく使われているところもあれば、例えば開発者がいなくなって塩漬けのために使うといった動機で使われることもあるんですよね。不幸なケースもあって、自由には責任が伴うんですね。コンテナはルート権限も含めて大きな裁量があって、大きな責任が伴うものがないがしろにできる技術的な状況がある。

それに対して、WebAssemblyはセキュアに不要なインターフェースを制約できるので、うまくそういう問題が起こる場所でWebAssemblyを利用してやっていこうみたいな、ハッピーな未来があると個人的には嬉しいなと思っています。Railsがエッジで動くことについては、エッジかどうかは別にして、WASIでうまく動いてほしいし、人によってはWASIの利用先がエッジであっても良いという世界観があってほしいなと思っています。

fujimura：エッジで動くならではのRubyのWebのフレームワークがもしかしたらあるかもしれないっていう想像をする一方で、でも起動が早い、ホカホカになったRailsをまけるんだったら、もう全部Railsでいいやってなりそうな気もします。

kateinoigakukun：そうですよね、そのまま動かしたいですよね。

mame：そもそもなんですけど、Railsって今まで起動速度を数ミリ秒でやってほしいっていう需要がそこまで大きくなかったから、その辺に最適化されてないけど、Railsアプリの書き方として起動が遅くなるような制約を負ってますかね？つまりRailsの設計そのものが悪いんですかね？それはあんまりよく知らなくて、原理的に遅くなるようなところってあります？初期化や起動時とか。

fujimura：どうだろうな。

kateinoigakukun：どうなんですか？

mame：フレームワークが悪いわけじゃないんじゃないかなと思ったんです。別にわからないですけど、基本的にやることはルーティング、どこのパスにアクセスしてきたらどのように動かすかっていう対応を書いて、その対応するコードを書くっていうところは、何で書いても同じなのかなと思ってて。あとはそれのマッチングをできるだけ早くするっていうぐらいなのかなと思って。それがRailsが特に不利になっているところがあるのかっていうと、ちょっとよく分からなかったです。

fujimura：荷物が多いというか、本当のSinatraだと少ないライブラリしか積んでないけど、Railsはやっぱりたくさんあるんで、その分、工夫がたくさんされているけども物理的に遅いみたいなのはあると思う。

kateinoigakukun：ZeitwerkがEagerロードしないと温まった状態にならないんですね。そういう細々したところがありそうな予感がします。

mame：エッジコンピューティングについての素人質問してもいいですか？

remore：どうぞ。

mame：エッジコンピューティングってデータベースはどうしてるんですか？

remore：それはいい質問ですね。結論から言うと、いろんな会社が試みているんですけど、多分最終的にこれだねって答えはまだないんですよね。結局、データって読むより書くほうが難しいというか、特に分散環境になっちゃうと書き込みの時の排他制御どうするのとか問題が当然出るじゃないですか。アグレッシブに頑張っている、分散したロケーションで書き込みも発生させようってやってる会社さんもいるんですけど、大きく見た時に業界全体としてはまだ最終的にこれだねっていう解決策はないんですよね。

なので、書き込みは奥の方にあるクラウドの1箇所でやろうって感じで、主に読み込みを中心にやろうみたいにしてるとか、そもそもデータをそんなに必要としないような処理で使うとか、そういう傾向が多いかなって気がします。

mame：じゃあ、世界に単一のデータベースがどこかに用意されていて、エッジはそこからフェッチして応答するって感じになってますか？

remore：そういうモデルもありますし、エッジならではなんですけど、キャッシュ機能が強力なんですよ。とにかくキャッシュさせるのが上手なんですね。だから、SQL投げるみたいなやつも結果を余裕でキャッシュできちゃうんですね。結局、分散してるんでキャッシュさせちゃえば、分散が効いてreadを何回も読みに行かないで済む。結局、極小的なキャッシュでreadについてはOKで、中央でwriteが発生したときにパージ、つまりキャッシュを削除させにいく機構がすでにある感じです。

mame：writeしたら全世界にパージがいく。

remore：宣伝する意味じゃないんですけど、例えばFastlyのKVストアとかだと、それが勝手にできるんですよ。多分、各社さんもやってると思うんですけど。

mame：それって普通のデータベースなんですか？つまり、Active Recordとかでそのままいけるような？

remore：いや、違いますね。Fastlyの場合もそうだし、一般的にエッジの業界でのKVストアは普通のデータベースじゃなくて、本当にキーバリューストアなので、問い合わせ言語としてSQLは使えないですね。

mame：多分、野生のRailsアプリケーションをエッジで動かそうとした上で一番大変なのはそこかなというふうに想像しました。Active Recordがそのまま動かないっていうのはちょっと大変そうですかね。

remore：やるとしたら、SQLiteとかのファイル系のデータベースをキャッシュに持たせて、読み込みはそれでまかなって、書き込みが発生したら中央の方で新しく書き込んだSQLiteのファイルを各キャッシュに持っていくみたいなことは技術的にはできると思います。それをやりたいかどうかは別として。

mame：RubyKaigiで発表されていたSinatraのアプリのブログですが、あれはデータベースを使っていないんですか？

remore：あれはコンテンツ自体をマークダウンで書いて、ファイルをVFS（Virtural File System）に入れちゃってます。データベースレスでやっています。

mame：なるほどなるほど。わかりました。

fujimura：データベース業界が頑張って、これからエッジ対応のものをどんどん出してくると思いますね。

remore：面白い領域だなと思ってます。

mame：エッジでRailsアプリを丸ごと動かすアプローチと、エッジで動かすのに特化したキラーアプリ、こういうRailsアプリだったら動かしやすいみたいなのがあるのかなと思って。今の話を聞いて、データベースにアクセスしないアプリがいいのかなと思ったんですが、そんなアプリはあんまりないか。

remore：そうなんですよね。データベースアクセスをするアプリだとすると、読み込みが多い系のアプリがエッジに向いているかもしれません。

mame：書き込みが発生すると全世界にパージが飛んで面白いことになってしまうので、なるほど。今回、Fastlyでアプリケーションを動かすために、kateiさんが元々ResponseBodyのとこだけAPI(C拡張)を書いてくれていた？

kateinoigakukun：はい、超基本的なことしかやっていなかったので。

mame：そこからリクエストを処理するAPIとかFastlyが提供しているAPIをRubyから使えるようにしたと思うんですが、その部分はカバレッジ100%に近いですか？

remore：全然。2、3割かな。全然使えてないですね。今お話ししたキーバリューストアのアクセスAPIがあるんですけど、まだ書けてないのでやれることがたくさんありますね。

mame：その辺って何か機械可読の形でAPIの仕様というか、API一覧があったりするんですか？

remore：はい、公開されてるものがあって、Fastlyのこのホストコールはこれですよっていうwitxっていう定義ファイルで定義されてるんですけど、そこを見れば、この関数の名前でこの引数で送ってくれれば動くと書いています。

mame：WITX、Wasmのですね。

remore：ただそのファイルがあるだけで、解説が一切ないので気合が必要です。

mame：そっか、WITXからRubyの薄いラッパーを自動生成することってありえるんですかね？

kateinoigakukun：ありえるんですよ。で、WITXは終わってしまったので、新しいコンポーネントモデルで使われているWITからRuby用のC拡張を自動的に作って、Ruby向けのインターフェースを自動生成するのは理論的にはできるんですけど、手が回ってないので誰かやりませんか？

mame：パースができる機械可読のAPI仕様があるので、そこからRubyのC拡張に変換するところ。

kateinoigakukun：そうですね、現状だとそれが一番シンプルですね。

mame：っていうのを作って、コンポーネントモデルで今C拡張ライブラリが読めるようになりかけているので、それで読めば一気に全部いける。

fujimura：それができるとでもエッジコンピューティングへのアダプションは進むかな。どうだろう、速度の問題がまだあるのか。

remore：ちょっと楽になって嬉しいっていうか、敷居が少し下がるかなって感じですかね。

fujimura：そういう意味で言うとやっぱり最大のボトルネックは速度なんですかね。

remore：ユーザーとして見たときは速度とほぼイコールなんですけど、CPU使用量かな。エッジってすごいたくさんのリクエストを極めて短い時間で捌くために設計されているので、CPUもこれくらいに抑えてねという指標が各プラットフォームから出されるんですよね。Fastlyももちろんあるし、他の会社もあると思うんですけど、そこに収めるには結構ダイエットしないと厳しいなっていう感じですね。

mame：大体どのくらいのスケールなんですか、数秒とか。

remore：msecレベルなんですけど、指標として出てるのはもう数十msecのレベルのオーダーなんですよね。

mame：ブログにアクセスするのに、1秒ぐらいしかかからないですよね。待ってくれるんですか？

remore：待ちます、はい。開発的な用途であれば動くんですけど。ただ本格的にそれをプロダクションで動かしちゃうと、使われすぎちゃうと、何かしらちょっと対応が必要だねっていう連絡が来るとか、そういうのはあり得ると思うんですね。

mame：Fastlyのエッジにいくつか種類あるんですかね？本格的にすごく早く返答しなきゃいけない大規模モードと開発用モードみたいな。

remore：アカウントの種類が開発用アカウントと、あとは商用アカウントと呼ばれてる2種類あるっていうだけですかね。

mame：ブログで利用されたのは開発用のアカウントの方？

remore：はい、そうです。

mame：じゃあプロダクションレディじゃないじゃないですか。

remore：実験的にやったっていう感じですね。

mame：数ミリ秒で頑張らないといけない？

remore：(CPU使用量は)数十ですね。

mame：数十ミリ秒。100倍頑張らないといけない。

remore：50msecぐらいが基準だねって言われて、そこが目指すターゲットなんですよね。で、RustやGo、そういう言語を使うと全然そこは達成できる。JSでもそこをクリアしてたりはするので、JSみたいなインタープリタがあってもってことですよ。なのでできないことじゃないはず。

kateinoigakukun：と思います。

fujimura：素のRailsって10msecぐらいかかってると思ってて、それでハードルはありますよね。

kateinoigakukun：そうですね。難しいな。そこからWasmに落とすだけで、5倍くらいを見積もると、それで結構パツパツですよね。

remore：たまたま僕がエッジでやったからエッジの話をしてもらってますけど、エッジってエクストリームな例だと思ってるんですよ。なのでそんなに焦る必要もなくて、まずはゆったりバックエンドでWASIで使うっていうのも価値が高いと思ってて。さっき言ったように僕の欲望って、悲しい塩漬けコンテナとか仮想イメージを減らしたいっていうところで言うと、WasmになってるCRubyってそれ自体がもう素晴らしいんですね。 10年後もWasmのランタイムがあれば動くことが保証されてるじゃないですか。それも僕は見てていいなと思うので、そういう観点で、バックエンドで使ってみてもいいんじゃないかなと思ったりします。

fujimura：はい、エッジではないWasmで動いている例ですって言うのは、それはそれで新しいトピックで、しかも可能性はかなりありそうですね。

remore：可能性ありますよね。kateiさんの話でも、gemを含めて動くし、ビルドしてもエラーが出たら潰せばいいだけだしっておっしゃってたんで、大丈夫だと思います。

kateinoigakukun：やるだけですね。

fujimura：いいな。誰が一番最初にそれでRailsを動かすのかっていう日本のRailsスタートアップのバトルが始まったわけですね。

kateinoigakukun：よーいどん。

fujimura：そうですね。では質問に答えます。

wasmtimeにserveサブコマンドがある(HTTPサーバーが起動できる)ことを最近知ったのですが、ローカル環境でHTTPを受け付けられるruby.wasmワンバイナリといったものも作れたりしますでしょうか？

remore：はい、Wasmtimeの方はkateiさんにお話を譲りたいというか、僕はserveコマンドを知らなかったんですけど、Fastlyにはそういう開発環境があるんですね。Fastlyが単体で動かせるViceroyっていうソフトウェアを使えば、Fastlyのホストコールに対応したWasmはもちろん動かせるんですけど。kateiさんに聞きたいな。

kateinoigakukun：Wasmtimeのserveコマンドについては、WASI Preview 2っていう新しいブリーディングエッジなABIに依存した話で、現状はCRubyのWASIの対応としては基本的にはPreview 1に依存していて、Preview 2のものは直接は呼び出せない。 Preview 2にするっていうことはどういうことかというと、コンポーネントモデルに対応するっていうのとほぼ同義なんですね。なのでPreview 2にまず対応するにはCRubyをコンポーネントモデルに対応させることが前提になっていて、それがもうちょっとでgem対応と一緒にいい感じになる。その先でWASI Preview 2に固有のHTTPのリクエストをRubyのAPIに対応させていくことで、serveコマンドとかも自然に使えるようになるはずです。

fujimura：ありがとうございます。

mame：Ruby側のインターフェースってどうなるんですか？リクエストがあったらRubyのメソッドが呼ばれたりする？それとも毎回実行されるんですか？serveコマンドでアクセスがあるたびにRubyのスクリプトは先頭から実行されるんですか？

kateinoigakukun：どうするのがいいのかな。

mame：普通だったらどうするんですか？他のWasm、Rustとかで書く場合には。

kateinoigakukun：コンセプトとしては、Wasm上のエクスポートされた関数として表現されるんですね。Wasm上のエクスポートされた関数がリクエストごとに1個起動するのか、ちゃんと覚えてないんですけど、そこから呼ばれると。それをどうRubyにマップするのがいいんですかね。

mame：ruby.wasmがエクスポートしないといけないんじゃないですか？

kateinoigakukun：そうです。

mame：ruby.wasmが、素のruby.wasmがエクスポートするんですかね？

kateinoigakukun：コアのインタープリタがエクスポートする必要はなくて、拡張ライブラリが、CRubyのビルドとは今回Dynamic Linkで独立してビルドして、それを後からくっつけることができるようになったので、そういうWASI Preview 2のHTTPリクエストハンドラーのインターフェースをエクスポートした拡張ライブラリを後からくっつけるっていう感じになるのかな。

mame：なるほど、それをやったら、どこかのRubyメソッドを呼ぶっていう規約を作らなきゃいけないって感じですかね。

kateinoigakukun：そうですね、ブロックを登録する何かが必要。

mame：それはRackのインターフェースに合わせるといいんですかね。

kateinoigakukun：そう思います。

mame：面白そう。

RubyKaigi 2024の配信を楽しみにしている

fujimura：他の発表及びRubyKaigi、Wasm関連、Wasmとは関係ないところへの感想とか意見があったらお伺いしたいです。

remore：Kaigi中で全部のトークを見れなかったので、配信を楽しみにしています。例えば、mrubyのWasmのトークは僕ちょっと被ってて見れなかったので、そういうのを楽しみにしています。

fujimura：mrubyのWasmのトークもここに近藤さん来てもらえたらよかったかなと思ったんですけど、さすがにちょっとボリューム的に難しいってのがあって、泣く泣く諦めたという事情がありました。

kateinoigakukun：CRubyは中ぐらいのアプリケーションを中ぐらいのボリュームでお手軽に作るっていうところなんですけど、mrubyがちゃんとWasmをサポートできるようになれば、小さいプログラムを本当に小さく作ることができるようになるので必要なピースではある。

fujimura：カバレッジがあっていいですよね。

kateinoigakukun：楽しみ。

fujimura：楽しみですね。もう終盤なんですけど、part 3を終わろうと思います。ありがとうございました。

質疑応答コーナー

fujimura：質疑応答コーナーをやります。ウェビナーのチャットでもXのタイムラインでも、ご質問いただければと思います。遠藤さんから聞き逃してるところとかがあれば、および御三方から質問があれば。

ledsun：ひとついいですか。WASIでスリープって動かせるんですか？

kateinoigakukun：大変良い質問ですね。どういうスリープかによるんですけど、今、WASI libcが提供しているスリープはビジーループで待つスリープなんですね。本当に欲しいスリープって、どういうスリープなんですかね？

mame：CPUを解放してくれるスリープでしょう。

kateinoigakukun：そうですよね。CPUのコントロールを開け渡す口っていうのは現状ないので厳しいですね。

mame：WASIでそういう挙動にすることってのは規定されてるんですか？ビジーループで待てっていうAPIをWASIが規定している？単にJavaScriptのランタイムの制約でそれができないからビジーループとしてダミー実装が与えられているぐらいなのかと思ったんですけど。

kateinoigakukun：WASIはそこについては何も規定していなくて、一応ポールする口はあるんですね。本当にやりたかったら、ポールはCPUのコントロールを開け渡してホスト側にコントロールを渡すので、それでスリープっぽいことはイベントループ的な書き方をすればできるんですよ。本物のスリープみたいなのはWASIは何も書いていなくて、WASI libcが勝手にユーザーランドでできることとしてビジーループで実装している。

mame：WASI libcでpollはどう実現されるものなんですか？

kateinoigakukun：あんまり詳しくないです。

mame：pollってファイルディスクリプター、IOの読み込みマッチとかのやつですね。

kateinoigakukun：そうですね。

mame：Asyncifyを使う前提じゃなくても待てるものなのか。

kateinoigakukun：コントロールを渡す、本物のpollみたいな。イベントループ的な書き方をしないといけないポールですね。

mame：コールバックを待つ形の？

kateinoigakukun：そうですね。

mame：pollを設定した後、どうやってそのイベントが来るまでスリープするんですかね？わからない。

kateinoigakukun：そういうパラメータがあったような、なかったような。ポール周りはVFSに実装してないからあんまり詳しくないんですよね。それ以外は実装したんですけど。

mame：VFSを自分で実装したから知ってるってのはすごいな。

fujimura：御三方に聞こうと思って忘れていました。仲間募集というか、こういうのを誰かやってほしいみたいなのがあったら聞きたいです。

kateinoigakukun：めちゃくちゃいっぱいあるんですけど、手が足りてなくてできてないことがいっぱいあります。さっき言ったコンポーネントモデル上のWITっていうIDLからRuby用のC拡張のコードを自動生成するBinding Generator、wit-bindgenっていうのが、いろんな言語用にあって、CやRustはサポートしてるんですけど、そこにRubyのサポートを入れたいです。

それができると、例えばプラグインを提供するような環境、それこそFastlyとかもそういうインターフェースを定義してるんで、そういうところでいちいちグルーコードを自分で手書きしなくても、プラットフォームといい感じに通信できるようになってうれしいっていうので、誰かやってくれないかな。

fujimura：remoreさんもお手伝い募集ありますか？

remore：WebAssembly全般なんですけど、僕としてはRubyがWebAssemblyでも書けるとよりうれしいので、ruby.wasmもそうだし、日々使うのでいうと、Wasmtimeとか、そういう下回りのツールもオープンソースで書かれています。どこの領域もこれから良くなっていくところで面白そうです。最適化ももちろん面白いし、JITの話もたくさん出ていますが、AOTの話もあると思うし、面白いことがいっぱいなので、興味がありそうな角度があれば見てみるといいんじゃないかなと思います。

ledsun：僕はRuby in the browserのアプリケーションを教えてもらいたいです。作って教えてもらえるのが一番いいですね。自分で書いてもネタが切れてて、どういうユースケースがあるかわからないので、誰かが書いたものを見て、こういう関数があると便利そうだなとわかるといいなと思ってます。

kateinoigakukun：それで思い出したんですけど、ruby.wasmのリポジトリにWikiがあって、そこにShowcaseっていうページがあります。そこはみなさんご自由に書き込めるので、自慢したいruby.wasmのユースケースがあれば書き込んでいただけると、アプリケーションのユースケースも集まって嬉しいので、よろしくお願いします。

github.com

fujimura：ありがとうございます。僕はruby.wasmをブラウザで動かすっていう面だと、やらないでいいんですけど、prototype.jsをRubyで書いたらどうなるかなってやってみたいですね。昔JavaScriptの人がRubyを真似て作ったやつを逆にRubyで書いたらどうなるかな、ギャグですけど。

mame：細かい質問になるんですけど、せっかくなので聞いちゃいます。Wasmtimeで普段開発されてるって言ってました？

remore：そうですね、Wasmtimeを使った会社の環境なので、厳密にはWasmtimeコマンドじゃないかな。Wasmtimeコマンドは、たまに使うぐらいですね。

mame：エッジコンピューティングでデプロイして、Wasmtimeの上で何か動くものを書いてる？

remore：そうですね。

mame：コマンドラインツールとしてWASIを使うっていうアプローチもあるのかなって思ってて。それにしてはWASIのインターフェースがいろいろ足りないものが多すぎて辛いなってのもあるんですけど、そういう未来もそのうち来るのかな、そういう開発をされてるのかなってちょっと聞いてみました。

remore：来てほしいですよね。Wasmtimeがローカルの環境に入ってる方は非常に少ないと思うんですけど、入ってるとすごい便利なはずなので、そういう世界が来てほしいなと思います。

mame：ゲームの配布をWasmでやる世界が来てほしいなって。

remore：僕も思いますね。

mame：最初、kateiさんがruby.wasmやりたいって話の時にポータブルなバイナリっていうふうに言ってましたもんね。いろんな環境でそのまま動くバイナリフォーマットを使っているものはWasmだってことでやったので、まだなかなかその世界にはなっていないですね。

kateinoigakukun：だいぶ遠い。

mame：Wasmtimeが当たり前にどの環境にも入って、かつWASIにもっとシステムのインターフェースがいっぱい増えて各環境でできることが増えていけばいいなって感じですね。プロセス起動もできないですもんね。

remore：そうですね。風呂敷を広げる意図ではないんですけど、やっぱりコンポーネントモデルがちゃんと出てきて、そのコンポーネントモデルで作った成果物が簡単に再利用できるみたいな、Dockerの世界でいうと$ docker pull (コマンド)とかのイメージですね。コンポーネントをすぐ持ってきてそれを使って開発するみたいなワークフローが組めるようになってくると、いよいよそういう開発が進むっていう夢が僕の中では広がっています。

mame：面白そうですね。

fujimura：これは誇大妄想かもしれないですけど、実行ファイルを配る世界に戻るのかみたいなことを想像したりもしますね。

kateinoigakukun：そうなんですよ、Wasmはプログラムの交換形式なんですよ。安全にサードパーティのプログラムを実行できるっていうのは面白い特徴なんで、いろんな使い方がこれから出てきてほしいですね。

fujimura：コンポーザブルな商用ソフトウェアみたいな世界もできるかもしれないですもんね。最後に渋そうな質問がきました。

WASIの仕様策定が遅い的な噂も聞きましたがどうなんですかね……

kateinoigakukun：仕様策定って一般的に急いでやるものじゃなく、慎重にやるものですよね、っていうのがまず前提としてあって、仕様策定したら実装しないといけないんですよ。現状のWASIをやっているBytecode AllianceがWASIの仕様策定をしているんですけど、最近はWASIの口をたくさん増やすところは一旦やめて、コンポーネントモデルの根本的な仕組みを改善して、それによって将来の口を増やしやすくすることを今やっている段階です。新しいAPIがなかなか増えないっていう面では仕様策定が遅く見える部分はあるんですけど、それは将来の速度を上げるための布石なので、しばしお待ちくださいって感じですね。

fujimura：ありがとうございます。Wasmの未来にみんな胸が膨らんできたところなんですが、ちょうど時間を過ぎたところなので、深堀りRubyKaigi 2024を終わろうと思います。今日は本当にありがとうございました。みなさんご視聴ありがとうございました。（完）