datapower xc10 アプライアンスワークショップ simple datagrid...

1

DataPower XC10 アプライアンスワークショップ

© 2010 IBM Corporation

日本アイ・ビー・エムシステムズ・エンジニアリング株式会社

Webシステム基盤

太田智之 [email protected]

Simple DataGrid～XC10を簡易データ・ストアとして利用する

2

© 2010 IBM Corporation2


Disclaimer

この資料は日本アイ・ビー・エム株式会社ならびに日本アイ・ビー・エムシステムズ・エンジニアリング株式会社の正式なレビューを受けておりません。

当資料は、資料内で説明されている製品の仕様を保証するものではありません。

資料の内容には正確を期するよう注意しておりますが、この資料の内容は2010年12月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変わる可能性があるのでご注意下さい。

今後国内で提供されるリリース情報は、対応する発表レターなどでご確認ください。

3



目次

§1. データ・ストアとしてのXC10§2. ユース・ケース - どのように使えるか？

§3. 手順解説 - どのように動かすか？

§4. ＷＸＳとの機能差異

§5. まとめ

4



§1. データ・ストアとしてのXC10

5



データ・ストア再考

従来、データ・ストアといえば、RDBが主流であった

Web2.0、クラウド、SOA、様々なテクノロジーが登場既存のRDBでは、フィットしない環境が出てきた

指数的に増加するデータを扱う必要がある

非定型データ / 非構造化データを柔軟に扱いたい

一つの回答が、NoSQL（=Not only SQL ）SQL要らない、という話ではない

NoSQLの分類（※1）キー/バリューストア（KVS：Key-Value-stores）

BigTable実装

ドキュメントストア（Document-stores）

グラフデータベース（Graph Databases）

※1グラフデータベース、NOSQL、Neo4j http://www.infoq.com/jp/articles/graph-nosql-neo4j

XC10が提供する、Simple DataGrid機能をご紹介する前に、まずはこの機能が必

要とされる背景について簡単に触れておきたいと思います。

従来、データベースと言えばリレーショナルデータベースが主流でした。しかしながら、近年はWeb2.0、クラウド・コンピューティング、SOAなど多様なテクノロジーが生まれ、これらが必要とするデータ・ストアの在り方にも多様性が生じるようになりました。

この様な流れの中で、リレーショナルではないデータ・ストアが生まれてきています。リレーショナルデータベースでのデータ操作言語であるSQLではない、という意味で、NoSQL（=Not Only SQL）というタイプのデータ・ストアです。

中でも、NoSQLの一つとして脚光をあびているのが、KVS（Key Value Store）です。

これは、データをキーと値のペアで保持し、データ操作はシンプルなget/put/update/removeで行おうというものです。

6



新しいタイプのデータ・ストア

KVSによる対応

スケール・アウトによる拡張性の確保

非定型・非構造化データのハンドリング

RDBで困ること…

値に入れるデータの型は問わない（ことが多い）

Valueに入れるものは構造化しなくてもOK

非定型・非構造化データの扱いが苦手

データの構造をあらかじめ定義しておく必要がある

非構造化データを

扱いたい

スケールしやすい

パーティション化が容易で、スケールアウトさせやすい

整合性よりも、可用性（いつでも使える）を重要視

スケールしにくいACID確保のため、スケールアウトさせにくい

整合性維持のためのロック取得がパフォーマンス上ネックになることもある

超大量データを

扱いたい

KVSでは…

KVSは、シンプルであるが故に高速であり、拡張性を備えている、反面、RDBが持つような整合性維持に弱いという特性を持っています。（実際にはKVSの実装は非常にバリエーションに富んでおり、一概にこの定義は当てはまらないかもしれませんが・・・）

KVSが近年のテクノロジー・シーンで何故脚光を浴びているかという事を説明する前に、RDBでは何故不都合があるかという点を考えて見ましょう。

例えば、クラウド・コンピューティング環境においては、ニーズに応じてスケールするようなデータ・ストアが求められます。

