Spring Batch アーキテクチャ

バッチソリューションを構築するときは、次の主要な原則、ガイドライン、一般的な考慮事項を考慮する必要があります。

バッチシステムの設計と実装を支援するために、基本的なバッチアプリケーションのビルドブロックとパターンを、サンプルの構造ビューとコードシェルの形式で設計者とプログラマーに提供する必要があります。バッチジョブの設計を開始するときは、ビジネスロジックを次の標準的な構成要素を使用して実装できる一連の手順に分解する必要があります。

さらに、前述のビルドブロックを使用して構築できないビジネスロジック用に、基本的なアプリケーションシェルを提供する必要があります。

主なビルドブロックに加えて、各アプリケーションは、次のような 1 つ以上の標準的なユーティリティステップを使用する場合があります。

バッチアプリケーションは、入力ソースによってさらに分類できます。

バッチシステムの基礎は処理戦略です。戦略の選択に影響を与える要因には、推定バッチシステムボリューム、オンラインシステムまたは他のバッチシステムとの同時実行性、利用可能なバッチウィンドウなどがあります。(24 時間 365 日稼働を望む企業が増えているため、明確なバッチウィンドウが消えつつあることに注意してください)。

バッチの一般的な処理オプションは次のとおりです（実装の複雑さの順）。

これらのオプションの一部またはすべては、有償スケジューラによってサポートされている場合があります。

このセクションの残りの部分では、これらの処理オプションについて詳しく説明します。経験則として、バッチプロセスで採用されるコミットおよびロック戦略は、実行される処理の型に依存し、オンラインロック戦略も同じ原則を使用する必要があることに注意してください。アーキテクチャ全体を設計する際に、バッチアーキテクチャを単に後付けすることはできません。

ロック戦略は、通常のデータベースロックのみを使用することも、アーキテクチャに追加のカスタムロックサービスを実装することもできます。ロッキングサービスは、データベースのロックを追跡し (たとえば、必要な情報を専用のデータベーステーブルに格納することによって)、データベース操作をリクエストするアプリケーションプログラムにアクセス許可を付与または拒否します。ロック状態の場合にバッチジョブの中止を回避するために、このアーキテクチャによって再試行ロジックを実装することもできます。

1. バッチウィンドウでの通常の処理オンラインユーザーまたは他のバッチプロセスが更新中のデータを必要としない別のバッチウィンドウで実行される単純なバッチプロセスの場合、同時実行性は課題にならず、バッチ実行の最後に単一のコミットを実行できます。

ほとんどの場合、より堅牢なアプローチがより適切です。バッチシステムは、複雑さと処理するデータ量の両方の点で、時間が経つにつれて大きくなる傾向があることに注意してください。ロック戦略が設定されておらず、システムがまだ単一のコミットポイントに依存している場合、バッチプログラムの変更は苦痛を伴う場合があります。最も単純なバッチシステムであっても、再起動リカバリオプションのコミットロジックの必要性と、このセクションで後述するより複雑なケースに関する情報を考慮してください。

2. 同時バッチ処理またはオンライン処理オンラインユーザーが同時に更新できるデータを処理するバッチアプリケーションは、オンラインユーザーが数秒以上必要とする可能性のあるデータ (データベースまたはファイルのいずれか) をロックしてはなりません。また、いくつかのトランザクションごとに更新をデータベースにコミットする必要があります。そうすることで、他のプロセスで使用できないデータの部分と、データが使用できなくなる経過時間を最小限に抑えることができます。

物理的なロックを最小限に抑えるもう 1 つのオプションは、論理的な行レベルのロックを楽観的なロックパターンまたは悲観的なロックパターンのいずれかで実装することです。

これらのパターンは必ずしもバッチ処理に適しているとは限りませんが、同時バッチ処理とオンライン処理 (データベースが行レベルのロックをサポートしていない場合など) に使用される場合があります。原則として、楽観的ロックはオンラインアプリケーションにより適していますが、悲観的ロックはバッチアプリケーションにより適しています。論理ロックを使用する場合は常に、論理ロックによって保護されたデータエンティティにアクセスするすべてのアプリケーションに対して同じスキームを使用する必要があります。

これらのソリューションは両方とも、1 つのレコードのロックのみに対応していることに注意してください。多くの場合、論理的に関連するレコードのグループをロックする必要があります。物理ロックでは、潜在的なデッドロックを回避するために、これらを非常に慎重に管理する必要があります。論理ロックを使用する場合、通常は、保護する論理レコードグループを理解し、ロックが一貫性がありデッドロックしないことを保証できる論理ロックマネージャーを構築するのが最善です。通常、この論理ロックマネージャーは、ロック管理、競合レポート、タイムアウトメカニズム、およびその他の問題のために独自のテーブルを使用します。

