(57)【要約】【課題】仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする。【解決手段】仮想化環境管理システム１０において、コンテナ型仮想化環境においてコンテナにより仮想化された各システムの稼働状況を監視する稼働分析サーバ２００と、稼働分析サーバ２００により特定した当該稼働状況と予め特定されている単位コンテナ当たりの処理性能とに基づき、当該システムに必要なコンテナ数を特定し、当該特定したコンテナ数と当該システム向けの現コンテナ数との過不足に応じて、当該コンテナ型仮想化環境を成すハードウェアでの当該システム向けのコンテナ数を増減させるコンテナ管理サーバ１００を含む構成とする。【選択図】図１
2017138895.tif 000002
【特許請求の範囲】
【請求項１】
コンテナ型仮想化環境においてコンテナにより仮想化された各システムの稼働状況を監視し、当該稼働状況と予め特定されている単位コンテナ当たりの処理性能とに基づき、当該システムに必要なコンテナ数を特定し、当該特定したコンテナ数と当該システム向けの現コンテナ数との過不足に応じて、当該コンテナ型仮想化環境を成すハードウェアでの当該システム向けのコンテナ数を増減させる演算装置を備える仮想化環境管理システム。
【請求項２】
前記演算装置は、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より少ない場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて低減するものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項３】
前記演算装置は、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より多い場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて増加させるものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項４】
前記演算装置は、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数との差異の値を、前記ハードウェアの数から当該システムの可用性基準に応じた障害発生ハードウェア数を減算した値で除算し、当該除算により得た値だけ、前記ハードウェアでの当該システム向けのコンテナ数を増減させるものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項５】
前記演算装置は、
各ハードウェアのうち少なくともいずれか複数のハードウェアに配置したコンテナ数が所定基準より少ない場合、当該複数のハードウェアのうち所定のハードウェアに他のハードウェアのコンテナを移動させる処理を更に実行するものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項６】
前記演算装置は、
前記過不足に応じて、前記ハードウェアでの当該システム向けのコンテナ数を増加させる必要があり、前記ハードウェアに配置しきれない未配置コンテナが生じる場合、所定の外部サーバに構築したコンテナ型仮想化環境に、前記未配置コンテナを配置する処理を更に実行するものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項７】
前記演算装置は、
前記未配置コンテナを前記外部サーバのコンテナ型仮想化環境に配置するに際し、予め定めたシステムごとの外部サーバへのコンテナ移行可否の基準に基づき、前記未配置コンテナに対応したシステムの移行要否を判定し、当該未配置コンテナの移行不可であった場合に、前記基準において移行可能な他システムの所定コンテナを前記外部サーバのコンテナ型仮想化環境に移行させ、当該移行させた前記所定コンテナが元々配置されていたハードウェアに、前記未配置コンテナを移行させる処理を更に実行するものである、
ことを特徴とする請求項６に記載の仮想化環境管理システム。
【請求項８】
前記演算装置は、
前記コンテナ数を増減させるに際し、当該システムにおける処理の繁閑時期に関する所定の予測情報に基づき、前記コンテナ数の過不足の状態が所定期間継続することが特定できる場合に、前記コンテナ数の増減を実行するものである、
ことを特徴とする請求項１に記載の仮想化環境管理システム。
【請求項９】
情報処理システムが、
コンテナ型仮想化環境においてコンテナにより仮想化された各システムの稼働状況を監視し、当該稼働状況と予め特定されている単位コンテナ当たりの処理性能とに基づき、当該システムに必要なコンテナ数を特定し、当該特定したコンテナ数と当該システム向けの現コンテナ数との過不足に応じて、当該コンテナ型仮想化環境を成すハードウェアでの当該システム向けのコンテナ数を増減させる、
ことを特徴とする仮想化環境管理方法。
【請求項１０】
前記情報処理システムが、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より少ない場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて低減する、
ことを特徴とする請求項９に記載の仮想化環境管理方法。
【請求項１１】
前記情報処理システムが、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より多い場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて増加させる、
ことを特徴とする請求項９に記載の仮想化環境管理方法。
【請求項１２】
前記情報処理システムが、
前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数との差異の値を、前記ハードウェアの数から当該システムの可用性基準に応じた障害発生ハードウェア数を減算した値で除算し、当該除算により得た値だけ、前記ハードウェアでの当該システム向けのコンテナ数を増減させる、
ことを特徴とする請求項９に記載の仮想化環境管理方法。
【請求項１３】
前記情報処理システムが、
各ハードウェアのうち少なくともいずれか複数のハードウェアに配置したコンテナ数が所定基準より少ない場合、当該複数のハードウェアのうち所定のハードウェアに他のハードウェアのコンテナを移動させる処理を更に実行する、
ことを特徴とする請求項９に記載の仮想化環境管理方法。
【請求項１４】
前記情報処理システムが、
前記過不足に応じて、前記ハードウェアでの当該システム向けのコンテナ数を増加させる必要があり、前記ハードウェアに配置しきれない未配置コンテナが生じる場合、所定の外部サーバに構築したコンテナ型仮想化環境に、前記未配置コンテナを配置する処理を更に実行する、
ことを特徴とする請求項９に記載の仮想化環境管理方法。
【請求項１５】
前記情報処理システムが、
前記未配置コンテナを前記外部サーバのコンテナ型仮想化環境に配置するに際し、予め定めたシステムごとの外部サーバへのコンテナ移行可否の基準に基づき、前記未配置コンテナに対応したシステムの移行要否を判定し、当該未配置コンテナの移行不可であった場合に、前記基準において移行可能な他システムの所定コンテナを前記外部サーバのコンテナ型仮想化環境に移行させ、当該移行させた前記所定コンテナが元々配置されていたハードウェアに、前記未配置コンテナを移行させる処理を更に実行する、
ことを特徴とする請求項１４に記載の仮想化環境管理方法。
【請求項１６】
前記情報処理システムが、
前記コンテナ数を増減させるに際し、当該システムにおける処理の繁閑時期に関する所定の予測情報に基づき、前記コンテナ数の過不足の状態が所定期間継続することが特定できる場合に、前記コンテナ数の増減を実行する、
ことを特徴とする請求項９に記載の仮想化環境管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想化環境管理システムおよび仮想化環境管理方法に関するものであり、具体的には、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする技術に関する。
【背景技術】
【０００２】
コンピュータシステムのリソースを複数ユーザ間で効率的かつ機動的に利用する手段として、仮想化技術が存在する。例えば、ハイパーバイザーによる仮想化技術においては、ハードウェアに搭載されているＣＰＵやメモリの利用タイミング、或いはストレージ容量を、各ユーザ向けに分割して割り当てることで仮想マシンを構成する。
【０００３】
このように、１台のハードウェアのリソースを複数ユーザで分け合う際には、そのリソースの振り分け状況を管理する必要がある。このような管理技術としては、例えば、仮想化環境のための管理システムであって、資格に基づく使用制限を有する少なくとも１つのコンピュータ・エンティティと、プロセッサを使用し、メモリ・ストレージ・デバイス上にプログラミングされ、前記メモリ・ストレージ・デバイスから実行されるリソース・マネージャであって、前記リソース・マネージャが仮想化環境内のリソースを管理するように構成されるリソース・マネージャと、前記リソース・マネージャに結合され、前記仮想化環境の変化に応じて資格関連制約を追跡し、前記リソース・マネージャが前記資格関連制約を含む割り振り決定を行えるようにして、前記少なくとも１つのコンピュータ・エンティティについて前記使用制限を満たしていることを保証するように構成される、資格使用率モジュールとを含むシステム（特許文献１参照）などが提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−２５３５２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところが、金融機関におけるシステムには特有の事情が存在し、従来技術を適用しても効率的なシステム運用が難しい。すなわち、時間帯や季節、休前日といった時期的要因に応じて金融取引の頻度、量が大幅に変化する事情、顧客数や業務数の増加等に応じて時間経過と共に金融取引の頻度、量が徐々に増加する事情、および、金融取引ゆえに高信頼性を常に要求される事情、などが存在する。
【０００６】
こうした各事情に対応しつつ必要な処理性能を維持するためには、例えば取引量のピーク値と高信頼性の条件を併せてクリア出来るだけのコンピュータ資源を用意する必要がある。換言すれば、システム運用開始からしばらくの期間や、特段の取引量増大が生じない通常時に関しては、当該システムにおいて大幅な余剰リソースが生まれることになりうる。
【０００７】
そこで本発明の目的は、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決する本発明の仮想化環境管理システムは、コンテナ型仮想化環境においてコンテナにより仮想化された各システムの稼働状況を監視し、当該稼働状況と予め特定されている単位コンテナ当たりの処理性能とに基づき、当該システムに必要なコンテナ数を特定し、当該特定したコンテナ数と当該システム向けの現コンテナ数との過不足に応じて、当該コンテナ型仮想化環境を成すハードウェアでの当該システム向けのコンテナ数を増減させる演算装置を備えることを特徴とする。
【０００９】
また、本発明の仮想化環境管理方法は、情報処理システムが、コンテナ型仮想化環境においてコンテナにより仮想化された各システムの稼働状況を監視し、当該稼働状況と予め特定されている単位コンテナ当たりの処理性能とに基づき、当該システムに必要なコンテナ数を特定し、当該特定したコンテナ数と当該システム向けの現コンテナ数との過不足に応じて、当該コンテナ型仮想化環境を成すハードウェアでの当該システム向けのコンテナ数を増減させる、ことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする。
【図面の簡単な説明】
【００１１】
【図１】本実施形態の仮想化環境管理システムを含むネットワーク構成図である。
【図２】本実施形態におけるコンテナ管理サーバのハードウェア構成例を示す図である。
【図３】本実施形態における稼働分析サーバのハードウェア構成例を示す図である。
【図４】本実施形態のサーバ情報テーブルのデータ構成例を示す図である。
【図５】本実施形態のシステム情報テーブルのデータ構成例を示す図である。
【図６】本実施形態の可用性マスタテーブルのデータ構成例を示す図である。
【図７】本実施形態のコンテナリストテーブルのデータ構成例を示す図である。
【図８】本実施形態のコンテナ配置状況テーブルのデータ構成例を示す図である。
【図９】本実施形態のコンテナ調整トリガテーブルのデータ構成例を示す図である。
【図１０】本実施形態における仮想化環境管理方法の処理手順例１を示すフロー図である。
【図１１】本実施形態における仮想化環境管理方法の処理手順例２を示すフロー図である。
【発明を実施するための形態】
【００１２】
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の仮想化環境管理システム１０を含むネットワーク構成図である。図１に示す仮想化環境管理システム１０は、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とするコンピュータシステムである。
【００１３】
こうした仮想化環境管理システム１０は、本実施形態においては、ネットワーク５で通信可能に結ばれた、コンテナ管理サーバ１００および稼働分析サーバ２００により構成される。
【００１４】
このうちコンテナ管理サーバ１００は、仮想化環境管理システム１０としての機能を主として実装し、コンテナ管理ソフトウェア１１０を適宜に利用した各種処理を行うサーバ装置である。一方、稼働分析サーバ２００は、仮想化環境を実現しているサーバ群３００をネットワーク５を介して監視し、その稼働状況に関する情報を得て、これをコンテナ管理サーバ１００に通知可能なサーバ装置である。いずれのサーバについても、その具体的な構成等については後述する。
【００１５】
他方、サーバ群３００は、金融機関等における各業務システムを仮想化環境で実現するためのハードウェアとなる。サーバ群３００の最小構成は、当該金融機関向けのデータセンタなどにオンプレミスで構成されたサーバ群３１０となる。このオンプレミスのサーバ群３１０による仮想化環境では、必要な処理性能を発揮するためのコンテナを配置しきれない場合に用いるのが、外部サーバであるパブリッククラウド３２０である。よって、図１の例では、パブリッククラウド３２０をサーバ群３００に含めているが、仮想化環境管理システム１０として利用しない状況もありうる。
【００１６】
ここで、本実施形態の仮想化環境とは、コンテナ型仮想環境である。コンテナ型仮想化環境では、いわゆるハイパーバイザ型の仮想化環境とは異なり、１台のハードウェア上の１つのＯＳに、それぞれが単体のサーバ装置とみなせるコンテナを複数配置して構成した仮想化環境である。本実施形態の場合、各コンテナは各業務システムや業務アプリケーションなどを実現するものとなる。
【００１７】
こうしたコンテナは、既に起動しているＯＳ上のプロセスとして起動されるため、高速起動が可能である。また、各コンテナは、ミドルウェアとアプリケーションおよびそれらが利用するライブラリを一体に備える構成であり、異なるハードウェア（サーバ装置）やクラウド間で移動させることも容易という特徴もある。
【００１８】
なお、サーバ群３００で実現しているコンテナ型仮想化環境は、具体的には、コンテナ管理ソフトウェア１１０で管理されることになる。このコンテナ管理ソフトウェア１１０も含め、コンテナ型仮想環境は、既存技術により構築、運用されるものであり、その詳細は省略する。いずれにしても、仮想化環境管理システム１０におけるコンテナ管理サーバ１００が、このコンテナ管理ソフトウェア１１０に対してコンテナの増減や配置変更等の適宜な指示を行い、当該仮想化環境管理方法を実行する。
【００１９】
−−−ハードウェア構成−−−
また、仮想化環境管理システム１０を構成する情報処理装置のハードウェア構成は以下の如くとなる。図２は、本実施形態におけるコンテナ管理サーバ１００のハードウェア構成例を示す図である。
【００２０】
コンテナ管理サーバ１００は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク５と接続し他装置との通信処理を担う通信装置１０５、を備える。
【００２１】
なお、記憶装置１０１内には、本実施形態の仮想化環境管理システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム１０２と、各種テーブルが少なくとも記憶されている。このうちプログラム１０２には、上述したコンテナ管理ソフトウェア１１０が含まれる。また、テーブルとしては、サーバ情報テーブル１２５、システム情報テーブル１２６、可用性マスタテーブル１２７、コンテナリストテーブル１２８、コンテナ配置状況テーブル１２９、およびコンテナ調整トリガテーブル１３０が含まれる。各テーブルのデータ構造の詳細は後述する。
【００２２】
図３は、本実施形態における稼働分析サーバ２００のハードウェア構成例を示す図である。稼働分析サーバ２００は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ネットワーク５と接続し他装置との通信処理を担う通信装置２０５、を備える。
【００２３】
なお、記憶装置２０１内には、本実施形態の仮想化環境管理システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム２０２と、トリガ情報２２５が少なくとも記憶されている。このうちトリガ情報２２５は、監視対象たるサーバ群３００の各業務システムやそのコンテナの状況に応じて感知した、コンテナ管理サーバ１００に通知すべきイベントの情報である。
【００２４】
例えば、或る業務システムの所定コンテナについて観測したＴＰＳ（Transactions Per Second）が所定基準より大きく変動している、サーバ群３００のうち或るサーバに配置されたコンテナ数が所定基準以下になっている、といった情報になる。こうしたトリガ情報２２５は、稼働分析サーバ２００からコンテナ管理サーバ１００に送信され、後述するコンテナ調整トリガテーブル１３０に格納される。
【００２５】
−−−データ構造例−−−
続いて、本実施形態の仮想化環境管理システム１０が用いるテーブル類について説明する。図４に、本実施形態におけるサーバ情報テーブル１２５の一例を示す。
【００２６】
本実施形態におけるサーバ情報テーブル１２５は、コンテナ型仮想環境を実現するハードウェア、すなわちサーバ群３００が含む各サーバの情報を蓄積したテーブルである。本実施形態の場合、サーバ群３００のうち、オンプレミスのサーバ群３１０が３つの物理サーバを含み、パブリッククラウド３２０が１つの物理サーバを含む状況を想定する。
【００２７】
サーバ情報テーブル１２５のデータ構造は、各サーバを一意に特定するサーバＩＤをキーとして、オンプレミスかパブリッククラウドのいずれのサーバ装置かを示す「区分」、当該サーバの「サーバ名」、「搭載ＣＰＵコア数」、「メモリ容量」、「ステータス」、「稼働中コンテナ数」、「空きＣＰＵコア数」、および「空きメモリ容量」、といったデータから成るレコードの集合体である。このうち、「ステータス」、「稼働中コンテナ数」、「空きＣＰＵコア数」、および「空きメモリ容量」の各値は、稼働分析サーバ２００より送信されてきた値である。
【００２８】
図５に、本実施形態におけるシステム情報テーブル１２６の一例を示す。本実施形態におけるシステム情報テーブル１２６は、コンテナ型仮想環境で実現している各業務システムの情報を蓄積したテーブルである。本実施形態の場合、「Ａシステム」、「Ｂシステム」の２つの業務システムをコンテナ型仮想環境で構築・運用する状況を想定する。
【００２９】
こうしたシステム情報テーブル１２６のデータ構造は、業務システムを一意に特定するシステムＩＤをキーとして、当該システムの、「システム名」、「可用性ＩＤ」、「性能要件」、「性能要件更新日」といったデータから成るレコードの集合体である。
【００３０】
このうち可用性ＩＤは、当該システムに求められている可用性を一意に特定する識別情報であり、後述する可用性マスタテーブル１２７でその内容が規定されるものである。また、性能要件は、当該システムに求められる、１秒あたりのトランザクション処理数、すなわちＴＰＳであり、稼働分析サーバ２００により直近の所定期間内で観測された値となる。また、性能要件更新日は、上述の性能要件の値を稼働分析サーバ２００から得て更新した日時を示す値である。
【００３１】
図６に、本実施形態における可用性マスタテーブル１２７の一例を示す。本実施形態における可用性マスタテーブル１２７は、上述のシステム情報テーブル１２６において各業務システムに紐付いている可用性の内容を規定したテーブルである。そのデータ構造は、可用性を一意に特定する可用性ＩＤをキーとして、当該可用性の名称、障害の発生を許容しうるサーバの台数、といったデータから成るレコードの集合体である。
【００３２】
図７に、本実施形態におけるコンテナリストテーブル１２８の一例を示す。本実施形態におけるコンテナリストテーブル１２８は、各業務システムを構成する各コンテナの情報を蓄積したテーブルである。本実施形態の場合、上述した「Ａシステム」と「Ｂシステム」の２つの業務システムが、それぞれ「端末アプリケーション」（図中は“端末ＡＰ”）、「バッチアプリケーション」（図中は“バッチＡＰ”）、および「データベース」（図中は“ＤＢ”）に対応したコンテナで構成される状況を想定する。
【００３３】
こうしたコンテナリストテーブル１２８のデータ構造は、コンテナを一意に特定するコンテナＩＤをキーとして、当該コンテナのコンテナ名、割当先の業務システムのシステムＩＤ、コンテナ性能、次回ピーク想定日、ピーク時間帯（開始）、ピーク時間帯（終了）、および登録日、といったデータから成るレコードの集合体である。
【００３４】
このうち、コンテナ性能は、各コンテナに対し、稼働分析サーバ２００等の所定装置が所定量の処理負荷をかけて予め測定したＴＰＳの値であり、コンテナ管理サーバ１００が、そうした稼働分析サーバ２００等より得て格納したものとなる。また、次回ピーク想定日、ピーク時間帯（開始）、およびピーク時間帯（終了）の各値は、当該レコードの「コンテナ名」が示す、業務システム（におけるアプリケーションやＤＢ）のデータ処理のピーク時期（換言すれば対応するサーバにおけるリソース使用量のピーク）を示すものである。また、こうしたピーク時期の各値は、例えば各業務システムの管理者等が、過去のシステム運用実績や曜日や季節の要因、或いは今後の事業計画、所定期間先までの顧客動向等に基づいて予め予想し、設定した値である。なお、登録日は、コンテナ性能、次回ピーク想定日、ピーク時間帯（開始）、およびピーク時間帯（終了）の各値の登録日である。
【００３５】
図８に、本実施形態におけるコンテナ配置状況テーブル１２９の一例を示す。本実施形態におけるコンテナ配置状況テーブル１２９は、上述のコンテナリストテーブル１２８で規定した各業務システム向けのそれぞれのコンテナに関して、配置先のサーバとステータスの情報を蓄積したテーブルである。そのデータ構造は、コンテナをサーバに配置した通番をキーとして、当該通番の順でサーバに配置された当該コンテナのコンテナＩＤ、配置先のサーバを示すサービスＩＤ、当該コンテナの稼働状況等を示すステータス、および、当該コンテナの起動日時、といったデータから成るレコードの集合体である。
【００３６】
図９に、本実施形態におけるコンテナ調整トリガテーブル１３０の一例を示す。本実施形態におけるコンテナ調整トリガテーブル１３０は、コンテナ管理サーバ１００が稼働分析サーバ２００から受信したトリガ情報２２５を格納するテーブルである。
【００３７】
そのデータ構造は、トリガ情報を一意に特定するトリガＩＤをキーとして、トリガの契機となった稼働状況が生じたコンテナを示すコンテナＩＤ、トリガ区分１、トリガ区分２、トリガ名称、当該コンテナで構成する業務システムのシステムＩＤ、当該業務システムでの取引量、当該レコード（すなわちトリガ情報）の登録日時、当該トリガ情報に基づくコンテナ数変更適用日時、といったデータから成るレコードの集合体である。
【００３８】
このうちトリガ区分１は、各コンテナに関して、対応する業務システムにおける深夜帯でのバッチ処理やリブートといった定常処理に伴うイベントか、または、そうした定常処理とは異なり、当該コンテナでの取引量（ＴＰＳ）が短時間で急増した、或いは、当該コンテナが配置されたサーバでコンテナ数が減少したので再配置が必要、といった特別なイベントのいずれかを示す区分である。
【００３９】
また、トリガ区分２は、上述のトリガ区分１が示すイベントへの対処内容を示すもので、トリガ区分１「特別」のうち取引量急増のイベントに対する「コンテナ数調整」、トリガ区分１「特別」のうちコンテナ再配置必要とのイベントに対する「再配置」、といった値になる。また、トリガ名称は、上述のトリガ区分１が示すイベントの内容を示すものである。また、取引量は、当該コンテナにおける取引量（ＴＰＳ）の値であり、当該トリガの契機になった観測値である。
【００４０】
−−−フロー例１−−−
以下、本実施形態における仮想化環境管理方法の実際手順について図に基づき説明する。以下で説明する仮想化環境管理方法に対応する各種動作は、仮想化環境管理システム１０を構成する各サーバらがメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００４１】
図１０は、本実施形態における仮想化環境管理方法のフロー例１を示す図である。ここでは、サーバ群３００のうちどのサーバにもコンテナが配置されていない初期状態で、各業務システムに必要なコンテナを可用性等を踏まえて特定し、適宜なサーバに配置する初期設定時の処理について示す。
【００４２】
この場合、コンテナ管理サーバ１００は、システム情報テーブル１２６から、各業務システムの性能要件の値を取得し、また、コンテナリストテーブル１２８から、各業務システム向けのコンテナのコンテナ性能の値を取得する（ｓ１００）。
【００４３】
次にコンテナ管理サーバ１００は、上述のｓ１００で得た、業務システムの性能要件の値を、当該業務システム向けのコンテナのコンテナ性能の値で除算して、必要なコンテナ数（これを「ｍ」とする）を算定する処理を、各業務システムに関して実行する（ｓ１０１）。
【００４４】
例えば、「Ａシステム」の性能要件が「１５」（ＴＰＳ）であり、この「Ａシステム」のための各コンテナのうち例えば、「端末ＡＰ」のコンテナ性能が「５」（ＴＰＳ）であるため、コンテナ管理サーバ１００は、「Ａシステム」の「端末ＡＰ」コンテナの必要数を、１５÷５＝３つ、と算定する。また同様に、「Ａシステム」の「バッチＡＰ」コンテナの必要数を、１５÷１５＝１つ、「Ａシステム」の「ＤＢ」コンテナの必要数を、１５÷１５＝１つ、などと算定する。
【００４５】
続いてコンテナ管理サーバ１００は、サーバ情報テーブル１２５において、各サーバの情報のうち、「ステータス」の値が「正常」、かつ「区分」が「オンプレミス」であるサーバに関して、「区分」、「搭載ＣＰＵコア数」、「メモリ容量」、「稼働中コンテナ数」、「空きＣＰＵコア数」、および「空きメモリ容量」の各値を参照し、新たにコンテナを配置可能なサーバ数（これを「ｓ」とする）を特定する（ｓ１０２）。
【００４６】
この場合のコンテナ管理サーバ１００は、まず、「稼働中コンテナ数」が「０」のサーバの数をカウントし、これをメモリ１０３に記憶する。またコンテナ管理サーバ１００は、稼働中コンテナ数が「１」以上のサーバのうち、「搭載ＣＰＵコア数」で「空きＣＰＵコア数」が占める割合と、「メモリ容量」で「空きメモリ容量」が占める割合が、それぞれ所定の基準以下であるサーバの数をカウントし、既にメモリ１０３に記憶しておいた値と合算する。この合算値が当該ステップｓ１０２で特定すべき、新たにコンテナを配置可能なサーバ数、となる。
【００４７】
次に、コンテナ管理サーバ１００は、各業務システムに求められる可用性について、システム情報テーブル１２６で当該業務システムに関して規定されている可用性ＩＤをキーに、可用性マスタテーブル１２７を検索し、該当する可用性の情報を特定する（ｓ１０３）。  例えば、システム情報テーブル１２６において、「Ａシステム」の可用性ＩＤは「０００１」と規定されている。そこでコンテナ管理サーバ１００は、この可用性ＩＤ「０００１」をキーに、可用性マスタテーブル１２７を検索し、該当レコードから「障害許容台数」の値「１」を特定する。一方、「Ｂシステム」の場合、その可用性ＩＤ「０００２」をキーに、可用性マスタテーブル１２７を検索すると、該当レコードから「障害許容台数」の値「０」が特定される。
【００４８】
上述のステップｓ１０３の結果、「障害許容台数」の値が「０」であった場合、コンテナ管理サーバ１００は、当該業務システムは高可用性が要求されないシステムであると判定し（ｓ１０４：ｎ）、ｓ１０１で得ている必要なコンテナ数の値「ｍ」を、ｓ１０２で得ているサーバ数の値「ｓ」で除算する処理を、各業務システムの各コンテナに関して実行し、各サーバへの各コンテナの配置数を特定し、コンテナ管理ソフトウェア１１０に対して当該コンテナの当該サーバへの配置処理を指示する（ｓ１０５）。この指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００４９】
例えば、「Ｂシステム」の「端末ＡＰ」コンテナに関してｓ１０１で得ている必要なコンテナ数の値が「１」、ｓ１０２で得ているサーバ数の値が「３」であった場合、ｍ÷ｓ＝１÷３＝０．３、これを切り上げた実際のコンテナ数「１」を、各サーバ（新たにコンテナを配置可能なサーバ）への「Ｂシステム＿端末ＡＰ」コンテナの配置数とする。従って、図８に例示したコンテナ配置状況テーブル１２９において、「Ｂシステム＿端末ＡＰ」コンテナである、コンテナＩＤ「０００００００４」は、サーバ「０００００００２」、および「０００００００３」、のそれぞれに１つずつ配置されている。
【００５０】
他方、上述のステップｓ１０３の結果、「障害許容台数」の値が「１」以上であった場合、コンテナ管理サーバ１００は、当該業務システムは高可用性が求められるサーバであると判定し（ｓ１０４：ｙ）、ｓ１０１で得ている必要なコンテナ数の値「ｍ」を、ｓ１０２で得ているサーバ数の値「ｓ」から「障害許容台数」の値（ｓ１０３で得ている値）を減算した値で除算する処理を、各業務システムの各コンテナに関して実行し、各サーバへの各コンテナの配置数を特定し、コンテナ管理ソフトウェア１１０に対して当該コンテナの当該サーバへの配置処理を指示する（ｓ１０６）。この指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００５１】
例えば、「Ａシステム」の「端末ＡＰ」コンテナに関してｓ１０１で得ている必要なコンテナ数の値が「３」、ｓ１０２で得ているサーバ数の値が「３」、この「Ａシステム」の障害許容台数が「１」であった場合、ｍ÷（ｓ−１）＝３÷２＝１．５、これを切り上げた実際のコンテナ数「２」を、各サーバ（新たにコンテナを配置可能なサーバ）への「Ａシステム＿端末ＡＰ」コンテナの配置数とする。従って、図８に例示したコンテナ配置状況テーブル１２９において、「Ａシステム＿端末ＡＰ」コンテナである、コンテナＩＤ「０００００００１」は、サーバ「０００００００１」、「０００００００２」、および「０００００００３」、のそれぞれに２つずつ配置されている。
【００５２】
なお、「Ａシステム」の「バッチＡＰ」コンテナおよび「ＤＢ」コンテナに関して、ｓ１０１で得ている必要なコンテナ数の値が「１」、ｓ１０２で得ているサーバ数の値が「３」、この「Ａシステム」の障害許容台数が「１」であった場合、ｍ÷（ｓ−１）＝１÷２＝０．５、これを切り上げた実際のコンテナ数「１」を、各サーバ（新たにコンテナを配置可能なサーバ）への「Ａシステム＿バッチＡＰ」および「Ａシステム＿ＤＢ」の各コンテナの配置数とする。
【００５３】
但し、図８のコンテナ配置状況テーブル１２９に示すように、「Ａシステム＿バッチＡＰ」コンテナである、コンテナＩＤ「０００００００２」は、サーバ「０００００００１」、および「０００００００３」、のそれぞれに１つずつ配置され、サーバ「０００００００３」には配置していない。これは「Ａシステム＿ＤＢ」のコンテナである、コンテナＩＤ「０００００００３」についても同様である。これは、障害許容台数が「１」、すなわちどれか１つのサーバに障害が発生しても、該当業務システムの性能要件を達成出来ればよいことを踏まえ、３つのサーバのうち２つにのみコンテナを配置すれば、そのうちの１つに障害が発生しても性能要件は達成出来ることに対応したものとなる。一方、障害許容台数が「２」、すなわちどれか２つのサーバに障害が発生しても、該当業務システムの性能要件を達成出来ればよい場合に、３つのサーバ全てではなく２つのサーバのみにコンテナを配置すれば、その２つのサーバに障害が発生したならば、性能要件は達成出来ないことになる。そのため、必要なコンテナ数および障害許容台数が所定数以下の場合のみ、コンテナ管理サーバ１００は、各サーバのうち所定数のサーバのみにコンテナを配置する対応を行う。
【００５４】
続いて、コンテナ管理サーバ１００は、ここまでの処理で、コンテナリストテーブル１２８に規定したコンテナのコンテナＩＤと、コンテナ配置状況テーブル１２９の配置コンテナＩＤのうちステータスが「稼働中」のものとを照合し、コンテナリストテーブル１２８に規定したコンテナのうち、サーバに配置出来ていないものがあるか判定する（ｓ１０７）。図８で示すコンテナ配置状況テーブル１２９の例では、コンテナＩＤ「０００００００５」および「０００００００６」については、「配置サーバＩＤ」が「ＮＵＬＬ」であり、「ステータス」が「稼働中」ではなく、「配置待ち」となっており、サーバに配置出来ていないことが判明する。
【００５５】
上述の判定の結果、未配置のコンテナが特定されなければ（ｓ１０８：ｎ）、コンテナ管理サーバ１００は、当該フローを終了する。
【００５６】
他方、上述の判定の結果、未配置のコンテナが特定されたならば（ｓ１０８：ｙ）、コンテナ管理サーバ１００は、サーバ情報テーブル１２５において、各サーバの情報のうち、「ステータス」の値が「正常」、かつ「区分」が「パブリッククラウド」であるサーバに関して、ステップｓ１０２と同様の処理で、新たにコンテナを配置可能なサーバ数を特定する（ｓ１０９）。
【００５７】
この結果、パブリッククラウドのうち、新たにコンテナを配置可能なサーバが特定出来なかった場合（ｓ１１０：ｎ）、コンテナ管理サーバ１００は、更なるパブリッククラウドの契約増を要求するメッセージ等を、システム管理者等の所定端末に宛てて出力し（ｓ１１１）、当該フローを終了する。
【００５８】
他方、パブリッククラウドのうち、新たにコンテナを配置可能なサーバ（例：サーバＩＤ「０００００００４」のパブリッククラウド）が特定出来た場合（ｓ１１０：ｙ）、コンテナ管理サーバ１００は、上述のステップｓ１０８の判定で特定された未配置のコンテナについて、コンテナ管理ソフトウェア１１０に対して当該コンテナの当該サーバへの配置処理を指示する（ｓ１１２）。この指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００５９】
以上で、初期状態のサーバへのコンテナの配置処理が完了する。
【００６０】
−−−フロー例２−−−
次に、上述のフロー例１のように構成したコンテナ型仮想環境が稼働を開始し、その状況を稼働分析サーバ２００が監視している状況での処理について図に基づき説明する。図１１は、本実施形態における仮想化環境管理方法のフロー例２を示す図である。なお、稼働分析サーバ２００は、サーバ群３００における各コンテナに関して、稼働状況を監視し、所定のイベントを検知した場合に、その情報をトリガ情報２２５としてコンテナ管理サーバ１００に送信しているものとする。また、その場合、コンテナ管理サーバ１００は、トリガ情報２２５をコンテナ調整トリガテーブル１３０に格納しているものとする。
【００６１】
こうした状況におけるコンテナ管理サーバ１００は、例えば所定時間ごとにコンテナ調整トリガテーブル１３０にアクセスして、コンテナ数変更適用日時が「ＮＵＬＬ」、すなわち、未対応のトリガを特定する（ｓ２００）。
【００６２】
次にコンテナ管理サーバ１００は、上述のステップｓ２００で特定した未対応のトリガのトリガ区分１が「通常」、かつトリガ区分２が「停止」か否か判定する（ｓ２０１）。
【００６３】
この判定の結果、未対応トリガのトリガ区分１が「通常」かつトリガ区分２が「停止」であった場合（ｓ２０１：ｙ）、コンテナ管理サーバ１００は、コンテナ管理ソフトウェア１１０に対して該当コンテナ停止を指示し（ｓ２０２）、当該フローを終了する。
【００６４】
他方、上述の判定の結果、未対応トリガのトリガ区分１が「特別」であった場合（ｓ２０１：ｎ）、コンテナ管理サーバ１００は、当該トリガのトリガ区分２が「コンテナ数調整」か否か判定する（ｓ２０３）。
【００６５】
この判定の結果、当該トリガのトリガ区分２が「コンテナ数調整」であった場合（ｓ２０３：ｙ）、コンテナ管理サーバ１００は、コンテナ調整トリガテーブル１３０において、当該トリガに関する情報のうち、「取引量（ＴＰＳ）」の値を抽出する（ｓ２０４）。
【００６６】
この場合のコンテナ管理サーバ１００は、該当コンテナに対応する業務システムでの取引量（ＴＰＳ）が急増或いは急減した状況を解消すべく、該当コンテナを増減させる対応を開始したことになる。
【００６７】
続いてコンテナ管理サーバ１００は、コンテナリストテーブル１２８から、各業務システム向けのコンテナのうち、当該コンテナのコンテナ性能の値を取得する（ｓ２０５）。
【００６８】
また、コンテナ管理サーバ１００は、上述のｓ２０４で得た、取引量（ＴＰＳ）の値を、当該コンテナのコンテナ性能の値で除算して、現状において必要なコンテナ数（これを「ｍ’」とする）を算定する（ｓ２０６）。
【００６９】
例えば、トリガＩＤ「０００００００１」が示すシステムＩＤ「００００１」、すなわち「Ａシステム」での取引量（ＴＰＳ）が「８」（ＴＰＳ）であり、この「Ａシステム」の当該コンテナ「０００００００１」、すなわち「端末ＡＰ」のコンテナ性能が「５」（ＴＰＳ）であるため、コンテナ管理サーバ１００は、現状における「Ａシステム」の「端末ＡＰ」コンテナの必要数を、８÷５＝１．６、すなわち２つ、と算定する。
【００７０】
続いてコンテナ管理サーバ１００は、上述のステップｓ２０６で算定したコンテナ数「ｍ’」と、フロー例１のステップｓ１０１で算定したコンテナ数「ｍ」、すなわち初期設定時のコンテナ数と比較する（ｓ２０７）。
【００７１】
この比較の結果、ｍ＞ｍ’、すなわち必要なコンテナ数が初期設定時より減少した場合（ｓ２０８：ｙ）、コンテナ管理サーバ１００は、当該コンテナが配置されているサーバを、コンテナ配置状況テーブル１２９にて特定する（ｓ２０９）。
【００７２】
コンテナ管理サーバ１００は、ｓ２０９で特定したサーバの数で、上述の現状において必要なコンテナ数「ｍ’」を除算し、該当サーバへの当該コンテナの配置数を特定し、この配置数と、当該フロー開始前の当該サーバへの当該コンテナの配置数との差分を算定する（ｓ２１０）。
【００７３】
例えば、「Ａシステム」の「端末ＡＰ」コンテナに関してｓ２０６で得ている、現状において必要なコンテナ数の値が「１」、ｓ２０９で特定した当該コンテナが配置されているサーバの数が「３」であった場合、ｍ’÷３＝１÷３＝０．３、これを切り上げた実際のコンテナ数「１」が、当該サーバへの「Ａシステム＿端末ＡＰ」コンテナの配置数と特定できる。また、当該フロー開始前の当該サーバへの該当コンテナの配置数が「３」であった場合、現状において必要なコンテナ数と当該フロー開始前のコンテナの配置数との差分は、３−１＝２、と算定出来る。つまりこの場合、３台の各サーバに配置する当該コンテナを、１つずつ減少させる必要があることになる。
【００７４】
そこでコンテナ管理サーバ１００は、コンテナ管理ソフトウェア１１０に対し、当該サーバにおける当該コンテナの配置数を、（上述の例の場合、１つ）減ずる処理を指示し（ｓ２１１）、フローを終了する。なお、こうしたコンテナの低減を行う場合、コンテナ管理サーバ１００は、パブリッククラウド３２０に配置されたコンテナから優先的に停止させるものとする。
【００７５】
上述の指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００７６】
一方、上述のステップｓ２０７の比較の結果、ｍ＜ｍ’、すなわち必要なコンテナ数が初期設定時より増加した場合（ｓ２０８：ｎ）、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９と、サーバ情報テーブル１２５を参照し、当該コンテナが配置されているサーバを含め全サーバについて、フロー例１のステップｓ１０２と同様に、新たなコンテナを配置可能なサーバ数（これを「ｓ’」とする）を特定する（ｓ２１２）。
【００７７】
また、コンテナ管理サーバ１００は、当該業務システムに求められる可用性について、上述のフロー例１のステップｓ１０３と同様に、「障害許容台数」の値を特定する（ｓ２１３）。
【００７８】
上述のステップｓ２１３の結果、「障害許容台数」の値が「０」であった場合、コンテナ管理サーバ１００は、当該業務システムは高可用性が要求されないシステムであると判定し（ｓ２１４：ｎ）、ｓ２０６で得ている必要なコンテナ数の値「ｍ’」を、ｓ２１２で得ているサーバ数の値「ｓ’」で除算する処理を実行し、該当各サーバへの当該コンテナの配置数を特定し、コンテナ管理ソフトウェア１１０に対して当該コンテナの当該サーバへの配置処理を指示し（ｓ２１５）、フローを終了する。
【００７９】
なお、こうしたコンテナの増加を行う場合、コンテナ管理サーバ１００は、オンプレミスのサーバ群３１０のサーバから優先的に配置させるものとする。但し、この優先的な配置を経ても、パブリッククラウド３２０へのコンテナ配置を行う必要がある場合、コンテナ管理サーバ１００は、予め定めた業務システムごとのパブリッククラウド３２０へのコンテナ移行可否の基準（例えば、システム情報テーブル１２６や、コンテナリストテーブル１２８で、各業務システムまたは各コンテナに関して移行可否が設定してあるとする）に基づき、新たに配置すべきコンテナの移行要否を判定する。この判定の結果、当該コンテナの移行が不可であった場合、コンテナ管理サーバ１００は、上述の基準において移行可能な他コンテナをパブリッククラウド３２０に移行させる。そしてコンテナ管理サーバ１００は、当該移行させたコンテナが元々配置されていたオンプレミスのサーバに、上述の当該コンテナを移行させる。勿論、こうした移行の処理はコンテナ管理ソフトウェア１１０に指示を行って実行する。
【００８０】
上述の指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００８１】
例えば、「Ａシステム」の「バッチＡＰ」コンテナに関してｓ２０６で得ている、現状において必要なコンテナ数の値が「４」、ｓ２１２で特定した新たなコンテナを配置可能なサーバの数が「３」であった場合、ｍ’÷３＝４÷３＝１．３、これを切り上げた実際のコンテナ数「２」が、当該サーバへの「Ａシステム＿バッチＡＰ」コンテナの配置数と特定できる。また、当該フロー開始前の当該サーバへの該当コンテナの配置数が「１」であった場合、現状において必要なコンテナ数と当該フロー開始前のコンテナの配置数との差分は、４−１＝３、と算定出来る。当該フロー開始前から当該コンテナを配置しているサーバ（便宜的に既存配置先とする）において、新たにコンテナの配置を受けるリソースの余裕が無い場合、こうした差分、すなわち増加するコンテナ数の配置先は、上述の既存配置先とは別のサーバになる。
【００８２】
他方、上述のステップｓ２１３の結果、「障害許容台数」の値が「１」以上であった場合、コンテナ管理サーバ１００は、当該業務システムは高可用性が求められるサーバであると判定し（ｓ２１４：ｙ）、ｓ２０６で得ている必要なコンテナ数の値「ｍ’」を、ｓ２１２で得ているサーバ数の値「ｓ’」から「障害許容台数」の値（ｓ２１３で得ている値）を減算した値で除算する処理を実行し、該当各サーバへの当該コンテナの配置数を特定し、コンテナ管理ソフトウェア１１０に対して当該コンテナの当該サーバへの配置処理を指示し（ｓ２１６）、フローを終了する。なお、こうしたコンテナの増加を行う場合、コンテナ管理サーバ１００は、オンプレミスのサーバ群３１０のサーバから優先的に配置させるものとする。
【００８３】
上述の指示に伴い、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９において当該コンテナのレコードを更新する。
【００８４】
なお、上述のようにコンテナ数の増減を行うに際し、コンテナ管理サーバ１００は、当該業務システムにおける処理の繁閑時期に基づき、コンテナ数の過不足の状態が所定期間継続することが特定できる場合に、コンテナ数増減を実行するとすれば好適である。例えば、上述のコンテナ数の増減指示をコンテナ管理ソフトウェア１１０に通知するに先立ち、コンテナリストテーブル１２８にて、当該コンテナの次回ピーク想定日、ピーク時間帯（開始）、およびピーク時間帯（終了）、の各値を参照する。またコンテナ管理サーバ１００は、ここで参照して特定出来た次回のピーク日時、すなわち繁忙期まで現日時から所定時間以内であれば、コンテナ数減少は実行せず、他方、次回のピーク日時まで現日時から所定時間以上であれば、コンテナ数増加は実行しない、といった処理を実行する。
【００８５】
他方、上述のステップｓ２０３の判定の結果、当該トリガのトリガ区分２が「コンテナ数調整」でなかった場合（ｓ２０３：ｎ）、コンテナ管理サーバ１００は、当該トリガのトリガ区分２は「再配置」であると特定し（ｓ２１７）、当該コンテナの配置先の各サーバを含む、サーバ群３００のいずれか複数のサーバのうち所定のサーバに、他のサーバのコンテナを移動させる処理を実行し（ｓ２１８）、フローを終了する。
【００８６】
こうした「再配置」の処理は、当該コンテナの配置先の各サーバのうち少なくともいずれか複数のサーバにおけるコンテナ数が所定基準より少なく、サーバの使用効率が低下しているため、コンテナの配置をいずれかのサーバに集約し、配置コンテナがゼロになったサーバを停止して全体のサーバ運用を効率化するためものとなる。
【００８７】
「再配置」の処理としては、コンテナ管理サーバ１００は、コンテナ配置状況テーブル１２９を参照し、例えば、オンプレミスのサーバ群３１０（配置サーバＩＤをキーにサーバ情報テーブル１２５で特定）において、配置コンテナの数が他サーバよりも少ないか配置コンテナ数がゼロ、かつ、リソースの使用率が低い（サーバ情報テーブル１２５で特定）、といった所定のサーバを特定し、このサーバに対し、他のサーバのコンテナを移動させて集約配置する。また、コンテナ管理サーバ１００は、これによりリソースに余剰が生じたオンプレミスのサーバ（上述の所定のサーバ以外のオンプレミスのサーバ）に対し、それまでパブリッククラウド３２０に配置されていたコンテナを移動させる、といった更なる処理を実行する。
【００８８】
但し当然ながら、当該業務システムに求められる可用性の要件を満たす範囲で、サーバ間でのコンテナ移動を行うことになる。従って、該当業務システムの可用性を可用性マスタテーブル１２７で特定し、既に述べた障害許容台数の値を用いた各サーバへのコンテナ配置数の算定手法を利用する。他方、この配慮を採用せず、徒にコンテナの集約を進めた結果、該当サーバでの障害発生が生じれば、全く機能を失う事態に至る。
【００８９】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００９０】
こうした本実施形態によれば、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用が可能となる。
【００９１】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より少ない場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて低減するものである、としてもよい。
【００９２】
これによれば、コンテナ数低減に伴う余剰リソースの抑制処理を効率的なものとし、ひいては、より効率的なシステム運用が可能となる。
【００９３】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より多い場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて増加させるものである、としてもよい。
【００９４】
これによれば、システム稼働状況に的確に対応して精度良くコンテナ数を増加させ、ひいては、より効率的なシステム運用が可能となる。
【００９５】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数との差異の値を、前記ハードウェアの数から当該システムの可用性基準に応じた障害発生ハードウェア数を減算した値で除算し、当該除算により得た値だけ、前記ハードウェアでの当該システム向けのコンテナ数を増減させるものである、としてもよい。
【００９６】
これによれば、システム稼働状況とともに、当該システムに求められる可用性を併せて踏まえて、必要なコンテナ数をさらに精度良好に特定し、ひいては、安定的で更に効率的なシステム運用が可能となる。
【００９７】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、各ハードウェアのうち少なくともいずれか複数のハードウェアに配置したコンテナ数が所定基準より少ない場合、当該複数のハードウェアのうち所定のハードウェアに他のハードウェアのコンテナを移動させる処理を更に実行するものである、としてもよい。
【００９８】
これによれば、コンテナを配置するハードウェア数を絞り込むことで、不要となったハードウェアの稼働を停止させ、当該ハードウェアの運用コスト等を低減することができる。ひいては、より効率的なシステム運用が可能となる。
【００９９】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記過不足に応じて、前記ハードウェアでの当該システム向けのコンテナ数を増加させる必要があり、前記ハードウェアに配置しきれない未配置コンテナが生じる場合、所定の外部サーバに構築したコンテナ型仮想化環境に、前記未配置コンテナを配置する処理を更に実行するものである、としてもよい。
【０１００】
これによれば、例えば金融機関に設置したオンプレミスのサーバらが、各システムのコンテナを収容しきれない状況が生じる事態となっても、いわゆるパブリッククラウド等の外部サーバ上のコンテナ型仮想化環境をコンテナ配置先として機動的に利用することが出来る。勿論、オンプレミスのサーバらで必要なコンテナを全て収容可能な状況になれば、こうした外部サーバに配置したコンテナをオンプレミスのコンテナ型仮想化環境に復帰させるといった運用も可能である。ひいては、システム負荷等の変化に応じたダイナミックで更に効率的なシステム運用が可能となる。
【０１０１】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記未配置コンテナを前記外部サーバのコンテナ型仮想化環境に配置するに際し、予め定めたシステムごとの外部サーバへのコンテナ移行可否の基準に基づき、前記未配置コンテナに対応したシステムの移行要否を判定し、当該未配置コンテナの移行不可であった場合に、前記基準において移行可能な他システムの所定コンテナを前記外部サーバのコンテナ型仮想化環境に移行させ、当該移行させた前記所定コンテナが元々配置されていたハードウェアに、前記未配置コンテナを移行させる処理を更に実行するものである、としてもよい。
【０１０２】
これによれば、金融機関等に特有の厳格なセキュリティポリシーの運用に適応しつつ、コンテナの効率的な配置管理が可能となる。ひいては、セキュアなシステム運用と効率的な仮想化環境管理を両立させ、更により効率的なシステム運用が可能となる。
【０１０３】
また、本実施形態の仮想化環境管理システムにおいて、前記演算装置は、前記コンテナ数を増減させるに際し、当該システムにおける処理の繁閑時期に関する所定の予測情報に基づき、前記コンテナ数の過不足の状態が所定期間継続することが特定できる場合に、前記コンテナ数の増減を実行するものである、としてもよい。
【０１０４】
これによれば、徒にコンテナ数増減を繰り返すことで、そうしたコンテナ配置の管理処理に関する負荷や時間が増大し、ついには全体効率が低下するといった懸念を解消出来る。ひいては、仮想環境における余剰リソースの効率的な抑制を図り、更に効率的なシステム運用が可能となる。
【０１０５】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より少ない場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて低減する、としてもよい。
【０１０６】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数とに差異があり、前記特定したコンテナ数が現コンテナ数より多い場合、前記ハードウェアに配置した当該システム向けのコンテナを、前記差異の値に応じて増加させる、としてもよい。
【０１０７】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記コンテナ数を増減させるに際し、前記特定したコンテナ数と前記現コンテナ数との差異の値を、前記ハードウェアの数から当該システムの可用性基準に応じた障害発生ハードウェア数を減算した値で除算し、当該除算により得た値だけ、前記ハードウェアでの当該システム向けのコンテナ数を増減させる、としてもよい。
【０１０８】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、各ハードウェアのうち少なくともいずれか複数のハードウェアに配置したコンテナ数が所定基準より少ない場合、当該複数のハードウェアのうち所定のハードウェアに他のハードウェアのコンテナを移動させる処理を更に実行する、としてもよい。
【０１０９】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記過不足に応じて、前記ハードウェアでの当該システム向けのコンテナ数を増加させる必要があり、前記ハードウェアに配置しきれない未配置コンテナが生じる場合、所定の外部サーバに構築したコンテナ型仮想化環境に、前記未配置コンテナを配置する処理を更に実行する、としてもよい。
【０１１０】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記未配置コンテナを前記外部サーバのコンテナ型仮想化環境に配置するに際し、予め定めたシステムごとの外部サーバへのコンテナ移行可否の基準に基づき、前記未配置コンテナに対応したシステムの移行要否を判定し、当該未配置コンテナの移行不可であった場合に、前記基準において移行可能な他システムの所定コンテナを前記外部サーバのコンテナ型仮想化環境に移行させ、当該移行させた前記所定コンテナが元々配置されていたハードウェアに、前記未配置コンテナを移行させる処理を更に実行する、としてもよい。
【０１１１】
また、本実施形態の仮想化環境管理方法において、前記情報処理システムが、前記コンテナ数を増減させるに際し、当該システムにおける処理の繁閑時期に関する所定の予測情報に基づき、前記コンテナ数の過不足の状態が所定期間継続することが特定できる場合に、前記コンテナ数の増減を実行する、としてもよい。
【符号の説明】
【０１１２】
５  ネットワーク
１０    仮想化環境管理システム
１００  コンテナ管理サーバ
１０１  記憶装置
１０２  プログラム
１０３  メモリ
１０４  演算装置
１０５  通信装置
１１０  コンテナ管理ソフトウェア
１２５  サーバ情報テーブル
１２６  システム情報テーブル
１２７  可用性マスタテーブル
１２８  コンテナリストテーブル
１２９  コンテナ配置状況テーブル
１３０  コンテナ調整トリガテーブル
２００  稼働分析サーバ
２０１  記憶装置
２０２  プログラム
２０３  メモリ
２０４  演算装置
２０５  通信装置
２２５  トリガ情報
３００  サーバ群
３１０  オンプレミスのサーバ群
３２０  パブリッククラウド（外部サーバ）
【図１】
2017138895.tif 000003
【図２】
2017138895.tif 000004
【図３】
2017138895.tif 000005
【図４】
2017138895.tif 000006
【図５】
2017138895.tif 000007
【図６】
2017138895.tif 000008
【図７】
2017138895.tif 000009
【図８】
2017138895.tif 000010
【図９】
2017138895.tif 000011
【図１０】
2017138895.tif 000012
【図１１】
2017138895.tif 000013