WebSphere eXtreme Scaleで実現する次世代クラウドのデータグリッド: 第2回 アプリケーションを改変せずにデータグリッドを活用する

この記事では、アプリケーション実装を変更することなく、IBMデータグリッド製品であるWebSphere eXtreme Scale(WXS)を活用して、Webアプリケーションの高速化や高可用性を実現する3つのシナリオと設定方法をご紹介します。
1つめは、WebSphere Application Server(WAS)の動的キャッシュでの利用です。これによって、生成されたWeb画面をキャッシュし、高速応答を実現します。
2つめは、Java Persistence API(JPA)キャッシュへの適用です。JPAを使用したアプリケーションの応答性能をアップします。
3つめは.Java EEアプリケーションのHTTPセッションの永続化(セッション・パーシスタンス)での利用です。WXSを使用することで、管理範囲や製品・バージョンの相違を超えてより広範にセッション・パーシスタンスを適用することが可能になります。
最後に、上の3つのシナリオに関連して、 WXSの機能を搭載した新しいキャッシュ・アプライアンス製品WebSphere DataPower XC10について簡単にご紹介します。

伊藤 隆, WebSphere Client Technical Professional, IBM China

伊藤 隆, WebSphere Client Technical Professional, IBM



植田 毅, WebSphere Client Technical Professional, IBM China

植田 毅, WebSphere Client Technical Professional, IBM



2010年 9月 30日

1.はじめに ~WXS活用の3つのシナリオ~

IBM WebSphere eXtreme Scale(WXS)は、大規模なスケーラビリティと高速応答を実現するキーバリュー・ストア(KVS)製品であり、元来は、Javaクライアントから、Java APIを通じてアクセスするインメモリー・データストアです。前回記事では、Java以外の開発言語やシステム環境からのWXSへのアクセスを実現するREST Data Service機能を紹介しました。
今回は、WASのJavaアプリケーションの改変をせずにWXSを活用する3つのシナリオを、その構成方法と共にご紹介します。

キャッシュによる高速化&スケーラビリティの実現

ユーザー数や業務量の増加によって求められる処理能力の向上、或いは、性能悪化への対処は、システム担当者の頭を悩ませる問題です。放置すれば、ユーザーの頻繁なクレームによる企業イメージの悪化や販売機会の損失、オーバーフローによる業務の停止、等々の問題に繋がる危険があります。

対処方法として、まず考えられるのは機器の増設ですが、処理のボトルネックがバックエンドのホストやデータベース・サーバーである場合、増設が困難なケースがあります。
データグリッドは、このようなスケーラビリティ問題に対して高いコスト・パフォーマンスを持つソリューションです。しかし、一方で、データグリッドを活用するように、アプリケーションを改変することは、開発要員の確保や予算の都合上、難しい場合もあります。
では、機器増設やアプリケーション改変の困難を回避しつつ、パフォーマンスの改善は図れないでしょうか?
次の2つのシナリオは、この課題に対するソリューションになります。

1つ目は、WebSphere Application Server(WAS)の動的キャッシュ機能(DynaCache)を使用し、そこにWXSを利用することです。動的キャッシュは、主に、JSPやサーブレットにより動的に生成されたデータをキャッシュし、同じパラメータ等を伴うリクエストへの応答を高速化するWASの機能です(動的キャッシュについては、参考文献を参照ください)。では、WASに本来ある機能に対して、なぜWXSを利用するのでしょうか?まず、WXSサーバーにデータをキャッシュすることで、使用できるメモリー量を飛躍的に増大させることができます。キャッシュ量の拡大に関しては、WAS動的キャッシュ機能のディスクへのオフロード機能を使用することも考えられますが、リモートのWXSサーバーに配置する方がより高速です。

2つ目は、Java Persistence API(JPA)のキャッシュです。JPAキャッシュは、JavaオブジェクトとRDBデータとの連携、いわゆるO/Rマッピングを実現するJava Persistence APIにおいて、DBへのアクセス結果をキャッシュして、DBアクセスを削減し、応答性能の向上を図るものです。JPAアプリケーションであれば、WXSによるJPAキャッシュの恩恵を得ることができます。WXSを利用することで、ローカルにキャッシュする場合に比べて、より大きなキャッシュ容量を使用し、また、複数サーバー間でキャッシュを共用することが可能になります。

セッション・パーシスタンス機能の拡張

