JP2023517270A - リアルタイムストリーミングのフラッシュクラウド管理 - Google Patents

Abstract

【要約】リアルタイムストリーミングサービスは、着信するフラッシュクラウドイベントを予測し、そしてトラフィックがピークに達する前にイベントに応答するようにコンピューティングリソースを管理し、これにより、ストリーミングサービスのリソースが圧倒される可能性を低くする。リアルタイムストリーミングサーバの実施形態は、エンドポイントサーバクラスタからのリアルタイムコンテンツストリームにアクセスするためのマルチのステッププロセスの間に、クライアントデバイスによるアクションを検出することによって、フラッシュクラウドイベントを予測する。最初、エンドポイントサーバは、コンテンツストリームをクライアントデバイスにストリーミングするように構成された第１のコンピューティングリソースを有する。ストリーミングサーバは、クライアントデバイスがマルチのステッププロセスの第１のステップに関連付けられているアクションを実行するレートに基づいて、エンドポイントサーバでの第２のコンピューティングリソースをプロビジョニングする。第２のコンピューティングリソースは、クライアントデバイスがマルチのステッププロセスの第２のステップに関連するアクションを実行するレートに基づいて、リアルタイムコンテンツストリームをストリーミングするように構成される。【選択図】図１

Description

本出願は、一般に、リアルタイムストリーミング、特に、リアルタイムストリーミングサービスにおけるフラッシュクラウドの検出および管理に関する。

（関連出願の相互参照）
この出願は、２０２０年１月１３日に出願された米国仮特許出願第６２／９６０，５３４号の優先権を主張し、この米国特許出願は参照によりその全体が本明細書に組み込まれている。

インターネットを介したビデオコンテンツのストリーミングは、ビデオコンテンツを表示する方法として急速に人気を集めている。一般的なストリーミングサービスでは、ビデオおよび／またはオーディオのデータが、サーバのコレクションから（スマートフォン、コンピュータ、タブレット、スマートテレビの様な）電子デバイスにストリーミングされ、ユーザにより再生される。しかしながら、リアルタイムストリーミングサービスは、例えば、ストリーミングコンテンツの参加者の間、スポーツの生中継のプレイの結果に賭ける観客の間、またはライブイベントの出演者とその観客の間、に存在する自然人間の対話に影響を与えないように、十分に小の遅延で、メディアをキャプチャしてユーザのデバイスに同時にブロードキャストする。

ユーザが自然であると感じる対話が容易に得られるように、そしてそれによってユーザのリテンションおよび関与を改善するために、リアルタイムストリーミングサービスは、高品質の体験を提供しなければならない。起動レイテンシ、平均ビットレート、再バッファリングレートを含む、様々な要因が、サービスの体験の品質に影響を与える可能性がある。これらの要因の多くは、処理されるクライアントリクエストの数に関して、サービスインフラストラクチャに課せられる負荷によって、直接または間接に影響を受ける。

リアルタイムストリーミングサービスの１つの特定の課題は、ストリームにアクセスする（または「サブスクライブする」）クライアントの数の一時的な急増を処理するサービスの能力である。「フラッシュクラウド」とも呼ばれる、ストリームをリクエストするクライアントの数の突然の急増は、広範囲に渡って関心が持たれる重要なイベント（例、津波、公人の死、衣装の実際の色についての質問）の発生後に、しばしば発生する。ストリーミングメディアによってリソースに対して高い要求が発生すると、フラッシュクラウドイベントは、ストリーミングサービスを容易に圧倒してしまう可能性がある。フラッシュクラウドは、津波のように到着し、この場合、トラフィックの急増は、通常、数分以内に発生するので、着信トラフィックに適応するために、サーバには、数十秒の猶予しかない。フラッシュクラウドが、まれにしか発生せずかつ予測不可能であることを考えると、フラッシュクラウドイベントの影響を軽減する解決法は、予防的かつリアルタイムの検出メカニズムと、ストレスの影響を軽減することが出来る即時アクションの方法とを含むことが有利であろう。

インフラストラクチャベースのコンテンツ配信ネットワーク（ＣＤＮ: Content Distribution Networks、例、Akamai2、Limelight3）から、ピアツーピア（Ｐ２Ｐ）コンテンツ配信（例、Gnutella、Bittorrent）、これら両方のアプローチの長所を活用するハイブリッド解決法まで、効率的なインターネットコンテンツ配信を改善するために多くの作業が行われて来ている。これらのプラットフォームの幾つかは、大規模なフラッシュクラウドイベントを処理することができるが、これらのプラットフォームのインフラストラクチャ、組織、および解決法は、当然、サポートすることを目的とするデータの種類と使用パターンに基づいて構築される。従来、これらのシステムは、ほとんど静的コンテンツ（例、テキスト、画像）を提供して来ているが、幾つかのコンテンツは、最近ではビデオオンデマンド（ＶｏＤ）およびビデオストリーミングに移行している。しかしながら、このような非リアルタイムサービスは、ストリーミングラグ（ストリーミングされるイベントが、発生してからサブスクライバに配信されるまでの時間）に対して高い許容度を有する。

ストリームラグに対する高い許容度は、権限移譲を使用しそしてデータパスに沿ってキャッシュを配置して、サージの影響を弱めることにより、非リアルタイムサービスが、クライアントリクエストのサージを処理することを可能にする。例えば、ＣＤＮは、フラッシュイベント中にリクエストの大部分に応答可能な（通常は少数の）オブジェクトをキャッシュし、そしてフラッシュイベントの初期段階でオリジンサーバの負荷を軽減する協調キャッシュまたは動的権限移譲に依存することが出来る。しかしながら、これらの手法は、ストリームラグが、コンテンツおよび他のサブスクライバにリアルタイムで応答するまたは対話する参加者の能力を、妨げるまたは完全に無効にする、リアルタイムメディアストリームにはほとんど効果が無い。

開示された技術の様々な特徴および特徴は、図面と併せた詳細な説明の研究から、当業者にはより明らかになるであろう。技術の実施形態は、例として例示されており、図面に限定されるものではなく、同様の参照は同様の要素を示す。

ビデオコンテンツを複数のクライアントデバイスにストリーミングするためのリアルタイムストリーミングシステムを示すブロック図である。 リアルタイムストリーミングシステムの例示的なアーキテクチャモデルを示す。 リアルタイムストリームにアクセスするためにクライアントデバイスによって実行されるプロセスを示すフローチャートである。 リアルタイムストリームへの着信フラッシュクラウドを検出し、そしてフラッシュクラウドに応答するためのリソースを管理するためのプロセスを示すフローチャートである。 処理システムの一例を示すブロック図である。

図面は、例示のみを目的とした様々な実施形態を示す。当業者は、技術の原理から逸脱することなく代替の実施形態を採用することができることを認識するであろう。従って、特定の実施形態が図面により示されているが、本技術は様々に修正可能である。

インターネットの様なパケット交換ネットワークを介したメディアコンテンツのストリーミングは、様々なメディア（例、ビデオ、オーディオ）を処理する方法として急速に人気が高まっている。電子デバイス（例、スマートフォン、コンピュータ、タブレット）は、ネットワーク（例、インターネット）に接続し、そして様々なビデオおよびオーディオデータストリームをサブスクライブすることが出来る。例えば、マルチの電子デバイス（または「クライアントデバイス」）が、発信元デバイスによって生成されたビデオ通話のライブストリームをサブスクライブすることができる。別の例として、クライアントデバイスは、スポーツイベントのライブストリームをサブスクライブすることができる。

