バッチ処理

バッチ処理とは

バッチ処理は、データをためておき、決まったタイミングでまとめて一括処理する方式です。リクエストが来るたびに即座に応答するオンライン処理(リアルタイム処理)と対をなす概念です。

「毎晩2時に前日の売上を集計する」「月末に全会員へ請求データを作る」— こうした業務の裏側はバッチ処理が支えています。実行タイミングの制御は [[ジョブスケジューリング(cron)]] が担います。

なぜ一括処理にするのか

• 重い処理をピーク時間帯から逃がせる — 集計や大量更新を夜間に回し、日中のオンライン処理への影響を避ける
• 効率が良い — 1件ずつ処理するより、[[SQL]] の一括更新やまとめ読みの方が圧倒的に速い
• 業務の区切りと合う — 「日次」「月次」という業務サイクルそのものが一括処理と相性が良い

大量データを段階的に変換していくバッチの発展形が [[データパイプライン・ETL]] です。

設計の勘所

バッチ処理には定番の設計ポイントがあります。

• リランを可能にする(再実行) — 途中で失敗したとき、最初からやり直しても二重計上などが起きないよう [[冪等性]] を意識して作る
• 処理範囲を明確にする — 「どこからどこまでのデータを対象にしたか」を記録し、漏れ・重複を防ぐ
• 突き抜けに注意する — データ量の増加で処理が予定時間内に終わらず、翌朝のオンライン処理開始に食い込む事故を「突き抜け」と呼びます。処理時間の監視が必須です([[監視とアラート]])
• 分割して処理する — 全件を一度にメモリへ載せず、一定件数ずつ(チャンク単位で)処理する

初学者向けポイント

• 最初のバッチは「CSV を読み込んで DB に登録する」「日次で集計テーブルを作る」あたりが定番の題材です
• 失敗時にどこまで進んだか・何が原因かをログで追えるようにしておくことが、運用のしやすさを大きく左右します。人が見ていない時間に動くバッチでは、[[ログ設計]] が唯一の証跡になります
• 即時性が必要な処理まで夜間バッチに寄せない — リアルタイムに近い連携が必要なら [[メッセージキュー]] による逐次処理も検討します

関連技術とのつながり

• [[ジョブスケジューリング(cron)]] — バッチの起動タイミングを制御する仕組み
• [[データパイプライン・ETL]] — 抽出・変換・格納を行うバッチの発展形
• [[メッセージキュー]] — 準リアルタイムに処理したい場合の代替手段
• [[SQL]] — 一括集計・一括更新でバッチの効率を支える
• [[エラーハンドリングとリトライ設計]] — 途中失敗した外部呼び出しの再試行と上限の決め方

Q: バッチ処理の説明として正しいのはどれ?
- [ ] リクエストのたびに即座に応答する処理方式
- [x] データをためて決まったタイミングで一括処理する方式
- [ ] 画面描画を高速化する処理方式
解説: バッチ処理は定時にまとめて一括処理する方式で、都度応答するオンライン処理と対をなします。

Q: バッチ処理の「突き抜け」とはどれ?
- [x] 処理が予定時間内に終わらず、翌朝のオンライン処理開始に食い込むこと
- [ ] バッチがエラーで1件も処理せず終了すること
- [ ] 対象外のデータまで誤って処理してしまうこと
解説: データ量増加などで夜間バッチが時間内に終わらない事故を突き抜けと呼び、処理時間の監視で予防します。

Q: バッチを再実行可能に設計する際に意識すべきことはどれ?
- [ ] 処理を必ず1件ずつ手動で実行すること
- [ ] 失敗時にログを残さないこと
- [x] 最初からやり直しても二重計上が起きないよう冪等性を意識すること
解説: 途中失敗からのリランで結果が壊れないよう、同じ処理を繰り返しても安全な作りにするのが基本です。