JP7838123B2 - 通信システムに含まれるプロセスが不安定であるか否かの判定 - Google Patents

Description

本発明は、通信システムに含まれるプロセスが不安定であるか否かの判定に関する。

特許文献１には、ハイパーバイザ等の仮想化レイヤ上に実装した仮想マシン（ＶＭ）によりネットワーク機器等の機能をソフトウェア的に実現するＮＦＶ（Network Functions Virtualization）が記載されている。

国際公開第２０２０／１４５２４２号

通信システムで動作するネットワークファンクション等のアプリケーションのなかには、複数のプロセスを含んでおり、これらのプロセスが、複数の仮想マシンで分散して稼働しているものがある。

ここで、これらのプロセスのなかから不安定であるプロセスを抽出するにあたって、それぞれのプロセスについて、当該プロセスが不安定になったか否かを監視すると、監視のための処理負荷が膨大になることがある。

本発明は上記実情に鑑みてなされたものであって、その目的の一つは、通信システムに含まれるプロセスのなかから不安定であるプロセスを少ない処理負荷で抽出できるようにすることにある。

上記課題を解決するために、本開示に係る判定システムは、含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視するアプリケーション監視手段と、前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定するプロセス不安定判定手段と、を含む。

また、本開示に係る判定方法は、含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視することと、前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定することと、を含む。

本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係る通信システムの一例を示す図である。 本発明の一実施形態に係るネットワークサービスの一例を模式的に示す図である。 本発明の一実施形態に係る通信システムに構築される要素間の関連付けの一例を示す図である。 本発明の一実施形態に係るプラットフォームシステムで実装される機能の一例を示す機能ブロック図である。 物理インベントリデータのデータ構造の一例を示す図である。 複数のアプリケーションのそれぞれに含まれるプロセスが複数の仮想マシンで分散して稼働している状況の一例を模式的に示す図である。 複数のアプリケーションのそれぞれに含まれるプロセスが複数の仮想マシンで分散して稼働している状況の一例を模式的に示す図である。 複数のアプリケーションのそれぞれに含まれるプロセスが複数の仮想マシンで分散して稼働している状況の一例を模式的に示す図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。 本発明の一実施形態に係るプラットフォームシステムで行われる処理の流れの一例を示すフロー図である。

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

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

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

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

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

エッジデータセンタ１４は、例えば、通信システム１がカバーするエリア内に分散して数千個配置される。また、エッジデータセンタ１４のそれぞれは、アンテナ１６を備えた通信設備１８と通信可能となっている。ここで図１に示すように、１つのエッジデータセンタ１４が数個の通信設備１８と通信可能になっていてもよい。通信設備１８は、サーバコンピュータなどのコンピュータを含んでいてもよい。本実施形態に係る通信設備１８は、アンテナ１６を介してＵＥ（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）サービスが提供されても構わない。そして、この場合において、例えば、ロボットアームやコネクテッドカーなどを利用するエンドユーザが本実施形態に係るネットワークサービスの購入者となっても構わない。

本実施形態では、セントラルデータセンタ１０、リージョナルデータセンタ１２、及び、エッジデータセンタ１４に配置されているサーバには、ハイパーバイザ（ベアメタル型ハイパーバイザ）や、ホストオペレーティングシステム（ホストＯＳ）上で動作するホスト型仮想化ソフトウェアがインストールされている。そして、それぞれのサーバでは、１以上の仮想マシン（ＶＭ：Virtual Machine）が稼働する。そして、それぞれの仮想マシンには、１又は複数のプロセスをデプロイして稼働させることができるようになっている。また、本実施形態において、複数のサーバにまたがる仮想マシンのクラスタが構築されてもよい。

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

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

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

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

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

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

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

図４に示すように、ネットワークサービス（ＮＳ）、ネットワークファンクション（ＮＦ）、及び、プロセスは、階層構成となっている。

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

ＮＦは、５Ｇでは、例えば、ＲＵ、ＤＵ、ＣＵ－ＣＰ、ＣＵ－ＵＰ、ＡＭＦ、ＳＭＦ、ＵＰＦなどの粒度の要素に相当する。また、ＮＦは、４Ｇでは、例えば、ＭＭＥ（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）が挙げられる。ＮＳＤは、ネットワークサービスに対応付けられるものであり、当該ネットワークサービスに含まれる複数の機能ユニットの種類などが示されている。なお、ＮＳＤに、機能ユニットの種類ごとについての、当該ネットワークサービスに含まれる数が示されていてもよい。また、ＮＳＤに、当該ネットワークサービスに含まれるＮＦに係る、後述するＮＦＤのファイル名が示されていてもよい。

また、サービステンプレートデータの一例として、ＮＦＤ（NF 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）を設定するコマンド、及び、当該ＶＬＡＮに設定情報が示す帯域幅や優先度を割り当てるコマンドを発行することにより、それら複数の設定対象のＮＦにわたるＮＳＩ及びＮＳＳＩを生成してもよい。

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

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

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

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

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

