Rustを業務で使うためにやったこと

なぜRustを使うのか？

原将己氏（以下、原）：紹介ありがとうございます、原将己と申します。僕はウォンテッドリー株式会社で新卒のソフトウェアエンジニアとして、今年4月から働いています。

仕事では「Wantedly People」という名刺管理アプリの、サーバーサイドと機械学習をいじったりしています。ふだんは趣味でRustコンパイラを読んだり書いたり。主に言語仕様や処理系を趣味としてやっています。

今回は、僕が仕事でなぜRustを使うのか、そしてどのようにRustで書くことを受け入れてもらえるかという点から、今日まで僕がやってきたことを紹介できたらなと思っています。

なぜ「僕が」Rustを使うのか、という問題の答えは、いくつか簡単に思いつくわけです。要するに好きだから……っていうのは、例えば「せっかく詳しくなったから」とか。せっかく詳しくなっても、好きに時間を使ってコンパイラを眺めたりできないので、できるだけもっと時間を使えるようにしていかないと、また鈍ってしまうなと。とくに成長の早い言語ですから。

そういうわけで、仕事で使えたらいいなとは思っているわけです。ただ「僕が使いたいから」というのに対して、周りのエンジニアも新技術には理解がありますが、そうは言っても「ウォンテッドリーでRustを採用する」ということに対してなんらかの意義を見出せないと、やはりあまり良いやり方にはならないわけですね。単に導入するというだけではなくて、「Rustにして良かった」と思ってもらえるような導入の仕方ができたらな、と考えていました。

Rustを導入する契機

さて、ウォンテッドリーでは、新しいサービスはとくに、マイクロサービス化を進めています。なのでいろんな言語でサーバーが動いていまして、とくに最近だと機械学習系のサーバーはTornadoだったり、ハイパフォーマンスのところはGoで書かれていたりします。

ここでRustがどちらかというと向いている用途は、ハイパフォーマンスなものが要求されるところだと思うんですけど。うち、エンコーダーのような（Rustがより有利になるような）サーバーを飼ってないので。この用途で総合的に戦おうとしたら……やっぱ正直Goに勝つのはキツいなぁと。

（会場笑）

正直、10倍速くてもasyncがツラいとなぁ……みたいな感じありますよね。そんなことを考えていたんですけど、ちょうどいい機会がありました。要するに「これがラッキーでした」って話なんですけれども。

先ほど説明したように、僕が「Wantedly People」という名刺管理アプリのチームにいるんですが、その裏で1つ、撮った名刺画像を綺麗にする画像処理のための単一要求のサーバーがあります。

それはこんな感じで、WebPというマイナーフォーマットのイメージを受け取って、それをリファインしたものをS3に入れて、「終わったよ」って返すというだけのサービスがあります。

これがなんと、C++で書かれていました。そういうロストテクノロジーがあったんですけども……。

（会場笑）

それがどうも高負荷になったときに怪しい挙動をするな、みたいなのがよくわからないんですよね。でもC++のサポートはちょっと微妙だし、よく知らないフレームワークなので原因調査が難しいな、という状況にありました。これに手を付けている場合でもないと思って。

こういう状況を待っていました。ということで、これをRustに移植することにしました。

C++を置き換えるだけでなく追加したこと

技術的には、このよくわからないフレームワークをActix Webにして、rusotoさんのお世話になりました。WebPはバインディングのソフトを自作して。あとOpenCV使ってたんですが、これは簡単な処理だったので自作で間に合いました。

ただ移植するだけだとアレなので、手土産を1つ用意しました。Honeybadgerというサービスをうちの中で使っていまして、これはエラートラッカーのサービスの1つなんですけども、このバインディングを自作しました。これでエラーリポートがちゃんと飛ぶようになると。これでかなり挙動の監視もしやすくなって、「良くなったでしょ？」と言うことができるようになったわけです。

この処理がやっぱり良かったと思っていて。「C++をRustにします」といって、それで「これがデメリットかな」というのが挙がる人はあんまりいないんじゃないかなと思います。なによりこれは同じ機能のサーバーを作っただけなので、なにかあったらC++に戻すこともできます。

うちの場合そもそも「C++なら触れるよ」みたいな人もそんなにいないので、C++とRustでRustのほうが人が少ないよね、という心配があるわけじゃないんですけど。一応「Rustを書ける人が少ない」という問題に対しても、既存のサービスの置き換えなのであまり心配ありません。

導入を可能にした環境要因

この移植をして今はどうなっているかというと、なんと。なんと！　明日入ります、と。

（会場笑）

（笑）。今日までがんばってたんですけど、ちょっと慎重を期そうということで。明日あたりなんとか相談しつつ、入れていこうかなと思っています。

結局のところ、C++のサービスがあって、すごく簡単なサービスだったので「これをRustにすることには利点がありますよ」とアピールできる機会がありました。状況的にもその退路を確保できる状態だったので入れやすいです。

あとは周りのエンジニアの方々、とくにインフラの人たちの理解があったので、わりといろいろ手助けしてもらえて、入れそうです。そうした幸運があったのと、一応言語仕様をそれなりに知っていて、ちゃんとしたライブラリを書けるという自負がありますので。

そういったことができる環境が整った状態でこういうことができました、という話なので、すぐにほかの人も適用できるとはいえないと思うんですが、1つの事例としてなにか参考になったらな、と思っています。

導入のその先の話

最後に今後の話としては、ここにあるように……「導入しました」の続きはけっこう大事です。1個サービスに入れられたので、これを軸に興味を持ってもらえるようにして、勉強会なりなんなりと企画して、という感じで広げていこうかなと考えています。

もしかしたら今後のイベントをなにか、ウォンテッドリーで開催することがあるかもしれないので。今後よろしくお願いします。以上です、ありがとうございました。

（会場拍手）

司会者：原さん、ありがとうございました。なにか質問がある方、いらっしゃいますか？

（会場挙手）

質問者1：Actix使っていたと言っていましたが、Actix WebではなくてActixの型システムを使ってたんですか？

原：あぁ、Actix Webです。すいません、なんか。口頭で変なこと言ってましたかね。Actix Webです。

質問者1：ということはマイクロサービスのああいうインターフェースには、httpを使っていた？

原：Actixの裏は僕ずっとhyperだと思ってたんですけど、違ったんでしたっけ？

スタッフ：違います。

参加者：でもActixで、unsafeの量が多くて最近ちょっと問題になってましたよ（笑）。

司会者：へぇー！

原：unsafeを使うのとパフォーマンスがちょっと低下するのだったら、もしunsafeが本当にバグってるのなら、パフォーマンスがちょっとくらい低下したほうがマシですね。

（会場笑）

司会者：原さん、ありがとうございました。

（会場拍手）