JP5840301B2 - 明示的または仮想化されたマシーントゥーマシンゲート（ｍ２ｍ）ウェイ要素を介して、サービス構成要素の集中的な過負荷の制御をクラウドベースで実行するためのシステムおよび方法 - Google Patents

Description

本発明は、クラウドベースシステムであって、とりわけ、分散された仮想化リソースを用いてサービス要素への集中的過負荷を制御するためのシステムの分野に属する。

ネットワークにおいて、ネットワークサービス要素が受領したすべてのプロセスを全うするための十分なリソースを得られない場合に、過負荷が発生する。該リソースは、ＣＰＵの処理能力、メモリ、ネットワーク帯域幅、ディスクリソース等が挙げられる。

あるネットワーク化されたサービス要素は、高頻度に流入するサービス要求および／または障害につながる部分的なネットワーク故障が原因で、長期的に過負荷となることがある。サービス構成要素は、音声メールサーバー、インスタントメッセージサーバー、プレゼンスサーバー、ロケーションサーバー、アドレスブックサーバー、サブスクライブプロファイルサーバー、セルフサービスキオスク、監視トリガー／インプットアグリゲーター、携帯端末起源のトラフィックアグリゲーター若しくはゲートウェイ、ポリシーサーバー、プロテクションおよびセキュリティサービスマネージャー等に限られるものではない。

集中的な過負荷は、過負荷がネットワーク若しくはサービス構成要素の一部分に集中して作用することによって引き起こされる特殊な場合である。当該部分は、電話番号やＩＰアドレスといったネットワーク目的地からスイッチングとネットワーク・サーバーの群にまで至る。

過負荷をコントロールする機能が備わっていない場合、こういった過負荷は通信ネットワークの安定性を害し、ひいてはサービスの遂行を致命的に滅殺することになりかねない。究極的には、リクエストがクライアントへのサービスの提供不能性によって喪失されてしまい、サービス構成要素が提供されないままという状態にすら陥ってしまう。しばし、過負荷にまつわる問題は自己増殖し、サービス構成要素にさらなる負荷をかけ続ける。さらに、負荷状態が続いている間は、サーバーのリソースの殆どがリジェクトおよびロードに割かれてしまうために、サーバーは本来的な機能を全うすることができず、サーバー全体のキャパシティが低下してしまう。深刻な過負荷がかかっている状態においては、一定時間に処理される情報処理量は、ごくわずかな原始的な処理能力にまで落ち込んでしまう。この現象は、混雑崩壊とよばれている。さらに、過負荷がかかっていると、サービスリクエストは遅延するか、喪失されやすくなってしまい、利用者はサービス自体を放棄してしまうか、さらにロードし、負荷をかけてしまうという状況を引き起こしがちである。

従来、集中的な過負荷をコントロールするのには、２つの方法が用いられてきた。一つは、サービスリクエスト自体を拒絶することによって、流入してくる負荷を減殺するという方法である。例えば、優先度の高いセッションや取引のみを受け付けて、他はリジェクトするという手法を講じる。だが、この手法をとると、客は欲求不満状態になり、ついにはむかむかし始めて、収益の低下を招くことになるだろう。

集中的な過負荷をコントロールするもう一つの手法は、代替のサービス構成要素へセッションや取引を移行させることである。代替サービス構成要素は、集中的な過負荷を制御する義務のある同一の機関が所持、管理している。しかしながら、この手法をとると、莫大な資産および事業費を支払う事態になるおそれがある。なぜならば、過負荷の発生およびその持続性はどちらも正確には予測できないからである。さらに、インフラを利用したサービス構成要素の過負荷の要素ベースの制御を実行するにあたっては、以下の様な欠点が挙げられる。

（ａ）費用
（ｂ）ネットワークを用いた過負荷制御要素の試験、統合にかかる時間
（ｃ）資源の最適な配置
（ｄ）リソースを移動することの柔軟性の欠如、そして、過負荷から保護されているサービス構成要素により通常は提供される、予め設計された境界特性および機能に対する、計算、通信資源の緊密なカップリング
（ｅ）システムのアップグレードおよび革新の機会が減ってしまうこと。

