(57)【要約】【課題】予想される処理能力に応じてサーバを準備可能な情報処理システム、情報処理装置及びプログラムを提供する。【解決手段】サーバプロビジョニングシステム１は、複数のサーバ４１，…，４ｎと、複数のサーバ４１，…，４ｎのうちサービスの提供に要求されるサーバの予想数を算出するキャパシティプランニングサーバ２と、予想数に基づいてサービスの提供に割り当てるサーバの数を決定する負荷分散管理サーバ３と、を含む情報処理システムであって、キャパシティプランニングサーバ２は、サービスに関する公開情報のリーチ数に基づいてサービスに要求されるリクエスト処理数を算出する第１算出部と、リクエスト処理数に基づいてサービスに要求されるサーバの予想数を算出する第２算出部と、を備える。【選択図】図１
2019164543.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバと、前記複数のサーバのうちサービスの提供に要求されるサーバの予想数を算出する情報処理装置と、前記予想数に基づいて前記サービスの提供に割り当てるサーバの数を決定する管理装置と、を含む情報処理システムであって、
前記情報処理装置は、
前記サービスに関する公開情報のリーチ数に基づいて前記サービスに要求されるリクエスト処理数を算出する第１算出部と、
前記リクエスト処理数に基づいて前記サービスに要求されるサーバの予想数を算出する第２算出部と、
を備える情報処理システム。
【請求項２】
前記管理装置は、前記サービスの提供に割り当てられたサーバに対するリクエスト数を取得する取得部を備え、
前記予想数及び前記リクエスト数に基づいて前記サービスの提供に割り当てるサーバの数を決定する
請求項１に記載の情報処理システム。
【請求項３】
前記情報処理装置は、前記公開情報のリーチ数の有効期限を設定可能な設定部を備える
請求項１又は２に記載の情報処理システム。
【請求項４】
前記第２算出部は、所定時間周期で前記予想数を更新する
請求項１から３のいずれか一項に記載の情報処理システム。
【請求項５】
複数のサーバのうちサービスの提供に要求されるサーバの予想数を算出する情報処理装置であって、
前記サービスに関する公開情報のリーチ数に基づいて前記サービスに要求されるリクエスト処理数を算出する第１算出部と、
前記リクエスト処理数に基づいて前記サービスに要求されるサーバの予想数を算出する第２算出部と、
を備える情報処理装置。
【請求項６】
サービスに関する公開情報のリーチ数に基づいて前記サービスに要求されるリクエスト処理数を算出する機能と、
前記リクエスト処理数に基づいて前記サービスに要求されるサーバの予想数を算出する機能と、
をコンピュータに実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム、情報処理装置及びプログラムに関する。
【背景技術】
【０００２】
従来、Ｉａａｓ（Infrastructure  as  a  Service）と呼ばれるクラウドサービスが知られている。Ｉａａｓは、サーバとして機能することが可能なコンピュータシステムのインフラストラクチャをインターネット経由のサービスとして提供する。
【０００３】
Ｉａａｓの特徴として、サーバを用いて提供されるサービスに対するリクエスト数の変化のように、コンピュータシステムに要求される処理能力の変化に対応して処理能力を拡張または縮小することが可能になっている。このような処理能力の拡張又は縮小を自動的に行うためのオートスケーリング技術が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のオートスケーリング技術は、実際に発生したリクエスト数の増加に応じて事後的に新たにサーバを割り当てて動作させる等、対症療法的なものであった。このため、リクエスト数の急激な増減に関わる事象に伴って要求される処理能力の増減に対応するには不十分であった。一方、どのような事象にも対応可能な処理能力を事前に準備しようとすると、実際には必要ない過剰な処理能力を提供するためのサーバの維持コストが生じて非効率になるという問題があった。従って、予想される処理能力に応じてサーバを準備するための方法が求められていた。
【０００５】
本発明は、上記に鑑みてなされたものであって、予想される処理能力に応じてサーバを準備可能な情報処理システム、情報処理装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した課題を解決し、目的を達成するために、本発明は、複数のサーバと、前記複数のサーバのうちサービスの提供に要求されるサーバの予想数を算出する情報処理装置と、前記予想数に基づいて前記サービスの提供に割り当てるサーバの数を決定する管理装置と、を含む情報処理システムであって、前記情報処理装置は、前記サービスに関する公開情報のリーチ数に基づいて前記サービスに要求されるリクエスト処理数を算出する第１算出部と、前記リクエスト処理数に基づいて前記サービスに要求されるサーバの予想数を算出する第２算出部と、を備えることを特徴とする。
【発明の効果】
【０００７】
本発明によれば、予想される処理能力に応じてサーバを準備することができるという効果を奏する。
【図面の簡単な説明】
【０００８】
【図１】図１は、第１の実施の形態にかかるサーバプロビジョニングシステムの構成を示す図である。
【図２】図２は、コンピュータのハードウェア構成例を示す図である。
【図３】図３は、第１の実施の形態においてサーバ群に含まれる複数のサーバの割り当て制御に関する機能構成例を示す図である。
【図４】図４は、マーケティング情報に含まれる情報の一例を示す図である。
【図５】図５は、サーバ装置処理能力情報に含まれる情報の一例を示す図である。
【図６】図６は、キャパシティプラン情報に含まれる情報の一例を示す図である。
【図７】図７は、設定部によるキャパシティプランニング設定の画面に含まれる項目例を示す図である。
【図８】図８は、キャパシティプラン作成処理部の処理の流れの一例を示す図である。
【図９】図９は、負荷分散管理部の処理の流れの一例を示す図である。
【図１０】図１０は、第２の実施の形態においてサーバ群に含まれる複数のサーバの割り当て制御に関する機能構成例を示す図である。
【図１１】図１１は、係数算出部の処理の流れの一例を示す図である。
【発明を実施するための形態】
【０００９】
以下に添付図面を参照して、情報処理システムの実施の形態を詳細に説明する。
【００１０】
（第１の実施の形態）
図１は、第１の実施の形態にかかるサーバプロビジョニングシステムシステム１の構成を示す図である。サーバプロビジョニングシステムシステム１は、キャパシティプランニングサーバ２と、負荷分散管理サーバ３とを備える情報処理システムである。サーバプロビジョニングシステムシステム１は、サーバ群４に含まれる複数のサーバ４１，…，４ｎのうち、サービスの提供のために準備されるサーバの数を決定する。ｎは、サーバ群４に含まれるサーバの数を示す。ｎは、自然数である。
【００１１】
サーバ群４に含まれる複数のサーバ４１，…，４ｎは、共通のストレージサービス提供部５と通信可能に設けられている。ストレージサービス提供部５は、１又は複数のコンピュータで構成され、ストレージサービスとして機能するシステムである。ストレージサービス提供部５は、ストレージサーバを含んでいても良いし、データベース（ＤＢ：Ｄａｔａ  Ｂａｓｅ）として機能するサーバを含んでいても良いし、その他の参照可能なデータを保持するサーバを含んでいても良い。
【００１２】
サーバ群４に含まれる複数のサーバ４１，…，４ｎは、ロードバランサー６を介して外部の通信回線７と接続されている。ロードバランサー６は、通信回線７を介して複数の端末８１，…，８ｍと接続されている。ｍは、端末の数を示す。ｍは、自然数である。ロードバランサー６は、サーバ群４に含まれる複数のサーバ４１，…，４ｎのうち、同一のサービスを提供する１以上のサーバを通信回線７側から見て単一の宛先の構成となる識別情報で管理し、サーバが複数である場合に当該宛先のリクエストを分散させる。識別情報とは、サービス毎に割り当てられた固有の情報であり、例えばＩＰやドメインである。
【００１３】
通信回線７は、ロードバランサー６と複数の端末８１，…，８ｍとを通信可能に接続する通信網からなる。通信回線７は、例えばインターネットであるが、これに限られるものでない。例えば、サーバ群４に含まれる複数のサーバ４１，…，４ｎにより提供されるサービスの為に構築された専用の通信網であっても良い。
【００１４】
複数の端末８１，…，８ｍは、ロードバランサー６に対してサービスのリクエストを行う。複数の端末８１，…，８ｍからのサービスのリクエストは、通信回線７を介してロードバランサー６に送信される。ロードバランサー６は、複数の端末８１，…，８ｍからのサービスのリクエストをサーバ群４に含まれる１以上のサーバに振り分ける。リクエストが振り分けられるサーバは、サービスの提供のために予め準備され、稼働中のサーバである。
【００１５】
キャパシティプランニングサーバ２、負荷分散管理サーバ３、サーバ群４に含まれる複数のサーバ４１，…，４ｎの各々、ストレージサービス提供部５を構成するＤＢサーバやストレージサーバ、ロードバランサー６及び複数の端末８１，…，８ｍの各々は、コンピュータである（図２参照）。
【００１６】
図２は、コンピュータのハードウェア構成例を示す図である。第１の実施の形態のコンピュータは、ＣＰＵ１１（Central  Processing  Unit）などの制御装置と、ＲＯＭ１２（Read  Only  Memory）やＲＡＭ１３（Random  Access  Memory）などの記憶装置と、ＨＤＤ１４（Hard  Disk  Drive）などの外部記憶装置と、キーボードやマウスなどの入力装置を含む操作部１５と、ＮＩＣ（Network  Interface  Controller）を含む通信部１６と、ディスプレイ装置などの表示部１７等を備えており、通常のコンピュータを利用したハードウェア構成となっている。
【００１７】
キャパシティプランニングサーバ２、負荷分散管理サーバ３、サーバ群４に含まれる複数のサーバ４１，…，４ｎの各々、ストレージサービス提供部５を構成するＤＢサーバやストレージサーバ、ロードバランサー６及び複数の端末８１，…，８ｍの各々はそれぞれ、図２を参照して説明したハードウェア構成を備える。ただし、操作部１５及び表示部１７については、個々のコンピュータに個別に設けられていなくても良い。例えば、サーバ群４に含まれる複数のサーバ４１，…，４ｎの各々は、切替機を介して操作部１５及び表示部１７を共有することができる。
【００１８】
キャパシティプランニングサーバ２、負荷分散管理サーバ３、サーバ群４に含まれる複数のサーバ４１，…，４ｎの各々、ストレージサービス提供部５を構成するＤＢサーバやストレージサーバ、ロードバランサー６及び複数の端末８１，…，８ｍの各々はそれぞれ、処理内容に応じたソフトウェア・プログラム（以下、単に「プログラム」と記載）をＨＤＤ１４に記憶している。
【００１９】
図３は、第１の実施の形態においてサーバ群４に含まれる複数のサーバ４１，…，４ｎの割り当て制御に関する機能構成例を示す図である。キャパシティプランニングサーバ２は、キャパシティプラン作成処理部２１及び設定部２２として機能する。また、キャパシティプランニングサーバ２は、これらの機能に関するデータとして、サーバ装置処理能力情報２３、マーケティング情報２４及び設定情報２５を有している。これらの機能及び情報に対応するプログラム及びデータは、キャパシティプランニングサーバ２が備えるＨＤＤ１４に記憶されている。キャパシティプランニングサーバ２が備えるＣＰＵ１１は、ＨＤＤ１４からプログラム及びデータを読み出してキャパシティプラン作成処理部２１及び設定部２２として機能する。
【００２０】
キャパシティプラン作成処理部２１は、サービスに関する公開情報のリーチ数に基づいてサービスに要求されるリクエスト処理数を算出する第１算出部としての機能を含む。具体的には、キャパシティプラン作成処理部２１は、マーケティング情報２４を読み出して、サービスに関する公開情報のリーチ数を取得する。キャパシティプラン作成処理部２１は、マーケティング情報２４から得られたリーチ数に基づいてサービスに要求されるリクエスト処理数を算出する。
【００２１】
図４は、マーケティング情報２４に含まれる情報の一例を示す図である。マーケティング情報２４には、例えば、「対象」、「手段」、「開始」、「終了」、「リーチ数」、「発売日」等の項目の各々に応じたパラメータを含むレコードが登録されている。
【００２２】
「対象」は、サービスにより提供される対象を示すパラメータである。具体的には、例えばサービスにより販売される商品名が「対象」のパラメータになる。第１の実施の形態では、サービスの提供は「対象」毎に行われる。「手段」は、公開情報がヒトに認知されるための手段を示すパラメータである。例えば、「ＴＶ広告」は、テレビ放送のコマーシャルとして提供される広告をさす。また、「ＯＯＨ」は、電車内の中吊り広告、駅構内の広告、車体ラッピング等の交通広告、野立て看板、屋上看板、大型ビジョン等の屋外広告、アドバルーンや飛行船を用いた広告等を含むOut  Of  Home  mediaをさす。「開始」は、公開情報の公開が開始する年月日を示すパラメータである。「終了」は、公開情報の公開が終了する年月日を示すパラメータである。「リーチ数」は、公開情報のリーチ数を示すパラメータである。なお、リーチ数とは、公開情報が提供されたユーザの人数である。「発売日」は、「対象」のパラメータが示す商品等、サービスにより提供される販売物が発売される年月日を示すパラメータである。
【００２３】
図４における１行が１つのレコードである。１つのレコードは、１つの公開情報と、当該公開情報のリーチ数とを含むマーケティング情報のレコードである。例えば、「商品Ａ（発売日：２０１７年１０月１日）」を対象とする「ＴＶ広告」が公開情報として「２０１７年９月１日」から提供開始され、「２０１７年９月３０日」まで提供されたことによって、「８００」人のユーザに提供されたことを示すマーケティング情報のレコードが、図４における１番目のレコードとして例示されている。また、図４における２番目のレコードは、１番目のレコードと同様の「対象」、「開始」、「終了」、「発売日」であり、「手段」が「ＯＯＨ」であって、「リーチ数」が２００（人）であることを示すマーケティング情報のレコードである。
【００２４】
キャパシティプラン作成処理部２１は、マーケティング情報２４から得られたリーチ数に基づいてサービスに要求されるリクエスト処理数を算出する。第１の実施の形態では、キャパシティプラン作成処理部２１は、マーケティング情報２４から得られたリーチ数をリクエスト処理数として算出する。例えば、図４における１番目のレコードに含まれるリーチ数「８００」に基づいたリクエスト処理数は、「８００」である。また、図４における２番目のレコードに含まれるリーチ数「２００」に基づいたリクエスト処理数は、「２００」である。従って、「商品Ａ」に関するサービスの提供に要求されるリクエスト数は、１番目の「ＴＶ広告」のリーチ数に基づいて算出された「８００」と２番目の「ＯＯＨ」のリーチ数に基づいて算出された「２００」とを足し合わせた「１０００」である。また、図４に例示するマーケティング情報２４に基づいて、「商品Ｂ」に関するサービスの提供に要求されるリクエスト数は、「７００」になる。
【００２５】
また、キャパシティプラン作成処理部２１は、リクエスト処理数に基づいてサービスに要求されるサーバの予想数を算出する第２算出部としての機能を含む。具体的には、キャパシティプラン作成処理部２１は、サーバ装置処理能力情報２３を読み出してサーバの同時処理能力を示す情報を取得する。キャパシティプラン作成処理部２１は、１つの「対象」のリクエスト処理数をサーバの同時処理能力で割る除算を行い、算出された値に基づいてサーバの予想数を導出する。当該除算で算出された値に小数点以下の端数があった場合、キャパシティプラン作成処理部２１は、値を切り上げてサーバの予想数を導出する。
【００２６】
図５は、サーバ装置処理能力情報２３に含まれる情報の一例を示す図である。サーバ装置処理能力情報２３には、例えば、「サーバ種類」、「同時処理能力」等の項目の各々に応じたパラメータを含むレコードが登録されている。
【００２７】
「サーバ種類」は、サーバ毎の処理能力の異同を識別するために付される識別用のパラメータである。「同時処理能力」は、「サーバ種類」に該当するサーバの同時処理能力を示すパラメータである。ここで、サーバの同時処理能力とは、ある単位時間内の時間平均リクエスト数に対する処理能力であり、厳密な意味での「同時」ではない。単位時間は、例えば、ロードバランサー６から見て「同時間帯のリクエスト」として扱われるリクエストの受付単位時間である。言い換えれば、厳密な意味で「同時」でなくとも、単位時間内に複数のリクエストがあった場合、当該複数のリクエストは、サーバの同時処理能力を必要とするリクエストである。図５に例示するサーバ装置処理能力情報２３は、「サーバＡ」の同時処理能力が「２５０」であることを示している。
【００２８】
第１の実施の形態における１つのサーバは、ハードウェア的な１つのサーバであっても良いし、ソフトウェア的な１つのサーバであっても良い。ハードウェア的な１つのサーバとは、物理的に独立した１つのコンピュータ装置で構成されるサーバをさす。ブレードサーバのように、１つの筐体内に複数の独立したコンピュータのハードウェア構成を設けることが可能な場合、１つのブレードサーバがハードウェア的な１つのサーバに相当する。ソフトウェア的な１つのサーバとは、ハードウェア的な１つのサーバに複数のＯＳ（Operating  System）を用いた複数のサーバとしての機能を与える仮想化ソフトウェアによって構築された当該複数のサーバのうちの１つをさす。すなわち、サーバの予想数及びサーバの数は、これらの仕組みを用いて予め用意された機能的な意味でのサーバ（ハードウェア及びソフトウェアを含む）の数である。
【００２９】
第１の実施の形態の説明では、サーバ群４に含まれる複数のサーバ４１，…，４ｎが全て「サーバＡ」で統一されている場合を例として説明するが、これはあくまで一例であってこれに限られるものでなく、適宜変更可能である。例えば、サービス毎に用いられるサーバの種類が異なっていても良いし、１つのサービスに対して同時処理能力が異なる複数種類のサーバを併用しても良い。
【００３０】
キャパシティプラン作成処理部２１は、１つの「対象」のリクエスト処理数をサーバの同時処理能力で割る除算を行い、算出された値に基づいてサーバの予想数を導出する。例えば、図４に例示したマーケティング情報２４における「商品Ａ」に関するサービスの提供に要求されるリクエスト数は、「１０００」である。これを、サーバ装置処理能力情報２３における「サーバＡ」の同時処理能力である「２５０」で割ると、「４」になる。従って、キャパシティプラン作成処理部２１は、サーバの予想数として「４」を算出する。このように、キャパシティプラン作成処理部２１として機能するキャパシティプランニングサーバ２は、サービスの提供に要求されるサーバの予想数を算出する情報処理装置として機能する。
【００３１】
キャパシティプラン作成処理部２１は、算出されたサーバの予想数を示す情報を、当該サーバの予想数に対応するサーバが要求されるサービスを示す情報と対応付けて負荷分散管理サーバ３に送信する。負荷分散管理サーバ３は、サーバの予想数を示す情報と、当該サーバの予想数に対応するサーバが要求されるサービスとを示す情報とが対応付けられた情報は、キャパシティプラン情報３３に含まれる情報として、負荷分散管理サーバ３のＨＤＤ１４に記憶される。
【００３２】
図６は、キャパシティプラン情報３３に含まれる情報の一例を示す図である。キャパシティプラン情報３３には、例えば、「対象」、「リクエスト数」、「割り当てサーバ」、「サーバ数」、「更新間隔」、「更新時刻」等の項目の各々に応じたパラメータを含むレコードが登録されている。
【００３３】
「対象」は、マーケティング情報２４の「対象」と同様のパラメータである。「リクエスト数」は、キャパシティプラン作成処理部２１によって算出された、「対象」に関するサービスの提供に要求されるリクエスト数を示すパラメータである。「割り当てサーバ」は、「対象」に関するサービスの提供に割り当てられるサーバの種類を示すパラメータである。「割り当てサーバ」のパラメータが示すサーバの種類は、サーバ装置処理能力情報２３における「サーバ種類」のパラメータのいずれかに該当する。「サーバ数」は、「対象」に関するサービスの提供に割り当てられるサーバの予想数を示すパラメータである。「更新間隔」は、このパラメータを含むレコード、すなわち、１つのキャパシティプラン情報のレコードが更新される時間間隔を示すパラメータである。第１の実施の形態において、「更新間隔」は、予想数を更新する「所定時間周期」を示すパラメータとして機能する。「更新時刻」は、このパラメータを含むレコードが更新された最後の時刻を示すパラメータである。
【００３４】
図６に例示するキャパシティプラン情報３３の１番目のレコードは、「商品Ａ」に関するサービスの提供のために割り当てられる「サーバＡ」の数が「４」であること、このレコードの最終更新時刻が「２０１７年１０月３１日０時０分０秒」であること、「２４時間」間隔でレコードが更新されることを示している。
【００３５】
キャパシティプラン作成処理部２１は、予め設定された更新間隔でキャパシティプラン情報３３を更新する。また、キャパシティプラン作成処理部２１は、キャパシティプラン情報３３の生成及び更新において、マーケティング情報の有効期間の設定を参照してマーケティング情報のリーチ数の採用可否を決定する。これらの設定は、設定部２２の機能による。
【００３６】
図７は、設定部２２によるキャパシティプランニング設定の画面に含まれる項目例を示す図である。設定部２２は、サービスに関する公開情報として機能するマーケティング情報２４のリーチ数の有効期限を設定可能に設けられている。例えば図７の例では、「マーケティング情報の有効期間」として「３０日」が設定されている。これは、マーケティング情報２４に含まれる「終了」のパラメータが示す年月日が、キャパシティプラン作成処理部２１によるキャパシティプランの生成又は更新のタイミング（年月日）から「３０日」内である場合、そのマーケティング情報のレコードが含む「リーチ数」が有効であることを示している。言い換えれば、設定されている有効期限（３０日）を過ぎた場合、そのマーケティング情報のレコードが含む「リーチ数」が無効になることを示している。
【００３７】
また、設定部２２は、キャパシティプラン情報３３の更新間隔等、サーバ群４に含まれる複数のサーバ４１，…，４ｎの割り当てに関するさらなる設定項目を有していても良い。図７の例では、「キャパシティプランの更新間隔」として「２４時間」が設定されている。キャパシティプラン作成処理部２１は、設定された更新間隔の時間に対応してキャパシティプラン情報３３の「更新間隔」のパラメータを更新する。設定部２２の機能により設定された内容を示す情報は、設定情報２５としてキャパシティプランニングサーバ２が備えるＨＤＤ１４に記憶されている。キャパシティプラン作成処理部２１は、設定情報２５を読み出してリーチ数の有効期限やキャパシティプランの更新間隔の設定等、サービスの提供に割り当てられるサーバの予想数の算出に関する情報を取得する。
【００３８】
図８は、キャパシティプラン作成処理部２１の処理の流れの一例を示す図である。図８に例示するキャパシティプラン作成処理部２１の処理は、例えば「更新間隔」として定められた所定時間周期で繰り返し行われる。キャパシティプラン作成処理部２１は、設定情報２５を読み出してサービスの提供に割り当てられるサーバの予想数の算出に関する情報を取得する（ステップＳ１）。ステップＳ１で取得される情報は、少なくともリーチ数の有効期限を含む。キャパシティプラン作成処理部２１は、マーケティング情報２４を読み出してマーケティング情報のレコードを取得する（ステップＳ２）。
【００３９】
キャパシティプラン作成処理部２１は、ステップＳ１で取得した有効期限に対応する「終了」前の時間帯（対象時間帯）に該当するマーケティング情報のレコードを１つの要因として選択する（ステップＳ３）。なお、マーケティング情報２４に含まれるマーケティング情報のレコードが対象時間帯に該当するか否かのふるい分けは、ステップＳ２で行っても良いし、ステップＳ３で行っても良い。キャパシティプラン作成処理部２１は、ステップＳ３で選択されたマーケティング情報のレコードに含まれている「リーチ数」のパラメータに基づいて、当該レコードに含まれる「対象」に関するサービスの提供に要求されるリクエスト数（時間平均リクエスト数）を算出する（ステップＳ４）。
【００４０】
キャパシティプラン作成処理部２１は、対象時間帯に含まれる全ての要因のリクエスト数を算出したか判定する（ステップＳ５）。全ての要因のリクエスト数を算出していない場合（ステップＳ５；Ｎｏ）、ステップＳ３に戻ってリクエスト数が未算出の要因についてステップＳ３，Ｓ４の処理を行う。全ての要因のリクエスト数を算出した場合（ステップＳ５；Ｙｅｓ）、サービス毎の合計リクエスト数を算出する（ステップＳ６）。ステップＳ６で算出された合計リクエストに対応して割り当てられるサーバの数（予想数）を算出する（ステップＳ７）。
【００４１】
次に、算出されたサーバ予想数に基づいた負荷分散管理サーバ３の動作について説明する。負荷分散管理サーバ３は、予想数に基づいてサービスの提供に割り当てるサーバの数を決定する管理装置として機能する。図３に例示するように、負荷分散管理サーバ３は、リクエスト処理能力情報取得部３１及び負荷分散管理部３２として機能する。また、負荷分散管理サーバ３は、これらの機能に関するデータとして、上述したキャパシティプラン情報３３を有している。これらの機能及び情報に対応するプログラム及びデータは、負荷分散管理サーバ３が備えるＨＤＤ１４に記憶されている。負荷分散管理サーバ３が備えるＣＰＵ１１は、ＨＤＤ１４からプログラム及びデータを読み出してリクエスト処理能力情報取得部３１及び負荷分散管理部３２として機能する。
【００４２】
リクエスト処理能力情報取得部３１は、サービスの提供に割り当てられたサーバに対するリクエスト数をロードバランサー６から取得する取得部として機能する。具体的には、ロードバランサー６は、サービス毎のリクエスト数を監視するリクエスト処理能力監視部６１を有する。リクエスト処理能力監視部６１は、リクエスト数をサービス毎にカウントする。サービス毎のリクエスト数は、例えば複数の端末８１，…，８ｍからのアクセス要求に含まれる識別情報に基づいてカウントされる。リクエスト処理能力情報取得部３１は、リクエスト処理能力監視部６１によりカウントされたリクエスト数をロードバランサー６から取得する。ここで、リクエスト処理能力情報取得部３１が取得するリクエスト数は、同時最大リクエスト数である。同時最大リクエスト数は、あるサービスに関して生じた単位時間内の時間平均リクエスト数のうち、最大の時間平均リクエスト数である。この単位時間は、同時処理能力を求めるために用いられる単位時間と同一である。
【００４３】
負荷分散管理部３２は、サーバ群４に含まれる複数のサーバ４１，…，４ｎのうち、サービスの提供に割り当てるサーバの数を決定する。具体的には、負荷分散管理部３２は、キャパシティプラン作成処理部２１により算出されたサービスに要求されるサーバの予想数に基づいて、当該サービスにサーバを割り当てる。
【００４４】
第１の実施の形態では、予想数に基づいたサーバの割り当てとして、サーバ・プロビジョニングが行われる。サーバ・プロビジョニングにより、サーバ群４に含まれる複数のサーバ４１，…，４ｎのうち、予定数に対応する数のサーバは、サービスに必要なソフトウェア・プログラムのロード、ロードバランサー６との通信の準備等が完了した状態で、ホットスタンバイ又はウォームスタンバイで待機する。
【００４５】
また、負荷分散管理部３２は、リクエスト処理能力情報取得部３１により取得されたリクエスト数に基づいて、サービスの提供に割り当てるサーバの数を決定する。具体的には、負荷分散管理部３２は、リクエスト処理能力情報取得部３１により取得されたリクエスト数と、予想数に基づいて予めサービスに割り当てられたサーバによる同時処理能力とを比較する。負荷分散管理部３２は、当該同時処理能力と当該リクエスト数との大小関係に基づいて、サービスの提供に割り当てるサーバの数を維持又は増減させる。
【００４６】
図６に例示するキャパシティプラン情報３３の１番目のレコードによれば、「商品Ａ」に関するサービスの提供のために割り当てられる「サーバＡ」の数は「４」である。「サーバＡ」の数が「４」である場合の同時処理能力は、図５に例示するサーバ装置処理能力情報２３が示す「サーバＡ」の同時処理能力によれば、２５０×４＝１０００になる。これに対し、リクエスト処理能力情報取得部３１により取得されたリクエスト数が例えば「７５０」であった場合、「サーバＡ」１つ分の処理能力が過剰になっていることを示す。この例の場合、負荷分散管理部３２は、「商品Ａ」に関するサービスの提供のために割り当てられる「サーバＡ」の数を「４」から「３」に減らす。減らされた１つのサーバは、例えばコールドスタンバイで待機するか、別のサービスに割り当てられる。一方、リクエスト処理能力情報取得部３１により取得されたリクエスト数が例えば「１０００」を大幅に超えていた場合、予想数に対応した数のサーバによる同時処理能力を大幅に超えていることになる。この場合、負荷分散管理部３２は、同時処理能力に対するリクエスト数の超過の度合いに応じて「商品Ａ」に関するサービスの提供のために割り当てられる「サーバＡ」の数を増やす。また、負荷分散管理部３２は、リクエスト処理能力情報取得部３１により取得されたリクエスト数が「１０００」程度であれば、予想数に対応するサーバの数を維持させる。このように、負荷分散管理部３２は、予想数及びリクエスト数に基づいて、サービスの提供に割り当てるサーバの数を決定する機能を有する。
【００４７】
図９は、負荷分散管理部３２の処理の流れの一例を示す図である。負荷分散管理部３２は、負荷分散管理部３２は、リクエスト処理能力情報取得部３１により取得された、サービスに対するリクエスト数（実際のリクエスト数）と、予想数に基づいて予め当該サービスに割り当てられたサーバの処理能力（同時処理能力）とを比較する（ステップＳ１１）。負荷分散管理部３２は、サーバの処理能力に対して実際のリクエスト数が上回る処理能力不足になっているか判定する（ステップＳ１２）。処理能力不足になっていると判定された場合（ステップＳ１２；Ｙｅｓ）、負荷分散管理部３２は、当該サービスに割り当てるサーバを追加する（ステップＳ１３）。処理能力不足になっていないと判定された場合（ステップＳ１２；Ｎｏ）、負荷分散管理部３２は、サーバの処理能力に対して実際のリクエスト数がサーバ１つ分以上下回る処理能力過剰になっているか判定する（ステップＳ１４）。処理能力過剰になっていると判定された場合（ステップＳ１４；Ｙｅｓ）、負荷分散管理部３２は、当該サービスに割り当てるサーバを削減する（ステップＳ１５）。処理能力過剰になっていないと判定された場合（ステップＳ１４；Ｎｏ）、負荷分散管理部３２は、処理を終了する。
【００４８】
リクエスト数を示す情報のリクエスト処理能力情報取得部３１による取得及び負荷分散管理部３２によるサーバの増減に関する処理の実施頻度は任意である。
【００４９】
第１の実施の形態によれば、サービスに関する公開情報のリーチ数に基づいて当該サービスに要求されるリクエスト処理数を算出し、当該リクエスト処理数に基づいて当該サービスに要求されるサーバの予想数を算出する。当該予想数に対応する数のサーバを準備することで、サービスの提供に必要であると予想される処理能力に応じたサーバの準備が可能になる。
【００５０】
また、サービスの提供に割り当てられたサーバに対するリクエスト数を取得し、予想数及び当該リクエスト数に基づいてサービスの提供に割り当てるサーバの数を決定する。これによって、予想された処理能力と実際に要求される処理能力との間に差異が生じたとしても、サービスの提供に必要な処理能力を提供するためのサーバを割り当てることができる。
【００５１】
また、公開情報のリーチ数の有効期限を設定可能である。これによって、リーチ数が有効な公開情報に基づいて、より高精度なサーバの予想数の算出を行うことができる。
【００５２】
また、第２算出部は、所定時間周期で予想数を更新する。これによって、無効になった公開情報のリーチ数が予想数に与える影響を所定時間周期で抑制することができる。従って、公開情報の鮮度に応じたサーバの予想数の調整を行うことができる。
【００５３】
（第２の実施の形態）
次に、第２の実施の形態について説明する。第２の実施の形態の説明において、第１の実施の形態と同様の事項については、同じ符号を用いて説明を省略する。
【００５４】
図１０は、第２の実施の形態においてサーバ群４に含まれる複数のサーバ４１，…，４ｎの割り当て制御に関する機能構成例を示す図である。第２の実施の形態における負荷分散管理サーバ３は、さらに、係数算出部３４として機能する。係数算出部３４の機能及び情報に対応するプログラム及びデータは、第２の実施の形態における負荷分散管理サーバ３が備えるＨＤＤ１４に記憶されている。第２の実施の形態における負荷分散管理サーバ３が備えるＣＰＵ１１は、ＨＤＤ１４からプログラム及びデータを読み出してリクエスト処理能力情報取得部３１、負荷分散管理部３２及びキャパシティプラン情報３３として機能する。
【００５５】
係数算出部３４は、リクエスト処理能力情報取得部３１により取得された、サービスに対するリクエスト数（実際のリクエスト数）と、予想数に基づいて予め当該サービスに割り当てられたサーバの処理能力（同時処理能力）との比に基づいて、リーチ数とリクエスト数との関係を補正するための係数を算出する。例えば、ある時点における公開情報のリーチ数を倍率１でそのままリクエスト処理数に換算してサーバの予想数を算出した場合の同時処理能力が「１０００」であったとする。これに対し、その公開情報のリーチ数が有効な期間に生じた実際のリクエスト数が「１２５０」であったとする。この場合、予想（１０００）に対して実際のリクエスト数（１２５０）が１．２５倍であったことになる。この場合、係数算出部３４は、リーチ数とリクエスト数との関係を補正するための係数として、「１．２５」を算出する。係数算出部３４が算出する係数は、０を超える実数であれば良い。予想に対して実際のリクエスト数が下回った場合、係数算出部３４が算出する係数は、１未満になる。
【００５６】
負荷分散管理サーバ３から送信された係数を示す情報は、設定情報２５に含まれる情報としてキャパシティプランニングサーバ２のＨＤＤ１４に記憶される。第２の実施の形態におけるキャパシティプラン作成処理部２１は、リーチ数に当該係数を乗じた値をリクエスト数として算出する。
【００５７】
係数算出部３４による係数の算出は、サービスの「対象」毎であっても良いし、公開情報の「手段」毎であっても良いし、「対象」と「手段」との組み合わせパターン毎であっても良い。より細かいパターン別の係数の算出を行うことで、リーチ数と、リーチ数に基づいたリクエスト処理数に対応するサーバの予想数との関係をより高精度にすることができる。
【００５８】
図１１は、係数算出部３４の処理の流れの一例を示す図である。係数算出部３４は、サービスに対するリクエスト数（実際のリクエスト数）と、予想数に基づいて予め当該サービスに割り当てられたサーバの処理能力（同時処理能力）とを比較する（ステップＳ２１）。係数算出部３４は、ステップＳ２１で比較された実際のリクエスト数とサーバの処理能力との比に基づいて、リーチ数とリクエスト数との関係を補正するための係数を算出する（ステップＳ２２）。
【００５９】
以上、特筆した事項を除いて、第２の実施の形態は、第１の実施の形態と同様である。第２の実施の形態によれば、実施の形態１の作用効果に加え、係数によって公開情報のリーチ数とサーバの予想数との関係をより高精度にすることができる。
【００６０】
なお、上記の実施の形態においてキャパシティプランニングサーバ２が備えるキャパシティプラン作成処理部２１、設定部２２としての機能は、上記の通り、キャパシティプランニングサーバ２が備えるＣＰＵ１１が対応するプログラムをＨＤＤ１４から読み出して実行することで実現される。すなわち、キャパシティプランニングサーバ２は、サービスに関する公開情報のリーチ数に基づいてサービスに要求されるリクエスト処理数を算出する機能と、リクエスト処理数に基づいてサービスに要求されるサーバの予想数を算出する機能と、をコンピュータに実現させるためのプログラムを含む。同様に、負荷分散管理サーバ３が備えるリクエスト処理能力情報取得部３１、負荷分散管理部３２、係数算出部３４としての機能は、上記の通り、負荷分散管理サーバ３が備えるＣＰＵ１１が対応するプログラムをＨＤＤ１４から読み出して実行することで実現される。
【００６１】
上記の実施の形態のキャパシティプランニングサーバ２、負荷分散管理サーバ３等で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。また、上記の実施の形態のキャパシティプランニングサーバ２、負荷分散管理サーバ３等で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、上記の実施の形態のキャパシティプランニングサーバ２、負荷分散管理サーバ３等で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。また、上記の実施の形態のキャパシティプランニングサーバ２、負荷分散管理サーバ３等で実行されるプログラムを、ＲＯＭ等に予め組み込んで提供するように構成しても良い。上記の実施の形態のキャパシティプランニングサーバ２、負荷分散管理サーバ３等で実行されるプログラムは、上述した各部（キャパシティプラン作成処理部２１及び設定部２２ならびにリクエスト処理能力情報取得部３１、負荷分散管理部３２及び係数算出部３４）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記記憶媒体から〜プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、キャパシティプラン作成処理部２１及び設定部２２ならびにリクエスト処理能力情報取得部３１、負荷分散管理部３２及び係数算出部３４が主記憶装置上に生成されるようになっている。
【符号の説明】
【００６２】
１  サーバプロビジョニングシステム
２  キャパシティプランニングサーバ
３  負荷分散管理サーバ
４  サーバ群
４１，…，４ｎ  サーバ
５  ストレージサービス提供部
６  ロードバランサー
７  通信回線
８１，…，８ｍ  端末
１１  ＣＰＵ
１２  ＲＯＭ
１３  ＲＡＭ
１４  ＨＤＤ
１５  操作部
１６  通信部
１７  表示部
２１  キャパシティプラン作成処理部
２２  設定部
２３  サーバ装置処理能力情報
２４  マーケティング情報
２５  設定情報
３１  リクエスト処理能力情報取得部
３２  負荷分散管理部
３３  キャパシティプラン情報
３４  係数算出部
６１  リクエスト処理能力監視部
【先行技術文献】
【特許文献】
【００６３】
【特許文献１】特開２００８−１２９８７８号公報
【図１】
2019164543.tif 000003
【図２】
2019164543.tif 000004
【図３】
2019164543.tif 000005
【図４】
2019164543.tif 000006
【図５】
2019164543.tif 000007
【図６】
2019164543.tif 000008
【図７】
2019164543.tif 000009
【図８】
2019164543.tif 000010
【図９】
2019164543.tif 000011
【図１０】
2019164543.tif 000012
【図１１】
2019164543.tif 000013