JP2018025944A - リソース制御ブログラム、リソース制御方法及びリソース制御装置 - Google Patents

Abstract

【課題】適切なタイミングで仮想サーバのスケールアウトを実行する。【解決手段】話題性分析システム６０は、他サイト（ＳＮＳやブログサイト）から、自サイトで提供されるサービスに関連するキーワードの出現頻度カウント値を取得する。また、オートスケール制御システム７０は、他サイト話題性情報ＤＢ６４の出現頻度カウント値が示す、他キーワードの出現数の時間的変化に応じて、Ｗｅｂサイトを運用する仮想サーバ１４をスケールアウトさせる。【選択図】図１

Description

本発明は、リソース制御ブログラム、リソース制御方法及びリソース制御装置に関する。

クラウドサービスでは、物理サーバではなく、仮想基盤上に仮想サーバを割り当てることでサービスの提供（Ｗｅｂサイトの運用等）を行うことがある。仮想サーバは、複製することで簡単にサーバ台数を増やすことが可能である。このため、Ｗｅｂサイトの利用者の増加により、仮想サーバのＣＰＵやメモリが過負荷になった場合、仮想サーバを複製して台数を増やす（スケールアウトする）ことで、利用者からのＷｅｂサイトへのアクセスや処理に対応することができる。特に、クラウドサービスが従量課金制の場合には、必要なときだけ仮想サーバを増やすことで、Ｗｅｂサイトの管理者にコスト的なメリットが生じる。

なお、特許文献１，２等には、負荷に応じてリソースを割り当てる技術について開示されている。

特開２０１５−９５１４９号公報 特開２０１１−２５８１１９号公報

サーバの負荷状況を監視し、負荷が閾値よりも高くなったことを検知してからスケールアウトを自動的に実施する場合、仮想サーバを増やしている間の利用者からのアクセス要求を処理できず、ビジネス機会を喪失するおそれがある。

これに対応するため、閾値を低く設定したり、予め多めに仮想サーバを稼働させておくなどの対策を講じることもできる。しかしながら、このような対策を講じた場合、急激なアクセス増加には対処できるものの、従量課金制の場合には、Ｗｅｂサイトの管理者に余計なコストが発生してしまう。

１つの側面では、本発明は、適切なタイミングで特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行うことが可能なリソース制御ブログラム、リソース制御方法及びリソース制御装置を提供することを目的とする。

一つの態様では、リソース制御ブログラムは、コンピュータに、登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせ、問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う、処理を実行させるブログラムである。

適切なタイミングで特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行うことができる。

一実施形態に係るクラウドサーバの構成を概略的に示す図である。 クラウドサーバのハードウェア構成を示す図である。 図３（ａ）は、ログ情報を示す図であり、図３（ｂ）は、自サイトアクセス数ＤＢのデータ構造を示す図である。 図４（ａ）は、自サイトキーワードＤＢのデータ構造を示す図であり、図４（ｂ）は、他サイトキーワードＤＢのデータ構造を示す図である。 図５（ａ）は、注目キーワードＤＢのデータ構造を示す図であり、図５（ｂ）は、他サイト話題性情報ＤＢのデータ構造を示す図である。 図６（ａ）は、自サイト負荷相関ＤＢのデータ構造を示す図であり、図６（ｂ）は、話題性／アクセス相関ＤＢのデータ構造を示す図である。 オートスケール制御部の一連の処理を示すフローチャートである。 図７の自サイト負荷相関ＤＢ作成処理（Ｓ１００）の具体的処理を示すフローチャートである。 図７の自サイトキーワードＤＢ作成処理（Ｓ２００）の具体的処理を示すフローチャートである。 図７の他サイトキーワードＤＢ作成処理（Ｓ３００）の具体的処理を示すフローチャートである。 図７のメイン処理（Ｓ４００）の具体的処理を示すフローチャートである。 図１１のステップＳ４１０の具体的処理を示すフローチャートである。 図１１のステップＳ４４０の具体的処理を示すフローチャートである。 図１１のステップＳ４５０の具体的処理を示すフローチャートである。 図１１のステップＳ４６０の具体的処理を示すフローチャートである。 図１１のステップＳ４７０の具体的処理を示すフローチャートである。 図１６のステップＳ４７２の回帰分析に用いるグラフの一例を示す図である。

以下、クラウドサーバ１００の一実施形態について、図１〜図１７に基づいて詳細に説明する。

図１には、本実施形態に係るクラウドサーバ１００の機能ブロック図が示され、図２には、クラウドサーバ１００のハードウェア構成が示されている。

クラウドサーバ１００は、図２に示すように、ＣＰＵ（Central Processing Unit）１９０、ＲＯＭ（Read Only Memory）１９２、ＲＡＭ（Random Access Memory）１９４、記憶部（ここではＨＤＤ（Hard Disk Drive））１９６、ネットワークインタフェース１９７、及び可搬型記憶媒体用ドライブ１９９等を備えている。これらクラウドサーバ１００の構成各部は、バス１９８に接続されている。クラウドサーバ１００では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているブログラム（リソース制御ブログラムを含む）、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったブログラム（リソース制御ブログラムを含む）をＣＰＵ１９０が実行することにより、図１に示す、各部の機能が実現される。なお、図１には、クラウドサーバ１００のＨＤＤ１９６等に格納されている各種ＤＢ（database）も図示されている。

