JP7707453B2

JP7707453B2 - 通信システムに含まれるハードウェアリソースの管理

Info

Publication number: JP7707453B2
Application number: JP2024549040A
Authority: JP
Inventors: 真也北
Original assignee: Rakuten Mobile Inc
Current assignee: Rakuten Mobile Inc
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2025-07-14
Anticipated expiration: 2042-09-30
Also published as: US20250094226A1; JPWO2024069949A1; WO2024069949A1; EP4597971A1; EP4597971A4

Description

本発明は、通信システムに含まれるハードウェアリソースの管理に関する。

通信システムに含まれるハードウェアリソースを複数のハードウェアリソース群に分けて管理する技術が存在する。このような技術の一例として、特許文献１には、特定種類の機能ユニットに応じたシステムソフトウェアのセットアップが施された未使用ハードウェアリソースを、当該特定種類の機能ユニットに関連付けられているリソースプールに追加することが記載されている。

また、特許文献２、及び、特許文献３には、ＶＮＦ（Virtualized Network Function）などといった、通信システムで稼働するアプリケーションのスケールアウトを実行する技術が記載されている。

国際公開第２０２１／１７１２１１号特開２０１７－１７３８９４号公報国際公開第２０１７／１７０４７０号

通信システムに含まれるハードウェアリソースを複数のハードウェアリソース群に分けて管理する場合に、アプリケーションのスケールアウトが実行されることを見越して、複数のハードウェアリソース群のそれぞれで多くのハードウェアリソースを予め確保してしまうと、ハードウェアリソースの無駄が発生してしまう。

本発明は上記実情に鑑みてなされたものであって、その目的の一つは、通信システムに含まれるハードウェアリソースを効率的に使用できるようにすることにある。

上記課題を解決するために、本開示に係るリソース管理システムは、通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視手段と、いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を、前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加手段と、所定のアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段と、を含み、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記リソース追加手段が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更し、前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記セットアップ実行手段が、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記リソース追加手段が、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更する。

また、本開示に係るリソース管理方法は、通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群の一部であり、含まれているハードウェアリソースが、所定のアプリケーションの種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更することと、前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更することと、を含む。

本発明の一実施形態に係る通信システムの一例を示す図である。本発明の一実施形態に係る通信システムの一例を示す図である。本発明の一実施形態に係るネットワークサービスの一例を模式的に示す図である。本発明の一実施形態に係る通信システムに構築される要素間の関連付けの一例を示す図である。本発明の一実施形態に係るプラットフォームシステムで実装される機能の一例を示す機能ブロック図である。物理インベントリデータのデータ構造の一例を示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係る通信システムに含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。

以下、本発明の一実施形態について図面に基づき詳細に説明する。

図１及び図２は、本発明の一実施形態に係る通信システム１の一例を示す図である。図１は、通信システム１に含まれるデータセンタ群のロケーションに着目した図となっている。図２は、通信システム１に含まれるデータセンタ群で実装されている各種のコンピュータシステムに着目した図となっている。

図１に示すように、通信システム１に含まれるデータセンタ群は、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４に分類される。

セントラルデータセンタ１０は、例えば、通信システム１がカバーするエリア内（例えば、日本国内）に分散して数個配置されている。

リージョナルデータセンタ１２は、例えば、通信システム１がカバーするエリア内に分散して数十個配置されている。例えば、通信システム１がカバーするエリアが日本国内全域である場合に、リージョナルデータセンタ１２が、各都道府県に１から２個ずつ配置されてもよい。

エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。ここで図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（User Equipment）２０との間で無線通信を行う。アンテナ１６を備えた通信設備１８には、例えば、後述のＲＵ（Radio Unit）が設けられている。

本実施形態に係るセントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４には、それぞれ、複数のサーバが配置されている。

本実施形態では例えば、セントラルデータセンタ１０、リージョナルデータセンタ１２、エッジデータセンタ１４は、互いに通信可能となっている。また、セントラルデータセンタ１０同士、リージョナルデータセンタ１２同士、エッジデータセンタ１４同士も互いに通信可能になっている。

図２に示すように、本実施形態に係る通信システム１には、プラットフォームシステム３０、複数の無線アクセスネットワーク（ＲＡＮ）３２、複数のコアネットワークシステム３４、複数のＵＥ２０が含まれている。コアネットワークシステム３４、ＲＡＮ３２、ＵＥ２０は、互いに連携して、移動通信ネットワークを実現する。

ＲＡＮ３２は、第４世代移動通信システム（以下、４Ｇと呼ぶ。）におけるｅＮＢ（ｅＮｏｄｅＢ）や、第５世代移動通信システム（以下、５Ｇと呼ぶ。）におけるｇＮＢ（ＮＲ基地局）に相当する、アンテナ１６を備えたコンピュータシステムである。本実施形態に係るＲＡＮ３２は、主に、エッジデータセンタ１４に配置されているサーバ群及び通信設備１８によって実装される。なお、ＲＡＮ３２の一部（例えば、ＤＵ（Distributed Unit）、ＣＵ（Central Unit）、ｖＤＵ（virtual Distributed Unit）、ｖＣＵ（virtual Central Unit））は、エッジデータセンタ１４ではなく、セントラルデータセンタ１０やリージョナルデータセンタ１２で実装されてもよい。

コアネットワークシステム３４は、４ＧにおけるＥＰＣ（Evolved Packet Core）や、５Ｇにおける５Ｇコア（５ＧＣ）に相当するシステムである。本実施形態に係るコアネットワークシステム３４は、主に、セントラルデータセンタ１０やリージョナルデータセンタ１２に配置されているサーバ群によって実装される。

本実施形態に係るプラットフォームシステム３０は、例えば、クラウド基盤上に構成されており、図２に示すように、プロセッサ３０ａ、記憶部３０ｂ、通信部３０ｃ、が含まれる。プロセッサ３０ａは、プラットフォームシステム３０にインストールされるプログラムに従って動作するマイクロプロセッサ等のプログラム制御デバイスである。記憶部３０ｂは、例えばＲＯＭやＲＡＭ等の記憶素子や、ソリッドステートドライブ（ＳＳＤ）、ハードディスクドライブ（ＨＤＤ）などである。記憶部３０ｂには、プロセッサ３０ａによって実行されるプログラムなどが記憶される。通信部３０ｃは、例えば、ＮＩＣ（Network Interface Controller）や無線ＬＡＮ（Local Area Network）モジュールなどといった通信インタフェースである。なお、通信部３０ｃにおいて、ＳＤＮ（Software-Defined Networking）が実装されていてもよい。通信部３０ｃは、ＲＡＮ３２、コアネットワークシステム３４、との間でデータを授受する。

本実施形態では、プラットフォームシステム３０は、セントラルデータセンタ１０に配置されているサーバ群によって実装されている。なお、プラットフォームシステム３０が、リージョナルデータセンタ１２に配置されているサーバ群によって実装されていてもよい。

本実施形態では例えば、購入者によるネットワークサービス（ＮＳ）の購入要求に応じて、購入要求がされたネットワークサービスがＲＡＮ３２やコアネットワークシステム３４に構築される。そして、構築されたネットワークサービスが購入者に提供される。

例えば、ＭＶＮＯ（Mobile Virtual Network Operator）である購入者に、音声通信サービスやデータ通信サービス等のネットワークサービスが提供される。本実施形態によって提供される音声通信サービスやデータ通信サービスは、図１及び図２に示すＵＥ２０を利用する、購入者（上述の例ではＭＶＮＯ）にとっての顧客（エンドユーザ）に対して最終的に提供されることとなる。当該エンドユーザは、ＲＡＮ３２やコアネットワークシステム３４を介して他のユーザとの間で音声通信やデータ通信を行うことが可能である。また、当該エンドユーザのＵＥ２０は、ＲＡＮ３２やコアネットワークシステム３４を介してインターネット等のデータネットワークにアクセスできるようになっている。

また、本実施形態において、ロボットアームやコネクテッドカーなどを利用するエンドユーザに対して、ＩｏＴ（Internet of Things）サービスが提供されても構わない。そして、この場合において、例えば、ロボットアームやコネクテッドカーなどを利用するエンドユーザが本実施形態に係るネットワークサービスの購入者となっても構わない。

本実施形態では、セントラルデータセンタ１０、リージョナルデータセンタ１２、及び、エッジデータセンタ１４に配置されているサーバには、ドッカー（Ｄｏｃｋｅｒ（登録商標））などのコンテナ型の仮想化アプリケーション実行環境がインストールされており、これらのサーバにコンテナをデプロイして稼働させることができるようになっている。これらのサーバにおいて、このような仮想化技術によって生成される１以上のコンテナから構成されるクラスタが構築されてもよい。例えば、クバネテス（Ｋｕｂｅｒｎｅｔｅｓ（登録商標））等のコンテナ管理ツールによって管理されるクバネテスクラスタが構築されていてもよい。そして、構築されたクラスタ上のプロセッサがコンテナ型のアプリケーションを実行してもよい。

そして本実施形態において購入者に提供されるネットワークサービスは、１又は複数の機能ユニット（例えば、ネットワークファンクション（ＮＦ））から構成される。本実施形態では、当該機能ユニットは、仮想化技術によって実現されたＮＦで実装される。仮想化技術によって実現されたＮＦは、ＶＮＦ（Virtualized Network Function）と称される。なお、どのような仮想化技術によって仮想化されたかは問わない。例えば、コンテナ型の仮想化技術によって実現されたＣＮＦ（Containerized Network Function）も、本説明においてＶＮＦに含まれる。本実施形態では、ネットワークサービスが１又は複数のＣＮＦによって実装されるものとして説明する。また、本実施形態に係る機能ユニットは、ネットワークノードに相当するものであってもよい。

図３は、稼働中のネットワークサービスの一例を模式的に示す図である。図３に示すネットワークサービスには、複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ４４（ＣＵ－ＣＰ（Central Unit - Control Plane）４４ａ、及び、ＣＵ－ＵＰ（Central Unit - User Plane）４４ｂ）、複数のＡＭＦ（Access and Mobility Management Function）４６、複数のＳＭＦ（Session Management Function）４８、及び、複数のＵＰＦ（User Plane Function）５０などのＮＦがソフトウェア要素として含まれている。

図３の例では、ＲＵ４０、ＤＵ４２、ＣＵ－ＣＰ４４ａ、ＡＭＦ４６、及び、ＳＭＦ４８が、コントロールプレーン（Ｃ－Ｐｌａｎｅ）の要素に相当し、ＲＵ４０、ＤＵ４２、ＣＵ－ＵＰ４４ｂ、及び、ＵＰＦ５０が、ユーザプレーン（Ｕ－Ｐｌａｎｅ）の要素に相当する。

なお、当該ネットワークサービスに、他の種類のＮＦがソフトウェア要素として含まれていても構わない。また、ネットワークサービスは、複数のサーバ等のコンピュータリソース（ハードウェア要素）上に実装されている。

そして、本実施形態では例えば、図３に示すネットワークサービスによって、あるエリアにおける通信サービスが提供される。

そして、本実施形態では、図３に示す複数のＲＵ４０、複数のＤＵ４２、複数のＣＵ－ＵＰ４４ｂ、及び、複数のＵＰＦ５０が、１つのエンド・ツー・エンドのネットワークスライスに所属していることとする。

図４は、本実施形態において通信システム１に構築される要素間の関連付けの一例を模式的に示す図である。なお、図４に示された記号Ｍ及びＮは１以上の任意の整数を表し、リンクで接続された要素同士の個数の関係を示す。リンクの両端がＭとＮの組み合わせの場合は、当該リンクで接続された要素同士は多対多の関係であり、リンクの両端が１とＮの組み合わせ又は１とＭの組み合わせの場合は、当該リンクで接続された要素同士は１対多の関係である。

図４に示すように、ネットワークサービス（ＮＳ）、ネットワークファンクション（ＮＦ）、ＣＮＦＣ（Containerized Network Function Component）、ｐｏｄ、及び、コンテナは、階層構成となっている。

ＮＳは、例えば、複数のＮＦから構成されるネットワークサービスに相当する。ここで、ＮＳが、例えば、５ＧＣ、ＥＰＣ、５ＧのＲＡＮ（ｇＮＢ）、４ＧのＲＡＮ（ｅＮＢ）、などの粒度の要素に相当するものであってもよい。

