特許 7426020 キャッシュＴＴＬを決定するためのシステム、方法、及びコンピュータ可読媒体

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

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

(11)【特許番号】

(24)【登録日】2024-01-24

(45)【発行日】2024-02-01

(54)【発明の名称】キャッシュＴＴＬを決定するためのシステム、方法、及びコンピュータ可読媒体

(51)【国際特許分類】

   H04L 67/5682 20220101AFI20240125BHJP

   H04N 21/2183 20110101ALI20240125BHJP

   H04N 21/24 20110101ALI20240125BHJP

【ＦＩ】

H04L67/5682

H04N21/2183

H04N21/24

【請求項の数】 20

(21)【出願番号】P 2022522346

(86)(22)【出願日】2021-09-30

(65)【公表番号】

(43)【公表日】2023-11-21

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

(87)【国際公開番号】W WO2023055364

(87)【国際公開日】2023-04-06

【審査請求日】2022-04-13

【早期審査対象出願】

(73)【特許権者】

【識別番号】517287224

【氏名又は名称】１７ＬＩＶＥ株式会社

(74)【代理人】

【識別番号】100126572

【弁理士】

【氏名又は名称】村越 智史

(72)【発明者】

【氏名】ロイ，カ チョン

(72)【発明者】

【氏名】ウー，シャオ ユアン

(72)【発明者】

【氏名】チェン，ミン－チュ

【審査官】木村 雅也

(56)【参考文献】

【文献】米国特許出願公開第２００４／０１２８３４６（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０２１／００２１５６３（ＵＳ，Ａ１）

【文献】特開平１０－０２１１３４（ＪＰ，Ａ）

【文献】中国特許出願公開第１１１５８６１９１（ＣＮ，Ａ）

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

Ｈ０４Ｌ ６７／５６８２

Ｈ０４Ｎ ２１／２１８３

Ｈ０４Ｎ ２１／２４

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

【請求項1】

キャッシュサーバ上のデータオブジェクトについてＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ、キャッシュ保持時間）を決定する方法であって、
前記データオブジェクトの更新頻度を検出する工程と、
前記データオブジェクトにアクセスするユーザ数を所定の監視タイミングで監視し、前記監視タイミングにおいて前記データオブジェクトにアクセスしているユーザ数を検出する工程と、
当該更新頻度と当該監視タイミングにおいて検出された当該ユーザ数に基づいてＴＴＬを決定する工程と、
を含むことを特徴とする、キャッシュＴＴＬを決定する方法。

【請求項2】

さらに、前記データオブジェクトにアクセスするユーザ数に基づいて最小キャッシュ保持時間（ＴＴＬｍｉｎ）を決定する工程を含み、そのうち、前記データオブジェクトにアクセスする前記ユーザ数が増加したとき、前記ＴＴＬｍｉｎがより長い時間に決定され、前記ＴＴＬが前記ＴＴＬｍｉｎ以上に決定される、ことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項3】

さらに、前記データオブジェクトの更新頻度に基づいて最大キャッシュ保持時間（ＴＴＬｍａｘ）を決定する工程を含み、そのうち、前記データオブジェクトの更新頻度が増加したとき、前記ＴＴＬｍａｘが短い時間に設定され、前記ＴＴＬが前記ＴＴＬｍａｘ以下に決定される、ことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項4】

さらに、前記データオブジェクトにアクセスするユーザ数に基づいて最小キャッシュ保持時間 （ＴＴＬｍｉｎ）を決定し、そのうち、前記データオブジェクトにアクセスする前記ユーザ数が増加したとき、前記ＴＴＬｍｉｎが長い時間に決定される工程と、
前記データオブジェクトの更新頻度に基づいて最大キャッシュ保持時間（ＴＴＬｍａｘ）を決定し、そのうち、前記データオブジェクトの更新頻度が増加したとき、前記ＴＴＬｍａｘが短い時間に設定され、前記ＴＴＬが前記ＴＴＬｍａｘ以下、かつＴＴＬｍｉｎ以上に決定される工程と、
を含むことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項5】

前記ＴＴＬｍａｘがＴＴＬｍｉｎ以下である場合、前記ＴＴＬがＴＴＬｍｉｎに決定されることを特徴とする、請求項４に記載のキャッシュＴＴＬを決定する方法。

【請求項6】

前記ＴＴＬｍｉｎが失効した後に前記データオブジェクトを提供するバックエンドサーバに到達するユーザ数から推定される１秒あたりの最大クエリ数（ＱＰＳ） が、前記バックエンドサーバの最大ＱＰＳ容量未満となるように前記ＴＴＬｍｉｎが決定される、ことを特徴とする、請求項２に記載のキャッシュＴＴＬを決定する方法。

【請求項7】

前記ＴＴＬｍａｘが、前記データオブジェクトの前記更新頻度の逆数と等しい、またはそれ以下に決定されることを特徴とする、請求項３に記載のキャッシュＴＴＬを決定する方法。

【請求項8】

前記データオブジェクトが、アプリケーションのページに対応する、ことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項9】

前記データオブジェクトが、アプリケーションのリーダーボードに対応する、ことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項10】

さらに、前記データオブジェクトにアクセスするユーザ数を常時検出する工程と、
前記更新頻度と常時検出された前記ユーザ数に基づいて、前記ＴＴＬを常時決定する工程と、
前記ＴＴＬを前記キャッシュサーバに常時更新する工程と、
を含むことを特徴とする、請求項１に記載のキャッシュＴＴＬを決定する方法。