クラウドサーバ１００では、ＣＰＵ１９０がブログラムを実行することで、サービス提供部１０、クラウド基盤制御部２０、オートスケール制御部３０として機能する。

サービス提供部１０は、仮想基盤上に仮想サーバ１４を割り当てることでサービスの提供（Ｗｅｂサイトの運用等）を行う。サービス提供部１０は、仮想サーバへの通信の振り分けを行うロードバランサ１２を有している。

クラウド基盤制御部２０は、仮想サーバ１４の監視や仮想サーバ１４の生成、削除等を行う。具体的には、クラウド基盤制御部２０は、監視システム２２と、クラウド構成管理システム２４と、を有する。監視システム２２は、仮想サーバ１４の負荷情報の収集と監視を行い、各Ｗｅｂサイトの負荷情報をオートスケール制御部３０に送信する。クラウド構成管理システム２４は、各Ｗｅｂサイトの負荷情報に基づいて、仮想サーバ１４の生成（スケールアウト）や削除（スケールイン）を行う。すなわち、クラウド構成管理システム２４は、Ｗｅｂサイトの管理者が利用する特定の情報処理装置に対してリソースを割り当てる制御を行っている。

オートスケール制御部３０は、クラウド構成管理システム２４によるスケールアウトやスケールインを制御するものである。オートスケール制御部３０は、ログシステム４０と、キーワード分析システム５０と、話題性分析システム６０と、オートスケール制御システム７０と、を有する。

ログシステム４０は、ロードバランサ１２や、仮想サーバ１４（Ｗｅｂサイト）のログを収集し、ログ情報４２として一括保存する。また、ログシステム４０は、ログ情報４２から、仮想サーバ１４において運用されているＷｅｂサイト（「自サイト」と呼ぶ）へのアクセス数の推移を取得し、自サイトアクセス数ＤＢ４４に蓄積する。

ここで、ログ情報４２は、図３（ａ）に示すような情報を含んでいる。具体的には、ログ情報４２には、アクセスに関する情報として「タイムスタンプ」、「アクセス元情報」、「接続先ＵＲＬ情報」が含まれる。「タイムスタンプ」は、自サイトへのアクセス日時の情報であり、「アクセス元情報」は、自サイトにアクセスしてきた端末のＩＰアドレスの情報であり、「接続先ＵＲＬ情報」は、自サイトのＵＲＬ（Uniform Resource Locator）情報である。

また、自サイトアクセス数ＤＢ４４は、図３（ｂ）に示すようなデータ構造を有する。具体的には、自サイトアクセス数ＤＢ４４は、「対象の仮想サーバ識別子」、「対象ＵＲＬ」、「アクセス数」の各フィールドを有する。「対象の仮想サーバ識別子」のフィールドには、アクセスのあった自サイトが運用されている仮想サーバの識別子が格納される。また、「対象ＵＲＬ」のフィールドには、アクセスがあったページのＵＲＬが格納され、「アクセス数」のフィールドには、所定時間（例えば１分）の間における各ページへのアクセス数が格納される。

図１に戻り、キーワード分析システム５０は、ログシステム４０において蓄積されるログ情報４２を分析して、自サイトで用いられているキーワードのうち集計のターゲットとなるキーワードを自動抽出する。そして、キーワード分析システム５０は、自動抽出したキーワードを自サイトキーワードＤＢ５２に蓄積する。また、キーワード分析システム５０は、インターネット上のＳＮＳ（Social Networking Service）やブログサイト（以下、「他サイト」とも呼ぶ）で人気となっているキーワードを抽出する。そして、キーワード分析システム５０は、抽出したキーワードを他サイトキーワードＤＢ５４に蓄積する。なお、他サイトを提供するサーバ等は、登録されたデータ（書き込まれたワードや検索されたワード）の参照を許容する制御を行う情報処理装置であると言える。

ここで、自サイトキーワードＤＢ５２は、図４（ａ）に示すようなデータ構造を有する。具体的には、自サイトキーワードＤＢ５２は、「対象の仮想サーバ識別子」、「対象ページの識別情報」、「主キーワード」、「サブキーワード」の各フィールドを有する。「対象の仮想サーバ識別子」のフィールドには、自サイトを運用している仮想サーバ１４の識別子が格納され、「対象ページの識別情報」のフィールドには、抽出したキーワードが存在するページの識別情報が格納される。「主キーワード」のフィールドには、キーワード分析システム５０が自サイトから抽出したキーワード（タイトルや主語など、ページ内でメインとなるワード）が格納される。また、「サブキーワード」のフィールドには、主キーワードに関連するサブキーワードが格納される。サブキーワードは、例えば、主キーワードから所定範囲内に存在し、主キーワードを説明するワードなど、主キーワードに関連している可能性の高いワードを意味する。

また、他サイトキーワードＤＢ５４は、図４（ｂ）に示すようなデータ構造を有する。具体的には、他サイトキーワードＤＢ５４は、「時刻情報」、「主キーワード」、「サブキーワード」の各フィールドを有する。「時刻情報」のフィールドには、主キーワードを抽出した日時の情報が格納される。「主キーワード」のフィールドには、キーワード分析システム５０が抽出した他サイトで人気となっているキーワードが格納される。また、「サブキーワード」のフィールドには、主キーワードに関連するキーワード（例えば、主キーワードをインターネット上で検索したときに、主キーワードに付随しているキーワードなど）が格納される。なお、他サイトキーワードＤＢ５４に格納される主キーワードは、Ｗｅｂサイトで提供されるサービスに関連するキーワードであると言える。

