バッチ処理を作る必要があるときに、考えているようなことをまとめておく。
はじめに
バッチは機能の実現方式であって、機能そのものではないと思っている。
なので、バッチ処理は単独で考えるものではないというのが前提。
とはいえバッチという手段を選んだ場合に、その手段故に考えておいたほうがいいことがあるのは確か。
思いつくままに
バッチ処理固有ではないものもあるけど、思いつくままに列挙しておく。
- 実行周期
- 日次とか月次とか
- 手動とか(リランや任意のタイミングでの実行とか)
- 実行タイミング
- 夜間とか早朝とか
- 処理時間
- 始まってから終わるまでどれくらいかかるか?
- 負荷
- 特に他システムとの兼ね合い
- オンラインでも使ってるDBを見に行くとか
- API コール数の制限とか
- 特に他システムとの兼ね合い
- 並列度
- 並列実行させるか(できればさせたくないが)
- させるなら同期をどうやって実現させるか
- 並列実行させるか(できればさせたくないが)
- 処理件数
- リラン設計
- 失敗時どうするか
- デプロイやメンテナンス等で意図的に止めたい場合どうするか
- 冪等なども観点に含める
- 動かなかったときに、何が起こるか?
- 後続ジョブやオペレーション
- リトライ設計
- 自動で何度かリトライするか
- 通知
- エラー等の通知方法やレベル
- ログ設計
- テスト設計
- 限界はあるが、できるだけ容易にテストや動作確認ができるように
- データ用意のコスト
- 任意タイミングでの実行
- パラメータを任意に変更できるように
- etc
- 限界はあるが、できるだけ容易にテストや動作確認ができるように