JP2022038919A - リソース構成見積もりシステムおよびリソース構成見積もり方法 - Google Patents

Abstract

【課題】ＩＴリソースの移行において、移行先のリソースをより適切にサイジングする。【解決手段】リソース構成見積もりシステムは、移行元の第一の計算機システムの第一のリソースの負荷を表す移行元負荷モデルを推定し、移行元負荷モデルに基づいて、第一のリソースを第二の計算機システムへ移行させた場合の第二のリソースの負荷を表す移行先負荷モデルを推定する。そしてリソース構成見積もりシステムは、第一のリソースの性能要件と移行先負荷モデルとを比較して、性能要件に適合する移行先負荷モデルを判別する。そしてリソース構成見積もりシステムは、第二のリソースのリソース構成の設計値を決定する際、性能要件に適合する移行先負荷モデルについて、推定した移行先負荷モデルに基づく第二のリソースの設計値を、要求されるサービスレベルに応じた設計補正値を用いてリソース構成の設計の余裕度を小さくする方向へ補正する。【選択図】図１１

Description

本発明は、リソース構成見積もりシステムおよびリソース構成見積もり方法に関する。

情報システム分野において、クラウドコンピューティングと呼ばれる利用形態が普及し、企業や自治体などの事業者が自身でシステムを保有することなく情報サービスを提供することができるようになった。いわゆるパブリッククラウドは機能要件や非機能要件に合わせて様々なサービスを提供しており、ユーザがそれらを自在に選択し組み合わせることで、保有型のシステムよりも安価に所望のサービスを構築することが可能となっている。

一方で、保守性やセキュリティ保護、サービス品質など主にコスト以外の観点から、従来主流であったように情報システムを自ら維持し続ける場合（オンプレミス）もある。よってオンプレミス、プライベートクラウド、パブリッククラウドのいずれか一つの環境に全ての役割を担わせるのではなく、個々のサービスに応じて使い分けることが重要となっている。

このような使い分けの形態によって、ユーザ環境は、マルチクラウドあるいはハイブリッドクラウドと呼ばれる。ユーザ側でもシステムのライフサイクルや事業をとりまく状況により需要が変化するほか、各クラウドが提供する機能性や仕様が様々に異なることから、ユーザは、システムに対するリソース構成を監視し、定期的に見直す必要に迫られる。

例えば、オンプレミス環境にあるサーバやストレージなどのＩＴリソースをパブリッククラウドへ移行する際には、移行元において生じていた負荷を十分処理できるよう移行先の構成を設計しなければならない。特にストレージリソースは構築後に構成を変更することが比較的難しいために、様々なサイジング手法やその自動化技術が提案されている。

このような従来技術として、例えば次の特許文献１では、機械学習により移行元および移行先における負荷の特性を抽出し、リソース構成のパターンとして管理することで精度の高いサイジング技術を開示している。

米国特許第９８６４７４９２号明細書

特許文献１に開示の従来技術によれば、個々の負荷情報をパターン化することができるために、ある程度の不測の負荷が観測される場合でも近似のパターンを検出し、サイジングを完了することができる。また、サイジングを行おうとする利用者が特にストレージリソースの管理や構成設計に関わる知識に通じていない場合であっても適切な移行先構成を見積もることができる。さらには、対象のシステムにおける構成や設定値に差異があってもサイジングにかかるモデルを自動的に構築、修正できることから、環境の変化に頑強で信頼性の高いサイジング結果を得ることができる。

しかしながら、サイジングの精度を高めるためには多様かつ多数の構成パターンおよび負荷のデータを収集し、事前に学習処理を行っておく必要がある。これは当然に長時間、大量の負荷データや構成情報を必要とし、処理量の大きい手法であり、負荷データや構成情報に未知な変数が多い場合には適用が難しい。

また、サイジングの結果として得られた構成が、実際に移行を完了した後で期待通りの負荷特性にならなかった場合、各設計項目の関係が自明ではないため、構成をどのように修正すれば有効であるか不明である。

ここでＩＴリソースの管理においては、サイジングの誤差や、予期しない負荷の上昇、障害発生時の備えとして、余分のリソース量を考慮するのが通例である。これらの安全マージンを含むため、実用上のリソース量は真に利用されるリソース量よりも大きく見積もられている場合が多く、特にサービス品質の低下が事業成果に大きく影響する基幹システムにおいてその傾向が顕著である。

特にストレージリソースにおいては、ファイルシステムなどの構造によってデータ配置が抽象化されるため、容量の拡張が容易である一方で、縮小が困難である。この時、安全マージンを大きく設定するやり方では、後で実使用状況に合わせて容量を縮小することが難しいため、サイジング時のマージンの設定方法によってはリソース利用コストが過大となる恐れがある。

本発明は以上の点に鑑み、ＩＴリソースの移行において、移行先のリソースをより適切にサイジングすることを目的とする。

本発明は、上記課題を解決するために、移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムは、前記第一のリソースの負荷を表す移行元負荷モデルを推定する移行元負荷モデル推定部と、前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定部と、前記第一のリソースの性能要件と、前記移行先負荷モデル推定部によって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計部と、を有し、前記移行先構成設計部は、前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を、要求されるサービスレベルに応じた設計補正値を用いて、前記リソース構成の設計の余裕度を小さくする方向へ補正することを特徴とする。

本発明によれば、ＩＴリソースの移行において、移行先のリソースをより適切にサイジングできる。

実施例１における計算機システムの全体構成の概要を示す図。 実施例１における第一の計算機システムの詳細構成を示す図。 実施例１における第二の計算機システムの詳細構成を示す図。 実施例１における第一の計算機システムの管理コンピュータのプログラム構成を示す図。 実施例１における第二の計算機システムの管理コンピュータのプログラム構成を示す図。 実施例１の第一の計算機システムにおけるグレード定義情報の例を示す図。 実施例１の第一の計算機システムにおけるボリューム性能情報の例を示す図。 実施例１におけるインスタンス構成情報の例を示す図。 実施例１の第二の計算機システムにおけるボリューム種別情報の例を示す図。 実施例１の第二の計算機システムにおけるバケット型課金方法の概念を示す図。 実施例１の第二の計算機システムにおけるバケット型課金方法の概念を示す図。 実施例１の第二の計算機システムにおけるボリューム性能情報の例を示す図。 実施例１におけるストレージ構成見積もりプログラムの概要を示す図。 実施例１におけるストレージ構成見積もり処理を示すフローチャート。 実施例２における処理フローを示す。 管理コンピュータ等の各装置を実現するコンピュータ５０００のハードウェア図である。

以下、図面を参照して本発明の実施例を説明する。実施例は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、種々の他の形態でも実施することが可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

各種情報の例として、「テーブル」、「リスト」、「キュー」等の表現にて説明することがあるが、各種情報はこれら以外のデータ構造で表現されてもよい。例えば、「ＸＸテーブル」、「ＸＸリスト」、「ＸＸキュー」等の各種情報は、「ＸＸ情報」としてもよい。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについては互いに置換が可能である。各種情報は、揮発性または不揮発性の記憶装置の記憶領域に格納される。

同一あるいは同様の機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。また、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

実施例において、プログラムを実行して行う処理について説明する場合がある。計算機は、プロセッサ（ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）等）によりプログラムを実行し、記憶資源（メモリ等）やインタフェースデバイス（通信ポート等）を用いながら、プログラムで定められた処理を行う。そのため、プログラムを実行して行う処理の主体を、「ＸＸＸ部」としてもよいし、プロセッサとしてもよい。

同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であればよく、特定の処理を行う専用回路を含んでいてもよい。ここで、専用回路とは、例えばＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）、ＣＰＬＤ（Complex Programmable Logic Device）等である。

プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、実施例において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

実施例において、第一の計算機システムから第二の計算機システムへの移行対象をストレージリソースとして説明するが、これに限らず、サーバやネットワーク機器といったＩＴリソース一般を移行対象とすることができる。

実施例１では、オンプレミス環境で稼働するストレージリソースに対して、パブリッククラウドへ移行した際の構成を見積もるシステムが提供される。

オンプレミス環境とパブリッククラウド環境を併用することで、ＩＴシステムに対するサービス需要や、セキュリティ、性能などの要件に合わせて最適な構成でインフラストラクチャを運用することができる。

