特許 5795690 エッジ・ネットワーク・サーバにおけるマルチ・ドメイン構成処理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5795690

(24)【登録日】2015年8月21日

(45)【発行日】2015年10月14日

(54)【発明の名称】エッジ・ネットワーク・サーバにおけるマルチ・ドメイン構成処理

(51)【国際特許分類】

   G06F 15/00 20060101AFI20150928BHJP

   G06F 13/00 20060101ALI20150928BHJP

【ＦＩ】

   G06F15/00 470

   G06F13/00 520C

【請求項の数】7

【全頁数】18

(21)【出願番号】特願2014-540100(P2014-540100)

(86)(22)【出願日】2012年11月1日

(65)【公表番号】特表2015-501498(P2015-501498A)

(43)【公表日】2015年1月15日

(86)【国際出願番号】US2012063120

(87)【国際公開番号】WO2013067224

(87)【国際公開日】20130510

【審査請求日】2014年8月29日

(31)【優先権主張番号】13/666,068

(32)【優先日】2012年11月1日

(33)【優先権主張国】US

(31)【優先権主張番号】61/554,571

(32)【優先日】2011年11月2日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】504266979

【氏名又は名称】アカマイ テクノロジーズ インコーポレイテッド

(74)【代理人】

【識別番号】100091568

【弁理士】

【氏名又は名称】市位 嘉宏

(72)【発明者】

【氏名】ルディン、スティ−ヴン、エル

(72)【発明者】

【氏名】ラグハテ、プラサンナ

(72)【発明者】

【氏名】スティーヴンス、マシュー、ジェイ

(72)【発明者】

【氏名】ショットン、フレデリック、アール

(72)【発明者】

【氏名】ハタラ、ジョゼフ

【審査官】 田中 幸雄

(56)【参考文献】

【文献】 特表２００５−５３７６８７（ＪＰ，Ａ）

【文献】 特開２００７−１５６９０６（ＪＰ，Ａ）

【文献】 特表２０１０−５０３９０１（ＪＰ，Ａ）

【文献】 特開平０７−０７８０６３（ＪＰ，Ａ）

【文献】 特開２００８−１３４５７３（ＪＰ，Ａ）

【文献】 河村春雄ほか，ＤＮＳを用いた大規模分散コンテンツデータベースの構築に関する提案，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２００７年 ３月 １日，Ｖｏｌ．１０６ Ｎｏ．５７８，３４５−３５０頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １５／００

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

第一者により運営される装置であって、
プロセッサを含むハードウェアと、
前記ハードウェア上で実行されるように適合されたコンピュータ・プログラムの命令を保持するコンピュータメモリと、
を備えた装置であって、
前記コンピュータ・プログラムの命令が、
第二者のカスタマの、一連の独自のドメイン名を単一の構成ファイルにマップすることを可能にするマルチ・ドメイン構成（ＭＤＣ）処理機能をアクティブ化する第二者データを受け取るコードを備え、前記第二者のカスタマの、一連の独自のドメイン名の少なくとも１つは、前記第一者ではなく前記第二者に関連付けられている第三者のドメイン名であり、
前記コンピュータ・プログラムの命令がさらに、
値を含むホスト・ヘッダと関連付けられたリクエストを受信するためのコードと、
前記ホスト・ヘッダ中の前記値が名前として認識されるか否かを判断するためのコードと、
前記ホスト・ヘッダ中の前記値が名前として認識されない場合、前記値についてＤＮＳクエリを実行するためのコードと、
前記ＤＮＳクエリに応答してＣＮＡＭＥチェーンを受信するためのコードと、
前記ＣＮＡＭＥチェーンを分析して所定のパターンが認識されるか否かを判断するためのコードと、
前記所定のパターンが認識される場合、前記所定のパターンおよび他のデータを用いてコンテンツ処理メタデータ・ファイルを捜し出すことを試みるためのコードと、
を備えることを特徴とする装置。

【請求項2】

前記コンピュータ・プログラムの命令が、
前記コンテンツ処理メタデータ・ファイルの中の情報を適用するためのコードと、
前記リクエストに応答を返すためのコードと、
をさらに含むことを特徴とする、請求項１に記載の装置。

【請求項3】

キャッシュをさらに含むことを特徴とする、請求項１に記載の装置。

【請求項4】

前記コンピュータ・プログラムの命令が、前記ＣＮＡＭＥチェーンをキャッシュして再利用するためのコードをも含むことを特徴とする、請求項１に記載の装置。

【請求項5】

前記コンピュータ・プログラムの命令が、前記コンテンツ処理メタデータ・ファイルが前記所定のパターンおよび前記他のデータからは捜し出せない場合に、エラーを返すためのコードを含むことを特徴とする、請求項１に記載の装置。

【請求項6】

前記コンピュータ・プログラム命令が、前記所定のパターンがプレフィックス値をも含むか否かを判断するためのコードをさらに含むことを特徴とする、請求項１に記載の装置。

【請求項7】

第一者により運営されるハードウェア上で実行され、第二者によって一連の第三者ドメイン名と関連付けられたマルチ・ドメイン構成（ＭＤＣ）ディジタル・プロパティを準備できるようにする、ウェブ・アクセス可能なプロビジョニング・ソフトウェアと、
第三者と関連付けられたドメイン名を受信し、受信したことに応じて、前記ドメイン名が前記ＭＤＣディジタル・プロパティと関連付けられた前記第三者ドメイン名の１つであるか否かを判断する、ハードウェア上で実行されるソフトウェア・プロセスを含む、少なくとも１つの、前記第一者により運営されるエッジ・サーバ・マシーンと、
を備え、
前記ソフトウェア・プロセスが、少なくとも１つの所定のパターンを含むＣＮＡＭＥチェーンを取得するために前記ドメインについてＤＮＳルックアップを行うことによって、前記ドメインが前記第三者ドメインの１つであるか否かを判断するものであり、
前記ウェブ・アクセス可能なプロビジョニング・ソフトウェアが、前記ＭＤＣディジタル・プロパティのための命名規則を確立するとともに、前記所定のパターンを準備するＣＮＡＭＥプロビジョニング・ツールを介して前記命名規則を施行する構成マネージャを含むことを特徴とする、システム。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は２０１１年１１月２日付け米国出願第６１／５５４，５７１号に基づき、同出願に関する優先権を主張する。

【0002】

本願は一般に、共有インフラストラクチャを使用して、複数のコンテンツ・プロバイダ・ドメインからコンテンツをオンライン配信することに関する。

【背景技術】

【0003】

