たのしい(※個人差あり)！ RustバックエンドのPythonライブラリ開発

2025/09/12 Python Meetup Fukuoka #4
https://lycorptech-fukuoka.connpass.com/event/365202/

Transcript

1. たのしい(※個人差あり) ！
 Rustバックエンドの
 Pythonライブラリ開発 LINEヤフー株式会社 データサイエンス統括本部 夜久真也
2. 本日お話すること PyO3/MaturinでRustと統合された Pythonデータサイエンスライブラリ(ベイズ統計モデリング)を
 個人開発してみた体験談についてお話しします。 PythonとRustを併用するモチベーションやメリットデメリット、 実際に使ってみた所感などをお伝えします。 Rustは高速なことで有名ですが、 そもそものプログラミング言語としての思想が大きく異なるため、 速度を求める場合でなくてもRustを使うと幸せになれる… ことがあるかもしれません。 本発表は、コードの書き味やプログラミングパラダイムの好みなどの 主観的かつ個人差が大きい内容を多く含みますので、あらかじめご了承ください (でも、プログラミングってそういう主観も大事ですよね)
3. 目次 自己紹介 PythonとRustを統合したライブラリを作ろうとした背景 PyO3とMaturinの基礎知識 実際に開発してみて起こったこと 開発した所感 まとめ
4. 自己紹介: 夜久真也 (Yaku Shinya) 趣味 クラフトビール (主に Hazy IPA) 福岡で飲んだことのあるものの一部→ 経歴 兵庫県出身、東京在住、福岡はなんだかんだで10回目ぐらい 2013年 東京大学 工学部 計数工学科 システム情報工学コース 卒業 2015年 東京大学大学院 情報理工学系研究科 システム情報学専攻 修了 2015年 ヤフー株式会社 入社 (現職、2023年10月よりLINEヤフー株式会社) LINEヤフーでの業務歴 2015~2021: ビッグデータ・機械学習エンジニア サジェスト ・関連検索ワー ド・一 発回 答意図解釈 etc. Ya hoo!検索 etc. 2021~現在: データサイエンティスト プロダクト や人事施策の 効果検証・分析アル ゴリズム 開発 etc. LINE 公式 アカウント、PayPay ギフト (Ya hoo!セールス プロモーシ ョン) 、
 Ya hoo!しごと カタログ etc. #Py th on Fuku ok a @sh 1n _89
5. 目次 自己紹介 PyO3とMaturinの基礎知識 実際に開発してみて起こったこと 開発した所感 まとめ PythonとRustを統合したライブラリを作ろうとした背景
6. 私の主な言語経験 ~2015 MATLAB (学生時代) 行列計算・数値計算が得意なスクリプト言語。脳波や音楽信号の信号処理を書いていた。
 コーディングのベストプラクティスを学ぶ機会があまりなく、当時はあまりコーディングは好きではなかった… 2015~ Python (ヤフー入社時~データサイエンティスト) データサイエンス系の部署に配属され、OJTから書き始めた。当時は2系から3系の過渡期。 すっきりしたコードがなかなか書けず、書き始め当時はやはりあまりコーディングは好きではなかった… 現在もデータサイエンティストとしての分析・アルゴリズム実装をする際は、実質的にPython一択。 2015~2021 Scala (ビッグデータエンジニア時代) Apache Sparkによるビッグデータ処理アプリケーションを書きはじめた。 静的型付けや型推論・関数型、オブジェクト指向などを覚え、コーディングが少し好きになった!! 今でも書き味は結構好きなのだが、JVM (Java Virtual Machine) への依存が面倒なため、最近は離れている… 2024~ Rust (趣味と実益) 中規模以上のアプリケーションをPythonで実装することにつらみを感じており、助けを求めた結果たどり着いた。 所有権を理解できると、Rustアプリケーションのみならず、多言語のコーディングでも考えが応用できてたのしい!!(当社比) 静的型付け・型推論・関数型プログラミングなどが好きです！ (おや…？ )
7. RustをバックエンドにしたPythonライブラリ開発の背景 ベイズ統計モデリングのライブラリを開発したくなった 副業で、とあるドメインのデータに対するベイズモデリングを行っている 入力データ形式はある程度決まっており、継続して様々なデータを分析している なので、共通処理をライブラリ化して、汎用的に分析作業を行えるようにしようとした (※OSSではなくプライベートPJ) しかし、Pythonだと、つらい、かも… 以前もデータサイエンス系ライブラリを作ったことがあるが、個人的に苦しいことがあった(詳しくは次のスライド) https://pola.rs そういえば、PythonからRustを呼び出せるのでは？？ 普段から よく使っている Polars では
 「Rust がバックエンドのため高速高効率!!」ということが有名 じゃあ、自分でもRustをバックエンドにした
 Pythonライブラリが開発できるのでは？？