しかしながら、各環境の利用状況が異なっていたり、利用時間の長さや構成の大きさ、利用可能なクラウドサービスの種類が多数存在したりするといった事情によって、オンプレミス、クラウドのいずれがより費用面で適するかは一定でない。そこで、実際に適材適所の構築を行い、要件を満たしながらコストを削減するには、システムの稼働状況に合わせて適切な構成を見積もる手段が必須となる。

＜実施例１のシステム構成＞
図１は、実施例１における計算機システムＳの全体構成の概要を示す図である。計算機システムＳは、第一の計算機システム１Ｓおよび第二の計算機システム２Ｓを含んで構成される。第一の計算機システム１Ｓはオンプレミス環境である。第一の計算機システム１Ｓは、エンドユーザに対して情報サービスを提供するユーザ自身によって保有され、運用管理されるシステムである。

第二の計算機システム２Ｓはパブリッククラウド環境である。第二の計算機システム２Ｓは、クラウド事業者によってユーザに対して従量課金等によりインフラストラクチャが提供されるシステムである。

第一の計算機システム１Ｓを所有するユーザは、第一の計算機システム１Ｓに関わる構成情報や性能情報を占有して管理することができる。一方、このユーザは、第二の計算機システム２Ｓを不特定多数の第三者と物理的に共有している。このため第二の計算機システム２Ｓにおいて、ユーザの管理が及ぶ範囲は限られる。

第二の計算機システム２Ｓを運用するクラウド事業者は、一定のサービス規約のもとで、ユーザに対し、第二の計算機システム２Ｓに関わる利用状況を限定的に提供し、また構成変更の権限を限定的に付与する。

またクラウド環境においては、必要分量のリソースのみを迅速に構築する機能が具備されており、時々の需要に合わせて、必要リソース量を従量課金により利用できる。オンプレミス環境では、ユーザが装置およびリソースを常に保有する形態で構築されることから、需要の変化に合わせてクラウド環境を利用することで、ユーザはサービスの提供に適したリソース量の決定のみに集中でき、システムの運用管理や利用にかかるコストを圧縮できる場合がある。

第一の計算機システム１Ｓは、情報サービスを提供するユーザが自身のデータセンタ１５０に構築されるＩＴインフラストラクチャであり、計算リソースを提供する複数のサーバ装置１０、ストレージリソースを提供する複数のストレージ装置１００、およびそれらを相互に接続する内部ネットワーク５０を含んで構成される。情報サービスを提供する各アプリケーションは、サーバ装置１０で稼働し、必要に応じてストレージ装置１００にデータを格納する。

第一の計算機システム１Ｓにはシステム運用管理基盤３００が設置され、ユーザのうち特にインフラストラクチャ管理者によって各装置の構成が管理される。また第一の計算機システム１Ｓはネットワーク１６１を介して、広域ネットワーク１６０に接続される。図１では第一の計算機システム１Ｓの構成要素を模式的に示しており、各装置が同じ計算機システムを構成する目的で複数のデータセンタ１５０に渡って構築されていてもよい。

第二の計算機システム２Ｓは、データセンタ２５０に構築されるＩＴインフラストラクチャであり、複数のサーバ装置２０、複数のストレージ装置２００、およびそれらを相互に接続する内部ネットワーク７０を含んで構成される。各アプリケーションがサーバ装置２０で稼働し、必要に応じてストレージ装置２００にデータを格納する。

第二の計算機システム２Ｓにはシステム運用管理基盤４００が設置され、ユーザの要求に応じて各装置の構成を管理する。また第二の計算機システム２Ｓはネットワーク１６２を介して、広域ネットワーク１６０に接続される。図１では第二の計算機システム２Ｓの構成要素を模式的に示しており、各装置が同じ計算機システムを構成する目的で複数のデータセンタ２５０に渡って構築されていてもよい。

情報サービスの消費者であるエンドユーザのクライアントコンピュータ１６３は、広域ネットワーク１６０を介して、第一の計算機システム１Ｓまたは第二の計算機システム２Ｓ上のアプリケーションと接続されている。クライアントコンピュータ１６３が各サーバ装置１０またはサーバ装置２０と通信することで、第一の計算機システム１Ｓのユーザが構築した情報サービスの提供を受けることができる。エンドユーザは通信先のサーバ装置が第一の計算機システム１Ｓの一部であるか、あるいは第二の計算機システム２Ｓの一部であるかを特に区別する必要はない。

図２は、実施例１における第一の計算機システム１Ｓの詳細構成を示す図である。第一の計算機システム１Ｓは、１つ以上のサーバ装置１０、１つ以上のストレージ装置１００、管理コンピュータ３０１、およびそれらを相互に接続するネットワーク１６１を含んで構成される。ネットワーク１６１は複数のネットワークスイッチから構成され、必要に応じて管理コンピュータ３０１がそれらネットワークスイッチの構成を管理していてもよい。

また、アプリケーションがデータの送受信を行うために、サーバ装置１０とストレージ装置１００との間に専用の内部ネットワーク５０が構築される。内部ネットワーク５０は大容量のデータを効率的に転送するためにファイバチャネルなど特定のプロトコルを利用するものであってもよい。内部ネットワーク５０は、ネットワークスイッチやアダプタを適宜用いて構築される。

サーバ装置１０はプロセッサや揮発性メモリなどの一般的な計算機アーキテクチャを備え、情報サービスを提供するために必要なアプリケーション１４を稼働させる。アプリケーション１４の動作に必要なリソースはサーバ装置１０上に直接的に稼働するＯＳ（Operating System）１３か、物理リソースを柔軟に利用するために仮想化ソフトウェア１１により実現される仮想マシン１２をさらに導入した形態によって構築される。

アプリケーション１４は、サーバ装置上のネットワークインタフェース１５を介してネットワーク１６１に接続される。また、アプリケーション１４が利用する不揮発性のストレージ領域は、ストレージ装置１００により論理ボリューム１６として提供される。アプリケーション１４は、論理ボリューム１６を直接的に利用するか、あるいは仮想化ソフトウェア１１の機能によりさらに仮想ディスク１７として利用する形態をとる。仮想ディスク１７は専ら、論理ボリューム１６に設定されたファイルシステム上のファイルとして構成される。

ストレージ装置１００は、サーバ装置１０に不揮発性のストレージ領域を提供するための装置であり、複数のサーバ装置１０から同時にデータの送受信を受け付ける。本実施例において、ストレージ装置１００はストレージ機能を効率的に提供するために共有ストレージコントローラ１０１を備え、データの送受信やストレージデバイスとの読み書きといった役割が共有ストレージコントローラ１０１に集約される。

共有ストレージコントローラ１０１は、プロセッサや揮発性メモリといった一般的な計算機アーキテクチャと同様の構成を持ち、ＨＢＡ（Host Bus Adapter）５２やＮＩＣ（Network Interface Card）１０５によりそれぞれ内部ネットワーク５０やネットワーク１６１に接続される。

ストレージ装置１００は多数のＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）といったストレージデバイス１０２を備えるが、これらはそのままストレージ領域としてサーバ装置１０に提供されるのではなく、構成管理がしやすいようさらに論理的な構造が定義される。

より具体的には、複数のストレージデバイスをＲＡＩＤ（Redundant Arrays of Independent Disks）グループ１０３として束ね、さらにストレージプール１０４を構築して論理ボリューム１１６を構成する。ストレージプール１０４は各論理ボリューム１１６に対して容量を動的に割り当てるための構造であり、複数の論理ボリューム１１６が単一のストレージプール１０４を共有して容量を融通しあえる他、複数のＲＡＩＤグループ１０３に分散させてデータを格納する機能を実現する。

ＩＯ（Input／Output）性能やレイテンシ、帯域などの性能は、ストレージデバイス１０２の種別により異なっており、同一のストレージプール１０４を構成する各ＲＡＩＤグループ１０３の容量比率によりストレージ領域を階層化することができる。ストレージデバイス１０２の種別によって性能や容量単価が異なっており、ユーザが実現したい情報サービスの要件に合わせて利用できるよう、複数のストレージ階層を用意する。これらストレージ階層が後述するグレードと関連づけられる。

ストレージプール１０４から割り当てられる論理ボリューム１１６は、サーバ装置１０から論理ボリューム１６として認識される。データ読み書きの応答性を高める目的で、共有ストレージコントローラ１０１はさらに揮発性メモリをキャッシュ領域として利用する場合がある。さらに、管理コンピュータ３０１から要求を受けて構成を変更したり、性能情報を取得させたりといった管理機能を実現するために、共有ストレージコントローラ１０１は管理インタフェースを備える。