3. 並列処理並列処理では、複数のバッチ実行またはジョブを並列に実行して、バッチ処理の合計経過時間を最小限に抑えることができます。ジョブが同じファイル、データベーステーブル、またはインデックススペースを共有していない限り、これは問題ではありません。その場合、このサービスは、分割されたデータを使用して実装する必要があります。もう 1 つのオプションは、制御テーブルを使用して相互依存性を維持するためのアーキテクチャモジュールを構築することです。コントロールテーブルには、各共有リソースの行と、それがアプリケーションによって使用されているかどうかが含まれている必要があります。バッチアーキテクチャまたは並列ジョブのアプリケーションは、そのテーブルから情報を取得して、必要なリソースにアクセスできるかどうかを判断します。

データアクセスが問題にならない場合は、追加のスレッドを使用して並列処理を実行することにより、並列処理を実装できます。メインフレーム環境では、すべてのプロセスに十分な CPU 時間を確保するために、従来から並列ジョブクラスが使用されてきました。ソリューションは、実行中のすべてのプロセスのタイムスライスを確保するのに十分堅牢でなければなりません。

並列処理におけるその他の重要な課題には、ロードバランシングと、ファイルやデータベースバッファプールなどの一般的なシステムリソースの可用性が含まれます。また、制御テーブル自体が重要なリソースになりやすいことにも注意してください。

4. パーティショニングパーティショニングを使用すると、大規模なバッチアプリケーションの複数のバージョンを同時に実行できます。これの目的は、長いバッチジョブの処理に必要な経過時間を短縮することです。正常に分割できるプロセスは、入力ファイルを分割できるプロセス、またはアプリケーションをさまざまなデータセットに対して実行できるようにメインデータベーステーブルを分割できるプロセスです。

さらに、分割されたプロセスは、割り当てられたデータセットのみを処理するように設計する必要があります。パーティショニングアーキテクチャは、データベースの設計とデータベースのパーティショニング戦略に密接に結び付ける必要があります。データベースのパーティション化は、必ずしもデータベースの物理的なパーティション化を意味するわけではないことに注意してください (ただし、ほとんどの場合、これは推奨されます)。次の図は、パーティショニングアプローチを示しています。

アーキテクチャは、パーティションの数を動的に構成できるほど柔軟である必要があります。自動構成とユーザー制御構成の両方を検討する必要があります。自動構成は、入力ファイルのサイズや入力レコードの数などのパラメーターに基づいて行うことができます。

4.1 分割アプローチパーティション化アプローチの選択は、ケースバイケースで行う必要があります。以下のリストは、可能なパーティション分割アプローチのいくつかを説明しています。

1. レコードセットの修正済みおよび均等な分割

これには、入力レコードセットを偶数の部分に分割することが含まれます（たとえば、各部分がレコードセット全体のちょうど 1/10 である 10 個）。各部分は、バッチ / 抽出アプリケーションの 1 つのインスタンスによって処理されます。

このアプローチを使用するには、レコード設定を分割するための前処理が必要です。この分割の結果は、バッチ / 抽出アプリケーションへの入力として使用して、その処理をその部分のみに制限できる下限および上限の配置数です。

前処理は、レコードセットの各部分の境界を計算および決定する必要があるため、大きなオーバーヘッドになる可能性があります。

2. キー列で分割する

これには、場所コードなどのキー列によって設定された入力レコードを分割し、各キーからバッチインスタンスにデータを割り当てることが含まれます。これを実現するために、列の値は次のいずれかになります。

オプション 1 では、新しい値を追加するということは、バッチまたは抽出を手動で再構成して、新しい値が特定のインスタンスに確実に追加されるようにすることを意味します。

オプション 2 では、これにより、すべての値がバッチジョブのインスタンスによってカバーされることが保証されます。ただし、1 つのインスタンスによって処理される値の数は、列値の分布に依存します (0000-0999 範囲に多数の場所があり、1000-1999 範囲には少数の場所がある場合があります)。このオプションでは、パーティション分割を考慮してデータ範囲を設計する必要があります。

両方のオプションでは、バッチインスタンスへのレコードの最適な均等分散を実現できません。使用されるバッチインスタンスの数の動的な構成はありません。

3. ビュー別

このアプローチは基本的にキー列による分割ですが、データベースレベルで行われます。レコードセットをビューに分割する必要があります。これらのビューは、処理中にバッチアプリケーションの各インスタンスによって使用されます。分割は、データをグループ化することにより行われます。

このオプションでは、バッチアプリケーションの各インスタンスを、（メインテーブルではなく）特定のビューにヒットするように構成する必要があります。また、新しいデータ値を追加すると、この新しいデータグループをビューに含める必要があります。インスタンス数を変更するとビューが変更されるため、動的構成機能はありません。

4. 処理インジケータの追加

これには、インジケータとして機能する入力テーブルへの新しい列の追加が含まれます。前処理ステップとして、すべてのインジケーターが未処理としてマークされます。バッチアプリケーションのレコードフェッチステージでは、個々のレコードが未処理としてマークされているという条件でレコードが読み取られ、(ロック付きで) 読み取られると、処理中としてマークされます。そのレコードが完了すると、インジケータは完了またはエラーに更新されます。追加の列によってレコードが 1 回だけ処理されることが保証されるため、バッチアプリケーションの多くのインスタンスを変更せずに開始できます。