また、例えば、監視機能部７２は、サーバに、メトリックデータをプロセス単位に取得するサイドカープロセスをデプロイしてもよい。監視機能部７２は、モニタリングツールの仕組みを利用して、プロセス単位で取得されたメトリックデータをサイドカープロセスから取得する処理を、所与の監視間隔で繰り返し実行してもよい。

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

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

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

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

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

また、監視機能部７２は、本実施形態では、例えば、通信システム１に含まれる要素の安定性を示す安定性評価値を特定する。そして、監視機能部７２は、特定される安定性評価値を示す安定性評価値データを生成する。そして、監視機能部７２は、生成される安定性評価値データを、データバス部６８に出力する。

データバス部６８は、本実施形態では例えば、監視機能部７２から出力される安定性評価値データを受け付ける。

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

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

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

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

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

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

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

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

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

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

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

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

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

また、本実施形態に係るポリシーマネージャ部９０は、データバス部６８に格納されている安定性評価値データを取得可能になっている。そして、ポリシーマネージャ部９０は、データバス部６８から取得される安定性評価値データに基づいて、所定の判定処理を実行してもよい。例えば、ポリシーマネージャ部９０は、アプリケーションの安定性を示す安定性評価値データに基づいて、当該アプリケーションが不安定であるか否かを判定してもよい。

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

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

本実施形態に係るプラットフォームシステム３０は、通信システム１に含まれるプロセスが不安定であるか否かを判定する。以下、本実施形態に係るプラットフォームシステム３０で実行される、プロセスが不安定であるか否かの判定についてさらに説明する。

図７は、複数のアプリケーションのそれぞれに含まれるプロセスが複数の仮想マシンで分散して稼働している状況の一例を模式的に示す図である。

図７の例では、識別子がそれぞれＡＰ１、ＡＰ２、ＡＰ３、ＡＰ４である４つのアプリケーションが稼働している状況が示されている。

これらのアプリケーションは、ネットワークファンクション（例えば、ＤＵ４２、ＣＵ－ＣＰ４４ａ、ＣＵ－ＵＰ４４ｂ、ＡＭＦ４６、ＳＭＦ４８、ＵＰＦ５０、など）であってもよい。

本実施形態ではアプリケーションの種類毎に当該種類のアプリケーションが稼働可能なハードウェアリソースが予め定められている。以下の説明ではハードウェアリソースは、サーバであることとするが、当該ハードウェアリソースはサーバである必要はなく、例えば、ノードであっても構わない。

以下、ある種類のアプリケーションが稼働可能なハードウェアリソースを当該アプリケーションに対応するテナントと呼ぶこととする。

図７には、識別子がそれぞれＳ１、Ｓ２、Ｓ３、Ｓ４である４つのサーバが示されている。これら４つのサーバは、識別子がＣＬ１０１である１つのクラスタに所属していることとする。

また、図７に示されている４つのアプリケーションは、それぞれ種類が異なることとする。そして、識別子がＡＰ１であるアプリケーションに対応するテナントには、識別子がＳ１、Ｓ２、及び、Ｓ３であるサーバが含まれていることとする。また、識別子がＡＰ２であるアプリケーションに対応するテナントには、識別子がＳ２、及び、Ｓ３であるサーバが含まれていることとする。また、識別子がＡＰ３であるアプリケーションに対応するテナントには、識別子がＳ１、Ｓ２、Ｓ３、及び、Ｓ４であるサーバが含まれていることとする。また、識別子がＡＰ４であるアプリケーションに対応するテナントには、識別子がＳ１、及び、Ｓ４であるサーバが含まれていることとする。

また、識別子がＳ１であるサーバには、識別子が、ＶＭ１、ＶＭ６、ＶＭ１０である仮想マシンが稼働していることとする。また、識別子がＳ２であるサーバには、識別子が、ＶＭ２、ＶＭ４、ＶＭ７である仮想マシンが稼働していることとする。また、識別子がＳ３であるサーバには、識別子が、ＶＭ３、ＶＭ５、ＶＭ８である仮想マシンが稼働していることとする。また、識別子がＳ４であるサーバには、識別子が、ＶＭ９、ＶＭ１１である仮想マシンが稼働していることとする。

また、図７に示されている角丸長方形の図形は、１つのプロセスに相当する。そして、角丸長方形の図形に示されている数字は、プロセスの種類に対応付けられる識別子であることとする。

図７に示すように、識別子がＡＰ１であるアプリケーションには、識別子が１、２、及び、３である３種類のプロセスがそれぞれ１つずつ含まれる。そして、識別子が１、２、及び、３である種類のプロセスが、それぞれ、識別子がＶＭ１、ＶＭ２、及び、ＶＭ３である仮想マシンで稼働している。

そして、識別子がＡＰ２であるアプリケーションには、識別子が４、５である２種類のプロセスがそれぞれ１つずつ含まれる。そして、識別子が４、及び、５である種類のプロセスが、それぞれ、識別子がＶＭ４、及び、ＶＭ５である仮想マシンで稼働している。