分散コンピュータ・システムは周知である。このような分散コンピュータ・システムの一例として、サービス・プロバイダによって運営及び管理される「コンテンツ配信ネットワーク」又は「ＣＤＮ」がある。サービス・プロバイダは一般に、サービス・プロバイダのインフラストラクチャを使用する第三者（カスタマ）に代わってコンテンツ配信サービスを提供する。この種の分散システムは一般に、コンテンツ配信、ウェブ・アプリケーション高速化、又はアウトソースド・オリジン・サイト・インフラストラクチャのサポートのような種々のサービスを容易にするよう設計されたソフトウェア、システム、プロトコル及び技術を含め、単一の又は複数のネットワークによってリンクされた自律的コンピュータの集合を意味する。ＣＤＮサービス・プロバイダは多くの場合、カスタマ・ポータルで準備された後ネットワークに配備される（ウェブ・サイトなどの）ディジタル・プロパティを介して、サービス配信を行う。ディジタル・プロパティは、典型的には１つ以上のエッジ構成に結びつけられており、このエッジ構成によりサービス・プロバイダはトラフィックに対処し、カスタマに請求を行うことができる。

【0004】

クラウド・コンピューティングは、最小限の管理労力又はサービス・プロバイダとの協働によって迅速に準備され提供され得る、構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、プロセッシング、メモリ、ストレージ、アプリケーション、仮想マシーン、及びサービス）の共用プールへのオン・デマンドなネットワーク・アクセスを可能にするサービス配信のモデルである。全部または一部を活用し得る利用可能なサービスモデルには、サービスとしてのソフトウェア（ＳａａＳ：Software as a Service、クラウド・インフラストラクチャ上で稼動するプロバイダのアプリケーション）、サービスとしてのプラットフォーム（ＰａａＳ：Platform as a service、カスタマがプロバイダのツールを用いてアプリケーションを作成し、クラウド・インフラストラクチャ上に配備する）、サービスとしてのインフラストラクチャ（ＩａａＳ：Infrastructure as a Service、カスタマが、自身のプロセッシング、ストレージ、ネットワーク及び他のコンピューティング・リソースを割り当てて、オペレーティング・システム及びアプリケーションを配備し、稼動させることができる）がある。クラウドベースのサービスのユーザは、制御可能であり、オープンであり、且つ「従量」制により課金される、「即時オン（instant-on）、待ち時間なし（no-waiting）の、自分でできる（do-it-yourself）」体験を期待するようになっている。この使い勝手の良さによって、単一のクラウド・サービス・カスタマ（例えばウェブ・サイト・ホスティング・プロバイダ）が、数百、あるいは数千にも及ぶ第三者のディジタル・プロパティを、クラウド・プロバイダの「自分でできる」構成機構を使用して準備することができる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】米国特許第７，１１１，０５７号

【特許文献2】米国特許第７，４７２，１７８号

【特許文献3】米国特許第７，３７６，７１６号

【特許文献4】米国特許出願公開第２００４００９３４１９号

【発明の概要】

【発明が解決しようとする課題】

【0006】

クラウド・プロバイダは、ＣＤＮサービス・プロバイダを利用して、クラウド・カスタマのウェブ・サイトのパフォーマンスを、全体的により良好なものにすることを望む。しかしながら、こうしたビジネスの既存の構成モデルは連携がとれていない。なぜなら、ＣＤＮサービス・プロバイダにより使用される第二者モデル（このモデルにおいては、ＣＤＮカスタマがトラフィックに対して請求を受ける）は、クラウド・プロバイダに付随する第三者モデル（このモデルにおいては、クラウド利用はしばしば複数の第三者に及び）に容易には適応しないからである。換言すれば、クラウド・サービスを利用する種々のディジタル・プロパティは、ＣＤＮのカスタマではない。それにもかかわらず、ＣＤＮサービス・プロバイダ（及び特にそのエッジ構成）はこうした第三者のディジタル・プロパティを、ＣＤＮが適切に配信する場合には認識しておかなければならない。

【課題を解決するための手段】

【0007】

サービス・プロバイダにより運営されるインターネット・インフラストラクチャである配信プラットフォームにより、特定の第三者への大規模なＨＴＴＰベースのサービス提供を可能とする。プラットフォームはこのサービスを、ＨＴＴＰサービス（ＩａａＳ，ＰａａＳ及びＳａａＳ）を特別なディジタル・プロパティとしてカプセル化する１つ以上のクラウド・プロバイダ（プラットフォーム・カスタマ）に提供する。このアプローチによれば、ＣＤＮプラットフォーム・プロバイダ（第一者）がクラウド・プロバイダ（第二者）に代わって第三者トラフィックに対してサービスすることが可能になる。

【0008】

配信プラットフォームは、インターネットでアクセス可能な場所にある複数のエッジ・サーバ・マシーンを運営する。エンドユーザ・クライアント（例えばブラウザ又は他のユーザ・エージェント）は、コンテンツを取得するべく、こうしたエッジ・サーバ・マシーンに差し向けられる。典型的には、エンドユーザ・リクエストは１つ以上のホスト・ヘッダを含むＨＴＴＰ ＧＥＴリクエストである。本開示によれば、エッジ・サーバ処理機構がＤＮＳ（ドメイン・ネーム・サービス）を利用して、未知のホスト・ヘッダを含むリクエストに対してエッジ・サーバがサービスするべきか否かを判断する。リクエストに対してサービスする前に、ホスト・ヘッダに含まれる名前が認識されないと仮定して、エッジ・サーバはホスト・ヘッダを解決し、中間応答、典型的にはエイリアス（例えばＤＮＳ正規名又は「ＣＮＡＭＥ」）のリストを取得する。エッジ・サーバは次いで、返ってきたＣＮＡＭＥリストをチェックし、オリジナル・リクエストへの応答の仕方を決定する。この機構及びたった１つのエッジ構成を使用することで、ＣＤＮサービス・プロバイダは、クラウド・プロバイダの特定第三者のトラフィックに対する即時プロビジョニングをサポートすることができる。

【0009】

以上、本発明の比較的核心的な特性のいくつかを概説した。これらの特性は単に例示のためのものとして解釈されるべきである。開示した本発明を異なる方法で適用することによって、又は本発明を以下に記載するように変更することによって、他の多くの有益な結果を達成することができる。

【0010】

本発明及びその利点をさらに完全に理解するため、ここで添付図面と関連付けて以下の記載を参照する。

【図面の簡単な説明】

【0011】

【図1】コンテンツ配信ネットワーク（ＣＤＮ）として構成された既知の分散コンピュータ・システムを説明するブロック図である。

【図2】代表的なＣＤＮエッジ・マシーンの構成を示す。

【図3】種々のディジタル・プロパティが、本明細書に記載のアプローチを用いてどのように互いに関連付けられるのかを説明する図である。

【図4】本開示の実施形態によるエッジ・サーバ処理機構における詳細な動作フローを説明する図を示す。

【発明を実施するための形態】

【0012】