流動的で絶えず進化し続けているネットワークサービスを進展しようとする環境にいるサービス提供業者は、以下のことを必要としている
（ａ）投資に対する保護。すなわち、アプリケーションやサービスを作成するための別途の収益のために、速く調達することができる資源への投資
（ｂ）機敏さと柔軟性。すなわち、新しく誕生する機能およびネットワークの中にすでに存在する計算資源および通信資源を用いた機能を展開すること。

したがって、予見される設計制限に基づいて計算、通信および制御基盤開発に予算を割り当てるシステムを形成することが、ネットワーク運営者とサービスプロバイダーにとって要請される課題となる。

それが可能となると、ネットワーク要素の集中的過負荷を制御するためにギアを備え付けたり、計算用サイロを作成、設置したりする必要がなくなることが期待される。

本発明の一側面によれば、しばしば十分活用されないままになったり、可能性を十分に引き出す前に陳腐化したりする計算機器およびネットワーク機器用サイロを新しく作成、設置するよりむしろ、計算、通信および制御インフラ整備のために予算をサービスプロバイダーに割り振り可能とすることによって、上記問題を解決する。

本発明の一側面によれば、サービス構成要素の通信伝達部へのリソースのブロックを、種々のネットワーク化されたリソースから得る手段を提供する。前記リソースブロックは、共用プールに統合され、サービス構成要素の通信伝達部と通信するアプリケーションおよびサービスの全てが利用可能となる。当該サービス構成要素の通信伝達部は、サービス構成要素のリソースの割り当てを、仮想私設ネットワークリンクからの指令により決定する。サービス構成要素の媒体部分へのリソースのブロックは様々なネットワークリソースにより得られる。当該リソースのブロックは共用プールに統合され、サービス構成要素の通信伝達部を共通に利用可能である態様で提供する。前記ネットワークの媒体部分は、アプリケーションおよびサービスを持続的に供給するためにリソースブロックを使用する。この持続時間は数秒から何十、何百時間にも及ぶ。

このリソースブロックは公用、私設、若しくは共用のネットワークにより、オープンアプリケーションおよびリソースプログラミングインターフェース（以下、ＡＰＩｓ、ＲＰＩｓと呼称する）を通じて取得することができる。

図１は、集中的な過負荷を制御するサービス構成要素（ＣＯＦＯ−ＳＥ）を実行している際のモデルに対応する図面を示したものである。 図２は、より高いレベルでのクラウドベースのＣＯＦＯ−ＳＥの実行モデルを示した図である。 図３は、ＣＯＦＯ−ＳＥをクラウドベースで実行した時のより詳細な図面を示したものである。 図４は、ＣＯＦＯ−ＳＥに備えて内部若しくは外部のソース（例えば、プライベートクラウド、公共クラウド）から、如何にして資源を収集するかを示したフローチャート図である。

従来のスタンドアローン、もしくはインフラ要素基板型の、サービス構成要素への集中的過負荷からの保護手段は、集中的な計算、メモリ、そして通信リソースを要求するものであった。これらのリソースは、ネットワークインフラにより統合される必要があり、交通管理およびプライバシー、権限、セキュリティ管理の見地から、これらが調和的に作用する方法で動作させる必要がある。

結果的に、災害管理、過負荷制御のための特徴および機能をサポートする準備が整ったネットワークを完成させるのにかかる時間と、望まれている結果を首尾よく達成するためにかかるコストは莫大なものとなる。

例えば、望まれている過負荷を制御する特徴および機能をサポートするために、更なる転換および接続、制御および処理、並びに保護のためのリソースが配置、結合される必要がある。

本発明の一側面によれば、集中的な過負荷の制御を実行することにより、前述した、スタンドアローン制御の実行による欠点を回避することができる。なぜならば、スタンドアローン若しくは、インフラサービス構成要素を用いた手法のいずれにも必須であったところの、過負荷を制御するための計算、メモリおよび通信リソースの事前割り当てをする必要がなくなったからである。事前割当をする代わりに、本発明では、上記リソースは、公開されているＡＰＩやＲＰＩを介して（例として、リソースブローカーまたは交換会社を通じて）、公共、私設、若しくは公共ネットワークから得られる。

