特開 2025-21166 予測期間通知プログラム、情報処理システムおよび予測期間通知方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025021166

(43)【公開日】2025-02-13

(54)【発明の名称】予測期間通知プログラム、情報処理システムおよび予測期間通知方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20250205BHJP

   G06Q 50/10 20120101ALI20250205BHJP

【ＦＩ】

G06F11/34 142

G06Q50/10

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023124926

(22)【出願日】2023-07-31

(71)【出願人】

【識別番号】598057291

【氏名又は名称】エフサステクノロジーズ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】児玉 武司

(72)【発明者】

【氏名】樋口 淳一

(72)【発明者】

【氏名】田辺 雅人

(72)【発明者】

【氏名】上野 仁

(72)【発明者】

【氏名】木村 義弘

(72)【発明者】

【氏名】久保田 聡

【テーマコード（参考）】

5B042

5L049

5L050

【Ｆターム（参考）】

5B042MA08

5B042MA14

5B042MC22

5L049CC12

5L050CC12

(57)【要約】

【課題】必要な時期にリソースを納品できる。
【解決手段】制御サーバ１は、コンピュータにおけるサーバの在庫状況を記憶する在庫管理データ２１と、顧客側の使用サータおよび使用台数を記憶する顧客管理データ２２とを照合し、顧客側が増設する場合に必要な台数の納品までに要する日数を計算し、納品までに要する日数から推奨される、キャパシティプランニングに用いられる予測期間を顧客側のサーバに通知する。
【選択図】図２Ａ

【特許請求の範囲】

【請求項1】

コンピュータにおけるリソースの在庫状況を記憶する在庫状況情報と、顧客側の使用リソースおよび使用台数を記憶する顧客情報とを照合し、前記顧客側が増設する場合に必要な台数の納品までに要する日数を計算し、
前記納品までに要する日数から推奨される、キャパシティプランニングに用いられる予測期間を顧客側のサーバに通知する
処理をコンピュータに実行させる予測期間通知プログラム。

【請求項2】

前記顧客情報は、顧客が使用するリソース、使用台数および前記キャパシティプランニングに用いられる現在の予測期間を記憶し、
前記通知する処理は、前記納品までに要する日数から推奨される予測期間が前記顧客情報に記憶された前記現在の予測期間と異なる場合には、前記納品までに要する日数から推奨される予測期間を前記顧客側のサーバに通知するとともに、前記推奨される予測期間を前記顧客情報に更新する
ことを特徴とする請求項１に記載の予測期間通知プログラム。

【請求項3】

前記通知する処理は、さらに、前記納品までに要する日数から推奨される予測期間が前記顧客情報に記憶された前記現在の予測期間と同じである場合には、前記推奨される予測期間を前記顧客側のサーバに通知しない
ことを特徴とする請求項２に記載の予測期間通知プログラム。

【請求項4】

前記計算する処理は、
前記顧客情報を参照し、前記使用台数の所定の割合を前記顧客側が増設する場合に必要な台数として計算し、
前記在庫状況情報を参照し、前記顧客側の使用リソースの時期ごとの在庫数を取得し、
前記顧客側の使用リソースの時期ごとの在庫数から、該計算した台数より多くなる時期を探索し、
探索した結果を示す時期と、推奨される予測期間の計算を実施した日とから必要な台数の納品までに要する日数を計算する
ことを特徴とする請求項１に記載の予測期間通知プログラム。

【請求項5】

販売側の第１のサーバと、
顧客側の第２のサーバと、を有する情報処理システムであって、
前記第１のサーバは、
コンピュータにおけるリソースの在庫状況を記憶する在庫状況情報と、顧客側の使用リソースおよび使用台数を記憶する顧客情報とを照合し、前記顧客側が増設する場合に必要な台数の納品までに要する日数を計算する計算部と、
前記納品までに要する日数から推奨される、キャパシティプランニングに用いられる予測期間を顧客側のサーバに通知する通知部と、を有し、
前記第２のサーバは、
前記第１のサーバから通知される前記予測期間を前記キャパシティプランニングに用いて、前記使用リソースの使用量を予測する予測部
を有することを特徴とする情報処理システム。

【請求項6】

コンピュータにおけるリソースの在庫状況を記憶する在庫状況情報と、顧客側の使用リソースおよび使用台数を記憶する顧客情報とを照合し、前記顧客側が増設する場合に必要な台数の納品までに要する日数を計算し、
前記納品までに要する日数から推奨される、キャパシティプランニングに用いられる予測期間を顧客側のサーバに通知する
処理をコンピュータが実行することを特徴とする予測期間通知方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、予測期間通知プログラム等に関する。

【背景技術】

【0002】

利用者の増加やサービスレベルの向上に合わせてシステムを構成するサーバを増設（スケールアウト）し、システムのスペックを増強することがなされている。

【0003】

