- 大量のデータや業務処理をまとめて（バッチ＝束）決まったタイミングで一括実行する処理方式のこと
- 給与計算・月末請求書発行・ログ集計など「即時性は不要だが大量データを効率よく処理したい」場面で使われ、夜間や休日にCPU・DBのリソースを効率よく使える
- リアルタイム処理（ユーザーの操作に即座に応答する）と対になる概念で、用途に応じて使い分けることが現代のシステム設計の基本だ
【深掘り】これだけ知ってればOK！
バッチ処理システムの設計で重要な概念としてジョブスケジューラがある。Linux系ではcron・Windowsではタスクスケジューラが代表的で、指定した時刻・周期でバッチジョブを自動実行する。クラウド環境ではAWS Lambda+EventBridge・Cloud Run Jobs・GitHub Actionsなどが柔軟なジョブスケジューリングを提供している。
バッチ処理の設計で特に重要なのが冪等性（べきとうせい）だ。同じバッチを複数回実行しても結果が変わらない性質で、障害によるリトライ・再実行時にデータが二重登録されないよう設計する必要がある。処理済みフラグの活用・upsertの使用・処理IDによる重複チェックが代表的な実装方法だ。
大規模なバッチ処理にはApache Spark・Flinkなどの分散処理フレームワークが使われる。1台のサーバーでは処理しきれないPBスケールのデータを複数のサーバーに分散して並列処理できる。クラウドではEMR・Dataproc・Azure HDInsightがSpark環境をマネージドサービスとして提供しており、大規模データエンジニアリングの中核技術になっている。
よくある誤解
バッチ処理は夜間しか動かないと思っている
夜間実行が多いが時間帯は問わない。数分間隔のミニバッチ・注文確定後に非同期で実行するバッチ・データが一定量たまったら起動するイベントドリブンなバッチなど、様々なトリガーと実行間隔がある。
バッチ処理はレガシーなシステムでしか使わないと思っている
AWS Batch・Cloud Run Jobs・Apache Spark・Google Dataflowなどのクラウドサービスを使った大規模バッチ処理は現代のデータエンジニアリングの中核技術だ。クラウドネイティブな設計でのバッチ処理は現在も活発に使われている。
会話での使われ方
夜間バッチの処理時間が長くなっています。並列化かSQLのチューニングで改善できますが、まずどこがボトルネックか確認してください。
インフラエンジニアがバッチ処理の性能劣化を指摘してボトルネック特定を促している場面。
月次の請求書バッチが失敗しても朝まで誰も気づかない状態です。失敗時にSlackにアラートが飛ぶ監視を追加してください。
開発リーダーがバッチの監視体制の不備を指摘している場面。
このバッチ、同じデータを2回処理したらレコードが重複します。冪等性を担保するためにupsertに変えてください。
シニアエンジニアがバッチ処理の設計問題を指摘して修正方針を示している場面。
【まとめ】3つのポイント
- 大量データを効率よく一括処理するシステムの処理方式：リアルタイム処理が不要な業務処理をまとめて実行することでCPUやDBのリソースを効率よく使い処理コストを下げる
- 冪等性の確保でリトライ・再実行を安全にする：障害時の再実行でデータが二重登録されないよう同じバッチを何度実行しても結果が変わらない設計にしておくことがバッチシステムの堅牢性の基本だ
- 失敗検知と監視を無人運用の前提で設計する：深夜に無人で動くバッチは失敗しても誰も気づかないリスクがあるためジョブ終了ステータスの記録と失敗時アラートの仕組みを組み込んで運用品質を担保する
よくある質問
-
Qバッチ処理とリアルタイム処理はどう使い分けますか？
-
A
即時性が必要な処理（ログイン・決済・在庫更新）はリアルタイム処理で、大量データを効率よく処理したい場合（給与計算・ログ集計・メール一括配信）はバッチ処理が向いています。
-
Qcronとバッチ処理は同じですか？
-
A
cronはジョブのスケジューリングツールで、バッチ処理を自動的に起動する仕組みです。バッチ処理はまとめて一括実行する処理方式を指します。cronを使ってバッチを実行するという関係です。
-
Qバッチ処理でよく使われるフレームワークは何ですか？
-
A
JavaではSpring Batch、PythonではAirflow・Prefect・Dagster、大規模データ処理ではApache Spark・Flinkが代表的です。クラウドではAWS Batch・Azure Data Factory・Cloud Composerも広く使われています。
-
Qバッチ処理の冪等性はどう実装しますか？
-
A
処理済みフラグのチェック・UPSERTの使用・処理IDによる重複チェックが代表的です。また処理対象の日付範囲を明示して同じ期間を再実行しても重複しない設計にすることも重要です。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| データ | 本記事のテーマと実務上セットで使われることが多い用語です。コンピュータが処理する数値や文字、画像といった事実や資料そのもの、それがデータだ |
| リアルタイム | 次のステップとしてリアルタイムを学ぶと知識が広がります。物事が起きるのとほぼ同時に、遅れなく処理や反映が行われること、それがリアルタイムだ |
| アイコン | アイコンを押さえると本記事の理解がさらに深まります。アプリやファイル、操作ボタンなどをひと目でわかる小さな絵で表したもの、それがアイコンだ |
| ボトルネック | 次のステップとしてボトルネックを学ぶと知識が広がります。システムや業務プロセスの中で全体の処理能力・スループットを制限している最も遅い・詰まっている箇所のこと。瓶の首（ボトルネック）が水の流れを制限することに由来する |
| Azure | Azureは関連分野でよく登場する重要キーワードです。Microsoftが提供する、サーバーやAI・データベースをネット経由で借りられるクラウドサービスの総称のこと！ |
【出典】参考URL
https://spring.io/projects/spring-batch ：Spring Batch公式サイト
https://airflow.apache.org ：Apache Airflow公式サイト
https://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html ：AWS Batch公式ドキュメント
コメント