図１に戻り、話題性分析システム６０は、他サイトキーワードＤＢ５４から、自サイトキーワードＤＢ５２に格納されているキーワードに類似しているものを注目キーワードとして抽出し、注目キーワードＤＢ６２に蓄積する。また、話題性分析システム６０は、インターネット上の他サイト（ＳＮＳやブログサイト）で単位時間あたりの注目キーワードの出現頻度をカウントし、カウントデータを他サイト話題性情報ＤＢ６４に蓄積する。なお、話題性分析システム６０は、他サイトに登録されたデータの登録状況を問い合わせる問い合わせ部として機能している。

注目キーワードＤＢ６２は、図５（ａ）に示すようなデータ構造を有する。具体的には、注目キーワードＤＢ６２は、「類似度」、「他キーワード（注目キーワード）」、「自キーワード」の各フィールドを有する。この注目キーワードＤＢ６２には、類似度が高い順に、他サイトに存在するキーワード（他キーワード）、すなわち注目キーワードと、該注目キーワードに類似する自サイトに存在するキーワード（自キーワード）とが関連付けて格納される。

また、他サイト話題性情報ＤＢ６４は、図５（ｂ）に示すようなデータ構造を有する。具体的には、他サイト話題性情報ＤＢ６４は、「対象の仮想サーバ識別子」、「キーワード」、「出現頻度カウント」の各フィールドを有する。他サイト話題性情報ＤＢ６４においては、注目キーワードの単位時間当たりの出現頻度（出現回数）のカウント値が、注目キーワードと類似する自キーワードに関連付けて格納されるとともに、自キーワードが存在する自サイトを運用する仮想サーバ１４の識別子が格納されている。具体的には、図５（ａ）の注目キーワード「●○ゲーム」の単位時間当たりの出現頻度（出現回数）のカウント値がｎであった場合には、「●○ゲーム」と類似する自キーワード「○○ゲーム」の出現頻度カウントとして、他サイト話題性情報ＤＢ６４に値ｎが格納される。そして、自キーワード「○○ゲーム」が存在するＷｅｂサイトを運用する仮想サーバの識別子「ｖｍ００１」も他サイト話題性情報ＤＢ６４に格納される。

オートスケール制御システム７０は、自サイト負荷相関ＤＢ７２及び話題性／アクセス相関ＤＢ７４を参照して、上述したシステム４０，５０，６０の分析結果に基づいて、仮想サーバ１４の増減の必要性を判断する。そして、オートスケール制御システム７０は、判断結果に基づいて、クラウド構成管理システム２４に対してスケールアウト又はスケールインの指示を出す。なお、オートスケール制御システム７０は、監視システム２２から取得した仮想サーバ１４の負荷情報に基づいて自サイト負荷相関ＤＢ７２を適宜更新する。また、オートスケール制御システム７０は、他サイト話題性情報ＤＢ６４と自サイトアクセス数ＤＢ４４とに基づいて、話題性／アクセス相関ＤＢ７４を適宜更新する。

ここで、自サイト負荷相関ＤＢ７２は、図６（ａ）に示すようなデータを格納している。この自サイト負荷相関ＤＢ７２は、過去に取得された自サイトへのアクセス数と、自サイトの負荷率（％）との関係を示すデータである。

また、話題性／アクセス相関ＤＢ７４は、図６（ｂ）に示すようなデータを格納している。この話題性／アクセス相関ＤＢ７４は、過去に取得された、他サイトにおいて注目キーワードが出現した頻度（回数）と、注目キーワードと類似するキーワードが用いられている自サイトへのアクセス数との関係を示すデータである。

（オートスケール制御部３０の処理について）
次に、図７〜図１６のフローチャートに沿って、その他図面を適宜参照しつつ、オートスケール制御部３０の処理について詳細に説明する。

図７には、オートスケール制御部３０による一連の処理が示されている。図７に示すように、本実施形態においては、自サイト負荷相関ＤＢ作成処理（Ｓ１００）と、自サイトキーワードＤＢ作成処理（Ｓ２００）と、他サイトキーワードＤＢ作成処理（Ｓ３００）と、メイン処理（Ｓ４００）とが同時並行的に繰り返される。以下、各処理について、詳細に説明する。

（自サイト負荷相関ＤＢ作成処理（Ｓ１００））
まず、ステップＳ１００の自サイト負荷相関ＤＢ作成処理について説明する。本処理は、オートスケール制御システム７０が、自サイト負荷相関ＤＢ７２（図６（ａ）参照）を作成する処理であり、図８のフローチャートに沿って実行される。

図８の処理では、まず、ステップＳ１０２において、オートスケール制御システム７０が、クラウド基盤制御部２０の監視システム２２から仮想サーバ１４の負荷情報を収集する。