8. 個人的PythonのつらみをRustに解決してもらう 個人的Pythonのつらみの例 Rustだと… 動的型付け
 (Type Hintはあるが…) (そもそもライブラリによってはないことも…) 静的型付け オブジェクトを更新すると参照先にも意図せず影響することが
 (Pandasあるある：DataFrameはcopyしないで再利用すると、
 参照先の改変が元のDataFrameに影響してしまう…) 所有権により、意図しないオブジェクト更新が起こりうる
 プログラムはコンパイルできない 速度やメモリ効率がどうしても悪くなったり、
 悪い原因がわかりにくかったりする
 (どこでデータコピーが起こってるのかがわかりにくい…) 適切に書けばパフォーマンスは高くなる もしデータコピーなどの遅くなる処理を書く場合は、
 明示的にそう書かれるので速度のボトルネックが特定しやすい Pythonプログラムは
 粘土のように柔らかい
 (※個人的イメージ) Rustプログラムは
 鉄骨の建物のように かっちりしている
 (※個人的イメージ)
9. 目次 自己紹介 PythonとRustを統合したライブラリを作ろうとした背景 実際に開発してみて起こったこと 開発した所感 まとめ PyO3とMaturinの基礎知識
10. PyO3 / Maturin によって Python から Rust を叩く Maturin: Python/Rust連携ビルドツール PyO3で作成されたRustプログラムをPythonパッケージ として配布可能にするためのビルドツール Cargo (Rustのビルドシステム) とPythonのパッケージン グエコシステムの橋渡しをする Polarsでも 使われてます PyO3: RustでPythonモジュールを作成するクレート(*) Python側から呼び出されたときにRust側で行う処理を定義する RustとPython間のデータ型や機能が相互変換できる 例) Rustの構造体はPythonのclassに変換される (*) Rustではパッケージをクレート(Crate)と呼びます 1 2 3 4 import my_rust_module my_rust_module.sum_as_string 5, 0) ( 1 # → 15 1 2 3 4 5 6 7 8 9 10 11 1 2 1 3 1 4 use n] (a: u b: u ym pyo3::prelude:: ; 関数 #[ pyfunc tio ring s ize, s ize) -> PyRe ul t<S t ing> { O ((a tring() モジュールを定義 #[ p o us t_ module(_ py: P th on, m: &PyM odule) - P Resul t<() d pyfunc tion!(su m_as s ring, m)?)?; * s r k y > y _ t /// 2つの数値を足し算する ) } /// "my_rust_module" という名前のPython fn sum_as_st + b).to_s dule] fn my_r > { m.a d_function(wrap_ Ok(()) } Rust プログラム w/ PyO3 Maturin バイナリ Python パッケージ Python
 プログラム https://github.com/pola-rs/polars
11. 目次 自己紹介 PythonとRustを統合したライブラリを作ろうとした背景 PyO3とmaturinの基礎知識 実際に開発してみて起こったこと まとめ 開発した所感
12. 利用ライブラリ選定 ベイズモデリングライブラリはどうする？ Rustでいい感じにベイズ統計モデリングできるライブラリ(クレート)はなさそう… ベイズ統計モデリングでメジャーなStanはCLIからも使える (CmdStan) Python, R, JuliaではStanのライブラリがあるが、Rustにはない… その他のRustクレートはどういうやつが使える？ PyO3 Polars: データフレーム (≒ PythonのPolars, Pandas) ndarray (≒ Pythonのnumpy) ... (*) https://docs.python.org/ja/3/tutorial/stdlib.html#batteries-included crates.io でクレートは検索できる Rust→CLI→Stan と呼び出すことでベイズモデリングを行うことにする!! Pythonの ”Batteries Included” 哲学(*)とは逆に Rustは標準ライブラリが軽量なので (乱数生成すらもない…) 積極的にクレートに頼っていきます
13. 1st Version: できるだけRustに処理を寄せる Item情報 入力データ 出力 Itemスコア I/Fクラス モデリングのために
 データ整形 Stan入力データ
 ファイル Stan
 モデリング結果
 ファイル CmdStan (CLI)
 ベイズモデリング ID変換や
 補足情報集計 元ID Itemスコア (w/信用区間etc.) 実行命令 元ItemID - StanItemID
 対応表 よいところ Rustだけ読めば処理が把握できる つらいところ CmdStanの呼び出しが煩雑 ファイルやCLI引数には
 型安全性がない… モデリング後 の「補足情報集計」の処理が面倒 Python版のStanライブラリなら
 信用区間など入りDFがすぐ取得できる… ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨
14. 1st Version: できるだけRustに処理を寄せる Item情報 入力データ 出力 Itemスコア I/Fクラス モデリングのために
 データ整形 Stan入力データ
 ファイル Stan
 モデリング結果
 ファイル CmdStan (CLI)
 ベイズモデリング ID変換や
 補足情報集計 元ID Itemスコア (w/信用区間etc.) 実行命令 元ItemID - StanItemID
 対応表 よいところ Rustだけ読めば処理が把握できる つらいところ CmdStanの呼び出しが煩雑 ファイルやCLI引数には
 型安全性がない… モデリング後 の 「補足情報集計」 の処理が 面倒 Py t ho n 版 のStan ラ イ ブラリ な ら
 信用区間 な ど入りDF が すぐ取得 できる… ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ CLIではなくPy t h on のS t a n ライブラリを使おう…
15. 2nd Version: データ整形はRustで、StanはPythonで Item情報 入力データ 出力 Itemスコア I/Fクラス モデリングのために
 データ整形 Stan
 入力データ CmdStanPy
 ベイズモデリング StanID
 Itemスコア
 (w/信用区間etc.) Itemごとの
 スコア情報集計
 (w/ 信用区間etc.) 元ItemID - StanItemID
 対応表 元ID
 Itemスコア
 (w/信用区間etc.) よいところ Stanの機能が使いやすくなった ベイズ信用区間情報や
 収束情報などがすぐ取得できる つらいところ Python, Rustにコアロジックが分かれている 処理を追うのが少ししんどいことが… バグ を 生みやす い
 データ整形処理 は
 Rustで 書けている ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨
16. やってみてよかったこと：安心して高速な処理が書けた!! 意図しないデータ参照や改変・状態変更などが発生しにくいコードが書ける 静的型付けや所有権が気持ちよくてたのしい!! (※個人差あり) 特に所有権はRust特有の概念ですが、バグのない高速なコードを書くのにすごく寄与してくれます 「メモリ上でデータをコピーするかどうか」を都度選択させるため、パフォーマンスが予想しやすい 可能な限り参照させることで、コピーのオーバーヘッドを避けられる!! しかも参照が安全であることが保証されている!! しかし、参照を避けすぎるとライフタイム引数が増えすぎてわけがわからなくなっていくので、
 潔くコピーしたほうがいいこともある 遅い場合は copy() されている場所を怪しめばいい (はず) Pythonよりも大規模プログラムを安心して構造化できる モジュ ー ル構成要素 は デ フ ォルト で 非公開 になるので、コードを書 き ながら 設計 の 見通 しを 立 てやす い 自分 が P yt h o n を書くと、 無邪 気に 公開 してごち ゃ ごち ゃ になってしまいがち …
 (そうならないよう強く念じながら書けばいいのですが、私は弱い…) ク ラ ス ではなく、 構造体 や トレ イ ト ( S c ala にもある)で プロ グラムを 構造化 する
17. やってみてつらかったこと：新たな苦労は生まれる… Pythonライブラリを使いたい場合に設計が複雑になる… 特にデータサイエンス系はPythonが圧倒的に強いので、使用ライブラリに設計が引っ張られがち… データサイエンスライブラリの場合は「複雑な前処理などをRustに寄せる」ぐらいの選択が無難？ Rustのコンパイルや全体把握が面倒… 動作確認時も「Rustをビルド→Pythonを実行」のような手順を踏む必要がある 実行環境 (OS, CPUアーキテクチャ) ごとにRustバイナリをビルドする必要がある AIエージェントに理解してもらうコストも高い 適当に指示すると、Rustコンポーネントの修正なのにPythonコードを読みに行ったりする… 柔らかいコードを書きたくなっても融通が利かない… 例えば 、同じPolarsでもRustで書くとかなりガチガチな印象になる (そもそもcast処理を明示的に書く時点で好ましくないので、
 リッチな処理をしないなら普通に型安全な構造体で書いたほうがいいのでは…？) ちょっと修正しようとしただけで所有権のエラーが何度も出たりも… 1 2 3 4 5 6 7 8 9 10 let l rating_edges: Vec RatingEdge ( ..rating_df_w_item_id. ()) p(|i| { et from_i = rating_df_w_item_id u n(&columns.from_converted_id) wrap() .u32() unwrap() .get(i) .unwrap(); ... < > = d m 0 height .ma .col .un . どっちも それぞれ よさがある
18. 目次 自己紹介 PythonとRustを統合したライブラリを作ろうとした背景 PyO3とMaturinの基礎知識 実際に開発してみて起こったこと 開発した所感 まとめ
19. まとめ： PythonからRustを叩くのはたのしい!!(※個人差あり)(※時と場合による) こういう人にとってはたのしいはず？ Pythonの ”柔らかさ” に辛さを感じることがある 大きくなったPythonプロジェクトを修正するたびに、壊れないよう祈っている自分がいる Pythonで書いたコードが、よくわからないけど遅くて辛くなったことがある 最近はAIさんによってRustの学習コストも下がっています！ ChatGPTでもClaude Codeでもいいので、AIに支援してもらうと理解が早くなると思います Rustで学んだ知見は、よいPythonコードを書くときにも応用できるはずです PythonとRustの責務をどう分けるのかは、かなりケースバイケースの判断が必要になりそう 特 に、Python/Rustの片方でしかやりにくいことをやる場合は、そこに設計が引っ張られる 例えば、機械学習やデータサイエンス系の処理はPythonに寄せざるを得なさそう PythonもRustも銀の弾丸にはなりえないので 適材適所で共存できると たのしい世界がつくれそうですね