JP7466881B2 - ストリーミングデータアクセスのためのシステム、方法、及びコンピュータ可読媒体 - Google Patents

Description

本発明は、インターネット上でのデータアクセスに関し、特にインターネット上でのストリーミングデータアクセスに関するものである。

ライブストリーミングのようなインターネット上でのリアルタイムなデータアクセスでは、遅延をできる限り低く抑えることが必要となる。５００ミリ秒以下のリアルタイム遅延を実現するＷｅｂＲＴＣ（Ｗｅｂリアルタイム通信）は、市場で最も高速なプロトコルの１つである。ＷｅｂＲＴＣは、基本的に双方向のリアルタイム通信を提供するように構築されている。ＴＣＰ（伝送制御プロトコル）で構築されたＨＬＳ（ＨＴＴＰライブストリーミング）とは異なり、ＷｅｂＲＴＣは主にＵＤＰ（ユーザデータグラムプロトコル）をベースとしている。

本発明の一実施態様による方法は、１つまたは複数のコンピュータによって実行されるストリーミングデータアクセス方法であって、ストリーミングデータに対するＴＣＰリクエストを送信する工程と、識別キーを含むＴＣＰレスポンスを取得する工程と、当該識別キーによりアドレス指定可能な領域に当該ストリーミングデータに対するＵＤＰリクエストを送信する工程と、当該ストリーミングデータを取得する工程と、を含む。

本発明の一実施形態によるシステムは、１つまたは複数のプロセッサを含むストリーミングデータアクセスのためのシステムであって、当該１つまたは複数のプロセッサが、ストリーミングデータに対するＴＣＰリクエストを送信し、識別キーを含むＴＣＰレスポンスを取得して、当該識別キーによりアドレス指定可能な領域に当該ストリーミングデータに対するＵＤＰリクエストを送信し、当該ストリーミングデータを取得する動作を実行するための機械可読命令を実行する。

本発明の一実施形態によるコンピュータ可読媒体は、ストリーミングデータアクセスのためのプログラムを含む非一過性のコンピュータ可読媒体であり、当該プログラムが、１つまたは複数のコンピュータに、ストリーミングデータに対するＴＣＰリクエストを送信し、識別キーを含むＴＣＰレスポンスを取得して、当該識別キーによりアドレス指定可能な領域に当該ストリーミングデータに対するＵＤＰリクエストを送信し、当該ストリーミングデータを取得する動作を実行させる。

本発明の一実施形態による方法は、１つまたは複数のコンピュータによって実行されるストリーミングデータアクセス方法であって、ストリーミングデータに対するＴＣＰリクエストを取得する工程と、識別キーを含むＴＣＰレスポンスを返す工程と、当該識別キーによりアドレス指定可能な領域で、当該ストリーミングデータに対するＵＤＰリクエストを取得する工程と、当該ストリーミングデータを送信する工程と、を含む。

混合プロトコルでのデータアクセス動作を示すシーケンス図である。 混合プロトコルでのデータアクセス動作を示すシーケンス図である。 本発明の一部の実施態様に基づく混合プロトコルでのデータアクセス動作を示すシーケンス図である。 本発明の一部の実施態様に基づく通信システムの構成を示す概略図である。

ＴＣＰとＵＤＰは、インターネット上でデータ、つまりパケットを送信するために使用されるトランスポート層のプロトコルである。どちらのプロトコルもＩＰプロトコルを使用しており、ＴＣＰまたはＵＤＰが送信するパケットはいずれもＩＰアドレスに送信される。

ＴＣＰはコネクション型のプロトコルで、 内蔵のエラー回復と再送信を特徴としている。しかしながら、パケットの順序を変更してパケットの完全な配信を確約するための往復通信が遅延を発生させる。

ＵＤＰは、エラーチェックを省くことで、より高速な情報の流れを提供する。パケットの順序変更や再送信を行うことなく、直接相手にパケットが送信される。送信側は送信の成功を待たずにパケットを送信し続けるため、より低遅延で通信を行うことができる。ライブストリーミングのようなリアルタイムのデータアクセスにはＵＤＰを利用することが望ましい。

一部の実施態様において、混合プロトコルのデプロイメントを利用することができ、その場合、まずクライアントとサーバ間の接続確立にＴＣＰが使用され、その後データ伝送にＵＤＰが使用される。