ＮＦは、５Ｇでは、例えば、ＲＵ、ＤＵ、ＣＵ－ＣＰ、ＣＵ－ＵＰ、ＡＭＦ、ＳＭＦ、ＵＰＦなどの粒度の要素に相当する。また、ＮＦは、４Ｇでは、例えば、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、Ｓ－ＧＷ（Serving Gateway）、ｖＤＵ、ｖＣＵなどの粒度の要素に相当する。本実施形態では例えば、１つのＮＳには、１又は複数のＮＦが含まれる。すなわち、１又は複数のＮＦが、１つのＮＳの配下にあることとなる。

ＣＮＦＣは、例えば、ＤＵｍｇｍｔやＤＵＰｒｏｃｅｓｓｉｎｇなどの粒度の要素に相当する。ＣＮＦＣは、１つ以上のコンテナとしてサーバにデプロイされるマイクロサービスであってもよい。例えば、あるＣＮＦＣは、ＤＵ、ＣＵ－ＣＰ、ＣＵ－ＵＰ等の機能のうち一部の機能を提供するマイクロサービスであってもよい。また、あるＣＮＦＣは、ＵＰＦ、ＡＭＦ、ＳＭＦ等の機能のうちの一部の機能を提供するマイクロサービスであってもよい。本実施形態では例えば、１つのＮＦには、１又は複数のＣＮＦＣが含まれる。すなわち、１又は複数のＣＮＦＣが、１つのＮＦの配下にあることとなる。

ｐｏｄは、例えば、クバネテスでドッカーコンテナを管理するための最小単位を指す。本実施形態では例えば、１つのＣＮＦＣには、１又は複数のｐｏｄが含まれる。すなわち、１又は複数のｐｏｄが、１つのＣＮＦＣの配下にあることとなる。

そして、本実施形態では例えば、１つのｐｏｄには、１又は複数のコンテナが含まれる。すなわち、１又は複数のコンテナが、１つのｐｏｄの配下にあることとなる。

また、図４に示すように、ネットワークスライス（ＮＳＩ）とネットワークスライスサブネットインスタンス（ＮＳＳＩ）とは階層構成となっている。

ＮＳＩは、複数ドメイン（例えばＲＡＮ３２からコアネットワークシステム３４）に跨るエンド・ツー・エンドの仮想回線とも言える。ＮＳＩは、高速大容量通信用のスライス（例えば、ｅＭＢＢ：enhanced Mobile Broadband用）、高信頼度かつ低遅延通信用のスライス（例えば、ＵＲＬＬＣ:Ultra-Reliable and Low Latency Communications用）、又は、大量端末の接続用のスライス（例えば、ｍＭＴＣ：massive Machine Type Communication用）であってもよい。ＮＳＳＩは、ＮＳＩを分割した単一ドメインの仮想回線とも言える。ＮＳＳＩは、ＲＡＮドメインのスライス、ＭＢＨ（Mobile Back Haul）ドメイン等のトランスポートドメインのスライス、又は、コアネットワークドメインのスライスであってもよい。

本実施形態では例えば、１つのＮＳＩには、１又は複数のＮＳＳＩが含まれる。すなわち、１又は複数のＮＳＳＩが、１つのＮＳＩの配下にあることとなる。なお、本実施形態において、複数のＮＳＩが同じＮＳＳＩを共有してもよい。

また、図４に示すように、ＮＳＳＩとＮＳとは、一般的には、多対多の関係となる。

また、本実施形態では例えば、１つのＮＦは、１又は複数のネットワークスライスに所属できるようになっている。具体的には例えば、１つのＮＦには、１又は複数のＳ－ＮＳＳＡＩ（Sub Network Slice Selection Assist Information）を含むＮＳＳＡＩ（Network Slice Selection Assistance Information）を設定できるようになっている。ここで、Ｓ－ＮＳＳＡＩは、ネットワークスライスに対応付けられる情報である。なお、ＮＦが、ネットワークスライスに所属していなくてもよい。

図５は、本実施形態に係るプラットフォームシステム３０で実装される機能の一例を示す機能ブロック図である。なお、本実施形態に係るプラットフォームシステム３０で、図５に示す機能のすべてが実装される必要はなく、また、図５に示す機能以外の機能が実装されていても構わない。

図５に示すように、本実施形態に係るプラットフォームシステム３０には、機能的には例えば、オペレーションサポートシステム（ＯＳＳ）部６０、オーケストレーション（Ｅ２ＥＯ：End-to-End-Orchestration）部６２、サービスカタログ記憶部６４、ビッグデータプラットフォーム部６６、データバス部６８、ＡＩ（Artificial Intelligence）部７０、監視機能部７２、ＳＤＮコントローラ７４、構成管理部７６、コンテナ管理部７８、リポジトリ部８０、ベアメタル管理部９６、が含まれている。そして、ＯＳＳ部６０には、インベントリデータベース８２、チケット管理部８４、障害管理部８６、性能管理部８８、が含まれている。そして、Ｅ２ＥＯ部６２には、ポリシーマネージャ部９０、スライスマネージャ部９２、ライフサイクル管理部９４、が含まれている。これらの要素は、プロセッサ３０ａ、記憶部３０ｂ、及び、通信部３０ｃを主として実装される。

図５に示す機能は、１又は複数のコンピュータであるプラットフォームシステム３０にインストールされ、当該機能に対応する指令を含むプログラムをプロセッサ３０ａが実行することにより、実装されてもよい。このプログラムは、例えば、光ディスク、磁気ディスク、磁気テープ、光磁気ディスク、フラッシュメモリ等のコンピュータ読み取り可能な情報記憶媒体を介して、あるいは、インターネットなどを介してプラットフォームシステム３０に供給されてもよい。また、図５に示す機能が、回路ブロック、メモリ、その他のＬＳＩで実装されてもよい。また、図５に示す機能が、ハードウェアのみ、ソフトウェアのみ、又はそれらの組合せといった様々な形態で実現できることは、当業者には理解されるところである。

コンテナ管理部７８は、コンテナのライフサイクル管理を実行する。例えば、コンテナのデプロイや設定などといったコンテナの構築に関する処理が当該ライフサイクル管理に含まれる。

ここで、本実施形態に係るプラットフォームシステム３０に、複数のコンテナ管理部７８が含まれていてもよい。そして、複数のコンテナ管理部７８のそれぞれには、クバネテス等のコンテナ管理ツール、及び、ヘルム（Ｈｅｌｍ）等のパッケージマネージャがインストールされていてもよい。そして、複数のコンテナ管理部７８は、それぞれ、当該コンテナ管理部７８に対応付けられるサーバ群（例えばクバネテスクラスタ）に対して、コンテナのデプロイ等のコンテナの構築を実行してもよい。

なお、コンテナ管理部７８は、プラットフォームシステム３０に含まれている必要はない。コンテナ管理部７８は、例えば、当該コンテナ管理部７８によって管理されるサーバ（すなわち、ＲＡＮ３２やコアネットワークシステム３４）に設けられていてもよいし、あるいは、当該コンテナ管理部７８によって管理されるサーバに併設されている他のサーバに設けられていてもよい。

リポジトリ部８０は、本実施形態では例えば、ネットワークサービスを実現する機能ユニット群（例えば、ＮＦ群）に含まれるコンテナのコンテナイメージを記憶する。

インベントリデータベース８２は、インベントリ情報が格納されたデータベースである。当該インベントリ情報には、例えば、ＲＡＮ３２やコアネットワークシステム３４に配置され、プラットフォームシステム３０で管理されているサーバについての情報が含まれる。

また本実施形態では、インベントリデータベース８２には、インベントリデータが記憶されている。インベントリデータには、通信システム１に含まれる要素群の構成や要素間の関連付けの現況が示されている。また、インベントリデータには、プラットフォームシステム３０で管理されているリソースの状況（例えば、リソースの使用状況）が示されている。当該インベントリデータは、物理インベントリデータでもよいし、論理インベントリデータでもよい。物理インベントリデータ及び論理インベントリデータについては後述する。

図６は、物理インベントリデータのデータ構造の一例を示す図である。図６に示す物理インベントリデータは、１つのサーバに対応付けられる。図６に示す物理インベントリデータには、例えば、サーバＩＤ、ロケーションデータ、建物データ、階数データ、ラックデータ、スペックデータ、ネットワークデータ、稼働コンテナＩＤリスト、クラスタＩＤ、などが含まれる。

物理インベントリデータに含まれるサーバＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバの識別子である。

物理インベントリデータに含まれるロケーションデータは、例えば、当該物理インベントリデータに対応付けられるサーバのロケーション（例えばロケーションの住所）を示すデータである。

物理インベントリデータに含まれる建物データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている建物（例えば建物名）を示すデータである。

物理インベントリデータに含まれる階数データは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されている階数を示すデータである。

物理インベントリデータに含まれるラックデータは、例えば、当該物理インベントリデータに対応付けられるサーバが配置されているラックの識別子である。

物理インベントリデータに含まれるスペックデータは、例えば、当該物理インベントリデータに対応付けられるサーバのスペックを示すデータであり、スペックデータには、例えば、コア数、メモリ容量、ハードディスク容量などといったものが示される。

物理インベントリデータに含まれるネットワークデータは、例えば、当該物理インベントリデータに対応付けられるサーバのネットワークに関する情報を示すデータであり、ネットワークデータには、例えば、当該サーバが備えるＮＩＣ、当該ＮＩＣが備えるポートの数、当該ポートのポートＩＤなどが示される。

物理インベントリデータに含まれる稼働コンテナＩＤリストは、例えば、当該物理インベントリデータに対応付けられるサーバで稼働する１又は複数のコンテナに関する情報を示すデータであり、稼働コンテナＩＤリストには、例えば、当該コンテナのインスタンスの識別子（コンテナＩＤ）のリストが示される。

物理インベントリデータに含まれるクラスタＩＤは、例えば、当該物理インベントリデータに対応付けられるサーバが所属するクラスタ（例えば、クバネテスクラスタ）の識別子である。

論理インベントリデータには、通信システム１に含まれる複数の要素についての、図４に示されているような要素間の関連付けの現況を示すトポロジーデータが含まれている。例えば、論理インベントリデータには、あるＮＳの識別子と当該ＮＳの配下にある１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。また、例えば、論理インベントリデータには、あるネットワークスライスの識別子と当該ネットワークスライスに所属する１又は複数のＮＦの識別子とを含むトポロジーデータが含まれる。

また、インベントリデータに、通信システム１に含まれる要素間の地理的な関係やトポロジー的な関係などの現況が示すデータが含まれていてもよい。上述の通り、インベントリデータには、通信システム１に含まれる要素が稼働しているロケーション、すなわち、通信システム１に含まれる要素の現在のロケーションを示すロケーションデータが含まれている。このことから、インベントリデータには、要素間の地理的な関係（例えば、要素間の地理的な近さ）の現況が示されていると言える。

また、論理インベントリデータに、ネットワークスライスに関する情報を示すＮＳＩデータが含まれていてもよい。ＮＳＩデータは、例えば、ネットワークスライスのインスタンスの識別子や、ネットワークスライスの種類等の属性を示す。また、論理インベントリデータに、ネットワークスライスサブネットに関する情報を示すＮＳＳＩデータが含まれていてもよい。ＮＳＳＩデータは、例えば、ネットワークスライスサブネットのインスタンスの識別子や、ネットワークスライスサブネットの種類等の属性を示す。

また、論理インベントリデータに、ＮＳに関する情報を示すＮＳデータが含まれていてもよい。ＮＳデータは、例えば、ＮＳのインスタンスの識別子や、ＮＳの種類等の属性を示す。また、論理インベントリデータに、ＮＦに関する情報を示すＮＦデータが含まれていてもよい。ＮＦデータは、例えば、ＮＦのインスタンスの識別子や、ＮＦの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに関する情報を示すＣＮＦＣデータが含まれていてもよい。ＣＮＦＣデータは、例えば、インスタンスの識別子や、ＣＮＦＣの種類等の属性を示す。また、論理インベントリデータに、ＣＮＦＣに含まれるｐｏｄに関する情報を示すｐｏｄデータが含まれていてもよい。ｐｏｄデータは、例えば、ｐｏｄのインスタンスの識別子や、ｐｏｄの種類等の属性を示す。また、論理インベントリデータに、ｐｏｄに含まれるコンテナに関する情報を示すコンテナデータが含まれていてもよい。コンテナデータは、例えば、コンテナのインスタンスのコンテナＩＤや、コンテナの種類等の属性を示す。