サーバをスケールアウトするか否かの要否については、キャパシティプランニング機能を用いて判断できる。キャパシティプランニングとは、システムに必要なリソースの構成を決定するプロセスのことをいい、キャパシティプランニング機能は、例えば、サーバ上で動作するアプリケーションである。

【0004】

例えば、顧客のシステムを管理する管理サーバは、キャパシティプランニング機能を用いて、今後のリソース使用量の変化に基づいてシステム内のサーバをスケールアウトするか否かの要否を判断する。管理サーバは、スケールアウトすると判断した場合には、必要な台数分のサーバを必要な時期までに納品するように販売側に発注する。

【0005】

また、キャパシティプランニング機能に関する技術が開示されている（例えば、特許文献１～３参照）。一例として、複数のコンテナが配置された計算機環境について、収集されたリソース使用量の測定値を時系列の分析処理により分解された規則変動データに基づいて、現在から所定期間後までの計算機環境におけるリソース使用量を予測し、リソース使用量の予測値に基づいて計算機環境におけるコンテナの再配置を行うことが開示されている。

【0006】

また、別の例として、複数の仮想マシンを搭載する物理サーバについて、所定期間内での仮想マシンのリソース使用量に基づき、移動することでリソース不足を解消できる仮想マシンを特定し、移動することが開示されている。

【先行技術文献】

【特許文献】

【0007】

【特許文献1】特開２０２０－１４４６６９号公報

【特許文献2】特開２０１４－６７３９号公報

【特許文献3】特開２００５－１８２６９７号公報

【発明の概要】

【発明が解決しようとする課題】

【0008】

しかしながら、キャパシティプランニング機能で用いられるリソース使用量を予測する予測期間が固定では、販売側では、サーバの納品が顧客の増強のタイミングに間に合わない場合があるという問題がある。例えば、リソースが枯渇する日が現在から固定の予測期間を経た日である場合、部材不足や急な大量の受注等の何らかの理由で在庫が減ることがあり、納品にかかる日数が固定の予測期間より延びる場合がある。かかる場合には、販売側では、サーバの納品が顧客の増強のタイミングに間に合わない。

【0009】

なお、上記課題は、コンピュータ自体の納品だけではなく、ＣＰＵ、メモリ、ＨＤＤ等のコンピュータを構成するリソースの納品にも同様に生じる課題である。

【0010】

本発明は、１つの側面では、必要な時期にリソースを納品できることを目的とする。

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

【0011】

１つの態様では、予測期間通知プログラムは、顧客側で実施されるキャパシティプランニングにおける推奨する予測期間を計算する際に、サーバの在庫状況を記憶する在庫状況情報と、顧客側が使用するサーバおよび台数を記憶する顧客情報とを照合し、前記顧客側が増設する場合に必要な台数の納品までに要する日数を計算し、前記納品までに要する日数から得られる推奨する予測期間を顧客側のサーバに通知する、処理をコンピュータに実行させる。

【発明の効果】

【0012】

１実施態様によれば、顧客が必要な時期に必要なリソースを納品できる。

【図面の簡単な説明】

【0013】

【図1】図１は、実施例に係る情報処理システムの一例を示す図である。

【図2A】図２Ａは、実施例に係る予測期間通知処理の流れの一例を示す図（１）である。

【図2B】図２Ｂは、実施例に係る予測期間通知処理の流れの一例を示す図（２）である。

【図3】図３は、実施例に係る制御サーバの機能構成の一例を示すブロック図である。

【図4】図４は、実施例に係る在庫管理データの一例を示す図である。

【図5】図５は、実施例に係る顧客管理データの一例を示す図である。

【図6】図６は、実施例に係るシステム管理サーバの機能構成の一例を示すブロック図である。

【図7A】図７Ａは、実施例に係る推奨予測期間計算処理の一例を示す図（１）である。

【図7B】図７Ｂは、実施例に係る推奨予測期間計算処理の一例を示す図（２）である。

【図7C】図７Ｃは、実施例に係る推奨予測期間計算処理の一例を示す図（３）である。

【図7D】図７Ｄは、実施例に係る推奨予測期間計算処理の一例を示す図（４）である。

【図8】図８は、実施例に係る予測期間通知処理のフローチャートの一例を示す図である。

【図9】図９は、実施例に係る予測期間通知処理の効果の一例を示す図である。

【図10】図１０は、予測期間通知プログラムを実行するコンピュータの一例を示す図である。

【図11】図１１は、キャパプラ機能を利用したサーバ発注までの流れを示す参考図である。

【図12】図１２は、納品に間に合わない場合を説明する参考図である。

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

【0014】

以下に、本願の開示する予測期間通知プログラム、情報処理システムおよび予測期間通知方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。

【実施例0015】