図１に混合プロトコルでのデータアクセス動作を示す例示的シーケンスを示す。ユーザ端末１０（またはクライアント）はユーザの装置であり、当該ユーザは、視聴者またはストリーミングする人物とすることができる。ロードバランサ５０は、ユーザ端末からのリクエストを宛先(destination)に分配する(distribute)、または導く(direct)ように構成され、当該宛先はインターネット上のサーバまたはサーバ内の領域とすることができる。ポッド６０は、クラスタ内のサーバ（プルエッジサーバなど）の領域または仮想マシンであり、当該クラスタは例えばＫｕｂｅｒｎｅｔｅｓクラスタとすることができる。オリジンサーバ７０は、アクセスに供するデータを格納するように構成されたサーバである。

工程Ｓ１００において、ユーザ端末１０は、ロードバランサ５０に対して、ストリーミングデータを要求するＴＣＰリクエストを送信する。

工程Ｓ１０２において、ロードバランサ５０は、ＴＣＰリクエストをポッド６０に分配する、または導く。

工程Ｓ１０４において、ポッド６０は、ストリーミングデータが格納されているオリジンサーバ７０に対して、ストリーミングデータを要求する。

工程Ｓ１０６において、オリジンサーバ７０は、ポッド６０にストリーミングデータを提供する。

工程Ｓ１０８において、ポッド６０は、ＴＣＰレスポンスをユーザ端末１０に送信する。ＴＣＰレスポンスは、ストリーミングデータに関連するＳＤＰ（セッション記述プロトコル）を含んでもよい。

工程Ｓ１１０において、ユーザ端末１０は、ロードバランサ５０に対して、ストリーミングデータを要求するＵＤＰリクエストを送信する。

工程Ｓ１１２において、ロードバランサ５０は、ＵＤＰリクエストをポッド６０に分配する、または導く。

工程Ｓ１１４において、ポッド６０は、オリジンサーバ７０から提供されたストリーミングデータをユーザ端末１０に送信する。

図１のデプロイメントでは、１つのポッド（ポッド６０）しかない点に留意する。したがってこの場合、工程１１２において、ロードバランサ５０は、ストリーミングデータが提供される正しい宛先（ポッド６０）にＵＤＰリクエストを送信することができる。しかし、デプロイメントに複数のポッドがあり、混合プロトコル（ＴＣＰとＵＤＰなど）戦略が利用される場合、ロードバランサによってＵＤＰリクエストが誤った宛先に送信される危険性がある。

図２に混合プロトコルでのデータアクセス動作を示す別の例示的シーケンスを示す。図２のデプロイメントにおいては、ポッド６２とポッド６４の２つのポッドがある。

工程Ｓ２００において、ユーザ端末１０は、ロードバランサ５０に対して、ストリーミングデータを要求するＴＣＰリクエストを送信する。

工程Ｓ２０２において、ロードバランサ５０は、ＴＣＰリクエストをポッド６２に分配する、または導く。分配は、ロードバランサ５０がどのポッドにリクエストを分配するかを判断するための所定の基準により行われてもよい。

工程Ｓ２０４において、ポッド６２は、ストリーミングデータが格納されているオリジンサーバ７０に対して、ストリーミングデータを要求する。

工程Ｓ２０６において、オリジンサーバ７０は、ポッド６２にストリーミングデータを提供する。

工程Ｓ２０８において、ポッド６２は、ＴＣＰレスポンスをユーザ端末１０に送信する。ＴＣＰレスポンスは、ストリーミングデータに関連するＳＤＰ（セッション記述プロトコル）を含んでもよい。

工程Ｓ２１０において、ユーザ端末１０は、ロードバランサ５０に対して、ストリーミングデータを要求するＵＤＰリクエストを送信する。

工程Ｓ２１２において、ロードバランサ５０は、要求されたストリーミングデータが提供されるポッド６２にＵＤＰリクエストを導くはずである。しかし、ロードバランサ５０は、以前のＴＣＰリクエストと現在のＵＤＰリクエストとを正しくマッチングまたは同期させることができないため、セッションアフィニティが正常に確立されない可能性がある。したがって、図２に示すように、要求されたストリーミングデータが存在しない誤ったポッドにＵＤＰリクエストを送信してしまう危険性がある。それにより、データアクセスを正常に完了することができなくなる。この失敗率は、デプロイメントに実装されるポッドの数が増えるにつれて増加する可能性がある。このようにＵＤＰリクエストを誤った宛先に送信してしまう問題は、Ｋｕｂｅｒｎｅｔｅｓクラスタシステムなど、さまざまなクラスタシステムにおいて、混合プロトコルを組み込んだ場合に起こり得る。一部の実施態様において、ロードバランサ５０、ポッド６２、ポッド６４、オリジンサーバ７０がＫｕｂｅｒｎｅｔｅｓクラスタシステムで実装される。

