WasmをRustにする

■ イベント
Rust、何もわからない… #15
https://estie.connpass.com/event/405217/

■登壇概要
タイトル：WasmをRustにする
登壇者：CTO 笹川 裕人

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Rust、何もわからない… #15 WasmをRustにする Sansan株式会社 CTO 笹川 裕⼈
2. 笹川 裕⼈（Sasakawa Hirohito） CTO - CSで博⼠の学位を取得 - 専⾨は正規表現照合のアルゴリズム 写真が入ります - アルゴリズムとデータ構造が好物 - 2023年4⽉より現職 - 2025年6⽉よりCTOに就任 - 新卒/中途全ての3次⾯接を担当。新しく⼊社する技 術系職種の⽅の技術レベルに責任を持っている - 技術全般と、美味しいご飯/お酒が好き - Rustは2020年頃から使⽤。CLIツールを作るのが好き
3. Key Takeaways - FFIをはじめ、⾃⾝のRuntimeから他のRuntimeを呼ぶことは、各処理系の いいところを活かす素晴らしい技術 - - ただし、⼀般に複雑な処理なので、別の問題を引き起こす事がある 呼び出される側のコードを、⾃⾝の処理系で動くNativeなコードに変換する アプローチがあるよ
4. bqvalidのケース
5. SQLのレビューはつらい (1/2) SQLのレビューは以下の理由で特に⼤変 - ある特定の処理に対して、書き⽅の⾃由度が⾼い - SQLの処理系による特性の違いが⼤きい - コードに現れない「テーブルの知識」が必要になる事がある
6. SQLのレビューはつらい (2/2)
7. SQLのレビューはつらい (2/2) _table_suffix の絞り込みに、サブク エリなど、実⾏時に動的に決まる値 を指定するとフルスキャンになって しまう
8. そうだLinterを作ろう Rust製BigQuery向けLinterツールを作成 - 先述の_table_suffixの⽐較をはじめ、現在7個ほどのルールを検出可能 - 当時Tree-sitterのBigQuery SQL向けの拡張を書いており、内部でそれを利⽤ - Tree-sitterはソースコードから抽象構⽂⽊ (AST) を得るためのparser
9. 込み⼊った静的解析の困難さ (1/2)
10. 込み⼊った静的解析の困難さ (1/2) 複雑なクエリを開発中に混⼊する ケースが多い。 BigQueryでは最適化で消えてしま うのでパフォーマンスには問題ない が、メンテナンス性に問題あり。
11. 込み⼊った静的解析の困難さ (2/2) 不具合の検出に、カラムやテーブルのlineageが必要になることがある - lineageとは、カラムやテーブルがどのテーブルに由来するものであるかを 特定する処理や、その情報⾃体を指す - SQLでは、CTE (With句) やサブクエリなどでカラムをrenameして別の箇所 で参照できるため、解析が⾮常に難しい - Tree-sitterでは限界があった
12. goccy/googlesql-wasmの利⽤ BigQueryのSQLのparserとしてGoogleが公式に出しているC++の巨⼤ライブラリ があるが、Compileに数⼗分かかるなど取り回しが悪い - C++のライブラリをWasmに変換して利⽤できるようにしたものが goccy/googlesql-wasm - Wasmは、RustからWasmtimeという処理系を介して利⽤できる
13. googlesql-rsを実装 goccy/googlesql-wasmをWasmtimeを介して呼び出し、⼊⼒されたSQLのAST を取得できるようにしたツール - bqvalidの内部で利⽤していたtree-sitterを置き換える形で利⽤ - 先述のCTE内部の不要カラムなどは簡潔に実装できるように
14. Wasmtimeの課題 googlesql-wasm + Wasmtimeを利⽤することで、先述の複雑なルールを簡潔に 記述することができたが、別の課題が発⽣した - Wasmtimeのバックエンドでは、並列化の⼯夫をいくつか適⽤しても、並列 数に対して2倍程度のスループットで頭打ちになってしまう現象 - Linterのユースケースでは、数百〜数千のSQLに対して処理することもある ため致命的
15. WasmをRustにしよう ⾊々な⼿段を実装したものの、劇的なスピードアップはなかったことと、実装し ていた時期に連休があったので悪い考えが去来しやすい状況だった WasmをRustにtranspileしたら、 compilerの最適化も効くし、runtime特有 の問題も考えなくていいのでは？？？
16. Transpiler完成 Wasmを等価なRustコードに変換するwasm2rsを実装 - 整数の演算などから徐々に複雑な処理に広げていきながら3⽇ほどで完成 - AIが無かったら数ヶ⽉〜年単位でかかり、そもそも実現できていない - 実装しながらWasmに関する知識もついて最⾼ - つまり連休は最⾼
17. ⽣成コードの問題点 wasm2rsでgooglesql-wasmを変換して⽣成されるコードにはいくつかの問題が - コード量が巨⼤ - - コードのネストが深すぎてコンパイラの上限（default 128段）に当たる - - コード変換時にピークメモリが⼤きくなってOOMする 上限は設定で変更できるものの... 後述の最適化してもまだ巨⼤（260万⾏, 122MB） - buildに30分くらいかかる
18. wasm2rsの改善 ネストのフラット化 - loop/ifなどのネストを単⼀のネストとmatchに変更する - どれだけ深いネストも1段のネストに収まるようになる - アームが増えるデメリットも
19. wasm2rsの改善 ネストのフラット化 - naiveにmatchに変換すると以下のようなコードが頻出する - 何もしないステップは取り除く - 単に後続ステップに進むだけのステップは融合してアームを減らす
20. ⽣成コードをCrateとして利⽤する場合の課題 Crateを構成するコードが巨⼤であると - crate.ioに登録できない （アーカイブサイズ上限10MB） - ユーザの体験が悪い - 「このcrateに依存すると途端にビルド時間が伸びるんだよな」
21. Cargoのfeaturesの利⽤ ユーザに対して性質の異なる選択肢を提供 - native: wasm2rsで⽣成したコードをそのまま利⽤する - - buildが重いが、⾼速に動作し安全（safe rust） native-ffi: wasm2rsで⽣成したコードをcdylibとして配布する - native相当の⾼速な動作を維持したまま、build済みdylibをダウンロードす るのみでbuildは軽い - wasmtime: WasmをWasmtimeで利⽤する - Wasmtimeの問題が許容できるなら問題ない選択肢
22. 結果 様々な最適化を頑張ったおかげで - 単⼀スレッドでWasm + Wasmtimeに⽐して1.5倍程度⾼速に - 並列化によって頭打ちしない性能を獲得 - - 並列化しない場合に⽐べ、4並列で3.6倍、8並列で7倍のスループット ⼤規模なcrateの体験の悪さはcdylibの配布で軽減
23. まとめ RustからWasmを利⽤する際に問題となるようなニッチなケースと、その対策と してNativeコードに変換するというアプローチを紹介した - WasmtimeはWasmをRustから扱う点で良い選択肢 - 並列性能などで問題になる場合にはwasm2rsの利⽤もぜひ
24. Sansan 技術本部 採⽤情報 https://media.sansan-engineering.com/