ストリーミングメディアコンテンツの人気が増大するに伴い、インターネットを介して高品質のビデオおよびオーディオストリーミングを配信するために、帯域幅と計算リソースに対するユーザからの要求も増加している。フラッシュクラウドイベントの間には、帯域幅と計算リソースに対する要求は、複雑になる。つまり、同じサーバを介して同じコンテンツストリームにアクセスしようとするクライアントデバイスの数が大幅に増加することにより、これらのサーバのストリーミング容量は圧倒されてしまう。

フラッシュクラウドイベントの間、正規のトラフィックが突然急増することにより、サーバのパフォーマンスおよび正規のユーザによるサービスへのアクセスは、低下してしまう。数学的には、フラッシュクラウドイベントは、指定された期間内の平均リクエストレートにより定義することが出来る。幾つかの場合には、フラッシュクラウドイベントは、特定のリソースのリクエストレートが指数関数的に増加する期間である。つまり、もし、期間

の1分あたりの平均リクエストレートが

の場合、もし、全ての

に対して、

の場合（ここで、

は期間の数である）、リソースはフラッシュクラウドを体験する。フラッシュクラウドイベントは、正規のリクエストによるサービスを圧倒してしまいそしてパフォーマンスを大幅に低下させてしまう。

本明細書に記載のリアルタイムストリーミングサービスの実施形態は、着信フラッシュクラウドイベントを予測し、そしてトラフィックがピークに達する前にイベントに応答するようにリソースを管理し、これにより、ストリーミングサービスに関連付けられているコンピューティングリソースが圧倒される可能性を低減させる。一般に、フラッシュクラウドイベントは、クライアントデバイスがストリームをサブスクライブする際に従うマルチのステッププロセスが、将来の潜在的なフラッシュイベントを検出するために利用することが出来るマルチの信号を提供するという観測に基づいて予測される。

幾つかの実施形態では、フラッシュクラウドイベントを予測および管理するためにリアルタイムストリーミングサービスが実行する方法は、リアルタイムストリーミングサーバの様なコンピュータシステムが、リアルタイムコンテンツストリームをストリーミングするエンドポイントサーバクラスタで、第１の量のコンピューティングリソースを構成することを含む。このコンピュータシステムは、エンドポイントサーバクラスタに接続するためのクライアントデバイスによるリクエストの第１のレートを決定する。エンドポイントに接続するためのリクエストの第１のレートが第１の閾値より大であるとの決定に応答して、このコンピュータシステムは、エンドポイントサーバクラスタで第２の量のコンピューティングリソースをプロビジョニングする。このコンピュータシステムは、エンドポイントサーバクラスタでクライアントデバイスによる制御チャネルのサブスクリプションを監視し、このサブスクリプションは、エンドポイントサーバクラスタへの接続リクエストに基づいている。このコンピュータシステムは、これらのサブスクリプションの第２のレートを決定し、そしてこの第２のレートが第２の閾値より大であるか否かを決定する。このコンピュータシステムは、この第２のレートが第２の閾値より大きいとの決定に応答して、リアルタイムコンテンツストリームが１つまたは複数のクライアントデバイスにストリーミングされるように、プロビジョニングされたコンピューティングリソースを構成する。

リアルタイムストリーミングシステムの幾つかの実施形態は、エンドポイントサーバクラスタおよびストリーミングサーバを含む。このエンドポイントサーバクラスタは、リアルタイムコンテンツストリームをクライアントデバイスにストリーミングするように構成された第１の量のコンピューティングリソースを含む。このエンドポイントサーバクラスタに通信可能に結合されたストリーミングサーバは、このエンドポイントサーバクラスタからのリアルタイムコンテンツストリームにアクセスするためのマルチのステッププロセスの間に、複数のクライアントデバイスによるアクションを検出する。このストリーミングサーバは、複数のクライアントデバイスがマルチのステッププロセスの第１のステップに関連付けられているアクションを実行するレートに基づいて、エンドポイントサーバクラスタで追加のコンピューティングリソースをプロビジョニングし、そして複数のクライアントデバイスが、マルチのステッププロセスの第２のステップに関連付けられているアクションを実行するレートに基づいて、リアルタイムコンテンツストリームをストリーミングする様に、プロビジョニングされたコンピューティングリソースを構成する。

以下に記載される実施形態は、当業者が実施形態を実施することを可能にし、そして実施形態を実施する最良の様式を示すために必要な情報を表す。添付の図に照らして以下の記述を読むと、当業者は、本開示の概念を理解し、そして本明細書で特に扱われていないこれらの概念の適用を認識するであろう。これらの概念および用途は、本開示および付随する実施形態の範囲内にある。

ここで開示された技術は、専用ハードウェア（例、回路）、ソフトウェアおよび／またはファームウェアで適切にプログラムされたプログラム可能な回路、または専用ハードウェアとprogram可能な回路の組み合わせを使用して具体化させることが出来る。従って、実施形態は、ビデオゲームをテストするために実行させることができる命令を有するマシン可読媒体を含むことができる。

本明細書で使用される用語の目的は、実施形態を説明することのみを目的としており、そして本開示の範囲を限定することを意図するものではない。文脈が許す場合、単数形または複数形を使用する単語は、それぞれ複数形または単数形を含むこともできる。

本明細書で使用される場合、特に明記しない限り、「処理する」、「コンピューティングする」、「計算する」、「決定する」、「表示する」、「生成する」などの用語は、コンピュータまたは同様の電子機器の動作およびプロセスを意味する。このコンピュータまたは同様の電子機器は、コンピュータのメモリまたはレジスタ内の物理（電子）量として表されるデータを操作し、そしてコンピュータのメモリまたはレジスタ内の物理（電子）量として表されるデータを、コンピュータのメモリ、レジスタ、または他のこのような格納媒体、送信、または表示デバイス内の物理量として同様に表される他のデータに変換する。

本明細書で使用される場合、「接続された」、「結合された」などの用語は、２つ以上の要素間の直接または間接の任意の接続または結合を指すことができる。要素間の結合または接続は、物理的、論理的、またはそれらの組み合わせとすることが出来る。

「実施形態（an embodiment）」または「一実施形態（one embodiment）」への言及は、記載されている特定の特徴、機能、構造、または特性が、少なくとも１つの実施形態に含まれることを意味する。このような語句の出現は、必ずしも同じ実施形態を指すわけではなく、また、必ずしも相互に排他的である代替の実施形態を指すわけでもない。

文脈上明確に別段の定めがない限り、「備える（comprise）」および「備えている（comprising）」という用語は、排他的または網羅的な意味ではなく、包括的意味で解釈されるべきである（すなわち、「・・・を備えるがこれに限定されない」という意味で）。 「に基づく」という用語は、また、排他的または網羅的な意味ではなく、包括的意味で解釈されるべきである。従って、特に断りのない限り、「に基づく」という用語は、「少なくとも部分的に、・・・に基づく」ことを意味することを意図している。

「モジュール」という用語は、ソフトウェアコンポーネント、ハードウェアコンポーネント、および／またはファームウェアコンポーネントを広く指す。モジュールは、通常、指定された入力に基づいて有用なデータまたは他の出力を生成することが出来る機能コンポーネントである。モジュールは自己完結型とすることができる。コンピュータプログラムは、１つまたは複数のモジュールを含むことができる。従って、コンピュータプログラムは、異なるタスクを完了することを担当する複数のモジュール、または複数のタスクを完了することを担当する単一のモジュールを含むことができる。

「または」という単語は、複数のアイテムのリストを参照して使用される場合、リスト内のアイテムの何れか、リスト内の全てのアイテム、およびリスト内のアイテムの任意の組み合わせの全ての解釈をカバーすることが意図されている。