管理コンピュータ３０１は、サーバ装置１０やストレージ装置１００の構成を管理するためのプログラム群を稼働させ、システム運用管理基盤３００の機能を実現する。それらのプログラム群を総称して管理プログラムと呼び、構成は動作の詳しい説明と合わせて後述する。システム運用管理基盤３００の機能を構成するために、必要であれば管理コンピュータ３０１は、複数のコンピュータに分かれて構築されていてもよい。

図３は、実施例１における第二の計算機システム２Ｓの詳細構成を示す図である。第二の計算機システム２Ｓは、１つ以上のサーバ装置２０、１つ以上のストレージ装置２００、管理コンピュータ４０１、およびそれらを相互に接続するネットワーク１６２を含んで構成される。ネットワーク１６２は複数のネットワークスイッチから構成され、必要に応じて管理コンピュータ４０１がそれらネットワークスイッチの構成を管理していてもよい。

また、アプリケーションがデータの送受信を行うためにサーバ装置２０とストレージ装置２００との間に専用の内部ネットワーク７０を構築される。本実施例において、例えばストレージ装置２００は、分散ストレージであり、内部ネットワーク７０を通じて協調的に動作する。サーバ装置２０およびストレージ装置２００は物理的には同様の汎用コンピュータであり、各機能を実現するソフトウェアを同一装置上で稼働させてもよいが、ここでは説明のため別途の装置であるものとする。

サーバ装置２０は、プロセッサや揮発性メモリなどの一般的な計算機アーキテクチャを備え、情報サービスを提供するために必要なアプリケーション２４を稼働させる。アプリケーション２４の動作に必要なリソースは、サーバ装置２０上で直接的に稼働するＯＳ２３か、物理リソースを柔軟に利用するために仮想化ソフトウェア２１により実現される仮想マシン２２をさらに導入した形態によって構築される。アプリケーション２４は、サーバ装置２０上のネットワークインタフェース２５を介してネットワーク１６２に接続される。また、アプリケーション２４が利用する不揮発性のストレージ領域は、ストレージ装置２００の分散ストレージが構築する論理ボリューム２６として提供される。

ストレージ装置２００は、サーバ装置２０に不揮発性のストレージ領域を提供するための装置であり、分散ストレージとして複数のストレージ装置２００が協調的に動作し複数のサーバ装置１０からデータ送受信を受け付ける。ストレージ装置２００は、プロセッサや揮発性メモリといった一般的な計算機アーキテクチャと同様の構成を有し、分散ストレージコントローラ２０１と呼ばれるソフトウェアによりストレージ機能を実現する。

ストレージ装置２００ではＯＳ２１３が動作し、各物理リソースを制御する。分散ストレージコントローラ２０１は、ストレージ装置２００に内蔵されるストレージデバイス２０２をそのままサーバ装置１０に提供するのではなく、構成管理がしやすいようさらに論理的な構造を定義する。より具体的には、ＲＡＩＤグループ２０３として各ストレージデバイス２０２を束ねてファイルシステムを定義し、分散ストレージコントローラ２０１が利用するストレージコンテナ２０４を構築する。

ストレージコンテナ２０４は、ファイルシステム上のファイルまたはディレクトリとして実現される。ストレージ領域をサーバ装置２０に提供する際には複数のストレージコンテナ２０４から容量を割り当て、論理ボリューム２１６を構成する。分散ストレージコントローラ２０１が構成する論理ボリューム２１６は、サーバ装置２０からは論理ボリューム２６として認識され、個々のストレージ装置２００やネットワークに障害が発生した場合にも機能を継続できるよう各ストレージ装置２００で構成情報が同期される。

このように、ストレージコンテナ２０４は元々物理的にはストレージ装置２００に内蔵されるストレージデバイス２０２であるが、ストレージデバイス２０２のＨＤＤの回転数や帯域、ＳＳＤの集積度などが様々に異なっており、ストレージコンテナ２０４の割り当て方によって性能と容量の関係が異なる論理ボリューム２１６が構成できる。

ここでは、特性の異なる論理ボリューム２１６を第一の計算機システム１Ｓにおけるグレードと同様に、複数に区別して提供することとし、これをボリューム種別と呼ぶ。管理コンピュータ４０１からの要求を受けて構成が変更できるよう、ストレージ装置２００はさらにネットワークインタフェース２０５によってネットワーク１６２に接続され、必要な管理インタフェースを稼働させる。

第二の計算機システム２Ｓにおけるストレージ装置２００では、ストレージコンテナ２０４を介して容量を割り当てる仕組みによって、論理ボリューム２１６のＩＯ性能を容易に調整できるという利点がある。これはシステムが継続的に稼働することにより、論理ボリューム２１６が消費するストレージ容量が増加したときに、容易に容量を追加できるという利点も併せ持つ。

一方で、論理ボリューム２１６に格納されたデータは、論理アドレス上に分散していることから、後になって容量を縮減することが難しい。容量を削減するには、サーバ装置２０側で管理されるファイルシステムの利用情報を調べて、使用されていないアドレスの部分のみを削除、または使用されているアドレスの部分のみを退避する必要がある。このため通常は、第二の計算機システム２Ｓの運用者は、容量の縮減を認めていない。

後述するように、論理ボリュームの課金額は容量によって決まる場合が多く、利用開始当初に大きめに容量を見積もっておき利用を継続した後で容量を削減するという手段が困難であることから、見積もり時点の課金額が長期間を通じて強く影響すると言える。

管理コンピュータ４０１は、サーバ装置２０やストレージ装置２００の構成を管理するためのプログラム群を稼働させ、システム運用管理基盤４００の機能を実現する。それらのプログラム群を総称して管理プログラムと呼び、構成は動作の詳しい説明と合わせて後述する。システム運用管理基盤４００の機能を構成するために必要であれば、管理コンピュータ４０１は、複数のコンピュータに分散して構築されていてもよい。

図４Ａは、実施例１における第一の計算機システム１Ｓの管理コンピュータ３０１のプログラム構成を示す図である。管理コンピュータ３０１では、第一の計算機システム１Ｓにおける各装置の構成を管理する目的の管理プログラムとして、ストレージ構成見積もりプログラム３１１、ストレージ性能分析プログラム３１２、ストレージ性能管理プログラム３１３、ストレージ構成管理プログラム３１５、およびインスタンス構成管理プログラム３１６が稼働する。さらに、管理コンピュータ３０１では、ストレージ性能管理プログラム３１３が利用するストレージ性能履歴データベース３１４が稼働し、取得されたストレージ装置１００に関わる性能情報を保管できるようにしておく。

ストレージ構成見積もりプログラム３１１の処理の説明は後述する。

ストレージ性能分析プログラム３１２は、論理ボリューム１６または仮想ディスク１７毎の性能を分析する。ストレージ性能分析プログラム３１２による分析結果は、性能情報として、ストレージ性能管理プログラム３１３により管理される。

ストレージ性能管理プログラム３１３は、ストレージ装置１００におけるボリューム性能を管理し、要求に応じて他の管理プログラムに提供する。ストレージ性能管理プログラム３１３がストレージ性能履歴データベース３１４を用いて管理する性能情報とは、例えば図６に示す形式のボリューム性能情報３２１であり、ストレージ装置１００の共有ストレージコントローラ１０１から取得され、ストレージ性能分析プログラム３１２によって分析された分析結果である。

ストレージ構成管理プログラム３１５は、ストレージ装置１００の論理構成および物理構成を管理する。より具体的には、ストレージ構成管理プログラム３１５は、各論理ボリューム１１６、ストレージプール１０４、ＲＡＩＤグループの割り当て関係や、ネットワークインタフェース５２と論理ボリューム１１６の接続関係、論理ボリューム１１６に対するキャッシュメモリの割り当てなどの構成を管理する。

またストレージ構成管理プログラム３１５は、他の管理プログラムと連携してストレージ装置１００の管理に必要な機能および情報を提供する。また論理ボリューム１１６の予約容量や実使用容量、ストレージプール１０４の性能および価格を左右するストレージデバイス１０２の割り当てメディア比率などの構成情報も、ストレージ構成管理プログラム３１５により管理される。

前述の通り、ストレージ装置１００に構成されるストレージ階層は、最終的にユーザに提供される性能および価格と関係しており、例えば図５に示す形式のグレード定義情報３２０として管理される。