RDBでは整合性維持を重視するという仕組み上、スケールしにくいという特性がありました。KVSは、パーティション化が容易であり、非常にスケールしやすいという特性を備えています。

また、データの型が一定でないもの、もしくはドキュメントや音声、映像などの非構造化データなどもデータベースに保管したいというニーズもあります。RDBでは、予めデータ定義を行っておく必要がありましたが、KVSでは、値に入れられる物に非常に柔軟性があります。

このようなに、KVSは新しいタイプのデータ・ストアとして非常に注目されています。

7



Key-Value型データ･ストア（KVS）

AAA, 03-000, [email protected]

100010

[email protected]

[email protected]

[email protected]

MAILPHONENAMEEMPNOVALUEKey

BBB, 03-010, [email protected]

100020 CCC, 03-020, [email protected]

100000

SQLによる複雑な条件指定でのアクセスkey指定による高速なアクセス

スケール･アップによる処理性能向上スケール･アウトによる処理性能向上

Key-Value型データ・ストア RDB

put, get, remove … SELECT, INSERT, UPDATE, DELETE

クエリの特性

拡張方式

ACIDBASE トランザクション

困難容易パーティション化

KVSとは、RDBとは異なり、「Key（キー）」と「Value（値）」のペアからなる、ごくシンプルなデータモデルに基づくデータストア

KVSとは、RDBとは異なり、「Key（キー）」と「Value（値）」のペアからなる、ごくシンプルなデータモデルに基づくデータストア

ACIDACIDBASEBASE

KVSについて、RDBとの比較を交えながらもう少し説明をしておきます。

KVSとは、名前が示すとおり、データを「Key（キー）」と「Value（値）」のペアで保存するデータ・ストアです。

KVSとRDBの特性を幾つかの観点で見てみます。

まず、クエリの特性としては、KVSはKey指定でデータを取得するシンプルな形式のため高速にアクセスできる反面、複雑な条件指定ができません。一方RDBは複雑な条件指定でクエリを行い、データを柔軟に操作できます。反面、複雑さに依存してパフォーマンスが変動します。

パーティション化に関しては、KVSはデータの管理粒度が1項目単位であるため、柔軟にパーティション化可能ですが、RDBの場合は表となるため、パーティション化が困難です。

拡張方式については、KVSはサーバーを追加するスケール・アウト方式であるのに対し、RDBはサーバー単体で処理性能を向上するスケール・アップ方式です。スケール・アップ方式では、価格対性能比が高くつくと言われています。

また、トランザクションの特性としては、KVSはいつでも使える状態：可用性を重視するBASEタイプであるのに対し、RDBは整合性を重視するACIDタイプとなります。（後述）

8



トランザクション中に行われる操作の過程が他の操作から隠蔽される


トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないことを指す


トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保証する性質


トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質


【参考】従来型トランザクションの特性 = ACIDtomicityA onsistencyC

solationI urabilityD

Trx scope

A

B

Trx scope

A

B

ACIDにおけるデータ整合性維持の仕組みがスケール・アウトの阻害要因ACIDにおけるデータ整合性維持の仕組みがスケール・アウトの阻害要因

在庫情報 ≧ 0

在庫情報 < 0

口座残高 ≧ 0

口座残高 < 0

Trx scope

A

Trx scope

B

Trx scope

A Trx scope

B在庫数更新在庫=5

在庫数取得在庫=5

ACIDACID

参考情報として、従来型のトランザクション特性を見てみましょう。

従来のトランザクションは、ACIDと呼ばれる整合性重視する特性が重視されていました。

ACIDは、以下の項目の頭文字を採ったものです。各項目の意味と例を記述しています。

Atomicity


例） A⇒Bへの振込み、Aからの出金だけ処理されてはならない。Aからの出金、Bへの送金両方処理

Consistency


例）口座残高がマイナスになってはならない

Isolation