これらＡＩＰｓ、ＲＰＩｓは、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、Ｐａｒｌａｙ、
Ｐａｒｌａｙ−Ｘ，ＨＴＴＰ，ＣＯＲＢＡなどにも使用可能である。ＡＰＩやＲＰＩのデザインや輪郭などについては、本願を超えた分野である。ともあれ、これらＡＰＩ，ＲＰＩは望ましいリソースに簡単にアクセスできるだけでなく、ネットワーク、インフラ、セキュリティ、供給性、サービスの持続性その他の統合および相互運用の迅速な処理を担保する点で特筆すべきものである。何故ならば、過負荷を制御するために必要な特徴および機能は、公開されているＡＰＩｓやＲＰＩｓ、およびこれらの結合により、持続時間に応じたアプリケーションやサービスへの要求を満たすような利用可能なネットワークを選択的に探り当てることによって選ばれるからである。例えば、リアルタイムでファイアーウォールおよび暗号化キーリソースを利用可能にすることは、公共のインターネット上で企業がセキュリティ管理するリアルタイム音声通信サービスに関して、都合のいい手法となる。また、本願発明の実施により、サービスとしてのファイアーウォール（ＦＡＡＳ）に対する合法的過負荷を制御することができる。

要約すると、過負荷を制御する特徴および機能を利用する必要のある任意のアプリケーションやサービスは、公開されているＡＰＩｓやＲＰＩｓを通じて、インターネットを始めとするネットワークからリソースを入手することができ、アプリケーションやサービスは当該リソースを利用して、安全かつ信頼度の高い状態を保ったまま、セッションの継続を可能にすることを担保する。

本発明の他の側面によれば、前記の特徴および優位性を備えたシステムやコンピュータプログラムを供給することができる。

図１は、サービス構成要素に対する集中的な過負荷の制御（ＣＯＦＯ−ＳＥ）の実行に関するブロック図である。（現行の）当該保護されているサービス構成要素は、直接アプリケーション・サーバー、セッション制御構成要素、サービスゲートウェイ、その他に接続されている。サービス構成要素は、ＩＤ証明書、ヴォイスメール、ＩＭ，位置情報、存在性等、取引やセッションに応じたサービスの提供にアクセスする権限を与えるために、加入者および需要者の本人確認のリクエストを受領する。当該サービス構成要素は、サービスネームや位置情報などの予め決定された配置番号、シークレットコードや生物的情報などの証明書、および氏名、ユーザーＩＤ，マックＩＤ，ＩＰアドレス若しくは位置情報といった識別子を用いる場合もある。ユーザーまたは加入者が権限を獲得すると、サービス構成要素サーバーが、セッションや媒体のリソースを直ちに制御するとは限らない。

サービスの方針や質、およびセキュリティの面から上記の配置を行うこともありうる。サービス構成要素の通信伝達部と媒体制御部との間のインターフェースは、公開されたプロトコル（標準プロトコルともいう）、所有者プロトコルとなり、リソースのリクエストの信用を失墜しないように、インターフェースはポイントツーポイント、若しくは、ポイントツーマルチポイントの状態となる。

クラウドフレームワークの詳細は、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｋｈａｓｎａｂｉｓｈ−ｃｌｏｕｄ−ｒｅｆｅｒｅｎｃｅ−ｆｒａｍｅｗｏｒｋ−０１．ｔｘｔに記載されており、その内容は引用により本願に組み込まれる。

図２は、本発明の一つの側面における、集中的過負荷の制御の実行モデルを示す図である。実行中、負担からの保護、若しくは危機回避のためのサービス構成要素の通信伝達部および媒体部は、ネットワーク化されたリソースより入手可能となっており、必要とされた時間中、有効に使用され得る。そして、リソースは元あった場所に戻される。また、持続時間は数秒から数時間にもわたる。

当該通信伝達による過負荷制御を管理するリソースブロックは、様々なネットワークリソースから入手可能である。また、リソースブロックは、情報やサービス、所有者の情報、プロフィールサーバー、トラストキー、権限アクセス、メディアポリシー制御、過負荷危機から保護されているサービス構成要素の通信伝達部と通信しているセッション取引、コントロールサーバーを、アプリケーションやサービスを受ける者が閲覧可能なようにサービス構成要素の束へと統合され得る。