図１は既知の分散コンピュータ・システムを図示しており、このシステムを（後述のように）本明細書に記載の技術により拡張することによって、最も普及しているランタイム環境に対して、また、固定回線とモバイル環境の両方の最新の機器に対して、ブロードキャスト・オーディエンスの規模でＨＤ映像をオンライン配信することのできる、単一のＨＴＴＰベース・プラットフォームを提供する。

【0013】

図１に示すような既知のシステムにおいて、分散コンピュータ・システム１００をＣＤＮとして構成し、インターネットに一連のマシーン１０２ａ〜１０２ｎが分散していると想定する。多くの場合、マシーンの多くはインターネットのエッジの近傍に、すなわちエンドユーザ・アクセス・ネットワークに又はそれに隣接して配置されたサーバである。ネットワーク・オペレーションズ・コマンド・センタ（ＮＯＣＣ）１０４は、システム中の種々のマシーンの動作を管理する。第三者のサイト、例えばウェブ・サイト１０６は、コンテンツ（例えば、ＨＴＭＬ、埋め込まれたページ・オブジェクト、ストリーミング・メディア、ソフトウェア・ダウンロード等）の配信を分散コンピュータ・システム１００に、特に「エッジ」サーバに肩代わりさせる。多くの場合、コンテンツ・プロバイダは、所与のコンテンツ・プロバイダ・ドメイン又はサブ・ドメインを（例えばＤＮＳ ＣＮＡＭＥによって）サービス・プロバイダの権限あるドメイン・ネーム・サービスにより管理されるドメインにエイリアシング処理することによってそのコンテンツ配信を肩代わりさせる。このようなコンテンツを希望するエンドユーザを分散コンピュータ・システムに差し向けることによって、より確実にかつ効率的にコンテンツを得ることができる。詳しくは図示しないが、分散コンピュータ・システムはその他のインフラストラクチャ、例えばエッジ・サーバから使用及び他のデータを収集し、そのデータを１つの領域又は一連の領域を通して集約し、これを他のバックエンド・システム１１０，１１２，１１４，及び１１６に通すことによって、モニタリング、ロギング、警告、請求書作成、管理その他の運用管理機能を容易にすることができる分散データ収集システム１０８も含むことができる。分散ネットワーク・エージェント１１８は、ネットワーク及びサーバ負荷をモニターして、ネットワーク、トラフィック、及び負荷データを、ＣＤＮの管理下にあるコンテンツ・ドメインに対して権限を持つＤＮＳクエリ処理機構１１５に提供する。分散データ伝送機構１２０を利用することによって、制御情報（例えばコンテンツを管理し、負荷平衡を容易にする等を目的とするメタデータ）をエッジ・サーバに配分することができる。

【0014】

図２に示すように、所与のマシーン２００は、１つ以上のアプリケーション２０６ａ〜２０６ｎをサポートするオペレーティング・システム・カーネル（Ｌｉｎｕｘ又は変形等）２０４を動作させるコモディティ・ハードウェア（例えばIntel Pentiumプロセッサ）２０２を含む。コンテンツ配信サービスを容易にするため、例えば所与のマシーンは典型的に、ＨＴＴＰプロキシ２０７（「グローバルホスト」又は「ゴースト」プロセスと称されることもある）、ネームサーバ２０８、ローカル・モニタリング・プロセス２１０、分散データ収集プロセス２１２等の一連のアプリケーションを実行する。ストリーミング・メディアでは、マシーンは通常、サポートされるメディア・フォーマットの要件に応じて、Windows Media Server（ＷＭＳ）又はフラッシュ・サーバ等の１つ以上のメディア・サーバを含む。

【0015】

ＣＤＮエッジ・サーバは、好ましくは構成システムを利用するエッジ・サーバに配分されている構成ファイルを利用して、好ましくはドメイン特化型、カスタマ特化型の１つ以上の広範なコンテンツ配信特性を提供するように構成されている。所与の構成ファイルは、ＸＭＬをベースとし、１つ以上の高度のコンテンツ処理特性を容易にする一連のコンテンツ処理規則及び命令を含むことが好ましい。構成ファイルは、データ伝送機構を介してＣＤＮエッジ・サーバに配信することができる。米国特許第７，１１１，０５７号は、エッジ・サーバ・コンテンツ制御情報を配信及び管理するための有用なインフラストラクチャを説明しており、これ等のエッジ・サーバ制御情報は、ＣＤＮサービス・プロバイダ自体、又は（エクストラネット等を介して）オリジン・サーバを運用するコンテンツ・プロバイダ・カスタマによって準備することができる。

【0016】

ＣＤＮは、米国特許第７，４７２，１７８号に記載されたもののような記憶サブシステムを含むことができる。この開示内容は引用により本願に含まれるものとする。

【0017】

ＣＤＮは、カスタマ・コンテンツの中間キャッシングを提供するためにサーバ・キャッシュ階層を運用することができる。このようなキャッシュ階層サブシステムの一例が米国特許第７，３７６，７１６号に記載されている。この開示内容は引用により本願に含まれるものとする。

【0018】

ＣＤＮは、米国特許出願公開第２００４００９３４１９号に記載されたように、クライアント・ブラウザ、エッジ・サーバ、及びカスタマ・オリジン・サーバ間でセキュアなコンテンツ配信を提供することができる。これに記載されたセキュアなコンテンツ配信は、一方ではクライアントとエッジ・サーバ・プロセスとの間で、他方ではエッジ・サーバ・プロセスとオリジン・サーバ・プロセスとの間でＳＳＬベースのリンクを実施する。これによって、ＳＳＬによって保護されたウェブ・ページ及び／又はそのコンポーネントを、エッジ・サーバを介して配信することができる。

【0019】

オーバーレイとしてＣＤＮリソースを用いることにより、（プライベートに管理可能な）エンタープライズ・データ・センタと第三者へのサービスとしてのソフトウェア（ＳａａＳ）プロバイダとの間の広域ネットワーク（ＷＡＮ：wide area network）高速化サービスを容易にしてもよい。

【0020】

典型的な運営においては、コンテンツ・プロバイダは、ＣＤＮによりサービスされることを望むコンテンツ・プロバイダ・ドメイン又はサブ・ドメインを特定する。ＣＤＮサービス・プロバイダは、（例えば正規名又はＣＮＡＭＥを介して）コンテンツ・プロバイダ・ドメインをエッジ・ネットワーク（ＣＤＮ）・ホスト名と関連付け、するとＣＤＮプロバイダがそのエッジ・ネットワーク・ホスト名をコンテンツ・プロバイダに提供する。コンテンツ・プロバイダのドメイン・ネームサーバは、コンテンツ・プロバイダ・ドメイン又はサブ・ドメインへのＤＮＳクエリを受信すると、エッジ・ネットワーク・ホスト名を返すことによって応答する。エッジ・ネットワーク・ホスト名はＣＤＮを指すので、ＣＤＮネーム・サービスにより解決される。そのために、ＣＤＮネーム・サービスは１つ以上のＩＰアドレスを返す。すると、リクエストを行っているクライアント・ブラウザは、そのＩＰアドレスと関連付けられているエッジ・サーバに対して（例えばＨＴＴＰ又はＨＴＴＰＳを介して）コンテンツ・リクエストを行う。このリクエストは、オリジナル・コンテンツ・プロバイダ・ドメイン又はサブ・ドメインを含むホスト・ヘッダを含んでいる。ホスト・ヘッダを有するリクエストを受信すると、エッジ・サーバはその構成ファイルをチェックして、リクエストされたコンテンツ・ドメイン又はサブ・ドメインが実際にＣＤＮによって処理されているのか否かを判断する。処理されているのであれば、エッジ・サーバは、構成に規定されているように、そのドメイン又はサブ・ドメインに対するコンテンツ処理規則及び命令を適用する。これらのコンテンツ処理規則及び命令はＸＭＬベースの「メタデータ」構成ファイル内にあってもよい。