残る3つ目のシナリオは、WXSのセッション・パーシスタンス機能の利用です。元来セッション・パーシスタンス機能を持たないアプリケーション・サーバーでも、J2EE 1.4以降をサポートしていれば、WXSを使ってセッション・パーシスタンス機能を実現することが可能です。この機能は、サーブレット・フィルターにより実装されており、これをアプリケーション・パッケージに組み込むツールも提供されています。また、セッション・パーシスタンス機能を持つアプリケーション・サーバーであるWAS NDにおいても、管理ドメインであるセルを超えたセッション共有を可能にするソリューションにもなります。WXS V7.1においては、特にWAS (v6.1及びv7.0)との連携が強化されており、管理コンソールによる設定だけで、簡単にWXSによるセッション・パーシスタンスを利用することが可能になりました。

2章以降では、以上の各機能の具体的な使い方を説明します。WAS V7.0及び、WXS v7.1を前提としています。

2.WebSphere Application Serverの動的キャッシュでのWXSの利用

動的キャッシュにおいて、WXSを利用する利点については、既に1章で述べました。ただし、実際にWXSの利用が適しているか、また、加えて、どのようなトポロジー構成が適切かは、アプリケーション特性を勘案して慎重に検討する必要があります。WXSのインフォセンターに、このような検討の要点の記載があります。同記載にあるようにWXSのトポロジーには、組み込み(embeded)、組み込み区分化(embeded partitioned)、リモート(remote)があります。ここでは、キャッシュ・サイズを最大化できるリモート・トポロジーの場合について、その構成手順を説明します。

WXSサーバーの構成と稼動

まず、キャッシュ・データを保持する、WXSサーバーを構成します。サーバーを構成するノードには、WXS V7.1が既にスタンドアロン・サーバーとして導入済みと仮定します。
<WXS導入先ディレクトリ>/ObjcetGrid/dynaCache/etcにサンプルの定義ファイル(dynacache-remote-objectgrid.xml)及び、配備設定ファイル(dynacache-remote-deployment.xml)があります。

(定義ファイルを見ると、WXS V7からサポートされたテンプレート・マップによる動的マップ機能が使用されていることがわかります。この機能に関する詳細はWXSのインフォセンターを参照ください)
今回は、以上の設定ファイルをほぼそのまま使用します。ただし、それぞれの設定ファイル中のObjectGrid名は、WASのデフォルトのキャッシュ・インスタンス名にあわせて「baseCache」に変更します。もし、WAS側で、デフォルトではなく新規のキャッシュ・インスタンスを作成して、それに対してWXSを利用したい場合には、同名のObjectGridをWXSサーバー側で構成する必要があります。
次に、カタログ・サーバーを起動します。(カタログ・サーバーについては、WXSの参考文献を参照ください)

 
        startOgServer.bat cat1 -catalogServiceEndpoints cat1:<host_name>:6601:6602

カタログ・サーバーが起動したら、実際にデータを保持するコンテナ・サーバーを起動します。今回はテストのために1サーバーのみ稼動しますが、コンテナ・サーバー・プロセスを追加稼動していくことで、キャッシュ容量を増加させることが可能です。

 
startOgServer.bat dynacacheserver1 –objectgridFile <WXS_installed_dir>
/ObjcetGrid/dynaCache/etc/dynacache-remote-objectgrid.xml -deploymentPolicyFile
 <WXS_installed_dir>/dynacache-remote-deployment.xml -catalogServiceEndpoints
 <catalog_server_host>:2809

以上で、サーバー側の準備は完了です。

WASの設定

WXSサーバーの準備ができたので、次にキャッシュ対象のサーブレットを稼動させるWASの設定を説明します。

① WXSクライアントの導入
WAS(V7.0.0.9以降)の環境に、WXS V7.1クライアントを導入します。このとき、WXSの導入先ディレクトリは、WASの導入ディレクトリである必要があります。(存在しない、或いは空のディレクトリを指定すると、スタンドアロンのクライアントとして導入されます)導入後、WASを起動して管理コンソールにアクセスすると、システム管理の、ナビゲーション・ペインに、WebSphere eXtrme Scaleという項目が追加されていることがわかります。

② カタログ・サーバー・ドメインの設定
ナビゲーション・ペインのWebSphere eXtrme Scaleを展開して、カタログ・サービス・ドメインをクリックします。図のようにカタログ・サービス・ドメインのリスト画面が表示されます(図1)。