従来、ユーザ端末はポッドの位置またはアドレスに関する情報を持っていないため、ユーザ端末がクラスタ内のポッドに直接アクセスする方法も存在しない。従来、安全性の問題などの懸念から、ポッドが存在するクラスタの外部のエンティティに公知または既知のポッドのアドレス情報は存在しない。

図３に本発明の一部の実施態様に基づく混合プロトコルでのデータアクセス動作を示すシーケンスを示す。

工程Ｓ３００において、ユーザ端末１０は、ロードバランサ５０に対して、ストリーミングデータを要求するＴＣＰリクエストを送信する。

工程Ｓ３０２において、ロードバランサ５０は、ＴＣＰリクエストをポッド６２に分配する、または導く。分配は、ロードバランサ５０がどのポッドにリクエストを分配するかを判断するための所定の基準により行われてもよい。ポッド６２はＴＣＰリクエストを取得する。

工程Ｓ３０４において、ポッド６２は、ストリーミングデータが格納されているオリジンサーバ７０に対して、ストリーミングデータを要求する。

工程Ｓ３０６において、オリジンサーバ７０は、ポッド６２にストリーミングデータを提供する。

工程Ｓ３０８において、ポッド６２は、ＴＣＰレスポンスをユーザ端末１０に送信または返答する。ユーザ端末１０は、ＴＣＰレスポンスを取得する。ＴＣＰレスポンスには、ポッド６２の識別キー、またはポッド６２に対して生成された識別キーが含まれる。識別キーは、ポッド６２が存在するクラスタの外部のエンティティがポッド６２にアクセスできるように構成される。ポッド６２は、識別キーによりアドレス指定可能である。識別キーは、ポッド６２のＩＰ情報、ノード情報、ポッド情報またはポート情報を含む、またはそれらに対応するものとしてもよい。識別キーは、ＳＤＰに含まれてもよい。

工程Ｓ３１０において、ユーザ端末１０は、識別キーにより、ストリーミングデータに対するＵＤＰリクエストを直接ポッド６２に送信する。

工程Ｓ３１２において、ポッド６２はストリーミングデータをユーザ端末１０に送信する。これにより、ユーザ端末１０は、ストリーミングデータを正常に取得する。

本実施形態においては、クラスタ内のポッドに対して、識別キーが作成される。当該識別キーは、ＴＣＰレスポンスにおいてクラスタ外部のユーザ端末に送信される。その後、ユーザ端末は識別キーを利用して、ロードバランサを迂回し、正しいポッドに直接ＵＤＰリクエストを送信して、ストリーミングデータにアクセスする。図３に示す例示的実施態様は、混合プロトコルのデプロイメントにおいて、誤った宛先にＵＤＰリクエストを送信する問題を効果的に解決することができる。一部の実施態様において、識別キーは、ＷｅｂＲＴＣ ＩＣＥなどのＩｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＩＣＥ）情報に対応するＩＰ情報、ノード情報、ポッド情報またはポート情報を含めることにより作成してもよい。当該ICE情報は、ＴＣＰレスポンスに含まれてもよい。

従来、アクセスされたデータがストリーミングデータやライブビデオデータでない場合、ＴＣＰリクエストとそれに続くＵＤＰが異なる宛先に送信されてもエラーにならないことがある。したがって、アクセスされたデータがストリーミングデータやライブビデオデータでなければ、混合プロトコルを実装しても、領域（Ｋｕｂｅｒｎｅｔｅｓクラスタ中のポッドなど）の識別キーを作成する必要がない場合がある。

一部の実施態様において、ユーザ端末とロードバランサの間に、ＣＤＮサーバやキャッチサーバなどの追加サーバを実装してもよい。一部の実施態様において、ユーザ端末とポッドの間に、ＣＤＮサーバやキャッチサーバなどの追加サーバを実装してもよい。

一部の実施態様において、ユーザ端末は、１つまたは複数のプロセッサを含むシステムとみなすことができ、そのうち、当該１つまたは複数のプロセッサは、機械可読命令を実行して、上述したデータアクセス処理などの処理を実行する。