【請求項11】

前記データオブジェクトにアクセスする前記ユーザ数を常時検出し、かつ常時検出された前記データオブジェクトにアクセスする前記ユーザ数に基づいて前記ＴＴＬｍｉｎを常時決定し、前記ＴＴＬが前記ＴＴＬｍａｘ以下かつ前記ＴＴＬｍｉｎ以上であると常時決定し、前記ＴＴＬが前記キャッシュサーバに対して常時更新されることを特徴とする、請求項４に記載のキャッシュＴＴＬを決定する方法。

【請求項12】

キャッシュサーバ上のデータオブジェクトに対しＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ、キャッシュ保持時間）を決定するシステムであって、１以上のプロセッサを含み、そのうち、前記１以上のプロセッサが、機械可読命令を実行して、
前記データオブジェクトの更新頻度を検出する工程と、
前記データオブジェクトにアクセスするユーザ数を所定の監視タイミングで監視し、前記監視タイミングにおいて前記データオブジェクトにアクセスしているユーザ数を検出する工程と、
当該更新頻度と当該監視タイミングにおいて検出された当該ユーザ数に基づいてＴＴＬを決定する工程と、
を実行することを特徴とする、キャッシュＴＴＬを決定するシステム。

【請求項13】

前記１または複数のプロセッサが、前記機械可読命令を実行して、さらに、
前記データオブジェクトにアクセスするユーザ数に基づいて最小キャッシュ保持時間（ＴＴＬｍｉｎ）を決定する工程を実行し、そのうち、前記データオブジェクトにアクセスする前記ユーザ数が増加したとき、前記ＴＴＬｍｉｎがより長い時間に決定され、前記ＴＴＬが前記ＴＴＬｍｉｎ以上に決定される、
ことを特徴とする、請求項１２に記載のキャッシュＴＴＬを決定するシステム。

【請求項14】

前記１または複数のプロセッサが、前記機械可読命令を実行して、さらに、
前記データオブジェクトの更新頻度に基づいて最大キャッシュ保持時間（ＴＴＬｍａｘ）を決定する工程を実行し、そのうち、前記データオブジェクトの更新頻度が増加したとき、前記ＴＴＬｍａｘが短い時間に設定され、前記ＴＴＬが前記ＴＴＬｍａｘ以下に決定される、
ことを特徴とする、請求項１２に記載のキャッシュＴＴＬを決定するシステム。

【請求項15】

前記１または複数のプロセッサが、前記機械可読命令を実行して、さらに、
前記データオブジェクトにアクセスするユーザ数に基づいて最小キャッシュ保持時間 （ＴＴＬｍｉｎ）を決定する工程を実行し、そのうち、前記データオブジェクトにアクセスする前記ユーザ数が増加したとき、前記ＴＴＬｍｉｎが長い時間に決定され、
前記データオブジェクトの更新頻度に基づいて最大キャッシュ保持時間（ＴＴＬｍａｘ）を決定する工程を実行し、そのうち、前記データオブジェクトの更新頻度が増加したとき、前記ＴＴＬｍａｘが短い時間に設定され、前記ＴＴＬが前記ＴＴＬｍａｘ以下、かつＴＴＬｍｉｎ以上に決定される、
ことを特徴とする、請求項１２に記載のキャッシュＴＴＬを決定するシステム。

【請求項16】

前記ＴＴＬｍａｘがＴＴＬｍｉｎ以下である場合、前記ＴＴＬがＴＴＬｍｉｎに決定されることを特徴とする、請求項１５に記載のキャッシュＴＴＬを決定するシステム。

【請求項17】

前記１または複数のプロセッサが、前記機械可読命令を実行して、さらに、
前記データオブジェクトにアクセスするユーザ数を常時検出する工程と、
前記更新頻度と常時検出された前記ユーザ数に基づいて、前記ＴＴＬを常時決定する工程と、
前記ＴＴＬを前記キャッシュサーバに常時更新する工程と、
を実行することを特徴とする、請求項１２に記載のキャッシュＴＴＬを決定するシステム。

【請求項18】

前記データオブジェクトにアクセスする前記ユーザ数を常時検出し、かつ常時検出された前記データオブジェクトにアクセスする前記ユーザ数に基づいて前記ＴＴＬｍｉｎを常時決定し、前記ＴＴＬが前記ＴＴＬｍａｘ以下かつ前記ＴＴＬｍｉｎ以上であると常時決定し、前記ＴＴＬが前記キャッシュサーバに対して常時更新されることを特徴とする、請求項１５に記載のキャッシュＴＴＬを決定するシステム。

【請求項19】

キャッシュサーバ上のデータオブジェクトに対しＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ、キャッシュ保持時間）を決定するためのプログラムを含む非一時的なコンピュータ可読媒体であって、そのうち、前記プログラムが、１または複数のコンピュータに、
前記データオブジェクトの更新頻度を検出する工程と、
前記データオブジェクトにアクセスするユーザ数を所定の監視タイミングで監視し、前記監視タイミングにおいて前記データオブジェクトにアクセスしているユーザ数を検出する工程と、
当該更新頻度と当該監視タイミングにおいて検出された当該ユーザ数に基づいてＴＴＬを決定する工程と、
を実行させることを特徴とする、コンピュータ可読媒体。