次いで、ステップＳ１０４では、オートスケール制御システム７０が、自サイトアクセス数ＤＢ４４を参照して、自サイトへのアクセス数が所定値（例えば、５０アクセス、１００アクセス、１５０アクセス、２００アクセス…）であるか否かを判断する。すなわち、オートスケール制御システム７０は、いずれかの仮想サーバ１４へのアクセス数が所定値であるか否かを判断する。このステップＳ１０４の判断が肯定された場合、オートスケール制御システム７０は、ステップＳ１０６に移行し、自サイト負荷相関ＤＢ７２を作成（更新）する。例えば、自サイトへのアクセス数が５０アクセスであり、そのときの自サイトの負荷率がｎ％であったとする。この場合、過去に５０アクセスのときの負荷率が得られている場合には、過去の負荷率と今回の負荷率の平均値で、５０アクセスのときの負荷率を更新してもよいし、今回得られた負荷率で過去に得られた負荷率を書き換えることとしてもよい。また、過去に５０アクセスのときの負荷率が得られていない場合には、今回得られた負荷率を５０アクセスのときの負荷率とすればよい。ステップＳ１０６の処理が終了した後は、図８の全処理が一旦終了するが、図７に示すように、図８の処理は繰り返し実行される。

一方、ステップＳ１０４の判断が否定された場合には、ステップＳ１０２に戻り、ステップＳ１０４の判断が肯定されるまでステップＳ１０２、Ｓ１０４の処理及び判断を繰り返す。

以上のように、自サイトへのアクセス数が所定値（５０、１００、１５０、２００…）になるたびに、自サイト負荷相関ＤＢ７２を更新することで、自サイト負荷相関ＤＢ７２を適宜更新することが可能となる。なお、自サイト負荷相関ＤＢ７２の作成処理は、常時実行しなくてもよく、例えば、所定時間毎や所定日数毎に実行してもよい。

（自サイトキーワードＤＢ作成処理（Ｓ２００））
次に、ステップＳ２００の自サイトキーワードＤＢ作成処理について説明する。本処理は、キーワード分析システム５０が、自サイトキーワードＤＢ５２（図４（ａ）参照）を作成する処理であり、図９のフローチャートに沿って実行される。

図９の処理では、ステップＳ２０２において、キーワード分析システム５０が、自サイト内のＷｅｂコンテンツの更新を監視する。

次いで、ステップＳ２０４では、キーワード分析システム５０は、自サイト内のＷｅｂコンテンツの更新が行われたか否かを判断する。このステップＳ２０４の判断が否定された場合には、ステップＳ２０２に戻るが、肯定された場合には、ステップＳ２０６に移行する。

ステップＳ２０６に移行すると、キーワード分析システム５０は、対象ページが識別できるように識別情報を生成する。具体的には、自サイトキーワードＤＢ５２（図４（ａ））の「対象ページの識別情報」に示すような、対象ページの識別情報を生成する。なお、識別情報は所定のルールに基づいて作成されるため、同一のページに対しては同一の識別情報が生成されるようになっている。

次いで、ステップＳ２０８では、キーワード分析システム５０は、更新されたページ内のワードを収集する。次いで、ステップＳ２１０では、キーワード分析システム５０は、タイトルや主語など、ページ内でメインとなるワードを「主キーワード」として抽出する。また、次のステップＳ２１２では、キーワード分析システム５０は、主キーワードに関連するワードを「サブキーワード」として抽出する。サブキーワードは、タイトルや主語などの近傍に位置しているワードのうち、主キーワードを説明するワードや、主キーワードが主語であれば、その文の述語や修飾語などである。

次いで、ステップＳ２１４では、キーワード分析システム５０は、対象ページの識別情報が、自サイトキーワードＤＢ５２において既に存在しているか否かを判断する。このステップＳ２１４の判断が肯定された場合には、ステップＳ２１６に移行し、キーワード分析システム５０は、該当の識別情報のテーブルを更新する。例えば、自サイト内の対象ページの主キーワードが更新された場合には、主キーワードを更新する。また、サブキーワードが追加、変更等された場合には、サブキーワードを更新する。

一方、ステップＳ２１４の判断が否定された場合には、ステップＳ２１８に移行し、キーワード分析システム５０は、対象ページの識別情報と、主キーワード、サブキーワードを関連付けて、自サイトキーワードＤＢ５２に追加する。

ステップＳ２１６、Ｓ２１８の処理が終了すると、図９の全処理が終了するが、その後は、図７に示すように、図９の処理が繰り返し実行される。

（他サイトキーワードＤＢ作成処理（Ｓ３００））
次に、ステップＳ３００の他サイトキーワードＤＢ作成処理について説明する。本処理は、キーワード分析システム５０が、他サイトキーワードＤＢ５４（図４（ｂ）参照）を作成する処理であり、図１０のフローチャートに沿って実行される。

図１０の処理では、まず、ステップＳ３０２において、キーワード分析システム５０は、インターネット上の他サイトで人気となっているキーワードを収集する。他サイトで人気となっているキーワードとは、他サイトで入力（登録）される頻度の高いワードであり、例えば、検索サービスなどへの入力が多いワードや、ＳＮＳサイトにおいて多く書き込まれている（つぶやかれている）ワードなどである。キーワード分析システム５０は、検索ワードのランキング上位のものやＳＮＳサイトでトレンドとなっているワードなどを、他サイトで人気となっているキーワードとして収集する。

次いで、ステップＳ３０４では、キーワード分析システム５０は、収集されたキーワードを主キーワードとして、インターネット上で検索し、主キーワードに関連するワード（付随するワード）を「サブキーワード」として抽出する。

次いで、ステップＳ３０６では、キーワード分析システム５０は、主キーワードと、サブキーワードを関連付けた、他サイトキーワードＤＢ５４を作成する。この場合、時刻情報として、主キーワードが収集された時刻を格納し、主キーワードとサブキーワードとを関連付けて他サイトキーワードＤＢ５４に格納する。なお、既に他サイトキーワードＤＢ５４に格納されている主キーワードと同一の主キーワードが抽出された場合には、キーワード分析システム５０は、既存の情報のうち、時刻情報とサブキーワードのみを更新すればよい。