まず、キャパシティプランニング機能を利用してシステム内のサーバを発注するまでの流れを、図１１を参照して説明する。ここでいうキャパシティプランニングとは、システムに必要なリソースの構成を決定するプロセスのことをいい、キャパシティプランニング機能は、例えば、サーバ上で動作するアプリケーションである。なお、以降では、キャパシティプランニングを「キャパプラ」と略記する。

【0016】

図１１は、キャパプラ機能を利用したサーバ発注までの流れを示す参考図である。図１１に示すように、サービス事業者（顧客）は、顧客のシステムを管理する。顧客のシステムには、複数のサーバが搭載される。システム管理サーバは、キャパプラ機能を用いて、顧客のシステムについての今後のリソース使用量の変化に基づいてサーバの発注の要否を判断する。リソースには、例えば、ＣＰＵ、ディスクやメモリが挙げられる。ここでは、リソースは、便宜上、ＣＰＵとする。

【0017】

顧客は、予め、キャパプラ機能で用いられる閾値をリソース総量の９０％に設定する（＜９１＞）。キャパプラ機能は、現在から予測期間までのＣＰＵ使用率の変化を予測する（＜９２＞）。ここでは、予測期間は、３０日間の固定値である。予測期間については、短い程、精度が高くなる。このため、顧客は、短めの固定値（例えば、３０日）をキャパプラ機能に設定する。

【0018】

そして、キャパプラ機能は、閾値を超える予測となった場合にアラートを通知する（＜９３＞）。ここでは、現在から予測期間の３０日後に、ＣＰＵ使用率が閾値を超えるので、アラートが通知される。すると、サービス事業者（顧客）は、最終的にサーバの発注の要否を判断して、必要と判断すると必要な台数のサーバをメーカーに発注する（＜９４＞）。その後、メーカーは、発注を受けて、顧客のリソースが枯渇するまでに顧客に納品する。ここでは、メーカーは、現在からリソースが枯渇すると予測される予測期間の３０日までに顧客に納品することが必要になる。

【0019】

ところが、メーカーは、納品に間に合わない場合がある。図１２は、納品に間に合わない場合を説明する参考図である。図１２に示すように、予測期間は、３０日間の固定値である。キャパプラ機能は、現在（１０／１７）から予測期間の３０日先の１１／１７にＣＰＵ使用率が閾値を超え、リソースが枯渇すると予測する。ところが、メーカーの納品日は、１２／５である。例えば、部材不足や急な大量の受注等の何らかの理由で在庫が減ることがあるからである。すると、メーカーが納品にかかる日数は現在から３０日以上になってしまう。すなわち、キャパプラ機能で用いられる予測期間が固定では、サーバの納品が顧客の増強のタイミングに間に合わない場合がある。

【0020】

そこで、実施例では、メーカーが、顧客の増強のタイミングに納品が間に合う仕組みについて説明する。

【0021】

［情報処理システムの一例］
図１は、実施例に係る情報処理システムの一例を示す図である。図１に示すように、情報処理システム９は、制御サーバ１と、顧客のシステム５と、システム管理サーバ３とを有する。

【0022】

システム（顧客）５は、複数のサーバを含む。サービス利用者は、ネットワークを介してシステム（顧客）５に含まれる複数のサーバにアクセスして、サービスを利用する。システム管理サーバ３は、顧客側のサーバであり、システム（顧客）５を管理する。システム管理サーバ３は、キャパプラ機能３２Ａを用いて、システム（顧客）５内の今後のリソース使用量の変化に基づいてシステム（顧客）５に含まれるサーバをスケールアウトするか否かの要否を判断する。キャパプラ機能３２Ａは、現在から予め定められた予測期間までについて、スケールアウトするか否かの要否を予測する。そして、システム管理サーバ３は、サービス事業者（顧客）の最終的な判断のもと、スケールアウトすると判断した場合には、必要な台数分のサーバを予測期間までに送品するようにメーカー（販売者）側に発注する。

【0023】

制御サーバ１は、メーカー（販売者）側のサーバであり、在庫管理データ２１および顧客管理データ２２と接続する。ここでいう在庫管理データ２１は、サーバのモデルごとに、在庫状況を記憶する。在庫状況については、将来の時期ごとの在庫台数が記憶される。ここでいう顧客管理データ２２は、顧客が使用しているサーバのモデル、使用台数およびキャパプラ機能の現在の予測期間を対応付けて記憶する。そして、制御サーバ１は、在庫管理データ２１および顧客管理データ２２を用いて、顧客ごとのキャパプラ機能３２Ａで用いられる予測期間をサーバの在庫状況に応じて動的に変更する。そして、制御サーバ１は、該当する顧客のシステム管理サーバ３に、変更した予測期間を通知する。

【0024】