本明細書に記載のプロセスの何れかで実行されるステップのシーケンスは、例示的なものである。しかしながら、物理的可能性に反しない限り、ステップは、様々なシーケンスおよび組み合わせで実行させることができる。例えば、ここで説明するプロセスにステップを追加する、またはプロセスからステップを削除することも出来るであろう。同様に、ステップを置き換えたり、並べ替えたりすることも出来るであろう。従って、プロセスの記載は制限がない（オープン－エンドである）ことが意図されている。

リアルタイムストリーミングシステム
図１は、様々な実施形態による、ビデオコンテンツを複数のクライアントデバイス１１４Ａ～１１４Ｃにストリーミングするためのリアルタイムストリーミングシステム１００を示す。このシステム１００は、インターネットの様なネットワーク１１２を介してメディアコンテンツをエンコードおよびストリーミングするように構成された１つまたは複数のストリーミングサーバ１１０を含むことができる。ストリーミングサーバ１１０は、外部ノード（例、クライアントデバイス、外部サーバ、ビデオカメラ）からメディアデータを受信することができる。ストリーミングサーバ１１０は、メディアデータをエンコードしそしてクライアントデバイス１１４に転送する。

メディアデータには、ライブビデオストリームが含まれる。一例として、ライブビデオストリームは、外部ノードによって生成させ、ストリーミングサーバ１１０によってネットワークを介して転送させ、そしてクライアントデバイス１１４のユーザが知覚できない期間内にクライアントデバイス１１４によってレンダリングさせることができる。幾つかの実施形態では、ライブビデオは、ほぼリアルタイムであるビデオを含むことができる。ライブビデオは、ライブビデオを見ているユーザがライブビデオと自然に対話し、そしてライブビデオに応答することができるように、クライアントデバイスに送信させることができる。

「ライブメディアストリーム」または「リアルタイムストリーム」という用語は、広くは、イベントが発生したときにネットワーク上にあるイベントをブロードキャストすることを指す。これは、ソースデバイスが生成させ、ネットワークを介して送信され、そして受信デバイスのユーザが認識できないレイテンシ／遅延（これは、「ニアリアル」と呼ぶこともできる）で受信デバイスによってレンダリングされるコンテンツのブロードキャストを含むことができる。デバイスのユーザが認識できないこのようなレイテンシの例は、１００ミリ秒、３００ミリ秒、５００ミリ秒等を含むことが出来る。従って、クライアントデバイスのユーザは、ほぼリアルタイムで（つまり、ストリームにサブスクライブしているクライアントデバイスのユーザには認識できない遅延で）、ライブメディアストリームと対話するまたはこれに応答することが出来る。実例では、リアルタイムのストリーミングショーをサブスクライブしている参加者は、パフォーマと直接通信し、そして（例えば、スタンダップコメディショーで、多分、質問に応答して、パフォーマと対話して）パフォーマのアクションを操作することができる。別の例では、カードのリアルタイムストリームゲームのプレーヤは、カードがめくられている間に賭けをすることが出来るであろう。

一例として、スマートフォン１１４Ａは、ライブビデオ（例、ビデオキャプチャゲームプレイ、ユーザの動きをキャプチャするビデオ）を生成し、そしてこれをストリーミングサーバ１１０に送信することができる。このストリーミングサーバ１１０は、受信したライブビデオをエンコードし、そしてこのエンコードされたビデオを他のクライアントデバイス（例、ラップトップコンピュータ１１４Ｂまたはコンピュータ１１４Ｃ）に送信することが出来る。この例では、他のクライアントデバイスは、最小限のバッファリングで、ユーザが認識できない時間遅延（例、３００ミリ秒未満）で、エンコードされたライブビデオを受信することができる。この例をさらに進めると、ラップトップコンピュータ１１４Ｂは、このライブビデオを受信し、そして第２のライブビデオを生成することが出来る。この第２のライブビデオは、ストリーミングサーバ１１０に送信させることができる。ここで、このストリーミングサーバ１１０は、第２のライブビデオをエンコードし、そして（スマートフォン１１４Ａまたはコンピュータ１１４Ｃの様な）他のクライアントデバイスに送信する。この例では、ストリームをサブスクライブしたデバイスは、デバイス１１４Ａ～Ｃのユーザが知覚できない遅延／レイテンシで、ライブビデオストリームを介してインタラクティブに通信することが出来る。

ストリーミングサーバ１１０は、エンコードされたメディアストリーム（例えば、メディアストリーム１１６）をクライアントデバイス１１４に送信する。ストリームリクエスト１１８は、クライアントデバイス１１４のユーザが、エンコードされたメディアストリーム１１６をサブスクライブすることを既にリクエストしていることを示すことができる。例えば、ラップトップコンピュータ１１４Ｂのユーザは、ネットワーク１１２を介してストリーミングサーバ１１０にストリームリクエストを送信することによって、スポーツイベントのライブビデオストリームをサブスクライブすることが出来る。ストリーミングリクエストを受信すると、ストリーミングサーバ１１０は、エンコードされたビデオコンテンツをラップトップコンピュータ１１４Ｂに送信することが出来る。次で、ラップトップコンピュータ１１４Ｂは、エンコードされたビデオデータをデコードし、そしてスポーツイベントのライブビデオストリームをディスプレイに出力することが出来る。

リアルタイムストリーミングのコンテンツキャッシングの利点が限られていることと、キャッシングとバッファリングがストリームに許容できない遅延をもたらす可能性があるという事実を考えて、システム１００は、地理的に分散させたポイントオブプレゼンス（ＰｏＰ: Points of Presence）にあるサーバのコレクション（ここではデータセンタまたはクラスタと呼ばれる）を活用する。図２は、クライアントデバイス１１４、ストリームソース２０５、および様々なＰｏＰにおけるデータセンタ２１０Ａ～２１０Ｆを含む、システム１００の例示的なアーキテクチャモデルを示す。ストリームソース２０５は、コンテンツのリアルタイムストリームをキャプチャおよび／または送信するために使用されるコンピューティングデバイスであり、そして例えば、クライアントデバイス１１４の１つとすることが出来る。各データセンタ２１０内には、サーバおよび関連するコンピューティングおよびネットワーキングインフラストラクチャのコレクション（本明細書ではエンドポイントサーバクラスタとも呼ばれる）がある。これは、ストリームソース２０５からクライアントデバイス１１４にコンテンツを配信するために利用可能なコンピューティングリソースの量を表す。

進行中のストリームへのアクセスをリクエストする前に、クライアントデバイス１１４は、通常、例えば、クライアントの地理的位置に最も近いＰｏＰを選択することによって、または複数のデータセンタ２１０のそれぞれのリクエストに対する応答時間に基づいて、近くのＰｏＰを選択する。ＰｏＰが選択されると、クライアント１１４は、特定のストリームをサブスクライブするために使用される永続的な制御チャネルを設定および認証する。例として、図２は、米国南西部に位置するクライアントデバイス１１４を示す。このクライアントは、（カナダにある）データセンタ２１０Ａ、（ブラジルにある）２１０Ｂ、および（ドイツにある）２１０Ｃにリクエストを送信し、そしてこのリクエストに対する応答時間が最も短いデータセンタを選択する。