【請求項20】

前記プログラムが、１または複数のコンピュータに、
前記データオブジェクトにアクセスするユーザ数に基づいて最小キャッシュ保持時間 （ＴＴＬｍｉｎ）を決定し、そのうち、前記データオブジェクトにアクセスする前記ユーザ数が増加したとき、前記ＴＴＬｍｉｎが長い時間に決定される工程と、
前記データオブジェクトの更新頻度に基づいて最大キャッシュ保持時間（ＴＴＬｍａｘ）を決定し、そのうち、前記データオブジェクトの更新頻度が増加したとき、前記ＴＴＬｍａｘが短い時間に設定され、前記ＴＴＬが前記ＴＴＬｍａｘ以下、かつＴＴＬｍｉｎ以上に決定される工程と、
を実行させることを特徴とする、請求項１９に記載のコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネット上の情報の保存に関するものであり、特に、インターネットのキャッシュ上のデータオブジェクトの保存に関する。

【背景技術】

【0002】

キャッシュやキャッシング技術は、オペレーティングシステム、ＣＤＮ（コンテンツデリバリーネットワーク）を含むネットワーク層、ドメインネームシステム（ＤＮＳ）、ウェブアプリケーション、データベースなどの技術全体に適用され、活用されている。Ｑ＆Ａポータル、ゲーム、メディア共有、コンテンツストリーミング、ソーシャルネットワーキングなど、読み取り負荷の高い多くのアプリケーションワークロードにおいて、キャッシュを使用することで遅延を減らし、１秒あたりの入出力処理（ＩＯＰＳ）を向上させることができる。キャッシュされる情報には、データベースへのクエリ結果、計算負荷の高い計算、アプリケーションプログラミングインターフェイス（ＡＰＩ）の要求／応答、およびＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、画像ファイルなどのウェブアーティファクトが含まれる。

【0003】

キャッシングは、ＣＤＮサービスにとって非常に重要である。ＣＤＮは、ウェブサイトのサーバやアプリケーションのバックエンドサーバなどのバックエンドサーバにあるコンテンツ／データオブジェクトやそのコピーをプロキシサーバやキャッシュサーバに移動し、ウェブサイトの訪問者や近隣からアクセスするアプリケーションの利用者がコンテンツにすばやくアクセスできるようにする。

【0004】

ＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ、キャッシュ保持時間）とは、コンテンツ／データオブジェクト（またはコンテンツ／データオブジェクトのコピー）がキャッシュサーバなどのキャッシュシステムに保存されてから削除またはリフレッシュされるまでの時間である。ＣＤＮのコンテキストで、ＴＴＬは一般的にコンテンツキャッシュを指し、これはウェブサイトやアプリケーションサーバ上のリソース（画像、価格、テキスト、ストリーミングコンテンツなど）のコピーをＣＤＮキャッシュサーバに保存してページロード速度を向上させ、オリジンサーバの帯域消費と作業負荷を軽減するプロセスである。

【発明の概要】

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

【0005】

本発明の一実施態様に係る方法は、１または複数のコンピュータによって実行される、キャッシュサーバ上のデータオブジェクトのＴＴＬ（Ｔｉｍｅ ｔｏ Ｌｉｖｅ、キャッシュ保持時間）を決定するための方法であり、当該データオブジェクトの更新頻度を検出する工程と、当該データオブジェクトにアクセスするユーザ数を検出する工程と、当該更新頻度と当該ユーザ数に基づいて当該ＴＴＬを決定する工程を含む。

【0006】

本発明の一実施態様に係るシステムは、１または複数のプロセッサを含む、キャッシュサーバ上のデータオブジェクトの ＴＴＬを決定するためのシステムであって、当該１または複数のコンピュータプロセッサが、機械読み取り可能な命令を実行し、当該データオブジェクトの更新頻度を検出する工程と、当該データオブジェクトにアクセスするユーザ数を検出する工程と、当該更新頻度と当該ユーザ数に基づいて 当該ＴＴＬを決定する工程と、を実行する。

【0007】

本発明の一実施態様に係るコンピュータ可読媒体は、キャッシュサーバ上のデータオブジェクトのＴＴＬを決定するためのプログラムを含む非一時的なコンピュータ可読媒体であって、当該プログラムが、１または複数のコンピュータに、当該データオブジェクトの更新頻度を検出する工程と、当該データオブジェクトにアクセスするユーザ数を検出する工程と、当該更新頻度と当該ユーザ数に基づいて当該ＴＴＬを決定する工程と、を実行させる。

【図面の簡単な説明】

【0008】

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

【図2】本発明の一部の実施態様に基づく通信システムの例示的な機能構成図である。

【図3】本発明の一部の実施態様に基づく通信システムの動作を示す例示的なシーケンス図である。

【図4】本発明の一部の実施態様に基づく工程を示すフローチャートである。

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

【0009】

データオブジェクトのＴＴＬは、キャッシュサーバ上の当該データオブジェクト（または当該データオブジェクトのコピー）の更新速度を管理し、当該データオブジェクトにアクセス可能なアプリケーションやウェブサイトを訪れる訪問者に当該データオブジェクトの「古い」バージョンが提供されないように確約することが理想的である。ＴＴＬは、アプリケーションやウェブサイトのページロード時間（つまり、キャッシュされたデータはロードが速くなる）とコンテンツの鮮度（つまり、長い間キャッシュされたデータが古くなる可能性がある）に直接影響を与える。

【0010】

静的なファイルやデータオブジェクト（画像ファイル、ＰＤＦ など）はほとんど更新されないため、通常はより長いＴＴＬを有する。例えば、ｅコマースサイトの商品画像のコレクションは、静的コンテンツに相当する。これらはめったに更新されないため、長期間（例えば、数日または数週間）キャッシュしておくことができる。このため、ＴＴＬの設定は予測可能で、保守も容易である。

【0011】

逆に、動的なコンテンツやデータオブジェクト（ＨＴＭＬファイルなど）は常に更新されるため、正確なＴＴＬの設定が複雑になる。例えば、製品の下にあるコメント欄は、頻繁に変更されるため、動的コンテンツとみなされる。ＴＴＬを長く設定しすぎると、コメントの反映が間に合わなくなる。

【0012】

ＴＴＬの設定でもう１つ懸念すべき点は、データオブジェクトにアクセスするユーザ数である。多くのユーザが該当するデータオブジェクトにアクセスしようとしているときにＴＴＬを短く設定しすぎると、ＴＴＬが終了したときに、多くのユーザがキャッシュサーバで応答を得られず、データオブジェクトのオリジンサーバにアクセス（オリジンサーバに直接アクセスする場合とキャッシュサーバを介してアクセスする場合がある）しなければならなくなる危険性がある。オリジンサーバがサポートできる最大容量を超える数のユーザがオリジンサーバにアクセスした場合、通常、オリジンサーバの１秒あたりのクエリ数（ＱＰＳ）が過大または過負荷となり、サーバがクラッシュダウンしたり、一部のユーザが正常にデータアクセスを達成できなくなったりする可能性がある。

【0013】

したがって、データオブジェクトの更新頻度やデータオブジェクトにアクセスするユーザ数などの要因に基づいて、データオブジェクトのキャッシュサーバ上におけるＴＴＬをどのように決定するかは、最も新鮮なデータを提供し、ユーザのアクセス障害を防止するとともに、オリジンサーバを機能停止から保護するために極めて重要である。一部の実施態様において、データオブジェクトは、リソースまたはリソースデータと呼ぶことができる。

【0014】

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

【0015】

図２に、通信システム１の例示的な機能構成図を示す。図２においては、ネットワーク９０を省略し、ユーザ端末１０とバックエンドサーバ３０を接続するＣＤＮサーバ５０が示されている。当該ＣＤＮサーバ５０は、当該ネットワーク９０の一部であってもよい。一部の実施態様において、当該ＣＤＮサーバ５０は、キャッシュサーバとして機能してもよい。

【0016】

本実施態様において、当該ユーザ端末１０は、ＵＩユニット１１と、デコーダー１２と、レンダラー１３と、ディスプレイ１３を含む。当該ユーザ端末１０は、例えば、ＡＰＩ要求を送信し、ＡＰＩ応答を受信することにより、当該ＣＤＮサーバ５０を介して、そのデータオブジェクトの当該バックエンドサーバ３０及び当該ストリーミングサーバ４０にアクセスすることができる。当該デコーダー１２は、受信したデータオブジェクト（ストリーミングデータであってもよい）をデコードし、当該レンダラー１３が当該ディスプレイ１４に表示する動画を生成する。当該ディスプレイ１４は、当該ユーザ端末１０のコンピュータ画面で当該映像を描写または表示する。当該ＵＩユニット１１は、当該ユーザ端末１０のユーザと相互作用するように構成されており、例えば、アプリケーションに関する当該ユーザの操作を受け付ける。一部の実施態様において、当該ユーザ端末１０は、動画をエンコードしてストリーミングデータを生成するためのエンコーダ（図示せず）を含んでもよい。

【0017】

図２に示す実施態様における当該ＣＤＮサーバ５０は、キャッシュ検出部５２と、キャッシュストレージユニット５４と、ＴＴＬ管理ユニット５６を含む。当該キャッシュ検出部５２は、当該ＣＤＮサーバ５０が、以前に取得またはアクセスした際に要求されたデータオブジェクトまたはリソースを保存しているか否かをチェックするように構成される。当該キャッシュストレージユニット５４は、当該ユーザ端末１０により以前に取得されたバックエンドサーバ３０及び／またはストリーミングサーバ４０からのデータオブジェクト（またはデータオブジェクトのコピー）を保存するように構成されている。当該ＴＴＬ管理ユニット５５は、各データオブジェクトについて、ＴＴＬまたはキャッシュストレージユニット５４に保存される期間を管理する。

【0018】

例えば、当該ＣＤＮサーバ５０は、当該ユーザ端末１０から当該バックエンドサーバ３０内のデータオブジェクトにアクセスするための要求（ＡＰＩ要求など）を受信すると、キャッシュ検出部５２は、マッピング操作または比較操作を実行し、要求されたデータオブジェクトがキャッシュストレージユニット５４に保存されているか否かを検出することができる。要求されたデータオブジェクトが当該キャッシュストレージユニット５４で見つかる（キャッシュヒットと呼ばれることがある）場合、当該ＣＤＮサーバ５０は、当該バックエンドサーバ３０にアクセスすることなく、保存されたデータオブジェクト、またはキャッシュされたデータオブジェクトを当該ユーザ端末１０に送信する。要求されたデータオブジェクトが当該キャッシュストレージユニット５４で見つからない（キャッシュミスと呼ばれることがある）場合、当該ＣＤＮサーバ５０は、当該データオブジェクトにアクセスするために当該バックエンドサーバ３０に要求を渡すことができる。キャッシュミスは、当該データオブジェクトが初めて要求されたとき、または当該キャッシュストレージユニット５４に保存されたデータオブジェクトの（以前に取得したときの）ＴＴＬが期限切れになったときに起こり得る。

【0019】

図２に示す実施態様における当該バックエンドサーバ３０は、処理ユニット３１、ストレージユニット３２、頻度検出ユニット３３、ユーザ数検出ユニット３４を含む。当該バックエンドサーバ３０は、当該ＣＤＮサーバ５０から要求を受信し、対応するデータオブジェクトで応答する。当該バックエンドサーバ３０は、当該ＣＤＮサーバ５０からＡＰＩ要求を受信し、ＡＰＩ応答を返すことができる。当該ＡＰＩ応答は、要求されたデータオブジェクトとそれに対応するＴＴＬ情報を含むことができる。当該ＴＴＬ情報は、当該ＴＴＬ管理ユニット５６で使用し、当該キャッシュストレージユニット５４に保存される当該データオブジェクトに対して当該ＴＴＬを設定するために使用されてもよい。

【0020】

当該ストレージユニット３２は、当該ＣＤＮサーバ５０を介して当該ユーザ端末１０によりアクセスされるデータオブジェクトを含め、多様なデータとプログラムを保存することができる。当該頻度検出ユニット３３は、データオブジェクトの更新頻度を検出または受信するように構成される。一部の実施態様において、当該頻度検出ユニット３３は、更新頻度について、Ｄａｔａｄｏｇなどの外部統計システムにアクセスしてもよく、これはＡＰＩ要求によって行われてもよい。当該ユーザ数検出ユニット３４は、データオブジェクトにアクセスするユーザ数を検出または受信するように構成される。一部の実施態様において、当該ユーザ数検出ユニット３４は、ユーザ数について、Ｄａｔａｄｏｇデータベースなどの外部データベースにアクセスしてもよく、これはＡＰＩ要求によって行われてもよい。当該処理ユニット３１は、他の多くの機能の中でも、当該ＣＤＮサーバ５０に当該ＣＤＮサーバ５０からの要求に応答して、当該ＣＤＮサーバ５０に対し更新または応答されるデータオブジェクトのＴＴＬを決定するように構成される。一部の実施態様において、当該処理ユニット３１は、当該データオブジェクトの更新頻度及び／または当該データオブジェクトにアクセスする当該ユーザ数に基づいてＴＴＬを決定する。

【0021】

一部の実施態様において、当該処理ユニット３１は、ＣＰＵ、ＧＰＵ等として構成され、アプリの一部であり得る、当該ストレージユニット３２に保存された各種プログラムを読み出し、当該プログラムに含まれる各種コマンドや機械読み取り可能な命令を実行する。一部の実施態様において、当該バックエンドサーバ３０に含まれる上述の各部材は、処理装置またはプロセッサとみなされてもよい。

【0022】

一部の実施態様において、当該バックエンドサーバ３０は、ライブストリーミングサービスを提供するアプリケーションのオリジンサーバである。この場合、当該バックエンドサーバ３０内のデータオブジェクトは、ストリーマーのリーダーボードを表す、またはそれに対応するデータオブジェクト、コメントまたはメッセージ情報を表す、またはそれに対応するデータオブジェクト、及び／または、多くのユーザがアクセスする人気ページまたはホットなページであり得るアプリケーションのページを表す、またはそれに対応するデータオブジェクトを含むことができる。当該ストリーミングサーバ４０のデータオブジェクトは、ストリーマーからのストリーミングデータを含んでもよい。

【0023】

図３に、本発明の一部の実施態様に基づく通信システムの動作を示す例示的なシーケンス図を示す。一部の実施態様において、図３に、ユーザ端末からの要求に応答して、バックエンドサーバ内のデータオブジェクトがどのようにコピー、更新またはＣＤＮサーバに送信されるかを示す。

【0024】

工程Ｓ１００において、当該ユーザ端末１０は、当該ＣＤＮサーバ５０にＡＰＩ要求を送信し、例えば、アプリケーションやウェブサイトのページ、リーダーボード、メッセージセクションを表す、またはそれに対応し得るデータオブジェクトまたはリソースを要求する。

【0025】

工程Ｓ１０２において、当該ＣＤＮサーバ５０は、要求された当該データオブジェクトが保存されているか否かを判断する。例えば、キャッシュ検出部５２は、検索操作またはマッピング操作を実行し、要求されたデータオブジェクトが当該キャッシュストレージユニット５４に保存されているか否かを判断する。本実施態様において、要求されたデータオブジェクトがキャッシュストレージユニット５４に見つからず、キャッシュミスとなり、フローは工程S１０４に進む。

【0026】

工程Ｓ１０４において当該ＣＤＮサーバ５０は、ユーザ端末１０が要求したデータオブジェクトのＡＰＩ要求を当該バックエンドサーバ３０に送信する（または、当該ユーザ端末１０のＡＰＩ要求を渡す）。

【0027】