一部の実施態様において、ポッド、オリジンサーバ、および／またはロードバランサは、ストリーミングサービスを提供するシステムに属する。一部の実施態様において、ポッドは、ストリーミングサーバに実装される。一部の実施態様において、オリジンサーバは、ストリーミングサーバとして機能する。一部の実施態様において、ストリーミングサービスは、スマートフォンやタブレットなどのユーザ端末上で動作するアプリケーションによってアクセスすることができる。

図３に示すように、一部の実施態様において、ストリーミングデータは、工程Ｓ３０６においてオリジンサーバ７０からポッド６２に提供されなくてもよい。その代わりに、オリジンサーバ７０は、最初に工程Ｓ３０６においてポッド６２にメタデータを転送し、その後ポッド６２がＵＤＰリクエストを受信した後（例えば、工程Ｓ３１０の後）ポッド６２にストリーミングデータを提供してもよい。

図４に本発明の一部の実施態様に基づく通信システムの構成を示す概略図を示す。

通信システム１は、コンテンツを介したインタラクションを伴うライブストリーミングサービスを提供することができる。ここで言う「コンテンツ」とは、コンピュータ装置で再生可能なデジタルコンテンツを指す。つまり、通信システム１は、ユーザがオンラインで他のユーザとのリアルタイムのインタラクションに参加することを可能にする。通信システム１は、複数のユーザ端末１０と、バックエンドサーバ３０と、ストリーミングサーバ４０とを含む。ユーザ端末１０、バックエンドサーバ３０、及びストリーミングサーバ４０は、ネットワーク９０（例えばインターネットとしてもよい）を介して接続される。バックエンドサーバ３０は、ユーザ端末および／またはストリーミングサーバ４０との間のインタラクションを同期させるサーバとすることができる。一部の実施態様において、バックエンドサーバ３０は、アプリケーション（ＡＰＰ）プロバイダーのサーバとしてもよい。ストリーミングサーバ４０は、ストリーミングデータまたはビデオデータを取り扱う、または提供するためのサーバである。一部の実施態様において、バックエンドサーバ３０とストリーミングサーバ４０は、独立したサーバとしてもよい。一部の実施態様において、バックエンドサーバ３０とストリーミングサーバ４０は、１つのサーバに統合してもよい。一部の実施態様において、ユーザ端末１０は、ライブストリーミングのためのクライアント装置である。一部の実施態様において、ユーザ端末１０は、視聴者、ストリーマー、アンカー、ポッドキャスター、オーディエンス、リスナーなどと呼ばれることがある。ユーザ端末１０、バックエンドサーバ３０、及びストリーミングサーバ４０はそれぞれ情報処理装置の一例である。一部の実施態様において、ストリーミングは、ライブストリーミングまたはビデオ再生とすることができる。一部の実施態様において、ストリーミングは、オーディオストリーミングおよび／またはビデオストリーミングとすることができる。一部の実施態様において、ストリーミングは、オンラインショッピング、トークショー、タレントショー、娯楽イベント、スポーツイベント、音楽ビデオ、映画、コメディ、コンサートなどのコンテンツを含むことができる。

本発明で説明した処理及び手順は、明示的に説明したものに加えて、ソフトウェア、ハードウェア、またはそれらの任意の組み合わせにより実現することができる。例えば、本明細書で説明した処理および手順は、その処理および手順に対応するロジックを集積回路、揮発性メモリ、不揮発性メモリ、非一過性のコンピュータ可読媒体、磁気ディスクなどの媒体に実装することにより実現することができる。さらに、本明細書に記載された処理および手順は、その処理および手順に対応するコンピュータプログラムとして実現することができ、各種のコンピュータにより実行することができる。

さらに、上記実施態様で説明したシステムまたは方法は、固体記憶装置、光ディスク記憶装置、磁気ディスク記憶装置などの非一時的なコンピュータ可読媒体に格納されたプログラムに統合されてもよい。あるいは、プログラムは、インターネットを介してサーバからダウンロードされ、プロセッサにより実行されるものとしてもよい。

以上、本発明の技術的内容及び特徴を説明したが、本発明の属する技術分野において通常の知識を有する者であれば、本発明の教示及び開示から逸脱することなく、なお多くの変形及び修正を行うことができる。したがって、本発明の範囲は、既に開示された実施態様に限定されず、本発明から逸脱しない別の変形や修正を含み、特許請求の範囲に含まれる範囲である。

１ 通信システム
１０ ユーザ端末
３０ バックエンドサーバ
４０ ストリーミングサーバ
５０ ロードバランサ
６０ ポッド
６２ ポッド
６４ ポッド
７０ オリジンサーバ
９０ ネットワーク
Ｓ１００、Ｓ１０２、Ｓ１０４、Ｓ１０６、Ｓ１０８、Ｓ１１０、Ｓ１１２、Ｓ１１４ 工程
Ｓ２００、Ｓ２０２、Ｓ２０４、Ｓ２０６、Ｓ２０８、Ｓ２１０、Ｓ２１２ 工程
Ｓ３００、Ｓ３０２、Ｓ３０４、Ｓ３０６、Ｓ３０８、Ｓ３１０、Ｓ３１２ 工程

Claims (9)

1. ストリーミングデータアクセスのための方法であって、
   クラスタの外部にあるユーザ端末が、ストリーミングデータに対するＴＣＰリクエストをロードバランサに送信する工程と、
   前記ロードバランサが、クラスタ内において互いに異なるアドレスが割り当てられている複数の領域のうちの一つの選択領域に前記ＴＣＰリクエストを導く工程と、
   前記ユーザ端末が、前記選択領域から前記選択領域のアドレスを指定する識別キーを含むＴＣＰレスポンスを取得する工程と、
   前記ユーザ端末が、前記識別キーにより、前記選択領域に対して、前記ストリーミングデータに対するＵＤＰリクエストを送信する工程と、
   前記ストリーミングデータを取得する工程と、
   を含む、ストリーミングデータアクセスのための方法。
2. 前記ＵＤＰリクエストは、前記ユーザ端末から前記ロードバランサを介さずに前記選択領域に送信される、請求項１に記載のストリーミングデータアクセスのための方法。
3. 前記選択領域は、前記ＴＣＰリクエストを受信した後、前記ＵＤＰリクエストを受信する前に、オリジンサーバから前記ストリーミングデータを取得する、
   請求項１または２に記載のストリーミングデータアクセスのための方法。
4. 前記ＵＤＰリクエストが、前記選択領域に直接送信されることを特徴とする、請求項２に記載のストリーミングデータアクセスのための方法。
5. 前記クラスタは、Ｋｕｂｅｒｎｅｔｅｓクラスタであり、
   前記複数の領域の各々が、Ｋｕｂｅｒｎｅｔｅｓクラスタ内のポッドに対応することを特徴とする、請求項１に記載のストリーミングデータアクセスのための方法。
6. 前記領域に対して前記識別キーを作成する工程をさらに含む、請求項１に記載のストリーミングデータアクセスのための方法。
7. 前記識別キーが、ＩＰ情報、ノード情報、ポッド情報またはポート情報を含むことを特徴とする、請求項１に記載のストリーミングデータアクセスのための方法。
8. ストリーミングデータアクセスのためのシステムであって、１つまたは複数のプロセッサを備え、前記１つまたは複数のプロセッサが、機械可読命令を実行して、
   クラスタの外部にあるユーザ端末から、ストリーミングデータに対するＴＣＰリクエストをロードバランサに送信し、
   前記ロードバランサにより、クラスタ内において互いに異なるアドレスが割り当てられている複数の領域のうちの一つの選択領域に前記ＴＣＰリクエストを導き、
   前記ユーザ端末により、前記選択領域から前記選択領域のアドレスを指定する識別キーを含むＴＣＰレスポンスを取得し、
   前記ユーザ端末から、前記識別キーにより、前記選択アドレス指定可能な領域に対して、前記ストリーミングデータに対するＵＤＰリクエストを送信し、
   前記ストリーミングデータを取得する動作を実行するための機械可読命令を実行する、
   ストリーミングデータアクセスのためのシステム。
9. ストリーミングデータアクセスのためのプログラムを含む非一過性のコンピュータ可読媒体であって、そのうち、前記プログラムが、１つまたは複数のコンピュータに、
   クラスタの外部にあるユーザ端末から、ストリーミングデータに対するＴＣＰリクエストを送信し、
   前記ロードバランサにより、クラスタ内において互いに異なるアドレスが割り当てられている複数の領域のうちの一つの選択領域に前記ＴＣＰリクエストを導き、
   前記ユーザ端末により、前記選択領域から前記選択領域のアドレスを指定する識別キーを含むＴＣＰレスポンスを取得し、
   前記ユーザ端末から、前記識別キーにより、前記選択アドレス指定可能な領域に対して、前記ストリーミングデータに対するＵＤＰリクエストを送信し、
   前記ストリーミングデータを取得する動作を実行させる、
   コンピュータ可読媒体。