レベル: 初級 宮田 裕樹, 未来価値創造事業．クラウド・コンピューティング事業推進, IBM
2009年 5月 26日 クラウドを実現するための技術としては、仮想化技術、プロビジョニング、スケーラビリティ、並列分散処理技術、高可用性などさまざまな要素が挙げられます。WebSphere eXtreme Scale（以下、WXS）は、その中でも特にスケーラビリティ、並列分散処理、高可用性、を実現するための機能を備える分散キャッシュ製品です。当資料では、クラウドの実現技術という観点からWXSの機能について説明します。
クラウドにおける要件
クラウド・コンピューティングのプラットフォームにおいては、多数のユーザーから大容量データや高トランザクションのサービス要求を受けた際にも、仮想化されたリソースによって、継続的に処理を行うことが要求されます。たとえ、ユーザー数や、処理するデータ量、トランザクション量が急激に増加したとしても、それに対応してスケールした仮想化リソースにおいて高速処理を継続することが求められます。そのような環境においては、スケーラビリティは必須の要件であり、スケールした環境においても、どこにもボトルネックが発生することなく高速処理を実現する必要があります。
また、大量データを、スケールした仮想リソース（つまり、分散する多数のサーバー環境）において高速で処理するためには、分散したデータを一ヶ所に集めてから処理を行うのではなく、分散したデータ側で並列的に処理を行い、その結果を一ヶ所に集めて集計した方が全体のスループットを向上させることができます。その高速化効果はデータが分散していればいるほど顕著に表れることとなります。このような並列分散データ処理機能もクラウド・コンピューティングでは要求される機能のひとつです。
さらに、クラウド・コンピューティング環境ではサービス・レベル管理の観点から、高可用性の維持が必須要件となります。サーバーに障害が生じた際にも処理を引き継いでサービス提供を中断することがないようにしなければなりません。
以上のようにクラウド実現のために必要なスケーラビリティ、並列分散データ処理、高可用性をサポートする製品として挙げられるのがWXSです。以下、その概要および、クラウドの実現技術となるそれぞれの機能について説明を行います。
WebSphere eXtreme Scale 概要
WXSは、高速な応答性能と柔軟なスケーラビリティを特色とした分散キャッシュ製品です。図1に示すように、バックエンド・データストアのデータはクラスターを構成するWXSサーバーの複数JVMプロセスのメモリー上に展開され、Key-Value型のMapデータとして保管されます。データはWXS起動時にデータベースやファイルなどからまとめてロードすることもできますし、要求が来た際にデータをロードしキャッシュすることもできます。このメモリー上のキャッシュ・データから応答を返すことで、超高速な応答性能を可能としているわけです。
図1. WebSphere eXtreme Scale 概要図
実際には、クライアント・アプリケーションがデータを要求すると、WXSサーバー上に分散配置したデータをgetし、クライアント側にロードします。また、データを更新すると、更新データをWXSサーバー上にputします。データの位置（実際にはデータを含むパーティションの位置）はカタログ・サーバーによって管理されており、ルーティングは自動的に行われるため、クライアントがどのプロセス上にデータが配置されているのかを意識する必要はありません。クライアントから見れば、単一のデータベースにアクセスするような感覚で、高速アクセスを実現することが可能になります。
WXSは、特にクラウド・コンピューティングを実現するために必要な機能として、以下のような特徴を持ちます。
- リニアなスケーラビリティを実現するパーティショニング機能
- 大規模並列分散データ処理を実現するデータグリッド・エージェント
以下のセクションでは、それぞれの特徴についてより詳しく紹介していくことにします。
リニアなスケーラビリティを実現するパーティショニング機能
先ず、WXSのような分散キャッシュがない場合の課題を考えてみます。Webサーバー、アプリケーション・サーバー、DBサーバーからなる３層システムにおいて、トランザクション量が増えてより多くのサーバー・リソースが必要となった場合、アプリケーション・サーバー層ではサーバーを追加してクラスタリングを行うスケール･アウトという手法が採られてきました。これは、一台のサーバーの性能を上げるというスケール・アップよりも、同じ性能のサーバーを並べるスケール・アウトの方がはるかに安価な解決策であるためです。
一方、DBサーバーはデータの整合性を確保するために、スケール・アウトではなく、スケール・アップの手法を採る必要があります。この構成方法を採ると、アプリケーション・サーバー層では処理を分散することができるのに対し、DBサーバーへの負荷集中を回避することはできないため、DBサーバーがボトルネックとなってしまいます。そのため、いくらDBサーバーを高性能にしてもリニアにスケールせず、スケーラビリティの限界に達してしまうという課題点があります。
図2. 現行システムのスケーラビリティの限界
図3. WXSによるスケーラビリティの実現
ここで、WXSを導入するとデータはWXSサーバー上のパーティションに分散配置されます。どのデータをどのパーティションが担当するのかは、キーのハッシュ値によって一意的に決定され、どのパーティションがどのサーバー上に配置しているのかは、カタログ・サーバーによって決められています。クライアントは最初の要求時にカタログ・サーバーからパーティションのロケーション表を取得するため、データを担当するパーティションの位置を知ることができ、データをput/getすることができます。ひとつのパーティションは複数のキーのデータを担当する可能性がありますが、同一キーのデータを担当するパーティションは単一であり、複数のパーティションにまたがることはありません。図3において、例えばIBMというキーのデータをputする場合、IBMキーを担当する単一のパーティションのデータを更新した後、データベースへの更新を行います。WXSでは、キャッシュ・データの更新とDBの更新を同期的に行うwrite-throughモードに加え、DBの更新は非同期的に行うwrite-behindモードも選択することが可能です。（WXS6.1.0.3からサポート）次に、IBMというキーのデータをgetする場合、先ほどの担当パーティションに問い合わせればよく、それが最新のデータを保持していることになります。
データ量の増加あるいはトランザクション量の増加によりスケーラビリティが求められた場合、スケール・アウトによってWXSプロセスを追加すれば、パーティションが動的に再配置されて、負荷が分散します。
このようなパーティショニングの効果により、リニアなスケーラビリティを実現することが可能となるわけです。
大規模並列分散データ処理を実現するデータグリッド・エージェント
WXSは、スケール・アウトによって分散したデータの並列処理を行う機能としてデータグリッド・エージェントをサポートしています。このデータグリッド・エージェントにより、HadoopのMapReduce*がサポートしているような分散データ側での並列処理とクライアント側での集計処理ができるようになります。
WXSがサポートするデータグリッド・エージェントにはMapGridAgentおよび、ReduceGridAgentの２種類があり、目的によってそのいずれかを実装することになります。
MapGridAgentは、Mapの該当エントリー群について分散データ側で参照・操作して、その結果をMapで返します。複数エントリーに演算を施して、結果も複数エントリーで返すという場合に使用します。
一方、ReduceGridAgentは、Mapの該当エントリー群について分散データ側で処理した後、クライアント側で集計処理を行い、結果を一つのオブジェクトで返します。例えば、多量の数値データから、合計や平均等を得るような場合に使用します。
各データグリッド・エージェントは以下のインターフェースにて実行します。（図4）
MapGridAgent: AgentManager.callMapAgent()
ReduceGridAgent: AgentManager.callReduceAgent()
図4．データグリッド・エージェントによる並列分散データ処理
データグリッド・エージェントによる並列分散データ処理のロジックはMapGridAgentまたはReduceGridAgentを実装したクラスを作成し、そのメソッドの中に記述していきます。ここでは、ReduceGridAgentのコーディング・サンプルを示します。
reduceメソッドには分散データ側で処理するロジックを記述します。keyList付きのreduce(Session s, ObjectMap map, Collection keyList) は処理対象のMapエントリーのkeyList付きで呼び出された際に実行されます。サンプルでは処理対象のMapエントリーの年齢を各パーティションで集計するようロジックを記述しています。
keyListのないreduce(Session s, ObjectMap map) は処理対象のMapエントリーのkeyListなしで呼び出された際に実行され、全Mapエントリーに対して処理されます。サンプルでは全Mapエントリーのうち、指定された最小年齢と最大年齢の間の人の年齢を各パーティションで集計するようロジックを記述しています。
reduceResultsメソッドは各パーティションでのreduceメソッドの処理結果をもとに、クライアント側で処理するロジックを記述します。サンプルでは、上記のreduceメソッドによって各パーティションで集計した年齢を収集し、クライアント側で集計を行うようにロジックを記述しています。
public class SumAgeReduceAgent implements ReduceGridAgent, EntityAgentMixin {
private static final long serialVersionUID = 2521080771723284899L;
int lowAge;
int highAge;
public Object reduce(Session s, ObjectMap map, Collection keyList) {
Iterator<Person> iter = keyList.iterator();
int sum = 0;
while(iter.hasNext()) {
Person p = iter.next();
sum += p.age;
}
return new Integer(sum);
}
public Object reduce(Session s, ObjectMap map) {
EntityManager em = s.getEntityManager();
Query q = em.createQuery("select p from Person p where p.age > ?1 and p.age < ?2");
q.setParameter(1, lowAge);
q.setParameter(2, highAge);
Iterator<Person> iter = q.getResultIterator();
int sum = 0;
while(iter.hasNext()) {
sum += iter.next().age;
}
return new Integer(sum);
}
public Object reduceResults(Collection results) {
Iterator<Integer> iter = results.iterator();
int sum = 0;
while(iter.hasNext()) {
sum += iter.next();
}
return new Integer(sum);
}
public Class getClassForEntity() {
return Person.class;
}
}
|
このようにデータグリッド・エージェントを利用すると、データ処理を分散データ側で並列的に実行することで大量データの高速処理が可能となります。また、ネットワークを介したデータのやりとりに関するオーバー・ヘッドを回避することも可能となります。さらに、システム負荷が増えた場合、WXSサーバーの追加により処理を分散させ、その負荷に対応することができるようになります。
* Hadoop MapReduce： Googleが採用している大規模分散処理フレームワークMapReduceに基づいて、その機能をオープンソースとして公開しているもの。分散データの分解・抽出を行うMapフェーズと抽出された情報の集約・計算を行うReduceフェーズによって処理される。
おわりに
本記事ではWXSの持つ機能のうち、クラウドの実現技術となるパーティショニングおよびデータグリッド・エージェントにフォーカスしてその機能の紹介をしました。WXSにはさらに、柔軟な同期／非同期レプリケーション、開発生産性を高めるEntityManager APIやQuery APIなどさまざまな機能を持ちます。より詳細な情報を知りたい方は以下のリンクの情報を参考にしてください。
WebSphere eXtreme Scale Wiki
developerWorks: WebSphere XD
WebSphere XD 6.1 テクニカル・ワークショップ資料
著者について  | | | 宮田 裕樹, 未来価値創造事業．クラウド・コンピューティング事業推進, IBM |
記事の評価
| 