標準化されたプロファイルで開かれたプロトコルを走査させる仮想プライベートネットワークリンクを通じて命令を下すことで、サービス構成要素の通信伝達部は、セッションおよびサービス構成要素の媒体制御部より、リソースを配分する。

サービス構成要素のメディアパートを制御するリソースは、ネットワーク化されたリソースのセットから入手可能であり、要求に応じた耐久時間中、統合される。該耐久時間は、数分から何時間にもわたる。当該サービス構成要素のメディアパートのリソースブロックは、様々なネットワークリソースから入手可能であって、サービス構成要素の通信伝達部が統一して閲覧可能なように、媒体部分制御部のリソースへ一つに統合される。

図３は、内部リソースおよび外部リソースが、サービス構成要素へ集中的過負荷が加わった時にいかに費用対効果が優れている形式で利用されるかを示した図である。

図４は、ＣＯＦＯ−ＳＥに備えて内部若しくは外部のソース（例えば、私設クラウド、公共クラウド）から、如何にして資源を収集するかを示したフローチャート図である。まず、履歴の傾向および現在の資源および要求のモニタリングを考慮に入れて、次の微小期間における要求を見積もる。次に、内部からのリソースの入手可能性を見積もる。もし、内部リソースが十分に入手可能であれば、リクエストに応えるための追加リソースが満たされる。もし、内部リソースが入手不能であれば、私用若しくは公共クラウドからのリソースへとリクエストが送信される。

本願発明の方法およびシステムが、単純なコンピュータから複雑なものまでを含む機械と装置を利用して実行されることを理解すべきである。さらにいえば、上述のアーキテクチャと方法は、部分的にまたは完全に、機械読み取り可能な媒体の形に保存されることができる。たとえば、本願発明の指令は機械可読メディア（例えば磁気ディスクまたは光ディスク）に保存し得る。そして、それはディスク・ドライブ（またはコンピュータで読取り可能な中間ドライブ）によってアクセスできる。あるいは、前記指令を実行する論理はさらなるコンピュータや機械読み取り可読メディア（例えば大規模集積回路（ＬＳＩ）、特定用途向け集積回路、（ＡＳＩＣ））そして、プログラム可能で電気的に消去可能なファームウェアの読み取り専用記憶媒体（ＥＥＰＲＯＭ））で実装されることができる。特定の具体的な実行に関しては、ウェブ上の実行やコンピュータソフトウェアなどによった、機械的な実行という態様を取り得る。

以上の詳細な説明は、本発明を例示するものにすぎない。また、前述した内容は本発明の望ましい実施形態を示して説明するものであり、本発明は多様な他の組み合わせ、変更および環境で使用することができる。したがって、以上の発明の詳細な説明は開示された実施状態に本発明を制限するものではない。

Claims (16)

1. サービスの特定のリソースの要求の履歴の傾向および現在のリソースの利用傾向および要求に基づいて、見積もられるリソースの要求を決定し、
   種々のネットワークリソースからサービス構成要素の通信伝達部のためのリソースを得て、
   前記サービス構成要素の前記通信伝達部によって、仮想私設ネットワークリンクからの指示を介して、前記サービス構成要素の媒体部分からリソースの割り当てを制御し、
   前記種々のネットワークリソースから前記サービス構成要素の媒体部分のためのリソースブロックを獲得し、ここで、前記リソースブロックは共用プールへ統合され、前記サービス構成要素の前記通信伝達部が共通に利用可能である態様で提供され、
   継続時間中、アプリケーションおよびサービスに前記リソースブロックを利用し、
   前記アプリケーションおよびサービスの使用後、前記リソースを開放する方法。
