バッチアプリケーション設計のポイント：Oracle技術者のためのバッチアプリ開発講座（1）（2/3 ページ）

設計段階から性能を考慮しよう——結合テストで泣かないために

　大規模アプリケーションの構築では、開発工程終盤のシステムテストフェイズで性能上の問題が露呈することがよくあります。機能レベルのテストで問題なく動いていたアプリケーションであっても、システムテストフェイズで大量の実データを使用したテストでは処理に時間がかかりすぎて使い物にならないのです。

トランザクション処理の特性を理解した設計を行う

　このような問題を防ぐには、性能を考慮したアプリケーション設計を行う必要があります。そのためには、設計対象のバッチ処理の特性を正確に把握する必要があります。画面系のオンライン処理で発生するショートトランザクション注1と異なり、バッチ処理はロングトランザクション注2になるという特徴があります。

　ロングトランザクションの場合では、一度に大量のデータを処理するため、メモリ上だけでは処理しきれない場合がほとんどです。そのため、ディスクアクセスが頻繁に発生します。

例えば、ショートトランザクションでデータベースにアクセスする場合、通常はカーソルを利用して条件に合ったデータを取り出し、1件ずつループ処理を行います。

　このタイプの処理では対象になるデータが少量のため、性能上の問題が発生することはめったにありません。しかし、何十万〜何百万件のデータを同じようにカーソルで1件ずつ処理したらどうなるでしょうか？ いつまでたっても終わらないバッチ処理が出来上がってしまうでしょう。

性能上のリスクは設計段階で極力排除

　Oracleなどのデータベース管理システムでは、結果セットに対する処理を非常に得意としています。大量データを処理するロングトランザクションでは、同一条件のデータを1つの結果セットとして取り出して一括処理することで、処理性能を飛躍的に向上させられます。

　このように、ショートトランザクションとロングトランザクションでは特徴に大きな違いがあるため、アプリケーション開発もこの特徴に合わせた設計を行うことが重要になります。性能上のリスクは設計段階で極力排除し、後戻りのない開発を行うようにしましょう。

リカバリ方式はシンプルに

　バッチの実行途中にエラーが発生した場合、バッチを再実行して処理を完了させる必要があります。その際、どのようなリカバリ方式を選択するかによって、実装コストや運用コストにかなりの差が出ます。

　汎用機のバッチ処理ではタイトなスケジュールでジョブを運用しているケースが多いので、「エラー発生時には極力短時間でリカバリする」という思想で設計されています。つまり、すべての処理を再実行するのではなく、エラーが発生した処理から再実行できるように実装されています。

　このようなリカバリポイントを多く含んだバッチ処理は、エラー発生時の運用が非常に煩雑になりがちです。ハードウェアリソースの有効活用が最重要課題だったメインフレームのアプリケーションでは、このような実装が常識でした。

　しかし、処理性能が格段に上がったオープンシステム環境では、リカバリ時の煩雑さをできるだけ減らせるような方式を採用するべきです。実装および運用の点から考えて最もシンプルなのは、エラーが発生した時点ですべての処理をロールバックする方式です。中途半端に処理が確定されている状態を作らないので、複雑なリカバリポイントの設定などを考える必要はありません。

　エラーの原因を解決した後は、同じバッチを単純に再実行するだけでよいのです。また、それぞれのバッチアプリケーションを1つのトランザクションとして実装する（処理の途中でコミットしない）ことで、エラー発生時のロールバック処理はデータベース管理システムが勝手に実行してくれます（図2）。

図2　リカバリ方式の違い

　このようなシンプルな方式で実装すれば、運用担当者のオペレーションミスを心配する必要もありません。また、運用の自動化を考える際にも非常に大きなメリットになります。