論理インベントリデータに含まれるコンテナデータのコンテナＩＤと、物理インベントリデータに含まれる稼働コンテナＩＤリストに含まれるコンテナＩＤと、によって、コンテナのインスタンスと、当該コンテナのインスタンスが稼働しているサーバとが関連付けられることとなる。

また、ホスト名やＩＰアドレスなどの各種の属性を示すデータが論理インベントリデータに含まれる上述のデータに含まれていても構わない。例えば、コンテナデータに、当該コンテナデータに対応するコンテナのＩＰアドレスを示すデータが含まれていてもよい。また、例えば、ＮＦデータに、当該ＮＦデータが示すＮＦのＩＰアドレス及びホスト名を示すデータが含まれていてもよい。

また、論理インベントリデータに、各ＮＦに設定されている、１又は複数のＳ－ＮＳＳＡＩを含むＮＳＳＡＩを示すデータが含まれていてもよい。

また、インベントリデータベース８２は、コンテナ管理部７８と連携して、リソースの状況を適宜把握できるようになっている。そして、インベントリデータベース８２は、リソースの最新の状況に基づいて、インベントリデータベース８２に記憶されているインベントリデータを適宜更新する。

また、例えば、通信システム１に含まれる新規要素の構築、通信システム１に含まれる要素の構成変更、通信システム１に含まれる要素のスケーリング、通信システム１に含まれる要素のリプレース、などのアクションが実行されることに応じて、インベントリデータベース８２は、インベントリデータベース８２に記憶されているインベントリデータを更新する。

サービスカタログ記憶部６４は、サービスカタログデータを記憶する。サービスカタログデータには、例えば、ライフサイクル管理部９４によって利用されるロジックなどを示すサービステンプレートデータが含まれていてもよい。このサービステンプレートデータには、ネットワークサービスを構築するために必要な情報が含まれる。例えば、サービステンプレートデータは、ＮＳ、ＮＦ及びＣＮＦＣを定義する情報と、ＮＳ－ＮＦ－ＣＮＦＣの対応関係を示す情報を含む。また、例えば、サービステンプレートデータは、ネットワークサービスを構築するためのワークフローのスクリプトを含む。

サービステンプレートデータの一例として、ＮＳＤ（NS Descriptor）が挙げられる。ＮＳＤは、ネットワークサービスに対応付けられるものであり、当該ネットワークサービスに含まれる複数の機能ユニット（例えば複数のＣＮＦ）の種類などが示されている。なお、ＮＳＤに、ＣＮＦ等の機能ユニットの種類ごとについての、当該ネットワークサービスに含まれる数が示されていてもよい。また、ＮＳＤに、当該ネットワークサービスに含まれるＣＮＦに係る、後述するＣＮＦＤのファイル名が示されていてもよい。

また、サービステンプレートデータの一例として、ＣＮＦＤ（CNF Descriptor）が挙げられる。ＣＮＦＤに、当該ＣＮＦが必要とするコンピュータリソース（例えば、ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。例えば、ＣＮＦＤに、当該ＣＮＦに含まれる複数のコンテナのそれぞれについての、当該コンテナが必要とするコンピュータリソース（ＣＰＵ、メモリ、ハードディスクなど）が示されていてもよい。

また、サービスカタログデータに、ポリシーマネージャ部９０によって利用される、算出された性能指標値と比較する閾値（例えば異常検出用閾値）に関する情報が含まれていてもよい。性能指標値については後述する。

また、サービスカタログデータに、例えば、スライステンプレートデータが含まれていてもよい。スライステンプレートデータには、ネットワークスライスのインスタンス化を実行するために必要な情報が含まれ、例えば、スライスマネージャ部９２によって利用されるロジックが含まれる。

スライステンプレートデータは、ＧＳＭＡ（GSM Association）（「GSM」は登録商標）が定める「Generic Network Slice Template」の情報を含む。具体的には、スライステンプレートデータは、ネットワークスライスのテンプレートデータ（ＮＳＴ）、ネットワークスライスサブネットのテンプレートデータ（ＮＳＳＴ）、ネットワークサービスのテンプレートデータを含む。また、スライステンプレートデータは、図４に示したような、これらの要素の階層構成を示す情報を含む。

ライフサイクル管理部９４は、本実施形態では例えば、購入者によるＮＳの購入要求に応じて、購入要求がされた新たなネットワークサービスを構築する。

ライフサイクル管理部９４は、例えば、購入要求に応じて、購入されるネットワークサービスに対応付けられるワークフローのスクリプトを実行してもよい。そして、このワークフローのスクリプトを実行することで、ライフサイクル管理部９４は、コンテナ管理部７８に、購入される新たなネットワークサービスに含まれるコンテナのデプロイを指示してもよい。そして、コンテナ管理部７８は、当該コンテナのコンテナイメージをリポジトリ部８０から取得して、当該コンテナイメージに対応するコンテナを、サーバにデプロイしてもよい。

また、ライフサイクル管理部９４は、本実施形態では例えば、通信システム１に含まれる要素のスケーリングやリプレースを実行する。ここで、ライフサイクル管理部９４は、コンテナのデプロイ指示や削除指示をコンテナ管理部７８に出力してもよい。そして、コンテナ管理部７８が、当該指示に従い、コンテナのデプロイやコンテナの削除等の処理を実行してもよい。本実施形態ではライフサイクル管理部９４によって、コンテナ管理部７８のクバネテスのようなツールでは対応できないようなスケーリングやリプレースを実行できるようになっている。

また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、通信経路の作成指示を出力してもよい。例えば、ライフサイクル管理部９４は、作成させる通信経路の両端の２つのＩＰアドレスをＳＤＮコントローラ７４に提示し、ＳＤＮコントローラ７４は、これら２つのＩＰアドレスを結ぶ通信経路を作成する。作成された通信経路は、これら２つのＩＰアドレスに関連付けられて管理されてもよい。

また、ライフサイクル管理部９４は、ＳＤＮコントローラ７４に、２つのＩＰアドレスに関連付けられた、これら２つのＩＰアドレス間の通信経路の作成指示を出力してもよい。

スライスマネージャ部９２は、本実施形態では例えば、ネットワークスライスのインスタンス化を実行する。スライスマネージャ部９２は、本実施形態では例えば、サービスカタログ記憶部６４に記憶されているスライステンプレートが示すロジックを実行することで、ネットワークスライスのインスタンス化を実行する。

スライスマネージャ部９２は、例えば、３ＧＰＰ（登録商標）（Third Generation Partnership Project）の仕様書「TS28 533」に記載される、ＮＳＭＦ（Network Slice Management Function）と、ＮＳＳＭＦ（Network Slice Sub-network Management Function）の機能を含んで構成される。ＮＳＭＦは、ネットワークスライスを生成して管理する機能であり、ＮＳＩのマネジメントサービスを提供する。ＮＳＳＭＦは、ネットワークスライスの一部を構成するネットワークスライスサブネットを生成し管理する機能であり、ＮＳＳＩのマネジメントサービスを提供する。

ここで、スライスマネージャ部９２が、ネットワークスライスのインスタンス化に関係する構成管理指示を構成管理部７６に出力してもよい。そして、構成管理部７６が、当該構成管理指示に従った設定等の構成管理を実行してもよい。

また、スライスマネージャ部９２は、ＳＤＮコントローラ７４に、２つのＩＰアドレスを提示し、これら２つのＩＰアドレス間の通信経路の作成指示を出力してもよい。

構成管理部７６は、本実施形態では例えば、ライフサイクル管理部９４やスライスマネージャ部９２から受け付ける構成管理指示に従って、ＮＦ等の要素群の設定等の構成管理を実行する。

ＳＤＮコントローラ７４は、本実施形態では例えば、ライフサイクル管理部９４又はスライスマネージャ部９２から受け付ける通信経路の作成指示に従って、当該作成指示に関連付けられている２つのＩＰアドレス間の通信経路を作成する。ＳＤＮコントローラ７４は、例えば、フレックスアルゴ（ＦｌｅｘＡｌｇｏ）などの公知のパス計算手法を用いて、２つのＩＰアドレス間の通信経路を作成してもよい。

ここで例えば、ＳＤＮコントローラ７４は、セグメントルーティング技術（例えばＳＲｖ６（セグメントルーティングＩＰｖ６））を用いて、通信経路間に存在するアグリゲーションルータや、サーバなどに対して、ＮＳＩやＮＳＳＩを構築してもよい。また、ＳＤＮコントローラ７４は、複数の設定対象のＮＦに対して、共通のＶＬＡＮ（Virtual Local Area Network）を設定するコマンド、及び、当該ＶＬＡＮに設定情報が示す帯域幅や優先度を割り当てるコマンドを発行することにより、それら複数の設定対象のＮＦにわたるＮＳＩ及びＮＳＳＩを生成してもよい。

なお、ＳＤＮコントローラ７４は、ネットワークスライスを構築することなく、２つのＩＰアドレス間の通信で利用可能な帯域幅の最大値の変更などを実行してもよい。

本実施形態に係るプラットフォームシステム３０に、複数のＳＤＮコントローラ７４が含まれていてもよい。そして、複数のＳＤＮコントローラ７４は、それぞれ、当該ＳＤＮコントローラ７４に対応付けられるＡＧ等のネットワーク機器群に対して通信経路の作成等の処理を実行してもよい。

監視機能部７２は、本実施形態では例えば、通信システム１に含まれる要素群を、所与の管理ポリシーに従って監視する。ここで、監視機能部７２は、例えば、ネットワークサービスの購入の際に購入者によって指定される監視ポリシーに従って、要素群を監視してもよい。

監視機能部７２は、本実施形態では例えば、スライスのレベル、ＮＳのレベル、ＮＦのレベル、ＣＮＦＣのレベル、サーバ等のハードウェアのレベル、などといった、様々なレベルでの監視を実行する。

監視機能部７２は、例えば、上述の様々なレベルでの監視が行えるよう、メトリックデータを出力するモジュールをサーバ等のハードウェアや通信システム１に含まれるソフトウェア要素に設定してもよい。ここで例えば、ＮＦが、当該ＮＦにおいて測定可能（特定可能）なメトリックを示すメトリックデータを監視機能部７２に出力するようにしてもよい。また、サーバが、当該サーバにおいて測定可能（特定可能）なハードウェアに関するメトリックを示すメトリックデータを監視機能部７２に出力するようにしてもよい。

また、例えば、監視機能部７２は、サーバに、複数のコンテナから出力されたメトリックを示すメトリックデータをＣＮＦＣ（マイクロサービス）単位に集計するサイドカーコンテナをデプロイしてもよい。このサイドカーコンテナは、エクスポーターと呼ばれるエージェントを含んでもよい。監視機能部７２は、クバネテス等のコンテナ管理ツールを監視可能なプロメテウス（Prometheus）などのモニタリングツールの仕組みを利用して、マイクロサービス単位に集計されたメトリックデータをサイドカーコンテナから取得する処理を、所与の監視間隔で繰り返し実行してもよい。

監視機能部７２は、例えば、「TS 28.552, Management and orchestration; 5G performance measurements」又は「TS 28.554, Management and orchestration; 5G end to end Key Performance Indicators (KPI)」に記載された性能指標についての性能指標値を監視してもよい。そして、監視機能部７２は、監視される性能指標値を示すメトリックデータを取得してもよい。

そして、監視機能部７２は、本実施形態では、例えば、所定の集計単位で、メトリックデータを集計する処理（エンリッチメント）を実行することで、当該集計単位における、通信システム１に含まれる要素の性能指標値を示す性能指標値データを生成する。

例えば、１つのｇＮＢについて、当該ｇＮＢの配下にある要素（例えば、ＤＵ４２やＣＵ４４などのネットワークノード）のメトリックを示すメトリックデータを集計することで、当該ｇＮＢの性能指標値データを生成する。このようにして、当該ｇＮＢがカバーするエリアにおける通信性能を示す性能指標値データが生成される。ここで、例えば、各ｇＮＢにおいて、トラフィック量（スループット）やレイテンシなどといった複数種類の通信性能を示す性能指標値データが生成されてもよい。なお、性能指標値データが示す通信性能は、トラフィック量やレイテンシには限定されない。

そして、監視機能部７２は、上述のエンリッチメントによって生成される性能指標値データを、データバス部６８に出力する。

データバス部６８は、本実施形態では例えば、監視機能部７２から出力される性能指標値データを受け付ける。そして、データバス部６８は、受け付ける１又は複数の性能指標値データに基づいて、当該１又は複数の性能指標値データを含む性能指標値ファイルを生成する。そして、データバス部６８は、生成される性能指標値ファイルをビッグデータプラットフォーム部６６に出力する。

