データチームの@komi_edtr_1230です。

突然ですが、heyがメインで使ってるプログラミング言語は何か知っていますでしょうか？ heyはECと決済、予約など複数事業の事業を展開しているのですが、ECと予約はRuby (+ Rails)で決済はJavaを使っています。また、アカウント共通基盤ではGoを使っています。

今回データチームでは事業成績を日次でSlackに通知してくれるアプリをRustで開発しました。

この記事ではどのようにして開発を進めたのか、ツラいポイントはなんだったか、何が良かったかなどについてまとめます。

何を作ったのか

今回作ったSlackアプリはどのような要件を抱えていたかというと、

様々な項目についてのデータを取得
Slackに投稿できるようJSONを整形
日次で稼働する(CRON Job)

というような具合でした。

現在heyのSlackでは、以下のように毎朝6時に前日の実績のサマリが投稿されるようになっています。

f:id:komi1230:20211019163121p:plain

これ以外にもデータをもとに事業成績の日次推移を画像として出力する機能もあったりします。この機能については後述します。

なぜRustを選んだの？

今回の要件として特徴的なのが、Slackで通知しなければいけないデータが非常に多いという点です。

具体的に、今のところ通知している内容としては前日と今月の流通額やトランザクション数、会員情報など多岐にわたります(これ以外にも何個も項目がある)

こうした各項目について都度SQLをBigQueryにPOSTして処理を行うという実装を行えばコードが冗長になるのは想像に難くないと思います。

また、Slack通知の内容はビジネス的制約によって条件が変更される可能性が出てくるわけです。

自分はこうした問題では型による振る舞いの共通化と制約が有効であると判断しました。

というのも、最初に型としてどのような振る舞いをして欲しいかを記述しておけばあとはそのガイドラインに則って実装を進めていけば良くなるので頭を使わなくて済むし、アスペクト指向プログラミング的に関心の分離を実現することもできます。

こうしたメリットは非常に有用です。そもそもSlackアプリなんてそんなアクティブにメンテナンスするものでもないし、必要とあらばたまに触っていじるみたいなものですよね。なので一度触って次にまた開発に着手するのは半年後なんてこともザラにあるわけです。

半年前に書いたコード、覚えていますか？僕は覚えていません。そうしたコードはもはや別人が実装したに等しいものです。

なので時間が経ってSlackアプリに改修を入れて欲しいなんて依頼が入ったときに、コードがどのように振る舞っているかを見るには型が重要なヒントになると思います。もちろんドキュメントやディレクトリ構成、変数命名なども超重要なんですけどね。

ということで型がしっかりした言語でありコードが冗長になりにくい、そうした点でRustを選定しました。

実装のポイント

以下では実装の際に気をつけたことを色々まとめていきます。

CI/CDではキャッシュをフル活用

Rustのビルドが遅いというのはよく聞く話です。

ですが、そのビルドが遅いのは初回だけで、2回目以降はIncremental Buildが有効になるのもあってかなり速いです。逆に、初回はクレートを外部から持ってきて色々するのでそりゃ時間もかかるわなという感想ですね。

で、コードをリポジトリにPushした際に毎回テストを回すにもビルドして云々して、というのはかなり時間がかかります。大した量のコードを書いてないのにテストが回り切るまで5分待たなきゃいけないというのは我慢なりません。

そこでキャッシュを利用します。 GitHub Actionsだとcacheというのがあり、これを利用します。

github.com

これをやるだけでcargo buildが一瞬で終わります。

このキャッシュ機構はDockerのビルドにも有効で、キャッシュを効かせるためにDockerのステップを意図的に外部クレートのビルドとアプリ本体のビルドで分けておくとDockerのビルドもかなり速くなります。

FROM rust:1.54.0

RUN cargo new --lib gmv-notifier
RUN mkdir /work
RUN mv gmv-notifier/Cargo.toml gmv-notifier/src/ /work
COPY Cargo.toml /work/
WORKDIR /work
RUN cargo build --release

# Set project file
COPY build.rs /work/
COPY src/ /work/src
COPY sql/ /work/sql
COPY config/ /work/config

WORKDIR /work

RUN ls src/lib.rs

RUN cargo build --release

CMD cargo run --release

このファイルでは最初にCargo.tomlとsrc/lib.rsだけセットしてビルドするだけで外部クレートがビルドされるようにしています。

今回はこのようにしてビルドを高速化しましたが、他にもcargo-chefというのを使って高速化する方法もあります。

Cargoを利用した複数の実行バイナリの生成

Rustでは以下のようなディレクトリ構成の時に複数の実行バイナリを持つことができます。

├── Cargo.toml
└── src
    ├── hoge.rs
    └── lib.rs
    └── bin
        └── foo.rs
        └── bar.rs

実行の際に以下のようにすることで異なるバイナリが実行できます。

$ cargo run --bin foo
# => fooが実行される

$ cargo run --bin bar
# => barが実行される

今回実装したSlackアプリでは、PMが日次で実績が欲しいという要望がある一方で別のPMから新規顧客リストが欲しいという要望もあり、これらは投稿するチャンネルや時間が異なるということもあってバイナリを分けることによって対応しました。

Cargoのビルド副作用機構を利用したディレクトリの作成

Cargoではbuild.rsというファイルを用意しておくとビルド時に副作用としてbuild.rsの内容を実行してくれます。

今回のSlackアプリではデータをもとにグラフを描画して画像に保存、Slackに投稿するという要件があり、その画像を一時的に保存しておくディレクトリを作成するようにしました。

use std::fs;
use std::path::Path;

fn main() -> std::io::Result<()> {
    if !Path::new("./images").exists() {
        fs::create_dir("./images")?;
    }
    Ok(())
}