このオプションを使用すると、テーブルの I/O が動的に増加します。バッチアプリケーションを更新する場合、書き込みは必ず発生するため、この影響は軽減されます。

5. テーブルをフラットファイルに抽出する

このアプローチには、フラットファイルへのテーブルの抽出が含まれます。次に、このファイルを複数のセグメントに分割し、バッチインスタンスへの入力として使用できます。

このオプションを使用すると、テーブルをファイルに抽出して分割する追加のオーバーヘッドにより、マルチパーティションの効果が相殺される場合があります。動的構成は、ファイル分割スクリプトを変更することで実現できます。

6. ハッシュカラムの使用

このスキームには、ドライバーレコードの取得に使用されるデータベーステーブルへのハッシュ列 (キーまたはインデックス) の追加が含まれます。このハッシュ列には、バッチアプリケーションのどのインスタンスがこの特定の行を処理するかを決定するインジケーターがあります。例: 開始するバッチインスタンスが 3 つある場合、'A' のインジケーターはインスタンス 1 で処理する行をマークし、'B' のインジケーターはインスタンス 2 で処理する行をマークし、'C' のインジケーターはマークを付けます。インスタンス 3 で処理する行。

レコードの取得に使用されるプロシージャには、特定のインジケータでマークされたすべての行を選択するための追加の WHERE 句があります。このテーブルへの挿入には、マーカーフィールドの追加が含まれます。マーカーフィールドは、デフォルトでインスタンスの 1 つ（ "A" など）になります。

単純なバッチアプリケーションを使用して、異なるインスタンス間で負荷を再分配するなど、インジケーターを更新します。十分な数の新しい行が追加されたら、このバッチを実行して（バッチウィンドウを除くいつでも）、新しい行を他のインスタンスに再配布できます。

バッチアプリケーションの追加のインスタンスは、バッチアプリケーションを実行するだけで (前の段落で説明したように)、新しい数のインスタンスで動作するようにインジケーターを再配布します。

4.2 データベースとアプリケーションの設計原則

パーティション化されたデータベーステーブルに対して実行され、キー列アプローチを使用するマルチパーティション化されたアプリケーションをサポートするアーキテクチャには、パーティションパラメーターを格納するための主要パーティションリポジトリが含まれている必要があります。これにより、柔軟性が提供され、保守性が確保されます。通常、リポジトリは、パーティションテーブルと呼ばれる単一のテーブルで構成されます。

パーティションテーブルに格納される情報は静的であり、一般に DBA が管理する必要があります。テーブルは、マルチパーティションアプリケーションのパーティションごとに 1 行の情報で構成されている必要があります。テーブルには、プログラム ID コード、パーティション番号 (パーティションの論理 ID)、このパーティションのデータベースキー列の下限値、およびこのパーティションのデータベースキー列の上限値の列が必要です。

プログラムの起動時に、プログラム id とパーティション番号がアーキテクチャ (具体的には制御処理タスクレット) からアプリケーションに渡されます。キー列アプローチが使用されている場合、これらの変数を使用してパーティションテーブルが読み取られ、アプリケーションが処理するデータの範囲が決定されます。さらに、次の目的で、処理全体でパーティション番号を使用する必要があります。

4.3 デッドロックの最小化

アプリケーションが並列で実行されているか、分割されている場合、データベースリソースの競合やデッドロックが発生する可能性があります。データベース設計チームは、データベース設計の一環として、潜在的な競合状況を可能な限り排除することが重要です。

また、開発者は、デッドロック防止とパフォーマンスを念頭に置いて、データベースインデックステーブルが設計されていることを確認する必要があります。

デッドロックまたはホットスポットは、ログテーブル、コントロールテーブル、ロックテーブルなどの管理テーブルまたはアーキテクチャテーブルで発生することがよくあります。これらの影響も考慮に入れる必要があります。アーキテクチャのボトルネックの可能性を特定するには、現実的なストレステストが不可欠です。

データに対する競合の影響を最小限に抑えるために、アーキテクチャは、データベースへのアタッチ時またはデッドロックの発生時にサービス (待機と再試行の間隔など) を提供する必要があります。これは、特定のデータベースリターンコードに反応し、すぐにエラーを発行する代わりに、所定の時間待機してデータベース操作を再試行する組み込みメカニズムを意味します。

4.4 パラメーターの受け渡しと検証

パーティションアーキテクチャは、アプリケーション開発者に対して比較的透過的でなければなりません。アーキテクチャは、次のようなパーティションモードでのアプリケーションの実行に関連するすべてのタスクを実行する必要があります。

検証には、次のことを確認するチェックを含める必要があります。

データベースがパーティション化されている場合、単一のパーティションがデータベースパーティションにまたがっていないことを確認するために、追加の検証が必要になる場合があります。

また、アーキテクチャはパーティションの統合を考慮する必要があります。主な質問は次のとおりです。