図1. 管理コンソール:カタログ・サービス・ドメイン

クリックして大きなイメージを見る

図1. 管理コンソール:カタログ・サービス・ドメイン

新規作成をクリックして、ウィザード画面でカタログ・サーバー・ドメイン名を入力し、先に稼動させたカタログ・サーバーのIPアドレス、及び、リスナー・ポートとJMXポートをカタログ・サーバー・エンドポイント設定のリモート・サーバーに記入します(図2)。リスナー・ポート及びJMXポート番号は、カタログ・サーバー起動時の標準出力ログ SystemOut.log中で確認できます。例えば、JMXポート番号は、以下のメッセージで確認できます。

 
        CWOBJ1600I: ManagementGateway サービスがポート (1099) で開始しました。

設定が終わったらOKをクリックし、次の画面で保存をクリックします。

図2. カタログ・サービス・エンドポイントの設定

(カタログ・サーバーをクラスター化している場合は、カタログ・サーバー・エンドポイントに追加します。)
カタログ・サーバー・ドメインのリスト画面に戻ったら、「テスト接続」ボタンで、カタログ・サーバーへの接続が成功することを確認します。

③ デフォルトのキャッシュ・インスタンスのプロバイダーをWXSに変更
デフォルトのキャッシュ・インスタンスのキャッシュ・プロバイダーをWXSに変更します(デフォルトではない、新規にキャッシュ・インスタンスを作成してキャッシュ・プロバイダーをWXSに設定することも可能です)。管理コンソールのナビゲーション・ペインで、「サーバー・タイプ」→「WebSphere Application Server」を選び、対象のサーバーを選択します。「コンテナー・サービス」中の動的キャッシュをクリックして、設定画面を開きます。キャッシュ・プロバイダーをWebSphere eXtreme Scaleに変更します(図3)。

図3. 管理コンソール:動的キャッシュ・サービスの設定
図3. 管理コンソール:動的キャッシュ・サービスの設定

④ カスタム・プロパティによるトポロジーの設定
次に、サーバーのJava仮想マシンのカスタム・プロパティに以下の値を設定します。

名前: com.ibm.websphere.xs.dynacache.topology
値: remote

(組み込みの場合はembedded、或いは、組み込み区画化の場合はembedded_partitionedを値に指定します。但し、これらのトポロジーを使用する場合は、WASにWXSサーバーの導入が必要です)

⑤ サーブレット・キャッシュの有効化
同じく管理コンソールのサーバー設定中で、Webコンテナー設定のWebコンテナーをクリックし、「サーブレットのキャッシュを使用可能にする」にチェックします(図4)。

図4. サーブレット・キャッシュの使用可能化
図4. サーブレット・キャッシュの使用可能化

⑥ アプリケーション側の設定
アプリケーションのサンプルとして、今回は、WASに付属するPlantsByWebSphereを使用します。動的キャッシュでは、WEB-INFに、配置したcachespec.xmlファイル中に対象となるサーブレット等を指定します。例えば、PlantsByWebSphereのImageServlet(イメージをDBから取得するサーブレット)をキャッシュ対象にするために、以下のように記述します。それぞれの記述子の意味については、WASのインフォセンターを参照ください。

 
<?xml version="1.0" ?>
<!DOCTYPE cache SYSTEM "cachespec.dtd">
<cache>
  <cache-entry>
    <class>servlet</class>
    <name>/servlet/ImageServlet</name>
    <cache-id>
      <component id="*" type="parameter">
        <required>false</required>
      </component>
      <component id="" type="pathinfo">
        <required>false</required>
      </component>
      <component id="host" type="header">
        <required>false</required>
      </component>
      <timeout>180</timeout>
    </cache-id>
  </cache-entry>
</cache>

⑦ WASの再起動
WASを再起動します。以下のようなメッセージが、標準出力ログ(SystemOut.log)に出力されます。

 
        CWOBJ4508I: WebSphere eXtreme Scale プロバイダーが、トポロジー remote を使用して、
        名前が baseCache の Dynamic Cache インスタンスを作成しました。

以上で設定は完了です。

PlantsByWebSphereにアクセスして、動的キャッシュが機能しているかを確認します。以下は、Fruits&Vegitablesのリストページです。それぞれのイメージ取得の際にImageServletが呼ばれています。