そして、識別子がＡＰ３であるアプリケーションには、識別子が６、７、８、９である４種類のプロセスがそれぞれ１つずつ含まれる。そして、識別子が６、７、８、及び、９である種類のプロセスが、それぞれ、識別子がＶＭ６、ＶＭ７、ＶＭ８、及び、ＶＭ９である仮想マシンで稼働している。

そして、識別子がＡＰ４であるアプリケーションには、識別子が１０、１１である２種類のプロセスがそれぞれ１つずつ含まれる。そして、識別子が１０、及び、１１である種類のプロセスが、それぞれ、識別子がＶＭ１０、及び、ＶＭ１１である仮想マシンで稼働している。

このように、図７に示されているアプリケーションには複数のプロセスが含まれている。そして、これらのプロセスは、複数の仮想マシンで分散して稼働することとなる。

図７の例では、１つのアプリケーションには複数種類のプロセスがそれぞれ１つずつ含まれているが、１つのアプリケーションには１つの種類のプロセスが複数含まれていてもよい。また、図７の例では、１つの仮想マシンでは１つのプロセスが稼働しているが、１つの仮想マシンで複数のプロセスが稼働していてもよい。

そして、本実施形態では例えば、監視機能部７２が、プロセスごとに、当該プロセスの安定性を示す値（メトリック）を取得する。ここで、例えば、プロセスの状態（例えば、生死）を示す値、プロセスの起動時刻、プロセスが入出力を実行した時間の長さ、プロセスの送信パケットドロップ数、プロセスの受信パケットドロップ数、などのメトリックが取得されてもよい。

そして、監視機能部７２は、取得されるこれら複数種類のメトリックについての、当該種類に対応付けられる重み付けによる重み付け和を、当該プロセスの安定性を示す安定性評価値として算出する。ここで例えば、プロセスの種類毎に、それぞれの種類のメトリックの重みが予め定められていてもよい。そして、取得されるメトリックについての、予め定められた重みでの重み付けによる重み付け和が、当該種類のプロセスの安定性を示す安定性評価値として算出されてもよい。以下、プロセスの安定性を示す安定性評価値を、プロセス安定性評価値と呼ぶこととする。例えば、図７の例では、識別子が１から１１であるプロセスのそれぞれについてプロセス安定性評価値が算出されることとなる。

そして、監視機能部７２が、アプリケーションに含まれるプロセスごとに取得される、当該プロセスのプロセス安定性評価値に基づいて、当該アプリケーションの安定性を示す安定性評価値を特定する。以下、アプリケーションの安定性を示す安定性評価値を、アプリケーション安定性評価値と呼ぶこととする。例えば、監視機能部７２は、アプリケーション毎に、当該アプリケーションに含まれるプロセスについて算出されるプロセス安定性評価値に基づいて、当該アプリケーションのアプリケーション安定性評価値を算出する。

ここで、アプリケーション安定性評価値は、当該アプリケーションに含まれるプロセスの状態、当該アプリケーションに含まれるプロセスの生存時間、当該アプリケーションに含まれるプロセスが入出力を実行した時間の長さ、又は、当該アプリケーションに含まれるプロセスのパケットドロップ数、のうちの少なくとも１つに基づいて特定されてもよい。ここで例えば、プロセスの生存時間は、上述のプロセスの起動時刻を示す値に基づいて特定可能である。

また、監視機能部７２が、アプリケーションの種類に対応付けられる規則に従って、当該アプリケーションの安定性を示すアプリケーション安定性評価値を算出してもよい。例えば、アプリケーションの種類毎に、数式が予め定められていてもよい。そして、当該アプリケーションに含まれるプロセスの種類毎に取得される、当該種類に係るプロセスのプロセス安定性評価値を、当該数式にあてはめることで、当該アプリケーションのアプリケーション安定性評価値が算出されてもよい。

例えば、識別子が１から３である種類のプロセスのプロセス安定性評価値に基づいて、識別子がＡＰ１であるアプリケーションのアプリケーション安定性評価値が算出される。また、識別子が４から５である種類のプロセスのプロセス安定性評価値に基づいて、識別子がＡＰ２であるアプリケーションのアプリケーション安定性評価値が算出される。また、識別子が６から９である種類のプロセスのプロセス安定性評価値に基づいて、識別子がＡＰ３であるアプリケーションのアプリケーション安定性評価値が算出される。また、識別子が１０から１１である種類のプロセスのプロセス安定性評価値に基づいて、識別子がＡＰ４であるアプリケーションのアプリケーション安定性評価値が算出される。

そして、監視機能部７２が、アプリケーション毎に算出される、当該アプリケーションのアプリケーション安定性評価値に基づいて、クラスタの安定性を示す安定性評価値を特定する。以下、クラスタの安定性を示す安定性評価値を、クラスタ安定性評価値と呼ぶこととする。例えば、監視機能部７２は、クラスタ毎に、当該クラスタで稼働しているアプリケーションについて算出されるプロセス安定性評価値に基づいて、当該クラスタのクラスタ安定性評価値を算出する。

