(57)【要約】【課題】アプリケーション環境のためのローバストで安全な認証技法を提供する。【解決手段】専用機器（ＳＰＡ）が、複数のキャッシュサーバ機器（ＣＳＡ）から成るサーバファームと共に動作して、ローカルストレージ媒体（すなわち共有キャッシュ）を管理する。このローカルストレージ媒体は、すべてのＣＳＡによってアクセス可能であり、リモートオブジェクトの少なくともいくつかを記憶する。これらのオブジェクトは、ＣＳＡの１つまたは複数のものによってその各クライアントにサーブされたことがあり、かつ／または、サーブされることになる。また、ＳＰＡは、好ましくは、ウェブページおよび当該ウェブページの組み込みオブジェクトならびに／またはストリーミングメディアオブジェクト等のリモートオブジェクトをいつプリフェッチするかも確定する。
2006501535.tif 000002
【特許請求の範囲】
【請求項１】
１つ以上のリモートオリジンサーバを起源とするオブジェクトのローカルストレージのためのキャッシュシステムであって、
専用ローカルストレージ、共有ローカルストレージおよびリモートサーバを含むソースのストレージ階層から、クライアントにより要求されたオブジェクトを取り出し、前記専用ローカルストレージおよび前記共有ローカルストレージに、選択された前記オブジェクトのキャッシュされたコピーを保持するキャッシュサーバ装置のクラスタと、
それぞれの前記キャッシュサーバ装置にそれぞれ関連づけられ、前記それぞれのキャッシュサーバ装置に、それぞれの前記専用ローカルストレージを供給する複数の専用ローカル記憶と、
前記キャッシュサーバ装置すべてにアクセス可能であって、前記共有ローカルストレージを供給する共有ローカル記憶と、
前記クライアントからのオブジェクト要求すべてに応答して、前記共有ローカル記憶に記憶された特定のオブジェクトが、他のオブジェクトにいつ置換されるかを判定する管理装置と
を有するシステム。
【請求項２】
２つ以上の前記クライアントからの少なくともいくつかの未来の要求を予想可能な共有プリフェッチサーバ装置
をさらに有し、
前記管理装置は、前記予想された未来の要求の少なくとも一部に基づいて、前記共有ローカル記憶の選択されたオブジェクトを置換する
請求項１に記載のシステム。
【請求項３】
前記共有プリフェッチサーバ装置は、前記クライアントからの過去の要求すべてを監視することにより、未来の要求の少なくともいくつかを予想する
請求項２に記載のシステム。
【請求項４】
前記共有プリフェッチサーバ装置は、前記共有ローカルストレージに記憶されたオブジェクトの所定の有効期限を監視することにより、未来の要求の少なくともいくつかを予想する
請求項２に記載のシステム。
【請求項５】
前記共有プリフェッチサーバ装置は、前記共有ローカルストレージに記憶されたオブジェクトを、他のオブジェクトとの関連について検査することにより、未来の要求の少なくともいくつかを予想する
請求項２に記載のシステム。
【請求項６】
前記共有プリフェッチサーバ装置は、まれにしか要求されない前記共有ストレージのオブジェクトのために、前記キャッシュサーバ装置のすべてにより受け取られた、前記キャッシュサーバ装置それぞれのクライアントからの要求を監視する
請求項２に記載のシステム。
【請求項７】
前記共有プリフェッチサーバ装置は、前記オブジェクトを、より頻繁に要求される他のオブジェクトと置換する
請求項２に記載のシステム。
【請求項８】
前記共有プリフェッチサーバ装置は、前記キャッシュサーバ装置の１つに統合されている
請求項２に記載のシステム。
【請求項９】
トラフィック指示装置をさらに含む
請求項２に記載のシステム。
【請求項１０】
前記トラフィック指示装置は、前記クライアントの要求を、その同じオブジェクトに対する前の要求の少なくとも一部に基づいて、選択されたキャッシュサーバ装置に送る
請求項９に記載のシステム。
【請求項１１】
前記管理装置は、前記トラフィック指示装置から受け取った情報に基づいて、前記要求を監視する
請求項９に記載のシステム。
【請求項１２】
単一の従来のオリジンサーバＡＰＩは、前記オリジンサーバそれぞれと前記クラスタとの間に供給されて、前記オリジンサーバに、単一の仮想キャッシュ装置を供給する
請求項１に記載のシステム。
【請求項１３】
単一の従来のクライアントＡＰＩは、前記クライアントそれぞれと前記クラスタとの間に供給されて、前記クライアントに、単一の仮想キャッシュ装置を供給する
請求項１に記載のシステム。
【請求項１４】
単一の従来のネットワークマネージャＡＰＩは、外部のネットワークマネージャと前記クラスタとの間に供給されて、ネットワークマネージャに、単一の仮想キャッシュ装置を供給する
請求項１に記載のシステム。
【請求項１５】
前記共有ローカル記憶は、ストレージエリアネットワークの一部である
請求項１に記載のシステム。
【請求項１６】
前記共有ローカル記憶は、ローカルエリアネットワークにより、前記キャッシュサーバ装置に接続されるネットワークストレージである
請求項１に記載のシステム。
【請求項１７】
１つ以上のリモートオリジンサーバを起源とするオブジェクトをキャッシュする方法であって、
少なくとも２つの異なるクライアントから要求された少なくとも２つの異なるオブジェクトを、リモートサーバから取り出し、
取り出された２つの異なるオブジェクトそれぞれの第１のコピーを、異なるローカル記憶それぞれにキャッシュし、
取り出された２つの異なるオブジェクトそれぞれの第２のコピーを、同じ共有記憶にキャッシュし、
前記第１のコピーおよび前記第２のコピーが、他のキャッシュされたオブジェクトにいつ置換されるかを、独立に判定する
ことを含む方法。
【請求項１８】
ＣＳＡが、自己のローカルキャッシュにおいて、前記第１のコピーを、定期的にライトバックするとき、前記第２のコピーは、前記共有ストレージに置かれる
請求項１７に記載の方法。
【請求項１９】
前記少なくとも２つのクライアントからの過去の要求を分析して、前記クライアントからの少なくともいくつかの未来の要求を予想し、
前記予想された未来の要求を用いて、前記共有記憶の前記キャッシュされた第２のコピーがいつ置換されるかを判定する
ことをさらに含む
請求項１７に記載の方法。
【請求項２０】
前記クライアントからの前記過去の要求すべては、監視される
請求項１９に記載の方法。
【請求項２１】
前記共有ローカル記憶に記憶されたオブジェクトの所定の有効期限は、監視される
請求項１７に記載の方法。
【請求項２２】
前記共有ローカル記憶に記憶された前記オブジェクトは、他のオブジェクトとの関連のために監視される
請求項１７に記載の方法。
【請求項２３】
前記クライアントからの前記要求すべては、まれにしか要求されない前記共有記憶のオブジェクトのために監視される
請求項１７に記載の方法。
【請求項２４】
まれにしか要求されない前記共有記憶のオブジェクトは、より頻繁に要求される他のオブジェクトに置換される
請求項２３に記載の方法。
【請求項２５】
特定のオブジェクトに対するクライアントの要求を、その同じオブジェクトに対する他のクライアントからの前の要求の少なくとも一部に基づいて、特定の前記専用ローカル記憶に関連づけられたサーバに送ること
をさらに含む
請求項１７に記載の方法。
【請求項２６】
単一の共通のオリジンサーバＡＰＩは、所与の前記オリジンサーバへの前記要求すべてのために使われる
請求項１７に記載の方法。
【請求項２７】
単一の共通のクライアントＡＰＩは、所与の前記クライアントからの要求すべてのために使われる
請求項１７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的には、リモートサーバおよびローカルサーバの双方によってサーブされたクライアントを有するネットワークに関し、より詳細には、選択されたオブジェクトがキャッシュされる共有ローカルストレージを管理する手段に関する。
【背景技術】
【０００２】
［背景］
リモート中央サーバに依存するウェブのストリーミングメディアクライアントに対して帯域幅を高くし、待ち時間を短くすることは、キャッシュサーバをネットワークのより多くのローカルポイントに設けて、これらのローカルポイントが、リモートサーバから事前に検索されたファイルのコピーを、このローカルクライアントによるその後の繰り返しアクセスに備えて保持することにより達成されうる。
複数のキャッシュサーバは、オブジェクトの共通のキャッシュを共有する階層的な方法で配置されることができ、実際には、それぞれのサーバの第１レベルのキャッシュから入手できなかったファイルに対する集約された要求に応じて、オブジェクトの第２レベルの共有キャッシュを形成する。
「キャッシュ」の基礎を成す理論は、同じファイルは２回以上使用されることがあるので、２回目には、リモート源からファイルを検索するのではなく、ローカルにコピーを保持するほうが（速度および資源利用の双方の観点から）効率的であるということである。
通常、各キャッシュサーバは、小さな１組の最近アクセスされた「ホット」なオブジェクトを、その内部バスに取り付けられた高速で比較的高価なランダムアクセスメモリにキャッシュし、幾分大きな１組のこのようなオブジェクトを、磁気ディスクや光ディスク等の低速で安価なランダムアクセス周辺ストレージデバイスにキャッシュする。
【０００３】
さらに大きな１組のオブジェクトは、ＳＡＮ（「ストレージエリアネットワーク」）やＮＡＳ（「ネットワーク接続型ストレージ」）等のネットワーク接続されたストレージ媒体にローカルにキャッシュされうる。
このネットワーク接続されたストレージ媒体は、リモートサーバから入手する場合よりも高帯域幅、かつ、短い待ち時間を提供する光ファイバケーブル等の比較的短距離で高速な伝送媒体を介して、キャッシュサーバ（ならびに他のローカルクライアントおよび／またはサーバによっても）によりアクセス可能である。
【０００４】
プリフェッチは、現時点および／または過去のファイル要求を分析して、どのファイルが今後要求される可能性があるかを予測する既知の技法であり、それらの予測を使用して、ファイルが実際に要求される前に、緊急度の低さに基づいてリモートサーバからファイルを検索する。
それによって、待ち時間（要求と応答との間の遅延）だけでなくネットワーク輻輳が削減される。
【特許文献１】国際公開第０１／４２９４１号
【特許文献２】米国特許第６２６００６１号
【特許文献３】国際公開第００／１７７６５号
【特許文献４】欧州特許出願公開第０８７７３２６号
【非特許文献１】Rabinovich M 及びSpatscheck O, 「Web Caching and Replication」, ADDISON WESLEY PROFESSIONAL, XP002248389, Chapter 11-12, p177-181, p183-206, p331-343
【非特許文献２】Paul S 他, 「Distributed Caching with Centralized Control」, 2000年2月1日, COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM NL, vol. 24, no. 2, p256-268, XP004228468
【非特許文献３】Foygel D 他, 「Reducing Web Latency with Hierarchical Cach-based Prefetching」, 2000年8月21日, INTERNATIONAL WORKSHOP ON PARALLEL PROCESSING 2000 会報, XP010511939, p103-108
【非特許文献４】Zhang Lin 他, 「an In-depth Survey on Web Caching」, 1999年4月, INTERNET ARTICLE 'ONLINE!(URL:http://trident.mcs.kent.edu/｛1zhang/data/thesis/web_cache.html), p10-23
【発明の開示】
【発明が解決しようとする課題】
【０００５】
これは、キャッシュとは異なる。
異なる点は、焦点が、すでに検索または更新されたファイルのローカルコピーを保持するかどうか（これは、主に、利用可能なローカルストレージ容量をどれだけ最善に使用するかという課題である）にあるのではなく、現時点でローカルに利用可能でなく、かつ、現時点でどの保留要求の対象でもないファイルをリモートサーバから取得するかどうか（これは、主に、リモートサーバへの利用可能な伝送容量をどれだけ最善に使用するかという課題である）にあるという点である。
【課題を解決するための手段】
【０００６】
［概要］
本発明者らは、新しい専用機器（ＳＰＡ（special-purpose appliance））を提案する。
このＳＰＡは、複数のキャッシュサーバ機器（ＣＳＡ）から成るサーバファームと共に動作して、ローカルストレージ媒体を管理する。
このローカルストレージ媒体は、すべてのＣＳＡによってアクセス可能であり、ウェブページおよび当該ウェブページの組み込みオブジェクトならびに／またはストリーミングメディアオブジェクト等のリモートオブジェクトの少なくともいくつかを記憶する。
これらのオブジェクトは、ＣＳＡの１つまたは複数のものによってその各クライアントにサーブされたことがあり、かつ／または、サーブされることになる。
ＳＰＡは、他のあらゆる役割に加えて、キャッシュされた単一のオブジェクトが複数のＣＳＡによって共有されることを容易にし、特定のオブジェクトが、サーバファーム全体に対してより大きな可能性のある値を有する別のオブジェクトといつ取り替えられるべきかを確定する。
本発明者らの高度に拡張性のあるＳＰＡベースのアーキテクチャは、共有外部ストレージとともにクラスタリングされた複数のキャッシュサーバ機器を提供する。
このアーキテクチャでは、キャッシュ機器の個数は、ユーザのニーズに合わせられることができ、キャッシュ用のストレージ量も、ユーザのニーズに合わせられることができる。
【０００７】
共有ローカルストレージのキャッシュ機能を管理することに加えて、ＳＰＡは、好ましくは、ウェブページおよび当該ウェブページの組み込みオブジェクトならびに／またはストリーミングメディアオブジェクト等のリモートオブジェクトをいつプリフェッチするかを確定する。
このプリフェッチするリモートオブジェクトは、現時点では、共有キャッシュに記憶されていない一方、ＣＳＡの各クライアントの１つまたは複数に代わって、ＣＳＡの１つまたは複数により今後要求される可能性があると、ＳＰＡが判断する。
このような共有されたプリフェッチ機能を含むように強化されたＳＰＡを、以下では、プリフェッチサーバ機器（ＰＳＡ（Prefetching Server Appliance））と呼ぶ。
【０００８】
特に、ＳＰＡまたはＰＳＡは、各ＣＳＡからリモートサーバへのファイル要求を単に監視するのではなく、各クライアントからその各ＣＳＡへの個々の要求を監視して集約する。
この監視および集約は、例えば、各ＣＳＡのアクセスログを監視し、そのデータを使用して、１つまたは複数のリモートサーバから共有キャッシュにプリフェッチすべきものと、まだ価値のあるものおよび更新される必要のあるものと、もはや価値がなく取り替えられうるものとを決定することによって行われる。
ＳＰＡまたはＰＳＡがプリフェッチするものは、例えば、すでに要求されたウェブページに存在するリンクと、ウェブページおよびストリーミングメディアオブジェクトへの最近のアクセスパターンと、ユーザプロファイルと、過去の傾向とに基づくことができる。
【０００９】
各ＣＳＡは、いくつかのＣＳＡに共通の共有キャッシュに加えて、専用ローカルキャッシュも有する。
各ＣＳＡは、自身のクライアントの１つからファイル要求を受信するごとに、必ずしも共有キャッシュにアクセスするとは限らない。
同様に、共有キャッシュの各アクセスも、必ずしもリモートサーバへの対応する要求に反映されるとは限らない。
しかし、本発明者らのＰＳＡは、個々のＣＳＡのそれぞれの個々のアクセスログにアクセスできるか、それ以外に、個々のクライアントの個々の要求を監視できる。
したがって、このＰＳＡは、リモートオブジェクトに関する自身のローカル使用予測を次のものに基づくことができる。
すなわち、ＰＳＡは、ＣＳＡからリモートサーバへのそのオブジェクトに対する要求および／またはＣＳＡから共有ローカルキャッシュへの要求を監視することから入手できる限られたデータだけでなく、ＣＳＡがサービスを提供するクライアントからの同じオブジェクトに対する個々の要求であって、ＣＳＡのローカルキャッシュから満たされる個々の要求にも基づくことができる。
また、ＰＳＡは、すでにキャッシュされたファイル内のメタデータ（他のファイルへのリンク、タイトル、著者、最後に編集またはアクセスされた日付、作成日、有効期限等）にアクセスすることもできる。
また、ＰＳＡは、関係したファイル（またはそのファイルの更新版）が今後要求される程度を予測する際に、そのメタデータを使用することもできる。
また、取り替え手順を起動して、リモートサーバから入力するオブジェクト用に、共有キャッシュのスペースを解放する必要がある際に、ＰＳＡは、好ましくは、それらの同じ結合されたアクセスログ（および、場合によっては、その同じメタデータも）を使用して、共有キャッシュから取り替えるものも決定する。
【００１０】
代替的な実施の形態では、各クライアントは、割り当てられた単一のＣＳＡにオブジェクトを直接要求せず、個別のトラフィックディレクタ機器を通じてこのような各要求をルーティングする。
次に、トラフィックディレクタ機器は、いずれかのＣＳＡが、その同じ（または近い関係の）オブジェクトに対する要求を最近ハンドリングしたかどうか判断する。
そして、ハンドリングしている場合には、トラフィックディレクタ機器は、経験および利用可能な資源の双方の観点から、要求を最善にハンドリングできるＣＳＡに当該要求をルーティングすることを試みる。
さらに、このようなＴＤＡの機能が、提案されたＳＰＡ／ＰＳＡと一体化されている場合には、ＳＰＡ／ＰＳＡは、すべてのクライアントの要求を統合した自身のアクセスログを、個々のＣＳＡによって保持されたあらゆるアクセスログとは独立して、保持できる場合がある。
【００１１】
提案されたＳＰＡ／ＰＳＡは、第１に、共有キャッシュを保持するように専用化されることが好ましく、その内部アーキテクチャは、その目的で最適化されることが好ましい。
これによって、各ＣＳＡは、各ＣＳＡのクライアントを専用ローカルキャッシュからサーブするように、最適化されうる。
また、各ＣＳＡは、一定の要求されたオブジェクトがその専用キャッシュに存在しない場合には、それらのオブジェクトのコピーであって、すでにキャッシュおよびプリフェッチされたコピーを共有キャッシュからサーブするように、最適化されうる。
それによって、ピーク負荷時の期間中において、リモートサーバからオブジェクトを得るのに必要な計算サイクルおよびアイドルサイクルが削減される。
【００１２】
以下に説明する例は、ＳＡＮまたはＮＡＳベースのストレージを使用した特定のアーキテクチャおよび特定の機能割り当てを前提とする。
しかし、基礎を成す概念の多くは、他のアーキテクチャおよび機能にも適用されうる。
特に、検索されるオブジェクトは、ＵＲＬで特定されるファイルでなくてもよい。
共有ストレージは、ＷＡＮによってのみアクセス可能な遠隔の場所にあってもよく、かつ／または、このような他の遠隔の場所にある他のクライアントおよびサーバと共有されてもよい。
複数のサーバの機能および管理者の機能は、単一のハードウェアユニット内に組み合わされてもよい。
単一のサーバの機能または管理者の機能は、２つの以上のハードウェアユニット間に分散されてもよいし、複製されてもよい。
さらに、当業者は、思うに現在または将来のいずれかにおいて、検索されたどのオブジェクトがいつどこにキャッシュされるべきか、たとえ要求される前であっても、どの未キャッシュのオブジェクトが検索されるべきか、キャッシュされたどのオブジェクトが取り替えられるべきか、および、どのサーバがどの要求に応答すべきかを判断する他の適切な手順に気付くだろう。
【発明を実施するための最良の形態】
【００１３】
［例］
図１に示すように、キャッシュサーバ複合体（ＣＳＣ（Caching Server Complex））は、好ましくは、複数のキャッシュサーバ機器（ＣＳＡ（caching server appliance））ならびに共有プリフェッチサーバ機器（ＰＳＡ（prefetch server appliance））およびトラフィックディレクタ機器（ＴＤＡ（Traffic Director Appliance））を含む。
ＴＤＡは、ＣＳＡと外部ネットワークＮＥＴとの間の透過的なインタフェースおよび負荷分散機能を提供する。
【００１４】
ＣＳＡ、ＰＳＡ、およびＴＤＡは個別の機能ブロックとして図示されるが、これらの一部またはすべては、単一のキャビネット内に物理的に統合されうるし、同じマシン上で実行する個別のアプリケーションとしても統合されうると理解されるべきである。
他の実施の形態では、ＰＳＡは、ストレージと物理的に同じ場所に置かれてもよいし、他の或る場所に置かれることもでき、かつ／または、ＴＤＡの機能は、外部ネットワークＮＥＴへの個別の交換接続（switched connection）または非交換接続（unswitched connection）と取り替えられることができる。
いずれにしても、ＰＳＡおよび各ＣＳＡの双方は、スイッチングルータ（ＦＣまたはＳＷ１）を通じて、共有ローカルストレージ（ＳＡＮまたはＮＡＳ）に、ローバストな高速接続（光ファイバネットワークの専用チャネルが好ましいが、場合によっては、イーサネット（登録商標）等のデマンドベースのネットワーク）を介して、物理的に接続される。
【００１５】
第２のスイッチングルータＳＷ２は、ＴＤＡを外部ＮＥＴと接続するだけでなく、好ましくは、ＮＥＴからＰＳＡへの、および、ＮＥＴからＮＡＳへの個別の迂回接続（直接またはＳＷ１を介して）をも提供する。
それによって、迂回接続が提供されない場合にＴＤＡによって課される可能性があるあらゆる遅延が回避される。
特に、これらの迂回された接続によって、大量のプリフェッチされたオブジェクトを、ＮＡＳの共有ローカルキャッシュへダウンロードすることが容易になる。
また、図示しないが、ＣＳＡのそれぞれは、ＴＤＡを通過することなくオリジンサーバＳからダウンロードするためのＳＷ２への直接接続を有することもできる。
【００１６】
ＰＳＡは、論理的には、共有ストレージおよび個々のＣＳＡに接続される。
しかし、いずれか１つのＣＳＡが故障した場合であっても、ＰＳＡが継続して機能し、かつ、ＰＳＡが故障した場合であっても、各ＣＳＡが（たとえ低い性能レベルであっても）継続して機能するように、ＰＳＡは、ＣＳＡのいずれとも物理的かつ論理的に独立していることが好ましい。
しかしながら、本発明の原理および利点のいくつかは、ＰＳＡおよびＣＳＡの機能が単一のハードウェアユニットに共に配置される他の実施の形態、または、ＰＳＡの機能が２つ以上のハードウェアユニットに分散もしくは複製される他の実施の形態にも適用可能である。
【００１７】
<第１のシナリオ：ＳＡＮベースのシステムアーキテクチャ>
少なくとも論理的には、ＳＡＮベースのＰＳＡは、通常、図１の上部に図示するように接続される。
図示した実施の形態では、いくつかのＣＳＡは、ファイバーチャネルスイッチＦＣを通じてＳＡＮに接続されることが好ましく、ＰＳＡも、その同じファイバーチャネルスイッチを通じてＳＡＮに接続される。
ＰＳＡと個々のＣＳＡとの間では、限られた量のネットワークトラフィックしか流れないので、そのＰＳＡ／ＣＳＡトラフィックは、通常、ファイバーチャネルスイッチＦＣを通じてルーティングされることはなく、オプションスイッチＳＷ１（ＮＡＳがない場合であっても存在し得る）を介して、または、ＴＤＡおよび関連したスイッチＳＷ２を介してルーティングされる。
上述したように、ＴＤＡおよびＳＷ２は、外部の従来のローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）ＮＥＴにも接続される。
このローカルエリアネットワークおよび／またはワイドエリアネットワークＮＥＴは、個々のＣＳＡをそのそれぞれのクライアント（Ｃ１、Ｃ２）に接続し、１つまたは複数のリモートオリジンサーバ（Ｓ）に接続する。
特に、従来のローカルエリアネットワークは、イーサネット（登録商標）ネットワークであってもよく、従来のワイドエリアネットワークは、インターネットであってもよいし、インターネットベースの仮想プライベートネットワークであってもよい。
他の物理的な場所の他のＣＳＡは、実質的には無制限で瞬時に、同じ共有ストレージ（ＳＡＮまたはＮＡＳ）にアクセスでき、したがって、実際よりもはるかに大きなキャッシュにアクセスできることが当業者には理解されよう。
しかしながら、少なくとも個々のＣＳＡからどの共有ローカルストレージ（ＳＡＮまたはＮＡＳ）への接続も、高帯域幅で短い待ち時間の接続であることが好ましい。
【００１８】
<第２のシナリオ：ＮＡＳベースのシステムアーキテクチャ>
図１の下部に示すように、すべてのＣＳＡおよびＰＳＡは、高速ＬＡＮおよび関連したスイッチングルータＳＷ１を介して、ＮＡＳに接続されてもよい。
あるいは、既存のＬＡＮが使用されて、ＣＡＳを互いに接続してもよく、また、ＣＳＡをそれらの共有ローカルサーバに接続してもよい。
しかしながら、各ＣＳＡとそれらの共有ローカルストレージとの間に専用高速伝送媒体がないと、結果として、このような共有ＬＡＮが他のトラフィックで飽和状態になった場合に、性能が劣化しうる。
【００１９】
<ＣＳＣ機器のアーキテクチャ>
図２は、一般的なキャッシュサーバ複合体機器のアーキテクチャブロック図である。
このキャッシュサーバ複合体機器は、プロセッサＣＰＵと、高速ランダムアクセスストレージＲＡＭと、図１のＳＷ１およびＴＤＡ／ＳＷ２にそれぞれ接続するための一対のネットワークインタフェース（ＮＩ１およびＮＩ２）と、第１のＩ／Ｏインタフェース（ＩＯ１）とを含む。
高速ランダムアクセスストレージＲＡＭは、（少なくともＣＳＡ用に）第１レベルのローカルキャッシュストアＣＳ１を含むことが好ましい。
第１のＩ／Ｏインタフェース（ＩＯ１）は、ローカルストレージＨＤ（通常は１つまたは複数の専用ハードディスク）に接続される。
このローカルストレージＨＤは、ＣＰＵを制御するサーバソフトウェア用に使用され、かつ、通常は、利用可能なＲＡＭ内に含まれうるよりも大きく安価であるが低速である第２レベルのローカルキャッシュストレージ（ＣＳ２）用に使用される。
簡略化された２つのレベルのキャッシュアーキテクチャ（ＲＡＭおよび１つの取り付けられたローカルドライブＨＤ）が図示されるが、ＣＳＡに利用可能な専用ローカルキャッシュは、より多くのレベルまたはより少ないレベルを有することもでき、ＣＳＡの直接制御下にあるプロセッサキャッシュ（ＳＲＡＭ）、メモリ（ＤＲＡＭ）、およびディスクドライブ（内部ディスクドライブおよび外部ディスクドライブの双方）に存在するあらゆるキャッシュ可能なコンテンツを含むことができることが当業者には理解されよう。
【００２０】
当業者には理解されるように、すべての機器が、図２に示すハードウェアコンポーネントのすべてを有するとは限らない。
特に、共有キャッシュは、通常、ＳＡＮまたはＮＡＳのいずれかであり、１つの共有キャッシュインタフェース（ＮＩ１またはＩＯ２）のみがＣＳＡに必要とされる。
同様に、ＣＳＡのみが、通常、ローカルＲＡＭキャッシュＣＳ１およびローカルディスクキャッシュＣＳ２の双方を有し、他のＣＳＣ機器は、個別のＩＯインタフェースを介した専用外部ストレージを必要とすることなく済ますことができる。
最後に、ＣＳＣ機器（ＴＤＡ等）のいくつかは、外部共有キャッシュ（ＳＡＮおよび／またはＮＡＳ）との直接的なインタフェースを何ら必要としない場合がある。
【００２１】
<双方のシナリオに共通の機能>
次に表１を参照すべきである。
【００２２】
【表１】
2006501535.tif 000003
【００２３】
定期的に、各ＣＳＡは、クライアントに関する情報を含んだ表１に示すログと同様のアクセスログを生成する。
オリジンサーバへの当該クライアントの要求は、ＣＳＡによってプロキシされており、かつ、その専用ローカルキャッシュ、共有ローカルキャッシュまたはオリジンサーバのいずれかからサーブされている。
各要求に対して、さまざまな詳細がログに配置される。
このさまざまな詳細は、要求されたＵＲＬ、そのＵＲＬがメモリまたはストレージにすでに存在した（キャッシュヒット）かどうか、アクセスの日付および時刻、転送バイト数、クライアントからの要求のタイプ等である。
このログは、ＣＳＡメモリに収集された要求の詳細を、アクセスログ記憶用の現時点のファイルに追加することによって生成されうる。
異なる時間窓に対しては、その特定の期間中のＣＳＡのアクセスログを記憶するのに、異なるファイル（または、表に示すように、同じファイルの異なる部分）が使用されることが好ましい。
ディレクトリ構造体およびファイル名は、ＰＳＡがすべてのＣＳＡのアクセスログを読み出すことを可能にする規則に従う。
その結果、ＰＳＡは、個々のＣＳＡアクセスログを、同様にフォーマットされた統合ログ内に結合することができる。
さらに、ＰＳＡは、前の時間、前の日、前の週等の異なる時間窓のアクセスデータを処理して、毎日、毎月曜日、月の第１営業日等の同じ時刻において繰り返すアクセスパターンを検出することもできる。
【００２４】
また、少なくともキャッシュ機能は、１つまたは複数のＣＳＡによって、個別に管理されうるが、ＰＳＡは、ＳＡＮまたはＮＡＳに存在する共有オブジェクトキャッシュのコンテンツの常時監視も行い、好ましくは、この共有キャッシュの管理も担当する。
特に、ＣＳＡは、そのクライアントの１つによって要求されたファイルが共有キャッシュから入手できないと判断すると、リモートオリジンサーバからそのローカル専用キャッシュへそのファイルのダウンロードを開始して、次いで、低優先度のバックグラウンド機能として、共有キャッシュにそのキャッシュされたファイルのコピーを転送できる。
しかしながら、待ち時間が比較的長く、帯域幅が比較的低いインターネットまたは他のＷＡＮネットワークＮＥＴを介して、遠方のサーバＳに要求されたファイルをダウンロードすることは、ＬＡＮまたはファイバーチャネルを介して、ローカルストレージファーム（ＳＡＮまたはＮＡＳ）から同じファイルを検索することよりも遅く、計算資源をより浪費する。
したがって、キャッシュ機能のこの態様であっても、ＰＳＡが管理することが好ましい。
このような集中化されたダウンロード機能は、異なるＣＳＡからの同じファイルの複数の要求をチェックすることが好ましく、したがって、限られた利用可能帯域幅が、さらに効率的に利用される。
【００２５】
新たにプリフェッチされたファイルを記憶するのに十分な空きスペースがまだ利用可能でない場合、ＰＳＡ（または共有キャッシュ機能のこの態様の管理を担当する他のエンティティ）は、どのオブジェクトを共有キャッシュから取り替えるか、および、いつ取り替えるかを確定する或るメカニズムを有しなければならない。
潜在的に、２種類の情報が、この目的のために、ＰＳＡに利用可能である。
ＰＳＡは、キャッシュの各オブジェクトのアクセス頻度や、各オブジェクトがどれくらい近時にアクセスされたか等の履歴使用データとして、前述した統合アクセスログを解析できる。
その使用データは、共有キャッシュにおけるファイルのコピーのアクセスだけでなく、キャッシュサーバのそれぞれによって保持された専用キャッシュにおけるその同じファイルの他のコピーのアクセスも反映する。
他の入力は、アクセスされた各オブジェクトのメタデータとされうる。
このメタデータは、オブジェクトのサイズ、コンテンツタイプまたは有効時間等である。
この有効時間は、当該有効時間を過ぎると、クライアントへサーブされる前に、キャッシュオブジェクトの有効性の検証をオリジンサーバから受けなければならない時間である。
【００２６】
アクセスログ（表１）が、定期的にしか更新されない場合、共有キャッシュへのアクセスに関するより近時の情報は、ＣＳＡから共有キャッシュに送信された実際の要求を監視することから得られうる。
しかしながら、アクセスログは、ＣＳＡと共有キャッシュとの間の伝送を単に監視することによっては得ることができないさらに有用な情報も提供する。
例えば、ＣＳＡが、ウェブページを共有キャッシュからそのメモリに転送すると、ＣＳＡは、複数のクライアントの要求を自身のメモリからサーブできる。
ＰＳＡがそのウェブページへのアクセス回数について知るための最も簡単な方法は、各ＣＳＡによって保持されたアクセスログを処理することによる。
あるいは、ＣＳＡのアクセスログまたはその或るサブセットに書き込まれる情報も、影響を受けたＣＳＡによって、適切なメッセージフォーマットで、ＰＳＡに同時に送信されうる。
【００２７】
アクセス情報がどのようにして得られるかおよびどこに記憶されるかにかかわらず、ＰＳＡは、ＣＳＡを発信源とするこのアクセス情報を使用して、いつプリフェッチすべきかおよび何をプリフェッチすべきかを確定することが好ましい。
履歴アクセスデータの解析に基づいて、ＰＳＡは、近い将来に、おそらく頻繁にアクセスされるコンテンツを予測できる。
例えば、アクセスログにデータマイニング技法を適用することによって、過去の日のニュースのウェブページ、オーディオおよびビデオのアーカイブが、午前７時から９時の間に、ｎｅｗｓ．ｃｏｍウェブサイトから多くアクセスされることが明らかにされうる。
これらのアクセスを高速にハンドリングするために、ＰＳＡは、午前６時から７時の間に、このコンテンツのプリフェッチを発行できる。
これらのプリフェッチは、ウェブクローラ内に生成されうる。
このウェブクローラは、ｎｅｗｓ．ｃｏｍからトップレベルのページをプリフェッチし、それらトップレベルのページのハイパーリンクに従って、ハイパーリンクごとにプリフェッチを発行する。
同様に、１２時から午後１時の間では、ｗａｉｔｅｒ．ｃｏｍにおいて利用可能なレストランメニューへのアクセスが、頻繁に行われうる。
したがって、これらのページは、午前１１：３０から正午までの間に、プリフェッチされうる。
大きなストリーミングメディアファイルの場合、ファイル全体をプリフェッチすることは妥当でない場合がある。
その場合には、最初の数秒の再生時間に対応するファイルのプリフィックス部分をプリフェッチされうる。
これによって、クライアントの要求に対する応答の待ち時間は、非常に短くなりうる。
同様に、ＰＳＡが、ビデオに対する今後のほとんどの要求は特定のフォーマットおよび解像度であると判断すると、ＰＳＡは、そのインスタンスのみをプリフェッチしてもよい。
これらは、「経験ベース」のプリフェッチと以下で呼ばれる例である。
【００２８】
ＰＳＡは、ＣＳＡと共有キャッシュとの間の全トラフィックを監視することが好ましいので、ＰＳＡは、保留要求が共有キャッシュから満たされることができない時（いわゆる「デマンドミス」）を知っている。
ＰＳＡまたは要求を行っているＣＳＡが、その時、リモートオリジンサーバ（または下流側のプロキシまたはミラー等の他の情報源）へファイルを要求する役割を負うかどうかにかかわらず、ＰＳＡは、この情報にアクセスできる。
このようなデマンドミスの結果、外部ネットワーク上の帯域幅は、さらに利用される。
したがって、デマンドミスの個数（より適切には、共有キャッシュに現時点で記憶されていない要求ファイルをダウンロードするのに必要なダウンロード帯域幅）が増加するに伴い、ＰＳＡは、そのプリフェッチアクティビティを低減することによって対応することが好ましい。
したがって、プリフェッチオペレーションは、デマンドミスに応じて、リモートサーバから要求ファイルを検索することよりも低い優先度を与えられるべきであり、利用可能なシステム資源は、より効率的に（かつ適応して）使用される。
逆に、十分な帯域幅が、さらなるプリフェッチを実行するのに利用可能であっても、すでにキャッシュされたファイルを、さらなるプリフェッチによって得られた他のファイルと取り替えることは、必ずしもそれらの資源の効率的な使用であるとは限らない。
例えば、現時点のデマンドミスが比較的少ない（一定のしきい値未満）場合に、プリフェッチされたオブジェクト数（あるいは、割り当てられたネットワーク帯域幅）は、さらに削減されうる。
その理由は、追加されたあらゆるプリフェッチが、労力の追加を正当化するのに十分な性能の改善を生み出す見込みがなく、現時点のキャッシュの有効性を劣化させる可能性さえあるからである。
【００２９】
経験ベースのプリフェッチを「ジャストインタイム」のプリフェッチと組み合わせることによって、ＰＳＡは、現時点の使用（デマンドミスに応じてつい最近キャッシュされたファイル、または、事前にプリフェッチされたファイルの最初の要求のいずれか）に基づく予測プリフェッチのサポートを提供することもできる。
履歴アクセスデータのレビューに基づいて、ＰＳＡは、特定のオブジェクトの要求に続いて、他の一定の関係オブジェクトに高い確率でアクセスが行われると判断できる。
そして、それらの関係オブジェクトが共有キャッシュにまだ存在しない場合には、ＰＳＡは、それらのオブジェクトのプリフェッチを発行する。
場合によっては、このような関係ファイルは、アクセスログから収集された履歴情報を事前に解析することによって、前もって決定されうる。
他の場合には、これらの他の関係オブジェクトは、現時点の要求の結果のみから確認されることができ、例えば、他のウェブページへのハイパーリンクが使用されて、それら他のページに対するプリフェッチを開始できる。
後者の可能性は、現時点の使用にのみ基づき、そのために、ＰＳＡがそれ以上介入することなく、ＣＳＡが現時点の要求をハンドリングすることによって実行されうる、純粋な「ジャストインタイム」のプリフェッチの一例である。
しかしながら、ハイパーリンクされたファイルは、別のＣＳＡによってすでにキャッシュされ、かつ／または、共有キャッシュにすでにキャッシュされている可能性があり、そのために、ＰＳＡによる何らかの調整が依然として望ましい。
【００３０】
経験ベースのプリフェッチの「ジャストインタイム」のプリフェッチとの別の可能な組み合わせは、特に、ストリーミングメディアファイルに適用可能である。
履歴使用データは、一定の間隔（例えば、各トラックの開始）のみのプリフェッチに優先順位を付けることができ、現時点の使用データは、最初の間隔が実際に要求された後にのみ、その後の間隔のプリフェッチをトリガする。
このトリガは、おそらく、オリジンサーバがそのトラックの残りを送信する低優先度のバックグラウンドタスクとして行われる。
このような手法は、待ち時間を何ら増加させることなく、プリフェッチされるデータ量および必要とされる関連したローカルストレージを削減するだけでなく、ネットワーク性能も改善する。
同様に、大きなオブジェクトの場合、そのオブジェクトの小さなフラクション（「チャンク」）のみがプリフェッチ（プリフィックスキャッシュ（prefix caching））されることが好ましい。
プリフェッチされた量は、キャッシュサーバのストレージの容量、クライアント側の消費率およびオリジンサーバへのネットワーク帯域幅に基づいてもよい。
また、プリフェッチするオブジェクト数も、予測されたヒット率によって決定されてもよい。
予測されたヒット率が大きい場合には、大きなチャンクサイズを有する少数のオブジェクトがプリフェッチされる。
他方、予測されたヒット率が小さい場合には、小さなチャンクサイズを有する多くのオブジェクトがプリフェッチされる。
【００３１】
次に、どのファイルがＰＳＡにキャッシュされるべきか、ＰＳＡにすでにキャッシュされたどのファイルが取り替えられるべきか、ＣＳＡからＰＳＡにどのファイルがコピーされるべきか、および、各クライアントの要求に適したＣＳＡをどのように関連付けるか（オプション）を決定する例示の手順を説明する。
【００３２】
<例示のプリフェッチ手順>
ステップ１
ＯＬＡＰ、データマイニング、関係データベースに対する標準的なＳＱＬクエリー等の技法を用いて、（プロキシキャッシュおよびストリーミングメディアサーバの双方からの）ＣＳＡによって書き込まれたアクセスログを解析する。
この解析は、アクセスログからのコンテンツを、これらの技法に必要なフォーマットに変換することを必要とする。
例えば、関係データベースに対するＳＱＬクエリーは、アクセスログのコンテンツがデータベースの適切な関係表に追加されることを必要とする。
【００３３】
ステップ２
ＣＳＡのアクセスログデータを使用して、平日または土曜日もしくは日曜日の時間帯別のコンテンツのアクセス変化を与える表を作成する。
【００３４】
【表２】
2006501535.tif 000004
【００３５】
この表は、１日のさまざまな時間について、或るしきい値よりも高い頻度でアクセスされたコンテンツを列挙している。
この表を平日について作成するために、前の週、前の月、または前の数ヵ月の間の平日のアクセスログの全エントリが、考慮されうる。
前の週を考慮するのか、それとも前の月を考慮するのかは、それぞれの場合にプリフェッチがどれだけ正確であるかのフィードバックに依存する。
【００３６】
ステップ３
ＣＳＡアクセスログデータが使用されて、以下のようなフォーマットでありうる相関ルールを特定することもできる。
・Ａ，Ｂ，Ｃ，Ｄ→Ｅ  このルールによれば、クライアントがＵＲＬ  Ａ、Ｂ、ＣおよびＤを要求している場合には、次の要求は、Ｅに対する可能性が高い。
したがって、Ｅは、プリフェッチの好適な候補である。
・（Ｗ，Ｘ）（Ｕ，Ｖ，Ｘ，Ｚ）  このクラスタリングルールによれば、ＷへのアクセスとＸへのアクセスとの間に強い相関がある。
したがって、いずれかがクライアントによって要求される場合には、プロキシは、他方をプリフェッチの候補とみなすべきである。
同様に、Ｕ、Ｖ、Ｙ、およびＺのいずれか１つがクライアントによってアクセスされる場合には、プロキシは、他の３つをプリフェッチの候補とみなすべきである。
これらのルールは、包括的ではない。
ステップ１で述べた技術分野の当業者には、それ以外のルールが明らかであろう。
【００３７】
ステップ４
当日の異なる時間の間のアクティビティを示す表を作成する。
【００３８】
【表３】
2006501535.tif 000005
【００３９】
この表は、関連したＣＳＡのアクセスログを解析することによって、一定の領域をサーブするＰＳＡに対して準備されうる。
各時間間隔について、毎秒の要求数の平均が得られる。
この平均は、その領域におけるクライアントからのトラフィックの見積もりを与える。
【００４０】
ステップ５
ステップ４からのアクティビティレベル表が使用されて、毎秒の要求が少ないのでネットワークトラフィックが低い、午前４時から午前７時等の時間間隔の間のプリフェッチをスケジューリングできる。
プリフェッチされるコンテンツは、ステップ２の使用表によって決定される。
このプリフェッチは、コンテンツがＳＡＮにもＮＡＳにもまだ存在しない場合にのみ発行される。
ＰＳＡおよび取り付けられたＳＡＮデバイスまたはＮＡＳデバイスのストレージ容量に応じて、その時間間隔のＵＲＬのサブセットのみが、場合によっては、プリフェッチされうる。
その場合、ＵＲＬは、そのＵＲＬのオリジンサーバの平均予測待ち時間等の判断基準に基づいて、優先順位を設けられうる。
この判断基準は、アクセスログに基づいて評価されうるし、オリジンサーバへのネットワークホップ数に基づいて見積もられうる。
より多くのネットワークホップ数は、より長い待ち時間を意味する。
【００４１】
スケジューリングされたプリフェッチに加えて、ステップ３で導出されたルールを使用して、ジャストインタイムのプリフェッチが行われうる。
これらのルールがＰＳＡによってＣＳＡに伝えられると、このプリフェッチは、より効率的に行われうる。
その場合に、ＣＳＡがＵＲＬ  Ｘに対する要求を取得すると、ＣＳＡは、ステップ３のクラスタリングルールに従って、関連したＵＲＬ  Ｗがストレージの階層のどこかに存在するかどうかをチェックできる。
存在しない場合には、ＣＳＡは、Ｗのオリジンサーバに要求を送信できる。
ＣＳＡからオリジンサーバへの往復待ち時間がＡミリ秒であり、クライアントからのＷの要求がＢミリ秒後にＣＳＡに達するとすると、Ａ>Ｂの場合には、クライアントは、この待ち時間のうち（Ａ−Ｂ）ミリ秒のみに立ち会うことになり、Ｂ≧Ａの場合には、待ち時間に立ち会うことはない。
【００４２】
ステップ７
ステップ５またはステップ６のいずれかにおいて、プリフェッチされるＵＲＬが静的コンテンツ（組み込み画像を有するＨＴＭＬテキスト）ではなくストリーミングメディア（ＭＰＥＧファイル等）である場合、そのＵＲＬは、ユーザ経験が異なることから、特別な場合として取り扱われるべきである。
静的コンテンツの場合、コンテンツ全体がダウンロードされ、単一のページビューとしてユーザに提示される。
ストリーミングメディアの場合、ユーザは、一時停止、中断、停止、または早送りを行うことができる。
これらのＶＣＲのような制御は、ＣＳＡ上で実行するストリーミングメディアサーバに伝えられる。
このサーバはアクセスログを生成する。
ステップ１の技法を使用して、ストリーミングメディアのどのセグメントが頻繁に視聴されるかが特定されうる。
例えば、人々は、ニュース放送の最初の数分を視聴してヘッドラインを取得し、次いで、そのニュースのビジネス部分またはスポーツ部分に、早送りまたはインデックスすることがある。
したがって、最初の数分、ならびにビジネス部分およびスポーツ部分がキャッシュされうる。
クライアントが最初の数分を超えて視聴するように思われる場合、そのクライアントは続けて視聴する可能性がある。
その場合には、クライアントが継続して視聴するに伴い、ジャストインタイムのプリフェッチは、ニュース放送のその後のセグメントのために、ＣＳＡにより発行されうる。
【００４３】
ステップ８
ステップ６または７のいずれかにおけるジャストインタイムのプリフェッチの場合、クライアントがサービスを受けている間、コンテンツは、ＣＳＡによりプリフェッチされて、そのローカルディスクに最初に配置されることが好ましい。
その後、バックグラウンドにおいて、ＣＳＡは、すでにプリフェッチされたコンテンツをＰＳＡに登録し、ＰＳＡは、すでにプリフェッチされたコンテンツをＣＳＡがコピー（「ライトバック」）すべきＳＡＮストレージデバイスまたはＮＡＳストレージデバイスの場所を示すことによって応答する。
【００４４】
<例示の取り替え手順>
ＰＳＡは、ＳＡＮデバイスおよび／またはＮＡＳデバイスの共有キャッシュからコンテンツを定期的に追い出す。
この取り替え手順は、以下のいくつかの調整可能なパラメータを有することが好ましい。
・Ｈは、共有キャッシュによるディスクスペース使用の上位しきい値である。
・Ｌは、共有キャッシュによるディスクスペース使用の下位しきい値である。
・Ｖは、ＵＲＬの値である。
このアイデアは、より有用なコンテンツをキャッシュに保持することであり、アクセス頻度、最も近時のアクセス時刻、有効期間に対して残された時間（オリジンサーバによって設定される）、および／またはＧＤＳＦ等のハイブリッドパラメータに基づくことができる。
また、このアイデアは、ＣＳＡのアクセスログの定期的なアクセス（または、後述するＴＤＡの機能が実施される場合には、ＴＤＡのＵＲＬ表）によって決定されることが好ましい。
【００４５】
Ｈが９５％であり、Ｌが８５％であると仮定する。
共有キャッシュの占有度が９５％に達するとすぐに、この取り替え手順は実行され、キャッシュの占有度が利用可能なスペースの８５％未満となるまで、共有キャッシュからコンテンツを追い出し続ける。
ＨおよびＬを調整することによって、取り替え手順が実行される頻度、および、各実行において行われる作業量を制御されうる。
【００４６】
取り替え手順は、Ｖによって順序付けられたリストのキャッシュ（または、この目的を果たすヒープ等のより効率的なデータ構造体）に存在するＵＲＬのほとんどを保有することが好ましい。
その結果、取り替えの可能性のある候補が、高速に選択されうる。
【００４７】
取り替え手順は、当日に後ほど使用が予想されていることからキャッシュにロックされたＵＲＬをスキップすることが好ましい。
ロックは、ネットワークトラフィックが少なくなった時（午前５時から７時の間等）にスケジューリングされたプリフェッチと共に行われ、予測可能なその後の繁忙期間（午前７時から１０時）の間に、コンテンツが多く利用されることが予想されることに備える。
スケジューリングされたプリフェッチは、予想された使用の多い期間の終了（午前１０時）までＵＲＬをロックできる。
あるいは、ＵＲＬは、予想された使用の多い期間の開始直後（例えば、午前８時）までロックされうる。
その場合、プリフェッチ予測が正確であると、午前８時までに十分なアクセスがあり、そのＵＲＬは、多くアクセスされている限り、取り替えられないことが保証される。
一方、プリフェッチが予測ミスという結果になると、午前８時の後、そのＵＲＬは追い出されることになる。
取り替え手順が、ロックされたＵＲＬをスキップしなければならないので、それらのロックされたＵＲＬは、リストＬとは別のリストに保持されることが好ましい。
ロックされたＵＲＬは、ロックが解除された後にのみリストＬに追加され、可能な追い出し候補となる。
【００４８】
各実行において、取り替え手順は次のように実行される。
すなわち、最小値のＶを有するリストＬのＵＲＬから開始して、ディスクスペース使用が下位しきい値Ｌに下がるまで、ＵＲＬが１つずつキャッシュから削除される。
【００４９】
<例示のライトバック手順>
上記手順は、ＳＡＮデバイスおよび／またはＮＡＳデバイスにおいて、スペースがＰＳＡによってどのように解放されるかを説明している。
このスペースのいくつかは、ＰＳＡがスケジューリングされたプリフェッチを行う際に、ＰＳＡによって使用される。
一方で、ジャストインタイムのカテゴリーおよびキャッシュミスにおいていくつかのプリフェッチが追加されることを想起されたい。
これらのカテゴリーの双方では、ＰＳＡではなくＣＳＡが、オリジンサーバと接触して、自身のローカルディスクおよびメモリにコンテンツを運び込むことが好ましい場合がある。
しかしながら、そのプリフェッチされたコンテンツの少なくとも一部は、共有キャッシュ（ＳＡＮ／ＮＡＳ）に保存する価値があり、それによって、サーバ複合体の他のＣＳＡが、キャッシュミスの問題なく、かつ、オリジンサーバにアクセスすることなく同じコンテンツをサーブでき、かつ／または、要求を行っているＣＳＡが、「よりホット」な（より高いＶの）ＵＲＬ用に自身の限られたローカルキャッシュストレージを解放できる。
これは、ライトバック手順によって行われる。
簡単なライトバック手順は、以下以下の通りである。
【００５０】
ステップ１
ＣＳＡは、時に、自身のキャッシュのコンテンツの表をキャッシュ間で交換する。
【００５１】
ステップ２
ＣＳＡ  Ａがクライアントから或るＵＲＬの要求を受信し、そのＵＲＬがＣＳＡ  Ａのキャッシュに存在しないが、別のＣＳＡ  Ｂのキャッシュに存在する場合、ＣＳＡ  Ａは、コンテンツが或るオリジンサーバに要求されたのと同様に、ＣＳＡ  Ｂにコンテンツを要求できる。
ＣＳＡ  Ｂは、短い待ち時間でＣＳＡ  Ａにコンテンツを送信できる。
【００５２】
ステップ３
ＣＳＡ  Ｂは、ＣＳＡ  Ａにコンテンツを送信した後、ＵＲＬ、自身のローカルディスクにおけるＵＲＬの場所およびコンテンツのサイズを、表に入力する。
【００５３】
ステップ４
定期的に、ＣＳＡ  Ｂは、この表をＰＳＡに送信する。
【００５４】
ステップ５
ＰＳＡは、表のサイズの列を合計し、必要なストレージ量が、共有キャッシュに確実に存在するようにする。
これは、そのスケジューリングされた時刻に先立って、取り替え手順の実行を必要としうる。
【００５５】
ステップ６
次いで、ＰＳＡは、共有キャッシュにおいて、各ＵＲＬをファイル名にマッピングし、ＵＲＬをファイル名にマッピングした表を、ＣＳＡ  Ｂに返信する。
【００５６】
ステップ７
次いで、ＣＳＡ  Ｂは、共有キャッシュ（ＳＡＮ／ＮＡＳ）において、各ＵＲＬのコンテンツをその対応するファイル名にコピーできる。
【００５７】
ステップ８
共有キャッシュのコンテンツの更新された表は、ＰＳＡによってすべてのＣＳＡに定期的に送信され、それによって、その後のクライアントによるあらゆるＣＳＡへの共有コンテンツの要求は、オリジンサーバにも他のＣＳＡにもメッセージを送信することなく、ＣＳＡによって共有キャッシュから満たすことができる。
【００５８】
<例示のトラフィック方向プロセス>
複数のＣＳＡおよびＰＳＡから成るサーバファームは、負荷分散装置またはトラフィックディレクタ機器（ＴＤＡ）として一般に知られている別のサーバ機器も有することができる。
このサーバ機器は、ＣＳＡを、一定の割り当てられたクライアントに専用の各ＣＳＡとしてではなく、プールとして編成し、所定の割り当て手順（通常、単純なラウンドロビン割り当てまたはランダム割り当て）を使用して、すべてのクライアントからの要求を、このプール内において、ＣＳＡに送信する。
それによって、ＣＳＡの負荷は、分散される。
ＴＤＡは、ＰＳＡに組み込まれることが好ましく、各ＵＲＬを最近サーブしたことがあるＣＳＡに対する、そのＵＲＬの事前に知られたあらゆる親和性を利用することが好ましい。
このような親和性ベースのＴＤＡは、以下のように実施されうる。
【００５９】
ステップ１
ＰＳＡは、ＵＲＬの高速参照を可能にするハッシュ表等の大きな表を保持し、それによって、いずれかのクライアントが以前にそのＵＲＬを要求したかどうかを判断し、いずれかのクライアントが以前にそのＵＲＬを要求している場合には、ＣＳＡのいずれにその要求が転送されたかを判断する。
このような転送に含まれる最近のＮ個の異なるＣＳＡが、この表に記憶されうる。
ここで、Ｎは、通常、小さく、例えば３である。
【００６０】
ステップ２
ＴＤＡは、クライアントの要求を受信すると、ＵＲＬを使用して表を探索する。
エントリが存在する場合には、その同じＵＲＬについて、少なくとも１つ、場合によってはＮ個以上の以前の要求が、ＴＤＡによってＣＳＡに転送されたことを意味する。
これらのＣＳＡが、転送された要求の時刻によってソートされていると仮定すると、ＴＤＡは、現時点の要求を、同じＵＲＬについて最も近時の以前の要求を取得したＣＳＡに転送できる。
このＣＳＡは、自身のローカルキャッシュに、そのＵＲＬのコンテンツをまだ有している可能性が最も高い。
【００６１】
ステップ３
しかしながら、このＣＳＡが、現時点で、平均負荷より高い負荷を有する場合には、その応答時間が遅くなる可能性がある。
その場合には、ＴＤＡは、多くともＮ個の関連したＣＳＡのリストを用いて、最も近時に含まれたＣＳＡから、最も過去に含まれたＣＳＡに順番に配列し、そして、現時点の要求を受け付けうる現時点の負荷である最初のＣＳＡを選択できる。
【００６２】
ステップ４
適切なＣＳＡが見つからない場合、または、表がこのＵＲＬのエントリを有しない場合には、ラウンドロビン割り当てやランダム割り当て等のデフォルトのＴＤＡ手順に従う。
【００６３】
ステップ５
表が更新される。
そのＵＲＬ用のエントリが存在しない場合には、新たなエントリがそのＵＲＬ用に作成される。
また、現時点の要求用に選択されたＣＳＡも、このＵＲＬに対して最も近時に要求されたとして加えられる（または、その既存のエントリが更新される）。
他のＮ個のＣＳＡがリストにすでに存在する場合には、最も過去に要求されたＣＳＡがリストから廃棄される。
【００６４】
このようなトラフィック方向手順が、共有キャッシュ（ＳＡＮ／ＮＡＳ）から複数のＣＳＡのローカルディスクへのデータコピー量を最小にし、ライトバック手順による逆方向で書き込まれるデータ量も最小にすることは当業者には明らかであろう。
これは、ＣＳＡの変化する負荷状況の下において可能な範囲で、同じＣＳＡまたは同じ小さな１組のＣＳＡが同じＵＲＬについてのすべてのクライアント要求にサービスを提供することを、トラフィック方向手順が確保しようとするからである。
【００６５】
上記内容は、要求がクライアントにサーブされる待ち時間を最小にすることも当業者には明らかであろう。
ＣＳＡのローカルキャッシュからサーブされるどの要求も、別のＣＳＡまたは共有ストレージ（ＳＡＮ／ＮＡＳ）からデータをフェッチすることを必要とする要求よりも、要する時間が短い。
したがって、このＴＤＡ手順は、ローカルキャッシュがより頻繁にコンテンツを有することを確実にする傾向がある。
【００６６】
<アプリケーションプログラマインタフェース>
既存のプロキシキャッシュと同様に、ＣＳＣも、共有アプリケーションプログラマインタフェース（ＡＰＩ）を有することが好ましい。
このＡＰＩは、ＣＳＣの振る舞い（特に、複数のユーザによる同じキャッシュファイルへの繰り返しアクセス、または、まだ要求されていないファイルのダウンロード）が、キャッシュデータのコンテンツを所有する機構によって制御されることを可能にする。
この共有ＡＰＩの機能は、ＰＳＡ／ＴＤＡに含まれることが好ましい。
そして、共有ＡＰＩの機能は、図３に示すように、ネットワーク（ＮＥＴ）、オリジンサーバ（Ｓ）、およびクライアント（Ｃ１、Ｃ２）に、従来の拡張性のない単一のＣＳＡ構成に含まれる同様のＡＰＩ機能を透過的に取り替えたＡＰＩを提供する。
しかし、ＰＳＡベースのＣＳＣは、共有キャッシュ（ＮＡＳまたはＳＡＮ）から複数のＣＳＡにサービスを提供するので、ＡＰＩの機能の追加が意図される。
例えば、ｎｅｗｓ．ｃｏｍウェブサイトのオーナとの同意により、午前７時から９時の予測されたピーク負荷に備えて、一定のタイプのコンテンツのみが、ＰＳＡのＡＰＩを通じてＳＡＮまたはＮＡＳにプッシュされうる場合がある。
異なるＳＡＮストレージデバイスまたはＮＡＳストレージデバイスに取り付けられた複数のＰＳＡは、オリジンサーバに向かうことなく、相互にコンテンツを要求することを許可される場合もあるし、許可されない場合もある。
このＡＰＩは、他のコンテンツがたとえ使用されない場合であっても、一定のクライアントが他のコンテンツについてのプリフェッチされた要求をバックグラウンドで発行することを可能にすることができ、そして、プリフェッチされたコンテンツのダウンロード（および支払い）を強制されることなく、当該他のコンテンツの要求および監視をＰＳＡによって行わせることを可能にすることができる。
ＰＳＡは、ＣＳＡのアクセスログを解析するので、ＡＰＩは、ＣＳＡファームのアクセス統計情報を要求するネットワーク監視エンティティのサポートを提供するように設計されてもよい。
このアクセス統計情報は、ＣＳＡアクセスログの単純なダウンロード形式、または、ＰＳＡによって生成された情報をフィルタリングして集約した形式のいずれかである。
また、ＡＰＩは、このネットワーク監視エンティティが、ネットワークの他の場所で現時点にダウンロードまたはプリフェッチされた「ホット」なコンテンツに関する情報に加えて、複製されたオリジンサーバの異なるインスタンスに対する検知された負荷および／または異なるネットワークパスの検知された待ち時間に関する情報もＰＳＡに送信することを可能にする。
それによって、ＰＳＡの性能が向上される。
【００６７】
<結論>
複数のローカルキャッシュサーバ（ＣＳＡ）を、好ましくはプリフェッチ機能（ＰＳＡ）、負荷管理（ＴＤＡ）および透過的な外部インタフェース（ＡＰＩ）を有する共有管理（ＳＰＡ）によって補完することにより、ＣＳＡのみによって可能な場合よりも、さらに大きな帯域幅、短い待ち時間、および利用可能なストレージのより効率的な使用を提供できる。
特に、ＳＰＡ／ＰＳＡが、各ＣＳＡクライアントからのすべての要求に関する情報へのアクセスを提供される場合に、これら大きな帯域幅等は提供されうる。
【図面の簡単な説明】
【００６８】
【図１】ストレージエリアネットワーク（ＳＡＮ）および／またはネットワーク接続型ストレージ（ＮＡＳ）に接続されたプリフェッチサーバ機器および複数のキャッシュサーバ機器を含む例示的なキャッシュサーバ複合体を示す図である。
【図２】一般的なキャッシュサーバ複合体機器のアーキテクチャブロック図である。
【図３】同じアプリケーションプログラマインタフェース（ＡＰＩ）を、単一のＣＳＡまたは複数のＣＳＡを含むキャッシュサーバ複合体のいずれかにどのようにして使用できるかを示す図である。
【符号の説明】
【００６９】
Ｃ１・・・有線クライアント
Ｃ２・・・無線クライアント
ＲＢＳ・・・無線
ＮＥＴ・・・ＬＡＮまたはＷＡＮもしくはインターネット
Ｓ・・・オリジンサーバ
ＭＧＲ・・・ネットワークマネージャ
ＮＩ１、ＮＩ２・・・ネットワークインタフェース１、２
ＣＳ１・・・ローカルキャッシュ
ＩＯ１、ＩＯ２・・・Ｉ／Ｏインタフェース１、２
ＣＳＣ・・・キャッシュサーバ複合体
Ｃ・・・無線または有線クライアント
【図１】
2006501535.tif 000006
【図２】
2006501535.tif 000007
【図３】
2006501535.tif 000008
【国際調査報告】
2006501535.tif 000009
2006501535.tif 000010
2006501535.tif 000011