バッチ処理とは
CSVなどの大量データを持つファイルを１行ずつ読み込んで処理するもの。
一般的なバッチ処理
- CSVなどをShellなどで読み込んだり、DBへインポートしたりする。
- ETLツールでファイル⇨DB、DB⇨DBなどの変換処理を行う。
上記の特徴として、対外的なAPI呼び出しは無いことが多いと思われる。
APIを呼び出すバッチ処理
DBやローカルディスクのみを相手にしてきたバッチ処理とは異なる課題がある。
APIは遅い
SaaSの場合、（通信速度は）遅い。
APIは早い
SaaSの場合、（処理速度は）速い。
APIは並列実行性に優れる
多数の呼び出しが想定されているため、並列実効性に優れる。
APIは失敗する
APIごとの制約があり、それに抵触する場合、エラーとなり、失敗する。
- スロットリング
- API側事情
ロールバックできない（結果整合性で担保する）
DBと異なり、ロールバック機能を有していないため、ワンアクションで処理前の状態に戻すことはできない。
このため、適切なロールバック処理を考える必要がある。
APIを呼び出すバッチ処理の方法論
バッチ処理APIを作れないか交渉する
呼出先のAPIが一つのSaaSから提供されており、深いリレーションが築けているならば、交渉する。
具体的にはリストデータの受付をできるか交渉する。
並列処理を行う
効率性を上げる。
もちろん、最初は単一プロセスで動作確認をしてから。
また、並列度は呼出先のAPIのスロットリングの上限を把握するか、抵触しない範囲で、
こちら側の要求を満たす時間幅で考える。
失敗時の動作を設計する
- リトライの方針を検討する
- 即時
- 次回繰越
- 繰越上限（＝運用調査トリガー）
- 失敗ログの残し方を検討する
- ロールバック（結果整合性の担保）方法を検討する