ここで、監視機能部７２が、所定の規則に従って、クラスタ安定性評価値を算出してもよい。例えば、アプリケーションの種類毎に、重みが予め定められていてもよい。そして、クラスタで稼働しているアプリケーションのアプリケーション安定性評価値の重み付け和が、当該クラスタのクラスタ安定性評価値として算出されてもよい。

例えば、識別子がＡＰ１からＡＰ４であるアプリケーションのアプリケーション安定性評価値に基づいて、識別子がＣＬ１０１であるクラスタのクラスタ安定性評価値が算出される。

そして、監視機能部７２は、複数のクラスタのそれぞれについて、当該クラスタについて算出されるクラスタ安定性評価値を示すクラスタ安定性評価値データを生成して、生成されるクラスタ安定性評価値データをデータバス部６８に出力する。本実施形態では例えば、監視機能部７２は、最新の状況を表すクラスタ安定性評価値データを所定の時間間隔で生成する。そして、監視機能部７２は、クラスタ安定性評価値データが生成される度に、当該クラスタ安定性評価値データをデータバス部６８に出力する。

そして、データバス部６８にクラスタ安定性評価値データが出力されたことに応じて、ポリシーマネージャ部９０は、当該クラスタ安定性評価値データを取得する。そして、ポリシーマネージャ部９０は、取得したクラスタ安定性評価値データが示すクラスタ安定性評価値を特定する。

そして、ポリシーマネージャ部９０は、複数のクラスタのそれぞれについて、当該クラスタの安定性を示すクラスタ安定性評価値に基づいて、当該クラスタが不安定であるか否かを判定する。例えば、クラスタが不安定であるほど、クラスタ安定性評価値は小さいこととする。この場合、ポリシーマネージャ部９０は、例えば、所定の閾値よりもクラスタ安定性評価値が小さい場合に、当該クラスタが不安定であると判定する。

以上のように、本実施形態では、クラスタが不安定であるか否かを判定する処理は、データバス部６８に当該クラスタのクラスタ安定性評価値データが出力される度に実行される。このようにして、本実施形態では、ポリシーマネージャ部９０は、通信システム１に含まれるクラスタが不安定になったか否かを監視することとなる。

そして、本実施形態では例えば、ポリシーマネージャ部９０が、クラスタが不安定になったことの検出に応じて、当該クラスタで稼働している複数のアプリケーションのそれぞれが不安定になったか否かの監視を開始する。

例えば、ポリシーマネージャ部９０が、識別子がＣＬ１０１であるクラスタが不安定であると判定したとする。この場合、ポリシーマネージャ部９０は、当該クラスタで稼働している複数のアプリケーションのそれぞれについてのアプリケーション安定性評価値を示す安定性評価値データの出力開始指示を監視機能部７２に出力してもよい。以下、アプリケーション安定性評価値を示す安定性評価値データを、アプリケーション安定性評価値データと呼ぶこととする。

そして、本実施形態では例えば、監視機能部７２は、当該出力開始指示の受付に応じて、当該クラスタで稼働している複数のアプリケーション（ここでは例えば、識別子がＡＰ１からＡＰ４である４つのアプリケーション）のそれぞれについて、最新の状況を表すアプリケーション安定性評価値データを所定の時間間隔で生成することを開始する。そして、監視機能部７２は、アプリケーション安定性評価値データが生成される度に、当該アプリケーション安定性評価値データをデータバス部６８に出力する。

そして、本実施形態では例えば、ポリシーマネージャ部９０は、データバス部６８に当該アプリケーション安定性評価値データが出力されたことに応じて、当該アプリケーション安定性評価値データを取得する。

そして、本実施形態では例えば、ポリシーマネージャ部９０が、取得するアプリケーション安定性評価値データが示す安定性評価値に基づいて、当該アプリケーションが不安定であるか否かを判定する。例えば、アプリケーションが不安定であるほど、アプリケーション安定性評価値は小さいこととする。この場合、ポリシーマネージャ部９０は、例えば、所定の閾値よりもアプリケーション安定性評価値が小さい場合に、当該アプリケーションが不安定であると判定する。

以上のように、本実施形態では、アプリケーションが不安定であるか否かを判定する処理は、データバス部６８に当該アプリケーションのアプリケーション安定性評価値データが出力される度に実行される。このようにして、本実施形態では、ポリシーマネージャ部９０は、含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システム１に含まれるアプリケーションが不安定になったか否かを監視することとなる。

また、以上で説明したように、ポリシーマネージャ部９０は、クラスタが不安定になったことの検出に応じて、当該クラスタで稼働している複数のアプリケーションのそれぞれが不安定になったか否かの監視を開始してもよい。