【0021】

マルチ・ドメイン構成処理
上述のことを背景として、ここで本開示の主題について説明する。上記のように、マルチプル・ドメイン構成（ＭＤＣ又はｍｄｃ：Multiple Domain Configuration）特性によれば、（例えば、多くの場合第三者と関連付けられているか、あるいは第三者により所有されている）無限個のドメインを、（第二者と関連付けられた）単一の構成により、スケーラブルな手法でサポートすることが可能である。代表的ではあるが非限定的な実施形態において、第二者はクラウド・サービス・プロバイダであり、第一者は図１に示すような分散ネットワークを運営するＣＤＮプラットフォーム・サービス・プロバイダである。既述のとおり、エッジ・サーバ・マシーン１０２は、後述する機能をインプリメントする処理機構を提供する。

【0022】

本明細書において使用する用語の用語集は以下の通りである。

【0023】

「ＭＤＣ」という用語は、「マルチ・ドメイン構成」というサービス特性の名前を指し、これは、エッジ・サーバ構成ファイルが、ＤＮＳルックアップを実行することによって多数のホスト（及びホスト名）をサポートすることを可能にするサービスである。このＤＮＳルックアップにより、特定のリクエストにふさわしいコンテンツ処理メタデータ・ファイルをルックアップするのに用いられる実際のホスト（ホスト名）へと導かれる。

【0024】

「中間パターン」は、ホスト・ヘッダ中の未認識のホスト名が解決された結果、返ってきたＤＮＳ応答である。典型的には、中間パターンは、ある特定のフォーマット、例えばconfig_name.mdc.service.netを有する場合には、有効な応答と見做される。ここで、config_nameは、最終的にコンテンツ処理メタデータ・ファイルのルックアップに使用されることになるホスト・ヘッダ（ディジタル・プロパティ）である。

【0025】

「config_host name」は、中間応答のconfig_nameセクションを意味する。

【0026】

「ホストＣＮＡＭＥチェーン」は、ホスト・ヘッダ中のホスト名が解決された結果、返ってきたＤＮＳ応答である。

【0027】

「プロキシ・ホストＣＮＡＭＥチェーン」は、ホスト・ヘッダ中の「proxy-host」というプレフィックスと組み合わせられたホスト名の解決の結果、返ってきたＤＮＳ応答である。ＤＮＳ応答は、コンテンツ処理メタデータ・ファイルによる抽出のために利用なメタデータを含む中間ＣＮＡＭＥエイリアスを含むことができる。このＤＮＳ応答は、config_host名及び他の情報（例えばホスト名のＩＰアドレスへのマップ）を突き止めるためにＭＤＣ特性により使用されるものである。プレフィックスの使用によって、ＤＮＳレコードを変更してディジタル・プロパティ（例えばウェブ・サイト）をＣＤＮプロバイダへ、又はＣＤＮプロバイダから移動させる際のサービス妨害を防止する方法が提供される。

【0028】

上述のように、ＭＤＣは、（サイト・ホスティングを含む）ＳａａＳベースのソリューションを運営するＣＤＮカスタマがＣＤＮサービス提供を利用できるようにするとともに、ＣＤＮプロバイダが第三者トラフィックを捕捉してそのカスタマ（ＳａａＳベースのソリューションのプロバイダ）に適切に請求を行うことができるようにする。この特性は、特定のドメインを構成毎の共通ドメインに別名定義（ＣＮＡＭＥ）することしか要さないので、統合するのが容易である。後述するように、ＭＤＣによって、ＣＤＮカスタマがその構成を変更することなく、多数の独自のドメインを単一の構成ファイルにマップすることが可能となる。これにより、プロビジョニングを単純化し、認証を容易にし、さらに管理の諸経費を大幅に削減しつつユーザのパフォーマンスを向上させる。

【0029】

一般に、この技術は以下のように機能する。XYZ.comなどのＣＤＮカスタマがＭＤＣをアクティブ化すると、ＭＤＣは、XYZ.comがCust1.saas.XYZ.com，Cust2.saas.XYZ.com等の多数の独自のドメインを単一の構成ファイルにマップできるようにする。図３は本開示の多者ＩＤアサーション・アプローチを図示しており、ここで、ＣＤＮカスタマはＣＤＮサービス・プロバイダ（第一者）との間でビジネス契約を有する第二者であり、この第二者はそのカスタマ（第三者）の各々との間で個別のビジネス契約を有する。アクティブ化されると、ＣＤＮエッジ・サーバはリクエストのホスト・ヘッダ（例：www.Cust1.com）の完全な正規名（ＣＮＡＭＥ）チェーンをキャッシュし、リクエストを正しい構成ファイルに結び付ける。その後、リクエストを解決して適切なＣＤＮエッジ・サーバのネットワークＩＰアドレスを得る。次いでリクエストを処理することにより、エンドユーザに対するサービスを行う。

【0030】

図３は、本開示の多者ＩＤアサーション（ＣＮＡＭＥチェーン）アプローチを図示しており、ここで、ＣＤＮカスタマはＣＤＮサービス・プロバイダ（第一者）との間でビジネス契約を有する第二者であり、この第二者はそのカスタマ（第三者）の各々との間で個別のビジネス契約を有する。

【0031】

セキュリティの検証及びアプリケーション・オリジン・ルーティングをサポートするため、任意で、ＣＮＡＭＥチェーンのＤＮＳレコードからのラベルを構成において参照してもよい。このアプローチの長所は、クラウド・プロバイダのオリジンがこの動作を中心となって行うことを肩代わりされ、アプリケーション配信プロセス全体がより効率化されるという点である。

【0032】