工程Ｓ１０６において、当該バックエンドサーバ３０は、要求されたデータオブジェクトを準備または取得して、当該データオブジェクトのＴＴＬを決定し、当該データオブジェクトが当該ＣＤＮサーバ５０にどのくらいの期間保存されるかにこれが適用される。ＴＴＬの決定に関する詳細は、後述する。

【0028】

工程Ｓ１０８において、当該バックエンドサーバ３０は、要求されたデータオブジェクト（当該データオブジェクトのコピー）と対応するＴＴＬ情報を少なくとも含む、ＡＰＩ応答を当該ＣＤＮサーバ５０に送信する。当該ＴＴＬ情報は、当該ＣＤＮサーバ５０の当該ＴＴＬ管理ユニット５６により、データオブジェクトの保存期間の長さを管理するために使用される。

【0029】

工程Ｓ１１０において、当該ＣＤＮサーバ５０は、要求された当該データオブジェクトとそのＴＴＬ情報を含む、当該ＡＰＩ応答を当該バックエンドサーバ３０から受信する。当該ＣＤＮサーバ５０は、当該データオブジェクトを当該キャッシュストレージユニット５４に保存し、ＴＴＬ情報に従って、当該ＴＴＬ管理ユニット５６内で対応するＴＴＬを設定することができる。

【0030】

工程Ｓ１１２において、当該ＣＤＮサーバ５０は、少なくとも要求された当該データオブジェクトを含むＡＰＩ応答を当該ユーザ端末１０に送信する。ここまでで、データオブジェクトにアクセスする例示的なラウンドが完了し、当該ユーザ端末１０は、受信したデータオブジェクトをアプリケーションにおける操作、例えば、リーダーボードの確認、アプリケーションのページ表示、または最新のコメント情報の取得のために使用することができる。

【0031】

工程Ｓ１１４において、ユーザ端末１０は、再び、同じデータオブジェクトにアクセスするためのＡＰＩ要求を当該ＣＤＮサーバ５０に送信するが、これは、ページ、リーダーボードまたはコメント欄を更新するためのアプリケーションにおける定期的な要求またはトリガーに従って実行されてもよい。

【0032】

工程Ｓ１１６において、当該ＣＤＮサーバ５０は、要求された当該データオブジェクトが保存されているか否かを判断する。例えば、キャッシュ検出部５２は、検索操作またはマッピング操作を実行し、要求されたデータオブジェクトが当該キャッシュストレージユニット５４に保存されているか否かを判断する。この例において、以前に取得またはアクセスしたデータオブジェクトが工程Ｓ１１０で当該キャッシュストレージユニット５４に保存されており、対応するＴＴＬがまだ失効していない。したがって、要求されたデータオブジェクトを当該キャッシュストレージユニット５４で見つけることができ、これがキャッシュヒットとなって、フローは当該バックエンドサーバ３０にアクセスする必要なく工程S１１８に進む。

【0033】

工程Ｓ１１８において、当該ＣＤＮサーバ５０は当該キャッシュストレージユニット５４に保存されている要求されたデータオブジェクトを少なくとも含むＡＰＩ応答をユーザ端末１０に送信する。この場合、データオブジェクトの内容は変更されない。

【0034】

図４に本発明の一部の実施態様に基づく工程のフローチャートを示す。図４に、図３の工程Ｓ１０６において、アクセスされたデータオブジェクトのＴＴＬがどのように当該バックエンドサーバ３０によって決定され得るのかを示す。

【0035】

工程Ｓ２００において、要求されたデータオブジェクトの更新頻度が、例えば、当該バックエンドサーバ３０の当該頻度検出ユニット３３により、検出または受信される。一部の実施態様において、当該頻度検出ユニット３３は、更新頻度について、Ｄａｔａｄｏｇデータベースなどの外部データベースにアクセスしてもよく、これはＡＰＩ要求によって行われてもよい。当該データオブジェクトはさまざまな方法で更新され得る。例えば、リーダーボードやコメント欄に対応するデータオブジェクトは、さまざまなユーザ端末からの投稿や入力情報によって、当該データオブジェクトを管理または保持するデータベース（当該バックエンドサーバまたは別のデータベースであり得る）に更新される可能性がある。別の例として、アプリケーションのホットなページまたは人気ページに対応するデータオブジェクトは、当該アプリケーションの当該バックエンドサーバによって更新され得るため、更新頻度のために別のデータベースにアクセスする必要がないことがある。

【0036】

工程Ｓ２０２において、当該データオブジェクトの更新頻度に基づいて、最大キャッシュ保持時間ＴＴＬｍａｘが、例えば、当該バックエンドサーバ３０の処理ユニット３１により決定される。一部の実施態様において、当該ＴＴＬｍａｘは、当該データオブジェクトの更新頻度が多いとき、より短く決定される。一部の実施態様において、当該ＴＴＬｍａｘは当該更新頻度に反比例する。一部の実施態様において、当該ＴＴＬｍａｘは、当該データオブジェクトの当該更新頻度の逆数と等しい、またはそれ以下に決定される。例えば、更新頻度が１秒当たり２回である場合、ＴＴＬｍａｘは、１／２秒に等しい、またはそれ以下とすることができる。また、別の例として、更新頻度が５秒に１回の場合、ＴＴＬｍａｘは５秒以下とすることができる。一部の実施態様において、インターネットにおける信号伝送遅延を考慮し、ＴＴＬｍａｘは更新頻度の逆数から所定のオフセットを有するように設定されてもよく、そのうち、この所定のオフセットは信号伝送遅延またはＡＰＩ応答時間をカバーまたは補償するために用いられ、ネットワーク条件など実際の実践に従い決定することができる。例えば、更新頻度が５秒に１回の場合、ＴＴＬｍａｘは（５－２）秒に等しくてもよく、そのうち、５は頻度の逆数であり、２は所定のオフセットである。

