Fusion Middleware Oracle Web Cache管理者ガイド

11g リリース1(11.1.1)

B56248-02(原本部品番号:E10143-04)

目次

例一覧

図一覧

表一覧

タイトルと著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このマニュアルでの新しい情報

- Release 11gの新機能

第I部 セキュアなプロキシ・キャッシュおよびロード・バランシングについて

1 リバース・プロキシについて

- 1.1 Web層について

- 1.1.1 リバース プロキシ

- 1.2 Web層でのリクエスト・フロー

- 1.2.1 HTTP通信の管理

- 1.2.2 リクエストのフィルタリングとルーティング

- 1.2.3 オリジン・サーバーのロード・バランシングとフェイルオーバー

- 1.2.4 キャッシュ機能

- 1.2.5 圧縮

- 1.2.6 セッション・バインディング

- 1.3 Oracle Fusion Middlewareコンポーネントとの互換性

第II部 基本的な管理

2 Oracle Web Cacheの管理の概要

- 2.1 Oracle Web Cacheの管理ツールについて

- 2.2 サイトの構成について

- 2.3 Oracle Web Cache管理でのリソース制限について

- 2.3.1 最大キャッシュ・サイズ

- 2.3.2 最大着信接続数

- 2.3.3 キャッシュ・オブジェクトの最大サイズ

- 2.3.4 ネットワーク・タイムアウト

- 2.4 Oracle Web Cacheポートについて

- 2.5 IPアドレスについて

- 2.6 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Web Cacheの管理の概要

- 2.6.1 Fusion Middleware Controlへのログイン

- 2.6.2 Oracle Web Cache管理ページへのナビゲート

- 2.6.3 「Webキャッシュ・メンバー」ページ上の統計について

- 2.6.4 Fusion Middleware Controlヘルプの使用

- 2.7 Oracle Web Cache Managerを使用したOracle Web Cacheの管理の概要

- 2.7.1 Oracle Web Cache Managerの起動

- 2.7.2 Oracle Web Cache Managerのナビゲート

- 2.7.3 「Cache Operations」ページについて

- 2.8 Oracle Process Manager and Notification(OPMN)を使用したOracle Web Cacheの管理の概要

- 2.9 Oracle Web Cacheを構成および管理するための基本的な作業

- 2.10 環境へのOracle Web Cacheシステム・コンポーネントの追加

- 2.11 Oracle Web Cacheシステム・コンポーネントのプロパティの指定

- 2.11.1 作業1: Oracle Web Cacheのポートの構成

- 2.11.1.1 Fusion Middleware Controlを使用したOracle Web Cacheのポート構成の検証

- 2.11.1.2 OPMNを使用したOracle Web Cacheのポート構成の検証

- 2.11.1.3 Oracle Web Cacheリスニング・ポートの追加

- 2.11.1.4 Oracle Web Cache操作ポートの変更

- 2.11.2 作業2: オリジン・サーバーの設定

- 2.11.3 作業3: サイト定義の指定

- 2.11.3.1 すべてのレスポンスに対する圧縮の無効化

- 2.11.4 作業4: サイト定義からオリジン・サーバーへのマッピング

- 2.11.5 作業5: リソース制限とネットワークしきい値の設定

- 2.11.6 作業6: エラー・ページの構成

- 2.11.7 作業7: Oracle Web Cacheの再起動

- 2.12 セッション定義の作成

- 2.13 Oracle Web Cacheの起動と停止

- 2.13.1 opmnctlを使用した起動と停止

- 2.13.2 Fusion Middleware Controlを使用した起動と停止

- 2.13.3 Oracle Web Cache Managerを使用した起動と停止

3 高可用性ソリューションの構成

- 3.1 オリジン・サーバーのロード・バランシングとフェイルオーバーの概要

- 3.1.1 急激な過負荷の回避

- 3.1.2 ステートレス・ロード・バランシング

- 3.1.3 バックエンド・フェイルオーバー

- 3.2 セッション・バインディングの概要

- 3.3 キャッシュ・クラスタの概要

- 3.4 ハードウェア・ロード・バランサを使用しない高可用性の概要

- 3.4.1 ソフトウェア・ロード・バランサ専用またはリバース・プロキシ専用としてのOracle Web Cache

- 3.4.2 オペレーティング・システムによるロード・バランシングのサポート

- 3.5 セッション・バインディングの構成

- 3.6 同一のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成

- 3.6.1 構成の前提条件

- 3.6.2 フェイルオーバーのしきい値と許容量設定の理解

- 3.6.2.1 キャッシュ・クラスタのフェイルオーバーのしきい値

- 3.6.2.2 キャッシュ・クラスタ・メンバーの許容量

- 3.6.3 作業1: クラスタへのキャッシュの追加とプロパティの構成

- 3.6.4 作業2: セッション・バインディングのトラッキングの有効化

- 3.6.5 作業3: クラスタ・メンバーへの構成の同期

- 3.6.6 クラスタからのキャッシュ・メンバーの削除

- 3.6.7 管理および無効化のみのクラスタの構成

- 3.7 非関連キャッシュまたは別のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成

- 3.7.1 作業1: キャッシュ・クラスタ設定の構成

- 3.7.2 作業2: クラスタへのキャッシュの追加

- 3.7.3 作業3: セッション・バインディングのトラッキングの有効化

- 3.7.4 作業4: クラスタ・メンバーへの構成の同期

- 3.7.5 クラスタからのキャッシュの削除

- 3.7.6 管理および無効化のみのクラスタの構成

- 3.8 ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成

- 3.9 Microsoft Windowsネットワーク負荷分散の構成

4 リクエスト・フィルタリングの構成

- 4.1 リクエスト・フィルタリングの概要

- 4.2 リクエスト・フィルタのタイプ

- 4.3 習得ルールについて

- 4.4 次のみを監視モードについて

- 4.5 特権IPフィルタのルールの構成

- 4.6 クライアントIPリクエスト・フィルタのルールの構成

- 4.7 メソッド・リクエスト・フィルタのルールの構成

- 4.7.1 メソッド・リクエスト・フィルタに対する習得ルールの有効化

- 4.8 URLリクエスト・フィルタのルールの構成

- 4.8.1 URLリクエスト・フィルタに対する習得ルールの有効化

- 4.9 ヘッダー・リクエスト・フィルタのルールの構成

- 4.10 問合せ文字列リクエスト・フィルタのルールの構成

- 4.11 フォーマット・リクエスト・フィルタのルールの構成

- 4.12 リクエスト・フィルタのルールの削除

- 4.13 リクエスト・フィルタのタイプとルールの統計監視

- 4.14 リクエスト・フィルタを構成する時間の削減

- 4.14.1 ソース・サイトからターゲット・サイトへのルールのコピー

- 4.14.2 構成設定のリセット

5 セキュリティの構成

- 5.1 Oracle Web Cacheのセキュリティの概要

- 5.1.1 Oracle Web Cacheのセキュリティ・モデル

- 5.1.1.1 管理の制限

- 5.1.1.2 Secure Sockets Layer(SSL)

- 5.1.1.2.1 認証局

- 5.1.1.2.2 証明書

- 5.1.1.2.3 ウォレット

- 5.1.1.2.4 SSLの仕組み

- 5.1.1.3 SSLアクセラレータ

- 5.1.2 保護リソース

- 5.1.3 認可およびアクセスの適用

- 5.1.4 Oracle Identity Managementインフラストラクチャの活用

- 5.1.4.1 Oracle Single Sign-Onサーバーからのコンテンツのキャッシュについて

- 5.1.4.2 Oracle Single Sign-Onパートナ・アプリケーション(mod_osso)のキャッシングについて

- 5.1.4.3 Oracle Single Sign-Onを介した認証について

- 5.2 パスワード・セキュリティの構成

- 5.3 アクセス制御の構成

- 5.4 HTTPSリクエストをサポートするためのOracle Web Cacheの構成

- 5.4.1 作業1: ウォレットの作成

- 5.4.2 作業2: HTTPSリスニング・ポートの構成

- 5.4.3 作業3: オリジン・サーバーに対するOracle Web Cache接続のためのSSL設定の構成

- 5.4.4 作業4: HTTPSリクエストを要求するサイトの構成

- 5.4.4.1 キープ・アライブ接続用のssl.confの変更

- 5.4.5 作業5: Oracle Web Cacheの再起動

- 5.4.6 作業6: Oracle WebLogic Serverの追加の構成の実行

- 5.5 追加のHTTPS構成

- 5.5.1 HTTPS操作ポートの構成

- 5.5.2 クライアント側の証明書の要求

- 5.5.2.1 HTTPSリスニング・ポートのクライアント側の証明書の構成

- 5.5.2.2 キャッシュ・クラスタのクライアント側の証明書の構成

- 5.5.2.3 サイトのクライアント側の証明書の構成

- 5.5.3 証明書失効リスト(CRL)の構成

- 5.6 HTTPリクエスト・ヘッダー・サイズの構成

- 5.7 ClientIPヘッダーが有効であることの確認

- 5.8 セキュアなコンテンツのキャッシュに対するサポートの構成

- 5.9 root権限によるwebcachedの実行

- 5.9.1 プロセス認証の構成

- 5.9.2 特権ポートおよび1,024よりも多いファイル・ディスクリプタに対するroot権限の構成

- 5.9.3 現在のユーザーのroot権限の構成

- 5.9.4 アクセス権のインストール時の状態へのリセット

- 5.10 UNIXでファイル・アクセス権を設定するためのスクリプト

6 コンテンツのキャッシュと圧縮

- 6.1 キャッシュへのデータ格納について

- 6.2 キャッシュの一貫性について

- 6.2.1 有効期限

- 6.2.2 HTTPキャッシュの検証

- 6.2.3 無効化

- 6.3 キャッシュ・デシジョンについて

- 6.4 キャッシュ・ルールの作成の概要

- 6.5 詳細設定の構成の概要

- 6.5.1 複数バージョンを持つオブジェクトのキャッシュ

- 6.5.2 埋込みURLパラメータとPOST本体パラメータを持つオブジェクトのキャッシュ

- 6.5.3 エラー・レスポンスのキャッシュ

- 6.5.4 セッションを持つオブジェクトのキャッシュ

- 6.5.5 セッション・エンコードされたURLを持つオブジェクトのキャッシュ

- 6.6 キャッシュ・ルールを構成および監視するための基本的な作業

- 6.7 有効期限ポリシーの構成

- 6.8 キャッシュ・ルールの構成と監視

- 6.8.1 一般ルール設定の構成

- 6.8.1.1 正規表現のパラメータ

- 6.8.2 1つのオブジェクトに複数のバージョンがある場合のルールの設定の構成

- 6.8.3 埋込みURLパラメータまたはPOST本体パラメータの値の除外

- 6.8.4 HTTPリクエスト・ヘッダーが含まれる複数バージョンのオブジェクトの類似ブラウザ・タイプの認識

- 6.8.5 ルールのエラー・レスポンスの構成

- 6.8.6 セッション・キャッシュ・ルールの構成

- 6.8.7 セッション・エンコードされたURLに対するサポートの構成

- 6.8.8 セッションの確立を含むポピュラーなページに対するルールの構成

- 6.9 キャッシュ・ルールのサマリー設定の監視

- 6.10 Surrogate-Controlレスポンス・ヘッダーをキャッシュ・ルールの代替として使用

- 6.10.1 Surrogate-Controlレスポンス・ヘッダー・フィールド

7 コンテンツの無効化

- 7.1 無効化の概要

- 7.2 バンド外無効化について

- 7.3 ESIによるインライン無効化

- 7.4 レスポンス・ヘッダーによる無効化について

- 7.5 バンド外メカニズムとESIインライン・メカニズムの無効化リクエストの形式

- 7.5.1 無効化リクエストの構文

- 7.5.2 無効化レスポンスの構文

- 7.5.3 無効化プレビュー・リクエストの構文

- 7.5.4 無効化プレビュー・レスポンスの構文

- 7.5.5 無効化の例

- 7.5.5.1 例: 1つのオブジェクトを無効にする

- 7.5.5.2 例: 複数のオブジェクトを無効にする

- 7.5.5.3 例: オブジェクトのサブツリーを無効にする

- 7.5.5.4 例: 特定のWebサイトのすべてのオブジェクトを無効にする

- 7.5.5.5 例: 接頭辞の一致を使用してオブジェクトを無効にする

- 7.5.5.6 例: サブストリングと問合せ文字列の一致を使用してオブジェクトを無効にする

- 7.5.5.7 例: 検索キーの一致を使用してオブジェクトを無効にする

- 7.5.5.8 例: キャッシュ・クラスタ全体に無効化リクエストを伝播する

- 7.5.5.9 例: 無効化をプレビューする

- 7.6 検索キーによる無効化について

- 7.7 バンド外無効化の開始

- 7.7.1 Telnetを使用した無効化リクエストの送信

- 7.7.2 Oracle Web Cache Managerを使用した無効化リクエストの送信

- 7.7.2.1 基本無効化リクエストの発行

- 7.7.2.2 拡張無効化リクエストの発行

- 7.7.3 Application Program Interface(API)を使用した自動無効化リクエスト

- 7.7.4 データベース・トリガーを使用した自動無効化リクエスト

- 7.7.5 スクリプトを使用した自動無効化

- 7.8 レスポンス・ヘッダーによる無効化の有効化

- 7.8.1 使用例

- 7.8.1.1 基本的なURIによる無効化

- 7.8.1.2 ディレクトリURIによる無効化

- 7.8.1.3 非同期の無効化

- 7.8.1.4 明示的URIを使用した検索キーによる無効化

- 7.8.1.5 暗黙的URIを使用した検索キーによる無効化

- 7.8.1.6 複数の無効化ディレクティブ

- 7.8.1.7 カンマとセミコロンの混在

- 7.8.1.8 複数の無効化レスポンス・ヘッダー

- 7.9 検索キーによる無効化の有効化

- 7.10 セキュリティに関する考慮事項

- 7.10.1 invalidatorアカウントについて

- 7.10.2 無効化メッセージの伝播

- 7.10.2.1 キャッシュ・クラスタ内での無効化処理

- 7.10.2.2 階層内での無効化

8 診断機能の使用方法

- 8.1 診断ソリューションの概要

- 8.2 ポピュラーなリクエストとキャッシュの内容のリスト表示の概要

- 8.3 HTMLボディまたはServerレスポンス・ヘッダー・フィールドでの診断情報とイベント・ログ情報の表示の概要

- 8.4 一般統計および詳細な統計の表示

- 8.5 構成統計の表示

- 8.6 ポピュラーなリクエストのリスト表示

- 8.7 ファイルへのキャッシュの内容のリスト出力

- 8.8 診断情報の表示場所の構成

9 ロギング

- 9.1 イベント・ログの概要

- 9.1.1 イベント・ロギング形式

- 9.1.1.1 Oracle Diagnostics LoggingのText形式およびXML形式

- 9.1.1.2 Oracle Web Cacheのクラシック形式

- 9.1.1.3 メッセージ9720のリクエスト詳細

- 9.1.1.4 Oracle-ECIDリクエスト・ヘッダー・フィールドについて

- 9.1.2 イベント・ログの例

- 9.1.2.1 例: 起動の失敗のエントリが含まれているイベント・ログ

- 9.1.2.2 例: 停止エントリが含まれているイベント・ログ

- 9.1.2.3 例: キャッシュ・ミスおよびキャッシュ・ヒットのエントリが含まれているイベント・ログ

- 9.1.2.4 例: 無効化エントリが含まれているイベント・ログ

- 9.1.2.5 例: ESIイベントの分析

- 9.2 アクセス・ログの概要

- 9.2.1 アクセス・ログの形式

- 9.2.1.1 共通ログ形式(CLF)

- 9.2.1.2 拡張CLF(ECLF)

- 9.2.1.3 複合ログ形式

- 9.2.1.4 拡張複合ログ形式

- 9.2.1.5 エンド・ユーザー・パフォーマンス監視の形式

- 9.2.2 アクセス・ログのフィールド

- 9.2.2.1 cs(header_name)およびsc(header_name)アクセス・ログ・フィールド

- 9.2.3 アクセス・ログの例

- 9.2.3.1 例: 再ロード・エントリが含まれているアクセス・ログ

- 9.2.3.2 例: ステータス・コード404エントリが含まれているアクセス・ログ

- 9.2.3.3 例: 複合形式のアクセス・ログ

- 9.2.3.4 例: サイト情報が含まれているアクセス・ログ

- 9.2.3.5 例: ESI診断情報が含まれているアクセス・ログ

- 9.2.3.6 例: ESIログ情報が含まれているアクセス・ログ

- 9.3 イベント・ログの構成

- 9.4 アクセス・ログの構成

- 9.5 カスタマイズされたアクセス・ログ形式の作成

- 9.6 カスタマイズされたアクセス・ログのロールオーバー・ポリシーの作成

- 9.7 イベント・ログとアクセス・ログの表示

- 9.8 イベント・ログとアクセス・ログのロールオーバー

- 9.9 監査ログの使用方法

10 一般的な配置シナリオの構成

- 10.1 一般的なデプロイメントでのOracle Web Cacheの使用方法

- 10.2 グローバル・イントラネット・アプリケーションでのキャッシュ階層の使用方法

- 10.3 ハードウェア・ロード・バランサを使用せずに高可用性を実現するためのOracle Web Cacheの使用方法

第III部 高度な管理

11 ESI言語タグによる動的コンテンツのキャッシュ

- 11.1 ページの部分的なキャッシュのためのESIについて

- 11.1.1 ESIの機能

- 11.1.1.1 ESI for Java(JESI)

- 11.1.2 Surrogate-Controlレスポンス・ヘッダーでのESI言語要素

- 11.1.3 キャッシュ・オブジェクトに対するSurrogate-Controlレスポンス・ヘッダーおよびSurrogate-Capabilityリクエスト・ヘッダーについて

- 11.1.4 構文規則

- 11.1.5 要素のネスト

- 11.1.6 変数式

- 11.1.6.1 変数の使用方法

- 11.1.6.2 変数のデフォルト値

- 11.1.6.3 HTTPリクエスト変数

- 11.1.7 例外およびエラー

- 11.1.8 inlineタグおよびincludeタグによる断片化

- 11.1.8.1 inlineタグをフェッチ不可の場合の断片化に使用する方法

- 11.1.8.2 inlineタグをフェッチ可能な場合の断片化に使用する方法

- 11.1.8.3 includeタグを断片化に使用する方法

- 11.1.8.4 アプリケーションに適した断片化メカニズムの選択

- 11.1.9 Refererリクエスト・ヘッダー・フィールド

- 11.1.10 テンプレート・ページおよびフラグメントのCookieの管理

- 11.2 コンテンツの動的アセンブリおよびページの部分的なキャッシュの使用

- 11.2.1 ページの部分的なキャッシュの使用

- 11.2.2 単純なパーソナライズでのESIの使用

- 11.2.3 ESIの使用例

- 11.2.3.1 ポータル・サイトの実装の例

- 11.2.3.1.1 inlineタグを使用したポータルの例

- 11.2.3.1.2 includeタグを使用したポータルの例

- 11.2.3.2 変数式を使用した単純なパーソナライズの例

- 11.3 HTTPレスポンスでのインライン無効化の使用方法

- 11.3.1 例: インライン無効化の使用

- 11.4 ESIタグの説明

- 11.4.1 ESIのchoose | when | otherwiseタグ

- 11.4.1.1 構文

- 11.4.1.2 属性

- 11.4.1.3 使用方法

- 11.4.1.4 ブール式

- 11.4.1.5 文

- 11.4.1.6 例

- 11.4.2 ESIのcommentタグ

- 11.4.2.1 構文

- 11.4.2.2 使用方法

- 11.4.2.3 例

- 11.4.3 ESIのenvironmentタグ

- 11.4.3.1 構文

- 11.4.3.2 属性

- 11.4.3.3 要素

- 11.4.3.4 構文の使用方法

- 11.4.3.5 例

- 11.4.4 ESIのincludeタグ

- 11.4.4.1 構文

- 11.4.4.2 属性

- 11.4.4.3 要素

- 11.4.4.4 構文の使用方法

- 11.4.4.5 使用方法

- 11.4.4.6 例

- 11.4.5 ESIのinlineタグ

- 11.4.5.1 構文

- 11.4.5.2 属性

- 11.4.5.3 使用方法

- 11.4.5.4 例

- 11.4.6 ESIのinvalidateタグ

- 11.4.6.1 構文

- 11.4.6.2 属性

- 11.4.6.3 使用方法

- 11.4.6.4 例

- 11.4.7 ESIのremoveタグ

- 11.4.7.1 構文

- 11.4.7.2 使用方法

- 11.4.7.3 例

- 11.4.8 ESIのtry | attempt | exceptタグ

- 11.4.8.1 構文

- 11.4.8.2 使用方法

- 11.4.8.3 例

- 11.4.9 ESIのvarsタグ

- 11.4.9.1 構文

- 11.4.9.2 構文の使用方法

- 11.4.9.3 使用方法

- 11.4.9.4 例

- 11.4.10 ESIの<!--esi-->タグ

- 11.4.10.1 構文

- 11.4.10.2 使用方法

- 11.4.10.3 例

12 サード・パーティ・アプリケーション・サーバーでのキャッシュ

- 12.1 サード・パーティ・アプリケーション・サーバーの概要

- 12.1.1 Webサイトの構成

- 12.1.2 キャッシュ・ルールと有効期限ルール

- 12.2 IBM WebSphere

- 12.2.1 WebSphere Snoop Servlet

- 12.2.2 WebSphere Calendar Creator JSP

- 12.3 Apache Tomcat

- 12.3.1 Apache TomcatのSnoop JSP

- 12.3.2 Apache Tomcatのセッション・サーブレット

- 12.4 Microsoft IIS

- 12.4.1 ServerVariables_Jscript ASP

- 12.4.2 Cookie_Jscript ASP

A Oracle Web Cacheのトラブルシューティング

- A.1 問題と解決方法

- A.1.1 Webアプリケーション・サーバーからレスポンスがないエラー

- A.1.2 Oracle Web Cacheコンピュータ上の負荷の問題

- A.1.3 パフォーマンスの低下とメモリー

- A.1.4 キャッシュ・クラスタ内の無効化タイムアウト

- A.1.5 オリジン・サーバー上の許容量の問題

- A.1.6 ブラウザで完全なレスポンスが受信されない

- A.1.7 ブラウザにページが表示されないエラー

- A.1.8 IBM Websphere Application Serverに伴うESIエラー

- A.1.9 イベント・ビューアにwebcache.xmlのXML解析エラーが表示される

- A.2 一般的な構成ミス

- A.3 キャッシュ・コンテンツ結果の診断

- A.4 一般的なEdge Side Includes(ESI)構文エラーの診断

- A.4.1 テンプレート構文エラーの例

- A.4.2 フラグメント構文エラーの例

- A.4.3 例外処理を伴うフラグメント構文エラーの例

- A.5 HTTPトラフィック変更の影響

- A.6 追加情報

用語集

索引

例一覧

- 11-1 ESIマークアップ

- 11-2 GetProfile.jspのXMLレスポンス

- 11-3 ESI要素のネスト

- 11-4 フェッチ不可の場合のinlineタグの例

- 11-5 フェッチ可能な場合のinlineタグの例

- 11-6 inlineタグ付きのportal.esi

- 11-7 inlineタグ付きのportal.esiの例: パーソナライズされた挨拶文

- 11-8 inlineタグ付きのportal.esiの例: Weather Forecast

- 11-9 portal.esiの例: 「My Stocks」フラグメント

- 11-10 inlineタグ付きのportal.esiの例: Promotion

- 11-11 inlineタグ付きのportal.esiの例: 「Latest News」および「Latest Sports News」

- 11-12 includeタグ付きのportal.esi

- 11-13 portal.esiの例: カスタム・プロファイル環境変数の設定

- 11-14 portal.esiの例: 環境変数付きのGetProfileファイル

- 11-15 varsタグ付きのportal.esiの例: パーソナライズされた挨拶文

- 11-16 includeタグ付きのportal.esiの例: Weather Forecast

- 11-17 includeタグ付きのportal.esiの例: 「My Stocks」フラグメント

- 11-18 portal.esiの例: MarkのPersonalizedStockSelectionフラグメント

- 11-19 portal.esiの例: ScottのPersonalizedStockSelectionフラグメント

- 11-20 includeタグ付きのportal.esiの例: Promotion

- 11-21 portal.esiの例: 入替式バナーの出力

- 11-22 portal.esiの例: 入替式バナーの再ロード

- 11-23 includeタグ付きのportal.esiの例: 「Latest News」および「Sports」セクション

- 11-24 パーソナライズされていないPL/SQLコード

- 11-25 ESIによるパーソナライズを使用したPL/SQLコード

- 11-26 show_bike.plのコード

- 11-27 インライン無効化リクエストを含むbuy_bike.plのコード

- 11-28 buy_bike.plのブラウザ・レスポンス

- 11-29 インライン無効化の診断情報を含むshow_bike.plのブラウザ・レスポンス

- 11-30 文の配置

- 12-1 Apache Tomcatバイナリ

図一覧

- 1-1 Webサーバー処理の高速化

- 1-2 Web層でのOracle Web Cacheへのリクエスト・フロー

- 2-1 「Webキャッシュ・メンバー」ページ

- 2-2 Oracle Web Cache Managerのインタフェース

- 3-1 ロード・バランシング

- 3-2 フェイルオーバー

- 3-3 セッション・バインディング

- 3-4 Oracle Web Cacheクラスタのアーキテクチャ

- 3-5 ロード・バランサとしてのOracle Web Cacheの配置

- 5-1 SSLによるセキュアな接続

- 6-1 複数のバージョンを持つオブジェクト

- 6-2 セッション・エンコードされたURL

- 7-1 無効化

- 7-2 分散キャッシュ階層内でのコンテンツの無効化

- 10-1 一般的な構成でのOracle Web Cacheの配置

- 10-2 Oracle Web Cache階層の配置

- 11-1 テンプレート・ページ

- 11-2 ポータル・サイト・ページ

表一覧

- 1-1 他のOracle Fusion Middlewareコンポーネントとの互換性

- 2-1 「Webキャッシュ」メニューのオプション

- 2-2 レスポンスと負荷の統計

- 2-3 CPU使用率およびメモリー使用量の統計

- 2-4 パフォーマンスの統計

- 2-5 オリジン・サーバーの統計

- 2-6 Web Cache Managerのナビゲータ・ペインのオプション

- 2-7 opmnctlユーティリティのコマンド

- 2-8 opmnctlユーティリティのパラメータ

- 2-9 オリジン・サーバーの作成

- 2-10 「サイトの作成」ページ

- 5-1 webcache_setuser.shスクリプトのコマンド

- 6-1 異なるHTTPメソッドの優先順位の例

- 6-2 異なるCookieの値を使用したオブジェクトの複数バージョン

- 6-3 HTTPリクエスト・ヘッダー・フィールド

- 6-4 「キャッシュ・ルール」-「一般」ページ

- 6-5 GLOBALCACHINGRULESのサブ要素

- 6-6 Surrogate-Controlの制御ディレクティブ

- 7-1 INVALIDATIONの要素および属性

- 7-2 INVALIDATIONRESULTの要素および属性

- 7-3 INVALIDATIONPREVIEWの属性

- 7-4 INVALIDATIONPREVIEWRESULTの要素および属性

- 7-5 Oracle-WebCache-Invalidateの制御ディレクティブ

- 7-6 Webサイトの定義

- 8-1 Serverの制御ディレクティブ

- 8-2 構成統計

- 9-1 ODL Textのメッセージ・フィールド

- 9-2 ODL XMLのメッセージ・フィールド

- 9-3 Oracle Web Cacheのメッセージ・フィールド

- 9-4 リクエスト詳細

- 9-5 アクセス・ログのフィールド

- 9-6 HTTP/1.1ヘッダー・フィールドの例

- 9-7 サポートされるCookie関連ヘッダー・フィールド

- 9-8 サポートされるOracle Web Cacheヘッダー・フィールド

- 9-9 冗長レベル

- 9-10 時間別のロールオーバーの構成

- 9-11 時間別のロールオーバーの構成

- 11-1 ESIタグのサマリー

- 11-2 ESI言語の機能

- 11-3 ESIでサポートされているHTTPリクエスト変数

- 12-1 サード・パーティのWebアプリケーション・サーバーのデフォルトのリスニング・ポート

Oracle® Fusion Middleware

Oracle Web Cache管理者ガイド

11g リリース1(11.1.1)

B56248-02(原本部品番号:E10143-04)

2011年1月

Oracle Fusion Middleware Oracle Web Cache管理者ガイド, 11g リリース1(11.1.1)

B56248-02

Copyright (C) 2011, Oracle and/or its affiliates.All rights reserved.

原本著者 : Deborah Steiner

原本協力者:  Rick Anderson, Fang Chen, Joseph Errede, Patrick Fry, Hideaki Hayashi, Kurt Heiss, Suresh Kotha, Gary Ling, Rabah Mediouni, Mohamed Sharfudeen, Raymond Pfau, Michael Skarpelos, Parthiban Thilager, Bill Wright, Zhong Xu, Rama Vijjapurapu, Jean Zeng, Naveen Zulpuri

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』では、Oracle Web Cacheを使用して、1つ以上のオリジン・サーバーに対して静的および動的に生成されたコンテンツをキャッシュする方法について説明します。

対象読者

『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』は、次の作業を実行するWebサイト管理者を対象としています。

- Webサイトの管理

- オリジン・サーバーの管理

- ドメイン・ネーム・システム(DNS)の管理

- セキュリティの管理

このマニュアルを使用するには、HTTPプロトコルのリリース1.0および1.1の知識に加えて、アプリケーション・サーバーとDNS管理の知識も必要です。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧のみを行に記述する必要があります。しかし、一部のスクリーン・リーダーは括弧のみの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

Oracleカスタマは、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlまたはhttp://www.oracle.com/accessibility/support.html(聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware 2日で管理者ガイド』

- Oracle Fusion Middleware管理者ガイド

- 『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』

- 『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このマニュアルでの新しい情報

この章では、このマニュアルで説明するOracle Web Cacheの新たな管理機能と変更された管理機能を紹介し、詳細情報の参照先を示します。

リリース11gの新機能

11g リリース(11.1.1)には多数の新機能が搭載されています。

- リクエスト・フィルタリング: Oracle Web Cacheでリクエスト・フィルタを構成し、受信リクエストに対し、リクエストの特定の属性に基づいてアクションを実行することができます。受信リクエストは、Oracle Web Cacheで処理される前に、指定のサイトに対して構成されているリクエスト・フィルタを通過する必要があります。リクエスト・フィルタを構成することで、悪意のあるコードによるソフトウェアの脆弱性への攻撃を回避できます。詳細は、第4章「リクエスト・フィルタリングの構成」を参照してください。

- キャッシュ・ルール用のMIMEタイプの一致条件: URL式に基づいた受信リクエストとキャッシュ・ルールの一致条件の指定に加え、オブジェクトのContent-Typeレスポンス・ヘッダーの値に基づく一致評価を行えます。この機能は、キャッシュ・ルールの定義を簡素化し、キャッシュ・ルールの総数を減らして、Oracle Web Cacheのパフォーマンスを向上させます。詳細は、第6.4項および第6.8.1項を参照してください。

- レスポンス・ヘッダーを使用した無効化: オリジン・サーバーで、HTTPレスポンス・ヘッダーを介してキャッシュされたコンテンツを無効化することができます。詳細は、7.4項を参照してください。

- リクエストベースのロギング: Oracle Web Cacheは、すべてのリクエストを内部に格納し、それをリクエスト後にまとめてイベント・ログに書き込みます。このようにして、Oracle Web Cacheはすべてのリクエストをグループ化します。詳細は、第9.1項を参照してください。

- イベント・ログのOracle Diagnostic Logging(ODL)形式: Oracle Web Cacheは、すべての診断メッセージとログ・ファイルの共通形式であるODL形式をサポートします。詳細は、9.1項を参照してください。

- 監査ロギング: Oracle Web Cacheでは、Oracle Fusion Middlewareコンポーネント全体の監査を管理する統一したシステムを提供するために、共通監査フレームワークをサポートしています。Oracle Web Cacheの各プロセスで生成される監査ログ・ファイルには、セキュリティ・パフォーマンスおよび構成上の問題を特定して診断する際に役立つ重要な情報が記録されます。詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。

- セキュアなキャッシング: Oracle Web Cacheは、Oracle Single Sign-On認証によって保護され、ほかに認可要件がないコンテンツのキャッシュをサポートするように構成できます。詳細は、5.8項を参照してください。

第I部

セキュアなプロキシ・キャッシュおよびロード・バランシングについて

このパートでは、Oracle Web Cacheの概要および概念について説明します。第I部の内容は次のとおりです。

- 第1章「リバース・プロキシについて」

1 リバース・プロキシについて

この章では、Oracle Web Cacheの概要、およびセキュアなリバース・プロキシを提供する際のOracle Web Cacheの役割について説明します。

この章の項目は次のとおりです。

- 第1.1項「Web層について」

- 第1.2項「Web層でのリクエスト・フロー」

- 第1.3項「Oracle Fusion Middlewareコンポーネントとの互換性」

1.1 Web層について

J2EEアプリケーション・サーバーのWeb層は、主にHTTPリクエストおよびレスポンスの形式で、Webブラウザなどのエンド・ユーザーと対話する役割を果たします。これは、HTTPスタックの最も外側にあり、エンド・ユーザーに最も近い層です。大局的に見ると、Web層は次の4つの基本タスクを実行します。

- クライアント・リクエストを解析

- 解析したリクエストを、ビジネス・ロジックをカプセル化するオブジェクト(エンタープライズJava Beanなど)に伝達

- 次に表示するビューを選択

- 次のビューを生成して配信

Web層は各受信HTTPリクエストを受信し、リクエストされたビジネス・ロジック操作をアプリケーション内で起動します。操作の結果とモデルの状態に基づいて、次に表示するビューが選択されます。選択されたビューは、クライアントに送信されて表示されます。

Oracle Web Cacheは、Web層で使用されるコンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)で、Oracle HTTP ServerやOracle WebLogic Serverなど任意のWebサーバーまたはアプリケーション・サーバーで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。

Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュ機能は、頻繁にアクセスされるURLをメモリーに格納することによって、Oracle Fusion Middlewareで稼動するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。

Oracle Web Cacheでは、頻繁にアクセスされるURLをメモリーに格納することにより、Webアプリケーション・サーバーおよびデータベース層でそれらのURLに対するリクエストを繰り返し処理する必要がなくなります。静的オブジェクトのみ処理する従来のプロキシとは異なり、Oracle Web Cacheでは、1つ以上のWebアプリケーション・サーバーで静的および動的に生成されたコンテンツをキャッシュします。Oracle Web Cacheでは従来のプロキシより大量のコンテンツをキャッシュできるので、Webアプリケーション・サーバーおよびデータベース層の負荷が大幅に軽減され、最適なパフォーマンスを実現できます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で稼働するオブジェクト・キャッシュよりはるかに高速です。

Web CacheはHTTP 1.0および1.1仕様に完全に準拠しているので、Apache TomcatやMicrosoft IISなどの標準WebサーバーによってホスティングされるWebサイトを高速化できます。Oracle Fusion Middlewareでは、Oracle Web CacheはOracle HTTP Serverの1つ以上のインスタンスの前面に配置されます。ブラウザ・ベースのHTTPリクエストに対するレスポンスは、Oracle HTTP Serverインスタンスに転送され、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスは、標準のHTTPプロトコルを使用して送信されるすべてのWebコンテンツを処理できます。

1.1.1 リバース・プロキシ

Oracle Web Cacheは、Oracle HTTP Serverなどのオリジン・サーバーへのリバース・プロキシとして構成できます。

リバース・プロキシは、クライアントからはコンテンツ・サーバーのように見えますが、内部的にはプロキシとして他のバックエンド・オリジン・サーバーからオブジェクトを取得します。リバース・プロキシは、オリジン・サーバーへのゲートウェイとして機能します。ファイアウォールの外側から受信したリクエストをファイアウォールの内側にあるオリジン・サーバーに中継し、取得したコンテンツをクライアントに送信します。

図1-1に、リバース・プロキシWebキャッシュの仕組みの概要を示します。Oracle Web CacheのIPアドレスは144.25.190.241で、Webアプリケーション・サーバーのIPアドレスは144.25.190.242です。

次に、ブラウザとOracle Web Cacheの対話処理ステップを示します。

1. ブラウザが、www.company.com:80というWebサイトにリクエストを送信します。
このリクエストにより、そのWebサイトのIPアドレスのドメイン・ネーム・システム(DNS)へのリクエストが生成されます。

2. DNSサーバーは、そのサイトに対するロード・バランサのIPアドレスである144.25.190.240を返します。

3. ブラウザは、Webページのリクエストをロード・バランサに送信します。次に、ロード・バランサはリクエストをOracle Web Cacheサーバー(144.25.190.241)に送信します。

4. リクエストされたコンテンツがキャッシュに入っている場合、Oracle Web Cacheはそのコンテンツを直接ブラウザに送信します。これはキャッシュ・ヒットと呼ばれます。

5. リクエストされたコンテンツがOracle Web Cacheに存在しない場合、またはコンテンツが失効しているか無効になっている場合、リクエストはWebアプリケーション・サーバー(144.25.190.242)に渡されます。これはキャッシュ・ミスと呼ばれます。

6. Webアプリケーション・サーバーは、コンテンツをOracle Web Cacheに送信します。

7. Oracle Web Cacheは、コンテンツをクライアントに送信し、そのページのコピーをキャッシュに保存します。
キャッシュに格納されたページは、無効になるか期限切れになると削除されます。

図1-1 Webサーバー処理の高速化

「図1-1 Webサーバー処理の高速化」の説明

1.2 Web層でのリクエスト・フロー

図1-2に、Web層でのリクエスト・フローの詳細を示します。

図1-2 Web層でのOracle Web Cacheへのリクエスト・フロー

「図1-2 Web層でのOracle Web Cacheへのリクエスト・フロー」の説明

図1-2に示すように、Web層内では次の処理が行われます。

1. 受信したブラウザ・リクエストが正しいHTTPフォーマットかどうかが分析されます。

2. ブラウザ・リクエストがさらに分析されて、HTTPSフォーマットかどうかが判断されます。

1. ブラウザ・リクエストがHTTPSフォーマットである場合は、SSL復号化が実行されます。

2. ブラウザ・リクエストがHTTPSフォーマットでない場合は、リクエストが解析されます。

3. リクエストが識別されたら、指定された一連のフィルタリング・ルールによってそのリクエストがフィルタ処理されます。

4. キャッシュ・ルックアップが実行されて、そのHTTPリクエストが以前に送信されてキャッシュ内に存在しているかどうかが確認されます。
リクエストがキャッシュ内に存在している場合(キャッシュ・ヒット)、リクエストは圧縮され、コンテンツが直接ブラウザに送信されます。

リクエストがキャッシュ内に存在していない場合(キャッシュ・ミス)、次のいずれかの処理が行われます。

1. リクエストが単一のオリジン・サーバーへ直接送信されます。

2. リクエストがロード・バランシングされた複数のオリジン・サーバーへ送信されます。

ロード・バランシングされた各オリジン・サーバーは、キャッシュの状態をチェックするために、各Oracle Web Cacheサーバーを定期的にpingします。ロード・バランサは、キャッシュ・クラスタ・メンバーにすべての受信リクエストを分散します。リクエストされたコンテンツがOracle Web Cacheに存在しない場合、またはコンテンツが失効しているか無効になっている場合、リクエストはWebアプリケーション・サーバーに渡されます。Webアプリケーション・サーバーは、コンテンツをOracle Web Cacheに送信します。Oracle Web Cacheは、コンテンツをクライアントに送信し、そのページのコピーをキャッシュに保存します。

プロキシ・サーバーは、非武装地帯(DMZ)という比較的セキュアでないゾーンにオリジン・サーバーのかわりに配置されます。

キャッシュ・ルールによって、キャッシュするオブジェクトが決定されます。特定のURLに対してキャッシュ・ルールを設定する場合、クライアントによってそのURL内のオブジェクトがリクエストされるまで、そのオブジェクトはキャッシュに格納されません。クライアントが最初にオブジェクトをリクエストすると、Oracle Web Cacheはそのリクエストをオリジン・サーバーに送信します。このリクエストはキャッシュ・ミスになります。このURLにはキャッシュ・ルールが関連付けられているため、Oracle Web Cacheは後続のリクエストのためにそのオブジェクトをキャッシュに格納します。Oracle Web Cacheは、同じオブジェクトに対して2度目のリクエストを受けると、そのオブジェクトをキャッシュからクライアントに送信します。このリクエストはキャッシュ・ヒットになります。

Oracle Web Cacheを停止すると、キャッシュのすべてのオブジェクトが削除されます。さらに、Oracle Web Cacheによって統計もリセットされます。

1.2.1 HTTP通信の管理

Oracle Web Cacheは、ファイアウォールの内側および外側に配置することができます。Oracle Web Cacheをファイアウォールの内側に配置すると、HTTP通信はDMZに入りますが、データベースと直接対話処理を行うのはWebアプリケーション・サーバーからの許可された通信のみであることが保証されます。Oracle Web Cacheをファイアウォールの外側に配置すると、スループットの負荷は、ファイアウォールではなくOracle Web Cacheにかかります。ファイアウォールは、Webアプリケーション・サーバーへのリクエストのみ受信します。このトポロジの場合、Oracle Web Cacheを侵入者から保護する必要があります。

セキュリティの専門家の間では、キャッシュをDMZの外に配置してよいかどうか、意見が分かれています。オラクル社では、Oracle Web CacheをDMZの外側に配置する前に、御社の企業方針を確認することをお薦めします。

1.2.2 リクエストのフィルタリングとルーティング

リクエスト・フィルタリングでは、正規化されたリクエスト(ほとんどのフィルタ・タイプ)またはオリジナルの正規化されていないRAWリクエスト(NULLバイト、厳密なエンコーディング、ダブル・エンコーディングの各フォーマット・フィルタ・ルール)がチェックされます。ルールに一致し、それが拒否ルールである場合、リクエストは拒否されます。許可ルールに一致した場合、リクエストは許可されます。拒否ルールの場合は、ルールが監視のみのモードであれば、リクエストはログ(監査ログとイベント・ログ)に記録されますが拒否されません。

リクエスト・フィルタリングの詳細は、第4章「リクエスト・フィルタリングの構成」を参照してください。

1.2.3 オリジン・サーバーのロード・バランシングとフェイルオーバー

オリジン・サーバーのロード・バランシングは、1つのオリジン・サーバーの負荷が過大にならないように、HTTPリクエストを複数のオリジン・サーバー間に分散する機能です。

Oracle Web Cacheは、Webアプリケーション・サーバーに対してロード・バランシングとフェイルオーバー検出をサポートしています。

Oracle Web Cacheにより、キャッシュ・ミスは、サーバー・ファーム内で最も可用性が高く、最もパフォーマンスが優れたWebサーバーに転送されます。また、容量ヒューリスティックにより、Webアプリケーション・サーバーの負荷増大時のパフォーマンスが保証され、急激な過負荷の回避が可能です。

ロード・バランシングとフェイルオーバーの詳細は、第3.1項を参照してください。

1.2.4 キャッシュ機能

キャッシュ機能は、頻繁にアクセスされるURLをメモリーに格納することによって、Oracle Fusion Middlewareで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。これによりOracle Web Cacheでは、Webアプリケーション・サーバーおよびデータベース層でそれらのURLに対するリクエストを繰り返し処理する必要がなくなります。静的オブジェクトのみ処理する従来のプロキシとは異なり、Oracle Web Cacheでは、1つ以上のWebアプリケーション・サーバーで静的および動的に生成されたコンテンツをキャッシュします。Oracle Web Cacheでは従来のプロキシより大量のコンテンツをキャッシュできるので、Webアプリケーション・サーバーおよびデータベース層の負荷が大幅に軽減され、最適なパフォーマンスを実現できます。Oracle Web Cacheは外部キャッシュであるため、アプリケーション層内で稼働するオブジェクト・キャッシュよりはるかに高速です。

Oracle Web CacheはWebアプリケーション・サーバーの前面に配置され、コンテンツをキャッシュし、そのコンテンツをリクエスト元のクライアントに提供します。WebブラウザがWebサイトにアクセスすると、HTTPプロトコルまたはHTTPSプロトコル・リクエストがOracle Web Cacheに送信されます。Oracle Web Cacheは、Webアプリケーション・サーバーのかわりに仮想サーバーとして機能します。リクエストされたコンテンツが変更されている場合、Oracle Web CacheはWebアプリケーション・サーバーから新しいコンテンツを取得します。Webアプリケーション・サーバーでは、Oracleデータベースからコンテンツを取得することも可能です。Oracle Web Cacheは、コンピュータの専用の層に配置することも、Webアプリケーション・サーバーと同じコンピュータに配置することもできます。

Webキャッシュを使用すると、Webベースのアプリケーションには次のような利点があります。

- パフォーマンス: 安価なハードウェアで稼働し、キャッシュと圧縮を組み合せることにより、Webサイトのスループットを大幅に改善できます。さらに、Oracle Web Cacheでは、メモリーへオブジェクトを格納することにより、またGZIPエンコード方式をサポートしているクライアントに圧縮されたオブジェクトを送信することにより、クライアント・リクエストへのレスポンス時間を大幅に削減します。圧縮の詳細は、第1.2.5項を参照してください。

- スケーラビリティ: Oracle Web Cacheでは、優れたスループットに加え、大量の同時クライアント接続を維持することが可能です。これにより、サイトにアクセスするユーザーは、負荷のピーク時でもWebアプリケーション・サーバーのエラーに遭遇する可能性が低くなります。

- 高可用性: Oracle Web Cacheは、Webアプリケーション・サーバーに対してロード・バランシングとフェイルオーバー検出をサポートしています。これらの機能により、キャッシュ・ミスは、サーバー・ファーム内で最も可用性が高く、最もパフォーマンスが優れたWebサーバーに転送されます。さらに、特許出願中の容量ヒューリスティックにより、Webアプリケーション・サーバーの負荷増大時のパフォーマンスが保証され、急激な過負荷の回避が可能です。

- コストの削減: パフォーマンス、スケーラビリティおよび可用性の向上は、Webサイト運営者にとってコストの削減につながります。トラフィックの急増やDoS攻撃に対処する必要のあるWebアプリケーション・サーバー数を抑えることができるため、Oracle Web Cacheは、Webサイトのリクエスト当たりのコストを削減する簡単で安価な手段を提供します。

- 開発者の生産性: アプリケーション開発者は、Oracle Web Cacheを使用することで、アプリケーション専用のキャッシュを設計および開発せずにコンテンツをキャッシュできます。

キャッシュの詳細は、第6章「コンテンツのキャッシュと圧縮」を参照してください。

1.2.5 圧縮

Oracle Web Cacheでは、キャッシュ可能およびキャッシュ不可の両方のオブジェクトを圧縮できます。圧縮設定は、Oracle Enterprise Manager Fusion Middleware Control、またはSurrogate-Controlレスポンス・ヘッダー・フィールドのcompress制御ディレクティブを使用して指定できます。Oracle Web Cacheでは、サイト・レベルとキャッシュ・ルール・レベルの両方で圧縮方法を構成できます。サイト・レベルで圧縮を有効にした場合は、そのサイトに対して自動的に圧縮が実行されます。キャッシュ・ルールを個別に構成すれば、圧縮設定をさらに細かく調整できます。

Oracle Web Cacheでは、様々なタイプのコンテンツおよび様々なタイプのブラウザの圧縮が正しく処理されます。これにより、HTML、Javascriptまたはカスケード・スタイル・シート(CSS)など、圧縮可能な一般的なコンテンツ・タイプを自動的に圧縮できます。圧縮によってブラウザでアプリケーションが中断される場合や利益が得られない場合、圧縮は自動的に無効化されます。このようなファイル・タイプとして、GIF、JPEG、PNGイメージ、またはWinZipやGZIPなどのユーティリティを使用して圧縮されたファイルがあります。同様に、Netscape 4ブラウザおよびInternet Explorer 5.5ブラウザの一部のファイル・タイプでは、これらのブラウザの既知の不具合により圧縮は無効化されます。

圧縮されたオブジェクトは小さいため、ブラウザへの配信が速くなり、ラウンドトリップが減少し、全体的な待機時間が短くなります。圧縮されたコンテンツは、Accept-Encodingリクエスト・ヘッダー・フィールドでGZIP圧縮がサポートされているブラウザによって圧縮解除されます。

Oracle Web Cacheでは、テキスト・ファイルを平均して4分の1に圧縮できます。たとえば、300KBのファイルは、75KBに圧縮されます。

圧縮の詳細は、次を参照してください。

- サイト・レベルでの圧縮の構成方法は、第2.11.3項を参照してください。

- すべてのリクエストに対して圧縮を無効化する方法については、第2.11.3.1項を参照してください。

- 個別のキャッシュ・ルールに対する圧縮の構成方法は、第6.8.1項を参照してください。

- Surrogate-Controlレスポンス・ヘッダー・フィールドの構成方法については、第6.10項を参照してください。

1.2.6 セッション・バインディング

Oracle Web Cacheでは、セッションIDまたはセッションCookieを使用してユーザー・セッションを特定のオリジン・サーバーにバインドし、一定期間、状態を維持できるようにする機能を持つサイトをサポートしています。セッション・バインディング機能を使用するには、オリジン・サーバー自体が状態を維持する(ステートフルである)必要があります。ユーザー・セッションをバインドするために、サイトでは、クライアントに送信するHTTPヘッダーまたはボディにセッション・データを含めることにより、クライアントの後続のリクエストにそのデータを強制的に含めて送信するようにします。このデータは、埋込みURLパラメータまたはCookie(クライアントに送信され、格納されるテキスト文字列)のいずれかによってOracle Web Cacheを介してオリジン・サーバーとクライアント間で転送されます。Oracle Web Cacheは、パラメータまたはCookieの値を処理せず、単にオリジン・サーバーとクライアント間で情報をやり取りします。

セッション・バインディングの詳細は、第3.2項を参照してください。

注意:
オリジン・サーバーが高負荷のためにそれ以上接続を受け入れることができない場合、Oracle Web Cacheはそのオリジン・サーバーへのセッションのバインドを無効にし、別のオリジン・サーバーに接続しようとします。

1.3 Oracle Fusion Middlewareコンポーネントとの互換性

表1-1では、その他のOracle Fusion MiddlewareコンポーネントとOracle Web Cacheとの互換性について説明します。包括的なリストではありません。

表1-1 他のOracle Fusion Middlewareコンポーネントとの互換性

コンポーネント

説明

Oracle HTTP Server

Oracle Fusion Middlewareでは、Oracle Web CacheはOracle HTTP Serverの1つ以上のインスタンスの前面に配置されます。ブラウザ・ベースのHTTPリクエストに対するレスポンスは、Oracle HTTP Serverインスタンスに転送され、Oracle Web Cacheを介して送信されます。Oracle Web Cacheインスタンスは、標準のHTTPプロトコルを使用して送信されるすべてのWebコンテンツを処理できます。

関連項目: Oracle Fusion Middleware Oracle HTTP Server管理者ガイド

Oracle Business Intelligence Discoverer

Oracle BI Discovererは、Discoverer Viewer全体のスケーラビリティ、パフォーマンスおよび可用性を改善するために、Oracle Web Cacheと密接に統合されています。Oracle BI Discovererは、ESIのSurrogate-Controlヘッダーを使用して、他の未構成のレスポンスがキャッシュ可能かどうかを決定します。この統合により、Oracle BI Discovererデプロイメント内の中間層サーバーおよびデータベース・サーバーの負荷が軽減され、より多くのDiscoverer Viewerユーザーがシステムに同時にアクセスすることが可能になり、またこれらのユーザーのワークブック操作時および一般的なビジネス・インテリジェンス問合せ時のレスポンス時間が大幅に短縮されます。

関連項目: Oracle Business Intelligence Discoverer構成ガイド

Oracle Forms Services

Oracle Web CacheをOracle Forms Servicesアプリケーションのロード・バランサとして配置できます。

関連項目: Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド

Oracle Portal

Oracle Portalの全般的なスケーラビリティ、パフォーマンスおよび可用性を改善するために、Oracle Web CacheはOracle Portalと緊密に統合されています。Oracle Portalには事前定義された複数のキャッシング・ポリシーおよび無効化ポリシーが用意されており、Oracle Web Cacheを最適な状態で使用できるようになっています。Oracle Web CacheのコントロールはOracle Portalの管理ユーザー・インタフェースに組み込まれており、コンテンツ・プロバイダがPortal Developer Kit(PDK)によって指定することもできます。

関連項目: Oracle Fusion Middleware Oracle Portal管理者ガイド

第II部

基本的な管理

このパートでは、Oracle Web Cacheの基本的な管理作業の実施方法を説明します。次の章が含まれます:

- 第2章「Oracle Web Cacheの管理の概要」

- 第3章「高可用性ソリューションの構成」

- 第4章「リクエスト・フィルタリングの構成」

- 第5章「セキュリティの構成」

- 第6章「コンテンツのキャッシュと圧縮」

- 第7章「コンテンツの無効化」

- 第8章「診断機能の使用方法」

- 第9章「ロギング」

2 Oracle Web Cacheの管理の概要

この章では、Oracle Web Cacheの管理を開始する方法について説明します。また、主要な管理作業について説明します。

この章の項目は次のとおりです。

- 第2.1項「Oracle Web Cacheの管理ツールについて」

- 第2.2項「サイトの構成について」

- 第2.3項「Oracle Web Cache管理でのリソース制限について」

- 第2.4項「Oracle Web Cacheポートについて」

- 第2.5項「IPアドレスについて」

- 第2.6項「Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Web Cacheの管理の概要」

- 第2.7項「Oracle Web Cache Managerを使用したOracle Web Cacheの管理の概要」

- 第2.8項「Oracle Process Manager and Notification(OPMN)を使用したOracle Web Cacheの管理の概要」

- 第2.9項「Oracle Web Cacheを構成および管理するための基本的な作業」

- 第2.10項「環境へのOracle Web Cacheシステム・コンポーネントの追加」

- 第2.11項「Oracle Web Cacheシステム・コンポーネントのプロパティの指定」

- 第2.12項「セッション定義の作成」

- 第2.13項「Oracle Web Cacheの起動と停止」

2.1 Oracle Web Cacheの管理ツールについて

Oracle Web Cacheの構成は、次のディレクトリ内にあるwebcache.xmlファイルに保存されます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

Oracle Web Cacheの管理には、次の2つのツールが提供されています。

- Oracle Enterprise Manager Fusion Middleware Control。第2.6項を参照してください。

- Oracle Web Cache Manager。第2.7項を参照してください。

特別な手順でファイルの編集が必要となる場合を除き、どの管理作業を実行する場合も、webcache.xml構成ファイルを編集するのではなく、上記のツールを使用してください。ファイルを編集すると一貫性が失われ、問題が発生する可能性があります。

2.2 サイトの構成について

Oracle Web Cacheでは、1つ以上のWebサイトの動的コンテンツのキャッシュおよび組立てを行います。Oracle Web Cacheについて次のプロパティを構成する場合は、そのプロパティをすべてのサイトまたは特定のサイトに適用します。

- セッション

- セキュリティ

- リクエスト・フィルタリング

- キャッシュ・ルール

- アクセス・ロギング

名前の付いたすべてのサイトに対して、サイト定義を作成する必要があります。サイト定義は、サイトとサイトの別名に関するホスト名、ポート情報および任意のURLパス接頭辞で構成されます。サイトの多くは1つ以上の別名で表されるため、別名情報は重要です。Oracle Web Cacheでは、サイトとその別名に対するリクエストを認識してキャッシュします。たとえば、www.company.com:80というサイトにcompany.com:80という別名があるとします。この別名を指定すると、Oracle Web Cacheは、company.com:80またはwww.company.com:80から同じコンテンツを取得してキャッシュします。

名前付きサイトを構成する場合、Oracle Web Cacheがサイトで自動圧縮を実行できるように、サイトに対して圧縮を有効にできます。未定義のサイトに対しても圧縮を構成できます。Oracle Web Cacheでは、定義済サイトと一致しないクライアント・リクエストに対して、未定義のサイトの圧縮設定を使用します。すべてのリクエストに対して圧縮を無効にする場合は、第2.11.3.1項を参照してください。

名前付きサイトと未定義のサイトの構成の他に、Oracle Web Cacheではホスト情報のないクライアント・リクエストのデフォルト・サイトも構成できます。Oracle Web Cacheをインストールする際、デフォルト・サイトではOracle HTTP Serverがインストールされていたコンピュータのホスト名とリスニング・ポートが使用されます。

Oracle Web Cacheは、リクエストをまずサイト定義に解決した後に、サイトからオリジン・サーバーへのマッピングのうち最初に一致したものに解決するので、サイト定義を構成する順序は重要です。

たとえば、サイト定義が次の順序で構成されているとします。

www.company.com:80
www.company.com:80/sales

www.company.com:80はwww.company.com:80/salesのスーパーセットであるため、Oracle Web Cacheは、www.company.com:80/salesに対するリクエストを、www.company.com:80/salesではなくサイト定義www.company.com:80と照合します。さらに、Oracle Web Cacheはwww.company.com:80に対するサイトからサーバーへのマッピングを使用します。

この問題を回避するには、サイト定義を次の順序で構成します。

www.company.com:80/sales
www.company.com:80

サイト定義を作成したら、サイトからオリジン・サーバーへの順序付けされたマッピングを作成します。リクエストが誤ったサイトにマップされないように、これらのマッピングの順序の付け方には注意する必要があります。

- ワイルド・カード(*)を使用するマッピングは広い有効範囲を持つため、このようなマッピングには他のマッピングよりも低い優先順位を割り当ててください。

- リクエストは最初に一致したマッピングに解決されるため、任意のURLパス接頭辞のあるマッピングには、URLパス接頭辞がないマッピングよりも高い優先順位を割り当ててください。
たとえば、次のマッピングを次のようにして並べます。

http://www.company.com/portal/page?_pageid=33,4232&_dad=portal

http://www.company.com/um/traffic_cop?mailid=inbox
http://www.company.com

かわりにマッピングを次のように並べ換えると、URL http://www.company.com/portal/page?_pageid=33,4232&_dad=portalおよびhttp://www.company.com/um/traffic_cop?mailid=inboxに対するリクエストは予想どおりには解決されません。かわりにこれらのURLのリクエストは、最初にリストされているhttp://www.company.comに解決されます。

http://www.company.com
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox

サイト定義およびサイトからサーバーへのマッピングの作成方法は、第2.11.3項と第2.11.4項を参照してください。

2.3 Oracle Web Cache管理でのリソース制限について

構成の一環として、Oracle Web Cacheが効率的に実行されるように、キャッシュおよびネットワークのしきい値を指定します。

Oracle Web Cacheでは次のタイプのしきい値を構成できます

- 第2.3.1項「最大キャッシュ・サイズ」

- 第2.3.2項「最大着信接続数」

- 第2.3.3項「キャッシュされたオブジェクトの最大サイズ」

- 第2.3.4項「ネットワーク・タイムアウト」

2.3.1 最大キャッシュ・サイズ

最大キャッシュ・メモリーの限界に達すると、Oracle Web Cacheによって、ガベージ・コレクションが実行されます。ガベージ・コレクションでは、Oracle Web Cacheによって使用頻度と妥当性に基づいて、失効しているオブジェクトが削除されます。キャッシュ・クラスタ環境では、オンデマンド・オブジェクトが削除された後に、Oracle Web Cacheにより所有オブジェクトが削除されます。

キャッシュ内のオブジェクトの入れ替えを回避するため、キャッシュに十分なメモリーを構成することが重要です。通常、Oracle Web Cacheのメモリー量(キャッシュの最大サイズ)は、512MB以上に設定する必要があります。

アプリケーションのメモリー要件は、オブジェクト・サイズ、オブジェクト数、戻されるHTTPヘッダー数、およびESIがあるかどうかなどの要素によって異なります。必要な最大メモリー量を正確に把握するには、次の計算式を使用します。

通常はデフォルト設定(500MB)のままで問題ありません。デフォルト設定を変更する場合は、次の手順に従って必要な最大メモリー量を調べます。

1. 必要な最大メモリー量の推定値(バイト)を求めるには、次の計算式を使用します。

1.25*(TotalDocs * ((AvgDocSize/8192+1) *8192 + 16384))

この計算式の詳細は、次のとおりです。

- .25は、実行時メモリーのオーバーヘッドです。

- TotalDocsは、キャッシュに格納するオブジェクト数の合計です。

- AvgDocSizeは、キャッシュに格納するオブジェクトの平均サイズ(バイト)です。平均サイズは、「パフォーマンス・サマリー」ページの次のメトリックを参照して算出できます。

- 「各サイトのパフォーマンスおよびサマリー」→「サイト」→「キャッシュ・サイズ」

- 「各サイトのパフォーマンスおよびサマリー」→「サイト」→「キャッシュ数」

「パフォーマンス・サマリー」ページの詳細は、第8.4項を参照してください。

注意:
特定のオブジェクトをキャッシュするよう指定しても、すべてのオブジェクトが同時にキャッシュされるわけではありません。リクエストされ、有効なオブジェクトのみキャッシュに格納されます。したがって、任意の時点においては一部のオブジェクトしかキャッシュに格納されません。つまり、前述の計算式で算出された最大メモリー量が必要ではない場合があります。

2. 結果をメガバイトに変換します。

3. Oracle Web Cache構成でのメモリーの推定値を指定します。第2.11.5項を参照してください。

4. シミュレートされたロードまたは実際のロードを使用してキャッシュを監視し、実行時に実際に使用されるメモリーの量を確認してください。
Oracle Web Cacheの起動時には、キャッシュは空です。正しく監視するためには、キャッシュにすべてのドキュメントが格納されていることを確認してください。つまり、該当するオブジェクトのキャッシュに必要なだけのリクエスト数がキャッシュに受信されていることを確認してください。

Fusion Middleware Controlの「パフォーマンス・サマリー」ページに、メモリーの現在の使用状況およびメモリーの最大使用状況に関する情報が表示されます。このページにアクセスするには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「監視」→「パフォーマンス・サマリー」を選択します。

2.3.2 最大着信接続数

キャッシュ・サイズに加え、Oracle Web Cacheサーバーの最大接続数制限に妥当な数を指定することが重要です。デフォルトは500です。設定した数が大きすぎると、パフォーマンスに影響を与え、レスポンス時間が長くなります。小さすぎる数値を設定した場合は、Oracle Web Cacheで同時に処理されるリクエストが少なくなります。レスポンス時間と、同時に処理されるリクエスト数との間で、バランスをとる必要があります。

適切な数値を決定するには、次のような要因を考慮します。

- 任意の時点において同時に処理するクライアントの最大数。

- ページの平均サイズと平均リクエスト数。

- ネットワーク帯域幅。一度に転送できるデータの量はネットワーク帯域幅によって制限されます。

- キャッシュ・ミスの割合。キャッシュ・ミスになるリクエストの割合が多いと、より多くのリクエストはWebアプリケーション・サーバーに転送されます。そのようなリクエストはネットワーク帯域幅を余分に消費するため、レスポンス時間が長くなります。

- ページの処理速度。ttcpまたはLoadRunnerなどのネットワーク監視ユーティリティを使用して、ご使用のシステムがページを処理する速度を調べてください。

- キャッシュ・クラスタ・メンバーの許容量(キャッシュ・クラスタ環境がある場合)。この許容量は、他のキャッシュ・クラスタ・メンバーからの着信接続数を示します。この設定をFusion Middleware Controlで構成するには第3.6.3項、この設定をOracle Web Cache Managerで構成するには第3.7.1項を参照してください。

オペレーティング・システムやOracle Web Cacheで使用できるツールなどの様々なツールを使用すると、接続の最大数の決定に役立ちます。たとえば、UNIXとWindowsオペレーティング・システムのnetstat -aコマンドを使用すると、確立されている接続数を判断できます。ttcpユーティリティを使用すると、ページの処理速度を判断できます。Fusion Middleware Controlの「Webキャッシュ・ホーム」ページおよび「パフォーマンス・サマリー」ページには、ヒットおよびミスに関する統計が表示されます。これらのページにアクセスするには、「Webキャッシュ」メニューから「ホーム」を選択するか、「監視」→「パフォーマンス・サマリー」を選択します。

Oracle Web Cacheでは、各接続に対してリソースが確保されるため、あまり大きな値を設定すると、パフォーマンスに悪影響を与えることがあります。多くのUNIXシステムの場合、通常は5000が適切な値です。

着信接続の最大数を指定する方法は、第2.11.5項を参照してください。

UNIXにおける接続

ほとんどのUNIXプラットフォームでは、クライアント接続ごとに異なるファイル記述子が必要です。Oracle Web Cacheは、起動時にファイル記述子の最大数(Max_File_Desc)を確保しようとします。Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行すると、この数を増やすことができます。たとえば、Sun Solaris上では、rlim_fd_maxパラメータを設定することでファイル記述子の最大数を増やすことができます。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。

ほとんどのUNIXプラットフォームでは、クライアント接続ごとに異なるファイル・ディスクリプタが必要です。Oracle Web Cacheサーバーは、起動時にファイル・ディスクリプタの最大数を確保しようとします。root権限を持っている場合、この数を増やすことができます。たとえば、LINUX Red Hatオペレーティング・システムでは、/etc/security/limits.confでOracle Web Cacheのユーザー・ファイル・ディスクリプタ制限を変更してファイル・ディスクリプタの最大数を増やすことができます。

たとえば、ユーザーWC_USERに4092の接続を許可するには、/etc/security/limits.confファイルに次のエントリを追加します。

WC_User       soft    nofile            4092
WC_User       hard    nofile            4092

/etc/sysctl.conf.で、パラメータfs.file-maxが65kに設定されていることを確認してください。Solarisオペレーティング・システムでは、rlim_fd_maxパラメータを設定することでファイル・ディスクリプタの最大数を増やすことができます。webcachedをroot権限で実行しないと、Oracle Web Cacheサーバーはエラー・メッセージを記録して起動に失敗します。

root権限で実行するためにwebcached実行可能ファイルを変更する方法は、第5.9項を参照してください。

詳細は、次を参照してください。

- 接続の制限事項の詳細は、ご使用のオペレーティング・システムに関するドキュメントを参照してください。

- TCP/IPパフォーマンス・チューニングのヒントについては、Oracle Fusion Middlewareパフォーマンス・ガイドを参照してください。

Windowsにおける接続

Windowsオペレーティング・システムの場合、ファイル・ハンドルおよびソケット・ハンドルの数は、使用可能なカーネル・リソース(正確にはページングされたプールおよびページングされていないプールのサイズ)のみによって制限されます。ただし、アクティブなTCP/IP接続数は、システムがオープン可能なTCPポート数によって制限されます。

TCPポートのデフォルトの最大数は、オペレーティング・システムによって5000に設定されています。そのうち、1024がカーネルによって確保されています。ポートの最大数は、Windowsのレジストリを編集して変更可能です。Windowsオペレーティング・システムでは最大65534ポートが使用可能です。

デフォルトの最大数を変更するには、次のレジストリ・キーに新しい値を追加する必要があります。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

次のように指定して、新しい値を追加します。

- 値の名前: MaxUserPort

- 値のタイプ: DWORD

- 値データ: 65534

- 値範囲: 5000から65534

Windowsオペレーティング・システムの場合、Oracle Web Cacheはファイル・ハンドルを確保しようとしたり、現在の最大着信接続数がTCPポートの数より少ないかどうかを確認したりしません。

2.3.3キャッシュ・オブジェクトの最大サイズ

システム・リソースを保護するために、オブジェクトが他のキャッシュ・ルールを満たしている場合でも、キャッシュするオブジェクトのサイズを制限できます。

キャッシュ・オブジェクトの最大サイズを指定すると、指定のサイズ以下で、キャッシュ・ルールに一致するオブジェクトのみをキャッシュに保存します。指定のサイズより大きいオブジェクトは、キャッシュ・ルールに一致していてもキャッシュされません。デフォルトは100KBです。アップグレードされたキャッシュの場合、デフォルトでは、制限は指定されません。

キャッシュ・オブジェクトの最大サイズより大きいオブジェクトがあり、そのオブジェクトが頻繁にリクエストされる場合は、制限サイズを大きくすることを検討してください。この値を0に指定すると、オブジェクトはキャッシュされず、効率的にキャッシュをオフにできます。

1つのキャッシュ・オブジェクトのサイズを指定する方法は、第2.11.5項を参照してください。

2.3.4 ネットワーク・タイムアウト

Oracle Web Cacheでは、次のタイムアウトに対する設定を指定できます。

- Keep-Alive Timeout: キープ・アライブのタイムアウトは、クライアントがOracle Web Cacheからのリクエストを処理するための時間制限です。Oracle Web Cacheがクライアントにレスポンスを送信した後、接続が5秒間開かれたままになります。これは通常、クライアントがOracle Web Cacheからのレスポンスを処理するために十分な時間です。クライアントとOracle Web Cache間のネットワークが低速な場合は、キープ・アライブのタイムアウト値を増やすことを検討してください。

- Client Send: Oracle Web Cacheからクライアントへの送信操作の完了に許容される時間を指定します。

- Client Receive: Oracle Web Cacheがクライアントからの受信操作の完了を待機できる時間を指定します。

- Origin Server Send: Oracle Web Cacheからオリジン・サーバーへの送信操作の完了に許容される時間を指定します。

- Origin Server Receive: オリジン・サーバーによるOracle Web Cacheへのレスポンスの生成および送信の開始に許容される時間を指定します。

- Origin Server Connect: Oracle Web Cacheからオリジン・サーバーへの接続の確立に許容される時間を指定します。オリジン・サーバーに再試行される複数のIPアドレスがある場合(たとえばIPv4とIPv6)、タイムアウト値は1つのオリジン・サーバーのIPアドレスへの接続を制限します。オリジン・サーバーがこの時間内にレスポンスを生成できない場合は、接続が切断され、ネットワーク・エラー・ページがクライアントへ送信されます。アプリケーションが必要とするタイムアウトがより短い場合は、タイムアウトを調整してください。

タイムアウトを指定する方法は、第2.11.5項を参照してください。

2.4 Oracle Web Cacheポートについて

多くのコンポーネントで、プロビジョニングの際にポートが動的に割り当てられます。ポート番号は、手動で変更しないかぎりプロビジョニング後も同じままです。

Oracle Web Cacheでは、HTTPまたはHTTPSリスニング・ポートを使用してリクエストを受信します。Oracle Web Cacheでは、リスニング・ポート以外でも、特定のHTTPまたはHTTPSリスニング・ポートで、管理、無効化および統計監視用のリクエストを受信します。

http://web_cache_hostname:http_port
https://web_cache_hostname:https_port

ポート設定を構成する方法は、第2.11.1項を参照してください。

2.5 IPアドレスについて

Oracle Web Cacheでは、IPバージョン4とバージョン6の両方のアドレスがサポートされます。

次の例は、IPバージョン4のアドレスを示しています。

- 138.1.16.102は、IPアドレスを指定します。

- 138.1.16.102/255.255.0.0は、IPアドレスとサブネット・マスク、138.1.any.anyを指定します。マスク内の0(ゼロ)は、任意の値が許可されることを意味します。このアドレスは、138.1.0.0/255.255.0.0または138.1.*.*と同等です。

- 138.1.16.102/16は、前述の例の別の指定方法です。これは、上位16ビットのみが重要であることを意味します。

ワイルドカードはフィールド全体に使用する必要があります。138.128.0.0/255.128.0.0などはワイルドカードを使用して指定することはできません。この例では、上位9ビットをチェックする必要があります。138.128*.*.*は使用できません。138.*.*.*は上位8ビットのみをチェックし、他の3つの8ビットのフィールドには任意の値を指定できます。

次の例は、IPバージョン6のアドレスを示しています。

- FE80:0:0:0:205:2FF:FE71:2594は、IPアドレスを指定します。

- FE80:0:0:0:205:0:0:0/FFFF:FFFF:FFFF:FFFF:FFFF:0:0:0は、IPアドレスとサブネット・マスクを指定します。ここでは、上位16*5 = 80ビット(16*5はFFFFの各FFFF * 5フィールドからの16ビット)の一致をチェックする必要があります。ワイルドカードを使用する場合は、FE80:0:0:0:205:*:*:*と同じアドレスを指定できます。

- FE80:0:0:0:205:0:0:0/80は、前述の例の別の指定方法です。これも上位80ビットをチェックするように指定しています。

ワイルドカードはフィールド全体に使用する必要があります。

2.6 Oracle Enterprise Manager Fusion Middleware Controlを使用したOracle Web Cacheの管理の概要

Oracle Enterprise Manager Fusion Middleware Controlでは、Oracle Web Cacheをはじめとするファーム内のOracle Fusion Middlewareコンポーネントを管理することができます。

ファームとは、Fusion Middleware Controlによって管理されるコンポーネントの集まりです。Oracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバーおよびドメインにインストールされ、構成され、稼動しているOracle Fusion Middlewareで構成されます。

Fusion Middleware Controlから、次の構成を行うことができます。

- キャッシュのプロパティ(オリジン・サーバー、サイト、リソース制限、パスワード、セッション、Cookieなど)

- イベント・ロギングおよびアクセス・ロギング

- 複数のキャッシュを1つにまとめたキャッシュ・クラスタ(これにより構成の共有、スケーラビリティ、高可用性を確保)

- 無効または不正なHTTPリクエストをブロックするリクエスト・フィルタリング

- キャッシュ・ルールと有効期限ポリシー

Oracle Web Cache Managerでは、その他の領域を構成することができます。Oracle Web Cache Managerの使用方法の詳細は、第2.7項を参照してください。

Fusion Middleware Controlでは、他にも、パフォーマンス統計を監視したり、キャッシュの起動と停止、キャッシュ・クラスタ・メンバー間の構成の同期などの操作タスクを実行したりすることができます。

この項では、次の項目について説明します。

- 第2.6.1項「Fusion Middleware Controlへのログイン」

- 第2.6.3項「「Webキャッシュ・メンバー」ページ上の統計について」

- 第2.6.4項「Fusion Middleware Controlヘルプの使用」

Fusion Middleware Controlの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

2.6.1 Fusion Middleware Controlへのログイン

Oracle Web Cacheのページを表示するには、次の手順を実行します。

1. Fusion Middleware Controlを表示するには、Fusion Middleware ControlのURLを入力します。これには、ホストの名前と、インストール時にFusion Middleware Controlに割り当てたポート番号が含まれます。URLの形式は次のとおりです。

http://hostname.domain:port/em

ポート番号はOracle WebLogic Serverの管理サーバーの番号です。デフォルトのポート番号は7001です。

2. Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。
管理者ユーザーのデフォルトのユーザー名はweblogicです。パスワードは、Oracle Fusion Middlewareのインストール時に指定したパスワードです。

2.6.2 Oracle Web Cache管理ページへのナビゲート

Oracle Web Cache管理タスクにナビゲートするには:

1. ナビゲータ・ペインで、ファーム、「Web層」インストール・タイプの順に開いて、Oracle Web Cacheコンポーネントを選択します。
図nav.gifの説明

「Webキャッシュ・メンバー」ページが表示されます。このホームページの内容の詳細は、第2.6.3項を参照してください。

2. 「Webキャッシュ」メニューを選択します。
図wc_menu.gifの説明

「Webキャッシュ」メニューに表示されるオプションを表2-1で説明します。

表2-1 「Webキャッシュ」メニューのオプション

要素

説明

ホーム

「Webキャッシュ・メンバー」ページが表示されます。このページの内容の詳細は、第2.6.3項を参照してください。

監視

次のオプションが表示されます。

- パフォーマンス・サマリー: Oracle Web Cacheのパフォーマンス・メトリックを表示できます。詳細は、第8.4項を参照してください。

- ポピュラーなリクエスト: キャッシュ・ルールに従って正しいオブジェクトをキャッシュしているかどうかを確認する最も一般的なリクエストを表示できます。詳細は、第8.6項を参照してください。

コントロール

Oracle Web Cacheを起動、停止、再起動するためのオプションが表示されます。詳細は、第2.13.2項を参照してください。

ログ

「ログ・メッセージの表示」オプションを選択すると、イベント・ログ・ファイルの内容を含む「ログ・メッセージ」ページが表示されます。詳細は、第9.7項を参照してください。

ポートの使用状況

使用中のポートが表示されます。詳細は、第2.11.1項を参照してください。

管理

次のオプションが表示されます。

- キャッシュ・ルール: キャッシュ・ルールを構成できます。詳細は、第6章「コンテンツのキャッシュと圧縮」を参照してください。

- リクエスト・フィルタ: 一般的なHTTPリクエスト攻撃から保護するためのリクエスト・フィルタを構成できます。詳細は、第4章「リクエスト・フィルタリングの構成」を参照してください。

- 有効期限: 有効期限ポリシーを指定できます。詳細は、第6.7項を参照してください。

- サイト: Oracle Web CacheがコンテンツをキャッシュするWebサイトを構成できます。詳細は、第2.11.3項を参照してください。

- オリジン・サーバー: Oracle Web Cacheがキャッシュ・ミスを送信するWebアプリケーション・サーバーまたはプロキシ・サーバーを構成できます。詳細は、第2.11.4項を参照してください。

- クラスタ: キャッシュ・クラスタを構成できます。詳細は、第3.6項を参照してください。

- パスワード: Oracle Web Cacheのセキュリティ・オプションを構成できます。詳細は、第5章「セキュリティの構成」を参照してください。

- アクセス・ログ: Oracle Web Cacheのアクセス・ログの設定を構成できます。詳細は、第9章「ロギング」を参照してください。

- イベント・ログ: Oracle Web Cacheのイベント・ログの設定を構成できます。詳細は、第9章「ロギング」を参照してください。

- リソース制限: Oracle Web Cacheのキャッシュしきい値を構成できます。詳細は、第2.11.5項を参照してください。

- パスワード: Oracle Web Cacheのセキュリティ・オプションを構成できます。詳細は、第5章「セキュリティの構成」を参照してください。

- セッション構成: 次の目的でセッション定義を作成できます。
- キャッシュによるセッション・リクエストの処理方法を指定します。

- セッション・バインディングを有効にして、特定サイトのユーザー・セッションをオリジン・サーバーにバインドし、一定期間、状態を維持できるようにします。

- セッション・エンコードされたURLのセッション情報を置換します。

詳細は、第2.12項を参照してください。

- 複数バージョンのCookie: 複数バージョンのURLのCookieの値を指定できます。詳細は、第6.5.1項を参照してください。

- ポート構成: Oracle Web Cacheのポートを構成できます。詳細は、第2.11.1項を参照してください。

セキュリティ

次のオプションが表示されます。

- 監査ポリシー: 監査ポリシー設定を構成できます。詳細は、Oracle Fusion Middlewareセキュリティ・ガイドを参照してください。

- SSL構成: Oracle Web CacheのSSL構成を指定できます。詳細は、第5.4.2項と第5.4.3項を参照してください。

- ウォレット: ウォレットを作成および管理できます。詳細は、第5.4.1項を参照してください。

一般情報

インスタンスに関する一般情報が表示されます。

2.6.3 「Webキャッシュ・メンバー」ページ上の統計について

「Webキャッシュ・メンバー」ページには、選択したキャッシュ・システム・コンポーネント、およびサポートされているサイトとオリジン・サーバーに関する一般情報が表示されます。

このページは、Oracle Web Cacheを監視および管理するための開始点としても使用できます。図2-1は、「Webキャッシュ・メンバー」ページの一部を示しています。

図2-1 「Webキャッシュ・メンバー」ページ

図2-1 「Webキャッシュ・メンバー」ページの説明

このページには次の統計リージョンが含まれています。

- 「レスポンスと負荷」リージョン

- 「CPU使用率およびメモリー使用量」リージョン

- 「パフォーマンス」リージョン

- 「オリジン・サーバー」リージョン

「レスポンスと負荷」リージョン

表2-2は、「レスポンスと負荷」リージョンのパフォーマンス監視統計とその説明です。

表2-2 レスポンスと負荷の統計

統計

説明

リクエスト処理時間

リクエストの処理に要する平均時間(ミリ秒)です。

リクエスト・スループット

毎秒処理されるリクエストの平均数です。

「CPU使用率およびメモリー使用量」リージョン

表2-3は、「レスポンスと負荷」リージョンのパフォーマンス監視統計とその説明です。

表2-3 CPU使用率およびメモリー使用量の統計

統計

説明

CPU使用率

Oracle Web Cacheに使用されているCPUの割合を示します。トラフィックが増えるにつれて、CPU使用率は増加します。

メモリー使用量

Oracle Web Cacheコンポーネントで使用される合計メモリー容量です。

「パフォーマンス」リージョン

表2-4は、「オリジン・サーバー」リージョンのパフォーマンス監視統計とその説明です。

表2-4 パフォーマンスの統計

統計

説明

オープン接続

Oracle Web Cacheサーバーに対して現在開いている着信接続の数です。

処理されたリクエスト

起動後にOracle Web Cacheで処理されたリクエストの累計数です。

ヒット率

キャッシュ・コンテンツで解決されたリクエストの割合です。

キャッシュされたオブジェクト

キャッシュに格納されたオブジェクトの合計数です。

キャッシュ・サイズ

現在キャッシュに格納されているオブジェクトのサイズ(メガバイト)です。キャッシュ・クラスタ・メンバーの場合、この数値は所有オブジェクトとオンデマンド・オブジェクトの集計になります。

リクエスト・フィルタリングにより拒否されたリクエスト

リクエスト・フィルタで拒否されたリクエストの累計数です。

ゼロ以外の数値は、サイトに攻撃があった可能性、またはリクエスト・フィルタの構成に問題がある可能性を示します。

圧縮による保存バイト

インキャッシュ圧縮が無効な場合にクライアントに送信される累計バイト数です。

処理されたエラー・ページ

起動後にOracle Web Cacheが処理したWebブラウザのエラー・ページの累計数です。

「オリジン・サーバー」リージョン

表2-5は、「オリジン・サーバー」リージョンのパフォーマンス監視統計とその説明です。

表2-5 オリジン・サーバーの統計

統計

説明

サーバー

オリジン・サーバーの名前が表示されます。

現行のステータス

Oracle Web Cacheがオリジン・サーバーとの通信を最後に試行したときのオリジン・サーバーのステータスが表示されます(Oracle Web Cacheは、キャッシュ・ミスに対するレスポンスの取得など、特定の目的でのみオリジン・サーバーへのアクセスを試行します)。

稼働時間(%)

Oracle Web Cacheから見た稼働時間を示します。オリジン・サーバーの稼働時間に近似しています。正確さは、Web Cacheが稼動している時間およびOracle Web Cacheがオリジン・サーバーにリクエストを送信する頻度に基づきます。

リクエスト

このカテゴリには次の統計情報が表示されます。

- 合計: オリジン・サーバーが処理したリクエストの累計数です。

- エラー: Oracle Web Cacheで発生したオリジン・サーバーのエラー数です。次のようなエラーがあります。
- Oracle Web Cacheがオリジン・サーバーへの接続に失敗した。

- リクエストをオリジン・サーバーへ送信する際、またはオリジン・サーバーからレスポンスを受信する際にエラーが発生した。

- オリジン・サーバーからHTTP 500クラスのレスポンスがあった。

- 平均レスポンス時間: オリジン・サーバーが、該当するOracle Web Cacheから受信したリクエストを処理して返信するまでにかかる平均時間です。

容量

このカテゴリには次の統計情報が表示されます。

- 現在のロード: Oracle Web Cacheからオリジン・サーバーが現在開いている接続の数です。

- 最大ロード: オリジン・サーバーが同時に開いている最大接続数です。

- 構成済: 「オリジン・サーバー」ページでサーバーに設定されている容量です。

注意: 「最大ロード」の値が「構成済」の値に近い場合、「オリジン・サーバー」ページで容量を増やします。第2.11.2項を参照してください。

2.6.4 Fusion Middleware Controlヘルプの使用

「ヘルプ」メニューのOracle Enterprise Managerヘルプ・コマンドを使用すると、現在のFusion Middleware Controlページに関係するタスク関連情報や概念情報にアクセスできます。また、ページ要素に関する詳細な説明が必要なページで、「ヘルプ」アイコンをクリックすることもできます。

検索機能も用意されているので、ヘルプを検索したり、オンライン・ヘルプ・システムに組み込まれている特定のOracle Fusion Middlewareマニュアルを検索したりすることができます。ヘルプによって、これらのマニュアルで文脈に依存する特定の情報にアクセスできます。

2.7 Oracle Web Cache Managerを使用したOracle Web Cacheの管理の概要

Oracle Web Cache Managerは、Fusion Middleware Controlにはない次の領域の構成機能を提供するグラフィカル・ユーザー・インタフェース・ツールです。

- 無効化

- リクエスト・フィルタ用の高度なオプション

- Oracle Web Cacheのネットワークしきい値

- 高度なセキュリティ・オプション

- 無効化

- 診断機能

- Oracle Web Cacheによって表示されるエラー・ページ

この項では、Oracle Web Cache Managerの機能について説明します。この項では、次の項目について説明します。

- 第2.7.1項「Oracle Web Cache Managerの起動」

- 第2.7.2項「Oracle Web Cache Managerのナビゲート」

2.7.1 Oracle Web Cache Managerの起動

Oracle Web Cache Managerを起動するには、次の手順を実行します。

1. 監視アカウントを持つOracle Web Cache管理者に対してセキュアなパスワードを構成します。監視アカウント用のパスワードを使用してOracle Web Cache Managerにログインします。セキュアなパスワードの設定方法は、第5.2項を参照してください。

2. 次のコマンドを使用して、adminサーバー・プロセスを起動します。

opmnctl startproc ias-component=WebCache process-type=WebCache-admin

WebCache-adminは、adminサーバー・プロセスを表します。

3. adminサーバー・プロセスのポートを決定します。第2.11.1項を参照してください。

4. ブラウザに、次のURLを入力します。

http://web_cache_hostname:admin_port/webcacheadmin

ポートを決定する方法については、第2.11.1.2項を参照してください。

5. Oracle Web Cache管理者のユーザー名(administrator)およびステップ1で設定したパスワードを入力します。

2.7.2 Oracle Web Cache Managerのナビゲート

Oracle Web Cache Managerのインタフェースは、次の要素で構成されています。

- 「Apply Changes」ボタン、「Cancel Changes」ボタンおよびOracle Web Cacheのステータス・メッセージが含まれているトップ・フレーム

- 構成および監視のメニュー項目が含まれているナビゲータ・フレーム

- 選択されたメニュー項目のプロパティ・シートが含まれている右フレーム

図2-2は、Oracle Web Cache Managerのインタフェースを示しています。

図2-2 Oracle Web Cache Managerのインタフェース

「図2-2 Oracle Web Cache Managerのインタフェース」の説明

インタフェースには次の機能が含まれます。

- 「Home」リンクをクリックすると、「Welcome」ページが表示されます。

- ナビゲータ・ペインには、Oracle Web CacheおよびサポートされているWebサイトの構成、管理、パフォーマンス監視機能がツリー構造で表示されます。

- コンテンツ・ペインには、ナビゲータ・ペインで選択したオプションのプロパティ・シートが表示されます。

- 「Apply Changes」ボタンにより、Oracle Web Cacheに送信された静的および動的な構成の変更が適用されます。「Cancel Changes」ボタンにより、Oracle Web Cacheに送信された静的および動的な構成の変更が取り消されます。

- ステータス・メッセージには、次のようなステータス・メッセージが表示されます。

- Web Cache running with current configuration: このメッセージは、Oracle Web Cacheが最新の構成で稼動している場合に表示されます。

- Web Cache running in Routing Only mode with current configuration: このメッセージは、Oracle Web Cacheが最新の構成で稼動している場合に表示されます。

- Press "Apply Changes" to commit your modifications: このメッセージは、いずれかのダイアログ・ボックスで「Submit」が選択されたが「Apply Changes」ボタンがまだ選択されていない場合に表示されます。

- Restart Web Cache to make configuration changes take effect: このメッセージは、Oracle Web Cacheが以前の構成で稼働している場合に表示されます。静的な構成の変更がwebcache.xmlに適用されたが、Oracle Web Cacheが再起動されていない場合、このメッセージが表示されます。

- Dynamic Changes Applied.Restart Not Needed: このメッセージは、1つ以上の動的な構成の変更が適用され、Oracle Web Cacheの再起動が不要な場合に表示されます。

- Retrieve configuration from remote cache: このメッセージは、キャッシュが現在のバージョンのOracle Web Cacheに最近アップグレードされたが、構成がローカル・キャッシュの構成ファイルにコピーされていない場合に表示されます。

ナビゲータ・フレームには、表2-1に示す主要なカテゴリが含まれます。他のカテゴリやオプションも使用できますが、これらの領域で優先される機能が提供されています。

表2-6 Web Cache Managerのナビゲータ・ペインのオプション

カテゴリ

説明

Operations

このカテゴリには次のオプションがあります。

- Cache Operations: cacheサーバー・プロセスを起動、停止または再起動する「Cache Operations」ページが表示されます。詳細は、第2.7.3項を参照してください。

- Basic Content InvalidationおよびAdvanced Content Invalidation: キャッシュのコンテンツを無効化します。詳細は、第7.7.2.1項を参照してください。

- On-Demand Log File Rollover: イベント・ログとアクセス・ログを即時にロールオーバーできます。詳細は、第9.8項を参照してください。

Filtering

リクエスト・フィルタの構成では、第4章「リクエスト・フィルタリングの構成」の説明に従ってFusion Middleware Controlを使用して構成する方法をお薦めします。Oracle Web Cache Managerで「Request Filters」オプションを使用して、第4.14項の説明に従ってルールをコピーし、構成設定を元に戻します。

Properties

このカテゴリには次のオプションがあります。

- Security: 高度なセキュリティ・オプションを提供します。詳細は、第5章を参照してください。

- Network Timeouts: 接続のネットワーク設定を構成できます。詳細は、第2.11.5項を参照してください。

Logging and Diagnostics

このカテゴリには次のオプションがあります。

- Diagnostics: オブジェクトのHTMLレスポンス・ボディに診断情報を表示できます。詳細は、第8.8項を参照してください。

2.7.3 「Cache Operations」ページについて

Oracle Web Cache Managerの「Cache Operations」ページ(「Operations」→「Cache Operations」)には、キャッシュのステータスおよび必要な操作の情報が表示されます。このページからキャッシュの起動、停止、再起動を行えます。

キャッシュがキャッシュ・クラスタの一部である場合、クラスタ内のすべてのキャッシュが「Cache Operations」ページに一覧されます。キャッシュの起動、停止、再起動に加えて、このページから他のクラスタ・メンバーに構成を伝播することができます。操作は、選択したキャッシュのみを対象にすることも、クラスタ内の全キャッシュを対象にすることもできます。Webサイトの停止時間を最小限にするためには、キャッシュに対する操作を一定の時間差をつけて開始するように指定します。

2.8 Oracle Process Manager and Notification(OPMN)を使用したOracle Web Cacheの管理の概要

Oracle Process Manager and Notification(OPMN)サーバーは、adminサーバー・プロセスやcacheサーバー・プロセスを含む、Oracle Web Cacheプロセスを管理します。

- adminサーバー・プロセスは、Oracle Web CacheインスタンスとFusion Middleware Controlが稼動するWebLogic Server環境との間で、webcache.xml構成ファイルの内容を転送します。

- cacheサーバー・プロセスはキャッシュを管理します。

OPMNではopmnctlコマンドを提供しています。このコマンドは次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin/
(Windows) ORACLE_INSTANCE\bin

OPMNの使用を開始するには、opmnctlコマンドを使用してインストール内のコンポーネントのステータスを問い合せるとともに、使用中のすべてのポートのリストを取得します。

opmnctl status -l

その後、OPMNを使用してOracle Web Cacheを制御します。次に、opmnctlコマンドの書式を示します。

opmnctl command [parameter=value] [parameter=value]

表2-7に、Oracle Web Cacheに適用可能なopmnctlユーティリティのコマンドを示します。

表2-7 opmnctlユーティリティのコマンド

コマンド

説明

startproc

指定したプロセスまたはコンポーネントを起動します。

stopproc

指定したプロセスまたはコンポーネントを停止します。cacheサーバー・プロセスの停止に使用される場合、このコマンドはすべてのコンテンツおよび統計のキャッシュも削除します。現在受入中のリクエストがすべて処理されるまで、またはユーザーが指定したタイムアウトまで待機した後、キャッシュを停止します。

指定したプロセスをすぐに停止するには、表2-8に示されているWCShutdown=abortパラメータを使用します。

restartproc

指定したプロセスまたはコンポーネントを停止し、再起動します。

startall

OPMNによって制御されるすべてのプロセスを起動します。

stopall

OPMNによって制御されるすべてのプロセスを停止します。

status

OPMNによって制御されるプロセスのステータスを表示します。statusコマンドのオプションの詳細を表示するには、コマンドラインで次のように入力します。

opmnctl status -help

表2-8に、opmnctlユーティリティのパラメータを示します。Oracle Web Cacheに適用できる有効な値も示します。特に記載のないかぎり、status以外であれば、表2-7にリストされているすべてのコマンドをどのパラメータでも使用できます。

表2-8 opmnctlユーティリティのパラメータ

パラメータ

有効な値

説明

ias-component=component_name

Oracle Web Cacheインスタンスの名前

Oracle Web Cacheのadminサーバー・プロセスおよびcacheサーバー・プロセスに対して指定された処理を実行します。たとえば、次のコマンドでは、システム・コンポーネントwebache1で、Oracle Web Cacheのadminサーバー・プロセスとcacheサーバー・プロセスの両方が起動されます。

opmnctl startproc ias-component=webcache1

Oracle Web Cacheのプロセスを管理するには、このパラメータを必ず指定する必要があります。

process-type=value

WebCache

WebCache-admin

値に指定されたプロセスに対して、指定された処理を実行します。

- WebCache: cacheサーバー・プロセス

- WebCache-admin: adminサーバー・プロセス

このパラメータの前に、パラメータias-component=component_nameを指定する必要があります。たとえば、次のコマンドでは、Oracle Web Cache webcache1に対してcacheサーバー・プロセスのみを起動します。

opmnctl startproc ias-component=webcache1 process-type=WebCache

WCShutdown=value

abort

stopprocコマンドが使用される場合にのみ使用されます。指定したプロセスまたはコンポーネントを中断(即時停止)します。通常の停止と中断による停止には次のような違いがあります。

通常の停止時は、Oracle Web Cacheは、新規接続を受け入れませんが、stopprocコマンドの受信前に行われた接続に対するリクエストは処理します。リクエストが処理された後、キャッシュが停止されます。

中断による停止時は、Oracle Web Cacheは新規接続を受け入れません。さらに、リクエストが処理されていない場合でも既存のすべての接続を削除します。その後、キャッシュが停止されます。

このパラメータの前に、パラメータias-component=component_nameを指定する必要があります。

OPMNの使用方法およびサポートされるコマンドの詳細は、Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイドを参照してください。

2.9 Oracle Web Cacheを構成および管理するための基本的な作業

環境でOracle Web Cacheを構成するときは、まずOracle Web Cacheコンポーネントがインストールに追加されていることを確認します。追加されていない場合は、Oracle Web Cacheコンポーネントを構成に追加します。

次に、基本のOracle Web Cacheを構成および管理するための手順の要約を示します。

1. Oracle Web Cacheシステム・コンポーネントを環境に追加します。第2.10項を参照してください。
キャッシュ・クラスタを作成する場合は、第3.6項を参照してください。

2. インストールに追加後、Oracle Web Cacheインスタンスのプロパティを指定します。第2.11項を参照してください。

3. Oracle Web Cacheに対してセキュアなパスワードを構成します。第5.2項を参照してください。

4. セッション関連プロパティのセッション定義を構成します。第2.12項を参照してください。

5. アクセス・ログとイベント・ログを構成します。第9章「ロギング」を参照してください。

6. リクエスト・フィルタリングを構成します。第4章「リクエスト・フィルタリングの構成」を参照してください。

7. キャッシュ・ルールを構成および監視します。第6.6項を参照してください。

8. コンテンツを無効化します。第7章「コンテンツの無効化」を参照してください。

2.10 環境へのOracle Web Cacheシステム・コンポーネントの追加

Oracle Web TierまたはOracle Portal、Forms、ReportsおよびDiscovererのインストールでOracle Web Cacheを選択しなかった場合でも、Oracle Universal Installerによって必要なソフトウェアがインストールされるので、Oracle Web Cacheシステム・コンポーネントを簡単に追加することができます。

Oracle Web Cacheシステム・コンポーネントをインストールに追加するには:

1. コマンドラインで、次のディレクトリに移動します。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

2. Oracle Web Cacheシステム・コンポーネントを作成します。

createcomponent -componentType WebCache -oracleHome ORACLE_HOME -oracleInstance ORACLE_INSTANCE -componentName component_name

たとえば、webcache2というOracle Web Cacheシステム・コンポーネントを作成するには、次のような構文を入力します。

createcomponent -componentType WebCache -oracleHome /scratch/webtier -oracleInstance /scratch/instances/instance1 -componentName webcache2

3. キャッシュ・ルールを構成します。第6.6項を参照してください。

4. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

5. 「オリジン・サーバー」セクションを表示して、オリジン・サーバーに対するリクエストがOracle Web Cacheを経由していることを確認します。

2.11 Oracle Web Cacheシステム・コンポーネントのプロパティの指定

Oracle Web Cacheシステム・コンポーネントのプロパティを設定するには、次の作業を実行します。

- 第2.11.1項「作業1: Oracle Web Cacheのポートの構成」

- 第2.11.2項「作業2: オリジン・サーバーの設定」

- 第2.11.3項「作業3: サイト定義の指定」

- 第2.11.4項「作業4: サイト定義からオリジン・サーバーへのマッピング」

- 第2.11.5項「作業5: リソース制限とネットワークしきい値の設定」

- 第2.11.6項「作業6: エラー・ページの構成」

- 第2.11.7項「作業7: Oracle Web Cacheの再起動」

2.11.1 作業1: Oracle Web Cacheのポートの構成

Oracle Web Cacheでは、HTTPまたはHTTPSリスニング・ポートを使用してリクエストを受信します。リスニング・ポートは必要に応じて追加できます。たとえば、オリジン・サーバーが以前にリスニングしていたポートをOracle Web Cacheに割り当てる場合は、リスニング・ポートの追加が必要になることがあります。

Oracle Web Cacheでは、リスニング・ポート以外でも、特定のHTTPまたはHTTPSリスニング・ポートで、adminサーバー・プロセスに対するリクエスト、無効化および統計監視用のリクエストを受信します。これらの操作ポートは変更することができます。

この項では、Oracle Web Cacheのポート構成に関連する次の項目について説明します。

- 第2.11.1.1項「Fusion Middleware Controlを使用したOracle Web Cacheのポート構成の検証」

- 第2.11.1.2項「OPMNを使用したOracle Web Cacheのポート構成の検証」

- 第2.11.1.3項「Oracle Web Cacheリスニング・ポートの追加」

- 第2.11.1.4項「Oracle Web Cache操作ポートの変更」

2.11.1.1 Fusion Middleware Controlを使用したOracle Web Cacheのポート構成の検証

Oracle Web Cacheで使用されているポートをFusion Middleware Controlで確認するには:

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「ポートの使用状況」を選択します。
「ポートの使用状況」ページが表示されます。

図ports.gifの説明

この例では次のポートが示されています。

- ポート7785は、Oracle Web Cache用のHTTPSリスニング・ポートです。

- ポート7786は、adminサーバー・プロセス用のHTTPリスニング・ポートです。

- ポート7787は、統計監視リクエスト用のHTTPリスニング・ポートです。

- ポート7788は、無効化リクエスト用のHTTPリスニング・ポートです。

- ポート7789は、Oracle Web Cache用のHTTPリスニング・ポートです。

2.11.1.2 OPMNを使用したOracle Web Cacheのポート構成の検証

Oracle Web Cacheで使用されているポートをOPMNで確認するには、次の手順を実行します。

(UNIX) ORACLE_INSTANCE/bin/opmnctl status -l
(Windows) ORACLE_INSTANCE\bin\opmnctl status -l
Processes in Instance: instance1
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
ias-component                    | process-type       |     pid | status   |        uid |  memused |    uptime | ports
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
webcache1                        | WebCache-admin     |   11244 | Alive    |  458185369 |    45852 | 180:27:00 | http_admin:7786
webcache1                        | WebCache           |   11243 | Alive    |  458185368 |    72540 | 180:27:00 | http_stat:7787,http_invalidation:7788,https_listen:7789,http_listen:7785
ohs1                             | OHS                |    6077 | Alive    |  458185358 |   349220 | 180:48:14 | https:9999,https:4443,http:7777

この例では次のポートが示されています。

- ポート7785は、http_listenで表されているOracle Web Cache用のHTTPリスニング・ポートです。

- ポート7786は、WebCache-adminで表されているadminサーバー・プロセス用のHTTPリスニング・ポートです。

- ポート7787は、http_statで表されている統計監視リクエスト用のHTTPリスニング・ポートです。

- ポート7788は、http_invalidationで表されている無効化リクエスト用のHTTPリスニング・ポートです。

- ポート7789は、https_listenで表されているOracle Web Cache用のHTTPリスニング・ポートです。

2.11.1.3 Oracle Web Cacheリスニング・ポートの追加

リスニング・ポートは必要に応じて追加できます。たとえば、オリジン・サーバーが以前にリスニングしていたポートをOracle Web Cacheに割り当てる場合は、リスニング・ポートの追加が必要になることがあります。HTTPSポートを構成する場合は、第5.4.2項を参照してください。

HTTPリスニング・ポートを追加するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

3. 「作成」をクリックします。
「ポートの作成」ページが表示されます。

4. 「ポート・タイプ」リストから「NORM」を選択します。

5. 「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。

- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。

- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXのetc/hostsファイルなどの別の名前解決メカニズムを使用してください。

- 任意のIPアドレスを表すANY

6. 「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号がまだ使用されていないことを確認してください。

1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。

webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。

7. リスニング・ポートをHTTPポートからHTTPSポートに変更する場合は、第5.4.2項を参照してSSL設定を構成します。

8. 「OK」をクリックします。

2.11.1.4 Oracle Web Cache操作ポートの変更

Oracle Web Cacheが管理、無効化および統計監視用のリクエストを受信するポートを変更するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

3. 変更するポートを選択して、「編集」をクリックします。
「ポートの編集」ページが表示されます。

4. 「エンドポイント属性」セクションの「ポート・タイプ」リストから、「ADMINISTRATION」、「INVALIDATION」または「STATISTICS」を選択します。

5. 「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。

- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。

- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXのetc/hostsファイルなどの別の名前解決メカニズムを使用してください。

- 任意のIPアドレスを表すANY

6. 「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号がまだ使用されていないことを確認してください。

1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。

webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。

7. ポートをHTTPポートからHTTPSポートに変更する場合は、第5.5.1項を参照してSSL設定を構成します。

8. 「OK」をクリックします。

2.11.2 作業2: オリジン・サーバーの設定

Oracle Web Cacheに、キャッシュ・ミスを送信するWebアプリケーション・サーバーまたはプロキシ・サーバーを構成します。Oracle Web Cacheでは、通常、内部サイトにWebアプリケーション・サーバーを使用し、ファイアウォールの外側にある外部サイトにはプロキシ・サーバーを使用します。

Oracle HTTP Serverがインストールされている場合は、インストールのプロセスで、Oracle HTTP Serverのホスト名とリスニング・ポートに基づいてデフォルトのオリジン・サーバーが作成されます。

オリジン・サーバーがWebサイトにマップされている場合、Oracle Web Cacheは構成されたオリジン・サーバーにのみリクエストを転送します。

複数のオリジン・サーバーを構成する場合には、ホストおよびポート設定が同一でないことを確認します。重複するホストおよびポート設定でオリジン・サーバーを構成すると、cacheサーバーとadminサーバーの両プロセスが起動に失敗します。

Oracle Web Cacheでオリジン・サーバーの情報を構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「オリジン・サーバー」を選択します。
「オリジン・サーバー」ページが表示されます。

3. 「作成」をクリックします。

「オリジン・サーバーの作成」ページが表示されます。

4. 表2-9の説明を参照して、Oracle Web Cacheのリクエストを送信する各オリジン・サーバーの「ホスト」、「ポート」、「容量」、「プロトコル」および「有効ルーティング」を設定します。

5. 複数のオリジン・サーバーを含む構成の場合は、Oracle Web Cacheが送信したリクエストを障害発生時にHTTPで他のオリジン・サーバーに分散させる方法を、表2-9の説明に従って「フェイルオーバー」セクションで指定します。

6. これらのオリジン・サーバーがプロキシ・サーバーである場合は、表2-9の説明に従って、前述の設定を「プロキシWebサーバー」セクションで指定します。

7. 変更を適用して「オリジン・サーバー」ページに戻るには、「OK」をクリックします。この変更を適用するために、「オリジン・サーバー」ページで「適用」をクリックする必要はありません。

表2-9 オリジン・サーバーの作成

要素

説明

ホスト

オリジン・サーバーのホスト名を入力します。

ポート

オリジン・サーバーがOracle Web Cacheのリクエストを受信するリスニング・ポートを入力します。

注意: Oracle Web Cacheは、プロキシ対象のWebアプリケーション・サーバーと同じポートでリスニングする必要があります。プロキシ・サーバーを構成するときは、プロキシ対象のすべてのポートに対応するリスニング・ポートの存在を確認してください。

容量

オリジン・サーバーが受け入れることのできる最大同時接続数を入力します。

この数は、オリジン・サーバーの負荷テストを行い、CPUをすべて使用してしまうか、反応が遅くなるか、またはバックエンド・データベースの許容量の限界に到達するまでテストを行って決定します。

キャッシュ・クラスタの場合は、すべてのクラスタ・メンバーからオリジン・サーバーへの接続数の合計が「容量」に指定された値を超えないことが、Oracle Web Cacheによって保証されます。各クラスタ・メンバーの最大許容接続数は、次の数式を使用して計算されます。

connections_from_each_cluster_member = capacity / number_of_cluster_members

プロトコル

ポートでHTTPリクエストを送信する場合は「HTTP」、HTTPSリクエストを送信する場合は「HTTPS」を選択します。

有効ルーティング

Oracle Web Cacheがリクエストをオリジン・サーバーにルーティングできるようにする場合はクリックし、キャッシュからのリクエストの処理のみを行う場合は選択が解除されたままにします。

オリジン・サーバーの一時的なメンテナンスが必要な場合は、このオプションを選択しないことをお薦めします。

Oracle Web Cacheは、特定サイトに一致したリクエストを、そのサイトにマップされているすべてのオリジン・サーバーにルーティングします。すべてのオリジン・サーバーで「有効ルーティング」が選択されていない場合、Oracle Web Cacheはネットワーク・エラー・ページをクライアントに送信します。エラー・ページの構成の詳細は、第2.11.6項を参照してください。

フェイルオーバーのしきい値

確立された接続で許容されるオリジン・サーバーの読取り/書込みの許容連続失敗回数を入力します。

リクエストおよびレスポンスのデフォルトの許容連続失敗回数は5回です。

接続障害が発生すると、Oracle Web Cacheはすぐに、オリジン・サーバーの障害とみなします。

しきい値に達すると、Oracle Web Cacheはオリジン・サーバーに障害が発生したとみなし、そのオリジン・サーバーの自動フェイルオーバーを実行します。Oracle Web Cacheのリクエスト送信開始後にオリジン・サーバーでエラーが発生すると、Oracle Web Cacheによってエラー・カウンタの数値が増やされます。サーバーがレスポンスの送信に成功すると、エラー・カウンタはリセットされます。次のような場合、リクエストが失敗したとみなされます。

- 接続障害エラー以外のネットワーク・エラーが発生した場合

- HTTPレスポンスのステータス・コードが1xx、2xx、3xx、4xx、501 - 未実装および505 サポートされていないHTTPバージョン以外である場合

しきい値に達すると、Oracle Web Cacheはサーバーに障害が発生したとみなし、その後のリクエストには他のサーバーを使用します。Oracle Web Cacheは、「pingのURL」フィールドで指定されたURLにリクエストを送信することによって、障害が発生したサーバーのポーリングを開始します。ネットワーク・エラーが発生せず、HTTPレスポンス・コードが100未満または500、502、503、504ではない状態で、Oracle Web Cacheがサーバーからのレスポンスの受信に成功すると、Oracle Web Cacheはそのサーバーが使用可能になったとみなし、その後のリクエストには、そのサーバーが再び使用されるようになります。

注意:

- Oracle Web Cacheがオリジン・サーバーに接続できない場合、しきい値は適用されません。この場合、Oracle Web Cacheはその時点で、サーバーに障害が発生したとみなし、その後のリクエストにそのサーバーを使用しません。他のオリジン・サーバーが存在する場合、Oracle Web Cacheはリクエストを別のオリジン・サーバーに再度送信します。構成されているサーバーが存在しない場合、Oracle Web Cacheはエラーを返します。

- 1つのオリジン・サーバーのみ使用可能である場合、別のオリジン・サーバーへのフェイルオーバーは行われません。

pingのURL

Oracle Web Cacheがフェイルオーバーのしきい値に達したオリジン・サーバーをポーリングするときに使用するURLを入力します。

- Webアプリケーション・サーバーの場合、Webアプリケーション・サーバーの仮想ホストを表すサイト名またはドメイン名を含む相対URLか完全修飾URLのいずれかを入力します。

- プロキシ・サーバーの場合は、そのプロキシ・サーバーの背後にあるオリジン・サーバーの仮想ホストを表すサイト名またはドメイン名を含む完全修飾URLを入力します。

デフォルト値は次のとおりです。

/

静的なURLではなく、オリジン・サーバー上のアプリケーション・ロジックが正常であることをチェックして、200または500番台のHTTPステータス・コードを返すようなURLを使用することをお薦めします。

pingの間隔(秒単位)

Oracle Web Cacheがフェイルオーバーのしきい値に達したオリジン・サーバーをポーリングする間隔(秒)を入力します。

デフォルトは10秒です。

プロキシWebサーバー

このオリジン・サーバーをプロキシ・サーバーとして処理する場合にクリックします。

ユーザー名

プロキシ・サーバーの管理者のユーザー名を入力します。

パスワード

プロキシ・サーバーの管理者のパスワードを入力します。

パスワードの確認

プロキシ・サーバーの管理者のパスワードを再入力します。

2.11.3 作業3: サイト定義の指定

Oracle Web Cacheを1つ以上の名前付きWebサイトの仮想サーバーとして動作させるには、Oracle Web CacheにWebサイトの情報を構成します。サイト構成の概要は、第2.2項を参照してください。

サイト定義を作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. 「サイト定義」セクションで、「作成」をクリックします。

「サイトの作成」ページが表示されます。

4. 「作成」セクションで、表2-10の説明を参照して要素を構成します。

5. 「別名」セクションで、リクエストが正しいサイトに転送されるように、対象のサイトの別名をすべて指定します。別名は、ブラウザがサイトへの接続に使用するホストとポートを指定します。

1. 「作成」をクリックして別名を作成します。

2. 表2-10の説明を参照して、「ホスト」および「ポート」を構成します。

6. 変更を適用して「サイト」ページに戻るには、「OK」をクリックします。この変更を適用するために、「サイト」ページで「適用」をクリックする必要はありません。

7. 追加のサイトそれぞれに対して、ステップ3から6を繰り返します。

8. 「サイト」ページで、「上に移動」および「下に移動」アイコンを使用して定義の順序を並べ替えます。
Oracle Web Cacheは、受信リクエストをまずサイト定義に解決した後に、サイトからオリジン・サーバーへのマッピングのうち最初に一致したものに解決します。Oracle Web Cacheがサイト定義の順序およびサイトからサーバーへのマッピングを使用してリクエストを照合する仕組みの詳細は、第2.2項を参照してください。

9. 「適用」をクリックして移動を適用します。

表2-10 「サイトの作成」ページ

要素

説明

ホスト

「サイトの作成」セクションにサイト・パターンを入力します(例: www.company.com)。Oracle Web Cacheがリクエストをこのサイトに対して照合できるようにするために、プロトコル情報(http://またはhttps://)はホスト名に追加しないでください。

「別名」セクションにサイトの別名を入力します(例: company.com)。Oracle Web Cacheがリクエストをこの別名に対して照合できるようにするために、プロトコル情報(http://またはhttps://)はホスト名に追加しないでください。

注意: 複数サイトを表すためにワイルド・カード*を使用することはできません。

ポート

Oracle Web Cacheで受信リクエストのリスニングを行う、HTTPまたはHTTPSポートの番号を入力します。

URL接頭辞

同じホストを共有するサイトと区別するために、URLのパス接頭辞を入力します。接頭辞は「/」で始めてください。ファイル名や埋込みURLパラメータは接頭辞に含めないでください。

たとえば、次の2つのURLは同じサイト名を共有していますが、完全に異なる2つのアプリケーションに属していて、この2つのアプリケーションは完全に異なるコンピュータ上でホスティングされている可能性があります。

http://www.company.com/portal/page?_pageid=33,4232&_dad=portal

http://www.company.com/um/traffic_cop?mailid=inbox

これらのURLは、同一または異なるオリジン・サーバー上でホスティングされている完全に異なるアプリケーションのものです。最初のURLはログイン後のメール・ユーザーにフロント・ページを表示し、2番目のURLは受信ボックスを表示します。サイトのホスト名がwww.company.comと定義されている場合は、接頭辞を/portalおよび/umと指定してサイトを区別できます。

デフォルト・サイト

このサイトをOracle Web Cacheがホスト情報なしでリクエストを転送するデフォルト・サイトに指定する場合、このオプションをクリックします。

圧縮

Oracle Web Cacheでキャッシュ可能およびキャッシュ不可の圧縮されたコンテンツをブラウザに送信するように指定する場合にクリックします。このオプションを選択しない場合、Oracle Web Cacheは対象のサイトの圧縮されたコンテンツを送信しません。

Oracle Web Cacheで圧縮が自動的に無効になる場合については、第1.2.5項を参照してください。

Oracle Web Cache Managerを使用して、どのサイトにも一致しないリクエストに対して圧縮を無効にできます。第2.11.3.1項を参照してください。

2.11.3.1 すべてのレスポンスに対する圧縮の無効化

Oracle Web Cacheでは、すべてのレスポンスに対して圧縮を無効にできます。

1. 名前付きサイトの場合、第2.11.3項の説明に従って、Fusion Middleware Controlの「サイトの作成」ページで「圧縮」オプションを選択解除します。

2. どのサイトにも一致しない未定義サイトのリクエストの場合、Oracle Web Cache Managerを使用して次の作業を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Site Definitions」を選択します。第2.7.2項を参照してください。
「Site Definitions」ページが表示されます。

2. 「Undefined Sites」行を選択し、「Show/Edit Selected」をクリックします。
「Show/Edit Undefined Sites Definition」ダイアログ・ボックスが表示されます。

3. 「Site-Wide Compression」に対して、「No」をクリックします。

4. 「Submit」をクリックします。

5. 「Apply Changes」をクリックします。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

2.11.4 作業4: サイト定義からオリジン・サーバーへのマッピング

サイト定義を指定したら、サイトからオリジン・サーバーへの順位付けされたマッピングを作成します。サイト構成の概要は、第2.2項を参照してください。

Oracle HTTP Serverがインストールされている場合は、インストールのプロセスで、Oracle HTTP Serverのホスト名とリスニング・ポートに基づいてデフォルトのサイトからサーバーへのマッピングが作成されます。

第2.11.2項で、複数のオリジン・サーバーのロード・バランシングを構成した場合は、サイトからサーバーへのマッピングを1つ作成し、適用可能なオリジン・サーバーをすべてサイトにマップします。このサイトからサーバーへのマッピングで、そのサイトに当てはまるすべてのオリジン・サーバーを選択します。オリジン・サーバーを複数のサイトからサーバーへのマッピングに分割すると、サイトのロード・バランシングは意図したとおりに行われません。

オリジン・サーバーへサイトをマップするには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「サイト」を選択します。
「サイト」ページが表示されます。

3. サイト・サーバー間マッピング」セクションで、「作成」をクリックします。

「サイト・サーバー間マッピング」ページが表示されます。

4. 「ホスト・パターン」、「ポート・パターン」および「接頭辞」の各要素を構成します。

1. 「ホスト・パターン」フィールドに、サイト・パターンを入力します(例: www.company.com)。Oracle Web Cacheがリクエストをこのサイトに対して照合できるようにするために、プロトコル情報(http://またはhttps://)はホスト名に追加しないでください。
「ホスト・パターン」フィールドでは、ワイルド・カード(*)を次のような用途に使用することができます。

- 1つ以上のWebアプリケーション・サーバーまたはプロキシ・サーバーに複数のサイト名をマップする場合。たとえば、site1.company.comおよびsite2.company.comというサイトを指定するために*.company.comと入力することができます。

- ファイアウォールの外側にあり、プロキシ・サーバーを通じてアクセス可能なサイトにキャッシュ・ミスをルーティングする場合。たとえば、プロキシ・サーバーproxy-hostへのマップにワイルド・カード(*)を使用することができます。

2. 「ポート・パターン」フィールドに、Oracle Web Cacheで受信リクエストのリスニングを行うWebサイトのHTTPまたはHTTPSポートの番号を入力します。
「ポート・パターン」フィールドでワイルド・カード(*)を使用して、異なるポート番号を持つ同じサイト名を同じオリジン・サーバーにマップすることもできます。オリジン・サーバーがプロキシ・サーバーの場合は、第2.11.2項の説明に従って、そのサーバーがプロキシ対象のWebアプリケーション・サーバーと同じポートでリスニングするように構成されていることを確認してください。

5. 「オリジン・サーバー」セクションで、オリジン・サーバーを選択します。
複数のオリジン・サーバーを選択する場合、同じタイプで、リスニング・ポート(HTTPまたはHTTPS)上で同じプロトコルを使用するサーバーを選択する必要があります。たとえば、Webアプリケーション・サーバーとプロキシ・サーバーを混在させることはできません。

6. 変更を適用して「サイト」ページに戻るには、「OK」をクリックします。この変更を適用するために、「サイト」ページで「適用」をクリックする必要はありません。

7. 追加の各マッピングに対して、ステップ3から6を繰り返します。

8. 「サイト」ページで、「上に移動」および「下に移動」機能を使用してマッピングの順序を並べ替えます。
Oracle Web Cacheは、受信リクエストをまずサイト定義に解決した後に、サイトからオリジン・サーバーへのマッピングのうち最初に一致したものに解決します。Oracle Web Cacheがサイト定義の順序およびサイトからサーバーへのマッピングを使用してリクエストを照合する仕組みの詳細は、第2.2項を参照してください。

2.11.5 作業5: リソース制限とネットワークしきい値の設定

リソース制限の詳細は、第2.3項を参照してください。

Oracle Web Cacheのキャッシュおよびネットワークしきい値を指定するには、次の手順を実行します。

1. キャッシュしきい値を指定します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューで、「管理」、次に「リソース制限」を選択します。
「リソース制限」ページが表示されます。

3. 「キャッシュされたオブジェクトの最大サイズ」フィールドで、キャッシュに格納するオブジェクトの最大サイズをKB単位で指定します。
入力する値の詳細は、第2.3.3項を参照してください。

4. キャッシュごとに、「最大キャッシュ・サイズ」フィールドに、Oracle Web Cacheの必要とするメモリー量をMB単位で入力します。
入力する値の詳細は、第2.3.1項を参照してください。

5. 「Maximum Incoming Connections」フィールドに、Oracle Web Cacheに対する着信接続の最大数を入力します。
入力する値の詳細は、第2.3.2項を参照してください。

6. 「適用」をクリックします。

2. すべてのキャッシュに対し、ネットワーク・タイムアウトを変更します。

1. Oracle Web Cache Managerで、「Properties」→「Network Timeouts」を選択します。第2.7.2項を参照してください。

2. 「For Cache」リストから、特定のキャッシュを選択します。

3. タイムアウトのタイプを選択し、「Edit Selected」をクリックします。タイムアウトの詳細は、第2.3.4項を参照してください。

4. しきい値の「Edit」ダイアログで、「Duration」フィールドの値を変更するか、デフォルト値を使用するには「Use Default」を選択します。
キープ・アライブのタイムアウトについては、値を0に設定した場合、クライアントとの接続は開かれた状態のままにはなりません。また、Oracle Web Cacheはレスポンスに次のレスポンス・ヘッダー・フィールドを含めて送信します。

Connection: Close

入力する値の詳細は、第2.3.4項を参照してください。

5. 期間をすべてのキャッシュに適用するには「Use for all caches in the cluster」オプションを選択し、現在のキャッシュにのみ変更を適用するにはこのオプションを選択解除します。

6. 「Submit」をクリックします。

7. 「Apply Changes」をクリックします。
いつでもデフォルト値に戻すことができます。「Network Timeouts」ページで「Use Defaults」をクリックし、「Apply Changes」をクリックして変更を適用します。

2.11.6 作業6: エラー・ページの構成

ネットワーク通信エラー、サイト・ビジー・エラー、またはESI <esi:include>エラーが発生した場合は、アプリケーションからエラー・ページが表示されます。この作業の負荷をオリジン・サーバーに負わせるのではなく、Oracle Web Cacheからこれらのページが表示されるように構成することができます。

サイトのエラー・ページを表示するようにOracle Web Cacheを構成するには、次の手順を実行します。

1. エラー・ページを作成して、次のディレクトリの場所に配置します。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>/files
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>\files

デフォルトの設定は次のとおりです。

- ネットワーク・エラーの場合、デフォルトはnetwork_error.htmlに設定されています。このエラー・ページは、キャッシュ・ミス・リクエストに対するオリジン・サーバーからのレスポンスの接続、送信または受信中にネットワーク障害が発生したときに表示されます。

- サイト・ビジー・エラーの場合、デフォルトはbusy_error.htmlに設定されています。このエラー・ページは、オリジン・サーバーが許容量に達したときに表示されます。

- ESIデフォルト・フラグメントの場合、デフォルトはesi_fragment_error.txtに設定されています。このページは、Oracle Web Cacheが<esi:include>タグで指定されたsrcをフェッチできず、alt属性、onerror属性、またはtry |attempt |exceptブロックのいずれかが存在しないか障害がある場合に表示されます。

本番環境では、そのサイトの他のエラー・ページとの整合性を取るために、デフォルトを変更するか、まったく新しいエラー・ページを作成することをお薦めします。

2. Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Error Pages」を選択します。
「Error Pages」ページが表示されます。

3. ページの表の中から「Default Pages」またはサイト名を選択し、「Edit」をクリックします。

「Edit Error Pages」ダイアログ・ボックスが表示されます。

4. 「Network Error Page」フィールドに、Oracle Web CacheとWebサイトとの間のネットワーク通信の問題に対して配信されるエラー・ページのファイル名を入力します。
デフォルトのnetwork_error.htmlページを使用している場合は、フィールドをそのままにしておきます。

5. 「Site Busy Page」フィールドに、Webサイトがリクエストで飽和状態になったときに配信されるエラー・ページのファイル名を入力します。
デフォルトのbusy_error.htmlページを使用する場合は、フィールドをそのままにしておきます。

6. 「ESI Default Fragment」フィールドに、Oracle Web Cacheが<esi:include>タグに対するHTMLフラグメントを取得できないときに配信されるページのファイル名を入力します。
ページの部分的なキャッシュに<esi:include>タグを使用しない場合や、例外に対してESI言語要素のみを使用する場合は、値を入力しないでください。

7. 「Apply Changes」をクリックします。
「Default Pages」を選択した場合、デフォルトのページ設定を使用するすべての定義済サイトに新しい設定が適用されます。ただし、未定義サイトには新しい設定は適用されません。ステップ3で特定のサイトを選択した場合は、そのサイトに新しい設定が適用されます。

2.11.7 作業7: Oracle Web Cacheの再起動

Oracle Web Cacheの再起動方法は、第2.13項を参照してください。

2.12 セッション定義の作成

次の機能に対するセッション定義を作成します。

- キャッシュによるセッション・リクエストの処理方法を指定します。

- セッション・バインディングを有効にして、特定サイトのユーザー・セッションをオリジン・サーバーにバインドし、一定期間、状態を維持できるようにします。

- セッション・エンコードされたURLのセッション情報を置換します。

これらの機能を有効にする場合には、セッション定義を選択する必要があります。

セッション定義を作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。

3. 「サイト」リストから、このセッション定義を適用する特定のサイトを選択します。すべてのサイトに適用可能なグローバル・セッション定義を作成するには、「グローバル」を選択します。
追加のサイトの指定方法は、第2.11.3項を参照してください。

4. 「セッション定義」セクションで、「作成」をクリックします。
表に新しい行が表示されます。

5. 「セッション名」フィールドに、覚えやすい一意のセッション名を入力します。

6. Cookie名を「Cookie名」フィールドに、埋込みURLパラメータを「URL POST本体パラメータ」フィールドに入力します。
Cookie名および埋込みURLパラメータの両方を入力した場合、どちらも同じセッションのサポートに使用する必要があります。異なるセッションをサポートする場合は、別々にセッション定義を作成します。

注意:
Cookieが期限切れになると、クライアントのブラウザによりCookieが削除され、オブジェクトに対するその後のリクエストはオリジン・サーバーに転送されます。ページがクライアントのブラウザのセッション期限後に表示されないようにするために、Webアプリケーション・サーバーによってクライアントのブラウザ・セッションが期限切れになる前に、セッションCookieが期限切れになるようにしてください。

7. 「URL POST本体パラメータ」フィールドに、セッション情報を含む埋込みURLパラメータまたはPOST本体パラメータを入力します。

8. 「デフォルト値」フィールドに、Oracle Web CacheでCookieまたは埋込みURLパラメータの値に使用されるデフォルトの文字列を入力します。Oracle Web Cacheでは、Cookieまたはパラメータ情報が含まれないリクエストに対して、このデフォルトの文字列が使用されます。これらのリクエストでは、Oracle Web Cacheによって、セッションID情報がデフォルトの文字列に置換されます。このデフォルト文字列のデフォルトはdefaultです。

9. 「適用」をクリックして変更を適用します。

10. Oracle Web Cacheを再起動します。第2.13項を参照してください。

セッション定義を必要とするOracle Web Cacheのプロパティの詳細は、次の項を参照してください。

- セッション・バインディングを構成する方法は、第3.5項を参照してください。

- セッション・キャッシュ・ルールを構成する方法は、第6.8.6項を参照してください。

- セッション・エンコードされたURLに対するサポートを構成する方法は、第6.8.7項を参照してください。

2.13 Oracle Web Cacheの起動と停止

構成の変更の大部分が静的です。静的な変更を適用する場合は、Oracle Web Cacheを再起動する必要があります。

ただし、Oracle Web Cacheでは、いくつかの変更が動的な変更として認識されます。Oracle Web Cache Managerでは、次の機能に対して動的な構成が提供されています。

- Fusion Middleware ControlとOracle Web Cache Managerの両方でのリクエスト・フィルタリング

- Oracle Web Cache Managerの「Event Logs」ページ(「Logging and Diagnostics」→「Event Logs」)のバッファリングおよび冗長性詳細レベルの設定

- Oracle Web Cache Managerの「Access Logs」ページ(「Logging and Diagnostics」→「Access Logs」)のバッファリングの設定

- Oracle Web Cache Managerの「Diagnostics」ページ(「Logging and Diagnostics」→「Diagnostics」)のオブジェクトのHTMLレスポンス・ボディにおける診断情報の有効化および無効化

- Fusion Middleware Controlの「オリジン・サーバー」ページ(「オリジン・サーバー、サイトおよびロード・バランシング」→「オリジン・サーバー」)のオリジン・サーバーに対するルーティングの設定

Oracle Web Cacheの構成を静的に変更した場合は、必ずOracle Web Cacheプロセスを停止して再起動する必要があります。

- adminサーバー・プロセスは管理インタフェースを管理します。

- cacheサーバー・プロセスはキャッシュを管理します。

cacheサーバー・バイナリはwebcached実行可能ファイルとadminサーバー・バイナリwebcacheaによって管理されます。これらの実行可能ファイルは次のディレクトリにあります。

(UNIX) ORACLE_HOME/webache/bin
(Windows) ORACLE_HOME\bin

Oracle Web Cacheを停止すると、キャッシュ内のオブジェクトがすべて削除されます。さらに、統計もすべて削除されます。

Oracle Web Cacheを構成した後は、Oracle Web Cacheを再起動します。Oracle Web Cacheを再起動するには、次のツールを使用します。

- cacheまたはadminサーバー・プロセスを再起動する場合は、Fusion Middleware Controlまたはopmnctlコマンドライン・ツールを使用します。

- cacheサーバー・プロセスを再起動する場合は、Oracle Web Cache Managerを使用します。

次のいずれかの構成設定を変更した場合は、cacheサーバー・プロセスとadminサーバー・プロセスの両方を再起動する必要があります。

- 管理ポートのプロパティ(第2.11.1.4項)

- 信頼できるサブネット(第5.3項)

- ユーザーIDとグループIDの情報(第5.9.1項)

2.13.1 opmnctlを使用した起動と停止

opmnctlを使用してOracle Web Cacheプロセスを起動、停止および再起動するには、次の手順を実行します。

1. Oracle Web Cacheのステータスを調べます。コマンドラインで、次のように入力します。

(UNIX) ORACLE_INSTANCE/bin/opmnctl status
(Windows) ORACLE_INSTANCE\bin\opmnctl status

OPMNで、実行中のプロセスのリストが作成されます。次のメッセージは、Oracle Web Cacheのadminサーバー(WebCache-admin)とcacheサーバー(WebCache)がすでに実行中であることを示します。

opmnctl status -l
Processes in Instance: instance1
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
ias-component                    | process-type       |     pid | status   |        uid |  memused |    uptime | ports
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
webcache1                        | WebCache-admin     |   11244 | Alive    |  458185369 |    45852 | 180:27:00 | http_admin:7786
webcache1                        | WebCache           |   11243 | Alive    |  458185368 |    72540 | 180:27:00 | http_stat:7787,http_invalidation:7788,https_listen:7789,http_listen:7785
ohs1                             | OHS                |    6077 | Alive    |  458185358 |   349220 | 180:48:14 | https:9999,https:4443,http:7777

2. adminサーバー(WebCache-admin)プロセスおよびcacheサーバー(WebCache)プロセスの両方を、コマンドラインから起動、停止または再起動するには、次のように入力します。

opmnctl startproc|stopproc|restartproc ias-component=component_name

adminサーバー(WebCache-admin)プロセスおよびcacheサーバー(WebCache)プロセスを、コマンドラインから個別に起動、停止または再起動するには、次のように入力します。

opmnctl startproc|stopproc|restartproc ias-component=component_name process-type=WebCache-admin

opmnctl startproc|stopproc|restartproc ias-component=component_name process-type=WebCache

Oracle Web Cacheのopmnctlに関する詳細は、次を参照してください。

- Oracle Web Cacheのopmnctlコマンドのリストは、第2.8項を参照してください。

- opmnctlの使用方法の詳細は、Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイドを参照してください。

2.13.2 Fusion Middleware Controlを使用した起動と停止

Fusion Middleware ControlからOracle Web Cacheを起動、停止または再起動するには:

1. Fusion Middleware Controlを起動します。第2.6.1項を参照してください。

2. ナビゲータ・ペインでファームを開き、「Web層」インストール・タイプを開きます。

3. webcache1などのOracle Web Cacheコンポーネントを選択します。

4. ターゲット名を表示してキャッシュのステータスを確認します。
図home_status.gifの説明

矢印は、adminサーバー・プロセスではなく、cacheサーバー・プロセスの稼働中または停止ステータスを表しています。

緑色の上向き矢印は、次の状況を示しています。

- cacheサーバーは実行中だが、adminサーバー・プロセスは実行されていません。

- cacheサーバーとadminサーバー・プロセスの両方が実行中です。

赤色の下向き矢印は、次の状況を示しています。

- cacheサーバーは実行されていないが、adminサーバー・プロセスは実行中です。

- cacheサーバーとadminサーバー・プロセスの両方が実行されていません。

adminサーバー・プロセスが停止している場合、構成ページのコンテキスト・ペインにエラーが表示され、adminサーバー・プロセスが停止しているために構成を使用できないことが示されます。

5. 「Webキャッシュ」メニューから、「コントロール」→「起動」、「停止」または「再起動」を選択します。
2つのプロセスが同じステータス(実行中または停止中)の場合、これらのコマンドを選択すると両方のプロセスが起動、停止または再起動されます。2つのプロセスのステータス(実行中または停止中)が異なる場合は、それぞれのプロセスの状況に応じて、該当するプロセスが起動、停止または再起動されます。たとえば、cacheサーバー・プロセスが実行中でadminサーバー・プロセスが実行されていない場合に「起動」を選択すると、adminサーバーのみが起動されます。

2.13.3 Oracle Web Cache Managerを使用した起動と停止

Oracle Web Cache Managerを使用して、cacheサーバー・プロセスを起動および停止できます。adminサーバー・プロセスを起動、停止または再起動する場合は、Fusion Middleware Controlまたはopmnctlを使用する必要があります。

Oracle Web Cache Managerを使用してcacheサーバー・プロセスを起動、停止および再起動するには、次の手順を実行します。

1. Oracle Web Cache Managerを起動します。第2.7.1項を参照してください。

2. ナビゲータ・フレームで、「Operations」→「Cache Operations」を選択します。第2.7.2項を参照してください。
右ペインに「Cache Operations」ページが表示されます。

3. キャッシュを選択し、「Start」、「Stop」または「Restart」をクリックします。

キャッシュ・クラスタ内の1つのキャッシュで操作を実行するには、次の手順を実行します。

キャッシュを1つ選択し、「Operate On」フィールドで「Selected Cache」を選択します。続いて「Start」、「Stop」または「Restart」をクリックします。

キャッシュ・クラスタ内のすべてのキャッシュで操作を実行するには、次の手順を実行します。

「Operate On」フィールドで「All Caches」を選択し、「Start」、「Stop」または「Restart」をクリックします。

3 高可用性ソリューションの構成

この章では、Oracle Web Cacheを使用した高可用性ソリューションの構成方法と実装方法について説明します。

この章の項目は次のとおりです。

- 第3.1項「オリジン・サーバーのロード・バランシングとフェイルオーバーの概要」

- 第3.2項「セッション・バインディングの概要」

- 第3.3項「キャッシュ・クラスタの概要」

- 第3.4項「ハードウェア・ロード・バランサを使用しない高可用性の概要」

- 第3.5項「セッション・バインディングの構成」

- 第3.6項「同一のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成」

- 第3.7項「非関連キャッシュまたは別のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成」

- 第3.8項「ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成」

- 第3.9項「Microsoft Windowsネットワーク負荷分散の構成」

3.1 オリジン・サーバーのロード・バランシングとフェイルオーバーの概要

Oracle Web Cacheには、キャッシュ・ミスを送信するWebアプリケーション・サーバーまたはプロキシ・サーバーを構成できます。Oracle Web Cacheでは、通常、内部サイトにWebアプリケーション・サーバーを使用し、ファイアウォールの外側にある外部サイトにはプロキシ・サーバーを使用します。

この項では、次の概念について説明します。

- 第3.1.1項「急激な過負荷の回避」

- 第3.1.2項「ステートレス・ロード・バランシング」

- 第3.1.3項「バックエンド・フェイルオーバー」

オリジン・サーバーの構成方法は、第2.11.2項を参照してください。

3.1.1 急激な過負荷の回避

Oracle Web Cacheは、キャッシュ不可のオブジェクト、失効しているオブジェクトまたは見つからないオブジェクトに対するリクエストをオリジン・サーバーに渡します。オリジン・サーバーへのリクエストの負荷が過大にならないように、Oracle Web Cacheには急激な過負荷の回避機能が備わっています。この機能では、オリジン・サーバーが同時に処理できるリクエストの数を制限できます。制限に達すると、それ以降のリクエストはキューに入れられます。キューがいっぱいになると、Oracle Web Cacheはリクエストを拒否し、リクエストを発信したクライアントにサイト・ビジー・エラー・ページを返します。

3.1.2 ステートレス・ロード・バランシング

ほとんどのWebサイトは、HTTPおよびHTTPSリクエストの負荷を共有する、複数のコンピュータ上で稼働する複数のオリジン・サーバーによって運営されています。Oracle Web Cacheで処理できないリクエストは、すべてオリジン・サーバーに渡されます。Oracle Web Cacheは、各オリジン・サーバーで使用可能な許容量の割合である許容負荷容量を判断することで、オリジン・サーバー間の負荷を均衡させます。Oracle Web Cacheでは、許容負荷容量が最も大きいオリジン・サーバーにリクエストを送信します。許容負荷容量の合計は、次の数式によって計算されます。

(Capacity - Load) / Capacity

この計算式の詳細は、次のとおりです。

- Capacityは、オリジン・サーバーが受け入れることのできる最大同時接続数を表します。

- Loadは、現在使用されている接続数を表します。

複数のオリジン・サーバーの許容負荷容量が同じである場合、Oracle Web Cacheはラウンドロビン法を使用してリクエストをそれらのオリジン・サーバーに送信します。ラウンドロビン法とは、構成済サーバーのリストの中で1番目のオリジン・サーバーが最初にリクエストを受け取り、2番目のオリジン・サーバーが次のリクエストを受け取る、というようにしてリクエストを振り分けるものです。許容負荷容量が同じではない場合、Oracle Web Cacheでは、許容量が最も大きいオリジン・サーバーにリクエストを送信します。

オリジン・サーバーの負荷が同じ場合は、オリジン・サーバーに対する容量が同じでない場合でも、Oracle Web Cacheはラウンドロビン法を使用します。したがって、容量が同じになるように構成されていない場合は、オリジン・サーバーへのリクエストが均等に分散されているかを調べることが可能です。

サイトのロード・バランシングを構成するには、各オリジン・サーバーの容量を設定し、サイトとサーバー間のマップを1つ作成して、すべての適用可能なオリジン・サーバーをこのサイトにマップします。

構成の詳細は、次を参照してください。

- 許容量の指定方法は、第2.11.2項を参照してください。

- サイトからサーバーへのマッピングの作成方法は、第2.11.4項を参照してください。

図3-1は、www.company.com:80とwww.server.com:80の2つのサイトを示しています。サイトwww.company.com:80は、アプリケーション・サーバーcompany-host1とcompany-host2でサポートされ、それぞれの容量は50です。サイトwww.server.com:80は、アプリケーション・サーバーserver-host1、server-host2およびserver-host3でサポートされ、それぞれの容量は150、50、50です。

図3-1 ロード・バランシング

「図3-1 ロード・バランシング」の説明

各Webアプリケーション・サーバーの初期の負荷が0であった場合、Oracle Web Cacheはwww.company.com:80およびwww.server.com:80へのリクエストを次の方法で分散します。

- Oracle Web Cacheはラウンドロビン法を使用して、www.company.com:80へのリクエストを2つのアプリケーション・サーバーに分散します。
Oracle Web Cacheはcompany-host1およびcompany-host2へのリクエストを、2つのアプリケーション・サーバーの負荷を等しく保持するように分散します。最初のリクエストは、company-host1に送信されます。2番目のリクエストは、company-host1が最初のリクエストをまだ処理中の場合、company-host2に送信されます。3番目以降のリクエストは、許容負荷容量が最も大きいアプリケーション・サーバーに送信されます。

許容量が同じ場合、Oracle Web Cacheはラウンドロビン法を使用してリクエストを分散します。

- Oracle Web Cacheは許容負荷容量のパーセンテージに基づいて、www.server.com:80へのリクエストを3つのオリジン・サーバーに分散します。
www.server.com:80への最初のリクエストは、server-host1が構成リストの先頭にあるため、そこに送信されます。2番目のリクエストは、server-host2に送信されます。これは、server-host1が最初のリクエストを処理中であり、重み付けされた使用可能な容量は99.3 %となり、server-host2の重み付けされた使用可能な容量が100 %であるためです。3番目のリクエストは、server-host3に送信されます。これは、server-host2がリクエストを処理中で重み付けされた使用可能な容量は98 %となり、server-host3の重み付けされた使用可能な容量が100 %であるためです。4番目のリクエストは、server-host1に送信されます。これは、server-host2とserver-host3がリクエストを処理中で重み付けされた使用可能な容量が98 %となるためです。5番目のリクエストは、server-host1に送信されます。これは重み付けされた使用可能な容量が98.6 %となり、これがserver-host2とserver-host3それぞれよりも依然として大きいためです。

許容量と負荷が同じでない場合、Oracle Web Cacheは許容負荷容量を使用してリクエストを分散します。新規リクエストが着信する前にリクエストが処理された場合は、3つのオリジン・サーバーの負荷がすべて0(ゼロ)になる可能性があります。この場合、Oracle Web Cacheはラウンドロビン法を使用します。

キャッシュ・サポートが不要で、ハードウェア・ロード・バランサに対して安価なソリューションが必要な場合は、Oracle Web Cacheをソフトウェア・ロード・バランサとして専用に構成できます。このような構成モードは、小規模Webサイト、部門別WebサイトまたはテストWebサイトへのトラフィックの管理に役立ちます。詳細は、第3.4項を参照してください。

3.1.3 バックエンド・フェイルオーバー

リクエストが指定された回数を連続で失敗すると、Oracle Web Cacheにより、そのオリジン・サーバーに障害が発生したとみなされます。オリジン・サーバーで障害が発生した場合、Oracle Web Cacheは、負荷を自動的に残りのオリジン・サーバーに分散し、障害の発生したオリジン・サーバーが再びオンラインになるまで、その稼働または停止状況をポーリングします。障害の発生したオリジン・サーバーへの既存リクエストについては、エラーが発生します。新規リクエストは、他のオリジン・サーバーに転送されます。障害の発生したサーバーが稼働状態に戻ると、Oracle Web Cacheはそのサーバーの許容負荷容量も含めて、リクエストのロード・バランシングを行います。

リクエストの失敗回数の構成の詳細は、第2.11.2項を参照してください。

図3-2にフェイルオーバー機能を示します。許容量50のserver-host3に障害が発生すると、リクエストの75%はserver-host1に配信され、25%はserver-host2に配信されます。

図3-2 フェイルオーバー

「図3-2 フェイルオーバー」の説明

3.2 セッション・バインディングの概要

特定サイトのユーザー・セッションをオリジン・サーバーにバインドし、一定期間、状態を維持できるようにする機能を持つセッション・バインディングをサポートするように、Oracle Web Cacheを構成できます。この機能を使用するには、オリジン・サーバー自体が状態を維持する(ステートフルである)必要があります。

セッション・バインディングを必要とするオブジェクトに対してリクエストがオリジン・サーバーに転送されると、オリジン・サーバーは、クライアントへのセッション情報をOracle Web Cache経由でセッションCookieまたは埋込みURLパラメータの形で含めることにより、ユーザー・セッションを作成します。Oracle Web CacheはパラメータまたはCookieの値を処理せず、情報を単にクライアントのブラウザに戻します。クライアントがセッション情報を後続のリクエストに含めると、Oracle Web Cacheは、ユーザー・セッションを作成したオリジン・サーバーにリクエストを転送します。Oracle Web Cacheは、ユーザー・セッションをその特定のオリジン・サーバーにバインドします。

図3-3に、Oracle Web Cacheがセッション・バインディングを使用するオブジェクトをサポートする仕組みを示します。

図3-3 セッション・バインディング

「図3-3 セッション・バインディング」の説明

リクエストにおけるセッション・バインディングの動作ステップは、次のとおりです。

1. Oracle Web Cacheは、リクエストを初めて受信したときに、ロード・バランシング機能を使用してリクエストを転送するオリジン・サーバーを決定します。この図の例では、アプリケーション・サーバーwww.server2.comが選択されています。

2. リクエストされたオブジェクトにセッション・バインディングが必要な場合、オリジン・サーバーは、Oracle Web Cacheを通じて、セッション情報をCookieまたは埋込みURLパラメータの形でクライアントに送り返します。

3. そのセッションの後続のリクエストについては、Oracle Web Cacheは、ロード・バランシングをバイパスして、セッションを確立したオリジン・サーバーに送信します。この例では、アプリケーション・サーバーwww.server2.comによって後続のリクエストが処理されます。

オリジン・サーバーの構成方法は、第2.12項を参照してください。

キャッシュ・クラスタを構成している場合、セッション・バインディングを構成する際に「内部-トラッキング」メカニズム・オプションは選択しないでください。これは、キャッシュ・クラスタでは機能しません。キャッシュ・クラスタのその他のメカニズムは機能します。詳細は、第3.6.4項を参照してください。

注意:

- セッションが期限切れになると、Oracle Web Cacheではオリジン・サーバーへのユーザー・セッションのバインドを中止します。そのかわりに、Oracle Web Cacheではロード・バランシングを使用してオリジン・サーバーを選択します。ページがクライアントのセッション期限後に表示されないようにするために、オリジン・サーバーによってクライアント・セッションが期限切れになる前に、セッションCookieが期限切れになるようにしてください。

- オリジン・サーバーがビジー状態の場合、Oracle Web Cacheはそのオリジン・サーバーへのセッションのバインディングを無効にします。

3.3 キャッシュ・クラスタの概要

キャッシュ・クラスタでは、Oracle Web Cacheの複数のシステム・コンポーネントが1つの論理キャッシュとして動作します。この論理キャッシュは、キャッシュ・クラスタ・メンバーと呼ばれます。キャッシュ・クラスタ・メンバーは、他のキャッシュ・クラスタ・メンバーがキャッシュしているキャッシュ可能なコンテンツをリクエストしたり、キャッシュ・クラスタ・メンバーに障害が発生したことを検出するために互いに通信します。

図3-4は、3つのキャッシュ・クラスタ・メンバーを持つOracle Web Cacheクラスタを示しています。この図に示されるように、クラスタ・メンバーは互いに通信するのみでなく、Webアプリケーション・サーバーやクライアントとも通信します。

図3-4 Oracle Web Cacheクラスタのアーキテクチャ

「図3-4 Oracle Web Cacheクラスタのアーキテクチャ」の説明

Oracle Web Cacheでは、各キャッシュ・インスタンスの相対許容量によって、キャッシュされたコンテンツをキャッシュ・クラスタ・メンバーに分散します。実際には、特定のオブジェクトの所有権を持つキャッシュ・クラスタ・メンバーを割り当てます。このコンテンツは所有コンテンツと呼ばれます。

所有コンテンツに加えて、Oracle Web Cacheは、各クラスタ・メンバーのキャッシュ内にポピュラーなオブジェクトも保存します。このようなオブジェクトはオンデマンド・コンテンツと呼ばれます。オンデマンド・コンテンツを保存することで、Oracle Web Cacheはポピュラーなオブジェクトへのリクエストに素早く応答できるようになり、キャッシュ・ミスの回数も減ります。またWebアプリケーション・サーバーに送信されるリクエストの数も減ります。結果としてパフォーマンスが改善されます。

キャッシュ・クラスタは、クラスタの全メンバーと同期する単一の構成を使用します。この構成には、セキュリティ、セッション情報、キャッシュ・ルールなどの一般的な情報が含まれており、これらがクラスタの全メンバー間で同一になります。また、容量、管理用などのポート、リソース制限、ログ・ファイルなど、クラスタの各メンバーで異なるキャッシュ固有の情報も含まれています。

各メンバーは、キャッシュ・クラスタに追加される前に認証を受ける必要があります。認証では、追加されるOracle Web Cacheインスタンスの管理者ユーザー名とパスワードが、クラスタの管理者ユーザー名とパスワードと同じであることが必要です。

クラスタにキャッシュを追加すると、新しいクラスタ・メンバーのキャッシュ固有の情報がキャッシュ・クラスタの構成に追加されます。次に、この構成はOracle Web Cacheによってクラスタの全メンバーと同期されます。新しいメンバーを追加することは各Webキャッシュの相対許容量を変えることになるので、Oracle Web Cacheは容量についての情報を使用して、どのクラスタ・メンバーがどのコンテンツを所有するのかを再計算します。

他のクラスタ・メンバーの障害をキャッシュ・クラスタ・メンバーが検出した場合、残りのキャッシュ・クラスタ・メンバーは障害を起こしたメンバーのコンテンツ所有権を自動的に引き継ぎます。障害を起こしたキャッシュ・クラスタ・メンバーが再び使用可能になると、Oracle Web Cacheによって、コンテンツの所有権が再割当てされます。

Webキャッシュの1つをキャッシュ・クラスタから削除した場合、削除されたメンバーが所有していたコンテンツの所有権は残りのキャッシュ・クラスタ・メンバーに引き継がれます。さらに、削除されたメンバーに関する情報も構成から削除され、変更された構成内容が残りのキャッシュ・クラスタ・メンバーと同期されます。

キャッシュ・クラスタの場合、管理者は、無効化メッセージをすべてのキャッシュ・クラスタ・メンバーに伝播するか、各キャッシュ・クラスタ・メンバーに個別に送信するかを選択できます。

キャッシュ・クラスタには次のような利点があります。

- 高可用性
Oracle Web Cacheでは、キャッシュ・クラスタの有無にかかわらず、可用性が最も高くパフォーマンスが最も優れたWebサーバーにキャッシュ・ミスがダイレクトされるようになっています。キャッシュ・クラスタがある場合、Oracle Web Cacheは、キャッシュの障害検出とフェイルオーバーをサポートします。あるWebキャッシュに障害が発生した場合、キャッシュ・クラスタの他のメンバーがその障害を検出し、障害の発生したクラスタ・メンバーのキャッシュ可能なコンテンツの所有権を引き継ぎます。

- スケーラビリティとパフォーマンス
Webサイトのコンテンツを複数のキャッシュに分散させることにより、キャッシュ可能なコンテンツの容量と接続可能なクライアントの数が増加します。

複数のキャッシュをキャッシュ・クラスタ内に配置することで、より多くのCPUの処理能力が利用可能になります。複数のリクエストがパラレルに実行されるため、同時に処理可能なリクエスト数が増加します。

ネットワークのボトルネックによって、処理できるリクエストの数が制限されることがよくあります。複数のネットワーク・カードを持っているノードの場合でさえ、オペレーティング・システムの制限に遭遇することがあります。キャッシュを別々のノードに配置することで、より広いネットワーク帯域幅が使用可能になります。またリクエストの分散により、レスポンス時間も改善されます。

キャッシュ・クラスタを使用すると、Webアプリケーション・サーバーにルーティングされるリクエスト数が減少します。キャッシュからのコンテンツの取得は、(リクエストがクラスタ内の他のキャッシュにルーティングされる場合でも)Webアプリケーション・サーバーからコンテンツを実体化するよりも効率的です。

- Webアプリケーション・サーバーの負荷削減
キャッシュ・クラスタ環境では、ポピュラーなオブジェクトは複数のキャッシュに保存されます。キャッシュに障害が発生した場合でも、リクエストされたキャッシュ可能なオブジェクトが、動作している他のクラスタ・メンバーのキャッシュに保存されている可能性があります。その結果、キャッシュに障害が発生した場合でも、Webアプリケーション・サーバーにルーティングする必要のあるキャッシュ可能なオブジェクトのリクエスト数は減少します。

障害の発生したキャッシュが動作可能な状態になった直後には、キャッシュされているオブジェクトはありません。複数の独立したキャッシュをクラスタ化せずに使用している環境の場合、回復したキャッシュはキャッシュ・ミスをWebアプリケーション・サーバーにルーティングする必要があります。キャッシュ・クラスタ環境では、回復したキャッシュはクラスタ内の他のキャッシュにキャッシュ・ミスをルーティングすることができるので、Webアプリケーション・サーバーにかかる負荷が軽減されます。

キャッシュ・クラスタはシステム・リソースの使用率を最大限にします。キャッシュ・クラスタ内の各キャッシュが異なるノードにある場合、1つのキャッシュが1つのノードにあるよりも、多くのメモリーが使用可能です。使用可能なメモリーが増えると、Oracle Web Cacheがキャッシュできるコンテンツの量が増えるため、Webアプリケーション・サーバーへのリクエストが減ります。

- データ整合性の改善
キャッシュ・クラスタの全メンバーに対してOracle Web Cacheが適用する無効化ルールは1セットのみであり、また、それによって、無効化リクエストをキャッシュ・クラスタの全メンバーに伝播するのがより容易になるため、クラスタ内のすべてのキャッシュにおけるキャッシュ・データの整合性が得られやすくなります。

キャッシュ・クラスタ・メンバー間のリクエストをサポートせずに、無効化リクエストの伝播および構成変更の同期を実行できるように、キャッシュ・クラスタを構成できます。詳細は、第3.6.7項を参照してください。

- 管理のしやすさ
キャッシュ・クラスタではすべてのメンバーに対して1つの構成を使用するため、管理が容易です。たとえば、キャッシュ・ルールを1セットと無効化ルールを1セット指定するだけで済みます。Oracle Web Cacheは各クラスタ・メンバーに構成を同期化することにより、これらのルールをクラスタ全体に配布します。

3.4 ハードウェア・ロード・バランサを使用しない高可用性の概要

ハードウェア・ロード・バランサを使用できない環境では、次のオプションを構成することができます。

- 第3.4.1項「ソフトウェア・ロード・バランサ専用またはリバース・プロキシ専用としてのOracle Web Cache」

- 第3.4.2項「オペレーティング・システムによるロード・バランシングのサポート」

3.4.1 ソフトウェア・ロード・バランサ専用またはリバース・プロキシ専用としてのOracle Web Cache

Oracle Web Cacheの特殊なモードを構成し、Oracle Web Cacheを、HTTP通信のソフトウェア・ロード・バランサまたはオリジン・サーバーへのリバース・プロキシ専用に使用できます。このような構成モードは、次の作業に役立ちます。

- 小規模Webサイト、部門別WebサイトまたはテストWebサイトの管理

- Oracle PortalまたはOracle Single Sign-Onを使用した、ハードウェア・ロード・バランサとアプリケーション間のDMZトラフィックの管理

このモードでは、キャッシュはすべてキャッシュされず、次の機能はサポートされません。

- 圧縮: すべての圧縮設定が無視されます。

- ESI: ESIコンテンツが組み立てられません。

- キャッシュ階層: キャッシュ階層に2つのキャッシュを構成する場合、1つのキャッシュはロード・バランサとして構成できません。

単一のOracle Web Cacheサーバーをロード・バランサとして配置できます。ただし、この配置では、Oracle Web Cacheサーバーがアプリケーションのシングル・ポイント障害になります。かわりに、複数のOracle Web Cacheサーバーでキャッシュ・クラスタを構成し、オペレーティング・システムのロード・バランシング機能を併用できます。この項の前半で説明した許容量の変更に注意してください。

このモードでは、Oracle Web Cacheを構成して、ESIを使用するアプリケーションの前面または、他のOracle Web Cacheの前面に配置されているHTTP通信量のロード・バランシングが行えます。Oracle Web Cacheロード・バランサは、ESIコンテンツの処理や階層的なキャッシュに関与しません。たとえば、Oracle Portalの標準的な配置では、ESIアセンブリに使用される組込みのOracle Web Cacheがあります。このような構成では、ESIアセンブリに使用されるOracle Web Cacheをロード・バランサとして構成しないでください。

キャッシュや圧縮のサポートなど、その他のOracle Web Cache機能が必要な場合は、このモードを構成しないでください。かわりに、ハードウェア・ロード・バランサ、またはオペレーティング・システムのロード・バランシングのサポートを構成して、オリジン・サーバーへのリクエストを管理するロード・バランシング機能を使用してください。

詳細は、次を参照してください。

- Oracle Web Cacheをロード・バランサとして構成する方法は、第3.8項を参照してください。

- オペレーティング・システムのロード・バランシング機能を構成する方法は、第3.9項を参照してください。

- キャッシュ・クラスタを構成する方法は、第3.6項を参照してください。

- Oracle Web CacheをOracle PortalおよびOracle Single Sign-Onのリバース・プロキシとして使用する方法については、Oracle Fusion Middleware for Java EEエンタープライズ・デプロイメント・ガイドを参照してください。

3.4.2 オペレーティング・システムによるロード・バランシングのサポート

一部のオペレーティング・システムではロード・バランシングがサポートされているため、Oracle Web Cacheの可用性(特にキャッシュ・クラスタにおける)を向上させることができます。

オペレーティング・システムが1つのキャッシュで障害を検出した場合は、自動IP引継ぎを使用して、クラスタ構成内の残りのキャッシュに負荷を分散します。リクエストは特定のホストではなく仮想IPアドレスに送信されるため、1つのホストにアクセスできない場合でもリクエストは処理されます。

さらに、一部のオペレーティング・システムは、受信リクエストのロード・バランシング機能を備えています。この場合、複数のノード上にあるキャッシュ間で受信リクエストの負荷を分散するように、オペレーティング・システムを構成できます。

ネットワーク・ロード・バランサでは、ハードウェア・ロード・バランサで提供されるファイアウォールやping URLなどの機能を使用できません。ただし、提供されない機能に対するニーズが満たされている場合は、ネットワーク・ロード・バランサの使用を検討できます。

第3.9項では、各オペレーティング・システムでのネットワーク・ロード・バランサの構成方法を説明します。

3.5 セッション・バインディングの構成

セッション・バインディングの詳細は、第3.2項を参照してください。

セッション・バインディングを構成するには、一連のセッション・バインディング・ルールを指定してサイトに適用します。デフォルトでは、サイトはデフォルトのルールを使用するように構成されます。デフォルト・ルールを使用するか、サイト用にカスタマイズされた別のルールを選択できます。

デフォルトのセッション・バインディング・ルールの値を変更する場合は、このルールが現在構成されているすべての名前付きサイトでセッション・バインディングが必要であることを確認してください。一部のサイトでセッション・バインディングが不要な場合は、デフォルト・ルールの値を変更せず、必要なサイトに対してセッション・バインディング設定を指定してください。

セッション・バインディングを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。

3. 「サイト」リストから、カスタマイズされたセッション・バインディングを作成するサイトを選択します。
定義済サイトと一致しないリクエストのデフォルト設定を指定するには、「グローバル」を選択します。サイトにカスタマイズされたセッション・バインディングを指定しない場合は、「グローバル設定を使用」オプションをクリックして「グローバル」に指定する設定を適用できます。「グローバル」には、デフォルトで「セッション・バインディング無効化」が選択されています。このデフォルト設定を変更するには、「サイト」リストから「グローバル」を選択し、他のいずれかのセッション・バインディング設定を選択します。

4. 「セッション定義」表でセッション定義を作成します。第2.12項を参照してください。

- グローバル設定を使用: 「サイト」リストの「グローバル」に構成したセッション・バインディング設定を適用するには、このオプションを選択します。

デフォルトでは、すべてのリクエストのセッション・バインディングが無効になります。「グローバル」には、デフォルトで「セッション・バインディング無効化」オプションが選択されています。最初にサイトを作成すると、デフォルトでは、グローバルのセッション・バインディング設定を使用するように設定されます。

- セッション・バインディング無効化: セッション・バインディングを無効にするには、このオプションを選択します。これはグローバル・サイトのデフォルト設定です。このデフォルト設定を変更するには、「サイト」リストから「グローバル」を選択し、他のいずれかのセッション・バインディング設定を選択します。

- Set-Cookieを使用したCookieに基づくセッション・バインディング: クライアントでCookieがサポートされ、オリジン・サーバーでセッションの状態に1つ以上のCookieが使用される場合、このオプションを選択します。Oracle Web Cacheは、独自のCookieを使用してセッションをトラッキングします。このCookieは、ルーティング情報を含んでいて、Oracle Web Cacheとクライアントのブラウザとの間で維持されます。クライアント/サーバーのバインディングは、アプリケーション・サーバーがクライアントに送信する最初のCookieによって開始されます。

- セッションを使用したバインド: このオプションを選択して次の手順を実行し、特定セッションのバインディングを有効にします。

1. 「セッション名」リストから、セッションを選択して特定セッションのバインディングを有効にします。

2. 「セッション・バインディング方式」リストから、選択したセッション定義のバインディング方式を選択します。
- Cookieベース: クライアントがCookieをサポートしている場合に選択します。Oracle Web Cacheは、独自のCookieを使用してセッションをトラッキングします。このCookieは、ルーティング情報を含んでいて、Oracle Web Cacheとクライアントのブラウザとの間で維持されます。

- セッション・バインディングIAS: アプリケーションがOC4Jベースの場合に選択します。Oracle Web Cacheは、各リクエストのルーティング情報をOracle HTTP Server経由でOC4Jに転送します。

- 内部-トラッキング: クライアントがCookieをサポートせず、アプリケーションがOracle HTTP ServerベースでもOC4Jベースでもない場合に選択します。このオプションは、Oracle Web Cacheの以前のリリースとの下位互換性のために用意されています。Oracle Web Cacheはメモリー内にルーティング表を保持し、この表の各エントリによってセッションIDがオリジン・サーバーにマップされます。ルーティング表は、クラスタ・ノード間では共有されません。このオプションを選択し、キャッシュ・クラスタ構成を使用する場合は、ロード・バランサ・レイヤーでもバインドを行う必要があります。

5. 「適用」をクリックして変更を送信します。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

3.6 同一のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成

Webサイトの可用性とスケーラビリティを高めるために、Oracle Web Cacheの複数のインスタンスをキャッシュ・クラスタのメンバーとして動作させるように構成することができます。キャッシュ・クラスタの詳細は、第3.3項を参照してください。

キャッシュ・クラスタを構成するには、複数のOracle Web Cacheインスタンスをキャッシュ・クラスタのメンバーとして構成し、クラスタのプロパティを指定します。

キャッシュ・クラスタでは、現在のキャッシュ(クライアント・ブラウザが接続しているキャッシュ)からすべてのクラスタ・メンバーに同期化される1つの構成を使用します。この構成には、すべてのクラスタ・メンバーで同一の設定と、各クラスタ・メンバーのキャッシュ固有の設定が含まれます。

この項では、すべてのキャッシュが同一のOracle WebLogic Serverに関連付けられている環境でキャッシュ・クラスタを構成する際に役に立つ次の項目について説明します。各項目ではFusion Middleware Controlを使用してクラスタを構成する方法が説明されており、すべてのキャッシュ・メンバーが同一のOracle WebLogic Serverを使用する必要があります。

- 第3.6.1項「構成の前提条件」

- 第3.6.2項「フェイルオーバーのしきい値と許容量設定の理解」

- 第3.6.3項「作業1: クラスタへのキャッシュの追加とプロパティの構成」

- 第3.6.4項「作業2: セッション・バインディングのトラッキングの有効化」

- 第3.6.5項「作業3: クラスタ・メンバーへの構成の同期」

また、クラスタの構成方法に関する次の情報を参照してください。

- 第3.6.6項「クラスタからのキャッシュ・メンバーの削除」

- 第3.6.7項「管理および無効化のみのクラスタの構成」

キャッシュが別のOracle WebLogic Serverに関連付けられている構成に対してキャッシュ・クラスタを構成する場合は、第3.7項の説明に従って、Oracle Web Cache Managerを使用してクラスタを構成します。

3.6.1 構成の前提条件

キャッシュ・クラスタはOracle Web Cacheの複数のインスタンスで構成されるため、キャッシュ・クラスタを設定するには、Oracle Web Cacheの複数のインスタンスが1つ以上のノードにインストールされている必要があります。各インスタンスは同一バージョンのOracle Web Cacheであることが必要です。また、クラスタ・メンバー間で、Oracle Web Cache管理者のパスワードと無効化ユーザーinvalidatorのパスワードが同じである必要があります。パスワードが異なる場合は、キャッシュのadminサーバーに接続して、第5.2項で説明されている手順に従って、管理者パスワードを変更してください。

3.6.2 フェイルオーバーのしきい値と許容量設定の理解

この項では、構成を容易にするために、キャッシュ・クラスタとそのメンバーに対する主要な構成設定項目について説明します。

- 第3.6.2.1項「キャッシュ・クラスタのフェイルオーバーのしきい値」

- 第3.6.2.2項「キャッシュ・クラスタ・メンバーの許容量」

3.6.2.1 キャッシュ・クラスタのフェイルオーバーのしきい値

キャッシュ・クラスタのプロパティの設定時に、フェイルオーバーのしきい値を設定します。この設定は、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を示します。つまり、Oracle Web Cacheは、障害の発生したメンバーに対して一定の回数だけ連続してリクエストを再試行したあとに、そのキャッシュ・メンバーが停止しているとみなします。Oracle Web Cacheが再試行を許可されている回数を「フェイルオーバーのしきい値」といいます。

Oracle Web Cacheでは、次のような場合に、他のキャッシュ・クラスタ・メンバーへのリクエストが失敗したとみなします。

- ネットワーク・エラーが発生した場合

- HTTPレスポンスのステータス・コードが「500 内部サーバー・エラー」、「502 不正なゲートウェイ」、「503 - サービスが使用できません」、「504 - ゲートウェイ・タイムアウト」または100未満のいずれかである場合

Oracle Web Cacheでは、リクエストが失敗するたびに、そのクラスタ・メンバーのエラー・カウンタの数値が増えます。エラー・カウンタはクラスタ・メンバーごとに1つずつ保持されます。リクエストがクラスタ・メンバーによって正常に処理されると、Oracle Web Cacheでエラー・カウンタがリセットされます。

カウンタがフェイルオーバーのしきい値に達すると、Oracle Web Cacheはそのキャッシュ・クラスタ・メンバーに障害が発生したとみなします。このため、Oracle Web Cacheは残りのキャッシュ・クラスタ・メンバーの相対許容量を再計算します。次に、キャッシュのコンテンツの所有権を割り当てなおします。

キャッシュ・クラスタ・メンバーに障害が発生すると、Oracle Web Cacheはキャッシュ・クラスタ・メンバーのポーリングを開始します。ポーリングは、指定されたping URLにリクエストを送信することで行われます。キャッシュ・クラスタ・メンバーからのレスポンスの受信に成功すると、Oracle Web Cacheはそのキャッシュ・クラスタ・メンバーが使用可能になったとみなします。そして、すべてのキャッシュ・クラスタ・メンバーの相対許容量を再計算して、キャッシュのコンテンツの所有権を割り当てなおします。

3.6.2.2 キャッシュ・クラスタ・メンバーの許容量

キャッシュ・クラスタ・メンバーの構成時に、メンバーに適用する許容量を指定します。

Oracle Web Cacheでは、許容量が次の2通りの方法で使用されます。

- 他のすべてのキャッシュ・クラスタ・メンバーからこのキャッシュ・クラスタ・メンバーへの同時接続数を示す絶対許容量を設定する
この接続は、他のキャッシュ・クラスタ・メンバーから、所有コンテンツに対するリクエストを受信するために使用されます。接続数は、その他のクラスタ・メンバーの間で振り分けられます。たとえば、3つのキャッシュから構成されるクラスタにおいて、Cache_Aの許容量が50、Cache_Bから開くことのできるCache_Aへの接続数が25、Cache_Cから開くことのできるCache_Aへの接続数が25である場合について考えてみます。

他のキャッシュ・クラスタ・メンバーのキャッシュにデータがほとんど、あるいはまったく格納されていない場合には(そのクラスタ・メンバーが初めて起動されたとき、障害から回復したとき、無効化処理を実行した後など)、多くの接続が使用されます。この期間中、クラスタ・メンバーはリクエストの多くを他のメンバー、つまりコンテンツの所有者に送信します。多くの場合、このようなリクエストはオリジン・サーバーへのリクエストよりも速く処理されます。接続数を多く設定すると、この期間中のパフォーマンスが向上し、キャッシュを完全にロードするまでの時間が短縮されます。キャッシュが完全にロードされると、使用される接続の数は少なくなります。未使用の接続に対してのオーバーヘッドはありません。

- 各キャッシュ・クラスタ・メンバーの相対許容量を設定する
キャッシュ・クラスタ・メンバーの容量は、すべてのアクティブなキャッシュ・クラスタ・メンバーの合計容量に対して重み付けされます。容量を設定すると、Oracle Web Cacheによって、クラスタ・メンバーに所有権の配列の割合が割り当てられます。これは、クラスタ・メンバーが所有するキャッシュ・コンテンツの量を示します。割合は、次の式を使用して計算されます。

cluster_member_capacity / total_capacity_of_all_active_cluster_members

たとえば、キャッシュ・クラスタ・メンバーCache_Aの許容量が100、キャッシュ・クラスタ・メンバーCache_Bの許容量が300で、許容量の合計が400である場合、Cache_Aには25パーセントの所有率が割り当てられ、Cache_Bには75パーセントの所有率が割り当てられます。これは、Cache_Aがキャッシュ・コンテンツの25パーセントを所有することを意味しています。

相対許容量を計算する場合、Oracle Web Cacheはアクティブなクラスタ・メンバーの許容量に基づいて計算を行い、障害が発生しているとみなしたクラスタ・メンバーの許容量は計算に入っていない点に注意してください。

各キャッシュ・クラスタ・メンバーの初期許容量は、「最大着信接続数」の設定の10パーセントに設定します。

アプリケーションの必要許容量およびヒット率についてデータが蓄積されたら、許容量を微調整します。これらの2つの想定をキャッシュ・クラスタに適用したら、次の計算式を使用して、各クラスタ・メンバーの許容量を決めます。

1. 着信通信量を、すべてのキャッシュ・クラスタ・メンバーに対して平等に配分します。

2. コンテンツの所有権を、すべてのキャッシュ・クラスタ・メンバーに対して平等に配分します。

次の計算式で、デフォルト値またはmax_incoming_connections計算式の値の最大値を選択します。

max(default_value, (max_incoming_connections * (cacheable_misses%/100) * (number_of_caches - 1) / number_of_caches))

この計算式の詳細は、次のとおりです。

- default_valueは次のとおりです。

- 本番環境の場合は100

- テスト環境の場合は30

- 無効化のみのクラスタの場合は0

許容量が増えると、Oracle Web Cacheが必要とするファイル記述子の数も増えます。

無効化のみのクラスタの詳細は、第3.6.7項を参照してください。

- max_incoming_connectionsは、Fusion Middleware Controlの「リソース制限」ページにある「最大着信接続数」の設定です。

- cacheable_misses%は、Oracle Web Cacheで即座には処理されず、オリジン・サーバーからコンテンツをフェッチした後にOracle Web Cacheで処理されたキャッシュ可能なオブジェクトに対するリクエストのパーセンテージです。
「キャッシュ可能ミス」の設定は、Fusion Middleware Controlの「WebCache統計」ページにあります。

たとえば、キャッシュ・クラスタが4つのメンバーで構成されているとします。最大着信接続数が1500、キャッシュ可能ミス率が30パーセントでOracle Web Cacheが実行されている場合、この構成に対する容量を算出する計算式は次のようになります。

(1500 * (30/100) * (4 - 1) / 4

計算結果は337.5になります。これを切り上げて338とし、各キャッシュ・クラスタ・メンバーの容量にこの値を入力します。

1500 * .3 * 3 / 4 = 337.5

クラスタ・メンバーに許容量0(ゼロ)を割り当てると、そのクラスタ・メンバーは、他のクラスタ・メンバーからのリクエストを受信しません。ただし、コンテンツの所有者である他のクラスタ・メンバーへのリクエストの転送は行います。すべてのクラスタ・メンバーに許容量0(ゼロ)を割り当てた場合は、クラスタ・メンバー間でリクエストが転送されません。許容量が0に設定されている場合でも、構成は同期可能で、Oracle Web Cacheは無効化リクエストをクラスタ・メンバーに自動的に伝播できます。

3.6.3 作業1: クラスタへのキャッシュの追加とプロパティの構成

クラスタにキャッシュを追加するには、第3.6.1項で説明した条件を満たしている必要があります。

Fusion Middleware Controlを使用してクラスタにキャッシュ・メンバーを追加するには:

1. Oracle Web Cacheインスタンスについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。

3. 追加するキャッシュ・メンバーごとに、次の手順を実行します。

1. 「追加」をクリックします。

2. 「コンポーネント」フィールドに、キャッシュ・メンバーの名前を入力します。
「容量」フィールドには、デフォルト値が自動的に入力されます。この値は変更できます。許容量の詳細は、第3.6.2項を参照してください。

4. 「フェイルオーバーのしきい値」フィールドに、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を入力します。
デフォルトの許容連続失敗回数は、5です。

このフィールドの詳細は、第3.6.2項を参照してください。

5. 「pingのURL」フィールドに、キャッシュ・クラスタ・メンバーが、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーとの通信を試みるときに使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存されているURLを使用してください。デフォルトは、キャッシュに格納される_oracle_http_server_webcache_static_.htmlです。

6. 「pingの間隔」フィールドに、クラスタ・メンバーが障害の発生したクラスタ・メンバーとの通信を試みる間隔(秒)を入力します。
ほとんどの場合、デフォルトの10秒が適切な間隔です。

7. 「適用」をクリックします。

3.6.4 作業2: セッション・バインディングのトラッキングの有効化

リクエストは元々は1つのキャッシュ・クラスタ・メンバーのみを経由してルーティングされますが、キャッシュ・クラスタでは、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを判別できる必要があります。

第3.6.3項でプロパティを設定したOracle Web Cacheについて、セッション・バインディング方式がCookieベースまたはセッション・バインディングIASのセッション・バインディングを構成します。「内部-トラッキング」オプションはキャッシュ・クラスタでは機能しないため、使用しないでください。

Cookieベースの方式を使用するセッション・バインディングを構成する方法は、第3.5項を参照してください。

3.6.5 作業3: クラスタ・メンバーへの構成の同期

クラスタに変更を加えて変更を適用すると、Oracle Web Cacheによって新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。すべてのクラスタ・メンバーに影響を及ぼすような変更を加えた場合は、構成を同期し、クラスタ・メンバーを再起動する必要があります。

Fusion Middleware Controlを使用して、新しく追加したキャッシュ・メンバーからクラスタ内の他のキャッシュへ構成を同期するには:

1. 第3.6.3項でプロパティを設定したOracle Web Cacheについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。

2. 「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。

3. クラスタ内の他のキャッシュ・メンバーを選択し、「同期化」をクリックします。

4. すべてのキャッシュ・メンバーを選択し、キャッシュでの操作開始時間をずらす間隔を選択し、「起動」をクリックします。

これで、キャッシュ・クラスタを使用する準備が整いました。

3.6.6 クラスタからのキャッシュ・メンバーの削除

クラスタからキャッシュ・メンバーを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。

Fusion Middleware Controlを使用してキャッシュをクラスタから削除するには:

1. クラスタから削除するキャッシュを除くOracle Web Cacheインスタンスについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。

3. 削除するキャッシュを選択し、「削除」をクリックします。

4. クラスタ内の他のキャッシュ・メンバーを選択し、「同期化」をクリックします。

5. 他のキャッシュが選択されている状態で、「再起動」をクリックします。
これで、クラスタ内の残りのすべてのキャッシュは、削除したキャッシュをクラスタの一部とみなさなくなります。ただし、削除されたキャッシュ自体は、依然としてクラスタの一部と認識しています。この状況は次のステップで修正されます。

6. クラスタから削除するキャッシュについて、Fusion Middleware Controlの「Webキャッシュ・メンバー」ページにナビゲートします。

7. 「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページにキャッシュのすべてのメンバーが表示されます。

8. 現在のキャッシュ以外のキャッシュを選択して、「削除」をクリックします。「クラスタ・メンバー」リストが現在のキャッシュのみになるまで、この手順を繰り返します。

9. 「再起動」をクリックします。

3.6.7 管理および無効化のみのクラスタの構成

構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。

この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)

これらのキャッシュを1つのクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。

1. 第3.6.3項および第3.6.4項の説明に従って、クラスタを作成し、メンバーを追加します。ただし、次の設定は異なります。

- 各クラスタ・メンバーに対して、許容量を0(ゼロ)に設定します。

- 「クラスタ・プロパティ」セクションで、「任意のクラスタ・メンバーに送信された無効化リクエストは、すべてのクラスタ・メンバーに伝播されます。」というオプションを選択します。

2. 第3.6.5項の説明に従って、構成をすべてのクラスタ・メンバーに同期します。

3.7 非関連キャッシュまたは別のOracle WebLogic Serverを使用するキャッシュに対するキャッシュ・クラスタの構成

この項では、すべての非関連キャッシュが別のOracle WebLogic Serverを使用している構成でキャッシュ・クラスタを構成する際に役に立つ次の項目について説明します。各項目ではOracle Web Cache Managerを使用してクラスタを構成する方法が説明されています。

- 第3.7.1項「作業1: キャッシュ・クラスタ設定の構成」

- 第3.7.2項「作業2: クラスタへのキャッシュの追加」

- 第3.7.3項「作業3: セッション・バインディングのトラッキングの有効化」

- 第3.7.4項「作業4: クラスタ・メンバーへの構成の同期」

また、クラスタの構成方法に関する次の情報を参照してください。

- 第3.7.5項「クラスタからのキャッシュの削除」

- 第3.7.6項「管理および無効化のみのクラスタの構成」

複数のキャッシュが同一のOracle WebLogic Serverに関連付けられている環境でキャッシュ・クラスタを構成するには、第3.6項の説明に従い、Fusion Middleware Controlを使用してクラスタを構成します。

3.7.1 作業1: キャッシュ・クラスタ設定の構成

Oracle Web Cache Managerを使用してキャッシュ・クラスタの設定を構成するには:

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Clustering」を選択します。第2.7.2項を参照してください。
「Clustering」ページが表示されます。「General Cluster Information」セクションにフェイルオーバーおよび無効化の同期についてのクラスタ全体のデフォルト値が表示されます。「Cluster Members」表に現在のキャッシュ(接続しているキャッシュ)が唯一のクラスタ・メンバーとして表示されます。クラスタ・メンバーが1つのみの場合は、クラスタ情報が無視されます。

2. 「Clustering」ページの「General Cluster Information」セクションで「Edit」をクリックします。
「Edit General Cluster Information」ダイアログ・ボックスが表示されます。

3. 「Cluster Name」フィールドにクラスタ名を入力します。

4. 「フェイルオーバーのしきい値」フィールドに、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を入力します。
デフォルトの許容連続失敗回数は、5です。

このフィールドの詳細は、第3.6.2項を参照してください。

5. 「pingのURL」フィールドに、キャッシュ・クラスタ・メンバーが、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーとの通信を試みるときに使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存されているURLを使用してください。デフォルトは、キャッシュに格納される_oracle_http_server_webcache_static_.htmlです。

6. 「pingの間隔」フィールドに、クラスタ・メンバーが障害の発生したクラスタ・メンバーとの通信を試みる間隔(秒)を入力します。
ほとんどの場合、デフォルトの10秒が適切な間隔です。

7. 「Propagate Invalidation」フィールドで「Yes」または「No」を選択して、キャッシュ・クラスタ・メンバーからの無効リクエストをすべて他のキャッシュ・クラスタ・メンバーと同期するかどうかを指定します。

8. 「Submit」をクリックします。

9. 「Clustering」ページの「Cluster Name」表に、現在のキャッシュのデフォルト値が表示されます。キャッシュを選択し、「Edit Selected」をクリックします。
「Edit Cluster Member」ダイアログ・ボックスが表示されます。

10. 「Cache Name」フィールドに、Oracle Web Cacheインスタンスの名前を入力します。キャッシュ・クラスタ内の他のキャッシュと重複しない名前を入力する必要があります。

11. デフォルトでは、「Host Name」フィールドにはOracle Web Cacheがインストールされているノードのホスト名が表示されます。通常は、このフィールドを変更する必要がありません。

12. デフォルトでは、「Oracle Home」フィールドには、Oracle Web CacheがインストールされているOracleホームのファイル仕様が表示されます。通常は、このフィールドを変更する必要がありません。「Host Name」と「Oracle Home」の組合せはキャッシュ・クラスタ内で一意である必要があります。

13. 「Capacity」フィールドに、Oracle Web Cacheで保持できる他のキャッシュ・クラスタ・メンバーからの同時着信接続数を入力します。
このフィールドの詳細は、第3.6.2項を参照してください。

14. 「Submit」をクリックします。
これで、クラスタ内に1つのキャッシュ(現在のキャッシュ)が設定されました。ただし、クラスタ情報は、クラスタ内に複数のOracle Web Cacheシステム・コンポーネントが設定されるまで無視されます。

3.7.2 作業2: クラスタへのキャッシュの追加

クラスタにキャッシュを追加するには、第3.6.1項で説明した条件を満たしている必要があります。

Oracle Web Cache Managerを使用してキャッシュをクラスタに追加するには:

1. ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。

2. 「Clustering」ページの「Cluster Members」セクションで、「Add」をクリックします。
「Add Cache to Cluster」ダイアログ・ボックスが表示されます。

3. 「Host Name」フィールドに、クラスタに追加するキャッシュのホスト名を入力します。

4. 「Admin Port」フィールドに、クラスタに追加するキャッシュの管理ポートを入力します。
管理ポートは、管理リクエストのリスニング・ポートです。

5. 「Protocol for Admin Port」フィールドで「HTTP」または「HTTPS」を選択して、HTTPまたはHTTPSクライアント・リクエストを受け入れます。

6. 「Cache Name」フィールドにキャッシュの名前を入力します。キャッシュ・クラスタ内の他のキャッシュと重複しない名前を入力する必要があります。

7. 「Capacity」フィールドに、Oracle Web Cacheで保持できる他のキャッシュ・クラスタ・メンバーからの同時着信接続数を入力します。
このフィールドの詳細は、第3.6.2項を参照してください。

8. 「Submit」をクリックします。
これでキャッシュはクラスタの一部となり、「Cluster Member」表に表示されます。

9. さらにOracle Web Cacheインスタンスをキャッシュ・クラスタに追加するには、ステップ2から8を繰り返します。

10. キャッシュ・クラスタへのメンバーの追加が完了したら、「Apply Changes」をクリックします。

新しいキャッシュ・クラスタ・メンバーのキャッシュ固有情報がクラスタ構成に追加されます。

「Add」を選択して、Oracle Web Cacheインスタンスをさらにクラスタに追加できます。「Edit」を選択して、キャッシュ・クラスタ・メンバーの設定を変更できます。「Delete Selected」を選択して、現在のキャッシュ以外のキャッシュ・クラスタ・メンバーを削除できます。

3.7.3 作業3: セッション・バインディングのトラッキングの有効化

リクエストは元々は1つのキャッシュ・クラスタ・メンバーのみを経由してルーティングされますが、キャッシュ・クラスタでは、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを判別できる必要があります。キャッシュ・クラスタ内のセッション・バインディングを構成するには、「Cookieベース」のセッション・バインディング・メカニズムを選択します。このメカニズムを設定することにより、セッション情報を追跡するCookieが追加されるため、すべてのクラスタ・メンバーによる読込みが可能になります。Oracle Web Cacheは、レスポンス内にSet-Cookieレスポンス・ヘッダーを含めます。これにより、クライアントからの後続リクエストにそのCookieが含まれます。Cookieから情報が提供されるため、初期リクエストを処理したキャッシュに関係なく、いずれのクラスタ・メンバーもバインディングを解決できます。

Cookieベースの方式を使用するセッション・バインディングを構成する方法は、第3.5項を参照してください。

3.7.4 作業4: クラスタ・メンバーへの構成の同期

クラスタに変更を加えて変更を適用すると、Oracle Web Cacheによって新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。すべてのクラスタ・メンバーに影響を及ぼすような変更を加えた場合は、構成を同期し、クラスタ・メンバーのキャッシュ・サーバー・プロセスを再起動する必要があります。

Oracle Web Cache Managerを使用して、構成を新しいクラスタ・メンバーに同期するには:

1. ナビゲータ・フレームで、「Operations」→「Cache Operations」を選択します。
「Cache Operations」ページが表示されます。「Operation Needed」列に、構成を同期すべきキャッシュが示されます。

2. 構成をすべてのキャッシュ・クラスタ・メンバーに同期します。

1. 「Operate On」フィールドで「All caches」を選択します。

2. 「Interval」で「Immediate」を選択します(同期にはその他の間隔は使用できません)。

3. 「Propagate」をクリックします。

(一度に1つのクラスタ・メンバーに構成を同期することもできます。その場合は、「Operate On」フィールドで「Selected cache」をクリックして、「Propagate」をクリックします)。

操作が完了すると、「Cache Operations」ページの「Operation Needed」列に再起動を必要とするクラスタ・メンバーが示されます。

3. すべてのクラスタ・メンバーを停止して再起動します。

1. 「Operate On」フィールドで「All caches」を選択します。

2. キャッシュに対する操作を時間差をつけて開始するために「Interval」を選択し、「Restart」をクリックします。

(一度に1つのクラスタ・メンバーを再起動することもできます。その場合は、「Operate On」フィールドで「Selected cache」を選択して、「Restart」をクリックします。

操作が完了すると、「Cache Operations」ページの「Operation Needed」列に必要な操作がないことが示されます。これで、キャッシュ・クラスタを使用する準備が整いました。

3.7.5 クラスタからのキャッシュの削除

クラスタからキャッシュを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。

Oracle Web Cache Managerを使用してクラスタからキャッシュを削除するには:

1. クラスタから削除するキャッシュを除く、クラスタ内のキャッシュのOracle Web Cache ManagerのURLを入力します。

2. ナビゲータ・フレームで「Properties」→「Clustering」を選択します。

3. 「Clustering」ページの「Cluster Members」セクションで、クラスタから削除するキャッシュを選択して「Delete Selected」をクリックします。

4. Oracle Web Cache Managerのメイン・ウィンドウで、「Apply Changes」をクリックします。

5. 変更内容を、残りのキャッシュ・クラスタ・メンバーに同期します。

1. ナビゲータ・フレームで「Operations」→「Cache Operations」を選択します。

2. 「Operate On」フィールドで「All caches」を選択します。

3. 「Interval」で「Immediate」を選択します

4. 「Propagate」をクリックします。
変更内容が、削除されたクラスタ・メンバー以外の残りのすべてのクラスタ・メンバーと同期されます。

6. すべてのクラスタ・メンバーを再起動します。

1. 「Cache Operations」ページの「Operate On」フィールドで「All caches」を選択します。

2. キャッシュに対する操作を時間差をつけて開始するために「Interval」を選択し、「Restart」をクリックします。

これで、クラスタ内の残りのすべてのキャッシュは、削除したキャッシュをクラスタの一部とみなさなくなります。ただし、削除されたキャッシュ自体は、依然としてクラスタの一部と認識しています。この状況を修正するには、次のステップを実行します。

7. クラスタから削除したキャッシュのOracle Web Cache ManagerのURLを入力します。

8. ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。「Cluster Members」セクションには、引き続きクラスタの全メンバーが表示されます。

9. 「Clustering」ページの「Cluster Members」セクションで、現在のキャッシュ以外の各キャッシュを選択して「Delete Selected」をクリックします。クラスタ・メンバー・リストが現在のキャッシュのみになるまで、操作を繰り返します。

10. Oracle Web Cache Managerのメイン・ウィンドウで、「Apply Changes」をクリックします。

11. ナビゲータ・フレームで「Operations」→「Cache Operations」を選択します。

12. キャッシュを選択して「Restart」をクリックします。

3.7.6 管理および無効化のみのクラスタの構成

構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。

この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)

これらのキャッシュを1つのクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。

1. 第3.7.1項および第3.7.2項の説明に従ってクラスタを作成し、メンバーを追加します。ただし、次の設定は異なります。

2. 各クラスタ・メンバーに対して、許容量を0(ゼロ)に設定します。(「Properties」→「Clustering」を選択します。次に、クラスタ・メンバーを選択して「Edit」をクリックします。「Edit Cluster Member」ダイアログ・ボックスで、「Capacity」を0に設定します)。

3. 第3.7.4項の説明に従って、構成をすべてのクラスタ・メンバーに同期します。

3.8 ソフトウェア・ロード・バランサとしてのOracle Web Cacheの構成

ハードウェアのロード・バランサを使用しない高可用性の概要は、第3.4項を参照してください。

単一のOracle Web Cacheサーバーをソフトウェア・ロード・バランサとして構成するには、次の手順を実行します。

1. 次の場所にあるwebcache.xmlをテキスト・エディタで開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

2. CACHE要素を探します。

3. ROUTINGONLY属性をCACHE要素に追加します。次に例を示します。

...
<CACHE WCDEBUGON="NO" CHRONOSONPERNODE="NO" CAPACITY="301" VOTES="1"
INSTANCENAME="instance_name" COMPONENTNAME="component_name"  ORACLEINSTANCE="instance" HOSTNAME="web_cache_host_name"
ORACLEHOME="directory" NAME="web_cache_name"
ROUTINGONLY="YES">
...

4. webcache.xmlを保存します。

5. 次のコマンドを使用してOracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

6. Oracle Web Cache Managerで「Apply Changes」ボタンおよび「Cancel Changes」ボタンの下に表示される次のステータス・メッセージを確認して、Oracle Web Cacheがロード・バランサ・モードで実行されていることを確認します。

Web Cache running in Routing Only Mode with current configuration

Fusion Middleware Controlでは、同等の検証ステータスは提供されません。

7. 第2.11.2項の説明に従って、オリジン・サーバーを構成します。

8. 第2.11.3項および第2.11.4項の説明に従って、サイト定義を作成してオリジン・サーバーにマップします。

9. アプリケーションの配置でセッションの振分けが必要な場合は、セッション・バインディングを有効化します。第2.12項を参照してください。

たとえば、図3-5に示すトポロジがあるとします。

図3-5 ロード・バランサとしてのOracle Web Cacheの配置

「図3-5 ロード・バランサとしてのOracle Web Cacheの配置」の説明

このトポロジを構成するには、次の手順を実行します。

1. Oracle Web Cacheサーバーwebche-hostのIPアドレスをwww.app1.company.comに登録します。

2. Oracle Web Cacheサーバーを次のように構成します。

1. 指定したリスニング・ポートでHTTPリクエストおよびHTTPSリクエストを受信します。

2. HTTPリクエストおよびHTTPSリクエストを、指定したリスニング・ポートからWebアプリケーション・サーバーapp1-host1およびapp1-host2に送信します。

3. app1-host1およびapp1-host2にマップされている、www.app1.company.comの仮想ホスト・サイト定義をマップします。

3.9 Microsoft Windowsネットワーク負荷分散の構成

ハードウェアのロード・バランサを使用しない高可用性の概要は、第3.4項を参照してください。

一部のMicrosoft Windowsプラットフォームでは、ハードウェア・ロード・バランサのかわりに、オペレーティング・システムのMicrosoftネットワーク負荷分散(NLB)コンポーネントを使用できます。NLBはMicrosoftクラスタリング・テクノロジの一部で、次のプラットフォームで使用できます。

- Windows 2000 Advanced Server

- Windows 2000 Datacenter Server

- Windows 2003(すべてのEdition)

ホストをクラスタとして構成し、ロード・バランシング機能を提供するようにオペレーティング・システムを構成します。次に、各ホストに対して次のステップを実行して、キャッシュ・クラスタ内のOracle Web Cacheが稼働しているホストに対してNLBを構成します。

1. 「スタート」→「設定」→「ネットワークとダイヤルアップ接続」を選択します。

2. ネットワーク・アダプタを選択します。次に、右クリックして「プロパティ」をクリックします。

3. 「プロパティ」ダイアログ・ボックスで、「ネットワーク負荷分散」を選択します。次に、「プロパティ」をクリックします。

4. 「ネットワーク負荷分散のプロパティ」ダイアログ・ボックスの「クラスタ パラメータ」タブで、次の手順を実行します。

1. 「プライマリ IP アドレス」に、クラスタのすべてのメンバーが共有する仮想IPアドレスを入力します。

2. 「サブネット マスク」に、仮想IPアドレスのサブネット・マスクを入力します。

3. 「フル インターネット名」に、仮想IPアドレスのフル・インターネット名を入力します。

4. 「ネットワーク アドレス」に表示された生成済アドレスをメモします。

5. 「マルチキャスト サポート」で「有効」をチェックします。

6. オプションで、「リモート パスワード」を入力し、「リモート制御」を有効にします。

5. 「ホスト パラメータ」タブを選択し、次の手順を実行します。

1. 「優先順位」に、1 - 32の間の整数を入力します。番号が小さいほど優先順位は高くなります。ポートの規則によってロード・バランシングされていないリクエストのホスト間でのデフォルト処理優先順位を設定します(ポートの規則の構成方法は、ステップ6を参照してください)。

2. 「クラスタの初期状態」で「アクティブ」をチェックします。この指定によって、Windows起動直後にこのホストがクラスタ配列に含まれます。

3. 「専用 IP アドレス」に、このホストのIPアドレスを入力します。

4. 「サブネット マスク」に、このホストのサブネット・マスクを入力します。

6. 「ポートの規則」タブを選択し、次の手順を実行します。

1. 「ポートの範囲」で、単一のポートの規則を使用して全クライアントのリクエストの負荷を分散するために、デフォルトのポートの範囲(1から65535)を使用します。アプリケーションによって異なるプロトコル、フィルタのモード、またはアフィニティが必要な場合は、複数のポートの規則を使用します。

2. 「プロトコル」で「TCP」を選択します。アプリケーションでUDPが必要なソフトウェアを使用する場合は、「両方」を選択します。

3. 「フィルタのモード」で「複数ホスト」を選択します。

4. 「アフィニティ」では、3つのオプションから1つを選択できます。「なし」を選択すると、すべてのホスト間ですべてのリクエストのロード・バランシングが行われます。「単一」を選択すると、特定のクライアントからのリクエストがすべて同じホストで処理されます。セッションの状態を維持する場合は、このオプションを使用します。「クラス C」を選択すると、TCP/IPクラスCアドレス範囲からのクライアントのリクエストがすべて同じホストで処理されます。

5. 「負荷配分」では、ホストで処理する負荷のパーセンテージを入力するか、「均一」を選択します。

クラスタ内のすべてのホストで、ポートの規則が同一であることが必要です。

Microsoftネットワーク負荷分散の詳細は、次のサイトでMicrosoft社のドキュメントを参照してください。

http://www.microsoft.com

4 リクエスト・フィルタリングの構成

この章では、Oracle Web Cacheで提供されるリクエスト・フィルタについて概説し、リクエスト・フィルタを有効にすることで一般的なHTTPリクエスト攻撃から保護する仕組みを説明します。

この章の項目は次のとおりです。

- 第4.1項「リクエスト・フィルタリングの概要」

- 第4.2項「リクエスト・フィルタのタイプ」

- 第4.3項「習得ルールについて」

- 第4.4項「次のみを監視モードについて」

- 第4.5項「特権IPフィルタのルールの構成」

- 第4.6項「クライアントIPリクエスト・フィルタのルールの構成」

- 第4.7項「メソッド・リクエスト・フィルタのルールの構成」

- 第4.8項「URLリクエスト・フィルタのルールの構成」

- 第4.9項「ヘッダー・リクエスト・フィルタのルールの構成」

- 第4.10項「問合せ文字列リクエスト・フィルタのルールの構成」

- 第4.11項「フォーマット・リクエスト・フィルタのルールの構成」

- 第4.12項「リクエスト・フィルタのルールの削除」

- 第4.13項「リクエスト・フィルタのタイプとルールの統計監視」

- 第4.14項「リクエスト・フィルタを構成する時間の削減」

4.1 リクエスト・フィルタリングの概要

Oracle Web Cacheには、オリジン・サーバー上の構成済サイトに対する受信HTTPまたはHTTPSリクエストをフィルタリングするためのリクエスト・フィルタが用意されています。

リクエスト・フィルタリングにより、管理者はWebサイトへのアクセスを制御できます。

- Webサイト内に悪意のあるコードを埋め込む攻撃。ユーザーがこのコードを実行すると、ユーザーの識別情報や個人情報が盗まれます。

- サイトでのソフトウェアの脆弱性を利用する攻撃。これにより攻撃者は、アプリケーション・サーバー上で任意のコードを実行できるようになります。

- アプリケーション・サーバーのリソースや帯域幅を効果的に消費する膨大な量の偽造リクエストを送信して他のユーザーがアクセスできなくなるようにすることで、Webサイトを使用不能な状態に陥れようとする攻撃。

また、リクエスト・フィルタリングでは、WebサイトまたはWebサイトの特定部分へのアクセスを許可するクライアントとリクエストを制御します。

Webサイトへの攻撃を防ぐには、一連のフィルタを有効にして、そのフィルタを通過したリクエストのみが処理されるようにします。各フィルタは、リクエストの許可または拒否を識別できるカスタマイズされたルールによって構成されます。

特定のサイトまたは未定義のサイトに対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

リクエスト・フィルタは、「リクエスト・フィルタ概要」ページに示された順序で処理されます。このページにアクセスするには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

図request_sum.gifの説明

「フィルタ」列でフィルタを選択し、そのフィルタに個別にルールを指定します。ルールを構成する際、Oracle Web Cacheでリクエストを照合する順序に基づいて、ルールに順序を付けます。キャッシュ・ルールに順序を付ける際は、許可ルールに拒否ルールよりも高い優先度を指定します。

フィルタのルールを構成し、そのルールを有効化または無効化したら、「リクエスト・フィルタ概要」ページに戻ってフィルタを有効にします。フィルタに対して「有効化」をクリックしないと、ルールを無効化することになり、Oracle Web Cacheではこのフィルタに構成したルールがすべて無視されます。

4.2 リクエスト・フィルタのタイプ

Oracle Web Cacheでは次のフィルタが提供されています。これらはそれぞれ、特定タイプのHTTPリクエストの脆弱性に重点を置いて設計されています。

- 特権IP

- クライアントIP

- メソッド

- URL

- ヘッダー

- 問合せ文字列

- フォーマット

特権IPフィルタは許可のみルールを許可し、ヘッダー、問合せ文字列およびフォーマット・フィルタは拒否のみルールを許可し、クライアントIP、メソッドおよびURLフィルタは許可ルールと拒否ルールの両方を許可します。ヘッダー、問合せ文字列およびフォーマット・フィルタのルールは相互に非依存であるため、許可ルールを許可すると他の拒否ルールをスキップする可能性があるためです。このため、これらのフィルタでは拒否ルールのみを許可します。

特権IP

特権IPフィルタにより、Oracle Web Cacheは他のリクエスト・フィルタリングをバイパスできます。このフィルタを使用して、指定した特権IPアドレスのアクセスを許可します。

クライアントIP

クライアントIPフィルタは、特定のIPアドレスへのサイト・アクセスを許可または拒否します。

これによりOracle Web Cacheでは、サイト内のサイトURL接頭辞へのアクセスを特定のIPアドレスのみに制限できます。このフィルタは、特定のIPアドレスからのクライアントがシステムに攻撃を仕掛けないように制限します。アクセスを制限しないと、アプリケーションや機密情報を格納したサイト領域にクライアントがアクセスできるようになります。Oracle Web Cacheがアクセスを拒否しない場合、特定のIPアドレスからの攻撃者が悪意のある攻撃を続行するおそれがあります。

IPアドレスおよびURLが一致する場合にリクエストを拒否するブラック・リスト、またはIPアドレスおよびURLが一致する場合にリクエストを許可するホワイト・リストを構成できます。

メソッド

メソッド・フィルタは、HTTPリクエスト・メソッドに基づいて、サイト・アクセスを許可または拒否します。たとえば、GETメソッドとPOSTメソッドのみが許可されている場合、Oracle Web Cacheはそれ以外のリクエストをすべて拒否します。

このフィルタにより、様々なHTTPメソッドを使用して制限付きファイルの読取りやファイルの変更を試みるクライアントから保護できます。HTTPリクエスト・メソッドだけでなく、URLを構成して、メソッドおよび指定したURLと一致するリクエストのみにルールを制限することができます。

URL(URL)

URLフィルタは、URLに基づいて、サイト・アクセスを許可または拒否します。

このフィルタにより、特定のURLを介したアプリケーション・サーバーへのインターネット攻撃から保護できます。

ヘッダー

ヘッダー・フィルタは、HTTPヘッダー値に基づいてサイト・アクセスを拒否します。HTTPヘッダー値だけでなく、URLを構成して、ヘッダー値および指定したURLと一致するリクエストのみにルールを制限することができます。

HTTPヘッダーおよびURLと一致する受信リクエストが、ルール内の式と比較されます。この式は部分文字列または正規表現です。部分文字列と正規表現のどちらの比較でも、リクエストのヘッダー値がルールの値式と一致する場合、ルールによりそのリクエストを拒否できます。

このフィルタにより、ヘッダー値を手動で作成してアプリケーションへの侵入を試みるクライアントや、ヘッダー値に不要なコンテンツを追加して送信するクライアントから保護できます。

問合せ文字列

問合せ文字列フィルタは、問合せ文字列パラメータに基づいてサイト・アクセスを拒否します。POSTリクエストの場合、Oracle Web Cacheは問合せ文字列(存在する場合)とPOST本体の両方をチェックします。問合せ文字列だけでなく、URLを構成して、問合せ文字列および指定したURLと一致するリクエストのみにルールを制限することができます。

問合せ文字列およびURLと一致する受信リクエストが、ルール内の式と比較されます。この式は部分文字列または正規表現です。部分文字列と正規表現のどちらの比較でも、リクエストの問合せ文字列がルールの値式と一致する場合、ルールによりそのリクエストを拒否できます。

このフィルタにより、問合せ文字列パラメータを手動で操作してサイトへの侵入を試みるクライアントや、パラメータ値に不要なコンテンツを追加して送信するクライアントから保護できます。

フォーマット

フォーマット・フィルタは、HTTPリクエストのフォーマットに基づいてサイト・アクセスを拒否します。このフィルタは、埋込みNULLバイト文字、厳密なエンコーディングおよび有効なUnicode、およびダブルURLエンコーディングをチェックします。Oracle Web Cacheは有効なタイプのフォーマットをそれぞれチェックして、フォーマットが無効な場合は、リクエストを拒否します。

このフィルタは、URLのコンポーネント(パス、ファイル名、問合せ文字列およびPOSTリクエストの場合はリクエスト・エンティティ本体)をチェックします。このフィルタにより、不正な形式のリクエストを送信したり、URLに想定外の文字列を挿入して送信したりすることでWebアプリケーションの中断を試みるハッカーから保護できます。

4.3 習得ルールについて

Oracle Web Cacheでは、メソッドとURLフィルタに対して習得ルールが自動的に作成されます。その後、作成された習得ルールを有効化できます。

新しいルールを保証する共通点があるかどうかを確認するために、フィルタの 「すべて検索」 ルールと一致するクライアント・リクエストが評価されます。これらの共通パターンは習得ルールとして表示されます。その後、これらの習得ルールを有効化するか無視するかを選択できます。構成でルールが有効化されたら、他のルールと同様に、ルールを有効化するか無効化するかを選択できます。学習したルールをアクティブ化しないように選択した場合でも、Oracle Web Cacheは引き続き、 「すべて検索」 ルールに該当するリクエストの共通パターンをすべて収集して評価します。

習得ルールを有効化する方法は、第4.7.1項および第4.8.1項を参照してください。

4.4 次のみを監視モードについて

フィルタのルールを構成する際、「次のみを監視」オプションを選択できます。ルールに対してこのオプションを有効にすると、Oracle Web Cacheではルールが無効化されたものとして扱われます。ただし、Oracle Web Cacheは統計内で一致を追跡し、冗長性が「TRACE」以上に設定されている場合にはイベント・ログに一致を書き込み、さらに一致する操作に対して監査ロギングが有効になっている場合には監査ログにも一致を書き込みます。

監視を有効にした場合、リクエストは許可されるので、「リクエスト統計」セクションで結果を調査できます。拒否ルールで「次のみを監視」をオフにすると、拒否アクションが実行されます。通常は、「次のみを監視」をオンに設定してルールと一致するアクティビティを確認します。結果が予期される場合は、「次のみを監視」を無効にしてルールのアクションを実行します。

4.5 特権IPフィルタのルールの構成

特権IPリクエスト・フィルタにより、Oracle Web Cacheは、特定の特権IPアドレスのすべてのリクエスト・フィルタをバイパスできます。特権IPアドレスからのリクエストはどれも、他のリクエスト・フィルタを通過しません。

特権IPリクエスト・フィルタの詳細は、第4.2項を参照してください。

特権IPリクエスト・フィルタを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「特権IP」リンクをクリックします。
「特権IPリクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「IPアドレス」フィールドにIPアドレスを入力します。クライアントのIPバージョン4またはIPバージョン6のアドレス・マスクとして入力してください。
IPアドレスの例は、第2.5項を参照してください。

3. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

4. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

5. 「適用」をクリックしてルール設定を保存します。

7. 追加のルールに対してステップ6を実行します。

8. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

9. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

10. 「特権IP」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

11. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.6 クライアントIPリクエスト・フィルタのルールの構成

クライアントIPリクエスト・フィルタは、アプリケーション・アクセスを特定のIPアドレスまたはIPアドレス範囲に制限します。アクセスを制限しないと、制限付きの情報へのアクセスや、特定のIPアドレスからの攻撃が可能となります。

クライアントIPリクエスト・フィルタの詳細は、第4.2項を参照してください。

クライアントIPリクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「クライアントIP」リンクをクリックします。
「クライアントIPリクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「IPアドレス」フィールドにIPアドレスを入力します。クライアントのIPバージョン4またはIPバージョン6のアドレス・マスクとして入力してください。
IPアドレスの例は、第2.5項を参照してください。

3. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

4. 「URL」フィールドに、選択した「URLタイプ」に基づいてオプションのURL文字列を入力します。URLを何も指定しないと、すべてのリクエストがチェックされます。これは、接頭辞/を付けてURLを指定した場合と同じです。
- パス接頭辞: オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。予約語には、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、カレット(^)、ドル記号($)およびバックスラッシュ(\)が含まれます。

- ファイル拡張子: ファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

- 正規表現: オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

5. 「URLタイプ」リストから、ルールのURLとリクエストのURLを比較する方法を選択します。
- パス接頭辞: パス接頭辞と一致するリクエストに対してアクセスを許可または拒否する場合に選択します。

- ファイル拡張子: 特定のファイル拡張子と一致するリクエストに対してアクセスを許可または拒否します。

- 正規表現: 正規表現の構文と一致するリクエストに対してアクセスを許可または拒否します。

6. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

7. IPアドレス・フィールドとURLフィールドに一致するリクエストをOracle Web Cacheで許可する場合は「許可」チェック・ボックスを選択します。IPアドレス・フィールドとURLフィールドに一致するリクエストをOracle Web Cacheで拒否する場合は、このチェック・ボックスを選択解除します。

8. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

9. 「適用」をクリックしてルール設定を保存します。

8. 追加のルールに対してステップ7を実行します。

9. 「すべて検索」ルールを変更します。このルールは、定義済ルールと一致しないすべてのリクエストに適用されることに注意してください。
許可ルールに加えて、「すべて検索」拒否ルールを作成することをお薦めします。

10. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

11. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

12. 「クライアントIP」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

13. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.7 メソッド・リクエスト・フィルタのルールの構成

メソッド・リクエスト・フィルタにより、Oracle Web CacheではHTTPリクエスト・メソッドに基づいてアクセスを制限できます。

メソッド・リクエスト・フィルタの詳細は、第4.2項を参照してください。

メソッド・リクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「メソッド」リンクをクリックします。
「メソッド・リクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 「定義済ルール」セクションで、新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「メソッド」フィールドに、GET、POST、PUTなどのHTTPリクエスト・メソッドを入力します。

3. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

4. 「URL」フィールドに、選択した「URLタイプ」に基づいてオプションのURL文字列を入力します。URLを何も指定しないと、すべてのリクエストがチェックされます。これは、接頭辞/を付けてURLを指定した場合と同じです。
- パス接頭辞: オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。予約語には、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、カレット(^)、ドル記号($)およびバックスラッシュ(\)が含まれます。

- ファイル拡張子: ファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

- 正規表現: オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

5. 「URLタイプ」リストから、ルールのURLとリクエストのURLを比較する方法を選択します。
- パス接頭辞: パス接頭辞と一致するリクエストに対してアクセスを許可または拒否する場合に選択します。

- ファイル拡張子: 特定のファイル拡張子と一致するリクエストに対してアクセスを許可または拒否します。

- 正規表現: 正規表現の構文と一致するリクエストに対してアクセスを許可または拒否します。

6. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

7. メソッド・フィールドとURLフィールドに一致するリクエストをOracle Web Cacheで許可する場合は「許可」チェック・ボックスを選択します。メソッド・フィールドとURLフィールドに一致するリクエストをOracle Web Cacheで拒否する場合は、このチェック・ボックスを選択解除します。

8. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

9. 「適用」をクリックしてルール設定を保存します。

8. 追加のルールに対してステップ7を実行します。第4.7.1項で説明するように、習得ルールを追加することもできます。

9. 「すべて検索」ルールを変更します。このルールは、定義済ルールと一致しないすべてのリクエストに適用されることに注意してください。
許可ルールに加えて、「すべて検索」拒否ルールを作成することをお薦めします。

10. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

11. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

12. 「メソッド」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

13. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.7.1 メソッド・リクエスト・フィルタに対する習得ルールの有効化

「すべて検索」ルールから習得ルールがどのように収集されるかについては、第4.3項を参照してください。メソッド・リクエスト・フィルタに習得ルールを追加できます。

メソッド・リクエスト・フィルタに対して習得ルールを有効化するには、次の手順を実行します。

1. 「メソッド・リクエスト・フィルタ」ページに移動します。

2. 「学習したルール」セクションに習得ルールがいくつか提案されている場合は、このページをしばらく監視し、これらのルールの統計を監視します。有用な習得ルールがあると判断した場合、先に進みます。
すべて検索ルールに習得ルールが表示されない場合、習得ルールはありません。

3. 行を選択し、「定義済ルールにルールを追加」をクリックしてルールを有効化し、「定義済ルール」セクションに移動します。

4. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。

5. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.8 URLリクエスト・フィルタのルールの構成

URLリクエスト・フィルタにより、Oracle Web Cacheでは特定のサイトURLへのアクセスを許可または拒否できます。

URLリクエスト・フィルタの詳細は、第4.2項を参照してください。

URLリクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「URL」リンクをクリックします。
「URLリクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 「定義済ルール」セクションで、新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

3. 「URL」フィールドに、選択した「URLタイプ」に基づいてオプションのURL文字列を入力します。URLを何も指定しないと、すべてのリクエストがチェックされます。これは、接頭辞/を付けてURLを指定した場合と同じです。
- パス接頭辞: オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。予約語には、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、カレット(^)、ドル記号($)およびバックスラッシュ(\)が含まれます。

- ファイル拡張子: ファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

- 正規表現: オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

4. 「URLタイプ」リストから、ルールのURLとリクエストのURLを比較する方法を選択します。
- パス接頭辞: パス接頭辞と一致するリクエストに対してアクセスを許可または拒否する場合に選択します。

- ファイル拡張子: 特定のファイル拡張子と一致するリクエストに対してアクセスを許可または拒否します。

- 正規表現: 正規表現の構文と一致するリクエストに対してアクセスを許可または拒否します。

5. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

6. URLフィールドに一致するリクエストをOracle Web Cacheで許可する場合は「許可」チェック・ボックスを選択します。URLフィールドに一致するリクエストをOracle Web Cacheで拒否する場合は、このチェック・ボックスを選択解除します。

7. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

8. 「適用」をクリックしてルール設定を保存します。

8. 追加のルールに対してステップ7を実行します。第4.8.1項で説明するように、習得ルールを追加することもできます。

9. 「すべて検索」ルールを変更します。このルールは、定義済ルールと一致しないすべてのリクエストに適用されることに注意してください。
許可ルールに加えて、「すべて検索」拒否ルールを作成することをお薦めします。

10. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

11. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

12. 「URL」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

13. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.8.1 URLリクエスト・フィルタに対する習得ルールの有効化

「すべて検索」ルールから習得ルールがどのように収集されるかについては、第4.3項を参照してください。URLリクエスト・フィルタに習得ルールを追加できます。

URLリクエスト・フィルタに対して習得ルールを有効化するには、次の手順を実行します。

1. 「URLリクエスト・フィルタ」ページに移動します。第2.7.2項を参照してください。

2. 「学習したルール」セクションに習得ルールがいくつか提案されている場合は、このページをしばらく監視し、これらのルールの統計を監視します。有用な習得ルールがあると判断した場合、先に進みます。
すべて検索ルールに習得ルールが表示されない場合、習得ルールはありません。

3. 行を選択し、「定義済ルールにルールを追加」をクリックしてルールを有効化し、「定義済ルール」セクションに移動します。

4. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。

5. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.9 ヘッダー・リクエスト・フィルタのルールの構成

ヘッダー・リクエスト・フィルタにより、Oracle Web CacheではHTTPヘッダー値に基づいてアクセスを拒否できます。ヘッダー・リクエスト・フィルタのルールは、ホワイト・ボックス・リストに最も効果的です。

ヘッダー・リクエスト・フィルタの詳細は、第4.2項を参照してください。

ヘッダー・リクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「ヘッダー」リンクをクリックします。
「ヘッダー・リクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「ヘッダー名」フィールドに、HTTPリクエスト・ヘッダーの名前を入力します(例: Cookie)。

3. 「値式」フィールドに、受信リクエストとの比較に使用するヘッダーの値の式を入力します。部分文字列または正規表現で入力できます。

4. 「タイプ」リストで、「値式」フィールドに入力した一致評価基準のタイプ(部分文字列または正規表現)を選択します。

5. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

6. 「URL」フィールドに、選択した「URLタイプ」に基づいてオプションのURL文字列を入力します。URLを何も指定しないと、すべてのリクエストがチェックされます。これは、接頭辞/を付けてURLを指定した場合と同じです。
- パス接頭辞: オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。予約語には、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、カレット(^)、ドル記号($)およびバックスラッシュ(\)が含まれます。

- ファイル拡張子: ファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

- 正規表現: オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

7. 「URLタイプ」リストから、ルールのURLとリクエストのURLを比較する方法を選択します。
- パス接頭辞: パス接頭辞と一致するリクエストに対してアクセスを許可または拒否する場合に選択します。

- ファイル拡張子: 特定のファイル拡張子と一致するリクエストに対してアクセスを許可または拒否します。

- 正規表現: 正規表現の構文と一致するリクエストに対してアクセスを許可または拒否します。

8. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

9. 「値式」フィールドで指定した部分文字列または正規表現とヘッダー値が一致する受信リクエストを一致と見なす場合は、「見つかった場合は一致」チェック・ボックスを選択します。一致するリクエストが存在し、ルールが有効になっている場合は、フィルタによってそのリクエストが拒否されます。
受信リクエストのヘッダー値が「値式」フィールドに指定されている部分文字列または正規表現に一致しないことをチェックする場合は、Oracle Web Cacheの「見つかった場合は一致」チェック・ボックスの選択を解除してください。指定の文字列または式が見つからない場合のみ、対象リクエストが拒否されます。つまり、指定の文字列が見つかった場合はリクエストが許可されます。

「見つかった場合は一致」チェック・ボックスを選択してルールを作成し、その後、このチェック・ボックスを選択解除してルールを作成します。

10. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

11. 「適用」をクリックしてルール設定を保存します。

8. 追加のルールに対してステップ7を実行します。

9. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

10. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

11. 「ヘッダー」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

12. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.10 問合せ文字列リクエスト・フィルタのルールの構成

問合せ文字列リクエスト・フィルタにより、Oracle Web Cacheでは問合せ文字列パラメータ値に基づいてアクセスを拒否できます。

問合せ文字列リクエスト・フィルタの詳細は、第4.2項を参照してください。

問合せ文字列リクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「問合せ文字列」リンクをクリックします。
「問合せ文字列リクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 新しいルールを作成します。

1. 「作成」をクリックして、表に新しい行を作成します。

2. 「問合せ文字列式」フィールドに、受信リクエストと比較する問合せ文字列を入力します。部分文字列または正規表現で入力してください。

3. 「有効化」チェック・ボックスを選択して作成したルールを有効にします。このチェック・ボックスを選択解除すると、該当するルールが一時的に無効になります。ルール定義自体は失われません。

4. 「タイプ」リストで、「問合せ文字列式」フィールドに入力した一致評価基準のタイプ(部分文字列または正規表現)を選択します。

5. 「値式」フィールドで指定した部分文字列または正規表現と問合せ文字列が一致する受信リクエストを一致と見なす場合は、「見つかった場合は一致」チェック・ボックスを選択します。一致するリクエストが存在し、ルールが有効になっている場合は、フィルタによってそのリクエストが拒否されます。
受信リクエストの問合せ文字列が「値式」フィールドに指定されている部分文字列または正規表現に一致しないことをチェックする場合は、Oracle Web Cacheの「見つかった場合は一致」チェック・ボックスの選択を解除してください。指定の文字列または式が見つからない場合のみ、対象リクエストが拒否されます。つまり、指定の文字列が見つかった場合はリクエストが許可されます。

たとえば、「問合せ文字列式」としてabc、「タイプ」として部分文字列を指定し、「見つかった場合は一致」チェック・ボックスを選択しない場合は、問合せ文字列(POST本体)に文字列abcを含まないリクエストが拒否されます。文字列abcを含むリクエストは許可されます。

複数のルールを作成して、特定の文字列を含むリクエストを許可し、他の文字列を含むリクエストを拒否することができます。たとえば、「問合せ文字列式」でdef、「タイプ」で部分文字列を指定して第2のルールを作成し、「見つかった場合は一致」チェック・ボックスを選択した場合、問合せ文字列にabcを含むリクエストは許可されますが、defを含むリクエストは拒否されます。

6. 「URL」フィールドに、選択した「URLタイプ」に基づいてオプションのURL文字列を入力します。URLを何も指定しないと、すべてのリクエストがチェックされます。これは、接頭辞/を付けてURLを指定した場合と同じです。
- パス接頭辞: オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。予約語には、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、カレット(^)、ドル記号($)およびバックスラッシュ(\)が含まれます。

- ファイル拡張子: ファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

- 正規表現: オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

7. 「URLタイプ」リストから、ルールのURLとリクエストのURLを比較する方法を選択します。
- パス接頭辞: パス接頭辞と一致するリクエストに対してアクセスを許可または拒否する場合に選択します。

- ファイル拡張子: 特定のファイル拡張子と一致するリクエストに対してアクセスを許可または拒否します。

- 正規表現: 正規表現の構文と一致するリクエストに対してアクセスを許可または拒否します。

8. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

9. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

10. 「適用」をクリックしてルール設定を保存します。

8. 追加のルールに対してステップ7を実行します。

9. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

10. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

11. 「問合せ文字列」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

12. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.11 フォーマット・リクエスト・フィルタのルールの構成

フォーマット・リクエスト・フィルタにより、Oracle Web Cacheでは整形式の有効なURLに基づいてアクセスを拒否できます。

フォーマット・リクエスト・フィルタの詳細は、第4.2項を参照してください。

フォーマット・リクエスト・フィルタのルールを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 「サイト」リストから、フィルタを適用するサイトを選択します。追加のサイトを作成する方法は、第2.11.3項および第2.11.4項を参照してください。
特定のサイトまたは「未定義のサイト」に対してフィルタおよびフィルタ・ルールを構成できます。Oracle Web Cacheは、定義済サイトと一致しないクライアント・リクエストを「未定義のサイト」用に構成されたリクエスト・フィルタへ転送します。

4. 「問合せ文字列」リンクをクリックします。
「問合せ文字列リクエスト・フィルタ」ページが表示されます。

5. 「監査」リストで、対象となるリクエスト・フィルタについて、Oracle Web Cacheが監査ログに記録するアクションのレベルを選択します。

6. 「拒否するレスポンス」リストで、このリクエスト・フィルタによってリクエストが拒否された場合にOracle Web Cacheがブラウザへ返すHTTPレスポンスを選択します。
「接続を閉じる」オプションを選択した場合はHTTPレスポンスが返されません。接続が閉じるだけです。

7. 検証タイプのルールを定義します。

1. 「有効化」チェック・ボックスを選択して、検証チェックを有効にします。
- Nullバイト: この検証では、Nullバイト%00としてエンコーディングをチェックします。ほとんどのアプリケーションでは、URLにNullバイトを使用していません。このため、アプリケーションがNullバイトにヒットするとチェックを停止して、そこを文字列マーカーの最後とみなすので、アプリケーションのチェックにNullバイトが渡された後トリックを含む文字列となる可能性があります。

- Valid Unicode: この検証では、Unicodeを処理するように設定されていないアプリケーションのURLに、Unicode文字がエンコードされた状態または未加工で含まれていないかがチェックされます。

- 厳密なエンコーディング: この検証では、スペース、円記号(\)、または印刷不能な文字などのエンコードされない文字をチェックします。

- Double Encoding: この検証では、アプリケーションに%XYシーケンスを渡すことを目的とした、%XYエンコーディングを使用する%XYシーケンスがチェックされます。このシーケンスによって、本来なら拒否される文字をハッカーが指定できるようになるおそれがあります。

- Uencoded Unicode Characters: この検証では、Unicodeを処理するように設定されていないアプリケーションのURLに、Unicode文字がエンコードされた状態または未加工で含まれていないかがチェックされます。

2. 「問合せ文字列のチェック」チェック・ボックスを選択して、URLのフォーマットだけでなく、問合せ文字列またはPOSTリクエストの本体を検証します。URLのフォーマットだけを検証する場合は、このチェック・ボックスを選択解除します。

3. 無効なフォーマットを含むリクエストをOracle Web Cacheで許可する場合は、「許可」チェック・ボックスを選択します。無効なフォーマットを含むリクエストをOracle Web Cacheで拒否する場合は、このチェック・ボックスを選択解除します。

4. 「次のみを監視」チェック・ボックスを選択すると、そのルールに一致するアクティビティが表示されますが、ルールは実行されません。
結果が予期される場合は、「次のみを監視」を無効にしてルールを実行します。「次のみを監視」オプションの詳細は、第4.4項を参照してください。

5. 「適用」をクリックしてルール設定を保存します。

8. ページ最上部のナビゲーション表示で「リクエスト・フィルタ概要」をクリックするか、「Webキャッシュ」メニューから「管理」→「リクエスト・フィルタ」を選択して、「リクエスト・フィルタ概要」ページに戻ります。

9. 「フォーマット」行の「有効化」チェック・ボックスを選択して、このフィルタを有効にします。
「有効化」チェック・ボックスを選択しない場合は、このフィルタに対して構成したすべてのフィルタ・ルールが無視されます。

10. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.12 リクエスト・フィルタのルールの削除

リクエスト・フィルタのルールを削除するには:

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 変更するフィルタをクリックします。

4. 「サイト」リストから目的のサイトを選択します。

5. 表内のルールを選択して、「削除」アイコンをクリックします。

6. 追加で削除する各ルールに対して、ステップ5を繰り返します。

7. 「適用」をクリックします。リクエスト・フィルタの構成が保存されます。

4.13 リクエスト・フィルタのタイプとルールの統計監視

Fusion Middleware Controlでは、構成されているリクエスト・フィルタとルールの有効性を評価するための統計を表示できます。ルールを分析することで、ルールを不適切に優先順位付けしたかどうかを確認できます。たとえば、拒否ルールとは一致するが、許可ルールとは一致しないように構成されていた場合、拒否ルールを上位に優先順位付けします。

Oracle Web Cacheの構成設定に変更を加えると、リクエスト・フィルタの統計は無効化され、「NA」とラベルが付けられます。

リクエスト・フィルタの統計を表示するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「リクエスト・フィルタ」を選択します。
「リクエスト・フィルタ概要」ページが表示されます。

3. 右端までスクロールして、「リクエスト統計」と「許可後統計」を表示します。「リクエスト統計」には、構成したリクエスト・フィルタが受信リクエストをどのように処理しているかを示すランタイム統計が表示されます。

- 一致したすべて検索: 「すべて検索」ルールと一致したリクエストの数が表示されます。

- 一致したその他: 「すべて検索」以外のルールと一致したリクエストの数が表示されます。

- 一致した拒否: 対象ルールと一致し、Oracle Web Cacheによって拒否されたリクエストの数が表示されます。

フィルタと一致するリクエストがほとんどない場合は、フィルタのルールを変更して有効性を向上させることを検討してください。

「許可後統計」には、許可されたリクエストの統計情報が表示されます。

- 成功: 許可されて成功したリクエストの数が表示されます。

- 後で拒否: 許可された後、別のフィルタによって拒否されたリクエストの数が表示されます。

- 失敗: 許可された後、エラーが発生して失敗したリクエストの数が表示されます。

4. 特定のフィルタの情報をより多く収集するには、フィルタをクリックして、個々のルールと付随する統計を表示します。

4.14 リクエスト・フィルタを構成する時間の削減

この項では、構成作業を容易にするための次の構成タスクについて説明します。これらの機能は、Oracle Web Cache Managerでのみ使用できます。

- 第4.14.1項「ソース・サイトからターゲット・サイトへのルールのコピー」

- 第4.14.2項「構成設定のリセット」

4.14.1 ソース・サイトからターゲット・サイトへのルールのコピー

1つのサイトで構成を完了させて、それを他のサイトの適用することで、フィルタおよび関連ルールの構成に要する時間を削減できます。すべてのフィルタのすべての構成をコピーするか、特定フィルタのルールの構成をコピーできます。

すべてのフィルタのすべての構成をソース・サイトからターゲット・サイトにコピーするには:

1. 第4.5項から第4.11項の説明に従って各種フィルタを設定します。

2. Oracle Web Cache Managerのナビゲータ・フレームで、「Filtering」→「Request Filters」を選択します。第2.7.2項を参照してください。
「Request Filters Summary」ページが表示されます。

3. 「For Site」リストから、フィルタの構成が完了しているコピー元サイトを選択します。

4. ページの下の方にある「Copy All Filters」をクリックします。

5. 「Copy All Request Filter」ダイアログの「To Site」リストから、構成設定を適用するコピー先サイトを選択し、「Submit」をクリックします。

6. 「Apply Changes」をクリックします。

特定フィルタのルール構成をソース・サイトからターゲット・サイトにコピーするには:

1. 第4.5項から第4.11項の説明に従って各種フィルタを設定します。

2. Oracle Web Cache Managerのナビゲータ・フレームで、「Filtering」→「Request Filters」を選択します。第2.7.2項を参照してください。
「Request Filters Summary」ページが表示されます。

3. 「Filter Type」列から目的のフィルタを選択します。
選択したフィルタの構成ページが表示されます。

4. 「For Site」リストから、フィルタの構成が完了しているコピー元サイトを選択します。

5. ページの下の方にある「Copy Filter」をクリックします。

6. 「Copy Request Filter」ダイアログの「To Site」リストから、構成設定を適用するコピー先サイトを選択し、「Submit」をクリックします。

7. 「Apply Changes」をクリックします。

4.14.2 構成設定のリセット

すべてのフィルタまたは特定のフィルタの構成を、Oracle Web Cacheのデフォルト設定に戻すことができます。

すべてのフィルタの構成設定を元に戻すには:

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Filtering」→「Request Filters」を選択します。第2.7.2項を参照してください。
「Request Filters Summary」ページが表示されます。

2. 「For Site」リストから、構成設定を元に戻すサイトを選択します。

3. 「Clear All Filters」をクリックします。

4. 「Apply Changes」をクリックします。

特定フィルタの構成設定を元に戻すには:

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Filtering」→「Request Filters」を選択します。第2.7.2項を参照してください。
「Request Filters Summary」ページが表示されます。

2. 「Filter Type」列から目的のフィルタを選択します。
選択したフィルタの構成ページが表示されます。

3. 「For Site」リストから、構成設定を元に戻すサイトを選択します。

4. 「Clear Filter」をクリックします。

5. 「Apply Changes」をクリックします。

5 セキュリティの構成

Webコンテンツへのユーザー・アクセスを制御する機能、および侵入から保護する機能は、エンタープライズ・デプロイメントに影響する重要な課題です。この章では、Oracle Web Cacheのセキュリティを構成する方法について説明します。

セキュリティの詳細は、Oracle Fusion Middlewareセキュリティ・ガイドを参照してください。

この章の項目は次のとおりです。

- 第5.1項「Oracle Web Cacheのセキュリティの概要」

- 第5.2項「パスワード・セキュリティの構成」

- 第5.3項「アクセス制御の構成」

- 第5.4項「HTTPSリクエストをサポートするためのOracle Web Cacheの構成」

- 第5.5項「追加のHTTPS構成」

- 第5.6項「HTTPリクエスト・ヘッダー・サイズの構成」

- 第5.7項「ClientIPヘッダーが有効であることの確認」

- 第5.8項「セキュアなコンテンツのキャッシュに対するサポートの構成」

- 第5.9項「root権限によるwebcachedの実行」

- 第5.10項「UNIXでファイル・アクセス権を設定するためのスクリプト」

5.1 Oracle Web Cacheのセキュリティの概要

この項では、Oracle Web Cacheのセキュリティ・モデルについて説明します。次のトピックが含まれます:

- 第5.1.1項「Oracle Web Cacheのセキュリティ・モデル」

- 第5.1.2項「保護リソース」

- 第5.1.3項「認可およびアクセスの適用」

- 第5.1.4項「Oracle Identity Managementインフラストラクチャの活用」

5.1.1 Oracle Web Cacheのセキュリティ・モデル

Oracle Web Cacheでは、次のセキュリティ関連の機能が提供されています。

- 第5.1.1.1項「管理の制限」

- 第5.1.1.2項「Secure Sockets Layer(SSL)」

- 第5.1.1.3項「SSLアクセラレータ」

注意:
Oracle Web Cacheは、HTTPの認証タイプの1つであるBasic認証をサポートしているページをキャッシュしません。したがって、これらのページはキャッシュ・ミスになります。

5.1.1.1 管理の制限

Oracle Web Cacheでは、次の機能によって管理を制限します。

- 管理および無効化処理のパスワード認証

- 管理および無効化処理に使用されるポートの制御

- IPおよびサブネットの管理制限

5.1.1.2 Secure Sockets Layer(SSL)

HTTPSプロトコル(HTTP over SSL)を使用して、ネットワーク・トラフィックは暗号化されます。Oracle Web Cacheでは、HTTPクライアント、管理、無効化および統計のリクエストを含めて、そのすべてのネットワーク・トラフィックでHTTPSがサポートされ、そのオリジン・サーバーとキャッシュ・クラスタ・ピアとの通信でもHTTPSがサポートされます。

図5-1に示すように、クライアントからのHTTPSリクエストを受信し、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成できます。

図5-1 SSLによるセキュアな接続

「図5-1 SSLによるセキュアな接続」の説明

オリジン・サーバーにリクエストを送信するとき、HTTPS通信の場合にはプロセッサに負荷がかかることがあります。Oracle Web Cacheからオリジン・サーバーへの通信で、オープンなインターネットを経由する必要がある場合は、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成します。データ・センター内のLANによる通信のみ行う場合は、オリジン・サーバーの負荷を軽くするためにHTTPの使用を検討します。

Oracle Web Cacheでは、サーバー側の証明書とクライアント側の証明書の両方がサポートされます。SSLサーバー証明書を使用するとサーバーの信頼性を検証でき、SSLクライアント証明書を使用すると、特定のクライアントへのアクセスを制限できます。ただし、SSLのみを使用してユーザー検証を行うことは一般にはありません。

この項では、次の項目について説明します。

- 第5.1.1.2.1項「認証局」

- 第5.1.1.2.2項「証明書」

- 第5.1.1.2.3項「ウォレット」

5.1.1.2.1 認証局

認証局(CA)は、サード・パーティや、ユーザー、データベース、管理者、クライアント、サーバーなど、その他のエンティティの識別情報を証明する、信頼できる第三者機関です。認証局は、当事者の識別情報を検証し、秘密鍵で署名された証明書を付与します。Oracle Web Cacheで使用する証明書は、CAによって署名されている必要があります。

CAごとに、証明書の発行時の識別情報要件が異なる可能性があります。CAによってはユーザーの運転免許証の提示を必要としたり、別のCAでは証明書リクエスト・フォームの公証や、証明書をリクエストしている当事者の指紋を必要とする可能性があります。

CAは、公開鍵が含まれている独自の証明書を発行します。各ネットワーク・エンティティは、信頼しているCAの証明書のリストを所有しています。あるエンティティが別のエンティティと通信を行う場合、通信を始める前に、このリストを使用して、相手のエンティティの証明書の署名が既知の信頼できるCAのものであるかを検証します。

ネットワーク・エンティティは、同じCAから、または異なるCAから証明書を取得できます。Oracle Wallet Managerは、デフォルトでVeriSign社、RSA社、Entrust社およびGTE CyberTrust社による信頼できる(トラステッド)証明書とともに自動的にインストールされます。

5.1.1.2.2 証明書

証明書は、サーバーまたはクライアントなどのネットワーク・エンティティを認証するために使用されるデジタル・データ・レコードです。ある当事者の公開鍵が信頼できるCAによって署名されると作成されます。証明書は、ある当事者の識別情報が正しく、公開鍵が実際にその当事者の所有するものであることを保証します。

証明書には、当事者の名前、公開鍵、有効期限、さらにシリアル番号および証明書チェーン情報が含まれています。また、証明書に関連付けられた権限に関する情報が含まれている場合もあります。

ネットワーク・エンティティが証明書を受信すると、それが信頼できる証明書、つまり信頼できる認証局によって発行および署名された証明書であるか検証します。証明書は、期限切れになるか無効にされるまで有効です。

Oracle Web Cacheは、次の証明書をサポートしています。

- サーバー側の証明書: サーバー側の証明書は、通信先のサーバーの識別情報を検証するための手段です。証明書は、サーバーに関する情報をサーバーの公開鍵にバインドするもので、信頼できるCAによって署名される必要があります。
サーバー側の証明書が使用される場合、Oracle Web Cacheは、SSLハンドシェイク時にサーバー証明書をクライアントのブラウザに送信し、その後でオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)従属キャッシュに転送します。

一意のサイト定義ごとに1つのサーバー側の証明書が必要です。HTTPSでは、単一のポートに対して複数の仮想ホストはサポートされません。たとえば、20のサイトIPアドレスがある環境の場合、ポート番号構成には20の異なる証明書が必要です。

- クライアント側の証明書: クライアント側の証明書は、クライアントの識別情報を検証する方法の1つです。証明書は、クライアント・ユーザーに関する情報をユーザーの公開鍵にバインドするもので、信頼できるCAによってデジタル署名される必要があります。証明書失効リスト(CRL)は、SSLハンドシェイクでピアの証明書を検証し、証明書がCAによって発行された失効している証明書のリストにないことを確認します。
クライアント側の証明書を使用する場合、クライアントのブラウザは、SSLハンドシェイク時に証明書をキャッシュに送信し、その後でキャッシュがオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)別のキャッシュに転送します。クライアント側の証明書に関する情報を別のキャッシュまたはWebアプリケーション・サーバーに転送するために、Oracle Web CacheはリクエストにHTTPヘッダーを追加します。これらのヘッダーは、文字列SSL-Client-Certで始まります。

また、配置に応じて、ピア・キャッシュまたは任意のエンティティ(プロバイダ・キャッシュやリモート・キャッシュなど)からHTTPヘッダーの証明書情報を受け入れるようにキャッシュを構成するか、またはヘッダーの証明書情報を受け入れないようにキャッシュを構成します。

クライアント側の証明書に関して、次の点に注意してください。

- クライアント側の証明書は、HTTPSリクエストでは要求されません。クライアント側の証明書は通常、金融、政府または軍事用のアプリケーションなど、PKIに基づくユーザー認証が必要な場合に使用されます。

- サイト全体がクライアント側の証明書を要求するように指定できます。

- リスニング・ポートがクライアント証明書を要求すると、接続が拒否されます。サイトがクライアント証明書を要求し、SSLポートが要求しない場合、HTTPエラー「403 禁止」が返されます。

- Oracle Web Cacheでは、Oracle HTTP Serverとともに使用する場合にのみクライアント側の証明書の使用がサポートされます。

- 分散キャッシュ階層では証明書の安全性が保証されないため、Oracle Web Cacheでは、クライアント側の証明書はサポートされていません。

- Oracle HTTP ServerではOpenSSL証明書失効リストがサポートされますが、Oracle Web Cacheではサポートされません。クライアント側の証明書を使用する場合は、クライアント側の証明書が失効しているかどうかを確認するようにアプリケーションを変更する必要があります。これを行うには、CGIスクリプトまたはサーブレットを使用します。

- Oracle Fusion Middlewareでは、Microsoft Server Gated Cryptography(SGC)証明書またはVeriSign Global Server IDはサポートされません。この暗号方式により、エクスポート・バージョンのブラウザは、アプリケーション・サーバーとの通信時に、弱い40ビットの暗号化から強力な128ビットの暗号化に透過的にアップグレードできます。この暗号方式がないと、弱い40ビットの暗号化を使用するブラウザは、Oracle Fusion Middlewareに対して保護された接続のネゴシエーションを行うことができません。

5.1.1.2.3 ウォレット

ウォレットは、SSLに必要な鍵、証明書、および信頼できる証明書などの認証データを管理するためのリポジトリです。ウォレットには、X.509バージョン3証明書、秘密鍵および信頼できる証明書のリストが含まれています。

セキュリティ管理者は、Oracle Web Cacheサーバーのセキュリティ資格証明の管理にOracle Wallet Managerを使用します。ウォレットの所有者は、クライアントのセキュリティ資格証明の管理に使用します。具体的には、Oracle Wallet Managerは次のことを行うために使用されます。

- 公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書リクエストを作成します。

- 識別情報用の証明書をインストールします。

- 識別情報用の信頼できる証明書を構成します。

Oracle Web CacheでHTTPSを構成するには、サポートしている各サイトのOracle Web Cacheサーバーでウォレットを作成します。Oracle Web Cache HTTPSリスニング・ポートおよび操作ポート(受信HTTPSリクエストのサポート用)とオリジン・サーバー(送信HTTPSリクエストのサポート用)のそれぞれに対してウォレットの場所を指定します。1つのウォレットを共有することも、異なるウォレットを作成することもできます。同じウォレットを使用する場合、このウォレットがサポートできるのは1つのサーバー側の証明書のみである点に注意する必要があります。

Oracle Web Cacheでは、デフォルトのウォレットがデフォルトの証明書とともにインストールされますが、これらはテスト目的のみに使用し、本番環境では使用しないでください。デフォルトのウォレットを使用した場合、SSL接続は安全であるとは考えられません。本番環境では、新しいウォレットを作成して新しい証明書を作成するか、または信頼できる証明書をウォレットにインポートしてください。

Oracle Wallet Managerの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

5.1.1.2.4 SSLの仕組み

HTTPS接続でのSSLの仕組みの説明では、「クライアント」という用語はブラウザまたはOracle Web Cacheを指し、「サーバー」という用語はOracle Web Cacheまたはオリジン・サーバーを指します。たとえば、ブラウザがクライアントの場合、サーバーはOracle Web Cacheまたはオリジン・サーバーのいずれかになります。一方、Oracle Web Cacheがクライアントの場合は、サーバーはオリジン・サーバーになります。

クライアントとサーバー間の認証プロセスは、次のステップで構成されます。

1. クライアントとサーバーは、どの暗号(暗号化アルゴリズム)を使用するかを決定します。

2. SSLは、保護された接続を確立するために、クライアントとサーバー間のハンドシェイクを実行します。

SSLハンドシェイクには次のアクションが含まれます。

1. クライアントとサーバーは、どの暗号スイートを使用するかを設定します。

2. サーバーは証明書をクライアントに送信し、クライアントは、サーバーの証明書が信頼できるCAによって署名されていることを検証します。

3. オプションで、サーバーがクライアント証明書をリクエストし、クライアントがサーバーにクライアント証明書を送信することによって応答します。サーバーは、クライアントの証明書が信頼できるCAによって署名されていることを検証します。

4. クライアントとサーバーが、公開鍵暗号化を使用してキー情報を交換します。この情報に基づいて、それぞれがセッション・キーを生成します。クライアントとサーバーとの間の以降のやりとりはすべて、このセッション・キーのセットと暗号を使用して暗号化/復号化されます。

5.1.1.3 SSLアクセラレータ

Oracle Web Cacheでは、SSL処理をWeb層に移動することによってSSLアクセラレータを提供しています。

オフボードのSSLアクセラレータ・ソリューションに加えて、Oracle Fusion Middlewareでは、Oracle Web CacheおよびOracle HTTP Serverが稼働しているサーバーへのデプロイメントのために、ソフトウェアのみのSSL処理とnCipherのBHAPI準拠ハードウェアの両方がサポートされています。ソフトウェアで実行される場合、SSL処理によってサーバーのCPUリソースに重度の負荷がかかるため、スループットが低下し、全体的なパフォーマンスが低下します。nCipherのハードウェアを使用すると、SSLの鍵交換処理によってサーバーのCPUにかかる負荷がなくなるため、同時SSL接続数が増加し、SSL保護コンテンツのレスポンス時間が改善されます。

nCipherの詳細は、http://www.ncipher.comを参照してください。

5.1.2 保護リソース

デフォルトでは、インストールを実行したユーザーがOracle Web Cacheファイルの所有者となります。ほとんどのファイルは、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で指定したユーザーIDおよびグループIDで読み取ることができます。

プロセス認証ユーザーを変更する場合は、chownコマンドを実行して、Oracle Web Cacheのファイルとディレクトリの所有権を新しいユーザーIDおよびグループIDに手動で変更する必要があります。

5.1.3 許可およびアクセスの適用

Oracle HTTP Serverのmod_accessモジュールによって、ホスト名やIPアドレスなどのリクエストの特性に基づいてURLへのアクセスが制御されます。Oracle Web Cacheでは、URLベースでIPアドレスが制限されることはありません。Oracle Web Cacheでmod_accessを使用している場合は、キャッシュ・ルールを指定しないか、またはコンテンツをキャッシュしないキャッシュ・ルールを明示的に設定して、保護リソースがキャッシュされないようにしてください。

クライアントのIPをOracle HTTP Serverに直接渡すには、httpd.confファイルでOrderディレクティブを構成します。詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

5.1.4 Oracle Identity Managementインフラストラクチャの活用

Oracle Identity Managementインフラストラクチャにより、エンタープライズ全体にまたがるセキュリティの管理が集中化されます。

- 第5.1.4.1項「Oracle Single Sign-Onサーバーからのコンテンツのキャッシュについて」

- 第5.1.4.2項「Oracle Single Sign-Onのパートナ・アプリケーション(mod_osso)のキャッシングについて」

- 第5.1.4.3項「Oracle Single Sign-Onを介した認証について」

5.1.4.1 Oracle Single Sign-Onサーバーからのコンテンツのキャッシュについて

セキュリティ上の理由により、Oracle Single Sign-Onサーバーからコンテンツをキャッシュしないでください。

5.1.4.2 Oracle Single Sign-Onパートナ・アプリケーション(mod_osso)のキャッシングについて

Single Sign-Onのパートナ・アプリケーションを実行しているOracle HTTP Serverに対するコンテンツをキャッシュするように、Oracle Web Cacheを構成できます。デフォルトでは、mod_osso保護ページは、Surrogate-Control: no-storeレスポンス・ヘッダーを使用してキャッシュ不可に構成されています。

mod_ossoのデフォルトの動作をオーバーライドするには、httpd.confファイルでOssoSendCacheHeadersをoffに設定します。次に例を示します。

<Location /foo/>
OssoSendCacheHeaders off
</Location>

この例は、/fooで始まるすべてのURLに対して、キャッシュ・ヘッダーのmod_ossoによる設定を無効にします。これらのURLについては、アプリケーション側で、適宜Surrogate-Controlを組み込んで、キャッシュ制御ヘッダーを設定する必要があります。

Oracle Web Cacheが同じSingle Sign-Onのパートナ・アプリケーションに対するリクエストのロード・バランシングを実行している場合は、Oracle HTTP Serverをクラスタとして構成して、複数のアプリケーションが単一のパートナ・アプリケーションとして機能するようにします。このように構成すると、サーバーに対するリクエストのステートレス・ロード・バランシングを実行するように、Oracle Web Cacheを構成できます。アプリケーションの中間層がクラスタ化されていない場合は、ステートフル・ロード・バランシングを実行する必要があります。

5.1.4.3 Oracle Single Sign-Onを介した認証について

Oracle Single Sign-Onを介して認証を要求するように、Oracle Web Cacheを構成できます。受信リクエストがOracle Web Cacheによって処理されるには、リクエストに有効なOracle Single Sign-OnのCookieが必要です。構成の詳細は、第5.8項を参照してください。

5.2 パスワード・セキュリティの構成

無効化および統計監視用のリクエストを発行する前に、リクエストを送信するためのセキュアなパスワードを確立する必要があります。

invalidatorアカウントは、無効化リクエストの送信を許可された管理者です。キャッシュ内のオブジェクトを無効化するために、invalidatorアカウントはHTTP POSTリクエストを送信します。

administratorアカウントは、Oracle Web Cache Managerにログインし、そのインタフェースを介して構成を変更することを許可されたOracle Web Cache管理者です。この管理者は、Oracle Web Cacheの統計監視用ポートに対する統計監視リクエストの送信も許可されています。Fusion Middleware Controlでメトリックを監視した後に別のパフォーマンス・メトリックが必要となった場合は、administratorアカウントを使用して統計監視用ポートにアクセスして、詳細なパフォーマンス・メトリックを表示できます。第8.4項を参照してください。

これらのアカウントのデフォルトのパスワードは、Oracle Universal Installerの「Web Cache管理者」ページで指定したパスワードです。構成を開始する前に、これらのアカウントのパスワードをセキュアなパスワードに変更します。この構成はFusion Middleware Controlで行う必要があります。

invalidatorおよびmonitorアカウントに対してセキュアなパスワードを確立するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「パスワード」を選択します。
「パスワード」ページが表示されます。

3. 「新規パスワード」フィールドに、新しいパスワードを入力します。このとき、次の制限事項に注意してください。

- パスワードは、5文字以上30文字以下にする必要があります。

- 最低でも1文字は数字にする必要があります。

- パスワードに使用できる文字は、英数字とアンダースコア(_)のみです。

- パスワードは、英字で始まる必要があります。パスワードを数字、アンダースコア(_)、ドル記号($)またはナンバー記号(#)で始めることはできません。

- Oracleの予約語はパスワードにできません。予約語の一覧は『Oracle Database SQLリファレンス』に記載されています。

4. 「パスワードの確認」フィールドに新しいパスワードを再入力して、パスワードの入力が正しいことを確認します。

5. 「適用」をクリックします。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。
Oracle Web Cacheを再起動しないと、Fusion Middleware Controlの一部のページへのアクセス時にエラーが発生することがあります。

5.3 アクセス制御の構成

デフォルトでは、Oracle Web Cacheをインストールしたコンピュータが信頼できるホストです。管理リクエスト、無効化リクエストおよび統計監視リクエストの発信元となる信頼できるサブネットまたは信頼できるホストは変更できます。

アプリケーションへの通信の一部または全部がHTTPSを使用するように限定するかどうか指定するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページが表示されます。

2. 「Security」ページで、「Current Trusted Subnets」の下にある「Change Trusted Subnets」をクリックします。
「Change Trusted Subnets」ダイアログ・ボックスが表示されます。

3. オプションを選択します。
All subnets: ネットワークのすべてのサブネット上にあるすべてのコンピュータからのリクエストを許可します。

This machine only: このコンピュータからのみリクエストを許可します。

Enter list of IP addresses: カンマ区切りのリストで入力したすべてのIPアドレスからのリクエストを許可します。次の形式を使用してIPアドレスを入力できます。

- ネットワーク番号、サブネット・アドレスおよび一意のホスト番号を含めた完全なIPアドレス(ドット表記法を使用)
例: 10.1.0.0

- マスクによるサブネット制限を実行するネットワーク/ネットマスクのペア
例: 10.1.0.0/255.255.0.0の場合、サブネット10.1からアクセスするすべてのホストが許可されます。

- ネットワーク/nnnの形式のClassless Inter-Domain Routing(CIDR)を指定することにより、ハイエンドからnnnビットの一致を要求
例: 10.1.0.0/16の場合、サブネット10.1からアクセスするすべてのホストが許可されます。この例はネットワーク/ネットマスクの例と似ていますが、ネットマスクがnnnという上位1ビットで構成される点が異なります。

4. 「Submit」をクリックします。

5. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

5.4 HTTPSリクエストをサポートするためのOracle Web Cacheの構成

Webサイトのセキュリティを強化するため、クライアントからHTTPプロトコル・リクエストを受信し、オリジン・サーバーにHTTPSリクエストを送信するようにOracle Web Cacheを構成することができます。HTTPSではSSLを使用して、ユーザー・ページのリクエストおよびOracle Web Cacheとオリジン・サーバーから返されるページを暗号化および復号化します。また、HTTPSのリスニング・ポートを通じてオリジン・サーバーに通信データを送信するようにOracle Web Cacheを構成することもできます。

Oracle Web CacheでHTTPSサポートを構成するには、次の作業を行います。

- 第5.4.1項「作業1: ウォレットの作成」

- 第5.4.2項「作業2: HTTPSリスニング・ポートの構成」

- 第5.4.3項「作業3: オリジン・サーバーに対するOracle Web Cache接続のためのSSL設定の構成」

- 第5.4.4項「作業4: HTTPSリクエストを要求するサイトの構成」

- 第5.4.5項「作業5: Oracle Web Cacheの再起動」

- 第5.4.5項「作業5: Oracle Web Cacheの再起動」

- 第5.4.6項「作業6: Oracle WebLogic Serverの追加の構成の実行」

5.4.1 作業1: ウォレットの作成

Oracle Web CacheでHTTPSをサポートするには、サポートしている各サイトのOracle Web Cacheサーバーでウォレットを作成します。次のHTTPSリクエストをサポートするにはウォレットが必要です。

- Oracle Web Cacheによってホスティングされるサイトに対するクライアント・リクエスト

- Oracle Web Cacheに対する管理、無効化および統計監視用のリクエスト

- オリジン・サーバーに対するOracle Web Cacheのリクエスト、およびSSL対応の無効化用ポートおよび統計監視用ポートに対するadminサーバー・プロセスのリクエスト

Oracle Web Cacheがサポートする各サイトには、少なくとも1つのウォレットを構成します。Oracle Web Cache HTTPSリスニング・ポートおよび操作ポート(受信HTTPSリクエストのサポート用)とオリジン・サーバー(送信HTTPSリクエストのサポート用)のそれぞれに対してウォレットの場所を指定します。1つのウォレットを共有することも、異なるウォレットを作成することもできます。同じウォレットを使用する場合、このウォレットがサポートできるのは1つのサーバー側の証明書のみである点に注意する必要があります。

ウォレットを作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「セキュリティ」→「ウォレット」を選択します。
「ウォレット」ページが表示されます。

3. 『Oracle Fusion Middleware管理者ガイド』のウォレットの作成に関する項の作業を実行します。

5.4.2 作業2: HTTPSリスニング・ポートの構成

クライアントとOracle Web Cache間でHTTPSプロトコルをサポートするように構成するには、Oracle Web Cache用のHTTPSリスニング・ポートを構成する必要があります。

HTTPSリスニング・ポートを追加するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. リスニング・ポートを作成します。

1. 「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

2. 「作成」をクリックします。
「ポートの作成」ページが表示されます。

3. 「ポート・タイプ」リストから「NORM」を選択します。

4. 「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。
- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。

- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXのetc/hostsファイルなどの別の名前解決メカニズムを使用してください。

- 任意のIPアドレスを表すANY

5. 「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号が使用されていないことを確認してください。

1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。

webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。

6. 「OK」をクリックします。

3. SSLのポートを有効にします。

1. 「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。

2. ステップ2で作成したエンドポイントの行を選択して、「編集」をクリックします。
「ポートの編集」ページが表示されます。

3. 「SSL構成」セクションで、「SSLの有効化」をクリックします。

4. 「サーバー・ウォレット名」フィールドで、第5.4.1項で作成したウォレットを選択します。

5. 「拡張SSL設定」セクションで、「開く」(+)をクリックして構成設定を開きます。

6. 「クライアント認証」リストから、クライアント認証のタイプを選択します。
- サーバー認証: サーバーがクライアントに対して自身を認証します。

- 相互認証: クライアントがサーバーに対して自身を認証するとともに、そのサーバーがそのクライアントに対して自身を認証します。

- 認証なし: サーバーもクライアントも認証を必要としません。

- オプションのクライアント認証: サーバーがクライアントに対して認証を実行しますが、クライアントはサーバーに対して認証を実行する場合としない場合があります。クライアント自身の認証を行わなくても、SSLセッションは機能します。

7. 「SSLプロトコル・バージョン」リストから、使用するSSLのバージョンを選択します。
- すべて: 「v1」、「v3」および「v3-v2Hello」オプションを有効にします。

- v1: TLSバージョン1トラフィックをサポートします。

- v3: SSLバージョン3トラフィックを提供します。

- v3_v2Hello: SSLバージョン2のhelloメッセージ・フォーマットとSSLバージョン3の処理を組み合せて、ハンドシェイク操作中のSSLバージョンのアップグレードをサポートします。

8. 「OK」をクリックします。

5.4.3 作業3: オリジン・サーバーに対するOracle Web Cache接続のためのSSL設定の構成

この作業では、オリジン・サーバーに対するOracle Web Cache接続で使用するSSLウォレットを指定します。このウォレットには、オリジン・サーバーが使用するウォレットに一致する証明書が含まれている必要があります。

オリジン・サーバーに対するWeb Cache接続で使用するSSLウォレットを指定するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。

3. 「WebCacheとOracle HTTP Server(OHS)間のSSL通信」セクションの横にある「開く」アイコンをクリックします。

4. 「ウォレットの変更」をクリックして、「クライアント・ウォレットの選択」ダイアログ・ボックスを表示します。

5. 使用するウォレットを選択し、「OK」をクリックします。このウォレットには、オリジン・サーバーが使用するウォレットに一致する証明書が含まれている必要があります。

5.4.4 作業4: HTTPSリクエストを要求するサイトの構成

HTTPとHTTPSの通信が混在する環境の場合は、次の手順に従って特定のサイト(またはサイトのURL接頭辞サブセット)の通信を制限して、Oracle Web CacheがSSL接続経由のリクエストのみを受信するようにします。

サイトの設定を構成するには、Fusion Middleware ControlとOracle Web Cache Managerを組み合せて使用します。

1. Fusion Middleware Controlで、第2.11.3項および第2.11.4項の説明に従って、サイト定義およびサイトからサーバーへのマッピングを指定します。サイト定義を構成するときには、HTTPSリスニング・ポートを必ず指定します。このサイトでは、そのポート用に定義されたウォレットが使用されます。

2. 「Webキャッシュ」メニューから、「可用性」→「再起動」を選択して、構成設定を保存し、Oracle Web Cacheを再起動します。

3. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Site Definition」を選択します。第2.7.2項を参照してください。

4. ステップ1で作成したサイトを選択し、「Show/Edit Site」をクリックします。

5. 「Show/Edit」ダイアログ・ボックスで、「HTTPS Only Prefix」フィールドに、HTTPSリクエストのみを処理することを示すURLの接頭辞を入力します。すべての通信をHTTPSに限定する場合は、サイト全体を表す「/」を入力します。

6. 「Submit」をクリックします。

5.4.4.1 キープ・アライブ接続用のssl.confの変更

Oracle HTTP Serverのデフォルトでは、Microsoft Internet Explorer 5.5以降のリリースからのHTTPSクライアント・リクエストに対するキープ・アライブ接続は維持されません。Internet Explorerには、タイムアウトしたSSL接続を再使用しようとする既知の問題があります。Oracle HTTP ServerがOracle Web Cacheからのキープ・アライブ接続を維持できるようにするには、UNIXでは$ORACLE_HOME/Apache/Apache/confディレクトリ、WindowsではORACLE_HOME\Apache\Apache\confディレクトリにあるssl.confファイルから次のエントリを削除する必要があります。

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

ssl.confファイルにより、Oracle HTTP ServerのSSL定義を指定します。このエントリを削除しないと、キープ・アライブ接続は無効です。Oracle Web Cacheでキープ・アライブのタイムアウトを構成する方法については、第2.11.5項を参照してください。

5.4.5 作業5: Oracle Web Cacheの再起動

第2.13項を参照してください。

5.4.6 作業6: Oracle WebLogic Serverの追加の構成の実行

オリジン・サーバーがOracle WebLogic Serverである場合は、SSLリクエストを正しく処理できるように、Oracle Web Cacheに対して追加の属性を指定する必要があります。

オリジン・サーバーがOracle WebLogic Serverである構成でOracle Web Cacheを構成する手順は次のとおりです。

1. 次の場所にあるwebcache.xmlをテキスト・エディタで開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

2. HOST ID要素を探します。

3. SERVERTYPE属性をCACHE要素に追加します。次に例を示します。

<HOST ID="host_ID" NAME="WLS_server_name" PORT="WLS_server_port" LOADLIMIT="100" OSSTATE="ON" SERVERTYPE="WebLogic"/>
...

4. webcache.xmlを保存します。

5. 次のコマンドを使用してOracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは、次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

5.5 追加のHTTPS構成

第5.4項の作業を実行した後に、オプションで次の構成を実行できます。

- 第5.5.1項「HTTPS操作ポートの構成」

- 第5.5.2項「クライアント側の証明書の要求」

- 第5.5.3項「証明書失効リスト(CRL)の構成」

5.5.1 HTTPS操作ポートの構成

Fusion Middleware Controlで管理リクエスト、無効化リクエストまたは統計監視リクエストをリスニングするHTTPSポートを構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. リスニング・ポートを作成します。

1. 「Webキャッシュ」メニューから、「管理」→「ポート構成」を選択します。
「ポート構成」ページが表示されます。

2. 「作成」をクリックします。
「ポートの作成」ページが表示されます。

3. 「ポート・タイプ」リストから、ポート・タイプとして「管理」、「無効化」または「統計」を選択します。

4. 「IPアドレス」フィールドで、Oracle Web Cacheが稼働しているコンピュータを指定します。
- 32ビットのドット10進数表記法で記述されたIPバージョン4アドレス、または128ビット表記法で記述されたIPバージョン6アドレス。第2.5項を参照してください。

- Oracle Web Cacheが稼働しているコンピュータのIPアドレスに解決されるホスト名。ホスト名の解決にドメイン・ネーム・システム(DNS)を使用しない場合は、UNIXの/etc/hostsファイルなどの別の名前解決メカニズムを使用してください。

- 任意のIPアドレスを表すANY

5. 「ポート」フィールドに、Oracle Web CacheがWebサイトのクライアント・リクエストを受信するリスニング・ポートを入力します。
このポート番号が使用されていないことを確認してください。

1024未満のポート番号は、UNIXの特権プロセス用に確保されています。Oracle Web Cacheが1024未満のポート(ポート80など)でリスニングするように構成するには、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行します。webcached実行可能ファイルをroot権限で実行しないと、Oracle Web Cacheは起動に失敗します。

webcached実行可能ファイルをroot権限で実行できるように変更する方法は、第5.9項を参照してください。

6. 「OK」をクリックします。

3. SSLのポートを有効にします。

1. 「Webキャッシュ」メニューから、「セキュリティ」→「SSL構成」を選択します。
「SSL構成」ページが表示されます。

2. ステップ2で作成したエンドポイントの行を選択して、「編集」をクリックします。
「ポートの編集」ページが表示されます。

3. 「SSL構成」セクションで、「SSLの有効化」をクリックします。

4. 「サーバー・ウォレット名」フィールドで、第5.4.1項で作成したウォレットを選択します。

5. 「拡張SSL設定」セクションで、「開く」(+)をクリックして構成設定を開きます。

6. 「SSL認証」リストから、クライアント認証のタイプを選択します。
- サーバー認証: サーバーがクライアントに対して自身を認証します。

- 相互認証: クライアントがサーバーに対して自身を認証するとともに、そのサーバーがそのクライアントに対して自身を認証します。

- 認証なし: サーバーもクライアントも認証を必要としません。

- オプションのクライアント認証: サーバーがクライアントに対して認証を実行しますが、クライアントはサーバーに対して認証を実行する場合としない場合があります。クライアント自身の認証を行わなくても、SSLセッションは機能します。

7. 「SSLプロトコル・バージョン」リストから、使用するSSLのバージョンを選択します。

8. 「OK」をクリックします。

5.5.2 クライアント側の証明書の要求

クライアントの識別情報を検証するために、証明書(クライアント側の証明書)をキャッシュに送信することをクライアントに要求できます。

クライアント側の証明書を使用する場合、クライアントのブラウザはSSLハンドシェイク時に証明書をキャッシュに送信します。次に、サーバーがそのオブジェクトに対するリクエストを処理します。リクエストされたオブジェクトがキャッシュに格納されていない場合、キャッシュはリクエストをWebアプリケーション・サーバー、(クラスタ内の)ピア・キャッシュまたは(階層内の)従属キャッシュに転送します。クライアント側の証明書に関する情報を別のキャッシュまたはWebアプリケーション・サーバーに転送するために、Oracle Web CacheはリクエストにHTTPヘッダーを追加します。ヘッダーの先頭は、文字列SSL-Client-Certで始まります。

クライアント側の証明書の使用については、次の点に注意してください。

- 単純な構成(クライアントからキャッシュ、キャッシュからWebアプリケーション・サーバーへ)では、クライアントはSSLハンドシェイク時に証明書をキャッシュに送信します。リクエストされたオブジェクトがキャッシュに保存されない場合、キャッシュはそのリクエストをWebアプリケーション・サーバーに転送し、ヘッダー内のクライアント側の証明書情報もWebアプリケーション・サーバーに転送します。Webアプリケーション・サーバーは、ヘッダーを認識してリクエストに応答します。

- クラスタ内で、クライアントはSSLハンドシェイク時に証明書をキャッシュ・クラスタ・メンバーに送信します。リクエストされたオブジェクトがキャッシュ内に保存されない場合、クラスタ・メンバーはピア(そのオブジェクトを所有するクラスタ・メンバー)にそのオブジェクトをリクエストします。クライアント側の証明書を使用する場合、Oracle Web Cacheはヘッダー内のクライアント側の証明書情報をピア・クラスタ・メンバーに渡すことができ、ピア・クラスタ・メンバーはそのヘッダーをWebアプリケーション・サーバーに渡すことができる必要があります。

- サイトがクライアント証明書を必要としている場合、クライアント証明書が渡されないと「403 禁止」エラーが返されます。リスニング・ポートがクライアント証明書を要求したときにクライアント証明書が提供されない場合、SSLハンドシェイクは失敗します。

注意:
Oracle Web Cacheでは、Oracle HTTP Serverとともに使用する場合にのみクライアント側の証明書の使用がサポートされます。
分散キャッシュ階層では証明書の安全性が保証されないため、Oracle Web Cacheでは、クライアント側の証明書はサポートされていません。

次のトピックは、クライアント側の証明書を構成する方法を示します。

- 第5.5.2.1項「HTTPSリスニング・ポートのクライアント側の証明書の構成」

- 第5.5.2.2項「キャッシュ・クラスタのクライアント側の証明書の構成」

- 第5.5.2.3項「サイトのクライアント側の証明書の構成」

5.5.2.1 HTTPSリスニング・ポートのクライアント側の証明書の構成

クライアント側の証明書を使用するには、第5.4.2項の説明に従ってHTTPSリスニング・ポートを有効にする必要があります。キャッシュ・クラスタを使用する場合は、すべてのクラスタ・メンバーに対してHTTPSリスニング・ポートを有効にする必要があります。また、クライアントのブラウザにSSL証明書を要求できるようOracle Web Cacheを構成する必要があります。

クライアント側の証明書を構成したら、Oracle Web Cacheが証明書情報をOracle HTTP Serverに転送できるようにAddCertHeaderディレクティブをhttpd.confに追加します。AddCertHeaderディレクティブの追加方法については、Oracle Fusion Middleware Oracle HTTP Server管理者ガイドを参照してください。

5.5.2.2 キャッシュ・クラスタのクライアント側の証明書の構成

キャッシュ・クラスタを使用する場合は、キャッシュがピア・クラスタ・メンバー以外のソースからHTTPヘッダーの証明書情報を受け取らないようにする必要があります。さらに、各キャッシュはヘッダー内のクライアント側の証明書情報をピア・クラスタ・メンバーに渡すことができ、ピア・クラスタ・メンバーはそのヘッダーをWebアプリケーション・サーバーに渡すことができる必要があります。

Oracle Web Cache Managerでこの動作を構成するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。

2. 「Security」ページの「Security Header Configuration」セクションで、「Accept SSL client certificates encoded in SSL-Client-Cert HTTP headers」の値を「NO」(デフォルト)に設定して、Oracle Web CacheがHTTPヘッダー内の証明書情報を受け取らないようにします。この設定により、キャッシュ・クラスタ内のキャッシュが、HTTPヘッダーの証明書情報を受け取らなくなります。

3. 「Cluster Security Configuration」セクションで、「Route requests that contain SSL client certificates to cache cluster peers」の値を「YES」に設定して、Oracle Web CacheがHTTPヘッダーのクライアント側証明書に関する情報をピア・キャッシュに渡すようにします。この設定を使用すると、キャッシュ・クラスタ内のキャッシュが、ピア・キャッシュに情報を渡すことができるようになります。

4. 「Apply Changes」をクリックします。

5. Oracle Web Cacheを再起動します。第2.13項を参照してください。

5.5.2.3 サイトのクライアント側の証明書の構成

サイト全体がクライアント側の証明書を要求するように指定することもできます。サイトがクライアント証明書を必要としている場合、クライアント証明書が渡されないと「403 禁止」エラーが返されます。

サイトがクライアント側の証明書を使用するよう構成するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Site Definition」を選択します。第2.7.2項を参照してください。

2. 「Site Definition」ページでサイトを選択し、「Show/Edit Site」をクリックします。

3. 「Show/Edit Site」ダイアログ・ボックスの「Client-Side Certificate」フィールドで、「Required」を選択します。

4. 「Submit」をクリックします。

5. Oracle Web Cacheを再起動します。第2.13項を参照してください。

5.5.3 証明書失効リスト(CRL)の構成

Fusion Middleware ControlまたはOracle Web Cache Managerでは、証明書失効リスト(CRL)によるクライアント証明書の検証はサポートされません。このサポートは、webcache.xmlファイルを手動で編集することで構成できます。

クライアント証明書失効ステータスは、ファイルシステム・ディレクトリに存在するCRLに基づいてチェックされます。通常、CRL定義の有効期限は数日間であり、定期的に更新される必要があります。CRL定義を変更した場合、常にOracle Web Cacheを再起動する必要があります。

CRL検証が有効化されており、使用可能な場合、Oracle Web Cacheはクライアント証明書に対して証明書失効ステータス・チェックを実行します。証明書が失効している場合、SSL接続は拒否されます。CRLが見つからない場合や、証明書がまだ失効していない場合、SSL接続は許可されます。

CRLによる証明書検証を構成するには、次の手順を実行します。

1. HTTPSリスニング・ポートに対してクライアント証明書を有効化します。第5.5.2項を参照してください。

2. 次の場所にあるwebcache.xmlをテキスト・エディタで開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

3. CRLチェックを有効化する必要のあるHTTPSリスニング・ポートの場所をwebcache.xmlで特定し、LISTENディレクティブにSSLCRLENABLE="YES"パラメータを追加します。次に例を示します。

...
<LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES" STRONG_CRYPTO_ONLY="NO">
...

4. HTTPS LISTENディレクティブにSSLCRLPATHおよびSSLCRLFILEパラメータを追加して、CRLファイルの場所を構成します。

- SSLCRLPATH: CRLが格納されているディレクトリのパスを入力します。パスが正しいことを確認します。間違っていると、CRLチェックは機能しません。このパラメータにデフォルト値はありません。

- SSLCRLFILE: PEMエンコードされた包括的CRLファイル(BASE64 CRLが優先度の順に1つのファイルに連結されたもの)へのパスを入力します。このパラメータを設定する場合、ファイルは指定した場所に存在している必要があります。存在していないと、CRLチェックが機能しません。

次に例を示します。

...
<LISTEN IPADDR="ANY" PORT="443" PORTTYPE="NORM" SSLENABLED="SSLV3_V2H"  CLIENT_CERT="YES" SSLCRLENABLE="YES"  SSLCRLFILE="/ORACLE_HOME/webcache/crls/sample_crl" SSLCRLPATH="/ORACLE_HOME/webcache/crls/" STRONG_CRYPTO_ONLY="NO">
...

orapkiコマンドライン・ユーティリティを使用して、ファイルシステムでCRLの名前を変更します。orapkiの使用方法の詳細は、Oracle Databaseドキュメント・ライブラリにあるOracle Database Advanced Security管理者ガイドの証明書失効リストの管理に関する項を参照してください。

5. webcache.xmlを保存します。

6. 次のコマンドを使用してOracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは、次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

クラスタ構成では、クラスタ・メンバーのwebcache.xmlファイルの構成を直接変更する場合、Fusion Middleware ControlまたはOracle Web Cache Managerを使用してその変更を他のクラスタ・メンバーに伝播してください。3.6項および3.7項を参照してください。

5.6 HTTPリクエスト・ヘッダー・サイズの構成

Oracle Web Cacheでは、デフォルトで、HTTPリクエスト・ヘッダー・フィールドに対して次の制限が設けられています。

- リクエスト内のすべてのHTTPリクエスト・ヘッダー・フィールドの合計は819000バイト
セキュリティを確立し、クライアントからのDoS攻撃を回避するために、ヘッダー・サイズはこのデフォルト値以下に設定することをお薦めします。

リクエストの長さが制限サイズより長い場合、Oracle Web Cacheはエラーをクライアントに送信し、次のエラー11356をイベント・ログに記録します。

Total request header length exceeds configured maximum. A forbidden error response is returned to the client.

- 各HTTPリクエスト・ヘッダー・フィールドは8152バイト
各ヘッダー・サイズは、アプリケーションで設定するHTTPリクエスト・ヘッダー・フィールドの大きさに基づいて設定することをお薦めします。

リクエストの長さが制限サイズより長い場合、Oracle Web Cacheはエラーをクライアントに送信し、次のエラー11355をイベント・ログに記録します。

Single request header length exceeds configured maximum. A forbidden error response is returned to the client.

デフォルトのヘッダー制限を変更するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。
「Security」ページが表示されます。

2. 「Security」ページの「HTTP Request Header Limits」セクションで、「Edit」をクリックします。
「HTTP Request Header Limits」ダイアログ・ボックスが表示されます。

3. 「Maximum combined header size in bytes」フィールドで、リクエスト内のすべてのHTTPリクエスト・ヘッダー・フィールドの合計サイズを指定します。制限は4096バイト(4 KB)以上に指定してください。

4. 「Maximum individual header size in bytes」フィールドで、各HTTPリクエスト・ヘッダー・フィールドの制限サイズを指定します。制限は256バイト以上に指定してください。

5. 「Submit」をクリックし、「Apply Changes」をクリックします。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

5.7 ClientIPヘッダーが有効であることの確認

ブラウザなどのクライアントは、リクエストのヘッダーでそのIPアドレスに関する情報を送信できます。ただし、クライアントはヘッダーに偽のIPアドレスを使用することがあるため、キャッシュにその情報を別のキャッシュやオリジン・サーバーに転送することを許可すると、セキュリティに問題が発生する可能性があります。デフォルトでは、Oracle Web Cacheは、クライアントから転送されたIPヘッダー情報を削除し、クライアントの正しいIPアドレスを含むヘッダーで置換します。(この場合のクライアントは、ブラウザ、または階層内の別のキャッシュです。)

キャッシュ階層では、Oracle Web Cacheは、階層内のキャッシュ間で転送される情報、またはキャッシュからオリジン・サーバーに転送される情報を保持できる必要があります。

これらを構成するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Security」を選択します。第2.7.2項を参照してください。

2. 「Security」ページの「Security Header Configuration」セクションで、「Accept client IP addresses encoded in ClientIP headers」フィールドの値をチェックします。
値が「NO」の場合、Oracle Web Cacheは、クライアントから転送されたClientIPリクエスト・ヘッダーを削除し、正しいIPアドレスが含まれているヘッダーに置き換えます。

値が「YES」の場合、Oracle Web Cacheはクライアントから受信したヘッダーを受け入れ、そのヘッダーを別のキャッシュまたはオリジン・サーバーに転送できます。

3. 設定値が次の内容と一致しない場合は、「Edit」をクリックし、「Security Header Configuration」ダイアログ・ボックスで設定値を変更します。

- 単純な構成の場合、値は「NO」です。

- キャッシュ・クラスタのすべてのクラスタ・メンバーについて、値は「NO」です。

- 分散キャッシュ階層内のリモート・キャッシュの場合、値は「NO」です。

- 分散キャッシュ階層内で他のキャッシュからのみリクエストを受信する集中キャッシュの場合、値は「YES」です。
集中キャッシュがブラウザと階層内の他のキャッシュの両方からリクエストを受信した場合、Oracle Web Cacheは、ブラウザから受信したリクエストと別のキャッシュから受信したリクエストを区別できません。このため、「YES」に指定すると、誤ったIPアドレスがブラウザから転送される可能性があります。ただし、別のキャッシュからは正しい情報が転送されます。「NO」を指定すると、誤ったIPアドレスがブラウザから転送される可能性がなくなります。ただし、別のキャッシュから転送される情報には、オリジナル・サーバーではなくキャッシュのIPアドレスが含まれます。

4. 「Submit」をクリックし、「Apply Changes」をクリックします。

5. Oracle Web Cacheを再起動します。第2.13項を参照してください。

5.8 セキュアなコンテンツのキャッシュに対するサポートの構成

Oracle Web Cacheは、Oracle Single Sign-On認証によって保護され、ほかに認可要件がないコンテンツのキャッシュをサポートするように構成できます。

Oracle Web Cache Managerでこの設定を有効にするには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Site Definitions」を選択します。第2.7.2項を参照してください。

2. 構成済のサイトを選択し、「Edit Show/Edit Site」をクリックします。

3. 「For Site」ダイアログ・ボックスの「Attributes」セクションで、リクエストされたオブジェクトに必要な認証のタイプを選択します。

- Oracle Single Sign-On: Oracle Single Sign-Onを介した認証を必要とする場合に選択します。Oracle Web Cacheがリクエストを処理するには、有効なOracle Single Sign-OnのCookieが必要です。

- None: 認証を一切必要としない場合に選択します。

4. 「Submit」をクリックします。

5. Oracle Web Cacheを再起動します。第2.13項を参照してください。

5.9 root権限によるwebcachedの実行

UNIXでは、次の場合、webcachedがroot権限で実行されるように構成する必要があります。

- 1024より小さな特権ポート番号をOracle Web Cacheのリスニング・ポートとして使用する場合

- Oracle Web Cacheへの接続に使用されるファイル記述子が1,024よりも多い場合

- 現在のopmnctlユーザーが、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で構成されたプロセス認証ユーザーと一致しない場合

この項では、次の項目について説明します。

- 第5.9.1項「プロセス認証の構成」

- 第5.9.2項「特権ポートおよび1,024よりも多いファイル・ディスクリプタに対するroot権限の構成」

- 第5.9.3項「現在のユーザーのroot権限の構成」

- 第5.9.4項「アクセス権のインストール時の状態へのリセット」

5.9.1 プロセス認証の構成

デフォルトでは、インストールを実行したユーザーがOracle Web Cacheプロセスの所有者となります。このユーザーはopmnctlコマンドを実行できます。インストールを実行したユーザーと同じグループIDに属するユーザーもopmnctlコマンドを実行できます。

現在のopmnctlのユーザーがOracle Web Cache Managerの「Process Identity」ページに構成されているユーザーと一致しない場合は、Oracle Web Cacheのwebcached実行可能ファイルをroot権限で実行する必要があります。webcached実行可能ファイルをroot権限で実行できない場合は、エラー・イベントがイベント・ログ・ファイルに記録され、Oracle Web Cacheは起動に失敗します。

UNIXでOracle Web CacheプロセスのユーザーIDとグループIDを変更するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Process Identity」を選択します。第2.7.2項を参照してください。
「Process Identity」ページが表示されます。

2. 設定を変更するキャッシュを選択し、「Change IDs」をクリックします。
「Change Process Identity」ダイアログ・ボックスが表示されます。

3. 「User ID」フィールドに新しいユーザーを、「Group ID」フィールドにそのユーザーのグループIDを入力します。

4. 「Submit」をクリックします。

5. 次のwebcache_setuser.shスクリプトを使用して、ファイルとディレクトリの所有権を変更します。

webcache_setuser.sh setidentity <user_ID>

この<user_ID>は、「Process Identity」ページの「User ID」フィールドで指定したユーザーです。

setidentityコマンドによって、次のファイルとディレクトリの所有権が新しいユーザーIDに変更されます。

- 次のディレクトリにあるwebcache.xml構成ファイル

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\webcache_name>

- 次のディレクトリにあるイベント・ログ・ファイルとアクセス・ログ・ファイル

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

6. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

5.9.2 特権ポートおよび1,024よりも多いファイル・ディスクリプタに対するroot権限の構成

特権ポートに関する構成を行う場合またはOracle Web Cacheのファイル・ディスクリプタ制限を引き上げるには、2つの方法があります。

- Oracle Web Cacheを実行している特定のユーザーの制限を引き上げます。この方法を使用することをお薦めします。ユーザーの制限の引上げに関する詳細は、オペレーティング・システムのマニュアルを参照してください。

- webcache_setuser.shのsetrootコマンドを使用して、プロセス認証の設定を変更することなくOracle Web Cacheにroot権限を設定します。

Oracle Web Cacheをアップグレードするかパッチを適用するたびに、Oracle Web Cacheのバイナリが暗黙的に再リンクされます。したがって、次の手順に示すようにsetrootコマンドを再実行する必要があります。

webcache_setuser.shのsetrootコマンドを使用するには、次の手順を実行します。

1. $ORACLE_HOME/webcache/binから次のコマンドを実行します。

webcache_setuser.sh setroot user_ID

user_IDはインストールを実行したユーザーです。webcache_setuser.shスクリプトの詳細は、第5.10項を参照してください。

2. コンピュータからログアウトし、Oracle Application Serverをインストールしたユーザーで再度ログインします。

3. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

5.9.3 現在のユーザーのroot権限の構成

構成されたユーザーと現在のユーザーが一致しない構成では、Oracle Web Cacheプロセスのプロセス認証を変更し、webcache_setuser.shのsetidentityコマンドを使用してOracle Web Cacheにroot権限を設定します。

1. Oracle Web Cacheプロセスのプロセス認証を変更します。
制限付きユーザーを使用してOracle Web Cacheを実行することをお薦めします。グループIDとユーザーIDを設定してプロセス認証を確立する方法は、第5.9.1項を参照してください。

2. 別のユーザーとしてOracle Web Cacheを実行するには、webcache_setuser.shスクリプトを次のように使用し、ユーザーIDに対するアクセス権をwebcached実行可能ファイルに追加します。

webcache_setuser.sh setidentity user_ID

このuser_IDは、ステップ2で指定したユーザーIDです。webcache_setuser.shスクリプトの詳細は、第5.10項を参照してください。

3. コンピュータからログアウトし、ステップ2で構成したユーザーで再度ログインします。

4. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

5.9.4 アクセス権のインストール時の状態へのリセット

アクセス権をインストール時の状態に戻すには、webcache_setuser.shのrevertコマンドを使用します。setidentityコマンドの使用後にパッチ・リリースをインストールする場合は、アクセス権を元に戻す必要があります。アクセス権を元に戻さないと、$ORACLE_HOME/webcacheディレクトリ内のファイルに書き込めません。パッチのインストールの完了後に、setidentityコマンドを使用してプロセス認証を再度変更できます。

ファイルのアクセス権をリセットするには、次の手順を実行します。

1. 次のwebcache_setuser.shスクリプトを使用して、ファイル・アクセス権をインストール時の状態に戻します。

webcache_setuser.sh revert user_ID

user_IDはインストールを実行したユーザーです。webcache_setuser.shスクリプトの詳細は、第5.10項を参照してください。

2. コンピュータからログアウトし、Oracle Application Serverをインストールしたユーザーで再度ログインします。

3. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

5.10 UNIXでファイル・アクセス権を設定するためのスクリプト

UNIXオペレーティング・システムの場合は、webcache_setuser.shスクリプトを使用して、Oracle Web Cacheの実行に使用するモードに従ってファイル・アクセス権を設定できます。ファイルwebcache_setuser.shは、$ORACLE_HOME/webcache/binディレクトリにあります。

webcache_setuser.shスクリプトを実行する前に、OPMNユーティリティ・コマンドを使用して、cacheサーバー・プロセスとadminサーバー・プロセスを停止してください。

opmnctl stopproc ias-compononent=WebCache

次に、webcache_setuser.sh構文の書式を示します。

webcache_setuser.sh command user_ID

表5-1で各コマンドについて説明します。

表5-1 webcache_setuser.shスクリプトのコマンド

コマンド

説明

setroot

webcached実行可能ファイルの所有権をrootに設定し、インストールを実行したユーザーとしてOracle Web Cacheを実行します。

setidentity

ランタイムOracle Web Cacheユーザーの所有権を変更します。このコマンドでは、ユーザーIDに対するアクセス権がwebcached実行可能ファイルに追加されます。

revert

ファイル・アクセス権をインストール時の状態に戻します。

setidentityコマンドの使用後にパッチ・リリースをインストールする場合は、アクセス権を元に戻す必要があります。アクセス権を元に戻さないと、$ORACLE_HOME/webcacheディレクトリ内のファイルに書き込めません。パッチのインストールの完了後に、setidentityコマンドを使用してプロセス認証を再度変更できます。

パラメータuser_IDは、Oracle Web Cacheプロセスと関連付けられているユーザーIDです。(デフォルトでは、そのユーザーIDはインストールを実行したユーザーのIDです。)setrootおよびrevertモードについては、ユーザーIDはインストールを実行したユーザーのIDである必要があります。このユーザーIDは、Oracle Web Cache Managerの「Process Identity」ページ(「Properties」→「Process Identity」)で指定したユーザーIDと一致する必要があります。webcache_setuser.shスクリプトの実行が必要となる状況の詳細は、第5.9項を参照してください。

6 コンテンツのキャッシュと圧縮

この章では、Oracle Web Cacheを使用してコンテンツをキャッシュおよび圧縮する方法について概説します。キャッシュへのデータの格納、キャッシュの一貫性およびキャッシュ・ルールについて説明します。また、キャッシュ・ルールと有効期限ポリシーを構成するためのプロパティについて説明します。

この章の項目は次のとおりです。

- 第6.1項「キャッシュへのデータ格納について」

- 第6.2項「キャッシュの一貫性について」

- 第6.3項「キャッシュ・デシジョンについて」

- 第6.4項「キャッシュ・ルールの作成の概要」

- 第6.5項「詳細設定の構成の概要」

- 第6.6項「キャッシュ・ルールを構成および監視するための基本的な作業」

- 第6.7項「有効期限ポリシーの構成」

- 第6.8項「キャッシュ・ルールの構成と監視」

- 第6.9項「キャッシュ・ルールのサマリー設定の監視」

- 第6.10項「Surrogate-Controlレスポンス・ヘッダーをキャッシュ・ルールの代替として使用」

6.1 キャッシュへのデータ格納について

キャッシュ・ルールを定義して、キャッシュするオブジェクトを決定します。キャッシュ・ルールを作成した場合、そのルールに一致するオブジェクトは、クライアント・リクエストがあるまでキャッシュされません。クライアントが最初にオブジェクトをリクエストすると、Oracle Web Cacheはそのリクエストをオリジン・サーバーに送信します。このリクエストはキャッシュ・ミスになります。このURLにはキャッシュ・ルールが関連付けられているため、Oracle Web Cacheは後続のリクエストのためにそのオブジェクトをキャッシュに格納します。Oracle Web Cacheは、同じオブジェクトに対して2度目のリクエストを受けると、そのオブジェクトをキャッシュからクライアントに送信します。このリクエストはキャッシュ・ヒットになります。

Oracle Web Cacheを停止すると、キャッシュのすべてのオブジェクトが削除されます。さらに、Oracle Web Cacheによって統計もリセットされます。

Oracle Web Cacheがキャッシュ・ルールによってキャッシュへのデータ格納を決定する方法については、第6.3項を参照してください。

6.2 キャッシュの一貫性について

Oracle Web Cacheの信頼性を確保する上で、一貫性は非常に重要です。次の機能によって、キャッシュとオリジン・サーバー間の一貫性が確保されます。

- 第6.2.1項「有効期限」

- 第6.2.2項「HTTPキャッシュの検証」

- 第6.2.3項「無効化」

6.2.1 有効期限

有効期限によって、Oracle Web Cacheはキャッシュ内に一定期間存在したオブジェクトを無効にします。オリジン・サーバーまたはデータベースでコンテンツが変更されるタイミングを正確に予測できる場合は、有効期限を使用すると便利です。オブジェクトがいつまでもキャッシュ内に残ることがないように、すべてのキャッシュ・オブジェクトに対して有効期限ポリシーを作成することをお薦めします。

有効期限ポリシーの作成方法は、第6.7項を参照してください。

6.2.2 HTTPキャッシュの検証

Oracle Web Cacheは、HTTP/1.1検証モデルを使用して、クライアントに対する最適なレスポンス送信方法を判断します。検証では、2つのバリデータを比較して、それらが同じエンティティを表すのか、異なるエンティティを表すのかが判断されます。具体的には、Oracle Web CacheはIf-Modified-SinceヘッダーとIf-None-Matchヘッダーを使用して、次の妥当性を決定します。

- キャッシュされたコピーのヘッダーと比較して、ブラウザのヘッダーが有効であること

- オリジン・サーバーのヘッダーと比較して、キャッシュされたコピーのヘッダーが有効であること

注意:
Oracle Web Cacheは、If-None-Matchバリデータに対して弱いバリデータはサポートしていません。Oracle Web Cacheは、他のすべてのIf-None-Matchリクエスト・ヘッダー・フィールドの書式をサポートしています。

検証の詳細は、次を参照してください。

- キャッシュの検証の詳細は、HTTP/1.1仕様書(http://www.ietf.org/rfc/rfc2616.txt)の第13.3項「Validation Model」を参照してください。

- コンテンツを無効にする方法は、第6.2.3項を参照してください。

- 有効期限ポリシーの作成方法は、第6.7項を参照してください。

6.2.3 無効化

有効期限を予測できないコンテンツに対しては、無効化を使用できます。無効化によって、Oracle Web Cacheはオブジェクトを無効にします。オブジェクトが無効になった後にクライアントがそれらをリクエストすると、オブジェクトはキャッシュから削除され、オリジン・サーバーから新しいコンテンツが取得されてキャッシュが更新されます。無効になったオブジェクトはすぐに削除して新しいものに更新するか、あるいはオリジン・サーバーの現在の負荷に基づいて、削除と更新を行うことが可能です。

無効化の詳細は、第7章「コンテンツの無効化」を参照してください。

6.3 キャッシュ・デシジョンについて

キャッシュ・ルールにより、静的オブジェクト、複数バージョンのオブジェクト、パーソナライズ・ページ、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータをサポートするページ、および動的ページのコンテンツをキャッシュするかどうかを選択できます。

Fusion Middleware Controlを使用して、URLまたはContent-Typeレスポンス・ヘッダーに基づいたキャッシュ属性を指定することでキャッシュ・ルールを構成するか、またはSurrogate-Controlレスポンス・ヘッダー・フィールド内の特定のオブジェクトに対してキャッシュ属性を設定します。ルールに一致するオブジェクトがクライアントによってリクエストされるまで、それらのオブジェクトはキャッシュに格納されません。

Oracle Web Cacheでは、次の優先順位を使用して、オブジェクトがキャッシュ可能かどうかを決定します。

1. Surrogate-Controlレスポンス・ヘッダー

2. Fusion Middleware Controlを使用して構成されたキャッシュ・ルール

3. その他のHTTPヘッダー:

- Authorizationリクエスト・ヘッダー

- Proxy-Authorizationリクエスト・ヘッダー

- Pragma: no-cacheレスポンス・ヘッダー

- Warningレスポンス・ヘッダー

これらのヘッダーのいずれかが存在する場合、Oracle Web Cacheでは、オブジェクトがキャッシュされません。

4. Cookieリクエスト・ヘッダーおよびSet-Cookieレスポンス・ヘッダーのCookie値

5. Cache-Controlレスポンス・ヘッダー

6. Expiresレスポンス・ヘッダー

Surrogate-Controlレスポンス・ヘッダー・フィールドを使用すると、Fusion Middleware Controlによって構成されたキャッシュ・ルールをオリジン・サーバー側でオーバーライドできます。同じオブジェクトに対してSurrogate-Controlレスポンス・ヘッダーとキャッシュ・ルールの両方がある場合、Oracle Web Cacheはこの2つをマージします。たとえば、キャッシュ不可のオブジェクトに対してFusion Middleware Controlで圧縮が使用可能に設定されているキャッシュ・ルールがあり、レスポンス・ヘッダーにSurrogate-Control: max-age=30+60という記述が含まれている場合、Oracle Web Cacheは両方の設定を考慮します。Oracle Web Cacheは、オブジェクトのキャッシュにSurrogate-Controlレスポンス・ヘッダーのmax-age制御ディレクティブを使用し、キャッシュ・ルールから圧縮の設定を使用します。Surrogate-Controlレスポンス・ヘッダーとキャッシュ・ルールの間に競合がある場合、Oracle Web CacheではSurrogate-Controlレスポンス・ヘッダーの設定が使用されます。

キャッシュ・ルールもSurrogate-Controlレスポンス・ヘッダーも指定されていない場合、Oracle Web CacheはHTTPプロキシ・キャッシュと同様に動作します。つまり、HTTPヘッダー情報を使用して何がキャッシュ可能かを判断します。一般的に、HTTPプロキシ・キャッシュには静的コンテンツを含むページのみが格納されます。

注意:

- 再起動時や一括無効化処理の実行後は、WGETなどのフリーウェアのWebクローラを使用してキャッシュにあらかじめデータを格納しておくことができます。WGETの詳細は、http://www.gnu.org/software/wget/wget.htmlを参照してください。

- Oracle Web Cacheを停止すると、キャッシュ内のオブジェクトがすべて削除されます。さらに、統計もすべて削除されます。

Oracle Web Cacheがキャッシュへのデータ格納を決定する方法については、第6.1項を参照してください。

6.4 キャッシュ・ルールの作成の概要

オブジェクトに対するキャッシュ・ルールを作成する場合は、まずオブジェクトのルールを特定のサイトに対して設定するのか、すべてのサイトに対してグローバルに設定するのかを決定します。サイト固有のキャッシュ・ルールは、グローバル・ルールよりも優先されます。ルールの対象を決定したら、次にルールの一般的な属性を構成します。

- 名前、説明、サイト、有効にするかどうかなど、ルールについての情報

- 受信リクエストがルールに一致する場合にOracle Web Cacheが実行するアクション

- 受信リクエストに一致するルールをOracle Web Cacheが見つけるための一致条件

一致評価の条件として、リクエストのURL式またはレスポンスのMIMEタイプ、あるいはその両方を使用するのかを選択します。一致条件を選択しない場合、Oracle Web CacheはすべてのURLおよびすべてのMIMEタイプとルールを一致させます。

URL式の入力が面倒な場合には、MIMEタイプに基づいて一致評価を行います。たとえば、各種のイメージ・タイプに対する複雑なURL式を次に示します。

\.(gif|jpe?g|png|bmp)$

かわりに、「MIMEタイプ」オプションを選択し、「次で始まる」を選択して、式フィールドに次の文字列を入力します。

image/

Content-Typeレスポンス・ヘッダーは、通常追加のコンテンツ・パラメータ値を持つため、ほとんどの一致評価では、「次で始まる」オプションを選択します。

式フィールドにはカンマで区切ったリストも入力できます。同じ例で、GIFまたはJPEGレスポンスにのみ一致させたい場合は、式フィールドに次の文字列を入力します。

image/gif, image/jpeg

キャッシュ・ルールを作成したら、次にキャッシュ・ルールの優先順位を指定します。優先順位の高いルールが最初に一致します。サイト固有のキャッシュ・ルールは、グローバルなキャッシュ・ルールよりも優先されます。キャッシュ可能なオブジェクトとキャッシュ不可のオブジェクトのキャッシュ・ルールの順序付けでは、キャッシュ不可のオブジェクトに対して、キャッシュ可能なオブジェクトより高い優先順位を指定します。

表6-1に示されているルールの場合、ルール2は、GETメソッドおよび問合せ文字列を含むGETメソッドを使用するURLのオブジェクトをキャッシュし、ルール3は、POSTメソッドおよびaction=searchに一致するPOST本体を使用するURLのオブジェクトをキャッシュします。順位が反転すると、/cec/cstage?ecaction=ecpassthru2を含めて、/cec/cstage?ecaction=ecpassthruで開始するすべてのオブジェクトがキャッシュされます。

表6-1 異なるHTTPメソッドの優先順位の例

優先順位

一致条件

HTTPメソッド

POST本体式

アクション

1

URL式:

正規表現: ^/cec/cstage\?ecaction=ecpassthru2

パス接頭辞: /cec/cstage\?ecaction=ecpassthru2

GETおよび問合せ文字列を含むGET

なし

キャッシュしない

2

URL式:

正規表現: ^/cec/cstage\?ecaction=ecpassthru.*

パス接頭辞: /cec/cstage\?ecaction=ecpassthru

GETおよび問合せ文字列を含むGET

なし

キャッシュ

3

URL式:

正規表現: ^/cec/cstage\?ecaction=ecpassthru.*

パス接頭辞: /cec/cstage\?ecaction=ecpassthru

POST本体式

action=search

キャッシュ

4

MIMEタイプ:

/image

GETおよび問合せ文字列を含むGET

なし

キャッシュ

キャッシュ・ルールの一般的な属性の指定および優先順位の指定に関する詳細は、第6.8.1項を参照してください。

6.5 詳細設定の構成の概要

一般的な属性に加え、次に説明するように詳細設定を構成できます。

- 第6.5.1項「複数のバージョンを持つオブジェクトのキャッシュ」

- 第6.5.2項「埋込みURLパラメータとPOST本体パラメータを持つオブジェクトのキャッシュ」

- 第6.5.3項「エラー・レスポンスのキャッシュ」

- 第6.5.4項「セッションを持つオブジェクトのキャッシュ」

- 第6.5.5項「セッション・エンコードされたURLを持つオブジェクトのキャッシュ」

6.5.1 複数バージョンを持つオブジェクトのキャッシュ

ページによっては、複数のバージョンが存在してカテゴリ化が可能な場合があります。図6-1に、同じhttps://oraclestore.oracle.com/OA_HTML/ibeCCtpItmDspRte.jsp?item=293017&section=11538というオブジェクトを使用して、顧客とオラクル社の従業員に対してそれぞれ異なる価格を表示するページを示します。顧客はec-400-id-acctcat=WALKINというCookie名と値を渡していますが、従業員はec-400-id-acctcat=INTERNALというCookie名と値を渡しています。

図6-1 複数のバージョンを持つオブジェクト

「図6-1 複数のバージョンを持つオブジェクト」の説明

Oracle Web Cacheを構成することにより、次の情報を使用して複数バージョンのページの識別およびキャッシュが可能です。

- ページのCookieの値

- ページのHTTPリクエスト・ヘッダー

Cookie(カテゴリCookieとも呼ばれる)を使用するオブジェクトの場合、Cookie名と、そのCookieを使用しないバージョンのオブジェクトをキャッシュするかどうかを指定するキャッシュ・ルールを構成します。

複数のバージョンを持つオブジェクトに対するリクエストがクライアントから初めて送信されると、Oracle Web Cacheはそのリクエストをオリジン・サーバーに渡します。オリジン・サーバーは、カテゴリがCookieで、値が次のように設定されたSet-Cookieレスポンス・ヘッダーをレスポンスに含めます。

Set-Cookie:cookie=value

Oracle Web Cacheでは、この最初のレスポンスはキャッシュされません。クライアントは、Set-Cookieレスポンス・ヘッダー・フィールドを受け取ると、Cookieをメモリーに保存します。次回、同じオリジン・サーバーにリクエストを送信するときには、クライアントはCookieリクエスト・ヘッダー・フィールドに、前回のレスポンスで受け取ったカテゴリCookieの名前と値を次の形式で設定します。

Cookie:cookie=value

Oracle Web Cacheは引き続きオリジン・サーバーにリクエストを転送し、オリジン・サーバーからはSet-Cookieヘッダーを含んだ、または含まないレスポンスが返されます。Oracle Web Cacheは、Set-Cookieレスポンス・ヘッダーに設定されたCookieとその値が、Cookieリクエスト・ヘッダーに設定されたCookieとその値と一致するかどうかを評価します。Cookieとその値が一致すると、レスポンスがキャッシュされます。Set-Cookieヘッダーがない場合は一致と見なされます。Cookieとその値が一致しない場合、レスポンスはキャッシュされません。複数バージョンのオブジェクトがキャッシュされると、Oracle Web Cacheは、クライアントのリクエストのCookieの値を使用して、クライアントのブラウザに該当するバージョンのオブジェクトを返します。

注意:
Oracle Web Cacheでは、Set-Cookieレスポンス・ヘッダー・フィールドはキャッシュされません。

表6-2に、同じURL http://www.dot.com/page1.htmの4つの異なるバージョンを示します。URLはuser_typeという名前のCookieを使用します。これは、Customer、InternalおよびPromotionalというCookie値を含むクライアント・リクエストをサポートします。Oracle Web Cacheがuser_type Cookieを認識するように構成することにより、Oracle Web Cacheに3つの異なるオブジェクトをキャッシュさせることができます。また、Cookieを使用しないリクエストに対する4番目のオブジェクトをキャッシュするようにOracle Web Cacheを構成することもできます。

表6-2 異なるCookieの値を使用したオブジェクトの複数バージョン

バージョン

URL(URL)

Cookieの名前と値

1

http://www.dot.com/page1.htm

user_type=Customer

2

http://www.dot.com/page1.htm

user_type=Internal

3

http://www.dot.com/page1.htm

user_type=Promotional

4

http://www.dot.com/page1.htm

Cookieなし

HTTPリクエスト・ヘッダーに基づいて異なるバージョンを使用するオブジェクトの場合、HTTPリクエスト・ヘッダーを指定するキャッシュ・ルールを構成します。HTTPリクエスト・ヘッダーにより、クライアントはリクエストおよびクライアント自身に関する追加情報を渡すことが可能です。Oracle Web Cacheでは、リクエスト・ヘッダーを使用して、該当するバージョンのURLをクライアントに渡します。

Oracle Web Cacheでは、有効なHTTPリクエスト・ヘッダーをすべてサポートしています。表6-3に、Fusion Middleware ControlでサポートされているHTTPリクエスト・ヘッダー・フィールドを示します。標準または他のHTTPリクエスト・ヘッダー・フィールドを指定するには、Surrogate-Controlレスポンス・ヘッダー・フィールドを使用します。

表6-3 HTTPリクエスト・ヘッダー・フィールド

ヘッダー・フィールド

説明

Accept

レスポンスに使用可能なメディア・タイプを指定します。

例: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*

Accept-Charset

レスポンスに使用可能なキャラクタ・セットを指定します。

例: Accept-Charset: iso-8859-1,*,utf-8

Accept-Encoding

レスポンスのコンテンツに使用可能なエンコーディングを制限します。

例: Accept-Encoding: gzip

Accept-Language

レスポンスに使用する言語セットを指定します。

例: Accept-Language: en

User-Agent

リクエストを発信したクライアントに関する情報が含まれます。

例: User-Agent: Mozilla/4.61 [en] (WinNT; U)

注意:
Oracle Web Cacheでは、デフォルトでこれらのHTTPリクエスト・ヘッダーの値が解析されません。2つのページの値が異なる場合、Oracle Web Cacheによりそれらのページは別々にキャッシュされます。
この問題は、User-Agentリクエスト・ヘッダーの場合は特に処理が複雑で、ブラウザのタイプ、バージョンおよびオペレーティング・システムごとに重複したキャッシュ・エントリが過剰に作成される場合があります。たとえば、異なるバージョンのInternet Explorerに対して、あるリクエストではUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows)というHTTPリクエスト・ヘッダー・フィールドが送信され、別のリクエストではUser-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows; DigExt)というHTTPリクエスト・ヘッダー・フィールドが送信された場合、Oracle Web Cacheではこれら2つのリクエストに対して2つのページが処理されます。

User-Agentリクエスト・ヘッダーに対するこの動作をオーバーライドするには、第6.8.4項の説明に従って、同じブラウザ・タイプの同じページをキャッシュして表示するようにOracle Web Cacheを構成します。

構成の詳細は、第6.8.2項を参照してください。

6.5.2 埋込みURLパラメータとPOST本体パラメータを持つオブジェクトのキャッシュ

デフォルトでは、Oracle Web Cacheは、オリジン・サーバーのレスポンスをリクエストURLによって識別します。ただし、リクエストに埋込みURLパラメータまたはPOST本体パラメータが含まれている場合、同じページ・コンテンツのリクエストURLはセッションごとに個別になります。したがって、Oracle Web Cacheでは、個別URLごとにレスポンスがキャッシュされます。その結果、キャッシュ・ヒット率が低くなり、キャッシュ内のオブジェクトに冗長性が生じます。

Oracle Web Cacheが埋込みURLパラメータまたはPOST本体パラメータの値を無視するように構成すると、Oracle Web Cacheは、同じページをリクエストする複数のセッションを1つのキャッシュ・オブジェクトで処理できます。Oracle Web Cacheは、最初のリクエストへのレスポンスをキャッシュし、そのページへの後続のリクエストをこのキャッシュから処理します。

たとえば、ユーザーJane Doeが次のリクエストURLを持つページにアクセスしているとします。

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33436

ユーザーJohn Doeが次のリクエストURLを持つ同じページにアクセスするとします。

https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10103&session_ID=33437

また、このページには、Jane DoeとJohn Doeのそれぞれに対して次のPOST本体が含まれるとします。

section=1013
&session_ID=3346

section=1013
&session_ID=3347

リクエストURLとPOST本体で異なっているのは、session_IDパラメータの値のみです。このとき、同じオブジェクトの2つのバージョンをキャッシュして送信するのではなく、キャッシュ内の1つのオブジェクトを両方のユーザーに送信するために、session_IDの値を無視するようにOracle Web Cacheを構成します。

無視するパラメータを構成するには、すべてのキャッシュ・ルールに適用されるグローバル・パラメータを確立するか、特定のサイトのキャッシュ・ルールに適用されるサイト固有のパラメータを確立します。第6.8.3項を参照してください。

6.5.3 エラー・レスポンスのキャッシュ

オリジン・サーバーで問題が発生し、このルールに一致するリクエストに対するHTTPレスポンスのステータスが200 OKでない場合、Oracle Web Cacheはオリジン・サーバーへのリクエストの再送を試みません。かわりに、キャッシュしたHTTPエラーを返し、既知の不正なレスポンス用のオリジン・サーバーのリソースを節約します。

Oracle Web Cacheでは、デフォルトで、200 OK以外のHTTPレスポンスがキャッシュされません。これらのエラーがキャッシュされるようにするには、エラー・レスポンスを明示的にキャッシュするようにキャッシュ・ルールを構成する必要があります。Oracle Web Cacheは、ルールの有効期限ポリシーに従ってエラー・ページをキャッシュします。問題が解決した後は、HTTPエラー・レスポンスを無効にしてください。

構成の詳細は、第6.8.5項を参照してください。

6.5.4 セッションを持つオブジェクトのキャッシュ

Oracle Web Cacheでは、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータが存在するリクエストまたは存在しないリクエストの処理方法を指定できます。次の選択が可能です。

- セッションCookie、埋込みURLパラメータまたはPOST本体パラメータを持つリクエストに対して、キャッシュ内のオブジェクトを送信または送信しません。

- セッションCookie、埋込みURLパラメータまたはPOST本体パラメータを持たないリクエストに対して、キャッシュ内のオブジェクトを送信または送信しません。

たとえば、新規ユーザーの最初のリクエストを受けたときにオリジン・サーバーからセッションを確立する場合、セッションCookieまたはパラメータを持つリクエストに対してはキャッシュ内のオブジェクトを送信し、セッションCookieまたはパラメータを持たないリクエストに対してはキャッシュ内のオブジェクトを送信しないように選択します。

両方に対してオブジェクトを送信するように選択した場合、セッションCookieやパラメータを持つリクエストまたは持たないリクエストで、同じキャッシュ内のオブジェクトを共有するかどうかを指定できます。Oracle Web Cacheでは、Cookieまたはパラメータが含まれないリクエストに対して、デフォルトの文字列が使用されます。

構成の詳細は、第6.8.6項を参照してください。

6.5.5 セッション・エンコードされたURLを持つオブジェクトのキャッシュ

第6.5.2項では、すべてのセッションにおいてコンテンツが同一であるオブジェクトに対して、埋込みURLパラメータまたはPOST本体パラメータの値を無視する方法について説明しています。ただし、オブジェクトのHTMLコンテンツが<A HREF=...>のようなハイパーリンク・タグでプログラミングされ、これにユーザーを識別するための埋込みセッション情報が含まれている場合があります。このようなリンクはセッション・エンコードされたURLと呼ばれます。セッション・エンコードされたURLを使用すると、セッション間でごくわずかな相違を持つレスポンスが生成されます。

HTMLハイパーリンク・タグのセッションを、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータから取得したセッション値で置換するように、Oracle Web Cacheを構成できます。セッション値の置換を、埋込みURLパラメータの値の無視と組み合せて構成することで、セッション・エンコードされたURLのセッション・パラメータの値が変更になった場合でも、1つのオブジェクトが複数のセッション用にキャッシュされるようにOracle Web Cacheを構成できます。

注意:
Oracle Web Cacheでは、Set-Cookieレスポンス・ヘッダー・フィールドはキャッシュされません。

第6.5.2項の例において、オリジン・サーバーによってJane DoeおよびJohn Doeにそれぞれsession_ID=33436およびsession_ID=33437という埋込みURLパラメータが割り当てられているとします。図6-2に示されたページには、session_IDパラメータを含んでいる<A HREF=...>リンクが複数存在します。Jane Doeの場合、「Oracle Database」ヘッダーの下の「Oracle Database Standard Edition」リンクには、次のHTMLコードが使用されます。

<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334326">Oracle Database Standard Edition</A>

John Doeの場合、同じリンクに次のHTMLコードが使用されます。

<A HREF="http://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=10166&session_ID=334327">Oracle Database Standard Edition</A>

Oracle Web Cacheでは、session_ID埋込みURLパラメータの値を使用することにより、Jane DoeおよびJohn Doeのそれぞれに該当するセッション情報に置換します。

図6-2 セッション・エンコードされたURL

「図6-2 セッション・エンコードされたURL」の説明

セッション・エンコードされたURLを含むページがキャッシュに挿入されると、そのページに対する後続のリクエストは、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータのどれを使用しているかに関係なく、キャッシュで処理されます。リクエストにセッションCookieまたは埋込みURLパラメータが含まれていない場合は、セッション・エンコードされたURLのセッション情報が任意の値に構成されたデフォルトの文字列で置換されるように、Oracle Web Cacheを構成できます。

構成の詳細は、第6.8.7項を参照してください。

6.6 キャッシュ・ルールを構成および監視するための基本的な作業

次に、オブジェクトをキャッシュおよび監視するために必要な手順のサマリーを示します。

1. 有効期限ポリシーを構成します。第6.7項を参照してください。

2. Oracle Web Cacheでリクエストを管理するサイトを作成します。第2.11.3項および第2.11.4項を参照してください。

3. キャッシュ・ルールの一般設定を構成します。第6.8.1項を参照してください。

4. キャッシュ・ルールの詳細設定を構成します。

- 複数バージョンのオブジェクトをサポートしているルールのCookieとHTTPリクエスト・ヘッダー・フィールドを構成します。第6.8.2項を参照してください。

- 埋込みURLパラメータまたはPOST本体パラメータの値を無視するようにOracle Web Cacheを構成します。第6.8.3項を参照してください。

- ルールのエラー・レスポンスを構成します。第6.8.5項を参照してください。

- ルールのセッション設定を構成します。第6.8.6項を参照してください。

- セッション・エンコードされたURLに対するサポートを構成します。第6.8.7項を参照してください。

5. Oracle Web Cacheを再起動してキャッシュ・ルールを適用します。第2.13項を参照してください。

6. キャッシュ・ルールの統計を監視します。第6.9項を参照してください。

7. ポピュラーなリクエストを表示します。第8.2項を参照してください。

6.7 有効期限ポリシーの構成

キャッシュ・ルールを作成する前に、有効期限ポリシーを作成します。後でキャッシュ・ルールを作成するときに、そのキャッシュ・ルールで適用する有効期限ポリシーを指定します。

キャッシュ内でオブジェクトが期限切れになるタイミングを指定する有効期限ポリシーを作成できます。さらに、オブジェクトが期限切れになった後に、キャッシュ内に存続する期間を指定することも可能です。オブジェクトが期限切れになると、Oracle Web Cacheはすぐに削除するか、または、オリジン・サーバーの容量によって許可される最大時間制限まで待って削除します。

有効期限ポリシーを作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「有効期限」を選択します。
「有効期限ポリシー」ページが表示されます。

3. 「作成」をクリックします。
「有効期限ポリシーの作成」ダイアログ・ボックスが表示されます。

4. 「オブジェクトの有効期限」セクションで、オプションを選択してオブジェクトを期限切れにするタイミングを指定します。

- HTTP Expiresヘッダーのとおり: HTTPのCache-ControlまたはExpiresレスポンス・ヘッダー・フィールドに従う場合は、このオプションを選択します。これはデフォルトです。

- エントリ・キャッシュの後: オブジェクトがキャッシュに入った時間によって期限を設定する場合は、このオプションを選択します。オブジェクトを期限切れにする時間を「時間制限」フィールドに入力します。

- 作成後: オブジェクトが作成された時間によって期限を設定する場合は、このオプションを選択します。オブジェクトを期限切れにする時間を「時間制限」フィールドに入力します。

5. 「期限切れのオブジェクトに対するアクション」セクションで、期限切れ後のオブジェクトをOracle Web Cacheでどのように処理するかを指定します。

- 即時削除: Oracle Web Cacheで、オブジェクトを無効にしてすぐに削除します。キャッシュがそのオブジェクトに対する次のリクエストを受信すると、オリジン・サーバーからオブジェクトが更新されます。

- オリジン・サーバーが許可した後に必要に応じてリフレッシュ: Oracle Web Cacheで、オブジェクトを失効させ、オリジン・サーバーの許容量に基づいて更新します。オリジン・サーバーに過剰な負荷がかかる場合は、Oracle Web Cacheが失効コンテンツを処理することがあります。オブジェクトをキャッシュに残して無効な状態で表示できる最大期間を「時間制限」フィールドに入力します。

6. 「OK」をクリックして変更を適用します。

7. Oracle Web Cacheを再起動します。第2.13項を参照してください。

6.8 キャッシュ・ルールの構成と監視

この項では、Oracle Web Cacheのキャッシュ・ルールを構成する方法について説明します。次のトピックが含まれます:

- 第6.8.1項「一般ルール設定の構成」

- 第6.8.2項「1つのオブジェクトに複数のバージョンがある場合のルールの設定の構成」

- 第6.8.3項「埋込みURLパラメータまたはPOST本体パラメータの値の除外」

- 第6.8.4項「HTTPリクエスト・ヘッダーが含まれる複数バージョンのオブジェクトの類似ブラウザ・タイプの認識」

- 第6.8.5項「ルールのエラー・レスポンスの構成」

- 第6.8.6項「セッション・キャッシュ・ルールの構成」

- 第6.8.7項「セッション・エンコードされたURLに対するサポートの構成」

- 第6.8.8項「セッションの確立を含むポピュラーなページに対するルールの構成」

6.8.1 一般ルール設定の構成

キャッシュ・ルールを作成する前に、まず特定のサイトに対してルールを設定するのか、すべてのサイトに対してグローバルに設定するのかを決定します。サイト固有のキャッシュ・ルールは、グローバル・ルールよりも優先されます。

キャッシュ・デシジョンの詳細は、第6.3項を参照してください。

キャッシュ・ルールを作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「キャッシュ・ルール」を選択します。
「キャッシュ・ルール」ページが表示されます。

3. 新しいルールを作成します。

1. 「サイト固有のキャッシュ・ルール」または「グローバル・キャッシュ・ルール」セクションで、「作成」をクリックします。

「キャッシュ・ルールの作成」ページに「一般」タブが表示されます。

2. 表6-4の説明を参照して、各要素を入力します。

要素の入力時には、「一致条件」セクションで、一致評価の条件として、リクエストのURL式またはレスポンスのMIMEタイプ、あるいはその両方を使用するのかを選択します。一致条件を選択しない場合、Oracle Web CacheはすべてのURLおよびすべてのMIMEタイプとルールを一致させます。

ルールに対するURL式の入力が面倒な場合は、「一致条件」セクションで「MIMEタイプ」オプションを選択します。複雑なURL式のかわりに「MIMEタイプ」オプションを使用する場合の詳細は、第6.4項を参照してください。

3. 変更を適用して「キャッシュ・ルール」ページに戻るには、「OK」をクリックします。この変更を適用するために、「キャッシュ・ルールの作成」ページで「適用」をクリックする必要はありません。

「サイト固有のキャッシュ・ルール」または「グローバル・キャッシュ・ルール」表にキャッシュ・ルールが追加されることに注意してください。

4. 追加の各ルールに対して、ステップ3を繰り返します。

5. 「上に移動」アイコンと「下に移動」アイコンを使用して、ルールをリクエストと照合する順序を変更します。
ルールの順序は重要です。Oracle Web Cacheでは最初に優先度の高いルールが照合されます。

6. 「適用」をクリックして移動を適用します。

7. 「キャッシュ・ルール」ページで、「有効化」をクリックしてルールを有効にします。
「有効化」をクリックしないと、ルールの設定がすべて無視されます。

8. Oracle Web Cacheを再起動します。第2.13項を参照してください。

表6-4 「キャッシュ・ルール」-「一般」ページ

要素

説明

名前

キャッシュ・ルールを一意に識別する文字列を入力します。

説明

キャッシュ・ルールについて説明するコメントを入力します。

有効

キャッシュ・ルールを有効にする場合は選択し、ルール定義を失うことなくキャッシュ・ルールを一時的に無効にする場合は選択を解除します。

サイト

このルールを適用するサイトが表示されます。

必要なサイトが見つからない場合は、第2.11.3項の手順に従ってサイトを作成します。

キャッシュ

コンテンツをキャッシュする場合は、このオプションを選択します。リクエストをオリジン・サーバーに転送し、コンテンツをキャッシュしない場合は、このオプションを選択解除します。

有効期限

リストから、オブジェクトに適用する有効期限ポリシーを選択します。オブジェクトに適した有効期限ポリシーが見つからない場合は、「有効期限ポリシー」リンクをクリックします。

圧縮

圧縮されたキャッシュ可能およびキャッシュ不可のオブジェクトをブラウザに送信する場合は、このオプションを選択します。このルールで圧縮を有効にするには、サイトでも圧縮を有効にする必要があります。

サイトの圧縮プロパティの設定方法は、第2.11.3項を参照してください。

Oracle Web Cacheでは、圧縮済であることがわかっているいくつかの一般的なファイル・タイプについては、圧縮が自動的に無効になります。GIF、JPEGおよびPNGイメージを含むこのようなファイル・タイプ、または、WinZipやGZIPなどのユーティリティを使用して圧縮されたファイルのコンテンツは、圧縮しないことをお薦めします。これらのファイルを圧縮すると、圧縮の利点を受けることなく、さらにオーバーヘッドが生じます。Oracle Web Cacheで圧縮が自動的に無効になる場合については、第1.2.5項を参照してください。

URL一致条件

URL式を一致評価の基準にする場合に選択します。

1. 式タイプを選択します。
-ファイル拡張子: .gifなど特定のファイル拡張子で終わるオブジェクトにキャッシュ・ルールを適用する場合に選択します。

横のフィールドにファイル拡張子を入力します。Oracle Web Cacheでは、内部的にファイル拡張子がピリオド(.)で始まるため、ピリオドを入力する必要はありません。

-パス接頭辞: パス接頭辞に一致するオブジェクトにキャッシュ・ルールを適用する場合に選択します。

横のフィールドに、オブジェクトのパス接頭辞を入力します。パスは/から開始します。パスをhttp://host_name:port/から開始しないでください。

接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。このような文字として、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、キャレット(^)、ドル記号($)および円記号(¥)があります。

-正規表現: 正規表現構文に一致するオブジェクトにキャッシュ・ルールを適用する場合に選択します。

横のフィールドに、オブジェクトの正規表現を入力します。URLの始まりを示す「^」およびURLの終わりを示す「$」を忘れずに使用してください。

2. リクエストの照合時に大文字と小文字を区別するには、「大/小文字区別なしの一致」チェック・ボックスを選択します。このチェック・ボックスを選択しない場合は、大文字と小文字を区別してルールが照合されます。

MIMEタイプ

Content-Typeレスポンス・ヘッダーを一致評価の基準にする場合に選択します。

1. Oracle Web CacheがレスポンスのMIMEタイプの式値をどこで検索するかを決定する演算値を選択します。
-次と等しい: 式と等しいMIMEタイプと照合することをOracle Web Cacheに指示する場合に選択します。

-次で始まる: Oracle Web CacheにMIMEタイプが式で開始するかどうかを照合するよう指示する場合に選択します。

-次を含む: Oracle Web CacheにMIMEタイプが式を含むかどうかを照合するよう指示する場合に選択します。

Content-Typeレスポンス・ヘッダーは、通常追加のコンテンツ・パラメータ値を持つため、ほとんどの一致評価では、「次で始まる」オプションを選択します。「次と等しい」を選択した場合、一致は予想どおりに動作しないことがあります。

2. 付属のフィールドに、Oracle Web CacheでレスポンスのMIMEタイプと比較する文字列値を入力します。式フィールドにカンマで区切ったリストを入力できます。

HTTPメソッド

次の中から、1つ以上のHTTPリクエスト・メソッドを選択します。

- GET: Webページの単純なリクエストに使用されるHTTPリクエスト・メソッド。GETメソッドはURLで構成されます。GETメソッドを使用するページへのリクエストは、通常キャッシュされます。

- 問合せ文字列を含むGET: パラメータおよび値が含まれているURLおよび問合せ文字列によって構成されたHTTPリクエスト・メソッド。

- POST本体式: Webアプリケーション・サーバーのデータ・ストアの内容を変更するリクエストに使用されるHTTPリクエスト・メソッド。たとえば、メーリング・リストへのメッセージの送信、登録用フォームの送信またはデータベースへのエントリの追加など。

注意: ご使用のWebサイトで、問合せ文字列が含まれるGETまたはPOSTメソッドが、オリジン・サーバーまたはデータベースに変更を加えるフォームで使用されている場合は、「問合せ文字列を含むGET」または「POST本体式」を選択しないでください。これらのオプションは、フォームが検索フォームで使用されている場合のみ選択してください。

必要なリクエスト・パラメータ

「追加」をクリックし、埋込みURLパラメータまたはPOST本体パラメータとその値を、対応する「パラメータ名」フィールドと「値」フィールド(オプション)に入力します。

注意:

- 「URL一致条件」リストから「正規表現」を選択した場合は、「必要なリクエスト・パラメータ」セクションを使用するか、付随する「URL一致条件」フィールドに埋込みURLパラメータをアルファベット順に手動で入力します。「必要なリクエスト・パラメータ」セクションを使用する場合、埋込みURLパラメータは自動的に並べ替えられます。付随する「URL一致条件」フィールドでパラメータを指定する方法は、第6.8.1.1項を参照してください。

- 「HTTPメソッド」セクションで「POST」を選択し、このセクションでPOST本体パラメータを指定しない場合は、付随する「POST本体式」フィールドでHTTP POST本体を指定します。このルールをすべてのPOSTリクエスト本体に適用する場合は、「.*」をフィールドに入力します。

6.8.1.1 正規表現のパラメータ

クライアントのブラウザからOracle Web Cacheに送信されるリクエストURLと、Oracle Web Cacheでそのリクエストの処理に使用される内部URL式は異なります。Oracle Web Cacheでページ・リクエストが処理されるときに、そのURLの埋込みURLパラメータはアルファベット順に並べ替えられます。一方、キャッシュ・ルールは、埋込みURLパラメータが並べ替えられたURLの内部表現に対してのみ一致します。キャッシュ・ルールを正しく一致させるには、「必要なリクエスト・パラメータ」セクションを使用するか、「URL一致条件」フィールドに埋込みURLパラメータを正規表現構文でアルファベット順に手動で入力します。「必要なリクエスト・パラメータ」セクションを使用する場合、埋込みURLパラメータは自動的に並べ替えられます。

たとえば、次のようなURLがあるとします。

http://my.oracle.com/servlet/page?_pageid=53&_dad=moc&_schema=MOC

「URL一致条件」フィールドに、埋込みURLパラメータの正規表現を手動で並べ替えずに^/servlet/page\?_pageid=53&_dad=moc&_schema=MOC$と入力した場合、キャッシュ・ルールは、Oracle Web Cacheで使用されるURLの内部表現に一致しません。一致させるには、「URL式」フィールドに、次のように正規表現を入力する必要があります。

^/servlet/page\?_dad=moc&_pageid=53&_schema=MOC$

6.8.2 1つのオブジェクトに複数のバージョンがある場合のルールの設定の構成

複数バージョンを持つオブジェクトのキャッシュの詳細は、第6.5.1項を参照してください。

複数バージョンのオブジェクトに対するキャッシュ・ルールを指定するには、次の手順を実行します。

1. キャッシュに影響するカテゴリCookieを持つサイトの場合は、Oracle Web Cacheが複数バージョンのオブジェクトのキャッシュおよび識別に使用する値を持つカテゴリCookieを指定します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「複数バージョンのCookie」を選択します。
「複数バージョンのCookie」ページが表示されます。

3. 「作成」をクリックします。

4. 「Cookie名」フィールドに、Cookieの名前を入力します。

5. このCookieが含まれていないバージョンのオブジェクトをキャッシュする場合は、「存在しない場合にキャッシュ」チェック・ボックスを選択します。このオプションを選択すると、Oracle Web Cacheで、このCookieが含まれていないクライアント・リクエストに対してキャッシュのオブジェクトが返されます。このCookieが含まれていないバージョンのオブジェクトをキャッシュしない場合は、オプションの選択を解除したままにします。

6. 「適用」をクリックします。

2. キャッシュ・ルールを作成します。第6.8.1項を参照してください。

3. 「キャッシュ・ルール」ページの「サイト固有のキャッシュ・ルール」セクションまたは「グローバル・キャッシュ・ルール」セクションで、作成したルールを選択し、「編集」をクリックします。
「キャッシュ・ルールの作成」ページが表示されます。

4. 「マルチ・バージョニング」タブをクリックします。

5. CookieまたはHTTPリクエスト・ヘッダーに依存する複数バージョンのオブジェクトの場合、CookieまたはHTTPリクエスト・ヘッダーを指定して、Oracle Web Cacheが複数バージョンのオブジェクトをキャッシュして、該当するバージョンのリクエストを送信できるようにします。
Cookieを使用する複数バージョンのオブジェクトの場合、ステップ1で作成したCookieを選択します。

HTTPヘッダーを使用する複数バージョンのオブジェクトの場合、「HTTPリクエスト・ヘッダーごと」セクションで、「選択可能なヘッダー」から1つ以上のヘッダーを選択し、「移動」または「すべて移動」をクリックしてそれらのヘッダーを「選択したヘッダー」リストに移動します。

6. 「OK」をクリックして変更を適用します。

7. Oracle Web Cacheを再起動します。第2.13項を参照してください。

6.8.3 埋込みURLパラメータまたはPOST本体パラメータの値の除外

Oracle Web Cacheが埋込みURLパラメータまたはPOST本体パラメータの値を無視するように構成すると、Oracle Web Cacheは、同じページをリクエストする複数のセッションを1つのキャッシュ・オブジェクトで処理できます。Oracle Web Cacheは、最初のリクエストへのレスポンスをキャッシュし、そのページへの後続のリクエストをこのキャッシュから処理します。

パラメータの値を無視するようにOracle Web Cacheを構成することで、Oracle Web Cacheが1つのキャッシュ・オブジェクトで複数のセッションを処理できるようにする方法は、第6.5.2項を参照してください。

無視するパラメータを指定するには、2つの構成オプションがあります。次が可能です。

- すべてのグローバル・キャッシュ・ルールとサイト固有のキャッシュ・ルールに自動的に適用されるグローバル・パラメータを確立します。

- サイトのキャッシュ・ルールに自動的に適用されるそのサイト固有のパラメータを指定します。

グローバル・パラメータを確立するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Site Definitions」を選択します。第2.7.2項を参照してください。
「Site Definitions」ページが表示されます。

2. 「Edit Global URL Parameters to Ignore」をクリックして、すべてのサイトを対象とするグローバル・パラメータを指定します。
「Global URL Parameters to Ignore」ダイアログ・ボックスが表示されます。

3. 「Parameters to Ignore」フィールドに、グローバル・パラメータを指定します。複数のパラメータを指定する場合は、各パラメータをカンマまたはスペースで区切ります。

4. 「Submit」をクリックします。

5. 「Apply Changes」をクリックします。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

7. サイト固有のキャッシュ・ルールを作成します。第6.8.1項を参照してください。

サイト固有のパラメータを確立するには、次の手順に従います。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Origin Servers, Sites, and Load Balancing」→「Site Definitions」を選択します。第2.7.2項を参照してください。
「Site Definitions」ページが表示されます。

2. サイトを選択し、「Show/Edit Selected」をクリックします。
「Show/Edit Site Definition」ダイアログ・ボックスが表示されます。

3. 「URL Parameters to Ignore」フィールドに、サイト固有のパラメータを指定します。複数のパラメータを指定する場合は、各パラメータをカンマまたはスペースで区切ります。

4. 「Submit」をクリックします。

5. 「Apply Changes」をクリックします。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

7. サイト固有のキャッシュ・ルールを作成します。第6.8.1項を参照してください。

6.8.4 HTTPリクエスト・ヘッダーが含まれる複数バージョンのオブジェクトの類似ブラウザ・タイプの認識

Oracle Web Cacheでは、デフォルトでHTTPリクエスト・ヘッダーの値が解析されません。Fusion Middleware Controlで、User-Agentリクエスト・ヘッダー・フィールドに対して「他のヘッダーによる同じセレクタを持つ複数のオブジェクト」が選択されている場合、同じURLのUser-Agentリクエスト・ヘッダーの値が異なっていると、Oracle Web Cacheでは両方のページが別々にキャッシュされます。たとえば、異なるバージョンのInternet Explorerに対して、あるリクエストではUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows)というHTTPリクエスト・ヘッダーが送信され、別のリクエストではUser-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows; DigExt)というHTTPリクエスト・ヘッダーが送信された場合、Oracle Web Cacheでは2つの別々のページがキャッシュされます。

このデフォルトの動作をオーバーライドするには、特定のクライアントのUser-Agentパターン文字列を使用してOracle Web Cacheを構成します。複数のバージョンを持つオブジェクトの中で影響を受けるドキュメントに対して、Oracle Web Cacheはx-Oracle-Mapped-Userリクエスト・ヘッダー・フィールドを追加し、User-Agentの値全体ではなくこの文字列の値を使用します。

x-Oracle-Mapped-User: MAPPEDUSERAGENT_String

ブラウザ・タイプごとに同じページをキャッシュして表示するようにOracle Web Cacheを構成するには、次の手順を実行します。

1. 第6.8.2項の説明に従って、User-Agentリクエスト・ヘッダーをサポートするページのキャッシュ・ルールを作成して、User-Agentヘッダーを確実に選択します。

2. 次の場所にあるwebcache.xmlをテキスト・エディタで開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

3. GLOBALCACHINGRULES要素を探します。

4. ブラウザ・タイプごとに、GLOBALCACHINGRULES要素の次の行に、次のサブ要素を追加します。

<USERAGENTREMAPRULE MATCHSTRING="browser" MAPPEDUSERAGENT="x-Oracle-Mapped-User-Agent_value" MAPTYPE="USERAGENT"/>

複数のエントリを入力する場合は、Oracle Web Cacheで一致させる方法に従ってエントリを並べます。これらのルールの順序は、キャッシュ・ルールの優先順位と同じように機能します。

サブ要素の値の入力方法を、表6-5で説明します。

表6-5 GLOBALCACHINGRULESのサブ要素

サブ要素

説明

MATCHSTRING

受信リクエスト・ヘッダーとの一致に使用するパターンを入力します。

注意: ワイルド・カード*を使用して、複数の異なるブラウザ・タイプにパターンを一致させることができます。たとえば、Mozilla*と入力すると、Mozillaのすべてのバリエーションが一致します。

MAPPEDUSERAGENT

Oracle Web Cacheによってx-Oracle-Mapped-User-Agentリクエスト・ヘッダーに追加されるUser-Agentパターンの一意の値を入力します。

MAPTYPE

User-Agentリクエスト・ヘッダーでパターンに一致させるUSERAGENTを入力します。

次のwebcache.xmlファイルの一部は、User-Agentの再マッピングを示します。

<USERAGENTREMAPRULE MATCHSTRING="MSIE *" MAPPEDUSERAGENT="MSIE" MAPTYPE="USERAGENT"/>
<USERAGENTREMAPRULE MATCHSTRING="Mozilla*" MAPPEDUSERAGENT="MOZ" MAPTYPE="USERAGENT"/>

受信リクエストに一致するルールが存在しない場合、Oracle Web Cacheはデフォルトのマッピングをリクエストに追加します。x-Oracle-Mapped-User-Agentヘッダーのデフォルト値はDEFAULT_USER_AGENTです。

これらのマッピング・ルールは、すべての受信リクエストに対して実行されます。複数のマッピング・ルールを作成すると、パフォーマンスが低下する可能性があります。

5. ステップ1で作成したキャッシュ・ルールについて、CACHEABILITYRULEの<MULTIVERSIONHEADERSRULE>サブ要素を探します。

<MULTIVERSIONHEADERSRULE>
<HTTPHEADER NAME="User-Agent"/>
</MULTIVERSIONHEADERSRULE>

6. User-Agentの値全体ではなくMAPPEDUSERAGENT文字列の値に一致させるには、ルールのHTTPHEADER属性のUser-Agentヘッダーをx-Oracle-Mapped-User-Agentに変更します。

<MULTIVERSIONHEADERSRULE>
<HTTPHEADER NAME="x-Oracle-Mapped-User-Agent"/>
</MULTIVERSIONHEADERSRULE>

7. webcache.xmlを保存します。

8. opmnctlを使用してOracle Web Cacheを再起動します。第2.13.1項を参照してください。

6.8.5 ルールのエラー・レスポンスの構成

HTTPエラー・レスポンスをキャッシュしてオリジン・サーバーのリソースを節約する方法については、第6.5.3項を参照してください。

エラー・レスポンスのキャッシュ・ルールを作成するには、次の手順を実行します。

1. キャッシュ・ルールを作成します。第6.8.1項を参照してください。

2. 「キャッシュ・ルール」ページの「サイト固有のキャッシュ・ルール」セクションまたは「グローバル・キャッシュ・ルール」セクションで、作成したルールを選択し、「編集」をクリックします。
「キャッシュ・ルールの作成」ページが表示されます。

3. 「エラー・レスポンス」タブをクリックします。

4. このルールに対して、Oracle Web Cacheでキャッシュおよび表示するHTTPエラー・コードを選択します。
オリジン・サーバーがHTTPエラー自体を生成するようにします。

5. 「OK」をクリックして変更を適用します。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

6.8.6 セッション・キャッシュ・ルールの構成

Oracle Web Cacheで、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータが存在するリクエストまたは存在しないリクエストが処理される方法については、第6.5.4項を参照してください。

Oracle Web Cacheによるセッション関連ページの送信方法を指定するには、次の手順を実行します。

1. 「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション定義」ページが表示されます。

2. 「セッション定義」表でセッション定義を作成します。第2.12項を参照してください。

3. セッション・ポリシーの設定を指定します。

1. 「セッション・ポリシー構成」セクションで、「作成」をクリックします。
表に新しい行が表示されます。

2. 「セッション名」リストから、ステップ2で作成したセッションを選択します。

3. 「キャッシュ」列で、Oracle Web CacheがCookieまたはパラメータを使用しないオブジェクトのバージョンをキャッシュする場合は「セッションを使用しない」チェック・ボックスを選択します。Oracle Web Cacheがセッション情報を持たないリクエストのキャッシュからオブジェクトを送信しない場合は、「いいえ」を選択します。

4. 「キャッシュ」列で、Oracle Web CacheがCookieまたはパラメータを使用するオブジェクトのバージョンをキャッシュする場合は「セッションを使用」チェック・ボックスを選択します。

5. 「デフォルト値の置換」列で、Oracle Web Cacheがオブジェクトの1つのバージョンのみキャッシュする場合は、このチェック・ボックスを選択します。Cookieまたはパラメータを持たないリクエストでは、デフォルト値が使用されます。Oracle Web Cacheがオブジェクトの2つの異なるバージョンをキャッシュする場合は、このチェック・ボックスを選択解除します。Oracle Web Cacheによって、Cookieまたはパラメータをサポートしているリクエストに対して1つのバージョンが返され、Cookieまたはパラメータをサポートしないリクエストに対してもう1つのバージョンが返されます。

4. キャッシュ・ルールを作成します。第6.8.1項を参照してください。

5. 次の手順を実行して、キャッシュ・ルールにセッション・ポリシーを関連付けます。

1. 「キャッシュ・ルールの作成」ページの「サイト固有のキャッシュ・ルール」または「グローバル・キャッシュ・ルール」セクションで、作成したルールを選択し、「編集」をクリックします。
「キャッシュ・ルールの編集」ページが表示されます。

2. 「セッション」タブをクリックします。

3. 「セッション定義」リストから、ステップ2で作成してステップ3でポリシーを定義したセッションを選択します。

4. 「OK」をクリックして変更を適用します。

6. Oracle Web Cacheを再起動します。第2.13項を参照してください。

6.8.7 セッション・エンコードされたURLに対するサポートの構成

HTMLハイパーリンク・タグのセッションを、セッションCookie、埋込みURLパラメータまたはPOST本体パラメータから取得したセッション値で置換するようにOracle Web Cacheを構成できます。セッション・エンコードされたURL内のセッション・パラメータ値が異なっていても、1つのオブジェクトが複数のセッション用にキャッシュされるようにOracle Web Cacheを構成する方法は、第6.5.5項を参照してください。

セッション・エンコードされたURLのセッションの値を置換するには、次のように設定します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション定義」ページが表示されます。

3. 「セッション定義」表でセッション定義を作成します。第2.12項を参照してください。
「デフォルト値」フィールドにデータを入力するときには、埋込みURLパラメータの値に使用されるデフォルトの文字列を入力します。

Oracle Web Cacheでは、埋込みURLパラメータの値が含まれないリクエストに対して、「デフォルト値」フィールドに入力した値が使用されます。このようなリクエストの場合、Oracle Web Cacheによって値がデフォルトの文字列に置換されます。文字列のデフォルトはdefaultです。たとえば、次の<A HREF=...>には、値を含まないsession_IDパラメータが含まれています。

<A HREF="https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=">Master Index</A>

文字列をdefaultに設定すると、Oracle Web Cacheによって値がdefaultに置換されます。

<A HREF="https://oraclestore.oracle.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=11886&session_ID=default">Master Index</A>

4. キャッシュ・ルールを作成します。第6.8.1項を参照してください。

5. 「キャッシュ・ルール」ページの「サイト固有のキャッシュ・ルール」セクションまたは「グローバル・キャッシュ・ルール」セクションで、作成したルールを選択し、「編集」をクリックします。
「キャッシュ・ルールの作成」ページが表示されます。

6. 「セッション」タブをクリックします。

7. 「セッション・エンコードされたURLに対する処理」をクリックします。

8. 「OK」をクリックして変更を適用します。

9. Oracle Web Cacheを再起動します。第2.13項を参照してください。

6.8.8 セッションの確立を含むポピュラーなページに対するルールの構成

一部のWebサイトでは、ユーザーがページ間を移動する間、セッションを使用する必要があります。セッション要件を維持するには、それらのページ用にセッション・キャッシュ・ルールを作成します。これにより、セッションを持たないリクエストは必ずオリジン・サーバーに転送されます。

通常セッションの確立を必要とする一般的なサイトのエントリ・ページ(/など)は、セッションを確立するため、セッションを持っていないすべての新規ユーザーについてキャッシュ不可になります。セッションの確立を維持したままこれらのページをキャッシュするには、ご使用のアプリケーションに次のような変更を加えます。

1. 実際のエントリ・ページにリダイレクトする、エントリURL(/など)用の空白のページを作成します。

2. セッションCookieを持たない状態で空白のページがリクエストされた場合に、オリジン・サーバーによってセッションを作成するよう構成します。

3. 第6.8.6項の説明に従って、実際のエントリ・ページおよび空白のページ用のセッション・キャッシュ・ルールを作成し、「キャッシュする」および「キャッシュしない」の両方のオプションをクリックします。

この構成により、エントリURLに対する最初のユーザー・リクエストはすべて、まず、最小限のリソースのみで生成される空白のページに進みます。クライアントは、Webアプリケーション・サーバーからレスポンスおよびセッションの確立を受信します。その後の、エントリ・ページに対するリダイレクトされたリクエストにはセッションが関連付けられ、エントリ・ページをキャッシュで処理することが可能になります。

セッションを必要とするページのセッションCookieを、Javascriptを使用して設定する方法でも解決できます。

1. セッションCookieを設定するJavascriptがない場合は、作成します。

2. セッションを必要とする各ページにJavascriptを追加します。

3. 第6.8.1項および第6.8.6項の説明に従って、Javascriptおよびセッション・ページのキャッシュ・ルールを作成します。

注意:
Javascriptによるソリューションを使用すると、セッションを必要とするページについて、セッション・キャッシュ・ルールを作成する必要はありません。

6.9 キャッシュ・ルールのサマリー設定の監視

Fusion Middleware Controlでは、構成されているキャッシュ・ルールの有効性を評価するための統計を表示できます。

キャッシュ・ルールの統計を表示するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「管理」→「キャッシュ・ルール」を選択します。
「キャッシュ・ルール」ページが表示されます。

3. 右端までスクロールして、キャッシュ・ルールの統計を表示します。

- マルチ・バージョニング: このキャッシュ・ルールに、複数バージョンを持つリクエストの設定が含まれているかどうかを示します。

- セッション: このキャッシュ・ルールに、ユーザー・セッション情報を含むCookie、埋込みURLパラメータまたはPOST本体パラメータを使用するリクエストの設定が含まれているかどうかを示します。

- エラー・レスポンス: このキャッシュ・ルールに、HTTPエラー・レスポンスを使用するリクエストの設定が含まれているかどうかを示します。

- 一致: キャッシュ・ルールと一致したリクエストの数が表示されます。

Oracle Web Cacheによってキャッシュされたオブジェクトの表示方法は、第8.2項を参照してください。

6.10 Surrogate-Controlレスポンス・ヘッダーをキャッシュ・ルールの代替として使用

アプリケーション開発者は、Fusion Middleware Controlで設定するキャッシュ・ルールに加えて、またはその代替として、多くのキャッシュ属性をHTTPレスポンス・メッセージのヘッダーに格納することもできます。この機能により、Webアプリケーション・サーバーがFusion Middleware Controlインタフェースでの設定をオーバーライドしたり、サード・パーティ製キャッシュでOracle Web Cacheのキャッシュ属性を使用したりすることが可能になります。次の属性を除き、第6.8項に記載されているすべての属性がサポートされています。

- セッション・キャッシュ・ルール

- HTTPエラー・レスポンスのキャッシュ・ルール

この機能を使用するには、次の項の説明に従って、HTTPレスポンスにSurrogate-Controlレスポンス・ヘッダー・フィールドを設定します。

Oracle Web CacheがSurrogate-Controlレスポンス・ヘッダーのキャッシュ属性を使用する方法、およびOracle Web Cache Managerがキャッシュへのデータ格納を決定する方法は、第6.1項を参照してください。

6.10.1 Surrogate-Controlレスポンス・ヘッダー・フィールド

Surrogate-Controlレスポンス・ヘッダー・フィールドによって、アプリケーション開発者は、オブジェクトのキャッシュ属性を指定できます。このレスポンス・ヘッダー・フィールドを使用すると、管理インタフェースであるFusion Middleware ControlまたはOracle Web Cache Managerによって構成されたキャッシュ・ルールをWebアプリケーション・サーバー側でオーバーライドできます。

Surrogate-Controlレスポンス・ヘッダー・フィールドは次の構文をサポートします。

Surrogate-Control:[content=content_type, content_type,..]
[no-store][max-age=expiration_time[+removal_time]]
[vary=headers(header header...)][cookie(cookie_name cookie_name...)]
[compress=yes|no]

表6-6に、サポートされている制御ディレクティブを示します。

表6-6 Surrogate-Controlの制御ディレクティブ

制御ディレクティブ

説明

content

必須の処理の種類を指定します。

- "ORAESI/9.0.4": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用するOracle独自の拡張ESIタグを処理します。"ORAESI/9.0.4"では、10g(9.0.4)以降のOracle Web Cacheで提供されるすべてのESIタグがサポートされます。

- "ORAESI/9.0.2": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用するOracle独自の拡張ESIタグを処理します。"ORAESI/9.0.2"では、リリース2(9.0.2および9.0.3)のOracle Web Cacheで提供されるすべてのESIタグがサポートされます。

- "ESI/1.0": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用する標準ESIタグを処理します。

- "ESI-Inline/1.0": <esi:inline>タグを処理します。

- "ESI-INV/1.0": <esi:invalidate>タグを処理します。

- "webcache/1.0": <!-- WEBCACHETAG-->タグおよび<!-- WEBCACHEEND-->タグを使用してパーソナライズ属性を処理します。

"ORAESI/9.0.2"、"ESI/1.0"および"ESI-Inline/1.0"は、"ORAESI/9.0.4"のサブセットです。このリリースでは、ESIアセンブリに"ORAESI/9.0.4"のみを、インライン無効化に"ESI-INV/1.0"のみを、パーソナライズ属性に"webcache/1.0"のみを指定する必要があります。

各処理バージョンに対してサポートされるESIタグの詳細は、第11章「ESI言語タグによる動的コンテンツのキャッシュ」を参照してください。

no-store

Oracle Web Cacheでオブジェクトをキャッシュしない場合に指定します。

vary

複数バージョンのオブジェクトをキャッシュして識別するようにOracle Web Cacheに指示するために、HTTPリクエスト・ヘッダーまたはCookieを指定します。次の書式を使用します。

vary=[headers(header[/f] *);] [cookies(cookie_name[/f] *)]

/fは、HTTPリクエスト・ヘッダーまたはCookieが存在した場合にのみオブジェクトのバージョンをキャッシュするようにOracle Web Cacheに指示する場合に指定します。HTTPリクエスト・ヘッダーまたはCookieが存在するかどうかに関係なくオブジェクトのバージョンをキャッシュするようにOracle Web Cacheに指示するには、/fを指定しません。

使用方法:

- 少なくとも1つのHTTPヘッダーまたはCookieを指定します。

- HTTPリクエスト・ヘッダーとCookieの両方を指定する場合は、Cookieの前にHTTPリクエスト・ヘッダーを指定します。

- カッコとセミコロンの間にはスペースを入れないか、1つ以上スペースを空けます。

- 複数のHTTPリクエスト・ヘッダーまたはCookieを指定するときは、HTTPリクエスト・ヘッダーとCookie名の間に1つ以上スペースを空けます。

compress

Oracle Web Cacheで、圧縮されたキャッシュ可能およびキャッシュ不可のオブジェクトをすべてのブラウザ・タイプに送信する場合はyesを指定します。Oracle Web Cacheで、圧縮されたキャッシュ可能およびキャッシュ不可のオブジェクトをブラウザに送信しない場合はnoを指定します。

この制御ディレクティブではブラウザ・タイプを指定することはできません。yesを指定してブラウザ・タイプを制限する必要がある場合は、第6.8.1項の説明に従って、圧縮キャッシュ・ルールを指定します。

Oracle Web Cacheが自動的に圧縮するものと圧縮しないものの詳細は、第1.2.5項を参照してください。

max-age

Oracle Web Cacheでオブジェクトをキャッシュする場合に指定します。

オブジェクトがキャッシュに入れられてから期限切れになるまでの秒数を指定します。オプションで、期限切れ後のオブジェクトを削除するまでの秒数を指定します。次の書式を使用します。

max-age=expiration_time[+removal_time]

使用方法:

- デフォルトの削除までの時間は0秒。

- max-age=infinityは、オブジェクトを期限切れにしないように指定します。

使用方法

- 制御ディレクティブには大文字と小文字の区別があります。

- content="ORAESI/9.0.4"、content="ESI-Inline/1.0"、content="ESI-INV/1.0"、content="ESI/1.0"を、content="webcache/1.0"と同時に使用することはできません。

Edgeアーキテクチャ仕様についてはhttp://www.esi.org/spec.htmlを参照してください。これには、Surrogate-Controlレスポンス・ヘッダーに関する仕様情報が含まれます。

使用例

次の例では、Surrogate-Controlレスポンス・ヘッダー・フィールドにより、オブジェクトがキャッシュに入ってから30秒後に期限切れにし、期限切れ後60秒で削除するよう指定します。また、ESIタグが含まれているオブジェクトを処理するよう指定しています。

Surrogate-Control: max-age=30+60, content="ORAESI/9.0.4"

次の例では、Surrogate-Controlレスポンス・ヘッダー・フィールドにより、オブジェクトをキャッシュしないよう指定します。

Surrogate-Control: no-store

次の例では、Surrogate-Controlレスポンス・ヘッダー・フィールドは、content制御ディレクティブでESI処理を指定します。vary制御ディレクティブは、リクエストにHTTP Acceptリクエスト・ヘッダーが含まれているかどうかに関係なく、HTTP Acceptリクエスト・ヘッダー値に基づいて、複数バージョンのオブジェクトのバージョンをキャッシュすることを指定します。

Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept)

次の同様の例では、Surrogate-Controlレスポンス・ヘッダー・フィールドは、content制御ディレクティブでESI処理を指定します。vary制御ディレクティブは、リクエストにAcceptおよびMyCustomHeaderヘッダーや、newsおよびsportsのCookieが含まれている場合にのみ、複数バージョンのオブジェクトのバージョンをキャッシュすることを指定します。

Surrogate-Control: content="ORAESI/9.0.4", vary=headers(Accept/f MyCustomHeader/f);cookies(news/f sports/f)

7 コンテンツの無効化

この章では、無効化リクエストをOracle Web Cacheに送信する方法について説明します。

この章の項目は次のとおりです。

- 第7.1項「無効化の概要」

- 第7.2項「バンド外無効化について」

- 第7.3項「ESIによるインライン無効化について」

- 第7.4項「レスポンス・ヘッダーによる無効化について」

- 第7.5項「バンド外メカニズムとESIインライン・メカニズムの無効化リクエストの形式」

- 第7.6項「検索キーによる無効化について」

- 第7.7項「バンド外無効化の開始」

- 第7.8項「レスポンス・ヘッダーによる無効化の有効化」

- 第7.9項「検索キーによる無効化の有効化」

- 第7.10項「セキュリティに関する考慮事項」

7.1 無効化の概要

第6.7項で説明されているように、有効期限ポリシーを作成し、それをキャッシュ・ルールに関連付けることによって、オリジン・サーバーのコンテンツは更新されます。たとえ有効期限ポリシーがあっても、コンテンツが失効するタイミングを正確に予測するのは困難な場合があります。Oracle Web Cacheでは代替の方法として、このようなコンテンツが失効したと管理者またはアプリケーションが判断したときには、コンテンツを明示的に無効化できるメカニズムを提供しています。

無効化によって、Oracle Web Cacheはオブジェクトを無効にします。オブジェクトが無効になった後にクライアントがそれらをリクエストすると、オブジェクトはキャッシュから削除され、オリジン・サーバーから新しいコンテンツが取得されてキャッシュが更新されます。無効になったオブジェクトはすぐに削除して新しいものに更新するか、あるいはオリジン・サーバーの現在の負荷に基づいて、削除と更新を行うことが可能です。

Oracle Web Cacheは、次の形式の無効化をサポートしています。

- 特殊な無効化ポートを介した無効化。無効化リクエストがOracle Web Cacheのリスニング・ポートを経由しないため、このタイプの無効化はバンド外無効化とも呼ばれます。第7.2項を参照してください。

- 無効化ディレクティブが通常のリクエストへのレスポンス・ボディを介してESIタグとして受信される、ESIによるインライン無効化。第7.3項を参照してください。

- 無効化ディレクティブが通常のリクエストへのレスポンス内の特殊な(および専用の)レスポンス・ヘッダーとして受信される、レスポンス・ヘッダーによる無効化。第7.4項を参照してください。

7.2 バンド外無効化について

キャッシュ内のオブジェクトを無効化するには、無効化リスニング・ポートを介してinvalidatorアカウントからHTTP POSTリクエストを送信します。invalidatorアカウントは、無効化リクエストの送信を許可されています。図7-1に示すように、無効化リクエストは次の方法で送信します。

- 手動(Fusion Middleware Controlまたはtelnetを使用)

- 自動(データベース・トリガー、スクリプトまたはアプリケーション・ロジックを使用)

図7-1 無効化

「図7-1 無効化」の説明

次の項では、使用可能な方法を個別に説明します。

- 第7.7.1項「Telnetを使用した無効化リクエストの送信」

- 第7.7.2項「Oracle Web Cache Managerを使用した無効化リクエストの送信」

- 第7.7.3項「Application Program Interface(API)を使用した自動無効化リクエスト」

- 第7.7.4項「データベース・トリガーを使用した自動無効化リクエスト」

- 第7.7.5項「スクリプトを使用した自動無効化」

7.3 ESIによるインライン無効化

Edge Side Includes(ESI)の一部として実装されるインライン無効化は、オリジン・サーバーに対して、Oracle Web Cacheに送信されたHTTPレスポンスに無効化メッセージを組み合せる便利な方法を提供します。具体的には、オリジン・サーバーがESIタグを使用してレスポンス・ボディのHTML内にXML無効化ドキュメントを埋め込みます。

たとえば、顧客がE-Commerceサイトでベジタリアン向けの料理本を購入した場合、確認レスポンスにその書籍、著者および野菜に関連するすべてのカタログ・ページを無効にする指示を含めることができます。無効化メッセージをインラインで送信する機能により、バンド外無効化の送信に関連する接続オーバーヘッドが軽減されるため、ESI開発者には便利なツールです。

ESIによる無効化の使用方法の詳細は、第11.3項を参照してください。

7.4 レスポンス・ヘッダーによる無効化について

レスポンス・ヘッダーによる無効化は、オリジン・サーバーがレスポンス・ボディにHTML以外の要素が含まれるトランザクション・レスポンスを返すことを可能にするOracle Web Cacheの機能です。この状況ではESIインライン無効化は使用できません。Oracle Web Cacheでは、レスポンス・ボディにHTMLが含まれている場合にのみESI無効化タグを使用できます。レスポンス・ヘッダーによる無効化では、オリジン・サーバーは専用の無効化レスポンス・ヘッダーで無効化ディレクティブを送信できます。

レスポンス・ヘッダーによる無効化は、返されるレスポンス・ボディのコンテンツに関して柔軟性が高いだけではありません。無効化ヘッダーの作成はきわめて負荷の低い作業であるため、Webアプリケーションでのコーディング作業が軽減されます。

レスポンス・ヘッダーによる無効化はインライン無効化と同様に機能します。つまりオリジン・サーバーは、Oracle Web Cacheに送信されるレスポンスに無効化ディレクティブを組み合せます。ただしレスポンス・ヘッダーによる無効化では、レスポンス・ボディにHTML以外の要素が含まれる場合にも無効化が可能な点が異なります。

オリジン・サーバーは、レスポンスに特別な無効化ヘッダーを追加します。Oracle Web Cacheは無効化ヘッダーを抽出し、対応するコンテンツを無効化して、無効化ヘッダーを含めずにレスポンスをクライアントに転送します。

オリジン・サーバーは、あらゆるレスポンスに無効化レスポンス・ヘッダーを組み合せることができます。たとえば、オリジン・サーバーが無効化ディレクティブの送信を遅らせて、後から最初に無効化が発生したリクエストとは無関係のリクエストへのレスポンスでその無効化ディレクティブを送信することができます。

Oracle Web Cacheは、Webクライアントにレスポンスを返すときに無効化レスポンス・ヘッダーを取り除きます。クラスタ伝播により無効化がクラスタ内の他のメンバーに転送されるため、Oracle Web Cacheは、キャッシュ・クラスタ内の別のメンバーにレスポンスを返す場合にも無効化レスポンス・ヘッダーを取り除きます。

レスポンス・ヘッダーによる無効化を有効にする方法の詳細は、第7.8項を参照してください。

7.5 バンド外メカニズムとESIインライン・メカニズムの無効化リクエストの形式

バンド外メカニズムでは、バンド外のHTTP POST無効化リクエストをExtensible Markup Language(XML)構文で送信します。ESIインライン・メカニズムも、<esi:invalidate>タグ内で同じ構文を使用します。XMLリクエストのボディの内容により、無効にするURLがキャッシュに指定されます。

次の項では、無効化リクエストの構文を説明します。

- 第7.5.1項「無効化リクエストの構文」

- 第7.5.2項「無効化レスポンスの構文」

- 第7.5.3項「無効化プレビュー・リクエストの構文」

- 第7.5.4項「無効化プレビュー・レスポンスの構文」

- 第7.5.5項「無効化の例」

7.5.1 無効化リクエストの構文

次の構文を使用して、絶対パスおよびファイル名が含まれている絶対URL内のオブジェクトを無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<BASICSELECTOR URI="URL"/>
<ACTION REMOVALTTL="TTL"/>
<INFO VALUE="value"/>
</OBJECT>
</INVALIDATION>

次の構文を使用して、より高度な無効化セレクタに基づいてオブジェクトを無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="prefix"
URIEXP="URL_expression"
HOST="host_name:port"
METHOD="HTTP_request_method"
BODYEXP="HTTP_body"/>
<COOKIE NAME="cookie_name" VALUE="value"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
<OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
TYPE="SUBSTRING|REGEX"
VALUE="value"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="TTL"/>
<INFO VALUE="value"/>
</OBJECT>
</INVALIDATION>

有効な無効化リクエストのボディの先頭は、次のとおりです。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">

最初の行ではXMLのリリース1.0が指定されます。2行目では、リクエストがXML文書タイプとしてWCSinvalidation.dtdファイルを使用する無効化リクエストであることを示します。WCSinvalidation.dtdは、無効化リクエストおよびレスポンスの文法を定義するDocument Type Definition(DTD)です。

次のことに注意してください。

- 「<?xml」の前に空白を入れないでください。

- アプリケーションが無効化リクエストをサード・パーティのXMLパーサーと共有している場合、"internal:///WCSinvalidation.dtd"のかわりに次のパスを使用します。

"http://www.oracle.com/webcache/90400/WCSinvalidation.dtd"

ルート要素INVALIDATIONには、表7-1に説明する属性と要素が含まれています。

表7-1 INVALIDATIONの要素および属性

無効化処理用の要素/属性

説明

VERSION属性

INVALIDATION要素の必須属性

XML文書タイプとして使用するWCSinvalidation.dtdファイルのバージョンを示します。

リリース9.0.x以降では、既存のアプリケーションを変更する必要がない場合を除いて、常にVERSION="WCS-1.1"を使用してください。ただし、VERSION="WCS-1.0"を使用した場合、新しい無効化機能は利用できません。

SYSTEM要素

INVALIDATION要素のオプション要素。SYSTEM要素はSYSTEMINFO要素が必要です。

SYSTEMINFO要素

SYSTEM要素の必須要素。

可能なNAME/VALUEペアを次に示します。

- NAME="WCS_PROPAGATE" VALUE="TRUE|FALSE"
このペアは、無効化リクエストをキャッシュ・クラスタのメンバーに伝播するかどうかを指定します。WCS_PROPAGATEがTRUEの場合は、クラスタ構成内の無効化の伝播設定より優先されます。WCS_PROPAGATEがFALSEの場合は、クラスタ構成内の無効化の伝播設定が使用されます。

デフォルトはFALSEです。

- NAME="WCS_DISCONNECTED_MODE_OK" VALUE="TRUE|FALSE"
このペアは、無効化が実行される時間を指定します。WCS_DISCONNECTED_MODE_OKがTRUEの場合、無効化は即時に実行されません。無効化レスポンスは、無効化リクエストの受信と同時に送信されます。無効化の結果を待機しない場合は、この要素をTRUEに設定します。WCS_DISCONNECTED_MODE_OKがFALSEの場合、無効化は即時に完了し、無効化の結果が送信されます。

デフォルトはFALSEです。

OBJECT要素

無効化リクエストの必須要素。リクエスト内で複数のOBJECT要素を指定できます。

BASICSELECTOR要素

URI属性: BASICSELECTOR要素の必須属性。無効にするオブジェクトのURLを指定します。次の形式を使用します。

- http://host_name:port/path/filename

- https://host_name:port/path/filename

administratorアカウントがリクエストを送信する場合は、host_name:portは必須ではありません。

ADVANCEDSELECTOR要素

URIPREFIX属性: ADVANCEDSELECTOR要素の必須属性。無効にするオブジェクトのパス接頭辞を指定します。パス接頭辞は、http|https://host_name:port/path/filenameまたは"/"で始めて、"/"で終わる必要があります。host_name:portは、HOST属性が指定されず、invalidatorアカウントがリクエストを送信している場合に必要です。

接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。このような文字として、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、キャレット(^)、ドル記号($)および円記号(¥)があります。

URIEXP属性: ADVANCEDSELECTOR要素のオプション属性。URIPREFIX内に存在する無効にするオブジェクトのURLを指定します。値が入力されなかった場合は、URIPREFIX内のすべてのオブジェクトが無効になります。

正規表現の使用が可能です。これらの文字を文字どおりに使用する場合は、その前にエスケープ文字としてバックスラッシュ(\)を置きます。

正規表現の構文は、http://www.cs.utah.edu/dept/old/texinfo/regex/regex_toc.htmlを参照してください。

注意:

- クライアントのブラウザからOracle Web Cacheに送信されるリクエストURLと、Oracle Web Cacheで内部的にそのリクエストの処理に使用されるURLは異なります。Oracle Web Cacheでページ・リクエストが処理されるときに、そのURLの埋込みURLパラメータはアルファベット順に並べ替えられます。一方、無効化リクエストは、埋込みURLパラメータが並べ替えられたURLの内部表現に対してのみ一致判定します。無効化リクエストに正しく一致させるには、埋込みURLパラメータをアルファベット順に並べ替えて入力してください。

- 無効化リクエストが送信されると、Oracle Web CacheはURIEXPに対して正規表現による照合を実行します。この処理には時間がかかる場合があります。かわりに、OTHER要素を使用して、正規表現一致ではなくサブストリング一致を指定することができます。

HOST属性: URIPREFIX値にhost_name:portが含まれず、invalidatorアカウントがリクエストを送信する場合、この属性は必須です。サイトのホスト名とポート番号(host_name:port)を指定します。HTTPのデフォルト・ポートはポート80です。

METHOD属性: ADVANCEDSELECTOR要素のオプション属性。無効にするオブジェクトのHTTPリクエスト・メソッド(GETまたはPOST)を指定します。デフォルト値はGETです。

BODYEXP属性: ADVANCEDSELECTOR要素のオプション属性。METHODがPOSTの場合は、無効にするオブジェクトのHTTP POST本体を指定します。

注意: 無効化リクエストが送信されると、Oracle Web CacheはBODYEXPに対して正規表現による照合を実行します。この処理には時間がかかる場合があります。かわりに、OTHER要素を使用して、正規表現一致ではなくサブストリング一致を指定することができます。

COOKIE要素

無効化リクエストのオプションの要素。次の属性を使用します。

- NAME属性: COOKIE要素属性の必須属性。Cookieに基づいて複数バージョンのオブジェクトを無効にするためのCookie名を指定します。

- VALUE属性: COOKIE要素のオプション属性。Cookieの値を指定します。値が存在しない場合は、指定されたCookieを持ち、値を持たないオブジェクトのみが無効になります。

複数のバージョンのオブジェクトとセッション・キャッシュ・ポリシーの両方に対して間違って指定されたCookieを指定する場合、無効化はこのCookieの発生に基づきます。過度の無効化を回避するには、複数のバージョンのオブジェクトとセッション・キャッシュ・ポリシーに対して異なるCookieを構成します。

詳細は、次を参照してください。

- 複数バージョンのオブジェクトに対するキャッシュ・ルールの作成方法は、第6.8.2項を参照してください。

- セッション・キャッシュ・ポリシーの指定方法は、第6.8.6項を参照してください。

HEADER要素

無効化リクエストのオプションの要素。次の属性を使用します。

- NAME属性: HEADER要素の必須属性。HTTPリクエスト・ヘッダーを指定すると、リクエスト・ヘッダーに基づいて複数バージョンのオブジェクトが無効になります。

- VALUE属性: HEADER要素のオプション属性。ヘッダーの値を指定します。

複数バージョンのオブジェクトに対するキャッシュ・ルールの作成方法は、第6.8.2項を参照してください。

OTHER要素

無効化リクエストのオプションの要素。次の属性を使用します。

- NAME属性: OTHER要素の必須属性。NAMEは次の値をサポートしています。
- URIPREFIX内に存在するURLの一致を指定するURI

- HTTP POST本体の一致を指定するBODY

- 埋込みURLパラメータの一致を指定するQUERYSTRING_PARAMETER

- Surrogate-Keyレスポンス・ヘッダーでの検索キーの一致を指定するSEARCHKEY

- TYPE属性: URI、BODYおよびQUERYSTRING_PARAMETERの必須属性。この属性は、SEARCHKEYでは認識されません。TYPEは、次の値をサポートしています。
- QUERYSTRING_PARAMETERの文字列完全一致、およびURIとBODYの文字列部分一致を指定するSUBSTRING

- 正規表現の一致を指定するREGEX

- VALUE属性: URI、BODY、QUERYSTRING_PARAMETERおよびSEARCHKEYの必須属性。URI、BODY、QUERYSTRING_PARAMETERまたはSEARCHKEYの値を指定します。TYPEとしてREGEXを指定した場合は、Oracle Web Cacheが文字どおりに解釈するように、正規表現の前にエスケープ文字としてバックスラッシュ(\)を置きます。

詳細は、次を参照してください。

- 拡張無効化の最適化の詳細は、第7.5.5項を参照してください。

- 検索キーの構成方法は、第7.9項を参照してください。

ACTION要素

無効化リクエストの必須要素。

REMOVALTTL属性

ACTION要素のオプション属性。オブジェクトが無効化されるまでキャッシュ内に存続する最長期間を指定します。デフォルトは0秒です。

INFO要素

無効化リクエストのオプションの要素。

VALUE属性

INFO要素の必須属性。無効化の結果に含まれるコメントを指定します。無効化リクエストが完了すると、コメントを含むメッセージおよび無効化の結果がイベント・ログに書き込まれます。

[15/Oct/2008:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 21085932167,0] Invalidation with INFO 'INFO_comment' has returned with status 'status'; number of objects invalidated: 'number'.

注意:
次のXML特殊文字は、フィールド内でエスケープする必要があります。アンパサンド(&)→「&amp;」、右山カッコ(>)→「&gt」、左山カッコ(<)→「&lt」、二重引用符(")→「&quot」、一重引用符(')→「&apos;」のように入力します。

注意:
Oracle Web Cacheでは、次のリリース1.0形式で送信された無効化リクエストもサポートしています。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///invalidation.dtd">
<INVALIDATION>
<URL EXP="URL" PREFIX="YES|NO">
<VALIDITY LEVEL="validity" REFRESHTIME="seconds"/>
<COOKIE NAME="cookie_name"
VALUE="value"
NONEXIST="YES|NO"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
</URL>
</INVALIDATION>

7.5.2 無効化レスポンスの構文

BASICSELECTOR無効化リクエストの無効化レスポンスは、次の形式で返されます。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECTRESULT>
<BASICSELECTOR URI="URL">
</BASICSELECTOR>
<RESULT ID="ID" STATUS="status" NUMINV="number"/>
<INFO VALUE="value"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

ADVANCEDSELECTOR無効化リクエストの無効化レスポンスは、次の形式で返されます。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="prefix"
URIEXP="URL_expression"
HOST="host_name:port"
METHOD="HTTP_request_method"
BODYEXP="HTTP_body"/>
<COOKIE NAME="cookie_name" VALUE="value"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
<OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
TYPE="SUBSTRING|REGEX"
VALUE="value"/>
</ADVANCEDSELECTOR>
<RESULT ID="ID" STATUS="status" NUMINV="number"/>
<INFO VALUE="value"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

有効な無効化レスポンスの先頭は、次のとおりです。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">

最初の行ではXMLのリリース1.0が指定されます。2行目は、レスポンスが、XML文書タイプとしてWCSinvalidation.dtdファイルを使用する無効化レスポンスであることを示しています。

ルート要素INVALIDATIONRESULTには、表7-2に説明する属性と要素が含まれています。BASICSELECTORおよびADVANCEDSELECTORについては、表7-1で説明されています。

表7-2 INVALIDATIONRESULTの要素および属性

無効化処理用の要素/属性

説明

VERSION属性

XML文書タイプとして使用するWCSinvalidation.dtdファイルのバージョン番号。

SYSTEM要素

INVALIDATIONRESULT要素のオプション要素。

SYSTEM要素はオプションです。SYSTEM要素はSYSTEMINFO要素が必要です。

SYSTEMINFO要素

SYSTEM要素の必須要素。

可能なNAME/VALUEペアを次に示します。

NAME="WCS_CACHE_NAME" VALUE="string"

このペアは、キャッシュの名前を指定します。

RESULT要素

次の属性を使用します。

- ID属性: 無効化レスポンスで送信されたすべての無効化オブジェクトの順序番号。無効化リクエストで複数のセレクタが指定された場合、順序番号は最初のセレクタが1で始まり、その後のセレクタに順番に番号が振られます。

- STATUS属性: 無効化のステータス。
- SUCCESS: 無効化が成功した場合

- URI NOT CACHEABLE: キャッシュ不可のオブジェクトの場合

- URI NOT FOUND: オブジェクトが見つからない場合

- NUMINV属性: 無効化リクエスト時に無効にされたオブジェクトの数。

INFO要素

無効化リクエストのINFO要素内に指定されているコメントを返します。

7.5.3 無効化プレビュー・リクエストの構文

無効化をテストするには、次の構文を使用して、無効にするBASICSELECTORオブジェクトのリストをプレビューします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="start_number" MAXNUM="max_number">
<BASICSELECTOR URI="URL"/>
</INVALIDATIONPREVIEW>

無効にするADVANCEDSELECTORオブジェクトのリストをプレビューするには、次の構文を使用します。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="start_number" MAXNUM="max_number">
<ADVANCEDSELECTOR URIPREFIX="prefix"
URIEXP="URL_expression"
HOST="host_name:port"
METHOD="HTTP_request_method"
BODYEXP="HTTP_body"
<COOKIE NAME="cookie_name" VALUE="value"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
<OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
TYPE="SUBSTRING|REGEX"
VALUE="value"/>
</ADVANCEDSELECTOR>
</INVALIDATIONPREVIEW>

有効な無効化プレビュー・リクエストのボディの先頭は、次のとおりです。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM "internal:///WCSinvalidation.dtd">

最初の行ではXMLのリリース1.0が指定されます。2行目は、リクエストが、XML文書タイプとしてWCSinvalidation.dtdファイルを使用する無効化プレビュー・リクエストであることを示しています。

ルート要素INVALIDATIONPREVIEWには、表7-3に説明する属性が含まれています。BASICSELECTORおよびADVANCEDSELECTORについては、表7-1で説明されています。

表7-3 INVALIDATIONPREVIEWの属性

無効化処理用の要素/属性

説明

VERSION属性

無効化プレビューの必須属性。

VERSION="WCS-1.1"を、XML文書タイプとして使用するWCSinvalidation.dtdファイルのバージョンとして使用します。

STARTNUM属性

無効化プレビューの必須属性。

リストされる最初のオブジェクトを表す番号を入力します。Oracle Web Cacheでは、番号0(ゼロ)からオブジェクトのカウントが始まります。

MAXNUM属性

無効化プレビューの必須属性。

リストされるオブジェクトの数を入力します。

無効化基準を満たすオブジェクトが指定した数よりも少ない場合、Oracle Web Cacheでは、基準を満たすオブジェクトのURLのみがリストされます。

無効化基準を満たすオブジェクトが指定した数よりも多い場合は、Oracle Web Cacheにより、リクエストした数のオブジェクトのURLがリストされます。無効化基準を満たすオブジェクトの合計数も返されます。追加オブジェクトのURLリストを取得するには、次のオブジェクト・セットの開始を指定する異なるSTARTNUMを含む別のプレビュー・リクエストを送信します。

7.5.4 無効化プレビュー・レスポンスの構文

プレビュー・リクエストに対する無効化プレビュー・レスポンスは、次の形式で返されます。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEWRESULT VERSION="WCS-1.1" STATUS="status" NUMURLS="number" TOTALNUMURLS="total_number">
<SELECTURL VALUE="URL">
</SELECTEDURL>
</INVALIDATIONPREVIEWRESULT>

有効な無効化プレビュー・レスポンスの先頭は、次のとおりです。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM "internal:///WCSinvalidation.dtd">

最初の行ではXMLのリリース1.0が指定されます。2行目は、レスポンスが、XML文書タイプとしてWCSinvalidation.dtdファイルを使用する無効化プレビュー・レスポンスであることを示しています。

次のことに注意してください。

- 「<?xml」の前に空白を入れないでください。

- アプリケーションが無効化リクエストをサード・パーティのXMLパーサーと共有している場合、"internal:///WCSinvalidation.dtd"のかわりに次のパスを使用します。

"http://www.oracle.com/webcache/90400/WCSinvalidation.dtd"

ルート要素INVALIDATIONPREVIEWRESULTには、表7-4に説明する属性と要素が含まれています。BASICSELECTORおよびADVANCEDSELECTORについては、表7-1で説明されています。

表7-4 INVALIDATIONPREVIEWRESULTの要素および属性

無効化処理用の要素/属性

説明

VERSION属性

XML文書タイプとして使用するWCSinvalidation.dtdファイルのバージョン番号。

STATUS属性

プレビューのステータス。

- SUCCESS: 無効化が成功した場合

- URI NOT CACHEABLE: キャッシュ不可のオブジェクトの場合

- URI NOT FOUND: オブジェクトが見つからない場合

STARTNUM属性

リストされる最初のオブジェクトを示す番号。

NUMURLS属性

このプレビュー結果で返されるURLの数。

TOTALNUMURLS属性

BASICSELECTORまたはADVANCEDSELECTORセレクタに一致するURLの数。

SELECTEDURL要素

無効にされるBASICSELECTORまたはADVANCEDSELECTORセレクタに一致するURL。

7.5.5 無効化の例

この項には、次の無効化リクエストの例が含まれます。

- 第7.5.5.1項「例: 1つのオブジェクトを無効にする」

- 第7.5.5.2項「例: 複数のオブジェクトを無効にする」

- 第7.5.5.3項「例: オブジェクトのサブツリーを無効にする」

- 第7.5.5.4項「例: 特定のWebサイトのすべてのオブジェクトを無効にする」

- 第7.5.5.5項「例: 接頭辞の一致を使用してオブジェクトを無効にする」

- 第7.5.5.6項「例: サブストリングと問合せ文字列の一致を使用してオブジェクトを無効にする」

- 第7.5.5.7項「例: 検索キーの一致を使用してオブジェクトを無効にする」

- 第7.5.5.8項「例: キャッシュ・クラスタで無効化リクエストを伝播する」

- 第7.5.5.9項「例: 無効化をプレビューする」

この項の例ではPOSTメソッドを使用する必要があり、ヘッダーのcontent_length: #bytes部でバイト(文字)数を送信する必要もあります。content_length: #bytes行の後、XMLリクエストまたはBODY情報の前に改行を1回入れる必要があるため、注意してください。

7.5.5.1 例: 1つのオブジェクトを無効にする

次のリクエストにより、ファイル/images/logo.gifを無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
<ACTION/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

次のリクエストにより、BASICSELECTOR要素を使用して、/contacts/contacts.htmlに完全一致するオブジェクトを無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<BASICSELECTOR URI="http://www.company.com:80/contacts/contacts.html"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

このリクエストは、ADVANCEDSELECTOR要素を使用した次のリクエストと同じです。このリクエストでは、HOST属性でサイト情報が指定されています。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="^/contacts/contacts\.html$" HOST="www.company.com:80"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

2番目のリクエストでは、URIPREFIX属性でサイト情報が指定されています。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="http://www.company.com/contacts/" URIEXP="^/contacts/contacts\.html$"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

ADVANCEDSELECTOR要素ではURIPREFIX属性が使用されます。この属性は、ディレクトリ構造の横断に使用されます。無効化が正しいツリー・レベルに到達するのが早いほど、無効化プロセスは早く完了します。これらの2つの例のうち、BASICSELECTOR要素を使用したリクエストはディレクトリ構造の横断が実行されないため、より効率的です。

7.5.5.2 例: 複数のオブジェクトを無効にする

次のリクエストにより、summary.jspおよびsummary.gifの2つのオブジェクトを無効にします。さらに、このリクエストにより、コメント"summary.jsp"および"summary.gif"が無効化の結果およびイベント・ログに含まれます。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001" HOST="www.company.com:80"/>
<COOKIE NAME="group" VALUE="asia"/>
</ADVANCEDSELECTOR>
<ACTION />
<INFO VALUE="summary.jsp"/>
</OBJECT>
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" HOST="www.company.com:80"/>
<INFO VALUE="summary.gif"/>
<ACTION />
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/global/sales/" URIEXP="summary.jsp\?year=2001" HOST="www.company.com:80"/>
<COOKIE  NAME="group"  VALUE="asia"  />
</ADVANCEDSELECTOR>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="2"/>
<INFO VALUE="summary.jsp"/>
</OBJECTRESULT>
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/image/" URIEXP="summary.*\.gif$" HOST="www.company.com:80"/>
</ADVANCEDSELECTOR>
<RESULT ID="2" STATUS="SUCCESS" NUMINV="14"/>
<INFO VALUE="summary.gif"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

イベント・ログには、次のメッセージが書き込まれます。

[15/Oct/2008:19:26:46 +0000] [notification 11748] [invalidation] [ecid:
21085932167,0] Invalidation with INFO 'summary.jsp' has returned with status
'SUCCESS'; number of objects invalidated: '2'.
.
.
.
[15/Oct/2008:19:26:46 +0000] [notification 11748] [invalidation] [ecid:
21085932167,0] Invalidation with INFO 'summary.gif' has returned with status
'SUCCESS'; number of objects invalidated: '14'.

7.5.5.3 例: オブジェクトのサブツリーを無効にする

次のリクエストにより、/images/ディレクトリ内のオブジェクトをすべて無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/images/" HOST="www.company.com:80"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/images/" HOST="www.company.com:80"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="125"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

次のリクエストにより、/contacts/ディレクトリ内でファイル名が.htmlで終わり、oracleの値を持つCookie名custを使用するオブジェクトをすべて無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/contacts/" URIEXP="\.html$" HOST="www.company.com:80"/>
<COOKIE NAME="cust" VALUE="oracle"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/contacts"/> URIEXP="\.html$" HOST="www.company.com:80"/>
<COOKIE NAME="cust" VALUE="oracle"/>
</ADVANCEDSELECTOR>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="45"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

7.5.5.4 例: 特定のWebサイトのすべてのオブジェクトを無効にする

次のリクエストにより、/内のオブジェクトをすべて無効にします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="17"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

7.5.5.5 例: 接頭辞の一致を使用してオブジェクトを無効にする

URIPREFIX属性とURIEXP属性の関係をさらに理解できるように、次の例を使って説明します。

次の構文は、/cec/cstage/graphic*ディレクトリ内のsample.gifファイルを無効にします。

<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/"
URIEXP="graphic.*/sample\.gif">
</ADVANCEDSELECTOR>

"graphic.*/sample\.gif"で使用されている「.*」は正規表現の文字で、graphicで始まるすべてのディレクトリに一致します。sample\.gifで使用されている「.」は、文字どおり解釈されるようにエスケープされています。

次の構文は、graphic*という名前のディレクトリを見つけるようOracle Web Cacheに指示します。

<ADVANCEDSELECTOR URIPREFIX="/cec/cstage/graphic*/" URIEXP="sample\.gif" HOST="www.company.com:80"/>
</ADVANCEDSELECTOR>

次の構文は、URIに/cec/cstage?ecaction=viewitemが含まれているオブジェクトを無効にします。

<ADVANCEDSELECTOR URIPREFIX="/cec/" URIEXP="cstage\?ecaction=viewitem" HOST="www.company.com:80"/>
</ADVANCEDSELECTOR>

「?」がバックスラッシュでエスケープされている点に注意してください。

/cec/cstage?ecaction=viewitem&zip=94405や/cec/cstage?ecaction=viewitem&zip=94305などのURLは一致して無効になりますが、/usa/cec/cstage?ecaction=viewitem&zip=94209は一致しないので無効になりません。

7.5.5.6 例: サブストリングと問合せ文字列の一致を使用してオブジェクトを無効にする

次のリクエストは、サブストリング/post/およびhtmに一致する/内のすべてのオブジェクトを無効にします。さらに、このリクエストは、無効化の結果とイベント・ログにコメント"remove-htm-under-all-post-dir"が書き込まれるようにします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/"
HOST="www.company.com:80">
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/post/"/>
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="htm"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="0" />
<INFO VALUE="remove-htm-under-all-post-dir"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/post/"/>
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="htm"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="52"/>
<INFO VALUE="remove-htm-under-all-post-dir"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

イベント・ログには、次のメッセージが書き込まれます。

[15/Oct/2008:19:26:46 +0000] [notification 11748] [invalidation] [ecid:
21085932167,0] Invalidation with INFO 'remove-htm-under-all-post-dir has
returned with status 'SUCCESS'; number of objects invalidated: '52'.

次のリクエストは、サブストリング/view_building.asp、および埋込みURLパラメータ値のペアbuilding=8とfloor=10に一致する、/corporate/asp/内のすべてのオブジェクトを無効にします。さらに、このリクエストは、無効化の結果とイベント・ログにコメント"remove-view-building8-10th-floor"が書き込まれるようにします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/corporate/asp/"
HOST="www.company.com:80">
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
<OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
<OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="0" />
<INFO VALUE="remove-view-building8-10th-floor"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/" HOST="www.company.com:80"/>
<OTHER NAME="URI" TYPE="SUBSTRING" VALUE="/view_building.asp"/>
<OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="building=8"/>
<OTHER NAME="QUERYSTRING_PARAMETER" TYPE="SUBSTRING" VALUE="floor=10"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="3"/>
<INFO VALUE="remove-view-building8-10th-floor"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

イベント・ログには、次のメッセージが書き込まれます。

[15/Oct/2008:19:26:46 +0000] [notification 11748] [invalidation] [ecid: 21085932
167,0] Invalidation with INFO 'remove-view-building8-10th-floor' has returned with status 'SUCCESS'; number of objects invalidated: '3'.

QUERYSTRING_PARAMETERを使用して無効化を最適化する方法は、第7.7.2.2項を参照してください。

7.5.5.7 例: 検索キーの一致を使用してオブジェクトを無効にする

次のリクエストにより、次の項目に一致する/pls/publicuser/内のオブジェクトをすべて無効にします。

- サブストリング/pls/publicuser/!MODULE.wwpob_page.show

- HTTPリクエスト・ヘッダーx-oracle-cache-userおよび値PUBLICUSER

- 検索キーtemplate_id=33,31345を含むSurrogate-Keyレスポンス・ヘッダー・フィールド

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="/pls/publicuser/" HOST="www.company.com:80"
METHOD="POST">
<OTHER NAME="SEARCHKEY" VALUE="template_id=33,31345"/>
<HEADER NAME="x-oracle-cache-user" VALUE="PUBLICUSER"/>
<OTHER NAME="URI" TYPE="SUBSTRING"
VALUE="/pls/publicuser/!MODULE.wwpob_page.show"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<ADVANCEDSELECTOR URIPREFIX="/pls/publicuser/" HOST="www.company.com:80"
METHOD="POST">
<OTHER NAME="SEARCHKEY" VALUE="template_id=33,31345"/>
<HEADER NAME="x-oracle-cache-user" VALUE="PUBLICUSER"/>
<OTHER NAME="URI" TYPE="SUBSTRING"
VALUE="/pls/publicuser/!MODULE.wwpob_page.show"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="3"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>

7.5.5.8 例: キャッシュ・クラスタ全体に無効化リクエストを伝播する

Fusion Middleware ControlとOracle Web Cache Managerでは、キャッシュ・クラスタで、すべてのクラスタ・メンバーへの無効化リクエストの伝播を有効または無効にできます。第3.6.5項および第3.7.4項をそれぞれ参照してください。

この設定を優先させるには、SYSTEMINFO要素の名前/値の属性ペアを使用します。NAMEがWCS_PROPAGATEに設定され、VALUEがTRUEに設定されている場合は、Fusion Middleware ControlまたはOracle Web Cache Managerで設定されている値が無視されます。NAMEがWCS_PROPAGATEに設定され、VALUEがFALSEに設定されている場合は、Fusion Middleware ControlまたはOracle Web Cache Managerで設定されている値が使用されます。

次のリクエストは、ファイル/images/logo.gifを無効にして、リクエストをすべてのクラスタ・メンバーに伝播します。この例では、3つのクラスタ・メンバーがあります。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="WCS_PROPAGATE" VALUE="TRUE"/>
</SYSTEM>
<OBJECT>
<BASICSELECTOR URI="/web_cache_host_name:port/images/logo.gif"/>
<ACTION/>
</OBJECT>
</INVALIDATION>

無効化レスポンス:

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULTDETAIL SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULTDETAIL VERSION="WCS-1.1">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_A"/>
</SYSTEM>
<OBJECTRESULT>
<BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>
<INVALIDATIONRESULT VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_B"/>
</SYSTEM>
<OBJECTRESULT>
<BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>
<INVALIDATIONRESULT VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="Cache_C"/>
</SYSTEM>
<OBJECTRESULT>
<BASICSELECTOR URI="http://www.company.com:80/images/logo.gif"/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>
</INVALIDATIONRESULTDETAIL>

7.5.5.9 例: 無効化をプレビューする

次のリクエストは、*.htmで終わるオブジェクトを最大50個プレビューします。

<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEW SYSTEM
"internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEW VERSION="WCS-1.1" STARTNUM="0" MAXNUM="50">
<ADVANCEDSELECTOR URIPREFIX="http://company-sun/"
URIEXP=".*\.htm" >
</ADVANCEDSELECTOR>
</INVALIDATIONPREVIEW>

無効化レスポンス:

"<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONPREVIEWRESULT SYSTEM
"internal:///WCSinvalidation.dtd">
<INVALIDATIONPREVIEWRESULT VERSION="WCS-1.1" STATUS="SUCCESS"
STARTNUM="0" NUMURLS="2" TOTALNUMURLS="2">
<SYSTEM>
<SYSTEMINFO NAME="WCS_CACHE_NAME" VALUE="server-cache"/>
</SYSTEM>
<SELECTEDURL VALUE="/company-sun:80/index.htm "/>
<SELECTEDURL VALUE="/company-sun:80/dtd.htm "/>
</INVALIDATIONPREVIEWRESULT>

7.6 検索キーによる無効化について

キャッシュ内のオブジェクトのSurrogate-Keyレスポンス・ヘッダー・フィールドで使用される1つ以上の検索キーに基づいて無効化を実行できます。

Surrogate-Keyレスポンス・ヘッダー・フィールドを使用すると、アプリケーション開発者は特定のレスポンス・オブジェクトの検索キー文字列を識別できます。検索キーは、オブジェクトのURL、CookieまたはHTTPリクエスト・ヘッダーに表示されない場合がある文字列です。検索キーの目的は、無効化に対して別の基準を提供することです。オブジェクトのURLの他に、Oracle Web Cache管理者は、キャッシュ内のSurrogate-Keyレスポンス・ヘッダー・フィールドで使用される1つ以上の検索キーに基づいて無効化を実行できます。

Surrogate-Keyレスポンス・ヘッダー・フィールドは、次の構文をサポートします。

Surrogate-Key: search-key=("key" "key" "key" ...)

使用方法

- このヘッダーでsearch-keyが指定されている場合は、少なくとも1つの検索キー値が存在している必要があります。

- 検索キーの値は引用符(")で囲む必要があります。

- 検索キーの値の形式は、"key_value"または"key_name=key_value"などです。

- 検索キーの最大許容数は20です。

- 検索キーの間の空白はオプションです。

- 検索キーは同じ指定のままにする必要があります。

使用例

次の例は、有効なSurrogate-Keyフィールドを示しています。最初の例は1つの検索キーtemplate_id=33,31345を示し、2番目の例は検索キーtemplate_id=33,31345およびcategoryを示しています。

Surrogate-Key: search-key=( "template_id=33,31345"  )

Surrogate-Key: search-key=("template_id=33,31345" "category")

次の例は、無効なSurrogate-Keyフィールドを示しています。最初の例は閉じ引用符(")のない1つの検索キー348を示し、2番目の例は検索キー値のないsearch-keyを示しています。

Surrogate-Key: search-key=( "template_id=348 )
Surrogate-Key: search-key=( )

検索キーによる無効化を有効にする方法の詳細は、第7.9項を参照してください。

7.7 バンド外無効化の開始

次の項目では、バンド外無効化を開始する方法について説明します。

- 第7.7.1項「Telnetを使用した無効化リクエストの送信」

- 第7.7.2項「Oracle Web Cache Managerを使用した無効化リクエストの送信」

- 第7.7.3項「Application Program Interface(API)を使用した自動無効化リクエスト」

- 第7.7.4項「データベース・トリガーを使用した自動無効化リクエスト」

- 第7.7.5項「スクリプトを使用した自動無効化」

7.7.1 Telnetを使用した無効化リクエストの送信

HTTP POSTリクエストで無効化リクエストを送信する際に、Oracle Web Cacheのホスト名、無効化リスニング・ポート番号および無効化リクエストを指定します。

たとえば、telnetを使用している場合は、次の手順で無効化リクエストを送信します。

1. 無効化リスニング・ポートでOracle Web Cacheに接続します。

telnet web_cache_host invalidation_port

2. 次の構文のBase64エンコーディング文字列を使用して、POSTメッセージ・ヘッダーを指定し、invalidatorアカウントを認証します。

POST /x-oracle-cache-invalidate http/1.0|1
Authorization: BASIC <base64 encoding of invalidator:invalidator_password>
content-length:#bytes

次に示すのはAuthorization行の例です。

Authorization: BASIC aW52YWxpZGF0b3I6aW52YWxpZGF0b3I=

この例のaW52YWxpZGF0b3I6aW52YWxpZGF0b3I=は、エンコードされたinvalidatorユーザー名とパスワード(invalidator:invalidator)です。

詳細は、次を参照してください。

- パスワードのBase64エンコーディングの詳細は、http://www.rfc-editor.org/を参照してください。

- EncodeBase64.javaスクリプトを使用して、invalidator:invalidator_passwordのBase64文字列を生成する方法の詳細は、readme.examples.htmlを参照してください。このファイルは次のディレクトリにあります。

(UNIX) ORACLE_HOME/webcache/docs
(Windows) ORACLE_HOME\webcache/docs

- 無効化パスワードの変更の詳細は、第5.2項を参照してください。

3. 改行を1回入力します。

4. 第7.5項に指定されているように、XML構文の無効化リクエストを送信します。

7.7.2 Oracle Web Cache Managerを使用した無効化リクエストの送信

Oracle Web Cache Managerの使いやすいインタフェースにより、キャッシュされたオブジェクトを簡単に無効化できます。このインタフェースを使用する利点は、管理者が複雑なHTTPおよびXMLフォーマットを使用する必要がなく、その結果、エラーが減少するという点です。管理者が指定する必要があるのは、無効にするオブジェクトと、オブジェクトを無効にするタイミングのみです。

Oracle Web Cache Managerを使用すると、1つのオブジェクトに対して基本無効化リクエストを送信するか、複数のオブジェクトに対して拡張無効化リクエストを送信できます。詳細は、次の各項目を参照してください。

- 第7.7.2.1項「基本無効化リクエストの発行」

- 第7.7.2.2項「拡張無効化リクエストの発行」

注意:
「Basic Content Invalidation」ページまたは「Advanced Content Invalidation」ページから無効化リクエストを発行したときに次のエラーが発生した場合は、サーバー・プロセスcacheまたはadminを再起動してください。
Internal error: can't connect to Oracle Web Cache Invalidation Listening Port

無効化ポートのプロパティを変更した場合は、cacheサーバー・プロセスを再起動してください。「セキュリティ」ページでadministratorアカウントのパスワードを変更した場合は、cacheおよびadminの各サーバー・プロセスを再起動してください。いずれの構成変更の場合も、cacheサーバー・プロセスが再起動されるまで、無効化リクエストではエラーが返されます。

再起動の方法は、第2.13項を参照してください。

7.7.2.1 基本無効化リクエストの発行

Oracle Web Cache Managerを使用して基本無効化リクエストを送信するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Operations」→「Basic Content Invalidation」を選択します。第2.7.2項を参照してください。
右ペインに「Basic Content Invalidation」ページが表示されます。

2. 「For Cache」リストからキャッシュを1つ選択します (キャッシュ・クラスタを構成済の場合にかぎり、リストには複数のキャッシュが表示されます)。無効化を伝播するようにクラスタが構成されている場合は、選択したキャッシュは、無効化コーディネータに指定されます。この無効化コーディネータによって、無効化リクエストは他のキャッシュ・クラスタ・メンバーに伝播されます。クラスタが無効化を伝播するように構成されていない場合、選択できるキャッシュはオブジェクトの無効化元キャッシュのみです)。

3. 「Search Criteria」セクションで、次の検索基準を選択します。

- Remove all cached objects: キャッシュ内のオブジェクトをすべて削除する場合に選択します。

- Enter exact URL for removal: 無効にするオブジェクトのURLを指定します。完全パスおよびファイル名を含めてください。
注意: Oracle Web Cacheでは、アンパサンド(&)、右山カッコ(>)、左山カッコ(<)、二重引用符(")および一重引用符(')がエスケープされるため、このフィールドにこれらのエスケープ文字を入力できます。

4. オプションで、無効にするオブジェクトのリストをプレビューして、削除するオブジェクトの選択が誤っていないことを確認できます。オブジェクトのリストをプレビューするには、次の手順を実行します。

1. 「Action」セクションで、無効化基準に一致するオブジェクトの「Preview」リストを選択します。

2. 「Object Range」を指定します。

- From: リストされる最初のオブジェクトを表す番号を入力します。Oracle Web Cacheでは、番号0(ゼロ)からオブジェクトのカウントが始まります。

- To: リストされるオブジェクトの数を入力します。
無効化基準を満たすオブジェクトが指定した数よりも少ない場合、Oracle Web Cacheでは、基準を満たすオブジェクトのみのURLがリストされます。

無効化基準を満たすオブジェクトが指定した数よりも多い場合は、Oracle Web Cacheにより、リクエストした数のオブジェクトのURLがリストされます。無効化基準を満たすオブジェクトの合計数も返されます。追加オブジェクトのURLリストを取得するには、次のオブジェクト・セットの開始を指定する異なる「From」数を含む別のプレビュー・リクエストを送信します。

3. 「Submit」をクリックします。
無効化基準を満たすオブジェクトが「Invalidation Preview Results」メッセージ・ボックスにリスト表示されます。Oracle Web Cache Managerでは、有効なオブジェクトのみがリストされます。キャッシュには、期限切れまたは無効にされたオブジェクトが含まれることもありますが、それらはリストされません。

無効にするオブジェクトがリストされている場合は、次の手順に進みます。リストされていない場合は、無効化基準を変更してもう一度プレビューします。

5. 「Action」セクションで、いずれかのオプションを選択して、無効になったオブジェクトの処理方法を指定します。

- Remove immediately: Oracle Web Cacheで、オブジェクトを無効にしてすぐに削除します。キャッシュがそのオブジェクトに対する次のリクエストを受信すると、オリジン・サーバーからオブジェクトが更新されます。

- Remove objects no later than <number> <time> after submission: Oracle Web Cacheでオブジェクトを無効としてマークし、オリジン・サーバーの容量に基づいてリフレッシュします。オブジェクトがキャッシュ内に存続可能な最大期間を入力します。このオプションを選択すると、Oracle Web Cacheではヒューリスティックが適用され、これ以上ドキュメントを送信しない最適なタイミングが決定されます。

6. 「Submit」をクリックします。

Oracle Web Cacheにより、無効化リクエストが処理され、無効化ステータスが表示されている「Cache Cleanup Result」ダイアログ・ボックスが返されます。次の図はこのダイアログ・ボックスを示しています。

図invalid.gifの説明

キャッシュ・クラスタ環境では、「任意のクラスタ・メンバーに送信された無効化リクエストは、すべてのクラスタ・メンバーに伝播されます。」を有効にすると、Oracle Web Cacheは無効化リクエストを、無効化コーディネータとして動作する1つのクラスタ・メンバーに送信します。コーディネータは無効化リクエストを他のクラスタ・メンバーに伝播します。すべてのクラスタ・メンバーに対して無効化が完了すると、Oracle Web Cacheは、各クラスタ・メンバーについて、キャッシュ名、無効化リクエストのステータスおよび無効化されたオブジェクト数をリストする「キャッシュ・クリーンアップ」ボックスを返します。

無効化伝播を有効にする方法は、第3.6.5項を参照してください。

7.7.2.2 拡張無効化リクエストの発行

Oracle Web Cache Managerを使用して拡張無効化リクエストを送信するには、次の手順を実行します。

1. ナビゲータ・フレームで、「Operations」→「Advanced Content Invalidation」を選択します。
右ペインに「Advanced Content Invalidation」ページが表示されます。

2. 「For Cache」リストからキャッシュを1つ選択します。(キャッシュ・クラスタを構成済みの場合にかぎり、リストには複数のキャッシュが表示されます。)

3. 「Search Criteria」セクションで、次の検索基準を選択します。

注意:
Oracle Web Cacheでは、アンパサンド(&)、右山カッコ(>)、左山カッコ(<)、二重引用符(")および一重引用符(')がエスケープされるため、これらのエスケープ文字を検索基準フィールドに入力できます。

- URL Path Prefix: 必須。無効にするオブジェクトのパス接頭辞を指定します。パス接頭辞は、http|https://host_name:port/path/filenameまたは"/"で始めて、"/"で終わる必要があります。
host_name:portはオプションです。「Host Name」フィールドで、サイトのホスト名とポートも指定できます。

接頭辞は、正規表現の予約語を含め、文字どおり解釈されます。このような文字として、ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、キャレット(^)、ドル記号($)および円記号(¥)があります。

- Host Name: オプション。サイトのホスト名とポート番号(host_name:port)を指定します。HTTPのデフォルト・ポートはポート80です。
このフィールドは、「URL Path Prefix」にhttp|https://host_name:port/path/filenameが含まれていない場合は必須です。

- HTTP Method: オプション。無効にするオブジェクトのHTTPリクエスト・メソッド(GETまたはPOST)を選択します。デフォルト値はGETです。

- URL Expression: オプション。「URL Path Prefix」内に存在する無効にするオブジェクトのURLを指定します。次に、厳密な文字列照合を行う場合は「substring」、正規表現照合を行う場合は「regular expression」を選択して、照合方法を指定します。
値が入力されなかった場合、「URL Path Prefix」内のすべてのオブジェクトが一致します。

- POST Body Expression: オプション。「HTTP Method」に対して「POST」を選択した場合は、無効にするオブジェクトのHTTP POST本体を入力し、サブストリング一致の場合は「substring」を、正規表現一致の場合は「regular expression」を選択して、一致方法を指定します。

注意:
「URL Expression」または「POST Body Expression」フィールドに対して「regular expression」を選択すると、Oracle Web Cacheは次の正規表現の予約語を解釈します。ピリオド(.)、疑問符(?)、アスタリスク(*)、大カッコ([])、中カッコ({})、キャレット(^)、ドル記号($)およびバックスラッシュ(\)。これらの文字を文字どおりに使用する場合は、その前にエスケープ文字としてバックスラッシュ(\)を置きます。

4. オプションで、「Cookie/Header Information」セクションで、複数バージョンのオブジェクトに対する検索基準にCookie名とHTTPリクエスト・ヘッダーのどちらを使用するかを指定します。

1. リストから、「Cookie」または「Header」を選択します。

2. 次の情報を入力します。

- Cookie: 「Name」フィールドに、無効にする複数バージョンのオブジェクトで使用されているCookie名を入力し、その値を「Value」フィールドに入力します。

注意:
複数のバージョンのオブジェクトとセッション・キャッシュ・ポリシーの両方に対して間違って指定されたCookieを指定する場合、無効化はこのCookieの発生に基づきます。過度の無効化を回避するには、複数バージョンのオブジェクト(「Rules for Caching, Personalization, and Compression」→「Cookie Definitions」)およびセッション・キャッシュ・ポリシー(「Rules for Caching, Personalization, and Compression」→「Session Definitions」)に対して異なるCookieを構成します。

- Header: 無効にするオブジェクトで使用されているHTTPリクエスト・ヘッダーを「Name」フィールドに入力し、その値を「Value」フィールドに入力します。

複数バージョンのオブジェクトに対するキャッシュ・ルールの作成方法は、第6.5.1項を参照してください。

5. オプションで、「URL Parameters」セクションの「Name」フィールドに、無効にするオブジェクトで使用されている埋込みURLパラメータの名前を入力し、その値を「Value」フィールドに入力します。次に、「exact strings」または「regular expression」のいずれかを選択して一致方法を指定します。

6. オプションとして、「Search Keys」セクションで、無効にするオブジェクトで使用されている「Surrogate-Key」レスポンス・ヘッダー・フィールドの検索キー名を「Key」フィールドに入力します。詳細は、第7.6項および第7.9項を参照してください。

7. オプションで、無効にするオブジェクトのリストをプレビューして、削除するオブジェクトの選択が誤っていないことを確認できます。オブジェクトのリストをプレビューするには、次の手順を実行します。

1. 「Action」セクションで、「Preview list of objects to be removed」を選択します。

2. 「Object Range」を指定します。

- From: リストされる最初のオブジェクトを表す番号を入力します。Oracle Web Cacheでは、番号0(ゼロ)からオブジェクトのカウントが始まります。

- To: リストされるオブジェクトの数を入力します。

無効化基準を満たすオブジェクトが指定した数よりも少ない場合、Oracle Web Cacheでは、基準を満たすオブジェクトのみのURLがリストされます。

無効化基準を満たすオブジェクトが指定した数よりも多い場合は、Oracle Web Cacheにより、リクエストした数のオブジェクトのURLがリストされます。無効化基準を満たすオブジェクトの合計数も返されます。追加オブジェクトのURLリストを取得するには、次のオブジェクト・セットの開始を指定する異なる「From」数を含む別のプレビュー・リクエストを送信します。

3. 「Submit」をクリックします。
無効化基準を満たすオブジェクトが「Invalidation Preview Results」メッセージ・ボックスにリスト表示されます。Oracle Web Cache Managerでは、有効なオブジェクトのみがリストされます。キャッシュには、期限切れまたは無効にされたオブジェクトが含まれることもありますが、それらはリストされません。

無効にするオブジェクトがリストされている場合は、次の手順に進みます。リストされていない場合は、無効化基準を変更してもう一度プレビューします。

8. 「Action」セクションで、いずれかのオプションを選択して、無効になったオブジェクトの処理方法を指定します。

- Remove immediately: Oracle Web Cacheで、オブジェクトを無効にしてすぐに削除します。キャッシュがそのオブジェクトに対する次のリクエストを受信すると、オリジン・サーバーからオブジェクトが更新されます。

- Remove objects no later than <number> <time> after submission: Oracle Web Cacheでオブジェクトを無効としてマークし、オリジン・サーバーの容量に基づいてリフレッシュします。オブジェクトがキャッシュ内に存続可能な最大期間を入力します。

9. 「Submit」をクリックします。

Oracle Web Cacheにより、無効化リクエストが処理され、無効化ステータスが表示されている「Cache Cleanup」ダイアログ・ボックスが返されます。

注意:
接頭辞ベースの無効化の場合、Oracle Web Cacheが複雑なディレクトリ構造内を横断する必要があるため、無効化に多少時間がかかる場合があります。したがって、「Cache Cleanup Result」ダイアログ・ボックスが表示されるまで、「Submit」を再びクリックしないでください。無効化リクエストのキューを作成すると、Oracle Web Cacheのパフォーマンスが低下します。

7.7.3 Application Program Interface(API)を使用した自動無効化リクエスト

無効化リクエストは、Webサイトのアプリケーション・ロジックから、またはWebページの設計に使用するコンテンツ管理アプリケーションから送信することも可能です。

Oracle Web Cacheには、次の実装可能なApplication Program Interface(API)が含まれています。

- jawc.jar(Java無効化API)

- wxvutil.sqlおよびwxvappl.sql(PL/SQL無効化API)

これらのAPIは次のディレクトリにあります。

(UNIX) ORACLE_HOME/webcache/toolkit
(Windows) ORACLE_HOME\webcache/toolkit

これらのAPIの詳細は、次のディレクトリにあるreadme.toolkit.htmlを参照してください。

(UNIX) ORACLE_HOME/webcache/docs
(Windows) ORACLE_HOME\webcache/docs

7.7.4 データベース・トリガーを使用した自動無効化リクエスト

データベース・トリガーはデータベースに格納されているプロシージャで、表への行の追加など、特定の状況が発生した場合に実行されます。トリガーを使用して無効化リクエストを送信することが可能です。データベース・トリガーによって無効化リクエストを送信するには、オラクル社が提供するUTL_TCPパッケージを使用します。

詳細は、OracleのPL/SQLに関するドキュメントを参照してください。

7.7.5 スクリプトを使用した自動無効化

多くのWebサイトで、スクリプトを使用して、新しいコンテンツがデータベースやファイル・システムにアップロードされています。たとえば、大型のオンライン書店の場合、1日1回、PERLスクリプトを実行し、新刊の追加や価格変更をカタログ・データベースに一括してロードすることがあります。その書店では、価格変更および在庫状況を、現在Oracle Web Cacheにキャッシュされているアイテム・ビューおよび検索結果にすぐに反映させるとします。この結果を得るため、Perlスクリプトを変更して、一括ロード処理の完了後にすべてのカタログ・ビューおよび検索結果を無効にする無効化リクエストをスクリプトからキャッシュに送信するようにすることが可能です。(無効化リクエストには、データ変更の影響を受ける検索ページまたはアイテム・ビューをすべて個別にリストする必要はありません。)Oracle Web Cacheのパフォーマンス保証機能により、管理者は一度に大量のコンテンツを無効にすることが可能です。コンテンツの一部のみが変更されている場合でも、すべてのカタログ・コンテンツを無効化してかまいません。

7.8 レスポンス・ヘッダーによる無効化の有効化

Oracle Web Cacheの機能の1つであるレスポンス・ヘッダーによる無効化によって、オリジン・サーバーは、キャッシュされたコンテンツをHTTPレスポンス・ヘッダーを通じて無効化できます。

レスポンス・ヘッダー・フィールドは次の構文をサポートします。

Oracle-WebCache-Invalidate:
([SYNCHRONOUS=ON|OFF,]
(URI="value" | ( URI_DIR="value" [(;S_KEY="value")*] )
| ( S_KEY="value"   [(;S_KEY="value")*] ))
([,SYNCHRONOUS=ON|OFF,]
URI="value" | ( URI_DIR="value" [(;S_KEY="value")*] )
| ( S_KEY="value"   [(;S_KEY="value")*] ))*
[,SYNCHRONOUS=ON|OFF]

表7-5に、レスポンス・ヘッダーによる無効化の制御ディレクティブを示します。

表7-5 Oracle-WebCache-Invalidateの制御ディレクティブ

制御ディレクティブ

説明

SYNCHRONOUS

SYNCHRONOUSディレクティブにより、Oracle Web Cacheは、無効化を完了するかどうかを決定してからレスポンスをクライアントに返すことができます。これは、無効化全体、つまり特定のレスポンスに対するすべての無効化レスポンス・ヘッダーの組合せに適用されます。デフォルトでは、Oracle Web Cacheは無効化が完了するまで待機し(SYNCHRONOUS=ON)、その後でレスポンスを返します。通常、オリジナル・サーバーでホストされているコンテンツは元のリクエストによって更新され、オリジナル・サーバーは、クライアントがレスポンスを受信する前にコンテンツに関連するすべてのエントリがOracle Web Cacheで無効化されるようにします。元のリクエストと無効化レスポンス・ヘッダーで識別されたコンテンツは直接リンクされています。

オリジン・サーバーが無効化レスポンス・ヘッダーを任意のリクエストに追加する場合、そのリクエストを送信したクライアントは、無効化が完了するまで待機する必要はありません。この場合、オリジン・サーバーは、無効化を処理する前にレスポンスを返すようOracle Web Cacheに指示します(SYNCHRONOUS=OFF)。

URI

無効化の指定でURIオプション・ディレクティブを使用すると、Oracle Web Cacheは指定されたURIを持つエントリを無効化できます。これは、基本無効化に相当します。

URI_DIR

無効化の指定でURI_DIRオプション・ディレクティブを使用すると、Oracle Web Cacheは指定されたURIをディレクトリと解釈し、指定されたディレクトリ内のすべてのエントリを無効化できます。これは、小規模で使用頻度の高い拡張無効化のサブセットであるURI接頭辞無効化に相当します。

URI_DIRオプション・ディレクティブと現在のURI接頭辞無効化との整合性を確保するために、ディレクトリURIの文字列はスラッシュ(/)で終わる必要があります。

S_KEY

無効化の指定でS_KEYオプション・ディレクティブを使用すると、Oracle Web Cacheは引用符付き文字列を検索キーと解釈します。これは、拡張無効化のもう1つの小さなサブセットである検索キーによる無効化に相当します。検索キーの一致では、従来の無効化と同様に、大文字小文字が区別されます。

S_KEYオプション・ディレクティブがURIディレクトリを明示的に記述しないで指定された場合、Oracle Web Cacheは、受信リクエストに関連するサイト定義のルートに相当する暗黙的URIディレクトリを使用します。特に、サイト定義にパス接頭辞が含まれている場合、暗黙的URIディレクトリにこのパス接頭辞が含まれます。

結合された複数ディレクティブ

無効化レスポンス・ヘッダーには、URIディレクトリの後に1つ以上の検索キーを続けることもできます。その場合は、セミコロン(;)デリミタで各ディレクティブを区切ります。この場合、Oracle Web Cacheエントリはすべてのディレクティブに一致していないと無効化の対象となりません。

複数の無効化ディレクティブ

無効化レスポンス・ヘッダーに複数の無効化ディレクティブが含まれていて、連続する無効化ディレクティブのペアがそれぞれカンマで区切られている場合、Oracle Web Cacheエントリは無効化ディレクティブの少なくとも1つと一致していないと無効化の対象となりません。つまり、Oracle Web Cacheは、カンマで区切られた個々の無効化ディレクティブを独立した無効化操作として扱います。

カンマとセミコロンの混在

無効化レスポンス・ヘッダーにカンマとセミコロンの両方のセパレータが含まれている場合は、セミコロンが優先されます。したがって、セミコロンで区切られた一連のディレクティブが調べられた後に、カンマで区切られた一連のディレクティブが調べられます。

複数の無効化レスポンス・ヘッダー

オリジン・サーバーは、Oracle Web Cacheへのレスポンスに複数の無効化レスポンス・ヘッダーを格納できます。この場合、Oracle Web Cacheエントリは1つのヘッダーに一致していれば無効化の対象となります。つまり、同一レスポンス内の複数の無効化レスポンス・ヘッダーのコンテンツは、カンマで結合された1つのレスポンス・ヘッダーの一部として扱われます。

レスポンスに無効な無効化レスポンス・ヘッダーが1つでも含まれていると、その他の無効化レスポンス・ヘッダーが有効であっても、無効化は行われません。

使用方法

- 無効化レスポンス・ヘッダーは、ヘッダー名Oracle-WebCache-Invalidate、コロン(:)およびカンマ(,)で区切った無効化ディレクティブの連続ペアからなる1つ以上の無効化ディレクティブで構成されます。ディレクティブの前または後に、オプションの同期ディレクティブを含めることもできます。

- 同期ディレクティブは、キーワードSYNCHRONOUS、等記号(=)およびキーワードONまたはOFFで構成されます。

- 無効化は、URI指定または複数ディレクティブ指定で構成されます。

- URIディレクティブは、URIオプション・ディレクティブ、等記号(=)および引用符付き文字列で構成されます。

- URIオプション・ディレクティブは、キーワードURIで構成されます。

- 複数ディレクティブ指定には、次の2つの形式があります。

- 明示的ディレクトリ

- 暗黙的ディレクトリ

- 明示的ディレクトリの形式は、URIディレクトリのディレクティブおよび連続する検索キーがセミコロン(;)デリミタで区切られているゼロ個以上の検索キー・ディレクティブで構成されます。

- 暗黙的ディレクトリの形式は、連続する検索キーがセミコロン(;)デリミタで区切られている1つ以上の検索キーで構成されます。

- URIディレクトリは、URIディレクトリ・オプション・ディレクティブ、等記号(=)および引用符付き文字列で構成されます。

- URIディレクトリ・オプション・ディレクティブは、キーワードURI_DIRで構成されます。

- 検索キーは、検索キー・オプション・ディレクティブ、等記号(=)および引用符付き文字列で構成されます。

- 検索キー・オプション・ディレクティブは、キーワードS_KEYで構成されます。

- 引用符付き文字列には、URIまたは検索キーが含まれています。URIおよび検索キー文字列の大/小文字区別ルールと使用可能なキャラクタ・セットは、他の無効化機能と同じです。

- 完全に修飾されたURIの場合、有効なスキームはhttp://またはhttps://と有効なホスト名(例: www.host1.com)で構成されます。

- ポート番号が指定されている場合は、ポート番号も有効である必要があります。URIにポート番号が含まれていない場合、Oracle Web Cacheはデフォルトのポート番号としてHTTPに80、HTTPSに443を想定します。暗黙的URIディレクトリの場合、Oracle Web Cacheは、元のリクエストのサイトに基づいてディレクトリを決定します。Oracle Web Cacheでは、決定されたサイト定義が元のリクエストに関連するサイト定義と一致することを確認します。つまり、安全対策のために、Oracle Web Cacheではサイト間の無効化が許可されません。

- ワイルドカードが使用されているサイトからサーバーへのマッピングでは、関連するサイト定義がないリクエストが発生する可能性があります。この場合は保守主義の原則が適用され、Oracle Web Cacheではレスポンス・ヘッダーによる無効化が許可されません。

7.8.1 使用例

次の各項では、無効化レスポンス・ヘッダーの例を示します。

これらの例は、次のアドレスをWebサイトに持つHarry's Hardwareストア向けの架空のWebアプリケーションに基づいています。

http://www.HarrysHardware.com

このサイトでは、Harryが販売しているすべての人気商品の説明(小売価格を含む)を公開しています。Harryでは、自社のサイトをホストしているWebサーバーの前面にOracle Web Cacheを配置してオンライン顧客へのレスポンス時間を改善していますが、オンライン顧客に最新のコンテンツが表示されるようにするために、商品の説明と価格を更新するたびに関連するOracle Web Cacheエントリを無効にする必要があります。次の各例では、Harryで確認された様々なシナリオでレスポンス・ヘッダーによる無効化を使用する方法を示します。

この項の内容は次のとおりです。

- 第7.8.1.1項「基本的なURIによる無効化」

- 第7.8.1.2項「ディレクトリURIによる無効化」

- 第7.8.1.3項「非同期の無効化」

- 第7.8.1.4項「明示的URIを使用した検索キーによる無効化」

- 第7.8.1.5項「暗黙的URIを使用した検索キーによる無効化」

- 第7.8.1.6項「複数の無効化ディレクティブ」

- 第7.8.1.7項「カンマとセミコロンの混在」

- 第7.8.1.8項「複数の無効化レスポンス・ヘッダー」

7.8.1.1 基本的なURIによる無効化

Harryで特に人気のある商品はThorハンマーです。これに対応する説明ページのURIは次のとおりです。

http://www.harryshardware.com/products/tools/hammers/Thor.html

このThorハンマーを特売する場合は、Webアプリケーションで、完全に指定されたURIを含む無効化レスポンス・ヘッダーを使用して該当するWeb Cacheエントリを無効化できます。

Oracle-WebCache-Invalidate: URI="http://www.harryshardware.com/products/tools/hammers/Thor.html"

元のリクエストにホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIを含む無効化レスポンス・ヘッダーをアプリケーションで返すことができます。

Oracle-WebCache-Invalidate: URI="/products/tools/hammers/Thor.html"

7.8.1.2 ディレクトリURIによる無効化

店舗のハンマーをすべて特売する場合は、Webアプリケーションで、完全に指定されたURIディレクトリを含む無効化レスポンス・ヘッダーを使用して、ハンマーに関するすべてのWeb Cacheエントリを無効化します。

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/tools/hammers/"

元のリクエストでホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIディレクトリを含む無効化レスポンス・ヘッダーを返すことができます。

Oracle-WebCache-Invalidate: URI_DIR="/products/tools/hammers/"

7.8.1.3 非同期の無効化

ここまでの例では、同期ディレクティブを指定していないために、Oracle Web Cacheがクライアントにレスポンスを返す前にデフォルトで無効化を完了していました。

第7.8.1.2項の例を非同期に進める場合、つまり、Oracle Web Cacheが無効化の完了を待ってからレスポンスを返す必要がない場合は、Webアプリケーションで次のような無効化レスポンス・ヘッダーを送信できます。

Oracle-WebCache-Invalidate: SYNCHRONOUS=OFF,
URI_DIR="http://www.harryshardware.com/products/tools/hammers/"

このレスポンス・ヘッダーには、完全に修飾されたURIディレクトリが含まれていることに注意してください。元のリクエストでホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIディレクトリを含む無効化レスポンス・ヘッダーを返すことができます。

Oracle-WebCache-Invalidate: SYNCHRONOUS=OFF, URI_DIR="/products/tools/hammers/"

7.8.1.4 明示的URIを使用した検索キーによる無効化

Harryでは、TrueSawのこぎりのうち、手引きのこぎりを除いたすべての動力のこぎり(丸のこやチェーンソーなど)の価格を下げようとしています。Webアプリケーションでは、次のような無効化レスポンス・ヘッダーを使用して、必要なエントリをすべて無効化できます。

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/tools/saws/";S_KEY="PowerTool";
S_KEY="TrueSaw"

S_KEYディレクティブの追加によって、TrueSawの動力のこぎりのみが無効化されます。

無効化レスポンス・ヘッダーにセミコロンで区切った複数のディレクティブが含まれている場合は、Oracle Web Cacheエントリがすべてのディレクティブと一致していないと無効化が行われません。

この例のレスポンス・ヘッダーには、完全に修飾されたURIディレクトリが含まれていることにも注意してください。元のリクエストでホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIディレクトリを含む無効化レスポンス・ヘッダーを返すことができます。

Oracle-WebCache-Invalidate: URI_DIR="/products/tools/saws/";S_KEY="PowerTool";S_KEY="TrueSaw"

7.8.1.5 暗黙的URIを使用した検索キーによる無効化

Harryでは、大型家電製品(食器洗い機や冷蔵庫など)を販売する新たなサイトを立ち上げようとしています。このサイトの定義には、パス接頭辞/products/appliancesを使用します。表7-6に、このWebサイトのサイト定義を示します。

表7-6 Webサイトの定義

スキーム

ホスト

ポート番号

パス接頭辞

http

www.harryshardware.com

80

/products/appliances

http

www.harryshardware.com

80

/

最初のサイトは大型家電製品のみに関連し、2番目のサイトはHarryの店舗にあるその他すべての製品に関連しています。

さらにHarryでは、すべてのKeepCold冷蔵庫の価格を変更し、受信リクエストに対するサイト定義をHarryの家電製品サイトに関連させようとしています。このサイトのスキームはhttp、ホスト名はwww.harryshardware.com、ポート(オプション)は80、パス接頭辞は/products/appliancesです。Webアプリケーションでは、次のような無効化レスポンス・ヘッダーを使用して、必要なエントリをすべて無効化できます。

S_KEY="KeepCold";S_KEY="Refrigerators"

無効化レスポンス・ヘッダーには検索キー・ディレクティブのみが含まれ、URIディレクトリ・ディレクティブは含まれていないことに注意してください。この場合、Oracle Web Cacheは受信リクエストに関連付けられたサイト定義から暗黙的URIディレクトリを作成します。この場合の暗黙的ディレクトリは次のようになります。

http://www.harryshardware.com/products/appliances/

前述のように、複数のディレクティブがセミコロンで区切られている場合は、Oracle Web Cacheエントリがすべてのディレクティブに一致していないと無効化が行われません。

完全に修飾された明示的URIディレクトリによる無効化レスポンス・ヘッダーは、次のようになります。

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/appliances/";S_KEY="KeepCold";
S_KEY="Refrigerators"

パスのみの明示的URIディレクトリによる無効化レスポンス・ヘッダーは、次のようになります。

Oracle-WebCache-Invalidate: URI_DIR="/products/appliances/";S_KEY="PowerTool";
S_KEY="TrueSaw"

7.8.1.6 複数の無効化ディレクティブ

Harryでは、ドリルとレンチの在庫リスト全体を更新しようとしています。Webアプリケーションでは、次の無効化レスポンス・ヘッダーを含んだレスポンスを使用して、必要なエントリをすべて無効化できます。

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/tools/drills/",
URI_DIR="http://www.harryshardware.com/products/tools/wrenches/"

無効化レスポンス・ヘッダーにカンマで区切った連続する2つの無効化指定が含まれている場合は、Oracle Web Cacheエントリが1つの無効化指定に一致していれば無効化が行われます。

この例のレスポンス・ヘッダーには、完全に修飾されたURIディレクトリが含まれています。元のリクエストにホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIディレクトリを含む無効化レスポンス・ヘッダーをアプリケーションで返すことができます。

Oracle-WebCache-Invalidate: URI_DIR="/products/tools/drills/", URI_DIR="/products/tools/wrenches/"

7.8.1.7 カンマとセミコロンの混在

Harryでは、ThorハンマーとすべてのTrueSaw動力のこぎりを特売しようとしています。Webアプリケーションでは、次の無効化レスポンス・ヘッダーを含んだレスポンスを使用して、必要なエントリをすべて無効化できます。

Oracle-WebCache-Invalidate: URI="http://www.harryshardware.com/products/tools/hammers/Thor.html",

URI_DIR="http://www.harryshardware.com/products/tools/saws/";S_KEY="PowerTools";S_KEY="TrueSaw"

カンマとセミコロンの両方がセパレータとして使用されていることに注意してください。この例で、最初のディレクティブはThorハンマーのURIのみで構成されています。2番目のディレクティブは、のこぎりのURIディレクトリおよび、電動工具用(PowerTools)の検索キーとTrueSaw工具の検索キーという3つの無効化指定で構成されています。セミコロンはカンマよりも優先されます。

この例のレスポンス・ヘッダーには、完全に修飾されたURIと、完全に修飾されたURIディレクトリが含まれていることにも注意してください。

元のリクエストにホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIとパスのみのURIディレクトリを含む無効化レスポンス・ヘッダーをアプリケーションで返すことができます。

Oracle-WebCache-Invalidate: URI="/products/tools/hammers/Thor.html"

URI_DIR="/products/tools/saws/";S_KEY="PowerTools";S_KEY="TrueSaw"

7.8.1.8 複数の無効化レスポンス・ヘッダー

第7.8.1.6項の例に戻り、Webアプリケーションで、2つの無効化レスポンス・ヘッダーを含むレスポンスを使用して必要なエントリをすべて無効にすることもできます。

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/tools/drills/"

Oracle-WebCache-Invalidate: URI_DIR="http://www.harryshardware.com/products/tools/wrenches/"

同じレスポンス内の2つの異なる無効化レスポンス・ヘッダーのディレクティブは、1つのレスポンス・ヘッダー内の別個のディレクティブとして扱われます。つまりこれらは、1つの無効化レスポンス・ヘッダー内でカンマで区切られたものとして扱われます。このレスポンス・ヘッダーには、完全に修飾されたURIディレクトリが含まれていることにも注意してください。元のリクエストにホスト名(www.harryshardware.com)が明示的に指定されている場合は、パスのみのURIディレクトリを含む無効化レスポンス・ヘッダーをアプリケーションで返すことができます。

Oracle-WebCache-Invalidate: URI_DIR="/products/tools/drills/"

Oracle-WebCache-Invalidate: URI_DIR="/products/tools/wrenches/"

7.9 検索キーによる無効化の有効化

この機能を有効化するには、次の手順を実行します。

1. 次のように、Surrogate-Keyレスポンス・ヘッダー・フィールドを使用してHTTPレスポンスを構成します。

Surrogate-Key: search-key=("key" "key" "key" ...)

Surrogate-Keyレスポンス・ヘッダー・フィールドの詳細は、第7.6項を参照してください。

デフォルトでは、Oracle Web Cacheは最大20個の検索キーをサポートしています。制限数を増加するには、次の手順を実行します。

1. テキスト・エディタでwebcache.xmlファイルを開きます。

2. SEARCHKEYOPTIONS要素内でMAXSEARCHKEYSPERDOC属性を探します。

<GLOBALCACHINGRULES>
<SEARCHKEYOPTIONS ENABLE="YES" MAXSEARCHKEYSPERDOC="20"/>

<ERRORPAGES>

3. 値を大きい値に変更します。
次の例では、検索キーの制限を35に設定します。

<GLOBALCACHINGRULES>
<SEARCHKEYOPTIONS ENABLE="YES" MAXSEARCHKEYSPERDOC="35"/>

<ERRORPAGES>

4. webcache.xmlを保存します。

2. 次の方法を使用して、無効化リクエストに検索キーを指定します。

- バンド外無効化の場合

- Oracle Web Cache Managerの「Advanced Content Invalidation」ページ(「Operations」→「Advanced Content Invalidation」)で、「Search Keys」セクションを使用します。Oracle Web Cache Managerの使用方法は、第7.7.2項を参照してください。

- XML手動無効化リクエストにOTHER要素を指定してADVANCEDSELECTOR要素を使用し、NAME属性とVALUE属性を指定してSEARCHKEYと検索キーの値をそれぞれ使用します。第7.5.1項を参照してください。

- ESIによるインライン無効化の場合は、OTHER要素を持つ<esi:invalidate>タグを指定してADVANCEDSELECTOR要素を使用し、NAME属性とVALUE属性を指定してSEARCHKEYと検索キーの値をそれぞれ使用します。第11.4.6項を参照してください。

- レスポンス・ヘッダーによる無効化の場合は、S_KEYオプション・ディレクティブを指定します。第7.8項を参照してください。

7.10 セキュリティに関する考慮事項

この項では、次の項目について説明します。

- 第7.10.1項「invalidatorアカウントについて」

- 第7.10.2項「無効化メッセージの伝播」

7.10.1 invalidatorアカウントについて

キャッシュ内のオブジェクトを無効化するには、無効化リスニング・ポートを介してinvalidatorアカウントからHTTP POSTリクエストを送信します。

invalidatorアカウントは、無効化リクエストの送信を許可された管理者です。パスワード・セキュリティの構成の詳細は、第5.2項を参照してください。

7.10.2 無効化メッセージの伝播

Oracle Web Cacheサーバー間での無効化メッセージの伝播は、次のような配置において行われます。

- 複数のOracle Web Cacheサーバーからなるキャッシュ・クラスタ

- あるOracle Web Cacheサーバーが別のOracle Web Cacheサーバーのオリジン・サーバーとして動作するキャッシュ階層

7.10.2.1 キャッシュ・クラスタ内での無効化処理

キャッシュ・クラスタでは、管理者が無効化メッセージをすべてのキャッシュ・クラスタ・メンバーに伝播するか、キャッシュ・クラスタの各メンバーに個別に送信するかを選択できます。

Oracle Web Cacheが無効化メッセージを伝播すると、無効化リクエストを受信したキャッシュは、そのリクエストの無効化コーディネータとして動作します。コーディネータは無効化メッセージを他のクラスタ・メンバーに伝播します。そして、コーディネータはすべてのクラスタ・メンバーからレスポンスが返されるのを待ちます。伝播が完了すると、コーディネータは各クラスタ・メンバーのメンバー名、無効化リクエストのステータス、無効になったオブジェクトの数を示すメッセージを送信元に返します。

通信できないクラスタ・メンバーがある場合には、Oracle Web Cacheからエラー・メッセージが返され、無効化メッセージは伝播されません。

キャッシュ・クラスタのアップグレード時には、キャッシュ・クラスタ・メンバーを1つずつアップグレードします。キャッシュはリクエストに応答し続けます。ただし、その他のクラスタ・メンバーの構成のバージョンが異なるため、キャッシュは、異なるバージョンで動作しているキャッシュ・クラスタ・メンバーには無効化メッセージを転送しません。かわりに、リクエストされたオブジェクトがこのキャッシュか、構成のバージョンが同じクラスタ・メンバーによってキャッシュされない場合、Oracle Web Cacheはリクエストをオリジン・サーバーに転送します。

キャッシュ・クラスタ・メンバーが実行しているOracle Web Cacheのリリースが異なっても、オブジェクトを無効化し、無効化をその他のクラスタ・メンバーに伝播できますが、無効化メッセージは旧リリースのOracle Web Cacheで動作しているキャッシュから送信される必要があります。

キャッシュ・クラスタ・メンバーのアップグレードなど、11g リリース1(11.1.1)へのOracle Web Cacheのアップグレードの詳細は、Oracle Fusion Middlewareアップグレード・プランニング・ガイドを参照してください。

7.10.2.2 階層内での無効化

Oracle Web Cacheサーバーが階層化された構成(キャッシュ階層)をとっている場合、コンテンツが複数のサーバーでキャッシュされることもあります。

図7-2に分散キャッシュ階層を示します。この例では、集中キャッシュが米国のオフィスに配置され、リモート・キャッシュが日本のオフィスに配置されています。集中キャッシュはWebアプリケーション・サーバーからコンテンツを格納し、リモート・キャッシュは集中キャッシュからコンテンツを格納します。すなわち、集中キャッシュは、日本のリモート・キャッシュに対してオリジン・サーバーとして動作します。

集中キャッシュは、リモートまたはサブスクライバOracle Web Cacheサーバーのinvalidatorアカウント名とパスワードを使用します。無効化リクエストは、無効にするオブジェクトおよびオブジェクトのサイト・ホスト名を指定します。サイト・ホスト名は、無効化リクエストの伝播元であるキャッシュのIPアドレスと比較されます。一致した場合、キャッシュは無効化リクエストを処理します。一致しなかった場合、リクエストは拒否されます。

無効化メッセージを自動伝播する場合、Oracle Web Cacheは、階層登録プロセスにおいて、集中キャッシュとリモート・キャッシュの間のページ・リクエストの中でエンコードされたinvalidatorパスワードを渡します。このHTTP通信は、ネットワーク傍受を受ける可能性が高くなります。保護されていない、セキュアでないネットワークの場合は、HTTPSポートを次のように構成してください。

- デフォルトのHTTPポートを無効化し、かわりに集中キャッシュ用のHTTPSポートを構成します。第5.4.2項を参照してください。

- 無効化用のデフォルトのHTTPポートを無効にし、かわりにリモート・キャッシュ用のHTTPSポートを構成します。第5.5.1項を参照してください。

コンテンツのリフレッシュのために、無効化メッセージが集中キャッシュに送信されると、一貫性を維持するために、無効化メッセージが集中キャッシュから日本のリモート・キャッシュに自動的に伝播されます。

図7-2 分散キャッシュ階層内でのコンテンツの無効化

「図7-2 分散キャッシュ階層内でのコンテンツの無効化」の説明

集中キャッシュが該当コンテンツのみを無効にするように、リモート・キャッシュは、無効化メッセージの伝播元である集中キャッシュのIPアドレスを使用して、無効化メッセージに指定されているサイト・ホスト名を確認します。一致した場合、リモート・キャッシュは無効化リクエストを処理します。一致しなかった場合、リクエストは拒否されます。集中キャッシュおよびリモート・キャッシュのサイト・ホスト名は一意になるように構成し、不一致が発生しないようにする必要があります。

キャッシュ階層の構成方法は、第10.2項を参照してください。

8 診断機能の使用方法

この章では、Oracle Web Cache付属の診断機能について説明します。

この章の項目は次のとおりです。

- 第8.1項「診断ソリューションの概要」

- 第8.2項「ポピュラーなリクエストとキャッシュの内容のリスト表示の概要」

- 第8.3項「HTMLボディまたはServerレスポンス・ヘッダー・フィールドでの診断情報とイベント・ログ情報の表示の概要」

- 第8.4項「一般統計および詳細な統計の表示」

- 第8.5項「構成統計の表示」

- 第8.6項「ポピュラーなリクエストのリスト表示」

- 第8.7項「ファイルへのキャッシュの内容のリスト出力」

- 第8.8項「診断情報の表示場所の構成」

8.1 診断ソリューションの概要

Oracle Web Cacheでは、パフォーマンスと最適な構成設定を評価するための各種診断ツールを提供しています。次のようなツールがあります。

- ポピュラーなリクエストのレポート。第8.2項を参照してください。

- Fusion Middleware Controlによる各種レベルの統計監視。第8.4項および第8.5項を参照してください。

- 診断情報を、Serverレスポンス・ヘッダー・フィールドに表示するか、テキスト文字列としてHTMLレスポンス・ボディに表示。第8.3項を参照してください。

8.2 ポピュラーなリクエストとキャッシュの内容のリスト表示の概要

最もポピュラーなリクエストとキャッシュの内容のリストのみでなく、キャッシュにないリクエストも表示できます。次のタイプのリストが作成されます。

- キャッシュが最後に開始された後にキャッシュが受信した最もポピュラーなリクエストのURLのリスト。
ポピュラー度の計算は、リクエスト回数とリクエスト時期の2つの要因を使用して行われます。キャッシュに格納されているオブジェクトのみ、キャッシュに格納されていないオブジェクトのみ、またはキャッシュが受信したすべてのリクエストを指定できます。第8.6項を参照してください。

- キャッシュに格納されていないオブジェクトのリクエストURLのリスト。
このリストは、キャッシュ・ルールが正しいオブジェクトをキャッシュしているかどうかの確認に使用できます。第8.6項を参照してください。

- エクスポート・ファイルに対する、オブジェクトのキャッシュされたURLまたはキャッシュされていないURLのリスト。
Oracle Web Cacheは、キャッシュの内容のリストをファイルに書き込むことができます。第8.7項を参照してください。

8.3 HTMLボディまたはServerレスポンス・ヘッダー・フィールドでの診断情報とイベント・ログ情報の表示の概要

デフォルトで、Oracle Web Cacheは診断情報をServerレスポンス・ヘッダー・フィールドに追加します。診断用に、この情報をテキスト文字列としてオブジェクトのHTMLレスポンス・ボディに表示すると便利です。有効な場合、文字列をオブジェクトのURLに追加し、レスポンス・ボディに埋め込まれた診断情報の文字列をブラウザに表示するのみです。

Web Cache Debug Info: diagnostic_information

HTMLレスポンスに「TRACE」の冗長レベルを持つイベント・ログ情報を表示する選択もできます。

また、Content-Type: text/htmlレスポンス・ヘッダー・フィールドを持つページのHTMLコメント・タグ内に診断情報を設定することもできます。有効な場合、診断情報はHTMLコメント・タグに表示されます。

<!-- Web Cache Debug Info: diagnostic_information-->

Oracle Web Cacheにより、ブラウザに送信されるオブジェクトに対して、HTTPレスポンス・メッセージのServerレスポンス・ヘッダー・フィールドに次の診断情報が追加されます。

Server: Oracle Fusion Middleware 11g (multiple_version_object_version_number) Server_header_from_origin_server Oracle-Web-Cache-11g/11.1.1.0.0 (diagnostic_information)

Serverレスポンス・ヘッダー・フィールドには、Oracle HTTP ServerおよびOracle Web Cacheの名前/値ペアを指定します。Oracle Web Cacheの情報には、バージョンおよび診断情報が含まれます。

diagnostic_informationは、次の形式をとります。

{ESI_processing_type}{cache_request_type}[;max-age=expiration_time[+removal_time];age=object_age;]{ecid=request_ID,sequence_number}

表8-1に、各診断フィールドの説明を示します。

表8-1 Serverの制御ディレクティブ

制御ディレクティブ

説明

ESI_processing_type

ESI_processing_typeは次のとおりです。

- Tは、オブジェクトがESIテンプレートであることを表します。

- Fは、オブジェクトがESIフラグメントであることを表します。

- 空の場合は、レスポンスがESIの処理を必要としないことを表します。

cache_request_type

cache_request_typeは次のとおりです。

- Hは、キャッシュ・ヒットを表します。

- Sは、失効しているオブジェクトに対するキャッシュ・ヒットを表します。

- Uは、失効しているオブジェクトに対するキャッシュの更新を表します。

- Gは、削除のマークが付けられた後も、物理的にはまだキャッシュ内に存在しているオブジェクトに対するキャッシュの更新を表します。

- Mは、キャッシュ・ミスを表します。

- Nは、キャッシュ不可のドキュメントに対するキャッシュ・ミスを表します。

max-age="expiration_time[+removal_time]

オブジェクトが期限切れになるまでの時間(秒)を指定します。オプションとして、期限切れになったオブジェクトがキャッシュから削除されるまでの時間(秒)を指定することもできます。cache_request_typeがNの場合、max_ageは表示されません。

age=object_age

オブジェクトがキャッシュ内に格納されてからの経過時間(秒)を表します。オブジェクトがキャッシュ不可の場合、ageは表示されません。

ecid=request_ID, sequence_number

Oracle-ECIDリクエスト・ヘッダーに指定したリクエストIDと順序番号を指定します。

Serverレスポンス・ヘッダー情報により、リクエストがキャッシュまたはオリジン・サーバーのどちらで処理されたのかがわかります。次に示すServerフィールドの例では、オブジェクトがキャッシュ・ヒットであったことを表しています。

Server: Oracle Fusion Middleware 11g (11.1.1.0.0) Oracle-HTTP-Server
Oracle-Web-Cache-11g/11.1.1.0.0 (TH;max-age=60+30;age=55;ecid=23248098121,0)

(TH;max-age=60+30;age=55;ecid=23248098121,0)が診断情報です。

- Tは、このページがESIで構成されていることを表します。

- Hは、このリクエストがキャッシュ・ヒットになったことを表します。

- max-age=60+30は、このオブジェクトがキャッシュに格納されてから60秒後に期限切れとなり、期限切れになってから30秒後にキャッシュから削除されることを表しています。つまり、このオブジェクトはキャッシュに格納されてから、合計で90秒間存在することになります。

- age=55は、キャッシュに格納されてから55秒経過したことを表します。つまり、期限切れになるまで残り5秒、削除されるまで残り35秒ということになります。

- ecid=23248098121,0は、Oracle-ECIDリクエスト・ヘッダーのリクエストIDと順序番号を指定します。

Serverレスポンス・ヘッダーをアクセス・ログに表示するには、sc(Server)フィールドを選択します。ユーザー定義のアクセス・ログの形式でsc(Server)フィールドを設定する必要があります。

詳細は、次を参照してください。

- sc(Server)フィールドを組み込むユーザー定義のアクセス・ログの形式を作成する方法の詳細は、第9.4項を参照してください。

- 診断情報の表示の構成は、第8.8項を参照してください。

8.4 一般統計および詳細な統計の表示

一般統計を表示するには、「Webキャッシュ・メンバー」ページにナビゲートします。「Webキャッシュ・メンバー」ページで提供される統計の詳細は、第2.6.3項を参照してください。

特定のキャッシュ・インスタンスの詳細な統計も表示できます。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「監視」→「パフォーマンス・サマリー」を選択します。
「パフォーマンス・サマリー」ページがパフォーマンス・メトリックとともに表示されます。

3. 別のメトリックを表示するには、「メトリック・パレットの表示」をクリックしてメトリックのカテゴリを開きます。
次の図は、「メトリック・パレット」が表示された「パフォーマンス・サマリー」ページを示しています。

図perform.gifの説明

4. 追加のメトリックを選択し、「パフォーマンス・サマリー」に追加します。
パフォーマンス・メトリックの定義、およびメトリックが範囲外のときに実行する必要があるアクションの情報を取得するには、メトリックの名前を右クリックし、コンテキスト・メニューの「ヘルプ」を選択します。

メトリックを監視した後、別のパフォーマンス・メトリックが必要な場合は、ブラウザで次のURLにアクセスします。

http://web_cache_hostname:stat_port

このURLによって表示される「Oracle Web Cache Internal Diagnosability Monitor」には、キャッシュ・ヒットとキャッシュ・ミスに関する追加情報が表示されます。統計監視ポートを確認する方法の詳細は、第2.11.1項を参照してください。

8.5 構成統計の表示

表8-2に、構成したルールの有効性を評価する場合の情報の参照先を示します。

表8-2 構成統計

統計のタイプ

関連項目

リクエスト・フィルタとルール

第4.13項

キャッシュ・ルール

第6.9項

8.6 ポピュラーなリクエストのリスト表示

最もポピュラーなリクエストを評価することにより、キャッシュ・ルールが正しいオブジェクトをキャッシュしているかどうか判断できる点については、第8.2項を参照してください。

最もポピュラーなリクエストのURLのリストを表示するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「監視」→「ポピュラーなリクエスト」を選択します。
「ポピュラーなリクエスト」ページが表示されます。

3. 「ポピュラーなリクエストの表示」リストから、オプションを選択します。

- すべて: キャッシュが受信したすべてのリクエストを表示します。

- キャッシュされたポピュラーなリクエスト: キャッシュに格納されているリクエストのみを表示します。

- キャッシュされていないポピュラーなリクエスト: キャッシュに格納されていないリクエストのみを表示します。

4. 「ポピュラーなリクエストの数」に、表示するURLの最大数を入力します。

5. 「実行」をクリックします。
キャッシュが最後に開始された後のリクエストのURLリストを含む表が表示されます。この表にはリクエストごとに次の列が含まれます。

- サイト: リクエストされたサイト名が表示されます。

- HTTPメソッド: リクエストで、GETメソッド、問合せ文字列を含むGETメソッドまたはPOST HTTPリクエスト・メソッドを使用しているかどうかが表示されます。

- URL: オブジェクトのURLが表示されます。URLには、Cookieやセッションの情報などの追加情報が含まれることがあります。

- POST本体: POST本体の内容が表示されます。

- キャッシュ済ですか。: オブジェクトがキャッシュされているかどうかが表示されます。次の値が可能です。

- はい: オブジェクトはキャッシュされています。

- はい、ただし期限が切れています: オブジェクトはキャッシュされていますが、期限切れです。(無効化および有効期限がパフォーマンスに与える影響を抑えるために、Oracle Web Cacheは、一部の期限切れオブジェクトを、オリジン・サーバーがそれらをリフレッシュできるようになるまで供給します。)

- はい。ただし検証が必要です。: オブジェクトはキャッシュされていますが、キャッシュで処理するにはオリジン・サーバーによる検証が必要です。検証は、キャッシュされたオブジェクトの固有のバリデータを使用して、Oracle Web Cacheからオリジン・サーバーに単純な条件付きリクエストを送信することによって行われます。

- いいえ: オブジェクトはキャッシュされていません。

- キャッシュの理由: オブジェクトがキャッシュされた理由またはキャッシュされなかった理由を示します。可能な値は次のとおりです。

- ACLドキュメント: オブジェクトが、アクセス制御リスト(ACL)保護ページへのユーザー アクセスを許可するためのACLドキュメントであるため、キャッシュされたか、またはキャッシュされませんでした。

- キャッシュ・ルールごと: キャッシュ・ルールに従ってキャッシュされました。または、キャッシュ・ルールに従ってキャッシュされませんでした。

- ETagレスポンス・ヘッダーごと: ETagレスポンス・ヘッダーによってキャッシュされたか、またはキャッシュされませんでした。

- HTTPヘッダーごと: HTTPヘッダーの情報によってキャッシュされたか、キャッシュされませんでした。

- HTTPレスポンス・コードごと: HTTPレスポンス・コードによってキャッシュされたか、またはキャッシュされませんでした。通常、キャッシュ・ルールで明示的に許可することによって、200でないレスポンス・コードはキャッシュされず、200以外のレスポンスはキャッシュされます。

- ESIタグの参照TTLごと: ESIタグで指定された参照TTL(TTLパラメータ)の値が0(ゼロ)以外であるため、キャッシュされたか、またはキャッシュされませんでした。

- Surrogate-Controlレスポンス・ヘッダーごと: Surrogate-Controlレスポンス・ヘッダーの情報によってキャッシュされたか、またはキャッシュされませんでした。

- X-Oracle-Cacheレスポンス・ヘッダーごと: X-Oracle-Cacheレスポンス・ヘッダーの情報によってキャッシュされたか、またはキャッシュされませんでした。

- Cookieが一致しません: リクエストに存在しないCookieまたはリクエスト内の同じCookieとは異なる値を持つCookieがレスポンスに含まれているため、キャッシュされたか、またはキャッシュされませんでした。

- ディレクティブまたはルールがありません: ディレクティブまたはルールに、オブジェクトのキャッシュが必要であることが記述されていないため、キャッシュされたか、またはキャッシュされませんでした。

- GETメソッドまたはPOSTメソッドではありません: オブジェクトがGETメソッドまたはPOSTメソッドではなかったため、キャッシュされませんでした。

- オブジェクトは大きすぎます: オブジェクトが、「リソース制限とタイムアウト」ページで「単一のキャッシュ・オブジェクトの最大サイズ」として指定されているサイズよりも大きいため、キャッシュされません。

- POST本体が大きすぎます: POST本体がキャッシュするには大きすぎたため、キャッシュされたか、またはキャッシュされませんでした。

- URLに問合せ文字列が含まれています: リクエストに問合せ文字列が含まれていますが、リクエストがどのキャッシュ・ルールにも一致しなかったため、キャッシュされたか、またはキャッシュされませんでした。

- サイズ: リクエストされたオブジェクトのサイズが表示されます。サイズは、バイト、KBまたはMBで表されます。

- 圧縮済ですか。: オブジェクトが圧縮された理由、または圧縮されなかった理由が表示されます。

- はい。キャッシュ・ルールごと: オブジェクトは、圧縮を有効または無効にしたキャッシュ・ルールに一致したため、圧縮されました。

- はい。MIMEタイプごと: オブジェクトのMIMEコンテンツ・タイプによって圧縮されました。

- いいえ。デフォルト設定ごと: サイトで圧縮は有効であり、ブラウザはGZIP圧縮レスポンスを使用できますが、一致するキャッシュ・ルールがなく、レスポンスのSurrogate-Controlレスポンス・ヘッダーにはcompressコントロール・ヘッダーまたはMIMEタイプが含まれていません。

- はい。Surrogate-Controlヘッダーごと: Surrogate-Controlレスポンス・ヘッダー内のcompress制御ディレクティブの設定によって、圧縮されたか、または圧縮されませんでした。

- はい。キャッシュ・ルールごと: オブジェクトは、圧縮を有効または無効にしたキャッシュ・ルールに一致したため、圧縮されたか、圧縮されませんでした。

- いいえ。MIMEタイプごと: オブジェクトのMIMEコンテンツ・タイプによって圧縮されませんでした。

- いいえ。デフォルト設定ごと: サイトで圧縮は有効であり、ブラウザはGZIP圧縮レスポンスを使用できますが、一致するキャッシュ・ルールがなく、レスポンスのSurrogate-Controlレスポンス・ヘッダーにはcompressコントロール・ヘッダーまたはMIMEタイプが含まれていません。Oracle Web Cacheで圧縮が自動的に無効になる場合については、第1.2.5項を参照してください。

- いいえ。Surrogate-Controlヘッダーごと: Surrogate-Controlレスポンス・ヘッダー内のcompress制御ディレクティブの設定によって圧縮されませんでした。

- いいえ。制限付きブラウザ・サポート: クライアントのブラウザにバグがあり、圧縮オブジェクトを受信できないため、圧縮されませんでした。

- いいえ。Webキャッシュ処理が必要です: オブジェクトの解析およびタグ処理が必要なため、圧縮されませんでした。たとえば、ESIタグを含むオブジェクトを処理してからでないと、キャッシュ・ヒットは発生しません。

- いいえ。ブラウザ機能: クライアントのブラウザがOracle Web Cacheに対してGZIP圧縮レスポンスを処理できることを示さなかったため、圧縮されませんでした。したがって、Oracle Web Cacheはこのブラウザに送信されるレスポンスを圧縮しません。

- いいえ。サイトでは無効です: 圧縮がサイト全体で無効になっていたため圧縮されませんでした。サイトに対して圧縮を有効にするには、第2.11.3項を参照してください。

- いいえ。オブジェクトが小さすぎます: オブジェクトは、圧縮することで効果が得られる23バイトより小さかったため、圧縮されませんでした。

- いいえ。ルーティング専用モードです: webcache.xmlファイルでROUTINGONLY属性がYESに設定されているため、圧縮されませんでした。この属性の詳細は、第3.8項を参照してください。

8.7 ファイルへのキャッシュの内容のリスト出力

キャッシュに現在格納されているすべてのオブジェクトのURLリストをwebache_contents.txtというファイルに生成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「監視」→「ポピュラーなリクエスト」を選択します。
「ポピュラーなリクエスト」ページが表示されます。

3. 「ポピュラーなリクエストのフィルタ条件」リストから、オプションを選択します。

- すべて: キャッシュが受信したすべてのリクエストを表示します。

- キャッシュされたポピュラーなリクエスト: キャッシュに格納されているリクエストのみを表示します。

- キャッシュされていないポピュラーなリクエスト: キャッシュに格納されていないリクエストのみを表示します。

4. 「ポピュラーなリクエストの数」に、表示するURLの最大数を入力します。

5. 「エクスポート・ファイル」をクリックします。

6. メッセージ・ダイアログで、「OK」をクリックしてコンテンツをエクスポートします。
次のディレクトリにあるwebcache_contents.txtにURLのリストが書き込まれます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

リストを生成するたびに、Oracle Web Cacheは、データを既存のファイルへ追加します。データをファイルに追加した日付と、その後に現在キャッシュされているオブジェクトのURLがリストされます。次の例はwebcache_contents.txtファイルの抜粋です。

Cache Contents at Wed Oct 20 11:47:03 2008
www.company.com:80/images/lnav/lnav_products.gif
www.company.com:80/images/rnav/rnav_red_line_1.gif
www.company.com:80/images/bullets_and_symbols/blk_line_bullet_10.gif
.
.
.
Cache Contents at Wed Oct 25 13:01:24 2008
www.company.com:80/images/white_spacer_xp.gif
www.company.com:80/images/white_spacer.gif
www.company.com:80/images/miniappsnet.gif
.
.
.

8.8 診断情報の表示場所の構成

Oracle Web Cacheが診断情報をServerレスポンス・ヘッダー・フィールドに追加、またはオブジェクトのHTMLレスポンス・ボディにテキスト文字列として追加する方法については、第8.3項を参照してください。

診断情報をServerレスポンス・ヘッダー・フィールドまたはHTMLレスポンス・ボディに設定するには、次の手順を実行します。

1. Oracle Web Cache Managerのナビゲータ・フレームで、「Logging and Diagnostics」→「Diagnostics」を選択します。第2.7.2項を参照してください。

2. 「Cache-Specific Page Body Diagnostics」表でキャッシュを選択し、HTMLレスポンス・ボディに診断情報を表示する場合は「Enable」を、診断情報の表示を無効にする場合は「Disable」をクリックします。

3. HTMLレスポンス・ボディに診断設定値を設定するには、次の手順を実行します。

1. 「Global Page Body Diagnostics Configuration」表から、「Edit」をクリックします。
「Edit Global Page Body Diagnostics Configuration」ダイアログ・ボックスが表示されます。

2. 「URL Flag」フィールドに、オブジェクトのURLに追加する文字列を入力します。
デフォルトでは、文字列は+wcdebugに設定されています。

3. 「Display Event Log Entries for Request」フィールドで、HTMLレスポンス・ボディに診断情報とTRACEイベント・ログのエントリを表示する場合は「Yes」を選択し、診断情報のみを表示する場合は「No」を選択します。

4. 「Submit」をクリックします。

4. Serverレスポンス・ヘッダーの診断設定値を有効または無効にする場合は、「Global Server Header Diagnostics」表で、「Enable」または「Disable」をクリックします。

5. 「Apply Changes」をクリックします。

9 ロギング

Oracle Web Cacheのロギング機能を使用すると、Oracle Web Cacheおよび関連プロセスの実行中および使用中に発生した問題をトラブルシューティングすることができます。

この章の項目は次のとおりです。

- 第9.1項「イベント・ログの概要」

- 第9.2項「アクセス・ログの概要」

- 第9.3項「イベント・ログの構成」

- 第9.4項「アクセス・ログの構成」

- 第9.5項「カスタマイズされたアクセス・ログ形式の作成」

- 第9.6項「カスタマイズされたアクセス・ログのロールオーバー・ポリシーの作成」

- 第9.7項「イベント・ログとアクセス・ログの表示」

- 第9.8項「イベント・ログとアクセス・ログのロールオーバー」

- 第9.9項「監査ログの使用方法」

9.1 イベント・ログの概要

Oracle Web Cacheは、イベントとエラーの情報をイベント・ログに記録します。イベント・ログ・エントリは、キャッシュに格納されたオブジェクトの判別に役立つとともに、キャッシュに関するすべての問題を通知します。デフォルトでは、Oracle Web Cacheは各リクエストに関連付けられている、メモリー内のすべてのイベント・ログ・メッセージを収集します。リクエストの最も重大なメッセージが、選択されている冗長性レベルと同じかそれ以上の場合、Oracle Web Cacheはそのリクエストに関連するすべてのメッセージをイベント・ログに一度に書き込みます。診断が容易なように、1つのリクエストに対するメッセージがグループ化されログ・ファイル内に集められます。

イベント・ログのデフォルトのファイル名は、Oracle Web Cache形式およびOracle Diagnostic Logging(ODL)Text形式ではevent_logとなり、ODL XML形式ではlog.xmlとなります。Oracle Web Cacheは、ログ・ファイルを次のディレクトリに格納します。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

この項では、次の項目について説明します。

- 第9.1.1項「イベント・ロギング形式」

- 第9.1.2項「イベント・ログの例」

9.1.1 イベント・ロギング形式

イベント・ログの設定を構成するときに、次のロギング形式を選択します。

- 第9.1.1.1項「Oracle Diagnostics LoggingのText形式およびXML形式」

- 第9.1.1.2項「Oracle Web Cacheのクラシック形式」

9.1.1.1 Oracle Diagnostics LoggingのText形式およびXML形式

Oracle Diagnostic Logging(ODL)形式は、すべての診断メッセージとログ・ファイルの共通形式であり、Oracle Fusion Middlewareの様々なコンポーネントの診断メッセージを関係付けるメカニズムです。

ODL Textを選択するとテキスト・ファイルを作成でき、ODL XMLを選択するとXMLファイルを作成できます。

ODL Textの形式は次のとおりです。

[TSTZ_ORIGINATING] [MSG_TYPE:MSG_ID] [MODULE_ID;MSG_LEVEL] [MODULE_ID] [ECID] MSG_TEXT

表9-4に、ODL Text形式の各フィールドを示します。

表9-1 ODL Textのメッセージ・フィールド

フィールド

説明

TSTZ_ORIGINATING

メッセージが生成された日付と時刻。時間は、ローカル・タイムまたはグリニッジ標準時のいずれかで表示されます。

MSG_TYPE

メッセージのタイプ。可能な値はNOTIFICATION、WARNING、TRACEおよびDEBUGです。

MSG_LEVEL

メッセージ・レベルは、メッセージ・タイプを限定する整数値で示されます。使用可能な値は1(最高重大度)から32(最低重大度)です。

MSG_ID

コンポーネント内でメッセージを一意に識別するID。コンポーネントを表す接頭辞、ダッシュおよび5桁の数字で構成されます。例: WXE-08513

メッセージの詳細は、Oracle Fusion Middlewareのエラー・メッセージ・リファレンスを参照してください。

MODULE_ID

メッセージを送信したモジュールのID。コンポーネントが単一のモジュールである場合は、この属性にコンポーネントIDが示されます。

ECID

実行コンテキストID(ECID)。生成コンポーネントが関与する特定のリクエストの実行のグローバル一意識別子。ECIDは、別のコンポーネントで発生したエラー・メッセージの関連付けに使用できます。

関連項目: Oracle-ECIDリクエスト・ヘッダーの詳細は、第9.1.1.4項を参照してください。

MSG_TEXT

エラー・メッセージのテキスト。

次に、ODL Text形式が含まれているイベント・ログの抜粋を示します。

[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-08513] [logging] [ecid: ] Cache server process ID 11679 is starting up.
[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-09612] [main] [ecid: ] Oracle Web Cache 11g (11.1.1)
[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-13002] [config] [ecid: ] Maximum allowed incoming connections are 700
[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-09446] [stats] [ecid: ] Statistics initialization commencing.
[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-09441] [stats] [ecid: ] DMS enabled
[2008-11-04T05:55:35-05:00] [webcache] [NOTIFICATION:1] [WXE-09447] [stats] [ecid: ] Statistics initialization complete.
[2008-11-04T05:55:36-05:00] [webcache] [NOTIFICATION:1] [WXE-12209] [cluster] [ecid: ] A 1 node cluster successfully initialized
[2008-11-04T05:55:36-05:00] [webcache] [NOTIFICATION:1] [WXE-09614] [main] [ecid: ] The following Oracle Web Cache internal files are pre-populated to the cache: [[/host:port/_oracle_http_server_webcache_static_.html]]

表9-2に、ODL XML形式の各フィールドを示します。

表9-2 ODL XMLのメッセージ・フィールド

フィールド

説明

TSTZ_ORIGINATING

メッセージが生成された日付と時刻。時間は、ローカル・タイムまたはグリニッジ標準時のいずれかで表示されます。

COMPONENT_ID

メッセージの発生元コンポーネントのID。

MSG_ID

コンポーネント内でメッセージを一意に識別するID。コンポーネントを表す接頭辞、ダッシュおよび5桁の数字で構成されます。例: WXE-08513

MSG_TYPE

メッセージのタイプ。可能な値はNOTIFICATION、WARNING、TRACEおよびDEBUGです。

MSG_LEVEL

メッセージ・レベルは、メッセージ・タイプを限定する整数値で示されます。使用可能な値は1(最高重大度)から32(最低重大度)です。

HOST_ID

メッセージの発生元ホストの名前。

HOST_NWADDR

メッセージの発生元ホストのネットワーク・アドレス。

MODULE_ID

メッセージを送信したモジュールのID。コンポーネントが単一のモジュールである場合は、この属性にコンポーネントIDが示されます。

ECID

実行コンテキストID(ECID)。生成コンポーネントが関与する特定のリクエストの実行のグローバル一意識別子。ECIDは、別のコンポーネントで発生したエラー・メッセージの関連付けに使用できます。

関連項目: Oracle-ECIDリクエスト・ヘッダーの詳細は、第9.1.1.4項を参照してください。

MSG_TEXT

エラー・メッセージのテキスト。

ODL XML形式にはほかにもフィールドがあります。次に、ODL XML形式のイベント・ログの抜粋を示します。

<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.0116-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>8513</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>logging</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Cache server process ID 13176 is starting up.
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.0117-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9612</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>main</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Oracle Web Cache 11g (11.1.1)
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.0118-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>13002</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>config</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Maximum allowed incoming connections are 700
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.0191-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9446</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>stats</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Statistics initialization commencing.
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.0265-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9438</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>stats</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>The statistics persistent repository is being reset by new configuration
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.1556-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9441</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>stats</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>DMS enabled
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.1559-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9447</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>stats</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Statistics initialization complete.
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:14.5912-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>12209</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>cluster</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>A 1 node cluster successfully initialized
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-11-04T06:07:20.8036-05:00</TSTZ_ORIGINATING>
<COMPONENT_ID>WXE</COMPONENT_ID>
<MSG_ID>9614</MSG_ID>
<MSG_TYPE TYPE="NOTIFICATION"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>host</HOST_ID>
<HOST_NWADDR>10.10.150.35</HOST_NWADDR>
<MODULE_ID>main</MODULE_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID>
<UNIQUE_ID>-</UNIQUE_ID>
<SEQ>0</SEQ>
</EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>The following Oracle Web Cache internal files are pre-populated to the cache: [[/host:port/_oracle_http_server_webcache_static_.html]]
</MSG_TEXT>  </PAYLOAD></MESSAGE>

ODL形式の詳細は、次を参照してください。

- ODLメッセージおよびODLログ・ファイルの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

- ログ・ファイルに書き込まれる情報量の構成については、『Oracle Fusion Middleware管理者ガイド』を参照してください。

9.1.1.2 Oracle Web Cacheのクラシック形式

Oracle Web Cacheログ形式は、これまでのOracle Web Cacheのリリースで提供されていた従来のログ形式を必要とする顧客向けです。

Oracle Web Cacheの形式は次のとおりです。

[TIMESTAMP] [MSG_TYPE MSG_ID] [ECID] MSG_TEXT

表9-3に、Oracle Web Cache形式の各フィールドを示します。

表9-3 Oracle Web Cacheのメッセージ・フィールド

フィールド

説明

TIMESTAMP

メッセージが生成された日付と時刻。時間は、ローカル・タイムまたはグリニッジ標準時のいずれかで表示されます。

MSG_TYPE

メッセージのタイプ。可能な値はNOTIFICATION、WARNING、TRACEおよびDEBUGです。

MSG_ID

コンポーネント内でメッセージを一意に識別するID。IDは5桁の数字で構成されます。例: 08513

ECID

実行コンテキストID(ECID)。生成コンポーネントが関与する特定のリクエストの実行のグローバル一意識別子。ECIDは、別のコンポーネントで発生したエラー・メッセージの関連付けに使用できます。

関連項目: Oracle-ECIDリクエスト・ヘッダーの詳細は、第9.1.1.4項を参照してください。

MSG_TEXT

エラー・メッセージのテキスト。

次に例を示します。

[04/Nov/2008:06:11:53 -0500] [notification 08513] Cache server process ID 13466is starting up.
[04/Nov/2008:06:11:53 -0500] [notification 09612] [ecid: -] Oracle Web Cache 11g (11.1.1)
[04/Nov/2008:06:11:53 -0500] [notification 13002] [ecid: -] Maximum allowed incoming connections are 700
[04/Nov/2008:06:11:53 -0500] [notification 09446] [ecid: -] Statistics initialization commencing.
[04/Nov/2008:06:11:53 -0500] [notification 09438] [ecid: -] The statistics persistent repository is being reset by new configuration
[04/Nov/2008:06:11:53 -0500] [notification 09441] [ecid: -] DMS enabled
[04/Nov/2008:06:11:53 -0500] [notification 09447] [ecid: -] Statistics initialization complete.
[04/Nov/2008:06:11:54 -0500] [notification 12209] [ecid: -] A 1 node cluster successfully initialized
[04/Nov/2008:06:11:54 -0500] [notification 09614] [ecid: -] The following Oracle Web Cache internal files are pre-populated to the cache: [[/host:port/_oracle_http_server_webcache_static_.html]]

9.1.1.3 メッセージ09720のリクエスト詳細

イベント・ログ・メッセージで「リクエストの詳細を含む」オプションを有効にすると、Oracle Web Cacheは、メッセージ09720にリクエスト詳細形式を表示します。このメッセージは、リクエストのイベントが初めてログに記録されるときに、クライアントIPアドレス、リクエストのサイト名、リクエストのURLを含む次のリクエスト詳細とともにログに記録されます。

表9-4に、リクエスト詳細形式の各フィールドを示します。

表9-4 リクエスト詳細

フィールド

説明

[detail]

リクエスト詳細イベント。

[client: IP_address]

リクエストを作成したクライアントのIPアドレス。

[host: site]

リクエストのサイト名。

[url: URL]

リクエストのURL。

次に例を示します。

[2008-11-20T23:27:32Z] [webcache] [TRACE:1] [WXE-09720] [io] [ecid: 15431471130,0] [req-info: ] [client: 140.87.8.166] [host: -] [url: /images/image1k.bmp]
[2008-11-20T23:27:31Z] [webcache] [TRACE:1] [WXE-11331] [frontend] [ecid: 15431471130,0] Request matches configured site: www.company.com:80
[2008-11-20T23:27:31Z] [webcache] [TRACE:1] [WXE-11414] [population] [ecid: 15431471130,0] Basic cache key is composed with sitename www.company.com:80, URI /images/image1k.bmp, method GET, post body -.
[2008-11-20T23:27:31Z] [webcache] [TRACE:1] [WXE-11304] [frontend] [ecid: 15431471130,0] Cache miss request.

リクエストのIPアドレス、サイト名およびURLに加えて、Oracle-ECIDリクエスト・ヘッダーのIDと順序番号がログに記録されます。Oracle-ECIDリクエスト・ヘッダーはリクエストのトラッキングに使用されます。

9.1.1.4 Oracle-ECIDリクエスト・ヘッダー・フィールドについて

Oracle-ECIDリクエスト・ヘッダーは、リクエストがOracle Fusion Middlewareアーキテクチャ内を移動するときに、その経由場所をトラッキングするために使用されます。この情報は、特に診断に役立ちます。Oracle Web Cacheは、クライアント・リクエストの最初の受信者であるため、オリジン・サーバーにキャッシュ・ミスを転送する前にリクエスト・ヘッダーを設定します。Oracle-ECIDリクエスト・ヘッダーの形式は次のとおりです。

Oracle-ECID: request_id, sequence_number

この形式のrequest_idはリクエストに対する64ビットの一意の整数、sequence_numberはOracle Fusion Middlewareを通過するときのリクエストのホップ番号です。Oracle Web Cacheは通常、最初の順序番号0(ゼロ)をリクエストに割り当てます。リクエストがOracle Web CacheからOracle Fusion Middlewareの他のコンポーネントに移るとき、リクエストIDは変わりませんが、順序番号は各ホップで増加します。

Oracle-ECIDリクエスト・ヘッダーのリクエストIDと順序番号をイベント・ログおよびアクセス・ログに記録するようにOracle Web Cacheを構成できます。Oracle-ECIDリクエスト・ヘッダーをイベント・ログに表示するには、「リクエストの詳細を含む」オプションを有効にし、アクセス・ログについてはx-ecidフィールドを選択します。デフォルトでは、x-ecidフィールドは拡張CLF(ECLF)、拡張複合ログ形式およびエンド・ユーザー・パフォーマンス監視の形式となります。さらに、Oracle-ECIDリクエスト・ヘッダーの情報をログに記録するようにOracle HTTP Serverを構成すると、同じリクエストに対する様々なOracle Fusion Middlewareの通過場所でのイベントを関連付けることができます。

Oracle Web Cacheでは、Serverレスポンス・ヘッダー・フィールドまたはHTMLレスポンス・ボディに診断情報を表示するように構成した場合も、Oracle-ECIDリクエスト・ヘッダー情報を記録します。

Serverレスポンス・ヘッダー・フィールドの診断出力、またはOracle-ECID情報が含まれるHTTPレスポンス・メッセージの構成方法の詳細は、第8.8項を参照してください。

9.1.2 イベント・ログの例

この項には、次のイベント・ログの例が含まれます。

- 第9.1.2.1項「例: 起動の失敗のエントリが含まれているイベント・ログ」

- 第9.1.2.2項「例: 停止エントリが含まれているイベント・ログ」

- 第9.1.2.3項「例: キャッシュ・ミスおよびキャッシュ・ヒットのエントリが含まれているイベント・ログ」

- 第9.1.2.4項「例: 無効化エントリが含まれているイベント・ログ」

- 第9.1.2.5項「例: ESIイベントの分析」

9.1.2.1 例: 起動の失敗のエントリが含まれているイベント・ログ

次に、起動の失敗のイベントが含まれているイベント・ログの抜粋を示します。ポート7777は使用されているため、Oracle Web Cacheはこのポートをリスニングできません。Oracle Web Cacheが稼働中でそのポートをリスニングしている場合、または別のアプリケーションによってそのポートが使用されている場合に、このエラーが発生する可能性があります。

[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-08513] [logging] [ecid: ] Cache server process ID 2427 is starting up.
[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-09612] [main]  [ecid: ] Oracle Web Cache 11g (11.1.1)
[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-13002] [config] [ecid: ] Maximum allowed incoming connections are 700
[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-09446] [stats]  [ecid: ] Statistics initialization commencing.
[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-09438] [stats]  [ecid: ] The statistics persistent repository is being reset by new configuration [2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-09441] [stats]  [ecid: ] DMS enabled
[2008-11-04T16:37:24-05:00] [webcache] [NOTIFICATION:1] [WXE-09447] [stats]  [ecid: ] Statistics initialization complete.
[2008-11-04T16:37:25-05:00] [webcache] [TRACE:1] [WXE-11366] [frontend] [ecid: ] A client connection to listening port 7777 is dropped.
[2008-11-04T16:37:25-05:00] [webcache] [TRACE:1] [WXE-11380] [frontend] [ecid: ] Network failure during client listen client listen (details: internal=failure system=2)
[2008-11-04T16:37:25-05:00] [webcache] [ERROR:1] [WXE-09707] [main] [ecid: ] Failed to start the server.
[2008-11-04T16:37:25-05:00] [webcache] [ERROR:1] [WXE-09609] [main] [ecid: ] The server process could not initialize.
[2008-11-04T16:37:25-05:00] [webcache] [NOTIFICATION:1] [WXE-09610] [main]  [ecid: ] The server is exiting.
[2008-11-04T16:37:25-05:00] [webcache] [NOTIFICATION:1] [WXE-08514] [logging] [ecid: ] Cache server process ID 2427 is shutting down.

9.1.2.2 例: 停止エントリが含まれているイベント・ログ

次に、通常の停止エントリが含まれているイベント・ログの抜粋を示します。

[2008-11-04T16:19:58-05:00] [webcache] [NOTIFICATION:1] [WXE-09703] [main]  [ecid: ] Stop Issued. The program will shut down after all accepted requests are served, or a timeout occurs.
[2008-11-04T16:21:29-05:00] [webcache] [NOTIFICATION:1] [WXE-09610] [main]  [ecid: ] The server is exiting.

9.1.2.3 例: キャッシュ・ミスおよびキャッシュ・ヒットのエントリが含まれているイベント・ログ

次に、キャッシュ・ミス・リクエストのイベントが含まれているイベント・ログの抜粋を示します。

[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11331] [frontend] [ecid: 5415484202,0] Request matches configured site: www.company.com:80
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11414] [population] [ecid: 5415484202,0] Basic cache key is composed with sitename www.company.com:80, URI /invalidate1/tcal_fct_invalidate_basic_2.html, method GET, post body -.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11304] [frontend] [ecid: 5415484202,0] Cache miss request.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11224] [os] [ecid: 5415484202,0] Site localhost:8888 matches site-to-server mapping www.company.com:80.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11227] [os] [ecid: 5415484202,0] Initial Request is routed to origin server host-server:8080 using load balancing.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11403] [population] [ecid: 5415484202,0]  begin cacheability decision for url: www.company.com:80/invalidate1/tcal_fct_invalidate_basic_2.html
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11481] [population] [ecid: 5415484202,0] Request/Response matches caching rule with URL expression "^/invalidate1/.*\.h.*$".
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-13736] [compression] [ecid: 5415484202,0] Compression is disabled because the browser does not support compression.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11446] [population] [ecid: 5415484202,0] URL which will be cached is: www.company.com:80/invalidate1/tcal_fct_invalidate_basic_2.html
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11415] [population] [ecid: 5415484202,0] Final cache key is composed sitename www.company.com:80, URI /invalidate1/tcal_fct_invalidate_basic_2.html, method GET, post body -, multiversion -, compressed no.
[2008-11-04T15:37:02-05:00] [webcache] [TRACE:1] [WXE-11088] [backend] [ecid: 5415484202,0] Following URL is now in cache: www.company.com:80/invalidate1/tcal_fct_invalidate_basic_2.html

次に、後続のキャッシュ・ヒット・リクエストのイベントが含まれているイベント・ログの抜粋を示します。

[2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-09720] [frontend] [ecid: 417732382502,0] [req-info: ] [client: 127.0.0.1] [host: www.company.com:80] [url: /x-oracle-cache-invalidate]
[2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-11331] [frontend] [ecid: 417732382502,0] Request matches configured site: localhost:8888 [2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-11414] [population] [ecid: 417732382502,0] Basic cache key is composed with sitename www.company.com:80, URI /invalidate1/tcal_fct_invalidate_basic_5.html, method GET, post body -.
[2008-11-04T15:37:39-05:00] [webcache] [NOTIFICATION:1] [WXE-11707] [invalidation] [ecid: 417732382502,0] Object with URL '/invalidate1/tcal_fct_invalidate_basic_5.html' is successfully invalidated.
[2008-11-04T15:37:39-05:00] [webcache] [NOTIFICATION:1] [WXE-11748] [invalidation] [ecid: 417732382502,0] Invalidation with INFO 'about-ttl' has returned with status 'SUCCESS'; number of objects invalidated: '1'.

9.1.2.4 例: 無効化エントリが含まれているイベント・ログ

次に、オブジェクト/invalidation1/tcal_fct_invalidate_basic_5.htmlの削除の無効化リクエストに関連するイベントが含まれているイベント・ログの抜粋を示します。

[2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-09720] [frontend] [ecid: 417732382502,0] [req-info: ] [client: 10.10.150.35] [host: host:port] [url: /x-oracle-cache-invalidate]
[2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-11331] [frontend] [ecid: 417732382502,0] Request matches configured site: www.company.com:80
[2008-11-04T15:37:39-05:00] [webcache] [TRACE:1] [WXE-11414] [population] [ecid: 417732382502,0] Basic cache key is composed with sitename localhost:8888, URI /invalidate1/tcal_fct_invalidate_basic_5.html, method GET, post body -.
[2008-11-04T15:37:39-05:00] [webcache] [NOTIFICATION:1] [WXE-11707] [invalidation] [ecid: 417732382502,0] Object with URL '/invalidate1/tcal_fct_invalidate_basic_5.html' is successfully invalidated.
[2008-11-04T15:37:39-05:00] [webcache] [NOTIFICATION:1] [WXE-11748] [invalidation] [ecid: 417732382502,0] Invalidation with INFO 'about-ttl' has returned with status 'SUCCESS'; number of objects invalidated: '1'.

9.1.2.5 例: ESIイベントの分析

次に、キャッシュ・ミスに関するESIフラグメントのイベント・ログ内のメッセージ例を示します。イベント・ログ内のメッセージでは、次の情報がレポートされます。

- テンプレートでのOracle Web CacheのESIの処理方法

- ESI処理でのESIフラグメントのロード方法

- フラグメントのロード後にESIフラグメントに対するキャッシュ・デシジョンが作成される方法。フラグメントをキャッシュするか否かの理由に関する情報も含まれます。

次の例で、TRACE:1メッセージはverbosity=TRACEレベル、TRACE:32メッセージはverbosity=DEBUGレベルに対応します。verbosity(冗長性)をDEBUGに設定すると、TRACE、NOTIFICATION、WARNING、ERRORの各レベルのメッセージが含められます。TRACEにはNOTIFICATION、WARNING、ERRORが含まれますが、DEBUGは含まれません。

event_logの冗長レベルをDEBUGに設定しないかぎり、次の例のようなログ・メッセージは表示されません。

[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11952] [esi] [ecid: 211577120190,0] Start processing ESI document www.company.com:80/cgi-bin/esi-headers.sh?/esi/esi-headers.html&localhost:8888, nesting level 1 [2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11331] [frontend] [ecid: 211577120190,0] Request matches configured site: www.company.com:80
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11953] [esi] [ecid: 211577120190,0] In ESI template www.company.com:80/cgi-bin/esi-headers.sh?/esi/esi-headers.html&localhost:8888, the fragment's site name and URL has been discovered as www.company.com:80 and /esi/include0.html [2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11304] [frontend] [ecid: 211577120190,0] Cache miss request.
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11224] [os] [ecid: 211577120190,0] Site www.company.com:80 matches site-to-server mapping www.company.com:80.
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11227] [os] [ecid: 211577120190,0] Initial Request is routed to origin server stadk61.us.oracle.com:8080 using load balancing.
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11403] [population] [ecid: 211577120190,0]  [[ begin cacheability decision for  url: www.company.com:80/esi/include0.html ]]
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11481] [population] [ecid: 211577120190,0] Request/Response matches caching rule with URL expression "/*". [2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11446] [population] [ecid: 211577120190,0]  [[ URL which will be cached is: www.company.com:80/esi/include0.html ]]
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11415] [population] [ecid: 211577120190,0] Final cache key is composed sitename www.company.com:80, URI /esi/include0.html, method GET, post body -, multiversion -, compressed no.
[2008-11-04T16:29:14-05:00] [webcache] [TRACE:1] [WXE-11088] [backend] [ecid: 211577120190,0]  [[ Following URL is now in cache: www.company.com:80/esi/include0.html ]]

9.2 アクセス・ログの概要

Oracle Web Cacheは、受信したHTTPリクエストおよびHTTPSリクエストに関する情報をアクセス・ログに記録します。Oracle Web Cacheで定義される各Webサイトは、各自のアクセス・ログを持つことができます。アクセス・ログのデフォルトのファイル名はaccess_logで、次のディレクトリに格納されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

この項では、次の項目について説明します。

- 第9.2.1項「アクセス・ログの形式」

- 第9.2.2項「アクセス・ログのフィールド」

- 第9.2.3項「アクセス・ログの例」

9.2.1 アクセス・ログの形式

アクセス・ログ・ファイルの内容を構成するには、各HTTPリクエスト・イベントに対して表示されるフィールドを定義します。これらのフィールドは、標準拡張ログ・ファイル形式(XLF)に基づいています。Oracle Web Cacheでは、デフォルトで次のアクセス・ログ形式がサポートされています。

- 第9.2.1.1項「共通ログ形式(CLF)」

- 第9.2.1.2項「拡張CLF(ECLF)」

- 第9.2.1.3項「複合ログ形式」

- 第9.2.1.4項「拡張複合ログ形式」

- 第9.2.1.5項「エンド・ユーザー・パフォーマンス監視の形式」

9.2.1.1 共通ログ形式(CLF)

この形式は、アクセス・ログに適用されるデフォルトの形式です。また、多くの構成に対して適切な形式です。CLF形式では、次のフィールドがサポートされます。

- c-ip

- x-log-id

- x-auth-id

- x-clf-date

- x-req-line

- sc-status

- bytes

9.2.1.2 拡張CLF(ECLF)

この形式では多数のCLFフィールドが使用され、Oracle-ECIDリクエスト・ヘッダーに指定したリクエストIDと順序番号をトラッキングするためのx-ecidフィールドが含まれます。

- c-ip

- x-log-id

- x-auth-id

- x-clf-date

- x-req-line

- sc-status

- bytes

- x-ecid

9.2.1.3 複合ログ形式

この形式では、CLFフィールドと、cs(Referer)およびcs(User-Agent)の追加フィールドがサポートされます。

- c-ip

- x-log-id

- x-auth-id

- x-clf-date

- x-req-line

- sc-status

- bytes

- cs(Referer)

- cs(User-Agent)

リクエストをOracle Web Cacheに転送する前に、リクエストを送信しているブラウザの種類とブラウザが訪問した場所を判別する必要がある場合は、この形式を選択します。

9.2.1.4 拡張複合ログ形式

この形式では多数の複合ログ形式フィールドが使用され、Oracle-ECIDリクエスト・ヘッダーに指定したIDをトラッキングするためのx-ecidフィールドが含まれます。

- c-ip

- x-log-id

- x-auth-id

- x-clf-date

- x-req-line

- sc-status

- bytes

- cs(Referer)

- cs(User-Agent)

- x-ecid

9.2.1.5 エンド・ユーザー・パフォーマンス監視の形式

この形式は、10gのエンド・ユーザーのパフォーマンス監視機能のために用意された次のフィールドをサポートしています。

- x-req-type

- x-date-start

- x-time-start

- c-ip

- s-ip

- x-auth-id

- cs(Host)

- cs-method

- cs-uri

- x-protocol

- sc-status

- bytes

- cs-bytes

- x-cache

- time-taken

- r-time-taken

- x-time-delay

- x-os-timeout

- x-ecid

- x-cookie(ORACLE_SMP_CHRONOS_ST)

- x-cookie(ORACLE_SMP_CHRONOS_LT)

- x-cookie(ORACLE_SMP_CHRONOS_GL)

- x-glcookie-set

- cs(Referer)

- cs(User-Agent)

- x-esi-info

- x-conn-abrt

- sc(Content-Type)

9.2.2 アクセス・ログのフィールド

デフォルトの形式が使用している環境に適していない場合は、必要なフィールドを指定することにより、カスタム・ログ形式を作成できます。表9-5に、サポートされているフィールドを示します。xまたはrの接頭辞を持つフィールドは、Oracle Web Cacheに固有のフィールドです。

表9-5 アクセス・ログのフィールド

フィールド

説明

bytes

リクエストのコンテンツの長さ。

c-ip

クライアントのIPアドレス。

cached

キャッシュのステータスを指定する整数。キャッシュのステータスは次のいずれかになります。

- 0はキャッシュ・ミスを表します。x-cacheフィールドのM、U、GおよびNの出力に相当します。

- 1は、失効しているオブジェクトに対するキャッシュ・ヒットを表します。x-cacheフィールドのS出力に相当します。

- 2は、キャッシュ・ヒットを表します。x-cacheフィールドのH出力に相当します。

cs(header_name)

クライアントから送信されたHTTPリクエスト・ヘッダー。

関連項目: 「cs(header_name)およびsc(header_name)アクセス・ログ・フィールド」

cs-bytes

クライアントから受信したバイト。

cs-method

クライアントからOracle Web CacheへのHTTPリクエスト・メソッド。

cs-uri

クライアントからOracle Web CacheへのURI

cs-uri-query

クライアントからOracle Web CacheへのURIの問合せ部分(ステムの部分は省略)。

cs-uri_stem

クライアントからOracle Web CacheへのURIのステム部分(問合せの部分は省略)。

date

トランザクションが完了した日付。次の書式で表示されます。

dd/Mon/yyyy

r-ip

オリジン・サーバーのIPアドレスとポート番号。キャッシュ・クラスタの場合、このフィールドには、キャッシュ・クラスタ内のピア・キャッシュのIPとポート番号が表示されます。この情報は、次の書式で表示されます。

IP_address:port

r-time-taken

Oracle Web Cacheとオリジン・サーバーまたはピア・キャッシュとの通信にかかった秒単位の時間(マイクロ秒も含む)。この時間は、次の2つのタイム・ポイント間の時間差です。

- Oracle Web Cacheがリクエストの最初のバイトをオリジン・サーバーまたはピア・キャッシュに送信した直前の時刻。

- レスポンスの最後のバイトをオリジン・サーバーまたはピア・キャッシュから受信した直後の時刻。

このフィールドは、エンド・ユーザーのパフォーマンス監視機能にタイム情報を提供する場合に便利です。

s-ip

Oracle Web CacheコンピュータのIPアドレス

sc(header_name)

Oracle Web Cacheからクライアントに送信されたHTTPレスポンス・ヘッダー

関連項目: 「cs(header_name)およびsc(header_name)アクセス・ログ・フィールド」

sc-status

Oracle Web Cache HTTPからクライアントへのHTTPステータス・コード。次のコードがあります。

- 1xxレンジ: 情報メッセージ。

- 2xxレンジ: 成功を示すメッセージ。

- 3xxレンジ: リダイレクションを示すメッセージ。リクエストを完了するには、他のアクションが必要です。

- 4xxレンジ: クライアント・エラーを示すメッセージ。

- 5xxレンジ: Oracle Web Cacheエラーを示すメッセージ。

関連項目: HTTPステータス・コードの詳細は、http://www.ietf.org/rfc/rfc2616.txtを参照してください。

time

Oracle Web Cacheからのレスポンスが完了した時刻。時刻は次の書式で表示されます。

hh:mm:ss

time-taken

トランザクションが完了するまでにかかった秒単位の時間(マイクロ秒も含む)。

x-auth-id

HTTPのBasic認証リクエストのユーザー名。

x-cache

キャッシュのステータス。キャッシュのステータスは次のいずれかになります。

- Hは、キャッシュ・ヒットを表します。

- Sは、失効しているオブジェクトに対するキャッシュ・ヒットを表します。

- Uは、失効しているオブジェクトに対するキャッシュの更新を表します。

- Gは、削除のマークが付けられた後も、物理的にはまだキャッシュ内に存在しているオブジェクトに対するキャッシュの更新を表します。

- Mは、キャッシュ可能なドキュメントに対するキャッシュ・ミスを表します。

- Nは、キャッシュ不可のドキュメントに対するキャッシュ・ミスを表します。

x-cache-detail

診断情報。次の形式で表示されます。

{ESI_processing_type}{cache_request_type} [;max-age=expiration_time[+removal_time];age=object_age]

ESI_processing_typeは次のとおりです。

- Tは、オブジェクトがESIテンプレートであることを表します。

- Fは、オブジェクトがESIフラグメントであることを表します。

- 空の場合は、レスポンスがESIの処理を必要としないことを表します。

cache_request_typeは次のとおりです。

- Hは、キャッシュ・ヒットを表します。

- Sは、失効しているオブジェクトに対するキャッシュ・ヒットを表します。

- Uは、失効しているオブジェクトに対するキャッシュの更新を表します。

- Gは、削除のマークが付けられた後も、物理的にはまだキャッシュ内に存在しているオブジェクトに対するキャッシュの更新を表します。

- Mは、キャッシュ可能なドキュメントに対するキャッシュ・ミスを表します。

- Nは、キャッシュ不可のドキュメントに対するキャッシュ・ミスを表します。

max_ageは、オブジェクトが期限切れになるまでの時間(秒)を指定します。オプションとして、期限切れになったオブジェクトがキャッシュから削除されるまでの時間(秒)を指定することもできます。cache_request_typeがNの場合、max_ageは表示されません。

ageは、オブジェクトがキャッシュ内に格納されてからの経過時間(秒)を表します。オブジェクトがキャッシュ不可の場合、ageは表示されません。

例: H;max-age=60+30;age=50

- Hは、このリクエストがキャッシュ・ヒットになったことを表します。

- max-age=60+30は、このオブジェクトがキャッシュに格納されてから60秒後に期限切れとなり、期限切れになってから30秒後にキャッシュから削除されることを表しています。つまり、このオブジェクトはキャッシュに格納されてから、合計で90秒間存在することになります。

- age=50は、キャッシュに格納されてから50秒経過したことを表します。つまり、期限切れになるまで残り10秒、削除されるまで残り40秒ということになります。

x-cache-key

キャッシュ・キーの値。次の書式で表示されます。

"cache_key"

x-clf-date

Oracle Web Cacheからのレスポンスが完了した日付。次の書式で表示されます。

dd/Mon/yyyy:hh:mm:ss [+GMT]

x-cluster

キャッシュ・クラスタのステータスを表す1つの文字。この文字は次のいずれかになります。

- Tは、キャッシュ・クラスタ・メンバーへのリクエストを表します。

- Fは、キャッシュ・クラスタ・メンバーからのリクエストを表します。

- Oは、所有コンテンツのリクエストを表します。

- Dは、オンデマンド・コンテンツのリクエストを表します。

x-cookie(cookie_name)

クライアント・ブラウザ・リクエストのCookieの値。

x-conn-abrt

レスポンスが完了する前に接続が終了したかどうかを表す1つの文字。このフィールドは、エンド・ユーザーのパフォーマンス監視用です。

- Cは、Oracle Web Cacheがレスポンスを完了する前にクライアントによって接続が切断されたことを表します。

- Oは、オリジン・サーバーがOracle Web Cacheへのレスポンスを完了する前にオリジン・サーバーによって接続が切断されたことを表します。

- Nは、接続が切断されずにレスポンスが完了したことを表します。

x-date-start

Oracle Web Cacheが、リクエストの最初のバイトを受信する前の日付。次の書式で表示されます。

yyyy-mm-dd

x-date-end

Oracle Web Cacheが、レスポンスの最後のバイトを送信した日付。次の書式で表示されます。

yyyy-mm-dd

x-ecid

Oracle-ECIDリクエスト・ヘッダーに指定されたID。次の書式で表示されます。

"request_ID, sequence_number"

関連項目: Oracle-ECIDリクエスト・ヘッダーの詳細は、第9.1.1.4項を参照してください。

x-esi-info

<esi:environment>タグまたは<esi:include>タグのlog要素のESIフラグメント・ログ・メッセージ。次の書式を使用します。

"ESI_log_message"

表示されるのは、access_log_file.fragmentファイル内のリクエストされたESIフラグメントのログ・メッセージのみです。リクエストのESIフラグメントにlog要素が設定されていない場合、このフィールドにはハイフン(-)が表示されます。

x-glcookie-set

Oracle Web CachがORACLE_SMP_CHRONOS_GL Cookieを作成し、クライアント・ブラウザへのレスポンスとしてSet-Cookie:ORACLE_SMP_CHRONOS_GLレスポンス・ヘッダー・フィールドを送信したかどうかを表すブール文字。このフィールドは、トランザクションをトラッキングするためのエンド・ユーザーのパフォーマンス監視用です。

- Yは、Oracle Web CacheがORACLE_SMP_CHRONOS_GL Cookieを設定したことを表します。また、Yにより、クライアントのトランザクションの始まりがマークされます。ブラウザからの後続のすべての通信により、Oracle Web Cacheレスポンスで受信したORACLE_SMP_CHRONOS_GL Cookieを使用して設定されたCookieリクエスト・ヘッダー・フィールドが送信されます。

- Nは、Oracle Web CacheがこのCookieを作成しなかったことを表します。Cookieがすでに設定されていると、このようになる場合があります。

x-log-id

クライアントのログイン・ユーザー名。Oracle Web Cacheは、このフィールドの値を取得できません。そのため、このフィールドが設定されている場合は出力にハイフン(-)が表示されます。

x-os-name

Oracle Web Cacheがリクエストを転送するオリジン・サーバーまたはキャッシュ・クラスタ・メンバー。次の書式で表示されます。

host:port

x-os-timeout

オリジン・サーバーがリクエスト時にタイムアウトしたかどうかを表す1文字。この文字は次のいずれかになります。

- 0は、オリジン・サーバーがタイムアウトしなかったことを表します。

- 1は、オリジン・サーバーがタイムアウトしたことを表します。出力1は、オリジン・サーバー自体に問題があることを示しています。

x-protocol

クライアント・リクエストのプロトコルおよびバージョン。次の書式で表示されます。

protocol/version

x-req-line

リクエスト行。次の書式で表示されます。

"HTTP_request_method URI protocol/version"

例: "GET /cache.htm HTTP/1.1"

x-req-type

リクエストのタイプ。リクエストのタイプは次のいずれかになります。

- Bは、ブラウザからのリクエストであることを表します。

- Cは、別のキャッシュ・クラスタ・メンバーからのリクエストであることを表します。

- Hは、別のキャッシュ・クラスタ、または現在のキャッシュ・クラスタのメンバーではないOracle Web Cacheからのリクエストであることを表します。

- Fは、ESIフラグメントのリクエストであることを表します。

x-time-delay

Oracle Web Cacheとオリジン・サーバーまたはピア・キャッシュとの通信にかかった秒単位の時間(マイクロ秒も含む)。この時間は、次の2つのタイム・ポイント間の時間差です。

- Oracle Web Cacheがリクエストの最初のバイトを受信する直前の時刻。

- Oracle Web Cacheがリクエストの最初のバイトをオリジン・サーバーまたはピア・キャッシュに送信した直前の時刻。

このフィールドは、エンド・ユーザー・パフォーマンス監視機能にタイム情報を提供する場合に便利です。

x-time-end

Oracle Web Cacheが、レスポンスの最後のバイトを送信した時刻。次の書式で表示されます。

hh:mm:ss:ssssss

x-time-handshake

クライアントが新規の接続を開始した時刻と、Oracle Web CacheがHTTPリクエストの最初のバイトを受信した時刻の時間差。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-reqrecvlatency

Oracle Web CacheがHTTPリクエストの最初のバイトと最後のバイトを受信した時刻の時間差。このフィールドは、ブラウザ・リクエストの読取り時間を示します。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-reqsendlatency

Oracle Web CacheがHTTPリクエストの最初と最後のバイトをオリジン・サーバーに送信した時刻の時間差。このフィールドは、リクエストをオリジン・サーバーに送信するためにかかった時間を示します。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-resprecvlatency

Oracle Web CacheがHTTPレスポンスの最初のバイトと最後のバイトをオリジン・サーバーから受信した時刻の時間差。このフィールドは、レスポンスをオリジン・サーバーから受信するためにかかった時間を示します。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-respsendlatency

Oracle Web CacheがHTTPレスポンスの最初のバイトと最後のバイトをオリジン・サーバーに送信した時刻の時間差。このフィールドは、レスポンスをクライアントに送信するためにかかった時間を示します。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-reqblocked

キャッシュの更新によってリクエストがブロックされた時刻とブロックが解除された時刻の時間差。既存のオブジェクトを更新するためにリクエストがOracle Web Cacheによってオリジン・サーバーに送信されている場合、Oracle Web Cacheでは後続のリクエストがすべてブロックされます。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-reqqueued

リクエストがオリジン・サーバーへのキューに入れられた時刻とデキューされた時刻の時間差。このフィールドは、リクエストが処理目的でオリジン・サーバーに送信される前に、Oracle Web Cacheのオリジン・サーバー用バックエンド・キューに入れられていた(オリジン・サーバーが最大許容量に達したため)時間を示します。

注意: オラクル社カスタマ・サポート・センターから指示された場合のみ、このフィールドを選択してください。

x-time-start

Oracle Web Cacheが、リクエストの最初のバイトを受信する前の時刻。次の書式で表示されます。

hh:mm:ss:ssssss

9.2.2.1 cs(header_name)およびsc(header_name)アクセス・ログ・フィールド

表9-6は、cs(header_name)フィールドおよびsc(header_name)フィールドに使用できるHTTP/1.1ヘッダーの例をリストにしたものです。この表には、使用可能なヘッダーの一部のみリストされています。包括的なリストではありません。

表9-6 HTTP/1.1ヘッダー・フィールドの例

cs(header_name)フィールド

sc(header_name)フィールド

Accept

Cache-Control

Authorization

Content-Encoding

Connection

Content-Language

Date

Content-Length

Host

Content-Type

Referer

Date

Cache-Control

ETag

Content-Encoding

Expires

Content-Language

Last-Modified

Content-Length

Pragma

Content-Type

Server

If-None-Match

Transfer-Encoding

If-Modified-Since

Via

Last-Modified

Pragma

Range

TE

User-Agent

Via

表9-7は、cs(header_name)フィールドとsc(header_name)フィールドに使用できるCookie関連ヘッダーの例をリストにしたものです。

表9-7 サポートされるCookie関連ヘッダー・フィールド

cs(header_name)フィールド

sc(header_name)フィールド

Cookie

Set-Cookie

表9-8は、cs(header_name)フィールドとsc(header_name)フィールドに使用できるOracle Web Cacheヘッダーの例をリストにしたものです。

表9-8 サポートされるOracle Web Cacheヘッダー・フィールド

cs(header_name)フィールド

sc(header_name)フィールド

Surrogate-Capability

Surrogate-Control

9.2.3 アクセス・ログの例

次に、アクセス・ログ・ファイルの抜粋を示します。

10.10.150.35 - - [25/Jul/2005:10:27:42 -0500] "GET /~user/personal.htm HTTP/1.1" 200 2438
10.10.150.35 - - [25/Jul/2005:10:27:54 -0500] "GET /~user/personal.htm?UserName=Bob HTTP/1.1" 200 2438
10.10.150.35 - - [25/Jul/2005:10:47:30 -0500] "GET /~user/count.sh HTTP/1.1" 403 289
10.10.150.35 - - [25/Jul/2005:10:47:34 -0500] "GET /~user/sbin/count.sh HTTP/1.1" 200 321

出力の最初の行で、各フィールドの意味は次のようになります。

- 10.10.150.35は、ブラウザのIPアドレス(c-ip)です。

- [25/Jul/2005:10:27:42 -0500]は、日付([x-clf-date])です。

- "GET /~user/personal.htm HTTP/1.1"は、リクエスト行("x-req-line")です。

- 200は、HTTPステータス・コード(sc-status)です。

- 2438は、送信されたオブジェクトのサイズ(bytes)です。

この項では、さらに次のアクセス・ログの例を示します。

- 第9.2.3.1項「例: 再ロード・エントリが含まれているアクセス・ログ」

- 第9.2.3.2項「例: ステータス・コード404エントリが含まれているアクセス・ログ」

- 第9.2.3.3項「例: 複合形式のアクセス・ログ」

- 第9.2.3.4項「例: サイト情報が含まれているアクセス・ログ」

- 第9.2.3.5項「例: ESI診断情報が含まれているアクセス・ログ」

- 第9.2.3.6項「例: ESIログ情報が含まれているアクセス・ログ」

他に注記がない場合、アクセス・ログの例では、CLF形式が使用されています。

c-ip x-log-id x-auth-id x-clf-date x-req-line sc-status bytes

9.2.3.1 例: 再ロード・エントリが含まれているアクセス・ログ

次に、Webブラウザの再ロードが2回、続いてシフト-再ロードが2回、さらに再ロードが2回発生した場合のアクセス・ログの抜粋を示します。

10.10.150.35 - - [25/Jul/2005:11:04:24 -0500] "GET /cache.htm HTTP/1.1" 200 250
10.10.150.35 - - [25/Jul/2005:11:04:26 -0500] "GET /cache.htm HTTP/1.1" 200 250
10.10.150.35 - - [25/Jul/2005:11:29:24 -0500] "GET /cache.htm HTTP/1.1" 304 0
10.10.150.35 - - [25/Jul/2005:11:29:25 -0500] "GET /cache.htm HTTP/1.1" 304 0
10.10.150.35 - - [25/Jul/2005:11:29:30 -0500] "GET /cache.htm HTTP/1.1" 200 250
10.10.150.35 - - [25/Jul/2005:11:29:35 -0500] "GET /cache.htm HTTP/1.1" 200 250

3と4行目では、オブジェクトが変更されていないことを示すHTTPステータス・コード304が返されていますので、再ロードの必要がなかったことを表しています。

9.2.3.2 例: ステータス・コード404エントリが含まれているアクセス・ログ

次に、リクエストされたURL /ows-img/chalk.jpgに一致するオブジェクトをOracle Web Cacheが検出できなかった場合のアクセス・ログの抜粋を示します。このエラーは、HTTPステータス・コード404によって示されます。

10.10.150.35 - - [25/Jul/2005:10:49:44 -0500] "GET /pls/coe/find_via_post HTTP/1.1" 200 1119
10.10.150.35 - - [25/Jul/2005:10:49:44 -0500] "GET /ows-img/chalk.jpg HTTP/1.1" 404 284

9.2.3.3 例: 複合形式のアクセス・ログ

複合形式を指定した場合のアクセス・ログの抜粋を示します。

c-ip x-log-id x-auth-id x-clf-date x-req-line sc-status bytes cs(Referer) cs(User-Agent)

10.10.150.35 - - [25/Jul/2005:20:09:47 +0000] "GET /manual/sections.html HTTP/1.1" 200 -1 "http://www.company.com:80/manual/mod/directive-dict.html#Syntax" "Mozilla/4.78 [ja] (Win98; U)"
10.10.150.35 - - [25/Jul/2005:20:09:50 +0000] "GET /manual/mod/core.html HTTP/1.1" 200 -1 "http://www.company.com:80/manual/sections.html" "Mozilla/4.78 [ja] (Win98; U)"
10.10.150.35 - - [25/Jul/2005:20:10:06 +0000] "GET / HTTP/1.1" 200 -1 - "Mozilla/4.78 [ja] (Win98; U)"
10.10.150.35 - - [25/Jul/2005:20:10:14 +0000] "GET /manual/LICENSE HTTP/1.1" 200 -1 "http://www.company.com:80/manual/index.html" "Mozilla/4.78 [ja] (Win98; U)"

9.2.3.4 例: サイト情報が含まれているアクセス・ログ

次のフィールドを指定した場合のアクセス・ログの抜粋を示します。

c-ip x-auth-id x-clf-date cs(Host) x-req-line sc-status bytes

cs(Host)は、サイト情報を指定するHostリクエスト・ヘッダー・フィールドの出力を表示します。この例では、サイトwww.company.com:80に対するリクエストがOracle Web Cacheに送信されます。

10.10.150.35 - [25/Jul/2005:20:05:51 +0000] "www.company.com:80" "GET / HTTP/1.1" 200 -1
10.10.150.35 - [25/Jul/2005:20:05:56 +0000] "www.company.com:80" "GET /manual/index.html HTTP/1.1" 200 -1
10.10.150.35 - [25/Jul/2005:20:05:59 +0000] "www.company.com:80" "GET /manual/upgrading_to_1_3.html HTTP/1.1" 200 -1
10.10.150.35 - [25/Jul/2005:20:06:02 +0000] "www.company2.com:80" "GET /manual/mod/mod_dir.html HTTP/1.1" 200 -1
10.10.150.35 - [25/Jul/2005:20:06:05 +0000] "www.company2.com:80" "GET /manual/mod/directive-dict.html HTTP/1.1" 200 -1

9.2.3.5 例: ESI診断情報が含まれているアクセス・ログ

次のフィールドを指定した場合のアクセス・ログの抜粋を示します。

c-ip x-clf-date x-req-line sc-status bytes x-cache-detail

x-cache-detailによって、診断情報が表示されます。次に例を示します。

- Tは、このリクエストがESIテンプレート用であることを表します。

- Hは、このリクエストがキャッシュ・ヒットになったことを表します。

- max-age=10+15は、このオブジェクトがキャッシュに格納されてから10秒後に期限切れとなり、期限切れになってから15秒後にキャッシュから削除されることを表します。つまり、このドキュメントはキャッシュに格納されてから、合計で25秒間存在することになります。

- age=0は、キャッシュに格納されてから0秒経過したことを表します。つまり、期限切れになるまで残り10秒、削除されるまで残り15秒ということになります。

[25/Jul/2005:02:35:37 +0000] "GET /cgi-bin/esi-headers.sh?err1.htm HTTP/1.0" 200 42 TM;max-age=10+15;age=0

9.2.3.6 例: ESIログ情報が含まれているアクセス・ログ

次のフィールドを指定した場合のアクセス・ログの抜粋を示します。

c-ip x-clf-date x-req-line sc-status bytes x-esi-info

x-esi-infoによって、<esi:environment>タグまたは<esi:include>タグのlog要素からログ情報が表示されます。

[25/Jul/2005:03:03:35 +0000] "GET /b.html HTTP/1.0" 200 4 "This is a sample fragment."

9.3 イベント・ログの構成

イベント・ログ設定を構成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューで、「管理」、次に「イベント・ログ」を選択します。
「イベント・ログ構成」ページが表示されます。

3. 「キャッシュ固有の設定」表内の各キャッシュに対して、次の設定を指定します。

1. 「Directory」フィールドに、イベント・ログを作成するディレクトリを入力します。
デフォルトでは、イベント・ログは次のディレクトリに格納されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

2. バッファ・ロギングを有効にするには「バッファリングを有効化?」をクリックし、バッファ・ロギングを無効にするにはこのチェック・ボックスを選択解除します。
バッファ・ロギングでは、Oracle Web Cacheはログ・メッセージをメモリーに格納します。バッファ・サイズまたはフラッシュ間隔に達すると、Oracle Web Cacheはメモリー内のログ・メッセージをまとめてイベント・ログに書き込みます。バッファ・ロギングを使用すると、ディスクI/O操作が減るのでパフォーマンスが向上します。

Oracle Web Cacheサーバーが予期せずシャットダウンすると、バッファされているログ・メッセージが失われる場合があります。

イベント・ログの結果を即時に参照する場合は、バッファリングを無効にすることをお薦めします。

3. バッファリングが有効になっている場合は、「フラッシュ間隔」フィールドに、Oracle Web Cacheがバッファの内容をイベント・ログ・ファイルに書き込む間隔を秒単位で指定します。
デフォルトは10秒です。間隔が経過すると、Oracle Web Cacheはバッファに格納されている情報をイベント・ログ・ファイルに書き込みます。バッファがいっぱいになっていなくても、Oracle Web Cacheはイベント・ログを更新します。時間を短くして結果を頻繁に表示する必要がある場合以外は、デフォルト値を変更しないことをお薦めします。

0を指定すると、Oracle Web Cacheは指定したバッファ・サイズを超えたときにのみバッファのイベント・ログをフラッシュします。

4. バッファリングを有効にしている場合は、「バッファ・サイズ」フィールドに、文字数で表したバッファのサイズを入力します。
デフォルトは2,048文字です。指定できる最大値は32,768文字です。

5. 「Verbosity」リストから、イベント・ログに必要な詳細レベルを選択します。表9-9にレベルを示します。

表9-9 冗長レベル

レベル

説明

警告

異常な操作イベントを表示します。

通知

起動や停止などの通常の操作イベントを表示します。これはデフォルトです。

トレース

構成のデバッグ用のイベントを表示します。

- サイトの解決

- 正しいオリジン・サーバーへのサイト・サーバー間マッピング・ルート

- 圧縮

- セッション・バインディング

- キャッシュ・ルール

- ESI処理

デバッグ

トラブルシューティングのための詳細イベントを表示します。このレベルは、オラクル社カスタマ・サポート用に用意されています。

4. 「グローバル・イベント・ログの構成」セクションでグローバル・イベント・ログ設定を指定します。

1. 「File Name」フィールドに、イベント・ログ・ファイルの名前を入力します。
デフォルトのファイル名は、event_logです。

2. 「File Format」リストからログ形式を選択します。
形式の詳細は、第9.1.1項を参照してください。

3. 「Time Style」リストから、「Local」または「GMT」(グリニッジ標準時)のいずれかを選択して、イベント・ログ・ファイル内のエントリに関連付けられたタイムスタンプの書式を変更します。

注意:
オラクル社では、可能なかぎりGMTの使用をお薦めします。「Local」を使用した場合、GMTからローカル・タイムへの変換処理により、CPUに負荷がかかる可能性があります。変換処理は、オペレーティング・システムによって実行されます。そのため、Oracle Web Cacheには、変換処理のパフォーマンスを改善するためのメカニズムは存在しません。

4. 「リクエストベースのロギング」をクリックして、リクエストベースのロギングを有効にします。
リクエストベースのロギングでは、Oracle Web Cacheは、各リクエストに関連付けられている、メモリー内のすべてのイベント・ログ・メッセージを収集します。リクエストの最も重大なメッセージが、選択されている冗長性レベルと同じかそれ以上の場合、Oracle Web Cacheはそのリクエストに関連するすべてのメッセージをイベント・ログに一度に書き込みます。診断が容易なように、1つのリクエストに対するメッセージがグループ化されログ・ファイル内に集められます。たとえば、冗長性が「通知」に設定されていて、トレース・レベルまたはデバッグ・レベルのエラーが検出された場合、Oracle Web Cacheはそのリクエストに対するすべてのイベント・ログ・メッセージをイベント・ログに書き込みます。

結果を発生したとおりに表示する場合、特に冗長性が「通知」より高いレベルに設定されている場合は、「無効」を選択します。

5. 「Include Request Details」で、Oracle Web CacheがOracle-ECIDリクエスト・ヘッダーの情報をイベント・ログに書き込む場合は「Yes」を選択し、リクエスト情報をイベント・ログに書き込まない場合は「No」を選択します。リクエスト詳細のロギング方法の詳細は、第9.1.1.2項を参照してください。
次の条件のどちらかに当てはまる場合は、「No」を選択します。

- リクエスト詳細のイベント・ログ・エントリによるパフォーマンス上の影響が心配な場合。

- Oracle HTTP Serverを使用せずにスタンドアロン環境でOracle Web Cacheが稼働している場合。

5. ロールオーバー・ポリシーを指定します。

1. 「時間別にロールオーバー」セクションで、「編集」をクリックします。
「ロールオーバー・ポリシーの編集」ダイアログ・ボックスが表示されます。

ロールオーバー・オプションは組み合せて使用できます。たとえば、「時間別にロールオーバー」と「サイズ別にロールオーバー」の両方を使用したり、「サイズ別に保存」と「時間別に保存」の両方を使用できます。Oracle Web Cacheでは、先に使用できるオプションでロールオーバーが実行されます。

2. 「Rollover by Time」リストから、「Never」、「Hourly」、「Daily」または「Weekly」を選択して、Oracle Web Cacheが現在のログ情報をevent_log_file.yyyymmddhhmmに保存し、設定されているログ・ファイル名を使用して今後のログ情報を新しいログ・ファイルに書き込む頻度を指定します。
ボリュームの大きいサイトでは、「日次」または「時間」を選択します。

3. 「スケジュール時間」フィールドで、「毎時」、「毎日」および「毎週」について、左側のフィールドとメニューを使用して新しい頻度を指定し、「追加」をクリックしてスケジュールに追加します。表9-10に、「Hourly」、「Daily」および「Weekly」の構成方法を具体的に示します。

表9-10 時間別のロールオーバーの構成

ポリシー

構成手順

毎時

1. 毎時何分かを示す値をフィールドに入力します。デフォルトの0は、1時間の開始分を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」(グリニッジ標準時)を選択します。

毎日

1. 時間フィールドと分フィールドに値を入力します。デフォルトの0は、1日の開始時刻を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」を選択します。

毎週

1. 曜日を選択し、時と分のフィールドに値を入力して、時間を追加します。デフォルトの0は、週の開始日時を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」(グリニッジ標準時)を選択します。

スケジュール・リストから時間を削除するには、目的の時間を選択して「Remove」をクリックします。選択した値が左側のリストへ移動し、変更できるようになります。

ログ・ファイルを即時にロールオーバーする方法は、第9.8項を参照してください。

4. 「Rollover by Size」フィールドに、ロールオーバーを実行するログ・ファイルの最大サイズを入力します。0を指定すると、サイズが無制限になります。

5. 「Retention by Time」フィールドに、最も古いログ・ファイルを消去するまでの期間を指定します。
「毎」フィールドに値を入力し、「時間」、「日」、「週」、「月」、「年」のリストから期間を選択します。値0は無期限を意味し、Oracle Web Cacheは時間に基づいてファイルを保持しません。

6. 「Retention by Size」フィールドに、最も古いログ・ファイルを消去する条件として、すべてのログ・ファイルの合計サイズを入力します。0を指定すると、サイズが無制限になります。
ここには、「Rollover Size」フィールドに指定した値より大きい値を入力する必要があります。

「Retention by Time」と「Retention by Size」を両方とも設定しない場合は、ログ・ファイルのサイズが無制限に大きくなります。その結果、ログ・ファイルを保存しているディスクの空き容量をすべて消費してしまう可能性があります。

7. 「OK」をクリックします。

6. 「適用」をクリックし、Oracle Web Cacheを再起動します。第2.13項を参照してください。

9.4 アクセス・ログの構成

アクセス・ログの設定を構成するには、次のようにします。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューで、「管理」、次に「アクセス・ログ」を選択します。
「アクセス・ログの構成」ページが表示されます。

3. 「キャッシュ固有の設定」表内の各キャッシュに対して、次の設定を指定します。

1. 「Directory」フィールドに、アクセス・ログを書き込むディレクトリを入力します。
デフォルトでは、イベント・ログは次のディレクトリに格納されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

2. ロギングを有効にするには「ロギングを有効化?」をクリックし、ロギングを無効にするには選択解除します。

3. バッファ・ロギングを有効にするには「バッファリングを有効化?」をクリックし、バッファ・ロギングを無効にするにはこのチェック・ボックスを選択解除します。
バッファ・ロギングでは、Oracle Web Cacheはログ・メッセージをメモリーに格納します。バッファ・サイズまたはフラッシュ間隔に達すると、Oracle Web Cacheはメモリー内のログ・メッセージをまとめてアクセス・ログに書き込みます。バッファ・サイズは2048バイトに設定されています。バッファ・ロギングを使用すると、ディスクI/O操作が減るのでパフォーマンスが向上します。

Oracle Web Cacheサーバーが予期せずシャットダウンすると、バッファされているログ・メッセージが失われる場合があります。

アクセス・ログの結果を即時に参照する場合は、バッファリングを無効にすることをお薦めします。

4. バッファリングが有効になっている場合は、「フラッシュ間隔」フィールドに、Oracle Web Cacheがバッファの内容をアクセス・ログ・ファイルに書き込む間隔を秒単位で指定します。
デフォルトは10秒です。間隔が経過すると、Oracle Web Cacheはバッファに格納されている情報をアクセス・ログ・ファイルに書き込みます。バッファがいっぱいになっていなくても、Oracle Web Cacheはアクセス・ログを更新します。時間を短くして結果を頻繁に表示する必要がある場合以外は、デフォルト値を変更しないことをお薦めします。

0を指定すると、Oracle Web Cacheは指定したバッファ・サイズを超えたときにのみバッファのアクセス・ログをフラッシュします。

4. 「サイト固有の設定」表内の各サイトに対して、次の設定を指定します。

1. 「デフォルト設定」行の設定をこのサイトに適用するには、すべてのサイト設定にデフォルトを使用をクリックします。他のフィールドでサイト固有のオーバーライドを行う場合は、このチェック・ボックスを選択解除します。

2. 「File Name」フィールドに、アクセス・ログ・ファイルの名前を入力します。
デフォルトのファイル名は、access_logです。

3. サイトのロギングを有効にする場合は「ロギングの有効化」を選択し、サイトのロギングを無効にする場合は選択解除します。
サイト固有のロギングは、キャッシュのロギングが有効な場合にのみ、有効になります。このオプションを有効にする場合は、ステップ3bでキャッシュについてもこのオプションが選択されていることを確認してください。

4. <esi:environment>または<esi:include>のlog要素からESIフラグメント・ログ・メッセージをaccess_log_file.fragmentファイルに記録するには、「ESIフラグメント・リクエストをログしますか。」を選択します。
x-esi-infoフィールドが選択済の場合は、イベントをaccess_log_file.fragmentファイルに記録することを選択します。「Format Style」がエンド・ユーザー・パフォーマンス監視の形式の場合、x-esi-infoフィールドは自動的に選択されます。x-esi-infoフィールドが選択されていない場合は、「Don't Log」を選択します。

5. 「Format Style」リストから、アクセス・ログの形式を選択します。
デフォルト形式の詳細は、第9.2.1項を参照してください。環境に合わせてカスタマイズされた形式の作成方法は、第9.5項を参照してください。

6. 「Rollover Policy」リストから、ロールオーバー・ポリシーを選択して書込み先のログ・ファイルの変更頻度を指定します。Oracle Web Cacheでは、現在のログ情報をaccess_log_file.yyyymmddhhmmに保存し、設定されているログ・ファイル名を使用して今後のログ情報を新しいログ・ファイルに書き込みます。
大規模サイトの場合は、頻度の高いポリシーを選択します。

既存のポリシーの変更方法または新しいロールオーバー・ポリシーの作成方法は、第9.6項を参照してください。

5. 「適用」をクリックし、Oracle Web Cacheを再起動します。第2.13項を参照してください。

9.5 カスタマイズされたアクセス・ログ形式の作成

第9.2.1項に示されているデフォルトの形式が使用環境に適していない場合は、新しいログ形式を作成します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューで、「管理」、次に「アクセス・ログ」を選択します。
「アクセス・ログの構成」ページが表示されます。

3. 「ログ・フォーマット」タブをクリックし、「作成」をクリックします。
ログ形式の作成ダイアログ・ボックスが表示されます。

4. 「Format Name」フィールドに、一意の形式名を入力します。このとき、次の制限事項に注意してください。

- 形式名には、空白や、アンダースコア(_)以外の特殊文字を含めることはできません。

- 名前は、他の形式名、ロールオーバー・ポリシー名およびセッション名の中で一意である必要があります。

5. 「Separator」リストから、アクセス・ログ・フィールドを区切るセパレータを選択します。

6. 「Print XLF Directives」フィールドで、アクセス・ログの先頭にXLFディレクティブ情報を挿入する場合は「Yes」を、挿入しない場合は「No」を選択します。
通常、ディレクティブ情報には、バージョン、日付およびフィールド情報が含まれています。次に例を示します。

#Version: 1.0
#Date: 12-Jul-2008 00:00:00
#Fields: c-ip x-auth-id x-clf-date cs(Host x-req-line sc-status bytes

XLFディレクティブの詳細は、http://www.w3.org/TR/WD-logfile.htmlを参照してください。

7. 「XLFフィールド」セクションで、「フィールド名」リストからアクセス・ログ・フィールド名を選択します。

サポートされるアクセス・ログ・フィールドのリストは、表9-5を参照してください。

8. cs(header_nameまたはsc cs(header_name)、sc(header_name)またはx-cookie(cookie_name)を選択した場合は、「ヘッダー/Cookie名」フィールドにヘッダーまたはCookie名を入力します。

cs(header_name)およびsc(header_name)で使用できるヘッダーの詳細は、表9-6、表9-7および表9-8を参照してください。

9. 「Add」をクリックします。

10. アクセス・ログに必要な形式ごとにステップ7と9を実行し、「Move Up」ボタンと「Move Down」ボタンを使用して、フィールドの順序を並べ替えます。フィールドの入力順序により、フィールドがログに記録される順序が決定されます。

11. 変更を適用して「アクセス・ログの構成」ページに戻るには、「OK」をクリックします。

12. 変更を適用するには、「アクセス・ログの構成」ページで「適用」をクリックします。

9.6 カスタマイズされたアクセス・ログのロールオーバー・ポリシーの作成

既存のロールオーバー・ポリシーを変更するか新しいロールオーバー・ポリシーを作成するには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューで、「管理」、次に「アクセス・ログ」を選択します。
「アクセス・ログの構成」ページが表示されます。

3. 「ロールオーバー・ポリシー」タブをクリックし、「作成」をクリックします。
「ロールオーバー・ポリシーの作成」ダイアログ・ボックスが表示されます。

ロールオーバー・オプションは組み合せて使用できます。たとえば、「時間別にロールオーバー」と「サイズ別にロールオーバー」の両方を使用したり、「サイズ別に保存」と「時間別に保存」の両方を使用できます。Oracle Web Cacheでは、先に使用できるオプションでロールオーバーが実行されます。

4. 「Policy Name」フィールドに、一意のロールオーバー・ポリシー名を入力します。このとき、次の制限事項に注意してください。

- ポリシー名には、空白や、アンダースコア(_)以外の特殊文字を含めることはできません。

- 名前は、他のポリシー名、ログ形式名およびセッション名の中で一意である必要があります。

5. 「Rollover by Time」セクションで、「Never」、「Hourly」、「Daily」または「Weekly」、を選択して、Oracle Web Cacheが現在のログ情報をaccess_log_file.yyyymmddhhmmに保存し、設定されているログ・ファイル名を使用して今後のログ情報を新しいログ・ファイルに書き込む頻度を指定します。
ボリュームの大きいサイトでは、「日次」または「時間」を選択します。

6. 「Rollover by Time」セクションで、「Never」、「Hourly」、「Daily」または「Weekly」、を選択して、Oracle Web Cacheが現在のログ情報をaccess_log_file.yyyymmddhhmmに保存し、設定されているログ・ファイル名を使用して今後のログ情報を新しいログ・ファイルに書き込む頻度を指定します。
ボリュームの大きいサイトでは、「日次」または「時間」を選択します。

「毎時」、「毎日」および「毎週」について、左側のフィールドおよびメニューに新しい頻度を入力し、「追加」をクリックしてスケジュールに追加します。表9-11に、「Hourly」、「Daily」および「Weekly」の構成方法を具体的に示します。

表9-11 時間別のロールオーバーの構成

ポリシー

構成手順

毎時

1. 毎時何分かを示す値をフィールドに入力します。デフォルトの0は、1時間の開始分を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」(グリニッジ標準時)を選択します。

毎日

1. 時間フィールドと分フィールドに値を入力します。デフォルトの0は、1日の開始時刻を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」を選択します。

毎週

1. 曜日を選択し、時と分のフィールドに値を入力して、時間を追加します。デフォルトの0は、週の開始日時を意味します。

2. 「Add」をクリックします。

3. 「Time Style」リストから、「Local」または「GMT」(グリニッジ標準時)を選択します。

スケジュール・リストから時間を削除するには、目的の時間を選択して「Remove」をクリックします。選択した値が左側のリストへ移動し、変更できるようになります。

ログ・ファイルを即時にロールオーバーする方法は、第9.8項を参照してください。

7. 「Rollover by Size」フィールドに、ロールオーバーを実行するログ・ファイルの最大サイズを入力します。0を指定すると、サイズが無制限になります。

8. 「Retention by Time」フィールドに、最も古いログ・ファイルを消去するまでの期間を指定します。
「毎」フィールドに値を入力し、「時間」、「日」、「週」、「月」、「年」のリストから期間を選択します。値0は無期限を意味し、Oracle Web Cacheは時間に基づいてファイルを保持しません。

9. 「Retention by Size」フィールドに、最も古いログ・ファイルを消去する条件として、すべてのログ・ファイルの合計サイズを入力します。0を指定すると、サイズが無制限になります。
ここには、「Rollover Size」フィールドに指定した値より大きい値を入力する必要があります。

「Retention by Time」と「Retention by Size」を両方とも設定しない場合は、ログ・ファイルのサイズが無制限に大きくなります。その結果、ログ・ファイルを保存しているディスクの空き容量をすべて消費してしまう可能性があります。

10. 変更を適用して「アクセス・ログの構成」ページに戻るには、「OK」をクリックします。

11. 変更を適用するには、「アクセス・ログの構成」ページで「適用」をクリックします。

9.7 イベント・ログとアクセス・ログの表示

イベント・ログを表示するには、Fusion Middleware ControlまたはWLSTのlistLogsコマンドを使用します。詳細は、次のドキュメントを参照してください。

- イベント・ログを表示するための様々なツールの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

- イベント・ログ・メッセージの詳細は、Oracle Fusion Middlewareのエラー・メッセージ・リファレンスを参照してください。

アクセス・ログを表示するには、任意のテキスト・エディタを使用します。

9.8 イベント・ログとアクセス・ログのロールオーバー

イベント・ログとアクセス・ログのロールオーバー頻度を構成する以外に、イベント・ログとアクセス・ログを即時にロールオーバーすることができます。ロールオーバー・プロセスでは、Oracle Web Cacheが現在の情報をログ・ファイルに保存し、設定されているログ・ファイル名を使用して今後のログ情報を新しいログ・ファイルに書き込みます。

ログ・ファイルを即時にロールオーバーするには、次の手順を実行します。

1. Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。

2. 「Webキャッシュ」メニューから、「操作」→「オンデマンド・ロールオーバー」を選択します。

9.9 監査ログの使用方法

Oracle Web Cacheは、Oracle Fusion Middlewareコンポーネント全体の監査を管理する統一したシステムを提供するために、共通監査フレームワークをサポートしています。Oracle Web Cacheの各プロセスで生成される監査ログ・ファイルには、セキュリティ・パフォーマンスおよび構成上の問題を特定して診断する際に役立つ重要な情報が記録されます。

Oracle Web Cacheは、次のイベントを監査ログに記録します。

- 起動イベントとシャットダウン・イベント

- 次のキャッシュ間通信イベント

- 認証イベントまたはチャレンジ・イベント

- サブスクライバ・リストへのサブスクライバ・キャッシュの挿入(成功または失敗)

- サブスクライバからの無効なアドレス情報

- リモートまたはサブスクライバ・キャッシュ認証イベント

- クラスタ・キャッシュ・メンバーの追加または削除

- 次のリクエスト認証イベント

- Oracle Web Cacheポートへのログイン

- アクセス制御設定またはリクエスト・フィルタリング・ルールが原因で拒否されたリクエスト

- キャッシュされているオブジェクトへのアクセスが拒否されたID

- 間違ったWebサイト情報を含んでいるレスポンスでの無効化

- クライアント証明書の失敗

- クライアント証明書が提示されなかったために拒否されたSSL接続

- 提示されたクライアント証明書がCRLにあったために拒否されたSSL接続

- 次の構成サービス

- 動的構成変更の適用

- オリジン・サーバーによるSSLハンドシェイクの失敗

- プロキシ・サーバーによる認証の失敗

監査ログの使用方法の詳細は、Oracle Fusion Middlewareセキュリティ・ガイドを参照してください。

10 一般的なデプロイメント・シナリオの構成

この章では、Oracle Web Cacheを使用した一般的なデプロイメント・シナリオの構成方法について説明します。次のトピックが含まれます:

- 第10.1項「一般的なデプロイメントでのOracle Web Cacheの使用方法」

- 第10.2項「グローバル・イントラネット・アプリケーションでのキャッシュ階層の使用方法」

- 第10.3項「ハードウェア・ロード・バランサを使用せずに高可用性を実現するためのOracle Web Cacheの使用方法」

10.1 一般的なデプロイメントでのOracle Web Cacheの使用方法

図10-1に、一般的なOracle Application Server構成内のOracle Web Cacheを示します。一連のOracle Web Cacheサーバーが、一連のWebアプリケーション・サーバーのコンテンツをキャッシュに格納します。Webアプリケーション・サーバーapp1-host1およびapp1-host2がサイトwww.app1.company.comのコンテンツを提供し、app2-hostがwww.app2.company.comのコンテンツを提供します。2つのOracle Web Cacheサーバーは、1つまたは2つの高速CPUを搭載した専用のコンピュータ上で実行されています。Webサイトの可用性および容量を高めるために、これらのサーバーはキャッシュ・クラスタまたはフェイルオーバー・ペアのいずれかとして構成されています。

キャッシュの状態をチェックするために、ハードウェア・ロード・バランサが各Oracle Web Cacheサーバーを定期的にpingするように設定することをお薦めします。

キャッシュ・クラスタとして機能する場合、2つのOracle Web Cacheサーバーは、障害検出とフェイルオーバーを実現します。Oracle Web Cacheサーバーの1つで障害が発生した場合、キャッシュ・クラスタの他のメンバーがその障害を検出し、障害の発生したクラスタ・メンバーにキャッシュされたコンテンツの所有権を引き継いで、キャッシュの障害を隠します。Oracle Web Cacheは、キャッシュ障害の影響を受けない、コンテンツを格納する1つの仮想キャッシュを保持できます。ロード・バランサは、キャッシュ・クラスタ・メンバーに受信リクエストを分散します。キャッシュ・クラスタのメンバーは受信したリクエストを処理します。キャッシュに格納されていないリクエストを受信した場合、Oracle Web Cacheは、サイトに対応するそれぞれのWebアプリケーション・サーバーにリクエストを分散します。

フェイルオーバー・ペアとして機能する場合は、両方のOracle Web Cacheサーバーが同じコンテンツをキャッシュするよう構成されます。両方のOracle Web Cacheサーバーが稼働中のときは、ロード・バランサによって負荷が2つのサーバーに分散されます。1つのサーバーに障害が発生すると、もう1つのサーバーがすべてのリクエストを受信し、処理します。

図10-1 一般的な構成でのOracle Web Cacheの配置

「図10-1 一般的な構成でのOracle Web Cacheのデプロイ」の説明

このトポロジを構成するには、次の手順を実行します。

1. ロード・バランサのIPアドレスをwww.app1.company.comおよびwww.app2.company.comに登録します。

2. ロード・バランサに、Oracle Web Cacheサーバーのホスト名webche1-hostおよびwebche2-hostを構成します。また、各キャッシュ・サーバーを定期的にpingしてキャッシュの状態をチェックするようにロード・バランサを構成します。

3. キャッシュに格納されているURL /_oracle_http_server_webcache_static_.htmlで各Oracle Web Cacheサーバーを定期的にpingするように、ロード・バランサを構成します。

4. キャッシュ・クラスタを構成する場合は、クラスタ・メンバーとしてwebche1-hostおよびwebche2-hostを指定します。
キャッシュ・クラスタの構成方法の詳細は、第3.6項 を参照してください。

5. Oracle Web Cacheサーバーを次のように構成します。

- 指定したリスニング・ポートでHTTPリクエストおよびHTTPSリクエストを受信します。

- HTTPリクエストおよびHTTPSリクエストを、指定したリスニング・ポートからWebアプリケーション・サーバーapp1-host1、app1-host2およびapp2-hostに送信します。

- app1-host1およびapp1-host2にマップされているサイトwww.app1.company.comを定義します。

- app2-hostにマップされているサイトwww.app2.company.comを定義します。

詳細は、次を参照してください。

- リスニング・ポートの構成方法の詳細は、第2.11.1項を参照してください。

- オリジン・サーバー設定の構成方法の詳細は、第2.11.2項を参照してください。

- サイト定義およびサイトからサーバーへのマッピングの作成方法は、第2.11.3項を参照してください。

10.2 グローバル・イントラネット・アプリケーションでのキャッシュ階層の使用方法

Webサイトの多くには、複数のデータ・センターが存在します。分散トポロジのネットワークでは、各データ・センターのOracle Web Cacheを分散キャッシュ階層に配置できます。図10-2は、Oracle Web Cacheサーバーが米国と日本のオフィスに分散された分散トポロジを示しています。Webアプリケーション・サーバーが米国のオフィスに配置され、データ・ソースが地理的に1箇所に集中化されています。米国にある集中キャッシュがWebアプリケーション・サーバーapp1-host1、app2-host2およびapp2-hostのコンテンツをキャッシュし、日本にあるリモート・キャッシュは集中キャッシュのコンテンツをキャッシュします。

クライアントは、ローカルのDNSサーバーにwww.app1.company.comおよびwww.app2.company.comの解決をリクエストします。ローカルのDNSサーバーは、各サイトの上位のDNSサーバーにルーティングされます。上位のDNSサーバーは、クライアントのIPアドレスを使用して、リクエストを処理するための最も近いOracle Web Cacheサーバーを選択します。その後、適切なOracle Web CacheサーバーのIPアドレスをクライアントに返します。

図10-2 Oracle Web Cache階層の配置

「図10-2 Oracle Web Cache階層のデプロイ」の説明

このトポロジを構成するには、次の手順を実行します。

1. ロード・バランサのIPアドレスをwww.app1.company.comおよびwww.app2.company.comに登録します。

2. ロード・バランサに、Oracle Web Cacheサーバーのホスト名us.webche1-hostおよびus.webche2-hostを構成します。また、各キャッシュ・サーバーを定期的にpingしてキャッシュの状態をチェックするようにロード・バランサを構成します。

3. Oracle Web Cacheサーバーus.webche1-hostおよびus.webche1-hostを次のように構成します。

- 指定したリスニング・ポートでHTTPリクエストおよびHTTPSリクエストを受信します。

- HTTPリクエストおよびHTTPSリクエストを、指定したリスニング・ポートからWebアプリケーション・サーバーapp1-host1、app1-host2およびapp2-hostに送信します。

- app1-host1およびapp1-host2にマップされているサイトwww.app1.company.comを定義します。

- app2-hostにマップされているサイトwww.app2.company.comを定義します。

4. Oracle Web Cacheサーバーjp.webche-hostを次のように構成します。

- 指定したリスニング・ポートでHTTPリクエストおよびHTTPSリクエストを受信します。

- HTTPリクエストおよびHTTPSリクエストを、指定したリスニング・ポートからWebアプリケーション・サーバーus.webche1-hostおよびus.webche2-hostに送信します。

- app1-host1およびapp1-host2にマップされているサイトwww.app1.company.comを定義します。

- app2-hostにマップされているサイトwww.app2.company.comを定義します。

5. キャッシュ階層内の各キャッシュに対する無効化メッセージの伝播を有効化します。

1. 次の場所にあるwebcache.xmlをテキスト・エディタで開きます。

(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>

2. <SECURITY>要素のサブ要素である<INTERCACHE>要素を探します。

3. ENABLEINBOUNDICC属性とENABLEOUTBOUNDICC属性をYESに変更します。次に例を示します。

<?xml version="1.0" encoding='ISO-8859-1'?>
<CALYPSO ... >
<VERSION DTD_VERSION="11.1.1.0.0"/>
<GENERAL>
<CLUSTER NAME="WebCacheCluster" ... />
<SECURITY SSLSESSIONTIMEOUT="3600" ... >
<USER TYPE="INVALIDATION" ... />
<USER TYPE="MONITORING" ... />
<SECURESUBNET ALLOW="ALL"/>
<DEBUGINFO HEADER="YES" ... />
<HTTPREQUEST MAXTOTALHEADERSIZE="819000" ... />
<INTERCACHE ENABLEINBOUNDICC="YES" ENABLEOUTBOUNDICC="YES"/>
</SECURITY>
...

4. webcache.xmlを保存します。

6. 次のコマンドを使用して階層内のキャッシュを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

詳細は、次を参照してください。

- リスニング・ポートの構成方法の詳細は、第2.11.1項を参照してください。

- オリジン・サーバー設定の構成方法の詳細は、第2.11.2項を参照してください。

- サイト定義およびサイトからサーバーへのマッピングの作成方法は、第2.11.3項を参照してください。

- 階層内での無効化の仕組みについては、第7.10.2.2項を参照してください。

10.3 ハードウェア・ロード・バランサを使用せずに高可用性を実現するためのOracle Web Cacheの使用方法

次のように構成することにより、ハードウェア・ロード・バランサを使用せずにOracle Web Cacheで高可用性を実現できます。

- HTTPトラフィックのソフトウェア・ロード・バランサ専用またはオリジン・サーバーへの リバース・プロキシ専用としてのOracle Web Cache
このオプションを使用して、1つまたは複数のキャッシュをロード・バランシングまたはリバース・プロキシ・サポート専用に構成します。

- オペレーティング・システムのロード・バランシング機能
このオプションを使用して、複数のキャッシュ間で受信リクエストのロード・バランシングを行うようにオペレーティング・システムを構成します。オペレーティング・システムがあるキャッシュで障害を検出した場合は、自動IP引継ぎを使用して、クラスタ構成内の残りのキャッシュに負荷を分散します。この機能は、Linux、Windows 2000 Advanced Server、Windows 2000 Datacenter ServerおよびWindows 2003(すべてのEdition)など、多くのオペレーティング・システムでサポートされています。

構成の詳細は、第3.8項および第3.9項を参照してください。

第III部

高度な管理

このパートでは、Oracle Web Cacheの高度な管理作業の実施方法を説明します。次の章が含まれます:

- 第11章「ESI言語タグによる動的コンテンツのキャッシュ」

- 第12章「サード・パーティ・アプリケーション・サーバーでのキャッシュ」

11 ESI言語タグによる動的コンテンツのキャッシュ

この章では、動的フラグメントを使用したコンテンツ・アセンブリに提供されているEdge Side Include(ESI)タグについて説明します。

ESIはオラクル社が共同開発に参加したオープン仕様です。クライアントとオリジン・サーバー間のサロゲートまたはプロキシとして配置され、動的コンテンツのキャッシュで動的ページを組み立てるための統一プログラミング・モデルの開発を目的としています。

ESIは、Oracle Web Cacheによるフラグメントの動的コンテンツ・アセンブリを可能にするXMLに類似したマークアップ言語です。テンプレート・ページにESIマークアップ・タグを設定し、このタグによって動的HTMLフラグメントをフェッチおよび挿入します。フラグメント自体にESIマークアップを含めることも可能です。テンプレート・ページおよびHTMLフラグメントにキャッシュ・ルールを割り当てることができます。オリジン・サーバーではなく、Oracle Web Cacheでページ・アセンブリを実行可能にすることによって、キャッシュ・ヒット率が高くなり、パフォーマンスが向上します。

この章の項目は次のとおりです。

- 第11.1項「ページの部分的なキャッシュのためのESIについて」

- 第11.2項「コンテンツの動的アセンブリおよびページの部分的なキャッシュの使用」

- 第11.3項「HTTPレスポンスでのインライン無効化の使用方法」

- 第11.4項「ESIタグの説明」

ESI言語リリース1.0仕様の詳細は、http://www.esi.orgを参照してください。

11.1 ページの部分的なキャッシュのためのESIについて

Oracle Web Cacheでは、キャッシュ可能およびキャッシュ不可の両方のページ・フラグメントを使用したWebページの動的アセンブリが可能です。Webページを異なるキャッシュ・プロファイルのフラグメントに分割することにより、このような動的アセンブリを可能にしています。これらのフラグメントは、キャッシュ内で別々の要素として管理されます。そして、エンド・ユーザーによってリクエストされたときに、適宜フラグメントがHTMLページの組立てに使用されます。

オリジン・サーバーではなくOracle Web CacheでのWebページの動的アセンブリを可能にすることにより、組み立てられたページの一部のフラグメントをキャッシュできます。ページの部分的なキャッシュによって、キャッシュ可能なHTMLコンテンツ数が大幅に増加します。これらのコンテンツは、リクエストされた時点でOracle Web Cacheによって組み立てられ、配信されます。さらに、HTTPリクエスト・ヘッダーまたはエンド・ユーザーのCookieで指定される情報に基づいたページ・アセンブリが可能になります。

アプリケーション開発者がページの部分的なキャッシュのためにコンテンツの組立てに使用する基本的な構造は、フラグメントが含まれているテンプレート・ページです。図11-1に示すように、テンプレートは、ロゴ、ナビゲーション・バー、フレームワーク、およびページのその他のルック・アンド・フィールなどの共通要素で構成されます。フラグメントは、ページの動的なサブセクションを示します。

図11-1 テンプレート・ページ

「図11-1 テンプレート・ページ」の説明

テンプレート・ページは、エンド・ユーザーがリクエストするURLに関連付けられています。フラグメントを挿入できるように、テンプレート・ページにはESIマークアップ・タグが構成されており、このタグによってHTMLフラグメントをフェッチおよび挿入するようOracle Web Cacheに指示します。フラグメント自体は、ディスクリート・テキストまたはその他のオブジェクトが含まれているHTMLファイルです。

挿入される各フラグメントは、独自のキャッシュ・ポリシーを持つ別々のオブジェクトです。コンテンツ・プロバイダによって、テンプレートを数日間キャッシュ内に存続可能にし、広告や株価などの特定のフラグメントは、数秒または数分間しかキャッシュに存在しないようにします。その他のフラグメント(ユーザーの銀行口座の残高など)はキャッシュ不可に設定することが可能です。

表11-1に、主なESIタグのサマリーを示します。

表11-1 ESIタグのサマリー

タグ

説明

<esi:choose>

ブール式に基づく条件処理を実行します。

<esi:comment>

出力に含まれないコメントを指定します。

<esi:environment>

HTTPレスポンスで変数を使用できるようにします。

<esi:include>

HTMLフラグメントを挿入します。

<esi:inline>

フラグメントを、個別にキャッシュ可能なフラグメントとして指定し、別のオブジェクトのHTTPレスポンスに埋め込む。

<esi:invalidate>

ブラウザ・ページのレスポンス内の無効化リクエストを指定します。

<esi:remove>

ESI処理が不可の場合に非ESIマークアップを指定します。

<esi:try>

オリジン・サーバーにアクセスできずにリクエストが失敗した場合の代替処理を指定します。

<esi:vars>

環境変数の変数置換を許可します。

例11-1に、図11-1に示したテンプレート・ページのESIマークアップ言語を示します。

例11-1 ESIマークアップ

<HTML>
<HEAD>
<TITLE>
Company.com
</TITLE>
</HEAD>
<BODY>
...
<!-- The following <esi:comment> tags are removed if this page is processed by an ESI processor. -->

<!--esi

<esi:comment text="This is the HTML source when ESI is enabled." />

<esi:comment text="Start: The quick link section. You cannot use the standard
HTML comments because the end of that comment tag would disrupt the HTML comment
tag with 'esi' following the two '-'." />

<esi:comment text="The URI query string parameter 'sessionID' is used to carry
session identifiers, The session ID is encoded in all links." />

<esi:comment text="'Profile' refers to environment variables stored in
GetProfile.jsp. GetProfile.jsp enables access to 'PersonalInterest.' 'zipcode,'
'tickers,' and 'address' environment variables." />

<esi:environment src="/GetProfile.jsp?sessionID=$(QUERY_STRING{sessionID})"
name="Profile" />

<esi:vars>
<A HREF="/shopping.jsp?sessionID=$(QUERY_STRING{sessionID})">
<IMG SRC="/img/shopping.gif">
</A>
<A HREF="/news.jsp?sessionID=$(QUERY_STRING{sessionID})">
<IMG SRC="/img/news.gif">
</A>
<A HREF="/sports.jsp?sessionID=$(QUERY_STRING{sessionID})">
<IMG SRC="/img/sports.gif">
</A>
<A HREF="/fun.jsp?sessionID=$(QUERY_STRING{sessionID})">
<img src="/img/fun.gif">
</A>
<A HREF="/about.jsp?sessionID=$(QUERY_STRING{sessionID})">
<iMG SRC="/img/about.gif">
</A>
</esi:vars>

<esi:comment text="End: The quick link section" />
...
<H3>Local Weather</H3>
<esi:include src="/weather.jsp?sessionID=$(QUERY_STRING{sessionID})&zipcode=$(Profile{zipcode})" />
...

<H3>Stock Quotes</H3>
<esi:try>
<esi:attempt>
<esi:include src="/CompanyStock.jsp?sessionID=$(QUERY_ STRING{sessionID})&tickers=$(Profiles{tickers})" />
</esi:attempt>
<esi:except>
The company stock quote is temporarily unavailable.
</esi:except>
</esi:try>
...
<H3>What's New at Company</H3>
<!-- This section is a static file that does not carry session information -->
<esi:include src="/whatisnew.html" />

...

<H3>Today's News</h3>
<esi:choose>

<esi:when test="$(Profile{PersonalInterests}) == 'Sports'">
<H4>Sport News</H4>
<esi:include src="/SportNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
</esi:when>

<esi:when test="$(Profile{PersonalInterests}) == 'Career'">
<H4>Financial News</H4>
<esi:include src="/FinancialNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
</esi:when>

<esi:otherwise>
<H4>General News</H4>
<esi:include src="/DefaultNews.jsp?sessionID=$(QUERY_STRING{sessionID})" />
</esi:otherwise>

</esi:choose>

...

-->

<!-- This is the HTML source when ESI is disabled. -->
<esi:remove>
Alternative HTML source that does not use ESI goes here. This tag enables you
to disable ESI on the fly without redeveloping or redeploying a different version
of the page.
</esi:remove>
...
</BODY>
</HTML>

例11-2に、プロファイル環境変数へのアクセスを提供するGetProfile.jspのXMLレスポンスを示します。

例11-2 GetProfile.jspのXMLレスポンス

<?xml version=1.0?>
<esi:environment esiversion="ORAESI/9.0.4">
<PersonalInterests>Sports</PersonalInterests>
<zipcode>94065</zipcode>
<tickers>ORCL,YHOO</tickers>
<address>500 Oracle Parkway, Redwood Shores, CA 94065</address>
</esi:environment>

11.1.1 ESIの機能

ESIは、HTML、XML、JSP、ASPおよびその他のあらゆるWebプログラミング・テクノロジとともに使用可能です。ESI言語には、次の機能があります。

- 組込み
ESIプロセッサは、ネットワークから取得した動的コンテンツのHTTPまたはHTTPSフラグメントを使用して、ユーザーに出力する統合ページを組み立てます。各フラグメントに、独自のキャッシュ・ルールを設定可能です。

- 変数のサポート
ESIでは、HTTPリクエストの属性に基づいた変数と、組み込まれたHTMLフラグメントのカスタム変数の使用をサポートしています。変数は、処理時にESI文によって使用したり、処理されたマークアップに直接出力することができます。

- 条件処理
ESIでは、ページ処理の方法を決定するための条件論理に、ブール比較を使用できます。

- エラー処理および代替処理
一部のESIタグでは、プライマリ・リソースが見つからない場合に使用する、デフォルトのリソースや代替リソース(代替のWebページなど)の設定をサポートしています。さらに、明示的な例外処理文ブロックが提供されています。

- キャラクタ・セットの変換
異なるキャラクタ・セットのESIフラグメントがある場合、1つのキャラクタ・セットに変換されます。これにより、特定のキャラクタ・セットで、ページは組み立てられます。キャラクタ・セットの変換は次の方法で行われます。

1. Oracle Web Cacheがテンプレート・ページのリクエストを受信します。

2. Oracle Web Cacheがフラグメントをフェッチし、すべてのフラグメントをテンプレートのキャラクタ・セットに変換します。デフォルトのキャラクタ・セットはISO-8859-1です。

ESIを使用していないページに対しては、Oracle Web Cacheはキャラクタ・セットの変換を行いません。

- XMLからHTMLへの変換
Oracle Web Cacheでは、XSL Transformations(XSLT)を使用して、XMLフラグメントをHTMLに変換します。

11.1.1.1 ESI for Java(JESI)

Oracle Web Cacheでは、ESIのタグおよび機能との便利なインタフェースとしてJESIタグ・ライブラリが提供されています。加えて、JESIタグ・ライブラリをOracle WebLogic Server上に配置することができます。どのようなWebアプリケーションであっても、開発者はESIタグを直接使用することができますが、JSP環境下でJESIタグを使用するとさらに便利になります。

ESIおよびJESIはオープン標準であるため、Oracle Web CacheのようなESIプロセッサが使用可能であれば、標準的なJSP環境の下で、JESIタグ・ライブラリを使用できます。

JSP開発者もESIを使用可能ですが、JESIを使用すると、新しい構文を習得しなくても、ページのモジュール構成や、それらのモジュールがキャッシュ可能かどうかということを簡単に示すことが可能です。

Oracle WebLogic Server上でのJESIの使用方法は、次を参照してください。

http://www.oracle.com/technology/sample_code/tech/java/codesnippet/webcache/index.html

11.1.2 Surrogate-Controlレスポンス・ヘッダーでのESI言語要素

表11-2に、Oracle Web CacheがサポートするESI言語タグ、要素および属性を示します。一番右の列には、各ESIタグ、属性または要素をサポートする機能セットがすべて指定されています。たとえば、<esi:invalidate>タグをサポートしているのは、"ESI-INV/1.0"機能セットのみです。Oracle Web Cacheで処理を正確に実行するために、Surrogate-Controlレスポンス・ヘッダーのcontent制御ディレクティブで、ESIテンプレートが使用するすべての機能セットを指定します。ただし、直接または間接的にテンプレートに挿入されるESIフラグメント内で使用される機能セットを指定する必要があります。たとえば、ESIテンプレートで、<esi:invalidate>タグ、および<esi:log>要素を含む<esi:environment>タグが使用されている場合は、次のようにcontent制御ディレクティブに"ESI-INV/1.0"と"ORAESI/9.0.4"を含める必要があります。

Surrogate-Control: content="ESI-INV/1.0 ORAESI/9.0.4"

Surrogate-Controlレスポンス・ヘッダーの構成方法の詳細は、第6.10項を参照してください。

表11-2 ESI言語の機能

ESI言語の機能

関連項目

Surrogate-Controlレスポンス・ヘッダーのcontent="value"制御ディレクティブでサポートされる機能

<esi:choose> | <esi:when> | <esi:otherwise>タグ

第11.4.1項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<esi:comment>タグ

第11.4.2項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<esi:environment>タグ

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

<esi:include>タグ

第11.4.4項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<esi:environment>タグおよび<esi:include>タグの属性と要素

alt属性

第11.4.4項

"ORAESI/9.0.4"

"ESI/1.0"

max-age属性

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

onerror属性

第11.4.4項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

src属性

第11.4.4項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

timeout属性

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

<esi:log>要素

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

<esi:request_header>要素

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

<esi:request_body>要素

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

<esi:inline>タグ

第11.4.5項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI-Inline/1.0"

"ESI/1.0"

name属性

第11.4.5項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI-Inline/1.0"

"ESI/1.0"

fetchable属性

第11.4.5項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI-Inline/1.0"

"ESI/1.0"

max-age属性

第11.4.5項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

timeout属性

第11.4.4項

第11.4.3項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

<esi:invalidate>タグ

第11.4.6項

"ESI-INV/1.0"

<esi:remove>タグ

第11.4.7項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<esi:try> | <esi:attempt> | <esi:except>タグ

第11.4.8項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<esi:vars>タグ

第11.4.9項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

<!--esi...--->タグ

第11.4.10項

"ORAESI/9.0.4"

"ORAESI/9.0.2"

"ESI/1.0"

ESI言語仕様1.0およびEdgeアーキテクチャ仕様については、http://www.esi.org/spec.htmlを参照してください。

11.1.3 キャッシュ・オブジェクトに対するSurrogate-Controlレスポンス・ヘッダーおよびSurrogate-Capabilityリクエスト・ヘッダーについて

Oracle Web CacheでESIタグを処理できるように、ESIタグを使用するページのHTTPレスポンス・メッセージに、HTTP Surrogate-Controlレスポンス・ヘッダー・フィールドを設定します。

Surrogate-Control: content="ESI-INV/1.0 ORAESI/9.0.4"

キャッシュ内のリクエストされた各オブジェクトに対し、Oracle Web CacheによってSurrogate-Capabilityリクエスト・ヘッダー・フィールドがオブジェクトのHTTPリクエスト・メッセージに追加されます。Surrogate-Capabilityリクエスト・ヘッダーは次の目的に使用できます。

- アプリケーションでOracle Web Cacheを検出できるようにします。

- Oracle Web Cacheが実行できるESI操作の種類を識別します。

Surrogate-Capabilityリクエスト・ヘッダーにより、Oracle Web Cacheは、キャッシュとして機能するオリジン・サーバーに対して実行可能な操作を特定できます。Surrogate-Capabilityリクエスト・ヘッダー・フィールドは次のような構文をサポートします。

Surrogate-Capability: orcl="operation_value operation_value ..."

"operation_value"は次のいずれか(複数可)の値を示します。

- "ORAESI/9.0.4": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用するOracle独自の拡張ESIタグを処理します。"ORAESI/9.0.4"では、10g(9.0.4)以降のOracle Web Cacheで提供されるすべてのESIタグがサポートされます。

- "ORAESI/9.0.2": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用するOracle独自の拡張ESIタグを処理します。"ORAESI/9.0.2"では、リリース2(9.0.2および9.0.3)のOracle Web Cacheで提供されるすべてのESIタグがサポートされます。

- "ESI/1.0": コンテンツ・アセンブリおよびページの部分的なキャッシュに使用する標準ESIタグを処理します。

- "ESI-Inline/1.0": <esi:inline>タグを処理します。

- "ESI-INV/1.0": <esi:invalidate>タグを処理します。

- "webcache/1.0": <!-- WEBCACHETAG-->タグおよび<!-- WEBCACHEEND-->タグを使用してパーソナライズ属性を処理します。

"ORAESI/9.0.2"、"ESI/1.0"および"ESI-Inline/1.0"は、"ORAESI/9.0.4"のサブセットです。このリリースでは、ESIアセンブリに"ORAESI/9.0.4"のみを、インライン無効化に"ESI-INV/1.0"のみを、パーソナライズ属性に"webcache/1.0"のみを指定する必要があります。

各operation_valueに対してサポートされるESIタグの詳細は、表11-3を参照してください。

11.1.4 構文規則

ESIの要素と属性はXML構文に準拠しますが、HTMLやXMLオブジェクトなど、他のオブジェクトに埋込み可能です。Oracle Web Cacheによってページが処理される際、ESI要素自体は出力から削除されます。

ESI構文は、基本的にXML構文規則に準拠します。タグの使用の際には、次の点に注意してください。

- ESIタグおよび属性は、大文字と小文字を区別します。
通常は小文字です。

- サポートされているCGI環境変数は、大文字と小文字を区別します。
通常は大文字です。

- ESIでは、等号(=)の前後、および"<"と"esi:"の間には、空白を使用できません。
次に、無効な構成を示します。

<esi:include src = "www.foo.com"/>

次に、正しい構成を示します。

<esi:include src="www.foo.com"/>

11.1.5 要素のネスト

例11-3に示すように、ESIタグにはESI要素およびその他のHTMLマークアップをネストすることが可能です。

例11-3 ESI要素のネスト

<esi:choose>
<esi:when test="$(HTTP_HOST) == 'www.company.com'">
<esi:include src="/company.html" />
<h4>Another</h4>
<esi:include src="/another.html" />
</esi:when>
<esi:when test="$(HTTP_COOKIE{fragment) == 'First Fragment'">
<esi:try>
<esi:attempt>
<esi:include src="/fragment1.html" />
</esi:attempt>
<esi:except>
<esi:choose>
<esi:when test="$(HTTP_COOKIE{otherchoice}) == 'image'" >
<img src="/img/TheImage.gif">
</esi:when>
<esi:otherwise>
The fragment is unavailable.
</esi:otherwise>
</esi:choose>
</esi:except>
</esi:try>
</esi:when>
<esi:otherwise>
The default selection.
</esi:otherwise>
</esi:choose>

11.1.6 変数式

ESIでは、<esi:environment>タグとともに使用されるHTTPリクエスト変数および環境変数をサポートしています。

この項では、次の項目について説明します。

- 第11.1.6.1項「変数の使用方法」

- 第11.1.6.2項「変数のデフォルト値」

- 第11.1.6.3項「HTTPリクエスト変数」

カスタム変数の挿入方法は、第11.4.3項を参照してください。

11.1.6.1 変数の使用方法

変数を参照するには、ドル記号の接頭辞を入力し、変数名をカッコで囲みます。

$(VARIABLE_NAME)

次に例を示します。

$(HTTP_HOST)

変数には、次のように、キーを使用してアクセスします。

$(VARIABLE_NAME{key})

変数のサブストラクチャにアクセスするには、アクセスするキーを中カッコで囲み、それを変数名に追加します。次に例を示します。

$(HTTP_COOKIE{username})

キーには大文字・小文字の区別とオプションがあります。キーを指定しない場合は、環境変数によって環境フラグメントの全内容が返されます。環境が空かどうかをテストする場合のみ、キーなしで環境変数を指定するようお薦めします。次のESIマークアップの$(logindata)は、null値に対して評価される変数です。

<esi:environment src="/getlogindata" name="logindata"/>
<esi:include src="/login/$(logindata{account})"/">
<esi:choose>
<esi:when test="$(logindata) != null">
<esi:include src="/login/$(logindata{account})"/>
</esi:when>
<esi:otherwise>
<esi:include src="/login/guest.html"/>
<esi:otherwise>
</esi:choose>

11.1.6.2 変数のデフォルト値

論理演算子OR(|)を使用すると、次の書式でデフォルト値を指定できます。

$(VARIABLE|default)

変数にデフォルト値を使用するのは、変数またはそのキーが存在しない場合のみです。変数が空の文字列と評価された場合は、デフォルト値ではなく、空の文字列が返されます。

次の例では、リクエストにCookie idが存在しない場合、Oracle Web Cacheによってhttp://example.com/default.htmlがフェッチされます。

<esi:include src="http://example.com/$(HTTP_COOKIE{id}|default).html"/>

他のリテラルと同様、空白を指定する場合は、デフォルト値を引用符で囲む必要があります。次に例を示します。

$(HTTP_COOKIE{first_name}|'new user')

注意:
HTTP_HOSTおよびHTTP_REFERERはデフォルト値をサポートしていません。

11.1.6.3 HTTPリクエスト変数

表11-3に、ESIでサポートされているHTTPリクエスト変数を示します。次のことに注意してください。

- QUERY_STRINGを除き、変数の値は、HTTPリクエスト・ヘッダー・フィールドから取得されます。QUERY_STRINGの場合、値はHTTPリクエスト・ボディまたはURLから取得されます。

- 変数は、ESIタグで囲まれている場合のみ解析されます。

- サブストラクチャ・タイプが「リスト」または「ディクショナリ」と示されている変数には、キーを使用してアクセスします。

- サブストラクチャ・タイプが「ディクショナリ」と示されている変数は、該当するキーによって文字列へのアクセスを可能にします。

- 「ディクショナリ」のキーには大文字・小文字の区別があります。

- サブストラクチャ・タイプが「リスト」と示されている変数は、リクエストされた値が存在するかどうかにより、ブール値を返します。

表11-3 ESIでサポートされているHTTPリクエスト変数

変数名

HTTPヘッダー・フィールド

サブストラクチャ・タイプ/変数タイプ

説明

例

$(HTTP_ACCEPT_LANGUAGE{language})

Accept-Languageリクエスト・ヘッダー・フィールド

レスポンスに使用する言語セットを指定します。言語はキーとして使用されます。

リスト/ブール

キーとして使用する言語を指定し、HTTPリクエスト・ヘッダーで指定される言語を評価します。

変数の設定:

$(HTTP_LANGUAGE{en-gb})

HTTPリクエスト・ヘッダーの内容:

Accept_Language:en-gb

結果: en-gbを返します。

$(HTTP_COOKIE{cookie})

Set-Cookieレスポンス・ヘッダー・フィールドまたはCookieリクエスト・ヘッダー・フィールド。

Cookieの名前と値のペアを指定します。Cookie名がキーとして使用されます。

Cookieリクエスト・ヘッダーとSet-Cookieレスポンス・ヘッダーが同じCookie名に対して異なる値を持っている場合は、Set-Cookieレスポンス・ヘッダーの名前/値のペアが使用されます。

ディクショナリ/文字列

キーとして使用するCookie名を指定し、そのCookieの値を返します。

変数の設定:

$(HTTP_COOKIE{visits})

HTTPリクエスト・ヘッダーの内容:

Cookie:visits=42

結果: 42を返します。

$HTTP_HEADER{header})

任意のHTTPリクエスト・ヘッダー。

ディクショナリ/文字列

キーとして使用するHTTPリクエスト・ヘッダー名を指定し、そのヘッダーの値を返します。

変数の設定:

$(HTTP_HEADER{Referer})

HTTPリクエスト・ヘッダーの内容:

Referer: http://www.company.com:80

結果: 次を返します。

http://www.company.com:80

$HTTP_HOST

Hostリクエスト・ヘッダー・フィールド

リソースのホスト名およびポート番号を指定します。デフォルトのポート番号はポート80です。

該当なし/文字列

HOSTヘッダーの値を返します。

変数の設定:

$(HTTP_HOST)

HTTPリクエスト・ヘッダーの内容:

Host:http://www.company.com:80

結果: 次を返します。

http://www.company.com:80

$HTTP_REFERER

Refererリクエスト・ヘッダー・フィールド

参照するリソースのURLを指定します。

該当なし/文字列

REFERERヘッダーの値を返します。

変数の設定:

$(HTTP_REFERER)

HTTPリクエスト・ヘッダーの内容:

Referer: http://www.company.com:80

結果: 次を返します。

http://www.company.com:80

$(HTTP_USER_AGENT{browser})

$HTTP_USER_AGENT{version})

$HTTP_USER_AGENT{os})

User-Agentリクエスト・ヘッダー・フィールド

リクエストを送信したWebブラウザ・タイプ、ブラウザのバージョン、またはオペレーティング・システムを指定します。

ディクショナリ/文字列

次の3つのキーから1つを指定します。browser(ブラウザのタイプ)、version(ブラウザのバージョン)およびos(オペレーティング・システム)

変数の設定:

$(HTTP_USER_AGENT{browser})

HTTPリクエスト・ヘッダーの内容:

User-Agent:Mozilla/4.0 (compatible, MSIE 5.5, Windows)

結果: MSIEを返します。

$(HTTP_USER_AGENT{version})

結果: 4.0を返します。

$(HTTP_USER_AGENT{os})

結果: Windowsを返します。

$(QUERY_STRING{parameter})

該当なし。

ディクショナリ/文字列

問合せ文字列に含まれるパラメータ名を指定し、URLエンコーディングされていないパラメータ値を返します。問合せ文字列は、URLまたはリクエスト・ボディに含まれています。

関連項目: URLエンコーディングの詳細は、http://www.rfc-editor.org/を参照してください。

変数の設定:

$(QUERY_STRING{CEO})

問合せリクエストの内容:

CEO=Jane%20Doe&CFO=John%20Doe

結果: デコードされたfullnameの値を返します。この例では、CEOがJane Doeの値を返します。

$(QUERY_STRING)

該当なし。

該当なし/文字列

エンコードされた問合せ文字列全体を返すように指定します。

変数の設定:

$(QUERY_STRING)

問合せリクエストの内容:

CEO=Jane%20Doe&CFO=John%20Doe

結果: エンコードされた問合せ文字列全体を返します。

CEO=Jane%20Doe&CFO=John%20Doe

$(QUERY_STRING_ENCODED{parameter})

該当なし。

ディクショナリ/文字列

問合せ文字列に含まれるパラメータ名を指定し、URLエンコーディングされたパラメータ値を返します。問合せ文字列は、URLまたはリクエスト・ボディに含まれています。

変数の設定:

$(QUERY_STRING{fullname})

問合せリクエストの内容:

fullname=Jane%20Doe

結果: エンコードされたfullnameの値を返します。

Jane%20Doe

$(QUERY_STRING_ENCODED)

該当なし。

該当なし/文字列

$(QUERY_STRING)と同じです。

変数の設定:

$(QUERY_STRING_ENCODED)

問合せリクエストの内容:

fullname=Jane%20Doe

結果: エンコードされた問合せ文字列全体を返します。

fullname=Jane%20Doe

$(QUERY_STRING_DECODED{parameter})

該当なし。

ディクショナリ/文字列

$(QUERY_STRING{parameter})と同じです。

変数の設定:

$(QUERY_STRING_DECODED{CEO})

問合せリクエストの内容:

fullname=Jane%20Doe

結果: デコードされたfullnameの値を返します。この例では、fullnameがJane Doeの値を返します。

11.1.7 例外およびエラー

ESIでは、ESIフラグメント・リクエスト時に発生した例外の処理に、複数のメカニズムを使用します。開発しているビジネス・ロジックによって、特定の状況で、すべてのメカニズムを同時に使用、または1つのみを使用できます。

最初のメカニズムはESI言語に含まれているもので、エラー発生時のコンテンツ・アセンブリを詳細に制御するために3つの要素が提供されています。

- <esi:include>タグのalt属性

- <esi:include>タグのonerror属性

- try |attempt |exceptブロック

- フラグメント用のデフォルト・ページ

<esi:include>タグのsrc属性を使用して指定したフラグメントがフェッチできない場合は、alt属性を使用して指定したフラグメントを代替として使用します。alt属性を使用しない場合、またはフラグメントがフェッチできない場合は、onerror属性を使用します。onerror属性をtry |attempt |exceptブロックの前に使用します。try |attempt |exceptブロックが存在しない場合は、例外処理が親またはテンプレート・ページに伝播されます。ESI言語制御がすべて失敗した場合、Oracle Web Cacheには、フラグメント用のデフォルト・ページが表示されます。

次の各項を参照してください。

- 第11.4.4項「ESIのincludeタグ」

- 第11.4.8項「ESIのtry | attempt | exceptタグ」

- 第2.11.6項「作業6: エラー・ページの構成」

11.1.8 inlineタグおよびincludeタグによる断片化

<esi:inline>タグおよび<esi:include>タグを使用すると、アプリケーションでESIによるページの断片化とアセンブリを行うことができます。次に示す項では、これらのタグおよび目的に応じた使用方法について説明します。

- 第11.1.8.1項「inlineタグをフェッチ不可の場合の断片化に使用する方法」

- 第11.1.8.2項「inlineタグをフェッチ可能な場合の断片化に使用する方法」

- 第11.1.8.3項「includeタグを断片化に使用する方法」

- 第11.1.8.4項「アプリケーションに適した断片化メカニズムの選択」

11.1.8.1 inlineタグをフェッチ不可の場合の断片化に使用する方法

既存のアプリケーションの大部分は、Webページ全体をHTTPリクエストに出力するように設計されています。このようなページのフラグメントおよびテンプレートはフェッチ不可、つまり、オリジン・サーバーを経由しないでフェッチすることはできません。キャッシュでこのようなフラグメントまたはテンプレートが必要になった場合には、対応するWebページ全体をリクエストする必要があります。フェッチ不可フラグメントを使用してESIによるページ・アセンブリを行うときには、アプリケーションは通常の場合と同様にページ全体のレスポンスを出力しますが、各フラグメントの最初と最後の部分に、フラグメントを区別するためのフラグメント名を指定した<esi:inline>タグが挿入されます。Oracle Web Cacheはタグで囲まれた部分を個別のフラグメントとして保存し、タグで囲まれたフラグメントのない元のページをテンプレートとして保存します。名前が同じで、同じサイトからのフラグメントが複数存在する場合、そのフラグメントはテンプレート間で共有されていることを示します。

例11-4に、単純な<esi:inline>タグの例を示します。<esi:inline>タグで囲まれているHTMLの表はフラグメント・コンテンツを示します。<esi:inline name="/news101">より前の部分および</esi:inline>より後の部分はページのテンプレートになります。別のページにある<esi:inline>タグにも同じ"/news101"という名前が設定されている場合、この2つのフラグメントは同じコンテンツを論理的に共有していることになります。

例11-4 フェッチ不可の場合のinlineタグの例

<HTML>
...
<esi:inline name="/news101">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

フェッチ不可の<esi:inline>フラグメントをアプリケーションで使用する場合、キャッシュ・ミスが発生するたびにページ全体をリクエストする必要があります。最初のうちは、キャッシュ・ミスの場合はキャッシュの明白な利点はないように思われることもあります。しかし、フェッチ不可の<esi:inline>フラグメントを使用すると、次の利点によりキャッシュ機能が全般的に改善されます。

- キャッシュ・ヒット率の向上
共有フラグメントをそれぞれ別々のフラグメントとして抽出することができるので、動的な部分のサイズが小さくなります。要求される領域の範囲が狭くなるため、ページ全体をキャッシュするよりもキャッシュ・ヒット率が高くなります。

- キャッシュの更新頻度の削減
動的な共有フラグメントは1回の更新しか必要としません。たとえば、株式市場に関する共有フラグメントは、ページ内のその他のフラグメントよりもかなり頻繁に期限切れになることがあります。そのような場合、<esi:inline>タグを使用してページを断片化すると、キャッシュに格納されているページのうち、このフラグメントを含んでいるいずれかのページ全体を1回更新すれば、このフラグメントを共有しているすべてのページ全体が最新の状態に更新されます。そのため、フェッチ不可の<esi:inline>フラグメントであっても、キャッシュの更新頻度を大幅に削減することができます。コストの削減は共有の程度に比例します。

フェッチ不可のフラグメントを無効にするには、テンプレート・オブジェクトとフェッチ不可のフラグメントの両方を無効にして、フラグメントを確実に無効にする必要があります。

11.1.8.2 inlineタグをフェッチ可能な場合の断片化に使用する方法

<esi:inline>フラグメントは、デフォルトではフェッチ不可です。アプリケーションでそれぞれ別々にフェッチ可能なフラグメントをサポートしている場合、<esi:inline>タグをフェッチ可能なフラグメントに使用するには、fetchable属性をyesに設定します。

例11-5に、/news101というフェッチ可能なフラグメントに使用する<esi:inline>タグの例を示します。このページをリクエストすると、テンプレート・ページとフェッチ可能なフラグメントが返されます。

例11-5 フェッチ可能な場合のinlineタグの例

<HTML>
...
<esi:inline name="/news101" fetchable="yes">
<TABLE>
...
</TABLE>
</esi:inline>
...
</HTML>

fetchable属性の詳細は、第11.1.8.2項を参照してください。

11.1.8.3 includeタグを断片化に使用する方法

動的コンテンツのキャッシュおよびアセンブリで使用できるように、<esi:include>タグを使用して、HTTP出力にフラグメントとテンプレートを定義する方法もあります。このタグは、多くの点で<esi:inline>タグと似ています。それは、定義されたフラグメントの名前を定義定します。<esi:include>タグを含んでいるページは、定義されたフラグメントを参照するテンプレートになります。しかし、このタグには<esi:inline>タグとは基本的に異なっている点がいくつかあるため、使用方法も次のように大きく異なっています。

- テンプレート内の<esi:include>タグは、フラグメントの参照のみを定義します。
それは、テンプレート内の埋込みフラグメントを直接囲みません。そのため、<esi:include>タグの埋め込まれたテンプレートを複数のユーザーに対して使用することができます。一方、<esi:inline>タグの埋め込まれたテンプレートは、各ユーザーに固有のものでなければなりません。

- <esi:include>タグによって参照されるフラグメントは、必ず、HTTPまたはHTTPSによって別々にフェッチ可能なフラグメントでなければなりません。
リクエストされるURLはフラグメント名と同じになります。一方、<esi:inline>タグの名前はフラグメントを区別するだけのものであり、実際のコンテンツのフェッチには使用されません。<esi:include>フラグメントでフラグメント名を定義する属性は、nameではなくsrcです。

<esi:include>タグを使用すると利点がある例として、次の2つをあげることができます。

- アプリケーションの中には、たとえばWebポータルのように、外部ソースからコンテンツを組み立てるものがあります。アプリケーションの役割は、サード・パーティのソースから各種のフラグメントをフェッチするために使用されるテンプレートを提供するのみです。このような場合、<esi:include>タグを使用するとフェッチと組立てが直接行われるので、1層分の冗長性が削減されます。

- アプリケーションによっては、<esi:inline>タグを使用したページ全体のリクエストよりも、テンプレートのみのリクエストの方がレスポンスが速い場合があります。<esi:include>タグをページの断片化とアセンブリに使用する場合、大部分またはすべてのフラグメントがすでにキャッシュされていると、Oracle Web Cacheがキャッシュ・ミスするのはテンプレートのみとなるので、キャッシュ・ミスにかかる実際のコストの節減になります。パーソナライズされたテンプレートについては変更されることがほとんどないため、多くの場合、そのようなテンプレートをキャッシュすることにも利点があります。

例11-1に、<esi:include>タグを使用したESIマークアップの例を示します。

11.1.8.4 アプリケーションに適した断片化メカニズムの選択

Oracle Web Cacheでは、<esi:include>と<esi:inline>の両方でクライアント・ブラウザ用のフラグメントをフェッチすることができますが、このタスクを実行する場合は<esi:include>の方が強力であり、かつフラグメントを容易に管理できます。<esi:include>はアプリケーション・フローに影響するため、アプリケーションの設計フェーズの初期段階で<esi:include>を組み込むのが最善の方法です。既存のアプリケーションの場合、アプリケーションの変更を最小限に抑えることができるため、<esi:inline>のメカニズムの方が効率的です。

11.1.9 Refererリクエスト・ヘッダー・フィールド

Oracle Web Cacheは、テンプレート・ページに対して、Refererリクエスト・ヘッダー・フィールドが含まれたリクエストをクライアントから受信すると、そのRefererリクエスト・ヘッダー付きのリクエストをオリジン・サーバーに転送します。次に、オリジン・サーバーは、Refererヘッダーに対する値として、テンプレートのURLを付けてOracle Web Cacheにフラグメントを戻します。この機能によって、フラグメント・リクエストとテンプレート・リクエストが関連付けられます。

11.1.10 テンプレート・ページおよびフラグメントのCookieの管理

ESIテンプレートおよびフラグメントを使用する場合のセッションCookieの設定の仕組みは、次のような特徴がある点を除いては、Oracle Web Cacheでの通常のオブジェクトの場合とほとんど同じです。

- Cookieリクエスト・ヘッダー・フィールドの継承
クライアントがフラグメントを含むESIテンプレート・ページをリクエストすると、フラグメント・ページのリクエストがOracle Web Cacheで生成されます。フラグメント・リクエスト内のHostリクエスト・ヘッダー・フィールドの値が、テンプレート・リクエスト内のHostリクエスト・ヘッダー・フィールドの値と一致する場合、フラグメント・リクエストはテンプレート・リクエストからCookieリクエスト・ヘッダー・フィールドを継承します。

- Set-Cookieレスポンス・ヘッダー・フィールドの蓄積
フラグメントのアセンブリが完了すると、Oracle Web Cacheは、レスポンス内のSet-Cookieレスポンス・ヘッダー・フィールドにテンプレートのCookie情報を取り込みます。Hostリクエスト・ヘッダー・フィールドがテンプレートのHostリクエスト・ヘッダー・フィールドと一致するフラグメントの場合、Oracle Web Cacheは、Set-Cookieレスポンス・ヘッダー・フィールドに、テンプレートのSet-Cookieレスポンス・ヘッダー・フィールドの情報を蓄積します。Hostリクエスト・ヘッダー・フィールドがテンプレートのHostリクエスト・ヘッダー・フィールドと一致しないフラグメントの場合、Oracle Web Cacheは、Set-Cookieレスポンス・ヘッダー・フィールドに、テンプレートおよび他の一致するフラグメントのSet-Cookieレスポンス・ヘッダー・フィールドの情報を蓄積しません。

ESIマークアップにおけるHTTP_COOKIE変数の使用方法は、第11.1.6項を参照してください。

11.2 コンテンツの動的アセンブリおよびページの部分的なキャッシュの使用

ページの部分的なキャッシュの概要は、第11.1項を参照してください。

この項では、フラグメントによるWebページの動的アセンブリ、およびキャッシュ可能またはキャッシュ不可のページ・フラグメント用ルールの作成方法について説明します。次のトピックが含まれます:

- 第11.2.1項「ページの部分的なキャッシュの使用」

- 第11.2.2項「単純なパーソナライズでのESIの使用」

- 第11.2.3項「ESIの使用例」

11.2.1 ページの部分的なキャッシュの使用

ページの部分的なキャッシュを使用するには、次の手順を実行します。

1. 次の手順に従って、テンプレート・ページを構成します。

1. フラグメントをフェッチして挿入するには、テンプレート内でESIマークアップ・タグを使用します。

重要
<!-- WEBCACHETAG-->タグおよび<!-- WEBCACHEEND-->タグが含まれているページでは、ESIタグは使用できません。単純なパーソナライズを必要とし、ESIを使用している場合は、第11.2.2項「単純なパーソナライズでのESIの使用」を参照してください。

2. テンプレート・ページで、HTTPレスポンスにSurrogate-Controlレスポンス・ヘッダー・フィールドを設定します。次に例を示します。

Surrogate-Control: max-age=30+60, content="ORAESI/9.0.4"

3. テンプレート・ページに必要なすべてのキャッシュ属性がSurrogate-Controlレスポンス・ヘッダー・フィールドに含まれていない場合は、そのページのキャッシュ・ルールを作成します。

2. フェッチ可能フラグメントを設定します。

- HTTPレスポンス・メッセージに、Surrogate-Controlレスポンス・ヘッダー・フィールドを使用します。

- フラグメントに必要なすべてのキャッシュ属性がSurrogate-Controlレスポンス・ヘッダー・フィールドに含まれていない場合は、そのフラグメントのキャッシュ・ルールを作成します。

詳細は、次を参照してください。

- ESIマークアップ・タグの詳細は、第11.4項を参照してください。

- Surrogate-Controlレスポンス・ヘッダー・フィールドの構成方法の詳細は、第6.10項を参照してください。

- キャッシュ・ルール構成方法の詳細は、第6.8項を参照してください。

11.2.2 単純なパーソナライズでのESIの使用

単純なパーソナライズには変数式を使用できます。

たとえば、次のHTMLでは、クライアントのブラウザからusernameというCookieで渡される値に基づいてユーザー名を置換しています。さらに、sessionIDというCookieに含まれているセッション情報を使用して、セッション情報がユーザーごとに置換されます。

次のESIマークアップにより、同じ結果が得られます。

<esi:vars>
Welcome $(HTTP_COOKIE{'username'})!
Here is a <A HREF="/jsp/myPage.jsp?sessionID=$(QUERY_STRING{'sessionid'})">link</A>.
</esi:vars>

<esi:vars>タグを使用すると、ESIタグの外部でESI環境変数を使用できます。変数は、他のESIタグでも使用可能です。

次の各項を参照してください。

- 第11.1.6項「変数式」

- 第11.4.9項「ESIのvarsタグ」

11.2.3 ESIの使用例

この項では、ESIの使用例を示します。次の項目が含まれます。

- 第11.2.3.1項「ポータル・サイトの実装の例」

- 第11.2.3.2項「変数式を使用した単純なパーソナライズの例」

11.2.3.1 ポータル・サイトの実装の例

図11-2に、Markという登録ユーザーのポータル・サイト・レスポンス・ページhttp://www.company.com/servlet/oportal?username=Markを示します。

図11-2 ポータル・サイト・ページ

「図11-2 ポータル・サイト・ページ」の説明

このページは、Oracle Web Cacheによって組み立てられます。パーソナライズされた挨拶文、気象情報、株式情報、販促広告、ニュースおよびスポーツなどのフラグメントに関してESIマークアップ・タグによって構成されたテンプレート・ページは、Markの環境設定に基づいて組み立てられます。たとえば、Markがサンフランシスコの気象情報を選択すると、アプリケーションはサンフランシスコの気象情報を検索し、その結果を最終的なHTMLページに出力します。これは動的コンテンツなので、このページはキャッシュできません。一方、ESIマークアップ・タグを使用している場合、Oracle Web Cacheで大部分のコンテンツの組立てとキャッシュが行われます。

次の項では、<esi:inline>タグおよび<esi:include>タグを使用してテンプレート・ページやそのフラグメントを実装する方法を説明します。

- 第11.2.3.1.1項「inlineタグを使用したポータルの例」

- 第11.2.3.1.2項「includeタグを使用したポータルの例」

11.2.3.1.1 inlineタグを使用したポータルの例

この項では、<esi:inline>タグの断片化やアセンブリによって、リアルタイム要素が含まれないページの動的コンテンツ・キャッシュの有効性が大幅に向上する仕組みについて説明します。フェッチ不可フラグメントをサポートする既存のアプリケーションに<esi:inline>タグを適用する方法を示します。<esi:inline>タグによりキャッシュ・コンテンツの容量が減少し、動的コンテンツを独立させることでキャッシュ・ヒット率が向上します。

注意:
アプリケーションでそれぞれ別々にフェッチ可能なフラグメントをサポートしている場合、<esi:inline>タグをフェッチ可能なフラグメントに使用するには、fetchable属性をyesに設定します。fetchable属性の詳細は、第11.4.5項を参照してください。

<esi:inline>タグを使用するには、portal.esi内の論理フラグメントを<esi:inline>タグでマークします。パーソナライズされた挨拶文、「Weather Forecast」、「My Stocks」、「Promotion」キャンペーン、「Latest News」および「Latest Sports News」には個別のキャッシュ・プロパティがあり、共有可能なため、これらは必然的にフラグメントとなります。「My Stock」フラグメントは、さらに個別の株価に対応する5つのサブフラグメントに細分されます。さらにフラグメントを最大限共有できるように、2つのパーソナライズされたフラグメントに共通するHTMLコード・セクションをESIフラグメントとして囲み、特定の名前を付けます。これにより、様々なテンプレートに含まれる共通データを最小限に抑えることができます。

例11-6に、<esi:inline>タグ付きのportal.esiを示します。

例11-6 inlineタグ付きのportal.esi

<esi:inline name="/Common_Fragment_1" >
<!-- First common fragment -->
<HTML>
...
<!-- Personalized Greeting With ESI variable -->
Welcome, $(QUERY_STRING{username})!
</esi:inline>

<esi:inline name="/Weathers_San_Francisco" >
...
<!-- Personalized Weather Forecast -->
Weather Forecast for San Francisco
<TABLE>
<TR>
<TD>
Currently: 50F
</TD>
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Common_Fragment_2" >
<!-- Second common fragment -->
...
</esi:inline>

<esi:inline name="/Stocks_$(QUERY_STRING{username})" >
<!-- Personalized Stock Quote Selections -->
<TABLE>
<TR>
<TD>
<esi:inline name="/ticker_IBM">
IBM 84.99
</esi:inline>
<BR>
<esi:inline name="/ticker_ORCL">
ORCL 13.379
</esi:inline>
<BR>
<esi:inline name="/ticker_YHOO">
YHOO 27.15
</esi:inline>
<TD>
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Common_Fragment_3">
<!-- Third common fragment -->
...
</esi:inline>

<esi:inline name="/ExternalAdvertisement">
<!-- External Advertisement -->
<TABLE>
<TR>
<TD>
<a href="http://www.companyad.com/advert?promotionID=126532">
<img src="http://www.companyad.com/advert_img?promotionID=126532">
</a>
</TD>
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Common_Fragment_4">
<!-- Fourth common fragment -->
...
</esi:inline>

<esi:inline name="/Top_News_Finance">
<!-- Personalized Top News -->
Latest News for finance
<TABLE>
<TR>
Tech Spending Growth Indexes Little Changes
Home Sales Hit Record High
Gas Prices Dip Again
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Sports_News_Soccer" >
<!-- Personalized Sports News -->
Latest Sports News for Soccer

<TABLE>
<TR>
Preparation for World Cup
Youth Cup game on a Sunday
Latest Scores
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Common_Fragment_5" >
...
</esi:inline>

例11-7に、パーソナライズされた挨拶文のマークアップを示します。フラグメントは、個々のユーザーに属するすべてのパーソナライズ・ページに共通です。このフラグメントには<esi:inline>タグによって特定の名前が割り当てられるため、たとえばJohnなどの別のユーザーが、同じ名前の同じフラグメントを自身のテンプレートに持つこともあります。2つのフラグメントは、それらの名前が同一である場合に限って共有されます。これにより、すべてのテンプレートに含まれる同一の共有フラグメントが期限切れまたは無効な場合、必要となる更新は1回で済みます。$(QUERY_STRING{username})は、usernameの値へのアクセスを提供するESI環境変数です。この変数がここで使用されているのは、このアプリケーションがusername問合せ文字列パラメータを使用してユーザー名を渡すためです。この変数を使用することにより、最初のフラグメントがすべてのユーザーに共有されます。

例11-7 inlineタグ付きのportal.esiの例: パーソナライズされた挨拶文

<esi:inline name="/Common_Fragment_1" >
<!-- First common fragment -->
<HTML>
...
<!-- Personalized Greeting With ESI variable -->
Welcome, $(QUERY_STRING{username})!
</esi:inline>

例11-8に、「Weather Forecast」のマークアップを示します。フラグメントは各都市に固有です。同じ都市を選択する各テンプレートは、フラグメントのネーミング上、このフラグメントをMarkのページと共有することになります。

例11-8 inlineタグ付きのportal.esiの例: Weather Forecast

<esi:inline name="/Weathers_San_Francisco" >
<!-- Personalized Weather Forecast -->
Weather Forecast for San Francisco
<TABLE>
<TR>
<TD>
Currently: 50F
</TD>
</TR>
</TABLE>
</esi:inline>

例11-9に、「My Stocks」のマークアップを示します。株価フラグメントは、Markのページにあるすべての指定銘柄を囲みます。このフラグメントは、ネストされた<esi:inline>タグを使用して、さらに個別の指定銘柄に対応する5つのサブフラグメントに細分されます。したがって、MarkのESIテンプレートはMarkの選択株フラグメントを参照し、さらに指定銘柄のフラグメントを参照します。指定銘柄は多数のユーザーの選択株フラグメントによって共有されますが、選択株フラグメント自体はMarkの固有のテンプレートでもあります。このマークアップよって固有の情報が共有情報から分離され、キャッシュの更新と個人の選択株に割り当てられる領域を大幅に抑制できます。

例11-9 portal.esiの例: 「My Stocks」フラグメント

<esi:inline name="/Stocks_$(QUERY_STRING{username})" >
<!-- Personalized Stock Quote Selections -->
<TABLE>
<TR>
<TD>
<esi:inline name="/ticker_IBM">
IBM 84.99
</esi:inline>
<BR>
<esi:inline name="/ticker_ORCL">
ORCL 13.379
</esi:inline>
<BR>
<esi:inline name="/ticker_YHOO">
YHOO 27.15
</esi:inline>
<TD>
</TR>
</TABLE>
</esi:inline>

例11-10に、「Promotion」セクションの広告を参照するマークアップを示します。promotionIDは、ユーザー識別情報に基づくIDです。

例11-10 inlineタグ付きのportal.esiの例: Promotion

<esi:inline name="/ExternalAdvertisement">
<!-- External Advertisement -->
<TABLE>
<TR>
<TD>
<a href="http://www.companyad.com/advert?promotionID=126532">
<img src="http://www.companyad.com/advert_img?promotionID=126532">
</a>
</TD>
</TR>
</TABLE>
</esi:inline>

レスポンスのたびに変化する入替式広告は、フェッチ不可ESI <esi:inline>キャッシュを利用する価値がないリアルタイム・コンテンツの一例です。フェッチ不可ESIのinlineフラグメントとしてわずかな部分でもリアルタイム・コンテンツが埋め込まれている場合、常にレスポンス全体を再生成してフェッチする必要があります。このようなリアルタイム・フラグメントにESIおよび動的コンテンツのキャッシュを使用するには、<esi:include>タグを使用します。

リアルタイム広告に<esi:include>タグを使用する例は、第11.2.3.1.2項を参照してください。

「Latest News」および「Latest Sports News」のフラグメントは、気象情報のフラグメントと同様です。共通する領域もすべてフラグメントとして定義されます。これらをテンプレートの一部として残しておくこともできますが、記憶領域を浪費します。例11-11に、マークアップを示します。

例11-11 inlineタグ付きのportal.esiの例: 「Latest News」および「Latest Sports News」

<esi:inline name="/Top_News_Finance">
<!-- Personalized Top News -->
Latest News for finance
<TABLE>
<TR>
Tech Spending Growth Indexes Little Changes
Home Sales Hit Record High
Gas Prices Dip Again
</TR>
</TABLE>
</esi:inline>

<esi:inline name="/Sports_News_Soccer" >
<!-- Personalized Sports News -->
Latest Sports News for Soccer
<TABLE>
<TR>
Preparation for World Cup
Youth Cup game on a Sunday
Latest Scores
</TR>
</TABLE>
</esi:inline>

11.2.3.1.2 includeタグを使用したポータルの例

この項では、<esi:include>タグを使用して、テンプレートにコンテンツが埋め込まれていないフェッチ可能なフラグメントの断片化およびアセンブリを行う方法について示します。

例11-12に、<esi:include>タグ付きのportal.esiを示します。

例11-12 includeタグ付きのportal.esi

<HTML>
...
<!-- Personal Profile -->
<esi:comment text="Profile refers to environment variables stored in
/servlet/GetProfile. GetProfile servlet enables access to a set of environment
variables with personal profile information."/>
<esi:environment src="/servlet/GetProfile?username=$(QUERY_STRING{username})"
name="Profile"/>
...

<!-- Personalized Greeting With ESI variable -->
<esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars>
...

<!-- Personalized Weather Forecast -->
<TABLE>
<TR>
<TD>
<esi:include src="/servlet/Weather?city=$(Profile{city})&state=$(Profile{state})"/>
</TD>
</TR>
</TABLE>
...

<!-- Personalized Stock Quote Selections -->
<TABLE>
<TR>
<TD>
<esi:include src="/servlet/PersonalizedStockSelection?username=$(QUERY_STRING{username})"/>
</TD>
</TR>
</TABLE>
...

<!-- External Advertisement -->
<TABLE>
<TR>
<TD>
<esi:try>
<esi:attempt>
<esi:comment text="Include an ad"/>
<esi:include src="/servlet/Advert"/>
</esi:attempt>
<esi:except>
<esi:comment text="Just write an HTML link instead"/>
<A HREF="http://www.oracle.com">http://www.oracle.com</a>
</esi:except>
</esi:try>
</TD>
</TR>
</TABLE>
...

<!-- Personalized Top News -->
Latest News for <esi:vars>$(Profile{news})</esi:vars>
<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{news}) == 'Internet'">
<esi:include src="/servlet/News?type=Top&topic=internet"/>
</esi:when>
<esi:when test="$(Profile{news}) == 'finance'">
<esi:include src="/servlet/News?type=Top&topic=business"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Top&topic=technology"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>
...

<!-- Personalized Sports News -->
Latest Sports News for <esi:vars>$(Profile{sport})</esi:vars>
<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{sport}) == 'golf'">
<esi:include src="/servlet/News?type=Sports&topic=golf"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'soccer'">
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'basketball'">
<esi:include src="/servlet/News?type=Sports&topic=basketball"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'baseball'">
<esi:include src="/servlet/News?type=Sports&topic=baseball"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>

例11-13では、GetProfileに格納されている環境変数を参照するようにProfileを指定しています。GetProfileは、挿入されるフラグメントのパラメータとして使用されているユーザー・プロファイル変数へのアクセスを可能にします。

例11-13 portal.esiの例: カスタム・プロファイル環境変数の設定

<!-- Personal Profile -->
<esi:comment text="Profile refers to environment variables stored in
/servlet/GetProfile. GetProfile servlet enables access to a set of environment
variables with personal profile information."/>

<esi:environment src="/servlet/GetProfile?username=$(QUERY_STRING{username})"
name="Profile"/>

例11-14に、環境変数city、state、newsおよびsportsへのアクセスを可能にするGetProfileを示します。

例11-14 portal.esiの例: 環境変数付きのGetProfileファイル

<?xml version="1.0"?>
<esi-environment esiversion="ORAESI/9.0.4">
<city>San_Francisco</city>
<state>CA</state>
<news>finance</news>
<sports>soccer</sports>
</esi-environment>

例11-15に、パーソナライズされた挨拶文「Welcome, Mark!」のマークアップを示します。パーソナライズされた挨拶文は、URLに埋め込まれたusernameパラメータに基づいて挨拶文を作成する、<esi:vars>タグによって実現されます。usernameパラメータは、登録ユーザーの名前です。このマークアップは、キャッシュ可能なテンプレート・ページにパーソナライズされた挨拶文を含めることを可能にします。

例11-15 varsタグ付きのportal.esiの例: パーソナライズされた挨拶文

<esi:vars>Welcome, $(QUERY_STRING{username})!</esi:vars>

例11-16に、「Weather Forecast」のマークアップを示します。「Weather Forecast」にはサーブレット・フラグメント名Weatherが含まれます。これは、GetProfile内でユーザーのcityおよびstate環境変数の値を使用して、ユーザーに適切な天気予報を表示します。GetProfileのcity環境変数の値はSan Francisco、state環境変数の値はCaliforniaであるため、カリフォルニア州サンフランシスコの天気予報が表示されます。

例11-16 includeタグ付きのportal.esiの例: Weather Forecast

<TABLE>
<TR>
<TD>
<esi:include src="/servlet/Weather?city=$(Profile{city})&state=$(Profile{state})"/>
</TD>
</TR>
</TABLE>

例11-17に、「My Stocks」のマークアップを示します。「My Stocks」には、PersonalizedStockSelectionというサーブレット・フラグメントが含まれます。表示される株価は、URLにエンコードされたuserIDパラメータに基づきます。userIDは、登録ユーザーの一意のIDです。

例11-17 includeタグ付きのportal.esiの例: 「My Stocks」フラグメント

<TABLE>
<TR>
<TD>
<esi:include src="/servlet/PersonalizedStockSelection?username=$(QUERY_STRING{username})"/>
</TD>
</TR>
</TABLE>

例11-18に、挿入されているフラグメントPersonalizedStockSelectionのマークアップを示します。3つの株価フラグメントIBM、ORCLおよびYHOOが含まれています。

例11-18 portal.esiの例: MarkのPersonalizedStockSelectionフラグメント

<TABLE>
<TR>
<TD>
<BR>
<esi:include src="Quote?symbol=IBM"/>
<BR>
<esi:include src="Quote?symbol=ORCL"/>
<BR>
<esi:include src="Quote?symbol=YHOO"/>
<BR>
</TD>
</TR>
</TABLE>

出力はユーザーごとに異なるため、PersonalizedStockSelectionフラグメントはキャッシュできません。ただし、内部の株価に対するレスポンスはキャッシュ可能で、複数のユーザー間で株価を共有できます。多数のユーザーが株価を共有していても、株価が更新された場合、1回のブラウザの再ロードのみ必要です。たとえば、例11-19に、Scottという別のユーザーのPersonalizedStockSelectionフラグメントを示します。3つの株価フラグメントIBM、ORCLおよびSCOが含まれています。前述のとおり、IBMとORCLはMarkと共有されています。Markが先にページを再ロードして株価をキャッシュすると、ScottのIBMとORCLの株価も自動的に更新されます。

例11-19 portal.esiの例: ScottのPersonalizedStockSelectionフラグメント

<TABLE>
<TR>
<TD>
<BR>
<esi:include src="Quote?symbol=IBM"/>
<BR>
<esi:include src="Quote?symbol=ORCL"/>
<BR>
<esi:include src="Quote?symbol=SCO"/>
<BR>
</TD>
</TR>
</TABLE>

例11-20に、「Promotion」セクションの入替式広告のマークアップを示します。広告は、レスポンスのたびに変化するということで入れ替わるようになっています。Oracle Web Cacheでは、挿入されるイメージ・フラグメントのレスポンスの生成をテンプレート・ページから切り離すことにより、テンプレートをキャッシュしつつ、動的な広告をテンプレートに統合できます。

例11-20 includeタグ付きのportal.esiの例: Promotion

<TABLE>
<TR>
<TD>
<esi:try>
<esi:attempt>
<esi:comment text="Include an ad"/>
<esi:include src="/servlet/Advert"/>
</esi:attempt>
<esi:except>
<esi:comment text="Just write an HTML link instead"/>
<A HREF="www.oracle.com">www.oracle.com</a>
</esi:except>
</esi:try>
</TD>
</TR>
</TABLE>

例11-21に示すように、バナーに挿入されるイメージ・フラグメントのレスポンスはキャッシュできません。ユーザーがこのページをリクエストすると、バナーを生成するリクエストがOracle Web CacheからWebアプリケーション・サーバーに送信されます。Webアプリケーション・サーバーから、Advertサーブレットによってリクエストのバナーが生成されます。

例11-21 portal.esiの例: 入替式バナーの出力

<TABLE>
<TR>
<TD>
<A HREF="http://www.companyad.com/redirect?refID=11934502">
<IMG src="http://www.companyad.com/advert_img?refID=11934502"></A>
</TD>
</TR>
</TABLE>

例11-22に示すように、ユーザーが次にページを再ロードすると、Advertサーブレットによってそのリクエスト用に別のバナーが生成されます。

例11-22 portal.esiの例: 入替式バナーの再ロード

<TABLE>
<TR>
<TD>
<A HREF="http://www.companyad.com/redirect?refID=123456602">
<IMG src="http://www.companyad.com/advert_img?refID=123456602"></A>
</TD>
</TR>
</TABLE>

バナーは、<esi:try>タグの代替処理によって表示されます。Advertサーブレットを実行できない場合は、www.oracle.comへのリンクがバナーの位置に表示されます。

例11-23に、「Latest News」および「Latest Sports News」のマークアップを示します。

- 「Latest News」では、ユーザーがnewsカテゴリでinternet、finance、technologyのいずれを選択したかに基づき、<esi:choose>タグを使用した条件処理によって、ニュース・ヘッドラインが表示されます。GetProfileのnews環境変数値がfinanceであるため、金融関連の/servlet/News?type=Top&topic=businessのヘッドラインが表示されます。

- 同様に「Latest Sports News」では、ユーザーがsportsカテゴリでgolf、soccer、basketball、baseball、soccerのいずれを選択したかに基づき、条件処理によってスポーツ・ヘッドラインが表示されます。GetProfileのsports環境変数値がsoccerであるため、サッカー関連の/servlet/News?type=Sports&topic=soccerのヘッドラインが表示されます。

例11-23 includeタグ付きのportal.esiの例: 「Latest News」および「Sports」セクション

Latest News for <esi:vars>$(Profile{news})</esi:vars>
<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{news}) == 'internet'">
<esi:include src="/servlet/News?type=Top&topic=internet"/>
</esi:when>
<esi:when test="$(Profile{news}) == 'finance'">
<esi:include src="/servlet/News?type=Top&topic=business"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Top&topic=technology"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>
...
<!-- Personalized Sports News -->
Latest Sports News for <esi:vars>$(Profile{sport})</esi:vars>

<TABLE>
<TR>
<TD>
<esi:choose>
<esi:when test="$(Profile{sport}) == 'golf'">
<esi:include src="/servlet/News?type=Sports&topic=golf"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'soccer'">
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'basketball'">
<esi:include src="/servlet/News?type=Sports&topic=basketball"/>
</esi:when>
<esi:when test="$(Profile{sport}) == 'baseball'">
<esi:include src="/servlet/News?type=Sports&topic=baseball"/>
</esi:when>
<esi:otherwise>
<esi:include src="/servlet/News?type=Sports&topic=soccer"/>
</esi:otherwise>
</esi:choose>
</TD>
</TR>
</TABLE>

11.2.3.2 変数式を使用した単純なパーソナライズの例

ESI変数はHTMLタグ内で使用可能です。たとえば例11-24で考えてみます。この例のHTMLコードでは、テキスト・ボックスが含まれるHTMLフォームにPL/SQLが使用されています。

例11-24 パーソナライズされていないPL/SQLコード

htp.p('<form action="test" method="GET">');
htp.p('<table border="0" >
<tr>
<td><input type="text" name="p_name" size="8" value="'||p_name||'"></td>
</tr>
<tr>
<td><input type="submit" value="Search"></td>
</tr>
</table>');

例11-25に、<esi:vars>タグとともに$HTTP_COOKIE変数を使用して、p_nameの値をユーザー名に置換する方法を示します。

例11-25 ESIによるパーソナライズを使用したPL/SQLコード

htp.p('<form action="test" method="GET">');
htp.p('<table border="0" >
<tr><esi:vars>
<td><input type="text" name="p_name" size="8"
value="$(HTTP_COOKIE{'p_name'}"></td>
</tr></esi:vars>
<tr>
<td><input type="submit" value="Search"></td>
</tr>
</table>');

11.3 HTTPレスポンスでのインライン無効化の使用方法

Edge Side Includes(ESI)の一部として実装されるインライン無効化は、オリジン・サーバーに対して、Web Cacheに送信されたトランザクション・レスポンスに無効化メッセージを組み合せる便利な方法を提供します。たとえば、顧客がE-Commerceサイトでベジタリアン向けの料理本を購入した場合、確認レスポンスにその書籍、著者および野菜に関連するすべてのカタログ・ページを無効にする指示を含めることができます。無効化メッセージをインラインで送信する機能により、バンド外無効化の送信に関連する接続オーバーヘッドが軽減されるため、ESI開発者には便利なツールです。

インライン無効化を構成するには、次の手順を実行します。

1. テンプレート・ページで、次のようにcontent="ESI-INV/1.0"を含むSurrogate-Controlレスポンス・ヘッダー・フィールドをHTTPレスポンスで構成します。

Surrogate-Control: content="ESI-INV/1.0"

2. 同じレスポンスのボディで、<esi:invalidate>タグを使用して、基本インライン無効化リクエストまたは拡張インライン無効化リクエストを挿入します。
インライン無効化リクエストは、ESIテンプレートのどの部分にも挿入できます。複数のリクエストを挿入できますが、処理されるのは最初のリクエストのみです。インライン無効化の実行はブロック化します。つまり、ESIテンプレートに他のESI機能が含まれている場合は、インライン無効化が最初に実行されます。

基本無効化の構文を次に示します。

<esi:invalidate [output="yes"]>
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<BASICSELECTOR URI="URL"/>
<ACTION REMOVALTTL="TTL"/>
<INFO VALUE="value"/>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

拡張無効化の構文を次に示します。

<esi:invalidate [output="yes"]>
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="prefix"
URIEXP="URL_expression"
HOST="host_name:port"
METHOD="HTTP_request_method"
BODYEXP="HTTP_body"/>
<COOKIE NAME="cookie_name" VALUE="value"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
<OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
TYPE="SUBSTRING|REGEX"
VALUE="value"/>
</ADVANCEDSELECTOR>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

詳細は、次を参照してください。

- 無効化リクエストの構文は、第7.5.1項を参照してください。

- <esi:invalidate>タグの説明は、第11.4.6項を参照してください。

11.3.1 例: インライン無効化の使用

次に、簡単なWebアプリケーションでインライン無効化を使用する自転車のオンライン・ショップの例を示します。この例では、Perlで書かれた2つのCGIスクリプトを使用します。show_bike.plは、特定モデルの自転車の在庫がどれだけあるかを示します。このスクリプトではデータベースの問合せが行われ、購入が発生するまでその結果が変更されないため、show_bike.plはキャッシュされます。buy_bike.plは自転車を購入する顧客によって使用されます。このページがリクエストされると、show_bike.plは有効ではなくなるため、無効化が必要になります。

例11-26に、show_bike.plのコードを示します。

例11-26 show_bike.plのコード

#!/usr/local/bin/perl

# first, retrieve how many bikes are in stock
# and assign it to $nBikes (omitted!)

print <<END;
Content-Type: text/html
Cache-Control: private
Surrogate-Control: max-age=3600

<html>
<body>
<h1>Bike: model 2005</h1>

<p>There are $nBikes bike(s) in stock for purchase!</p>
<p>Click <a href="/cgi/buy_bike.pl">here</a> to purchase a bike.</p>

</body>
</html>
END

max-age=3600は、このページをキャッシュできる時間が最大1時間であることをOracle Web Cacheに通知します。

例11-27に、インライン無効化リクエストを含むbuy_bike.plのコードを示します。

例11-27 インライン無効化リクエストを含むbuy_bike.plのコード

#!/usr/local/bin/perl

print <<END;
Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more
about this model.</p>

<esi:invalidate>
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<BASICSELECTOR URI="/cgi/show_bike.pl"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

<p>Thanks again!</p>
</body>
</html>
END

Surrogate-Control内のESI-INV/1.0トークンによって、Oracle Web Cacheに<esi:invalidate>タグの処理が指示されます。

例11-28に、buy_bike.plのブラウザ・レスポンスを示します。Oracle Web Cacheでインライン無効化リクエストをすでに処理済であるため、インライン無効化はレスポンス内に存在しません。

例11-28 buy_bike.plのブラウザ・レスポンス

Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more
about this model.</p>

<p>Thanks again!</p>
</body>
</html>

デバッグのヒント

デバッグを容易にするために、アプリケーション開発者は、次を実行できます。

- 次のように、"ESI-INV/1.0"を含むSurrogate-Capabilityリクエスト・ヘッダーを追加します。

Surrogate-Capability: content="ESI-INV/1.0"

インライン無効化でSurrogate-Capabilityリクエスト・ヘッダーが追加されると、Oracle Web Cacheは無効化リクエストをレスポンスに挿入します。

- <esi:invalidate>タグのoutput属性を有効化します。
output属性が有効化されると、Oracle Web Cacheは無効化の結果をコメント<!--result-->で囲んだ状態でレスポンスに挿入します。

例11-29に示すbuy_bike.plのブラウザ・レスポンスでは、Surrogate-Capabilityリクエスト・ヘッダーでインライン無効化が有効になり、<esi:invalidate>タグのoutput属性が有効になっています。

例11-29 インライン無効化の診断情報を含むshow_bike.plのブラウザ・レスポンス

Content-Type: text/html
Cache-Control: private
Surrogate-Control: content="ESI/1.0 ESI-INV/1.0"

<html>
<body>
<h1>Thank you for purchasing bike model 2000.</h1>

<p>Click <a href="/cgi/show_bike.pl">here</a> to read more
about this model.</p>

<esi:invalidate output="yes">
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<OBJECT>
<BASICSELECTOR URI="/cgi/show_bike.pl"/>
<ACTION REMOVALTTL="0"/>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

<!--
<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.1">
<OBJECTRESULT>
<BASICSELECTOR URI="/cgi/show_bike.pl/>
<RESULT ID="1" STATUS="SUCCESS" NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>
-->

<p>Thanks again!</p>
</body>
</html>

11.4 ESIタグの説明

この項では、ページの部分的なキャッシュ処理に使用されるESIタグについて説明します。次のものがあります。

- 第11.4.1項「ESIのchoose | when | otherwiseタグ」

- 第11.4.2「ESIのcommentタグ」

- 第11.4.3項「ESIのenvironmentタグ」

- 第11.4.4項「ESIのincludeタグ」

- 第11.4.5項「ESIのinlineタグ」

- 第11.4.6項「ESIのinvalidateタグ」

- 第11.4.7項「ESIのremoveタグ」

- 第11.4.8項「ESIのtry | attempt | exceptタグ」

- 第11.4.9項「ESIのvarsタグ」

- 第11.4.10項「ESIの<!--esi-->タグ」

11.4.1 ESIの choose | when | otherwiseタグ

<esi:choose>、<esi:when>、<esi:otherwise>の各条件タグにより、ブール式に基づいてロジックを実行することができます。

11.4.1.1 構文

<esi:choose>
<esi:when test="BOOLEAN_expression">
Perform this action
</esi:when>
<esi:when test="BOOLEAN_expression">
Perform this action
</esi:when>
<esi:otherwise>
Perform this other action
</esi:otherwise>
</esi:choose>

11.4.1.2 属性

test: ブール操作を指定します。

11.4.1.3 使用方法

- 各<esi:choose>タグには1つ以上の<esi:when>タグが必要で、オプションで1つの<esi:otherwise>タグを含めることが可能です。

- Oracle Web Cacheでは、test属性がtrueと評価された最初の<esi:when>タグが実行され、その後<esi:choose>タグが終了します。trueと評価される<esi:when>タグがなく、<esi:otherwise>タグが存在する場合は、その要素のコンテンツが実行されます。

- <esi:when>要素または<esi:otherwise>要素内に、他のHTMLまたはESI要素を含めることができます。

11.4.1.4 ブール式

test属性では、trueまたはfalse論理の評価方法を決定するためにブール式を使用します。ESIでは、次のブール演算子をサポートしています。

- ==(等しい)

- !=(等しくない)

- >(より大きい)

- <(未満)

- >=(以上)

- <=(以下)

- &(および)

- |(または)

- !(ではない)

ブール式の使用方法に関して、次の点に注意してください。

- オペランドは、左から右へ対応付けられています。
明示的に関連付けを示すには、式の一部をカッコで囲んでグループ化します。

- 両方のオペランドが数値である場合、式は数式として評価されます。

- いずれかのオペランドが数値以外の場合、いずれのオペランドも文字列として評価されます。たとえば、'a'==3は'a'=='3'と評価され、3は文字列として評価されます。

- 2つのブール式を比較すると、未定義の操作となります。

- オペランドが空または未定義の場合、式は常にfalseと評価されます。

- 論理演算子(&、!、|)は式の修飾に使用しますが、比較には使用できません。

- 定数文字列には一重引用符(')を使用します。たとえば、次の文字列は有効です。

$(HTTP_COOKIE{name})=='typical'

- 一重引用符のエスケープ(\')は使用できません。たとえば、次の例はサポートされていません。

$(HTTP_COOKIE{'user\'s name'})=='typical'

- 算術操作および代入は使用できません。

- null値は、変数が空かどうかを評価します。
数値をnullと比較すると、その数値は対応する文字列に変換され、空の文字列と比較されます。次のESIマークアップでは、$(logindata{name})はnameの値へのアクセスを提供する変数です。nameが空でnullと評価された場合、式はtrueと評価されます。一方、nameが空ではなく、nullと評価されない場合、式はfalseと評価されます。

注意:
変数が存在し、空の文字列と評価された場合、その値はnullとはみなされません。

<esi:choose>
<esi:when test="$(logindata{name}) == null">
<esi:include src=/login/$(logindata{name})"/>
</esi:when>
<esi:otherwise>
<esi:include src=/login/guest.html"/>
<esi:otherwise>
</esi:choose>

次の式に、ブール演算子の正しい使用方法を示します。

!(1==1)
!('a'<='c')
(1==1)|('abc'=='def')
(4!=5)&(4==5)

次の式に、ブール演算子の誤った使用方法を示します。

(1 & 4)
("abc" | "edf")

11.4.1.5 文

文は、<esi:when>サブタグまたは<esi:otherwise>サブタグ内に記述する必要があります。サブタグの外部にある文は、条件として評価されません。例11-30に、文の無効な配置を示します。

例11-30 文の配置

<esi:choose>
This markup is invalid because any characters other than whitespace
are not allowed in this area.
<esi:when test="$(HTTP_HOST) == 'www.company.com'">
<esi:include src="/company.html" />
</esi:when>
This markup is invalid because any characters other than whitespace
are not allowed in this area.
<esi:when test="$(HTTP_COOKIE{fragment) == 'First Fragment'">
<img src="/img/TheImage.gif">
</esi:when>
This markup is invalid because any characters other than whitespace
are not allowed in this area.
<esi:otherwise>
The default selection.
</esi:otherwise>
This markup is invalid because any characters other than whitespace
are not allowed in this area.
</esi:choose>

11.4.1.6 例

次のESIマークアップには、Cookie Advancedを使用するリクエスト用のadvanced.html、およびCookie Basicを使用するリクエスト用のbasic.htmlが含まれています。

<esi:choose>
<esi:when test="$(HTTP_COOKIE{group})=='Advanced'">
<esi:include src="http://www.company.com/advanced.html"/>
</esi:when>
<esi:when test="$(HTTP_COOKIE{group})=='Basic User'">
<esi:include src="http://www.company.com/basic.html"/>
</esi:when>
<esi:otherwise>
<esi:include src="http://www.company.com/new_user.html"/>
</esi:otherwise>
</esi:choose>

11.4.2 ESIのcommentタグ

<esi:comment>タグにより、ESIの指示に関するコメントを出力に表示することなく追加できます。

11.4.2.1 構文

<esi:comment text="text commentary"/>

<esi:comment>は空の要素で、終了タグはありません。

11.4.2.2 使用方法

<esi:comment>タグは、Oracle Web Cacheによって評価されません。コメントをHTML出力で表示するには、標準のXML/HTMLコメント・タグを使用してください。

11.4.2.3 例

次のESIマークアップには、挿入されているGIFファイルに関するコメントが含まれています。

<esi:comment text="the following animation will have a 24 hour TTL"/>
<esi:include src="http://www.company.com/logo.gif" onerror="continue" />

11.4.3 ESIのenvironmentタグ

<esi:environment>タグによって、挿入されたフラグメントのカスタム環境変数を含めることができます。含めた変数は他のESIタグとともに使用できます。

11.4.3.1 構文

このタグには2つの形式があります。最初の形式では、<esi:environment>に終了の</esi:environment>タグが存在しません。

<esi:environment src="environment_URL" name="environment_name"  [max-age="expiration_time [+ removal_time]]" [method="GET|POST"] [onerror="continue"] [timeout="fetch_time"]/>

要素を含む2番目の形式では、<esi:environment>に終了の</esi:environment>タグが存在します。

<esi:environment src="environment_URL" name="environment_name"
[max-age="expiration_time [+ removal_time]"] [method="GET|POST"]
[onerror="continue"] [timeout="fetch_time"]>
[<esi:request_header name="request_header" value="value"/>]
[<esi:request_body value="value"/>]
[<esi:log>log_message</esi:log>]
</esi:environment>

11.4.3.2 属性

- src: 環境変数とその値の取得元となるURLを指定します。
URLは、絶対URLでも、相対URLでも構いません。絶対URLを指定する場合は、次のいずれかの形式を使用します。

- "http://host_name:port/path/filename"

- "https://host_name:port/path/filename"

絶対URLにホスト名を指定する場合は、接頭辞としてhttp://またはhttps://を付加する必要があります。HTMLパーサーでは、次のURL内のhost:80が、ホスト名ではなくフォルダ名として扱われます。

src="host:80/index.htm"

このURLを有効にするには、次のように指定します。

src="http://host:80/index.htm"

相対URLは、テンプレート・ページに対して相対的に解決されます。その結果、現在のテンプレートのESI環境が設定されます。

URLのソース・コードには、次のXML形式が必要です。

<?xml version="1.0"?>
<esi:environment esiversion="ORAESI/9.0.4">
<variable_name>variable_value</variable_name>
<variable_name>variable_value</variable_name>
</esi:environment>

- name: 環境変数の参照に使用する名前を指定します。

- method: 環境フラグメントの HTTPリクエスト・メソッドを指定します。有効な値はGETまたはPOSTです。

- max-age: XMLファイルが期限切れになるまでの時間(秒)を指定します。オプションとして、期限切れになってからXMLファイルが削除されるまでの時間(秒)を指定します。

- timeout: フラグメントをフェッチするまでの時間(秒)を指定します。フラグメントが指定時間内にフェッチされなかった場合、フェッチは中断されます。

- onerror: srcオブジェクトのフェッチが失敗した場合、ESIタグを無視してページを表示するよう指定します。

11.4.3.3 要素

- request_body: フラグメントのHTTPリクエスト・ボディを指定します。

- request_header: 使用するOracle Web CacheのHTTPリクエスト・ヘッダー・フィールドおよび値を指定します。

- log: x-esi-infoログ・フィールドが設定されている場合は、access_log_file.fragmentファイルに挿入するフラグメントのログ・メッセージを指定します。フラグメントとそのフラグメントを生成したアプリケーションを識別する説明的なテキスト文字列を指定できます。説明的なテキストを指定することによって、ログ・ファイル内のフラグメントを簡単に識別でき、フラグメントがリクエストされる頻度を判断できます。

x-esi-infoログ・フィールドの詳細は、表9-5を参照してください。

11.4.3.4 構文の使用方法

- テンプレート・ページごとに1つの<esi:environment>タグを指定してから、他のESIタグを指定します。

- 属性の順序は特に決められていません。

- 複数のrequest_body要素を指定しないでください。

- request_header要素は0(ゼロ)個以上指定できます。
複数のHTTPリクエスト・ヘッダー・フィールドを指定するには、複数のrequest_header要素を使用します。

<esi:environment src="environment_URL"
[max-age="expiration_time [+ removal_time]"][method="GET|POST"]
[onerror="continue"] [timeout="fetch_time"]>
<esi:request_header name="request_header" value="value"/>
<esi:request_header name="request_header" value="value"/>
</esi:environment>

- request_header要素が指定されていない場合、Oracle Web Cacheは親ページから他のリクエスト・ヘッダーを使用します。

- 複数のlog要素を指定しないでください。

詳細は、次を参照してください。

- 変数の使用方法は、第11.1.6項を参照してください。

- max-age、method、onerror、request_bodyおよびrequest_headerの使用時の注意事項は、第11.4.4項を参照してください。

- onerrorの使用時の注意事項は、第11.1.7項を参照してください。

11.4.3.5 例

次のESI出力は、catalog.xmlに格納されている環境変数を参照するlogindataを示しています。ファイルcatalog.xmlにより、挿入されたURLのパラメータとして使用されているvendorID環境変数の値にアクセスできます。

<esi:environment src="/catalog.xml" name="logindata"/>
<esi:include src="http://provider.com/intranetprovider?vendorID=$(logindata{vendorID})"/>

ファイルcatalog.xmlの内容は、次のとおりです。

<?xml version="1.0"?>
<esi:environment esiversion="ORAESI/9.0.4">
<product_description>stereo</product_description>
<vendorID>3278</vendorID>
<partner1>E-Electronics</partner1>
<partner2>E-City</partner2>
</esi:environment>

次のESI出力は、env.datに格納されている環境変数を参照するlogindataを示しています。ファイルenv.datにより、dir1.txtの挿入されたログ・メッセージのパラメータとして使用されているenv環境変数の値にアクセスできます。x-esi-infoログ・フィールドが設定されている場合にフラグメントがリクエストされると、dir1.txtおよびesi-log2.htmlのログ・メッセージがaccess_log.fragmentファイルに書き込まれます。

<esi:environment src="/esi/env.dat" name="env">
<esi:log>Used environment /esi/env.dat</esi:log>
</esi:environment>

<esi:include src="/cached/dir1.txt">
<esi:log>Fragment:/cache/dir1.txt is included, by $(env{xl_name})</esi:log>
</esi:include>

<font color="red">Including /cgi-bin/esi-fetch.sh?/esi/esi-log2.html in esi-log1.html </font>
<esi:include src="/cgi-bin/esi-fetch.sh?/esi/esi-log2.html">
<esi:log>Fragment: /cgi-bin/esi-fetch.sh?/esi/esi-log2.html is included
</esi:log>

11.4.4 ESIのincludeタグ

<esi:include>タグにより、フラグメントの挿入に使用する構文が提供されます。

<esi:inline>と<esi:include>の使用方法の比較は、第11.1.8項を参照してください。

11.4.4.1 構文

このタグには2つの形式があります。最初の形式では、<esi:include>に終了の</esi:include>タグが存在しません。

<esi:include src="URL_fragment" [alt="URL_fragment"]
[max-age="expiration_time [+removal_time]]" [method="GET|POST"] [onerror="continue"] [redirect=yes|no] [timeout="fetch_time"]/>

要素を含む2番目の形式では、<esi:include>に終了の</esi:include>タグが存在します。

<esi:include src="URL_fragment" [alt="URL_fragment"]
[max-age="expiration_time[+removal_time]"] [method="GET|POST"]
[onerror="continue"] [redirect=yes|no] [timeout="fetch_time"]>
[<esi:request_header name="request_header" value="value"/>]
[<esi:request_body value="value"/>]
[<esi:log>log_message</esi:log>]
</esi:include>

11.4.4.2 属性

- src: フェッチするフラグメントのURLを指定します。URLは、リテラル文字列でも変数が含まれていても構いません。
URLは、絶対URLでも、相対URLでも構いません。絶対URLを指定する場合は、次のいずれかの形式を使用します。

- "http://host_name:port/path/filename"

- "https://host_name:port/path/filename"

絶対URLにホスト名を指定する場合は、接頭辞としてhttp://またはhttps://を付加する必要があります。HTMLパーサーでは、次のURL内のhost:80が、ホスト名ではなくフォルダ名として扱われます。

src="host:80/index.htm"

このURLを有効にするには、次のように指定します。

src="http://host:80/index.htm"

相対URLは、テンプレート・ページに対して相対的に解決されます。マークアップ内の要素は挿入された結果に置換されてブラウザに送信されます。

XMLファイルのフラグメントが有効なXMLである場合は、XMLフラグメントを指定できます。次の例では、Oracle Web CacheでXSL Transformation(XSLT)を使用して、スタイル・シートによってXMLをHTMLに変換するように指定しています。スタイル・シートは、XMLフォーマットをHTMLフォーマットにマップします。

<?xml version="1.0"?>
<?xml-stylesheet type="text/xml" href="stylesheet.xsl"?>

XMLフラグメントとXSLスタイル・シートの両方のレスポンス・ページが、テキストとXMLのメディア・タイプを含むContent-Typeレスポンス・ヘッダー・フィールドで構成されていることを確認してください。次に例を示します。

Content-Type: text/xml

XSLTの詳細は、http://www.w3.org/TR/xsltを参照してください。

- alt: srcが見つからない場合に代替リソースを指定します。値の要件はsrcと同じです。

- max-age: フラグメントが期限切れになるまでの時間(秒)を指定します。オプションとして、期限切れになってからフラグメントが削除されるまでの時間(秒)を指定します。この属性は、失効したフラグメントに対するテンプレート・ページの許容値が、フラグメント・レスポンスの有効期限(TTL)パラメータで指定された値よりも高い場合に使用します。

- method: フラグメントのHTTPリクエスト・メソッドを指定します。有効な値はGETまたはPOSTです。

- onerror: srcオブジェクトのフェッチが失敗した場合、ESIタグを無視してページを表示するよう指定します。

- redirect: srcフラグメントが一時的に異なるURLにある場合に、そのフラグメントの表示方法を指定します。yesを指定すると、そのURLがリダイレクトされて表示されます。noを指定すると、そのフラグメントのURLはリダイレクトされず、HTTPの302 Foundステータス・コードがフラグメントのかわりに表示されます。デフォルトはyesです。

- timeout: フラグメントをフェッチするまでの時間(秒)を指定します。フラグメントが指定時間内にフェッチされなかった場合、フェッチは中断されます。
altおよびonerrorの使用時の注意事項は、第11.1.7項を参照してください。

11.4.4.3 要素

- request_body: フラグメントのHTTPリクエスト・ボディを指定します。

- request_header: Oracle Web Cacheが使用するHTTPリクエスト・ヘッダーフィールドおよび値を指定します。複数のHTTPリクエスト・ヘッダーを指定できます。この属性を指定すると、親フラグメントまたはテンプレート・ページからのリクエスト・ヘッダーはすべて無視されます。

- log: x-esi-infoログ・フィールドが設定されている場合は、access_log.fragmentファイルに挿入するフラグメントのログ・メッセージを指定します。フラグメントとそのフラグメントを生成したアプリケーションを識別する説明的なテキスト文字列を指定できます。説明的なテキストを指定することによって、ログ・ファイル内のフラグメントを簡単に識別でき、フラグメントがリクエストされる頻度を判断できます。
x-esi-infoログ・フィールドの詳細は、表9-5を参照してください。

11.4.4.4 構文の使用方法

- <esi:include>では、最大3レベルのネストをサポートしています。

- <esi:include>では、二重引用符のエスケープ(\")をサポートしていません。たとえば、次の例はサポートされていません。

<esi:include src="file\"user.htm"/>

- 属性の順序は特に決められていません。

- src属性は、HTTPとHTTPSの両方をサポートしています。Oracle Web Cacheでは、テンプレートとフラグメントに異なるプロトコルの使用を許可しています。次のことに注意してください。

- src属性で、src="/PersonalizedGreeting"のようにフラグメントの相対パスが指定されている場合は、テンプレートのプロトコルが使用されます。

- src属性で使用されているプロトコルが、Oracle Web Cache Managerの「Site-to-Server Mapping」ページ(「Origin Servers, Sites, and Load Balancing」→「Site-to-Server Mapping」)で指定されたプロトコルと一致しない場合、Oracle Web Cacheは「Site-to-Server Mapping」ページでオリジン・サーバー用に設定されたプロトコルを使用します。さらに、Oracle Web Cacheは、次の警告メッセージをイベント・ログに記録します。

[Date] [warning 11250] [ecid: request_id, serial_number]
ESI include fragment protocol does not match origin server protocol:
Origin Server Protocol=protocol URL=URL

たとえば、テンプレート・ページで<esi:include> src="https://www.company.com:80/gifs/frag1.gif"/>と構成され、かつサイトからサーバーへのマッピングでHTTPがオリジン・サーバーに指定されている場合は、http://www.company.com:80/gifs/frag1.gifが使用され、次のメッセージがイベント・ログに記録されます。

[03/Feb/2005:23:16:46 +0000] [warning 11250] [ecid: 90125204378,0]
ESI include fragment protocol does not match origin server protocol:
Origin Server Protocol=http URL=https://www.company.com:80/gifs/frag1.gif

- 複数のrequest_body要素を指定しないでください。

- request_header要素は0(ゼロ)個以上指定できます。

- 複数のHTTPリクエスト・ヘッダー・フィールドを指定するには、複数のrequest_header要素を使用します。

<esi:include src="URL_fragment"
[max-age="expiration_time[+removal_time]"] [method="GET|POST"]
[onerror="continue"] [timeout="fetch_time"]>
<esi:request_header name="request_header" value="value"/>
<esi:request_header name="request_header" value="value"/>
</esi:include>

- 複数のlog要素を指定しないでください。

11.4.4.5 使用方法

<esi:include>タグにより、src属性で指定されているフラグメントをフェッチするよう、Oracle Web Cacheに指示します。

処理が正しく実行されると、srcで指定されたURLからフェッチされたコンテンツが表示されます。オブジェクトは、includeタグの場所に挿入されます。たとえば、includeタグが表セル内に存在する場合、フェッチされたオブジェクトは表セル内に表示されます。

Surrogate-Controlレスポンス・ヘッダー・フィールドのmax-age制御ディレクティブはレスポンスに適用されます。max-age属性は、<esi:include>タグを介して、特定の使用方法のフラグメント・レスポンスにのみ適用されます。Surrogate-Controlレスポンス・ヘッダー・フィールドのmax-age制御ディレクティブおよびmax-age属性の両方が設定されている場合、この特定の組込みに適用される有効期限および削除期限は、それぞれ長い方の有効期限および削除期限となります。失効したフラグメントに対する特定ページの許容値が高い場合は、max-age属性をmax-age制御ディレクティブより長い値に設定します。max-age属性を使用して、削除時間までフラグメントを無効化した状態で表示することにより、キャッシュ・ヒット率を高めます。max-age=infinityは、オブジェクトを期限切れにしないようにする指定です。

methodが設定されていない場合は、GETとみなされます。ただし、request_body要素が設定されている場合は、POSTとみなされます。

Oracle Web Cacheにより、すべてのフラグメント・リクエストに次のHTTPリクエスト・ヘッダーが生成されます。

- Host

- Content-Length

- Surrogate-Capability

- Connection

request_header要素を使用すると、上記以外のHTTPヘッダーを制御できます。競合が発生してOracle Web Cacheの動作に影響することがあるため、これらのHTTPリクエスト・ヘッダーをrequest_header属性として指定しないでください。

request_header要素が指定されていない場合、Oracle Web Cacheは親ページから他のリクエスト・ヘッダーを使用します。

<esi:inline>と<esi:include>の使用方法の比較は、第11.1.8項を参照してください。

11.4.4.6 例

次のESIマークアップには、frag1.htmというファイルが含まれています。フラグメントは60秒以内にフェッチされます。フェッチに失敗した場合、Oracle Web Cacheはincludeを無視し、ページを表示します。フェッチに成功した場合、Oracle Web Cacheはフラグメントを挿入します。Oracle Web Cacheによってフラグメントは5分後に期限切れになり、さらに8分後に削除されます。

<esi:include src="/frag1.htm" timeout="60" maxage="300+480" onerror="continue"/>

次のESI出力には、動的問合せの結果が含まれます。

<esi:include src="/search?query=$QUERY_STRING(query)"/>

次のESI出力には、パーソナライズされた挨拶文、Cookie HTTPリクエスト・ヘッダーおよび日付を含むHTTPリクエスト・ボディが含まれます。x-esi-infoログ・フィールドが設定されている場合にフラグメントがリクエストされると、ログ・メッセージ"Fragment: /Personalized Greeting is included"がaccess_log.fragmentファイルに書き込まれます。

<esi:include src="/PersonalGreeting">
<esi:request_header name="Cookie" value="pname=Scott Tiger"/>
<esi:request_body value="day=05, month=10, year=2001"/>
<esi:log>Fragment: /Personalized Greeting is included</esi:log>
</esi:include>

<esi:include>の具体的な使用例は、第11.2.3.1項を参照してください。

11.4.5 ESIのinlineタグ

<esi:inline>タグは、フラグメントを、別のオブジェクトのHTTPレスポンスに埋め込まれる個別にキャッシュ可能なフラグメントとしてマークします。Oracle Web Cacheでは、これらのフラグメントを独立した<esi:include>フラグメントとして格納し、組み立てます。

<esi:inline>と<esi:include>の使用方法の比較は、第11.1.8項を参照してください。

11.4.5.1 構文

<esi:inline name="URL" fetchable="yes|no"
[max-age="expiration_time [+ removal_time]"] [timeout="fetch_time"]
Embedded HTML code
</esi:inline>

11.4.5.2 属性

- name: フラグメントに一意の名前をURL形式で指定します。

- fetchable: yesの場合、フラグメントが期限切れになると、Oracle Web Cacheはフラグメントをオリジン・サーバーからフェッチします。このフェッチ・プロセスでは、フラグメント用のテンプレートは挿入されません。noの場合、Oracle Web Cacheは、キャッシュ・ミスがあったときにテンプレート全体をオリジン・サーバーからフェッチし、テンプレートからすべてのフラグメントを抽出しようとします。

- max-age: フラグメントが期限切れになるまでの時間(秒)を指定します。オプションとして、期限切れになってからフラグメントが削除されるまでの時間(秒)を指定します。この属性は、失効したフラグメントに対するテンプレート・ページの許容値が、フラグメント・レスポンスの有効期限(TTL)パラメータで指定された値よりも高い場合に使用します。

- timeout: フラグメントをフェッチするまでの時間(秒)を指定します。フラグメントが指定時間内にフェッチされなかった場合、フェッチは中断されます。

11.4.5.3 使用方法

一部のinlineフラグメントは、他のオブジェクトのHTTPレスポンスの一部としてのみ配信されます。Oracle Web Cacheでは、これらのフラグメントを<esi:include>フラグメントのように個々にフェッチすることはできません。フェッチ不可のフラグメントがOracle Web Cacheで必要な場合、inlineフラグメントが抽出されたオブジェクトをリクエストする必要があります。

フェッチ不可の<esi:inline>フラグメントがキャッシュ内で見つからない場合、フラグメントの親テンプレートがOracle Web Cacheによって再フェッチされます。この動作は、親テンプレートがさらにフェッチ不可な<esi:inline>フラグメントであってはならないということを意味します。親もフェッチ不可の<esi:inline>フラグメントであった場合、ブラウザに返されるレスポンスは未定義になります。

詳細は、次を参照してください。

- 第11.1.8.1項

- 第11.1.8.2項

- 第11.4.4項

11.4.5.4 例

次のESIの出力には、金融のヘッドラインが埋め込まれています。

<esi:inline name="/Top_News_Finance">
Latest News for Finance
<TABLE>
<TR>
Blue-Chip Stocks Cut Losses; Nasdaq Up MO
French rig factory with explosives New York Times
Volkswagen faces Brazil strike CNN Europe
Airbuss reliability record BBC
</TR>
</TABLE>
</esi:inline>

<esi:inline>の具体的な使用例は、第11.2.3.1項を参照してください。

11.4.6 ESIのinvalidateタグ

<esi:invalidate>タグを使用すると、ブラウザ・ページのレスポンス内に無効化リクエストを構成できます。

11.4.6.1 構文

基本無効化の構文を次に示します。

<esi:invalidate [output="yes"]>
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<BASICSELECTOR URI="URL"/>
<ACTION REMOVALTTL="TTL"/>
<INFO VALUE="value"/>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

拡張無効化の構文を次に示します。

<esi:invalidate [output="yes"]>
<?xml version="1.0"?>
<!DOCTYPE INVALIDATION SYSTEM "internal:///WCSinvalidation.dtd">
<INVALIDATION VERSION="WCS-1.1">
<SYSTEM>
<SYSTEMINFO NAME="name" VALUE="value"/>
</SYSTEM>
<OBJECT>
<ADVANCEDSELECTOR URIPREFIX="prefix"
URIEXP="URL_expression"
HOST="host_name:port"
METHOD="HTTP_request_method"
BODYEXP="HTTP_body"/>
<COOKIE NAME="cookie_name" VALUE="value"/>
<HEADER NAME="HTTP_request_header" VALUE="value"/>
<OTHER NAME="URI|BODY|QUERYSTRING_PARAMETER|SEARCHKEY"
TYPE="SUBSTRING|REGEX"
VALUE="value"/>
</ADVANCEDSELECTOR>
<ACTION REMOVALTTL="TTL"/>
<INFO VALUE="value"/>
</OBJECT>
</INVALIDATION>
</esi:invalidate>

11.4.6.2 属性

- output: yesを指定すると、無効化の結果がコメント<!--result-->に囲まれてブラウザ・レスポンスに含まれます。noを指定すると、無効化の結果は出力に表示されません。テスト環境では値yesを、本番環境では値noを指定します。

11.4.6.3 使用方法

第11.3項を参照してください。

11.4.6.4 例

第11.3.1項を参照してください。

11.4.7 ESIのremoveタグ

<esi:remove>タグを使用すると、Surrogate-ControlヘッダーでESI処理が使用可能になっていない場合、またはESI対応のキャッシュが存在しない場合に、ESI以外のマークアップによる出力を指定できます。

11.4.7.1 構文

<esi:remove> HTML output...</esi:remove>

11.4.7.2 使用方法

このタグには、別の<esi:remove>タグ以外のあらゆるHTMLまたはESI要素を含めることが可能です。ネストされたESIタグは処理されないため、注意してください。

11.4.7.3 例

次のESIマークアップでは、<esi:include>コンテンツを挿入できない場合にhttp://www.company.comを挿入します。

<esi:include src="http://www.company.com/ad.html"/>
<esi:remove>
<A HREF="http://www.company.com">www.company.com</A>
</esi:remove>

通常、Oracle Web Cacheは、この例のブロックを処理する際に、ad.htmlファイルをフェッチしてテンプレート・ページに挿入し、<esi:remove>タグとそのコンテンツを暗黙的に破棄します。ESI処理が使用不可の場合、すべての要素がブラウザに渡され、ブラウザによりESIマークアップが無視されます。ただし、ブラウザにより、<A HREF=...> HTMLリンクが表示されます。

11.4.8 ESIのtry | attempt | exceptタグ

<esi:try>タグは例外処理に使用します。<esi:try>タグには、<esi:attempt>タグが1つ、<esi:except>タグが1つ以上含まれている必要があります。altおよびonerrorの使用時の注意事項は、第11.1.7項を参照してください。

11.4.8.1 構文

次の形式では、<esi:except>タグが1つだけサポートされます。

<esi:try>
<esi:attempt>
Try this...
</esi:attempt>
<esi:except>
If the attempt fails, then perform this action...
</esi:except>
</esi:try>

次の形式では、タイプの異なる複数の<esi:except>タグがサポートされます。

<esi:try>
<esi:attempt>
Try this...
</esi:attempt>
<esi:except [type="type"]>
If the attempt fails, then perform this action...
</esi:except>
<esi:except [type="type"]>
Perform this action...
</esi:except>
<esi:except>
If the attempt fails, then perform this action...
</esi:except>
</esi:try>

11.4.8.2 使用方法

Oracle Web Cacheにより、最初に<esi:attempt>のコンテンツが処理されます。<esi:attempt>に失敗すると、エラーがトリガーされ、Oracle Web Cacheによって<esi:except>タグのコンテンツが処理されます。

一般的なエラーについてはタイプなしで<esi:except>タグを、特定のエラーについてはタイプとともに<esi:except>タグを指定します。<esi:except>タグには、次のタイプを指定できます(大文字小文字の区別はありません)。

- nestingtoodeep: フラグメントの組込み深度が最大組込み深度を超えた場合に発生するエラー。

- originserverbusy: そのフラグメントのオリジン・サーバーがビジー状態で、新規リクエストを受け入れることができないために発生するエラー。このエラーが発生するのは、Oracle Web Cacheからオリジン・サーバーへのリクエストのキューが限界に達したときです。

- noconnection: キャッシュがそのフラグメントを処理するオリジン・サーバーに接続できないために発生するエラー。

- networktimeout: オリジン・サーバーへのフラグメント・リクエストがネットワーク接続中にタイムアウトしたために発生するエラー。

- httpclienterror: オリジン・サーバーが、HTTP 4xxステータス・コードを返すために発生するエラー(不正なHTTPリクエストや権限のないアクセスなどのクライアント・エラー)。

- httpservererror: オリジン・サーバーがHTTP 5xxステータス・コードを返すために発生するエラー(サーバー・エラー)。

- incompatiblefragmentversion: フラグメントの処理要件がサポートされていないかテンプレートとの互換性がないために発生するエラー。ESIフラグメントの<!-- WEBCACHETAG-->および<!-- WEBCACHEEND-->の処理にはESI処理との互換性はありません。フラグメントが、キャッシュ内での処理を必要としないプレーン・データであるか、このリリースでサポートされているESI機能の処理を必要とするESIテンプレート自体の可能性があります。使用するESI機能は、Surrogate-Control content制御ディレクティブで指定されています。

- incorrectresponseheader: フラグメントのレスポンス・ヘッダーが原因で発生するエラー。

- incorrectesifragment: Oracle Web CacheでESIフラグメント・レスポンスのボディのエラーを解析または処理しようとしたときに発生するエラー。

- incorrectxmlfragment: Oracle Web CacheによるXSLTの取得、解析、または処理にエラーがあった場合に発生するエラー。

11.4.8.3 例

次のESIマークアップでは、広告のフェッチを試みています。広告を挿入できない場合、Oracle Web Cacheにより、かわりに静的リンクが挿入されます。

<esi:try>
<esi:attempt>
<esi:comment text="Include an ad"/>
<esi:include src="http://www.company.com/ad1.htm"/>
</esi:attempt>
<esi:except>
<esi:comment text="Just write some HTML instead"/>
<a href=www.company.com>www.company.com</a>
</esi:except>
</esi:try>

次のESIマークアップでは、フラグメントのフェッチを試みています。フラグメントがhttpclienterrorのために挿入できない場合、Oracle Web Cacheでは、/cgi-bin/esi-fetch?/esi/tryNestL1.htmlをかわりに挿入します。

<esi:try>
<esi:attempt>
<esi:include src="/frag.html"/>
</esi:attempt>
<esi:except type="httpclienterror">
<esi:include src="/cgi-bin/esi-fetch?/esi/tryNestL1.html"/>
</esi:except>
</esi:try>

次の<esi:try>では、複数のHTTPリクエスト・ヘッダーを含むフラグメントhttp://server.portal.com/pls/ppcdemo/!PCDEMO.wwpro_app_provider.execute_portlet/513104940/26の挿入を試みています。様々なtypeエラーが原因でフラグメントを挿入できない場合、Oracle Web Cacheでは、Unknown ESI Exceptionエラーを返します。

<esi:try>
<esi:attempt>
<esi:include src="http://server.portal.com/pls/ppcdemo/!PCDEMO.wwpro_app_provider.execute_portlet/513104940/26" timeout="15000" >
<esi:request_header name="X-Oracle-Device.MaxDocSize" value="0"/>
<esi:request_header name="Accept"
value="text/html,text/xml,text/vnd.oracle.mobilexml"/>
<esi:request_header name="User-Agent"
value="Mozilla/4.0 (compatible; MSIE 5.5; Windows; YComp 5.0.0.0)
RPT-HTTPClient/0.3-3"/>
<esi:request_header name="Device.Orientation" value="landscape"/>
<esi:request_header name="Device.Class" value="pcbrowser"/>
<esi:request_header name="PORTAL-SUBSCRIBER" value="us"/>
<esi:request_header name="Device.Secure" value="false"/>
<esi:request_header name="PORTAL-SUBSCRIBER-DN"
value="dc=us,dc=oracle,dc=com"/>
<esi:request_header name="PORTAL-SUBSCRIBER-GUID"
value="A5EE385440E6252BE0340800208A8B00"/>
<esi:request_header name="Accept-Language" value="en-us"/>
<esi:request_header name="PORTAL-USER-DN"
value="cn=public,cn=users,dc=us,dc=oracle,dc=com"/>
<esi:request_header name="PORTAL-USER-GUID"
value="A5EE55B396E22651E0340800208A8B00"/>
<esi:request_header name="Content-Type"
value="application/x-www-form-urlencoded"/>
</esi:include>
</esi:attempt>
<esi:except type="incompatiblefragmentversion" >
This happens when a fragment's processing requirement is not supported
or not compatible with the template.
</esi:except>
<esi:except type="noconnection" >
The cache is unable to connect to the origin server serving this fragment.
</esi:except>
<esi:except type="nestingtoodeep" >
The fragment include depth has exceeded the maximum include depth. The
default value defined in Web Cache is 3.
</esi:except>
<esi:except type="httpservererror" >
The origin server returns an HTTP 5xx status code, a server error.
</esi:except>
<esi:except type="httpclienterror" >
The origin server returns an HTTP 4xx status code, a client error, such as
a malformed HTTP request or an unauthorized access.
</esi:except>
<esi:except type="incorrectresponseheader" >
This happens when the response headers for a fragment cause the error.
</esi:except>
<esi:except type="incorrectxmlfragment" >
This happens when there is any kind of error in Oracle Web Cache XSLT
retrieval, parsing, or processing.
</esi:except>
<esi:except type="originserverbusy" >
The origin server for this fragment is busy and cannot accept new requests
now. This is caused by Oracle Web Cache-to-origin server request queue
limit.
</esi:except>
<esi:except type="networktimeout" >
This is thrown by a fragment whose request to the origin server has timed
out in the network connection.
</esi:except>
<esi:except type="incorrectesifragment" >
An error is encountered when Oracle Web Cache tries to parse or process
the ESI fragment response body due to errors in the body.
</esi:except>
<esi:except>
Unknown ESI Exception
</esi:except>
</esi:try>

11.4.9 ESIのvarsタグ

<esi:vars>タグを使用すると、ESIタグの外部で変数を使用できます。たとえば、<esi:include>または<esi:choose>ブロック内で変数を指定するかわりに、<esi:vars>タグを使用して、HTMLコード内で変数を指定できます。

11.4.9.1 構文

<esi:vars>Optional HTML code $(VARIABLE_NAME{key}) Optional HTML code</esi:vars>

11.4.9.2 構文の使用方法

- 変数に完全な$(VARIABLE_NAME{key})形式が使用されていない場合、Oracle Web Cacheでは、次のエラー・メッセージがイベント・ログに記録されます。

[Date] [error 12086] [ecid: request_id, serial_number]ESI syntax error. Unrecognized keyword keyword is at line line.

- <esi:vars>タグは、HTMLコードの行内でネストしないでください。次に誤った構文の例を示します。

HTML code <esi:vars>$(VARIABLE_NAME{key})</esi:vars>HTML code

たとえば、次の例は無効です。

<IMG SRC="http://www.example.com/<esi:vars>$(HTTP_COOKIE{type})</esi:vars>/hello.gif"/>

11.4.9.3 使用方法

HTTPリクエスト変数およびカスタム変数の使用方法は、第11.1.6項および第11.4.3項を参照してください。

11.4.9.4 例

次のESIマークアップには、挿入されたURLの一部として、Cookieのtypeとその値が含まれています。

<esi:vars>
<IMG SRC="http://www.example.com/$(HTTP_COOKIE{type})/hello.gif"/>
</esi:vars>

次のESI出力は、「ようこそ」ページへの<A HREF=...>リンクの一部としてlogindataを参照しています。logindataは、カスタム環境変数を含むXMLファイルを参照します。出力には、他の<A HREF=...>リンクの一部として、ユーザーのsessionIDおよびカテゴリtypeのCookie値も含まれています。

<esi:vars>
<A HREF="welcome.jsp?name=$(logindata{name})">
<A HREF="/shopping.jsp?sessionID=$(QUERY_STRING{sessionID})&type=$(QUERY_STRING{type})">
<IMG SRC="/img/shopping.gif">
</A>
<A HREF="/news.jsp?sessionID=$(QUERY_STRING{sessionID})&type=$(QUERY_STRING{type})">
<IMG SRC="/img/news.gif">
</A>
<A HREF="/sports.jsp?sessionID=$(QUERY_STRING{sessionID})&type=$(QUERY_STRING{type})">
<IMG SRC="/img/sports.gif">
</A>
<A HREF="/fun.jsp?sessionID=$(QUERY_STRING{sessionID})&type=$(QUERY_STRING{type})">
<IMG SRC="/img/fun.gif">
</A>
<A HREF="/about.jsp?sessionID=$(QUERY_STRING{sessionID})&type=$(QUERY_STRING{type})">
<IMG SRC="/img/about.gif">
</A>
</esi:vars>

11.4.10 ESIの<!--esi-->タグ

<!--esi...--->タグにより、ESIタグでマークアップされているHTMLが、ESIタグを処理せずにブラウザに表示されます。このタグを使用したページが処理される際に、Oracle Web Cacheでは、開始の<!--esi要素と終了の-->要素を削除しながらページのコンテンツが処理されます。マークアップを処理できない場合は、このタグにより、ESIマークアップがHTMLの最終出力に影響しないことが保証されます。

11.4.10.1 構文

<!--esi
ESI elements
-->

11.4.10.2 使用方法

このタグには、他の<!--esi...-->タグ以外のあらゆるESIまたはHTML要素を含めることが可能です。

11.4.10.3 例

In the following ESI markup, the <!--esi and --> are removed in the final
output. The output displays the content generated by <p><esi:vars>Hello, $(HTTP_COOKIE{name})!</esi:vars></p>,
plus any surrounding text.

<!--esi
<p><esi:vars>Hello, $(HTTP_COOKIE{name})!</esi:vars></p>
-->

ESIマークアップを処理できない場合は、<p><esi:vars>Hello, $(HTTP_COOKIE{name})!</esi:vars></p>がHTML出力に表示されます。

12 サード・パーティ・アプリケーション・サーバーでのキャッシュ

この章では、サード・パーティのWebアプリケーション・サーバーでOracle Web Cacheを構成する方法について説明します。

この章の項目は次のとおりです。

- 第12.1項「サード・パーティ・アプリケーション・サーバーの概要」

- 第12.2項「IBM WebSphere」

- 第12.3項「Apache Tomcat」

- 第12.4項「Microsoft IIS」

注意:

- この章では、Oracle Web Cacheが3種類のサーバーと連携する仕組みについて説明しますが、Oracle Web CacheはHTTPに準拠しているどのWebアプリケーション・サーバーとも連携可能です。

- サード・パーティ・サーバーとの連携の説明として例にあげられているアプリケーションは比較的単純なものです。実用アプリケーションで使用する場合は、Oracle Web Cacheをより幅広く構成する必要があります。アプリケーションの設計の詳細は、サード・パーティのWebアプリケーション・サーバーのマニュアルを参照してください。

12.1 サード・パーティ・アプリケーション・サーバーの概要

Oracle Web CacheはWebアプリケーション・サーバーに対して透過的であるため、Webアプリケーション・サーバーは、Oracle Web CacheからのHTTPリクエストを、ブラウザから直接送信される他のHTTPリクエストと同じように処理します。次にWebアプリケーション・サーバーはレスポンスを生成し、HTTPメッセージとしてOracle Web Cacheに返します。

Oracle Web Cacheは、HTTPを完全にサポートしているため、HTTPに準拠しているすべてのWebアプリケーション・サーバーとの連携が可能です。Webアプリケーション・サーバーがHTTPレスポンスを生成するかどうかの選択方法は、Oracle Web Cacheとは関係ありません。

サイトが使用するWebアプリケーション・サーバーのタイプは、主にそのサイトが実行しているアプリケーションのタイプに依存します。たとえば、顧客がActive Server Page(ASP)を実行する場合は、Microsoft Internet Information Server(IIS)をWebアプリケーション・サーバーとして選択します。

- 第12.1.1項「Webサイトの構成」

- 第12.1.2項「キャッシュ・ルールと有効期限ルール」

12.1.1 Webサイトの構成

Oracle Web Cacheを、Oracle HTTP Serverの場合と同じように、ホスト名とリスニング・ポート番号を指定してサード・パーティのWebアプリケーション・サーバーと通信するように構成します。この章で説明する製品のデフォルトのリスニング・ポートを、表12-1に示します。

表12-1 サード・パーティのWebアプリケーション・サーバーのデフォルトのリスニング・ポート

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

ポート

IBM WebSphere Application Serverバージョン6.0

80

Apache Tomcatバージョン4.1

8080

Microsoft IIS 6.0

80

Oracle Web Cacheをサード・パーティのWebアプリケーション・サーバーと通信するように構成するには、次の作業を行います。

1. Oracle Web Cacheのポート設定を変更する方法は、第2.11.1項を参照してください。

2. Webアプリケーション・サーバーの設定を構成する方法は、第2.11.2項を参照してください。

3. Webサイトの設定を構成する方法は、第2.11.3項および第2.11.4項を参照してください。

12.1.2 キャッシュ・ルールと有効期限ルール

サード・パーティのWebアプリケーション・サーバーをOracle HTTP Serverと同様に使用する場合は、キャッシュ・ルールと有効期限ルールを割り当てます。次のようなコンテンツをキャッシュするかどうかを選択できます。

- 静的オブジェクト

- 同じURLの複数バージョンのオブジェクト

- セッションCookieまたは埋込みURLパラメータをサポートしているページ

- 単純なパーソナライズを含むページ

- Edge Side Includes(ESI)フラグメントの動的アセンブリ

任意のタイミングで、オブジェクトに有効期限を割り当てたり、オブジェクトを無効化したりすることもできます。第6章「コンテンツのキャッシュと圧縮」および第7章「コンテンツの無効化」を参照してください。

12.2 IBM WebSphere

Oracle Web Cacheで、IBM Websphere Application Serverからの静的コンテンツがフェッチされるときに、IBM Websphere Application Serverからは、Oracle Web CacheのSurrogate-Capability: orcl="ESI/1.0"リクエストに対するレスポンスとしてSurrogate-Controlレスポンス・ヘッダー内のcontent="ESI/1.0+"ディレクティブが送信されます。Oracle Web Cacheでは、ページ・レンダリングの問題およびエラーを排除するためにESI/1.0+機能が無視されます。Oracle Web Cacheがキャッシュ・ソリューションとして配置されている場合、制御ディレクティブの値がこのように異なることによって、Webアプリケーションが未定義の動作を起こす可能性があります。

次の手順に従って、IBM Websphere Application ServerからESI/1.0以前ではなくESI/1.0が送信されるようにします。

1. WebSphere Application Serverの管理コンソールで、「Servers」→「Application Server」にナビゲートします。
「Application servers」ページが表示されます。

2. 「Application servers」ページで、server1アプリケーション・サーバーを選択します。
server1は、IBM Websphere Application Serverをデフォルトのオプションでインストールするときのサーバー名です。他の名前を指定した場合は、その名前を選択します。

3. 「Configuration」タブの「Server Infrastructure」セクションで、「Java and Process Management」を選択し、「Process Definition」を選択します。

4. 「Additional Properties」セクションで、「Java Virtual Machine」を選択してから「Custom Properties」を選択します。

5. 「New」をクリックしてエントリを作成します。

6. 「Name」フィールドに、com.ibm.servlet.file.esi.controlと入力します。

7. 「Value」フィールドに、max-age=300, cacheid="URL", content="ESI/1.0"と入力します。

8. 「Apply」をクリックしてから、WebSphere Application Serverを保存して再起動します。

WebSphere Application Serverのインストールには、JSP、JavaサーブレットおよびEJBのサンプルが含まれています。この項では、次のコンテンツをキャッシュするようにOracle Web Cacheを構成する方法について説明します。

- 第12.2.1「WebSphere Snoopサーブレット」

- 第12.2.2「WebSphere Calendar Creator JSP」

12.2.1 WebSphere Snoopサーブレット

snoopサーブレットは、ブラウザにより送信されるリクエスト情報、ヘッダーおよびパラメータの取得および使用を表示します。これを使用して、Oracle Web Cacheが動的コンテンツをキャッシュする方法を説明します。

snoopサーブレットをキャッシュするには、次の手順を実行します。

1. 第12.1.1項の説明に従って、Oracle Web CacheがWebSphere Application Serverと通信するように構成されていることを確認します。

2. WebSphere Application Serverを起動し、次のURLにアクセスします。

http://hostname/snoop

ブラウザにより送信されたリクエスト情報、ヘッダーおよびパラメータが表示されていることに注意してください。

3. 第6.8項の説明に従って、snoop出力のキャッシュ・ルールを作成します。
snoop出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページで次のように構成してください。

- 「キャッシュ」チェック・ボックスを選択します。

- 「URL一致条件」セクションで、「パス接頭辞」を選択し、/snoopと入力します。

- 「HTTPメソッド」セクションで、「GET」をクリックします。

4. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:admin_port/snoop

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、WebSphere Application Serverから直接snoopにアクセスした場合と同じです。この場合、Oracle Web Cacheはsnoopの出力をキャッシュし、レスポンスをブラウザに送信します。

5. 第8.6項の説明に従ってキャッシュの内容を表示し、snoopがキャッシュされていることを確認します。
ページを再ロードすると、WebSphere Application Serverに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

12.2.2 WebSphere Calendar Creator JSP

Calendar JSPでは、ユーザー入力に基づいてカレンダが生成されます。このサンプルは、snoopサーブレットのような、あらかじめ配置されたWebSphereサンプルではありません。このサンプルを見つけるには、IBM WebSphere Application Serverのサンプル・ギャラリーにあるドキュメントに記述されているとおり、Technology Samplesをインストールする必要があります。このJSPを使用して、Oracle Web CacheがセッションCookieを持つページをどのようにキャッシュしているのかを説明します。

セッション・エンコードされたURLのSimpleTag.jspをキャッシュするには、次の手順を実行します。

1. WebSphere Application Serverを起動し、ブラウザをCookieを受け入れるように設定し、次のURLにアクセスします。

http://hostname/TechnologySamples/Calendar

このページに表示されるフォームでは、月や年など、カレンダを作成するための設定を入力するように要求されます。このアプリケーションを使用するには、次の手順を実行します。

1. なんらかの値を入力し、「Continue」をクリックします。

2. 「Day」フィールドと「Memo」フィールドになんらかの値を入力し、「Add Memo」をクリックします。

3. 「Generate Calendar」をクリックします。

2. 第6.7項の説明に従って、有効期限ルールを作成します。
「有効期限ポリシーの作成」ダイアログ・ボックスで、次の手順を実行します。

1. 「オブジェクトの有効期限」セクションで、「エントリ・キャッシュの後」を選択し、「時間制限」フィールドに60秒を入力します。

2. 「期限切れのオブジェクトに対するアクション」セクションで、「即時削除」を選択します。

3. 第6.8.6項の説明に従って、セッション・キャッシュ・ルールを作成します。
セッション・キャッシュ・ルールを構成する場合は、次の手順を実行します。

1. 「セッション構成」ページの「セッション定義」セクションで、セッション定義を作成します。

- 「セッション名」フィールドに、IBMSessionと入力します。

- 「Cookie名」フィールドに、JSESSIONIDと入力します。

- 「URL POST本体のパラメータ」フィールドに、jsessionidと入力します。

2. 「セッション構成」ページの「セッション・ポリシー構成」セクションで、IBMSessionという名前の2つのポリシーを作成します。

- 最初のIBMSessionポリシーの「キャッシュ」列で、「セッションを使用」オプションを選択します。

- 2つ目のIBMSessionポリシーの「キャッシュ」列で、「セッションを使用しない」オプションを選択します。

- 「デフォルト値の置換」チェック・ボックスは選択しないでください。

3. Calendarに対する新しいキャッシュ・ルールを作成します。
Calendar出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページの「一般」タブで次のように構成します。

- 「キャッシュ」チェック・ボックスを選択します。

- 「有効期限」リストで、「キャッシュ・エントリの60秒後に期限が切れ、即時に削除」を選択します。

- 「URL一致条件」セクションで、「パス接頭辞」を選択し、/TechnologySamples/Calendarと入力します。

- 「HTTPメソッド」セクションで、「GET」をクリックします。

「キャッシュ・ルールの作成」ページの「セッション」タブで、両方のIBMSessionセッションを選択し、一方には「セッションを使用」を設定し、もう一方には「セッションを使用しない」を設定します。

4. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:WebCache-admin_port/TechnologySamples/Calendar

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、WebSphere Application Serverから直接Calendarにアクセスした場合と同じです。この場合、Oracle Web CacheはCalendar出力をキャッシュします。

5. 第8.6項の説明に従ってキャッシュの内容を表示し、Calendarがキャッシュされていることを確認します。
ページを再ロードすると、WebSphereサーバーに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

このURLの有効期限ルールは60秒に設定されているため、Oracle Web Cacheはキャッシュされた内容を60秒後に期限切れにし、ユーザーが次にページをリクエストしたときにその内容を反映させます。

Oracle Web Cacheの配置後、ブラウザにHTTP 404 Page not foundエラーが表示される場合は、次の手順を実行します。

1. WebSphere ServerのWAS_home/config/cells/plugin-cfg.xmlファイルで、<VirtualHost Name="*:WebCache-admin_port"/>を追加します。

2. WebSphere Application Serverの管理コンソールで、「Environment」→「Virtual Hosts」にナビゲートします。

3. プロンプトに従って、新しい仮想ホストを追加します。

12.3 Apache Tomcat

Apache Tomcatバージョン4.1はサーブレット・コンテナです。これはApache Jakartaプロジェクトに含まれています。Apache Tomcatのインストールには、JSPおよびJavaサーブレットのサンプルがいくつか含まれています。この項では、次のコンテンツをキャッシュするようにOracle Web Cacheを構成する方法について説明します。

- 第12.3.1「Apache TomcatのSnoop JSP」

- 第12.3.2「Apache Tomcatのセッション・サーブレット」

インストールについては、Apache Tomcatバイナリ内の説明に従ってください。Apache Tomcatには、Java Development Kit(JDK)が必要です。

詳細は、次を参照してください。

- Apache Tomcatの詳細は、http://jakarta.apache.org/tomcat/を参照してください。

- JDKのダウンロード方法およびインストール方法の詳細は、http://java.sun.comを参照してください。

12.3.1 Apache TomcatのSnoop JSP

snoop.jspは、ブラウザによって送信されるリクエスト情報、ヘッダーおよびパラメータの取得および使用を表示します。これを使用して、Oracle Web Cacheが動的コンテンツをキャッシュする方法を説明します。

はじめに、次の手順を実行します。

1. 第12.1.1項の説明に従って、Oracle Web CacheがApache Tomcatサーバーと通信するように構成されていることを確認します。

2. Apache Tomcatサーバーを起動し、次のURLにアクセスします。

http://web_cache_hostname:WebCache-admin_port/examples/jsp/snp/snoop.jsp

ブラウザにより送信されたリクエスト情報、ヘッダーおよびパラメータが表示されていることに注意してください。

コンテンツをキャッシュするには、次の手順を実行します。

1. 第6.8項の説明に従って、snoop出力のキャッシュ・ルールを作成します。
snoop出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページで次のように構成してください。

- 「キャッシュ」チェック・ボックスを選択します。

- 「URL一致条件」セクションで、「パス接頭辞」を選択し、/examples/jsp/snp/snoop.jspと入力します。

- 「HTTPメソッド」セクションで、「GET」をクリックします。

2. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:admin_port/eexamples/jsp/snp/snoop.jsp

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、Apache Tomcatから直接snoopにアクセスした場合と同じです。この場合、Oracle Web Cacheはsnoopの出力をキャッシュし、レスポンスをブラウザに送信します。

3. 第8.6項の説明に従ってキャッシュの内容を表示し、snoopがキャッシュされていることを確認します。
ページを再ロードすると、Apache Tomcatに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

12.3.2 Apache Tomcatのセッション・サーブレット

SessionServletは、HttpSessionクラスを使用してブラウザがサーブレットを訪問した回数を記録するHTTPサーブレットの単純なサンプルです。このサンプルを使用して、Oracle Web Cacheがセッション・エンコードされたURLを持つページをどのようにキャッシュしているのかを説明します。

このサーブレットはApache Tomcatバイナリに含まれていない場合があります。このサンプルはWebから入手するか、例12-1のサーブレットのコードを使用することもできます。

例12-1 Apache Tomcatバイナリ

/*
* @(#)SessionServlet.java     1.5 1.5
*
* Copyright (c) 1996-1998 Sun Microsystems, Inc. All Rights Reserved.
*
* This software is the confidential and proprietary information of Sun
* Microsystems, Inc. ("Confidential Information").  You shall not
* disclose such Confidential Information and shall use it only in
* accordance with the terms of the license agreement you entered into
* with Sun.
*
* SUN MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THE
* SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
* IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
* PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES
* SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING
* THIS SOFTWARE OR ITS DERIVATIVES.
*
* CopyrightVersion 1.0
*/

package sunexamples;

import java.io.*;
import java.util.Enumeration;

import javax.servlet.*;
import javax.servlet.http.*;

/**
* This is a simple example of an HTTP Servlet that uses the HttpSession
* class
*
* Note that in order to guarantee that session response headers are
* set correctly, the session must be retrieved before any output is
* sent to the client.
*/
public class SessionServlet extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
{

//Get the session object
HttpSession session = req.getSession(true);

//Get the output stream
ServletOutputStream out = res.getOutputStream();

res.setContentType("text/html");

out.println("<HEAD><TITLE> SessionServlet Output " +
"</TITLE></HEAD><BODY>");
out.println("<h1> SessionServlet Output </h1>");

//Here's the meat
Integer ival = (Integer) session.getValue("sessiontest.counter");
if (ival==null) ival = new Integer(1);
else ival = new Integer(ival.intValue() + 1);
session.putValue("sessiontest.counter", ival);

out.println("You have hit this page <b>" + ival + "</b> times.<p>");

// encodeURL Encodes the specified URL by including the session ID in it
// if cookies are not turned on or not supported by the browser
out.println("Click <a href=" + res.encodeURL("/session.html") +
">here</a>");
out.println(" to ensure that session tracking is working even if" +
" cookies aren't supported.<br>");
out.println(" Note that by default URL rewriting is not enabled due" +
" to it's expensive overhead.");
out.println("<p>");

out.println("<h3>Request and Session Data:</h3>");
out.println("Session ID in Request: " + req.getRequestedSessionId());
out.println("<br>Session ID in Request from Cookie: " +
req.isRequestedSessionIdFromCookie());
out.println("<br>Session ID in Request from URL: " +
req.isRequestedSessionIdFromURL());
out.println("<br>Valid Session ID: " +
req.isRequestedSessionIdValid());
out.println("<h3>Session Data:</h3>");
out.println("New Session: " + session.isNew());
out.println("<br>Session ID: " + session.getId());
out.println("<br>Creation Time: " + session.getCreationTime());
out.println("<br>Last Accessed Time: " +
session.getLastAccessedTime());
out.println("<br><a href=\"/examples/simple_servlets\">Up</a>");
out.println("</BODY>");
out.close();
}

public String getServletInfo() {
return "A simple session servlet";
}
}

はじめに、次の手順を実行します。

1. Apache Tomcat環境でSessionServlet.javaファイルをコンパイルします。

2. SessionServlet.classを/examples/servlets/ディレクトリにコピーします。このディレクトリには、別のサーブレットのサンプルが存在する場合があります。

3. 第12.1.1項の説明に従って、Oracle Web CacheがApache Tomcatと通信するように構成されていることを確認します。

4. Cookieを受け入れないようにブラウザを構成します。
これは、この例でセッション・エンコードされたURLを使用するために必須です。

5. Apache Tomcatを起動し、次のURLにアクセスします。

http://hostname/examples/servlets/SessionServlet

ページにブラウザの訪問回数が表示されることに注意してください。「here」と表示されたリンクをクリックすると、セッションIDがURL内でエンコードされることに注意してください。ページを更新または再ロードするたびに、カウンタの数値が1つずつ増えます。

コンテンツをキャッシュするには、次の手順を実行します。

1. 第6.7項の説明に従って、有効期限ルールを作成します。
「有効期限ポリシーの作成」ダイアログ・ボックスで、次の手順を実行します。

1. 「オブジェクトの有効期限」セクションで、「エントリ・キャッシュの後」を選択し、「時間制限」フィールドに60と入力します。

2. 「期限切れのオブジェクトに対するアクション」セクションで、「即時削除」を選択します。

2. 第6.8.6項の説明に従って、セッション・キャッシュ・ルールを作成します。
セッション・キャッシュ・ルールを構成する場合は、次の手順を実行します。

1. 「セッション構成」ページの「セッション定義」セクションで、セッション定義を作成します。

- 「セッション名」フィールドに、ApacheSessionと入力します。

- 「Cookie名」フィールドに、JSESSIONと入力します。

- 「URL POST本体パラメータ」フィールドに、jsessionidと入力します。

2. 「セッション構成」ページの「セッション・ポリシー構成」セクションで、ApacheSessionという名前の2つのポリシーを作成します。

- 最初のApacheSessionポリシーの「キャッシュ」列で、「セッションを使用」オプションを選択します。

- 2つ目のApacheSessionポリシーの「キャッシュ」列で、「セッションを使用しない」オプションを選択します。

- 「デフォルト値の置換」チェック・ボックスは選択しないでください。

3. Sessionに対する新しいキャッシュ・ルールを作成します。
SessionServletサーブレット出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページの「一般」タブで次のように構成します。

- 「キャッシュ」チェック・ボックスを選択します。

- 「有効期限」リストで、「キャッシュ・エントリの60秒後に期限が切れ、即時に削除」を選択します。

- 「URL一致条件」セクションで、「パス接頭辞」を選択し、/examples/servlets/SessionServletと入力します。

- 「HTTPメソッド」セクションで、「GET」をクリックします。

「キャッシュ・ルールの作成」ページの「セッション」タブで、両方のApacheSessionセッションを選択し、一方には「セッションを使用」を設定し、もう一方には「セッションを使用しない」を設定します。

3. 第6.8.6項の説明に従って、セッション・キャッシュ・ルールを作成します。

4. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:WebCache-admin/examples/servlets/SessionServlet

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、Apache Tomcatから直接Sessionにアクセスした場合と同じです。この場合、Oracle Web CacheはSessionサーブレット出力をキャッシュします。ページを更新または再ロードした場合に、カウンタの数値が変わらないことに注意してください。これは、Oracle Web Cacheがコンテンツを表示し、リクエストがApache Tomcatに到達しないためです。

5. 第8.6項の説明に従ってキャッシュの内容を表示し、Sessionサーブレットがキャッシュされていることを確認します。
ページを再ロードすると、Apache Tomcatサーバーに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

このURLの有効期限ルールは60秒に設定されているため、Oracle Web Cacheはキャッシュされた内容を60秒後に期限切れにし、ユーザーが次にページをリクエストしたときにその内容を反映させます。

12.4 Microsoft IIS

Microsoft IISのインストールには、いくつかのASPサンプルが含まれています。この項では、次のコンテンツをキャッシュするようにOracle Web Cacheを構成する方法について説明します。

- 第12.4.1「ServerVariables_Jscript ASP」

- 第12.4.2「Cookie_Jscript ASP」

12.4.1 ServerVariables_Jscript ASP

ServerVariables_JScript.aspは、ASPスクリプトからサーバー変数情報にアクセスする方法を説明するためのものです。これを使用して、Oracle Web Cacheが動的コンテンツをキャッシュする方法を説明します。

はじめに、次の手順を実行します。

1. 第12.1.1項の説明に従って、Oracle Web CacheがIISと通信するように構成されていることを確認します。

2. IISを起動し、次のURLにアクセスします。

http://hostname/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp

ブラウザにより送信されたリクエスト情報、ヘッダーおよびパラメータが表示されていることに注意してください。

コンテンツをキャッシュするには、次の手順を実行します。

1. 第6.8項の説明に従い、次の情報を使用してServerVariables_JScript.aspに対するキャッシュ・ルールを作成します。
ServerVariables_JScript.asp出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページで次のように構成します。

- 「URL一致条件」セクションで、次のように入力します。

/IISSamples/sdk/asp/interaction/ServerVariables_JScript.asp

- 「HTTPメソッド」セクションで、「GET」をクリックします。

- 「キャッシュ・レスポンス」セクションで、「キャッシュ」をクリックします。

2. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:WebCache-admin_port/eIISSamples/sdk/asp/interaction/ServerVariables_JScript.asp

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、IISから直接ServerVariables_JScript.aspにアクセスした場合と同じです。この場合、Oracle Web CacheはServerVariables_JScript.asp出力をキャッシュし、リクエストをブラウザに送信します。

3. 第8.6項の説明に従ってキャッシュの内容を表示し、ServerVariables_JScript.aspがキャッシュされていることを確認します。
ページを再ロードすると、IISに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

12.4.2 Cookie_Jscript ASP

Cookie_JScript.aspは、Response.Cookiesコレクションを使用して、スクリプトでCookieを設定する方法や読み取る方法を説明します。これを使用して、Oracle Web CacheがセッションCookieを持つページをどのようにキャッシュしているのかを説明します。

はじめに、次の手順を実行します。

1. 第12.1.1項の説明に従って、Oracle Web CacheがIISと通信するように構成されていることを確認します。

2. IISを起動し、ブラウザがCookieを受け入れるように設定されていることを確認し、次のURLにアクセスします。

http://hostname/IISSamples/sdk/asp/interaction/Cookie_JScript.asp

URLにアクセスすると、そのページを最後に訪問した日付と時刻がページに表示されます。「Revisit this page」をクリックすると、日付と時刻が更新されます。

コンテンツをキャッシュするには、次の手順を実行します。

1. 第6.7項の説明に従って、有効期限ルールを作成します。
「有効期限ポリシーの作成」ダイアログ・ボックスで、次の手順を実行します。

1. 「オブジェクトの有効期限」セクションで、「エントリ・キャッシュの後」を選択し、「時間制限」フィールドに60と入力します。

2. 「期限切れのオブジェクトに対するアクション」セクションで、「即時削除」を選択します。

2. 第6.8.6項の説明に従って、セッション・キャッシュ・ルールを作成します。
セッション・キャッシュ・ルールを構成する場合は、次の手順を実行します。

1. 「セッション構成」ページの「セッション定義」セクションで、セッション定義を作成します。

- 「セッション名」フィールドに、MSSessionと入力します。

- 「Cookie名」フィールドに、CookieJSCriptと入力します。

- 「URL POST本体パラメータ」フィールドに、jsessionidと入力します。

2. 「セッション構成」ページの「セッション・ポリシー構成」セクションで、MSSessionという名前の2つのポリシーを作成します。

- 最初のMSSessionポリシーの「キャッシュ」列で、「セッションを使用」オプションを選択します。

- 2つ目のMSSessionポリシーの「キャッシュ」列で、「セッションを使用しない」オプションを選択します。

- 「デフォルト値の置換」チェック・ボックスは選択しないでください。

3. Cookie_JScript.aspに対する新しいキャッシュ・ルールを作成します。
Cookie_JScript.asp出力に対するキャッシュ・ルールを作成するときは、「キャッシュ・ルールの作成」ページの「一般」タブで次のように構成します。

- 「キャッシュ」チェック・ボックスを選択します。

- 「有効期限」リストで、「キャッシュ・エントリの60秒後に期限が切れ、即時に削除」を選択します。

- 「URL一致条件」セクションで、/IISSamples/sdk/asp/interaction/Cookie_JScript.aspと入力します。

- 「HTTPメソッド」セクションで、「GET」をクリックします。

「キャッシュ・ルールの作成」ページの「セッション」タブで、両方のMSSSessionセッションを選択し、一方には「セッションを使用」を設定し、もう一方には「セッションを使用しない」を設定します。

3. 次のURLを使用して、ブラウザにOracle Web Cacheを指定します。

http://web_cache_hostname:WebCache-admin_port/eIISSamples/sdk/asp/interaction/Cookie_JScript.asp

ポートを決定する方法は、第2.11.1.1項を参照してください。

出力は、IISから直接Cookie_JScript.aspにアクセスした場合と同じです。この場合、Oracle Web CacheはCookie_JScript.asp出力をキャッシュします。キャッシュからこのコンテンツが表示されることを確認するには、ページを再表示するをクリックします。日付と時刻は更新されないことに注意してください。これは、Oracle Web Cacheがキャッシュされたコンテンツを表示し、リクエストがIISに到達しないためです。

4. 第8.6項の説明に従ってキャッシュの内容を表示し、Cookie_JScript.aspがキャッシュされていることを確認します。
ページを再ロードすると、IISサーバーに直接アクセスするよりも速く、キャッシュされたレスポンスが表示されます。

このURLの有効期限ルールは60秒に設定されているため、Oracle Web Cacheはキャッシュされた内容を60秒後に期限切れにし、ユーザーが次にページをリクエストしたときにその内容を反映させます。

A Oracle Web Cacheのトラブルシューティング

この付録では、Oracle Web Cacheの使用時に直面する可能性がある一般的な問題とその解決方法について説明します。次のトピックが含まれます:

- 第A.1項「問題と解決方法」

- 第A.2項「一般的な構成ミス」

- 第A.3項「キャッシュ・コンテンツ結果の診断」

- 第A.4項「一般的なEdge Side Includes(ESI)構文エラーの診断」

- 第A.5項「HTTPトラフィック変更の影響」

- 第A.6項「追加情報」

A.1 問題と解決方法

この項では、一般的な問題と解決方法について説明します。次のトピックが含まれます:

- 第A.1.1項「Webアプリケーション・サーバーからレスポンスがないエラー」

- 第A.1.2項「Oracle Web Cacheコンピュータ上の負荷の問題」

- 第A.1.3項「パフォーマンスの低下とメモリー」

- 第A.1.4項「キャッシュ・クラスタ内の無効化タイムアウト」

- 第A.1.5項「オリジン・サーバー上の許容量の問題」

- 第A.1.6項「ブラウザで完全なレスポンスが受信されない」

- 第A.1.7項「ブラウザにページが表示されないエラー」

- 第A.1.8項「IBM Websphere Application Serverに伴うESIエラー」

- 第A.1.9項「イベント・ビューアにwebcache.xmlのXML解析エラーが表示される」

A.1.1 Webアプリケーション・サーバーからレスポンスがないエラー

問題

11g リリース1(11.1.1)のOracle Web Cacheが、Oracle Portal、Oracle Forms ServicesまたはOracle Business Intelligence Discovererなどの10gコンポーネントをリバース・プロキシしている場合に、SSLが有効になっていると、次のブラウザ・エラーが表示されることがあります。

No response from Application Web Server

また、次のようなメッセージがイベント・ログに書き込まれます。

[2009-02-11T03:44:55-08:00] [webcache] [ERROR:32] [WXE-11904] [security]
[ecid: ] SSL handshake fails NZE-29024
[2009-02-11T03:44:55-08:00] [webcache] [WARNING:1] [WXE-11905] [security]
[ecid: ] SSL additional information: The certificate sent by the other side could not be validated. This may occur if the certificate has expired, has been revoked, or is invalid for another reason.
[2009-02-11T03:44:55-08:00] [webcache] [WARNING:1] [WXE-11905] [security]
[ecid: ] SSL additional information: Remote IP [140.87.11.159]:9002
[2009-02-11T03:44:55-08:00] [webcache] [WARNING:1] [WXE-11905] [security]
[ecid: ] SSL additional information: Local IP 152.68.64.152:2832
[2009-02-11T03:44:55-08:00] [webcache] [WARNING:1] [WXE-11906] [security]
[ecid: ] SSL details: SSL error during handshake (details: internal=The
certificate sent by the other side could not be validated. This may occur if the certificate has expired, has been revoked, or is invalid for another reason. system=Success)

このエラーは、10gコンポーネントで使用されているウォレットに適合しない証明書が、Oracle Web Cache用として選択されたウォレットに含まれていることを示しています。

解決方法

この問題を解決するには、Oracle Web Cache用として指定するウォレットを10gコンポーネント用として使用しているウォレットに変更します。第5.4.3項を参照してください。

A.1.2 Oracle Web Cacheコンピュータ上の負荷の問題

UNIXオペレーティング・システムで、topユーティリティまたはuptimeユーティリティを使用したときに、Oracle Web Cacheコンピュータが待機中の予想平均負荷を上回る数値が報告されます。

問題

この現象は、Oracle Web Cacheが待機中にも軽いメンテナンス作業を実施しているためです。Oracle Web Cacheで実施される作業の1つがガベージ・コレクションです。待機モードでは次の現象が発生します。

- uptimeの負荷(平均カーネル・スケジューラ・キュー長)が長くなります。Oracle Web Cacheによって、平均キュー長(uptime出力)が約1個分増加します。

- Oracle Web Cacheで実施される作業が最小限のため、CPUの負荷は低いままです。

A.1.3 パフォーマンスの低下とメモリー

Oracle Web Cacheはメモリー内キャッシュのため、Oracle Web Cacheを専用のコンピュータ上にデプロイしてページングを最小化することをお薦めします。コンピュータ上でOracle Web Cacheのみを実行するのでない場合は、最大キャッシュ・サイズが全メモリーの20%を超えないようにしてください。

この項では、無効化タイムアウトの回避方法について説明します。

- 問題1: ページング

- 問題2: 最大キャッシュ・サイズを超えるメモリーを使用するOracle Web Cache

問題1: ページング

オブジェクトのキャッシングまたは無効化に時間がかかる場合は、コンピュータがページングしている可能性があります。ページングによってパフォーマンスが大幅に低下する可能性があります。

解決方法1

ページングが使用されるコンピュータ上でOracle Web Cacheが効率よく動作するように構成するには、Oracle Web Cacheを専用のコンピュータにデプロイするか、最大キャッシュ・サイズと最大キャッシュ・オブジェクト・サイズを削減します。これらの設定の構成については、第2.11.5項を参照してください。

問題2: 最大キャッシュ・サイズを超えるメモリーを使用するOracle Web Cache

Oracle Web Cacheで最大キャッシュ・サイズ以上のメモリーが使用される場合は、最大キャッシュ・オブジェクト・サイズよりも大きなオブジェクトに対する同時リクエストが大幅に増加する可能性があります。この状況では、オブジェクトがキャッシュされないため、オブジェクトのキャッシングよりも多くのメモリーがリクエストの処理とオリジン・サーバーへの転送に使用されます。

解決方法2

サイズの大きなオブジェクトに対する同時リクエストが増加した場合は、アクセス・ログを確認して、このようなオブジェクトがキャッシュされるように最大キャッシュ・オブジェクト・サイズを調整します。加えて、キャッシュ・ルールまたはレスポンス・ヘッダーでオブジェクトのキャッシングが指定されていることを確認します。

最大キャッシュ・サイズまたは最大キャッシュ・オブジェクト・サイズを変更するには、新しい制限範囲を設定する必要があります。これらの設定の構成については、第2.11.5項を参照してください。

A.1.4 キャッシュ・クラスタ内の無効化タイムアウト

キャッシュ階層またはキャッシュ・クラスタ・デプロイメントでは、無効化リクエストを伝播するために300秒のデフォルト・タイムアウトが設定されます。無効化伝播の概要は、第7.10.2項を参照してください。

問題

キャッシュ・クラスタ内でタイムアウトが発生すると、無効化リクエストに対するレスポンスとして次のメッセージが表示されます。

Can't connect to the web cache's invalidation listening port.

解決方法

このエラーを解決するには、次の手順に従います。

1. キャッシュ・クラスタ・メンバー上で、テキスト・エディタを使用してwebcache.xmlファイルを開きます。

2. CALYPSONETINFO要素を探します。

<CALYPSONETINFO...INV_PEER_TIMEOUT="300"
INV_GLOBAL_TIMEOUT="300".../>

3. INV_PEER_TIMEOUT属性の値を変更します。
キャッシュ・クラスタ内では、キャッシュ・クラスタ・メンバーの多くがLAN環境で動作します。そのため、通常は、INV_PEER_TIMEOUTの値を小さくすることによって効率性が向上します。

4. webcache.xmlを保存します。

5. 次のコマンドを使用してOracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

6. すべてのキャッシュ・クラスタ・メンバーに対する構成変更を同期させ、他のキャッシュ・クラスタ・メンバーを再起動します。このタスクをFusion Middleware Controlで実行する場合は第3.6.5項を、このタスクをOracle Web Cache Managerで実行する場合は第3.7.4項を参照してください。

A.1.5 オリジン・サーバー上の許容量の問題

問題

Webアプリケーション・サーバーの最大容量に達した場合、Webサイトのページにアクセスしようとすると次のエラー・メッセージが表示されます。

The application Web server is busy. Possible reach capacity.

また、次のようなメッセージがイベント・ログに書き込まれます。

[2009-04-16T11:56:23-04:00] [webcache] [WARNING:1] [WXE-14021] [backend] [ecid: 453611135182,0] Capacity, as set by Web Cache, is exceeded for all origin servers that are available for processing this request.
[2009-04-16T11:56:23-04:00] [webcache] [ERROR:32] [WXE-11365] [frontend] [ecid: 453611135182,0] Server busy response is returned.

これらのエラーは、Webアプリケーション・サーバーで同時接続数が上限を超えたことを示しています。

解決方法

次のいずれかの方法でこの問題を解決できます。

- 許容量を増やします。第2.11.2項を参照してください。

- キャッシュ・ルールを評価して、キャッシュ可能なコンテンツを増やせるかどうかを判断します。第A.3項を参照してください。

A.1.6 ブラウザで完全なレスポンスが受信されない

クライアント・ブラウザで完全なレスポンスが受信されません。

問題

実際のページ長が、オリジン・サーバーで設定され、Oracle Web Cacheからクライアント・ブラウザに送信されたContent-Lengthレスポンス・ヘッダー・フィールドの値より短い場合は、ブラウザでまだデータが到着するものと判断され、最終的に接続がタイムアウトします。実際のページ長がContent-Lengthより長い場合は、ブラウザに完全なページが届きません。Oracle Web Cacheではキャッシュに保存されたページのコンテンツ長そのものが正確に計算されるため、キャッシュ・ヒットに対してこの問題は発生しません。

次のようなメッセージがイベント・ログに記録されます。

[2009-04-16T13:23:32-04:00] [webcache] [WARNING:1] [WXE-11093] [backend] [ecid: 268932876536,0] Content-Length value 7755 sent byorigin server does not match number of bytes received, that is 454 bytes for localhost:7785/cgi-bin/test-cgi.

解決方法

キャッシュ・ミスの場合は、不正なcontent-length問題の回避方法が2つあります。

- Content-Lengthレスポンス・ヘッダー・フィールドの値が正しいことが保証されるようにアプリケーションを修正します。

- Connection: keep-aliveリクエスト・ヘッダー・フィールドのないHTTP/1.0リクエストを送信するようにブラウザまたはクライアント・エミュレータを構成します。

A.1.7 ブラウザにページが表示されないエラー

クライアント・ブラウザからページが表示できないという内容のエラーが返されます。

問題

Microsoft Internet Explorerには、タイムアウトしたSSL接続を再使用しようとする既知の問題があります。この制限によって、Internet Explorer 5.5以前のリリースを使用して次のOracle Web Cache構成条件でWebサイトに接続しているユーザーには、ページが表示できないという内容のエラーが表示される可能性があります。

- Oracle Web Cacheに、HTTPSクライアント・リクエストを受け入れるように設定するためのリスナー・ポートが1つ以上あります。

- ネットワーク接続キープ・アライブ・タイムアウトが0より大きい値に設定されています。

次の関連項目を参照してください。

- HTTPSリクエストを受け入れるためのOracle Web Cacheの構成方法に関する第5.4項

- キープ・アライブ・タイムアウトの設定方法に関する第2.11.5項

- Oracle Web CacheからInternet Explorerへのキープ・アライブ接続を維持するためのOracle HTTP Serverの構成方法に関する第5.4.4.1項

Oracle Web Cacheがこのような設定で構成された場合は、Oracle Web Cacheで接続が閉じられた後にInternet ExplorerからHTTPSリクエストが送信される可能性があります。その場合は、ブラウザからページが表示できないという内容のエラーが返されます。

解決方法

この問題を解決するには、正しいMicrosoftパッチを使用するようにすべてのクライアントをアップグレードする必要があります。Internet Explorerに関する問題、その回避方法、およびInternet Explorerの更新リンクの詳細は、次のURLを参照してください。

- Internet Explorer 5.5: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q305217

- Internet Explorer 6: http://support.microsoft.com/default.aspx?kbid=831167

公開Webサイトを含む構成では、このオプションが適さない場合があります。このような構成の場合は、Webサイト管理者が、webcache.xmlファイル内でInternet ExplorerからのHTTPS接続に対するキープ・アライブ・タイムアウトを有効または無効にする必要があります。デフォルトで、Oracle Web Cacheによって、Internet ExplorerからのHTTPS接続に対するキープ・アライブが無効にされます。

Internet ExplorerからのHTTPSリクエストに対するキープ・アライブ接続を有効にするには、次の手順に従います。キャッシュ・クラスタでは、クラスタ・メンバーごとにこの手順を実行する必要があります。

1. テキスト・エディタでwebcache.xmlファイルを開きます。

2. CALYPSONETINFO要素を探します。

<CALYPSONETINFO...KEEPALIVE4MSIE_SSL="NO".../>

3. KEEPALIVE4MSIE_SSL属性の値をYESに変更します。

4. webcache.xmlを保存します。

5. 次のコマンドを使用してOracle Web Cacheを再起動します。

opmnctl restartproc ias-component=component_name

この実行可能ファイルは次のディレクトリにあります。

(UNIX) ORACLE_INSTANCE/bin
(Windows) ORACLE_INSTANCE\bin

A.1.8 IBM Websphere Application Serverに伴うESIエラー

IBM Websphere Application ServerとOracle Web CacheのESI機能トークンに互換性がないことが原因で、エラーが表示される場合があります。

問題

IBM Websphere Application ServerのコンテンツをキャッシュするためにOracle Web Cacheがデプロイされている場合は、次のエラーが発生する可能性があります。

- 「Some ESI Features in this page are not supported」という文字列を含むエラー・ページ

- イメージがレンダリングされない

解決方法

この問題を解決するには、次の手順に従います。

1. WebSphere Application Serverの管理コンソールで、「Servers」→「Application Servers」にナビゲートします。

2. 「Application servers」ページで、server1アプリケーション・サーバーを選択します。
server1は、IBM Websphere Application Serverをデフォルトのオプションでインストールするときのサーバー名です。他の名前を指定した場合は、その名前を選択します。

3. 「Configuration」タブの「Server Infrastructure」セクションで、「Java and Process Management」を選択し、「Process Definition」を選択します。

4. 「Additional Properties」セクションで、「Java Virtual Machine」を選択してから「Custom Properties」を選択します。

5. 「New」をクリックしてエントリを作成します。

6. 「Name」フィールドに、com.ibm.servlet.file.esi.controlと入力します。

7. 「Value」フィールドに次の文字列を入力します。

max-age=300, cacheid="URL",content="ESI/1.0".

8. 「Apply」をクリックして設定を保存します。

9. IBM Websphere Application Serverを再起動します。

A.1.9 イベント・ビューアにwebcache.xmlのXML解析エラーが表示される

webcache.xmlファイルを読み取れないことに関連したXML解析エラーがWindows上の画面ではなく、イベント・ビューアに表示されます。

A.2 一般的な構成ミス

一般的な構成ミスには、次のものが含まれます。

- サイトがオリジン・サーバーに正しくマッピングされていません。
サイトがマッピングされていない場合は、リクエストがOracle Web CacheからデフォルトのOracle HTTP Serverに転送されます。ブラウザで、HTTP 500エラー・コードが受信される場合があります。

その他のサイト構成エラーには、次のものが含まれます。

- すべてのサイト別名が指定されていない

- ワイルドカード文字*の誤用

- 複数のオリジン・サーバーを使用しているサイトで、複数のサイト・サーバー間マッピングを作成している

サイトの構成方法は、第2.11.3項を参照してください。

- PingのURL
pingのURLを構成する場合は、オリジン・サーバーによってURLの入力方法が異なります。Webアプリケーション・サーバーの場合は、ドメイン名またはWebアプリケーション・サーバーの仮想ホストを表すサイト名を含む相対URLと完全修飾URLのどちらかを入力します。プロキシ・サーバーの場合は、そのプロキシ・サーバーの背後にあるオリジン・サーバーの仮想ホストを表すサイト名またはドメイン名を含む完全修飾URLを入力します。URLがキャッシュされることを確認します。

オリジン・サーバーの構成方法は、第2.11.2項を参照してください。

- root権限によるOracle Web Cacheの起動
UNIXでは、次の場合に、Oracle Web Cacheがroot権限で起動するように構成する必要があります。

- 1024より小さな特権ポート番号をOracle Web Cacheのリスニング・ポートとして使用する場合

- Oracle Web Cacheへの接続に使用されるファイル・ディスクリプタが1,024よりも多い場合

- 現在のopmnctlユーザーが、構成されたプロセスIDユーザーと一致しない場合

オリジン・サーバーの構成方法は、第5.9項を参照してください。

TRACE冗長性イベント・ロギング・レベルが、次のようなOracle Web Cache構成設定の検証に役立ちます。

- サイトの解決

- 正しいオリジン・サーバーへのサイト・サーバー間マッピング・ルート

- 圧縮

- セッション・バインディング

- キャッシュ・ルール

- ESI処理

イベント・ログ内のTRACE冗長性の構成方法は、第9.3項を参照してください。

A.3 キャッシュ・コンテンツ結果の診断

キャッシュ・ルールが、不正なコンテンツや期限切れのコンテンツを提供するように設定されていないかどうかを診断するには、次の手順に従います。

1. 次の方法によってキャッシュの内容を判断します。

- 最もポピュラーなリクエスト(キャッシュされたリクエストとキャッシュされないリクエストのどちらか)と、キャッシュ・オブジェクトに関連付けられたキャッシュ・ルールのリスト表示。第8.6項を参照してください。

- キャッシュの内容のリスト表示。第8.6項を参照してください。

- 実際のコンテンツを無効化しない無効化のプレビュー。「無効化基準を満たすオブジェクトのリストをプレビュー」オプションの使用方法は、第7.7.2項を参照してください。

2. TRACEのロギング・レベルでイベント・ロギングを有効にします。その後で、リクエストを再送信します。
TRACEレベル・ロギングでは、オブジェクトがキャッシュされたかどうかと、そのオブジェクトがどのキャッシュ・ルールを満たしているかが示されます。

イベント・ロギングの有効化方法は、第9.3項を参照してください。

3. キャッシュ・ルールとキャッシュの内容を比較して、矛盾や構文エラーを特定します。
ルールの追加または削除、式タイプ構文の調整、またはルールの優先順位の変更を通してキャッシュ・ルールを調整します。

キャッシュ・ルールの構成方法は、第6.6項を参照してください。

4. アクセス・ロギングを有効にします。その後で、オブジェクトに対して明示的なリクエストを送信します。
アクセス・ログを分析することによって、Oracle Web Cacheがキャッシュからオブジェクトを提供しているか、オリジン・サーバーにリクエストを転送しているかを判断できます。

アクセス・ロギングの有効化方法は、第9.4項を参照してください。

A.4 一般的なEdge Side Includes(ESI)構文エラーの診断

ESIエラーの大部分は、テンプレートまたはフラグメント・ページ内の構文エラーによるものです。イベント・ログ内のESI出力を分析することによって、ほとんどのESI構文エラーを簡単に診断できます。イベント・ログから不要な報告を排除するには、第9.3項の説明に従って、WARNINGの冗長性レベルを使用します。第8.3項の説明に従ったHTMLレスポンス・ボディ内での診断情報とイベント・ログ情報の表示も有効です。

次のトピックでは、テンプレートとフラグメント構文エラーを診断するためのイベント・ログとHTMLレスポンス・ボディの使用方法について説明します。

- 第A.4.1項「テンプレート構文エラーの例」

- 第A.4.2項「フラグメント構文エラーの例」

- 第A.4.3項「例外処理を伴うフラグメント構文エラーの例」

A.4.1 テンプレート構文エラーの例

たとえば、<esi:exclude>という名前の存在しないESIタグの構文を含むexlusion.htmlという名前のテンプレートがあるとします。

<html><body>
Simple inclusion test.
<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/>
</body></html>

ブラウザに返されるレスポンスは次のとおりです。

<HTML><HEAD><TITLE>Unsupported ESI feature</TITLE></HEAD>
<BODY>Some ESI features on this page are not supported.
</BODY></HTML>

次に、<esi:exlude>キーワードに伴う問題を示しているイベント・ログの抜粋を示します。

[24/Jul/2005:16:02:12 -0500] [detail] [ecid: 25732665668,0] [client: 127.0.0.1] [host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/exclusion.html]
[24/Jul/2005:16:02:12 -0500] [error 12086] [ecid: 25732665668,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005:16:02:12 -0500] [warning 11064] [ecid: 25732665668,0] ESI object
www.company.com:80/cgi-bin/esi-headers.sh?/esi/exclusion.html parsing error

A.4.2 フラグメント構文エラーの例

たとえば、フラグメントexlusion1.htmlを追加するための次の構文を含むinclusion_exclusion.htmlという名前のテンプレートがあるとします。HTMLには、ESI例外処理タグまたは属性が1つも含まれていないことに注意してください。

<html><body>
Simple inclusion test.
<esi:include src="/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html"/>
</body></html>

フラグメントfrag_exclusion.htmlには、<esi:exclude>という存在しないESIタグの構文が含まれています。

<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/>

ブラウザに返されるレスポンスは次のとおりです。

<HTML><HEAD><TITLE>ESI Processing Exception</TITLE></HEAD>
<BODY>The page caused an ESI processing exception.
</BODY></HTML>

次に示すイベント・ログは、<esi:exlude>キーワードに伴う問題を報告しています。このエラーと、提供する代替フラグメントがテンプレート内のESIで指定されていないという事実から、ブラウザにESI例外が表示されます。

[24/Jul/2005:16:10:40 -0500] [detail] [ecid: 25733186204,0] [client: 127.0.0.1] [host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html]
[24/Jul/2005:16:10:40 -0500] [error 12086] [ecid: 25733186204,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005:16:10:40 -0500] [warning 11064] [ecid: 25733186204,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error
[24/Jul/2005:16:10:40 -0500] [warning 12009] [ecid: 25733186204,0] Incorrect ESI fragment exception in ESI template www.company.com:80/cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html, fragment www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html
[24/Jul/2005:16:10:40 -0500] [error 12012] [ecid: 25733186204,0] No exception handler is defined in template www.company.com:80/cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html:.
[24/Jul/2005:16:10:40 -0500] [error 11368] [ecid: 25733186204,0] ESI exception error response is returned.

A.4.3 例外処理を伴うフラグメント構文エラーの例

たとえば、フラグメントfrag_exclusion.htmlまたは代替フラグメントfragment1.htmlを追加するための次の構文を含む同じinclusion_exclusion.htmlテンプレートがあるとします。指定されたexlusion1.htmlフラグメントがフェッチできない場合は、かわりに、alt属性を持つ指定されたfragment1.htmlフラグメントが表示されます。

<html><body>
Simple inclusion test.
<esi:include src="/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html" alt="/esi/fragment1.html"/>
</body></html>

フラグメントfrag_exclusion.htmlには、<esi:exclude>という存在しないESIタグの構文が含まれています。

Simple inclusion succeeded.
<esi:exclude src="/cgi-bin/esi-headers.sh?/esi/fragment1.html"/>

そのため、frag_exclusion.htmlのかわりにフラグメントfragment1.htmlがフラグメントとして使用されます。

Simple inclusion succeeded.

ブラウザに返されるレスポンスは次のとおりです。

<html><body>
Simple inclusion test. Simple inclusion succeeded.
</body></html>

次に示すイベント・ログは、<esi:exlude>キーワードに伴う問題を報告しています。例外処理によって、ブラウザには、ESI例外のかわりに代替フラグメントが表示されます。

[24/Jul/2005:16:14:41 -0500] [detail] [ecid: 25733432444,0] [client: 127.0.0.1]
[host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html]
[24/Jul/2005:16:14:41 -0500] [error 12086] [ecid: 25733432444,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005:16:14:41 -0500] [warning 11064] [ecid: 25733432444,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error
[24/Jul/2005:16:14:41 -0500] [warning 12009] [ecid: 25733432444,0] Incorrect ESI
fragment exception in ESI template www.company.com:80/cgi-bin/esi-headers.sh?/
esi/inclusion_exclusion.html, fragment www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html

イベント・ログでイベントのシーケンスを分析することに加えて、HTMLレスポンス内の診断結果とイベント・ログ結果を表示することもできます。次に、文字列+wcdebugがURLに付加された場合のHTMLレスポンスを示します。テンプレート診断情報TU;max-age=30+60;age=0の意味は次のとおりです。

- Tは、このページがESIテンプレートで構成されていることを表します。

- Uは、このリクエストが失効しているオブジェクトの更新の結果であることを表します。

- max-age=30+60は、このオブジェクトがキャッシュに格納されてから30秒後に期限切れとなり、期限切れになってから60秒後にキャッシュから削除されることを表します。つまり、このオブジェクトはキャッシュに格納されてから、合計で90秒間存在することになります。

- age=0は、キャッシュに格納されてから0秒経過したことを表します。つまり、期限切れになるまで残り30秒、削除されるまで残り60秒ということになります。

フラグメント診断情報FM;max-age=30+0;age=0の意味は次のとおりです。

- Fは、このページがESIフラグメントであることを表します。

- Uは、このリクエストがキャッシュ・ミスの結果であることを表します。

- max-age=30+0は、このオブジェクトがキャッシュに格納されてから30秒後に期限切れとなり、期限切れになってから0秒後にキャッシュから削除されることを表します。つまり、このオブジェクトはキャッシュに格納されてから、合計で30秒間存在することになります。

- age=0は、キャッシュに格納されてから0秒経過したことを表します。つまり、期限切れになって削除されるまで残り30秒ということになります。

Web Cache Debug Info: Web Cache Debug Info: TU;max-age=30+60;age=0
Simple inclusion test: Web Cache Debug Info: Web Cache Debug Info: TU;max-age=30+60;age=0
Web Cache Debug Info: FM;max-age=30+0;age=0

[EVENTLOG]
[24/Jul/2005:16:17:23 -0500] [detail] [ecid: 25733598670,0] [client: 127.0.0.1] [host: www.company.com:80] [url: /cgi-bin/esi-headers.sh?/esi/inclusion_exclusion.html]
[24/Jul/2005:16:17:23 -0500] [error 12086] [ecid: 25733598670,0] ESI syntax error. Unrecognized keyword exclude is at line 2.
[24/Jul/2005:16:17:23 -0500] [warning 11064] [ecid: 25733598670,0] ESI object www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html parsing error
[24/Jul/2005:16:17:23 -0500] [warning 12009] [ecid: 25733598670,0] Incorrect ESI
fragment exception in ESI template www.company.com:80/cgi-bin/esi-headers.sh?/
esi/inclusion_exclusion.html, fragment www.company.com:80/cgi-bin/esi-headers.sh?/esi/frag_exclusion.html
Simple inclusion succeeded.

A.5 HTTPトラフィック変更の影響

Oracle Web Cacheが既存のWebアプリケーション・サーバー環境に追加された場合は、HTTPトラフィックの変更によって次のアプリケーションの側面に影響が出ます。

- プロトコル/ホスト名/ポート・マッピング
トラフィックがOracle Web Cache経由で転送されることを保証するために、Oracle Web Cacheのプロトコル、ホスト名、およびポート番号を使用するようにすべての絶対URLを構成します。また、Oracle HTTP Serverのhttpd.confファイル内のPortディレクティブにOracle Web Cacheリスニング・ポートが指定されていることを保証します。

- SSL処理
クライアントとOracle Web Cache間の接続はHTTPSでも、Oracle Web Cacheとオリジン・サーバー間の接続がHTTPの場合は、Oracle Web Cacheに証明書管理を追加します。

- ページ配信タイミング
圧縮されたページまたは処理が必要なページの場合は、Oracle Web Cacheでオリジン・サーバーからページ全体が届くまで待ってからブラウザに送信されます。

- HTTPプロトコル
Oracle Web Cacheでは次の処理が透過的に行われます。

- Oracle Web Cacheで、オリジン・サーバーとクライアント間のプロトコル・バージョンがアップグレートまたはダウングレードされます。

- キャッシュ可能オブジェクトの場合は、最初のリクエストのチャンクされたエンコーディングではなく、Content-Lengthレスポンス・ヘッダーを持つコンテンツがOracle Web Cacheからクライアントに送信されます。

- キャッシュ・ヒットの場合は、Content-Lengthレスポンス・ヘッダー・フィールドがオリジン・サーバーから送信されたものと違っていれば、Oracle Web Cacheによって上書きされます。この機能によって、ブラウザで完全なページの内容が受信されることが保証されます。

A.6 追加情報

次の場所で、その他の解決方法を見つけることができます。

- Oracle MetaLink、http://metalink.oracle.com。問題の解決方法が見つからない場合は、サービス・リクエストを記録してください。

- Oracle Web Cacheフォーラム
http://forums.oracle.com/forums/forum.jspa?forumID=8

用語集

アクセス・ログ

あるWebサイトについて、Oracle Web Cacheに送信されたHTTPリクエストに関する情報が含まれるログ・ファイル。アクセス・ログのファイル名はaccess_logで、デフォルトで次のディレクトリに格納されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

adminサーバー・プロセス

管理、構成および監視機能を提供するOracle Web Cacheのプロセス。

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

Webサイトのデータ管理、そのデータへのアクセス制御およびクライアント・リクエストへの応答を行うオリジン・サーバー。Webサーバー上のアプリケーションはデータベースとのインタフェースとして機能し、Webサーバーによってリクエストされた作業を実行します。

キャッシュ・クラスタ

協調して動作する疎結合されたOracle Web Cacheのキャッシュ・インスタンスの集まりで、1つの論理キャッシュを構成します。キャッシュ・クラスタを使用すると、キャッシュに障害が発生した場合に、自動的に、障害が検出されてフェイルオーバー処理が実行されるので、Webサイトの可用性が高くなります。

キャッシュ・クラスタ・メンバー

他のOracle Web Cacheインスタンスとともに構成された、1つの論理キャッシュとして動作するOracle Web Cacheインスタンス。キャッシュ・クラスタ・メンバーは、他のキャッシュ・クラスタ・メンバーがキャッシュしているキャッシュ可能なコンテンツをリクエストしたり、キャッシュ・クラスタ・メンバーに障害が発生したことを検出するために互いに通信します。

キャッシュ階層

Oracle Web Cacheが、コンテンツ別のOracle Web Cacheからローカルにキャッシュする配置。Oracle Web Cacheは、分散ネットワークでは分散キャッシュ階層をサポートし、ESIプロバイダ・サイトの構成ではESIキャッシュ階層をサポートします。

キャッシュ・ヒット

オリジン・サーバーに送信せずにOracle Web Cacheのキャッシュに格納されているオブジェクトで処理可能なHTTPまたはHTTPSリクエスト。

キャッシュ・ミス

キャッシュでは処理できないため、オリジン・サーバーに送信する必要があるHTTPまたはHTTPSリクエスト。

cacheサーバー・プロセス

接続管理とリクエスト処理を行うことによってキャッシュを管理するOracle Web Cacheのプロセス。

許容量

オリジン・サーバーの場合は、オリジン・サーバーが受け入れ可能な最大同時接続数。

キャッシュ・クラスタの場合は、他のすべてのキャッシュ・クラスタ・メンバーからこのキャッシュ・クラスタ・メンバーへの同時接続数を示す絶対許容量とキャッシュ・クラスタ・メンバーの相対許容量。

カテゴリCookie

1つのページの複数のバージョンを異なるカテゴリのユーザーに渡すためのCookie。

集中キャッシュ

分散キャッシュ階層内で、少なくとも1つのリモート・キャッシュに対してオリジン・サーバーとして動作するOracle Web Cacheサーバー。コンテンツが無効になると、集中キャッシュは整合性を保つために無効化リクエストをリモート・キャッシュに伝播します。

CLF(CLF)

「共通ログ形式(CLF)」を参照してください。

共通ログ形式

Webトランザクション・ログ・ファイルの業界標準の形式。

Cookie

HTTPリクエスト内で、オリジン・サーバーからWebブラウザに送信される状態情報のパケット。後続のHTTPリクエストでは、Cookieはオリジン・サーバーに返され、オリジン・サーバーが最後のトランザクションの状態を記憶することが可能となります。

分散キャッシュ階層

集中キャッシュがリモート・キャッシュに対してオリジン・サーバーとして動作するキャッシュ階層。

DMZ(DMZ)

非武装地帯(DMZ)または境界ネットワークは、組織の内部ネットワークと外部ネットワーク(通常はインターネット)との間に位置するネットワーク領域(サブネットワーク)です。DMZの目的は、内部および外部のネットワークからDMZへの接続を許可する一方で、DMZからの接続は外部ネットワークに限定することにあります。DMZ内のホストは内部ネットワークには接続できません。これにより、DMZ内のホストが侵入者によって危険にさらされた場合でも、DMZのホストは、内部ネットワークを保護しながら、内部および外部の両方のネットワークにサービスを提供できます。

DNS(DNS)

「ドメイン・ネーム・システム(DNS)」を参照してください。

ドメイン・ネーム・システム

ドメイン階層として編成された、コンピュータおよびネットワーク・サービスのネーミング・システム。DNSは、TCP/IPネットワーク内で、ユーザー・フレンドリな名前を使用してコンピュータの位置を特定するために使用されます。DNSにより、ユーザー・フレンドリな名前は、コンピュータが識別可能なIPアドレスに解決されます。

Document Type Definition(DTD)

オブジェクト・クラスの記述方法を定義するマークアップ宣言。

Edge Side Includes (ESI)

HTMLフラグメントによりページの部分的なキャッシュを可能にするマークアップ言語。

埋込みURLパラメータ

オブジェクトのURLに埋め込まれているパラメータ情報。Oracle Web Cacheでは、疑問符(?)、アンパサンド(&)、ドル記号($)またはセミコロン(;)をデリミタとして使用したリクエストを処理可能です。

ESI(ESI)

「Edge Side Include((ESI)」を参照してください。

ESIキャッシュ階層

プロバイダ・キャッシュがサブスクライバ・キャッシュに対してオリジン・サーバーとして動作するキャッシュ階層。

ESIプロバイダ・サイト

Oracle Web CacheがEdge Side Include(ESI)アセンブリのみを目的として通信するサイト。ブラウザからこれらのサイトのコンテンツをリクエストすることは許可されません。

イベント・ログ

Oracle Web Cacheのイベントおよびエラー情報が含まれるログ・ファイル。イベント・ログのファイル名はevent_logで、次のディレクトリに格納されます。

(UNIX) ORACLE_INSTANCE/diagnostics/logs/WebCache/<webcache_name>
(Windows) ORACLE_INSTANCE\diagnostics\logs\WebCache\<webcache_name>

有効期限

指定された期間キャッシュに存在した後、オブジェクトを無効にする機能。オブジェクトが無効になっているときに、クライアントがそれらをリクエストすると、オブジェクトはキャッシュから即時に削除され更新されるか、またはオリジン・サーバーによるオブジェクトの更新可能時期に基づいて更新されます。

拡張ログ形式

拡張可能であり、より多様なデータの取得を可能にする、改善されたHTTPサーバーのログ形式。XLFを使用すると、HTTPリクエストの様々な統計(クライアントのIPアドレスなど)、HTTPリクエストのメソッドおよびレスポンス・ヘッダー(User-AgentやAcceptなど)を生成するようにログ出力を構成できます。

eXtensible Markup Language(XML)

柔軟な共通の情報フォーマットの作成方法を提供する言語。XMLは、無効化メッセージおよびレスポンスに使用されています。

ファーム

Fusion Middleware Controlによって管理されるコンポーネントの集まり。0個または1個の管理対象サーバー・ドメイン、およびそのドメインでインストールされ、構成され、稼働しているOracle Fusion Middlewareシステム・コンポーネントで構成されます。

フェイルオーバー

オリジン・サーバーで障害が発生した場合、Oracle Web Cacheは、負荷を自動的に他のオリジン・サーバーに分散し、障害の発生したオリジン・サーバーが再びオンラインになるまで、その稼働または停止状況をポーリングします。キャッシュ・クラスタ環境では、Oracle Web Cacheは、障害の発生したメンバーから他のクラスタ・メンバーへコンテンツの所有権を移動します。

障害検出

キャッシュ・クラスタ環境では、Oracle Web Cacheは、キャッシュ・クラスタ・メンバーの使用不可状態を検出します。

GETメソッド

Webページの単純なリクエストに使用されるHTTPリクエスト・メソッド。GETメソッドはURLで構成されます。GETメソッドを使用するページへのリクエストは、通常キャッシュされます。

問合せ文字列が含まれるGETメソッド

パラメータおよび値が含まれているURLおよび問合せ文字列によって構成されたHTTPリクエスト・メソッド。次に、問合せ文字列が含まれるGETメソッドの例を示します。

http://www.myserver.com/setup/config/navframe?frame=default

このリクエストにより、www.myserver.comサーバーの/setup/configディレクトリ内に含まれているnavframeというスクリプトが実行され、frame変数に値defaultが代入されたものがスクリプトに渡されます。

注意:
オリジン・サーバーまたはデータベースに変更を加える問合せ文字列が含まれるGETメソッドのページをキャッシュしないでください。問合せ文字列が含まれるGETメソッドを使用するページは、検索で使用されている場合にのみキャッシュしてください。

ガベージ・コレクション

使用頻度と妥当性に基づいて、失効しているオブジェクトを削除するOracle Web Cacheのプロセス。

HTTPプロトコル

Hypertext Transfer Protocol。ブラウザとオリジン・サーバーとの通信を可能にする言語を提供するプロトコル。

HTTPリクエスト・ヘッダー

Webブラウザから、リクエストおよびWebブラウザ自体に関する追加情報をオリジン・サーバーに送信可能にするヘッダー。

HTTPリクエスト・メソッド

クライアントのリクエストの目的を指定する、HTTPリクエストに含まれたメソッド。HTTPでは様々なメソッドがサポートされていますが、キャッシュに関連するメソッドには、GET、問合せ文字列が含まれるGETおよびPOSTがあります。

HTTPSプロトコル

Secure Hypertext Transfer Protocol。Secure Sockets Layer (SSL)を使用して、ユーザー・ページ・リクエストおよびオリジン・サーバーから返されたページの暗号化と復号化を行うプロトコル。

無効化

オブジェクトを無効にするOracle Web Cacheの機能。無効とマークされたオブジェクトをクライアントがリクエストすると、オブジェクトがキャッシュから削除され、オリジン・サーバーから新しいコンテンツが取得されてキャッシュが更新されます。無効化処理により、Oracle Web Cacheのキャッシュとオリジン・サーバーのコンテンツとの一貫性が保たれます。

無効化コーディネータ

キャッシュ・クラスタ環境では、Oracle Web Cacheは、無効化メッセージを他のキャッシュ・クラスタ・メンバーに伝播します。無効化メッセージは、コーディネータとして機能する1つのキャッシュ・クラスタ・メンバーに送信されます。コーディネータは無効化メッセージを他のクラスタ・メンバーに伝播します。

IPアドレス

ネットワーク上のノードを識別するために使用します。ネットワーク上の各コンピュータには、ネットワークIDと一意のホストIDからなる一意のIPアドレスが割り当てられます。通常、このアドレスは、8ビットずつの10進値をピリオドで区切ったドット10進表記(144.45.9.22など)で表されます。

待機時間

ネットワークのラウンドトリップにかかる時間。

ロード・バランシング

1つのサーバーの負荷が過大にならないように、HTTPリクエストを複数のオリジン・サーバー間に分散する機能。

レイヤー7(L7)スイッチ

Open Systems Interconnection(OSI)モデルの第7層(アプリケーション層)にロード・バランシング機能を提供するネットワーク・スイッチ。L7スイッチは、URLのコンテンツに基づいてロード・バランシングの決定を行います。

ロード・バランサ

受信リクエストによる負荷を均衡させるメカニズム。このメカニズムは通常、レイヤー7(L7)スイッチなど、ネットワーク・スイッチ形式のハードウェア・ロード・バランサです。通常、ハードウェア・ロード・バランサは、Oracle Web Cacheサーバーの前面に配置されます。ハードウェア・ロード・バランサを使用できない環境では、Oracle Web Cacheをソフトウェア・ロード・バランサとして機能させることが可能です。

オンデマンド・コンテンツ

キャッシュ・クラスタ環境でのオンデマンド・コンテンンツ。各クラスタ・メンバーのキャッシュに格納されているポピュラーなオブジェクトで構成されています。

Open Systems Interconnection(OSI)

ISOにより、異機種間コンピュータ・ネットワーク・アーキテクチャのフレームワークとして開発されたネットワーク・アーキテクチャのモデル。

OSIアーキテクチャは7層に分かれており、下位の層から順に、次のようになっています。

1. 物理層

2. データ・リンク層

3. ネットワーク層

4. トランスポート層

5. セッション層

6. プレゼンテーション層

7. アプリケーション層

各層では、その直下の層を使用し、上位の層にサービスを提供します。

Oracle Enterprise Manager

Oracle Application Serverを管理するためのツール。アプリケーション・サーバーとそのコンポーネントの管理、構成および監視に対する完全な管理ソリューション。これを使用して次のことができます。

- Oracle Web Cacheの全体的なステータスの表示

- パフォーマンス・メトリックの表示

Oracle Web Cache Manager(Oracle Web Cache Manager)

構成機能とコンポーネント制御機能を組み合せることにより、Oracle Web Cacheの構成および管理のための統合環境を提供するツール。

オリジン・サーバー

内部サイト用のWebアプリケーション・サーバーまたはファイアウォールの外側の外部サイト用のプロキシ・サーバーのどちらか。

OSI(OSI)

「Open System Interconnection(OSI)」を参照してください。

所有コンテンツ

キャッシュ・クラスタ環境で、特定のキャッシュ・クラスタ・メンバーにより所有されているコンテンツ。キャッシュ・コンテンツは、Oracle Web Cacheによって、キャッシュ・クラスタ・メンバーに配布されます。実際は、コンテンツを特定のキャッシュ・クラスタ・メンバーが所有するように割り当てます。

ページの部分的なキャッシュ

Oracle Web CacheでHTMLオブジェクトのフラグメントを個別にキャッシュおよび管理できるようにする機能。Oracle Web CacheにHTMLフラグメントをフェッチして挿入するように指示するEdge Side Include(ESI)マークアップ・タグでテンプレート・ページが構成されます。フラグメント自体は、ディスクリート・テキストまたはその他のオブジェクトが含まれているHTMLファイルです。

パフォーマンス保証ヒューリスティック

Oracle Web Cacheによるオブジェクトのキュー順序を割当て可能にするヒューリスティック。このヒューリスティックにより、無効な状態でも表示してよいオブジェクトとすぐに取得する必要のあるオブジェクトが判別されます。優先順位の高いオブジェクトは先に取得され、優先順位の低いオブジェクトは後で取得されます。

オブジェクトのキュー順序は、オブジェクトの使用頻度と、無効化時に割り当てられたオブジェクトの妥当性に基づいて決定。オリジン・サーバーの現在の負荷と許容量を超過していない場合、まず、使用頻度が高く、妥当性の低いオブジェクトが更新されます。

パーソナライズ属性

汎用的なページに、「Hello, Name」のようなパーソナライズされた挨拶文、アイコン、アドレス、ショッピング・カートの一部などのパーソナライズ属性が含まれているページ。パーソナライズ属性の値にCookieまたは埋込みURLパラメータに含まれる情報を代入するようにOracle Web Cacheを構成できます。

使用頻度

オブジェクトがキャッシュに格納されて以来、そのオブジェクトに対するリクエスト数と、ドキュメントに対する最近のリクエスト数。

POST本体のパラメータ

オブジェクトのPOST本体に埋め込まれているパラメータ情報。

POSTメソッド

オリジン・サーバーのデータ・ストアの内容を変更するリクエストに使用されるHTTPリクエスト・メソッド。たとえば、メーリング・リストへのメッセージの送信、登録用フォームの送信、データベースへのエントリの追加などです。

注意:
オリジン・サーバーまたはデータベースに変更を加えるPOSTメソッドを使用したページをキャッシュしないでください。POSTメソッドを使用したページは、検索で使用されている場合にのみキャッシュ可能です。

プロキシ・サーバー

実際のサーバーのかわりとなるオリジン・サーバーで、クライアントの接続リクエストを実際のサーバーや他のプロキシ・サーバーに転送します。プロキシ・サーバーは、アクセス制御、データとシステムのセキュリティ、監視およびキャッシュ機能を提供します。

プロバイダ

1つの中心的な場所に集められた一連のコンテンツ(コンテンツ領域、ページ、アプリケーションおよび外部ソースのデータ)。ページと呼ばれる共通のインタフェースを介してアクセスされます。

プロバイダ・キャッシュ

ESIキャッシュ階層内で、プロバイダ・サイト用にコンテンツをローカルにキャッシュするOracle Web Cacheサーバー。サブスクライバ・キャッシュがこのプロバイダ・キャッシュと通信してHTMLフラグメントを組み立てます。コンテンツが無効になると、プロバイダ・キャッシュは整合性を保つために無効化リクエストをサブスクライバ・キャッシュに伝播します。

プロバイダ・サイト

プロバイダ・キャッシュおよびサブスクライバ・キャッシュにコンテンツのソースを提供するサイト。

正規表現

Oracle Web Cacheでは、Netscape Proxy Server 2.5でサポートされている、URL用POSIX 1003拡張正規表現がサポートされています。

正規表現の構文は、http://www.cs.utah.edu/dept/old/texinfo/regex/regex_toc.htmlを参照してください。

リモート・キャッシュ

分散キャッシュ階層内で、集中キャッシュのコンテンツをローカルのリクエストとして処理するためにキャッシュするOracle Web Cacheサーバー。集中キャッシュに無効化リクエストが送信されると、コンテンツの整合性を保つために、集中キャッシュはこのリクエストをリモート・キャッシュに伝播します。

リバース・プロキシ

クライアントからはコンテンツ・サーバーのように見えますが、内部的には他のバックエンド・オリジン・サーバーからオブジェクトをプロキシとして取得するサーバーです。リバース・プロキシは、オリジン・サーバーへのゲートウェイとして機能します。ファイアウォールの外側から受信したリクエストをファイアウォールの内側にあるオリジン・サーバーに中継し、取得したコンテンツをクライアントに送信します。

ラウンドロビン法

接続の負荷を複数のサーバーに分散して、サーバーの負担を管理する方法。ラウンドロビン法により、構成済サーバーのリストにある最初のオリジン・サーバーがリクエストを受信すると、2番目のオリジン・サーバーが次のリクエストを受信する、というようにしてリクエストの入替えが行われます。

Secure Sockets Layer(SSL)

Netscape社によって開発されたプロトコル。SSLは、ネットワーク・トランスポート層のセキュリティの業界標準。SSLにより、認証、暗号化およびデータの整合性が公開鍵インフラストラクチャ(PKI)で提供されます。Oracle Web CacheではSSLをサポートすることにより、HTTPSプロトコル・リクエストのページをキャッシュできます。

セレクタ

Oracle Web Cacheでは、セレクタを使用して、キャッシュ・ルールによるフィルタ処理およびリクエストに対する適切なルールの特定を行います。キャッシュ可能かどうかが、次のセレクタを元に評価されます。

- 式タイプ

- URL式

- オブジェクトのHTTPリクエスト・メソッド

- 埋込みURLおよびPOST本体のパラメータ

- HTTPのPOSTメソッドのボディ

セッション・バインディング

一定期間ある状態を維持するために、特定のオリジン・サーバーにユーザー・セッションをバインドするプロセス。

セッションCookie

Webサイトでユーザー・セッションをトラッキングするためのCookie。

セッション・エンコードされたURL

ユーザーを識別するために埋め込まれたセッション情報を含む、<A HREF=...>のようなHTMLハイパーリンク・タグ。HTMLのハイパーリンク・タグにあるセッション・パラメータの値にセッションCookieまたは埋込みURLパラメータに含まれるセッション情報を代入するようにOracle Web Cacheを構成可能です。

サブスクライバ・キャッシュ

ESIキャッシュ階層内で、テンプレートのHTMLフラグメントについてプロバイダ・キャッシュと通信してESIコンテンツを組み立てるOracle Web Cacheサーバー。取得したHTMLフラグメントとテンプレートで完全なページが組み立てられます。プロバイダ・サイトのコンテンツが無効になると、プロバイダ・サイトは整合性を保つために無効化リクエストをサブスクライバ・キャッシュに伝播します。

Uniform Resource Identifier(URI)

URLの作成に使用されるアドレス構文。

Uniform Resource Locator(URL)

インターネット上でのファイルの場所とルーティングを指定する規格。URLはブラウザによってWorld Wide Web上での移動に使用され、プロトコル、ドメイン名、ディレクトリ・パスおよびファイル名で構成されます。たとえば、http://www.oracle.com/technology/index.htmlの場合は、ブラウザがWorld Wide Web上でOracle Technology Networkのメイン・ページを見つけるために使用する場所とパスが指定されます。

URI(URI)

「Uniform Resource Identifier(URI)」を参照してください。

URL(URL)

「Uniform Resource Locator(URL)」を参照してください。

妥当性

オブジェクトの有効期限、無効化時刻および削除時刻。

仮想ホスト・サイト

Oracle Web Cacheによってホスティングされるサイト。ブラウザは、これらのサイトのキャッシュ内コンテンツを、Oracle Web Cacheを介してリクエストできます。Oracle Web Cacheでは、コンテンツをキャッシュするだけでなく、これらのサイトからESIフラグメントを組み立てることもできます。

ウォレット

キー、証明書、およびSSLに必要な信頼できる証明書などの認証データを管理するための透過的なデータベース。ウォレットには、X.509バージョン3証明書、秘密鍵および信頼できる証明書のリストが含まれています。

許容負荷容量

オリジン・サーバーが受入れ可能な利用できる許容量のパーセンテージ。

webcachectlユーティリティ

Oracle Web Cacheをスタンドアロン環境で実行している場合(つまり、Oracle Application Serverのインストールの一環としてOracle Web Cacheをインストールしたのでなく、Oracle Web Cache製品のみを含んだキットからOracle Web Cacheをインストールした場合)に、adminサーバー・プロセス、cacheサーバー・プロセスおよびauto-restartプロセスの起動、停止、再起動に使用するユーティリティ。

XLF(XLF)

「拡張ログ形式(XLF)」を参照してください。

XML(XML)

「Extensible Markup Language(XML)」を参照してください。

索引

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X

記号

\(バックスラッシュ)

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

. (ピリオド)

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

"(二重引用符)

正規表現, 7.5.1, 7.7.2.1, 7.7.2.2

$(ドル記号)

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

&(アンパサンド)

正規表現, 7.5.1, 7.7.2.1, 7.7.2.2

<!--esi-->タグ、Edge Side Includes(ESI), 11.4.10 '(一重引用符)

正規表現, 7.5.1

*(アスタリスク)

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

+wcdebug文字列, 8.8 >(右山カッコ)

正規表現, 7.5.1, 7.7.2.1, 7.7.2.2

?(疑問符)

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

[ ](大カッコ)記号

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

^(キャレット)記号

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

{ }(中カッコ)記号

パス接頭辞の表現, 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

数字

1024ポート, 2.11.1.3, 2.11.1.4, 5.4.2, 5.5.1, 5.9

80ポート, 12.1.1, 12.1.1

A

Acceptリクエスト・ヘッダー・フィールド, 6.5.1, 9.2.2.1

Accept-Charsetリクエスト・ヘッダー・フィールド, 6.5.1

Accept-Encodingリクエスト・ヘッダー・フィールド, 6.5.1

Accept-Languageリクエスト・ヘッダー・フィールド, 6.5.1

アクセス制御, 5.3

アクセス・ログのフィールド

バイト, 9.2.2

c-ip, 9.2.2, 9.2.2

cs, 9.2.2

cs-bytes, 9.2.2

cs-method, 9.2.2

cs-uri, 9.2.2

cs-uri_stem, 9.2.2

cs-uri-query, 9.2.2

date, 9.2.2

r-time-taken, 9.2.2

sc, 9.2.2

sc-status, 9.2.2

s-ip, 9.2.2

time, 9.2.2

time-taken, 9.2.2

x-auth-id, 9.2.2

x-cache, 9.2.2

x-cache-detail, 9.2.2

x-clf-date, 9.2.2

x-cluster, 9.2.2

x-conn-abrt, 9.2.2

x-cookie, 9.2.2

x-date-end, 9.2.2

x-date-start, 9.2.2

x-ecid, 9.2.2

x-esi-info, 9.2.2

x-glcookie-set, 9.2.2

x-log-id, 9.2.2

x-os-name, 9.2.2

x-os-timeout, 9.2.2

x-protocol, 9.2.2

x-req-line, 9.2.2

x-req-type, 9.2.2

x-time-delay, 9.2.2

x-time-end, 9.2.2

x-time-handshake, 9.2.2

x-time-reqblocked, 9.2.2

x-time-reqqueued, 9.2.2

x-time-reqrecvlatency, 9.2.2

x-time-reqsendlatency, 9.2.2

x-time-resprecvlatency, 9.2.2

x-time-respsendlatency, 9.2.2

x-time-start, 9.2.2

アクセス・ログ

構成, 9.4

カスタマイズされたログ形式, 9.5

カスタマイズされたロールオーバー・ポリシー, 9.6

例, 9.2.3

形式, 9.2.1

複合ログ形式, 9.2.1.3

共通ログ形式(CLF), 9.2.1.1

エンド・ユーザー・パフォーマンス監視の形式, 9.2.1.5

拡張CLF(ECLF), 9.2.1.2

拡張複合ログ形式, 9.2.1.4

ロールオーバー, 9.8 表示, 9.7 アクセス・ログのフィールド

説明, 9.2.2

Fusion Middleware Controlの「アクセス・ログ」メニュー・オプション, 2.6.2 access_log.fragmentファイル, 9.2.2, 9.4 access_log.yyyymmddhhmmファイル, 9.4, 9.6, 9.6 ACTION要素

無効化メッセージ, 7.5.1

adminサーバー・プロセス

説明, 2.8, 2.13

webcachea実行可能ファイル, 2.13

Fusion Middleware Controlの「管理」メニュー, 2.6.2 管理のみのクラスタ, 3.6.7, 3.7.6 Oracle Web Cache Managerの「Advanced Content Invalidation」メニュー・オプション, 2.7.2 ADVANCEDSELECTOR要素

無効化メッセージ, 7.5.1

別名, 2.2 Apache Tomcat, 12.3 API

jawc.jar, 7.7.3

wxvappl.sql, 7.7.3

wxvutil.sql, 7.7.3

attemptタグ、Edge Side Includes(ESI), 11.4.8 監査ログ, 9.9 Fusion Middleware Controlの「監査ポリシー」メニュー・オプション, 2.6.2 認可, 5.1.3 Authorizationリクエスト・ヘッダー・フィールド, 6.3, 9.2.2.1

B

バックエンド・フェイルオーバー, 3.1.3

Oracle Web Cache Managerの「Basic Content Invalidation」メニュー・オプション, 2.7.2

BASICSELECTOR要素

無効化メッセージ, 7.5.1

バインディング、セッション, 1.2.6 BODYEXP属性

無効化メッセージ, 7.5.1

busy_error.htmlファイル, 2.11.6

C

キャッシュ・クラスタ・メンバー, 3.3

キャッシュ・クラスタ

キャッシュ・メンバーの追加

Oracle Web Cache Manager, 3.7.2

キャッシュ・メンバーの追加

Fusion Middleware Control, 3.6.3

キャッシュの追加, 3.7.2 メンバーの追加, 3.7.2, 3.7.5 管理のみ, 3.6.7, 3.7.6 認証, 3.3 利点, 3.3 キャッシュ・クラスタの設定

Fusion Middleware Control, 3.6.3

Oracle Web Cache Manager, 3.7.1

クライアント側の証明書, 5.5.2, 5.5.2.2 デプロイ, 10.1 フェイルオーバー

フェイルオーバーのしきい値, 3.6.3, 3.7.1

pingのURL, 3.6.3, 3.7.1

ポーリングの間隔, 3.6.3, 3.7.1

無効化, 3.3, 7.7.2.1, 7.10.2.1 無効化のみ, 3.6.7, 3.7.6 名前, 3.7.1 オンデマンド・コンテンツ, 3.3 概要, 3.3 所有コンテンツ, 3.3 キャッシュ・メンバーの削除

Fusion Middleware Control, 3.6.6

Oracle Web Cache Manager, 3.7.5

セッション・バインディング

Fusion Middleware Control, 3.6.4

Oracle Web Cache Manager, 3.7.3

構成の同期

Fusion Middleware Control, 3.6.5, 3.7.4

無効化メッセージの同期

Fusion Middleware Control, 3.6.7, 3.7.6

キャッシュの内容

リストの作成, 8.2

ファイルへの書込み, 8.7

CACHE要素、webcache.xmlファイル, 3.8 キャッシュ階層

デプロイ, 10.2, 10.2

キャッシュ・ヒット

説明, 1.1.1, 6.1

キャッシュのメモリー

構成, 2.11.5

説明, 2.3.1

キャッシュ・ミス

説明, 1.1.1, 6.1

Oracle Web Cache Managerの「Cache Operations」メニュー・オプション, 2.7.2 キャッシュへのデータ格納, 6.1 cacheサーバー・プロセス

説明, 2.8, 2.13

webcached実行可能ファイル, 2.13

キャッシュ・サイズ

構成, 2.11.5

最大サイズ, 2.3.1

Cache-Controlリクエスト・ヘッダー・フィールド, 9.2.2.1 Cache-Controlレスポンス・ヘッダー・フィールド, 6.3, 9.2.2.1 キャッシュするオブジェクト

最大サイズ, 2.3.3

キャッシュ・ルール

構成, 6.8

一般ルール, 6.8.1

HTTPエラー・レスポンス, 6.8.5

パラメータの値の無視, 6.8.3

MIMEタイプに基づく, 6.8.1

1つのオブジェクトの複数のバージョン, 6.8.2

ポピュラーなページ, 6.8.8

セッション・キャッシュ・ルール, 6.8.6, 6.8.7

URLに基づく, 6.8.1

1つのオブジェクトの複数のバージョン, 6.8.4 概要, 6.3 優先順位, 6.4 セキュア, 5.8 サマリー統計, 6.9 トラブルシューティング, A.3 Fusion Middleware Controlの「キャッシュ・ルール」メニュー・オプション, 2.6.2 CALYPSONETINFO要素、webcache.xmlファイル, 6.8.4, A.1.4, A.1.7 許容量

クラスタ・メンバー, 3.7.1

オリジン・サーバー, 2.11.2

トラブルシューティング, A.1.5

カスケード・スタイル・シート、圧縮, 1.2.5 カテゴリCookie

説明, 6.5.1

リクエストおよびレスポンスの値の比較, 6.5.1

認証局(CA), 5.1.1.2.1 証明書失効リスト, 5.1.1.2.2 証明書

クライアント側, 5.1.1.2.2, 5.5.2

構成, 5.5.2

サーバー側, 5.1.1.2.2, 5.1.1.2.2 chooseタグ、Edge Side Includes(ESI), 11.4.1 クライアントIPリクエスト・フィルタ

構成, 4.6

説明, 4.2

ClientIPリクエスト・ヘッダー

転送, 5.7

クライアント側の証明書, 5.1.1.2.2, 5.5.2

クラスタ, 5.5.2

構成, 5.5.2

キャッシュ・クラスタ, 5.5.2.2

分散キャッシュ階層, 5.1.1.2.2 サイト用, 5.5.2.3 サイト, 5.1.1.2.2, 5.1.1.2.2 Fusion Middleware Controlの「クラスタ」メニュー・オプション, 2.6.2 クラスタ

キャッシュ・メンバーの追加

Oracle Web Cache Manager, 3.7.2

キャッシュ・メンバーの追加

Fusion Middleware Control, 3.6.3

キャッシュの追加, 3.7.2 メンバーの追加, 3.7.2, 3.7.5 管理のみ, 3.6.7, 3.7.6 認証, 3.3 利点, 3.3 キャッシュ・クラスタの設定

Fusion Middleware Control, 3.6.3

Oracle Web Cache Manager, 3.7.1

クライアント側の証明書, 5.5.2, 5.5.2.2 デプロイ, 10.1 フェイルオーバー

フェイルオーバーのしきい値, 3.6.3, 3.7.1

pingのURL, 3.6.3, 3.7.1

ポーリングの間隔, 3.6.3, 3.7.1

無効化, 3.3, 7.7.2.1, 7.10.2.1 無効化のみ, 3.6.7, 3.7.6 オンデマンド・コンテンツ, 3.3 概要, 3.3 所有コンテンツ, 3.3 キャッシュ・メンバーの削除

Fusion Middleware Control, 3.6.6

Oracle Web Cache Manager, 3.7.5

構成の同期

Fusion Middleware Control, 3.6.5, 3.7.4

無効化メッセージの同期

Fusion Middleware Control, 3.6.7, 3.7.6

複合ログ形式, 9.2.1.3 commentタグ、Edge Side Includes(ESI), 11.4.2 共通ログ形式(CLF), 9.2.1.1 圧縮

カスケード・スタイル・シート, 1.2.5

構成

キャッシュ・ルール, 6.8.1

サイト用, 2.11.3

Surrogate-Controlレスポンス・ヘッダー・フィールドでのcompressディレクティブの使用, 6.10.1, 6.10.1

説明, 1.2.5 すべてのリクエストに対する無効化, 2.11.3.1 GIFファイル, 1.2.5 GZIPユーティリティ, 1.2.5 HTMLファイル, 1.2.5 Javascriptファイル, 1.2.5 JPEGファイル, 1.2.5 PNGファイル, 1.2.5 WinZipユーティリティ, 1.2.5 構成

アクセス制御, 5.3

アクセス・ログ, 9.4

キャッシュのメモリー, 2.11.5

キャッシュ・サイズ, 2.11.5

キャッシュ・ルール

ページの部分的なキャッシュ, 11.2.1

圧縮

キャッシュ・ルール, 6.8.1

サイト用, 2.11.3

Surrogate-Controlレスポンス・ヘッダー・フィールドでのcompressディレクティブの使用, 6.10.1, 6.10.1

Edge Side Includes(ESI), 11.2 イベント・ログ, 9.3 有効期限, 6.7 フェイルオーバー

キャッシュ・クラスタ, 3.6.3, 3.7.1

オリジン・サーバー, 2.11.2

HTTPSリクエスト, 5.4 ロード・バランサ

ハードウェア, 10.1

Microsoftネットワーク負荷分散, 3.9

Oracle Web Cacheソフトウェア, 3.8

オリジン・サーバーのロード・バランシング, 2.11.2 ページの部分的なキャッシュ, 11.2 パスワード, 5.2 キャッシュなしのリバース・プロキシ, 3.8 オリジン・サーバーへのセッションのバインディング, 3.2 サイト設定, 2.11.3 キャッシュなしのソフトウェア・ロード・バランサ, 3.8 接続数の制限

キャッシュ・クラスタ通信, 3.7.1

構成, 2.11.5

説明, 2.3.2

UNIXの場合, 2.3.2

Windowsの場合, 2.3.2

Connectionリクエスト・ヘッダー・フィールド, 9.2.2.1 Content-Encodingリクエスト・ヘッダー・フィールド, 9.2.2.1 Content-Encodingレスポンス・ヘッダー・フィールド, 1.2.5, 9.2.2.1 Content-Languageリクエスト・ヘッダー・フィールド, 9.2.2.1 Content-Languageレスポンス・ヘッダー・フィールド, 9.2.2.1 Content-Lengthリクエスト・ヘッダー・フィールド, 9.2.2.1, A.1.6 Content-Lengthレスポンス・ヘッダー・フィールド, 9.2.2.1 Content-Typeリクエスト・ヘッダー・フィールド, 9.2.2.1 Content-Typeレスポンス・ヘッダー・フィールド, 9.2.2.1 COOKIE要素

無効化メッセージ, 7.5.1

Cookieリクエスト・ヘッダー・フィールド, 6.3, 9.2.2.1

カテゴリCookie, 6.5.1

Edge Side Includes(ESI), 11.1.10

Cookie

1つのURLに対する複数のバージョンのカテゴリCookie, 6.5.1

セッションCookie

キャッシュ・ルール, 6.5.4, 6.8.6

セッション・バインディング, 1.2.6

セッション・エンコードされたURL, 6.5.5

D

データ整合性

クラスタ, 3.3

無効化、有効期限および検証, 6.2

Dateリクエスト・ヘッダー・フィールド, 9.2.2.1 Dateレスポンス・ヘッダー・フィールド, 9.2.2.1 キャッシュ・メンバーの削除, 3.6.6, 3.7.5 デプロイ、Oracle Web Cache

キャッシュ・クラスタ, 10.1

キャッシュ階層, 10.2

一般的な構成, 10.1

ロード・バランサ

ハードウェア, 10.1

ネットワーク, 10.3

ソフトウェア, 10.3

キャッシュなしのリバース・プロキシ, 10.3 診断情報

HTMLレスポンス・ボディ内の表示, 8.3

Serverレスポンス・ヘッダー・フィールド内の表示, 8.3

Oracle Web Cache Managerの「Diagnostics」メニュー・オプション, 2.7.2 DNSサーバー, 1.1.1 Document Type Definition(DTD)

WCSinvalidation.dtd, 7.5.1

E

ECID, 9.1.1.4

Edge Side Includes(ESI)

<!--esi-->タグ, 11.4.10

attemptタグ, 11.4.8

chooseタグ, 11.4.1

commentタグ, 11.4.2

Cookieリクエスト・ヘッダー・フィールド, 11.1.10

environmentタグ, 11.4.3

ESI for Java(JESI), 11.1.1.1

例

パーソナライズされた挨拶文, 11.2.3.2

ポータル・サイト, 11.2.3.1

Surrogate-Controlレスポンス・ヘッダー・フィールド, 6.10.1, 7.6

exceptタグ, 11.4.8 例外およびエラー処理, 11.1.7 HTTP_ACCEPT_LANGUAGE変数, 11.1.6.3 HTTP_COOKIE変数, 11.1.6.3 HTTP_HEADER変数, 11.1.6.3 HTTP_HOST変数, 11.1.6.3 HTTP_REFERER変数, 11.1.6.3 HTTP_USER_AGENT変数, 11.1.6.3 includeタグ, 11.2.3.1.2, 11.2.3.1.2, 11.4.4 inlineタグ, 11.2.3.1.1, 11.2.3.1.1, 11.2.3.1.1, 11.3, 11.4.5 invalidateタグ, 11.4.6 otherwiseタグ, 11.4.1 パーソナライズされた挨拶文, 11.2.2 QUERY_STRING_DECODED変数, 11.1.6.3 removeタグ, 11.4.7 Set-Cookieレスポンス・ヘッダー・フィールド, 11.1.10 Surrogate-Capabilityリクエスト・ヘッダー・フィールド, 11.1.3 Surrogate-Controlレスポンス・ヘッダー・フィールド, 6.10, 6.10.1, 11.3 タグ, 11 tryタグ, 11.4.8 varsタグ, 11.2.3.1.2, 11.4.9 whenタグ, 11.4.1 埋込みURLパラメータ

キャッシュ・ルール, 6.5.4, 6.8.6

パラメータの値の無視, 6.5.2, 6.8.3

セッション・バインディング, 1.2.6

セッション・エンコードされたURL, 6.5.5

EncodeBase64.javaファイル, 7.7.1 エンド・ユーザー・パフォーマンス監視の形式, 9.2.1.5 拡張CLF形式(ECLF), 9.2.1.2 拡張複合ログ形式, 9.2.1.4 environmentタグ、Edge Side Includes(ESI), 11.4.3 エラー・ページ

Edge Side Includes(ESI)インクルード・エラー用の構成, 11.1.7

デフォルト, 2.11.6

busy_error.html, 2.11.6

esi_fragment_error.txt, 2.11.6

network_error.html, 2.11.6

ESI for Java(JESI), 11.1.1.1 ESI、「Edge Side Includes(ESI)」を参照 esi_fragment_error.txtファイル, 2.11.6 ETagレスポンス・ヘッダー・フィールド, 9.2.2.1 イベント・ログ情報

HTMLレスポンス・ボディ内の表示, 8.3

Serverレスポンス・ヘッダー・フィールド内の表示, 8.3

イベント・ログ

構成, 9.3

例, 9.1.2

形式, 9.1.1

Oracle Diagnostic Logging(ODL), 9.1.1.1

Oracle Web Cache, 9.1.1.2

ロールオーバー, 9.8 表示, 9.7 Fusion Middleware Controlの「イベント・ログ」メニュー・オプション, 2.6.2 event_log.yyyymmddhhmmファイル, 9.3 exceptタグ、Edge Side Includes(ESI), 11.4.8 有効期限

概念, 6.2.1

構成, 6.7

Fusion Middleware Controlの「有効期限」メニュー・オプション, 2.6.2 Expiresレスポンス・ヘッダー・フィールド, 6.3, 9.2.2.1 コンテンツのリストのエクスポート, 8.7

F

フェイルオーバー

構成

キャッシュ・クラスタ, 3.6.3, 3.7.1

オリジン・サーバー, 2.11.2

フェイルオーバーのしきい値

キャッシュ・クラスタ, 3.6.3, 3.7.1

オリジン・サーバー, 2.11.2

概要

オリジン・サーバー, 3.1.3

pingのURL

キャッシュ・クラスタ・メンバー, 3.6.3, 3.7.1

オリジン・サーバー, 2.11.2

ポーリングの間隔

クラスタ・メンバー, 3.6.3, 3.7.1

オリジン・サーバー, 2.11.2

ファイル・ディスクリプタ

権限, 5.9

ファイル拡張子

キャッシュ・ルール, 6.8.1

Oracle Web Cache Managerの「Filtering」メニュー, 2.7.2 ファイアウォールとOracle Web Cacheのデプロイメント, 1.2.1 フォーマット・リクエスト・フィルタ

構成, 4.11

説明, 4.2

Fusion Middleware Control

ナビゲート, 2.6.2

Oracle Web Cache

「Access Logs」メニュー・オプション, 2.6.2

「管理」メニュー, 2.6.2

「監査ポリシー」メニュー・オプション, 2.6.2

「キャッシュ・ルール」メニュー・オプション, 2.6.2

「クラスタ」メニュー・オプション, 2.6.2

「Event Logs」メニュー・オプション, 2.6.2

「有効期限」メニュー・オプション, 2.6.2

「一般情報」メニュー, 2.6.2

「複数バージョン」メニュー・オプション, 2.6.2

「オリジン・サーバー」メニュー・オプション, 2.6.2

「パスワード」メニュー・オプション, 2.6.2, 2.6.2

「ポート構成」メニュー・オプション, 2.6.2

「リクエスト・フィルタ」メニュー・オプション, 2.6.2

「Resource Limits」メニュー・オプション, 2.6.2

「セキュリティ」メニュー, 2.6.2

「セッション構成」メニュー・オプション, 2.6.2

「サイト」メニュー・オプション, 2.6.2

「SSL構成」メニュー・オプション, 2.6.2

「ウォレット」メニュー・オプション, 2.6.2

URL, 2.6.1

G

ガベージ・コレクション, 2.3.1

Fusion Middleware Controlの「一般情報」メニュー, 2.6.2

GIFファイル、圧縮, 1.2.5

GLOBALCACHINGRULES要素、webcache.xmlファイル, 6.8.4, 6.8.4

グループID、Oracle Web Cacheの管理, 5.9.1

GZIPユーティリティ、圧縮, 1.2.5

H

ハードウェア・ロード・バランサ, 10.1, 10.1

構成, 10.1

自動再起動メカニズムと同じpingのURLの構成, 10.1

HEADER要素

無効化メッセージ, 7.5.1, 7.5.1

ヘッダー・リクエスト・フィルタ

構成, 4.9

説明, 4.2

階層、「キャッシュ階層」を参照 高可用性

クラスタ, 3.3

ヒット数

説明, 1.1.1

HOST属性

無効化メッセージ, 7.5.1

HOST ID要素、webcache.xmlファイル, 5.4.6 Hostリクエスト・ヘッダー・フィールド, 9.2.2.1 HTMLファイル、圧縮, 1.2.5 HTTPリクエスト・ヘッダー・サイズ, 5.6 HTTPリクエスト・ヘッダー・フィールド

Accept, 6.5.1, 9.2.2.1

Accept-Charset, 6.5.1

Accept-Encoding, 6.5.1

Accept-Language, 6.5.1

Authorization, 6.3, 9.2.2.1

Cache-Control, 9.2.2.1

クライアントIP, 5.7

Connection, 9.2.2.1

Content-Encoding, 9.2.2.1

Content-Language, 9.2.2.1

Content-Length, 9.2.2.1, A.1.6

Content-Type, 9.2.2.1

Cookie, 6.3, 9.2.2.1

カテゴリCookie, 6.5.1

Date, 9.2.2.1 説明, 6.5.1 Host, 9.2.2.1 If-Modified-Since, 6.2.2, 9.2.2.1 If-None-Match, 6.2.2, 9.2.2.1 キープ・アライブ, 2.11.5 Last-Modified, 9.2.2.1 Pragma, 9.2.2.1 Proxy-Authorization, 6.3 Range, 9.2.2.1 Referer, 9.2.2.1 SSL-Client-Cert, 5.1.1.2.2, 5.5.2 Surrogate-Capability, 9.2.2.1, 11.1.3 Surrogate-Control, 11.1.3 TE, 9.2.2.1 User-Agent, 6.5.1, 9.2.2.1 Via, 9.2.2.1 HTTPレスポンス・ヘッダー・フィールド

Cache-Control, 6.3, 9.2.2.1

Content-Encoding, 9.2.2.1

Content-Language, 9.2.2.1

Content-Length, 9.2.2.1

Content-Type, 9.2.2.1

Date, 9.2.2.1

ETag, 9.2.2.1

Expires, 6.3, 9.2.2.1

Last-Modified, 9.2.2.1

Pragma, 6.3, 9.2.2.1

Server, 8.3, 9.2.2.1

Set-Cookie, 6.3, 9.2.2.1

カテゴリCookie, 6.5.1

Surrogate-Control, 6.3, 6.10, 6.10.1, 9.2.2.1 Surrogate-Key, 7.6, 7.9 Transfer-Encoding, 9.2.2.1 Via, 9.2.2.1 Warning, 6.3 HTTP_ACCEPT_LANGUAGE変数, 11.1.6.3 HTTP_COOKIE変数, 11.1.6.3 HTTP_HEADER変数, 11.1.6.3 HTTP_HOST変数, 11.1.6.3 HTTP_REFERER変数, 11.1.6.3 HTTP_USER_AGENT変数, 11.1.6.3 httpd.confファイル, A.5 HTTPSリクエスト

構成, 5.4

リスニング・ポート, 5.4.2

Secure Sockets Layer(SSL)プロトコル, 5.1.1.2

I

IBM Websphere Application Server, 12.2

ID属性

無効化レスポンス, 7.5.2

If-Modified-Sinceリクエスト・ヘッダー・フィールド, 6.2.2, 9.2.2.1 If-None-Matchリクエスト・ヘッダー・フィールド, 6.2.2, 9.2.2.1 includeタグ、Edge Side Includes(ESI), 11.2.3.1.2, 11.2.3.1.2, 11.4.4 INFO要素

無効化メッセージ, 7.5.1

無効化レスポンス, 7.5.2

インライン無効化

構成, 11.3

説明, 7.3

inlineタグ、Edge Side Includes(ESI), 11.2.3.1.1, 11.2.3.1.1, 11.2.3.1.1, 11.3, 11.4.5 INTERCACHE要素、webcache.xmlファイル, 10.2 INV_PEER_TIMEOUT属性、webcache.xmlファイル, A.1.4 invalidateタグ、Edge Side Includes(ESI), 11.4.6 無効化

拡張, 7.7.2.2

基本, 7.7.2.1

概念, 6.2.3

クラスタ, 3.3, 7.10.2.1

メカニズム

API, 7.7.3

データベース・トリガー, 7.7.4

HTTP POSTメッセージ, 7.7.1

インライン, 7.3

Oracle Web Cache Manager, 7.7.2

レスポンス・ヘッダー, 7.4

スクリプト, 7.7.5

リストのプレビュー, 7.5.3, 7.7.2.1, 7.7.2.2 メッセージの伝播, 3.3

キャッシュ・クラスタ, 3.7.1, 3.7.6, 7.7.2.1, 7.10.2.1

キャッシュ階層, 7.10.2.2

Surrogate-Keyレスポンス・ヘッダー・フィールド, 7.6, 7.6 メッセージの同期

キャッシュ・クラスタ, 3.6.7

無効化コーディネータ, 3.3, 7.10.2.1 無効化メッセージ

ACTION要素, 7.5.1

ADVANCEDSELECTOR要素, 7.5.1

BASICSELECTOR要素, 7.5.1

BODYEXP属性, 7.5.1

リリース1.0との互換性, 7.5.1

COOKIE要素, 7.5.1

HEADER要素, 7.5.1, 7.5.1

HOST属性, 7.5.1

INFO要素, 7.5.1

METHOD属性, 7.5.1

NAME属性, 7.5.1, 7.5.1, 7.5.1

OBJECT要素, 7.5.1

パス接頭辞の表現

\(バックスラッシュ), 6.8.1, 7.5.1, 7.7.2.2

.(ピリオド), 6.8.1, 7.5.1, 7.7.2.2

$(ドル記号), 6.8.1, 7.5.1, 7.7.2.2

*(アスタリスク), 6.8.1, 7.5.1, 7.7.2.2

?(疑問符), 6.8.1, 7.5.1, 7.7.2.2

[ ](大カッコ), 6.8.1, 7.5.1, 7.7.2.2

^(カレット記号), 6.8.1, 7.5.1, 7.7.2.2

{ }(中カッコ), 6.8.1, 7.5.1, 7.7.2.2

正規表現, 7.7.2.2

\(バックスラッシュ), 7.7.2.2

.(ピリオド), 7.7.2.2

"(二重引用符), 7.5.1, 7.7.2.1

$(ドル記号), 7.7.2.2

&(アンパサンド), 7.5.1, 7.7.2.1, 7.7.2.2

'(一重引用符), 7.5.1

*(アスタリスク), 7.7.2.2

>(右山カッコ), 7.5.1, 7.7.2.1, 7.7.2.2

?(疑問符), 7.7.2.2

[ ](大カッコ), 7.7.2.2

^(カレット記号), 7.7.2.2

{ }(中カッコ), 7.7.2.2

REMOVALTTL属性, 7.5.1 SYSTEM要素, 7.5.1 SYSTEMINFO要素, 7.5.1 TYPE属性, 7.5.1, 7.5.1 URI属性, 7.5.1 URIEXP属性, 7.5.1 URIPREFIX属性, 7.5.1 VALUE属性, 7.5.1, 7.5.1, 7.5.1, 7.5.1 VERSION属性, 7.5.1, 7.5.2 無効化プレビュー・メッセージ

MAXNUM属性, 7.5.3

STARTNUM属性, 7.5.3

VERSION属性, 7.5.3

無効化プレビュー・レスポンス

NUMURLS属性, 7.5.4

SELECTEDURL要素, 7.5.4

STARTNUM属性, 7.5.4

STATUS属性, 7.5.4

構文, 7.5.4

TOTALNUMURLS属性, 7.5.4

VERSION属性, 7.5.4

無効化レスポンス, 7.5.2, 7.5.2

ID属性, 7.5.2

INFO要素, 7.5.2

NUMINV属性, 7.5.2

RESULT要素, 7.5.2

STATUS属性, 7.5.2

構文, 7.5.1, 7.5.4

SYSTEM要素, 7.5.2

SYSTEMINFO要素, 7.5.2

無効化のみクラスタ, 3.6.7, 3.7.6 IPアドレス

検証, 5.7

IPバージョン4アドレス, 2.5 IPバージョン6アドレス, 2.5

J

Javascriptファイル、圧縮, 1.2.5

jawc.jarファイル, 7.7.3

JESI, 11.1.1.1

JPEGファイル、圧縮, 1.2.5

K

Keep-Aliveリクエスト・ヘッダー・フィールド

構成, 2.11.5

KEEPALIVE4MSIE_SSL属性、webcache.xmlファイル, A.1.7

L

Last-Modifiedリクエスト・ヘッダー・フィールド, 9.2.2.1

Last-Modifiedレスポンス・ヘッダー・フィールド, 9.2.2.1

リクエスト・フィルタでの習得ルール, 4.3

構成, 4.7.1, 4.8.1

limits.confファイル, 2.3.2, 2.3.2 リスニング・ポート

HTTP, 2.11.1.3

HTTPS, 5.4.2

listLogsコマンド, 9.7 ロード・バランサ

ハードウェア, 10.1

Microsoftネットワーク負荷分散, 3.9

Oracle Web Cacheソフトウェア, 3.8

ロード・バランシング

構成

IPアドレスの登録によるハードウェア・ロード・バランサ, 10.1

Microsoftネットワーク負荷分散, 3.9

ソフトウェア・ロード・バランサとしてのOracle Web Cache, 3.8

オリジン・サーバーの設定許容量, 2.11.2

説明, 3.1.2 ローカル・タイムスタンプの変換の問題, 9.3 Oracle Web Cache Managerの「Logging and Diagnostics」メニュー, 2.7.2

M

GLOBALCACHINGRULES要素のMAPPEDUSERAGENTサブ要素, 6.8.4

GLOBALCACHINGRULES要素のMAPTYPEサブ要素, 6.8.4

GLOBALCACHINGRULES要素のMATCHSTRINGサブ要素, 6.8.4

Max_File_Desc設定, 2.3.2

キャッシュの最大サイズ

構成, 2.3.1

キャッシュ・オブジェクトの最大サイズ, 2.3.3 MAXNUM属性

無効化プレビュー・メッセージ, 7.5.3

メモリー

構成, 2.3.1

METHOD属性

無効化メッセージ, 7.5.1

メソッド・リクエスト・フィルタ

構成, 4.7

説明, 4.2

Microsoft IIS, 12.4 MIMEタイプのキャッシュ, 6.8.1 ミス回数

説明, 1.1.1

mod_osso保護ページ, 5.1.4.2 「次のみを監視」オプション, 4.4 1つのオブジェクトの複数のバージョン

ルールの構成, 6.8.2, 6.8.5

Cookieの値, 6.5.1

HTTPリクエスト・ヘッダー, 6.5.1, 6.8.4

Fusion Middleware Controlの「複数バージョン」メニュー・オプション, 2.6.2

N

NAME属性

無効化メッセージ, 7.5.1, 7.5.1, 7.5.1

netstat -aコマンド, 2.3.2 ネットワーク接続数

UNIXの場合, 2.3.2

Windowsの場合, 2.3.2

ネットワーク・ロード・バランサ, 3.9 クラスタのネットワーク・スループット, 3.3 Oracle Web Cache Managerの「Network Timeout」メニュー・オプション, 2.7.2 network_error.htmlファイル, 2.11.6 NUMINV属性

無効化レスポンス, 7.5.2

NUMURLS属性

無効化プレビュー・レスポンス, 7.5.4

O

OBJECT要素

無効化メッセージ, 7.5.1

オンデマンド・コンテンツ, 3.3 Oracle Web Cache Managerの「On-Demand Log File Rollover」メニュー・オプション, 2.7.2 OpenSSL証明書失効リスト, 5.1.1.2.2 オペレーティング・システムのロード・バランサ, 3.9 操作ポート

HTTP, 2.11.1.4

HTTPS, 5.5.1

Oracle Web Cache Managerの「Operations」メニュー, 2.7.2 操作ポート

HTTPS, 5.5.1

OPMN「Oracle Process and Notification」を参照 opmnctlユーティリティ

パラメータ, 2.8

restartprocコマンド, 2.8, 2.13.1

startallコマンド, 2.8

startprocコマンド, 2.8, 2.13.1

statusコマンド, 2.8

stopallコマンド, 2.8

stopprocコマンド, 2.8, 2.13.1

Oracle BI Discoverer, 1.3 Oracle Diagnostic Logging(ODL), 9.1.1.1 Oracle Forms Services, 1.3 Oracle Fusion Middleware

Oracle Web Cache, 1.1

Oracle Portal, 1.3 Oracle Process Manager and Notification

Oracle Web Cacheのコマンド, 2.8

説明, 2.8

ポート構成, 2.11.1.2

起動、停止、再起動, 2.13.1

Oracle Single Sign-On

サーバーからのコンテンツのキャッシュ, 5.1.4.1

パートナ・アプリケーション, 5.1.4.2

Oracle Single Sign-Onキャッシュ, 5.8 Oracle Single-Sign

キャッシュ, 5.8

Oracle Web Cache

環境への追加, 2.10

adminサーバー・プロセス, 2.8, 2.13

キャッシュ・サーバー・プロセス, 2.8, 2.13

互換性

Oracle BI Discoverer, 1.3

Oracle Forms Services, 1.3

Oracle Portal, 1.3

デプロイ

キャッシュなしのリバース・プロキシ・サーバー, 10.3

キャッシュなしのソフトウェア・ロード・バランサ, 10.3

キャッシュ・クラスタ, 10.1

キャッシュ階層, 10.2

一般的な構成, 10.1

ハードウェア・ロード・バランサ, 10.1

ネットワーク・ロード・バランサ, 10.3

機能

バックエンド・フェイルオーバー, 3.1.3

キャッシュ, 1.2.2, 1.2.4

圧縮, 1.2.5

ロード・バランシング, 3.1, 3.1.2

オリジン・サーバーのロード・バランシングとフェイルオーバー, 1.2.3

管理の制限, 5.1.1.1

リバース・プロキシ, 1.1.1

Secure Sockets Layer(SSL), 5.1.1.2

セキュリティ, 5.1.1

セッション・バインディング, 1.2.6

SSLアクセラレータ・ハードウェア・ソリューション, 5.1.1.3

急激な過負荷の回避, 3.1.1

ロギング形式, 9.1.1.2 Oracle Single Sign-Onキャッシュ, 5.8 Oracle Single Sign-Onサーバー, 5.1.4.1 Oracle Web層, 1.1 キャッシュへのデータ格納, 6.1 再起動

Fusion Middleware Control, 2.13.2

opmnctl restartprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

ステータスの取得

opmnctl statusコマンド, 2.8

起動

Fusion Middleware Control, 2.13.2

opmnctl restartprocコマンド, 2.8, 2.13.1

opmnctl startallコマンド, 2.8

opmnctl startprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

停止

Fusion Middleware Control, 2.13.2

opmnctl stopallコマンド, 2.8

opmnctl stopprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

Oracle HTTP Server, 1.1 Oracle WebLogic Server, 1.1 Oracle Web Cache Manager(Oracle Web Cache Manager)

「Advanced Content Invalidation」メニュー・オプション, 2.7.2

「Basic Content Invalidation」メニュー・オプション, 2.7.2

「Cache Operations」メニュー・オプション, 2.7.2

クラスタ構成, 3.7.1

説明, 2.7

「Diagnostics」メニュー・オプション, 2.7.2

「Filtering」メニュー, 2.7.2

コンテンツの無効化, 7.7.2

レイアウト, 2.7.2

「Logging and Diagnostics」メニュー, 2.7.2

「Network Timeouts」メニュー・オプション, 2.7.2

「On-Demand Log File Rollover」メニュー・オプション, 2.7.2

「Operations」メニュー, 2.7.2

「Properties」メニュー, 2.7.2

「Request Filters」メニュー・オプション, 2.7.2

「Security」メニュー・オプション, 2.7.2

起動, 2.7.1

Oracle Web Cacheの運用

HTTP, 2.11.1.4

Oracle Web Tier

説明, 1.1

Oracle HTTP Server, 1.1

Oracle Web Cache, 1.1

Oracle-ECIDリクエスト・ヘッダー, 9.1.1.4 オリジン・サーバー

許容量, 2.11.2

フェイルオーバー

フェイルオーバーのしきい値, 2.11.2

pingのURL, 2.11.2

ポーリングの間隔, 2.11.2

ロード・バランシング

許容量, 2.11.2

構成, 2.11.2

説明, 3.1, 3.1.2

セッション・バインディング

説明, 1.2.6

Fusion Middleware Controlの「オリジン・サーバー」メニュー・オプション, 2.6.2 otherwiseタグ、Edge Side Includes(ESI), 11.4.1 所有コンテンツ, 3.3

P

ページの部分的なキャッシュ

キャッシュ・ルール, 11.2

構成, 11.2.1

説明, 11.1

例

パーソナライズされた挨拶文, 11.2.3.2

ポータル・サイト, 11.2.3.1

Surrogate-Controlレスポンス・ヘッダー・フィールド, 6.10.1, 7.6

Surrogate-Controlレスポンス・ヘッダー・フィールド, 6.10 パスワード, 5.2 Fusion Middleware Controlの「パスワード」メニュー・オプション, 2.6.2, 2.6.2 パス接頭辞

キャッシュ・ルール, 6.8.1

パス接頭辞の表現

\(バックスラッシュ), 6.8.1, 7.5.1, 7.7.2.2

.(ピリオド), 6.8.1, 7.5.1, 7.7.2.2

$(ドル記号), 6.8.1, 7.5.1, 7.7.2.2

*(アスタリスク), 6.8.1, 7.5.1, 7.7.2.2

?(疑問符), 6.8.1, 7.5.1, 7.7.2.2

[ ](大カッコ), 6.8.1, 7.5.1, 7.7.2.2

^(カレット記号), 6.8.1, 7.5.1, 7.7.2.2

{ }(中カッコ), 6.8.1, 7.5.1, 7.7.2.2

パフォーマンス

メトリック

「パフォーマンス・サマリー」ページ, 8.4

リクエスト・フィルタリング, 4.13

「Webキャッシュ・メンバー」ページ, 2.6.3

Oracle Web Cacheの設定

構成, 2.11.5

説明, 2.3

低下のトラブルシューティング, A.1.3 パーソナライズ属性

Edge Side Includes(ESI), 11.2.2, 11.2.3.1.1

WEBCACHEENDタグ, 11.4.8.2

WEBCACHETAGタグ, 11.4.8.2

pingのURL

キャッシュ・クラスタ, 3.6.3, 3.7.1

ハードウェア・ロード・バランサ, 10.1

オリジン・サーバー, 2.11.2

PKI, 5.1.1.2 PNGファイル、圧縮, 1.2.5 ポピュラーなリクエスト

リスト, 8.2

データ格納、キャッシュ, 6.1 ポート

1024, 2.11.1.3, 2.11.1.4, 5.4.2, 5.5.1, 5.9

80, 12.1.1, 12.1.1

8080, 12.1.1

説明, 2.4

Oracle Web Cacheリスニング

HTTP, 2.11.1.3

HTTPS, 5.4.2

Oracle Web Cacheの運用

HTTPS, 5.5.1

サード・パーティ・アプリケーション・サーバー, 12.1.1 Oracle Web Cacheで使用

Fusion Middleware Control, 2.11.1.1

Oracle Process Manager and Notification, 2.11.1.2

Fusion Middleware Controlの「ポート構成」メニュー・オプション, 2.6.2 POST本体のパラメータ

キャッシュ・ルール, 6.8.6

パラメータの値の無視, 6.5.2, 6.8.3

Pragmaリクエスト・ヘッダー・フィールド, 9.2.2.1 Pragmaレスポンス・ヘッダー・フィールド, 6.3, 9.2.2.1 プレビューの無効化, 7.5.3, 7.7.2.1, 7.7.2.2 特権IPリクエスト・フィルタ

構成, 4.5

説明, 4.2

プロセス認証, 5.1.2

root権限, 5.9.3

伝播、無効化メッセージ

キャッシュ・クラスタ, 3.7.1, 3.7.6, 7.7.2.1

キャッシュ階層, 7.10.2.2

Oracle Web Cache Managerの「Properties」メニュー, 2.7.2 Proxy-Authorizationリクエスト・ヘッダー・フィールド, 6.3 公開鍵インフラストラクチャ(PKI), 5.1.1.2

Q

問合せ文字列リクエスト・フィルタ

構成, 4.10

説明, 4.2

QUERY_STRING_DECODED変数, 11.1.6.3

R

Rangeリクエスト・ヘッダー・フィールド, 9.2.2.1

readme.toolkit.htmlファイル, 7.7.3

Refererリクエスト・ヘッダー・フィールド, 9.2.2.1

正規表現

\(バックスラッシュ), 7.7.2.2

.(ピリオド), 7.7.2.2

"(二重引用符), 7.5.1, 7.7.2.1, 7.7.2.2

$(ドル記号), 7.7.2.2

&(アンパサンド), 7.5.1, 7.7.2.1, 7.7.2.2

'(一重引用符), 7.5.1

*(アスタリスク), 7.7.2.2

>(右山カッコ), 7.5.1, 7.7.2.1, 7.7.2.2

?(疑問符), 7.7.2.2

[ ](大カッコ), 7.7.2.2

^(カレット記号), 7.7.2.2

{ }(中カッコ), 7.7.2.2

REMOVALTTL属性

無効化メッセージ, 7.5.1

removeタグ、Edge Side Includes(ESI), 11.4.7 キャッシュ・メンバーの削除, 3.6.6, 3.7.5 リクエスト・フィルタ, 4.4

クライアントIP, 4.2

ルールのコピー, 4.14.1

ルールの削除, 4.12

形式, 4.2

ヘッダー, 4.2

習得ルール, 4.3, 4.3

構成, 4.7.1, 4.8.1

メソッド, 4.2 特権IP, 4.2 問合せ文字列, 4.2 構成設定のリセット, 4.14.2 統計監視, 4.13 統計, 4.13 URL, 4.2 Fusion Middleware Controlの「リクエスト・フィルタ」メニュー・オプション, 2.6.2 Oracle Web Cache Managerの「Request Filters」メニュー・オプション, 2.7.2 Fusion Middleware Controlの「リソース制限」メニュー・オプション, 2.6.2 レスポンス・ヘッダーの無効化

説明, 7.4

有効化, 7.8

Oracle Web Cacheの再起動

構成の変更後, 2.11.7

Fusion Middleware Control, 2.13.2

opmnctl restartprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

管理の制限, 5.1.1.1 RESULT要素

無効化レスポンス, 7.5.2

キャッシュありのリバース・プロキシ・サーバー

Oracle Web Cache, 1.1

キャッシュなしのリバース・プロキシ・サーバー

Oracle Web Cache, 3.4.1

構成, 3.8

機能の制限, 3.4.1

rlim_fd_maxパラメータ, 2.3.2 ロールオーバー、ログ, 9.8 ロールオーバー・ポリシー, 9.6 root権限

webcached, 5.9

ラウンドロビン法, 3.1.2 リクエストのルーティング

オリジン・サーバーへ, 2.11.2

ROUTINGONLY属性、webcache.xmlファイル, 3.8 キャッシュ・ルールの作成ルール, 6.3

S

スケーラビリティ

キャッシュ・クラスタ, 3.3

無効化用の検索キー, 7.6 セキュアなキャッシング, 5.8 Secure Sockets Layer(SSL), 5.1.1.2

トラブルシューティング, A.1.1

セキュリティ

HTTPSリクエスト, 5.4

セキュリティ機能

アクセス制御, 5.3

認可およびアクセスの適用, 5.1.3

HTTPリクエスト・ヘッダー・サイズ, 5.6

HTTPSリクエスト, 5.1.1.2

パスワード, 5.2

保護リソース, 5.1.2

管理の制限, 5.1.1.1

root権限によるwebcachedの実行, 5.9

セキュアなキャッシング, 5.8

SSLアクセラレータ・ハードウェア・ソリューション, 5.1.1.3

有効なClientIPヘッダー, 5.7

Fusion Middleware Controlの「セキュリティ」メニュー, 2.6.2 Oracle Web Cache Managerの「Security」メニュー・オプション, 2.7.2 SELECTEDURL要素

無効化プレビュー・レスポンス, 7.5.4

Serverレスポンス・ヘッダー・フィールド, 8.3

アクセス・ログ, 9.2.2.1

診断情報, 8.3

サーバー側の証明書, 5.1.1.2.2, 5.1.1.2.2 SERVERTYPE属性、webcache.xmlファイル, 5.4.6 セッション・バインディング

概念, 3.2

構成, 3.5

キャッシュ・クラスタ, 3.6.4, 3.7.3

説明, 1.2.6 Fusion Middleware Controlの「セッション構成」メニュー・オプション, 2.6.2 セッションCookie

キャッシュ・ルール, 6.5.4, 6.8.6

セッション・バインディング, 1.2.6

セッション・エンコードされたURL, 6.5.5

セッション・エンコードされたURL

構成, 6.8.7

説明, 6.5.5

セッション

オリジン・サーバーへのバインディング, 3.2, 3.5

キャッシュ・ルール, 6.5.4, 6.8.6

ポピュラーなページのキャッシュからの表示, 6.8.8

Set-Cookieレスポンス・ヘッダー・フィールド, 6.3, 9.2.2.1

カテゴリCookie, 6.5.1

Edge Side Includes(ESI), 11.1.10

サイト定義

作成, 2.11.3

デフォルト・サイト, 2.2

説明, 2.2

名前付きサイト, 2.2

未定義サイト, 2.2

サイト, 2.11.4

別名, 2.2

クライアント側の証明書, 5.5.2.3

構成, 2.11.3

デフォルト, 2.2

定義

作成, 2.11.3

説明, 2.2

名前付き, 2.2 未定義, 2.2 Fusion Middleware Controlの「サイト」メニュー・オプション, 2.6.2 サイトからサーバーへのマッピング

作成, 2.11.4

説明, 2.2

キャッシュなしのソフトウェア・ロード・バランサ

構成, 3.8

機能の制限, 3.4.1

SSLアクセラレータ・ハードウェア, 5.1.1.3 Fusion Middleware Controlの「SSL構成」メニュー・オプション, 2.6.2 SSL、「Secure Sockets Layer(SSL)」を参照 SSL-Client-Certヘッダー, 5.1.1.2.2 ssl.confファイル, 5.4.4.1 OPMNプロセスの起動, 2.8 Oracle Web Cacheの起動, 2.13

Fusion Middleware Control, 2.13.2

opmnctl restartprocコマンド, 2.8, 2.13.1

opmnctl startallコマンド, 2.8

opmnctl startprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

STARTNUM属性

無効化プレビュー・メッセージ, 7.5.3

無効化プレビュー・レスポンス, 7.5.4

ステートフル・ロード・バランシング、「セッション・バインディング」を参照 ステートレス・ロード・バランシング、「ロード・バランシング」を参照 統計監視リクエスト

ポート番号、統計を取得するために使用, 8.4

STATUS属性

無効化プレビュー・レスポンス, 7.5.4

無効化レスポンス, 7.5.2

OPMNプロセスの停止, 2.8 Oracle Web Cacheの停止, 2.13

Fusion Middleware Control, 2.13.2

opmnctl stopallコマンド, 2.8

opmnctl stopprocコマンド, 2.8, 2.13.1

Oracle Process Manager and Notification Server, 2.13.1

Oracle Web Cache Manager, 2.13.3

急激な過負荷の回避, 3.1.1 Surrogate-Capabilityリクエスト・ヘッダー・フィールド, 9.2.2.1, 11.1.3

orcl="ESI/1.0"操作値, 11.1.3

orcl="ESI-Inline/1.0"操作値, 11.1.3

orcl="ESI-INV/1.0"操作値, 11.1.3

orcl="ORAESI/9.0.2"操作値, 11.1.3

orcl="ORAESI/9.0.4"操作値, 11.1.3

orcl="webcache/1.0"操作値, 11.1.3

Surrogate-Controlリクエスト・ヘッダー・フィールド, 6.3, 6.10, 6.10, 6.10.1, 9.2.2.1, 11.3

compress制御ディレクティブ, 6.10.1

content="ESI/1.0"制御ディレクティブ, 6.10.1, 11.1.3

content="ESI-Inline/1.0"制御ディレクティブ, 6.10.1

content="ESI-INV/1.0"制御ディレクティブ, 6.10.1, 11.3

content="ORAESI/9.0.2"制御ディレクティブ, 6.10.1, 11.1.3

content="ORAESI/9.0.4"制御ディレクティブ, 6.10.1

content="webcache/1.0"制御ディレクティブ, 6.10.1, 11.1.3

max-age制御ディレクティブ, 6.10.1

no-store制御ディレクティブ, 6.10.1

vary制御ディレクティブ, 6.10.1

Surrogate-Keyレスポンス・ヘッダー・フィールド, 7.6, 7.9 構成のクラスタへの同期, 3.6.5, 3.7.4 無効化メッセージの同期

キャッシュ・クラスタ, 3.6.7

SYSTEM要素

無効化メッセージ, 7.5.1

無効化レスポンス, 7.5.2

SYSTEMINFO要素

無効化メッセージ, 7.5.1

無効化レスポンス, 7.5.2

T

TEリクエスト・ヘッダー・フィールド, 9.2.2.1

サード・パーティ・アプリケーション・サーバー

Apache Tomcat, 12.3

IBM Websphere Application Server, 12.2

Microsoft IIS, 12.4

topユーティリティ, A.1.2 TOTALNUMURLS属性

無効化プレビュー・レスポンス, 7.5.4

Transfer-Encodingレスポンス・ヘッダー・フィールド, 9.2.2.1 トラブルシューティング

ブラウザにページが表示されないエラー, A.1.7

完全なレスポンスが受信されないブラウザ, A.1.6

キャッシュ・ルール, A.3

一般的な構成ミス

pingのURL, A.2

root権限によるwebcachedの実行, A.2

サイトの構成, A.2

Edge Side Includes(ESI)エラー, A.4 GMTからローカル・タイムスタンプへ, 9.3 無効化タイムアウト

キャッシュ・クラスタ, A.1.4

負荷の問題, A.1.2 Webアプリケーション・サーバーからレスポンスがない, A.1.1 オリジン・サーバーの許容量, A.1.5 パフォーマンスの低下

最大キャッシュ・サイズ以上, A.1.3

ページング, A.1.3

イベント・ビューアでのXML解析エラー, A.1.9 tryタグ、Edge Side Includes(ESI), 11.4.8 ttcpユーティリティ, 2.3.2 TYPE属性

無効化メッセージ, 7.5.1, 7.5.1

U

uptimeユーティリティ, A.1.2

URI属性

無効化メッセージ, 7.5.1

URIEXP属性

無効化メッセージ, 7.5.1

URIPREFIX属性

無効化メッセージ, 7.5.1

URLキャッシュ, 6.8.1 URLリクエスト・フィルタ

構成, 4.8

説明, 4.2

ユーザーID、Oracle Web Cacheの管理, 5.9.1 User-Agentリクエスト・ヘッダー・フィールド, 6.5.1, 9.2.2.1

複数のバージョンを持つオブジェクト, 6.8.4

オラクル社提供のUTL_TCPパッケージ, 7.7.4

V

VALUE属性

無効化メッセージ, 7.5.1, 7.5.1, 7.5.1, 7.5.1

varsタグ

Edge Side Includes(ESI), 11.2.3.1.2

varsタグ、Edge Side Includes(ESI), 11.4.9 VERSION属性

無効化プレビュー・メッセージ, 7.5.3

無効化プレビュー・レスポンス, 7.5.4

無効化レスポンス, 7.5.2

VERSION要素

無効化メッセージ, 7.5.1

Viaリクエスト・ヘッダー・フィールド, 9.2.2.1 Viaレスポンス・ヘッダー・フィールド, 9.2.2.1

W

ウォレット

作成, 5.4.1

デフォルト, 5.1.1.2.3

説明, 5.1.1.2.3

Fusion Middleware Controlの「ウォレット」メニュー・オプション, 2.6.2 Warningレスポンス・ヘッダー・フィールド, 6.3 WCSinvalidation.dtdファイル, 7.5.1 Web層

説明, 1.1

Oracle HTTP Server, 1.1

Oracle Web Cache, 1.1

webcache_contents.txtファイル, 8.7 webcache_setuser.shスクリプト, 5.9.1, 5.9.2, 5.9.3, 5.9.4

コマンド書式, 5.10

revertコマンド, 5.10

setidentityコマンド, 5.10

setrootコマンド, 5.10

webcachea実行可能ファイル, 2.13 webcached実行可能ファイル, 2.13

権限, 2.11.1.3, 2.11.1.4, 5.4.2, 5.5.1

root権限による実行, 5.9

WEBCACHEENDタグ、パーソナライズ属性, 11.4.8.2 WEBCACHETAGタグ、パーソナライズ属性, 11.4.8.2 webcache.xmlファイル

CACHE要素, 3.8

CALYPSONETINFO要素, 6.8.4, A.1.4, A.1.7

GLOBALCACHINGRULES要素, 6.8.4, 6.8.4

HOST ID要素, 5.4.6

INTERCACHE要素, 10.2

INV_PEER_TIMEOUT属性, A.1.4

KEEPALIVE4MSIE_SSL属性, A.1.7

ROUTINGONLY属性, 3.8

SERVERTYPE属性, 5.4.6

whenタグ、Edge Side Includes(ESI), 11.4.1 WinZipユーティリティ、圧縮, 1.2.5 wxvappl.sqlスクリプト, 7.7.3 wxvutil.sqlスクリプト, 7.7.3

X

x-ecidフィールド, 9.1.1.4

Copyright c 2011, Oracle and/or its affiliates. All rights reserved.