はじめに
こんにちは！Webアプリケーションを開発しているチームでいろいろ学びながら協力しているインターン生です！この間、バッチ処理の導入を検討するタスクをもらいました。正直、最初は「バッチって何？」というレベルからのスタートでした。
ですが、調べていくうちに「この場合は2つのバッチ処理を入れたほうが良いのでは？」などと自分で考えられるようになり、最終的にはバッチ処理全体の設計を考えるところまで進みました。この記事では、私と同じような初学者の方にもわかるように、バッチ処理とは何か、そして設計を考える時のポイントを紹介していきます。
バッチ処理とは？
まず、「バッチ（batch）」という言葉自体は英語で一括、一回分といった意味があります。この考え方をITの世界に応用したのがバッチ処理（Batch Processing) です。バッチ処理とは、大量のデータや繰り返しの作業をバッチというまとまりにして、一括で処理する方法のことです。処理をまとめて行うことで、時間やコンピュータの負荷を抑えることができます。多くのデータを定期的に処理する場面に適しており、集計、分析、アーカイブ、レポート作成などに広く使われています。
バッチ処理に対して、リアルタイム処理(ストリーム処理) というのもあります。リアルタイム処理とは、データが発生したその瞬間に即座に処理を行う方法です。ユーザーの操作に対して即時に反応する必要がある機能に向いており、例えば、チャットアプリでメッセージを即表示したり、決済完了後すぐに通知を送ったりする場面などに使われているようです。
バッチ処理の用途
バッチ処理は、いろいろな業界で使われていますが、ここでその一部の例を紹介します。
-
アーカイブ:
サービスが長く続くと、古いデータがどんどん蓄積していきます。でも、システムにもよりますが、3年前のログを毎回検索する人はほとんどいないと思います。
そこで、本番用のデータベースを軽くして、読み書き速度を保つために、たとえば、1年以上前のデータをアーカイブ専用のテーブルやストレージに移すようなバッチ処理が動いています。
こうすることで、すぐ使わないけど消せないデータをうまく管理できます。 -
給与処理:
企業に勤めていると、月に1回や2回、給料日がありますよね？あの給料の計算も、「バッチ処理」で行われています。
どう使われるかというと、毎日社員の勤怠情報（出勤・残業・休暇など）を記録しておき、月末や月初に、全社員分をまとめて集計・計算し、給与金額、控除、税金などを計算して、給与明細や振込データを一括で生成します。
つまり、一人ずつリアルタイムで計算するのではなく、その月の分をまとめて処理するのです。 -
集計：売上やユーザーの動きをまとめる
たとえば、スーパーマーケットでは、毎日何千件ものレジ通過データが記録されていると思いますが、これを1件ずつリアルタイムに処理していたら、レジもシステムもパンクしてしまいます。
そこで、夜中にその日1日分の売上や商品別の売上数を集計するバッチ処理が使われています。
他にも、ECサイトで「昨日どの商品がよく売れたか」を毎朝9時にレポート化したり、アプリで「週ごとのアクティブユーザー数」を日曜日の深夜に集計したりと、一定期間ごとにデータをまとめて処理する場面で使われます。
バッチ処理のメリット
- 大量データに強い（効率がいい）
バッチ処理は、一件ずつ処理するよりも効率的に大量データをさばけるという強みがあります。
一度にたくさんの処理をまとめて行うことで、読み込み・書き込みの回数を減らしたり、計算リソースを最適化することができます。 - コスト効率が良い
多くの企業では、バッチ処理を夜間や早朝など、システム利用が少ない時間帯（＝オフピーク時間）に実行しています。
これにより、サーバーのリソースを無駄なく使える、クラウドなどで従量課金されるケースでもコストを抑えられるというメリットがあります。 - ワークフローがシンプルになる
バッチ処理は、基本的に「一定のタイミングでまとめて処理する」という決まった流れなので、リアルタイム処理と比較すると設計や運用がシンプルです。 - エラー対応がしやすい
バッチ処理では、処理の前後でエラーをまとめて確認・対応できます。
たとえば、異常なデータだけログに出力したり、失敗した処理だけ別の場所に退避させて再実行（リトライ）したりと、途中で止まってもやり直せる仕組みを入れやすいのが特徴です。
バッチ処理の設計を考える時のポイント
ここで、実際プロジェクトのデータにバッチ処理を入れる設計を考えた時に、気づいたポイントについてまとめます。
まず目的を明確にする
一番大事なのは、「なぜこのバッチ処理が必要か？」をはっきりさせることだと思いました。
- 古いデータをアーカイブしてDBを軽くしたいのか？
- 毎日のレポートを作りたいのか？
目的が曖昧だと、何をどのくらいの頻度で処理するかも決めづらくなります。
データの温度を考える：Hot / Warm / Cold データ
データに温度がある？という感じですが、これはとても面白い考え方でした！Hot / Warm / Coldデータとは何かというと、
- Hot データ：よく使うデータ、頻繁にアクセスされるデータのことです。このようなデータは、すぐに表示・反映する必要があります。
- Warm データ：それほど頻繁には使われないけれど、たまに使うデータです。
- Cold データ：ほとんど使わないけど、消せないデータです。読み出しは遅くてもOKですが、できるだけ安く保存したいというニーズがあるため、低コストで大容量なストレージに保存されます。
自分のプロジェクトのデータベースをこれらの観点で分類して考えることで、「どのデータをどこに置くべきか」や「どの範囲をいつ処理すべきか」が明確になりました。
処理開始時間と処理頻度を考える
バッチ処理は「定期的に動かす」のが基本ですが、いつ・どのくらいの頻度で動かすのが最適かは、バッチの目的やデータの種類によって変わります。
開始時間を決める
たとえば：
- 夜中や早朝（オフピーク時間）あるいは土日：ユーザーのアクセスが少ないので、サーバーの負荷を気にせず重たい処理を回せる
- 業務開始前：朝9時にレポートを使うなら、バッチは朝7時ごろに完了している必要がある
- システム更新の直後：新しいデータが反映されたタイミングで実行したい場合など
このように、誰がいつデータを使うのかやシステムの混雑状況を考慮して、実行開始時間を設計することも大切です。
頻度を決める
毎日回す必要がある処理もあれば、週1や月1で十分なケースもあります。私は、Hot / Warm / Cold データの考え方を使って、それぞれに合った処理頻度を決めました。たとえば、Warm データは週1回で、Cold データは月1回で処理するというように設計しました。
失敗しても大丈夫な設計にする
処理中にエラーが起きても、もう一度やり直せるようにしておくことが大事だと思います。
たとえば：
- 処理済みのデータを記録しておく
- 同じ処理を何回やっても結果が同じになるようにする
- エラーになったら管理者に通知がすぐ届くようにする
- エラーになったデータを別のところに保存して後で確認する
こうした仕組みがあると、安心して運用できます。
まとめ
バッチ処理は実際に設計してみると考えることがたくさんありました。特に「目的を明確にする」「どのデータを対象にするか」「失敗時の対応を考える」など、実際の運用を具体的にイメージすることが大切だと感じました。
この記事が、これからバッチ処理にチャレンジする初学者の方の参考になればうれしいです！
参考資料
Discussion