こうしたアプローチは、多くの利点をもたらす。第１の利点は、管理の容易化である。この技術は、単一の構成でＣＤＮ上に無制限のドメインを配置することにより即時プロビジョニングを行うスケーラブルな手法を提供する。新たに追加されるドメインは、第二者によって追加されるものであるから、そのための追加的な構成変更は全く不要である。また、この技術によれば、エッジ・ネットワークでのセキュリティの強化がもたらされる。これは、インテリジェントなエッジ構成が、完全なＣＮＡＭＥチェーンからのデータを、簡単な信頼モデルを使用して、エッジにおけるＩＤ／セキュリティ・バインディングに利用することができ、それによってオリジンのためにセキュリティを肩代わりできるためである。この技術はまた、第二者カスタマにもより良好なパフォーマンスを提供する。インテリジェントなエッジ構成は、完全なＣＮＡＭＥチェーンからのデータをリソース・バインディング及び条件処理に利用して、全体的なパフォーマンスを向上させるとともに、オリジンを肩代わりする。

【0033】

一実施形態においては、マルチ・ドメイン構成機能はＣＤＮエッジ・ネットワークのエッジ・サーバで動作する。マルチ・ドメイン構成機能は、（エッジ・サーバでクライアント・ブラウザＧＥＴリクエストとともに受信される）未知のHostヘッダと、そこでサポートされ得る（又はされ得ない）カスタマ構成ファイルとの間のバインディングをサポートするための手段を提供する。カスタマ構成が見つからない場合には、ホスト・ヘッダ値についてＤＮＳルックアップが行われ、その結果得られたＣＮＡＭＥチェーンを分析して、（もしあれば）いずれのカスタマ構成を使用するのかを決定する。肯定的及び否定的なＤＮＳルックアップがキャッシュされてもよい。図４には、プロセスの詳細が図示されている。

【0034】

好ましくは、ＭＤＣはＤＮＳを利用して、未知のホスト・ヘッダを含むリクエストがエッジ・サーバ・ゴースト（ウェブ・プロキシ）プロセスによりサービスされるべきか否かを判断する。リクエストに対してサービスする前に、ホスト・ヘッダとのマッチがサーバの構成ファイル中には見つからないと仮定して、未知のホスト・ヘッダを解決する。プロセスは次いで、返ってきたＣＮＡＭＥリストを調べ、リクエストがサービスされるべきか否か、及びどのようにサービスされるべきかをチェックする。以下はこのプロセスの一例である。

【0035】

カスタマ（foo.com）がそのホストを

【数1】

などの新たなＣＤＮエッジ・ドメインに別名定義（ＣＮＡＭＥ)し、次にcfg.foo.com.mdc.edgesuite.netを解決してaX.s.akamaiedge.net等のＣＤＮに固有のマップが得られると仮定する。ここで、Ｘは（ロード・バランシングのための）ＣＤＮシリアル番号割り当てであり、ｓはこのトラフィック用の任意の特別なマップである。ＣＤＮに固有のマップに用いられる専門用語は、限定的であることを意図されてはいない。なぜなら、特定のプロバイダは多くの場合異なるスキームを利用するためである。この設定によって、好ましくは動作フローは以下のようになる。まず、エンドユーザ・クライアント・マシーン（又はそれに関連付けられたローカルＤＮＳ）がwww.odddomain.comを解決してＩＰアドレスを得て、リクエストを送信する。典型的には、ＩＰアドレスは、エンドユーザに近接し、オーバーロードされておらず、所望のコンテンツをホストすることが見込まれる、特定のエッジ・サーバ・マシーン上で実行される特定のゴースト・プロセスに関連付けられている。ゴースト（ウェブ・プロキシ）プロセスはリクエストを受信し、ホスト・ヘッダを抽出する。次いで、ゴースト・プロセスは、典型的にはＸＭＬであるその構成ファイル（この例においてはarlindexと称される）中のホストをルックアップする。ホスト・ヘッダ値が見つかった場合には、通常の処理が行われる。見つからない場合には、フローは、好ましくは以下のように続行する。詳細には、ゴースト・プロセスがホスト・ヘッダ名のＤＮＳ解決を実行する。そして、返ってきたＣＮＡＭＥを２つのパターンについて調べる。まず、実施例のシナリオの下では、ゴースト・プロセスは*.mdc.edgesuite.netというパターンを探す。上述のように、このパターンはconfig_host名とも称される。次に、ゴーストはaX.s.akamaiedge.netマップ（又は別のＣＤＮ認識可能なシリアル／マップ・パターン）を探す。この時、ゴースト・プロセスは、トラフィックが有効なＣＤＮシリアル／マップにマップされていると認めれば、config_host名を用いて、関連付けられたメタデータ・ファイルについて別の構成ファイル・ルックアップを実行する。ここで、結果として得られたメタデータ・ファイルがロードされると仮定すると、ゴースト・プロセスがリクエストを通常通りに処理する（つまり、メタデータ・ファイル中の特定されたコンテンツ処理要件をリクエストされたコンテンツに適用してサービスを行う）。いかなる失敗であってもゴーストの「未知のホスト」論理がトリガされて支配権を握る。この動作は再帰的でないのが好ましい点に注意されたい。よって、構成ファイルでの２回目のルックアップが失敗すると、未知のホスト名の新たなＤＮＳ解決を試みることはない。

【0036】

上述の手順は、ＭＤＣリクエストに対する応答にいくらかの時間を加算する。これを抑えるためには、ゴースト・プロセスが肯定的及び否定的なルックアップをキャッシュするのが好ましい。肯定的なルックアップは、カスタマのネームサーバから返ってきたＤＮＳ応答の生存時間（time-to-live：ＴＴＬ）に従ってキャッシュされてもよい。好ましくは、否定的な（ＮＸ）応答は、デフォルトで所与の時間（例えば３０分）キャッシュされる。タイムアウトなどのエラー応答はキャッシュされないのが好ましい。肯定的な応答については、メタデータのルックアップに使用されるホスト名（及びＣＮＡＭＥエイリアス）がキャッシュされるのが好ましい。このために、専用のキャッシュを用いてもよい。

【0037】

このフローは、カスタマにとっては極めて柔軟性のあるものである。なぜなら、ＣＤＮがサービスされるホスト名をあらかじめ知っておく必要がなく、任意の数のホスト名に容易にスケール可能であるためである。

【0038】

