スポンサーリンク

バッチ処理の要件定義や設計をする場合のチェック観点はどこ!

バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。
日本語では「一束、一群、一団」といった意味があります。
つまりバッチ処理とは“一定量の(あるいは一定期間の)データを集め、一括処理するための処理方法”です
この反対の言葉として、オンライン処理があります。「リアルタイム処理」の反対語っぽいイメージで良いと思います。
オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。
バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にします。

バッチ処理を利用するのは?場所や人は

 場所や時間に囚われずにデータ処理が可能バッチ処理は一定量集計したデータをまとめて処理するという特性上、オペレーターがその場に居合わせる必要はありません。
タスクスケジューリングを行うことで、好きな日時にデータ処理を行わせることができるのです。
夜間や祝日など業務時間外にデータ処理を設定することも可能なので、時間をフル活用することができます。

バッチ処理化するメリットは

1.自動化できる
2.忙しく無いときに実行できる

バッチに利用されるプログラミング言語は大まかに2種類

・コンパイル言語…人間語で書いたものを機械語に訳す言語。Cとか
・スクリプト言語…書いた処理を1行ずつ読んでいく言語。RubyとかPythonとか

保存先

目的や用途に応じてファイルシステムに保存するのかRDBに保存するのかを検討します。
 

処理件数

バッチ処理が1回起動するごとに対象となる処理件数の見積です。
業務要件を読み解くことが重要となります。既にオンラインで行っている処理をバッチ処理に移行する場合は、そこから計測して求めます。これから始める業務の場合は、企画担当者が考えている利用数の想定曲線から求めます。1ヶ月後、3ヶ月後、半年後、そして1年後までを、大まかに低利用率・中利用率・高利用率の別で求められると良いでしょう。

処理時間

バッチ処理を設計するにあたり、まず取りかからねばならないのが時間のことです。3つの観点で考えていきます。
  • いつ起動するか
  • いつまでに終えなければならないか
  • どのくらい処理時間がかかりそうか

回復可能か

バッチ処理は、不幸にも何らかの理由で途中で異常終了する可能性があります。このときに、その事態を回復可能にできるよう設計しておく必要があります。以下の優先順位で事前に対策を取ります。
  • 処理が完了した次のデータから処理が再開できる
  • 再度同じ処理が開始されるが、結果が冪等になる(二重に処理されない)
  • 失敗したIDを控えることができ、再実行できるコマンドオプションを用意する

多重起動可能か

多重起動可能かどうかは、業務の性質によります。多重起動により処理するデータを破壊しかねない場合は、実行をロックできる機構を設けましょう。

運用時に考えること・手数を減らしたい

データのライフサイクル バッチ処理結果データの保持期限・削除基準は決まっているか?
  •  保持期限を過ぎたデータを削除する処理は実装されているか?
ログ出力 処理失敗時に事態を把握するため、バッチ処理を行う対象データの範囲、バッチ処理の開始時刻・終了時刻をログに出力しているか
  •  処理失敗時、途中から再開できるようにどの処理・どの行でコケたかを出力しているか
  •  パフォーマンス劣化を監視するためのバッチ処理の所用時間を開始時刻・終了時刻から毎回計算せずとも済むようにログに出力しているか
  •  終了見込み時間を報告できるようにするため、処理の進捗状況が分かるようなログを出力しているか
  •  ログからコピペしてすぐにlessできるように結果ファイルの絶対パスを出力しているか
  •  ログローテーションの設定はされているか?
冪等性 処理が途中で失敗したりkillされたとしても、再実行するだけでリカバリ可能なロジックになっているか?
実行条件の判定 処理に必要なディレクトリやファイルの有無は事前にチェックしているか?
  •  前処理が失敗している場合、無理やり動かずちゃんとエラーで落ちるか?
範囲指定での実行 バッチが複数回動作しなかった場合、手動実行を回数分ループさせてリカバリが必要な処理か? 実行時に引数で範囲指定して一括実行ができるか?
  •  リカバリ作業の内容がルーチン化できる内容か? リカバリ作業をワンボタンで行えるようにコマンド化しているか?
多重起動防止 前回の処理が生き残っている間に次の処理が動くと不具合があるか? 処理が多重起動しないようにロックファイルを生成しているか?
    •  処理途中にコケてもロックファイルが削除されるか?
起動禁止ファイル 運用上、ジョブが混雑している等で一時的に動作を止めておきたいケースはあるか? crontabのコメントアウト処理忘れなど、オペミスをなくすために停止ファイルを参照して起動防止をしているか?
オペミス防止のために 実行時の引数に応じてログだけ吐き出すdryrunオプションはあるか?
  •  手動実行時、入力された引数から処理内容を確認させるダイアログは出しているか?

まとめ

ジョブにも要件定義や設計が運用まで考える必要がありますね。

(Visited 8 times, 1 visits today)
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク