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

大規模アプリケーションの構築では、開発工程終盤のシステムテストで性能上の問題が露呈することがよくあります。

機能レベルのテストで問題なく動いていたアプリケーションであっても、システムテストで大量の実データを使用したテストでは処理に時間がかかりすぎて使い物になりません。

ですが、設計工程を見ていると、性能指標値を定めているプロジェクトをたまに見かけることはありますが、その「条件を満たすための設計」というのをしているようには見えないのです。

だから、レビューなどのチェックリストも

　「極力〇〇しない」
　「できるだけ〇〇を使用しないこと」

と言った、機能性優先で、性能度外視を容認するような内容になっている現場も多々見受けられます。実際、その〇〇を使ったら、どれくらい性能に影響が出るかについて、試算もしていないのです。

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

このような問題を防ぐには、性能を考慮したアプリケーション設計を行う必要があります。そのためには、設計対象のバッチ処理の特性を正確に把握する必要があります。

画面系のオンライン処理で発生するショートトランザクションと異なり、バッチ処理はロングトランザクションになるという特徴があります。

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

たとえば、ショートトランザクションでデータベースにアクセスする場合、
通常はカーソルを利用して条件に合ったデータを取り出し、1件ずつループ処理を行います。このタイプの処理では対象になるデータが少量のため、性能上の問題が発生することは滅多にありません。

しかし、何十万〜何百万件のデータを同じようにカーソルで1件ずつ処理したらどうなるでしょう。いつまでたっても終わらないバッチ処理が出来上がってしまうのではないでしょうか。

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

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

このように、ショートトランザクションとロングトランザクションでは特徴に大きな違いがあるため、アプリケーション開発もこの特徴に合わせた設計を行うことが重要になります。

性能上のリスクは設計段階で極力排除し、後戻りのない開発を行うようにしましょう。

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

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

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

このようなリカバリポイントを多く含んだバッチ処理は、エラー発生時の運用が非常に煩雑になりがちです。

ハードウェアリソースの有効活用が最重要課題だったメインフレームのアプリケーションでは、このような実装が常識でした。しかし、処理性能が格段に上がったオープンシステム環境では、リカバリ時の煩雑さをできるだけ減らせるような方式を採用するべきです。

実装および運用の点から考えて最もシンプルなのは、エラーが発生した時点ですべての処理をロールバックする方式です。中途半端に処理が確定されている状態を作らないので、複雑なリカバリポイントの設定などを考える必要はありません。エラーの原因を解決した後は、同じバッチを単純に再実行するだけでよくなります。

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

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