［予測期間通知処理の流れ］
ここで、実施例に係る予測期間通知処理の流れを、図２Ａおよび図２Ｂを参照して説明する。図２Ａおよび図２Ｂは、実施例に係る予測期間通知処理の流れの一例を示す図である。図２Ａに示すように、制御サーバ１は、在庫管理データ２１から、サーバの在庫数を取得する（＜１＞）。制御サーバ１は、顧客管理データ２２から、顧客が使用しているサーバのモデル、使用台数およびキャパプラ機能３２Ａの現在の予測期間を取得する（＜２＞）。制御サーバ１は、取得したサーバの在庫数と、顧客が使用しているサーバの使用台数とを用いて、顧客がスケールアウトに必要な台数の納品までに要する日数を計算する。そして、制御サーバ１は、納品までに要する日数から推奨される予測期間を計算する（＜３＞）。そして、制御サーバ１は、推奨される予測期間を、顧客に対応するシステム管理サーバ３に通知する（＜４＞）。推奨される予測期間が通知されたシステム管理サーバ３は、通知された予測期間をキャパプラ機能に用いて、今後のリソース使用量の変化を予測する。

【0025】

図２Ｂには、リソースがＣＰＵである場合に、顧客のシステム管理サーバ３は、キャパプラ機能を用いて、今後のＣＰＵ使用量の変化を予測する。閾値は９０％であるとする。

【0026】

図２Ｂ左図は、現在の予測期間が固定の３０日である場合である。かかる場合には、キャパプラ機能を実施する実施日が１０／１７のとき、キャパプラ機能は、１０／１７から現在の予測期間である３０日先の１１／１７に、ＣＰＵ使用率が９０％を超えると予測する。ところが、メーカーの納品までの日数が４０日の場合には、納品が実施日の１０／１７から３０日以上となってしまい、顧客の増強のタイミングに間に合わない。

【0027】

図２Ｂ右図は、変更後の予測期間が６０日の場合である。かかる場合には、キャパプラ機能を実施する実施日が９／１７のとき、キャパプラ機能は、９／１７から変更後の予測期間である６０日先の１１／１７で、ＣＰＵ使用率が９０％を超えると予測する。すると、メーカーの納品までの日数が４０日の場合には、納品日が１０／２７となり、ＣＰＵ使用率が９０％を超えるタイミング（１１／１７）より前になる。すなわち、納品が顧客の増強のタイミングに間に合う。

【0028】

このように、制御サーバ１は、キャパプラ機能の予測期間を顧客のサーバの在庫状況に応じて動的に変更することで、顧客が必要な時期にサーバの納品が可能となる。

【0029】

［制御サーバの機能構成］
図３は、実施例に係る制御サーバの機能構成の一例を示すブロック図である。図３に示すように、制御サーバ１は、制御部１０と、記憶部２０とを有する。制御部１０は、推奨予測期間計算部１１と、通知部１２とを有する。記憶部２０は、在庫管理データ２１と、顧客管理データ２２とを有する。なお、推奨予測期間計算部１１は、計算部の一例である。通知部１２は、通知部の一例である。

【0030】

在庫管理データ２１は、サーバのモデルごとに、在庫状況を記憶する。ここで、在庫管理データ２１の一例を、図４を参照して説明する。図４は、実施例に係る在庫管理データの一例を示す図である。図４に示すように、在庫管理データ２１は、将来の時期ごとの在庫台数を品名ごとに記憶する。品名は、サーバのモデルに対応する。時期は、例えば、１週間単位でも良いし、月間単位でも良いし、週間単位と月間単位との混合でも良い。

【0031】

一例として、品名が「ＸＹ２０００Ｍ５」である場合に、「～１１／２５」の時期には「０」、「～１１／３０」の時期には「０」、・・・、「～１２／０９」の時期には「５」、「１２月」の時期には「１５」、「１月」の時期には「１８６」と記憶している。

【0032】

図３に戻って、顧客管理データ２２は、顧客の情報を記憶する。ここで、顧客管理データ２２の一例を、図５を参照して説明する。図５は、実施例に係る顧客管理データの一例を示す図である。顧客管理データ２２は、サーバモデル、台数および現在の予測期間を、顧客に対応付けて記憶する。サーバモデルは、サーバの品名に対応する。台数は、顧客のシステム５で使用しているサーバの台数である。現在の予測期間は、顧客で実施されるキャパプラ機能３２Ａで用いられる現在の予測期間である。なお、現在の予測期間は、通知部１２によって変更される。

【0033】

一例として、顧客が「顧客Ａ」である場合に、サーバモデルとして「ＸＹ２０００Ｍ５」、台数として「１００」、現在の予測期間として「３０日」と記憶している。

【0034】

図３に戻って、推奨予測期間計算部１１は、顧客ごとに、顧客で実施されるキャパプラ機能３２Ａで用いられる、推奨される予測期間を計算する。

【0035】