また、本実施形態において、ポリシーマネージャ部９０は、アプリケーションに係る複数の監視項目を監視してもよい。そして、ポリシーマネージャ部９０は、当該複数の監視項目のうちの所与の監視項目の監視結果が所定の条件を満たしたことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定してもよい。

そして、本実施形態では例えば、ポリシーマネージャ部９０が、アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定する。

ここで例えば、ポリシーマネージャ部９０が、アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンを特定してもよい。そして、ポリシーマネージャ部９０が、特定される複数の仮想マシンのそれぞれについての、当該仮想マシンで稼働しているプロセスが不安定であるか否かの監視を開始してもよい。

例えば、ポリシーマネージャ部９０が、識別子がＡＰ１であるアプリケーションが不安定であると判定したとする。この場合、ポリシーマネージャ部９０は、当該アプリケーションに含まれる複数のプロセスのそれぞれについてのプロセス安定性評価値を示す安定性評価値データの出力開始指示を監視機能部７２に出力してもよい。以下、プロセス安定性評価値を示す安定性評価値データを、プロセス安定性評価値データと呼ぶこととする。

そして、本実施形態では例えば、監視機能部７２は、当該出力開始指示の受付に応じて、当該アプリケーション含まれる複数のプロセス（ここでは例えば、識別子が１から３である３つのプロセス）のそれぞれについて、最新の状況を表すプロセス安定性評価値データを所定の時間間隔で生成することを開始する。そして、監視機能部７２は、プロセス安定性評価値データが生成される度に、当該プロセス安定性評価値データをデータバス部６８に出力する。

そして、本実施形態では例えば、データバス部６８に当該プロセス安定性評価値データが出力されたことに応じて、ポリシーマネージャ部９０は、当該プロセス安定性評価値データを取得する。

そして、本実施形態では例えば、ポリシーマネージャ部９０が、取得するプロセス安定性評価値データが示す安定性評価値に基づいて、当該プロセスが不安定であるか否かを判定する。例えば、プロセスが不安定であるほど、プロセス安定性評価値は小さいこととする。この場合、ポリシーマネージャ部９０は、例えば、所定の閾値よりもプロセス安定性評価値が小さい場合に、当該プロセスが不安定であると判定する。

以上のように、本実施形態では、プロセスが不安定であるか否かを判定する処理は、データバス部６８に当該プロセスのアプリケーション安定性評価値データが出力される度に実行される。このようにして、本実施形態では、ポリシーマネージャ部９０は、通信システム１に含まれるプロセスが不安定になったか否かを監視することとなる。

また、以上で説明したように、ポリシーマネージャ部９０は、アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる複数のプロセスのそれぞれが不安定になったか否かの監視を開始してもよい。

なお、クラスタが不安定であると判定されたことに応じて、アプリケーション安定性評価値データのデータバス部６８への出力が開始されるようにしなくてもよい。例えば、クラスタが不安定であると判定されたことに応じて、ポリシーマネージャ部９０が、監視機能部７２に、当該クラスタで稼働するアプリケーションについての最新のアプリケーション安定性評価値を示すアプリケーション安定性評価値データの出力を要求してもよい。

そして、監視機能部７２が、当該要求の受付に応じて、最新のアプリケーション安定性評価値を示すアプリケーション安定性評価値データを生成し、生成されるアプリケーション安定性評価値データをポリシーマネージャ部９０に出力してもよい。そして、ポリシーマネージャ部９０が、監視機能部７２から出力されるアプリケーション安定性評価値データを受け付けて、当該アプリケーション安定性評価値データが示すアプリケーション安定性評価値に基づいて、当該アプリケーションが不安定であるか否かを判定してもよい。

また、同様に、アプリケーションが不安定であると判定されたことに応じて、プロセス安定性評価値データのデータバス部６８への出力が開始されるようにしなくてもよい。例えば、アプリケーションが不安定であると判定されたことに応じて、ポリシーマネージャ部９０が、監視機能部７２に、当該アプリケーションに含まれるプロセスについての最新のプロセス安定性評価値を示すプロセス安定性評価値データの出力を要求してもよい。

そして、監視機能部７２が、当該要求の受付に応じて、最新のプロセス安定性評価値を示すプロセス安定性評価値データを生成し、生成されるプロセス安定性評価値データをポリシーマネージャ部９０に出力してもよい。そして、ポリシーマネージャ部９０が、監視機能部７２から出力されるプロセス安定性評価値データを受け付けて、当該プロセス安定性評価値データが示すプロセス安定性評価値に基づいて、当該プロセスが不安定であるか否かを判定してもよい。

また、本実施形態において、プロセスが不安定であると判定されることに応じて、ポリシーマネージャ部９０が、当該プロセスに係るアクションを実行してもよい。例えば、ポリシーマネージャ部９０は、当該プロセスに対するアクション、当該プロセスが稼働している仮想マシンに対するアクション、当該仮想マシンが稼働しているサーバ、当該サーバが稼働しているクラスタ、などに対するアクションを実行してもよい。