2. 前記サービス構成要素は、分散され、統合されていない請求項１に記載の方法。
3. 前記仮想私設ネットワークリンクは、標準化されたプロファイルにより公開されているプロトコルを駆動させる、請求項１または請求項２に記載の方法。
4. リソースブロックは、公開されているアプリケーションおよびリソースプログラミングインターフェースを介して、公用、私設または公共ネットワークを通じて入手される請求項１〜３のいずれか一項に記載の方法。
5. 種々のネットワークリソースから入手されたリソースブロックを含む、サービス構成要素の通信伝達部と、
   前記種々のネットワークリソースから入手されたリソースブロックを含む、前記サービス構成要素の媒体部分と、
   を有し、
   前記リソースブロックは、共用プールに統合されており、前記サービス構成要素の前記通信伝達部が共通に利用可能である態様で提供されているものであって、
   前記サービス構成要素の前記通信伝達部はさらに仮想私設ネットワークリンクからの指示を介してサービス構成要素の媒体部分からリソースの割り振りを制御するように構成されており、
   アプリケーションおよびサービスのための前記リソースブロックは、継続時間中、使用され、使用後にはリソースを開放するように設計され、
   見積もられるリソースの要求がサービスの特定のリソースの要求の履歴の傾向および現在のリソースの利用傾向および要求に基づいて決定される機器。
6. 前記サービス構成要素は、分散され、統合されていない請求項５に記載の機器。
7. 前記仮想私設ネットワークリンクは、標準化されたプロファイルを用いて、公開されているプロトコルを実行する請求項５または請求項６に記載の機器。
8. 公開されているアプリケーションおよびリソースプログラミングインターフェースを通じて、公用、私設、若しくは、公共ネットワークから前記リソースブロックを調達する請求項５〜７のいずれか一項に記載の機器。
9. サービスの特定のリソースの要求の履歴の傾向および現在のリソースの利用傾向および要求に基づいて、見積もられるリソースの要求を決定する手段と、
   種々のネットワークリソースからサービス構成要素の通信伝達部のためのリソースブロックを獲得する手段と、
   前記サービス構成要素の媒体部分からリソースの割り当てを制御する手段と、
   種々のネットワークリソースからサービス構成要素の媒体部分のためのリソースブロックを獲得する手段と、前記リソースブロックは共用プールに統合され、サービス構成要素の通信伝達部が共通に利用可能である態様で提供されるものであって、
   特定の継続時間にアプリケーションおよびサービスを実行するためにリソースブロックを使用する手段と、
   を有するシステム。
10. 前記サービス構成要素は分散されており、統合されていない、請求項９に記載のシステム。
11. 前記リソースの割り当てを制御する手段は、仮想私設ネットワークリンクからの指示を介して、前記リソースの割り当てを制御し、
    前記仮想私設ネットワークリンクは、標準化されたプロファイルを用いて、公開されているプロトコルを実行する請求項９または請求項１０に記載のシステム。
12. 公開されているアプリケーションおよびリソースプログラミングインターフェースを通じて、公用、私設、または、公共ネットワークからリソースブロックを調達する請求項９〜１１のいずれか一項に記載のシステム。
13. サービスの特定のリソースの要求の履歴の傾向および現在のリソースの利用傾向および要求に基づいて、見積もられるリソースの要求を決定する指令と、
    種々のネットワークリソースからサービス構成要素の通信伝達部のためのリソースブロックを入手する指令と、
    仮想私設ネットワークリンク上の指示を通じて、サービス構成要素の媒体部分のリソースの配置を、通信伝達部のサービス構成要素により制御する指令と、
    種々のネットワークリソースからサービス構成要素の媒体部分に対応するリソースブロックを入手する指令と、ここで、前記リソースブロックは共用プールに統合され、サービス構成要素の通信伝達部が共通に利用可能である態様で提供可能なものであり、
    一定のセッション時間、または取引時間の間、アプリケーションおよびサービスのために、リソースブロックを使用する指令と、
    をコンピューターに実行させるためのコンピュータープログラム。
14. 前記サービス構成要素は分散され、統一されていない請求項１３に記載のコンピュータープログラム。
15. 前記仮想私設ネットワークリンクは、標準化されたプロファイルを用いて、公開されているプロトコルを実行する請求項１３または請求項１４に記載のコンピュータープログラム。
16. 公開されているアプリケーションおよびリソースプログラミングインターフェースを通じて、公用、私設、若しくは、公共ネットワークからリソースブロックを調達する請求項１３〜１５のいずれか一項に記載のコンピュータープログラム。