次いで、ステップＳ３０８では、キーワード分析システム５０は、他サイトキーワードＤＢ５４の時刻情報が、特定期間（例えば１日）より過去である情報があるか否かを判断する。このステップＳ３０８の判断が肯定された場合には、ステップＳ３１０に移行し、キーワード分析システム５０は、該当する情報を削除する。このようにすることで、他サイトキーワードＤＢ５４に格納されている古い情報を適切なタイミングで削除することができる。その後は、図１０の全処理を終了する。一方、ステップＳ３０８の判断が否定された場合には、ステップＳ３１０を経ずに、図１０の全処理を終了する。

なお、図１０の処理は、図７に示すように繰り返し実行される。

（メイン処理（Ｓ４００））
次に、ステップＳ４００のメイン処理について説明する。本処理は、ログシステム４０、話題性分析システム６０、及びオートスケール制御システム７０が実行する処理であり、図１１のフローチャートに沿った処理が実行される。

図１１の処理では、まずステップＳ４１０において、ログシステム４０が、自サイトアクセス数ＤＢ作成処理を実行する。具体的には、ログシステム４０は、図１２のフローチャートに沿った処理を実行する。

（自サイトアクセス数ＤＢ作成処理（Ｓ４１０））
図１２の処理では、ステップＳ４１２において、ログシステム４０が、サービス提供部１０のロードバランサ１２、仮想サーバ１４からアクセスログを取得し、ログ情報４２に蓄積する。

次いで、ステップＳ４１４では、ログシステム４０は、単位時間（例えば、１分）あたりの各ページへのアクセス数をアクセスログからカウントする。次いで、ステップＳ４１６では、ログシステム４０は、ページの情報と、収集したカウント値（アクセス数）を関連付けて、自サイトアクセス数ＤＢ４４に格納する。

以上のように、図１２の処理が終了すると、図１１のステップＳ４２０に移行する。

図１１のステップＳ４２０に移行すると、話題性分析システム６０は、自サイトアクセス数ＤＢ４４を参照し、自サイトへのアクセス数の状況を監視する。次いで、ステップＳ４３０では、話題性分析システム６０は、アクセス数が予め定められている数以上上昇しているか否かを判断する。このステップＳ４３０の判断が否定された場合には、ステップＳ４１０に戻る。一方、ステップＳ４３０の判断が肯定された場合、すなわち自サイトへのアクセス集中が生じ始めている場合には、ステップＳ４４０に移行する。

ステップＳ４４０に移行すると、話題性分析システム６０は、注目キーワードＤＢ作成処理を実行する。具体的には、話題性分析システム６０は、図１３のフローチャートに沿った処理を実行する。

（注目キーワードＤＢ作成処理（Ｓ４４０））
図１３の処理では、ステップＳ４４２において、話題性分析システム６０は、自サイトキーワードＤＢ５２と他サイトキーワードＤＢ５４の、主キーワード、サブキーワードの類似度を算出する。この場合、話題性分析システム６０は、一例として、主キーワードに含まれる文字の一致度と、サブキーワードに含まれる文字の一致度とを求め、これらに基づいて類似率を算出することができる。

次いで、ステップＳ４４４では、話題性分析システム６０が、類似度が所定の閾値（例えば８０％）以上となったキーワードの情報を注目キーワードＤＢ６２に蓄積する。この場合、注目キーワードＤＢ６２には、類似度と、他サイトに存在する主キーワード（他キーワード）と、他キーワードに類似する自サイトに存在する主キーワード（自キーワード）と、が蓄積されることになる。

以上のようにして、図１３の処理が終了すると、図１１のステップＳ４５０に移行する。なお、図１３の処理は、自サイトへのアクセス数が上昇したときに行われるので（Ｓ４３０：肯定）、自サイトへのアクセス集中が予想されるタイミングにおける注目キーワードを注目キーワードＤＢ６２に格納することができる。

図１１のステップＳ４５０に移行すると、話題性分析システム６０は、他サイト話題性情報ＤＢ作成処理を実行する。具体的には、話題性分析システム６０は、図１４のフローチャートに沿った処理を実行する。

（他サイト話題性情報ＤＢ作成処理（Ｓ４５０））
図１４の処理の前提として、インターネット上の他サイト（ＳＮＳやブログサイト）のうち、話題性分析システム６０が監視対象とするサイトは、監視サイト一覧に登録されているものとする。

図１４の処理では、ステップＳ４５２において、話題性分析システム６０が、監視サイト一覧に登録されているサイトから注目キーワードＤＢ６２に蓄積されている他キーワード（注目キーワード）を検索する。なお、監視対象がＳＮＳである場合には、ＳＮＳの検索機能を利用し、ブログサイトである場合には、ブログのポータルサイトの検索機能を利用することができる。また、監視対象が検索サイトであれば、検索サイトにおいて検索需要のあるキーワードを取得するようにすればよい。

次いで、ステップＳ４５４では、話題性分析システム６０が、検索した他キーワードの単位時間あたりの出現頻度をカウントする。