また、通信システム１に含まれるネットワークスライス、ＮＳ、ＮＦ、ＣＮＦＣ等の要素や、サーバ等のハードウェアは、監視機能部７２に、各種のアラートの通知（例えば、障害の発生をトリガとしたアラートの通知）を行う。

そして、監視機能部７２は、例えば、上述のアラートの通知を受け付けると、当該通知を示すアラートメッセージデータをデータバス部６８に出力する。そして、データバス部６８は、１又は複数の通知を示すアラートメッセージデータを１つのファイルにまとめたアラートファイルを生成して、当該アラートファイルをビッグデータプラットフォーム部６６に出力する。

ビッグデータプラットフォーム部６６は、本実施形態では例えば、データバス部６８から出力される性能指標値ファイルやアラートファイルを蓄積する。

ＡＩ部７０には、本実施形態では例えば、学習済の機械学習モデルが予め複数記憶されている。ＡＩ部７０は、ＡＩ部７０に記憶されている各種の機械学習モデルを用いて、通信システム１の利用状況やサービス品質の将来予測処理などの推定処理を実行する。ＡＩ部７０は、推定処理の結果を示す推定結果データを生成してもよい。

ＡＩ部７０は、ビッグデータプラットフォーム部６６に蓄積されるファイルと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、長期的なトレンドの予測を低頻度で行う場合に好適である。

また、ＡＩ部７０は、データバス部６８に格納されている性能指標値データを取得可能になっている。ＡＩ部７０は、データバス部６８に格納されている性能指標値データと、上述の機械学習モデルと、に基づいて、推定処理を実行してもよい。この推定処理は、短期的な予測を高頻度で行う場合に好適である。

性能管理部８８は、本実施形態では例えば、複数のメトリックデータに基づいて、これらのメトリックデータが示すメトリックに基づく性能指標値（例えば、ＫＰＩ）を算出する。性能管理部８８は、単一のメトリックデータからは算出できない、複数の種類のメトリックの総合評価である性能指標値（例えば、エンド・ツー・エンドのネットワークスライスに係る性能指標値）を算出してもよい。性能管理部８８は、総合評価である性能指標値を示す総合性能指標値データを生成してもよい。

なお、性能管理部８８は、ビッグデータプラットフォーム部６６から上述の性能指標値ファイルを取得してもよい。また、性能管理部８８は、ＡＩ部７０から推定結果データを取得してもよい。そして、性能指標値ファイル又は推定結果データのうちの少なくとも一方に基づいて、ＫＰＩ等の性能指標値を算出してもよい。なお、性能管理部８８が、監視機能部７２からメトリックデータを直接取得してもよい。そして、当該メトリックデータに基づいて、ＫＰＩ等の性能指標値を算出してもよい。

障害管理部８６は、本実施形態では例えば、上述のメトリックデータ、上述のアラートの通知、上述の推定結果データ、上述の総合性能指標値データのうちの少なくともいずれかに基づいて、通信システム１における障害の発生を検出する。障害管理部８６は、例えば、所定のロジックに基づいて、単一のメトリックデータや単一のアラートの通知からでは検出できないような障害の発生を検出してもよい。障害管理部８６は、検出された障害を示す検出障害データを生成してもよい。

なお、障害管理部８６は、メトリックデータやアラートの通知を、監視機能部７２から直接取得してもよい。また、障害管理部８６は、ビッグデータプラットフォーム部６６から性能指標値ファイルやアラートファイルを取得してもよい。また、障害管理部８６は、データバス部６８から、アラートメッセージデータを取得してもよい。

ポリシーマネージャ部９０は、本実施形態では例えば、上述のメトリックデータ、上述の性能指標値データ、上述のアラートメッセージデータ、上述の性能指標値ファイル、上述のアラートファイル、上述の推定結果データ、上述の総合性能指標値データ、上述の検出障害データ、のうちの少なくともいずれかに基づいて、所定の判定処理を実行する。

そして、ポリシーマネージャ部９０は、判定処理の結果に応じたアクションを実行してもよい。例えば、ポリシーマネージャ部９０は、スライスマネージャ部９２にネットワークスライスの構築指示を出力してもよい。また、ポリシーマネージャ部９０は、判定処理の結果に応じて、要素のスケーリングやリプレースの指示をライフサイクル管理部９４に出力してもよい。

本実施形態に係るポリシーマネージャ部９０は、データバス部６８に格納されている性能指標値データを取得可能になっている。そして、ポリシーマネージャ部９０は、データバス部６８から取得される性能指標値データに基づいて、所定の判定処理を実行してもよい。また、ポリシーマネージャ部９０は、データバス部６８に格納されているアラートメッセージデータに基づいて、所定の判定処理を実行してもよい。

チケット管理部８４は、本実施形態では例えば、通信システム１の管理者に通知すべき内容が示されたチケットを生成する。チケット管理部８４は、発生障害データの内容を示すチケットを生成してもよい。また、チケット管理部８４は、性能指標値データやメトリックデータの値を示すチケットを生成してもよい。また、チケット管理部８４は、ポリシーマネージャ部９０による判定結果を示すチケットを生成してもよい。

そして、チケット管理部８４は、生成されたチケットを、通信システム１の管理者に通知する。チケット管理部８４は、例えば、生成されたチケットが添付された電子メールを、通信システム１の管理者の電子メールアドレスに宛てて送信してもよい。

ベアメタル管理部９６は、本実施形態では例えば、ＢＩＯＳ（Basic Input Output System）の設定、シングルルートＩ／Ｏ仮想化（ＳＲ－ＩＯＶ）の設定、システムソフトウェアのインストールや入替、などのセットアップを実行する。

また、本実施形態において、構成管理部７６が、ハードウェアリソースに対して、クラスタＩＤ、ＩＰアドレス、ホスト名、又は、ラベルの設定などといった、ハードウェア若しくはソフトウェアの設定（コンフィギュレーション）を実行してもよい。

また、ベアメタル管理部９６が、所定の種類のアプリケーションに応じたセットアップを、ハードウェアリソースに対して実行してもよい。

例えば、構成管理部７６又はベアメタル管理部９６に所定の種類のアプリケーションについてのセットアップを行うためのスクリプト（例えば、Ａｎｓｉｂｌｅスクリプト）が記憶されていてもよい。当該スクリプトには、例えば、特定種類あるいは特定バージョンである、コンテナ実行環境の基盤であるホストＯＳのインストール手順が記述されていてもよい。また、当該スクリプトには、例えば、ホストＯＳのカーネルの設定手順、ＢＩＯＳの設定手順、ＳＲ－ＩＯＶの設定手順などが記述されていてもよい。

そして、ベアメタル管理部９６が、当該スクリプトを実行することにより、ハードウェアリソースで稼働するアプリケーションの種類に応じたセットアップを、当該ハードウェアリソースに対して実行してもよい。例えば、ベアメタル管理部９６が、コンテナ実行環境のホストＯＳやＢＩＯＳのセットアップを、ハードウェアリソースに対して実行してもよい。

また、ベアメタル管理部９６は、ハードウェアリソースにインストールされているＯＳ等のシステムソフトウェアの入替を実行してもよい。すなわち、ベアメタル管理部９６は、ハードウェアリソースにインストールされているシステムソフトウェアのアンインストール、及び、当該ハードウェアリソースに対する別のシステムソフトウェアのインストールを実行してもよい。

以下、本実施形態に係る通信システム１に含まれるハードウェアリソースの管理について、さらに説明する。

図７は、本実施形態に係る通信システム１に含まれるハードウェアリソースの割り当ての一例を模式的に示す図である。

ここでは例えば、２人の購入者（購入者Ａ、及び、購入者Ｂ）がネットワークサービスを購入したとする。そして、図７には、購入者Ａが購入したネットワークサービスに含まれるＵＰＦ５０が稼働する第１ハードウェアリソース群１００ａ、及び、第２ハードウェアリソース群１００ｂが示されている。このように、本実施形態において、１人の購入者によって購入されたネットワークサービスに含まれる１種類のＮＦが複数のハードウェアリソース群１００に配置されても構わない。ここで、ハードウェアリソース群１００には、サーバ群が含まれていてもよい。

また、図７には、購入者Ａが購入したネットワークサービスに含まれるＡＭＦ４６が稼働する第３ハードウェアリソース群１００ｃが示されている。

また、図７には、購入者Ｂが購入したネットワークサービスに含まれるＵＰＦ５０が稼働する第４ハードウェアリソース群１００ｄ、及び、購入者Ｂが購入したネットワークサービスに含まれるＡＭＦ４６が稼働する第５ハードウェアリソース群１００ｅが示されている。

なお、購入者Ａ、又は、購入者Ｂが購入したネットワークサービスには、図７に示されていないＮＦ（例えば、ＤＵ４２、ＣＵ４４、ＳＭＦ４８等）も含まれているが、これらのＮＦについては省略されている。

図７に示すように、本実施形態に係る通信システム１に含まれるハードウェアリソースは、複数のハードウェアリソース群１００に分けて管理されている。例えば、通信システム１に含まれる複数のサーバが、複数のサーバ群に分けて管理されている。

また、図７に示すように、複数のハードウェアリソース群１００のそれぞれは、当該ハードウェアリソース群１００で稼働するアプリケーションの種類が予め定められていてもよい。図７の例では、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第４ハードウェアリソース群１００ｄでは、ＵＰＦ５０が稼働することが予め定められている。また、第３ハードウェアリソース群１００ｃ、及び、第５ハードウェアリソース群１００ｅでは、ＡＭＦ４６が稼働することが予め定められている。

また、図７に示すように、複数のハードウェアリソース群１００のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別のハードウェアリソース群１００で稼働していてもよい。図７の例では、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第３ハードウェアリソース群１００ｃで、購入者Ａによって購入されたアプリケーションが稼働する。そして、第４ハードウェアリソース群１００ｄ、及び、第５ハードウェアリソース群１００ｅで、購入者Ｂによって購入されたアプリケーションが稼働する。

なお、上述のハードウェアリソースは、サーバには限定されない。また、図７に示されているハードウェアリソースの所在は特に問わない。以下の説明では、図７に示されているハードウェアリソースは、セントラルデータセンタ１０に配置されているものであることとするが、当該ハードウェアリソースが、リージョナルデータセンタ１２やエッジデータセンタ１４に配置されていてもよい。

そして、以下の説明では、１つのハードウェアリソース群１００（例えばサーバ群）は、コンテナ管理ツールによって管理される１つのクラスタ（例えば、１つのクバネテスクラスタ）に相当することとする。なお、１つのハードウェアリソース群１００が、コンテナ管理ツールによって管理される１つのクラスタに相当する必要はない。例えば、コンテナ管理ツールによって管理される１つのクラスタに複数のハードウェアリソース群１００が含まれていてもよい。この場合に、例えば、１つのハードウェアリソース群１００が、１つの名前空間（ネームスペース）に相当するものであってもよい。

本実施形態では例えば、監視機能部７２が、通信システム１に含まれる複数のハードウェアリソース群１００のそれぞれの使用状況を監視する。ここで例えば、監視機能部７２が、通信システム１に含まれる複数のサーバ群のそれぞれの使用状況を監視してもよい。

ここでハードウェアリソース群１００の使用状況とは、例えば、ＣＰＵ使用率、メモリ使用量、ストレージ使用量、ネットワーク使用量等を指す。また、ハードウェアリソース群について監視されるこれらの指標のうちの一部又は全部に基づいて算出される総合評価値が、当該ハードウェアリソース群１００の使用状況を示す値として監視されてもよい。

そして、本実施形態では例えば、上述のように、トラフィック量やレイテンシ等の性能指標値に基づいて、ＮＦ等のアプリケーションのスケーリング（スケールアウトやスケールイン）が実行される。そのためスケーリングに伴い、１つのハードウェアリソース群１００で稼働しているアプリケーションの数は適宜変動する。

また、本実施形態では例えば、１つのハードウェアリソース群１００で稼働しているアプリケーションの数に基づいて、当該ハードウェアリソース群１００における、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量が特定可能になっている。例えば、アプリケーションの種類ごとの、当該アプリケーション１つあたりの最大ハードウェアリソース量を示すデータが構成管理部７６に記憶されていてもよい。そして、構成管理部７６が、当該データに基づいて、複数のハードウェアリソース群１００（例えば、複数のサーバ群）のそれぞれについて、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量を特定してもよい。このように、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量が、ハードウェアリソース群１００で稼働しているアプリケーションの数に比例してもよい。

