「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
バッチEXEの実装方式
注意点 †
バッチ処理の方式を検討する上で以下の点に注意する。
- 例えば１万件の処理を行うにあたり、１万件分のデータをメモリに保持するよう処理を実装する。
すると、ページングによる性能劣化や、メモリ リーク、アウト オブ メモリ例外が発生する。
- シーケンシャル アクセスの中間ファイルを使う概念が無く、全てデータベースへの入出力で処理を行う。
すると、無駄なDBMSとのプロセス間通信のラウンドトリップや、ランダム アクセスで性能が劣化する。
- トランザクション分割の概念がなく、１つの巨大なトランザクション処理を行う（ロング トランザクション）。
すると、（ロング トランザクションでは）ロックを長時間ホールドしたり、ロールバックに長い時間がかかる。
- リランを行う概念がなく、１レコードでも失敗すると全ての処理が失敗する。
すると、リラン時に、常に最初からの開始となってしまうため、
処理時間が長いバッチは時間内に処理を完了することができない可能性がある。
- 並列処理前提のプログラムと単一処理前提のプログラムの違いが分からずに実装する。
すると、後々、処理の多重化（システム リソースを使い切って処理時間を短縮すること）などのチューニングができなくなる。
- 実行ファイルを分割する概念がなく、全て１つの実行ファイルで処理する。
すると、タスクを組み合わせて１つのジョブにすることができなくなる。また、リランに時間がかかることもある。
バッチ処理フレームワーク †
Spring Batch を参考に方式を参考にして、上記の問題を起こさない、多重化＆リラン可能なバッチ処理方式を説明する。
Spring Batchの多重化＆リランは、オンライン側を排他で止めておくことが前提で、反復不可、ファントムは発生しない前提とする。
トランザクション範囲 †
反復不可、ファントムの問題は無い前提のため、トランザクション範囲は、下図の（処理 → Write）の範囲とする。
（コミット インターバル分、データを渡す）
↓
Read ────>（処理 ──> Write）
↑ │
└───────────┘loop
多重化方法 †
- バッチEXEを多重起動する（Javaと異なりマルチスレッド化する必要はない）。
- それぞれのバッチEXEが処理する結果セットを分割する。
- これには、バッチEXE起動時に結果セット取得に使用する
検索条件（分割キー、主キー範囲）のコマンドライン引数を変更する。
リラン †
- 異常終了時は、所定のディレクトリに次回、再開の行番号を出力する。
- 多重起動することを考慮すると下記を１つのファイルで管理すると良い。
- 「結果セット取得に使用する検索条件」
- 「再開の行番号（処理済みの行番号）」
分散多重処理対応 †
複数のバッチ処理サーバ。
分散多重処理の状態の一元管理には、
別途管理データベースなどの利用が必要になることがあり大掛かりになる。
バッチ処理のフロー †
集計処理の場合、DBMSを使用しない場合は、コミットインターバルは不要。
オンラインバッチ処理方式 †
Windows NT系カーネルでは、
- コマンドライン起動で
- startコマンドを用いなければ同期実行
- startコマンドを用いれば非同期実行
が可能である。
- Processクラスを使用する場合は、
- Startメソッドを用いれば非同期実行
- WaitForExit?メソッドを用いれば同期実行
となる。
なお、非同期実行を行う場合、連打できてしまうので、
Semaphoreなどを使用して多重実行を防ぐ必要がある。
同期実行 †
ASP.NETからの同期実行 ＆ セマフォ を使用してバッチの多重度を制御することも可能であるが、
これではオンライン処理が待機によりスレッドを占有してしまい同時実行性が低下する場合がある。
非同期実行 †
非同期実行では上記問題は発生しないが、場合によっては、
多重度・リトライ、結果通知などの制御・実装が必要となってくる。
- 非同期実行で多重度・リトライなどの制御が必要になる場合は、
キュー（ディスク、RDB、MQなど）を用意して多重度・リトライを制御することも可能である。
- 実行結果の通知方法（プッシュ型通知、プル型通知）を検討しておく必要がある。
多重度・リトライ、結果通知などの制御・実装が必要となる場合、”Open棟梁”の非同期処理サービスを利用できる。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