例） A⇒Bへの振込み、Aからの出金、 Bへの送金と行われているが、外からはA⇒Bへの振込みとしてしか見えない

Durability


例）トランザクションログなど、情報は永続的で（障害などによって）失われてはならない

9



【参考】Basically Available / Soft-state / Eventually consistent

自分自身で値をハードコードして持たない

外からもらったデータで自分自身が存在する

自分自身で値をハードコードして持たない

外からもらったデータで自分自身が存在する

一時的にはシステムが返す結果の整合性がとれない不整合ウィンドウが発生するが、結果的には整合性が確保される、という考え方

一時的にはシステムが返す結果の整合性がとれない不整合ウィンドウが発生するが、結果的には整合性が確保される、という考え方

基本的にいつでも使える状態にあること基本的にいつでも使える状態にあること

asically vailableB oft-stateS

ventually consistentE

A

クラウド等の分散環境では、可用性が重要であるという考えBASEで説明されている、Eventually Consistentという考え方がポイント

クラウド等の分散環境では、可用性が重要であるという考えBASEで説明されている、Eventually Consistentという考え方がポイント

BASEBASE

以下のようなものは、データの鮮度、整合性よりも可用性が重要例)・ショッピングサイトのカタログ情報

・検索サイトの検索結果

・Blogデータ、

・DNS etc

以下のようなものは、データの鮮度、整合性よりも可用性が重要例)・ショッピングサイトのカタログ情報

・検索サイトの検索結果

・Blogデータ、

・DNS etc

参考情報として、BASEについて簡単に説明します。

Availabilityが重要視されるケースでは、BASE型トランザクションがフィットする

ケースが多いと思われます。

BASEとは、以下の3つの特性を表したものです。

Basically Available分散システムであるがゆえに、可用性が高く常に利用できることを重視する考え方

Soft-state状態は、外部から送られた情報によって決まるという状態の考え方

Eventual consistencyシステム内に一時的にConsistentでない状態が生まれても、ある期間の後にはConsistentな状態になるような性質

10



XC10は、インメモリKVSWebSphere eXtreme Scale

インメモリ分散オブジェクトキャッシュ

KeyとValueのペアでデータを保管

XC10は、WXSのアプライアンス

シンプルなマップとして利用可能

ただし、Loader機能（※）が無いため、データをパーシストできない

よって、一時的なデータを保管するコンポーネントとして利用可能

よって・・・

として利用する

HTTPセッションの保管庫 Simple DataGrid 動的キャッシュストア

※ WXSにおけるLoader機能とは、プラグインとして提供される、WXSのマップ内のデータをDBにパーシストする機能を指します。

ここから、本題に入りましょう。

XC10は、WebSphere eXtreme Scale（WXS）というインメモリ分散オブジェクトキャッシュ製品をアプライアンス化したものです。

WXSは多様なAPIを提供していますが、基本的にはデータ（=Javaオブジェクト）をキーと値のペアで保管、アクセスできるKVSという事が出来ます。

なお、WXSをアプライアンス化する上で、複雑な設定・コーディングを必要とする機能は削がれています。重要なポイントですが、WXSで提供されているデータをDBなどにパーシストするLoader機能などもXC10では提供していません。従って、XC10を再起動すると、マップに含まれるデータは消えてしまうことになります。

つまり、XC10はシンプルなKVSとして、一時的にデータを保管するコンポーネント

として位置づけることができます。

即ち、このような特性を生かすことが出来る使い方として、

・HTTPセッションの外部保管先

・動的キャッシュの保管先

・Simple DataGrid = データの一時保管先 ≒ キャッシュ

が考えられる訳で、これらの3つの機能を提供しています。

11



§2. ユース・ケース - どのように使える

か？

このセッションは、Simple DataGridのセッションですので、Simple DataGridにフォーカスして、どのように利用することができるか、説明したいと思います。

12



インメモリKVS – XC10 の使いどころ