図5. PlantsByWebSphereのリスト画面
図5. PlantsByWebSphereのリスト画面

トレース出力により、キャッシュを使用している様子がより詳細にわかります。管理コンソールの「ログ詳細レベルの変更」で、次のトレース・ストリングを設定します。*=info: ObjectGridDynaCache=all

 
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0006:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@18351835 with a TTL of 180
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0005:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@c7e0c7e with a TTL of 180
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0002:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@1bf31bf3 with a TTL of 180
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0004:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@33a433a4 with a TTL of 180
Distributed GET: key=/PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID
=F0007:host=192.168.11.77:9080:
requestType=GET paritionId= null shard=null returned val= null
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0007:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@66ba66ba with a TTL of 180
Distributed GET: key=/PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID
=F0008:host=192.168.11.77:9080:
requestType=GET paritionId= null shard=null returned val= null
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0008:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@36403640 with a TTL of 180
Distributed GET: key=/PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID
=F0009:host=192.168.11.77:9080:
requestType=GET paritionId= null shard=null returned val= null
baseCache PUT /PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&inventoryID=F0009:
host=192.168.11.77:9080:requestType=GET-->
com.ibm.ws.objectgrid.dynacache.entries.CacheEntryData@63866386 with a TTL of 180
Distributed GET: key=/PlantsByWebSphere/servlet/ImageServlet:*=action=getimage&nventoryID
=F0010:host=192.168.11.77:9080:
requestType=GET paritionId= null shard=null returned val= null

また、WXSサーバーでのキャッシュの様子は、WXSのWebコンソールで確認できます(コラム「WXSトランザクションのモニター」を参照ください)。


3.WXSによるJava Persistence API (JPA) キャッシュ

WXSでは、OpenJPAとHibernate Java Persistence API (JPA) プロバイダーの両方に対するレベル2 (L2)のキャッシュ・プラグインが組み込まれています。特に、参照が主なアプリケーションではより高いスループットを得ることが可能です。更新処理が主な場合、データベースとキャッシュの間でデータの一貫性を保持するためのオーバーヘッドがかかるためキャッシュを利用するか考慮が必要です。このプラグインを使用すると、動的キャッシュの場合と同様に、組み込み(EMBEDDED)、組み込みの区画化(EMBEDDED_PARTITION)、およびリモート(REMOTE)の3つのトポロジー・タイプを作成可能です。

トポロジー・タイプ特長
組み込みトポロジー
(EMBEDDED)
各アプリケーションのプロセス内にWXSサーバーを作成。キャッシュ・データの量が少なく、1つのプロセスに収まる場合に最も良く機能する。全てのキャッシュ読み取りがローカル・アクセスで非常に早い。
組み込みの区画化トポロジー
(EMBEDDED_PARTITION)
キャッシュ・データの量が多く、1つのプロセスに収まらない場合、データを複数のプロセスに分割する。多くのキャッシュ読み取りがリモートになるため、パフォーマンスは組み込みトポロジーほど高くない。
リモート・トポロジー
(REMOTE)
全てのキャッシュ・データを1つ以上の個別のプロセスに保管する。大容量のデータを保管でき、アプリケーション・プロセスのメモリー使用を減らせる。全てのキャッシュ・アクセスがリモートで行われる。リモート構成は、アプリケーションから独立して管理が必要。

WASのOpenJPAキャッシュとの違い

WASはv6.1でのfeature pack for EJB、v7.0からJPA実装のOpenJPAが標準提供されており、WAS単独でもOpenJPAはキャッシングを利用することができます(WASの同一プロセス内にデータをキャッシュすることが可能です)。WXSを利用する利点はどういう所にあるのでしょうか?WASでJPAキャッシュを使用する場合、複数のアプリケーション・サーバーがあるような分散環境では、キャッシュを共用できません。しかし、WXSを利用した組み込みトポロジーの場合、分散環境でもキャッシュが全てのプロセスで自動的に複製されるので、WASをしのぐ利点があります。あるクライアントが値をキャッシュすると、他のクライアントが、そのキャッシュされた値をローカルのメモリー内で使用できるようになります。他の2つのトポロジーでは、キャッシュに使用できる領域を飛躍的に拡大することができます。

OpenJPAキャッシュの設定

