freeeの開発情報ポータルサイト

freee会計の月末のDB負荷を減らしたい!

こんにちは、freee 基盤チーム advent calendar の 21 日目担当、DBRE (Database Reliability Engineer) の shinta です。今年新卒入社しました。
freee の中でも一番のリクエスト数を誇る freee会計の DB は、月末に負荷が高まって色んなアラートを発報するのですが、なんとかその負荷を減らしたいな〜と思ってやっていることを書いていきます。

freee会計の負荷の傾向

freee会計のワークロードにはトレンドがはっきりあって、月単位で見れば月末、年単位で見れば確定申告のある 2, 3 月にアクセスが集中します。去年の確定申告期は一時的に会計 DB をスケールアップして乗り切りました。freee会計へのリクエスト数はありがたいことに年々増加傾向で、今年は既に去年の確定申告期のリクエスト数を突破しているそうです。freee 的にはありがたいことなのですが、DBRE 的には気になるのはやはり DB の負荷になってきます。

月末の負荷を減らしたい!

そこで DBRE では、とりあえず直近でアラートが鳴るのが確定している月末をターゲットにして、月末に実行時間の多くなるエンドポイントを集中的にチューニングすることにしました。以下は、今取り組んでいる方法の概要になります。

月末に実行時間の多くなるエンドポイントの特定

弊社ではモニタリングのツールとして Datadog を採用しているのですが、Datadog APM のメトリクスを集計することで、下図のように平常時と月末の各エンドポイントごとの実行時間の差分を取ることができます。チューニング対象を選ぶ際には、この中で上位に来てるエンドポイントから選べば、月末の負荷を狙い撃ちで減らせるのでは、という作戦です。

負荷をかけている原因の調査

問題となっているエンドポイントが特定できたので、次は対象のエンドポイントの APM をグッと睨むフェーズになります。

Datadog APM を見ていると色んなことがわかるのでおすすめです。

N+1 が発生しているかどうか

Datadog APM の span summary にて、SQLを実行時間でソートしたものを見ると、下図のように、同種の SELECT クエリがそのエンドポイントの 1 リクエストごとに平均 35 回ほど呼ばれていることが分かります。これだけで N+1 が起きていることの断定はできないですが、可能性はありそうに見えます。

slow query が流れているかどうか

この判断は、APM 上で見えるそのエンドポイントでの SQL と、その後 AWS RDS の Performance Insights, mysql.slow_log 上での SQL を突き合わせて同じ SQL が出ていないか目 grep して行っています。

APM 上で対象エンドポイントで流れている SQL の平均レスポンスタイムを見ると slow query を見つけやすいかもしれません。

1エンドポイント内で色々やってる

N+1, slow query のどちらのパターンでもないのになんかトータルの実行時間が長い...時はエンドポイント内で色々やってるパターンが多いです。 freee会計での一例ですが、あるページでは Rails の view から SQL を source に大量に投げていました。 このエンドポイント内で色々やってるパターンでは、処理を抜本的に変えるか、簡易的な対策として read replica を見るようにする、というのがあるのかなと思います。

改善の提案

どのエンドポイントでどの問題が起きているか、対象サービスのコードに詳しくなくても APM やその他周辺ツールで概要は掴めたので、対象のサービスを開発するチームに報告していきます。
freee会計は Rails の controller ごとにコードオーナーが設定されているので、各コードオーナーのチームに改善提案を投げていっています。 今は人力で各チームに連絡していってますが、ゆくゆくは自動化したいです。

やってみて今どうなっているか

DB の負荷が劇的に下がる、みたいなことは起きていないです。以下に二つ理由として感じているものを挙げます。

  • DBRE 側にアプリケーションレベルでの改善提案のノウハウが溜まっておらず、改善提案を数多く投げられていない

    • 今まで DBRE は DB の運用改善 + DB におけるパラメータの tuning に注力していた
    • クエリ単位でのパフォーマンス改善提案は今までも行っていたが、アプリケーションレベルで DB への問い合わせを眺めて改善点を考えるのは DBRE でも新しい取り組み
  • サービス開発チーム内での優先度が上がらず、提案しても改善が後回しになりがち

    • どのチームも機能開発で忙しそうに見えます

おわりに

ボトルネック見つけて、修正案考えて、改善結果見て...の流れは ISUCON に似ていて楽しいので今後も続けていきたいです。 明日は我らが DBRE のリーダーの juni さんです。次回もお楽しみに!