ここで例えば、ポリシーマネージャ部９０は、プロセスが不安定であると判定されたことに応じて、当該プロセスが稼働しているハードウェアリソースで稼働している、当該プロセスが稼働している仮想マシンとは異なる仮想マシンで稼働しているプロセスが不安定であるか否かを判定してもよい。そして、ポリシーマネージャ部９０が、当該異なる仮想マシンで稼働しているプロセスが不安定であるか否かの判定結果に応じたアクションを実行してもよい。

ここで例えば、ポリシーマネージャ部９０は、プロセスのリプレースを実行してもよい。また、ポリシーマネージャ部９０は、仮想マシンの起動や終了を実行してもよい。また、ポリシーマネージャ部９０は、クラスタからのハードウェアリソースの切り離しを実行してもよい。また、ポリシーマネージャ部９０は、アプリケーションのテナントの設定を変更してもよい。

例えば、識別子が１であるプロセスが不安定であると判定されたことに応じて、識別子が６、及び、１０であるプロセスが不安定であるか否かが判定されてもよい。

そして、例えば、識別子が６、及び、１０であるプロセスのうちの少なくとも一方が安定であると判定された場合は、図８に示すように、識別子がＳ４であるサーバに、識別子がＶＭ１２である新たな仮想マシンが起動されてもよい。そして、識別子が１であるプロセスが、識別子がＶＭ１２である新たな仮想マシンで稼働するよう、識別子が１であるプロセスのリプレースが実行されてもよい。そして、識別子がＶＭ１である仮想マシンが終了されてもよい。

一方、識別子が６、及び、１０であるプロセスの両方が不安定であると判定された場合は、図９に示すように、識別子がＣＬ１０１であるクラスタに識別子がＳ５であるサーバが追加されてもよい。そして、識別子がＳ４であるサーバに、識別子がＶＭ１２、ＶＭ１３、ＶＭ１４である新たな仮想マシンが起動されてもよい。そして、識別子が１であるプロセスが、識別子がＶＭ１２である新たな仮想マシンで稼働し、識別子が６であるプロセスが、識別子がＶＭ１３である新たな仮想マシンで稼働し、識別子が１０であるプロセスが、識別子がＶＭ１４である新たな仮想マシンで稼働するよう、識別子が１、６、１０であるプロセスのリプレースが実行されてもよい。そして、識別子がＣＬ１０１であるクラスタから識別子がＳ１であるサーバが切り離されてもよい。

また、本実施形態において、１つの仮想マシンに複数のプロセスが稼働している場合が想定される。この場合、これら複数のプロセスのすべてが不安定であると判定された場合に、これらの複数のプロセスのすべてのリプレース、及び、当該仮想マシンの終了が実行されてもよい。一方、これら複数のプロセスのうちの一部が不安定であると判定された場合に、不安定であると判定されたプロセスのリプレースが実行されてもよい。この場合、残りのプロセスは、リプレースされずに当該仮想マシンで稼働している状態が続いてもよい。

また、本実施形態において、クラスタが不安定であると判定される条件の方が、アプリケーションが不安定であると判定される条件よりも緩くてもよい。

例えば、クラスタが不安定であるほど、クラスタ安定性評価値は小さく、また、アプリケーションが不安定であるほど、アプリケーション安定性評価値が小さいこととする。また、クラスタの安定性を示すクラスタ安定性評価値が、当該クラスタで稼働しているアプリケーションの安定性を示すアプリケーション安定性評価値の合計値であるとする。そして、所定の閾値ｔｈ１よりもクラスタ安定性評価値が小さい場合に、当該クラスタが不安定であると判定され、所定の閾値ｔｈ２よりもアプリケーション安定性評価値が小さい場合に、当該アプリケーションが不安定であると判定されるとする。

ここで、当該クラスタで稼働しているアプリケーションの数がｎ１個である場合に、閾値ｔｈ１は、閾値ｔｈ２のｎ１倍よりも大きくてもよい。

逆に、アプリケーションが不安定であると判定される条件の方が、クラスタが不安定であると判定される条件よりも緩くてもよい。例えば上述の場合において、閾値ｔｈ１が、閾値ｔｈ２のｎ１倍よりも小さくてもよい。

また、アプリケーションが不安定であると判定される条件の方が、プロセスが不安定であると判定される条件よりも緩くてもよい。

例えば、アプリケーションが不安定であるほど、アプリケーション安定性評価値は小さく、また、プロセスが不安定であるほど、プロセス安定性評価値が小さいこととする。また、アプリケーションの安定性を示すアプリケーション安定性評価値が、当該アプリケーションに含まれるプロセスの安定性を示すプロセス安定性評価値の合計値であるとする。そして、所定の閾値ｔｈ３よりもアプリケーション安定性評価値が小さい場合に、当該アプリケーションが不安定であると判定され、所定の閾値ｔｈ４よりもプロセス安定性評価値が小さい場合に、当該プロセスが不安定であると判定されるとする。