ここでは、動的キャッシュと同様、PlantsByWebSphereアプリケーションを使用して、OpenJPAキャッシュを、組み込みトポロジーで設定してみます。組み込みトポロジーを設定するには以下を行います。

  1. WASにWXSサーバー、WXSクライアントをインストール
  2. Persistence.xmlファイルの修正
  3. (Option) 構成ファイルの用意
  4. アプリケーションのインストール

組み込みトポロジーを設定する場合、まず、WASに、WXSサーバー、WXSクライアントをインストールする必要があり、プロファイルもWXS用に拡張します。

2つ目に、persistence.xmlファイルを修正します。WXSは、OpenJPAに対してDataCache実装、QueryCache実装の両方を提供しています。JPAキャッシュの設定は、persistence.xmlファイルにopenjpa.DataCacheとopenjpa.QueryCache構成プロパティーを追加します。DataCacheとQrueryCache構成は互いに独立しており、いずれかの構成を使用可能にすることができます。両方の構成を使用可能にした場合、QueryCache構成は、DataCache構成と同じ構成が使用されます。PlantsByWebSphereアプリケーションでは、Queryも使用されているため、両方定義します。PlantsByWebSphereアプリケーションのpersistence.xmlファイルは、PlantsByWebSphereEJB.jar/META-INF以下にあります。persistence.xmlファイルの編集後は、以下のようになります。追加部分は太字にしてあります。

 
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns=http://java.sun.com/xml/ns/persistence
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0"
  xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
  http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="PBW">
    <jta-data-source>jdbc/PlantsByWebSphereDataSource</jta-data-source>
    <non-jta-data-source>jdbc/PlantsByWebSphereDataSourceNONJTA</non-jta-data-source>
        
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.BackOrder</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.Customer</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.IdGenerator</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.Inventory</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.Order</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.OrderItem</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.OrderItem$PK</class>
    <class>com.ibm.websphere.samples.plantsbywebsphereejb.Supplier</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
      <property name="openjpa.jdbc.SynchronizeMappings"
        value="buildSchema(ForeignKeys=true)"/>
      <property name="openjpa.DataCache" 
        value="com.ibm.websphere.objectgrid.openjpa.ObjectGridDataCache
        (ObjectGridName=JPACache, ObjectGridType=EMBEDDED, maxNumberOfReplicas=4)"/>
      <property name="openjpa.RemoteCommitProvider" value="sjvm"/>
      <property name="openjpa.QueryCache" 
        value="com.ibm.websphere.objectgrid.openjpa.ObjectGridQueryCache()"/>
    </properties>
  </persistence-unit>
</persistence>

WXSのキャッシュ設定として、openjpa.DataCacheプロパティーにWXSのクラスObjectGridDataCacheを、openjpa.QueryCacheプロパティーに、WXSのクラスObjectGridQueryCacheを指定します。また、openjpa.RemoteCommitProviderをsjvmに設定する必要があります。
キャッシュ・クラスのプロパティー・リストにObjectGridName、ObjectGridType や、その他の単純なデプロイメント・ポリシー関連のプロパティーを指定することで、キャッシュ構成をカスタマイズできます。(NumberOfPartitions、ReplicaMode、ReplicaReadEnabled、MaxNumberOfReplicasなど。)ObjectGridNameは、名前が競合しない値を設定する必要があります。ObjectGridTypeがEMBEDDEDの場合、NumberOfPartitionsの値は「1」、ReplicaReadEnabledの値は「TRUE」で変更することはできません。

WXSの構成は、persistence.xmlのキャッシュ・クラスのプロパティーを設定すれば十分ですが、構成をさらにカスタマイズするには、WXSの構成ファイルをpersistence.xmlファイルと同様にMETA-INFディレクトリに置きます。これが3つ目の構成ファイルの準備です。ここでは構成ファイルは準備しませんが、構成ファイルの例は、WXSのインフォセンターに記述がありますので参照ください。

組み込みの区画化トポロジーは、ほぼ同様の設定で行うことが可能です。NumberOfPartitionsの数を変更することで、データの分割が可能になります。
リモート・トポロジーに関しては、WXSの環境をWASとは別に作成する必要があります。
リモート・トポロジーでは、WXSサーバー側、WXSクライアント側(WAS)では以下のようなことを行うことで、構成することができます。

  • WXSサーバー側
    • OpenJPAのクラスをクラスパスで指定
    • キャッシュするEntityクラスをクラスパスで指定
    • 組み込みトポロジーや組み込み区画化トポロジーでは、オプションであったWXSの構成ファイルをpersistence.xmlに対応し作成し、作成した構成ファイルでWXSを起動
  • WXSクライアント側(WAS)
    • カタログ・サービス・ドメインで、上記で起動したWXSサーバーのカタログ・サーバーの指定を行う(動的キャッシュでの設定方法と同様)