【0037】

工程Ｓ２０４において、当該データオブジェクトにアクセスするユーザ数が、例えば、当該バックエンドサーバ３０の当該ユーザ数検出ユニット３４により、検出または受信される。一部の実施態様において、当該ユーザ数検出ユニット３４は、ユーザ数について、Ｄａｔａｄｏｇデータベースなどの外部データベースにアクセスしてもよく、これはＰＩ要求によって行われてもよい。

【0038】

工程Ｓ２０６において、当該データオブジェクトにアクセスするユーザ数に基づいて、最小キャッシュ保持時間ＴＴＬｍｉｎが、例えば、当該バックエンドサーバ３０の当該処理ユニット３１により決定される。一部の実施態様において、当該ＴＴＬｍｉｎは、当該データオブジェクトにアクセスするユーザ数が増加したとき、より長く決定される。一部の実施態様において、当該ＴＴＬｍｉｎは、当該ＴＴＬｍｉｎが失効した後に当該データオブジェクトを提供する当該バックエンドサーバに到達する当該ユーザ数からの推定ＱＰＳが、当該バックエンドサーバの最大ＱＰＳ容量以下となるように決定される。

【0039】

工程Ｓ２０８において、当該データオブジェクトのＴＴＬは、当該最大キャッシュ保持時間ＴＴＬと当該最小キャッシュ保持時間ＴＴＬｍｉｎに基づいて、例えば、当該バックエンドサーバ３０の当該処理ユニット３１により決定される。一部の実施態様において、当該ＴＴＬは、当該ＴＴＬｍｉｎと等しい、またはそれよりも大きいものとして決定される。一部の実施態様において、当該ＴＴＬは、当該ＴＴＬｍａｘと等しい、またはそれよりも小さいものとして決定される。一部の実施態様において、当該ＴＴＬは、当該ＴＴＬｍａｘと等しい、またはそれよりも小さく、かつ当該ＴＴＬｍｉｎと等しい、またはそれよりも大きいものとして決定される。一部の実施態様において、当該ＴＴＬは、ＴＴＬｍａｘがＴＴＬｍｉｎと等しい、またはそれよりも小さい場合、ＴＴＬｍｉｎとして決定される。

【0040】

一部の実施態様において、最大キャッシュ保持時間ＴＴＬｍａｘは、ＴＴＬの最大値を設定し、それにより、当該ユーザ端末が常に当該データオブジェクトの最新バージョンを取得するよう確約する。更新頻度の高いデータオブジェクトでは、対応するＴＴＬｍａｘが短く設定され、当該データオブジェクトが当該ＣＤＮサーバ上に存在する時間が短くなる。したがって、ユーザ端末からの当該データオブジェクトの要求は、（当該ＴＴＬｍａｘが失効し、当該データオブジェクトが当該ＣＤＮサーバ上で見つからなくなったときに）当該ＣＤＮサーバを経由して当該バックエンドサーバにより高い頻度でアクセスし、最新バージョンのデータオブジェクトを取得する必要が生じることになる。一部の実施態様において、低い更新頻度のデータオブジェクトの場合、対応するＴＴＬｍａｘはより長く設定され、当該データオブジェクトは当該ＣＤＮサーバ上により長い時間存在する。したがって、ユーザ端末からの当該データオブジェクトの要求は、（当該ＴＴＬｍａｘが失効し、当該データオブジェクトが当該ＣＤＮサーバ上で見つからなくなったときに）当該ＣＤＮサーバを経由して当該バックエンドサーバにアクセスする必要性が生じる頻度がより低くなり、当該バックエンドサーバの負担が軽減される可能性がある。

【0041】

一部の実施態様において、データオブジェクトの更新頻度は、例えば、図２中の当該バックエンドサーバ３０の当該頻度検出ユニット３３により、常時または定期的に監視または追跡されてもよい。当該処理ユニット３１は、常時監視された更新頻度を利用して、ＴＴＬｍａｘを常時決定し、ＴＴＬｍａｘ及びＴＴＬLｍｉｎに基づいてＴＴＬを決定してもよい。一部の実施態様において、当該バックエンドサーバ３０は、当該ＣＤＮサーバ５０に保存された対応するデータオブジェクトに対してＴＴＬを設定するために、当該ＣＤＮサーバ５０に対しＴＴＬ情報を常に更新してもよい。一部の実施態様において、当該バックエンドサーバ３０は、データオブジェクトの更新頻度の変化が検出されると、当該ＣＤＮサーバ５０に対してＴＴＬ情報を更新し、ユーザ端末がアクセスするデータオブジェクトがその最新バージョンであることを保証することができる。一部の実施態様において、当該ＴＴＬの更新は当該ＣＤＮサーバ５０からの要求を必要としなくてもよい。

【0042】