データをパーシストすることが出来ないため、一時的なデータの保管庫として利用します。

例えば・・・データキャッシュを行うコンポーネント

計算途中のデータを一時的に保管するコンポーネント

データを他のアプリケーション/システム/コンポーネントと共有するための

コンポーネント

バッチ処理における中間データの一時保管先

クライアント間で一時的に共有するデータの保管先

大量参照トランザクションを捌くためのデータ・キャッシュ・ストア

先に説明したように、XC10の使いどころとしては、一時的なデータの保管庫として利用します。

考えられるユースケースとしては、以下のようなものがあるかと思います。

・データキャッシュを行うコンポーネント = 大量参照トランザクションを捌くためのデータ・キャッシュ・ストア

・計算途中のデータを一時的に保管するコンポーネント =バッチ処理における中間データの一時保管先

・データを他のアプリケーション/システム/コンポーネントと共有するためのコンポーネント =クライアント間で一時的に共有するデータの保管先

それぞれについて、具体的に見ていきましょう。

13



超高速データ参照が必要なシステムである。

• DBのサイド・キャッシュとしてXC10を利用

•金融系

• 株取引などの低レイテンシーで大量トランザクションを処理

• ユーザー増大が見込めるネット企業

課題

適用システム例

ソリューション

ObjectGridクライアント


アプリケーション


適用イメージ

DB

まずはXC10のグリッドを検索• キャッシュヒットによる超低レイテンシーでの応答

• DBの負荷軽減

期待される効果

ヒットしない場合のみDBアクセス

大量参照トランザクションを捌くためのデータ・キャッシュ・ストア

このケースは、WXS/XC10が得意とするXTP（eXtreme Transaction Processing）の実装ケースです。

構成としては、データベースと並列にXC10を配置します。

処理としては、まずアプリケーションはXC10のマップにアクセスし、データのキャッシュが保管されていないか確認します。

保管されていればデータをそのまま取得して処理を行います。保管されていなければ、DBにアクセスしてデータを取得し、XC10にキャッシュとして保管します。

DBにアクセスを行わないため、DBサーバーの負荷軽減に繋がりますし、XC10ではインメモリでの処理となるため、非常に高速に応答を返す事が出来ます。トランザクション量が増えた場合はXC10を追加することで処理量増加が可能です。

これらキャッシュデータのハンドリングは、アプリケーション側で処理を実装する必要があります。参照系ではトランザクション処理が複雑になるため、主に参照系での実装が推奨されます。

14



バッチ処理において中間データを生成しているが、中間データの量が多く、これらのread / write がボトル

ネックになっている。

•一時的な中間データの格納先をXC10とする

•金融系

•情報系のデータマート生成時の一時データプール

課題



適用イメージ

後続のジョブのINPUTとなる中間データをXC10に書き込み

•バッチ処理時間短縮


バッチ処理における中間データの一時保管先

ジョブステップ

1


2


3

前ジョブで生成されたデータをXC10から読

み込み。メモリ上で処理されるため、高速

このケースでは、バッチ処理の途中で一時的に生成・使用される中間データをXC10に格納し、データアクセスを高速化しようというものです。

バッチジョブでは、INPUTとして読み込んだデータを処理しOUTPUTに出力、後続のジョブステップは前のステップでのOUTPUTを入力とする、という処理が多くを占めていると思われます。

更新系では処理が複雑になる旨前ページに記述しましたが、このような処理であればINSERTが中心であると考えられますので、トランザクション処理などそれほど複雑にはならないものと思われます。

RDBであれば事前に定義を行ってデータを補完する必要がありましたが、XC10の場合はJavaオブジェクトをそのまま保管することが出来ますので、コードの簡略化にも有効です。また、ディスクアクセスではなくインメモリで、かつオブジェクト形式でのデータアクセスという事になりますので、非常な高速化が期待できます。

15



アプリケーション・クライアントが参照する一時的な共有データを扱う必要がある。