図４は、エッジ・サーバの論理フローの一例をより詳細に図示している。フローは、ゴーストがホスト・ヘッダを有するＨＴＴＰ ＧＥＴを受信するステップ４００で開始する。ステップ４０２において、ゴーストはテストを行い、ホスト・ヘッダがそのインデックス中に見つかるか否かを判断する。このインデックスは通常、この特定のエッジ構成（ＣＤＮカスタマのすべてを含んでいてよく、又はそのいくつかのサブセットを含んでいてもよい）によりサービスされているディジタル・プロパティのすべてを特定するホスト・ヘッダを含んでいる。ホスト・ヘッダが認識されると、ステップ４０４において通常の処理が続行し、ゴーストは認識されたドメイン（ディジタル・プロパティ）のエッジ構成をロードする。次いで、コンテンツは（エッジ構成において特定された任意のコンテンツ処理要件を適用した後で）普通の方法でサービスされる。しかしながら、ステップ４０２におけるテストの結果が、ＧＥＴリクエスト中のホスト・ヘッダが認識されないことを示す場合には、ルーチンはステップ４１０へと分岐し、ゴーストがそのホスト・ヘッダのキャッシュをチェックして、以前にこのホスト・ヘッダを解決したことがあるか否かを確かめる。その後ルーチンはステップ４１２において続行し、何らかのそのような結果が否定的にキャッシュされているか否かを確かめる。否定的にキャッシュされている場合には、ルーチンはステップ４０８へと分岐してＨＴＴＰ４００（不正な要求）を発し、プロセスは終了する。以前の解決結果が見つかっていて、且つステップ４１４でのテストの結果、肯定的にキャッシュされていない場合には、ルーチンはステップ４１６へと分岐して、ホスト・ヘッダ名の解決を試みる。ステップ４１６は、上述のようなＤＮＳを介した基本的な動作（未知の「ホスト・ヘッダ」の解決）である。

【0039】

ステップ４１６において、ゴーストは未知のホスト・ヘッダを解決する。この解決が長くかかりすぎないことを保証するために、ステップ４１８では、テストを行う。ステップ４１６においてタイムアウト期間内に解決される場合には、制御はステップ４２０において続行し、解決の結果（典型的には１つ以上のＣＮＡＭＥ）が中間パターンとして認識されるか否かを判断する。その結果が中間パターンとは認められない場合には、ルーチンはステップ４２２において続行し、（ステップ４１６からの）応答の中のＣＮＡＭＥがホスト・ヘッダ構成ファイル中に見つかるか否かをテストする。見つかる場合には、ルーチンはステップ４２６へと分岐し、config_host名を抽出する。ステップ４２６の後、制御はステップ４０６において続行し、抽出されたconfig_host名がエッジ・サーバのホスト・ヘッダ構成ファイル中に見つかるか否かを判断する。ステップ４０６におけるテストの結果が、config_host名がインデックス・ファイル中に見つかることを示す場合には、制御はステップ４０４において続行し、エッジ・サーバが任意のコンテンツ処理要件を適用して応答を出す。そうでなければ、制御はステップ４０８に進み、前述のようにＨＴＴＰ４００をもって終了する。

【0040】

ステップ４２０におけるテストの結果が、中間パターンが認識されていることを示す場合には、ゴーストはステップ４２４においてテストを実施し、（ステップ４１６で返ってきた）応答が認識されたシリアル／マップ・パターンを有するか否かを判断する。有する場合には、制御はステップ４２６において前述のように続行する。

【0041】

ステップ４１８の結果が肯定的である場合、あるいはステップ４２２又はステップ４２４の結果が否定的である場合には、制御はステップ４２８において続行する。このステップでは、ゴーストが、proxy-hostプレフィックスを有するホスト・ヘッダ名を解決する。上述のとおり、プレフィックスの使用によって、ＤＮＳレコードを変更してディジタル・プロパティ（例えばウェブ・サイト）をＣＤＮプロバイダへ、又はＣＤＮプロバイダから移動させる際のサービス妨害を防止する方法が提供される。ステップ４２８における解決の結果は、その後一連の動作（ステップ４３０，４３４及び４３８）を経る。これらの動作は、ステップ４３０におけるタイムアウト・テストへの肯定的応答が（再帰しないために）ＨＴＴＰ５００コードを生成する点を除いて、ステップ（４１８，４２０及び４２４）における動作のミラーである。これにより処理は完了する。

【0042】

マイグレーション・オプション
多くの場合、カスタマが別のプロバイダを利用しているときには、いくつかのＭＤＣマイグレーション・オプション、すなわち第二者マイグレーション・オプション、及び第三者マイグレーション・オプションがある。第二者オプションとは、第二者が、別名定義（ＣＮＡＭＥ）することになる多数の第三者ウェブ・サイトに対してＤＮＳ権限を有するシナリオである。第二者がＣＤＮに別名定義（ＣＮＡＭＥ）すると、すべての第三者ウェブ・サイトが同時に移動される。第三者シナリオとは、第三者がそのホストを第二者プロバイダに別名定義（ＣＮＡＭＥ）するウェブ・サイトである場合である。

【0043】

第二者シナリオに対するソリューションは次のとおりである。まず、ホスト・ヘッダについてＤＮＳルックアップを行う。ｍｄｃサフィックスのうち１つを見つけるのに失敗したと仮定する。すると、ゴーストが、ＤＮＳルックアップにおいて戻ってきた各ＣＮＡＭＥについて、そのＣＮＡＭＥがエッジ・サーバのホスト・ヘッダ構成ファイル中に存在するか否かを判断する。ＣＮＡＭＥが実際に構成ファイル中に、且つ各ｍｄｃサフィックスについて存在する場合、ゴーストはｍｄｃサフィックスをＣＮＡＭＥに追加して、結果がホスト・ヘッダ構成ファイル中に存在するかどうかを再度チェックする。存在する場合には、この結果はｍｄｃカスタマを示す。そして、ＣＮＡＭＥ及びｍｄｃサフィックスから構成されたそのホスト名は、シリアル／マップのルックアップに用いられ、これが次いでリクエストに適用されることになる。

【0044】

以下は一例である。ＣＤＮカスタマがimages.example.comをホストし、ＣＤＮへのマイグレーションを望んでいるものと仮定する。古いＤＮＳ ＣＮＡＭＥチェーンは、例えば次のようなものである。：

【数2】

このとき、マイグレーションに基づく新しいＤＮＳ ＣＮＡＭＥチェーンは、次のようなものとなり得る。：

【数3】

古いＤＮＳ ＣＮＡＭＥチェーンにより、ゴーストはホスト・ヘッダ・インデックス中にa8.cdn.cpcloud.comを見つけ、mdc.edgesuite.netを付加して、インデックス中にa8.cdn.cpcloud.com.mdc.edgesuite.netをも見つけることができる。次いで、サーバがa8.cdn.cpcloud.com.mdc.edgesuite.netを用いてシリアル／マップを見つける。このシリアル／マップの構成は、最終的には受信されたリクエストに適用される。

【0045】

第三者マイグレーションのシナリオを容易にするためには、ｐｒｏｘｙ−ｈｏｓｔなどの特化されたプレフィックスを用いてルックアップを行う。この場合、カスタマは２つのホスト名を別名定義（ＣＮＡＭＥ）する。例えば：

【数4】

proxy-host.www.odddomain.com名がwww.odddomain.comの前に（あるいは、そのサイトがＣＤＮにエイリアスされるのが初めてである場合には同時に）別名定義（ＣＮＡＭＥ）される限りは、ゴースト・サーバ・プロセスは正しいＣＮＡＭＥチェーンを取得することになる。このようにホスト名を分離することによって、マイグレーションが容易に可能となる。一般的なプレフィックスであるproxy-hostを使用することで、マルチ・ドメイン構成であるプロキシＣＤＮプロバイダへのシームレスなマイグレーションが可能となる。

