世にはびこるバッチ処理
何らかの企業システム構築に携わった経験がある方であれば、バッチ処理という名のもと、膨大なプログラム処理記述に遭遇したことがあるだろう。ユーザーの立場からは、キャッシュカードやクレジットカードの再発行手続きを行うと身をもって知ることになるだろうし、さまざま請求書や申請書にシステムの都合によって何らかの締め日が存在したりもする。人間による最終チェックが必要であればいたしかたないが、そうとは思えないほど時間がかかるものが多い。
「何分以内にこの処理を終えて、何時何分までに処理結果を返す。想定するデータ量がこの程度なのでピーク値を加味してこれぐらい高速なコンピュータが必要になります」こういった主旨のやり取りは一般的である。
バッチ処理は単一のコンピュータ資源しか使えかった時代、フローチャートからプログラムを作成していた頃から存在する。処理のメインは、スループットの非常に大きな高価なコンピュータで行われる。処理が滞るようになってくると、ハードウェアの増強で対応することとなる。先の図1では、メッセージキューあるいは、データベースサーバで集中的に処理されることが多い（メッセージキューの場合は、その接続先のサーバとなる）。しかし、これでは想定するデータ量が増大するなどサーバの最大処理能力を超えてしまった場合にリプレースの必要が生じてしまい、必然的にシステム停止を余儀なくされる。システム停止が問題なくても、ある程度高価な費用がかかってしまうだろう。これでは、何のためにクラスタやグリッド構成にしたのかという根底が否定されてしまう。
旧来のバッチ処理は、グリッドはもちろんクラスタ構成のシステムを想定して作られてなどいない。さらに悪いことに、その頃からの教育を受けた技術者には、グリッドの目的という意識がない場合が多い。たとえば、A1＋B1＋A2＋B2……＋An＋Bnといった処理に対して、律義に順番に処理するのが世界中でもっとも高速だと信じて疑わない。仮に複数のコンピュータがあってもその中の1台しか使わないのだ。時代が変わり、ハードウェア的に帯域速度が向上し、扱うデータの種類も量も増えているが、バッチ処理という世界では時間が止まっているようだ。過去の実績が基準になるので発想に進歩もなければ、言い訳することに何の罪悪感もない。システム固有の実装と、ビジネス固有の実装が混ざり込んでいても違和感を覚えず、両者の区別すらつかない。そんな技術者がいるために、無駄で無意味な投資をさせられる不幸なユーザーが増える。すでにバッチ処理では実現できないリアルタイム処理が要求されるユーザーも増えているが、決済など、ほかのシステムとは関係がないにも関わらずバッチ処理的な対応しかできないシステムが多いのが現実である。
バッチ処理がなくならないのであれば、バッチ処理をグリッド対応にさせる必要がある（図4）。そのためにアプリケーションサーバでは、大きなプログラム処理をグリッド処理するためのフレームワークの整備が重要といえる。最低限、依存関係のない処理記述が前提となる。さらに踏み込んで、並列処理する際に問題となる依存関係のあるプロセスに対して、パイプライン処理や先読みキャッシング処理を行える仕組みが必要となり、時間軸とサーバ位置に対して抽象化されることも必要になる。これは言い換えると、4次元時空間とタイムマシン処理をサポートするフレームワークとなる。非現実的な言い回しに聞こえるかもしれないが、CPUのアーキテクチャやカーネルレベルでは実際に実装されている概念でもある。グリッドコンピューティングでも、よりハイレベルな実装がシステム構築の現場では求められるので、現実的なフレームワークは必要不可欠である。
 |
|---|
| 【図4】グリッドに対応したバッチ処理 |