例えば、推奨予測期間計算部１１は、在庫管理データ２１と顧客管理データ２２とを照合し、顧客がスケールアウトに必要な台数の納品までに要する日数を計算する。一例として、推奨予測期間計算部１１は、顧客管理データ２２を参照し、顧客が使用するサーバをスケールアウトする場合に必要な台数を計算する。サーバをスケールアウトする場合に必要な台数は、例えば、顧客が使用しているサーバの台数の１割である。但し、サーバをスケールアウトする場合に必要な台数は、顧客が使用しているサーバの台数の１割に限定されず、０．５割であっても良いし、２割であっても良く、適宜変更されることが可能である。

【0036】

そして、推奨予測期間計算部１１は、在庫管理データ２１を参照し、顧客が使用するサーバの時期ごとの在庫数を取得する。そして、推奨予測期間計算部１１は、サーバごとの時期ごとの在庫数から、計算された必要な台数より多くなる時期を探索する。そして、推奨予測期間計算部１１は、探索した結果を示す時期と、推奨予測期間計算の実施日とから必要な台数の納品までに要する日数を計算する。

【0037】

そして、推奨予測期間計算部１１は、納品までに要する日数よりも長い日数を推奨される予測期間として計算する。一例として、推奨される予測期間は、３０日単位で設定されても良いし、１０日単位で設定されても良いし、適宜変更されても良い。例えば、３０日単位で設定される場合には、納品までに要する日数が４５日であれば、推奨される予測期間は、６０日として計算される。１０日単位で設定される場合には、納品までに要する日数が４５日であれば、推奨される予測期間は、５０日として計算される。

【0038】

通知部１２は、推奨される予測期間を顧客のシステム管理サーバ３に通知する。例えば、通知部１２は、顧客管理データ２２から、対象の顧客に対応付けられた現在の予測期間を取得する。通知部１２は、推奨される予測期間が、取得された現在の予測期間と異なる場合には、顧客のシステム管理サーバ３に推奨される予測期間を通知する。これにより、顧客側のシステム管理サーバ３は、メーカーによって推奨される予測期間をキャパプラ機能に用いることで、必要な時期に必要なサーバを納入できる。一方、制御サーバ１は、顧客側が必要な時期に必要なサーバの納品を可能にできる。

【0039】

そして、通知部１２は、顧客管理データ２２の対象の顧客に対応付けられた現在の予測期間を、推奨される予測期間に更新する。また、通知部１２は、推奨される予測期間が、取得された現在の予測期間と同じである場合には、推奨される予測期間を顧客のシステム管理サーバ３に通知しない。これにより、通知部１２は、推奨される予測期間を通知しないことで、通信の無駄をなくすことができる。

【0040】

［システム管理サーバの機能構成］
次に、システム管理サーバ３の機能構成について、図６を参照して説明する。図６は、実施例に係るシステム管理サーバの機能構成の一例を示すブロック図である。図６に示すように、システム管理サーバ３は、制御部３０と、記憶部４０とを有する。制御部３０は、受付部３１、リソース使用量予測部３２およびアラート通知部３３を有する。記憶部４０は、推奨予測期間４１を有する。

【0041】

推奨予測期間４１は、キャパプラ機能に用いられる予測期間であってメーカーに推奨された予測期間である。

【0042】

受付部３１は、制御サーバ１から推奨される予測期間を受け付ける。そして、受付部３１は、推奨される予測期間をキャパプラ機能に用いるべく、推奨予測期間４１に保持する。

【0043】

リソース使用量予測部３２は、推奨予測期間４１をキャパプラ機能に用いて、リソース使用量を予測する。すなわち、リソース使用量予測部３２は、キャパプラ機能の実施日から推奨予測期間４１までのリソース使用量を予測する。

【0044】

アラート通知部３３は、リソース使用量の予測に基づいて、リソース使用量が閾値を超える場合に、アラートを通知する。例えば、アラート通知部３３は、リソース使用量が閾値を超える場合に、サービス事業者に対してアラートを通知する。その後、サービス事業者は、最終的にサーバの発注の要否を判断し、必要であれば、必要な台数をメーカーに発注する。

【0045】

［推奨予測期間計算処理の一例］
ここで、制御サーバ１における推奨予測期間計算部１１が実施する推奨予測期間計算処理の一例を、図７Ａ～図７Ｄを参照して説明する。図７Ａ～図７Ｄは、実施例に係る推奨予測期間計算処理の一例を示す図である。なお、推奨予測期間計算部１１は、例えば１日１回、以下の手順で、各顧客に対して推奨される予測期間を計算する。ここでは、推奨予測期間計算部１１は、顧客Ａに対する推奨予測期間の計算を「１２／４」に実施した場合について説明する。

【0046】

図７Ａに示すように、推奨予測期間計算部１１は、顧客管理データ２２を参照し、顧客Ａが使用するサーバモデル、台数、現在の予測期間を取得する。ここでは、顧客Ａが使用するサーバモデルとして「ＸＹ２０００Ｍ５」、台数として「１００」、現在の予測期間として「３０日」が取得される（符号ａ１参照）。