ストリーミングサーバ１１０は、変動するトラフィック負荷を処理するために、各データセンタ２１０にコンピューティングリソースの変動する量をプロビジョニングおよび構成することが出来る。一般に、ストリーミングサーバ１１０は、大量のストリーミングトラフィックを処理するために追加のコンピューティングリソースを展開し、そしてトラフィックが軽いときにはリソースの使用を減らす。例えば、コンピューティングリソースのベースライン量が、所与のデータセンタ２１０で展開される。このベースラインは、例えば、データセンタ２１０を通過するストリーミングトラフィックの中央値を処理するために必要なリソースの量によって定義される。ストリーミングサーバ１１０は、トラフィックが増加するとベースラインからコンピューティングリソースを増加させ、そしてトラフィックが減少するとコンピューティングリソースをベースラインのレベルまたはそれ以上のレベルにまで減少させる。ベースライン量は、もし、ストリーミングトラフィックが増加した場合に、予想されるストリーミングトラフィック、ベースラインリソースを維持するためのコスト、またはリソースをスケールアップするために必要なコストまたは時間のような要素間のバランスを取って、管理者が定義することが出来る。各データセンタ２１０は、量の異なるトラフィックを管理するように構成させることが出来、そしてベースラインリソースは、トラフィックパターンが変化するにつれて時間とともに増減させることが出来る。例えば、あるストリーミングサービスがオーストラリアよりも北米で人気がある場合、北米データセンタ２１０Ａが、オーストラリアデータセンタ２１０Ｆよりも通常の条件下でより多くのデータを扱う可能性が高いとの決定に基づいて、データセンタ２１０Ａを通じて利用可能なベースラインリソースを、データセンタ２１０Ｆで利用可能なリソースよりも大とすることができる。しかしながら、もし、オーストラリアでこのストリーミングサービスの人気が高まって、この地域の平均トラフィック量が増大する場合、オーストラリアのデータセンタ２１０Ｆで利用できるベースラインリソースは、これに応じて、増大させることが出来る。

リアルタイムストリームにアクセスするとき、クライアントデバイス１１４は、通常、ステップのシーケンスに従ってサーバに接続し、そしてストリームへのアクセスをリクエストする。図３は、リアルタイムストリームにアクセスするためにクライアントデバイス１１４が実行するプロセス３００を示すフローチャートである。

図３に示されるように、クライアントデバイス１１４は、ブロック３０２で領域を選択することによって、リアルタイムストリームにアクセスするプロセスを開始する。ブロック３０２は、例えば、ユーザがクライアントデバイス１１４を使用して、リアルタイムストリーミングサービスに関連付けられているウェブサイトまたはアプリケーションにアクセスする際に、実行される。幾つかの実施形態では、クライアントデバイス１１４は、複数のデータセンタ２１０のそれぞれにリクエストを送信しそして各リクエストに対するサーバ応答を待つことによって、領域を選択する。次で、クライアントデバイス１１４は、サーバ応答が最初に受信されたデータセンタ２１０を選択する。クライアントデバイス１１４は、領域を選択するために１つまたはマルチの異なるタイプのリクエストを使用することができる。例えば、インターネット制御メッセージプロトコル（ＩＣＭＰ: Internet Control Message Protocol）リクエストパケット（「ｐｉｎｇ」）を送信することは、クライアントデバイス１１４と各サーバとの間のネットワーク遅延に関する情報を提供し、他方、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴコマンドは、ネットワークレイテンシおよびアプリケーション層の応答時間の両方に関する情報を提供する。クライアントデバイス１１４は、選択されたエンドポイントとのサーバ接続を確立する。

ブロック３０４で、クライアントデバイス１１４は、制御チャネルをサブスクライブする。リアルタイムストリーミングサービスを通じて利用可能なマルチのチャネルの1つとすることができるこの制御チャネルは、メディアストリームに関連付けられているソースまたは作成者を表す。例えば、リアルタイムストリーミングサービスで利用可能な各制御チャネルは、ストリームソースと提携していて、そして1つ以上のリアルタイムストリームを特定の時間にストリーミングサービスを介して提供する。

ブロック３０６で、クライアントデバイス１１４は、ブロック３０４で選択された制御チャネルを介して利用可能な特定のストリームをサブスクライブする。ブロック３０６は、例えば、クライアントデバイス１１４のユーザが、チャネルを通じて利用可能なストリームのリストから所望のストリームを選択することに応答して、実行させることが出来る。

リアルタイムストリーミングシステムのフラッシュクラウド管理
ストリーミングサーバ１１０は、着信フラッシュクラウドを検出し、そしてクライアントがリアルタイムストリームをサブスクリプションする、定義されたプロセス内のマルチのステップの各ステップでレートを監視することによって、リソースを管理してフラッシュクラウドの影響を軽減する。一般に、フラッシュクラウドは、クライアントデバイス１１４が、リアルタイムストリームをサブスクリプションする際に、図３に関して記載されたプロセスに従う（プロセス３００の各ステップに関連付けられている動作が、着信フラッシュクラウドを示す、漸進的に強くなる信号に対応する）という観測に基づいて検出される。

図４は、リアルタイムストリームへの着信フラッシュクラウドを検出し、そしてリソースを管理して、フラッシュクラウドに応答するためのプロセス４００を示すフローチャートである。図４に示されるプロセスは、例えば、プロセッサを使用して、ストリーミングサーバ１１０に格納されたコンピュータプログラム命令を実行するプロセッサを使用することによって、ストリーミングサーバ１１０によって実行させることが出来る。プロセスの１つまたは複数のステップは、幾つかの実施形態では、データセンタ２１０内のコンピューティングデバイスの様なストリーミングサーバ１１０以外のデバイスによって実行させることができる。

図４に示されるように、ストリーミングサーバ１１０は、ブロック４０２で、クライアントデバイス１１４によって行われたエンドポイント選択を検出する。ストリーミングサーバ１１０とデータセンタ２１０のエンドポイントサーバとの構成に応じて、様々なエンドポイント選択信号が、特定のエンドポイントと通信しようとするクライアントによる試みを示すことが出来る。例えば、ストリーミングサーバ１１０は、データセンタ２１０を介してストリーミングしようとするクライアントの数の指標として、所与のデータセンタ２１０で受信されたｐｉｎｇ（ＩＣＭＰリクエストパケット）の数を測定することが出来る。ストリーミングサーバ１１０が測定することが出来る別のエンドポイント選択信号は、データセンタ２１０を介してコンテンツへのアクセスをリクエストしている、データセンタ２１０で受信されるクライアントデバイス１１４からのＨＴＴＰ ＧＥＴリクエストの数である。さらに別の例示的なエンドポイント選択信号は、伝送制御プロトコル（ＴＣＰ）接続リクエストが受信されるレート、またはＴＣＰ接続がセットアップされるレートである。ブロック４０２でエンドポイント選択を検出する際、ストリーミングサーバ１１０は、エンドポイント選択信号の何れか１つまたはこれらの信号の任意の組み合わせを監視することが出来る。

ブロック４０４で、ストリーミングサーバ１１０は、所与のエンドポイントの選択レートが閾値レートよりも大であるか否かを決定する。幾つかの実施形態では、ストリーミングサーバ１１０は、指定された期間内に、所与のエンドポイントを選択するクライアント１１４の数の変化レートに基づいて、エンドポイント選択信号によって示される、エンドポイント選択レートを測定する。例えば、ストリーミングサーバ１１０は、以下の式

（ここで、

は時間

でのエンドポイント選択の数の測定値であり、

は前回のエンドポイント選択の数の測定値であり、そして

は構成可能な重みパラメータである）により、時間

における推定負荷を計算する。管理者は、
（時間

での）過去の負荷見積もりに高い重みを与える、または時間

の現在の負荷見積もりに高い重みを与えるように、重みパラメータ

を定義することが出来る。他の実施形態では、ストリーミングサーバ１１０は、1回目のエンドポイント選択レートと２回目のエンドポイント選択レートとの間の変化に基づいて、エンドポイント選択レートを測定する。例えば、ストリーミングサーバ１１０は、時間

でのエンドポイント選択の変化レートの測定値を

として使用し、時間

でのエンドポイント選択の変化レートの測定値を

として使用して、上述の式を適用する。エンドポイント選択数の変化レートとしてであろうと、またはエンドポイント選択レートの変化としてであろうと、推定負荷を計算した後、ストリーミングサーバ１１０は、次の式：

