| Oracle® Fusion Middleware WebCenter Sites管理者ガイド 11gリリース1 (11.1.1.8.0) E49682-01 |
|
 前 |
 次 |
Oracle WebCenter SitesとSatellite Serverには、inCacheフレームワーク(または単純にinCache)と呼ばれるキャッシング・システムが付属しています。このシステムは、Terracotta社によるオープン・ソースで標準ベースの製品であるEhcacheの上に構築されています。従来の方法によるデータベースへのキャッシングと比べて、inCacheでは、Webサイト・パフォーマンスが向上しています。この章では、inCacheフレームワークの概要を説明します。
この章は、次の項で構成されています。
inCacheは高パフォーマンス、メモリーベースのページおよびアセット・キャッシング・システムで、これを使用すると、Oracle WebCenter Sitesのデータを中央の共有リポジトリや共有ファイル・システムにキャッシュする必要がなくなります。inCacheは、Terracotta社によるオープン・ソースのJavaキャッシング・フレームワークであるEhcacheに基づいており、任意のキャッシング・システム上に実装できます。(Ehcacheの詳細は、 http://ehcache.org/を参照してください。)
inCacheフレームワークは、レガシーのページ・キャッシング・フレームワークに置き換わるものです。inCacheでは、デフォルトでアセットのキャッシングもサポートしています。inCacheフレームワークでは、次のような利点が得られます。
高パフォーマンス。レスポンス時間が短いので、パブリッシング・セッションの頻度を上げることができます。ページおよびアセットの効果的な無効化により、更新済コンテンツがすばやく提供されます。
分散化アーキテクチャ。ノードはそれぞれ独自のローカル・キャッシュを維持しています。inCacheフレームワークでは、データベースのキャッシングと共有ディスクが排除されています。
ブロードキャスト・システム。個別のノードがキャッシュ全体の完全なビューを持つ必要がなくなりました。コンテンツへの変更をリスニングしているノードが、個々のコンテンツの必要に応じてブロードキャストに応答します。
リニアなスケーラビリティが強化され、ディスクやメモリーのデータに対して拡張。
フェイルオーバーと永続性。シャットダウンされたノードはローカル・キャッシュ内にデータを保持し、再起動時に、中央管理されている無効化のレコードに対して自己更新します。
オンデマンドのページ評価と無効化。ノードは、コンテンツがリクエストされたときのみ、現在キャッシュされているコンテンツを有効化して更新します。
この章では、主にページ・キャッシングについて説明します。全体を通して、ページは、ページ・アセットではなくレンダリングされるページを意味する用語として使用されています。アセットのキャッシングについでの説明を理解するには、まずこの章の残りの部分を読むことをお薦めします。特に、第27.2項「inCacheの仕組み」をよく読んで、キャッシュ・コンテナに関する基本知識と、これらが相互機能する仕組みについて理解してください。
クラスタ化された環境では、inCacheはクラスタのデータベースの外側の分散化されたアーキテクチャに実装されます。図27-1「ローカル・キャッシュ」に示すように、各ノードにはそれぞれ独自のローカル・キャッシュがあります。各Oracle WebCenter Sitesノードは、他のOracle WebCenter Sitesノードからのブロードキャストをリスニングすることで、ローカル・キャッシュを最新に保ち、HTTPを介してリモートのSatellite Serverに更新を伝達します。
ノードのローカル・キャッシュはパーティションで区切られています。
pageByQryキャッシュには、ノードのWebページが格納されます。
dependencyRepositoryキャッシュには、Webページを構成するアセットの識別子が格納されます。
|
注意:
|
notifierキャッシュは、編集またはパブリッシュのプロセスで変更されたアセットの識別子をブロードキャストします。ブロードキャストは、アセットの変更されたノードによって開始されます。リスニングするノードがブロードキャストに応答する方法は、ノードによって異なります。次に例を示します。
ノードAのWebCenter SitesユーザーがアセットAを編集します。
ノードAのnotifierキャッシュが、その他のすべてのノードに変更の通知をブロードキャストします。
アセットAを含むすべてのWebCenter Sitesノードが、それぞれ独自のローカル・キャッシュ内のアセットを無効化することで応答します。各ノードは独自のdependencyRepositoryキャッシュを参照し、アセットの識別子を無効にマークして、キャッシュ全体の依存性生成数を増分させます。無効化されたアセットは、そのアセットを参照するページで使用できなくなるので、これらのページそのものも無効になります。ただし、ノードは、ページがリクエストされるまでページを評価しません。ここにパフォーマンス上の利点があります。
無効化されたアセットに対する依存性を持つページのリクエストにノードが応答する場合、このノードはpageByQryキャッシュを参照し、ページを評価し、無効化するページを決定し、ページをフラッシュし、新規ページを生成し、そのページを訪問者のブラウザに提示して、ローカル・キャッシュ内に新規ページとその依存性を記録します(依存性は、ページを構成するアセットの識別子として記録されます)。その時点から、ページが異常終了するか、アセットが再び無効化されるまで、ノードのローカル・キャッシュからは同じページが提示されます。
WebCenter SitesとSatellite Serverは同じキャッシング・フレームワークを使用していますが、1つだけ大きく異なる点があります。これは、Satellite Serverノードは、HTTPを介してWebCenter Sitesノードと通信しているという点です。
|
注意:
|
WebCenter SitesノードまたはSatellite Serverノードがシャットダウンした場合、そのキャッシュ内のデータは保持されますが、アクティブなノードは引き続きアセットを無効化しているので、すぐにデータが古いものになってしまう可能性があります。このため、ノードを再起動するにはキャッシュの更新が必要になります。再起動時の更新は共通の無効化メモリーによって確実に実行されます。これはWebCenter Sitesクラスタのデータベースに表として格納され、クラスタ内のすべてのノードが再起動時に使用できるように保持されています。この表の名前は、FW_InvalidationMemoryです。
無効化メモリーにはアセットの無効化のレコードが格納されます。具体的に言えば、コンテンツ管理やパブリッシュ・プロセスの実行中に変更または削除されたアセットの識別子です。表の拡大は、タイマーベースのクリーンアップ・メカニズムによってチェックされます。これは15分間隔で実行され、最も古い期間の無効化レコードを消去します。
ノードは再起動時に、非アクティブであった期間に欠落した情報をリカバリしようとして、無効化メモリーを参照します。
ノードの非アクティブ期間の無効化レコードが存在する場合、ノードは自分自身でリプレイします。
非アクティブ期間に無効化されたアセットが存在しない場合、ノードはシャットダウンされなかったかのように動作を続行します。
ノードが非アクティブであった間にクリーンアップ・メカニズムによって無効化レコードが消去された場合、ノードのキャッシュは自らを破棄するので、再構築する必要があります。
リモートのSatellite Serverは、WebCenter Sitesに更新を求めるリクエストを送信することによって失った情報を、再起動時に取得します。
inCacheを有効にすると、リアルタイム・パブリッシュ・プロセス用のdonotregenerateフラグが無効になります。このフラグが認識されなくなるので、リアルタイム・パブリッシュ・セッション時のページの再生成には、クロールが使用されます。クロールは計算コストの高くつくオプションです。これを実装していなければ、ページはリクエスト時のみ再生成されます。
クロール・オプションでは、WebCenter Sitesのページ・リジェネレータによって分析される一連のURLを指定する必要があります。通常、これらはホームページやその他のトラフィックの多いページのURLです。さらに、これらのページのクロール深度を指定することもできます。たとえば、深度1では指定したページとそれらのページのリンク先のページがクロールされ、深度0では指定したページのみがクロールされます。クロールされるページは、そのコンポーネント・アセットがパブリッシュ・セッション時に無効化された場合か、それらのページがキャッシュされていない場合のみ再生成されます。指定したページ上のすべてのページレットがプロセス内で再生成されます。
クロールするURLのリストとクロールの深度は、FW_RegenCriteria表で指定する必要があります。この表は、inCacheの構成後の最初のパブリッシュ・セッション時に配信システム上に作成されます。ft_ssパラメータをURLに含むことで、リクエストをWebCenter Sitesで直接処理するのか、リモートのSatellite Serverによって処理するのかを指定できます。inCacheの構成方法とページの再生成については、第28章「inCacheによるページのキャッシング」を参照してください。
WebCenter Sitesのダブルバッファによるページ・キャッシング方法では、ライブWebサイト上でWebCenter SitesとSatellite Serverのキャッシュを連結させて使用します。ダブル・バッファリングでは、ページが常にWebCenter SitesかSatellite Serverのいずれかのキャッシュ内に保持され、ページ・リクエストの過負荷からWebCenter Sitesを保護し、ライブWebサイトで空白ページやリンク切れが表示されないようにします。
inCacheフレームワークで従来のシステムのダブルバッファ・キャッシングを維持するために、HTTPリクエストを介してリモートのSatellite ServerはWebCenter Sitesと通信を続けるようになっています。Satellite Serverはこれまでどおりの方法で、HTTPリクエストを介してページ・データを読み取ってキャッシュします。ただし、ページ・データには、アセット識別子のカンマ区切りのリスト形式で依存性情報が含まれるようになり、この情報はリモートのSatellite Serverにもストリームされます。
リモートのSatellite Serverは、ページ・キャッシングのみで使用されます。これは、ページ伝播やバックグラウンドでのページ再生成など、高度な機能をサポートするように構成できます。
この項は、次のトピックで構成されています。
ページ伝播オプションによって、すべてのWebCenter SitesノードとSatellite Serverノードが同じページをホストできるようになり、それぞれのノードがページを再生成する必要がなくなります。データベースを参照してページを再生成するかわりに、ノードは新しく生成および再生成されたページを、ページが(再)生成およびキャッシュされたノードからローカル・キャッシュに受信します。ページのキャッシングによって伝播が引き起こされます。ページ伝播の構成方法については、第28章「inCacheによるページのキャッシング」を参照してください。
リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。詳細は、第28.3.4項「バックグラウンドでページレットを再生成するための構成」を参照してください。
inCacheフレームワークでは、パフォーマンスが大幅に向上しています。ノードはキャッシュをディスク上に保持し、障害からリカバリできます。分散化アーキテクチャによってボトルネックが防止されます(ただし、キャッシュ・アイテムの中央リポジトリが存在しないので、すべてのキャッシュの全体状況の確認が難しくなる可能性はあります)。ページ伝播によって、ページを再生成する必要がなくなり、バックグラウンドでのページの再生成によって、リモートのSatellite Serverは置き換えページの生成中でもページを引き続き提供できます。
この新しいフレームワークでは、リアルタイム・パブリッシュ用のdonotregenerateフラグが無効になります。パブリッシュ・セッション中に再生成する必要があるページは、FW_RegenCriteria表で指定する必要があります。それ以外の場合、ページはリクエスト時に再生成されます。
ページ・キャッシングと構成方法の詳細は、第28章「inCacheによるページのキャッシング」を参照してください。この章には、ディスクのストライプ化、リアルタイム・パブリッシュ時にページ再生成を実行可能にする方法、ページ伝播の設定、バックグラウンドでのページ再生成の構成、従来のシステムのページ・キャッシングに戻す方法といったオプションに関する情報が含まれています。
アセットのキャッシングについては、第29章「inCacheによるアセットのキャッシング」を参照してください。