OpenJPAキャッシュの動作確認

これまでで設定は終了です。実際にアプリケーションをインストールして動作確認を行います。PlantsByWebSphereにアクセスします。PlantsByWebSphereの商品情報はDBに保存されており、それらのデータへのアクセスがJPAで実装されています。「Bonsai Tree」を選択してみます。

図6. PlantsByWebSphere
図6. PlantsByWebSphere

初めてアクセスする際には、WXSの初期化処理の実行に時間がかかります。標準出ログ(/SystemOut.log)を見れば、WXSの初期化のメッセージが確認できます。

 
CWOBJ0047I: ObjectGrids: [JPACache] の 1 つ以上の MapSets に対して開発モードが有効になっています。
実動デプロイメントの場合、デプロイメント・ポリシー・ファイルの開発モード属性を false に設定してください。
CWOBJ7000I: ObjectGrid JPACache は、履歴統計の保管用に使用可能になっています。
CWOBJ7002I: ObjectGrid:MapSet JPACache:MAPSET_JPACache は、
履歴統計の保管用に使用可能になっています。
CWOBJ0047I: ObjectGrids: [JPACache] の 1 つ以上の MapSets に対して開発モードが有効になっています。
実動デプロイメントの場合、デプロイメント・ポリシー・ファイルの開発モード属性を false に設定してください。
CWOBJ0046I: memoryThresholdPercentage プロパティーがサーバー・プロパティー・ファイルに
指定されておらず、MemoryMXPool Bean が設定されていませんでした (現行値は 0)。
デフォルト値 70 が使用されます。
CWOBJ0034I: メモリー使用率のしきい値は 70 % に設定されています。
CWOBJ0036W: Java heap メモリー・プールのメモリー使用率のしきい値を 0K から 183500K に変更しています。
CWOBJ0037W: Java heap メモリー・プールのメモリー・コレクション使用率のしきい値を
 0K から 183500K に変更しています。
CWOBJ1511I: JPACache:IBM_SYSTEM_ENTITYMANAGER_MAPSET:0 (プライマリー) は使用可能です。
CWOBJ1511I: JPACache:MAPSET_JPACache:0 (プライマリー) は使用可能です。
CWOBJ3134I: ObjectGrid タイプが 組み込み で、レプリカのデフォルトの最大数が 47 です。
レプリカの最大数は、システム内の JVM の数以上でなければなりません。

トレースを取得すると、実際にキャッシュを使用している様子を確認することができます。管理コンソールの「ログ詳細レベルの変更」で、次のトレース・ストリングを設定します。*=info: openjpa.DataCache=all: openjpa.Query=all
アプリケーションにアクセスすると、キャッシュ・ミスやキャッシュへの格納等の動作状況がトレース出力(trace.log)で確認できます。(以下は、そのメッセージ例です)

openjpa.Query: Trace: 照会を実行しています: [select i from Inventory i where i.category = 
:category ORDER BY i.inventoryId] パラメーター: {category=0}
openjpa.DataCache: Trace: キー "org.apache.openjpa.datacache.QueryKey@309a9e01[query:
[select i from Inventory i where i.category = :category ORDER BY i.inventoryId],
access path:[com.ibm.websphere.samples.plantsbywebsphereejb.Inventory],subs:true,
ignoreChanges:false,startRange:0,endRange:9223372036854775807,timeout:-1]" 
のルックアップ時にキャッシュ・ミスしました。
openjpa.DataCache: Trace: キー "F0001" のルックアップ時にキャッシュ・ミスしました。
openjpa.DataCache: Trace: キー "F0001" のルックアップ時にキャッシュ・ミスしました。
openjpa.DataCache: Trace: キー "F0001" をキャッシュに入れました。
openjpa.DataCache: Trace: キー "F0001" のルックアップ時にキャッシュ・ヒットしました。
openjpa.DataCache: Trace: キー "F0002" のルックアップ時にキャッシュ・ミスしました。
openjpa.DataCache: Trace: キー "F0002" のルックアップ時にキャッシュ・ミスしました。
openjpa.DataCache: Trace: キー "F0002" をキャッシュに入れました。
openjpa.DataCache: Trace: キー "F0002" のルックアップ時にキャッシュ・ヒットしました。