図７では、それぞれのハードウェアリソース群１００に割り当てられているハードウェアリソース量が模式的に示されている。また、図７には、ハードウェアリソース群１００に割り当てられているハードウェアリソース量のそれぞれ一部である、実際使用リソース量１０２、想定最大使用リソース量１０４、及び、スタンバイリソース量１０６が示されている。

ここで、実際使用リソース量１０２は、ハードウェアリソース群１００で稼働しているアプリケーションによって実際に使用されているハードウェアリソース量に相当する。

また、想定最大使用リソース量１０４は、上述した、アプリケーションの稼働のための使用が想定される最大ハードウェアリソース量に相当する。本実施形態では、ハードウェアリソース群１００で稼働しているアプリケーションの数が変化していない状況でも、ハードウェアリソースの実際の使用量は適宜変動する。そのため、図７に示すように、実際使用リソース量１０２は、想定最大使用リソース量１０４よりも少ない。

また、スタンバイリソース量１０６は、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から想定最大使用リソース量１０４を引いたハードウェアリソース量に相当する。

本実施形態では、ハードウェアリソース群１００で稼働しているアプリケーションのスケールアウトが実行されると、想定最大使用リソース量１０４が増加し、想定最大使用リソース量１０４の増加量だけスタンバイリソース量１０６が減少することとなる。

ハードウェアリソース群１００に割り当てられているハードウェアリソース量（すなわち、想定最大使用リソース量１０４とスタンバイリソース量１０６の合計）は、例えば、購入者がネットワークサービスの購入時に指定することができてもよい。例えば、購入者によるネットワークサービスの購入額が高額になるほど、より多くのハードウェアリソースがハードウェアリソース群１００に割り当てられるようにしてもよい。また、本実施形態において、購入者が、ハードウェアリソース群１００に割り当てられているハードウェアリソースを適宜追加したり削除したりできてもよい。

また、本実施形態に係る通信システム１では、いずれの上述のハードウェアリソース群１００とも異なる共通予備リソース群１０８（例えば、共通サーバ群）が管理されている。すなわち、本実施形態では、上述の複数のハードウェアリソース群１００（例えば、第１ハードウェアリソース群１００ａから第５ハードウェアリソース群１００ｅ）とは別のハードウェアリソース群が、共通予備リソース群１０８として管理されている。

図７に示すように、共通予備リソース群１０８には、複数の予備リソース１１０（１１０ａ，１１０ｂ，１１０ｃ，・・・）が含まれている。１つの予備リソース１１０は、例えば、１又は複数のサーバに相当する。

また、図７に示すように、共通予備リソース群１０８には、汎用予備リソース群１１２と、１又は複数の特殊予備リソース群（図７の例ではＵＰＦ用予備リソース群１１４）と、が含まれる。すなわち、汎用予備リソース群１１２は、共通予備リソース群１０８の一部である。また、特殊予備リソース群は、共通予備リソース群１０８の一部である。

本実施形態に係る特殊予備リソース群は、アプリケーションの種類に対応付けられる。例えば、ＵＰＦ用予備リソース群１１４は、ＵＰＦ５０に対応付けられる。

そして、特殊予備リソース群に含まれているハードウェアリソースは、当該特殊予備リソース群に対応付けられるアプリケーションの種類に応じたセットアップが実行されたハードウェアリソースである。例えば、ＵＰＦ用予備リソース群１１４に含まれているハードウェアリソースは、ＵＰＦ５０に応じたセットアップが実行されたハードウェアリソースである。

アプリケーションの種類によっては、汎用的なハードウェアリソース（例えば、汎用サーバ）では当該アプリケーションを稼働させることができず、当該種類に応じたセットアップを実行する必要があるものがある。特殊予備リソース群に含まれているハードウェアリソースは、そのようなセットアップがされたものであると言える。

一方、汎用予備リソース群１１２に含まれているハードウェアリソースは、特殊予備リソース群に対応付けられる種類のアプリケーションとは異なるアプリケーションを稼働させるためには、当該アプリケーションの種類に応じたセットアップを追加で実行する必要がないハードウェアリソースである。汎用予備リソース群１１２に含まれるハードウェアリソースは、例えば、汎用的なサーバである。

そして、本実施形態では例えば、図７に示すように、初期状態では、汎用予備リソース群１１２には予備リソース１１０が含まれているが、ＵＰＦ用予備リソース群１１４には予備リソース１１０が含まれておらず、空であることとする。

そして、構成管理部７６が、本実施形態では例えば、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる第１の条件（以下、リソース追加条件と呼ぶ。）を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更する。このようにして、当該ハードウェアリソース群１００にハードウェアリソースが追加され、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量は増加する。

ここで、構成管理部７６が、いずれかのサーバ群の使用状況が当該サーバ群に対応付けられる条件を満たしたことに応じて、いずれのサーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を共通予備サーバ群から当該サーバ群に変更してもよい。

ここで、構成管理部７６は、リソース追加条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が所定の種類であるか否かを判定してもよい。例えば、構成管理部７６が、リソース追加条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が、特殊予備リソース群に対応付けられる種類（例えば、ＵＰＦ５０）であるか否かを判定してもよい。

そして、リソース追加条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が所定の種類である場合は、構成管理部７６は、当該種類に対応付けられる特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たすか否かを判定する。

ここで、ハードウェアリソースの余裕度は、例えば、特殊予備リソース群に含まれるハードウェアリソース量、あるいは、特殊予備リソース群にハードウェアリソースが含まれているか否か、などに相当する。そして、余裕条件は、例えば、特殊予備リソース群に含まれるハードウェアリソース量が所定量以上である、あるいは、特殊予備リソース群に含まれるハードウェアリソースが存在する、などの条件に相当する。

そして、余裕条件を満たす場合は、構成管理部７６は、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群１００に変更してもよい。

一方、余裕条件を満たさない場合は、ベアメタル管理部９６が、汎用予備リソース群１１２に含まれるハードウェアリソースに対して当該アプリケーションの種類に応じたセットアップを実行してもよい。そして、構成管理部７６が、当該セットアップが実行されたハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

上記の場合において、ベアメタル管理部９６は、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソース（例えば、上述の選択ハードウェアリソース）に対して、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に応じたセットアップを実行してもよい。

例えば、ＵＰＦ用予備リソース群１１４に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、ＵＰＦ５０が稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、構成管理部７６は、ＵＰＦ用予備リソース群１１４に含まれるハードウェアリソースの所属をＵＰＦ用予備リソース群１１４から当該ハードウェアリソース群１００に変更してもよい。

また、例えば、ＵＰＦ用予備リソース群１１４に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たさない場合に、ＵＰＦ５０が稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、ベアメタル管理部９６が、汎用予備リソース群１１２に含まれるハードウェアリソースに対してＵＰＦ５０に応じたセットアップを実行してもよい。そして、構成管理部７６が、当該セットアップが実行されたハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

一方、リソース追加条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が上述の所定の種類以外の種類である場合は、構成管理部７６は、汎用予備リソース群１１２に含まれるハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

例えば、ＡＭＦ４６が稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、構成管理部７６は、汎用予備リソース群１１２に含まれるハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

また、構成管理部７６が、本実施形態では例えば、いずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる第２の条件（以下、リソース削除条件と呼ぶ。）を満たしたことに応じて、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００から共通予備リソース群１０８に変更する。このようにして、当該ハードウェアリソース群１００からハードウェアリソースが削除され、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量は減少する。

なお、本実施形態において、ハードウェアリソース群１００に割り当てられているハードウェアリソースに予備リソース１１０が含まれていない場合は、当該ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース削除条件を満たしても、当該ハードウェアリソース群１００からハードウェアリソースが削除されないようにしてもよい。

本実施形態では例えば、構成管理部７６が、クラスタＩＤ、ＩＰアドレス、ホスト名、又は、ラベルの設定を実行することで、ハードウェアリソースの所属を変更する。

ここで、構成管理部７６は、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる予備リソース群を特定してもよい。そして、構成管理部７６は、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を、当該ハードウェアリソース群１００から、特定される予備リソース群に変更してもよい。

例えば、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が上述の所定の種類である場合は、構成管理部７６は、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００から当該種類に対応付けられる特殊予備リソース群に変更してもよい。

例えば、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類がＵＰＦ５０である場合は、構成管理部７６は、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００からＵＰＦ用予備リソース群１１４に変更してもよい。

また、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が上述の所定の種類以外の種類である場合は、構成管理部７６は、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００から汎用予備リソース群１１２に変更してもよい。

例えば、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類がＡＭＦ４６である場合は、構成管理部７６は、当該ハードウェアリソース群１００の一部であるハードウェアリソースの所属を当該ハードウェアリソース群１００から汎用予備リソース群１１２に変更してもよい。

例えば、図８に示すように、第１ハードウェアリソース群１００ａに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ１を超えたとする。

ここで、第１ハードウェアリソース群１００ａで稼働しているアプリケーションの種類は、ＵＰＦ５０である。

そのため、構成管理部７６は、ＵＰＦ用予備リソース群１１４に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たすか否かを判定する。

ここで、例えば、余裕条件が、特殊予備リソース群に含まれるハードウェアリソースが存在する、との条件であるとする。この場合、ＵＰＦ用予備リソース群１１４は空であるので、余裕条件を満たさないこととなる。

そのため、ベアメタル管理部９６が、例えば、汎用予備リソース群１１２のうちから選択される１つの予備リソース１１０（以下、選択ハードウェアリソースと呼ぶ。）に対してＵＰＦ５０に応じたセットアップを実行する。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。そして、構成管理部７６が、例えば、当該セットアップが実行された選択ハードウェアリソースの所属を汎用予備リソース群１１２から第１ハードウェアリソース群１００ａに変更する。

そして、図９に示すように、第１ハードウェアリソース群１００ａに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ２を下回ったとする。ここで、ｐ２の値は、ｐ１よりも小さな値であってもよい。

そのため、構成管理部７６は、例えば、上述の選択ハードウェアリソースの所属を第１ハードウェアリソース群１００ａからＵＰＦ用予備リソース群１１４に変更する。

そして、その後、図１０に示すように、第４ハードウェアリソース群１００ｄに割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合が所定割合ｐ３を超えたとする。ここで、ｐ３の値は、ｐ１の値と、同じであってもよいし、異なっていてもよい。

ここで、第４ハードウェアリソース群１００ｄで稼働しているアプリケーションの種類は、ＵＰＦ５０である。

図９に示す状況では、ＵＰＦ用予備リソース群１１４は空ではないので、余裕条件を満たすこととなる。

そのため、ベアメタル管理部９６が、例えば、ＵＰＦ用予備リソース群１１４のうちから選択される１つの予備リソース１１０（上述の選択ハードウェアリソースであってもよい。）の所属をＵＰＦ用予備リソース群１１４から第４ハードウェアリソース群１００ｄに変更する。

このように、構成管理部７６は、第１ハードウェアリソース群１００ａから共通予備リソース群１０８に所属が変更されたハードウェアリソースの所属を、第４ハードウェアリソース群１００ｄの使用状況が第４ハードウェアリソース群１００ｄに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８から第４ハードウェアリソース群１００ｄに変更してもよい。

このようにすれば、あるハードウェアリソース群１００で使用された予備リソース１１０が、他のハードウェアリソース群１００で使用されることとなる。

また、上述のように、構成管理部７６は、第１ハードウェアリソース群１００ａの使用状況が第１ハードウェアリソース群１００ａに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８のうちから選択される選択ハードウェアリソースの所属を共通予備リソース群１０８から第１ハードウェアリソース群１００ａに変更してもよい。

そして、構成管理部７６は、第１ハードウェアリソース群１００ａの使用状況が第１ハードウェアリソース群１００ａに対応付けられるリソース削除条件を満たしたことに応じて、当該選択ハードウェアリソースの所属を第１ハードウェアリソース群１００ａから共通予備リソース群１０８に変更してもよい。

そして、構成管理部７６は、第１ハードウェアリソース群１００ａから共通予備リソース群１０８に所属が変更された当該選択ハードウェアリソースの所属を、第４ハードウェアリソース群１００ｄの使用状況が第４ハードウェアリソース群１００ｄに対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８から第４ハードウェアリソース群１００ｄに変更してもよい。

このようにすれば、特定の予備リソース１１０（選択ハードウェアリソース）が、複数のハードウェアリソース群１００において転々と使用されることとなる。