一部の実施態様において、最小キャッシュ保持時間ＴＴＬｍｉｎは、ＴＴＬの最小値を設定することにより、例えば、ＴＴＬｍｉｎが切れた直後のタイミング及び／またはデータオブジェクトがキャッシュサーバに送信またはコピーされる前のタイミングで、ユーザ端末からの要求により、当該バックエンドサーバが圧倒されたり過負荷になったりすることを防止する。多くのユーザ端末によりアクセスされるデータオブジェクトの場合、対応するＴＴＬｍｉｎはより長く設定され、当該データオブジェクトは当該ＣＤＮサーバ上により長い時間存在する。したがって、当該データオブジェクトにアクセスするユーザ数がまだ多い場合、ユーザ端末からの当該データオブジェクトの要求は、より長い時間当該ＣＤＮサーバを経由して当該バックエンドサーバにアクセスする必要がなくなり、当該バックエンドサーバのクラッシュダウンやアクセス障害のリスクを低減することが可能となる。

【0043】

一部の実施態様において、ＴＴＬｍｉｎは、例えば、１０秒後、３０秒後、または１分後などこれからのタイミングで対応するデータオブジェクトにアクセスしようとするユーザの推定ユーザ数によって決定されてもよい。当該推定ユーザ数は、ユーザ行動データ、アプリケーションイベントデータ及び／またはそれらの相関データなどの履歴データによってトレーニングされた機械学習アルゴリズムを含む、さまざまな推定メカニズムによって達成されてもよい。例えば、ＴＴＬｍｉｎは、データオブジェクトにアクセスするユーザ数が、当該バックエンドサーバをクラッシュダウンのリスクに陥らせない、またはアクセス障害を引き起こさないレベルまで減少すると推定または期待される長さに設定することができる。

【0044】

一部の実施態様において、当該データオブジェクトにアクセスするユーザ数は、例えば、図２中の当該バックエンドサーバ３０の当該ユーザ数検出ユニット３４により、常時または定期的に監視または追跡されてもよい。当該処理ユニット３１は、常時監視されたアクセスユーザ数を利用して、ＴＴＬｍｉｎを常時決定し、ＴＴＬｍａｘ及びＴＴＬｍｉｎに基づいてＴＴＬを決定する。一部の実施態様において、当該バックエンドサーバ３０は、当該ＣＤＮサーバ５０に保存された対応するデータオブジェクトに対してＴＴＬを設定するために、当該ＣＤＮサーバ５０に対しＴＴＬ情報を常に更新してもよい。一部の実施態様において、当該ＴＴＬの更新は当該ＣＤＮサーバ５０からの要求を必要としなくてもよい。例えば、多くのユーザ数によりアクセスされることが予想されるデータオブジェクト（例えば、アプリケーションのホットなページに対応するデータオブジェクトなど）の場合、当該バックエンドサーバ３０はリアルタイムのアクセスユーザ数に基づいてＴＴＬ設定を継続的にまたは常時更新することができる。上述のように、ＴＴＬの決定は、常に最新のアクセスユーザ数を考慮したものであり、そのため当該ＣＤＮサーバにおけるＴＴＬ失効後のクラッシュダウンやアクセス失敗のリスクを回避することができる。一部の実施態様において、対応するデータオブジェクトにより多くのユーザ端末からのアクセスがある場合、ＴＴＬｍｉｎ（およびＴＴＬ）は当該ＣＤＮサーバに対してより頻繁に決定及び／または更新行うことができる。

【0045】

また、ＴＴＬｍａｘがＴＴＬｍｉｎと同等かそれ以下である状況もあり得る。例えば、データオブジェクトの更新頻度が高く、多くのユーザがアクセスする場合、当該データオブジェクトはＴＴＬｍａｘが短く、ＴＴＬｍｉｎが長くなる場合がある。一部の実施態様において、ＴＴＬｍａｘ がＴＴＬｍｉｎ以下である場合、ＴＴＬはＴＴＬｍｉｎに決定される。つまり、一部の実施態様において、ＴＴＬの決定時、ＴＴＬｍｉｎの優先度または重要度のウェイトはＴＴＬｍａｘ より高い場合があり、これは、ＴＴＬｍｉｎの目的の１つが当該バックエンドサーバを過負荷やクラッシュから保護することであるためである。

【0046】

また、ＴＴＬｍｉｎに基づいてＴＴＬを決定することで、当該バックエンドサーバの負担を軽減する複雑な仕組みを省略・簡略化できるメリットもある。例えば、通信速度制限の仕組みや、バックエンドサーバの増設を省くことができる。一部の実施態様において、効率的にバックエンドサーバの負荷を分散させる機能を備えた追加のインフラストラクチャ実装や複雑なキャッシュサーバを必要とすることがあるサーバ負荷分散機構を省くことができる。そのため、対応するアプリケーションの運用コストを削減することができる。

【0047】

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

【0048】

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

【0049】

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

【符号の説明】

【0050】

１ 通信システム
１０ ユーザ端末
１１ ＵＩユニット
１２ デコーダー
１３ レンダラー
１４ ディスプレイ
３０ バックエンドサーバ
３１ 処理ユニット
３２ ストレージユニット
３３ 頻度検出ユニット
３４ ユーザ数検出ユニット
４０ ストリーミングサーバ
５０ ＣＤＮサーバ
５２ キャッシュ検出部
５４ キャッシュストレージユニット
５６ ＴＴＬ管理ユニット
９０ ネットワーク

【図1】

【図2】

【図3】

【図4】