このデータの格納先としてわざわざRDBを使いたくない。

•一時的なデータ格納先として、XC10を利用する

• クライアント間で共有する一時データを扱うシステム

課題



適用イメージ









共有データをXC10に書き込

み

共有データをXC10から読み

込みメモリ上で処理されるため、高速

•拡張性・柔軟性の確保

•データ・アクセスの高速化


クライアント間で一時的に共有するデータの保管先

このケースも、前ケースと同様に一時的に使用するデータをKVSで扱おうというものです。

RDBにデータを保管しようとすると、データの定義を行ったうえでテーブルを作成、etcなど、構築、メンテナンスに比較的手間がかかりますが、KVSの場合は設定ファイルを用意するのみで構築が完了します。また、WXSの場合はオブジェクトをそのまま使いまわす形になるので、オブジェクト/データのインピーダンス・ミスマッチも気にする必要がありません。

あわせてインメモリで処理可能であるため、処理時間の短縮も見込めます。

16



§3. 手順解説 - どのように動かすか？

ここまでで、XC10の位置づけ、機能概要を見てきました。

ここからは、実際に使う際にはどのような手順が必要になるか、ということを説明します。

17



一般的なトポロジー

Rational Application Developer V7.0/V8.0Rational Application Developer V7.0/V8.0

WebSphere AS V7WXS Client

WebSphere AS V7WXS Client

拡張済みプロファイル拡張済みプロファイル

アプリケーション・サーバー

ワークスペース

wsogclient.jar開発開発

テストテスト

Javaビルドパス

WebSphere AS V7XC10 Client

WebSphere AS V7XC10 Client

拡張済みプロファイル拡張済みプロファイル

アプリケーション・サーバー

ObjectGrid.xml

エクスポート

インポート

EARファイル

エクスポート

インストール

XC10

開発端末

検証環境 / 本番環境

手順をご説明する前に、ここでの説明の前提環境についてご説明します。

Simple DataGridとしてXC10を使用する場合は、コーディングが必要となります。従って、コーディングは開発端末でRational Application Developerなどを使用して行うことになります。

このアプリケーションの中からWXS（APIはXC10と同様です）のAPIを使用することになるため、予めクライアントとなる端末/WASには、WXS クライアントを導入しておく必要があります。

RADでテストを行い、稼動確認がとれたら、EARファイルをexportして実際の検証環境、本番環境に導入し、サーバー上での稼動確認テストを行う、という流れが一般的な流れになるかと思います。

18



構成・設定方法

設定の流れ

1. XC10管理コンソールにて、DataGridの作成2. 作成したDataGridの構成ファイルをexport

XC10

3. アプリケーション作成

クライアント側（スタンドアロン環境の場合）

3. アプリケーション作成4. アプリケーションに、2. でexportしたファイルをインポート5. アプリケーションアーカイブファイル（ear）を生成6. 5.で生成したEARをWAS統合環境にインストール

クライアント側（WAS統合環境の場合）

※ XC10クライアントもしくは WXSクライアントが導入されており、プロファイルが拡張されている事を前提とします。

全体の構成の流れを説明します。

まずは、XC10側で、DataGridを作成します。この作成が終わったら、クライアント側がGridの構成を知るための構成ファイルをexportします。XC10側で必要になる手順は非常に簡単です。

次に、クライアント側のセットアップ手順です。WAS統合環境の場合、クライアント側では、RADのプロジェクトのセットアップを行い、アプリケーションコードを書いてテストした後に、アプリケーションをearファイルとしてexportします。Exportしたearファイルは、任意のWAS上にインストールしてセットアップは完了です。（通常のアプリケーション開発手順となんら変わりありません。）

スタンドアロン環境（Javaアプリケーション）で動作させる場合も通常のアプリケーション開発手順と変わるところはありません。

19



構成・設定方法 – 1/3XC10側設定

XC10管理コンソールにて、DataGridの作成

XC10

