動的キャッシング 1 WebSphere Application Server V6.0 - Network Deployment -
by user
Comments
Transcript
動的キャッシング 1 WebSphere Application Server V6.0 - Network Deployment -
WebSphere Application Server V6.0
- Network Deployment -
動的キャッシング
1
当資料では以下の略語を使用しています。
( )内が正式名称になります。
製品名
WAS(WebSphere Application Server)
ND (WebSphere Application Server Network Deployment)
RAD (IBM Rational Application Developer for WebSphere Software)
製品に含まれるコンポーネント
AST (Application Server Toolkit)
IHS (IBM HTTP Server)
環境により異なるインストール・
ルート等については、以下の表記を使用しています。
<WAS_root> ：WASのインストール・ルート(Windowsデフォルト
：C:¥Program Files¥IBM¥WebSphere ¥AppServer）
<IHS_root> ：IHSのインストール・
ルート（Windowsデフォルト：
C:¥Program Files¥IBM¥IBM HTTP Server）
2
Agenda
n
WAS６動的キャッシング概要
動的キャッシュの基本設定
近年のWebシステムの課題
u
動的キャッシュ構成手順
u
なにがキャッシュできるのか？
u
サーブレット・JSPキャッシュ
コマンド・キャッシュ
オブジェクト・キャッシュ
u
動的キャッシュ・サービスの有効化
サーブレット/コマンド・キャッシュの
設定
u
cachespec.xmlの記述
l
l
l
n
n
u
u
どこでキャッシュするか？
u
いつキャッシュを無効化するか？
n
動的キャッシュの基本機能
u
キャッシュ・インスタンス
u
キャッシュの複製
キャッシュのディスク・オフロード
u
動的キャッシュの応用設定
u
外部キャッシュ
u
外部キャッシュの設定
ESIキャッシュ
u
u
u
n
IHS高速応答キャッシュ
EdgeComponent CachingProxy
動的キャッシュの管理
u
キャッシュのモニタリング
当セッションのアジェンダです。
3
WAS6 動的キャッシング概要
まずWAS６動的キャッシュの概要についてご説明致します。
4
近年のWebシステムの課題
n
相反する課題への対応が求められる
ユーザー数の増大
レスポンス・タイム
n
ユーザー毎に
カスタマイズされた
動的コンテンツ
動的キャャッシュの利用
Ø
Ø
同じことは何度も聞かない！
再利用できる情報はキャッシュし、
より前段のコンポーネントで
レスポンスを返す
もはやWebアプリケーションは単なる情報提供の場ではなくなり、Webでのオンライン処理は当たり
前のように 行われるようになってきました。Webシステムの重要性は高まり、社会のインフラとしての
役割も果たしてきています 。このような中で、Webサイトを訪れるユーザー の数はますます 増大し、
高速回線の普及によりユーザーはよりシビアなレスポンス・タイムを要求するようになっています。
かってのような静的コンテンツ中心のサイトであれば、Webサーバーの前段にCaching Serverを配
置することにより、パフォーマンスを向上させることが見込めます。
しかし現在では、多くのユーザー を自らのサイトに繰り返し訪れて頂くために、個々のユーザー毎
にカスタマイズされたコンテンツを提供しているサイトが通常です。この場合、ユーザー毎にServlet
やJSPによって動的にページが生成されます。場合によっては後方に控えるバックエンド・システム
に処理が走ります。ですから、どうしてもApplication Serverの処理負荷が増え、Application
Serverが過負荷となりレスポンス・タイムを悪化させてしまうといった問題が発生しがちです。たとえ
ユーザー のためにコンテンツを工夫していたとしても、レスポンスが悪いサイトにはどうしてもユー
ザーは定着してくれません。
近年のWebアプリケーションは、このように増加するユーザー 環境の中で、パーソナライズされたコ
ンテンツとより快適なアプリケーションのレスポンスという相反する課題への対応が求められていま
す。このような 中で必要とされてきたのが動的コンテンツのキャッシュです。静的コンテンツと同様、
動的コンテンツであっても使いまわすことのできるコンテンツはできるだけ再利用 を行い、アプリ
ケーション・サーバーや後方のバックエンド・システムに対する負荷を減らそうという
発想です。
WebSphere Application Sever では V4以来、WebSphereの独自拡張機能としてこの動的コンテ
ンツをキャッシュする機能を提供しています。この動的キャッシュを利用して頂くことで、処理数の増
大とより快適なレスポンス・タイムという相反する課題に対応することが可能になります。
5
なにがキャッシュできるのか？
n
株価情報サイトの例
u
多くのユーザーに共通して使用される動的コンテンツ
l
生成されたページにある程度の時間有効期間がある
l
毎回Application Serverで生成する負荷を軽減することが 可能
JSP<include>タグを利用して、ページ自体をフラグメント化
l
u
静的コンテンツ
l
多くのユーザーに共通して使用される静的コンテンツ
l
画像ファイル、ヘッダーやフッター 、メニュー・リスト
株価情報.com
Top
aaa
bbb
ccc
ddd
12月1６日 日次リサーチ・
レポート
････････････････････････････････
l
l
l
l
内容が個人特有ではない
多くの人で使いまわせる
ある程度の有効期間がある
ページ毎キャッシュしても有効
サーブレット・JSPキャッシュ
････････････････････････････････
･･･････････････
･･･････････････
l
l
･･･････････････
画像ファイル
ヘッダー・フッター
静的コンテンツ・キャッシュ
・・・ ・
・
・ ･･･ ・
・
・
どういったものをWAS ではキャッシュできるのでしょうか ？株価情報サイトの例をもとに考えてみま
す。
まず通常の静的コンテンツがあります。
画像ファイルやヘッダー・フッター、ロゴといったコンテンツは多くのユーザーに共通して使用するこ
とのできるものですので、積極的 にキャッシュの対象とすることができます。
次に動的コンテンツで。キャッシュしてもキャッシュが使われなければ意味がありませんので、基本
的にキャッシングが有効なコンテンツとしては、複数のユーザー に対して共通して使用され、かつ
一定時間コンテンツの有効期間があるものになります。
たとえば、上の例では株価情報の日次レポート・ページです。このコンテンツは特定個人に向けた
ものではありませんので、キャッシュすることにより、多くのユーザーに対して共通して使いまわすこ
とができます。また日次レポートですので一定時間コンテンツ自体にも有効期間を見込むことがで
きます。日次レポートほど有効期間が長くなく、数分程度の有効期間であったとしても、その間に同
一コンテンツに対して複数のアクセスがあるのであれば、その分毎回アプリケーション・サーバーに
かかっていた負荷を軽減することができますので、キャッシュが有効であるといえます。
6
なにがキャッシュできるのか？
n
株価情報サイトの例（つづき）
u
個人用にカスタマイズされたページでもキャッシュの粒度を見直すこ
とでキャッシング可能
Ø
例えば、ポートフォリオ表示ページ
ü
リクエストがあるたびに、データベースへのアクセスが発生し、DBが過負荷に
株価情報.com
Top
aaa
bbb
ccc
ddd
l
l
個人用にカスタマイズされたページ
ページ毎キャッシュしても効果なし
l
個々の銘柄レベルで、データベース
への問い合わせ結果をキャッシュ
データベース・アクセス（負荷の高い
処理）の絶対数を減らせる
○○さん
銘柄
価格
前日比
XAB
7.29
+1.44%
YCC
4.83
-3.23%
ZDF
18.23
+1.32%
GHI
2.10
+2.3%
l
コマンド・キャッシュ
V6New
オブジェクト・キャッシュ
・・・ ・
・
・ ･･･ ・
・
・
では、次の例を考えてみましょう。
これは個々のユーザー が保持する株式のポートフォリオを表示するページです。このページを生成
するためにはその時点での株価の情報などを取得するためにデータ・ベースにアクセスする必要
があるとします。
このページは個々のユーザー向けに生成されていますので、JSPページ全体をキャッシュしてし
まってはあまり意味がありません。しかし、このページへのリクエストが発生する度にデータ・ベース・
アクセスが発生するのであれば、かなりの負荷がアプリケーション・サーバーおよび データ・ベース・
サーバーにかかってしまいます 。
このような ページ毎キャッシュはできないけれどもアプリケーション・サーバーに負荷がかかるような
処理に対しては、キャッシュの粒度を見直し、コマンド・キャッシュまたはV6の新機能 オブジェクト・
キャッシュを利用することで、キャッシュを有効に使用することができます。この例であればページを
生成する元となっている銘柄別のデータをキャッシュします。具体的 には銘柄単位にデータ・ベー
スへの問い合わせを行っていますので、データベースの問い合わせ結果を保管しているコマンド・
オブジェクト（または通常のJavaBeans）をキャッシュしておきます。これにより個々のユーザー のレ
スポンスには、もしキャッシュされたオブジェクトが利用できれば利用し、キャッシュになければデー
タベースのアクセスをした上でユーザー毎のコンテンツを生成します。データベースにアクセスした
場合には、問い合わせ結果はキャッシュとして保管し、次のリクエストに備えます。このようにして負
荷のかかるデータ・ベース・アクセスを減らしバックエンド・システムにかかる負荷を軽減すると共に、
アプリケーション・サーバーにかかる負荷を減らし、より早くクライアントにレスポンスを返すことが可
能になります。
7
サーブレット・
JSPキャッシュ
n
サーブレットやJSPの実行結果を保存
u
Webコンテナー上にキャッシュを保持
l
u
複数の箇所にキャッシュを配置可能（外部キャッシュ）
l
より前段のコンポーネントにキャッシュを配置することで効果大！
l
Edge Side IncludeキャッシュでWebサーバー Plug-in上にキャッシュ可能
IHS上へもキャッシュも可能
l
u
パラメータやCookie情報、パス情報などでキャッシュ・エントリー を区別
キャッシュの採用が比較的容易
l
管理コンソールおよびcachecspec.xmlでの設定で使用可能
l
キャッシュの無効化 をcachespec.xml のみで行う場合は、既存コンテンツに修正は
発生しない
キャッシュ・ヒットで
即レスポンス
AppServer
IHS
Cache
Cache
ESIキャッシュや外部キャッシュで
より前段に配置も可能
動的コンテンツ・キャッシュにおいて最も基本的なものがサーブレット・JSPキャッシュです。既に
WAS V4から導入されており、その名の通りサーブレットやJSPの実行結果を保存します。WASは
サーブレットのserviceメソッド（doGetやdoPostメソッド）への要求をインターセプトします。もし
キャッシュ内のコンテンツに対する要求であった場合にはキャッシュから即レスポンスを返します。も
しキャッシュが存在しなければ、実際にserviceメソッドを実行し、実行結果をキャッシュに入れます 。
サーブレットやJSPには、ページの生成などそれぞれの処理のキーとなるものがあります。ユー
ザー毎にコンテンツを生成している場合であればパラメータとして渡されるユーザー情報でしょうし、
日次レポートのページであれば日付が処理をわけるキーとなります。サーブレット・JSPキャッシュで
は同じサーブレットに対するリクエストであっても、指定したパラメータやCookie情報毎 に区別して
キャッシュを生成することができます。
またサーブレット・JSPキャッシュはWAS上だけでなく、WASの外部にもサーブレットやJSPの実行
結果をキャッシュとして配置することができます（外部キャッシュ）。外部キャッシュとしては
WebServer上のWebServer Plugin、Windows環境であればIHS上の高速キャッシュ・アクセラ
レータ上にキャッシュを配置することができます。より前段のコンポーネントでキャッシュから応答を
返すことにより、処理のホップの絶対数が減りますのでレスポンスも早くなりますし、バックエンド・シ
ステムにかかる負荷を軽減することにもなります。
サーブレット・JSPキャッシュは、基本的 には管理コンソールおよびcachespec.xmlでの設定で使
用可能です。キャッシュの無効化 をWebSphere Caching API（com.ibm.websphere.cache以下
のクラス）を利用したコーディングにより行うケースを除けば、アプリケーションへの変更作業は発生
しませんので、比較的容易に動的キャッシュを採用していただくことができます。
8
コマンド・キャッシュ
n
Commandオブジェクトのインスタンスをキャッシュ
u
デザイン・パターンの“Command Pattern”
l
u
様々な命令（Command）をオブジェクトとして表現することにより、要求（命令）の呼
出し元と要求自身 を疎結合 にし、Commandの再利用性 を高める”
WebSphere Command Frameworkに基づきアプリケーションを実装
l
l
Redbook “Design and Implement Servlets, JSPs and EJBs for WebSphere Application
Server”Chapter 4. WebSphere Command Framework
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg245754.html?Open
Invoker
<<interface>>
Command
+execute( )
呼出し元はコマンド・
オブジェクトのexecuteを
呼び出すのみ。
実装ロジックについては
知る必要がない。
<<interface>>
CacheableCommand
すべてCommand
の親インターフェース
CommandCacheの
ためのインターフェース
実際にはこの実装クラス
を継承すればよい
CacheableCommandImpl
＊説明のため簡略化されています
次にWAS5から導入されましたコマンド・キャッシュです。コマンド･キャッシュもその名の通りコマン
ド・オブジェクトの実行結果をキャッシュします。
コマンド・キャッシュのコマンドとは、広範に使われているデザイン・パターンの１つであるコマンド・
パターンの「コマンド」です。著名なGoF本(＊)におけるCommand Patternの定義は以下の通りで
す。
“ Encapsulate a request as an object, thereby letting you parameterize clients with different
requests, queue or log requests, and support undoable operations”
このパターンの核は、様々な命令（Command）をオブジェクトとして表現することにより、要求（命
令）の呼出し元と要求自身を疎結合 にし、Commandの再利用性を高めることにあります。
CommandはJavaBeansとして実装し、Setter/Getterで必要データのやりとりを行います。
Command（命令）実行の呼び出しはCommandのexecuteメソッドに統一されます。
このコマンド・パターンに基づいたフレームワークとして、WebSphere Command Frameworkとい
うAPIが提供されています 。このCommand Framework に基づいてアプリケーションを実装すること
により、コマンド・オブジェクトをキャッシュすることが 可能になります。
＊”Design Patterns : Elements of Reusable Object-Oriented Software” 1994
by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four).
オブジェクト指向ソフトウェア設計において遭遇する様々な問題に対する解法を23個のデザイン
パターンとしてカタログ化している。
9
コマンド・キャッシュ実装イメージ①
n
株価情報検索アプリケーション（現状の問題）
ü ビジネス・ロジックの変化が、サーブレット
IB M
・・・
…
…
…
…
…
…
にまで影響を与えやすい
株価情報検索
ü ビジネス・ロジックの実装方法は多様
検索条件を入力して下さい。
銘柄
株価
銘柄
・
・
IBM
・
$90.30
・
・
・
$53.25
XXX
(EJB,JDBC,etc)
⇒Servlet開発者がビジネスロジックの
実装について知っていることが必要・・・
。
開発時の役割分担も困難
実行
SearchPage.html
検索条件
EJB
SearchServlet
Business Logic
Data
Result.jsp
SELECT 文
発行
JDBC
IB M
・・・
…
…
…
…
…
…
株価検索結果
銘柄
株価
IBM
$90.30
XXX
$53.25
ü毎回EJB要求、DBアクセスが発生
⇒リソースの無駄遣い
DB
簡単な株価検索アプリケーションを例に、具体的にCommand Cacheの適用について考えてみま
す。このアプリケーションは典型的なMVCモデルで作られています。ViewはJSP・HTML、
ControllerはServlet、Model（ビジネス・ロジック）はEJB が担っています。
①ユーザーは株価情報検索ページで調べたい銘柄を入力し、それをパラメータとしてServletに渡
します。
②Servletではビジネス・ロジックを担うEJB をコールし、受け取ったパラメータをEJB に渡します。
③EJBはそのパラメータを元にデータベースへとSQL を発行します。
④EJBはデータベースの検索結果をJavaBeansにセットしてサーブレットへと返します。
⑤ServletはJavaBeans をリクエスト・オブジェクトにセットして、JSPにリクエストをForwardします。
⑥JSPは受け取ったJavaBeans を元に、クライアントに株価情報のページを出力します。
しかし、現状では以下のような問題点が挙げられます 。
・Servletで直接EJBの呼び出しなどを行っているため、ControllerとModelの結合度が高く、Model
の実装（ビジネス・ロジック）が変化した場合には、Servletにまで変更が必要になります。
・ControllerとModelの結合度が高いため、Servlet作成者 もビジネス・ロジックの実装に精通してい
る必要があります。
・株価情報検索ページにリクエストが発生する度に、データ・ベースへのアクセスが発生してしまい、
リソースを消費してしまいます。
10
コマンド・キャッシュ実装イメージ②
n
Command Pattern適用により・・・
IB M
・・・
…
…
…
…
…
…
株価情報検索
Ø Business Logicをカプセル化
検索条件を入力して下さい。
銘柄
株価
銘柄
・
・
IBM
・
$90.30
・
・
・
$53.25
XXX
実行
SearchPage.html
検索条件
SearchServlet
-Programのロジックを分離
-Business LogicをServletから隠蔽
Ø シンプルで統一された利用方法
Ø JavaBeansとして実装
Command
SearchCmd
EJB
Business Logic
Data
Result.jsp
JDBC
Ø HTTP要求の解析とcommandの実行。
IB M
・・・
…
…
…
…
…
…
株価検索結果
銘柄
株価
IBM
$90.30
XXX
$53.25
…
//リクエスト
・パラメータを処理
String _name = req.getParameter(“
name”
,name);
//Commandをインスタンス化
SearchCmdcmd = new SearchCmd( );
//必要なプロパティをSet
cmd.setName(_name);
//Commandを実行
cmd.execute();
…
DB
この例では、先ほどのアプリケーションにCommand Patternを適用しています。SearchServletとビ
ジネス・ロジック（EJB）の間にCommandを導入することにより、Business LogicとServlet を分離し
ています。WebSphere Command Framework では、CommandはJavaBeansとして実装すること
が推奨されています 。
Servlet側で必要な処理は、
・リクエスト・オブジェクトに含まれている必要な情報をCommandにSetする
・Commandオブジェクトのexecuteメソッドを実行する
です。これにより、Servlet作成者はビジネス・ロジックの実装について知らなくてもよくなりますし、
Servletはビジネス・ロジックの変更の影響を受けにくくなります。
11
コマンド・キャッシュ実装イメージ③
さらにCommandオブジェクトをキャッシュすると…
n
IB M
・・・
…
…
…
…
…
…
株価情報検索
検索条件を入力して下さい。
銘柄
株価
銘柄
・
・
IBM
・
$90.30
・
・
・
$53.25
XXX
Ø EJBメソッドの結果をCache
実行
SearchPage.html
検索条件
SearchServlet
-Cache Hitで即レスポンス
-Cache Missの時のみ、
EJB要求・DBアクセスが発生
⇒負荷軽減・リソースの有効活用
Command
SearchCmd
EJB
Business Logic
Data
Result.jsp
Cache
JDBC
IB M
・・・
…
…
…
…
…
…
株価検索結果
銘柄
株価
IBM
$90.30
XXX
$53.25
１．CommandCacheは、コマンドのexecute()
メソッドのコールをintercept。
２．キャッシュからコマンド・オブジェクトを返
せないか、チェック。
３．コマンド・オブジェクトがキャッシュにない
場合のみ、execute()のロジックを実行
DB
Command Pattern適用によりControllerとビジネス・ロジックの分離が可能になりましたが、さらに
Command PatternをWebSphere Command Frameworkに従って実装することにより、
Commandオブジェクトのキャッシュが可能になります。
Command Cacheを実装すると、WASはコマンドのexecute( )メソッドの呼び出しをインターセプト
します。そして、キャッシュからコマンド・オブジェクトが返せないか確認します。キャッシュから返す
ことができる場合は、キャッシュされているオブジェクトを用いて結果を返します。キャッシュからオブ
ジェクトを返せない場合にのみ、execute( )メソッドが実行されます。
これによりキャッシュが有効な間は、EJBメソッドへの要求やデータ・ベースへのアクセスといった処
理を減らすことができ、パフォーマンスの改善を期待することができます。
12
スループットおよびレスポンスタイムの改善
n
Trade3でのパフォーマンス・テスト結果
u
（ページ/秒）
株式トレーディング・サイトのサンプル・アプリケーション
（ミリ秒）
214.83
200.19
200
200
179.73
143.26
150
113.89
100
100
94.76
75.65
50
59.42
51.43
53.62
0
レスポンス・タイム
スループット
150
50
0
None
Servlet Caching
Servlet & ESI Caching
Command Cacing
Servlet & Command
Caching
動的キャッシュを利用することによって、どのくらいサイトのパフォーマンスが改善するかを示したグ
ラフです。このデータはWebSphereパフォーマンス・チームによって発表された論文に基づいてお
り、論文はWeb上にも公開され読むことが可能です。（＊）。
Trade3 という
WebSphereのパフォーマンス・アプリケーション を利用したテスト結果ですが、サー
ブレット・キャッシングを採用することにより、約２．２倍のスループット向上が見られます。さらに外部
キャッシュとしてESIキャッシングを併用することにより、動的キャッシュなしと比して２．８倍のスルー
プットを記録しています。またアプリケーション にコマンド・キャッシュを使用した場合には、動的
キャッシュなしと比して約３．５倍のスループット、さらにサーブレット・キャッシュとコマンド・キャッシュ
を併用することにより最大４倍近くスループットが改善しています。
＊IBM System Journal Volume 43, Number 2, 2004
“WebSphere DynamicCache: Improving J2EE application performance”（R. Bakalova, A.
Chow, C. Fricano, P. Jain, N. Kodali, D. Poirier, S. Sankaran, and D. Shupp ）
http://www.research.ibm.com/journal/sj/432/bakalova.html
13
(参考）Trade3/Trade6
n
WebSphere ベンチマーク・アプリケーション
u
u
u
WebSphereのパフォーマンス・テスト用アプリケーションの役割
動的キャッシングのサンプル・
アプリケーションの役割
IBM developerWorksから入手可能
l
u
http://www-128.ibm.com/developerworks/websphere/library/samples/AppServer.html
Trade3/3.1
l
l
l
WAS V5.0/5.1対応
J2EE1.3対応
動的キャッシュ
Ø
Ø
u
サーブレット・キャッシュ
コマンド・キャッシュ
Trade6
l
l
l
WAS V6.0対応
J2EE1.4対応
動的キャッシュ
Ø
Ø
サーブレット・キャッシュ
オブジェクト・キャッシュ
前のページのパフォーマンス・テストに用いられたアプリケーションはWebSphereのベンチマーク
用アプリケーションであるTradeです。
このアプリケーションは動的キャッシングのサンプル・アプリケーションとしての役割ももっており、動
的キャッシングに対応したアプリケーション を開発する際には参考にして頂けます。このサンプル・
アプリケーションは以下のdeveloperWorksのサイトから入手可能です。
http://www-128.ibm.com/developerworks/websphere/library/samples/AppServer.html
<Trade3>
Trade3 is the third generation of the WebSphere end-to-end benchmark and performance sample
application. This provides a real world workload driving WebSphere's implementation of J2EE 1.3 and
Web Services including key WebSphere performance components and features.Trade3's new design
spans J2EE 1.3 including the new EJB 2.0 component architecture, Message Driven beans,
transactions (1-phase, 2-phase commit) and Web Services (SOAP, WSDL, UDDI). Trade3 also
highlights key WebSphere performance components such as DynaCache, WebSphere Edge Server
and Web Services with AXIS.
<Trade6>
Trade6 Release for WAS 6.0. Updates in this package include converting the entire package over to
J2EE 1.4. This includes moving to Servlet 2.4, JSP 2.0, JSR 101/109 1.1, EJB 2.1, JMS 1.1, App
client 1.4.
14
オブジェクト・キャッシュ
n
V6New
Distributed Java Object Cache
u
u
Javaオブジェクトのインスタンスを保管・共有する
l
キャッシュ・エントリーはオブジェクト・キャッシュ・インスタンス内に保管
l
DistributedMapインターフェースを使用してキャッシュ・インスタンスにアクセス
プログラマティックにJavaオブジェクトをキャッシュ可能
l
l
同一複製ドメインに所属しているAppServer間でオブジェクトを共有可能
ビジネス・ロジックの実行結果など生成負荷 の高いオブジェクトをキャッシュ
import javax.naming.InitialContext;
import com.ibm.websphere.cache.DistributedMap;
・・・
public ResultBean getResutlBean( String arg1){
・
・
・
InitialContext ic = new InitialContext( );
DistributedMap dMap1 =
(DistributedMap)ic.lookup(“services/cache/instance1”);
・
・
・
ResultBean res=null;
//まずキャッシュを確認
res = dMap1.get(arg1);
//キャッシュがなかった場合はビジネスロジックを実行
ｉ
f(res ==null ){
res = doSomeHighCostBackendProcessing(arg1);
//キャッシュに保管
dMap1.put( arg1, res);
}
return res;
}
CacheInstance1
dMap1.get(“bbb”);
dMap1.put(“aaa”,aaaObj);
AppServer1
AppServer2
次にご紹介するのがオブジェクト・キャッシュです。WAS６の新機能であるこのキャッシュは名前の
通りJavaオブジェクトをキャッシュします。
オブジェクト・キャッシュはサーブレット・キャッシュやコマンド・キャッシュと異なり、WASが特定のメ
ソッドをインターセプトするのではなく、ユーザーがアプリケーション・ロジックの中でキャッシュを利
用するようにロジックを書いて利用します。
まずキャッシュを保管する領域であるキャッシュ・インスタンスをJNDI名によりルックアップします。そ
してルック･アップしてきたキャッシュ・インスタンスに対し
com.ibm.websphere.cache.DistributedMapインターフェースを使用してキャッシュ・エントリーの
保管および取出しを行います。このDistributedMapインターフェースはjava.util.Mapインター
フェースを拡張していますので、使い方が非常に分かりやすいものになっています。
同一キャッシュ・インスタンスへと保管したオブジェクトは、同一複製ドメインに所属するAppServer
間では複製することが 可能ですので、アプリケーション・サーバー間で同一のオブジェクトを共有す
ることが可能です。
このオブジェクト・キャッシュもさきほどのコマンド・キャッシュと同様、データベースへの問い合わせ
結果など生成負荷の高いオブジェクトをキャッシュすることでパフォーマンスを改善することができま
す。
15
オブジェクト・キャッシングの実装
n
com.ibm.websphere.cache.DistributedMapインターフェース
u
キャッシュ・エントリーの保管
l
void put(“someCacheKey”,someObject)
l
void put(“someCacheKey”, someObject, timeToLive, sharingPolicy, dendencyIDs)
Ø
Ø
Ø
u
キャッシュ・エントリーの取得
l
u
timeToLive：キャッシュの有効期間を秒数で指定（int)
sharingPolicy ：共有ポリシーを指定 (int)
ü EntryInfo.NOT_SHARED、EntryInfo.SHARED_PUSH、
またはEntryInfo.SHARED_PUSH_PULL
dependencyIDs ：キャッシュ・エントリーに紐付けられたキャッシュ・エントリー
(java.lang.Object[ ])
java.lang.Object get(“someCacheKey”)
キャッシュ・エントリーの無効化
l
void invalidate(“someCacheKey”)
オブジェクト・キャッシュに使用するDistributedMapインターフェース内に定義されている主なメソッ
ドです。
キャッシュに保管する際にはDistributedMapインターフェースのputメソッドを用いて、特定のキーと
紐付けてキャッシュを保管します。この際キャッシュの有効期限やキャッシュの共有ポリシーなどを
明示的に指定してキャッシュすることも可能です。
キャッシュを取り出す際には、キャッシュを保管した際に指定したキーを引数にgetメソッドを利用し
ます。
キャッシュを明示的 に無効化する際には、同様にキャッシュを保管した際に指定したキーを引数に
指定してinvalidateメソッドを指定します。
詳細については 製品に付属するjavadocのcom.ibm.websphere.cacheパッケージをご確認下さ
い。
16
どこでキャッシュするか？
n
n
キャッシュの対象により、「どこ」が決まる
複数キャッシュできる場所がある場合
u
基本的には、クライアントに近いほど有効
l
l
u
応答時間の短縮
バックエンドのシステムへの負荷の軽減
セキュリティの観点
l
Non-Secureなデータはできるだけクライアントの近くで
l
ユーザー固有情報・機密情報 などSecureなデータは、Firewallの後で
LoadBalancer
Tier
Web Server Tier
Presentation Tier
Business Logic Tier
Load
Balancer
IHS/
Plug-in
Web
Container
EJB
Container
Servlet Cache
(外部キャッシュ）
IHSの
FRCA
Plug-in
ESI Cache
Servlet Cache
Object Cache
Object Cache
Command Cache
Command Cache
ここまで「なにを」キャッシュするのかの話をしてきました。次に検討すべき項目は「どこで」キャッシュ
をするのかです。
基本的に「どこで」キャッシュするのかは、「なにを」キャッシュするのか、つまりキャッシュの対象に依
存します。
コマンド・キャッシュやオブジェクト・キャッシュはApplication Server上にキャッシュすることになりま
すが、サーブレット・キャッシュは外部キャッシュを含め複数のTierにキャッシュを配置することがで
きます。
基本的にはクライアントからより近いところでキャッシュが返される方が、レスポンスの処理にかかる
ホップも少なくなるため応答時間がよくなりますし、後方のシステムへの要求数を削減するという
意
味でもより効果が高くなります。
もう一つの観点としてセキュリティを考える必要があります。個人情報など機密情報の入ったコンテ
ンツをキャッシュの対象とする場合には、DMZに配置されるコンポーネント（Webサーバー）に
キャッシュをおくことは 好ましくありません。SecureなコンテンツやデータはFirewallの背後の
Secureなゾーン内にキャッシュするべきです。
17
いつキャッシュを無効化するか？
n
「CacheとOriginalが同一である」ことが大原則
u
オリジナルのコンテンツやその元となるデータに変更があった場合
は、キャッシュを無効化できなくてはいけない
?
古い!?
AppServer
データの更新
Cache
u
WAS６動的キャッシュでサポートされる無効化方法
l
l
l
l
時間ベース
グループ・ベース（dependency-id)
ルール・ベース（LRUルール）
Javaコーディング
Ø
com.ibm.websphere.cache.DistributedMapインターフェース
これまで「なにを」「どこで」キャッシュするかを見てきましたが、キャッシュを使用する際に考えなくて
はいけないポイントがもう１つあります。
「いつ」無効化するかです。
たとえキャッシュを用いてパフォーマンスが向上しても、クライアントに返されるコンテンツが古いも
のであっては意味がありません。キャッシュを用いる際には、かならず「キャッシュとオリジナルのコ
ンテンツが同一である」ことが保障されている必要があります。特に動的キャッシュが扱うコンテン
ツ・データはそもそも動的に変化するものですので、キャッシュの無効化 には細心の注意をはかる
必要があります。
WAS５の動的キャッシュでは以下の4つのinvalidate（無効化）方法をサポートしています。
・時間ベース（キャッシュが作成されてから過ぎた秒数による無効化）
・グループ・ベース（作成されたキャッシュをグループ化し、グループ単位での無効化）
・キャッシュが溢れた際のLeast Recently Usedルールによる無効化
・com.ibm.websphere.cache.DistributedMapインターフェースに定義されたメソッドを呼び出す
ことによる無効化
18
動的キャッシュの基本機能
ここからは動的キャッシュの基本的な機能についてご説明致します。
19
キャッシュ・インスタンス
n
キャッシュを保持する領域
u
キャッシュ・インスタンス間は互いに影響を与えない
l
u
キャッシュ・インスタンス毎にJNDI名、キャッシュ・サイズ 、優先順位 、ディスク･ オ
フロードの設定が可能
AppServer間でキャッシュを共用することが可能
l
AppServerが同一複製ドメインに所属していることが 条件
複製ドメイン
CLUSTER1
CacheInstance1
AppServer1
AppServer2
AppServer3
CacheInstance2
まずキャッシュを保持する領域をキャッシュ・インスタンスと呼びます 。データベースを利用する際に
JDBCプロバイダーを定義するように、動的キャッシュを利用する際には管理コンソールからキャッ
シュ・インスタンスをリソースとして定義します。
このキャッシュ・インスタンスは複数定義することが可能であり、キャッシュ・インスタンス毎にJNDI名
を設定します。キャッシュ・インスタンス毎にキャッシュ・サイズやキャッシュ・エントリー の優先順位、
ディスク･オフロードの有無などを指定することができますので、アプリケーションごとにキャッシュの
運用を分けることも可能です。また複数定義されたキャッシュ・インスタンスは互いに影響を与えま
せんので、同じキー値で別のオブジェクトを複数のキャッシュ・インスタンスにキャッシュすることも可
能です。
同じキャッシュ・インスタンス内ではキャッシュの複製が可能ですので、アプリケーション・サーバー
間でキャッシュ・エントリー を共用することが 可能です。ただし、キャッシュを共用するアプリケーショ
ン・サーバーは同一の複製ドメインに所属している必要があります。
20
キャッシュ・インスタンスの種類
n
２種類のキャッシュ・インスタンス
u サーブレット・
キャッシュ・インスタンス
l
サーブレット・キャッシュ、コマンド・キャッシュのキャッシュ・エントリーを保持する
Ø
Ø
cachespec.xmlファイル内の<cache-instance> エレメントでインスタンスを指定
<cache-instance>を明示的に指定しない場合は、デフォルトのキャッシュ・インスタンス
「services/cache/basecache」にキャッシュされる
u オブジェクト・
キャッシュ・インスタンス
l
オブジェクト・キャッシュのキャッシュ・エントリーを保持する
Ø
Ø
Ø
com.ibm.websphere.cache.DistributedMapインターフェースまたはcom.ibm.websphere.
cache.DistributedObjectCacheを介してキャッシュ・インスタンスにアクセス
動的キャッシュを有効にすると「services/cache/distributedmap」
というJNDI名でデフォ
ルト・インスタンスが作成される
アプリケーション ・コード内で、キャッシュインスタンスをJNDI名によりルック･アップ
キャッシュ・インスタンスには2種類あります。
1つ目はサーブレット・キャッシュやコマンド・キャッシュのキャッシュ・エントリー を保持する「サーブ
レット・キャッシュ・インスタンス」です。サーブレット・キャッシュ・インスタンスを指定するには、動的
キャッシュの構成ファイルcachespec.xmlの中の<cache-instance>タグで指定します。特に明示的
にキャッシュ・インスタンスを指定しなかった場合（つまり<cache-instance> タグの外でキャッシュの
指定が行われた場合）は、デフォルトで用意されているキャッシュ・インスタンス（JNDI名
services/cache/basecache)が使用されます。
2つ目はオブジェクト・キャッシュのキャッシュ・エントリー を保持する「オブジェクト・キャッシュ・インス
タンス」です。こちらはアプリケーション内で、JNDI名によりキャッシュ・インスタンスをルックアップす
ることにより使用します。先にご説明したようにキャッシュ・インスタンスにアクセスするには、
com.ibm.websphere.cache.DistributedMapインターフェースおよびその実装クラスである
com.ibm.websphere.cache.DistributedObjectCacheクラスを利用します。
21
キャッシュ・インスタンスの構成
n
管理コンソールから設定可能
u
「リソース」→「キャッシュ・インスタンス」
u
定義レベルに注意
l
l
セル、クラスター、ノード、サーバーのレベルで設定可能
インスタンス名、JNDI名、キャッシュ・サイズ等を設定
キャッシュ・インスタンスを構成するには、管理コンソールから「リソース」→「キャッシュ・インスタンス」
とたどります。
採用する動的キャッシュにあわせて必要なキャッシュ・インスタンスを作成します。この際、データ・
ソースを定義する場合などと同様キャッシュ・インスタンスを作成するレベルにご注意下さい。キャッ
シュ・インスタンスはセル・ノード・クラスター・サーバーの各レベルで作成することができますが、ここ
で設定したレベルによりキャッシュ・インスタンスのJNDI名が名前解決されるか否かが異なってきま
す。
キャッシュ・インスタンスの設定画面では、キャッシュ・インスタンスの管理用の名前、およびアプリ
ケーションからルックアップする際に使用するJNDI名、最大キャッシュ・サイズなどを指定します。そ
の他、ディスク・オフロード（後述）の有無などもあわせて設定して下さい。
22
キャッシュの複製
n
連携AppServer間でキャッシュ・エントリーを共有
u
キャッシュのヒット率を向上させ、動的キャッシュがより効果的に
u
各AppServerが同一の内部複製ドメインに所属することが前提
l
n
内部複製ドメインは動的キャッシュ専用に用意することを推奨
キャッシュ複製タイプ
タイプ
AppServer間
での連携
Memoryの
利用効率
動 作
共有しない
×
−
Cacheが作成されたAppServerでのみCacheを用いる
特定ユーザーが複数回使用するキャッシュに使用
デフォルト
値
pushのみ
○
△
キャッシュのエントリーが作成されると、他のAppServerのキャッシュにエ
ントリーとキャッシュIDを自動的に配布。常に各サーバー上にキャッシュ
のコピーが作成される。対障害性は高いが、全てのサーバーにキャッ
シュが配置されているのでリソースを浪費しやすい。
多くのユーザーに使われ、かつヒット率も高いキャッシュに使用
pushとpull
の両方
○
○
キャッシュが作成されるとキャッシュID のみを他の連携AppServerにブ
ロードキャストを行う。これにより、AppServerは特定のキャッシュID に
対するエントリーをあらかじめどのAppServerに取りにいけばよいか、ま
たは自分で実際に処理を行うべきかを判断できる。これにより必要なと
きにのみキャッシュ複製を各サーバーに配置することが可能になる
多くのユーザーで使いまわせるけれども、それほどヒット率が高くない
キャッシュに使用
同一のキャッシュ・インスタンスを利用するアプリケーション・サーバー間でキャッシュを共有すること
ができます。キャッシュ・エントリー を複数のアプリケーション間で共有することによりキャッシュのヒッ
ト率を向上させ、動的キャッシュがより効果的に機能するようになります。キャッシュの共有には。
セッション・オブジェクトのレプリケーションと同様、データ・レプリケーション・サービス（DRS）が用い
られています 。このためキャッシュを共有するアプリケーション・サーバーは同一の複製ドメインに存
在する必要があります。なお、動的キャッシュの複製に使用する複製ドメインとセッション・オブジェ
クトの複製に使用する複製ドメインは分けていただくことをお勧めいたします 。これはセッションの複
製と動的キャッシュの複製では、そもそも作成すべき複製の数が異なるからです。（セッション・オブ
ジェクトはオリジナル以外にどれか１つのアプリケーション・サーバー上に複製が１つだけ存在すれ
ばいいのに対し、動的キャッシュは全てのアプリケーション・サーバー上に複製（またはそのID）を
配置する必要があるからです）。
キャッシュの複製タイプとしては、上記の３つを指定することが可能です。デフォルトのキャッシュ複
製タイプは複製ドメインの設定で指定します。個々のキャッシュ・エントリーの使用され方にあわせ
て適切なキャッシュ複製タイプをcachespec.xmlで上書きすることができます。
23
キャッシュの複製の設定
n
複製ドメインの作成
u
n
管理コンソールから作成可能
l
「環境」⇒「複製ドメイン」⇒「新規作成」
l
レプリカの数は「ドメイン全体」を指定
キャッシュ複製タイプの設定
u
管理コンソール
l
「動的キャッシュ・サービス」または
「キャッシュ・インスタンス」から設定
l
整合性設定として指定
push頻度
l
Ø
新規作成（修正）された
キャッシュ・エントリーを
pushする前に待機する秒数を指定
複製ドメインの作成は管理コンソールから行うことができます。「環境」⇒「複製ドメイン」⇒「新規作
成」とたどり任意の複製ドメイン名を指定してください。この際レプリカの数には「ドメイン全体」を指
定します。
次にキャッシュ複製タイプの設定ですが、これはアプリケーション・サーバー単位に動的キャッシュ・
サービスの設定項目の１つとして設定することもできますし、キャッシュ・インスタンス毎に設定を行う
ことも可能です。キャッシュの複製を有効にするには「キャッシュ複製を使用可能にする」のチェッ
ク・ボックスにチェックを入れ、作成した複製ドメインとデフォルトの複製タイプを指定してください。
24
キャッシュのディスク・オフロード
n
ディスク・オフロード
u
u
最大キャッシュ・
サイズを超えたキャッシュはLRU（Least Recently Used)ルー
ルに従いメモリから削除される
ディスク・オフロードを設定した場合、メモリから削除されるキャッシュをディス
クに保管しておくことが可能
l
オフロード位置
Ø
同一ノードに複数AppServerが存在する場合には、ディスク・オフロード位置はそれぞれ
別のロケーションを指定する
明示的に指定しない場合
Ø
明示的に指定した場合 (例 <WAS_ROOT>¥diskoffloadを指定）
Ø
ü
ü
l
<WAS_ROOT> ¥temp¥node ¥<serever_name>¥_dynacache¥<cacheJNDIName>
<WAS_ROOT> ¥diskoffload¥node ¥<server_name> ¥<cacheJNDIName>
ディスクへのフラッシュ
Ø
サーバーを停止する際に、メモリ上のキャッシュを全てディスクに書込むか否かを指定
キャッシュ・インスタンス毎に最大キャッシュ・サイズが指定可能です（デフォルト２０００エントリー）。
この最大キャッシュ・サイズを超えたキャッシュはLRUルールによりメモリー上から削除されます。通
常そのキャッシュ・エントリー はメモリー から削除された時点で消えてしまいますが、ディスク・オフ
ロードを有効に設定しておくことで、メモリーから削除されたキャッシュをディスクに退避させておくこ
とが可能です。ディスクに退避されたキャッシュ・エントリーに対するアクセスがあった場合には、そ
のキャッシュ・エントリー が再びメモリー上にロードされ、別のキャッシュ・エントリーがLRUルールに
よりディスクへと退避されます。
オプショナルな設定として、オフロード位置の指定とディスクへのフラッシュの有無があります。
オフロードの位置とは、ディスク上のどこにキャッシュ・エントリー を保管するかの設定になります。同
一ノードに複数アプリケーション・サーバーが存在し、それぞれ別ユーザー で起動されているような
場合にはディスク・オフロード位置はそれぞれ 別のロケーション を明示的 に指定してください。
キャッシュをオフロードしようとした際にアクセス権限の問題が発生することを防ぐためです。
次にディスクへのフラッシュです。これはサーバーを停止する際に、メモリー上のキャッシュを全て
ディスクに書き込むか否かを指定します。短期間のメンテナンスで復旧する場合などには有効です。
25
動的キャッシュの基本設定
ここからは動的キャッシュの基本的な構成方法についてご説明致します。
26
動的キャッシュ構成手順
n
サーブレット・キャッシュ
1.
2.
3.
4.
n
コマンド・キャッシュ
1.
2.
3.
4.
n
（オプション）キャッシュ・インスタンスの作成
動的キャッシュ・
サービスを有効にする
cachespec.xmlでキャッシュ内容を定義する
(オプション）無効化ロジックのアプリケーションへの作りこみ
WebSphere Commad Frameworkに基づいたアプリケーションの開発
（オプション）キャッシュ・インスタンスの作成
動的キャッシュ・
サービスを有効にする
cachespec.xmlでキャッシュ内容を定義する
オブジェクト・キャッシュ
1.
2.
3.
DistributedMapインターフェースを用いたアプリケーションの開発
（オプション）キャッシュ・インスタンスの作成
動的キャッシュ・
サービスを有効にする
採用する動的キャッシュによって、必要となる構成手順を上にまとめました。いずれの構成において
も動的キャッシュ・サービスの有効化は必須の作業です。デフォルトのキャッシュ・インスタンス以外
にキャッシュ・インスタンスが必要な場合は、キャッシュ・インスタンスの作成を行ってください。
アプリケーションへの作りこみが必須であるのは、コマンド・キャッシュおよび オブジェクト・キャッシュ
です。サーブレット・キャッシュおよびコマンド・キャッシュはキャッシュ構成ファイル
（cachespec.xml）でキャッシュ・ポリシー（キャッシュ対象とキャッシュの有効期間時間や優先度な
ど）の定義が必要です。
27
動的キャッシュ・サービスの有効化
n
管理コンソールから動的キャッシングを使用可能に
u
「サーバー」⇒「アプリケーション ・サーバー」⇒<サーバー名>⇒「コンテナー設定」
u
「サーバー始動時にサービスを使用可能 にする」にチェックを入れる
全ての動的キャッシュの設定で必要となる動的キャッシュ・サービスの有効化作業です。
管理コンソール「サーバー」⇒「アプリケーション・サーバー」⇒＜サーバー名＞⇒「コンテナー設
定」とたどり、「動的キャッシュ・サービス」の設定ページを開きます。「動的キャッシュ・サービス」設
定ページの「サーバー始動時にサービスを使用可能にする」のチェックボックスにチェックが入って
いることを確認します。
28
サーブレット/コマンド・キャッシングの設定
n
キャッシュ・ポリシーの作成
u
cachespec.xmlでキャッシュ方針を指定
l
なにをキャッシュするか
l
なにを元にキャッシュ・エントリー を生成するか
l
いつ無効化するか
ü
ü
ü
u
パラメータ、アトリビュート、パス、セッション情報、ヘッダー情報、ロケール、Cookie情報
時間ベース、グループ・
ベース（dependency-id)、ルール・
ベース（LRUルール）
Javaコーディング（
com.ibm.websphere.cache.Cacheインターフェース）
Dynamic Cache Policy Editorを使用して編集可能
l
u
どのサーブレット？どのコマンド？
alphaWorksでEclipse Pluginとして提供
cachesepc.xmlの配置
l
モジュール・レベルでの設定
Ø
Ø
WebモジュールのWEB-INFディレクトリ
EJBモジュールのMETS-INFディレクトリ
l
グローバル・レベルでの設定
l
メンテナンスを考慮し、モジュールレベルでの設定を推奨
Ø
<WAS_ROOT>¥propertiesディレクトリ
サーブレット・キャッシュおよび コマンド・キャッシュの場合は、キャッシュ・ポリシーを構成ファイル
cachespec.xmlで定義します。cachespec.xmlで指定すべき情報はどのサーブレット・コマンドを
キャッシュするか、どんな情報をもとにキャッシュを区別してキャッシュしていくか、キャッシュの無効
化をどのようにして行うかです。
cachespec.xmlの編集は、<WAS_ROOT>¥propertiesディレクトリーにある
cachespec.sample.xmlを元に手動で行って頂くことができます。動的キャッシュの対象が多い場
合には、手動での編集は煩雑になりますので、alphaWorksで提供されているDynamic Cache
Policy Editorを利用して頂くことが可能です。
2005年4月の現段階ではV5.x対応のものしか出ていませんが、V6でもRational Applicatoin
Developer および Application Assembly Tool対応のものが提供される予定です。V5.x対応の
Dynamic Cache Policy Editor は以下のサイトから入手可能です。
http://www.alphaworks.ibm.com/tech/cachepolicyeditor
cachespec.xmlの配置箇所としては、アプリケーション・モジュール内に同梱する方法と、
<WAS_ROOT>¥propertiesディレクトリに配置する方法の２つの方法があります。アプリケーション
に修正が入った場合は、当然cachespec.xmlにも変更が入ると思いますので、メンテナンス性を考
慮してモジュール・レベルに配置することを推奨いたします。
29
cachespec.xmlの記述①
n
cache
u
n
cache-instance
u
n
cacheエレメント内には<cache-instance>、<cache-entry>が含まれる
name属性として管理コンソールで設定したキャッシュ・インスタンスのJNDI名を指定
cache-entry
u
u
個々のキャッシュ対象の情報を指定するエントリー
cache内のcache-entryはデフォルト・キャッシュインスタンスに、cache-instance内の
cache-entryは指定のキャッシュ・インスタンスにキャッシュされる
<cache>
<cache-entry>
個々のキャッシュ対象を指定
<class>servlet</class><name>/myServlet1</name>
<cache-id>
<component id="*" type="parameter"><required>true</required></component><timeout>180</timeout>
</cache-id>
</cache-entry>
<cache-instance name="services/cache/Instance1">
キャッシュインスタンスの指定
<cache-entry>
個々のキャッシュ対象を指定
<class>servlet</class><name>/myServlet2</name>
<cache-id>
<component id="*" type="parameter"><required>false</required></component><timeout>180</timeout>
</cache-id>
</cache-entry>
</cache-instance>
</cache>
ここからはcachespec.xmlの記述方法についてご説明致します。詳細な内容はInfocenterでご確
認ださい。
まずcachespec.xmlのルートとしてあるのが<cache> タグです。その下には<cache-instance> タグ
または<cache-entry>タグがきます。
<cache-instance>タグは、明示的 にキャッシュ・インスタンスを指定したい場合に利用します。特に
明示的にキャッシュ・インスタンスを指定せず<cache-instance> タグ外に配置された<cacheentry>は、デフォルトのキャッシュ・インスタンスにキャッシュされます。
<cache-entry>タグは個々のキャッシュ対象を指定するエントリー です。このタグ内にキャッシュ・エ
ントリーの名前やキャッシュの生成規則などを記述していきます。
30
cachespec.xmlの記述②
n
class
u
キャッシュ対象のタイプを指定
Ø
n
<class> servlet | command | static </class>
name
u
どのコンテンツをキャッシュするか指定
u
サーブレット・JSPキャッシュ、静的コンテンツの場合
l
l
Webモジュール内 ：コンテキストルートからの相対パスで指定
Ø <name> myApplication/Sample.jsp </name>
Ø <name> myApplication/image/logo.gif </name>
<WAS_ROOT> ¥ properties ：フル・パスで指定
Ø
u
<name> / myApplication/control/searchServlet </name>
コマンド・キャッシュの場合
l
キャッシュ対象オブジェクトのフル・クラス名（拡張子.classも付加して指定）
Ø
<name> com.ise.sample.command.UpdateCmd.class </name>
このページ以降は<cache-entry>タグ内に記述する内容の説明です。
まず<class>タグにはキャッシュ対象のタイプを指定します。サーブレット・JSPキャッシュであれ
ば”servlet”、コマンド・キャッシュであれば”command”、静的コンテンツであれば”static”と指定しま
す。
次に<name>タグです。このタグ内にどのサーブレット・どのコマンドをキャッシュするかを指定しま
す。サーブレット・JSPキャッシュの場合はcachespec.xmlの配置箇所により記述方法が変わります
のでご注意下さい。コマンド・キャッシュの場合はキャッシュ対象のコマンド・オブジェクトのフル・クラ
ス名を指定します。拡張子.classも付加して設定する点にご注意下さい。
31
cachespec.xmlの記述③
n
sharing-policy
u
n
複数AppServer間でのキャッシュの共有方法を指定（
エントリー毎に設定）
ポリ
シー
AppServer間
での連携
Memoryの
利用効率
動 作
notshared
×
−
Cacheが作成されたAppServerでのみCacheを用いる
特定ユーザーが複数回使用するキャッシュに使用
デフォルト
値
sharedpush
○
△
キャッシュのエントリーが作成されると、他のAppServerのキャッシュ
にエントリーを自動的に配布。各キャッシュにコピーが作成される
多くのユーザーに使われ、かつヒット率も高いキャッシュに使用
shared
pushpull
○
○
作成したエントリーのキャッシュID を他の連携AppServerにブロード
キャスト。これによりAppServerは特定のキャッシュID に対するエン
トリーがあらかじめどこに存在するかを判断できる
多くのユーザーに使われるけれども、それほどヒット率が高くない
キャッシュに使用
property
u
キャッシュの詳細機能の挙動を指定
u
EdgeCacheable
ExternalCache
persist-to-disk
u
u
：EdgeSideIncludeキャッシュ可能か否かを指定
：外部キャッシュ先を指定
：キャッシュをディスクに書き込み可能か否かを指定
<sharing-policy>タグでは、複数のアプリケーション・サーバー間でキャッシュを共用する際の
キャッシュ・エントリーの複製方針を定義します。sharing-policyによりリソースの使用状況に影響を
与えますので、各エントリー 毎に最適なものを選択するようにします。
<property>タグでは、外部キャッシュ可能であるか否か、ディスク・オフロード可能であるか否かな
ど動的キャッシュのオプションの動きを指定します。
32
cachespec.xmlの記述④
n
cacheid
u
WASがキャッシュに入れたエントリーの判別に用いるID
l
l
l
u
複数のCacheIDの生成規則を定義可能
Cachespec.xml内に指定した情報を基にルールベースで作成する
com.ibm.websphere.servlet.cache.IdGeneratorクラスを実装したクラスを用いて、Javaコーディ
ングによりキャッシュIDを生成することも可能
cacheidのサブ・
エレメント
l
component
Ø
Ø
Ø
キャッシュIDの生成に使用される情報を指定
サーブレット：parameter、cookie、session、header、locale、requestTypeなど
コマンド：method、field
l
timeout
l
inactivity
l
priority
Ø
Ø
Ø
l
キャッシュ・エントリーの生存時間の絶対時間を指定
キャッシュ・エントリーの生存時間をラスト・アクセス時間を元に指定
Cacheが指定した最大キャッシュ・サイズに達した際に、LRUルールに基づいて、エント
リーをメモリから除去、またはディスク・オフロードを行う。その際に用いられる優先順位
idgenerator
Ø
com.ibm.websphere.servlet.cache.IdGeneratorクラスを実装したクラスを用いて、jコー
ディングによりキャッシュIDの生成を行う際に指定します。
<cache-id>タグにはWASがキャッシュに入れたエントリー の判別に用いるIDを生成する方法を指
定します。キャッシュ・エントリー ごとに複数のCacheIDの生成規則を指定でき、有効なCacheIDが
生成されるか、実行する規則がなくなるまでCacheIDの生成を実行します（有効なCacheIDが生成
できなかった場合はCacheされません）
<cache-id>のサブ・エレメントは以下のようになっています。
−component：キャッシュIDの生成に使用される情報を指定します。サーブレット・キャッシュの場
合、parameter、cookie、session、header、locale、requestTypeを指定可能です。コマンド・
キャッシュの場合methodまたはfieldのいずれかになります。
-timeout：キャッシュのエントリー が存続できる時間（秒）を指定します。
−priority：キャッシュが指定した最大キャッシュ・サイズに達した際にLRU（Least Recentely
Used)ルールに基づいて、エントリー のメモリーからの除去またはディスク・オフロードが行われます 。
その際の判定ロジックに用いられます。
−idgenerator：com.ibm.websphere.servlet.cache.IdGenerator インターフェースを実装したカス
タム・クラスを用いて、独自ロジックによるキャッシュIDの生成を行う際に指定します。
33
cachespec.xmlの記述⑤
n
dependency-id
u
u
キャッシュをグループ化する際に指定
dependency-id基本ストリングとcomponentエレメントの値により生成される
<dependency-id> CompanyCache
<component id= “
company”type=“parameter”><required>true</required></component>
</dependency-id>
n
invalidation-id
u
u
cacheidやdependency-idと同様の指定方法
invalidation-idに指定されたcacheidまたは dependency-idが一致したキャッシュは無効
化される
<invalidation>ComapnyCache
<component id= “
company”type=“parameter”><required>true</required></component>
</invalidation>
<dependency-id>タグはキャッシュのエントリー をグループ化してキャッシュする際に指定します。
dependency-idはdependency-id基本ストリング（キャッシュ・グループ名）とcomponentエレメント
の値を用いて生成されます。componentエレメントの指定方法はcache-idと同じです。
<invalidation>キャッシュを無効化する際に指定します。invalidation-idとdependency-idが一致し
た場合、該当dependency-idを持つキャッシュ・エントリーは全て無効化されます
34
動的キャッシュの応用設定
（外部キャッシュ）
ここからは動的キャッシュの応用として、外部キャッシュについてご説明致します。
35
外部キャッシュ
n
サーブレット・キャッシュを前段のコンポーネントに配置可能
u
u
より前段でキャッシュ・ヒットさせることによりキャッシュ効果アップ
外部キャッシュ先としては以下の2つ
l
l
WebServer Plugin上のESIキャッシュ
IHS上の高速応答キャッシュ・アクセラレーター（
Windows環境のみ）
IHS
WebServer
Plug-in
cache
ESI
Processor
cache
高速応答キャッシュ・
アクセラレーター
（Windows環境のみ）
AppServer
cache
WebサーバーPlugin
ESIキャッシュ
サーブレット・キャッシュのオプショナルな設定として、外部キャッシュがあります。より前段でキャッ
シュ・ヒットさせることにより、レスポンスが返されるまでのホップ数が減り応答時間も向上しますし、
バックエンドのシステムにかかる負荷を軽減することにもつながります。
外部キャッシュの配置先としてサポートされるのは以下の３つです。
WebServer Plugin上のEdge Side Includeキャッシュ
IHS上の高速応答キャッシュ・アクセラレーター（FRCA）（Windows環境のみ）
36
外部キャッシュの設定
1.
外部キャッシュ・グループ定義の作成
l
2.
外部キャッシュ･グループ・メンバーの追加
l
3.
以下の表に従って、キャッシュのタイプと配置先 を指定
外部キャッシュ
アダプター 名
アドレス
ESIキャッシュ
com.ibm.websphere.servlet.cache.ESIInvalidatorServlet
ローカル・ホスト
IHS AFPA
com.ibm.ws.cache.servlet.Afpa
AFPAのポート
cachespec.xmlでの定義
l
4.
「動的キャッシュ・サービス」の追加プロパティより設定
キャッシュ・エントリー毎に外部キャッシュの可否を設定
各コンポーネントでの定義
外部キャッシュを行うために必要な設定は以下の通りです。
１．外部キャッシュ・グループ定義の作成
動的キャッシュ・サービスの追加プロパティより設定します。デフォルトでESIキャッシュの定義はあら
かじめ作成されいます 。
２．外部キャッシュ・グループ・メンバーの定義
作成した外部キャッシュ・グループのメンバーとして、外部メンバーのアドレスおよび外部キャッ
シュ・アダプター名を指定します。
３．cachespec.xmlでの定義
cachespec.xmlで、キャッシュ・エントリー毎にpropertyタグの中で外部キャッシュ可能か否かを指
定します。
４．各コンポーネントでの定義
次ページ以降の各外部キャッシュ・コンポーネントで必要な設定を行います。
37
Edge Side Includeキャッシュ
n
WebServerプラグイン内にESIプロセッサーが存在
u
u
WAS上にDynaCacheESI.earをインストール
外部キャッシュの設定
・
・
・
Name="ESIEnable" Value="true" />
およびplugin-cfg.xmlで設定 <Property
<Property Name="ESIMaxCacheSize" Value="1024" />
l
l
デフォルト有効
最大キャッシュサイズ を
KB単位で指定
<Property Name="ESIInvalidationMonitor" Value="false" />
・
・
・
①ESIが有効な場合、全てのリクエ
ストはESIプロセッサーを経由
②キャッシュ・
ミスの場合は
Surrogate-Capabilityヘッダーを
要求に付加しリクエスト
を
AppServerにフォワード
IHS
WebServer Plug-in
ESI
Processor
④Surrogate -Controlヘッダーの
値を元に、キャッシュIDを生成し
キャッシュを保管
AppServer
③AppServerで、
・
サーブレット・キャッシュが有効 かつ
・
cachespec.xmlでESI 可能に指定されている
場合、Surrogate-Controlヘッダーを応答として返す
まずWebサーバー・プラグイン上にあるEdge Side Includeキャッシュです。
Edge Side Includeはフラグメント化されたWebページを動的に統合しページを生成するための
マーク・アップ言語を規定したオープン・スタンダードな仕様です。このESI仕様に基づいて、
WebServerプラグイン内に存在するESIプロセッサーによって動的コンテンツのフラグメントをキャッ
シュします。ESIキャッシュはWebサーバー・プラグインのメモリー 上にキャッシュを行います。ESI
キャッシュを有効にするには、WAS上に製品提供のDynaCacheESI.earをインストールし、設定を
plugin-cfg.xmlファイルで行います。
pugin-cfg.xmlで指定可能な設定は、ESIキャッシュの有効・無効（デフォルト有効）、最大キャッ
シュ・サイズ（KB単位で指定、デフォルト１M）およびアプリケーション・サーバーからの明示的な
キャッシュの無効化通知を受け付けるか否か（デフォルト無効）です。
基本的なESIキャッシュの動きは以下の通りです。Web サーバーのプラグインが要求を受信した際、
ESIプロセッサーが使用不可でない限り、その要求はESIプロセッサーに送信されます。キャッシュ・
ミスが発生した場合、Surrogate-Capabilityヘッダー が要求に追加され、その要求がアプリケーショ
ン・サーバーに転送されます。アプリケーション・サーバーにおいて、サーブレット・キャッシングが
使用可能となっており
、かつ応答がエッジ・キャッシュ可能である場合、アプリケーション・サーバー
は Webサーバー・プラグインへの応答としてSurrogate-Controlヘッダー を戻します。
Surrogate-Control 応答ヘッダー の値にはルールのリストがあり、ESIプロセッサーはこれを使用し
て、キャッシュID を生成します。そしてキャッシュID をキーとして、ESI キャッシュ内にレスポンスを
保管します。レスポンスのBODYにある< esi: include>タグごとに新規要求が処理され、ネストされ
ているインクルードはそれぞれキャッシュ・ヒットで見付かるか、または別の要求としてアプリケーショ
ン・サーバーに転送されるかします。ネストされたインクルードがすべて処理された場合、そのペー
ジはアセンブルされてクライアントに戻されます。
38
Edge Side Includeキャッシュ
n
ESIキャッシュ・エントリーの無効化
u
新規エントリーのために古いキャッシュが無効化される
u
有効期限タイムアウト
l
l
l
最も有効期限が近いキャッシュが削除される
cachespec.xmlのtimeoutタグで指定
静的コンテンツのデフォルトの有効期限 は３００秒
Ø
u
l
l
n
JVMパラメーター -Dcom.ibm.servlet.file.esi.timeOut=60 で変更可能
AppServerから明示的に無効化通知を送る
plugin-cfg.xmlでESIInvalidationMonitorを有効に
AppServer上にDynaCacheESI.earをインストール
ESIキャッシュの考慮点
u
WebサーバーがThreadモデルで稼動するときに有効
キャッシュはプロセス毎に行われ、プロセス間では共有されないためメモリーを食
いつぶす危険性がある
l IHS6.0はスレッド・
モデルで稼動、１プロセスのみ起動させる
l
u
AppServer上のCacheMonitor.earからキャッシュ状況を監視可能
ESIキャッシュが無効化されるタイミングは３つあります。
まず1つ目はESIキャッシュのキャッシュ量が最大サイズに達した場合に、最も有効期限が近い
キャッシュから削除されます。2つ目としてはタイムアウト設定によるものです。ESIキャッシュ上に
キャッシュされたコンテンツの有効期限はcachespec.xmlの<timeout>タグで指定することが可能
です。静的コンテンツのデフォルトの有効期限は300秒となっておりますが、JVMパラメータDcom.ibm.servlet.file.esi.timeOut=<value>で明示的 に指定することも可能です。３つ目として、
アプリケーション・サーバーから明示的 に無効化通知を送られた場合です。アプリケーション・サー
バーから明示的 に無効化通知を送るには、plugin-cfg.xmlでESIInvalidationMonitorを有効に設
定し、WAS上にDynaCacheESI.earがインストールされている必要があります。
ESIキャッシュを用いる際の注意点としては、IHS6.0などThreadモデルのWebサーバーとともに使
用するようにしてください。キャッシュはプロセス毎に行われますので、プロセス・ベースのWebサー
バーを利用した場合には、キャッシュを有効に利用できません。
なお、ESIキャッシュの状況はWAS上のCacheMonitor.ear（後述）から監視して頂くことが可能で
す。
39
IHS高速応答キャッシュ・アクセラレーター
n
高速応答キャッシュ・アクセラレーター
u
静的コンテンツのキャッシュ
l
Windows環境およびAIXでサポート
l
httpd.confでの設定
LoadModule ibm_afpa_module modules/mod_afpa_cache.so
AfpaEnable
AfpaCache on
AfpaLogFile “<IHS_ROOT>¥logs¥afpalog" V-ECLF
u
動的コンテンツのキャッシュ
l
l
Windows環境のみ
外部キャッシュの定義およびhttpd.confでの設定
Ø
Ø
AfpaPluginHostにはWASのホスト名および外部キャッシュグループのメンバー設定のアドレス欄で設
定したポートを指定
WASが複数存在する場合は、AfpaPluginHostディレクティブを複数指定
LoadModule ibm_afpa_module modules/mod_afpa_cache.so
AfpaEnable
AfpaCache on
AfpaLogFile “<IHS_ROOT>¥logs¥afpalog" V-ECLF
#以下が動的コンテンツのキャッシュに必要な追加設定
LoadModule afpaplugin_module <WASPlugin_ROOT> ¥bin¥afpaplugin20.dll
AfpaPluginHost WAS_Hostname1:port
AfpaPluginHost WAS_Hostname2:port
次にIHS の高速応答キャッシュ・アクセラレーター（Fast Response Cache Accelerator, FRCA）、
別名AFPAへの外部キャッシュです。
IHS上への静的コンテンツのFRCAキャッシュはWindows環境およびAIX環境でサポートされます
が、動的コンテンツのFRCA上への外部キャッシュがサポートされるのはWindows環境のみです。
設定はhttpd.confで上記の通り行います。
一つのIHSが複数のアプリケーション・サーバーへとリクエストをルーティングしている場合には、上
記例のようにAfpaPluginHostディレクティブ を複数設定して下さい。
40
動的キャッシュの管理
41
キャッシュのモニタリング
n
CacheMonitor.earのインストール
u
製品提供のキャッシュ管理用アプリケーション
l
基本キャッシュ統計情報
l
キャッシュ・エントリーのモニタリング・無効化
l
l
依存性ID別キャッシュ・エントリーのモニタリング
ESIキャッシュ統計
l
外部キャッシュ内のデータ、ディスク・オフロードされたデータのモニター・無効化
l
キャッシュ・ポリシーの確認
Ø
キャッシュ・サイズ、キャッシュ・ヒット数、キャッシュ・ミス数、除去されたキャッシュ数etc
キャッシュした内容を確認するには、製品提供のCacheMonitorという
アプリケーションを使用して
頂くことが可能です。
このキャッシュ・モニター から、上に列挙したような基本キャッシュ統計情報の表示やキャッシュ・イン
スタンス内に保管されているキャッシュの確認や無効化などを行うことができます。
アプリケーションを導入する際の注意点として、一般ユーザー 用アプリケーション が稼動する
default_hostにマッピングしないようにご注意下さい。事前に定義されているadmin_hostにマッピ
ングするかキャッシュ・モニター用の仮想ホストを作成してください。
42