【0047】

そして、推奨予測期間計算部１１は、顧客Ａのスケールアウトに必要な台数を計算する。必要な台数は、顧客が使用しているサーバの台数の１割であるとする。ここでは、顧客Ａについては、サーバの台数が１００台であるので、スケールアウトに必要な台数は１０台と計算される。

【0048】

図７Ｂに示すように、推奨予測期間計算部１１は、在庫管理データ２１を参照し、顧客Ａが使用するサーバの時期ごとの在庫数を取得する。そして、推奨予測期間計算部１１は、サーバごとの時期ごとの在庫数から、スケールアウトに必要な台数よりも多くなる時期を探索する。ここでは、顧客Ａが使用するサーバモデル「ＸＹ２０００Ｍ５」の在庫数がスケールアウトに必要な台数である１０台よりも多くなる時期は、１２月末である（ａ２参照）。

【0049】

そして、推奨予測期間計算部１１は、探索した結果を示す時期と、推奨予測期間計算の実施日とから必要な台数の納品までに要する日数を計算する。ここでは、探索した結果を示す時期は、「１２／３１」であり、推奨予測期間計算の実施日は「１２／４」である。そこで、納品までに要する日数は、２７日（＝１２／３１－１２／４）と計算される。

【0050】

そして、推奨予測期間計算部１１は、納品までに要する日数よりも長い日数を推奨される予測期間として計算する。ここでは、推奨される予測期間は、３０日単位で設定されるとする。すると、納品までに要する日数は「２７日」であるので、推奨される予測期間は「３０日」と計算される。

【0051】

そして、通知部１２は、顧客管理データ２２から、顧客Ａに対応付けられた現在の予測期間を取得する。そして、通知部１２は、推奨される予測期間が、現在の予測期間と異なる場合には、顧客Ａのシステム管理サーバ３に推奨される予測期間を通知する。ここでは、顧客Ａに対応する現在の予測期間は、顧客管理データ２２から「３０日」と取得される（符号ａ３参照）。したがって、通知部１２は、推奨される予測期間が取得された現在の予測期間と同じであるので、推奨される予測期間を顧客Ａのキャパプラ機能へ通知しない。

【0052】

図７Ｃは、推奨される予測期間が変わるケースである。ここでは、推奨予測期間計算部１１は、顧客Ａに対応する推奨予測期間の計算を「１２／１３」に実施した場合について説明する。在庫管理データ２１は、図７Ｃ左図に示す通りである。

【0053】

図７Ｃに示すように、推奨予測期間計算部１１は、在庫管理データ２１を参照し、顧客Ａが使用するサーバの時期ごとの在庫数を取得する。そして、推奨予測期間計算部１１は、サーバごとの時期ごとの在庫数から、スケールアウトに必要な台数よりも多くなる時期を探索する。ここでは、顧客Ａが使用するサーバモデル「ＸＹ２０００Ｍ５」の在庫数がスケールアウトに必要な台数である１０台よりも多くなる時期は、１月末である（ａ５参照）。

【0054】

そして、推奨予測期間計算部１１は、探索した結果を示す時期と、推奨予測期間計算の実施日とから必要な台数の納品までに要する日数を計算する。ここでは、探索した結果を示す時期は、「１／３１」であり、推奨予測期間計算の実施日は「１２／１３」である。そこで、納品までに要する日数は、４８日（＝１／３１－１２／１３）と計算される。

【0055】

そして、推奨予測期間計算部１１は、納品までに要する日数よりも長い日数を推奨される予測期間として計算する。ここでは、推奨される予測期間は、３０日単位で設定されるとする。すると、納品までに要する日数は「４８日」であるので、推奨される予測期間は「６０日」と計算される。

【0056】

図７Ｄに示すように、通知部１２は、顧客管理データ２２から、顧客Ａに対応付けられた現在の予測期間を取得する。そして、通知部１２は、推奨される予測期間が、現在の予測期間と異なる場合には、顧客Ａのシステム管理サーバ３に推奨される予測期間を通知する。ここでは、顧客Ａに対応する現在の予測期間は、顧客管理データ２２から「３０日」と取得される（符号ａ６参照）。したがって、通知部１２は、推奨される予測期間が取得された現在の予測期間と異なるので、推奨される予測期間「６０日」を顧客Ａのキャパプラ機能へ通知する。そして、通知部１２は、顧客管理データ２２の顧客Ａに対応付けられた現在の予測期間を、「３０日」から推奨される予測期間「６０日」に更新する（符号ａ７参照）。

【0057】

これにより、顧客Ａのシステム管理サーバ３は、メーカーによって推奨される予測期間「６０日」をキャパプラ機能に用いることで、必要な時期に必要なサーバを納入できる。一方、制御サーバ１は、顧客Ａが必要な時期に必要なサーバの納品を可能にできる。