ストレージ装置１００では、各グレード定義情報３２０における性能を満足するようにストレージプール１０４に紐づけるＲＡＩＤグループ１０３を調整することにより実現される。グレードはユーザとのサービス条件を定める目安であり、ここではユーザが自ら性能要件に合致するグレードを選択し、ボリュームに割り当てた容量に比例した料金を支払う。ただし、論理ボリューム１１６がどのようなファイルシステムを定義され、仮想ディスク１７などの用途に利用されているかなどについてはユーザの管掌であるので、ストレージ構成管理プログラム３１５は、サーバ装置１０側で制御される構成を管理しない。

インスタンス構成管理プログラム３１６は、サーバ装置１０上にアプリケーション１４を稼働させるための計算リソースに関わる構成情報を管理する。ここでの構成情報は、例えば図７に示す形式のインスタンス構成情報３２２である。、第二の計算機システム２Ｓにおける、サーバ装置２０上にアプリケーション２４を稼働させるための計算リソースに関わるインスタンスの構成情報も同様の形式である。

図４Ｂは、実施例１における第二の計算機システム２Ｓの管理コンピュータ４０１のプログラム構成を示す図である。管理コンピュータ４０１では、第二の計算機システム２Ｓにおける各装置の構成を管理する目的の管理プログラムとして、ストレージリモート管理インタフェースプログラム４１１、ストレージ性能分析プログラム４１２、ストレージ性能管理プログラム４１３、ストレージ構成管理プログラム４１５、およびインスタンス構成管理プログラム４１６が稼働する。さらに、管理コンピュータ４０１では、ストレージ性能管理プログラム４１３が利用するストレージ性能履歴データベース４１４が稼働し、取得されたストレージ装置２００に関わる性能情報を保管できるようにしておく。

管理コンピュータ４０１が第一の計算機システム１Ｓにおける管理コンピュータ３０１のプログラムの構成と異なる点は、ストレージリモート管理インタフェースプログラム４１１を備える点である。これは、第二の計算機システム２Ｓが第一の計算機システム１Ｓの管理者およびユーザとは異なる他者（クラウド事業者）によって運用され、さらに複数の第三者とも共同利用されることから、適正な管理機能および情報のみを遠隔に提供するという事情による。

ストレージリモート管理インタフェースプログラム４１１は、同じく管理コンピュータ４０１上に稼働するストレージ性能管理プログラム４１３などの管理プログラムと連携して機能するが、第二の計算機システム２Ｓの外部に提供可能な機能および情報はユーザ権限に応じて全体の一部に制御される。より具体的には、例えばインスタンス構成管理プログラム４１６が管理するインスタンス構成情報３２２において、特定のユーザまたはユーザグループが参照・変更可能な情報は当該インスタンスにおける所有者のみに制御する、などの機能を有する。

第二の計算機システム２Ｓにおいては、インフラストラクチャの運用者が複数のユーザに対して計算機システムを分配し、従量課金により利用させる形態をとる。すなわち、第一の計算機システム１Ｓのユーザを含む不特定多数のユーザが第二の計算機システム２Ｓを共有して利用しており、第一の計算機システム１Ｓのユーザはそれら他のユーザの利用状況を知ることができない。

第二の計算機システム２Ｓにおける課金方法の主要な例として、最大性能型とバケット型の二通りを想定する。運用者のサービス定義によって、その他の項目として転送帯域（単位時間あたりの転送データ量）や下り転送量、およびスナップショットなどの有償オプションをさらに課金対象として用意する場合があるが、例えば転送帯域は、以降に述べるＩＯＰＳに平均ＩＯサイズを乗じたものであり従属の量である。よって、本実施例においては、特に性能要件において重要な役割を担う設計事項に着目して説明する。

また、ＩＯＰＳや転送帯域はそれぞれ、トランザクションやスループットの用語でも呼称されるが、いずれも同義のものであり本実施例に述べる原理は一様に適用可能である。これらの課金方法は、ボリューム種別毎に定義され、例えば図８に示すような形式のボリューム種別情報４２０がストレージ構成管理プログラム４１５において管理される。

ここでいう最大性能型は、ユーザが設定した最大ＩＯＰＳとストレージ容量によって課金額が決定される方法である。各論理ボリューム２１６には、ストレージ容量に応じて提供可能なＩＯＰＳが決定される。ユーザは当該ＩＯＰＳ以下の値を最大ＩＯＰＳに設定することで課金額が決定される。例えば、当該ストレージリソースの利用状況、ひいては当該システムの利用状況を熟知しているユーザによって、繁忙期のみに最大ＩＯＰＳを高く設定することで、通常の課金額を削減する効果が得られる。

一方で、バケット型は、ユーザが設定したストレージ容量と所与のバースト可能ＩＯ量によって課金額が決定される。図９Ａおよび図９Ｂにバケット型課金方法の概念図を示す。これは、各論理ボリューム２１６に対してベースライン性能６０５と呼ばれる値（ＩＯ量）を想定し、ベースライン性能６０５を超えるＩＯに対してはバースト可能ＩＯと呼ばれる一定値を越えない範囲でＩＯ処理を保証する方法である。

ベースライン性能６０５はストレージ容量に比例して定義され、単位時間あたりの流入ＩＯ６０１のうちベースライン性能６０５を越えたものがバーストＩＯとして蓄積される様子から（リーキー）バケット６００に例えられる。流入ＩＯ６０１がベースライン性能６０５に達しない間（符号６０４）はバケット６００に蓄積されず、ベースライン性能６０５を超えた場合にバケット６００に蓄積され始める（符号６０６）。バースト可能ＩＯに達した場合には以降のＩＯ要求が失敗または遅延させられる。ＩＯ要求がベースライン性能６０５を下回れば、バケット６００に蓄積されたＩＯが流出ＩＯ６０２の相当分減少し（符号６０７）、次のバーストＩＯを受け入れられる余地が増える。

バースト可能ＩＯに対するその時の蓄積ＩＯ量は、その比率を用いて、バケットバランス６０３として表すことができる。理想的には要求ＩＯ量に対して常にバケットバランス６０３が１未満であるように設計される。

バケット型においては、所定の量まではバーストＩＯに課金しない課金方法をとっているものが多く、その場合はベースライン性能６０５を踏まえて容量を設計することで、一定のバーストＩＯが想定されるリソースであってもベースライン性能６０５分の価格で利用することが可能となる。

いずれの課金方式においても、ストレージ性能管理プログラム４１３が管理するボリューム性能情報４２１（図１０）に基づいて論理ボリューム２６の利用状況が測定され、それに応じた利用料金が算定される。

ＩＯ負荷は、実際にはＩＯＰＳのみではなく、ＩＯブロック長さやシーケンシャル／ランダム比率、読み書き比率、キャッシュ利用率などのＩＯ特性や、直前の利用状況、同一のコントローラに対する他のサーバからの利用状況などの、多数の要因により一定ではない。

しかしながら、特に第二の計算機システム２Ｓでは、運用者とユーザが異なっていたり、複数のユーザが同じ装置を共有していたり、かつ公正にリソースを分配する必要があったりといった第二の計算機システム２Ｓに特有な利用形態を想定するため、ごく少数の設計パラメータによってＩＯ性能を設計させる仕様を採用している。ここで述べる課金方法が、専ら容量とＩＯＰＳという二つの設計値に強く依存しているのは、他の設計パラメータが支配的でないから除外できるという意図ではなく、少数に限定せざるを得ない事情による。

いずれの課金方法であっても、当該ストレージ領域が移行の前後で同じアプリケーションおよび近似のサーバ装置構成から利用されると想定すると、性能要件において、移行元で生じていたもとのＩＯ要求を受け付けられるよう移行先ＩＯ性能を設計する必要がある。上述のようにＩＯ性能は容量と関係するよう定義されており、当該ＩＯ性能を満たすように容量を考慮しなければならない。このとき、定常的に生じるＩＯ量と、ごく短期的に高騰した場合のＩＯ量と、の二つのＩＯ性能指標が重要となる。ボリューム種別によって課金方法が異なるため、容量や積算したＩＯ量が一定であっても、時間当たりのＩＯ特性が異なっていれば最も安価な課金方法が時々により異なる可能性がある。

