バッチ処理の基本と運用¶
原文¶
解説) バッチ処理
銀行から不動産まで幅広く動くバッチ処理。エンジニアは全員、バッチ処理とは何で、どのように動いているのかを知った方がいい。
日々決まった時間に自動で実行される処理を一般にバッチ処理といい、Linux ではcron, AWSではEvent Bridge Scheduler などの各機構で時間を設定しておいて日々決まった処理を動かすことができる。
メディア、不動産など毎日大量のデータを処理して反映するシステムを始め、アプリを動かすためにリアルタイムで計算をしていては時間がかかるような処理は深夜帯などサービス影響が低い時間バッチで事前処理を行っておくと、リアルタイムでスムーズな動作が実現できる。
実務面に関していうとバッチが成功/失敗したかどうかのSlackなどへの通知と、失敗した場合のリトライ（可能な場合自動リトライが望ましい）までできることが必要。
バッチは作って終わりではなく日々成功/失敗しているかの監視までが必須なので注意。
要約¶
バッチ処理は定時自動実行の処理。cron/EventBridgeなどで時間指定して動かす。リアルタイムでやるには重い処理を深夜帯に前計算して、ユーザー体験をスムーズにする用途が主。作って終わりではなく、Slack通知・リトライ・監視まで実装して初めて完成。
解説¶
実行基盤の選択肢¶
| 基盤 | 特徴 | 典型用途 |
|---|---|---|
| cron | Linuxサーバー内。シンプル | 単一サーバーで完結する処理 |
| AWS EventBridge Scheduler | マネージド。Lambda/ECSと連携 | サーバーレスなバッチ |
| GCP Cloud Scheduler | HTTP/Pub-Sub起動 | GCPネイティブ |
| Kubernetes CronJob | K8Sクラスタ内 | K8S運用済みなら |
| Airflow / Dagster | DAG管理、依存関係 | 複雑なデータパイプライン |
バッチが失敗したときのパターンと対応¶
| 失敗パターン | 対応 |
|---|---|
| 一時的エラー（ネットワーク、DB一時不可） | 自動リトライ（指数バックオフ） |
| 入力データ不正 | スキップ or DLQ送り、通知 |
| 処理途中停止 | 冪等設計で再実行可能に |
| 実行時間超過 | タイムアウト設定、分割実行 |
監視の最低ライン¶
- 実行結果通知: 成功/失敗をSlack等へ
- 実行時間メトリクス: 長期化トレンドを見る
- エラーアラート: 閾値超え時にPagerDuty等
- 実行履歴: 過去N回の結果が追える
→ 関連: Sidekiqチューニング（非同期処理の文脈）