を使用して、エンドポイント選択レートの推定移動標準偏差（ＥＭＳＤ: Estimated Moving Standard Deviation）を計算することが出来る。

ブロック４０４でエンドポイントの選択レートが閾値レートよりも大であるか否かを決定する際、ストリーミングサーバ１１０は、エンドポイント選択レートの様々な測定値の何れかをこの閾値レートと比較することが出来る。ストリーミングサーバ１１０の実施形態は、この閾値レートを、例えば、推定移動標準偏差、時間

での推定負荷、エンドポイント選択信号の値と比較する。さらに、ストリーミングサーバ１１０がエンドポイント選択レートと比較する閾値は、例えば、利用可能なリソースの量または予想されるストリームサブスクリプションに基づいて、ストリーミングシステム１００の管理者が構成することが出来るパラメータとすることが出来る。しかしながら、幾つかの場合には、閾値は、着信フラッシュクラウドを示すエンドポイント選択レートを予測するために、リアルタイムストリーミングトラフィックの過去の観測を使用して、マシン学習モデルをトレーニングすることにより、選択された値である。

もし、ストリーミングサーバ１１０が、ブロック４０４でエンドポイント選択レートが閾値よりも小さいと決定した場合、ストリーミングサーバ１１０は、閾値を超えるレートが検出されるまで、エンドポイント選択を監視し続ける。これに代えて、もし、ブロック４０４で閾値を超えた場合、ストリーミングサーバ１１０は、ブロック４０６で、エンドポイント選択レートに対して、着信ストリームリクエストを処理するために十分な量のコンピューティングリソースが現在利用可能であるか否かを決定する。例えば、ストリーミングサーバ１１０は、エンドポイントに展開されたコンテナまたは仮想マシンの数がベースライン数であるか否か、またはベースラインを超える追加のリソースが（例えば、エンドポイントを通るトラフィックの以前の増加に応答して）すでに展開されているか否かを決定する。

もし、ブロック４０６で、構成されたコンピューティングリソースが不十分であると決定された場合、ストリーミングサーバ１１０は、ブロック４０８で、追加のリソースをプロビジョニングする、またはリクエスト処理を遅くする、またはその両方を行う。リソースをプロビジョニングすることは、例えば、さらなる着信ストリーミングリクエストを処理するために、データセンタ２１０で利用可能なハードウェアに追加のコンテナまたは仮想マシンを展開することを含むことが出来る。チャネルサブスクリプションを遅くするために、ストリーミングサーバ１１０は、例えば、各リクエストまたはリクエストのサブセットに応答する前に、人為的なレイテンシを挿入する、またはリクエストのサブセットを拒否して、クライアント１１４に後で再接続を試みるよう強制することが出来る。

ブロック４０８でリソースをプロビジョニングした後、またはブロック４０６で利用可能なリソースが十分であると決定した後、ストリーミングサーバ１１０は、ブロック４１０で、エンドポイントでのチャネルサブスクリプションを監視する。ストリーミングサーバ１１０は、チャネルサブスクリプションリクエストのレート、チャネルサブスクリプションリクエストのキューの長さ、またはトランスポートセッションリクエストレートの様な、様々なチャネルサブスクリプション信号を測定することが出来る。エンドポイント選択信号と同様に、ストリーミングサーバ１１０は、１つ以上のチャネルサブスクリプション信号を個別に監視する、またはマルチのチャネルサブスクリプション信号を組み合わせてチャネルサブスクリプションのレートを決定することが出来る。

ブロック４１２で、ストリーミングサーバ１１０は、エンドポイントでの第１のチャネルのサブスクリプションのレートが閾値レートよりも大であるか否かを決定する。エンドポイント選択レートと同様に、チャネルサブスクリプションのレートは、様々な実施形態において、特定のチャネルをサブスクライブするクライアント１１４の数の変化のレート、または例えば、推定負荷および上述の推定移動標準偏差方程式を使用して、1回目のチャネルサブスクリプションのレートと2回目のチャネルサブスクリプションのレートとの間の変化として、測定させることが出来る。同様に、チャネルサブスクリプションのレートが比較される閾値は、幾つかの実施形態では、利用可能なリソースまたは予想されるストリームサブスクリプションの様な要因に基づいて管理者が設定する構成可能なパラメータである。これに代えて、閾値は、着信フラッシュクラウドを示すサブスクリプションのレートを予測するようにトレーニングされたマシン学習モデルを適用することにより、設定させることが出来る。

もし、ブロック４１２で、第１のチャネルのチャネルサブスクリプションのレートが閾値を超えると決定された場合、ストリーミングサーバ１１０は、ブロック４１４で、コンピューティングリソースが十分であるか否かを決定する。例えば、ストリーミングサーバ１１０は、第１のチャネルからのコンテンツを提供するために、現在割り当てられている仮想マシンまたはコンテナの容量を決定し、この容量を事前設定された閾値と比較して、この容量が、受信チャネルサブスクリプションリクエストレートに基づいて十分であるか否かを決定する。

もし、リソースが不十分であると決定された場合、ブロック４１６で、ストリーミングサーバ１１０は、ブロック４０８で、プロビジョニングされたリソースの一部または全てを構成する、またはサブスクリプション処理を遅くする、またはその両方を行う。リソース構成は、新たにプロビジョニングされたリソースを第１のチャネルのチャネルサーバに割り当てること、そして設定、ネットワークパラメータ、または第１のチャネルからクライアントデバイス１１４にコンテンツをストリーミングすることを可能にするリソースの他の側面、を構成することを含む。

ブロック４１６でリソースを構成した後、またはブロック４１４で利用可能なリソースが十分であると決定した後、ストリーミングサーバ１１０は、エンドポイントで特定のストリームのサブスクリプションを監視する。ストリーミングサーバ１１０によって測定されるストリームサブスクリプション信号は、例えば、ストリームサブスクリプションリクエストの到着レート、ストリームサブスクリプションリクエストキューの長さ、またはトランスポートセッションリクエストレートを含む。これらまたは他のストリームサブスクリプション信号は、ストリーミングサーバ１１０がリアルタイムストリームのサブスクリプションのレートを決定するときに、個別にまたは組み合わせて監視させることが出来る。

ブロック４２０で、ストリーミングサーバ１１０は、エンドポイントでの第１のストリームのサブスクリプションのレートが閾値レートよりも大であるか否かを決定する。第１のストリームのサブスクリプションのレートは、様々な実施形態において、第１のストリームをサブスクリプションするクライアント１１４の数の変化のレートとして、または１回目のストリームサブスクリプションのレートと２回目のストリームサブスクリプションのレートとの間の変化として、測定させることが出来る。ストリームサブスクリプションのレートが比較される閾値は、上述したエンドポイント選択およびチャネルサブスクリプションのレートに適用される閾値と同様に、管理者によって定義されたパラメータ、またはトレーニングされたマシン学習モデルを適用することによって、ストリーミングサーバ１１０によって自動的に選択された閾値とすることが出来る。

もし、第１のストリームのサブスクリプションのレートが閾値よりも大である場合、ストリーミングサーバ１１０は、ブロック４２２で、ストリーミングを処理するために現在展開されているリソースが十分であるか否かを決定する。もし、リソースが十分でない場合、ストリーミングサーバ１１０は、ブロック４２４で、リソースを調整する、サブスクリプション処理を遅くする、またはその両方を行う。リソースを調整することは、これらのリソース間のトラフィックをバランスさせそしてリアルタイムストリームのデリバリを同期させるために、新しく構成されたリソースおよび以前から存在するリソースを構成することも含むことが出来る。