次いで、ステップＳ４５６では、話題性分析システム６０は、他キーワード毎の出現頻度カウント値を、他キーワードに類似する自キーワードの出現頻度カウント値として集計し、他サイト話題性情報ＤＢ６４に格納する。なお、図１４の処理では、他キーワードの出現頻度を、単位時間ごとに所定回数カウントしているため、カウント値の時系列データが他サイト話題性情報ＤＢ６４に格納されることになる。

以上のようにして、図１４の処理が終了すると、図１１のステップＳ４６０に移行する。

図１１のステップＳ４６０に移行すると、オートスケール制御システム７０は、話題性／アクセス相関ＤＢ作成処理を実行する。具体的には、オートスケール制御システム７０は、図１５のフローチャートの処理を実行する。

（話題性／アクセス相関ＤＢ作成処理（Ｓ４６０））
図１５の処理では、ステップＳ４６２において、オートスケール制御システム７０が、他サイト話題性情報ＤＢ６４の出現頻度カウント値と、自サイトアクセス数ＤＢのアクセス数とから話題性／アクセス相関ＤＢ７４を作成（更新）する。

具体的には、オートスケール制御システム７０は、他サイト話題性情報ＤＢ６４のキーワード（例えば「○○ゲーム」）の出現頻度カウント値ｎと、キーワードに対応する対象の仮想サーバ識別子（例えば「ｖｍ００１」）を抽出する。そして、オートスケール制御システム７０は、自サイトアクセス数ＤＢ４４において、抽出した仮想サーバ識別子（例えば「ｖｍ００１」）のアクセス数の合計値ｍを抽出し、値ｎと値ｍを用いて話題性／アクセス相関ＤＢ７４を更新する。これにより、Ｗｅｂサイトに存在するあるキーワードに類似するキーワードが他サイトで話題になったとき（トレンドになったとき）に、あるキーワードが存在する自サイトへのアクセス数がどの程度増えるかを表す図６（ｂ）のデータベースを更新することができる。

以上のようにして、図１５の処理が終了すると、図１１のステップＳ４７０に移行する。

図１１のステップＳ４７０に移行すると、オートスケール制御システム７０は、スケールアウト／インの実施処理を実行する。具体的には、オートスケール制御システム７０は、図１６のフローチャートに沿った処理を実行する。

（スケールアウト／インの実施処理（Ｓ４７０））
ステップＳ４７２では、オートスケール制御システム７０は、他サイト話題性情報ＤＢ６４のカウンタデータの単位時間毎の差分（増加量、時間的変化）の回帰分析から近未来（所定時間後）の予測カウンタ数を算出する。この場合、図１７に示すようなグラフに基づいて、統計的に予測カウンタ数を算出する。例えば、図１７において●（黒丸）で示すように、単位時間ごとにカウンタデータが増加しているとする。この場合、次に単位時間が経過するタイミングでは、図１７のグラフから、□（白抜き四角）で示すだけのカウンタデータの増加が見込まれる。したがって、オートスケール制御システム７０は、□で示す増加分を現在のカウント値に加算した値を予測カウンタ数とすることができる。

次いで、ステップＳ４７４では、オートスケール制御システム７０は、予測カウンタ数と、話題性／アクセス相関ＤＢ７４（図６（ｂ））及び自サイト負荷相関ＤＢ７２（図６（ａ））から予想負荷率（％）を求める。この場合、オートスケール制御システム７０は、予測カウンタ数と、話題性／アクセス相関ＤＢ７４（図６（ｂ））とを用いて、自サイトへのアクセス数を予測する。そして、オートスケール制御システム７０は、予測した自サイトへのアクセス数と、自サイト負荷相関ＤＢ７２（図６（ａ））とを用いて、自サイトの負荷率（％）を予測する。

なお、ステップＳ４７２、Ｓ４７４では、自キーワードと類似するキーワード（注目キーワード）の他サイトでの出現頻度の変化に基づいて、自サイトへのアクセス数や自サイトの負荷率を予測している。このように、本実施形態では、自サイトに対するアクセス数との相関が高い注目キーワードの出現頻度の変化を利用した予測を行うことで、自サイトへのアクセス数や自サイトの負荷率を適切に予測することが可能となっている。

次いで、ステップＳ４７６では、オートスケール制御システム７０は、予想負荷率が閾値（例えば８０％）を超えているか否かを判断する。このステップＳ４７６の判断が肯定された場合、すなわち、近未来において、仮想サーバ１４のＣＰＵやメモリが過負荷になり、リソースが不足するおそれがある場合には、ステップＳ４７８に移行する。

ステップＳ４７８に移行した場合、オートスケール制御システム７０は、クラウド基盤制御部２０へスケールアウト指示を行う。この場合、クラウド基盤制御部２０は、過負荷になるおそれのある仮想サーバ１４を複製する（スケールアウトする）。

一方、ステップＳ４７６の判断が否定された場合には、ステップＳ４８０に移行する。ステップＳ４８０では、オートスケール制御システム７０は、監視システム２２から送られた仮想サーバの負荷情報が一定時間（例えば３０分）の間、閾値（例えば６０％）以下であるか否かを判断する。すなわち、一定時間の間、リソースが所定以上過多であるか否かを判断する。このステップＳ４８０の判断が否定された場合には、ステップＳ４７２に戻るが、肯定された場合には、ステップＳ４８２に移行する。

ステップＳ４８２に移行した場合、オートスケール制御システム７０は、クラウド基盤制御部２０へスケールイン指示を行う。この場合、クラウド基盤制御部２０は、複製されたが、利用されていない仮想サーバ１４を削減する（スケールアウトする）。

