Macchinetta Batch 2.xの注意点について
ここでは、各節で説明しているMacchinetta Batch 2.xを利用する際の、ルールや注意点についてリストにまとめる。 ユーザはバッチアプリケーションを開発する際、以降に示すポイントに留意して進めてほしい。
|
ここでは、特に重要な注意点を挙げているのみであり、あらゆる検討事項を網羅しているわけではない。 ユーザは必ず利用する機能を一読すること。 |
-
単一のバッチ処理は可能な限り簡素化し、複雑な論理構造を避ける。
-
複数のジョブで同じことを何度もしない。
-
システムリソースの利用を最小限にし、不要な物理入出力を避け、メモリ上での操作を活用する。
-
JavaConfig版の利用
-
前バージョンからの移行でない限り、原則としてJavaConfig版を利用する
-
-
-
1ジョブ=1Bean定義(1ジョブ定義) として作成する
-
1ステップ=1バッチ処理=1ビジネスロジック として作成する
-
-
-
大量データを効率よく処理したい場合に利用する。
-
-
-
シンプルな処理や、定型化しにくい処理、データを一括で処理したい場合に利用する。
-
-
-
スケジュールどおりにジョブを起動したり、複数のジョブを組み合わせてバッチ処理行う場合に利用する。
-
-
-
ディレード処理、処理時間が短いジョブの連続実行、大量ジョブの集約などに利用する。
-
-
-
DBポーリングと同様だが、起動までの即時性が求められる場合にはこちらを利用する。
-
-
JobRepositoryの管理
-
Spring Batch はジョブの起動状態・実行結果の記録に
JobRepositoryを使用する。 -
Macchinetta Batch 2.xでは、以下のすべてに該当する場合は永続化は任意としてよい。
-
同期型ジョブ実行のみでMacchinetta Batch 2.xを使用する。
-
ジョブの停止・リスタートを含め、ジョブの実行管理はすべてジョブスケジューラに委ねる。
-
Spring Batchがもつ
JobRepositoryを前提としたリスタートを利用しない。
-
-
-
これらに該当する場合は
JobRepositoryが使用するRDBMSの選択肢として、インメモリ・組み込み型データベースであるH2を利用する。 一方で非同期実行を利用する場合や、Spring Batchの停止・リスタートを活用する場合は、ジョブの実行状態・結果を永続化可能なRDBMSが必要となる。
この点については、ジョブの管理も一読のこと。
-
チャンクモデルとタスクレットモデルの使い分けも一読のこと。
-
Tasklet実装では、Injectされるコンポーネントのスコープに合わせる。
-
Composite系コンポーネントは、委譲するコンポーネントのスコープに合わせる。
-
JobParameterを使用する場合は、
stepのスコープにする。 -
Step単位でインスタンス変数を確保したい場合は、
stepのスコープにする。
-
チャンクサイズを調整する
-
チャンクを利用するときは、コミット件数を適度なサイズにする。サイズを大きくしすぎない。
-
-
フェッチサイズを調整する
-
データベースアクセスでは、フェッチサイズを適度なサイズにする。サイズを大きくしすぎない。
-
-
ファイル読み込みを効率化する
-
専用のFieldSetMapperインタフェース実装を用意する。
-
-
並列処理・多重処理
-
出来る限りジョブスケジューラによって実現する。
-
-
分散処理
-
出来る限りジョブスケジューラによって実現する。
-
-
インメモリデータベースの使用
-
長期連続運用するには向かず、定期的に再起動する運用が望ましい。
-
長期連続運用で利用したい場合は、定期的に
JobRepositoryからデータを削除するなどのメンテナンス作業が必須である。
-
-
登録ジョブの絞込み
-
非同期実行することを前提に設計・実装されたジョブを指定する。
-
-
性能劣化もあり得るため、超ショートバッチの大量処理は向いていない。
-
同一ジョブの並列実行が可能になっているので、並列実行した場合に同一ジョブが影響を与えないようにする必要がある
-
基本的な検討事項は、非同期実行(DBポーリング)と同じ。
-
スレッドプールの調整をする。
-
非同期実行のスレッドプールとは別に、Webコンテナのリクエストスレッドや同一筐体内で動作している他のアプリケーションも含めて検討する必要がある。
-
-
Webとバッチとでは、データソース、MyBatis設定、Mapperインタフェースは相互参照はできない。
-
スレッドプール枯渇によるジョブの起動失敗はジョブ起動時に捕捉できないので、別途確認する手段を用意しておく。
-
「ItemWriterに
MyBatisBatchItemWriterを使用する」と「ItemProcessorでMapperインタフェースを使用し更新処理をする」は同時にできない。-
MyBatisには、同一トランザクション内で2つ以上の
ExecutorTypeで実行してはいけないという制約があるため。 Mapperインタフェース(出力)を参照。
-
-
データベースの同一テーブルへ入出力する際の注意点
-
読み取り一貫性を担保するための情報が出力(UPDATEの発行)により失われた結果、入力(SELECT)にてエラーが発生することがある。 以下の対策を検討する。
-
データベースに依存になるが、情報を確保する領域を大きくする。
-
入力データを分割し多重処理を行う。
-
-
-
以下の固定長ファイルを扱う場合は、TERASOLUNA Batch 5.xが提供する部品を必ず使う。
-
マルチバイト文字を含む固定長ファイル
-
改行なし固定長ファイル
-
-
フッタレコードを読み飛ばす場合は、OSコマンドによる対応が必要。
-
複数ジョブを同時実行する場合は、排他制御の必要がないようにジョブ設計を行う。
-
アクセスするリソースや処理対象をジョブごとに分割することが基本である。
-
-
デッドロックが発生しないように設計を行う。
-
ファイルの排他制御は、タスクレットモデルで実装すること。
-
例外ハンドリングではトランザクション処理を行わない。
-
処理モデルでChunkListenerの挙動が異なることに注意する。
-
リソースのオープン･クローズで発生した例外は、
-
チャンクモデル…ChunkListenerインタフェースが捕捉するスコープ外となる。
-
タスクレットモデル…ChunkListenerインタフェースが捕捉するスコープ内となる。
-
-
-
入力チェックエラーは、チェックエラーの原因となる入力リソースを修正しない限り、リスタートしても回復不可能である
-
JobRepositoryに障害が発生した時の対処方法を検討する必要がある。
-
ExecutionContextはJobRepositoryへ格納されるため、以下の制約がある。-
ExecutionContextへ格納するオブジェクトは、java.io.Serializableを実装したクラスでなければならない。 -
格納できるサイズに制限がある。
-
-
Javaプロセス強制終了時の終了コードとバッチアプリケーションの終了コードとは明確に区別する。
-
バッチアプリケーションによるプロセスの終了コードを1に設定することは厳禁とする。
-
-
Multi Thread Stepは利用しない。 -
処理内容によっては、リソース競合とデッドロックが発生する可能性に注意する。