プロセス４００の幾つかの実施形態では、ストリーミングサーバ１１０は、着信フラッシュクラウドが、新しいリソースを展開させることが出来るまたは各エンドポイントで利用可能な有限のリソースに対して大きすぎるであろうレートよりも速いレートで増加している時を識別するために、追加の、より高い閾値を使用する。追加の閾値は、ブロック４０４、４１２、または４２０の何れかまたは全てに適用させることが出来、そして管理者が手動で設定する、またはストリーミングサーバ１１０により自動的に設定させることが出来る。もし、エンドポイントの選択、チャネルサブスクリプション、またはストリームサブスクリプションのレートが、対応する追加の閾値を超える場合、ストリーミングサーバ１１０は、ストリームサブスクリプションの数がエンドポイントで利用可能なリソースの容量を超える可能性が高いと決定し、そして脅威が過ぎるまで新しい選択またはサブスクリプションの処理を遅くするまたは停止する手順を実装することが出来る。

プロセス４００内の様々なポイントの何れにおいても、ストリーミングサーバ１１０の実施形態は、もし、サーバ１１０が、ストリーミングトラフィックが遅くなっていることを検出した場合、不要なリソースの放棄または再利用を決定することが出来る。例えば、もし、ストリーミングサーバ１１０が、エンドポイント選択の閾値を超えるレートを検出したが、その後、フラッシュクラウドイベントは発生しなかったと決定した後に、ブロック４０８でリソースをプロビジョニングした場合、ストリーミングサーバ１１０は、プロビジョニングされたリソースを破棄することができる。あるいは、もし、ストリーミングサーバ１１０が、ストリームサブスクリプションが殺到することを管理するためにリソースを構成および調整する場合、サーバ１１０は、十分なクライアントがストリームから切断された後に、リソースを破棄または再利用することが出来る。

図４に関して説明したフラッシュイベント検出プロセスは、トラフィックがピークに達する前に、ストリーミングサーバ１１０が、着信フラッシュクラウドを検出することを可能にする。早期検出により、ストリーミングサーバ１１０は、クライアントがストリームに接続しようとする前に、トラフィックが殺到することを処理するようにコンピューティングリソースをプロビジョニングおよび構成することが出来る。従って、ストリーミングサーバ１１０によって提供されるストリーミングサービスは、フラッシュクラウドイベントに関連する、突然のトラフィック増加に対してよりロバストである。これにより、サービスが圧倒される可能性、またはストリームのリアルタイム双方向性が損なわれる可能性は、低減する。

処理システムの例
図５は、本明細書で記載される少なくとも幾つかの動作を実施することが出来る処理システムの例を示すブロック図である。この処理システムは、上述した方法／アルゴリズムの何れかを実行することができるシステムを表す処理デバイス５００とすることが出来る。例えば、エンドポイントに関連付けられているストリーミングサーバ１１０、クライアントデバイス１１４、またはコンピューティングデバイスの何れも、処理システム５００として実装させることが出来る。システムは、ネットワークまたは複数のネットワークを介して互いに結合させることができる、図５に表されるような２つ以上の処理デバイスを含むことができる。ネットワークは、通信ネットワークと呼ぶことも出来る。

図示の実施形態では、処理デバイス５００は、１つまたは複数のプロセッサ５０２、メモリ５０４、通信デバイス５０６、および１つまたは複数の入力／出力（Ｉ／Ｏ）デバイス５０８を含み、これらは、全て相互接続５１０を介して互いに結合されている。相互接続５１０は、１つまたは複数の導電性トレース、バス、ポイントツーポイント接続、コントローラ、アダプタ、および／または他の従来の接続デバイスとする、またはこれらを含むことができる。プロセッサ５０２のそれぞれは、例えば、１つまたは複数の汎用プログラマブルマイクロプロセッサまたはマイクロプロセッサコア、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、プログラマブルゲートアレイ等とする、またはこのようなデバイスの組み合わせとする、またはこれらを含むことができる。

プロセッサ５０２は、処理デバイス５００の全体的な動作を制御する。メモリ５０４は、ランダムアクセスメモリ（ＲＡＭ）、（消去可能かつプログラム可能とすることができる）読取り専用メモリ（ＲＯＭ）、フラッシュメモリ、ミニチュアハードディスクドライブ、または他の適切なタイプの格納デバイス、またはこのようなデバイスの組み合わせの形態とすることができる、１つまたは複数の物理的格納デバイスとする、またはそれらを含むことができる。メモリ５０４は、プロセッサ５０２が、上述の技術に従って動作を実行するように構成するデータおよび命令を格納することができる。通信デバイス５０６は、例えば、イーサネットアダプタ、ケーブルモデム、Ｗｉ－Ｆｉアダプタ、セルラートランシーバ、ブルートゥーストランシーバ等、またはこれらの組み合わせとする、またはこれらの組み合わせを含むことができる。処理デバイス５００の特定の性質および目的に応じて、Ｉ／Ｏデバイス５０８は、（タッチスクリーンディスプレートすることができる）ディスプレイ、オーディオスピーカ、キーボード、マウスまたは他のポインティングデバイス、マイクロフォン、カメラ等の様なデバイスを含むことが出来る。

プロセスまたはブロックは所与の順序で提示されているが、代替の実施形態は、ステップを有するルーチンを実行する、またはブロックを有するシステムを異なる順序で使用することができ、そして幾つかのプロセスまたはブロックは、削除、移動、追加、細分化、結合、および／または代替またはサブコンビネーションを提供するように変更させる、または複製させる（例、複数回実行させる）ことができる。これらのプロセスまたはブロックのそれぞれは、様々な異なる方法で実装させることができる。加えて、プロセスまたはブロックは、順次に実行されるように示される場合があるが、これに代えて、これらのプロセスまたはブロックは、並列で実行させる、または異なる時間に実行させることもできる。プロセスまたはステップが、値または計算に「基づいている」場合、プロセスまたはステップは、少なくともその値またはその計算に基づいていると解釈すべきである。

ここで紹介する技術を実装するためのソフトウェアまたはファームウェアは、マシン可読格納媒体に格納させることができ、そして1つまたは複数の汎用または専用プログラム可能なマイクロプロセッサによって実行させることができる。「マシン可読媒体」は、本明細書で使用される用語として、マシン（マシンは、例えば、コンピュータ、ネットワークデバイス、携帯電話、携帯情報端末（ＰＤＡ）、製造ツール、1つ以上のプロセッサを搭載した任意のデバイス等とすることができる）によってアクセス可能な形態で情報を格納することが出来る任意の機構を含む。例えば、マシンアクセス可能なメディアは、書込み可能／書込み不可能なメディア（例、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク格納メディア、光格納メディア、フラッシュメモリデバイス）等を含む。

上述の実施形態の何れもおよび全ては、上記とは別段の記載が可能な範囲、またはこのような実施形態が、機能および／または構造において相互に排他的となる可能性がある範囲を除いて、互いに組み合わせることが出来ることに留意されたい。本発明は、特定の例示的な実施形態を参照して説明されてきたが、本発明は、ここで説明された実施形態に限定されず、開示された実施形態の精神および範囲内で修正および変更を加えて実施できることは認識されるであろう。従って、明細書および図面は、限定的ではなく、例示的な意味で解されるべきである。