＜見積もりプログラムの概要＞
図１１は、実施例１におけるストレージ構成見積もりプログラム３１１の概要を示す図である。本実施例における見積もりとは、第一の計算機システム１Ｓ、特にストレージリソースの指定を処理要求とし、第二の計算機システム２Ｓへ当該リソースを移行した場合の当該計算機システムにおける課金額、および容量やＩＯ性能などの設計値を処理結果として算出することを言う。特に記載しない限り他の用語と組み合わされる場合も同じ意味であり、例えば見積もり方法や見積もりプログラムとは、それぞれ見積もりを行う方法や見積もりに関わる処理を実現するプログラムのことを指す。

ここでは第一の計算機システム１Ｓから第二の計算機システム２Ｓへのストレージリソースの移行を考え、便宜上、本実施例における第一の計算機システム１Ｓを移行元、第二の計算機システム２Ｓを移行先と呼ぶことがある。

ストレージ構成見積もりプログラム３１１は、主に移行元負荷モデル推定部３５０、移行先負荷モデル推定部３５２、および移行先構成設計部３５３を含んで構成される。その他、ストレージ構成見積もりプログラム３１１は、必要に応じて、例えば移行元負荷モデル推定部３５０の処理に必要な性能データをストレージ性能分析プログラム３１２から取得し加工する目的で性能情報集計部３５１を、移行先負荷モデル推定部３５２や移行先構成設計部３５３における処理に必要とする移行先の情報を管理する移行先仕様管理部３５４を、移行先構成設計部３５３の処理に必要な補正値を管理する補正値管理部３５５を、それぞれの機能別に備える。

ストレージ構成見積もりプログラム３１１は概ね、移行元における負荷をモデル化し、同じく移行先の負荷を表すモデルに当てはめた上で、性能要件ほかの要件を満たすように設計値を定め、複数存在するボリューム種別毎に同様の設計を繰り返す、という処理を実現する。

移行元負荷モデル推定部３５０は、移行元である第一の計算機システム１Ｓにおいて、指定されたストレージリソースにおける負荷（ＩＯＰＳ）を統計的にモデル化するものである。より具体的には、例えばＩＯＰＳの発生確率が指数分布やポアソン分布に従うとして最尤法により平均や分散などのパラメータを比定するものや、同様に正規分布のカーネル密度推定により特定のカーネル関数の重ね合わせと比定するものがある。

移行元負荷モデルの母分布を推定する手法は、反復アルゴリズムや機械学習による。移行元負荷モデルは論理ボリューム１６または仮想ディスク１７毎に作成され、ストレージ性能分析プログラム３１２から負荷モデル作成対象であるリソース部分の性能データを取得し、性能情報集計部３５１の集約処理を経たもの、すなわち所定の評価区間において集計やリサンプリング、欠損値処理を施したものを入力（学習データ）とする。

移行元負荷モデル推定部３５０において同定されたパラメータとして、例えば発生確率を与える母分布の平均や分散を、以降の移行先負荷モデル推定部３５２の処理に用いる。移行元負荷の非定常性（時間軸に対して移動平均が変動する性質）が強い場合には、母分布推定を定常成分のみに限定し、非定常なトレンドや周期成分を別途回帰問題としてさらにモデル化してもよい。

また要求される見積もりが将来の区間を含む場合には、非定常成分を加味して上記の母分布における平均をシフトする。また、カーネル密度推定などによって、移行元負荷モデルが複数の確率分布に従う混合分布であると想定される場合には、各母分布（カーネル関数）をそれぞれ推定し、移行先負荷モデルもそれぞれ別に考える。この場合は、見積もり結果を各移行先負荷モデルの出力による重み付き線形結合で表現する。

移行先負荷モデル推定部３５２は、移行先である第二の計算機システム２Ｓにおいて、あるボリューム種別について定められた仕様をもとに、論理ボリューム２６に生じうる負荷をモデル化するものである。ここでは、課金方法のＩＯ性能における要件をもとに、待ち行列モデルを用いることを考える。このとき、待ち行列において待ちに入る到着過程が移行元負荷モデル推定部３５０が表す負荷、待ちから出ていく時間当たり処理能力が移行先論理ボリュームにおける性能（ベースライン性能６３５）、待ち状態にある量がバケット型課金方法においてバケットに蓄積されたＩＯ量と比定できる。

最も単純に、移行元負荷が指数分布やポアソン分布でモデル化できる場合、移行先の負荷は待ち行列の平均や分散などのパラメータを用いて解析的に同定できる。したがって、この場合は移行先負荷の推定に機械学習や他の反復的手法によるモデル同定が不要である点において、推定にかかる処理量を低減することができる。

より具体的には、移行先負荷を待ち行列としてモデル化した場合、バケットに蓄積されるＩＯの平均値が待ち行列の平均待ち長さに相当し、また蓄積されるＩＯが増減する度合は待ち行列の分散により表現される。このとき、待ち行列の分散から定められる特定のパーセンタイルを、バケットバランスの最大ではないが十分大きい値であるとみなして、基準待ち長さと呼ぶこととする。

ただし、特に移行先のストレージ装置２００が不特定多数のサーバ装置２０から負荷を受けている状況では、ストレージ構成見積もりプログラム３１１で対象とするストレージリソースの他にも同一の論理ボリューム２１６の性能に影響するものが存在しており、また前述のように設計値が少数に限られており、それらの他者の影響を検知するための性能指標が十分に得られない可能性が残ることから、第二の計算機システム２Ｓの運用者が公称する仕様が厳密に保証されるとは限らない。

移行先構成設計部３５３は、移行先負荷モデル推定部３５２において同定されたパラメータに基づいて、補正値管理部３５５やストレージ構成管理プログラム３１５の情報により所定の補正を加えた上で、特定のボリューム種別における容量およびＩＯ性能の設計を行う。原則として、最大性能型の課金方法においては基準待ち長さが最大ＩＯ設計値に相当し、バケット型では平均待ち長さがベースライン性能、基準待ち長さがバースト時性能に相当するが、ストレージ容量の縮減が容易でないという第二の計算機システム２Ｓの特性に鑑みて、これらの値を補正する。

具体的には、移行先負荷モデル推定部３５２が出力する各パラメータに対し、グレード毎に定義した設計補正値を係数として乗じたものを性能要件に基づく設計値とする。このとき、設計補正値は、補正前後のリソース量比率を与える正の数値である。設計補正値はストレージ構成管理プログラム３１５が管理するグレード定義情報３２０を参照し、見積もり処理のなかでは補正値管理部３５５において管理される。グレードはユーザが期待する性能と価格の優先度が反映されたものであるから、より性能を重視するグレードには性能要件上の同定パラメータに近い設計値を、より価格を重視するグレードには同定パラメータに強く下方修正を施した（比較して小さくなるよう変更した）設計値を性能要件上の結果として採用する。

これにより、価格を重視するグレードを移行する場合には、性能が不足する恐れはあるが課金額を小さく見積もった結果が得られる。仮にそのような低課金額の見積もり結果を経て、実際に移行された後に性能が不足する事態が生じても、移行後の第二の計算機システム２Ｓにおける、容量の追加により不足分のＩＯ性能を容易に補うことができる。移行先構成設計部３５３は、その他、ストレージ構成管理プログラム３１５から得た各論理ボリューム１１６の容量（予約または実使用容量）と、性能要件による容量設計値とを比較してより大きい値を最終的な設計値とし、双方の条件をともに満たすよう調整する。

移行先構成設計部３５３は、その他の設計事項についても検証し、ボリューム種別によって機能要件が合致しない場合、例えば移行元の論理ボリューム１６または仮想ディスク１７がＯＳ起動用のストレージ領域である場合に移行先ボリューム種別がそれらをサポートしない場合など、には移行先として不適当であると判断する。また、最終的な処理結果としてはコスト最適である移行先構成を示すことを目的とするが、ユーザの判断材料として多角的な評価が必要な場合に備え、課金額以外の構成も併せて処理結果とする。

本実施例においては、移行先の情報として、移行の実績に関わる情報、例えば過去に同様のストレージ移行が実際に行われた際にＩＯ性能がどのように変化したか、といった履歴を含まない。このとき、移行先の情報を提供する移行先仕様管理部３５４は、第二の計算機システム２Ｓの運用者によって公開されている課金方法についての仕様などの事前情報のみを扱っており、例えば第二の計算機システム２Ｓに関する稼働状況についての情報が全く得られていない場合においても、本実施例に述べる見積もり方法が実現可能であることが示唆される。

