謎のCSVコンバータ、未完のViewer、依存関係可視化ツール　私がRustを使って作った3つのプロダクト

Rustを触ったきっかけと勉強方法

刈部拓未氏：私からは「業務でRustをしれっと使う方法」について話します。私が最初にRustを触ったきっかけは、プログラミングを始めた頃にいろいろなパラダイムの言語を触ってみたいと思ったことです。スライドにある『7つの言語 7つの世界』という本を読んでいました。

この本の中にRustはありませんでしたが、言語への関心が高まっていた時に見た言語設計などの公式のドキュメントには、ちょうど仕事で触っていたSwiftが、Rustに影響を受けていると書いてあり、それでたまたま知って、興味を持つようになりました。

そのあとは、公式のドキュメントやオライリーのカニの本や、表紙に自転車が書いてあるRustの参考書などを読みながらRustで書いて勉強しました。さらに、C++で書いていた競技プログラミングをRustで書いたり、スライドの右下にある『Go言語でつくるインタプリタ』をRustに移植したりして勉強しました。

徐々に書く量が増えて、Rustを業務で使ってみたいなと思うようになり、前職までにいくつか業務でRustを取り入れてみたことが、今回の本題です。

ツール1　謎のCSVコンバータ

今回は3つの話をします。1つ目は、謎のCSVコンバータを作った話です。他部署から渡される謎のCSVを自部署が使う謎のCSVに変換するためのツールをRustで書いてみました。

これは設計もなく、変換処理がベタッと書いてあるだけのCLIのツールで、公式ドキュメントを行ったり来たりしながら、なんとかコンパイルを通して動くものを作るためにひたすら書いていきました。今思うと、ひたすらコンパイルエラーを検索して、コピペするコードでした。

よかったことは、わからないことを自分で調べながらやるので、これをきっかけに外部crateの使い方やドキュメントの読み方に慣れたことです。

Rustとは関係ありませんが、この謎のCSVは恒常的に変換する必要はなく、単発だったので、特に運用に乗せることを考えずに書いて、そのまま捨てられるものだったというのも、よかったことの1つだと思います。

また、初めてきちんとしたものを作るきっかけになったので、「よくわからないけれど、とりあえずunwrap()で見なかったことにしよう」と割り切れたのはよかったと思います。

ツール2　未完のViewer

2つ目は、未完のViewerです。社内で高速な画像Viewerを作ろうという話が持ち上がった時に、検証のため作ったものです。これはWebGLをWasm（WebAssembly）経由で呼び出すため、Rustを採用して書いてみました。結局は検証で終わってしまって、本格的にプロダクトに組み込んでチームで開発しようという結論には至りませんでした。

社内の技術検証でRustを使う話をした時に、それほど反対されなかったので、このような技術検証だと、あまり反対されないのだと学びました。

結局、これは本格的な開発には至りませんでした。しかし、周りの誰もRustが書けないチームだったため、仮に本格的にプロダクトを開発するとなれば、それなりに学習コストも発生するのであまりよくない進め方だったと思っています。

ツール3　マイクロサービス依存関係可視化ツール

3つ目は、マイクロサービスの依存関係を可視化するツールを作りました。このツールは、Terraformで書かれたAmazon SNSと、Amazon SQSの依存関係をパースして可視化するツールです。最終的なアウトプットとしては、スライドの右にあるようなグラフ構造として画像を出力します。

よかったことは、可視化されたことで依存関係が複雑化しているマイクロサービスを発見しやすくなり、社内で共有しやすくなったことです。ほかにも、2つ目のViewer開発の反省を活かして、あまりRustを書かない人に運用を強いらないように、CIには組み込まず、気になる人が気なる時に叩いて確認できる程度にした点はよかったと思います。

このツールを社内のLTで発表したのですが、SREチームの人から「HCLはJSON互換だから、JSONをパースしたほうが速いんじゃないか」と言われました。何も知らなかったのでかなり驚愕したことを覚えています。

マイクロサービスとして本当に必要だったのは、なぜ依存しているのか、また、どういう時に依存するのかという「依存している意味」だったので、これも結局あまり使われないという結末を迎えました。

Rustでツールを作成するうえで気をつけるべきこと

結論です。社内のニッチなツールや技術検証であれば、どんな会社にもRustで作れるものがけっこうあると思います。同じ作業を繰り返しているようなトイルの撲滅にもいいですし、書き捨てられるようなものや技術検証であれば、特にハードルは低いと体感的に思いました。

ただ、プロダクトとしてRustを使う場合は、スライドに書いてあるようにかなりの責任と覚悟が必要だと思っています。これはRustに限りませんが、中途半端にツールを導入して退職すると、残される人はかなり運用がつらくなってしまうので、ある程度自分が責任を負える範囲で作るのがいいと思います。そういう意味では、Rustを仕事で使ううえでのハードルはRustそのものよりも人にあるのではないでしょうか。

学習において非常によかったことは、業務の時間にRustを書けたことです。Rustでの良い書き方を求めずに、unwrap()、unwrap()、unwrap()である程度動くものを作って、社内でフィードバックをもらいました。家に帰ってから本や公式のドキュメントを読んで、翌日また修正するというサイクルが作れたのは、非常によかったです。写経に飽きた人にはすごくおすすめです。

ということで、「自分の手の届く範囲で業務でRustをしれっと使う方法」の発表は以上です。