処理デバイス５００に関連付けられている物理および機能コンポーネント（例、デバイス、エンジン、モジュール、およびデータリポジトリ）は、回路、ファームウェア、ソフトウェア、他の実行可能命令、またはこれらの任意の組み合わせとして実装させることが出来る。例えば、機能コンポーネントは、1つまたは複数の、適切にプログラムされたプロセッサ、シングルボードチップ、フィールドプログラマブルゲートアレイ、実行可能命令によって構成された汎用コンピューティングデバイス、実行可能命令によって構成された仮想マシン、実行可能命令によって構成されたクラウドコンピューティング環境、またはそれらの任意の組み合わせの形で、専用回路の形により実装させることが出来る。例えば、ここで記載された機能コンポーネントは、プロセッサまたは他の集積回路チップによって実行させることが出来る有形の格納メモリ上の命令として実装させることが出来る。有形の格納メモリは、コンピュータ読取り可能なデータ格納とすることが出来る。有形格納メモリは、揮発性または不揮発性メモリとすることができる。幾つかの実施形態では、揮発性メモリは、それが一時的な信号ではないという意味で「非一時的な」と見なすことができる。図示されているメモリスペースおよび格納は、揮発性または不揮発性メモリを含む有形の格納メモリにより実装させることが出来る。

各機能コンポーネントは、他の機能コンポーネントとは独立して個別に動作することができる。一部または全ての機能コンポーネントは、同じホストデバイスまたは個別デバイスで実行させることができる。個別デバイスは、1つまたは複数の通信チャネル（例、無線または有線チャネル）を介して結合させて、それらの動作を調整させることができる。一部または全ての機能コンポーネントは、1つのコンポーネントとして組み合わせることができる。単一の機能コンポーネントは、各サブコンポーネントが、個別のメソッドステップまたは単一コンポーネントのメソッドステップを実行するサブコンポーネントに分割させることができる。

幾つかの実施形態では、機能コンポーネントのうちの少なくとも幾つかは、メモリ空間へのアクセスを共有する。例えば、ある機能コンポーネントは、別の機能コンポーネントによってアクセスまたは変換されたデータにアクセスすることができる。もし、これらの機能コンポーネントが、物理接続または仮想接続を直接または間接に共有し、ある機能コンポーネントによってアクセスまたは変更されたデータが別の機能コンポーネントによりアクセス可能となる場合、これらの機能コンポーネントは、互いに「結合」されていると見なすことができる。幾つかの実施形態では、機能コンポーネントのうちの少なくとも幾つかは、（例、機能コンポーネントの一部を実装する実行可能命令を再構成することによって）リモートでアップグレードまたは変更させることができる。上述の他のアレイ、システム、およびデバイスは、様々なアプリケーションに追加される、より少い、または異なる機能コンポーネントを含むことができる。

ここで開示された実施形態の態様は、メモリに格納されたデータビットに対する動作のアルゴリズムおよび記号表現の観点から記述させることができる。これらのアルゴリズムの説明と記号表現は、通常、目的の結果に導く動作のシーケンスを含む。これらの動作は、物理量の物理的な操作を必要とする。通常、これらの物理量は、必ずしも必須とは限らないが、保存、転送、結合、圧縮が可能な電気信号または磁気信号の形式を取る。慣習的にそして便宜上、これらの信号は、ビット、値、要素、記号、文字、用語、数字等と呼ばれる。これらのおよび類似の用語は、物理量に関連付けられていて、そしてこれらの量に適用される便利なラベルにすぎない。

実施形態は、完全に機能するコンピュータの文脈で説明されて来たが、当業者は、様々な実施形態が様々な形態のプログラム製品として配布することができ、そして当業者は、本開示が、実施形態を実際に実施するために使用されるマシンまたはコンピュータ可読媒体のタイプに関係なく、等しく適用されることを理解するであろう。

前述のことから、本発明の特定の実施形態は、例示の目的で本明細書に記載されているが、本発明の範囲から逸脱することなく様々な修正を行うことができることは、理解されるであろう。従って、本発明は、添付の特許請求の範囲による場合を除いて、限定されることはない。

Claims (20)

1. コンピュータシステムが、リアルタイムコンテンツストリームをストリーミングするために、エンドポイントサーバクラスタで第１の量のコンピューティングリソースを構成するステップ、
   前記コンピュータシステムが、前記エンドポイントサーバクラスタに接続するためのクライアントデバイスによるリクエストの第１のレートを決定するステップ、
   前記エンドポイントサーバクラスタに接続するための前記リクエストの前記第１のレートが、第１の閾値よりも大であるとの決定に応答して、前記コンピュータシステムが、前記エンドポイントサーバクラスタで第２の量のコンピューティングリソースをプロビジョニングするステップ、
   前記コンピュータシステムが、前記エンドポイントサーバクラスタで前記クライアントデバイスによる制御チャネルのサブスクリプションを監視するステップであって、前記サブスクリプションが、前記エンドポイントサーバクラスタに接続するための前記リクエストに基づいている、ステップ、
   前記コンピュータシステムが、前記エンドポイントサーバクラスタでの前記制御チャネルの前記サブスクリプションの第２のレートを決定するステップ、および
   前記制御チャネルの前記サブスクリプションの前記第２のレートが、第２の閾値よりも大であるとの決定に応答して、前記コンピュータシステムが、前記リアルタイムコンテンツストリームを１つまたは複数の前記クライアントデバイスにストリーミングするように、前記プロビジョニングされたコンピューティングリソースを構成するステップ
   を備える方法。
2. 前記クライアントデバイスによる前記リクエストの前記レートを決定するステップが、
   前記エンドポイントサーバクラスタで前記クライアントデバイスから受信されたインターネット制御メッセージプロトコル（ＩＣＭＰ）パケットの数、
   前記エンドポイントサーバクラスタで前記クライアントデバイスから受信されたハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴリクエストの数、または
   前記エンドポイントサーバクラスタで前記クライアントデバイスから受信された伝送制御プロトコル（ＴＣＰ）接続リクエストの数
   のうちの少なくとも1つに基づいて、前記エンドポイントに接続するための前記クライアントデバイスによる前記リクエストを検出するステップ
   を備える、請求項１に記載の方法。
3. 前記クライアントデバイスによる前記サブスクリプションの前記レートを決定するステップが、
   前記クライアントデバイスによる前記制御チャネルの前記サブスクリプションを監視するステップを備え、そして、
   前記制御チャネルに関連付けられているチャネルサブスクリプションリクエストのレート、
   前記制御チャネルに関連付けられているチャネルサブスクリプションリクエストキューの長さ、または
   前記制御チャネルに関連付けられているトランスポートセッションリクエストのレート
   のうちの少なくとも1つを検出するステップを備える、請求項１に記載の方法。
4. 前記コンピュータシステムが、制御チャネル上の前記リアルタイムコンテンツストリームの前記クライアントデバイスによるサブスクリプションを監視するステップ、および
   前記リアルタイムストリームの前記サブスクリプションの第３のレートが、第３の閾値よりも大であるとの決定に応答して、前記リアルタイムコンテンツストリームを前記クライアントデバイスに配信するために、前記第1の量のコンピューティングリソースと前記第２の量のコンピューティングリソースを調整するステップ、
   を更に備える、請求項１に記載の方法。
5. 前記制御チャネル上の前記リアルタイムコンテンツストリームの前記クライアントデバイスによる前記サブスクリプションを監視するステップが、
   前記リアルタイムコンテンツストリームに関連付けられているストリームサブスクリプションリクエストのレート、
   前記リアルタイムコンテンツストリームに関連付けられているストリームサブスクリプションリクエストキューの長さ、または
   前記リアルタイムコンテンツストリームに関連付けられているトランスポートセッションリクエストのレート、
   のうちの少なくとも１つを検出するステップを備える、
   請求項４に記載の方法。
6. 前記エンドポイントサーバクラスタに接続するための前記リクエストの前記第１のレートが、第３の閾値を超えているとの決定に応答して、前記エンドポイントサーバクラスタに接続するための前記リクエストの処理を遅くするステップ
   を更に備える、請求項１に記載の方法。
7. 前記制御チャネルのサブスクリプションの前記第２のレートが、第３の閾値よりも大であるとの決定に応答して、前記エンドポイントサーバクラスタをサブスクライブする前記リクエストの処理を遅くするステップ
   を更に備える、請求項１に記載の方法。