＜実施例１のストレージ構成見積もり処理＞
図１２は、実施例１におけるストレージ構成見積もり処理を示すフローチャートである。以降の処理は、主に管理コンピュータ３０１上のストレージ構成見積もりプログラム３１１において実行される。

ステップ（以下ステップを“Ｓ”と記載する）７００では、ストレージ構成見積もりプログラム３１１は、ユーザによる移行対象のインスタンスまたはストレージリソースの指定を受け付けることで処理フローを開始する。移行先である第二の計算機システム２Ｓにおけるリソースが潤沢に提供されていることを踏まえると、移行対象が複数であった場合は少なくとも本処理フローを繰り返し適用することで複数の移行対象について同様に見積もり可能である。またＳ７００において、ユーザは、見積もり結果のうち最大効果のもののみを取り出すか否かなど、見積もり処理に関する要求を合わせて行ってもよい。

Ｓ７０１において、ストレージ構成見積もりプログラム３１１は、Ｓ７００で受け付けた移行処理要求で移行対象に指定されたインスタンスまたはストレージリソースを特定する。Ｓ７０１では、ストレージ構成見積もりプログラム３１１は、指定されたインスタンスまたはストレージリソースについて、対象となる論理ボリューム１１６を判別し、グレードや使用容量などの構成、および性能情報を取得するために必要な識別子（ボリュームＩＤ）を合わせて判別する。Ｓ７０１が終了すると、ストレージ構成見積もりプログラム３１１は、移行元負荷モデル推定Ｓ７０２（Ｓ７０３～Ｓ７０５）および補正値判定Ｓ７１１へ処理を移す。移行元負荷モデル推定Ｓ７０２は、ストレージ構成見積もりプログラム３１１の移行元負荷モデル推定部３５０によって実行される。

Ｓ７０３では、移行元負荷モデル推定部３５０は、Ｓ７０１において判別された識別子を用いて、同じくＳ７０１で判別された対象となる論理ボリューム１１６の性能情報を、ストレージ性能管理プログラム３１３から取得する。ストレージ構成見積もりプログラム３１１内の性能情報集計部３５１は、ストレージ性能分析プログラム３１２から取得された性能情報に対して集約処理を実施する。

図１１に示すように、性能情報の集約処理では、所定の評価区間において、主にＩＯＰＳの時間変化についてのデータが、移行元負荷モデル推定に適するよう加工される。所定の評価区間は、既定のものを用いてもよいし、Ｓ７００のリソース指定時にユーザによって都度指定されてもよい。所定の評価区間は、少なくとも移行元環境においてある程度の使用実績があり、かつ高負荷を含む期間であることが望ましい。

Ｓ７０４では、移行元負荷モデル推定部３５０は、移行元負荷モデルとして適切なモデルを選択する。Ｓ７０４では、例えば過去に同様のストレージリソースの見積もりが行われた場合には、過去の見積もり時と同一のモデルを選ぶ。あるいは見積もり処理に関わる処理時間が許容すれば、複数のモデルを用いて実際に評価を行い、最もモデル化誤差を小さくするものを選べばよい。

Ｓ７０５では、移行元負荷モデル推定部３５０は、Ｓ７０４にて選択されたモデルについて移行元負荷モデルのパラメータを評価する。前述の通り、最も簡便には単一のポアソン分布などの母分布を想定した場合、後段の移行先負荷モデル推定Ｓ７０６の入力となる平均到着率を推定する。Ｓ７０５が終了すると、ストレージ構成見積もりプログラム３１１は、移行先負荷モデル推定Ｓ７０６（Ｓ７０７～Ｓ７０９）へ処理を移す。移行先負荷モデル推定Ｓ７０６は、ストレージ構成見積もりプログラム３１１の移行先負荷モデル推定部３５２によって実行される。移行先負荷モデル推定Ｓ７０６では、ボリューム種別毎に負荷の評価を行う。

Ｓ７０７では、移行先負荷モデル推定部３５２は、移行先として想定される全てのボリューム種別について、未評価のボリューム種別の中から１つ選択する。Ｓ７０８では、移行先負荷モデル推定部３５２は、移行先のボリューム種別をＳ７０７で選択されたボリューム種別とした場合の移行先負荷モデルのパラメータを評価する。移行先負荷モデルの離脱速度や最大待ち容量を定める仕様は、移行先仕様管理部３５４において管理される。移行元負荷モデル推定Ｓ７０２において移行元の負荷を到着過程としてモデル化できれば、移行先の負荷を待ち行列とモデル化でき、Ｓ７０８の移行先パラメータの評価において待ち行列の平均待ち長さや分散を評価できる。

Ｓ７０９では、移行先として想定される全てのボリューム種別のうち移行先パラメータが未評価である残りボリューム種別があるか否かを判定し、残りボリューム種別ある場合（Ｓ７０９Ｙｅｓ）にステップＳ７０７に処理を移し、残りボリューム種別ない場合（Ｓ７０９Ｎｏ）にステップＳ７１０に処理を移す。

Ｓ７１０では、移行先構成設計部３５３は、Ｓ７０７で負荷を評価したボリューム種別のうち、移行先のＩＯ負荷およびその他の要件に適合するボリューム種別を判別する。上述したように、Ｓ７１０は、移行先構成設計部３５３が、移行対象として指定されたストレージリソースの構成をストレージ構成管理プログラム３１５から取得し、当該ボリューム種別の仕様と比較することにより実現できる。例えば移行元における当該論理ボリューム１１６の使用容量が、当該ボリューム種別が提供可能な容量の範囲を逸脱している場合には適合しないものとして除外する。

一方で、Ｓ７１１では、ストレージ構成見積もりプログラム３１１は、Ｓ７０１において判別されたグレードに基づいて補正値を決定し、補正値管理部３５５に保存する。Ｓ７１２では、移行先構成設計部３５３は、Ｓ７０１で適合すると判定されたボリュームについての移行先負荷モデルに基づいて、第二の計算機システム２Ｓにおける移行先のストレージリソースのリソース構成を設計すると共に、この設計に関する設計値に、Ｓ７１１において決定された設計補正値を乗じて補正する。設計値は、移行先での課金額に直接的に関係する容量やＩＯ性能などである。

Ｓ７１３では、移行先構成設計部３５３は、最終見積もり結果として提示する移行後のリソースの設計値や、課金額を最終決定する。Ｓ７１４では、移行先構成設計部３５３は、Ｓ７１３で決定した最終的な設計値や、最終的な設計値の算出基礎である補正前の設計値、補正前の設計値に乗じた設計補正値などを、ユーザに対して表示したり、ユーザが使用する別の管理プログラムに転送したりし、ストレージ構成見積もり処理を終了する。あるいはＳ７１４では、ユーザが処理開始時に指定した要求に応じて、最小の課金額のリソース構成の設計値のみを結果として提示したり、性能値の設計余裕が最大のリソース構成の設計値のみを結果として提示したりしてもよい。

本実施例によれば、例えばオンプレミス環境を想定した第一の計算機システム１Ｓからパブリッククラウド環境を想定した第二の計算機システム２Ｓへとストレージリソースを移行する際に、事前に構成を見積もる機能が提供される。移行先の構成の詳細や利用状況が自明でない場合であっても、主要な設計値を導出することができ、サイジングに必要な処理量を削減することができる。また、移行元の利用条件に応じてリソースの見積もり量を補正し、ストレージの利用コストを抑制することができる。

本実施例では、オンプレミス環境で稼働するストレージリソースをパブリッククラウドへ移行した際に構成を見積もり、かつ過去に実際に移行を行った後の稼働情報から見積もり方法を修正するシステムが提供される。本実施例は先の実施例1に加えてより正確な見積もり方法を実現するものである。

本実施例におけるシステム構成や、管理プログラムの処理内容の多くは実施例１と共通であり、ここでは専ら差異について説明する。

前述の通り、本発明の要点の一つは移行先および移行元における負荷のモデル化であるが、見積もり結果と、実際の移行対象のシステムにおける稼働状況には、負荷に差が生じる場合がある。本実施例では、特に移行元負荷モデル推定と移行先負荷モデル推定におけるそれぞれのモデル化誤差に基づいて見積もり方法を改善するための追加の機能を備える。