また、リソース追加条件やリソース削除条件は、ハードウェアリソースの実際の使用量、又は、ハードウェアリソースの実際の使用率に係る条件であってもよい。例えば、リソース追加条件やリソース削除条件が、実際使用リソース量１０２に係る閾値であってもよい。

また、リソース追加条件やリソース削除条件は、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件であってもよい。ここで、ハードウェアリソースの実際の余裕量とは、例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いたハードウェアリソース量に相当する。また、ハードウェアリソースの実際の余裕率は、例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量に対する、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いたハードウェアリソース量の割合に相当する。なお、余裕量及び余裕率の算出にあたり、重みづけを行ってもよいし、算出された値にさらに重みをかけるなどの追加の計算を行ってもよい。また、例えば、リソース追加条件やリソース削除条件が、ハードウェアリソース群１００に割り当てられているハードウェアリソース量から実際使用リソース量１０２を引いた値に係る条件であってもよい。

また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、ハードウェアリソース群１００でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件であってもよい。すなわち、リソース追加条件やリソース削除条件が、想定最大使用リソース量１０４に係る条件であってもよい。例えば、想定最大使用リソース量１０４が所定の閾値を超えたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。

また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００で稼働しているアプリケーションの数に対応付けられる条件であってもよい。例えば、スケールアウトによって、ハードウェアリソース群１００で稼働しているアプリケーションの数が３になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。また、スケールインによって、ハードウェアリソース群１００で稼働しているアプリケーションの数が１になったことに応じて、当該ハードウェアリソース群１００に含まれるハードウェアリソースの所属が当該ハードウェアリソース群１００から共通予備リソース群１０８に変更されてもよい。

通信システム１に含まれるハードウェアリソースを複数のハードウェアリソース群１００に分けて管理する場合に、アプリケーションのスケールアウトが実行されることを見越して、複数のハードウェアリソース群１００のそれぞれで多くのハードウェアリソースを予め確保してしまうと、ハードウェアリソースの無駄が発生してしまう。

本実施形態では、以上で説明したように、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられる条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更される。

このようにして、本実施形態によれば、通信システム１に含まれるハードウェアリソースを効率的に使用できることとなる。

また、スケールアウトに伴いハードウェアリソース群１００に既に割り当てられているハードウェアリソースにアプリケーションをデプロイするのに要する時間よりも、スケールアウトに伴い予備リソース１１０の所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更した上で、当該予備リソース１１０にアプリケーションをデプロイするのに要する時間の方が長い。そのため、スケールアウトがスムーズに行われるようにするためには、ハードウェアリソース群１００にできるだけ多くのハードウェアリソースが常時確保されていることが望ましい。

しかし、ハードウェアリソース群１００に割り当てられているハードウェアリソース量が多いほど購入者が支払う費用が多くなるような状況においては、ハードウェアリソース群１００に常時確保されるハードウェアリソース量はできるだけ少ない方が望ましい。

一方で、不測の事態により負荷が突発的に高くなった場合や、多くの人が集まるイベントが開催されることが予定されている場合に、ハードウェアリソース群１００に確保されているハードウェアリソースだけでは充分なサービスが提供できないことがある。

本実施形態では、以上で説明したように、ハードウェアリソース群１００への予備リソース１１０の一時的な追加により、当該ハードウェアリソース群１００に確保されるハードウェアリソースを柔軟に調整することができるので、上述の場合などにおいても充分なサービスを提供できることとなる。

なお、ハードウェアリソース群１００がコンテナ管理ツールによって管理されるクラスタに相当する場合、本実施形態によれば、コンテナ管理ツールでは行えないような、クラスタをまたぐような予備リソース１１０の所属の変更が可能となる。

また、本実施形態では、上述のように、特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、当該特殊予備リソース群に対応付けられる種類のアプリケーションが稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、構成管理部７６が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群１００に変更してもよい。

そして、特殊予備リソース群に含まれているハードウェアリソースの余裕度が上述の余裕条件を満たさない場合に、当該特殊予備リソース群に対応付けられる種類のアプリケーションが稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、ベアメタル管理部９６が、汎用予備リソース群１１２に含まれるハードウェアリソースに対して当該種類に応じたセットアップを実行し、構成管理部７６が、当該セットアップが実行されたハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

このようにすることで、上述の所定の種類のアプリケーションが稼働しているハードウェアリソース群１００の使用状況がリソース追加条件を満たした場合に、当該種類に応じたセットアップが実行されたハードウェアリソースに余裕があれば、当該セットアップが実行されていないハードウェアリソースに対して当該セットアップを実行することなく、当該ハードウェアリソース群１００に予備リソース１１０をスムーズに追加することが可能となる。

また、初期状態において、上述の所定のアプリケーションの種類に応じたセットアップを予備リソース１１０に対して事前に実行していなくても、当該種類のアプリ―ションが稼働するハードウェアリソース群１００に予備リソース１１０を追加することが可能となる。

また、上述のように、構成管理部７６は、特殊予備リソース群に含まれているハードウェアリソースの余裕度が余裕条件を満たさない場合に、当該特殊予備リソース群に対応付けられる種類のアプリケーションが稼働するいずれかのハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、ベアメタル管理部９６が、汎用予備リソース群１１２のうちから選択される選択ハードウェアリソースに対して当該種類に応じたセットアップを実行し、構成管理部７６が、当該セットアップが実行された選択ハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更してもよい。

そして、構成管理部７６が、当該ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース削除条件を満たしたことに応じて、上述のセットアップが実行された選択ハードウェアリソースの所属を当該ハードウェアリソース群１００から当該特殊サブ予備リソース群に変更してもよい。

このように、汎用予備リソース群１１２から当該ハードウェアリソース群１００に所属が変更された、上述のセットアップが実行されたハードウェアリソースを、当該セットアップの実行前の状態に戻すことなく、当該ハードウェアリソースの所属を、汎用予備リソース群１１２ではなく、特殊予備リソース群に変更するようにすることで、ストレージの読み書き回数を抑制できるなどの理由で、ハードウェアリソースの耐久性を向上させることが可能となる。

また、本発明は、コアネットワークシステム３４に含まれる他のアプリケーション（ＳＭＦ４８等）が稼働するハードウェアリソース群１００についても適用可能である。

また、本発明は、ＲＡＮ３２に含まれるアプリケーション（ＤＵ４２、ＣＵ－ＣＰ４４ａ、ＣＵ－ＵＰ４４ｂ等）が稼働するハードウェアリソース群１００にも適用可能である。

また、リソース追加条件やリソース削除条件は、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる条件であってもよい。例えば、リソース追加条件が、ハードウェアリソース群１００に割り当てられているハードウェアリソース量に対する実際使用リソース量１０２の割合に係る閾値である場合に、スケールアウトにより増加する想定最大使用リソース量１０４が多いアプリケーションであるほど、当該閾値が小さくなるようにリソース追加条件が設定されてもよい。

そして、構成管理部７６は、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属を共通予備リソース群１０８から当該ハードウェアリソース群１００に変更してもよい。

また、構成管理部７６は、ハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられるリソース削除条件を満たしたことに応じて、当該ハードウェアリソース群１００に含まれるハードウェアリソースの所属を当該ハードウェアリソース群１００から共通予備リソース群１０８に変更してもよい。

例えば、ＵＰＦ５０が稼働している、第１ハードウェアリソース群１００ａ、第２ハードウェアリソース群１００ｂ、及び、第４ハードウェアリソース群１００ｄについては、リソース追加条件、又は、リソース削除条件のうちの少なくとも一方が同じであってもよい。そして、ＡＭＦ４６が稼働している、第３ハードウェアリソース群１００ｃ、及び、第５ハードウェアリソース群１００ｅについては、リソース追加条件、又は、リソース削除条件のうちの少なくとも一方が同じであってもよい。

このようにリソース追加条件やリソース削除条件をアプリケーションの種類に対応付けられるものとすることで、複数のアプリケーションの種類のそれぞれについて、当該種類に適したタイミングでのハードウェアリソースの追加や削除を行うことが可能となる。

また、アプリケーションの購入者が、リソース追加条件やリソース削除条件を、設定できるようにしてもよい。

また例えば、リソース追加条件やリソース削除条件が、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件であってもよい。このようにすれば、アプリケーションの購入者が、リソース追加条件やリソース削除条件を設定できるようにしつつ、その設定について、アプリケーションの種類に対応付けられる制限を設けることが可能となる。

また、本実施形態において、共通予備リソース群１０８からハードウェアリソース群１００に所属が変更される予備リソース１１０のハードウェアリソース量が、当該ハードウェアリソース群１００に割り当てられているハードウェアリソース量に応じたものになっていてもよい。例えば、ハードウェアリソース群１００に割り当てられているハードウェアリソース量が多いほど、多くの予備リソース１１０の所属が変更されるようにしてもよい。

また、ハードウェアリソース群１００に対して、予備リソース１１０の追加（共通予備リソース群１０８から当該ハードウェアリソース群１００への所属の変更）が複数回実行されてもよい。すなわち、ハードウェアリソース群１００に１つの予備リソース１１０が追加された後で、さらに、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたことに応じて、当該ハードウェアリソース群１００にさらに１つの予備リソース１１０が追加されるようにしてもよい。この場合、リソース追加条件は、ハードウェアリソース群１００に追加された予備リソース１１０の数に応じた条件であってもよい。

また、本実施形態において、共通予備リソース群１０８は、複数の特殊予備リソース群を含んでいてもよい。そして、これら複数の特殊予備リソース群のそれぞれは、アプリケーションの種類に対応付けられていてもよい。そして、これら複数の特殊予備リソース群のそれぞれは、含まれているハードウェアリソースが、当該特殊予備リソース群に対応付けられるアプリケーションの種類に応じたセットアップが実行されたハードウェアリソースであってもよい。

そして、いずれかの特殊予備リソース群に含まれているハードウェアリソースの余裕度が当該特殊予備リソース群に対応付けられる余裕条件を満たす場合に、当該特殊予備リソース群に対応付けられるアプリケーションが稼働しているハードウェアリソース群１００の使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、構成管理部７６が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群１００に変更してもよい。

以下、共通予備リソース群１０８に複数の特殊予備リソース群が含まれる状況について、図１１から図１７を参照しながら説明する。

以下の説明では、図１１に示すように、第６ハードウェアリソース群１００ｆで、購入者Ｃが購入したＵＰＦ５０が稼働し、第７ハードウェアリソース群１００ｇで、購入者Ｃが購入したＡＭＦ４６が稼働し、第８ハードウェアリソース群１００ｈで、購入者Ｃが購入したＤＵ４２が稼働していることとする。

なお、購入者Ｃが購入したネットワークサービスには、図１１に示されていないＮＦ（例えば、ＣＵ４４、ＳＭＦ４８等）も含まれているが、これらのＮＦについては省略されている。

そして、共通予備リソース群１０８には、汎用予備リソース群１１２と、２つの特殊予備リソース群（ＵＰＦ用予備リソース群１１４、及び、ＤＵ用予備リソース群１１６）が含まれていることとする。

ＵＰＦ用予備リソース群１１４に含まれているハードウェアリソースは、ＵＰＦ５０に応じたセットアップが実行されたハードウェアリソースであることとする。

また、ＤＵ用予備リソース群１１６に含まれているハードウェアリソースは、ＤＵ４２に応じたセットアップが実行されたハードウェアリソースであることとする。

また、上述のように、汎用予備リソース群１１２に含まれているハードウェアリソースは、特殊予備リソース群に対応付けられる種類のアプリケーションとは異なるアプリケーションを稼働させるためには、当該アプリケーションの種類に応じたセットアップを追加で実行する必要がないハードウェアリソースであることとする。汎用予備リソース群１１２に含まれるハードウェアリソースは、例えば、汎用的なサーバである。

そして、図１１に示すように、初期状態では、汎用予備リソース群１１２には予備リソース１１０（１１０ａ，１１０ｂ，１１０ｃ，・・・）が含まれているが、ＵＰＦ用予備リソース群１１４、及び、ＤＵ用予備リソース群１１６には予備リソース１１０が含まれておらず、空であることとする。

図１１に示す状況において、例えば、図１２に示すように、ＡＭＦ４６が稼働している、第７ハードウェアリソース群１００ｇの使用状況が、リソース追加条件を満たしたとする。

