(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022158061
(43)【公開日】2022-10-14
(54)【発明の名称】表示方法、及び表示プログラム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20221006BHJP
G06F 9/50 20060101ALI20221006BHJP
G06F 9/455 20060101ALI20221006BHJP
G06Q 30/02 20120101ALI20221006BHJP
【ＦＩ】
G06Q50/10
G06F9/50 120Z
G06F9/455 150
G06Q30/02 490
【審査請求】未請求
【請求項の数】11
【出願形態】ＯＬ
(21)【出願番号】P 2021062690
(22)【出願日】2021-04-01
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100087480
【弁理士】
【氏名又は名称】片山 修平
(72)【発明者】
【氏名】佐藤 昌浩
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049CC12
(57)【要約】
【課題】移行すべきコンテナを利用者が判断できるようにすることを目的とする。
【解決手段】第１システムで動作しているプログラムに割り当てられた第１リソース量を特定し、第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、算出した前記利用料金を表示する、処理をコンピュータが実行する。
【選択図】図１５
【解決手段】第１システムで動作しているプログラムに割り当てられた第１リソース量を特定し、第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、算出した前記利用料金を表示する、処理をコンピュータが実行する。
【選択図】図１５
【特許請求の範囲】
【請求項1】
第１システムで動作しているプログラムに割り当てられた第１リソース量を特定し、
第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、
前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、
算出した前記利用料金を表示する、
処理をコンピュータが実行することを特徴とする表示方法。
第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、
前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、
算出した前記利用料金を表示する、
処理をコンピュータが実行することを特徴とする表示方法。
【請求項2】
前記プログラムにアクセスするときのＡＰＩ（アプリケーションプログラミングインターフェイス）ごとの通信量を特定する処理を更に有し、
前記第２リソース量を決定する処理において、前記第２リソース量の比率が、前記通信量の比率となるように前記第２リソース量を決定することを特徴とする請求項１に記載の表示方法。
前記第２リソース量を決定する処理において、前記第２リソース量の比率が、前記通信量の比率となるように前記第２リソース量を決定することを特徴とする請求項１に記載の表示方法。
【請求項3】
前記第２リソース量は、前記プログラムの前記第１リソース量以上であることを特徴とする請求項１又は２に記載の表示方法。
【請求項4】
前記第１システムにおける前記プログラムの前記第１リソース量は、予め定められた閾値以上であることを特徴とする請求項３に記載の表示方法。
【請求項5】
前記第１リソース量以上の前記第２リソース量の中で、前記利用料金が最安値になる第２リソース量の前記プログラムを前記第１システムから前記第２システムへの移行対象として選択する処理を更に有することを特徴とする請求項３又は４に記載の表示方法。
【請求項6】
前記プログラムが出力するログを格納するデータベースにおけるデータ種別ごとのデータ量を特定する処理を更に有し、
前記第２リソース量を決定する処理において、前記第２リソース量の比率が、前記データ量の比率となるように前記第２リソース量を決定することを特徴とする請求項１に記載の表示方法。
前記第２リソース量を決定する処理において、前記第２リソース量の比率が、前記データ量の比率となるように前記第２リソース量を決定することを特徴とする請求項１に記載の表示方法。
【請求項7】
前記第２リソース量を決定する処理において、前記プログラムにアクセスするときのＡＰＩ（アプリケーションプログラミングインターフェイス）が同じ種類である場合、前記第２リソース量の比率が、均等となるように前記第２リソース量を決定することを特徴とする請求項１に記載の表示方法。
【請求項8】
前記プログラムのグループを生成する処理と、前記プログラムのプログラム間通信の通信関係に基づいて、前記プログラムを前記グループに登録する処理を更に有し、
前記第２リソース量を決定する処理において、前記グループごとに、前記第２リソース量を決定することを特徴とする請求項１から７のいずれか１項に記載の表示方法。
前記第２リソース量を決定する処理において、前記グループごとに、前記第２リソース量を決定することを特徴とする請求項１から７のいずれか１項に記載の表示方法。
【請求項9】
前記グループを登録する処理において、前記プログラム間通信の通信頻度が予め定められた閾値頻度より低い前記プログラムは前記グループの登録対象から除外することを特徴とする請求項８に記載の表示方法。
【請求項10】
前記第２システムから前記第１システムに向かう通信の通信料を算出する処理を更に有し、
前記利用料金を算出する処理において、前記通信料を前記利用料金に加算した総利用料を算出することを特徴とする請求項１から９のいずれか１項に記載の表示方法。
前記利用料金を算出する処理において、前記通信料を前記利用料金に加算した総利用料を算出することを特徴とする請求項１から９のいずれか１項に記載の表示方法。
【請求項11】
第１システムで動作しているプログラムに割り当てられた第１リソース量を特定し、
第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、
前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、
算出した前記利用料金を表示する、
処理をコンピュータに実行させることを特徴とする表示プログラム。
第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、
前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、
算出した前記利用料金を表示する、
処理をコンピュータに実行させることを特徴とする表示プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本件は表示方法、及び表示プログラムに関する。
【背景技術】
【0002】
オンプレミス上のシステムで複数のコンテナが動作している場合に、特定のコンテナに処理が集中することがある。その結果、その特定のコンテナの稼働に要するリソースが不足し、システムとしての性能が低下することがある。このような場合、例えば対象のコンテナをパプリッククラウド上のシステムにスケールアウトにより移行して、リソース不足を解消することが想定される。
【0003】
しかしながら、コンテナをパプリッククラウド上のシステムに移行すると、パプリッククラウド上のシステムを利用する利用料金が発生することがある。この利用料金はコンテナが利用するリソースのリソース量に応じて決定されている。このため、コンテナを単純にパプリッククラウド上のシステムに移行すると、システムの性能低下が抑制されても、多大な利用料金が請求される可能性がある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１５－１５２９８４号公報
【特許文献2】米国特許出願公開第２０１６／０１７３４１１号明細書
【特許文献3】特表２０２０－５１８９３２号公報
【特許文献4】特開２０１６－２０６９５２号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
一側面によれば、移行すべきコンテナを利用者が判断できるようにすることを目的とする。
【課題を解決するための手段】
【0006】
一側面によれば、第１システムで動作しているプログラムに割り当てられた第１リソース量を特定し、第２システムにおいて前記プログラムに割り当てる第２リソース量を、前記第１リソース量に基づいて決定し、前記第２システムの利用料金を、前記第２リソース量に基づいて算出し、算出した前記利用料金を表示する、処理をコンピュータが実行する。
【発明の効果】
【0007】
一側面によれば、移行すべきコンテナを利用者が判断できる。
【図面の簡単な説明】
【0008】
【図5】図５（ａ）は第１収集部が実行する処理の一例を示すフローチャートである。図５（ｂ）は第２収集部が実行する処理の一例を示すフローチャートである。図５（ｃ）は第３収集部が実行する処理の一例を示すフローチャートである。
【発明を実施するための形態】
【0009】
以下、本件を実施するための形態について図面を参照して説明する。
【0010】
（第１実施形態）
図１に示すように、第１システムＳＴ１は、第１担当者端末１１０、第２担当者端末１２０、ユーザ端末１３０、管理サーバ２００とともに、オンプレミス側に配置されている。第１システムＳＴ１、第１担当者端末１１０、第２担当者端末１２０、ユーザ端末１３０、管理サーバ２００は第１通信ネットワークＮＷ１によって互いに接続されている。第１通信ネットワークＮＷ１としては例えばＬＡＮ(Local Area Network)などがある。第１通信ネットワークＮＷ１はインターネットといった第２通信ネットワークＮＷ２と接続されている。
図１に示すように、第１システムＳＴ１は、第１担当者端末１１０、第２担当者端末１２０、ユーザ端末１３０、管理サーバ２００とともに、オンプレミス側に配置されている。第１システムＳＴ１、第１担当者端末１１０、第２担当者端末１２０、ユーザ端末１３０、管理サーバ２００は第１通信ネットワークＮＷ１によって互いに接続されている。第１通信ネットワークＮＷ１としては例えばＬＡＮ(Local Area Network)などがある。第１通信ネットワークＮＷ１はインターネットといった第２通信ネットワークＮＷ２と接続されている。
【0011】
第２システムＳＴ２はクラウド側に配置されている。例えば第２システムＳＴ２はパブリッククラウドのクラウドサービスを提供するデータセンターＤＣ内に設置される。第２システムＳＴ２はデータセンターＤＣ内に設置された第２システムＳＴ２以外の様々なシステムとＬＡＮなどの通信回線ＮＷ３によって互いに接続されている。この通信回線ＮＷ３は第２通信ネットワークＮＷ２と接続されている。したがって、第２システムＳＴ２と第１システムＳＴ１は、通信回線ＮＷ３、第２通信ネットワークＮＷ２、及び第１通信ネットワークＮＷ１によって互いに通信することができる。なお、通信回線ＮＷ３、第２通信ネットワークＮＷ２、及び第１通信ネットワークＮＷ１はいずれも有線通信と無線通信の少なくとも一方を含んでいる。
【0012】
第１システムＳＴ１及び第２システムＳＴ２はいずれもコンピュータシステムである。コンテナは第１システムＳＴ１や第２システムＳＴ２で動作するプログラムの一例である。第１システムＳＴ１及び第２システムＳＴ２はいずれも複数のコンテナによって様々なサービス（具体的には通信サービスや情報処理サービスなど）を提供する。ユーザ端末１３０は第１システムＳＴ１にも第２システムＳＴ２にもアクセスすることができる。ユーザ端末１３０を操作するアプリユーザは例えば第１システムＳＴ１が提供するサービスを利用することができる。第１担当者端末１１０及び第２担当者端末１２０はいずれも第１システムＳＴ１及び第２システムＳＴ２にアクセスすることができる。第１担当者端末１１０を操作する分析担当者は例えば第１システムＳＴ１が提供するサービスの負荷を分析することができる。第２担当者端末１２０についても第１担当者端末１１０と同様である。
【0013】
管理サーバ２００は第１システムＳＴ１のコンテナの構成を管理する管理者が操作するサーバ装置である。管理者を管理サーバ２００の利用者と称してもよい。管理サーバ２００は第１システムＳＴ１にアクセスし、第１システムＳＴ１が管理する各種の情報を定期的に収集する。管理サーバ２００は、管理者の操作に基づく特定の依頼を受信すると、収集した情報に基づいて、移行すべきコンテナを管理者が判断できる情報を提供する。例えば、管理サーバ２００は第１システムＳＴ１で動作する複数のコンテナの一部をスケールアウトにより第２システムＳＴ２に移行する際の決定に有益な情報を提供する。詳細は後述するが、この有益な情報としては、例えば第２システムＳＴ２の利用料金や、第２システムＳＴ２に移行するコンテナに割り当てられるリソース量などがある。
【0014】
図２を参照して、第１システムＳＴ１の詳細について説明する。なお、第２システムＳＴ２については第１システムＳＴ１と基本的に同様の構成であるため、第２システムＳＴ２の詳細な説明については省略する。
【0015】
図２に示すように、第１システムＳＴ１は、メモリやＣＰＵ（Central Processing Unit）等のハードウェアリソース１１を有する。そして、ハードウェアリソース１１に含まれるメモリとＣＰＵが協働してＯＳ（Operating System）１２を実行し、更にＯＳ１２の上でハードウェアリソース１１がコンテナエンジン１５を実行する。コンテナエンジン１５は、コンテナ１６を生成するためのDOCKER（登録商標）等のプログラムである。コンテナ１６はポッドに収容される。なお、ポッドはコンテナ１６を管理するための最小単位であり、複数のコンテナ１６の集合体である。ポッドによりコンテナ１６を単独で管理するのではなく、グループとして管理することができる。
【0016】
コンテナ１６の個数は特に限定されないが、この例ではコンテナエンジン１５が全部でｎ個のコンテナ１６を起動するものとし、各々のコンテナを「＃１」、「＃２」、・・・、「＃ｎ」等の文字列で識別する。また、ｎ個のコンテナ１６は、それぞれ１つのアプリ１７を実行する。各アプリ１７は後述するＷｅｂアプリや分析用アプリ等を実現するためのアプリケーションプログラムである。
【0017】
更に、この例では、ＯＳ１２の上でハードウェアリソース１１がコンテナオーケストレーションプログラムを実行する。これにより、ｎ個のコンテナ１６がコンテナオーケストレーションプログラムの配下に置かれ、各コンテナ１６が同一のコンテナ実行環境２０で起動する。なお、コンテナオーケストレーションプログラムとしては、例えばKubernetes（K8s）がある。
【0018】
コンテナ実行環境２０は、コンテナオーケストレーションプログラムの管理下にある環境である。コンテナオーケストレーションプログラムは複数のコンテナ１６の各々に名前を付与するが、一つのコンテナ実行環境２０では名前が衝突することがなく、名前によって一意にコンテナを識別することができる。
【0019】
また、一つのコンテナ実行環境２０は、複数のコンテナ１６によって形成されたクラスタコンピュータと捉えることができる。コンテナオーケストレーションプログラムは、相異なるコンテナ実行環境２０を一意に識別するためのクラスタＩＤを各々のコンテナ実行環境２０に付与する。
【0020】
図３を参照して、管理サーバ２００のハードウェア構成について説明する。図３に示すように、管理サーバ２００は表示方法を実行する制御装置２１０を含んでいる。制御装置２１０は、ＣＰＵ２１０Ａと、ＲＡＭ（Random Access Memory）２１０ＢとＲＯＭ（Read Only Memory）２１０Ｃとを含んでいる。制御装置２１０は、ネットワークＩ／Ｆ（インタフェース）２１０ＤとＨＤＤ（Hard Disk Drive）２１０Ｅを含んでいる。ＨＤＤ（Hard Disk Drive）２１０Ｅに代えて、ＳＳＤ（Solid State Drive）を採用してもよい。
【0021】
制御装置２１０は、必要に応じて、入力Ｉ／Ｆ２１０Ｆ、出力Ｉ／Ｆ２１０Ｇ、入出力Ｉ／Ｆ２１０Ｈ、ドライブ装置２１０Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ２１０Ａからドライブ装置２１０Ｉまでは、内部バス２１０Ｊによって互いに接続されている。すなわち、制御装置２１０はコンピュータによって実現することができる。
【0022】
入力Ｉ／Ｆ２１０Ｆには入力装置７１０が接続される。入力装置７１０としては例えばキーボードやマウス、タッチパネルなどがある。入力装置７１０を管理サーバ２００に含めてもよい。出力Ｉ／Ｆ２１０Ｇには表示装置７２０が接続される。表示装置７２０としては例えば液晶ディスプレイなどがある。表示装置７２０を管理サーバ２００に含めてもよい。入出力Ｉ／Ｆ２１０Ｈには半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばＵＳＢ（Universal Serial Bus）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ２１０Ｈは半導体メモリ７３０に記憶された表示プログラムを読み取る。入力Ｉ／Ｆ２１０Ｆ及び入出力Ｉ／Ｆ２１０Ｈは例えばＵＳＢポートを備えている。出力Ｉ／Ｆ２１０Ｇは例えばディスプレイポートを備えている。
【0023】
ドライブ装置２１０Ｉには可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばＣＤ（Compact Disc）－ＲＯＭ、ＤＶＤ（Digital Versatile Disc）といったリムーバブルディスクがある。ドライブ装置２１０Ｉは可搬型記録媒体７４０に記録された表示プログラムを読み込む。ネットワークＩ／Ｆ２１０Ｄは例えばＬＡＮポートや通信回路などを備えている。
【0024】
ＲＡＭ２１０ＢにはＲＯＭ２１０Ｃ、ＨＤＤ２１０Ｅ、半導体メモリ７３０の少なくとも１つに記憶された表示プログラムがＣＰＵ２１０Ａによって一時的に格納される。ＲＡＭ２１０Ｂには可搬型記録媒体７４０に記録された表示プログラムがＣＰＵ２１０Ａによって一時的に格納される。格納された表示プログラムをＣＰＵ２１０Ａが実行することにより、ＣＰＵ２１０Ａは後述する各種の機能を実現し、また、後述する各種の処理を実行する。なお、表示プログラムは後述するフローチャートに応じたものとすればよい。
【0025】
【0026】
図４（ａ）に示すように、制御装置２１０は記憶部２１１、処理部２１２、入力部２１３、出力部２１４、及び通信部２１５を備えている。記憶部２１１は上述したＲＡＭ２１０ＢやＨＤＤ２１０Ｅなどによって実現することができる。処理部２１２は上述したＣＰＵ２１０Ａによって実現することができる。入力部２１３は上述した入力Ｉ／Ｆ２１０Ｆによって実現することができる。出力部２１４は上述した出力Ｉ／Ｆ２１０Ｇによって実現することができる。通信部２１５は上述したネットワークＩ／Ｆ２１０Ｄによって実現することができる。したがって、記憶部２１１、処理部２１２、入力部２１３、出力部２１４、及び通信部２１５は互いに接続されている。
【0027】
記憶部２１１はトレーシングＤＢ（Database）２２１、通信量ＤＢ２２２、及びコンテナ構成ＤＢ２２３を含んでいる。処理部２１２は第１収集部２３１、第２収集部２３２、第３収集部２３３、及び配備部２３４を含んでいる。第１収集部２３１は第１システムＳＴ１が管理するトレーシング情報を収集する。第１収集部２３１は収集したトレーシング情報をトレーシングＤＢ２２１に登録する。これにより、トレーシングＤＢ２２１はトレーシング情報を記憶する。第２収集部２３２は第１システムＳＴ１が管理する性能情報（メトリクス情報）を収集する。第２収集部２３２は収集した性能情報を通信量情報として通信量ＤＢ２２２に登録する。これにより、通信量ＤＢ２２２は通信量情報を記憶する。第３収集部２３３は第１システムＳＴ１が管理するコンテナ構成情報を収集する。第３収集部２３３は収集したコンテナ構成情報をコンテナ構成ＤＢ２２３に登録する。これにより、コンテナ構成ＤＢ２２３はコンテナ構成情報を記憶する。なお、トレーシング情報、通信量情報、及びコンテナ構成情報の詳細については後述する。
【0028】
配備部２３４は、図４（ｂ）に示すように、第１特定部２４１、第２特定部２４２、及び決定部２４３を含んでいる。また、配備部２３４は、第１算出部２４４、第２算出部２４５、表示部２４６、及び選択部２４７を含んでいる。第１特定部２４１、・・・、選択部２４７はトレーシングＤＢ２２１、通信量ＤＢ２２２、及びコンテナ構成ＤＢ２２３に選択的にアクセスして、各種の処理を実行する。例えば、第１特定部２４１はコンテナ構成ＤＢ２２３にアクセスしてコンテナ構成情報を取得する。そして、第１特定部２４１は、取得したコンテナ構成情報に基づいて、第１システムＳＴ１で動作している複数のコンテナの各々に割り当てられた第１リソース量を特定する。その他の構成要素の詳細については後述する。
【0029】
次に、制御装置２１０の動作について説明する。
【0030】
まず、第１収集部２３１の動作について説明する。図５（ａ）及び図６に示すように、第１収集部２３１は第１システムＳＴ１や第２システムＳＴ２のコンテナ実行環境２０が管理するトレーシング情報を収集する（ステップＳ１）。例えば図７に示すように、第１実施形態に係る第１システムＳＴ１は、分析用アプリ、Ｗｅｂアプリ、及びデータ加工といった複数のコンテナ１６を有する。この場合、コンテナ実行環境２０はこれら複数のコンテナ１６の間で行われるメッセージ（通信メッセージ）の流れ（処理フロー）をメッセージＩＤ毎にトレーシング情報として管理する。各コンテナ１６には分散トレーシングプログラム１６ａが実装されている。分散トレーシングプログラム１６ａがメッセージＩＤを付与して、各コンテナ１６の間で行われるメッセージの流れや流量、アクセス頻度等の情報を管理する。コンテナ実行環境２０は分散トレーシングプログラム１６ａが管理するこれらの情報を取得してトレーシング情報として管理する。第１収集部２３１は第１システムＳＴ１のコンテナ実行環境２０にアクセスして、コンテナ実行環境２０からトレーシング情報を収集する。
【0031】
第１収集部２３１はトレーシング情報を収集すると、トレーシング情報をトレーシングＤＢ２２１に登録する（ステップＳ２）。これにより、例えば図８（ａ）に示すように、トレーシングＤＢ２２１はメッセージＩＤと処理フローとを含むトレーシング情報を記憶する。処理フローにより、複数のコンテナ１６の間で行われるメッセージの方向などを特定することができる。
【0032】
次に、第２収集部２３２の動作について説明する。図５（ｂ）及び図６に示すように、第２収集部２３２は第１システムＳＴ１や第２システムＳＴ２のコンテナ実行環境２０が管理する性能情報を収集する（ステップＳ３）。上述したように、分散トレーシングプログラム１６ａはメッセージの流量や各コンテナ１６に対するアクセス頻度等の情報を管理している。コンテナ実行環境２０は当該情報を取得し、性能情報として管理する。第２収集部２３２は第１システムＳＴ１のコンテナ実行環境２０にアクセスして、コンテナ実行環境２０から性能情報を収集する。
【0033】
第２収集部２３２は性能情報を収集すると、性能情報を通信量ＤＢ２２２に登録する（ステップＳ４）。これにより、例えば図８（ｂ）に示すように、通信量ＤＢ２２２は送信元のコンテナと宛先のコンテナとＡＰＩ（Application Programming Interface）の組合せにより一意に識別できる通信料情報を記憶する。通信料情報により、上記組合せにおけるメッセージの流量やアクセス頻度を特定することができる。なお、ＡＰＩはＵＲＩ（Uniform Resource Identifier）によって定義することができる。
【0034】
次に、第３収集部２３３の動作について説明する。図５（ｃ）及び図６に示すように、第３収集部２３３は第１システムＳＴ１や第２システムＳＴ２のコンテナ実行環境２０が管理するコンテナ構成情報を収集する（ステップＳ５）。分散トレーシングプログラム１６ａは各コンテナ１６に割り当てられたＣＰＵの数量やメモリ量などの第１リソース量も管理することができる。コンテナ実行環境２０は第１リソース量を取得し、コンテナ構成情報として管理する。第３収集部２３３は第１システムＳＴ１のコンテナ実行環境２０にアクセスして、コンテナ実行環境２０からコンテナ構成情報を収集する。
【0035】
第３収集部２３３はコンテナ構成情報を収集すると、コンテナ構成情報をコンテナ構成ＤＢ２２３に登録する（ステップＳ６）。これにより、例えば図８（ｃ）に示すように、コンテナ構成ＤＢ２２３はコンテナ名とＣＰＵの数量とメモリ量とを含むコンテナ構成情報を記憶する。コンテナ構成情報により、複数のコンテナ１６のそれぞれに割り当てられた第１リソース量を特定することができる。
【0036】
次に、配備部２３４の動作について説明する。図９に示すように、まず、第１特定部２４１がリソース増強依頼を受信する（ステップＳ１１）。例えば、Ｗｅｂアプリ（図７参照）を利用するアプリユーザが増加し、Ｗｅｂアプリの処理でリソース不足に起因した第１システムＳＴ１の性能低下が発生することがある。このような場合、管理サーバ２００を操作する管理者が入力装置７１０にリソース増強依頼を入力する。入力装置７１０は入力されたリソース増強依頼を第１特定部２４１に向けて送信する。これにより、第１特定部２４１はリソース増強依頼を受信する。
【0037】
リソース増強依頼を受信すると、第１特定部２４１はトレーシングＤＢ２２１を参照して、全トレーシング情報を探索済であるか否かを判断する（ステップＳ１２）。トレーシングＤＢ２２１は、図８（ａ）に示すように、メッセージＩＤによって識別される複数のトレーシング情報を記憶するため、第１特定部２４１は複数のトレーシング情報の全てを探索し終えたか否かを判断する。全トレーシング情報を探索済でない場合（ステップＳ１２：ＮＯ）、第１特定部２４１は、未探索のトレーシング情報の１つを処理対象として指定する。そして、第１特定部２４１は、コンテナ１６を纏めるための空のグループを、識別番号を付して生成する（ステップＳ１３）。グループを生成すると、第１特定部２４１は処理対象として指定したトレーシング情報の処理フローを参照して、処理フローに含まれる全コンテナの抽出が完了したか否かを判断する（ステップＳ１４）。
【0038】
全コンテナの抽出が完了していない場合（ステップＳ１４：ＮＯ）、第１特定部２４１はコンテナ１６を抽出し（ステップＳ１５）、グループに登録済であるか否かを判断する（ステップＳ１６）。特に、第１特定部２４１はコンテナ１６を抽出する際に通信量ＤＢ２２２を参照する。そして、第１特定部２４１はトレーシング情報の処理フローに応じた通信量情報のアクセス頻度が頻繁を表す所定値以上である場合に、コンテナ１６を抽出する。例えば図８（ａ）に示すように、メッセージＩＤ「０」のトレーシング情報が処理対象として指定されたと仮定する。この場合、図８（ｂ）に示すように、このトレーシング情報の処理フローに応じた通信量情報のアクセス頻度は１００リクエスト／３０分である。本実施形態において、このアクセス頻度は頻繁を表す所定値以上に相当する。このため、第１特定部２４１は分析用アプリをコンテナ１６として抽出し、グループに登録済であるか否かを判断する。なお、ステップＳ１５の処理において、第１特定部２４１はアクセス頻度が所定値未満であればコンテナ１６の抽出を中止する。このように、アクセス頻度が所定値未満のコンテナ１６は通信遅延の影響が少ないと想定されるため、後述するグループの登録対象から除外する。
【0039】
グループに登録済でない場合（ステップＳ１６：ＮＯ）、第１特定部２４１は当該コンテナ１６をグループに登録する（ステップＳ１７）。これにより、図７に示すように、分析用アプリのコンテナ１６がグループ「１」に登録される。
【0040】
コンテナ１６をグループに登録すると、第１特定部２４１は他のメッセージＩＤに当該コンテナ１６があるか否かを判断する（ステップＳ１８）。他のメッセージＩＤに当該コンテナ１６がある場合（ステップＳ１８：ＹＥＳ）、第１特定部２４１は他のメッセージＩＤに含まれる別のコンテナ１６を抽出する（ステップＳ１９）。特に、第１特定部２４１は別のコンテナ１６を抽出する際にも通信量ＤＢ２２２を参照し、トレーシング情報の処理フローに応じた通信量情報のアクセス頻度が頻繁を表す所定値以上である場合に、別のコンテナ１６を抽出する。
【0041】
例えば図８（ａ）に示すように、分析用アプリはメッセージＩＤ「０」の他にメッセージＩＤ「１」にもある。メッセージＩＤ「１」にはデータ加工を表す別のコンテナ１６が含まれている。しかしながら、図８（ｂ）に示すように、メッセージＩＤ「１」のトレーシング情報の処理フローに応じた通信量情報のアクセス頻度は１リクエスト／１日である。本実施形態において、このアクセス頻度は上記所定値未満に相当する。このため、第１特定部２４１は別のコンテナ１６の抽出を中止する。すなわち、別のコンテナ１６の抽出対象から除外される。このように、アクセス頻度が所定値未満である場合には、別のコンテナ１６の抽出が中止されるため、ステップＳ１４の処理に戻る。グループに登録済である場合（ステップＳ１６：ＹＥＳ）や、他のメッセージＩＤに当該コンテナ１６がない場合（ステップＳ１８：ＮＯ）も同様にステップＳ１４の処理に戻る。
【0042】
ステップＳ１４の処理において、メッセージＩＤ「０」のトレーシング情報における処理フローには、分析用アプリを表す１つのコンテナ１６がある。このため、第１特定部２４１は全コンテナの抽出が完了したと判断し（ステップＳ１４：ＹＥＳ）、ステップＳ１２の処理に戻る。ステップＳ１２の処理では、メッセージＩＤ「１」のトレーシング情報などがまだ処理対象として指定されていない。このため、第１特定部２４１は全トレーシング情報を探索済でないと判断し、ステップＳ１３～Ｓ１９までの処理を繰り返す。これにより、図７に示すように、グループ「２」も生成される。
【0043】
ステップＳ１２の処理において、全トレーシング情報が探索済である場合（ステップＳ１２：ＹＥＳ）、第１特定部２４１は後続の処理に対し全グループの探索が済んだか否かを判断する（ステップＳ２０）。全グループの探索が済んでいない場合（ステップＳ２０：ＮＯ）、第１特定部２４１は未探索のグループの１つを処理対象として指定した後、処理対象のグループに属するコンテナ１６の第１リソース量を特定する（ステップＳ２１）。図７に示すように、グループ「１」を処理対象として指定した場合、第１特定部２４１は分析用アプリのコンテナ１６の第１リソース量を特定する。図８（ｃ）に示すように、コンテナ構成ＤＢ２２３はコンテナ構成情報を記憶する。このため、第１特定部２４１は分析用アプリのコンテナ１６に割り当てられたＣＰＵの数量「８」及びメモリ量「２４ＧＢ」を第１リソース量として特定することができる。
【0044】
第１リソース量を特定すると、次いで、決定部２４３は第２リソース量の候補を決定する（ステップＳ２２）。より詳しくは、決定部２４３は、第１リソース量に基づいて、第２システムＳＴ２に移行した後のコンテナ１６に割り当てる第２リソース量の複数の候補を決定する。例えば図１１（ａ）に示すように、分析用アプリのコンテナ１６にはＣＰＵの数量「８」及びメモリ量「２４ＧＢ」の第１リソース量が割り当てられている。決定部２４３は予め定めた均等分割条件に基づいて第１リソース量を分割した第２リソース量の候補を決定する。本実施形態では、均等分割条件が２分割である。このため、図１１（ａ）に示すように、決定部２４３はＣＰＵの数量「４」及びメモリ量「１２ＧＢ」の第２リソース量の第１候補を決定する。また、決定部２４３はＣＰＵの数量「４」及びメモリ量「１２ＧＢ」の第２リソース量の第２候補を決定する。グループ「１」については、このように、第２システムＳＴ２に移行した後のコンテナ１６に割り当てる第２リソース量の複数の候補が決定される。第１候補はサブグループ「１－１」に属し、第２候補はサブグループ「１－２」に属する。なお、均等分割条件は３分割以上であってもよい。ステップＳ２２の処理が終了すると、ステップＳ２０の処理に戻る。
【0045】
グループ「２」が処理対象として指定されていないため、グループ「２」が処理対象として指定されて同様の処理が実行される。これにより、図１１（ｂ）に示すように、決定部２４３はＣＰＵの数量「２」及びメモリ量「６ＧＢ」の第２リソース量の第３候補を決定する。また、決定部２４３はＣＰＵの数量「２」及びメモリ量「６ＧＢ」の第２リソース量の第４候補を決定する。グループ「２」については、このように、第２システムＳＴ２に移行した後のコンテナ１６に割り当てる第２リソース量の複数の候補が決定される。第３候補はサブグループ「２－１」に属し、第４候補はサブグループ「２－２」に属する。これにより、全グループの探索が済む（ステップＳ２０：ＹＥＳ）。その後、図１０に示すように、決定部２４３は後続の処理に対し全サブグループの探索が済んだか否かを判断する（ステップＳ２３）。全サブグループの探索が済んでいない場合（ステップＳ２３：ＮＯ）、決定部２４３は未探索のサブグループの１つを処理対象として指定する。そして、決定部２４３は処理対象のサブグループに属する全コンテナ１６の総リソース量を算出する（ステップＳ２４）。
【0046】
例えばサブグループ「１－１」を処理対象として指定したと仮定する。この場合、図１１（ａ）及び（ｂ）に示すように、サブグループ「１－１」に属するコンテナ１６は１つである。このため、サブグループ「１－１」であれば、総リソース量は、図１２の上段に示すように、ＣＰＵの数量「４」及びメモリ量「１２ＧＢ」となる。
【0047】
総リソース量を算出すると、決定部２４３は総リソース量が補強対象のコンテナ１６のリソース量以上か否かを判断する（ステップＳ２５）。決定部２４３はステップ２５の処理をスキップしてもよい。本実施形態では、上述したように、Ｗｅｂアプリを利用するアプリユーザが増加し、Ｗｅｂアプリの処理でリソース不足に起因した第１システムＳＴ１の性能低下が発生している。このため、図１２の右隅に示すように、Ｗｅｂアプリが補強対象のコンテナ１６に該当する。補強対象のコンテナ１６のリソース量は予め定められた閾値以上である。ステップＳ２５の処理では、決定部２４３は総リソース量におけるＣＰＵの数量のメモリ量の両方がいずれも補強対象のコンテナ１６のリソース量におけるＣＰＵの数量とメモリ量以上か否かを判断する。図１２に示すように、サブグループ「１－１」の総リソース量と補強対象のコンテナ１６のリソース量を比較すると、総リソース量と補強対象のコンテナ１６のリソース量は同じである。このため、決定部２４３は総リソース量が補強対象のコンテナ１６のリソース量以上であると判断する（ステップＳ２５：ＹＥＳ）。
【0048】
この場合、決定部２４３はリソースタイプを決定し（ステップＳ２６）、第１算出部２４４は決定したリソースタイプに基づいて第２システムＳＴ２の利用料金を算出する（ステップＳ２７）。利用料金は第２システムＳＴ２のハードウェアリソースを利用するリソースコストに相当する。例えば図１３（ａ）に示すように、決定部２４３は管理サーバ２００の内部又は外部で管理された第１課金情報を参照し、総リソース量に該当するリソースタイプを決定する。サブグループ「１－１」であれば、総リソース量がＣＰＵの数量「４」及びメモリ量「１２ＧＢ」であるため、リソースタイプ「中」を決定する。リソースタイプを決定すると、第１算出部２４４は決定したリソースタイプに基づいて利用料金の月額を算出する。サブグループ「１－１」であれば、図１４の下段に示すように、リソースタイプ「中」に対応するリソース料金単価「＄０．２４８／時間」に１日の時間数と１か月の日数を掛け合わせることで利用料金の月額を算出することができる。
【0049】
利用料金を算出すると、第２算出部２４５は通信料を算出する（ステップＳ２８）。ステップＳ２８の処理をスキップしてもよい。通信料は第２システムＳＴ２から第１システムＳＴ１に向かう通信の通信コストに相当する。第１システムＳＴ１から第２システムＳＴ２に向かう通信は無課金になることが多い。一方で、第２システムＳＴ２から第１システムＳＴ１に向かう通信には課金が発生することが多い。このため、第２システムＳＴ２から第１システムＳＴ１に向かう通信を通信料の算出対象とすることで通信料を精度良く算出することができる。
【0050】
例えば図１３（ｂ）に示すように、第２算出部２４５は管理サーバ２００の内部又は外部で管理された第２課金情報を参照し、通信量に該当する通信単価を決定する。図１４の上段に示すように、サブグループ「１－１」に属するコンテナ１６が通信量「７ＧＢ」であれば、通信量「７ＧＢ」に対応する通信単価「＄０．１１４／ＧＢ」を決定する。そして、第２算出部２４５は、図１４の下段に示すように、通信単価「＄０．１１４／ＧＢ」に通信量「７ＧＢ」から通信量「１ＧＢ」の無料分を差し引いた通信量「６ＧＢ」を掛け合わせることで通信料の月額を算出することができる。
【0051】
通信料を算出すると、第１算出部２４４は総利用料金を算出する（ステップＳ２９）。具体的には、図１４の下段に示すように、通信料を利用料金に加算することにより、総利用料金を算出する。これにより、サブグループ「１－１」に属するコンテナ１６を第２システムＳＴ２に移行した場合の総利用料金が特定される。ステップＳ２９の処理が終了すると、ステップＳ２３の処理に戻る。総リソース量が補強対象のコンテナ１６のリソース量未満である場合（ステップＳ２５：ＮＯ）、同様に、ステップＳ２３の処理に戻る。全サブグループの探索が済むまで、ステップＳ２４～Ｓ２９の処理が繰り返される。これにより、サブグループ「１－２」、・・・「２－２」に属するコンテナ１６を第２システムＳＴ２に移行した場合のそれぞれの総利用料金が特定される。なお、ステップＳ２８の処理がスキップされた場合、総利用料金は利用料金と同額になる。
【0052】
全サブグループの探索が済むと（ステップＳ２３：ＹＥＳ）、表示部２４６は総利用料金を表示する（ステップＳ３０）。より詳しくは、表示部２４６はＡＰＩごとのリソース量と総利用料金とを表示装置７２０に表示する。これにより、図１５に示すように、第２システムＳＴ２に移行するコンテナ１６の複数の候補が表示装置７２０に現れる。移行先候補１がサブグループ「１－１」に対応し、移行先候補４がサブグループ「２－２」に対応する。サブグループ「１－２」及び「２－１」に対応する移行先候補２及び移行先候補３は省略されている。ステップＳ２５の処理がスキップされた場合には、４つの移行先候補１～移行先候補４が現れる。一方で、ステップＳ２５の処理が実行された場合には、総リソース量が補強対象のコンテナ１６のリソース量未満である移行先候補３及び移行先候補４（図１２参照）が現れずに、２つの移行先候補１及び移行先候補２が現れる。表示部２４６は総利用料金を表示すると、選択部２４７は移行先候補１～移行先候補４のいずれか（又は移行先候補１及び移行先候補２のいずれか）が選択されるまで待機する（ステップＳ３１：ＮＯ）。
【0053】
管理者が入力装置７１０を操作して、例えば総利用料金が最も低いサブグループ「１－１」に相当する移行先候補１を指定することができる。移行先候補１が指定されると、選択部２４７は移行先候補１を選択し、選択された移行先候補１を第２システムＳＴ２に移行して（ステップＳ３２）、処理を終了する。具体的には、選択部２４７は、図１６（ａ）に示すように、第１システムＳＴ１向けの第１設定ファイルＦ１を生成するとともに、図１６（ｂ）に示すように、第２システム向けの第２設定ファイルＦ２を生成する。そして、選択部２４７は、図１７（ａ）に示すように、第１設定ファイルＦ１を第１システムＳＴ１のコンテナ実行環境２０に通知し、第２設定ファイルＦ２を第２システムＳＴ２のコンテナ実行環境２０に通知する。
【0054】
これにより、図１７（ｂ）に示すように、サブグループ「１－１」に相当する移行先候補１のコンテナ１６が第２システムＳＴ２に移行し、サブグループ「１－２」に相当する移行先候補２のコンテナ１６が第１システムＳＴ１に残存する。このように、Ｗｅｂアプリを表すコンテナ１６を第１システムＳＴ１に追加してもリソース不足が発生せず、第１システムＳＴ１の性能が補強される。また、総利用料金が最も低いサブグループを指定することで、第２システムＳＴ２の総利用料金を低額に抑えることができる。分析担当者の一部は第２システムＳＴ２を利用して各種の分析作業を行う。
【0055】
なお、上述した実施形態では、管理者が総利用料金の最も低いサブグループ「１－１」に相当する移行先候補１を指定したが、選択部２４７が総利用料金の最も低いサブグループ「１－１」に相当する移行先候補１を動的に選択してもよい。この場合、ステップＳ３０，Ｓ３１の処理を省略してもよい。これにより、管理者の操作負担を低減することができる。
【0056】
（第２実施形態）
続いて、図１８から図２７を参照して、本件の第２実施形態について説明する。なお、図１８おいて、第１実施形態に係る図９と同様の処理であるステップＳ２０～Ｓ２２については同一の符号を付して破線で示し、詳細な説明は省略する。
続いて、図１８から図２７を参照して、本件の第２実施形態について説明する。なお、図１８おいて、第１実施形態に係る図９と同様の処理であるステップＳ２０～Ｓ２２については同一の符号を付して破線で示し、詳細な説明は省略する。
【0057】
まず、図１８に示すように、ステップＳ２１の処理において、第１特定部２４１が第１リソース量を特定すると、第１特定部２４１は処理対象のＡＰＩを抽出する（ステップＳ３１）。第２実施形態に係る第１システムＳＴ１は、図１９に示すように、７つのコンテナ１６を備えている。第１実施形態におけるステップＳ１３～Ｓ１９の処理により、７つのコンテナ１６から分析向けＧＵＩ（Graphical User Interface）といった３つのコンテナ１６を含むグループ「１」が生成される。また、ステップＳ１３～Ｓ１９の処理により、Ｗｅｂアプリ（フロント側）といった３つのコンテナ１６を含むグループ「２」も生成される。データ加工のコンテナ１６は、アクセス頻度が低いため、グループの生成対象から除外される。このように、第１実施形態と異なり、グループ「１」及びグループ「２」はいずれも複数のコンテナ１６を含んでいる。
【0058】
グループ「１」を処理対象として指定した場合、第１特定部２４１は分析向けＧＵＩ、分析エンジン、及びアプリログ用ＤＢの各コンテナ１６の第１リソース量を特定する。図２０（ｃ）に示すように、コンテナ構成ＤＢ２２３はコンテナ構成情報を記憶する。このため、第１特定部２４１は分析向けＧＵＩのコンテナ１６に割り当てられたＣＰＵの数量「３」及びメモリ量「９ＧＢ」を第１リソース量として特定することができる。同様に、第１特定部２４１は分析エンジンのコンテナ１６に割り当てられたＣＰＵの数量「９」及びメモリ量「９ＧＢ」を第１リソース量として特定することができる。第１特定部２４１はアプリ用ログＤＢのコンテナ１６に割り当てられたＣＰＵの数量「８」及びメモリ量「１６ＧＢ」を第１リソース量として特定することができる。
【0059】
このように、第１リソース量を特定すると、第１特定部２４１は処理対象のＡＰＩを抽出する。例えばグループ「１」を処理対象として指定したと仮定する。この場合、図１９に示すように、第１特定部２４１はグループ「１」に属する３つのコンテナ１６に対するＡＰＩ「ｂｎｓｋ…／ｆｒ」及びＡＰＩ「ｂｎｓｋ…／ｂｋ」（図２０（ｂ）参照）を抽出する。なお、第１特定部２４１は通信量ＤＢ２２２を参照し、抽出対象から除外されたデータ加工を表すコンテナ１６を含まない通信量情報と分析向けＧＵＩ等のコンテナ１６とを突合することで、ＡＰＩを抽出することができる。
【0060】
処理対象のＡＰＩを抽出すると、第１特定部２４１はＡＰＩが２種類以上か否かを判断する（ステップＳ３２）。本実施形態では、２つのＡＰＩが抽出され、これら２つのＡＰＩは異なるＵＲＩで定義されているため、２種類である。このため、第１特定部２４１はＡＰＩが２種類以上であると判断する（ステップＳ３２：ＹＥＳ）。この場合、第１特定部２４１は処理対象として指定したグループ「１」に属する全コンテナ１６の探索が済んだか否かを判断する（ステップＳ３３）。全コンテナ１６の探索が済んでいない場合（ステップＳ３３：ＮＯ）、第２特定部２４２は、全コンテナ１６の探索が済むまで、ステップＳ３４～Ｓ３６の処理を繰り返す。
【0061】
まず、第２特定部２４２は、通信量ＤＢ２２２を参照して、コンテナ１６にアクセスするときのＡＰＩごとの通信量を特定する（ステップＳ３４）。なお、第２特定部２４２は、通信量ＤＢ２２２が記憶する通信量情報の流量等に登録された流量の数値に基づいて通信量を特定することができる。
【0062】
例えば図２１に示すように、分析向けＧＵＩのコンテナ１６に対するフロントのＡＰＩの単位時間当たりのメッセージの第１流量と第２流量の合計を第２特定部２４２が算出する。この結果、送信側が合計流量「５ＧＢ」であり、受信側が合計流量「１５ＧＢ」であると仮定する。この場合、第２特定部２４２は通信量「２０ＧＢ」を特定する。同様に、バックのＡＰＩの単位時間当たりのメッセージの第１流量と第２流量の合計を第２特定部２４２が算出する。この結果、送信側が合計流量「５ＧＢ」であり、受信側が合計流量「５ＧＢ」であると仮定する。この場合、第２特定部２４２は通信量「２０ＧＢ」を特定する。
【0063】
また、分析エンジンのコンテナ１６に対するフロントのＡＰＩの単位時間当たりのメッセージの第２流量と第３流量の合計を第２特定部２４２が算出する。この結果、送信側が合計流量「１０ＧＢ」であり、受信側が合計流量「６０ＧＢ」であると仮定する。この場合、第２特定部２４２は通信量「７０ＧＢ」を特定する。同様に、バックのＡＰＩの単位時間当たりのメッセージの第２流量と第３流量の合計を第２特定部２４２が算出する。この結果、送信側が合計流量「５ＧＢ」であり、受信側が合計流量「３０ＧＢ」であると仮定する。この場合、第２特定部２４２は通信量「３５ＧＢ」を特定する。
【0064】
通信量を特定すると、第２特定部２４２は、通信量ＤＢ２２２を参照して、データ加工のコンテナ１６が出力するログを格納するデータベースにおけるデータ種別ごとのデータ量を特定する（ステップＳ３５）。なお、第２特定部２４２は、通信量ＤＢ２２２が記憶する通信量情報の流量等に登録されたデータ量の数値に基づいてデータ量を特定することができる。
【0065】
例えば図２１に示すように、アプリログ用ＤＢにおけるフロントに関するログのデータ量がデータ量「３００ＧＢ」であれば、第２特定部２４２はフロントのデータ量「３００ＧＢ」を特定する。アプリログ用ＤＢにおけるバックに関するログのデータ量がデータ量「１００ＧＢ」であれば、第２特定部２４２はバックのデータ量「１００ＧＢ」を特定する。なお、これらのログはデータ加工のコンテナ１６で加工されたものである。データ加工のコンテナ１６はＷｅｂアプリ（フロント側）のコンテナ１６及びＷｅｂアプリ（バック側）のコンテナ１６から出力されてストレージのコンテナ１６に蓄積されたログを加工する。
【0066】
データ量を特定すると、第２特定部２４２は通信量の比率及びデータ量の比率を算出する（ステップＳ３６）。図２１に示すように、分析向けＧＵＩのコンテナ１６であれば、フロント側が通信量「２０ＧＢ」であり、バック側が通信量「１０ＧＢ」である。このため、第２特定部２４２は通信量の比率「２：１」を算出する。分析エンジンのコンテナ１６であれば、フロント側が通信量「７０ＧＢ」であり、バック側が通信量「３５ＧＢ」である。このため、第２特定部２４２は通信量の比率「２：１」を算出する。アプリログ用ＤＢのコンテナ１６であれば、フロント側がデータ量「３００ＧＢ」であり、バック側がデータ量「１００ＧＢ」である。このため、第２特定部２４２はデータ量の比率「３：１」を算出する。
【0067】
全コンテナ１６の探索が済むと（ステップＳ３３：ＹＥＳ）、決定部２４３がステップＳ２２の処理を実行する。この場合、決定部２４３は第２リソース量の複数の候補の各々の第２リソース量同士の比率が、複数の通信量同士の比率となるように候補を決定する。例えば図２１に示すように、分析向けＧＵＩのコンテナ１６であれば、通信量の比率「２：１」が算出されている。このため、決定部２４３は当該コンテナ１６が使用するＣＰＵの数量「３」及びメモリ量「９ＧＢ」の第１リソース量を比率「２：１」で分割した第２リソース量の候補を決定する。これにより、決定部２４３はＣＰＵの数量「２」及びメモリ量「６ＧＢ」の第２リソース量の第１候補を決定する。また、決定部２４３はＣＰＵの数量「１」及びメモリ量「３ＧＢ」の第２リソース量の第２候補を決定する。なお、分析エンジンのコンテナ１６については、分析向けＧＵＩのコンテナ１６と同様であるため、説明を省略する。
【0068】
一方、アプリログ用ＤＢのコンテナ１６であれば、データ量の比率「３：１」が算出されている。このため、決定部２４３は第２リソース量の複数の候補の各々の第２リソース量同士の比率が、複数のデータ量同士の比率となるように候補を決定する。したがって、決定部２４３はアプリログ用ＤＢのコンテナ１６が使用するＣＰＵの数量「８」及びメモリ量「１６ＧＢ」の第１リソース量を比率「３：１」で分割した第２リソース量の候補を決定する。これにより、決定部２４３はＣＰＵの数量「６」及びメモリ量「１２ＧＢ」の第２リソース量の第１候補を決定する。また、決定部２４３はＣＰＵの数量「２」及びメモリ量「４ＧＢ」の第２リソース量の第２候補を決定する。グループ「１」については、以上のように、第２システムＳＴ２に移行した後のコンテナ１６に割り当てる第２リソース量の複数の候補が決定される。以上３つの第１候補はサブグループ「１－１」に属し、３つの第２候補はサブグループ「１－２」に属する。
【0069】
ステップＳ２２の処理が終了すると、ステップＳ２０の処理に戻る。これにより、グループ「２」が処理対象として指定されて、同様の処理が繰り返される。ここで、グループ「２」が処理対象として指定されて、ステップＳ３２の処理において、ＡＰＩが２種類以上か否かを第１特定部２４１が判断する際、図２２に示すように、本実施形態では、２つのＡＰＩが抽出される。しかしながら、これら２つのＡＰＩは同じＵＲＩで定義されているため、１種類である。このため、第１特定部２４１はＡＰＩが２種類以上でないと判断する（ステップＳ３２：ＮＯ）。この場合、決定部２４３はステップＳ２２の処理を実行する。特に、ＡＰＩが１種類である場合、第１実施形態と同様に、決定部２４３は予め定めた均等分割条件に基づいて第１リソース量を分割した第２リソース量の候補を決定する。
【0070】
本実施形態では、均等分割条件が２分割である。このため、Ｗｅｂアプリ（フロント側）のコンテナ１６であれば、図２２に示すように、決定部２４３はＣＰＵの数量「６」及びメモリ量「８ＧＢ」の第２リソース量の第１候補を決定する。また、決定部２４３はＣＰＵの数量「６」及びメモリ量「８ＧＢ」の第２リソース量の第２候補を決定する。Ｗｅｂアプリ（バック側）のコンテナ１６については、Ｗｅｂアプリ（フロント側）のコンテナ１６と同様であるため、説明を省略する。一方、ストレージのコンテナ１６であれば、決定部２４３はＣＰＵの数量「２」及びメモリ量「８ＧＢ」の第２リソース量の第１候補を決定する。また、決定部２４３はＣＰＵの数量「２」及びメモリ量「８ＧＢ」の第２リソース量の第２候補を決定する。グループ「２」については、以上のように、第２システムＳＴ２に移行した後のコンテナ１６に割り当てる第２リソース量の複数の候補が決定される。以上の第１候補はサブグループ「２－１」に属し、第２候補はサブグループ「２－２」に属する。グループ「２」に関する処理が終了すると、ステップＳ２０の処理に戻る。本実施形態では、２つのグループ「１」及び「２」の全ての探索が済んだため、第１実施形態で説明したステップＳ２３以後の処理が進行する。
【0071】
ここで、例えばＷｅｂアプリ（フロント側）を利用するアプリユーザが増加し、Ｗｅｂアプリ（バック側）の処理でリソース不足に起因した第１システムＳＴ１の性能低下が発生すると仮定する。この場合、図２３の右隅に示すように、Ｗｅｂアプリ（バック側）が補強対象のコンテナ１６に該当する。このため、ステップＳ２５の処理において、決定部２４３は総リソース量がいずれも補強対象のコンテナ１６のリソース量以上か否かを判断する。より詳しくは、決定部２４３は総リソース量におけるＣＰＵの数量のメモリ量の両方が補強対象のコンテナ１６のリソース量におけるＣＰＵの数量とメモリ量以上か否かを判断する。図２３に示すように、サブグループ「１－１」の総リソース量と補強対象のコンテナ１６のリソース量を比較すると、これらの総リソース量は補強対象のコンテナ１６のリソース量以上である。サブグループ「２－１」及び「２－２」についてもサブグループ「１－１」と同様である。一方、サブグループ「１－２」の総リソース量と補強対象のコンテナ１６のリソース量を比較すると、この総リソース量は補強対象のコンテナ１６のリソース量未満である。このため、サブグループ「１－２」に属する複数のコンテナ１６は第２システムＳＴ２への移行対象として望ましくないため、この時点で移行対象から除外してもよい。
【0072】
その後、ステップＳ２６～Ｓ２８の処理において、決定部２４３がリソースタイプを決定し、第１算出部２４４が決定したリソースタイプに基づいて第２システムＳＴ２の利用料金を算出し、第２算出部２４５が通信料を算出する。サブグループ「１－１」であれば、決定部２４３は第１課金情報で定義されたリソースタイプ「特大」（図１３（ａ）参照）を決定する。そして、図２４の下段に示すように、第１算出部２４４はリソースタイプ「特大」に対応するリソース料金単価「＄０．９９２／時間」を特定する。第１算出部２４４は特定したリソース料金単価「＄０．９９２／時間」に１日の時間数と１か月の日数を掛け合わせることで利用料金の月額を算出することができる。また、サブグループ「１－１」に属するコンテナ１６が通信量「７ＧＢ」であれば、第２算出部２４５はこの通信量に対応する通信単価を特定する。具体的には、第２算出部２４５は第２課金情報で定義された通信量「７ＧＢ」に対応する通信単価「＄０．１１４／ＧＢ」を特定する（図１３（ｂ）参照）。そして、図２４の下段に示すように、第２算出部２４５は通信単価「＄０．１１４／ＧＢ」に通信量「６ＧＢ」を掛け合わせることで通信料の月額を算出することができる。これにより、ステップＳ２９の処理において、第１算出部２４４が総利用料金を算出する。サブグループ「１－２」、「２－１」及び「２－２」についても同様である。なお、通信量「６ＧＢ」は通信量「７ＧＢ」から通信量「１ＧＢ」の無料分を差し引いた量である。
【0073】
総利用料金が算出されると、ステップＳ３０の処理において、表示部２４６がＡＰＩごとのリソース量と総利用料金とを表示装置７２０に表示する。これにより、図２５に示すように、第２システムＳＴ２に移行するコンテナ１６の複数の候補が表示装置７２０に現れる。移行先候補１がサブグループ「１－１」に対応し、移行先候補４がサブグループ「２－２」に対応する。サブグループ「１－２」及び「２－１」に対応する移行先候補２及び移行先候補３は省略されている。ステップＳ２５の処理がスキップされた場合には、４つの移行先候補１～移行先候補４が現れる。一方で、ステップＳ２５の処理が実行された場合には、総リソース量が補強対象のコンテナ１６のリソース量未満である移行先候補２（図２３参照）が現れずに、３つの移行先候補１、移行先候補３及び移行先候補４が現れる。
【0074】
総利用料金が表示されると、選択部２４７は移行先候補１～移行先候補４のいずれか（又は移行先候補１、移行先候補３及び移行先候補４のいずれか）が選択されるまで待機する。管理者が例えば総利用料金が最も低いサブグループ「１－１」に相当する移行先候補１を指定すると、選択部２４７は移行先候補１を選択し、選択された移行先候補１を第２システムＳＴ２に移行して、処理を終了する。
【0075】
具体的には、選択部２４７は、図２６に示すように、第１システムＳＴ１向けの第１設定ファイルＦ１を生成するとともに、図２７に示すように、第２システム向けの第２設定ファイルＦ２を生成する。そして、選択部２４７は、第１設定ファイルＦ１を第１システムＳＴ１のコンテナ実行環境２０に通知し、第２設定ファイルＦ２を第２システムＳＴ２のコンテナ実行環境２０に通知する。これにより、図示しないが、サブグループ「１－１」に相当する移行先候補１のコンテナ１６が第２システムＳＴ２に移行し、サブグループ「１－２」に相当する移行先候補２のコンテナ１６が第１システムＳＴ１に残存する。
【0076】
このように、Ｗｅｂアプリ（バック側）を表すコンテナ１６を第１システムＳＴ１に追加してもリソース不足が発生せず、第１システムＳＴ１の性能が補強される。また、総利用料金が最も低いサブグループを指定することで、第２システムＳＴ２の総利用料金を低額に抑えることができる。分析担当者の一部は第２システムＳＴ２を利用して各種の分析作業を行う。
【0077】
なお、第１実施形態と同様に、選択部２４７が総利用料金の最も低いサブグループ「１－１」に相当する移行先候補１を動的に選択してもよい。この場合、ステップＳ３０，Ｓ３１の処理を省略してもよい。これにより、管理者の操作負担を低減することができる。
【0078】
以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、上述した実施形態では、コンテナ１６をプログラムの一例として説明したが、仮想マシンをプログラムとしてもよい。
【0079】
また、上述した実施形態ではオンプレミス側の第１システムＳＴ１からパブリッククラウド側の第２システムＳＴ２への移行を一例として説明したが、例えばプライベートクラウド側の第３システム（不図示）からパブリッククラウド側の第２システムＳＴ２への移行であってもよい。
【符号の説明】
【0080】
２００ 管理サーバ
２１０ 制御装置
２１２ 処理部
２３４ 配備部
２４１ 第１特定部
２４３ 決定部
２４４ 第１算出部
２４６ 表示部
ＳＴ１ 第１システム
ＳＴ２ 第２システム
２１０ 制御装置
２１２ 処理部
２３４ 配備部
２４１ 第１特定部
２４３ 決定部
２４４ 第１算出部
２４６ 表示部
ＳＴ１ 第１システム
ＳＴ２ 第２システム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】