【0046】

第二者マイグレーションの場合又は第三者マイグレーションの場合のいずれでも、ＣＮＡＭＥチェーンは、キャッシュミスが起きるとオリジンに渡す必要のあるメタデータを提供するものであってよい。以下の例を検討する。：

【数5】

この例において、エッジ・サーバは、メタデータを抽出するべく、ＣＮＡＭＥチェーンにアクセスできるようにすることが望まれると仮定する。したがって、ＭＤＣキャッシュにおいて、AK_MDC_DATA等の変数が以下のように構成される（これもやはり単なる一例である）：

【数6】

すると、エッジ・サーバは次のようなメタデータを抽出し得る：

【数7】

【0047】

上述のように、ＣＤＮはキャッシュ階層内のエッジ・サーバを運営してもよく、その場合、エッジ・ゴーストは親サーバと通信するが、親サーバもウェブ・プロキシ・プロセス（ゴースト）を運営している。（このシナリオにおいては）エッジ・ゴーストが既にホスト・ヘッダ名を構成にマップする作業を行っているので、いずれの親ゴーストに対しても同じことを強制する必要はない。これを回避するために、好ましくはエッジ・ゴーストが（キャッシュ階層の親に）ヘッダの形態でconfig_host名（及びＣＮＡＭＥチェーン）を送信する。すると、親ゴーストがホスト名を抽出して、ホスト・ヘッダ中の値の代わりにそれを使用する。この種のヘッダは、以下の例が説明するように、X-Akamai-MDC-Dataとして特定されてもよい。：

【数8】

親ゴーストは動作時にまず、ホスト・ヘッダ構成ファイル中の通常の「Host:」ヘッダ・ホスト名をルックアップする。そしてこれが失敗すると、この親は、X-Akamai-MDC-Dataヘッダから抽出されたconfig_hostを使用することを試みる。この動作が失敗すると、ＨＴＴＰ４００応答コードが発せられる。

【0048】

当業者には理解されるであろうが、上述のＭＤＣアーキテクチャの性質によって、単純（だが柔軟）なフォワード・オリジン・ウェブ・リソース・バインディング・ソリューション及び単純な信頼モデルを用いたセキュアなＩＤアサーションのためのオプションが可能となる。メタデータにおけるウェブ・リソース・バインディングは、例えばＤＮＳレコード・ラベルからＣＤＮカスタマ識別属性の依存性が注入されることによって、分散スケールで強化される。このアプローチは、マネージド型の命名規則及びＤＮＳレコード・ラベルから抽出されたセキュア・トークンの両方によって、ＭＤＣアーキテクチャにおける主体間（すなわちＣＤＮ→ＣＤＮ（イントラ・プラットフォーム）、ＣＤＮ→カスタマ、及びカスタマ→第三者）の強固な信頼モデルを可能にする。

【0049】

ＭＤＣモジュールの初期設定は、制限なしに、エクストラネット・ポータル構成マネージャを使用してカスタマが行ってよい。構成マネージャは、「エッジ・ホスト名」（又はＣＮＡＭＥ）ツール及びディジタル・プロパティ・データベースと協働する。上述のように、ＭＤＣによることなく、エッジ構成はディジタル・プロパティ・バインディングの考えによるエッジ・ホスト名管理から分離される。エッジ構成がディジタル・プロパティに結び付けられると、ポータル・プロビジョニング・アプリケーションが構成ファイル（arlindex）中でこの両者の結合を符号化し、エッジ・サーバ・ゴースト・プロセスがこのファイルを使用してＨＴＴＰホスト・ヘッダと構成ファイルのマッチングを試みる。ＭＤＣのために、ＭＤＣディジタル・プロパティと呼ばれる特化されたディジタル・プロパティ・タイプが導入されるのが好ましい。ＭＤＣタイプのディジタル・プロパティが構成に結び付けられている場合には、エッジ構成ファイルはＭＤＣ能力を有する。このモジュールを購入したカスタマに対しカスタマ・ポータルは、「マルチ・ドメイン・ディジタル・プロパティ」タイプ用の改良されたユーザ・インタフェースを表示してもよい。

【0050】

単純なシナリオにおいては、customerは１つの構成を有し、ＭＤＣを介して数千もの第三者バニティＣＮＡＭＥをサポートする必要がある。構成ファイルは、既存のものであっても新しいものであってもよく、prod-domains.customer.com.xmlとなる。マルチ・ドメイン・ディジタル・プロパティ・タイプを作成する場合には、ポータルが、ＣＮＡＭＥプロビジョニング・ツールと連携して、（ＭＤＣプレフィックスを形成する）所定のラベルをＣＤＮネットワーク・ドメイン名とカスタマのディジタル・プロパティ名との間に追加的に挿入することにより、ＭＤＣエッジ・ホスト名を形成するのが好ましい。：

【数9】

このトークンにおけるセキュア・ハッシュは、不変のビジネス識別属性を使用するのが好ましい。ＣＮＡＭＥツールはこの文字列を用いてＣＮＡＭＥを作成する。これが一旦行われると、構成マネージャ・アプリケーションは構成ファイルをカスタマ・アカウントと関連付け、（エッジ・サーバへの）ネットワーク配備のために待ち行列に加える。（カスタマがそのディジタル・プロパティを権限あるエッジ・ホスト名に権威をもってマッピングすることにより、）権限あるエッジ・ホスト名は、ＣＤＮ→ＣＤＮ（イントラ・プラットフォーム）信頼モデル及びＣＤＮ→カスタマ信頼モデルの両方をインプリメントする。

【0051】

ゴースト・プロセスは、そのコントロール・ファイル、具体的にはarlindex.xmlを介してＭＤＣエンタイトルメントを信頼する。この設計代案においては、ホスト名中のハッシュの代わりに、構成マネージャが（ＭＵＩを介して）、この構成ファイルの「multi-domain config」特性エンタイトルメントを示すarlindex.xmlエントリと関連付けられたＣＮＡＭＥについて属性（flexible-host=”yes”）を設定するであろう。上記例の名前を用いると、arlindex.xmlエントリは次のようになるであろう。：

【数10】

ベーシックなＭＤＣカスタマには、カスタマ・ドメインを各構成ファイルに結び付け得る範囲、ならびに構成を転送できるオリジン・ドメインがいくつあるかについて、制約があり得る。例えば、構成マネージャは、構成ファイルごとに１つのオリジン・ドメインしか認めないかもしれない。カスタマは、必要に応じて、このモジュールをより多くの単位購入し、好ましくは各々が独自の構成ファイルを有するであろうマルチプル・オリジン・ドメインをサポートすることができる。