この場合は、汎用予備リソース群１１２のうちから選択される予備リソース１１０である選択ハードウェアリソースに対して特段のセットアップが実行されることなく、構成管理部７６は、当該選択ハードウェアリソースの所属を共通予備リソース群１０８から第７ハードウェアリソース群１００ｇに変更してもよい。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。

そして、例えば、図１２に示す状況において、例えば、図１３に示すように、ＡＭＦ４６が稼働している第７ハードウェアリソース群１００ｇの使用状況が、リソース削除条件を満たしたとする。

この場合、構成管理部７６が、選択ハードウェアリソースの所属を第７ハードウェアリソース群１００ｇから汎用予備リソース群１１２に変更してもよい。

また、図１１に示す状況において、例えば、図１４に示すように、ＵＰＦ５０が稼働している、第６ハードウェアリソース群１００ｆの使用状況が、リソース追加条件を満たしたとする。

この場合、ベアメタル管理部９６が、汎用予備リソース群１１２から第６ハードウェアリソース群１００ｆに所属が変更される予備リソース１１０である選択ハードウェアリソースに対して、ＵＰＦ５０に応じたセットアップを実行してもよい。ここでは例えば、予備リソース１１０ａが選択ハードウェアリソースに相当する。そして、構成管理部７６が、当該セットアップが実行された選択ハードウェアリソースの所属を共通予備リソース群１０８から第６ハードウェアリソース群１００ｆに変更してもよい。

また、上記の場合において、ベアメタル管理部９６は、第６ハードウェアリソース群１００ｆの使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、共通予備リソース群１０８に含まれるハードウェアリソース（例えば、上述の選択ハードウェアリソース）に対して、第６ハードウェアリソース群１００ｆで稼働しているアプリケーションの種類に応じたセットアップを実行してもよい。

そして、例えば、図１４に示す状況において、例えば、図１５に示すように、ＵＰＦ５０が稼働している第６ハードウェアリソース群１００ｆの使用状況が、リソース削除条件を満たしたとする。

この場合、構成管理部７６が、選択ハードウェアリソースの所属を第６ハードウェアリソース群１００ｆからＵＰＦ用予備リソース群１１４に変更してもよい。当該選択ハードウェアリソースは、その後、ＵＰＦ５０が稼働しているハードウェアリソース群１００の使用状況がリソース追加条件を満たした場合に、当該ハードウェアリソース群１００に所属が変更されてもよい。

そして、図１５に示す状況において、その後、例えば、図１６に示すように、ＤＵ４２が稼働している第８ハードウェアリソース群１００ｈの使用状況が、リソース追加条件を満たしたとする。

この場合、ベアメタル管理部９６が、汎用予備リソース群１１２から第８ハードウェアリソース群１００ｈに所属が変更される選択ハードウェアリソースに対して、ＤＵ４２に応じたセットアップを実行してもよい。ここでは例えば、予備リソース１１０ｂが選択ハードウェアリソースに相当する。そして、構成管理部７６が、当該セットアップが実行された選択ハードウェアリソースの所属を共通予備リソース群１０８から第８ハードウェアリソース群１００ｈに変更してもよい。

また、上記の場合において、ベアメタル管理部９６は、第８ハードウェアリソース群１００ｈの使用状況が当該ハードウェアリソース群１００に対応付けられるリソース追加条件を満たしたことに応じて、汎用予備リソース群１１２に含まれるハードウェアリソース（例えば、選択ハードウェアリソース）に対して、第８ハードウェアリソース群１００ｈで稼働しているアプリケーションの種類に応じたセットアップを実行してもよい。

そして、図１６に示す状況において、例えば、図１７に示すように、ＤＵ４２が稼働している第８ハードウェアリソース群１００ｈの使用状況が、リソース削除条件を満たしたとする。

この場合、構成管理部７６が、選択ハードウェアリソースの所属を第８ハードウェアリソース群１００ｈからＤＵ用予備リソース群１１６に変更してもよい。当該選択ハードウェアリソースは、その後、ＤＵ４２が稼働しているハードウェアリソース群１００の使用状況がリソース追加条件を満たした場合に、当該ハードウェアリソース群１００に所属が変更されてもよい。

以上のようにすることで、上述の所定の種類が複数ある場合に、それぞれの種類について、当該種類のアプリケーションが稼働しているハードウェアリソース群１００の使用状況がリソース追加条件を満たした場合に、当該種類に応じたセットアップが実行されたハードウェアリソースに余裕があれば、当該セットアップが実行されていないハードウェアリソースに対して当該セットアップを実行することなく、当該ハードウェアリソース群１００に予備リソース１１０をスムーズに追加することが可能となる。

また、以上のようにすることで、初期状態において、所定のアプリケーションの種類が複数である場合に、それぞれのアプリケーションの種類に応じたセットアップを予備リソース１１０に対して事前に実行していなくても、当該種類のアプリ―ションが稼働するハードウェアリソース群１００に予備リソース１１０を追加することが可能となる。

また、以上の場合についても、ストレージの読み書き回数を抑制できるなどの理由で、ハードウェアリソースの耐久性を向上させることが可能となる。

また、本実施形態において、初期状態で、特殊予備リソース群に、当該特殊予備リソース群に対応付けられるアプリケーションの種類に応じたセットアップが実行された予備リソース１１０が含まれるようにしてもよい。

また、本実施形態において、構成管理部７６が、特殊予備リソース群に含まれるハードウェアリソース量と、汎用予備リソース群１１２に含まれるハードウェアリソース量と、の比率が、所定の比率条件を満たしていない場合に、当該比率条件を満たすよう、当該特殊予備リソース群又は汎用予備リソース群１１２のうちの一方に含まれるハードウェアリソースの所属を、当該一方から他方に変更してもよい。

ここで、所属が汎用予備リソース群１１２から特殊予備リソース群に変更されるハードウェアリソースに対して、ベアメタル管理部９６は、当該特殊予備リソース群に対応付けられるアプリケーションの種類に応じたセットアップを実行してもよい。

また、所属が特殊予備リソース群から汎用予備リソース群１１２に変更されるハードウェアリソースに対して、ベアメタル管理部９６は、セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻してもよい。以下、上述のセットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻す処理を、アンセットアップと呼ぶこととする。

ここで、例えば、構成管理部７６が、ハードウェアリソースの使用実績に基づいて上述の比率を決定してもよい。例えば、過去の所定期間における、所定の種類のアプリケーションが稼働するハードウェアリソース群１００におけるハードウェアリソースの実際の使用率と、当該所定の種類以外のアプリケーションが稼働するハードウェアリソース群１００におけるハードウェアリソースの実際の使用率と、の比率に基づいて、特殊予備リソース群に含まれる予備リソース１１０の量と、汎用予備リソース群１１２に含まれる予備リソース１１０の量と、の比率が決定されてもよい。

また、期間種別ごとに、上述の比率条件が決定されてもよい。例えば、平日と休日のそれぞれについての比率条件が決定されてもよい。また、昼間及び夜間のそれぞれについての比率条件が決定されてもよい。そして、現在時刻が属する期間種別について決定された比率条件に基づいて、特殊予備リソース群又は汎用予備リソース群１１２のうちの一方に含まれるハードウェアリソースの所属が、当該一方から他方に変更されてもよい。

以上のようにすれば、セットアップが実行されたハードウェアリソースを共通予備リソース群１０８に確保することが可能となる。

また、本実施形態において、構成管理部７６が、特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の補充条件を満たす場合に、汎用予備リソース群１１２に含まれるハードウェアリソースの所属を、汎用予備リソース群１１２から当該特殊予備リソース群に変更してもよい。この補充条件は、上述の余裕条件と同じであってもよいし異なっていてもよい。

例えば、特殊予備リソース群に予備リソース１１０が含まれておらず、空である場合に、構成管理部７６が、汎用予備リソース群１１２に含まれるハードウェアリソースの所属を、汎用予備リソース群１１２から当該特殊予備リソース群に変更してもよい。

ここで、ベアメタル管理部９６が、所属が汎用予備リソース群１１２から特殊予備リソース群に変更されるハードウェアリソースに対して、当該特殊予備リソース群に対応付けられるアプリケーションの種類に応じたセットアップを実行してもよい。

なお、以上の処理は、例えば、夜間や休日にバッチ処理で実行されてもよい。

この場合も、セットアップが実行されたハードウェアリソースを共通予備リソース群１０８に確保することが可能となる。

また、本実施形態において、ネットワークサービスの購入者の要求に応じて、予備リソース１１０の所属が、共通予備リソース群１０８から、当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００に変更されるようにしてもよい。

また、ネットワークサービスの購入者が、上述のように予め設定されたリソース追加条件を満たした場合に予備リソース１１０の所属が変更されるようにするか否かを設定できてもよい。

また、ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたことに応じて、ネットワークサービスの購入者にハードウェアリソースの追加要否の問い合わせが通知されるようにしてもよい。そして、当該購入者によってリソースの追加が承認されたことに応じて、予備リソース１１０の所属が共通予備リソース群１０８から当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００に変更されるようにしてもよい。

同様に、ハードウェアリソース群１００の使用状況がリソース削除条件を満たしたことに応じて、ネットワークサービスの購入者にハードウェアリソースの削除要否の問い合わせが通知されるようにしてもよい。そして、当該購入者によってリソースの削除が承認されたことに応じて、予備リソース１１０の所属が、当該購入者が購入したアプリケーションが稼働するハードウェアリソース群１００から共通予備リソース群１０８に変更されるようにしてもよい。

また、リソース追加条件やリソース削除条件が、アプリケーションが稼働しているサーバ数、又は、空きサーバ数に係る条件であってもよい。例えば、ハードウェアリソース群１００に含まれる空きサーバ数が所定数以下になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。

また、リソース追加条件やリソース削除条件が、アプリケーションが稼働している仮想マシン（ＶＭ）数、又は、空きＶＭ数に係る条件であってもよい。例えば、ハードウェアリソース群１００に含まれる空きＶＭ数が所定数以下になったことに応じて、共通予備リソース群１０８に含まれるハードウェアリソースの所属が共通予備リソース群１０８から当該ハードウェアリソース群１００に変更されてもよい。

ここで、本実施形態に係るプラットフォームシステム３０で行われる、ハードウェアリソース群１００へのハードウェアリソースの追加に関する処理の流れの一例を、図１８に例示するフロー図を参照しながら説明する。

図１８に例示する処理は、通信システム１に含まれる、上述の所定の種類（例えば、ＵＰＦ５０、又は、ＤＵ４２）のアプリケーションが稼働している、すべてのハードウェアリソース群１００において実行される。

本処理例では、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしているか否かを監視している（Ｓ１０１）。

ここで、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたと判定すると（Ｓ１０１：Ｙ）、構成管理部７６が、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たすか否かを判定する（Ｓ１０２）。

余裕条件を満たす場合は（Ｓ１０２：Ｙ）、構成管理部７６は、当該特殊予備リソース群に含まれる選択ハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群１００に変更して（Ｓ１０３）、Ｓ１０１に示す処理に戻る。

余裕条件を満たさない場合は（Ｓ１０２：Ｎ）、ベアメタル管理部９６が、汎用予備リソース群１１２に含まれる選択ハードウェアリソースに対して、当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に応じたセットアップを実行する（Ｓ１０４）。

そして、構成管理部７６が、Ｓ１０４に示す処理でセットアップが実行された選択ハードウェアリソースの所属を、汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更して（Ｓ１０５）、Ｓ１０１に示す処理に戻る。

上述の所定の種類のアプリケーション（例えば、ＵＰＦ５０、又は、ＤＵ４２）以外のアプリケーションが稼働している、すべてのハードウェアリソース群１００においては、Ｓ１０２からＳ１０５に示す処理が実行されない。その代わりに、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース追加条件を満たしたと判定すると（Ｓ１０１：Ｙ）、構成管理部７６が、汎用予備リソース群１１２に含まれる選択ハードウェアリソースの所属を汎用予備リソース群１１２から当該ハードウェアリソース群１００に変更して、Ｓ１０１に示す処理に戻る。

次に、本実施形態に係るプラットフォームシステム３０で行われる、ハードウェアリソース群１００からのハードウェアリソースの削除に関する処理の流れの一例を、図１９に例示するフロー図を参照しながら説明する。

図１９に例示する処理は、通信システム１に含まれるすべてのハードウェアリソース群１００において実行される。

本処理例では、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース削除条件を満たしているか否かを監視している（Ｓ２０１）。