より具体的には、管理プログラムの一つであるストレージ構成見積もりプログラム３１１において、移行先構成設計部３５３が移行後の状況を示す移行履歴３６０をもとに見積もり方法の改善処理を実現する（図１１参照）。ここでいう移行履歴３６０とは、課金額の算定と移行先負荷に関わる実績値であり、移行先のストレージのＩＯＰＳの時系列変化や、バケット型であればバケットバランスの時系列データを、設計値と対応を付けた履歴である。移行履歴３６０は、第二の計算機システム２Ｓにおいてサポートされる監視機能を利用し、ストレージリモート管理インタフェースプログラム４１１を介して取得できる。

移行元負荷モデル推定部３５０におけるモデル化誤差は、主に移行元における性能データを集約する手順の良さに関わる。前述の通り、移行元負荷モデルとして特定の確率母分布を想定するが、第一の計算機システム１Ｓにおいてパラメータ推定に用いる実性能データの区間の取り方や、確率分布の選択によって、実データとモデルとの間に誤差が生じる。本実施例では、性能データの集約方法やモデル選択の調整によって、より精度の高い推定を行う。

移行先負荷モデル推定部３５２におけるモデル化誤差は、主に第二の計算機システム２Ｓにおける外乱の多寡に関わる。移行先負荷モデルは、第二の計算機システム２Ｓが公称する性能特性を表現するものであるが、前述の通り、第二の計算機システム２Ｓ内における他のユーザの負荷との競合や、性能を左右する他の設計値の影響によって、公称値からの誤差が生じる。本実施例では、ある移行前後に生じる誤差を用いて移行先（第二の計算機システム２Ｓ）における外乱的要因を評価し、見積もり方法を調整する。

本実施例によれば、数理モデルを用いて移行元負荷および移行先負荷を推定し、負荷やリソースの特性、リソースの構成に支配的に関わる量の関係を表現し、ユーザの挙動や移行元の利用条件に基づいて移行先リソースを設計するので、移行先リソースのサイジングを適切かつ効率的に行うことができる。またマージン（設計余裕）の過大評価によるリソース利用コストの増大を抑制する。

また本実施例によれば、移行先の構成の詳細が自明でない場合であっても、主要な設計値（容量やＩＰＯＳなど）を導出することができる。また解析的モデルを用いることで負荷推定の処理コストが増大しないよう抑制することにより、移行先リソースのサイジングに必要な処理量を削減する。また移行元リソースの利用条件（要求されるサービスレベルを表すグレード）に応じた設計補正値（図５）を用いて、設計値をリソースの見積もり量を減じる方向へ補正することで、事後に減設が難しいストレージ等の見積もりを、リソースの利用コストを抑制しつつ適切に見積ることができる。

＜実施例２のストレージ構成見積もり処理＞
図１３は、実施例２におけるストレージ構成見積もり処理を示すフローチャートである。図１３の実施例２のストレージ構成見積もり処理のフローチャートにおいて、図１２の実施例１の見積もり処理におけるステップと同一のステップには同一ステップ番号を付与して説明を省略する。

実施例２における見積もり処理は、実施例１と同様に、主に管理コンピュータ３０１上のストレージ構成見積もりプログラム３１１において実行される。本実施例の見積もり処理では、実施例１と同様に、Ｓ７００において、トレージ構成見積もりプログラム３１１は、ユーザによる移行対象のインスタンスまたはストレージリソースの指定を受け付けることで処理フローを開始する。

Ｓ７０１が終了すると、ストレージ構成見積もりプログラム３１１は、移行元負荷モデル推定Ｓ７０２（Ｓ７０３～Ｓ７０５）、補正値判定Ｓ７１１、および移行履歴の取得Ｓ７１１Ａへ処理を移す。

Ｓ７０２では、実施例１と同様に、Ｓ７０１において判別された識別子を用いて論理ボリューム１１６の性能情報を取得および集計し（Ｓ７０３）、集計された性能情報に基づいて移行元負荷モデルとして適切なモデルを選択し（Ｓ７０４）し、選択されたモデルについて移行元負荷モデルのパラメータを評価する（Ｓ７０５）。Ｓ７０５では、例えば移行元負荷モデルをポアソン分布などの確率母分布とし、移行先負荷モデルの入力となる平均到着率を推定する。

ここで本実施例における性能情報は、実施例１と同じく性能情報集計部３５１において集約処理が実施される。しかし移行元負荷モデル推定Ｓ７０２の後にＳ７０５Ａにおいて実行されるモデル化誤差の評価結果によっては、集約処理の期間が修正され得る。

特に第一の計算機システム１Ｓにおけるサーバ装置１０の起動時やソフトウェア更新など、アプリケーション１４の通常の処理負荷とは大きく異なる状況での性能情報は、モデル化の目的と離反する部分である。よって、対象期間の見直しによって性能情報から除外することでモデル化誤差を解消できる可能性がある。Ｓ７０５Ａでモデル化誤差が十分許容できる範囲内であるか否かの判定の結果、Ｓ７０３の性能情報の収集が再実行されることにより、Ｓ７０４におけるモデル選択が修正される場合がある。Ｓ７０５Ａでは、移行元負荷モデルの検定による信頼度判定により、モデル化誤差の評価を行う。

Ｓ７０５Ａにおいてモデル化誤差が十分許容できる所定範囲内と判定された以降は、ストレージ構成見積もりプログラム３１１は、移行先負荷モデル推定Ｓ７０６（Ｓ７０７、Ｓ７０８、およびＳ７０９）に処理を移す。そしてストレージ構成見積もりプログラム３１１は、Ｓ７０６に続き、Ｓ７１０、Ｓ７１２を実行する。

Ｓ７１１では、ストレージ構成見積もりプログラム３１１は、Ｓ７０１において判別されたグレードに基づいて設計補正値を決定し、補正値管理部３５５において管理する。Ｓ７１２では、移行先構成設計部３５３は、Ｓ７０１で適合すると判定されたボリュームについての移行先負荷モデルに基づいて、第二の計算機システム２Ｓにおける移行先のストレージリソースを設計すると共に、この設計に関する設計値を、Ｓ７１１において決定された設計補正値をもとに修正する。しかしながら、移行先の第二の計算機システム２Ｓに外乱的要素が含まれる場合には、Ｓ７１１において決定された設計補正値をさらに再設定する必要が生じる。

そこで本実施例では、移行先構成設計部３５３は、Ｓ７１２Ａにおいて、当該見積もり対象のボリュームと類似の構成を持つ移行実績の履歴を検索し、移行実績の履歴に基づく移行先リソースの設定実績値と、移行先負荷モデル推定Ｓ７０６の結果との誤差を算出する。移行先構成設計部３５３は、この誤差が所定値以上の場合には設計補正値を再設定して移行先パラメータを補正するようにＳ７１１を再度実施し、誤差が所定値未満の場合にはＳ７１３に処理を移す。

Ｓ７１２における設計補正値の再設定方法として、例えば外乱が多く、競合する処理負荷が第二の計算機システム２Ｓ上で既に稼働していると想定される場合には、設計補正値を増加方向に再設定し、移行先負荷モデル推定Ｓ７０６の出力よりも多くのリソースを確保するようサイジングする。また外乱が小さく、競合する処理負荷が第二の計算機システム２Ｓ上で稼働していないと想定される場合には、設計補正値を減少方向に再設定し、モデル出力よりも楽観的に、より少ないリソースの取得にとどめるようサイジングする。

より具体的には例えば、設計補正値による補正量が小さく、性能よりも価格が重視されているグレードに対して移行履歴におけるバケットバランスが小さい場合、つまり外乱が生じていないと想定される場合に、サイジング結果がさらに小さくなるよう設計補正値を下方修正する。一方で、外乱が大きいと想定される場合、移行元対象が性能重視のグレードであった場合には、設計補正値による下方修正を緩めて、より多くのリソースを確保するように設計値を見直す。

本実施例によれば、実施例１の効果に加えて、過去の同様の構成のリソースの移行履歴に基づいて実際の利用状況に適応させてサイジング結果を補正することで、移行後のリソース構成の見積もりの精度を改善することができる。このとき、見積もり方法において移行元および移行先の挙動を表す数理モデルは、モデルの種類を選ぶ方法やモデル評価のための性能情報の選び方、あるいはパラメータを調整する方法に違いはあっても、解析的モデルを用いる点は変わっておらず、移行元モデルおよび移行先モデルの複雑化を回避できる。これは、例えば機械学習によって構成されるような説明変数の合成量や確率変数を用いるモデルとは異なり、支配的な物理量の関係を表現している点において実際の稼働実績との差異をどのように用いてサイジング結果を修正すべきかを判別できる利点がある。