ここで、当該アプリケーションに含まれるプロセスの数がｎ２個である場合に、閾値ｔｈ３は、閾値ｔｈ４のｎ２倍よりも大きくてもよい。

逆に、プロセスが不安定であると判定される条件の方が、アプリケーションが不安定であると判定される条件よりも緩くてもよい。例えば上述の場合において、閾値ｔｈ３が、閾値ｔｈ４のｎ２倍よりも小さくてもよい。

ここで、本実施形態に係るプラットフォームシステム３０で行われる、プロセスが不安定であるか否かの判定に関する処理の流れの一例を、図１０Ａ及び図１０Ｂに例示するフロー図を参照しながら説明する。

本処理例では例えば、通信システム１に含まれる複数のクラスタのそれぞれに対して、以下で説明するＳ１０１からＳ１１３に示す処理が実行されることとする。以下、これら複数のクラスタのうちの１つに着目して、当該クラスタに対して実行される処理の流れの一例を説明する。

本処理例では例えば、ポリシーマネージャ部９０が、当該クラスタの安定性を示すクラスタ安定性評価値データがデータバス部６８に出力されることを監視している（Ｓ１０１）。

クラスタ安定性評価値データがデータバス部６８に出力されたことを検出すると、ポリシーマネージャ部９０が、当該クラスタ安定性評価値データを取得する（Ｓ１０２）。

そして、ポリシーマネージャ部９０が、Ｓ１０２に示す処理で取得されたクラスタ安定性評価値データに基づいて、当該クラスタが不安定であるか否かを判定する（Ｓ１０３）。

不安定であると判定されなかった場合は（Ｓ１０３：Ｎ）、Ｓ１０１に示す処理に戻る。

不安定であると判定された場合は（Ｓ１０３：Ｙ）、ポリシーマネージャ部９０は、当該クラスタで稼働する複数のアプリケーションのそれぞれについての、アプリケーション安定性評価値データの出力開始指示を、監視機能部７２に出力する（Ｓ１０４）。すると、監視機能部７２による、アプリケーション安定性評価値データのデータバス部６８への出力が開始される。

そして、ポリシーマネージャ部９０が、当該クラスタで稼働する複数のアプリケーションのそれぞれについて、当該アプリケーションの安定性を示すアプリケーション安定性評価値データがデータバス部６８に出力されることを監視する（Ｓ１０５）。

アプリケーション安定性評価値データがデータバス部６８に出力されたことを検出すると、ポリシーマネージャ部９０が、当該アプリケーション安定性評価値データを取得する（Ｓ１０６）。

そして、ポリシーマネージャ部９０が、Ｓ１０６に示す処理で取得されたアプリケーション安定性評価値データに基づいて、当該アプリケーションが不安定であるか否かを判定する（Ｓ１０７）。

不安定であると判定されなかった場合は（Ｓ１０７：Ｎ）、Ｓ１０５に示す処理に戻る。

不安定であると判定された場合は（Ｓ１０７：Ｙ）、ポリシーマネージャ部９０は、当該アプリケーションに含まれる複数のプロセスのそれぞれについての、プロセス安定性評価値データの出力開始指示を、監視機能部７２に出力する（Ｓ１０８）。すると、監視機能部７２による、プロセス安定性評価値データのデータバス部６８への出力が開始される。

そして、ポリシーマネージャ部９０が、当該アプリケーションに含まれる複数のプロセスのそれぞれについて、当該プロセスの安定性を示すプロセス安定性評価値データがデータバス部６８に出力されることを監視する（Ｓ１０９）。

プロセス安定性評価値データがデータバス部６８に出力されたことを検出すると、ポリシーマネージャ部９０が、当該プロセス安定性評価値データを取得する（Ｓ１１０）。

そして、ポリシーマネージャ部９０が、Ｓ１１０に示す処理で取得されたプロセス安定性評価値データに基づいて、当該プロセスが不安定であるか否かを判定する（Ｓ１１１）。

不安定であると判定されなかった場合は（Ｓ１１１：Ｎ）、Ｓ１０９に示す処理に戻る。

不安定であると判定された場合は（Ｓ１１１：Ｙ）、ポリシーマネージャ部９０は、当該プロセスに係るアクションを実行する（Ｓ１１２）。Ｓ１１２に示す処理では、例えば、当該プロセスの他の仮想マシンへのリプレースが実行される。

そして、ポリシーマネージャ部９０は、出力終了指示を、監視機能部７２に出力する（Ｓ１１３）。すると、監視機能部７２は、上述の、アプリケーション安定性評価値データのデータバス部６８への出力、及び、プロセス安定性評価値データのデータバス部６８への出力を終了する。そして、Ｓ１０１に示す処理に戻る。

本処理例において、Ｓ１０９からＳ１１３に示す処理が実行されている間も、ポリシーマネージャ部９０は、アプリケーション安定性評価値データがデータバス部６８に出力されることを監視してもよい。そして、ポリシーマネージャ部９０が、アプリケーション安定性評価値データがデータバス部６８に出力されたことの検出に応じて、当該アプリケーション安定性評価値データについての、Ｓ１０６以降に示す処理が実行されてもよい。

