Chapter 3 バッチ処理の方式/戦略 (1)

バッチシステムの設計と実装の手助けとなるような、基本的なバッチアプリケーションのビルディングブロックとパターンがサンプルチャートやコード抜粋の形で設計者とプログラマーに提供されるべきであろう。バッチジョブを設計するに当たっては、ビジネスロジックは実装可能な以下に示す標準的なビルディングブロックを用いた一連の処理ステップ(a series of steps)へ分解される必要がある。

変換アプリケーション(Conversion Applications)

外部システムに対して生成するまたは外部システムから供給されるファイルの各タイプに応じて、トランザクションのレコードを処理するために必要となる標準的な形式に変換するアプリケーションが必要になる(場合がある)。この種のバッチアプリケーションは部分的または全部がユーティリティ的なモジュールから構成される場合がある(「基本バッチサービス」を参照)

検証アプリケーション(Validation Applications)

検証アプリケーションは、全ての入力/出力レコードが正しく整合性が保たれているかを保証する。検証処理はファイルヘッダーやトレイラー、チェックサムやレコード単位のクロスチェックと同様の検証アルゴリズムを用いて行われる

展開アプリケーション(Extract Applications)

データベースや入力ファイルから、レコードのセットを読み込み、あらかじめ決められたルールに基づいてレコードを選択し、出力ファイルへレコードを書き出すアプリケーション

展開/更新アプリケーション(Extract/Update Applications)

データベースや入力ファイルから、レコードを読み込み、各入力レコードのデータに応じてデータベースや出力ファイルへ変更(更新)を行うアプリケーション

処理&更新アプリケーション(Processing and Updating Applications)

展開アプリケーションや検証アプリケーションからの入力トランザクションを処理するアプリケーション。通常、この処理は処理に必要なデータを得るためにデータベースを読み込み、場合によってはデータベースを更新ないし出力処理用にレコードを新規生成する

出力/フォーマットアプリケーション(Output/Format Applications)

入力ファイルを読み込み、レコード内容を標準的な形式に適した形に再構築して他のプログラムやシステムへ転送したり、印刷用の出力ファイルを生成したりするアプリケーション。
さらには、上述のビルディングブロックを使用して構築できないようなビジネスロジックのために、基本的なアプリケーションシェルが必要になることもある。
主なビルディングブロックに加え、各アプリケーションは以下のような標準ユーティリティのステップを1つないし複数利用する場合があるだろう。

ソート(並べ替え)

入力ファイルを読み込み、レコード内のソート用のキーとなるフィールドに応じて順番を並べ替え、そのレコードを出力ファイルへと処理する。ソートは通常、標準的なシステム(訳者註：OSのsortコマンドなどのことを指すと思われる)ユーティリティが利用される。

スプリット(分割)

1つの入力ファイルを読み込み、そのフィールドの値に基づいて複数の出力ファイルのどれかへと各レコードを書き出す。スプリット処理はパラメータ指定した標準的なシステムユーティリティによって行われることもあれば、カスタム開発される場合もある

マージ(併合)

複数の入力ファイルからレコードを読み取り、それらのファイルからのデータを組み合わせたデータを1つの出力ファイルへと処理する。マージ処理はパラメーターを指定した標準的なシステムユーティリティで行われることもあれば、カスタム開発される場合もある
さらに、バッチアプリケーションは入力データによってカテゴリ分けすることができる。

データベース駆動型

データベースから取得する行や値に基づいて動作する

ファイル駆動型

ファイルから取得するレコードや値に基づいて動作する

メッセージ駆動型

メッセージキューから取得するメッセージに基づいて動作する

あらゆるバッチシステムの基礎となるのは、その処理方式(processing strategy)である。処理方式の選択にあたって影響を及ぼす要因としては、以下のようなものがある：

バッチ処理システムの想定ボリューム
オンライン処理との同時実行性
他のバッチ処理との同時実行性
利用できるバッチウィンドウ(企業はどんどん稼働中の状態つまり24x7の稼動を求めており、このことは明確なバッチウィンドウというものがもはや無くなってくることに繋がってくる)

バッチ処理の典型的な処理方式の選択肢を以下に挙げる：

オフライン時間帯の、バッチウィンドウ内での通常処理
バッチとオンライン処理との同時実行
多数の異なるバッチ処理の並列実行、または一時点での同時実行
パーティショニング(区分化処理)(例：同一ジョブの多数のインスタンスが、同時に処理)
上記の組み合わせ

上記のリストの順番は、そのままその実装時の複雑さを表している。つまり、バッチウィンドウでの処理が最も実装が容易で、逆に区分化処理が最も困難である。
これらの内いくつかまたは全ての処理方式は、商用のスケジューラー製品でサポートされているものもあるだろう。
以下のセクションでは、これらの処理方式をもっと詳細に議論していくことにする。バッチ処理によって採用されるコミットとロック戦略は処理方式の種別に依存しているということが重要な点である。オンラインのロック戦略と同じ原則を利用する。従って、バッチアーキテクチャは全体のアーキテクチャを設計する場合、単純に後から思いつけるようなものではない。
ロック方式は、通常のデータベースが実装するロックのみを利用するか、またはアーキテクチャにおいて実装される別のカスタムロックサービスを利用して実現する。ロックサービスは(たとえば専用のDB上テーブルに必要な情報を保持することで)アプリケーションプログラムがDB操作を要求することを許可したり拒否したりするものである。バッチジョブがロックを必要とする状況で異常終了してしまうのを回避するために、リトライロジックもこのアーキテクチャを利用して実装されるかもしれない。