【0058】

［予測期間通知処理のフローチャート］
ここで、実施例に係る制御サーバ１が実施する予測期間通知処理のフローチャートを、図８を参照して説明する。図８は、実施例に係る予測期間通知処理のフローチャートの一例を示す図である。なお、制御サーバ１は、顧客の推奨予測期間の計算を、例えば１日１回実施するとする。

【0059】

計算要求を受け付けた制御サーバ１は、顧客管理データ２２から、顧客が使用するサーバのモデル、使用台数、現在の予測期間を取得する（ステップＳ１１）。制御サーバ１は、顧客が使用するサーバのモデルをスケールアウトする場合に必要な台数を計算する（ステップＳ１２）。例えば、スケールアウトする場合に必要な台数は、現在の使用台数の１割である。

【0060】

そして、制御サーバ１は、在庫管理データ２１から、顧客が使用するモデルのサーバについてスケールアウトに必要な台数よりも在庫が多い最早の日を取得する（ステップＳ１３）。そして、制御サーバ１は、現在（推奨予測期間計算の実施日）から、取得した日までの日数を納品までに要する日数とする（ステップＳ１４）。

【0061】

そして、制御サーバ１は、キャパプラ機能の推奨される予測期間を、３０日単位で納品までに要する日数を超える最短の日数とする（ステップＳ１５）。制御サーバ１は、推奨される予測期間が顧客の現在の予測期間と異なるか否かを判定する（ステップＳ１６）。顧客の現在の予測期間は、顧客管理データ２２から取得されれば良い。

【0062】

推奨される予測期間が顧客の現在の予測期間と同じであると判定した場合には（ステップＳ１６；Ｎｏ）、制御サーバ１は、推奨される予測期間を顧客に通知しないで、予測期間通知処理を終了する。この後、顧客のシステム管理サーバ３は、引き続き、既に設定された推奨予測期間４１をキャパプラ機能に用いてリソース使用量を予測する。

【0063】

一方、推奨される予測期間が顧客の現在の予測期間と異なると判定した場合には（ステップＳ１６；Ｙｅｓ）、制御サーバ１は、顧客のキャパプラ機能に推奨される予測期間を通知する（ステップＳ１７）。加えて、制御サーバ１は、顧客管理データ２２の現在の予測期間を推奨される予測期間に更新する（ステップＳ１８）。そして、制御サーバ１は、予測期間通知処理を終了する。この後、顧客のシステム管理サーバ３は、更新された予測期間をキャパプラ機能に用いてリソース使用量を予測する。

【0064】

［予測期間通知処理の効果］
ここで、実施例に係る予測期間通知処理の効果を、図９を参照して説明する。図９は、実施例に係る予測期間通知処理の効果の一例を示す図である。図９に示すように、システム管理サーバ３は、推奨予測期間４１に保持される「３０日」をキャパプラ機能３２Ａに用いて、符号ｂ１で示される９／１７（現在）から３０日先のＣＰＵ使用量の変化を予測する。ここでは、９／１７（現在）から３０日先のＣＰＵ使用量は閾値を超えないと予測される。

【0065】

メーカー側では、９／２１に在庫が減少して、顧客が使用するサーバについて、納品までに要する日数が２０日から３８日に延びるとする。すると、制御サーバ１は、推奨される予測期間を、３０日単位で、納品までに要する日数「３８日」を超える最短の日数とする。ここでは、制御サーバ１は、推奨される予測期間を「６０日」と計算される。そして、制御サーバ１は、顧客のシステム管理サーバ３に推奨される予測期間「６０日」を通知する（ｂ２）。システム管理サーバ３は、９／２１に推奨予測期間４１を「３０日」から「６０日」に変更する（ｂ３）。

【0066】

そして、システム管理サーバ３は、推奨予測期間４１に変更された「６０日」をキャパプラ機能３２Ａに用いて、符号ｂ４で示される９／２１（現在）から６０日先のＣＰＵ使用量の変化を予測する。ここでは、９／２１（現在）から６０日先までの期間内の１１／１で、ＣＰＵ使用量は閾値を超えると予測される（ｂ５）。

【0067】

したがって、サービス事業者は、９／２１の時点でスケールアウトのために必要なサーバをメーカーに発注すれば、必要な時期（１１／１）にサーバを納入できる。一方、メーカー側は、顧客の必要な時期にサーバの納品を可能にできる。

【0068】

