カカオ推薦チームのRust導入
(tech.kakao.com)カカオの推薦チームでは、既存の機械学習プラットフォームを置き換える新しいプラットフォームの開発を進めている。
チーム内の主力言語であるPythonでは、アプリケーションの性能と安全性の両方を確保するのがやや難しい面があった。
ユーザー指標アプリケーションにRustを導入し、Rustでアプリケーションを実装することが適切かどうかを検証する手順を進めた。
- RustはPythonより作業を約1.9倍速く処理
- メモリ使用量はPythonがRustより約4.5倍多い
- PythonのCPU使用量はRustより最大3倍、平均で約2倍高い
- Pythonの
asyncioとRustのtokioを各言語のアプリケーションに適用し、非同期処理を同じように実装したシングルスレッド環境でも、Rustのメッセージ処理速度はPythonより約10倍速かった。
Rustの大きな欠点の一つは、学習コストが高かったこと。
Pythonで開発するときも型アノテーションを必須にしていた。ユーザー指標アプリケーションを2つのバージョンで実装しながらも、PythonとRustの間で開発時間の差を大きく実感することはなかった。
生産性の面で最も大きく感じられた違いはコンパイル時間。（パッケージのダウンロードやDocker時間を含む）
- Rustはおおよそ340秒
- Pythonはおおよそ100秒
Pythonでは型情報のないライブラリで生成されたデータは、型検査が無視されるAny型になる。これはプロジェクト全体の型検査の精度を下げる。
Pythonは例外を使い、RustはResultというenum型を使うといった違いもあった。
開発ツール
Rustではcargoが基本的に多くの機能を提供している。
Pythonの開発ツールは高度に整備されており、インストールするだけで比較的簡単に使えた。
4件のコメント
Python も Rust もどちらも経験はありませんが、文章だけを見る限りでは、Rust 導入の大きな利点を感じられません。
Rust が良くないと言いたいわけではなく、Rust 導入のために行った実験も物足りなく、
（たった 50 件のメッセージ処理結果だけを見て、何倍も速いから何倍も良いと主張するのは、あまりに根拠が弱い展開に思えます……）
しかも、同一の処理ロジック（同期 vs 非同期）で比較したわけでもありませんし。
[非同期メッセージ処理をサポートするがリファレンスがあまり多くない Python ライブラリ] vs [学習コストが高く、少人数による保守リスクのある Rust 言語]
この 2 つの状況を並べて見たとき、今後の持続可能性についても真剣に検討されたのか疑問です（少なくとも記事から受けた印象ではそうでした）。
ETL の特性上、短時間で頻繁にテストする必要がある場面が多そうですが、ビルド時間 100 秒 vs 300 秒は開発において大きなボトルネックになりそうです。
記事では増分ビルドが優れていると触れていますが、その内容はハイパーリンクで済まされていて……
実際にはしっかり調査・検討したのだと思いますが、少なくとも記事から受ける印象としては……本当に Rust 導入によって何が良くなったのか、期待効果は何で、何を解決したのかが分からず、共感もしにくいです。
個人的には、「最近ホットな技術」や、あるいはキャリアの 1 行のために技術を選ぶケースを見てきましたが、結果としてチーム内で保守もできず、技術的負債として残った場合がほとんどでした。
もちろん、上の Rust の記事がそうだと言いたいわけではなく、そうでないことを願っていますが……
深く考えずに導入した技術によるしわ寄せを受けるのはチームメンバーだ、ということを何度も経験してきたので、ああした技術プロモーション的な記事を読むときは、より慎重になるように思います。
基本的にはETLタスクのように見えますが、このドメインでPythonとあわせて強みを持つJavaは検討されなかったのでしょうか。Rustと比較して採用しなかった理由があるなら、知りたいです。
一部の性能比較資料は小規模なテストを通じて得られたものであり、やや物足りなさが残ります。
性能テストはワークロードの性質によって意味合いが大きく変わりますが、テスト設計や数値をどのように得たのかといった説明がなくて残念ですね。
たとえば500万件を処理した後、50件処理を基準に算術平均などを取ったのか、そうだとしたらメモリ使用量はどのように求めたのか、CPU使用量の差はどのように測定したのか、などが気になります。（時間はおそらく wall-clock time ですよね？）
また、「CPU使用量を見ると、両言語での性能差の大部分は入出力（Input Output、以下 IO）処理である Kafka メッセージ消費処理と MongoDB ドキュメント保存処理に起因する」という解釈がありますが、結果では wall-clock time は Rust が 1/2 程度で、CPU使用量（CPU time?）は 1/4.5 とのことなので、IO に関する実装方式の違いという話なのか、それとも CPU-intensive な IO 対象データを扱う過程の違いなのか、論理が少し理解しづらい点があります。実際、CPU-intensive な task に対して Rust が優位性を持つ部分はよく知られているので、後者であればライブラリの違いに触れる必要性もあまりない気がします。 むしろ実験では、CPU-intensive な作業であれば記事でも言及していた asyncio/tokio の実装比較のように、もっと大きな差が生じているべきで、IO のために性能差が小さくなったと解釈すべきではないかと思います.