通信システム１に含まれるプロセスのなかから不安定であるプロセスを抽出するにあたって、それぞれのプロセスについて、当該プロセスが不安定になったか否かを監視すると、監視のための処理負荷が膨大になることがある。

以上で説明したように、本実施形態では、アプリケーションが不安定になったことが検出されるまでは、当該アプリケーションに含まれるプロセスが不安定であるか否かの判定処理は実行されない。

そして、アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かが判定される。

このようにして、本実施形態によれば、通信システム１に含まれるプロセスのなかから不安定であるプロセスを少ない処理負荷で抽出できることとなる。

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

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

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

また、本実施形態に係る機能ユニットがソフトウェアによって実装されている必要はなく、電子回路等のハードウェアによって実装されていてもよい。また、本実施形態に係る機能ユニットが、電子回路とソフトウェアとの組合せによって実装されていてもよい。

本開示に記載の技術は以下のように表現することもできる。
［１］
含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視するアプリケーション監視手段と、
前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定するプロセス不安定判定手段と、
を含むことを特徴とする判定システム。
［２］
前記アプリケーション監視手段は、前記アプリケーションに係る複数の監視項目を監視し、
前記プロセス不安定判定手段は、前記複数の監視項目のうちの所与の監視項目の監視結果が所定の条件を満たしたことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定する、
ことを特徴とする［１］に記載の判定システム。
［３］
前記通信システムに含まれる、複数のアプリケーションが稼働しているクラスタが不安定になったか否かを監視するクラスタ監視手段、をさらに含み、
前記アプリケーション監視手段は、前記クラスタが不安定になったことの検出に応じて、当該クラスタで稼働している複数のアプリケーションのそれぞれが不安定になったか否かの監視を開始する、
ことを特徴とする［１］又は[２]に記載の判定システム。
［４］
前記プロセスが不安定であると判定されることに応じて、当該プロセスに係るアクションを実行するアクション実行手段、をさらに含む、
ことを特徴とする［１］から[３]のいずれか一項に記載の判定システム。
［５］
前記プロセス不安定判定手段は、前記プロセスが不安定であると判定されたことに応じて、当該プロセスが稼働しているハードウェアリソースで稼働している、当該プロセスが稼働している仮想マシンとは異なる仮想マシンで稼働しているプロセスが不安定であるか否かを判定し、
前記アクション実行手段は、前記異なる仮想マシンで稼働しているプロセスが不安定であるか否かの判定結果に応じたアクションを実行する、
ことを特徴とする［４］に記載の判定システム。
［６］
前記アプリケーションは、ネットワークファンクションである、
ことを特徴とする［１］から[５]のいずれか一項に記載の判定システム。
［７］
含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視することと、
前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定することと、
を含むことを特徴とする判定方法。

Claims (7)

1. 含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視するアプリケーション監視手段と、
   前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定するプロセス不安定判定手段と、
   を含む判定システム。
2. 前記アプリケーション監視手段は、前記アプリケーションに係る複数の監視項目を監視し、
   前記プロセス不安定判定手段は、前記複数の監視項目のうちの所与の監視項目の監視結果が所定の条件を満たしたことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定する、
   請求項１に記載の判定システム。
3. 前記通信システムに含まれる、複数のアプリケーションが稼働しているクラスタが不安定になったか否かを監視するクラスタ監視手段、をさらに含み、
   前記アプリケーション監視手段は、前記クラスタが不安定になったことの検出に応じて、当該クラスタで稼働している複数のアプリケーションのそれぞれが不安定になったか否かの監視を開始する、
   請求項１に記載の判定システム。
4. 前記プロセスが不安定であると判定されることに応じて、当該プロセスに係るアクションを実行するアクション実行手段、をさらに含む、
   請求項１に記載の判定システム。
5. 前記プロセス不安定判定手段は、前記プロセスが不安定であると判定されたことに応じて、当該プロセスが稼働しているハードウェアリソースで稼働している、当該プロセスが稼働している仮想マシンとは異なる仮想マシンで稼働しているプロセスが不安定であるか否かを判定し、
   前記アクション実行手段は、前記異なる仮想マシンで稼働しているプロセスが不安定であるか否かの判定結果に応じたアクションを実行する、
   請求項４に記載の判定システム。
6. 前記アプリケーションは、ネットワークファンクションである、
   請求項１に記載の判定システム。
7. 含まれるプロセスが複数の仮想マシンで分散して稼働している、通信システムに含まれるアプリケーションが、不安定になったか否かを監視することと、
   前記アプリケーションが不安定になったことの検出に応じて、当該アプリケーションに含まれる少なくとも１つのプロセスが稼働している複数の仮想マシンのそれぞれについて、当該仮想マシンで稼働しているプロセスが不安定であるか否かを判定することと、
   を含む、１以上のコンピュータによって実行される判定方法。