今までお仕事でバッチ処理設計に携わることが多かったので、バッチ処理設計の考慮点をまとめておく。主に非機能要件に関するところである。

考慮点一覧

• バッチ稼動
  • 前提条件と起動トリガー
  • 実行タイミング（スケジュールと処理時間）
  • 同時に動くバッチとの兼ね合い
  • 環境依存の値は変数に
• データ入出力
  • ログ出力
  • データの入出力形式
  • 処理データ量（ファイル分割 or 分割コミット）
• 例外処理
  • アラート通知方針
  • バッチがエラーとなったときの影響
  • リカバリ対応方針
  • 後続バッチへの影響

バッチ稼動に関する点

バッチが動くためには前提条件がある。Aファイルが存在すること・Xバッチが正常終了していることなどである。これは、バッチの起動トリガーを考えておくことにも繋がる。例えば、起動トリガーが他システムから転送されてくるファイルであれば、他システムに自システムが依存することになる。他システムが止まってしまうと自システムも停止する。それで良いのか、ダメなのかを考えて、トリガーを設定する必要がある。

バッチが動き始める時刻や動いている時間も重要である。他のバッチ処理と並行で稼働しても問題ないかを検討しておく必要がある。

ちょっとしたテクニックだけど、環境依存の値は環境変数に持たせるようにしよう。サーバが変わった時に死ぬほど苦労することになる。

入出力に関する点

ログ出力の方針を決めておく。どこのファイルに、どれだけ出力するのかを決めておく。バッチ処理でデータが処理されていないなどの障害が起きた時に、過去に遡れるようにしておく必要がある。1ヶ月分あれば良いのか、1年分が必要なのかを検討する。ログの保持期間は日次処理 or 月次処理でも変わるだろう。

バッチ処理でファイルを入出力する場合に、ファイルの形式（CSV）や文字コード、改行コードを決めておく。

処理データ量が増えた時のことも考えて設計しておく。例えば、大量データを処理するときは、DBのUNDO領域を考慮して分割コミットする手段がある。他にも、インプットのデータを細切れにして処理していく手段もある。個人的には、インプットデータを細切れにする方が良いと思っている。どこまで処理したが分かるようになっていれば、リカバリが簡単になるからだ。

例外処理に関する点

アラートは、即連絡通知 or 翌日連絡 などの通知方法を考えておく。バッチの重要度に応じて通知方法を変える。1つでもエラーデータがあった時に、バッチ自体エラーとする or 不正データはskipして通知 などの検討も必要である。このタイミングで、エラーやワーニングの一覧があるとリカバリ対応がやりやすくなる。

次は、一番重要なリカバリ方針である。リカバリ方針は、リランするだけ or データを変更してリラン など、様々なパターンが考えられるので、どの方針かを決めておく。もちろん、想定外のエラーは個別の対応が必要となる。ここでは想定可能なエラーの対応方針を決めておくという話しだ。

バッチ処理は冪等性を持たせておくのが良いと考えている。冪等性を持たせておけば、基本的に再実行する方針となるはず。

複数日、稼働しなかった時の対応についても考えておく。エラー対応に複数日かかるというのも十分に考えられるし、サーバメンテナンスで複数日かかる事もあるだろう。複数日動かなかった時にどう復旧するか？という点も考えて設計しておきたい。可能であれば、複数日動かなくても、次のバッチ処理でまとめて処理できると良い。

バッチの不具合で不正なデータが出来ていた時に、どうリカバリできるかも検討しておきたい。これは、処理前のデータを置いておくしかないので、DBのバックアップ設計に影響する。

また、エラー発生時に何が影響を受けるか？も検討しておく。後続バッチ処理への影響があるならば、後続バッチ処理を止める必要があるし、影響がないのであれば後続バッチ処理は継続しても良い。直接的な影響がなくても、データがおかしくならないかという点も十分に考えておく必要がある。他システムへの影響も考慮しておくこと。