8. 実行可能なコンピュータプログラム命令を格納する非一時的コンピュータ可読格納媒体であって、プロセッサによって実行されると前記コンピュータプログラム命令が、前記プロセッサに、以下のステップ、
   エンドポイントサーバクラスタでの第１の量のコンピューティングリソースを、リアルタイムコンテンツストリームをストリーミングするように構成させるステップ、
   前記エンドポイントサーバクラスタに接続するように、クライアントデバイスによるリクエストの第１のレートを決定させるステップ、
   エンドポイントサーバクラスタに接続するための前記リクエストの前記第１のレートが、第１の閾値よりも大であるとの決定に応答して、前記エンドポイントサーバクラスタで第２の量のコンピューティングリソースをプロビジョニングさせるステップ、
   前記エンドポイントサーバクラスタでの前記クライアントデバイスによる制御チャネルのサブスクリプションを監視させるステップであって、前記サブスクリプションが、前記エンドポイントサーバクラスタに接続するための前記リクエストに基づいている、ステップ、
   前記エンドポイントサーバクラスタでの前記制御チャネルの前記サブスクリプションの第２のレートを決定させるステップ、および
   前記制御チャネルの前記サブスクリプションの前記第２のレートが、第２の閾値より大であるとの決定に応答して、前記リアルタイムコンテンツストリームを前記1つ以上のクライアントデバイスにストリーミングするために前記プロビジョニングされたコンピューティングリソースを構成させるステップ、
   を実行させる、非一時的コンピュータ可読格納媒体。
9. 前記コンピュータプログラム命令が、更に、前記プロセッサに、
   前記制御チャネル上の前記リアルタイムコンテンツストリームの前記クライアントデバイスによるサブスクリプションを監視させ、そして
   前記リアルタイムストリームの前記サブスクリプションの第３のレートが、第３の閾値より大であるとの決定に応答して、前記第1の量のコンピューティングリソースと前記第２の量のコンピューティングリソースとを調整して、前記リアルタイムコンテンツストリームを前記クライアントデバイスに配信させる、
   請求項８に記載の非一時的コンピュータ可読格納媒体。
10. 前記コンピュータプログラム命令が、更に、前記プロセッサに、
    前記エンドポイントサーバクラスタに接続するための前記リクエストの前記第１のレートが、第３の閾値を超えているとの決定に応答して、前記エンドポイントサーバクラスタに接続するための前記リクエストの処理を遅くさせる、
    請求項８に記載の非一時的コンピュータ可読格納媒体。
11. 前記コンピュータプログラム命令が、前記プロセッサに、
    前記制御チャネルのサブスクリプションの前記第２のレートが、第３の閾値よりも大であるとの決定に応答して、前記エンドポイントサーバクラスタをサブスクライブする前記リクエストの処理を遅くさせる、
    請求項８に記載の非一時的コンピュータ可読格納媒体。
12. リアルタイムコンテンツストリームをクライアントデバイスにストリーミングするように構成されている第１のコンピューティングリソースを含むエンドポイントサーバクラスタ、および
    前記エンドポイントサーバクラスタに通信可能に結合されていて、そして
    前記エンドポイントサーバクラスタからの前記リアルタイムコンテンツストリームにアクセスするためのマルチのステッププロセスの間に、複数の前記クライアントデバイスによるアクションを検出し、
    前記複数のクライアントデバイスが、前記マルチのステッププロセスの第１のステップに関連付けられているアクションを実行するレートに基づいて、前記エンドポイントサーバクラスタで前記第１のコンピューティングリソースとは異なる第２のコンピューティングリソースをプロビジョニングし、そして、
    前記複数のクライアントデバイスが、前記マルチのステッププロセスの第２のステップに関連付けられているアクションを実行するレートに基づいて、前記リアルタイムコンテンツストリームをストリーミングするように、前記エンドポイントサーバクラスタでの前記プロビジョニングされた第２のコンピューティングリソースを構成するように
    構成されているストリーミングサーバ
    を備えるリアルタイムストリーミングシステム。
13. 前記マルチのステッププロセスの前記第１のステップに関連付けられている前記アクションが、クライアントデバイスと前記エンドポイントサーバクラスタとの間の接続を確立することを備え、そして前記ストリーミングサーバが、前記複数のクライアントデバイスが実行する前記レートを、エンドポイント選択信号を使用して前記第１のステップに関連付けられている前記アクションによって、測定するように構成されている、
    請求項１２に記載の、リアルタイムストリーミングシステム。
14. 前記エンドポイント選択信号が、
    前記エンドポイントサーバクラスタで前記クライアントデバイスから受信されたインターネット制御メッセージプロトコル（ＩＣＭＰ）パケットの数、
    前記エンドポイントサーバクラスタで前記クライアントデバイスから受信されたハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴリクエストの数、または
    前記エンドポイントサーバクラスタで前記クライアントデバイスから受信された伝送制御プロトコル（ＴＣＰ）接続リクエストの数
    のうちの少なくとも１つを備える、請求項１３に記載のリアルタイムストリーミングシステム。
15. 前記マルチのステッププロセスの前記第２のステップに関連付けられている前記アクションが、制御チャネルへのアクセスをリクエストすることを備え、そして前記ストリーミングサーバが、前記複数のクライアントデバイスが実行する前記レートを、チャネルサブスクリプション信号を使用して、前記第２のステップに関連付けられているアクションによって測定するように構成されている、請求項１２に記載のリアルタイムストリーミングシステム。
16. 前記チャネルサブスクリプション信号が、
    前記制御チャネルに関連付けられているチャネルサブスクリプションリクエストのレート、
    前記制御チャネルに関連付けられているチャネルサブスクリプションリクエストキューの長さ、または
    前記制御チャネルに関連付けられているトランスポートセッションリクエストのレート
    のうちの少なくとも１つを備える、請求項１５に記載のリアルタイムストリーミングシステム。
17. 前記ストリーミングサーバが、さらに、
    前記複数のクライアントデバイスが、前記マルチのステッププロセスの第３のステップに関連付けられているアクションを実行するレートに基づいて、前記リアルタイムコンテンツストリームを１つまたは複数のクライアントデバイスに配信するために、前記第１のコンピューティングリソースと前記第２のコンピューティングリソースとを調整するように構成されている、
    請求項１２に記載のリアルタイムストリーミングシステム。
18. 前記マルチのステッププロセスの前記第３のステップに関連付けられている前記アクションが、前記リアルタイムコンテンツストリームのサブスクリプションをリクエストすることを備え、そして前記ストリーミングサーバが、前記複数のクライアントデバイスが実行する前記レートを、ストリームサブスクリプション信号を使用して前記第３のステップに関連付けられている前記アクションによって、測定するように構成されている、
    請求１７に記載のリアルタイムストリーミングシステム。
19. 前記ストリームサブスクリプション信号が、
    前記リアルタイムコンテンツストリームに関連付けられているストリームサブスクリプションリクエストのレート、
    前記リアルタイムコンテンツストリームに関連付けられているストリームサブスクリプションリクエストキューの長さ、または
    前記リアルタイムコンテンツストリームに関連付けられているトランスポートセッションリクエストのレート
    のうちの少なくとも１つを備える、
    請求項１８に記載のリアルタイムストリーミングシステム。
20. 前記ストリーミングサーバが、さらに、
    前記複数のクライアントデバイスが、前記マルチのステッププロセスの前記第１のステップに関連付けられている前記アクションを実行する前記レートが、閾値より大であるとの決定に応答して、第１のステップを実行するリクエストの処理を遅くするように構成されている、
    請求項１２に記載のリアルタイムストリーミングシステム。

Images