| Oracle Fusion Middleware Oracle Web Cache管理者ガイド 11g リリース1(11.1.1) B56248-02 |
|
 前 |
 次 |
この章では、Oracle Web Cacheの概要、およびセキュアなリバース・プロキシを提供する際のOracle Web Cacheの役割について説明します。
この章の項目は次のとおりです。
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コンテンツを処理できます。
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の対話処理ステップを示します。
ブラウザが、www.company.com:80というWebサイトにリクエストを送信します。
このリクエストにより、そのWebサイトのIPアドレスのドメイン・ネーム・システム(DNS)へのリクエストが生成されます。
DNSサーバーは、そのサイトに対するロード・バランサのIPアドレスである144.25.190.240を返します。
ブラウザは、Webページのリクエストをロード・バランサに送信します。次に、ロード・バランサはリクエストをOracle Web Cacheサーバー(144.25.190.241)に送信します。
リクエストされたコンテンツがキャッシュに入っている場合、Oracle Web Cacheはそのコンテンツを直接ブラウザに送信します。これはキャッシュ・ヒットと呼ばれます。
リクエストされたコンテンツがOracle Web Cacheに存在しない場合、またはコンテンツが失効しているか無効になっている場合、リクエストはWebアプリケーション・サーバー(144.25.190.242)に渡されます。これはキャッシュ・ミスと呼ばれます。
Webアプリケーション・サーバーは、コンテンツをOracle Web Cacheに送信します。
Oracle Web Cacheは、コンテンツをクライアントに送信し、そのページのコピーをキャッシュに保存します。
キャッシュに格納されたページは、無効になるか期限切れになると削除されます。
図1-2に、Web層でのリクエスト・フローの詳細を示します。
図1-2に示すように、Web層内では次の処理が行われます。
受信したブラウザ・リクエストが正しいHTTPフォーマットかどうかが分析されます。
ブラウザ・リクエストがさらに分析されて、HTTPSフォーマットかどうかが判断されます。
ブラウザ・リクエストがHTTPSフォーマットである場合は、SSL復号化が実行されます。
ブラウザ・リクエストがHTTPSフォーマットでない場合は、リクエストが解析されます。
リクエストが識別されたら、指定された一連のフィルタリング・ルールによってそのリクエストがフィルタ処理されます。
キャッシュ・ルックアップが実行されて、そのHTTPリクエストが以前に送信されてキャッシュ内に存在しているかどうかが確認されます。
リクエストがキャッシュ内に存在している場合(キャッシュ・ヒット)、リクエストは圧縮され、コンテンツが直接ブラウザに送信されます。
リクエストがキャッシュ内に存在していない場合(キャッシュ・ミス)、次のいずれかの処理が行われます。
リクエストが単一のオリジン・サーバーへ直接送信されます。
リクエストがロード・バランシングされた複数のオリジン・サーバーへ送信されます。
ロード・バランシングされた各オリジン・サーバーは、キャッシュの状態をチェックするために、各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によって統計もリセットされます。
Oracle Web Cacheは、ファイアウォールの内側および外側に配置することができます。Oracle Web Cacheをファイアウォールの内側に配置すると、HTTP通信はDMZに入りますが、データベースと直接対話処理を行うのはWebアプリケーション・サーバーからの許可された通信のみであることが保証されます。Oracle Web Cacheをファイアウォールの外側に配置すると、スループットの負荷は、ファイアウォールではなくOracle Web Cacheにかかります。ファイアウォールは、Webアプリケーション・サーバーへのリクエストのみ受信します。このトポロジの場合、Oracle Web Cacheを侵入者から保護する必要があります。
セキュリティの専門家の間では、キャッシュをDMZの外に配置してよいかどうか、意見が分かれています。オラクル社では、Oracle Web CacheをDMZの外側に配置する前に、御社の企業方針を確認することをお薦めします。
リクエスト・フィルタリングでは、正規化されたリクエスト(ほとんどのフィルタ・タイプ)またはオリジナルの正規化されていないRAWリクエスト(NULLバイト、厳密なエンコーディング、ダブル・エンコーディングの各フォーマット・フィルタ・ルール)がチェックされます。ルールに一致し、それが拒否ルールである場合、リクエストは拒否されます。許可ルールに一致した場合、リクエストは許可されます。拒否ルールの場合は、ルールが監視のみのモードであれば、リクエストはログ(監査ログとイベント・ログ)に記録されますが拒否されません。
リクエスト・フィルタリングの詳細は、第4章「リクエスト・フィルタリングの構成」を参照してください。
オリジン・サーバーのロード・バランシングは、1つのオリジン・サーバーの負荷が過大にならないように、HTTPリクエストを複数のオリジン・サーバー間に分散する機能です。
Oracle Web Cacheは、Webアプリケーション・サーバーに対してロード・バランシングとフェイルオーバー検出をサポートしています。
Oracle Web Cacheにより、キャッシュ・ミスは、サーバー・ファーム内で最も可用性が高く、最もパフォーマンスが優れたWebサーバーに転送されます。また、容量ヒューリスティックにより、Webアプリケーション・サーバーの負荷増大時のパフォーマンスが保証され、急激な過負荷の回避が可能です。
ロード・バランシングとフェイルオーバーの詳細は、第3.1項を参照してください。
キャッシュ機能は、頻繁にアクセスされる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章「コンテンツのキャッシュと圧縮」を参照してください。
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項を参照してください。
Oracle Web Cacheでは、セッションIDまたはセッションCookieを使用してユーザー・セッションを特定のオリジン・サーバーにバインドし、一定期間、状態を維持できるようにする機能を持つサイトをサポートしています。セッション・バインディング機能を使用するには、オリジン・サーバー自体が状態を維持する(ステートフルである)必要があります。ユーザー・セッションをバインドするために、サイトでは、クライアントに送信するHTTPヘッダーまたはボディにセッション・データを含めることにより、クライアントの後続のリクエストにそのデータを強制的に含めて送信するようにします。このデータは、埋込みURLパラメータまたはCookie(クライアントに送信され、格納されるテキスト文字列)のいずれかによってOracle Web Cacheを介してオリジン・サーバーとクライアント間で転送されます。Oracle Web Cacheは、パラメータまたはCookieの値を処理せず、単にオリジン・サーバーとクライアント間で情報をやり取りします。
セッション・バインディングの詳細は、第3.2項を参照してください。
|
注意: オリジン・サーバーが高負荷のためにそれ以上接続を受け入れることができない場合、Oracle Web Cacheはそのオリジン・サーバーへのセッションのバインドを無効にし、別のオリジン・サーバーに接続しようとします。 |
表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 BI Discovererは、Discoverer Viewer全体のスケーラビリティ、パフォーマンスおよび可用性を改善するために、Oracle Web Cacheと密接に統合されています。Oracle BI Discovererは、ESIの 関連項目: Oracle Business Intelligence Discoverer構成ガイド |
|
|
Oracle Web CacheをOracle Forms Servicesアプリケーションのロード・バランサとして配置できます。 関連項目: Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド |
|
|
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管理者ガイド |
