本日のテーマ

本日のテーマは「バッチ処理の負荷低減」です。

YOUTRUSTには高負荷なバッチ処理がいくつかあるのですが、それぞれ何かしらの工夫で負荷の低減を図っています。今回はそれらのバッチ処理の中から一つを例に取り、具体的にどのようにして負荷低減を実現しているかについて書こうと思います。

題材のバッチ処理

前日に行われた転職意欲変更・副業意欲変更をまとめてユーザーに通知するバッチ処理（以降「意欲変更サマリ通知バッチ」と記載します）を題材にします。

本題に入る前に、まずはこのバッチ処理が何を行うバッチ処理なのかについて触れようと思います。

意欲変更サマリ通知バッチとは？

YOUTRUSTにはユーザーが転職意欲と副業意欲を設定できる機能があるのですが、意欲を変更した際に「特定のユーザー」にその意欲変更を伝えることで、ユーザー同士のキャリアに関するコミュニケーションを促進したり、企業からスカウトが届くようにしています。

意欲変更通知には即時通知とサマリ通知があり、サマリ通知では前日の意欲変更者をまとめてユーザーに通知するので、意欲変更をしたユーザーが複数人いる場合はそれらがまとめて通知されます。

意欲変更サマリ通知バッチの問題

意欲変更通知では意欲変更を誰に通知するかを判定する処理を行っているのですが、この処理が実行時間が長かったり、消費メモリ量が多かったりなど、システム負荷を高めていました。

さらに、意欲変更サマリ通知バッチでは、前日に行われた転職意欲変更・副業意欲変更をまとめて通知しているため、例えば1日で1000人のユーザーが意欲変更をしていた場合に、1000人の意欲変更それぞれに対して通知対象者を判定する必要があります。

そのため、システム負荷がさらに高くなっていました。

負荷を下げるために行っている工夫

通知対象者を判定する処理自体を軽くする方法も考えられたのですが、この対応は実装コストが高くなりそうということで別の方法を取ることにしました。

実際に行った対応としては、意欲変更の即時通知実行時に「誰の意欲変更を誰に通知したか」を記録しておくことで、サマリ通知の時に通知対象者の計算を省略するようにしたと言うものです。

これまでの説明にもあったように、意欲変更の即時通知送信時にも意欲変更の通知対象者を計算しており、その計算結果をもとに通知を行っているので、ここで使用した計算結果を記録しておいて再利用する形にしました。

具体的には以下のようなテーブルを作成して通知履歴情報を記録するようにしています。

# 転職意欲変更通知履歴テーブル
user_job_change_motivation_history_notification_target_users
+---------------------------------------+--------------+------+
| Field                                 | Type         | Null |
+---------------------------------------+--------------+------+
| id                                    | bigint       | NO   |
| user_job_change_motivation_history_id | int unsigned | NO   |
| user_id                               | int unsigned | NO   |
| created_at                            | datetime     | NO   |
+---------------------------------------+--------------+------+

# 副業意欲変更通知履歴テーブル
user_side_job_motivation_history_notification_target_users
+---------------------------------------+--------------+------+
| Field                                 | Type         | Null |
+---------------------------------------+--------------+------+
| id                                    | bigint       | NO   |
| user_side_job_motivation_history_id   | int unsigned | NO   |
| user_id                               | int unsigned | NO   |
| created_at                            | datetime     | NO   |
+---------------------------------------+--------------+------+

転職意欲変更履歴や副業意欲変更履歴をもとに意欲変更者がわかるので、上記のテーブルにより「誰の意欲変更を誰に通知したか」がわかる形になります。

そのため、意欲変更サマリ通知を送る際には、上記のテーブルを参照すれば良くなるので、通知対象者を計算する処理自体を省くことができました。