メニューから、データ・グリッド→単純データ・グリッドを選択します。

単純データ・グリッド横の「＋」をクリックします。

グリッド名を入力するポップアップが表示されますので、グリッド名を入力します。

バックグラウンドでグリッド作成処理が開始されます。

それぞれのステップを具体的に見てみましょう。

XC10の構成は、基本的にブラウザから管理コンソールにアクセス、もしくはSSHで接続の上コマンドを介して行います。（詳細は、「05 構成・管理」の資料を参照ください。）

Simple DataGridの作成は、上記の流れに沿って作業することで作成できます。

20



構成・設定方法 – 2/3

サーバー側設定

メニューの「タスク」から、作成中ステータスを確認します。

正常に作成されると、「成功」と表示されます。

メニューの「データ・グリッド」→「単純データ・グリッド」に作成したグリッドが表示されるようになります。個別の設定をここで行います。

XC10

21



構成・設定方法 – 3/3作成したDataGridの構成ファイルをexport

<?xml version="1.0" encoding="UTF-8"?>

<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=http://ibm.com/ws/objectgrid/config ../objectGrid.xsd xmlns="http://ibm.com/ws/objectgrid/config">

<objectGrids>

<objectGrid name="QIT_SimpleGrid">

<backingMap name="QIT_SimpleGrid" readOnly="false" lockStrategy="NONE" ttlEvictorType="NONE" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.CT" template="true" readOnly="false" lockStrategy="NONE" ttlEvictorType="CREATION_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LAT" template="true" readOnly="false" lockStrategy="NONE" ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LUT" template="true" readOnly="false" lockStrategy="NONE" ttlEvictorType="LAST_UPDATE_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.NONE" template="true" readOnly="false" lockStrategy="NONE" ttlEvictorType="NONE" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.CT¥.P" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="CREATION_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LAT¥.P" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LUT¥.P" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="LAST_UPDATE_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.NONE¥.P" template="true" readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="NONE" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.CT¥.O" template="true" readOnly="false" lockStrategy="OPTIMISTIC" ttlEvictorType="CREATION_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LAT¥.O" template="true" readOnly="false" lockStrategy="OPTIMISTIC" ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.LUT¥.O" template="true" readOnly="false" lockStrategy="OPTIMISTIC" ttlEvictorType="LAST_UPDATE_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES" />

<backingMap name=".*¥.NONE¥.O" template="true" readOnly="false" lockStrategy="OPTIMISTIC" ttlEvictorType="NONE" copyMode="COPY_TO_BYTES" />

</objectGrid>

</objectGrids>

</objectGridConfig>

グリッド設定画面右上端のアイコンをクリックし、構成ファイルをダウンロードします。

構成ファイルのサンプルです。

XC10

DataGridの作成を行ったら、クライアント側で必要となるDataGridの構成ファイルをexportします。

上記は、出力結果のサンプルです。

22



RAD上でプロジェクト作成クライアント側（WAS統合環境の場合）

1. RAD上で動的Webアプリケーションプロジェクトを作成します。

2. プロジェクトのMETA－INFディレクトリに、

XC10からexportしたファイルをインポートします。

3. ビルドパスにjar（WASのlibディレクトリ下にあるwsogclient.jar）を追加します。

※ RAD：Rational Application Developer

ここからは、クライアント側の作業手順です。

まずは、RADのプロジェクトセットアップです。

ポイントは以下2点です。

・プロジェクトを作成した後に、前のステップでエクスポートしておいたobjectGrid.xmlファイルをMETA-NFディレクトリにインポートします。

・ビルドパスに、WXSクライアントが必要とするjarファイルを追加します。

23



アプリケーション作成

アプリケーションコードを書く～もっともシンプルなサンプル

クライアント側（WAS統合環境の場合）

～省略～

public class XC10AccessServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

static String gridName = "QIT_SimpleGrid";