【0052】

好ましくは、ある構成ファイルと関連付けられたすべてのカスタマ（エッジ）ホスト名は、同じメタデータ規則を共有すべきである。

【0053】

上述のように、適切なセキュア・エッジ・ホスト名を作成する目的で、ＣＮＡＭＥツールが構成マネージャにより呼び出されるのが好ましい。このツールは、構成マネージャにより渡された文字列を用いて、すべてのカスタマのドメインをマップするＣＮＡＭＥを作成すべきである。

【0054】

好ましくは、第三者ブランドのドメイン（クラウド）又はＣＤＮカスタマ・ブランドの複数ドメインは、信頼モデルゆえに、ＣＤＮセキュア・エッジ・ホスト名に直接別名定義（ＣＮＡＭＥ）すべきでない。

【0055】

本開示は、強固なエッジ・サーバ処理機構を提供する。既述のとおり、カスタマのドメインに対するクライアント・リクエストが（ＣＤＮの権限あるＤＮＳにより）ゴースト・プロセスにマップされると、そのプロセスはまず、（そのarlindex.xml中で）ホスト・ヘッダとマッチングするもののルックアップを行う。このルックアップは失敗するものと仮定される。すると、ゴーストは受信したホスト・ヘッダについてＤＮＳルックアップを行い、例えばmdc.edgesuite.netで終わるもののような中間ＣＮＡＭＥを介してこのホスト名を解決して、有効なＣＤＮサービス・プロバイダ・ドメインが得られるか否かをチェックする。解決しない場合には、ゴーストはエラー（ＨＴＴＰ４００コード）を返すとともに、このホスト名を否定的にキャッシュする。このキャッシングにより、ゴーストが次にこのホスト名に対するリクエストに出会ったときに、（ＤＮＳルックアップを要さずに）より迅速に応答することができる。中間ＣＮＡＭＥが予期されたサフィックスを実際に有する場合には、ゴーストは返ってきたＣＮＡＭＥ（例えばcustomer.com.mdc.edgesuite.net）を使用して、所望の構成ファイルの名前 （例えばcfg.customer.com.xml）に到達できるよう、arlindex.xmlをルックアップする。さらなるチェックとして、このファイルをメタデータ・アプリケーションのために使用する前にゴーストが、内部flexible-host=”yes”属性がＣＮＡＭＥに対して設定されていることを確認してもよい。この場合、ゴーストは、将来におけるより迅速な応答のために、「ホスト名対構成ファイル」のマッピングをキャッシュする。構成マネージャがファイル命名規則を確立し、それをＣＮＡＭＥプロビジョニング・ツールを介して施行しているので、ゴースト・プロセスは、メタデータ構成ファイルの名前を、中間ＣＮＡＭＥを用いて得ることができる。ＤＮＳルックアップがタイムアウトする場合には、ゴーストは肯定的にも否定的にもこのホスト名をキャッシュすべきではなく、単にエラーを出すべきである。残りのゴースト・リクエスト処理は通常通りに続く。

【0056】

必須ではないが、ゴーストは、必要なＤＮＳルックアップを実行するために、別個の処理スレッドを使用するのが好ましい。このスレッドは速度制限されていてもよく、そうすれば、この追加的なルックアップを悪用するべく（多数の無効なホスト名を用いたリクエストを行うことにより）サービス妨害（ＤｏＳ）攻撃が開始された場合に有益である。この点については、不正なホスト名の否定的なキャッシング及び正当なホスト名の肯定的なキャッシングもまた有益である。

【0057】

上記で説明したように、中間ＣＮＡＭＥは、マルチ・ドメイン・カスタマ用の特別な合意済みのサフィックス（mdc.edgesuite.net）で終わるのが好ましい。

【0058】

代表的な実施形態においては、本発明の機能は、プロセッサにより実行されるコンピュータ・プログラム命令として、ソフトウェアの形態でインプリメントされる。

【0059】

より一般的には、本明細書に記載された技術は、一緒になって上述の機能を容易にし又は提供する、一連の１つ以上のコンピュータ関連のエンティティ（システム、マシーン、プロセス、プログラム、ライブラリ、機能など）を用いて提供される。典型的な実施形態においては、ソフトウェアが実行される代表的なマシーンは、コモディティ・ハードウェア、オペレーティング・システム、アプリケーション・ランタイム環境、及び一連のアプリケーション又はプロセス、ならびに関連データであって、所与のシステム又はサブシステムを提供するものから成る。既述の通り、機能はスタンドアロン・マシーンの形態でインプリメントされてもよいし、あるいは一連の分散されたマシーンにわたってインプリメントされてもよい。機能はサービス、例えばＳａａＳソリューションとして提供されてもよい。

【0060】

上記は本発明のいくつかの実施形態によって実行される動作の特定の順序を記載したが、代替的な実施形態では、異なる順序での動作の実行、いくつかの動作の組み合わせ、いくつかの動作の重複等があり得るから、このような順序は例示的なものであることは理解されよう。本明細書における所与の実施形態の参照は、記載する実施形態が特定の特性、構造、又は特徴を含む場合があるが、全ての実施形態がその特定の特性、構造、又は特徴を必ずしも含むものではないことを示している。

【0061】

開示した主題は、方法又はプロセスに照らして記載したが、主題の開示は本明細書における動作を実行するための装置にも関する。この装置は、必要な目的のために特別に構築してもよく、又はコンピュータに記憶したコンピュータ・プログラムによって選択的に活性化又は再構成される汎用コンピュータを含んでもよい。そのようなコンピュータ・プログラムは、限定ではないが、光ディスク、ＣＤ−ＲＯＭ、及び光磁気ディスクを含むいずれかのタイプのディスク、読み出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気もしくは光カード、又は電子命令の記憶に適したいずれかのタイプの媒体等のコンピュータ読み取り可能記憶媒体に記憶することができ、その各々はコンピュータ・システム・バスに結合される。システムの所与のコンポーネントを別個に記載したが、それらの機能のいくつかは、所与の命令、プログラム・シーケンス、コード部分等において組み合わせるか共有することが可能であることは当業者には認められよう。

【0062】

これは限定ではないが、特定の機能の一部はオペレーティング・システム等に内蔵できるから、機能はアプリケーション層ソリューションの形態でインプリメントされるのが好ましい。

【0063】

機能は、ＨＴＴＰＳなどの、ＨＴＴＰ以外の他のアプリケーション層プロトコル、又は類似の動作特性を有する他のプロトコルによってインプリメントされてもよい。

【0064】

接続のクライアント側又はサーバ側をインプリメントし得るコンピューティング・エンティティのタイプに限定はない。いかなるコンピューティング・エンティティ（システム、マシーン、デバイス、プログラム、プロセス、ユーティリティなど）であっても、クライアント又はサーバとしての機能を果たすことができる。

【図1】

【図2】

【図3】

【図4】