ここで、ポリシーマネージャ部９０が、当該ハードウェアリソース群１００の使用状況がリソース削除条件を満たしたと判定すると（Ｓ２０１：Ｙ）、構成管理部７６が、選択ハードウェアリソースの所属を、当該ハードウェアリソース群１００から当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる予備リソース群に変更して（Ｓ２０２）、Ｓ２０１に示す処理に戻る。

Ｓ２０２に示す処理では、例えば、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が上述の所定の種類である場合は、選択ハードウェアリソースの所属が、当該ハードウェアリソース群１００から当該ハードウェアリソース群１００で稼働しているアプリケーションの種類に対応付けられる特殊予備リソース群に変更される。

また、Ｓ２０３に示す処理では、例えば、リソース削除条件を満たしたハードウェアリソース群１００で稼働しているアプリケーションの種類が上述の所定の種類以外の種類である場合は、選択ハードウェアリソースの所属が、当該ハードウェアリソース群１００から汎用予備リソース群１１２に変更される。

なお、本発明は上述の実施形態に限定されるものではない。

例えば、以上の説明においてベアメタル管理部９６によって実行される諸例が、例えば、構成管理部７６によって実行されてもよい。逆に、以上の説明において構成管理部７６によって実行される処理を、例えば、ベアメタル管理部９６によって実行されてもよい。

また、本実施形態に係る機能ユニットは図３に示したものには限定されない。

また、本実施形態に係る機能ユニットは、５ＧにおけるＮＦである必要はない。例えば、本実施形態に係る機能ユニットが、ｅＮｏｄｅＢ、ｖＤＵ、ｖＣＵ、Ｐ－ＧＷ（Packet Data Network Gateway）、Ｓ－ＧＷ（Serving Gateway）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）などといった、４Ｇにおけるネットワークノードであっても構わない。

また、本実施形態に係る機能ユニットが、コンテナ型の仮想化技術でなく、ハイパーバイザ型やホスト型の仮想化技術を用いて実現されてもよい。また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。

本開示に記載の技術は以下のように表現することもできる。
［１］
通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視手段と、
いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を、前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加手段と、
所定のアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段と、を含み、
前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記リソース追加手段が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更し、
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記セットアップ実行手段が、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記リソース追加手段が、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更する、
ことを特徴とするリソース管理システム。
［２］
前記共通予備リソース群は、アプリケーションの種類にそれぞれ対応付けられる、含まれているハードウェアリソースが、当該種類に応じたセットアップが実行されたハードウェアリソースである複数の前記特殊予備リソース群を含み、
いずれかの前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が当該特殊予備リソース群に対応付けられる前記余裕条件を満たす場合に、当該特殊予備リソース群に対応付けられるアプリケーションが稼働している前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記リソース追加手段が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更する、
ことを特徴とする［１］に記載のリソース管理システム。
［３］
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記セットアップ実行手段が、前記汎用予備リソース群のうちから選択される選択ハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記リソース追加手段が、前記セットアップが実行された前記選択ハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更し、
前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース削除条件を満たしたことに応じて、前記セットアップが実行された前記選択ハードウェアリソースの所属を当該ハードウェアリソース群から当該特殊予備リソース群に変更するリソース削除手段、をさらに含む、
ことを特徴とする［１］又は［２］に記載のリソース管理システム。
［４］
前記特殊予備リソース群に含まれるハードウェアリソース量と、前記汎用予備リソース群に含まれるハードウェアリソース量と、の比率が、所定の比率条件を満たしていない場合に、当該比率条件を満たすよう、前記特殊予備リソース群又は前記汎用予備リソース群のうちの一方に含まれるハードウェアリソースの所属を、当該一方から他方に変更するリソース調整手段、をさらに含み、
所属が前記汎用予備リソース群から前記特殊予備リソース群に変更されるハードウェアリソースに対して、前記セットアップ実行手段は、前記アプリケーションの種類に応じたセットアップを実行し、
所属が前記特殊予備リソース群から前記汎用予備リソース群に変更されるハードウェアリソースに対して、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行手段、をさらに含む、
ことを特徴とする［１］から［３］のいずれか一項に記載のリソース管理システム。
［５］
前記ハードウェアリソースの使用実績に基づいて前記比率を決定する比率決定手段、をさらに含む、
ことを特徴とする［４］に記載のリソース管理システム。
［６］
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の補充条件を満たす場合に、前記汎用予備リソース群に含まれるハードウェアリソースの所属を、当該汎用予備リソース群から前記特殊予備リソース群に変更するリソース調整手段、をさらに含み、
所属が前記汎用予備リソース群から前記特殊予備リソース群に変更されるハードウェアリソースに対して、前記セットアップ実行手段は、前記アプリケーションの種類に応じたセットアップを実行する、
ことを特徴とする［１］から［３］のいずれか一項に記載のリソース管理システム。
［７］
前記リソース追加条件は、ハードウェアリソースの実際の使用量、ハードウェアリソースの実際の使用率、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件である、
ことを特徴とする［１］から［６］のいずれか一項に記載のリソース管理システム。
［８］
前記リソース追加条件は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件である、
ことを特徴とする［１］から［６］のいずれか一項に記載のリソース管理システム。
［９］
前記リソース追加条件は、前記ハードウェアリソース群で稼働しているアプリケーションの数に対応付けられる条件である、
ことを特徴とする［１］から［８］のいずれか一項に記載のリソース管理システム。
［１０］
前記リソース追加条件は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件である、
ことを特徴とする［１］から［９］のいずれか一項に記載のリソース管理システム。
［１１］
前記複数のハードウェアリソース群のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別の前記ハードウェアリソース群で稼働している、
ことを特徴とする［１］から［１０］のいずれか一項に記載のリソース管理システム。
［１２］
前記使用状況監視手段は、前記通信システムに含まれる複数のサーバ群のそれぞれの使用状況を監視し、
前記リソース追加手段は、いずれかの前記サーバ群の使用状況が当該サーバ群に対応付けられるサーバ追加条件を満たしたことに応じて、いずれの前記サーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を、前記共通予備サーバ群から当該サーバ群に変更する、
ことを特徴とする［１］から［１１］のいずれか一項に記載のリソース管理システム。
［１３］
前記ハードウェアリソース群は、コンテナ管理ツールによって管理されるクラスタに相当する、
ことを特徴とする［１］から［１２］のいずれか一項に記載のリソース管理システム。
［１４］
通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、
いずれの前記ハードウェアリソース群とも異なる共通予備リソース群の一部であり、含まれているハードウェアリソースが、所定のアプリケーションの種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更することと、
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更することと、
を含むことを特徴とするリソース管理方法。

Claims

通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視する使用状況監視手段と、
いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、いずれの前記ハードウェアリソース群とも異なる共通予備リソース群に含まれるハードウェアリソースの所属を、前記共通予備リソース群から当該ハードウェアリソース群に変更するリソース追加手段と、
所定のアプリケーションの種類に応じたセットアップを実行するセットアップ実行手段と、を含み、
前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記リソース追加手段が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更し、
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記セットアップ実行手段が、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記リソース追加手段が、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更する、
リソース管理システム。
前記共通予備リソース群は、アプリケーションの種類にそれぞれ対応付けられる、含まれているハードウェアリソースが、当該種類に応じたセットアップが実行されたハードウェアリソースである複数の前記特殊予備リソース群を含み、
いずれかの前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が当該特殊予備リソース群に対応付けられる前記余裕条件を満たす場合に、当該特殊予備リソース群に対応付けられるアプリケーションが稼働している前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記リソース追加手段が、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更する、
請求項１に記載のリソース管理システム。
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記セットアップ実行手段が、前記汎用予備リソース群のうちから選択される選択ハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記リソース追加手段が、前記セットアップが実行された前記選択ハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更し、
前記いずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース削除条件を満たしたことに応じて、前記セットアップが実行された前記選択ハードウェアリソースの所属を当該ハードウェアリソース群から当該特殊予備リソース群に変更するリソース削除手段、をさらに含む、
請求項１に記載のリソース管理システム。
前記特殊予備リソース群に含まれるハードウェアリソース量と、前記汎用予備リソース群に含まれるハードウェアリソース量と、の比率が、所定の比率条件を満たしていない場合に、当該比率条件を満たすよう、前記特殊予備リソース群又は前記汎用予備リソース群のうちの一方に含まれるハードウェアリソースの所属を、当該一方から他方に変更するリソース調整手段、をさらに含み、
所属が前記汎用予備リソース群から前記特殊予備リソース群に変更されるハードウェアリソースに対して、前記セットアップ実行手段は、前記アプリケーションの種類に応じたセットアップを実行し、
所属が前記特殊予備リソース群から前記汎用予備リソース群に変更されるハードウェアリソースに対して、前記セットアップが実行されたハードウェアリソースを当該セットアップの実行前の状態に戻すアンセットアップ実行手段、をさらに含む、
請求項１に記載のリソース管理システム。
前記ハードウェアリソースの使用実績に基づいて前記比率を決定する比率決定手段、をさらに含む、
請求項４に記載のリソース管理システム。
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の補充条件を満たす場合に、前記汎用予備リソース群に含まれるハードウェアリソースの所属を、当該汎用予備リソース群から前記特殊予備リソース群に変更するリソース調整手段、をさらに含み、
所属が前記汎用予備リソース群から前記特殊予備リソース群に変更されるハードウェアリソースに対して、前記セットアップ実行手段は、前記アプリケーションの種類に応じたセットアップを実行する、
請求項１に記載のリソース管理システム。
前記リソース追加条件は、ハードウェアリソースの実際の使用量、ハードウェアリソースの実際の使用率、ハードウェアリソースの実際の余裕量、又は、ハードウェアリソースの実際の余裕率、に係る条件である、
請求項１に記載のリソース管理システム。
前記リソース追加条件は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース量、又は、前記ハードウェアリソース群でのアプリケーションの稼働のための使用が想定される最大ハードウェアリソース率に係る条件である、
請求項１に記載のリソース管理システム。
前記リソース追加条件は、前記ハードウェアリソース群で稼働しているアプリケーションの数に対応付けられる条件である、
請求項１に記載のリソース管理システム。
前記リソース追加条件は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる範囲内から当該アプリケーションの購入者によって選択される条件、又は、前記ハードウェアリソース群で稼働しているアプリケーションの種類に対応付けられる複数の選択肢のうちから当該アプリケーションの購入者によって選択される条件である、
請求項１に記載のリソース管理システム。
前記複数のハードウェアリソース群のうちのいずれかで稼働しているアプリケーションの購入者とは異なる購入者によって購入されたアプリケーションが別の前記ハードウェアリソース群で稼働している、
請求項１に記載のリソース管理システム。
前記使用状況監視手段は、前記通信システムに含まれる複数のサーバ群のそれぞれの使用状況を監視し、
前記リソース追加手段は、いずれかの前記サーバ群の使用状況が当該サーバ群に対応付けられるサーバ追加条件を満たしたことに応じて、いずれの前記サーバ群とも異なる共通予備サーバ群に含まれるサーバの所属を、前記共通予備サーバ群から当該サーバ群に変更する、
請求項１に記載のリソース管理システム。
前記ハードウェアリソース群は、コンテナ管理ツールによって管理されるクラスタに相当する、
請求項１に記載のリソース管理システム。
通信システムに含まれる複数のハードウェアリソース群のそれぞれの使用状況を監視することと、
いずれの前記ハードウェアリソース群とも異なる共通予備リソース群の一部であり、含まれているハードウェアリソースが、所定のアプリケーションの種類に応じたセットアップが実行されたハードウェアリソースである特殊予備リソース群に含まれているハードウェアリソースの余裕度が所定の余裕条件を満たす場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられるリソース追加条件を満たしたことに応じて、当該特殊予備リソース群に含まれるハードウェアリソースの所属を当該特殊予備リソース群から当該ハードウェアリソース群に変更することと、
前記特殊予備リソース群に含まれているハードウェアリソースの余裕度が前記余裕条件を満たさない場合に、前記種類のアプリケーションが稼働するいずれかの前記ハードウェアリソース群の使用状況が当該ハードウェアリソース群に対応付けられる前記リソース追加条件を満たしたことに応じて、前記共通予備リソース群の一部であり、含まれているハードウェアリソースが、前記セットアップが実行されていないハードウェアリソースである汎用予備リソース群に含まれるハードウェアリソースに対して前記アプリケーションの種類に応じたセットアップを実行し、前記セットアップが実行されたハードウェアリソースの所属を当該汎用予備リソース群から当該ハードウェアリソース群に変更することと、
を含むリソース管理方法。