🙄
バッチ処理がなぜ嫌われるのか、嫌われないようにするには
バッチ処理への向き合い方を改めようと思い
背景
チーム内の会話で「バッチこれ以上増やしたくないよね」となり、どうやらバッチ処理はチーム内で嫌われている様子が伺えた
なぜ、とどうすれば良いのか、を明確にしたく世間の意見を調査
なぜ嫌われているのか
嫌われる理由例
- 処理が重くリソースを圧迫する
- 私のチームは数ヶ月前までアプリケーション用のサーバとバッチ用のサーバが共用でした
- バッチ処理によってCPU使用率のアラートが出たりも
- バッチ内の処理がブラックボックス化しがち
- バッチ内の処理は大抵が複雑で、改修が必要になると頭が痛くなる
- 処理の遅延によってユーザーの業務に影響が出ることがある
- ひとつのモデルに対するデータ更新の箇所が分散して分かりにくくなる
- とあるステータス用のカラムが、画面上で更新されたりモデルイベントで更新されたりバッチで更新されたり、、、考慮すべきことが増える
などなど
嫌われたバッチ例
- システム間の連携
- 5分に１回連携元のデータ取得APIを叩いてデータを連携
- 5分に１回しか実行できない上に、１度に連携できるデータ量に上限があり、運用などで大量にデータ更新をすると遅延が発生する
- 月次のデータ更新バッチ
- 処理が重く毎回エラーで落ちるため都度手動で再実行が必要
なぜバッチ処理なのか
- 大量のデータを処理する必要がある
- タイムスケジュール実行する必要がある
などなど
今ほどコンピュータの性能が高くない時代では、リソース状態を良く保つために「業務時間にリクエストをためて、夜間にまとめて処理をする」という方法が主流だった(らしい)
現在はコンピュータの性能が高くなっている上にさまざまな便利ツールができているので、バッチ処理にすべきか別の方法をとるべきかを都度考える必要がある
どうバッチ処理を使うか
会社の上長に教えていただいたこちらが参考になりました
大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』
すべて書くと長くなるので気になったtipsを抜粋
- 処理ワーカーが自動スケールされる
- システム運用期間が長くなるほどデータは増え、バッチ処理は重くなる一方
- データ量増えても落ちずに処理できるようスケーラブルにしておくべき
- 現在日時に依存する処理を入れない
- 再実行したときに現在日時ではなく処理実行日時などを見るようにすべき
- 冪等性を担保しよう
- 再実行したときに現在日時ではなく処理実行日時などを見るようにすべき
- 自動リトライをする
- 自動リトライを任せられるツールがあるらしい(一部知っているものもあるが使ったことはない)
- Apache Airflow
- Digdag
- Argo Workflows
- Step Functions
- GCP Workflows
- 自動リトライを任せられるツールがあるらしい(一部知っているものもあるが使ったことはない)
- ひとつひとつの処理を小さくする
- バッチの処理は大きくなりがち
- 失敗した際の再実行時間を短くできる
- コードが読みやすくなる
- 脱ブラックボックス
感想
わいはバッチのこと嫌いじゃないで
参考
Discussion