バッチ処理システムの設計フェーズで考えること

はじめに

• バッチ処理システムを設計するときに考えることのメモ

参考

• バッチ処理について考える

バッチ処理システムを設計するときに考えること

システム構成

• オフラインバッチかオンラインバッチか
  • 観点が変わってくる
• ジョブスケジューラは何か

プログラム実装

機能面

• IFのIn/Outをきっちり固める
  • 連携項目、データ型
  • 連携プロトコル
• DFD・シーケンス図を書いて、「処理フロー」と「データ（ファイル、テーブル、etc）」を網羅的に確認
  • 作成、更新、削除の観点で確認
  • 異常終了時のリカバリの観点で確認
    • 処理が冪等か。途中で落ちたときにゴミが残らないか。リランでよいか。
      • 可能な限りDBで完結させてトランザクションを作る
      • 一時テーブルや一時ファイルを作ってやりなおすポイントを作る
    • ジョブを高速化してやり直しのペナルティを小さくする
  • バックアップ、改廃の観点で確認
• 障害切り分け、パッチを当てられる設計になっているか
  • created_at, updated_at, deleted_at
• 業務日付
  • DBにbatch_success_runを持つなど
• 初期移行は問題なく実施できるか
• モード切り替えの環境変数を持たせる必要はあるか
  • 洗い替えしたいときがあるか
  • 不要な処理をスキップしたいときがある（パッチを当てるときなど）

非機能面

• バッチウィンドウはいつからいつか
• 処理は早く。（ただし、運用を考えてできるだけシンプルに。）
  • 並列処理にすべき箇所はあるか
    • LoadはBulk InsertやSelect Insertを使う。
      • 1件1件Insertしてコミットとかは典型的なミス
    • Extract/Transform部分はなるべく並列度を上げる、Loadは並列度をコントロール
  • 一時テーブルを作ったりしてDB内で完結させてI/Oコストを下げるべき箇所はあるか
  • インデックスを貼るべき箇所はあるか
    • 過剰にインデックスを貼らずにフルスキャンでも目的の性能が出ないかは検証
    • オンライン処理なら、Insertコストを極小化するためにインデックスはなるべく貼らない
• APIの制約はあるか
  • レートリミット、月間発行数上限など

障害時対応

• どこで処理が落ちたら（遅れたら）、どこ（他システム）に影響があるか
• 処理時間と件数の推移はモニタリングしておく

リリース

• メンテナンスウィンドウはいつからいつか
  • データの静止点を取ることができるか
• リリースが遅れたら、どこ（他システム）に影響があるか