［実施例の効果］
上記実施例によれば、制御サーバ１は、コンピュータにおけるリソースの在庫状況を記憶する在庫管理データ２１と、顧客側の使用リソースおよび使用台数を記憶する顧客管理データ２２とを照合し、顧客側が増設する場合に必要な台数の納品までに要する日数を計算する。制御サーバ１は、納品までに要する日数から推奨される、キャパシティプランニングに用いられる予測期間を顧客側のシステム管理サーバ３に通知する。かかる構成によれば、システム管理サーバ３は、キャパシティプランニング機能を用いることで、必要な時期に必要なリソースを納入できる。一方、制御サーバ１は、顧客側が必要な時期に顧客側が必要なリソースを納品できる。

【0069】

また、上記実施例によれば、顧客管理データ２２は、顧客が使用するリソース、使用台数およびキャパシティプランニングに用いられる現在の予測期間を記憶する。そして、制御サーバ１は、納品までに要する日数から推奨される予測期間が顧客管理データ２２に記憶された現在の予測期間と異なる場合には、納品までに要する日数から推奨される予測期間を顧客側のシステム管理サーバ３に通知するとともに、推奨される予測期間を顧客管理データ２２に更新する。かかる構成によれば、制御サーバ１は、リソースの在庫状況に応じてキャパシティプランニングに用いられる予測期間を動的に変更できる。

【0070】

また、上記実施例によれば、制御サーバ１は、さらに、納品までに要する日数から推奨される予測期間が顧客管理データ２２に記憶された現在の予測期間と同じである場合には、推奨される予測期間を顧客側のシステム管理サーバ３に通知しない。かかる構成によれば、制御サーバ１は、推奨される予測期間を通知しないことで、通信の無駄をなくすことができる。

【0071】

また、上記実施例によれば、制御サーバ１は、顧客管理データ２２を参照し、使用台数の所定の割合を顧客側が増設する場合に必要な台数として計算する。制御サーバ１は、在庫管理データ２１を参照し、顧客側の使用リソースの時期ごとの在庫数を取得する。そして、制御サーバ１は、顧客側の使用リソースの時期ごとの在庫数から、該計算した台数より多くなる時期を探索する。そして、制御サーバ１は、探索した結果を示す時期と、推奨される予測期間の計算を実施した日とから必要な台数の納品までに要する日数を計算する。かかる構成によれば、制御サーバ１は、顧客側が必要な台数の納品までに要する日数を容易に計算できる。

【0072】

［その他］
なお、上記実施例では、図示した制御サーバ１やシステム管理サーバ３の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、制御サーバ１やシステム管理サーバ３の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。また、記憶部２０を制御サーバ１の外部装置としてネットワーク経由で接続するようにしても良い。記憶部４０をシステム管理サーバ３の外部装置としてネットワーク経由で接続するようにしても良い。

【0073】

また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することによって実現することができる。そこで、以下では、図３に示した制御サーバ１と同様の機能を実現する予測期間通知プログラムを実行するコンピュータの一例を説明する。図１０は、予測期間通知プログラムを実行するコンピュータの一例を示す図である。

【0074】

図１０に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ（Central Processing Unit）２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信Ｉ／Ｆ（InterFace）２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ（Hard Disk Drive）２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、表示装置２０９、ドライブ装置２１３、入力装置２１５、通信Ｉ／Ｆ２１７は、バス２１９で接続されている。

【0075】

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、予測期間通知プログラム２０５ａおよび予測期間通知処理関連情報２０５ｂを記憶する。通信Ｉ／Ｆ２１７は、ネットワークと装置内部とのインタフェースを司り、他のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ２１７には、例えば、モデムやＬＡＮアダプタ等を採用することができる。

【0076】

表示装置２０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報等のデータを表示する表示装置である。表示装置２０９は、例えば、液晶ディスプレイや有機ＥＬ（Electroluminescence）ディスプレイ等を採用することができる。

【0077】

ＣＰＵ２０３は、予測期間通知プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは制御サーバ１の各機能部に対応する。予測期間通知処理関連情報２０５ｂには、例えば、在庫管理データ２１および顧客管理データ２２が含まれる。そして、例えばリムーバブルディスク２１１が、予測期間通知プログラム２０５ａ等の各情報を記憶する。

【0078】

なお、予測期間通知プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらから予測期間通知プログラム２０５ａを読み出して実行するようにしても良い。

【0079】

また、上記実施例で説明した情報処理システム９は、オンプレミスでシステムが利用者にサービスを提供する場合に、システムを構成するサーバ等を増設する際に適用することができる。例えば、メーカー（販売者）がサービス提供者（顧客）に増設等の必要な時期に必要なリソースを納品できる。

【符号の説明】

【0080】

１ 制御サーバ
３ システム管理サーバ
９ 情報処理システム
１０ 制御部
１１ 推奨予測期間計算部
１２ 通知部
２０ 記憶部
２１ 在庫管理データ
２２ 顧客管理データ
３０ 制御部
３１ 受付部
３２ リソース使用量予測部
３２Ａ キャパプラ機能
３３ アラート通知部
４０ 記憶部
４１ 推奨予測期間

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【図10】

【図11】

【図12】