以上のように、図１６の処理が行われた後は、図１１の全処理も終了する。なお、図７に示すように、図１１の処理が終了した後も、図１１の処理は繰り返し実行される。なお、図１１の処理を繰り返す場合、図５（ａ）の注目キーワードＤＢ６２と、他サイト話題性情報ＤＢ６４は、リセットされるものとする。

以上、詳細に説明したように、本実施形態によると、話題性分析システム６０は、他サイト（ＳＮＳやブログサイト）から、自サイトで提供されるサービスに関連するキーワード（自キーワードに類似する他キーワード）の出現頻度カウント値を取得し（Ｓ４５０、図１４）、オートスケール制御システム７０が、他サイト話題性情報ＤＢ６４の出現頻度カウント値が示す、他キーワードの出現数の時間的変化に応じて、Ｗｅｂサイトを運用する仮想サーバ１４をスケールアウトさせる（Ｗｅｂサイトに割り当てるリソースを増加させる）制御を実行する（Ｓ４７８）。この場合、例えば、Ｗｅｂサイトへのアクセス集中が起こり、仮想サーバ１４が過負荷になるおそれがある場合に、過負荷になる前の段階で、仮想サーバ１４をスケールアウトすることができる。このように、本実施形態によれば、いつどのような話題がトレンドになるかが分からない状況でも、他サイトの話題性の変化に応じて、適切なタイミングでスケールアウトを行うことができる。これにより、Ｗｅｂサイトの利用者がアクセスできなくなる事態が発生するのを極力抑制することができるので、Ｗｅｂサイトの管理者のビジネス機会の損失を減らすことができる。また、クラウドサービスが従量課金制であっても、リソースを適切に割り当てることができるので、Ｗｅｂサイトの管理者のコストを適切に抑えることができる。

また、本実施形態では、自サイトで抽出されるキーワード（主キーワードとこれに関連するサブキーワード）、及び他サイトで人気となっているキーワード（主キーワードとこれに関連するサブキーワード）を抽出し、自サイトで抽出されたキーワードに類似する（類似度が閾値以上）他サイトで人気となっているキーワードの出現頻度をカウントする（Ｓ４４０，Ｓ４５０）。このように、自サイトへのアクセス数との相関が高い注目キーワードを特定し、該注目キーワードの出現頻度の変化を利用して自サイトへのアクセス数や自サイトの負荷率を予測することで、適切な予測が可能となっている。

また、本実施形態では、オートスケール制御システム７０は、図１７のグラフを用いて近未来において注目キーワードが出現する回数を予測する（Ｓ４７２）。また、オートスケール制御システム７０は、図６（ｂ）の話題性／アクセス相関ＤＢ７４に基づいて、自サイトへのアクセス数を予測し、更に、図６（ａ）の自サイト負荷相関ＤＢ７２に基づいて、自サイト負荷率（％）を予測する（Ｓ４７４）。そして、オートスケール制御システム７０は、予測した自サイト負荷率に基づいて、クラウド構成管理システム２４に対してスケールアウトの指示を出す（Ｓ４７８）。このように、図１７のグラフや、図６（ｂ）、図６（ａ）のデータベースを用いることで、簡易に自サイト負荷率を予測することが可能である。

また、本実施形態では、オートスケール制御システム７０は、仮想サーバの負荷情報が一定時間の間、閾値（例えば６０％）以下の場合に、クラウド構成管理システム２４に対してスケールインの指示を出す（Ｓ４８２）。これにより、オートスケール制御システム７０は、過去にスケールアウトしたが当分の間利用されない可能性が高い仮想サーバを、適切なタイミングで、スケールインすることができる。

なお、上記実施形態では、図６（ａ）の自サイト負荷相関ＤＢ７２や、図６（ｂ）の話題性／アクセス相関ＤＢ７４をオートスケール制御システム７０が作成又は適宜更新する場合について説明した。しかしながら、これに限らず、両ＤＢは、事前に作成しておいてもよい。この場合、例えば、複数のクラウドサーバにおける平均的な値に基づいて、両ＤＢを作成しておけばよい。

なお、上記実施形態では、注目キーワードと自キーワードとの類似度（図６（ａ）参照）を考慮して、自サイトへのアクセス数を予測することとしてもよい。この場合、例えば、図６（ｂ）の話題性／アクセス相関ＤＢ７４に基づいて予測される自サイトへのアクセス数に対して類似度に基づく補正を行うなどすればよい。

なお、上記実施形態では、オートスケール制御部３０がクラウドサーバ１００内に設けられている場合について説明したが、これに限られるものではない。例えば、クラウドサーバ１００とネットワーク等で接続されている情報処理装置がオートスケール制御部３０を有していてもよい。この場合、情報処理装置は、複数のクラウドサーバ１００のオートスケール制御を行うこととしてもよい。

なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したブログラムが提供される。そのブログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したブログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。

ブログラムを流通させる場合には、例えば、そのブログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、ブログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのブログラムを転送することもできる。

ブログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたブログラムもしくはサーバコンピュータから転送されたブログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からブログラムを読み取り、ブログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接ブログラムを読み取り、そのブログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからブログラムが転送されるごとに、逐次、受け取ったブログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） コンピュータに、
登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせ、
問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う、
処理を実行させるリソース制御ブログラム。
（付記２） 前記特定の情報処理装置により提供されるサービスに関連するキーワードは、前記特定の情報処理装置により提供されるサービスのキーワードとの類似度が予め定められている閾値以上のキーワードであることを特徴とする付記１に記載のリソース制御ブログラム。
（付記３） 前記制御を行う処理において、
前記キーワードの登録数の時間的変化に基づいて、前記特定の情報処理装置により提供されるサービスへのアクセス数の時間的変化を予測し、
予測した前記アクセス数の時間的変化に基づいて、前記リソースの過不足を予測し、
予測した前記リソースの過不足に基づいて、前記リソースの増加又は減少の制御を行う、ことを特徴とする付記１又は２に記載のリソース制御ブログラム。
（付記４） 前記リソースの過不足を予測する処理において、前記リソースが不足することを予測した場合に、
前記制御を行う処理において、前記リソースを増加させる制御を行う、ことを特徴とする付記３に記載のリソース制御ブログラム。
（付記５） 前記制御を行う処理において、所定時間の間、前記リソースが所定以上過多である場合に、前記リソースを減少させる制御を行う、ことを特徴とする付記１〜４のいずれかに記載のリソース制御ブログラム。
（付記６） 前記類似度は、前記特定の情報処理装置により提供されるサービスのキーワード及び該キーワードに関連するワードと、前記特定の情報処理装置により提供されるサービスに関連するキーワード及び該キーワードに関連するワードと、の一致度合に基づく値である、ことを特徴とする付記２に記載のリソース制御ブログラム。
（付記７） コンピュータが、
登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせ、
問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う、
ことを特徴とするリソース制御方法。
（付記８） 登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせる問い合わせ部と、
問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う制御部と、
を備えるリソース制御装置。
（付記９） 前記特定の情報処理装置により提供されるサービスに関連するキーワードは、前記特定の情報処理装置により提供されるサービスのキーワードとの類似度が予め定められている閾値以上のキーワードであることを特徴とする付記８に記載のリソース制御装置。
（付記１０） 前記制御部は、
前記キーワードの登録数の時間的変化に基づいて、前記特定の情報処理装置により提供されるサービスへのアクセス数の時間的変化を予測し、
予測した前記アクセス数の時間的変化に基づいて、前記リソースの過不足を予測し、
予測した前記リソースの過不足に基づいて、前記リソースの増加又は減少の制御を行う、ことを特徴とする付記８又は９に記載のリソース制御装置。
（付記１１） 前記制御部は、前記リソースが不足することを予測した場合に、前記リソースを増加させる制御を行う、ことを特徴とする付記１０に記載のリソース制御装置。
（付記１２） 前記制御部は、所定時間の間、前記リソースが所定以上過多である場合に、前記リソースを減少させる制御を行う、ことを特徴とする付記８〜１１のいずれかに記載のリソース制御装置。
（付記１３） 前記類似度は、前記特定の情報処理装置により提供されるサービスのキーワード及び該キーワードに関連するワードと、前記特定の情報処理装置により提供されるサービスに関連するキーワード及び該キーワードに関連するワードと、の一致度合に基づく値である、ことを特徴とする付記９に記載のリソース制御装置。

６０ 話題性分析システム（問い合わせ部）
７０ オートスケール制御システム（制御部）
１００ クラウドサーバ（リソース制御装置）

Claims (8)

1. コンピュータに、
   登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせ、
   問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う、
   処理を実行させるリソース制御ブログラム。
2. 前記特定の情報処理装置により提供されるサービスに関連するキーワードは、前記特定の情報処理装置により提供されるサービスのキーワードとの類似度が予め定められている閾値以上のキーワードであることを特徴とする請求項１に記載のリソース制御ブログラム。
3. 前記制御を行う処理において、
   前記キーワードの登録数の時間的変化に基づいて、前記特定の情報処理装置により提供されるサービスへのアクセス数の時間的変化を予測し、
   予測した前記アクセス数の時間的変化に基づいて、前記リソースの過不足を予測し、
   予測した前記リソースの過不足に基づいて、前記リソースの増加又は減少の制御を行う、ことを特徴とする請求項１又は２に記載のリソース制御ブログラム。
4. 前記リソースの過不足を予測する処理において、前記リソースが不足することを予測した場合に、
   前記制御を行う処理において、前記リソースを増加させる制御を行う、ことを特徴とする請求項３に記載のリソース制御ブログラム。
5. 前記制御を行う処理において、所定時間の間、前記リソースが所定以上過多である場合に、前記リソースを減少させる制御を行う、ことを特徴とする請求項１〜４のいずれか一項に記載のリソース制御ブログラム。
6. 前記類似度は、前記特定の情報処理装置により提供されるサービスのキーワード及び該キーワードに関連するワードと、前記特定の情報処理装置により提供されるサービスに関連するキーワード及び該キーワードに関連するワードと、の一致度合に基づく値である、ことを特徴とする請求項２に記載のリソース制御ブログラム。
7. コンピュータが、
   登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせ、
   問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う、
   ことを特徴とするリソース制御方法。
8. 登録されたデータの参照を許容する制御を行う情報処理装置に対して、前記情報処理装置への特定の情報処理装置により提供されるサービスに関連するキーワードの登録状況を問い合わせる問い合わせ部と、
   問い合わせた前記登録状況が示す、前記キーワードの登録数の時間的変化に応じて、前記特定の情報処理装置に割り当てるリソースの増加又は減少の制御を行う制御部と、
   を備えるリソース制御装置。

Images