static String mapName = "QIT_SimpleGrid";

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException {

try {

ObjectGridManager ogmgr = ObjectGridManagerFactory.getObjectGridManager();

ClientClusterContext ccc = ogmgr.connect("192.168.11.185:2809", null,null);

ObjectGrid ogm = ogmgr.getObjectGrid(ccc, gridName);

Session session = ogm.getSession();

ObjectMap customerMap = session.getMap(mapName);

session.begin();

customerMap.put(1, "value1");

System.out.println(customerMap.get(1));

customerMap.remove(1);

session.commit();

} catch (ConnectException e) {

e.printStackTrace();

～省略～

XC10へ接続

管理コンソールでのカタログクラスタードメイン定義を参照できる

セッションを作成セッションは、以下のメソッドを提供マップへのアクセストランザクションの管理

セッションを通じてマップへアクセスマップはXC10側で定義したもの（objectgrid.xmlで定義されている）

セッションの開始、終了

トランザクションの開始、終了に相当

マップに含まれるデータにアクセスget / put / update / remove

プロジェクトのセットアップが終わったら、実際にアプリケーションコードを書きます。

マップへのアクセスの流れは上記のようにほぼ型どおりのアクセスになります。順に処理を解説します。

まず初めの処理として記述するのはXC10への接続を行う部分です。XC10に接続したら、XC10で設定したグリッド名を指定してObjectGrdを取得します。

次に、セッションを生成します。ObjectGridに含まれるマップへは、セッションを通じてアクセスします。

生成したセッションを開始します。開始後、実際にget / put / update / remove メソッドを実行し、マップ内のデータにアクセスします。

処理が終わったら、セッションを終了します。

以上のような流れで処理を実装します。

24



EARファイルを生成・導入クライアント側（WAS統合環境の場合）

1. RAD上でアプリケーションをテストします。

2. サーバー環境に導入するために、アプリケーションアーカイブファイル（ear）をエクスポートします

3. 生成したEARをWASサーバー環境

にインストール

アプリケーションコードが完成したら、アプリケーションが正しく動作するか否か、ロジックが通るか否かを確認します。

テスト後、開発端末から開発環境・検証環境・本番環境にデプロイするために、アプリケーションをEAR（WAR）ファイルとしてエクスポートします。

あとは、エクスポートされたアプリケーションを各環境にインストールして終了です。

25



§4. ＷＸＳとの機能差異

XC10はWXSのアプライアンス製品である旨、冒頭でご説明しましたが、では、両者に機能的にどのような差異があるか、についてご説明します。

26



WXSとXC10 Simple DataGridの機能比較

○○HTTPセッションストア

○○動的キャッシュストア

○RESTデータサービス

○専用モニターコンソール

○監視

○インデックス

○EventListenerr

○ObjectTransformer

○Loader

○Evictor

プラグイン機能

○トランザクション管理

○DataGrid

○EntityManager

○○ObjectMap

API

DataPower XC10WebSphere eXtreme Scale機能

上記の表は、WXSが持つ主要な機能を表で表したものです。それぞれの機能に対して、両者が持っているものに「○」をつけています。

こうしてみてみると、両者の機能的差異が際立ちます。

機能的な豊富さではWXSと比較になりませんが、 XC10はアプライアンス製品であるためそもそも特定の機能に特化・専用化されており、安定性・構成の手間、専用のモニタリングコンソールなど、キャッシング用途に使用するのであれば、迅速配備、運用コスト軽減の観点で最適な選択肢となっています。

27



WXSとの機能比較サマリ – 重要なポイント

サポートされないものクライアント側 ObjectGrid 構成のカスタマイズ

ローダー

インデックス

エンティティ・マネージャー

サーバー側（XC10側）で実装するプラグイン

クエリー

ObjectMap.getNextKeyサーバー側でのコーディングが必要なもの

コピーモードWXSの場合、以下を選択可能

COPY_ON_READ_AND_COMMIT / COPY_ON_READ / COPY_ON_WRITE / COPY_TO_BYTESXC10の場合、 COPY_TO_BYTES のみサポート

コミット時にはじめてマップへの反映が行われる

ロック・ストラテジーWXSの場合、「Optimistic locking」 / 「Pessimistic locking」を選択可能

XC10の場合は、「NONE」のみ指定可能、つまり、厳密なトランザクション管理を行うことができない

XC10 Simple DataGridでは、あくまで

データをキャッシュ的に扱う場合に利用する。

厳密な整合性維持が必要な場合は、WXSを使用する。

但し、XC10をSimple DataGrid、一時的なデータ保管庫として使用するためには留意すべき重要なポイントがあります。

まずは、コピーモードについてです。コピーモードは何かというと、ObjectMap APIではトランザクションを開始すると、トランザクションで使用するマップは特殊なマップにコピーされます。コピーモードは、オブジェクトの更新対象を、コピーにするのかオリジナルのマップにするのか、どちらにするのかを指定します。

コピーモードは、トランザクション中の更新処理の整合性維持（ロールバックするか等）強度とパフォーマンスに影響します。（非常に大雑把に言うと、トランザクション分離レベルと近い概念という事が出来るかと思います。）

WXSでは、コピーのタイミングを、 COPY_ON_READ_AND_COMMIT / COPY_ON_READ / COPY_ON_WRITE / COPY_TO_BYTES から選択でき、厳密さとパフォーマンスをチューンできますが、XC10の場合は、 COPY_TO_BYTESのみサポートしています。

COPY_TO_BYTESでは、 COPY_ON_READ_AND_COMMITと同様の振る舞いになりますが、値はシリアライズされて保管されます。つまり、コミットされるまでは、コピーに対しての操作となり、コミット時にはじめてマップへの反映が行われます。

もう一点、非常に重要なポイントが、充分なトランザクション管理機能を提供していないという点です。WXSでは、「Optimistic locking」 / 「Pessimistic locking」を選択可能であり、トランザクションの整合性を維持する機構があります。しかしながら、XC10の場合は、「NONE」のみ指定可能、つまり、厳密なトランザクション管理を行うことができないことになります。

XC10はキャッシングを行うコンポーネントであるという位置づけですので、そもそも厳密なトランザクション管理が必要な場合には、WXSを使用する、という切り分けになります。

28



まとめ

XC10を一時的なデータ保管庫 = キャッシュ・ストアとして利用

することで、パフォーマンスを向上

アプライアンスであるため、信頼性が高く、構築・メンテナンスが簡単

整合性を重視するRDBと比較して、拡張性、可用性に優れたソ

リューション

29



参考資料

WebSphere DataPower XC10InfoCenter

http://publib.boulder.ibm.com/infocenter/wdpxc/v1r0/index.jspOverview demos

https://www14.software.ibm.com/webapp/iwm/web/signup.do?source=sw-app&S_PKG=xc10_video&S_TACT=109J62SW&S_CMP=web_ibm_ws_appinfra_hero_xc10

WebSphere eXtreme ScaleInfoCenter

http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r1/index.jspdeveloperWorks Japan: WebSphere eXtreme Scale の技術情報サイト

http://www.ibm.com/developerworks/jp/websphere/category/wxd/wxs.htmldeveloperworks連載：WebSphere eXtreme Scaleで実現する次世代クラウドのデータグリッド

http://www.ibm.com/developerworks/jp/websphere/library/wxd/wxs71_cloud_datagrid/1.htmlhttp://www.ibm.com/developerworks/jp/websphere/library/wxd/wxs71_cloud_datagrid/2.htmlhttp://www.ibm.com/developerworks/jp/websphere/library/wxd/wxs71_cloud_datagrid/3.html

http://www.youtube.com/user/ibmextremescale#p/a

Weekly video podcasts covering customers questions and forum posts on the IBM WebSphere eXtreme Scale product.

Additional resources

datapower xc10 アプライアンスワークショップ simple datagrid...

Documents