XTP（大量トランザクション処理）

XTP（大量トランザクション処理）が可能に

第2回では、Java資産を活用した軽量なWeb開発の動向を紹介しました。実は、こうしたシンプルなWebシステムへのニーズがある一方で、高速大量処理やスケーラビリティを必要とする要件もあります。

例えば、「IBM WebSphere eXtreme Scale」（WXS）を導入している米国の投資銀行の例では、3.5ミリ秒以内のレイテンシ（遅延時間）と、1スレッドあたり1秒で175個のイベントを実現しています。サーバー1台あたりでは、1秒につき8200イベントを処理し、フェール・オーバー（縮退運転）は1秒以内です。

このような高速大量トランザクション処理を、分散システムの技術を使って実施することを「Extreme Transaction Processing」（XTP）と呼びます。

市場調査会社の米Gartnerでは、XTPを以下のように定義付けています。「分散システムの技術を利用して、高速大量処理／スケーラビリティ／可用性／セキュリティ／管理と信頼性などの要件を特徴とするトランザクション・アプリケーションを、設計／開発／配置／管理の点で支援することを目的としたアプリケーション・スタイル」。詳しくは「Gartner RAS Core Research Note G00131036」を、GartnerのWebサイトで見てください。

Web 3層アーキテクチャーが抱える課題

Webシステムでは一般的に、システムの構成要素を以下の3つの階層、すなわち（1）Webサーバー層、（2）アプリケーション・サーバー層、（3）データベース層、に分けます。

トランザクションの増加に合わせて処理能力を増強する場合、Webサーバー層やアプリケーション・サーバー層では、サーバーの追加によるスケールアウト構成が一般的です。一方で、データベース層では、サーバー自身の処理能力を向上させるスケールアップが一般的であり、このため高性能なサーバー機が必要になっています。可用性を維持するためにバックアップ機を用意する必要もあり、コストが高くなってしまうという課題がありました。

データベース層に対する処理の集中と物理I/Oを軽減するためには、アプリケーション・サーバー層でデータをキャッシュする方法が考えられます。

しかし、図1-2のようにアプリケーション・サーバーごとに同一のキャッシュを置いてキャッシュ間でデータの同期をとった場合、キャッシュの最大容量は1台のサーバー機のメモリ・サイズに依存してしまいます。サーバーの数を増やしてもキャッシュ容量は増えません。データに更新が発生した場合、同じデータを各キャッシュで共有し、キャッシュの整合性を確保する必要もあります。

こうしたキャッシュの課題を解決する方法として、「インメモリ・データグリッド」という考え方が提唱されています。この方法では、アプリケーション・サーバー層とデータベース層の間にキャッシュ層を置きます。

このキャッシュ層の基礎として使われる技術／考え方が、キー・バリュー・ストア（Key-Value Store）です。キー・バリュー・ストアでは、データを、識別子である「キー」と、その本体である「バリュー（値）」の組にして保持します。データの格納先としては一般的に、分散メモリ技術が使われます。

ユニークなキーの値から生成したハッシュ値により、キャッシュ層のサーバーにプライマリーのデータを分散させます。このため、キャッシュ・サーバー機を増やせば、キャッシュ容量が増えます。サーバー1台のキャッシュ容量をM、サーバー台数をNとすると、キャッシュの総容量はM×Nになります。

さらに、同一データ（レプリカ）を別のキャッシュ・サーバーに置くことで、キャッシュ・サーバーの障害対策になります。また、キャッシュ・サーバーを新規に追加した際には、キャッシュ・サーバーのクラスタ内部で自動的にキャッシュ・データが再配置されます。この際にデータベース層に負荷を与えることはありません。

エンタープライズWebではさらに、トランザクション管理、排他制御、セキュリティや障害回復の機能が必要になります。これらの機能を備えたインメモリ・データグリッド製品が冒頭で触れたWXSです。次ページ以降では、WXSを例に、インメモリ・データグリッド製品にどのような機能が必要なのかを示します。