なお実施例１および実施例２において、移行元のストレージリソースの入出力の特性に応じて、Ｓ７０５Ａのモデル化誤差を評価するための所定範囲、および／または、Ｓ７１２Ａの誤差を評価するための所定値を調整してもよい。例えば計算機システムからネットワークへ情報を送出する下り方向が上り方向よりも課金額が高い場合を考える。この場合に、移行元の第一の計算機システムの１Ｓのストレージの入出力（Ｒｅａｄ／Ｗｒｉｔｅ）のうちＲｅａｄが多いとき、Ｓ７０５の所定範囲および／またはＳ７１２Ａの所定値をより小さくして評価精度を高める。一方、Ｗｒｉｔｅが多い場合には、Ｓ７０５の所定範囲および／またはＳ７１２Ａの所定値をより大きくして評価精度を緩める。このように、ストレージリソースの移行に際し、移行元のストレージリソースのＩＯ特性に応じてＳ７０５Ａおよび／またはＳ７１２の評価精度を調整することで、より厳密にコストを意識して移行先のリソース構成の設計を行うことができる。

また上述の実施例１および実施例２では、第一の計算機システム１Ｓをオンプレミス環境、第二の計算機システム２Ｓをパブリッククラウド環境として説明した。しかしこれに限らず、第一の計算機システム１Ｓをパブリッククラウド環境、第二の計算機システム２Ｓをオンプレミス環境とする場合や、第一の計算機システム１Ｓおよび第二の計算機システム２Ｓが共にパブリッククラウド環境である場合でもよい。すなわち第一の計算機システム１Ｓおよび第二の計算機システム２Ｓが、オンプレミス環境、パブリッククラウド環境の何れであるかを問わない。

＜管理コンピュータ３０１，４０１を実現するコンピュータ５０００＞
図１４は、管理コンピュータ３０１，４０１等の各装置を実現するコンピュータ５０００のハードウェア図である。コンピュータ５０００では、プロセッサ５１００、メモリ５２００、ストレージ５３００、ネットワークインタフェース５４００、入力装置５５００、および出力装置５６００が、バス５７００を介して接続されている。プロセッサ５１００は、ＣＰＵ（Central Processing Unit）等である。メモリ５２００は、ＲＡＭ（Random Access Memory）等である。ストレージ５３００は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、媒体読取装置等である。入力装置５５００は、キーボード、マウス、タッチパネル等である。出力装置５６００は、ディスプレイ等である。

コンピュータ５０００において、前述の各装置を実現するための各プログラムがストレージ５３００から読み出されて、プロセッサ５１００及びメモリ５２００の協働により実行されることにより、各装置がそれぞれ実現される。あるいは、各装置を実現するための各プログラムは、ネットワークインタフェース５４００を介した通信により外部のコンピュータから取得されてもよい。あるいは、各装置を実現するための各プログラムは、可搬型の記録媒体（光学ディスク、半導体記憶媒体等）に記録され、媒体読取装置により読み出されて、プロセッサ５１００及びメモリ５２００の協働により実行されてもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明する為に詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置換することも可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。言い換えると、本発明の技術思想の範囲内で矛盾しない限りにおいて、各実施例および変形を組合せることができる。また、実施例における構成および処理の分散および統合を適宜行うことができる。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、各構成を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、集積回路搭載カード、半導体記録媒体、光学式記録媒体等の記録媒体に置くことができる。

１Ｓ：第一の計算機システム、２Ｓ：第二の計算機システム、３０１：管理コンピュータ、３１１：ストレージ構成見積もりプログラム、３５０：移行元負荷モデル推定部、３５１：性能情報集計部、３５２：移行先負荷モデル推定部、３５３：移行先構成設計部

Claims (12)

1. 移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムであって、
   前記第一のリソースの負荷を表す移行元負荷モデルを推定する移行元負荷モデル推定部と、
   前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定部と、
   前記第一のリソースの性能要件と、前記移行先負荷モデル推定部によって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計部と、を有し、
   前記移行先構成設計部は、
   前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を、要求されるサービスレベルに応じた設計補正値を用いて、前記リソース構成の設計の余裕度を小さくする方向へ補正する
   ことを特徴とするリソース構成見積もりシステム。
2. 前記第一のリソースおよび前記第二のリソースは、ストレージリソースであり、
   前記移行先負荷モデル推定部は、
   前記第二のリソースのボリューム種別毎に前記移行先負荷モデルを推定し、
   前記移行先構成設計部は、
   前記性能要件と、前記移行先負荷モデル推定部によって推定された前記ボリューム種別毎の前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルのボリューム種別を判別し、
   前記性能要件に適合する前記移行先負荷モデルのボリューム種別についての前記移行先負荷モデルに基づく前記リソース構成の設計値を、前記設計補正値を用いて修正する
   ことを特徴とする請求項１に記載のリソース構成見積もりシステム。
3. 前記移行元負荷モデルは、前記第一のリソースの負荷を確率モデルで表し、
   前記移行先負荷モデルは、前記第二のリソースの負荷を待ち行列で表す
   ことを特徴とする請求項１に記載のリソース構成見積もりシステム。
4. 前記確率モデルは、ポアソン分布、指数分布、または正規分布のカーネルである
   ことを特徴とする請求項３に記載のリソース構成見積もりシステム。
5. 前記移行先負荷モデル推定部は、
   前記待ち行列の平均待ち長さと、前記待ち行列の長さの分散から定められる特定パーセンタイルである基準待ち長さとを推定し、
   前記移行先構成設計部は、
   前記リソース構成の設計値を決定する際、
   前記第二の計算機システムのストレージリソースの課金方法が、最大性能型の場合には前記平均待ち長さを最大ＩＯ設計値とし、バケット型の場合には前記平均待ち長さをベースライン性能、前記基準待ち長さをバースト時性能とする
   ことを特徴とする請求項３に記載のリソース構成見積もりシステム。
6. 前記第一の計算機システムはオンプレミス環境上に構築され、
   前記第二の計算機システムはパブリッククラウド環境上に構築されている
   ことを特徴とする請求項１に記載のリソース構成見積もりシステム。
7. 前記移行元負荷モデル推定部は、
   評価期間における前記第一のリソースの性能の実績データに基づいて前記移行元負荷モデルを推定し、推定した前記移行元負荷モデルに関するモデル化誤差が所定範囲内であるか否かを評価し、前記モデル化誤差が前記所定範囲外である場合に前記評価期間を修正し、修正した前記評価期間における前記第一のリソースの性能の実績データに基づいて前記移行元負荷モデルを再推定する
   ことを特徴とする請求項１に記載のリソース構成見積もりシステム。
8. 前記移行先構成設計部は、
   前記第一のリソースの入出力の特性に応じて、前記モデル化誤差を評価するための前記所定範囲を調整する
   ことを特徴とする請求項７に記載のリソース構成見積もりシステム。
9. 前記移行先構成設計部は、
   前記第一のリソースと類似の構成を持つ過去のリソースの移行履歴に基づく設計実績値と前記設計値との誤差が所定値以上の場合に、前記設計補正値を再設定し、再設定した前記設計補正値を用いて前記設計値を再補正する
   ことを特徴とする請求項１に記載のリソース構成見積もりシステム。
10. 前記移行先構成設計部は、
    前記設計補正値の再設定では、前記移行履歴と前記サービスレベルとに基づいて前記設計補正値を増加または減少させる
    ことを特徴とする請求項９に記載のリソース構成見積もりシステム。
11. 前記移行先構成設計部は、
    前記第一のリソースの入出力の特性に応じて、前記誤差を評価するための前記所定値を調整する
    ことを特徴とする請求項９に記載のリソース構成見積もりシステム。
12. 移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムが行うリソース構成見積もり方法であって、
    前記第一のリソースの負荷を表す移行元負荷モデルを推定する移行元負荷モデル推定ステップと、
    前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定ステップと、
    前記第一のリソースの性能要件と、前記移行先負荷モデル推定ステップによって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計ステップと、を有し、
    前記移行先構成設計ステップでは、
    前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を、要求されるサービスレベルに応じた設計補正値を用いて前記リソース構成の設計の余裕度を小さくする方向へ補正する
    ことを特徴とするリソース構成見積もり方法。

Images