4.WXSを使ったセッション・パーシスタンス

ここまでの2つのシナリオは、WXSをキャッシュとして利用するケースでした。もう1つ別の活用シナリオとして、この章では、セッション・パーシスタントにWXSを利用する場合について述べます。アプリケーション・サーバーとしては、WAS V7を前提とします。
まず、WXSによるセッション・パーシスタンスのトポロジーを決める必要があります。WASの場合は、、組み込み(embedded)または、リモート(remote)からの選択になります。(WAS以外のアプリケーション・サーバーでは組み込みはサポートされません)組込みトポロジーでは、WASプロセス内でWXSサーバーが稼動し、格納されたセッションは、他のサーバーで稼動するWXSサーバーの何れかに複製されます。一方、リモート・トポロジーでは、WASとは別個の専用WXSサーバーに全サーバーが保持するセッションが複製されます。詳細については、インフォセンターを参照ください。ここでは、リモートのトポロジーを前提に、設定方法を説明します。

WXSサーバーの稼動

セッション・パーシスタンス用設定ファイルのサンプルが、<WAS導入先ディレクトリ>/ObjectGrid/session/samplesにあります。ここでは、リモートのサーバー用の定義ファイル(objectGridStandAlone.xml)及び配備ファイル(objectGridDeploymentStandAlone.xml)を、そのまま使用して、コンテナ・サーバーを稼動します。((カタログ・サーバーは稼動済みとします)

 
        startOgServer.bat dynacacheserver1 -objectgridFile <WAS_installed_dir>
        /ObjectGrid/session/samples/objectGridStandAlone.xml -deploymentPolicyFile 
        <WAS_installed_dir>/ObjectGrid/session/samples/objectGridDeploymentStandAlone.xml 
        -catalogServiceEndpoints <catalog_server_host>:2809

以上で、WXSサーバー側の準備は完了です。

WASの設定

WAS V7.0において、セッション・パーシスタンスでリモートのWXSを利用する設定は、非常に簡単です。WXSクライアント導入後、セッション管理の画面には、「eXtreme Scale セッション管理設定」のメニューが追加されています。ここでは、デフォルトでアプリケーション・サーバーに導入されるサンプル・アプリケーションDefaultApplicationで、eXtreme Scaleセッション管理を設定します。(図7)

① 設定画面で、「セッション管理使用可能」にチェック

② 「セッション・パーシスタンスの管理」のリストから「リモート eXtreme Scaleデータグリッド」を選択します。(選択肢には、他に「組込みeXtreme Scaleデータグリッド」と「IBM WebSphere DataPower XC10 Appliance」があります。後者のアプライアンス製品に関しては、次章で簡単にご紹介します)

図7. 管理コンソール:eXtreme Scale セッション管理設定画面
図7. 管理コンソール:eXtreme Scale セッション管理設定画面

③ 「リモート・セッション・データグリッドを管理するカタログ・サービス・ドメイン」に、対応するカタログ・サーバーを登録したカタログ・サービス・ドメインを指定します。指定が正しければ、「アクティブ・リモート・データグリッドのリスト」に、カタログ・サーバーに構成したObject Gridの名前のリストが表示されます。先ほど稼動させたサーバーに設定したObject Grid名sessionを選択します(図8)。

図8. 管理コンソール:リモートeXtreme Scaleデータグリッド構成の設定
図8. 管理コンソール:リモートeXtreme Scaleデータグリッド構成の設定

④ OKをクリックして、表示される画面で「保存」をクリックして、変更を確定します。

⑤ サーバーを再起動します。

以下のメッセージが、SystemOut.log出力で確認できます。

 
        CWWSM0007I: ObjectGrid ベースの Session Manager を使用しています。

以上で設定は完了です。実際にDefaultApplicationのHit Countアプリケーションで稼動を確認します。http://<ホスト名>:<ポート>/hitcountにアクセスします(図9)。最初に、Session state(create if neccesary)をチェックしてIncrementボタンをクリックするとセッションが作成されます。その後は、Existing session state onlyをチェックして、Incrementボタンをクリックすると、セッションを使用してカウント・アップしていきます。

図9. デフォルト・アプリケーションのHit Count Demonstration
図9. デフォルト・アプリケーションのHit Count Demonstration

最初のWXSサーバーへのアクセス時に、WASのSystemOut.logには、以下のようなメッセージが表示され、WXSサーバーにセッションを保持していることがわかります。

 
   CWOBJ4700I: マップ名 objectgridSessionAttributeEvicted がテンプレート・マップ 
   objectgridSessionAttribute.* の正規表現に一致しました。
   objectgridSessionAttributeEvicted マップが ObjectGrid session に対して作成されました。
   CWOBJ4700I: マップ名 objectgridSessionAttribute がテンプレート・マップ 
   objectgridSessionAttribute.* の正規表現に一致しました。
   objectgridSessionAttribute マップが ObjectGrid session に対して作成されました。

また、WXSコンソールで、アクセスの様子をモニターして、セッションの格納状況を確認することができます。(コラムを参照ください)


5.キャッシュ・アプライアンス製品XC10の概要

これまでは、ソフトウェア製品であるWXSの機能について触れてきましたが、WXSの姉妹製品とも言えるキャッシュ専用アプライアンス製品 IBM WebSphere DataPower XC10が2010年6月23日から出荷開始されています。ここでは、このアプライアンス製品の概要、ソフトウェア製品であるWXSと比べた相違点などについてご紹介します。

XC10は、企業のアプリケーションのパフォーマンス向上のために、「ドロップイン」で即座に使用できるキャッシュ専用アプライアンスです。大容量160GBのキャッシュを提供し、更にアプライアンスを追加することで容量を拡張することができます。WXSクライアントを導入すれば、WASから簡単に利用できます。また、Web UIにより、アプライアンスの管理・操作も非常に容易に行えます。

XC10使用用途

XC10は、多彩なWXSの機能のうち、特に、「HTTPセッション管理」、「WASの動的キャッシュ」にフォーカスしています。また、WXSで提供されているObjectMap APIを利用して、「Webサイド・キャッシュ」として利用することも想定されています。

図10. WebSphere DataPower XC10とWebSphere eXtreme Scaleの比較
図10. WebSphere DataPower XC10とWebSphere eXtreme Scaleの比較

本記事では、WASの動的キャッシュ、HTTPセッションに関して、WXSをサーバーとして使用した場合について紹介しましたが、XC10についても同様の操作で利用することができます。また、java.util.MapライクなAPIであるObjectMap APIを通じて、キーとバリューの形でデータをXC10にストア&照会することができます。(WXSでは、更にJPAライクなAPIであるEntityManagerAPIも提供しています)

XC10の利点

柔軟で多彩な機能を提供するWXSに対して、XC10はスピードとシンプルさを提供します。アプライアンスを利用することで、ソフトウェアであれば稼動システムの設計や構成に要したであろう工数及び期間を節約することができます。また、高いセキュリティ上の堅固さも特徴です(アクセスやコマンドが限定された専用OS、無理にこじ開ければデータが消失する筐体等)。

実際、XC10のセットアップは容易です。梱包されている状態から実際に利用できる状態になるまで、ラックへの配置、初期セットアップ(ネットワーク設定、日時設定)、ファームウェアのアップデートなどを含めても3時間程度で完了できます。アプリケーションの改修がない、セッション管理や、動的キャッシュであれば、セットアップ後すぐに利用することができるでしょう。また、ビルトインのWeb UIコンソールにより、パフォーマンスのモニターや、管理操作をWebブラウザーから直感的に行うことができます。


まとめ

当記事では、アプリケーションの改変をせずに、WASの動的キャッシュやJPAキャッシュ、及びセッション管理といった用途でWXSによる高速・スケーラブルなデータグリッド機能が活用できることを、具体的な設定方法を通じて説明しました。特にWASの動的キャッシュ及びセッション管理では、新しいアプライアンス製品WebSphere DataPower XC10を利用することも可能です。クラウド・コンピューティングへの関心の高さが示すように、今後、このような俊敏性へのニーズは更に高まっていくでしょう。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=548368
ArticleTitle=WebSphere eXtreme Scaleで実現する次世代クラウドのデータグリッド: 第2回 アプリケーションを改変せずにデータグリッドを活用する
publish-date=09302010