JP7048691B1 - 運用管理システムおよび運用管理方法 - Google Patents

Abstract

【課題】アプリケーションおよびデータの最適な配置を実現し得る運用管理システムを提供する。【解決手段】センサにより取得されたデータを記憶する第１の記憶部を備える第１のエッジサーバと、データを処理するアプリケーションを備える第２のエッジサーバと、上記第１の記憶部に記憶されているデータが上記アプリケーションにより処理される際、上記データを示す情報と、上記データが記憶されている上記第１の記憶部を示す情報と、上記アプリケーションを示す情報と、上記アプリケーションが設けられている上記第２のエッジサーバを示す情報とを関係付けて関係性情報を生成する情報管理部と、上記情報管理部により生成された関係性情報を出力する出力部と、を設けるようにした。【選択図】図１

Description

本発明は、概して、エッジサーバの運用を管理する技術に関する。

近年ＩｏＴ（Internet of Things）の拡大に伴い、エッジコンピューティングに注目が集まっている。エッジコンピューティングでは、工場等の現場に、センサが接続されたエッジサーバが分散配置され、エッジサーバに設けられているアプリケーションにおいてセンサで取得されたデータの処理が行われる。

しかしながら、増え続けるデータにより、エッジサーバにかかる負荷に偏りが生じたり、ストレージ装置の容量が逼迫したりすることがある。

この点、複数の情報処理装置間での処理負荷の偏りを抑制する技術が開示されている（特許文献１参照）。

特開２０１８－３２０７９号公報

特許文献１に記載の技術では、ディスクＩ／Ｏ（Input / Output）の負荷のみを対象としているので、エッジサーバに設けられているアプリケーションが使用するリソースの負荷については偏りが解消されないことがある。

本発明は、以上の点を考慮してなされたもので、アプリケーションおよびデータの最適な配置を実現し得る運用管理システム等を提案しようとするものである。

かかる課題を解決するため本発明においては、複数のエッジサーバを備え、前記複数のエッジサーバの運用を管理するための運用管理システムであって、センサにより取得されたデータを記憶する第１の記憶部を備える第１のエッジサーバと、データを処理するアプリケーションを備える第２のエッジサーバと、前記第１の記憶部に記憶されているデータが前記アプリケーションにより処理される際、前記データを示す情報と、前記データが記憶されている前記第１の記憶部を示す情報と、前記アプリケーションを示す情報と、前記アプリケーションが設けられている前記第２のエッジサーバを示す情報とを関係付けて関係性情報を生成する情報管理部と、前記情報管理部により生成された関係性情報を出力する出力部と、を設けるようにした。

上記構成では、関係性情報が出力されるので、例えば、アプリケーションとデータとの関係が把握できるようになり、手動でまたは自動で、アプリケーションおよび／またはデータを最適なエッジサーバに配置することができるようになる。

本発明によれば、アプリケーションおよびデータをエッジサーバに最適に配置することができる。

第１の実施の形態による運用管理システムに係る構成の一例を示す図である。 第１の実施の形態による運用管理システムに係るハードウェア構成の一例を示す図である。 第１の実施の形態による運用管理システムに係る機能構成の一例を示す図である。 第１の実施の形態による関係性情報の一例を示す図である。 第１の実施の形態による運用管理システムの特徴的な構成の一例を示す図である。 第１の実施の形態による生成処理の一例を示す図である。 第１の実施の形態によるリソース負荷に基づく最適配置に係る処理の一例を示す図である。 第１の実施の形態によるＩ／Ｏ負荷に基づく最適配置に係る処理の一例を示す図である。 第１の実施の形態による不要データ削除に係る処理の一例を示す図である。 第１の実施の形態によるリソース負荷検出処理の一例を示す図である。 第１の実施の形態による移動アプリ選定処理の一例を示す図である。 第１の実施の形態によるアプリ移動先候補選定処理の一例を示す図である。 第１の実施の形態によるアプリ移動先抽出処理の一例を示す図である。 第１の実施の形態によるアプリおよびデータ移動先決定処理の一例を示す図である。 第１の実施の形態による候補選定処理の一例を示す図である。 第１の実施の形態による移動処理の一例を示す図である。 第１の実施の形態によるＩ／Ｏ負荷検出処理の一例を示す図である。 第１の実施の形態による移動データ選定処理の一例を示す図である。 第１の実施の形態によるデータ移動先候補選定処理の一例を示す図である。 第１の実施の形態によるデータ移動先抽出処理の一例を示す図である。 第１の実施の形態によるデータおよびアプリ移動先決定処理の一例を示す図である。 第１の実施の形態による期間超過削除処理の一例を示す図である。 第１の実施の形態による緊急削除処理の一例を示す図である。

（１）第１の実施の形態
以下、本発明の一実施の形態を詳述する。ただし、本発明は、実施の形態に限定されるものではない。

本実施の形態の運用管理システムは、アプリケーションとデータとの関係性を示す関係性情報を記憶（例えば、データベース化）する。本運用管理システムは、例えば、関係性情報をもとにエッジサーバの処理性能が劣化しないように、アプリケーションとデータとを最適なエッジサーバに配置する。また、例えば、本運用管理システムは、増え続けるデータにより記憶容量が逼迫することを防止するために、関係性情報をもとにデータが不要であるか否かを判定し、不要であると判定したデータを自動削除する。

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

なお、以下の説明では、図面において同一要素については、同じ番号を付し、説明を適宜省略する。また、同種の要素を区別しないで説明する場合には、枝番を含む参照符号のうちの共通部分（枝番を除く部分）を使用し、同種の要素を区別して説明する場合は、枝番を含む参照符号を使用することがある。例えば、エッジサーバを特に区別しないで説明する場合には、「エッジサーバ１２０」と記載し、個々のエッジサーバを区別して説明する場合には、「エッジサーバ１２０－１」、「エッジサーバ１２０－２」のように記載することがある。

図１は、運用管理システム１００に係る構成の一例を示す図である。

運用管理システム１００は、１以上の運用管理サーバ１１０と１以上のエッジサーバ１２０とを含んで構成される。運用管理サーバ１１０およびエッジサーバ１２０は、工場内等の限られた空間にあるコンピュータである。運用管理サーバ１１０とエッジサーバ１２０とは、内部ネットワーク１０１を介して通信可能に接続されている。内部ネットワーク１０１では、プライベートＩＰアドレスが用いられて通信が行われている。

運用管理サーバ１１０は、関係性情報１１１を備える。関係性情報１１１は、エッジサーバ１２０に設けられているアプリケーションとエッジサーバ１２０に記憶されているデータとの関係性を示す情報である。運用管理サーバ１１０は、想定外の要因によってエッジサーバ１２０が停止することなく、エッジサーバ１２０が処理を実行できるように、関係性情報１１１に基づいてエッジサーバ１２０の運用（環境）を管理する。

ここで、エッジサーバ１２０において、アプリケーション、データ等が増加してくると、エッジ―サーバ１２０毎にリソース負荷の偏り、Ｉ／Ｏ負荷の偏り、記憶容量の不足等が発生する。これらを解消するため、運用管理サーバ１１０は、リソース負荷の高いエッジサーバ１２０のアプリケーションをリソース負荷の低いエッジサーバ１２０に移動（配置）したり、Ｉ／Ｏ負荷の高いエッジサーバ１２０のデータをＩ／Ｏ負荷の低いエッジサーバ１２０に移動したりするための指示をエッジサーバ１２０に行う。また、運用管理サーバ１１０は、記憶容量が不足する前に不要なデータを消去するための指示をエッジサーバ１２０に行う。

エッジサーバ１２０には、１以上のセンサ１３０が接続されている。ただし、センサ１３０が接続されていないエッジサーバ１２０があってもよい。エッジサーバ１２０は、センサ１３０から受信したデータをローカルストレージ装置（例えば、後述のストレージ装置２２３）に記憶する。また、エッジサーバ１２０は、所定のストレージ装置（ローカルストレージ装置または外部ストレージ装置）のデータについて、各種の処理を行い、処理の結果のデータを所定のストレージ装置に記憶する。なお、エッジサーバ１２０は、所定のストレージ装置に記憶されたデータを、内部ネットワーク１０１および外部ネットワーク１０２を介してクラウド１０３に送信することもある。外部ネットワーク１０２では、グローバルＩＰアドレスが用いられて通信が行われている。

図２は、運用管理システム１００に係るハードウェア構成の一例を示す図である。

運用管理サーバ１１０は、構成要素として、プロセッサ２１１と、主記憶装置２１２と、ストレージ装置２１３と、入力装置２１４と、出力装置２１５と、通信装置２１６とを備える。

プロセッサ２１１は、演算処理を行う装置である。プロセッサ２１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＡＩ（Artificial Intelligence）チップ等である。

主記憶装置２１２は、プログラム、データ等を記憶する装置である。主記憶装置２１２は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等である。ＲＯＭは、ＳＲＡＭ（Static Random Access Memory）、ＮＶＲＡＭ（Non Volatile RAM）、マスクＲＯＭ（Mask Read Only Memory）、ＰＲＯＭ（Programmable ROM）等である。ＲＡＭは、ＤＲＡＭ（Dynamic Random Access Memory）等である。

ストレージ装置２１３は、ハードディスクドライブ（Hard Disk Drive）、フラッシュメモリ（Flash Memory）、ＳＳＤ（Solid State Drive）、光学式記憶装置等である。光学式記憶装置は、ＣＤ（Compact Disc）、ＤＶＤ(Digital Versatile Disc)等である。ストレージ装置２１３に格納されているプログラム、データ等は、主記憶装置２１２に随時読み込まれる。

入力装置２１４は、ユーザから情報を受付けるユーザインターフェースである。入力装置２１４は、例えば、キーボード、マウス、カードリーダ、タッチパネル等である。

出力装置２１５は、各種の情報を出力（表示出力、音声出力、印字出力等）するユーザインターフェースである。出力装置２１５は、例えば、各種情報を可視化する表示装置、音声出力装置（スピーカ）、印字装置等である。表示装置は、ＬＣＤ（Liquid Crystal Display）、グラフィックカード等である。

通信装置２１６は、通信媒体を介して他の装置と通信する通信インターフェースである。通信装置２１６は、例えば、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（Universal Serial Interface）モジュール、シリアル通信モジュール等である。通信装置２１６は、通信可能に接続する他の装置から情報を受信する入力装置として機能することもできる。また、通信装置２１６は、通信可能に接続する他の装置に情報を送信する出力装置として機能することもできる。

エッジサーバ１２０は、構成要素として、プロセッサ２２１と、主記憶装置２２２と、ストレージ装置２２３と、入力装置２２４と、出力装置２２５と、通信装置２２６とを備える。

エッジサーバ１２０の各構成要素は、運用管理サーバ１１０の各構成要素と同じであるので、その説明については省略する。

図３は、運用管理システム１００に係る機能構成の一例を示す図である。

運用管理サーバ１１０の機能（データ管理部３１１、分析部３１２、完了部３１３等）は、例えば、プロセッサ２１１がストレージ装置２１３に格納されたプログラムを主記憶装置２１２に読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。

なお、運用管理サーバ１１０の１つの機能は、複数の機能に分けられていてもよいし、複数の機能は、１つの機能にまとめられていてもよい。また、運用管理サーバ１１０の機能の一部は、別の機能として設けられてもよいし、他の機能に含められていてもよい。また、運用管理サーバ１１０の機能の一部は、運用管理サーバ１１０と通信可能な他のコンピュータにより実現されてもよい。

エッジサーバ１２０の機能（アプリケーション３２１、監視部３２２、配置部３２３、データ管理部３２４、削除部３２５等）は、例えば、プロセッサ２２１がストレージ装置２２３に格納されたプログラムを主記憶装置２２２に読み出して実行すること（ソフトウェア）により実現されてもよいし、専用の回路等のハードウェアにより実現されてもよいし、ソフトウェアとハードウェアとが組み合わされて実現されてもよい。

付言するならば、アプリケーション３２１は、コンテナ、ＶＭ（Virtual Machine）等のソフトウェアである。以下では、アプリケーション３２１として、コンテナを用いる場合について説明する。また、エッジサーバ１２０は、アプリケーション３２１を備えていなくてもよいし、複数備えていてもよい。また、データ管理部３２４は、データ管理部３１１のエージェントとして動作する機能である。

なお、エッジサーバ１２０の１つの機能は、複数の機能に分けられていてもよいし、複数の機能は、１つの機能にまとめられていてもよい。また、エッジサーバ１２０の機能の一部は、別の機能として設けられてもよいし、他の機能に含められていてもよい。また、エッジサーバ１２０の機能の一部は、エッジサーバ１２０と通信可能な他のコンピュータにより実現されてもよい。

図４は、関係性情報１１１の一例（関係性テーブル４００）を示す図である。以下では、関係性情報１１１として関係性テーブル４００を例に挙げて説明する。

関係性テーブル４００は、データ識別子４０１と、取得日時４０２と、ストレージ識別子４０３と、保管場所４０４と、アプリ識別子４０５と、リソース要求量４０６と、アプリ稼働場所４０７と、アクセス速度４０８と、リソース競合発生４０９と、Ｉ／Ｏ競合発生４１０と、処理ラベル４１１と、保管期間４１２と、グループラベル４１３と、削除予定時間４１４との情報を含んで構成される。

データ識別子４０１は、運用管理システム１００におけるデータを識別可能な情報である。取得日時４０２は、当該データがセンサ１３０またはアプリケーション３２１から取得された日時を示す情報である。ストレージ識別子４０３は、当該データが記憶される物理領域（例えば、ストレージ装置２２３）を識別可能な情報（例えば、ストレージ名）である。保管場所４０４は、当該データが記憶される論理領域（例えば、ボリューム）を識別可能な情報（例えば、ボリューム名）である。アプリ識別子４０５は、当該データを使用したアプリケーション３２１を識別可能な情報（例えば、アプリケーション名）である。

リソース要求量４０６は、当該データを処理するアプリケーション３２１に必要となるリソースのリソース量（リソース要求量）を示す情報（１Ｇｈｚ、２ＧＢ等）である。リソースとは、エッジサーバ１２０のハードウェア資源であり、プロセッサ２２１、主記憶装置２２２等である。アプリ稼働場所４０７は、当該データを使用するアプリケーション３２１が稼動する場所（例えば、エッジサーバ１２０）を識別可能な情報（例えば、サーバ名）である。アクセス速度４０８は、当該データへのアクセスの速さを示す情報である。

リソース競合発生４０９は、リソース競合を示す情報である。リソース競合とは、複数のアプリケーション３２１で要求するリソース量（リソース要求量）が、エッジサーバ１２０が供給可能なリソース量（供給量）を超えることをいう。Ｉ／Ｏ競合発生４１０は、Ｉ／Ｏ競合を示す情報である。Ｉ／Ｏ競合とは、複数のアプリケーション３２１が同じデータに一斉（同時または略同時）にアクセスすること、または、複数のアプリケーション３２１がストレージ装置２２３にＩ／Ｏを要求し、当該ストレージ装置２２３の性能以上にＩ／Ｏ負荷がかかることでアクセスにかかる時間が長くなることをいう。

処理ラベル４１１は、当該データの処理に応じて付与されるラベルを示す情報である。保管期間４１２は、当該データが保管される期間を示す情報である。なお、保管期間４１２の情報は、時間の経過と共に減少していくので、残りの保管期間と記すことがある。グループラベル４１３は、当該データが属するグループを識別可能な情報である。グループは、１つまたは複数のアプリケーション３２１による一連の処理で用いられるデータ範囲である。例えば、１つのアプリケーション３２１で複数のデータが処理される場合、当該複数のデータは、同じグループに属する。また、例えば、複数のアプリケーション３２１で複数のデータが処理される場合、当該複数のデータは、同じグループに属する。なお、以下では、１つのアプリケーション３２１で複数のデータが処理される場合を例に挙げて説明する。削除予定時間４１４は、当該データが削除される予定の時間を示す情報である。本例では、削除予定時間４１４には、残りの保管期間が「０」になる時間が設定される。

なお、関係性テーブル４００については、運用管理サーバ１１０に設けられる構成に限るものではなく、各エッジサーバ１２０に設けられて同期がとられる構成であってもよい。

図５は、運用管理システム１００の特徴的な構成の一例を示す図である。

運用管理システム１００は、関係性テーブル４００を生成して記憶する（関係性テーブル生成５００）。関係性テーブル４００によれば、システム管理者により（手動で）または運用管理サーバ１１０およびエッジサーバ１２０により（自動で）、アプリケーション３２１およびデータを最適な場所に配置すること（最適配置５１０）ができるようになる。また、関係性テーブル４００によれば、手動でまたは自動で、不要なデータを削除すること（不要データ削除５２０）ができるようになる。

＜関係性テーブル生成５００＞
データ管理部３１１は、データとアプリケーション３２１との関係と、当該データと当該データの記憶場所との関係、および当該アプリケーション３２１と当該アプリケーション３２１の動作場所との関係を示す情報を関係性テーブル４００に記憶する。

＜最適配置５１０＞
監視部３２２は、エッジサーバ１２０の負荷（リソース負荷およびＩ／Ｏ負荷）を監視する。監視部３２２は、エッジサーバ１２０の負荷が閾値を超過したことを検出すると、閾値超過を検出したこと（超過検出情報）を分析部３１２に送信する。分析部３１２は、超過検出情報を受信すると、関係性テーブル４００をもとに、閾値超過が検出されたエッジサーバ１２０の処理性能を落とさないように、当該エッジサーバ１２０の移動対象のアプリケーション３２１および／または当該アプリケーション３２１が使用するデータの最適なエッジサーバ１２０を導出する。配置部３２３は、分析部３１２が決定した場所に移動対象のアプリケーション３２１および／または当該アプリケーション３２１が使用するデータを移動する。

上記構成によれば、アプリケーション３２１だけまたはデータだけでなく、アプリケーション３２１とデータとの両方を最適な場所に配置させることで、アプリケーション３２１の処理性能の劣化とデータへのアクセス速度の劣化とをより抑制することができる。

＜不要データ削除５２０＞
データ管理部３２４は、センサ１３０から送られてきたデータに未処理ラベルを付与することをデータ管理部３２４に指示する。データ管理部３１１は、当該データに未処理ラベルを付与したことを関係性テーブル４００に反映する。

完了部３１３は、アプリケーション３２１が一連の処理を完了したことをデータ管理部３１１に送信する。データ管理部３１１は、一連の処理に用いられたデータに保管ラベルを付与したことを関係性テーブル４００に反映し、一連の処理で生成されたデータに対して未処理ラベルを付与したことを反映する。さらに、データ管理部３１１は、当該データにグループラベルを付与して保管期間（ＴＴＬ）を設定したことを関係性テーブル４００に反映する。

データ管理部３１１は、保管期間を経過したデータについては、保管ラベルから削除ラベルに関係性テーブル４００を更新する。

削除部３２５は、削除ラベルが付与されたデータに対して所定の時間（例えば、１２時間）以内にアクセスがない場合、当該データと同一グループラベルが付されたデータ群を自動削除する。なお、所定の時間のデフォルト値を１２時間に設定しているが、設定値の変更は可能である。また、処理前データ（センサ１３０から受信した生データなど、アプリケーション３２１により処理が行われていないデータ）、処理後データ（アプリケーション３２１により処理が行われたデータ）等のデータの種類ごとの設定も可能である。

上記構成によれば、不要なデータを自動削除して空き容量を確保することで、記憶容量が不足することによるアクセスエラー、書き込みエラー等、ストレージ装置２２３に起因するデータ処理エラーを回避し、安定稼働および運用コストの削減が可能になる。

運用管理システム１００によれば、アプリケーション３２１およびデータが増減したとしても、エッジサーバ１２０を適切に運用することができるようになる。

図６は、関係性テーブル生成５００に係る処理（生成処理）の一例を示す図である。生成処理は、所定のタイミングで行われる。なお、所定のタイミングは、リアルタイムであってもよいし、周期的であってもよし、予め指定された時間であってもよいし、システム管理者により指示されたタイミングであってもよい。

Ｓ６０１では、データ管理部３２４は、センサ１３０からデータを取得する。なお、データの取得については、センサ１３０が所定のタイミングでデータを送信するものであってもよいし、データ管理部３２４がセンサ１３０にデータを要求して当該データを受信するものであってもよい。

また、例えば、Ｓ６０１では、データ管理部３２４は、当該データを当該データのデータ識別子と共にストレージ装置２２３に記憶する。データ管理部３２４は、取得したデータの情報をデータ管理部３１１に送信する。当該データの情報には、当該データのデータ識別子、当該データの取得日時、当該データを記憶したストレージ装置２２３のストレージ名、当該データを記憶したボリュームのボリューム名等が含まれる。

Ｓ６０２では、データ管理部３１１は、データ管理部３２４により取得されたデータの情報を関係性テーブル４００に記憶する。

Ｓ６０３では、データ管理部３２４は、アプリケーション３２１の情報を取得する。例えば、アプリケーション３２１によりストレージ装置２２３に記憶されているデータ（処理前データ）が処理されて新たにデータ（処理後データ）が生成されてストレージ装置２２３に記憶された場合、データ管理部３２４は、当該処理前データの情報と当該処理後データの情報とを取得する。当該処理前データの情報には、当該処理前データを使用したアプリケーション３２１のアプリ名、当該アプリケーション３２１が稼動しているエッジサーバ１２０のサーバ名等の情報が含まれる。当該処理後データの情報には、当該処理後データのデータ識別子、当該処理後データの取得日時、当該処理後データを記憶したストレージ装置２２３のストレージ名、当該処理後データを記憶したボリュームのボリューム名等が含まれる。

Ｓ６０４では、データ管理部３１１は、データ管理部３２４により取得されたアプリケーション３２１の情報を関係性テーブル４００に記憶する。

図７～図９は、最適配置５１０および不要データ削除５２０に係るシーケンス図の一例を示す図である。

図７は、リソース負荷に基づく最適配置５１０に係る処理の一例を示す図である。

Ｓ７０１では、監視部３２２は、リソース負荷の閾値超過を検出する処理（リソース負荷検出処理）を行う。監視部３２２は、リソース負荷の閾値超過を検出した場合、リソース負荷の閾値超過を検出したことを分析部３１２に送信する。なお、リソース負荷検出処理については、図１０を用いて後述する。

Ｓ７０２では、分析部３１２は、リソース競合が発生したデータについて、リソース競合が発生したことを示す情報を関係性テーブル４００（リソース競合発生４０９）に登録する。

Ｓ７０３では、分析部３１２は、関係性テーブル４００を読み込む。

Ｓ７０４では、分析部３１２は、移動するアプリケーション３２１を選定する処理（移動アプリ選定処理）を行う。なお、移動アプリ選定処理については、図１１を用いて後述する。

Ｓ７０５では、分析部３１２は、Ｓ７０４で選定したアプリケーション３２１を移動するエッジサーバ１２０（移動先）の候補を選定する処理（アプリ移動先候補選定処理）を行う。なお、アプリ移動先候補選定処理については、図１２を用いて後述する。

Ｓ７０６では、分析部３１２は、Ｓ７０５で選定した移動先の候補からアプリケーション３２１の移動先を抽出する処理（アプリ移動先抽出処理）を行う。なお、アプリ移動先抽出処理については、図１３を用いて後述する。

Ｓ７０７では、分析部３１２は、アプリケーション３２１の移動先を抽出できたか否かを判定する。分析部３１２は、アプリケーション３２１の移動先を抽出できたと判定した場合、Ｓ７０９に処理を移し、アプリケーション３２１の移動先を抽出できなかったと判定した場合、Ｓ７０８に処理を移す。付言するならば、分析部３１２は、アプリケーション３２１の移動だけで最適配置になると判定した場合、Ｓ７０９に処理を移し、アプリケーション３２１の移動とデータの移動とにより最適配置になると判定した場合、Ｓ７０８に処理を移す。

Ｓ７０８では、分析部３１２は、Ｓ７０４で選定したアプリケーション３２１と当該アプリケーション３２１が使用するデータとに最適な移動先を決定する処理（アプリおよびデータ移動先決定処理）を行う。なお、アプリおよびデータ移動先決定処理については、図１４および図１５を用いて後述する。

Ｓ７０９では、分析部３１２は、Ｓ７０４で選定したアプリケーション３２１の移動先の情報、または、Ｓ７０８で決定した当該アプリケーション３２１および当該アプリケーション３２１が使用するデータの移動先の情報を配置部３２３に送信する。

Ｓ７１０では、配置部３２３は、受信した移動先の情報をもとに、Ｓ７０４で選定したアプリケーション３２１、または、Ｓ７０８で決定した当該アプリケーション３２１および当該アプリケーション３２１が使用するデータを移動する処理（移動処理）を行う。なお、移動処理については、図１６を用いて後述する。

図８は、Ｉ／Ｏ負荷に基づく最適配置５１０に係る処理の一例を示す図である。

Ｓ８０１では、監視部３２２は、Ｉ／Ｏ負荷の閾値超過を検出する処理（Ｉ／Ｏ負荷検出処理）を行う。監視部３２２は、Ｉ／Ｏ負荷の閾値超過を検出した場合、Ｉ／Ｏ負荷の閾値超過を検出したことを分析部３１２に送信する。なお、Ｉ／Ｏ負荷検出処理については、図１７を用いて後述する。

Ｓ８０２では、分析部３１２は、Ｉ／Ｏ競合が発生したデータについて、Ｉ／Ｏ競合が発生したことを示す情報を関係性テーブル４００（Ｉ／Ｏ競合発生４１０）に登録する。

Ｓ８０３では、分析部３１２は、関係性テーブル４００を読み込む。

Ｓ８０４では、分析部３１２は、移動するデータを選定する処理（移動データ選定処理）を行う。なお、移動データ選定処理については、図１８を用いて後述する。

Ｓ８０５では、分析部３１２は、Ｓ８０４で選定したデータを移動するボリューム（移動先）の候補を選定する処理（データ移動先候補選定処理）を行う。なお、データ移動先候補選定処理については、図１９を用いて後述する。

Ｓ８０６では、分析部３１２は、Ｓ８０５で選定した移動先の候補からデータの移動先を抽出する処理（データ移動先抽出処理）を行う。なお、データ移動先抽出処理については、図２０を用いて後述する。

Ｓ８０７では、分析部３１２は、データの移動先を抽出できたか否かを判定する。分析部３１２は、データの移動先を抽出できたと判定した場合、Ｓ８０９に処理を移し、データの移動先を抽出できなかったと判定した場合、Ｓ８０８に処理を移す。付言するならば、分析部３１２は、データの移動だけで最適配置になると判定した場合、Ｓ８０９に処理を移し、データの移動とアプリケーション３２１の移動とにより最適配置になると判定した場合、Ｓ８０８に処理を移す。

Ｓ８０８では、分析部３１２は、Ｓ８０４で選定したデータと当該データを使用するアプリケーション３２１とに最適な移動先を決定する処理（データおよびアプリ移動先決定処理）を行う。なお、データおよびアプリ移動先決定処理については、図２１等を用いて後述する。

Ｓ８０９では、分析部３１２は、Ｓ８０４で選定したデータの移動先の情報、または、Ｓ８０８で決定した当該データおよび当該データを使用するアプリケーション３２１の移動先の情報を配置部３２３に送信する。

Ｓ８１０では、配置部３２３は、受信した移動先の情報をもとに、Ｓ８０４で選定したデータの移動先の情報、または、Ｓ８０８で決定した当該データおよび当該データを使用するアプリケーション３２１を移動する処理（移動処理）を行う。なお、移動処理については、図１６を用いて後述する。

図９は、不要データ削除５２０に係る処理の一例を示す図である。

Ｓ９０１では、センサ１３０は、測定（取得）したデータをデータ管理部３２４に送信する。

Ｓ９０２では、データ管理部３２４は、受信したデータに未処理ラベルを付与することをデータ管理部３１１に指示し、データ管理部３１１は、当該データに未処理ラベルを付与したことを示す情報を関係性テーブル４００（処理ラベル４１１）に登録する。

Ｓ９１１では、アプリケーション３２１は、ストレージ装置２２３に記憶されているデータである処理前データと、当該処理前データを処理したデータである処理後データとをデータ管理部３２４に送信する。

Ｓ９１２では、データ管理部３２４は、処理前データに処理ラベルを付与することをデータ管理部３１１に指示し、処理後データに未処理ラベルを付与することをデータ管理部３１１に指示する。データ管理部３１１は、処理前データに処理ラベルを付与したことを示す情報と、処理後データに未処理ラベルを付与したことを示す情報とを関係性テーブル４００（処理ラベル４１１）に登録する。

Ｓ９２０では、期間超過削除処理が行われる。期間超過削除処理については、Ｓ９２１～Ｓ９２７および図２２を用いて説明する。

Ｓ９２１では、完了部３１３は、アプリケーション３２１による一連の処理が完了したこと（例えば、一連の処理に係るデータのデータ識別子）をデータ管理部３１１に送信する。

Ｓ９２２では、データ管理部３１１は、受信したデータ識別子のデータに保管ラベルを付与したことを示す情報を関係性テーブル４００（処理ラベル４１１）に登録する。

Ｓ９２３では、データ管理部３１１は、受信したデータ識別子のデータにグループラベルを付与したことを示す情報を関係性テーブル４００（グループラベル４１３）に登録する。

Ｓ９２４では、データ管理部３１１は、受信したデータ識別子のデータに保管期間を設定したことを示す情報を関係性テーブル４００（保管期間４１２）に登録する。

Ｓ９２５では、データ管理部３１１は、保管期間を経過したデータに削除ラベルを付与したことを示す情報を関係性テーブル４００（処理ラベル４１１）に登録する。

Ｓ９２６では、データ管理部３１１は、削除ラベルが付与されたデータのうち、所定の時間が経過したデータを検出し、検出したデータを削除するように削除部３２５に指示する。

Ｓ９２７では、削除部３２５は、削除ラベルが付与されたデータのうち、所定の時間が経過したデータをストレージ装置２２３から削除する。

Ｓ９３０では、緊急削除処理が行われる。緊急削除処理については、Ｓ９３１、Ｓ９３２、図２２を用いて説明する。

Ｓ９３１では、データ管理部３１１，３２４は、緊急削除するデータを選定し、選定したデータを削除するように削除部３２５に指示する。

Ｓ９３２では、削除部３２５は、緊急削除するデータをストレージ装置２２３から削除する。

図１０は、リソース負荷検出処理の一例を示す図である。

Ｓ１００１では、監視部３２２は、リソース負荷が閾値を超過したことを検出する。例えば、監視部３２２は、アプリケーション３２１のリソース要求量が、エッジサーバ１２０が供給可能なリソースのリソース量（リソース供給量）を超えたことを検出した場合、検出したことを分析部３１２に送信する。

Ｓ１００２では、監視部３２２は、リソース負荷が閾値を超過したことを検出した場合、リソース競合が発生したかを検出する。監視部３２２は、リソース競合が発生したことを検出した場合、分析部３１２にリソース競合の情報を送信する。リソース競合の情報には、リソース競合に係るアプリケーション３２１のアプリ名、当該アプリケーション３２１が使用していたデータのデータ識別子等が含まれている。

Ｓ１００３では、分析部３１２は、リソース競合に係るデータのそれぞれについて、関係性テーブル４００のリソース競合発生４０９に一意の文字列を登録する。なお、リソース競合の情報の関係性テーブル４００への登録は、データ管理部３１１，３２４により行われてもよい。

図１１は、移動アプリ選定処理の一例を示す図である。

Ｓ１１０１では、分析部３１２は、分析対象のエッジサーバ１２０が備えているアプリケーション３２１の候補をリスト化（アプリリストを生成）する。なお、分析対象のエッジサーバ１２０は、リソース負荷が閾値を超過したことが検出されたエッジサーバ１２０である。

Ｓ１１０２では、分析部３１２は、アプリリストの候補をソート（整列）する。例えば、分析部３１２は、リソース要求量が大きい順に候補をソートし、リソース要求量が同じ候補がある場合、Ｉ／Ｏが小さい順に候補をソートする。

Ｓ１１０３では、分析部３１２は、アプリリストの一番上の候補を移動対象として選定する。

このように、リソース要求量が最も大きいアプリケーション３２１を移動対象として選定して移動することで、分析対象のエッジサーバ１２０でリソース負荷の閾値超過が直ぐに発生してしまう事態を回避できるようになる。また、Ｉ／Ｏが小さいアプリケーション３２１を移動対象とすることで、当該アプリケーション３２１によるＩ／Ｏが頻繁に発生して当該アプリケーション３２１を移動できない事態を回避できるようになる。

図１２は、アプリ移動先候補選定処理の一例を示す図である。

Ｓ１２０１では、分析部３１２は、移動対象のアプリケーション３２１を移動するエッジサーバ１２０（移動先）の候補をリスト化（サーバリストを生成）する。例えば、分析部３１２は、移動対象のアプリケーション３２１のリソース要求量以上の空きリソース量（リソース空き量）を持つエッジサーバ１２０を移動先の候補とする。なお、移動対象のアプリケーション３２１は、Ｓ１１０３で選定されたアプリケーション３２１である。

Ｓ１２０２では、分析部３１２は、関係性テーブル４００を参照し、移動対象のアプリケーション３２１が、各候補のエッジサーバ１２０上で動いているアプリケーション３２１とリソース競合が発生したことがあるか否かを判定する。分析部３１２は、リソース競合が発生したことがあると判定した場合、Ｓ１２０３に処理を移し、リソース競合が発生したことがないと判定した場合、Ｓ１２０４に処理を移す。

Ｓ１２０３では、分析部３１２は、サーバリストの中から、リソース競合が発生した候補を除外する。

Ｓ１２０４では、分析部３１２は、移動対象のアプリケーション３２１の稼働実績の有無でサーバリストの候補をソートする。例えば、分析部３１２は、当該アプリケーション３２１を一度でも稼働したことがある候補を上位に、当該アプリケーション３２１を一度も稼働したことがない候補を下位にソートする。

Ｓ１２０５では、分析部３１２は、移動先のエッジサーバ１２０からのデータ（移動対象のアプリケーション３２１が使用するデータ）へのアクセス速度を算出する。例えば、分析部３１２は、データの容量とネットワーク帯域幅とからアクセス速度を算出する。

図１３は、アプリ移動先抽出処理の一例を示す図である。

ここで、アプリケーション３２１とデータとの対応関係については、１対１または１対多の２つのケースが想定される。

１対１のケースでは、アプリケーション３２１が設けられているエッジサーバ１２０からのアクセス速度と、アプリケーション３２１の移動先のエッジサーバ１２０からのアクセス速度とを比較して、現状より速くなるまたは現状と同等である場合は、アプリケーション３２１を移動させる。

１対多のケースでは、１つのデータへのアクセス速度のみの判定でアプリケーション３２１を移動させてしまい、監視部３２２で更新された情報をもとに、再度アプリケーション３２１の配置を実施してもよい。また、アプリケーション３２１の移動先のエッジサーバ１２０から各データへのアクセス速度を全パターン計算して、全てが速くなる場合に移動させてもよいし、または、多数決で半数が速くなる場合に移動させてもよい。

Ｓ１３０１では、分析部３１２は、アクセス速度の速い順にサーバリストの候補をソートする。そして、分析部３１２は、アクセス速度が移動元より速い候補が見つかるか、全ての候補を比較し終えるまで、Ｓ１３０２～Ｓ１３０４の処理を繰り返す。

Ｓ１３０２では、分析部３１２は、サーバリストから未処理の候補を１つ選択する。

Ｓ１３０３では、分析部３１２は、選択した候補からのアクセス速度が移動元からのアクセス速度よりも遅いか否かを判定する。分析部３１２は、遅いと判定した場合、Ｓ１３０４に処理を移し、遅くないと判定した場合（速いまたは同等と判定した場合）、Ｓ１３０５に処理を移す。

Ｓ１３０４では、分析部３１２は、Ｓ１３０２で選択した候補をサーバリストに残し、Ｓ１３０２に処理を移す。なお、サーバリストに候補が残った場合は、続いて、図１４の処理が行われる。

Ｓ１３０５では、分析部３１２は、アクセス速度が移動元より速いまたは同等と判定したエッジサーバ１２０のサーバ名を移動先として抽出（取得）する。なお、サーバ名が取得された場合は、続いて、図１６の移動処理が行われる。

図１４は、アプリおよびデータ移動先決定処理の一例を示す図である。

Ｓ１４０１では、分析部３１２は、サーバリストから未処理の候補を１つ選択する。

Ｓ１４０２では、分析部３１２は、移動対象のデータの中から、削除ラベルが付与されているデータを移動対象から外す。なお、移動対象のデータは、移動対象のアプリケーション３２１が使用するデータである。

Ｓ１４０３では、分析部３１２は、運用管理システム１００に設けられているボリュームのうち、空き容量が移動対象のデータの容量以上あるボリュームの候補をリスト化（ボリュームリストを生成）する。

Ｓ１４０４では、分析部３１２は、Ｉ／Ｏ競合が発生したことのある候補をボリュームリストから削除する。

Ｓ１４０５では、分析部３１２は、各ボリュームの候補と移動先のエッジサーバ１２０の候補とにおけるデータへのアクセス速度を算出する。例えば、分析部３１２は、データの容量とネットワーク帯域幅とからアクセス速度を算出する。

Ｓ１４０６では、分析部３１２は、候補選定処理を行う。候補選定処理では、データへのアクセス速度が移動元のボリュームのアクセス速度よりも速いボリュームの候補が選定される。候補選定処理については、図１５を用いて後述する。

Ｓ１４０７では、分析部３１２は、ボリュームリストに候補があるか否かを判定する。分析部３１２は、ボリュームリストに候補があると判定した場合、Ｓ１４０８に処理を移し、ボリュームリストに候補がないと判定した場合、Ｓ１４０１に処理を移す。

Ｓ１４０８では、分析部３１２は、アクセス速度が速い順にボリュームリストの候補をソートする。

Ｓ１４０９では、分析部３１２は、各ボリュームの候補へのデータの移動時間を算出する。例えば、分析部３１２は、各ボリュームの候補へのデータの移動時間をデータの容量とネットワーク帯域幅とから算出する。

Ｓ１４１０では、分析部３１２は、データの移動時間が短い順にボリュームリストの候補をソートする。

Ｓ１４１１では、分析部３１２は、ボリュームリストの一番上の候補を移動先に決定する。

Ｓ１４１２では、分析部３１２は、Ｓ１４０７においてボリュームリストに候補があると判定したときのエッジサーバ１２０の候補を移動先として決定する。

図１５は、候補選定処理の一例を示す図である。分析部３１２は、リスト（ボリュームリストまたはサーバリスト）の全ての候補について、Ｓ１５０１～Ｓ１５０４の処理を行う。なお、当該リストは、Ｓ１４０６から呼び出される候補選定処理では、ボリュームリストであり、Ｓ２１０４から呼び出される候補選定処理では、サーバリストである。

Ｓ１５０１では、分析部３１２は、リストから未処理の候補を１つ選択する。

Ｓ１５０２では、分析部３１２は、Ｓ１５０１で選択した移動先の候補のアクセス速度が移動元のアクセス速度より速いか否かを判定する。分析部３１２は、速いと判定した場合（新しいアクセス速度 ＞≒元のアクセス速度）、Ｓ１５０３に処理を移し、速くないと判定した場合、Ｓ１５０４に処理を移す。

Ｓ１５０３では、分析部３１２は、Ｓ１５０１で選択した候補をリストに残し、Ｓ１５０１に処理を移す。

Ｓ１５０４では、分析部３１２は、Ｓ１５０１で選択した候補をリストから除外し、Ｓ１５０１に処理を移す。

図１６は、移動処理の一例を示す図である。

Ｓ１６０１では、配置部３２３は、移動対象のデータへのアクセスがあるか否かを判定する。配置部３２３は、移動対象のデータへのアクセスがあると判定した場合、Ｓ１６０２に処理を移し、移動対象のデータへのアクセスがないと判定した場合、Ｓ１６０３に処理を移す。

Ｓ１６０２では、配置部３２３は、移動対象のデータを移動予定のボリュームにシャドーコピーする。配置部３２３は、移動元のストレージ装置２２３にある移動対象のデータへのアクセスがなくなった場合、移動対象のデータを削除する。

Ｓ１６０３では、配置部３２３は、移動対象のデータ（例えば、グループラベルごとのデータ）を移動先のボリュームに移動する。

Ｓ１６０４では、配置部３２３は、移動対象のアプリケーション３２１を移動先のエッジサーバ１２０に移動する。

Ｓ１６０５では、配置部３２３は、移動が完了したことを分析部３１２に送信する。

Ｓ１６０５では、データ管理部３１１，３２４は、関係性テーブル４００（ストレージ識別子４０３、保管場所４０４、アプリ稼働場所４０７等）を移動先に更新する。

図１７は、Ｉ／Ｏ負荷検出処理の一例を示す図である。

Ｓ１７０１では、監視部３２２は、Ｉ／Ｏ負荷が閾値を超過したことを検出する。例えば、監視部３２２は、ＩＯＰＳ（Input / Output Per Second）が所定の値より低下したことを検出した場合、検出したことを分析部３１２に送信する。

Ｓ１７０２では、監視部３２２は、Ｉ／Ｏ負荷が閾値を超過したことを検出した場合、Ｉ／Ｏ競合が発生したかを検出する。監視部３２２は、Ｉ／Ｏ競合が発生したことを検出した場合、分析部３１２にＩ／Ｏ競合の情報を送信する。Ｉ／Ｏ競合の情報には、Ｉ／Ｏ競合に係るアプリケーション３２１のアプリ名、当該アプリケーション３２１が使用していたデータのデータ識別子等が含まれている。

Ｓ１７０３では、分析部３１２は、Ｉ／Ｏ競合が発生したアプリケーション３２１のそれぞれについて、関係性テーブル４００のＩ／Ｏ競合発生４１０に一意の文字列を登録する。なお、Ｉ／Ｏ競合の情報の関係性テーブル４００への登録は、データ管理部３１１，３２４により行われてもよい。

図１８は、移動データ選定処理の一例を示す図である。

Ｓ１８０１では、分析部３１２は、分析対象のストレージ装置２２３のデータをリスト化（データリストを生成）する。分析対象のストレージ装置２２３は、Ｉ／Ｏ負荷が閾値を超過したことが検出されたストレージ装置２２３である。

Ｓ１８０２では、分析部３１２は、データリストの候補をソートする。例えば、分析部３１２は、Ｉ／Ｏが小さい順に候補をソートし、同じＩ／Ｏの候補がある場合、データ容量が小さい順に候補をソートする。

Ｓ１８０３では、分析部３１２は、データリストの一番上のデータを移動対象として選定する。この際、分析部３１２は、選定したデータに関係付けられているアプリケーション３２１が使用する全てのデータ、または、選定したデータと同じグループラベルが付与されたデータを移動対象のデータとして選定する。

このように、Ｉ／Ｏが小さいデータを移動対象とすることで、当該データに対するＩ／Ｏが頻繁に発生して当該データを移動できない事態を回避できるようになる。また、データ容量が小さいデータを移動対象とすることで、当該データの移動にかかる時間を短縮することができるようになる。

図１９は、データ移動先候補選定処理の一例を示す図である。

Ｓ１９０１では、分析部３１２は、移動対象のデータから、削除ラベルが付与されているデータを外す。

Ｓ１９０２では、分析部３１２は、空き容量が移動対象のデータ量以上あるボリュームを移動先の候補としてリスト化（ボリュームリストを生成）する。

Ｓ１９０３では、分析部３１２は、関係性テーブル４００を参照し、ボリュームの候補に記憶されているデータが移動対象のデータとＩ／Ｏ競合が発生したことがあるか否かを判定する。分析部３１２は、Ｉ／Ｏ競合が発生したことがあると判定した場合、Ｓ１９０４に処理を移し、Ｉ／Ｏ競合が発生したことがないと判定した場合、Ｓ１９０５に処理を移す。

Ｓ１９０４では、分析部３１２は、Ｉ／Ｏ競合が発生したことのある候補をボリュームリストから除外する。

Ｓ１９０５では、分析部３１２は、Ｉ／Ｏ競合が１回目であるか否かを判定する。分析部３１２は、Ｉ／Ｏ競合が１回目であると判定した場合、Ｓ１９０６に処理を移し、Ｉ／Ｏ競合が１回目でないと判定した場合、Ｓ１９０８に処理を移す。なお、図示は省略するが、データ管理部３１１は、Ｉ／Ｏ競合が発生した回数を示す情報（例えば、履歴情報）を記憶している。

Ｓ１９０６では、分析部３１２は、各候補へのデータの移動時間を算出する。例えば、分析部３１２は、各候補へのデータの移動時間をデータの容量とネットワーク帯域幅とから算出する。

Ｓ１９０７では、分析部３１２は、データの移動時間が短い順にボリュームリストの候補をソートする。

Ｓ１９０８では、分析部３１２は、各候補へのアクセス速度を算出する。例えば、分析部３１２は、データの容量とネットワーク帯域幅とから各候補へのアクセス速度を算出する。

図２０は、データ移動先抽出処理の一例を示す図である。

ここで、データとアプリケーション３２１との対応関係については、１対１または１対多の２つのケースが想定される。

１対１のケースでは、データを使用するアプリケーション３２１を備えるエッジサーバ１２０からの移動元のデータへのアクセス速度と当該エッジサーバ１２０からの移動先のデータへのアクセス速度とを比較して、現状より速くなるまたは現状と同等である場合は、データを移動させる。

１対多のケースでは、１つのアプリケーション３２１へのアクセス速度のみの判定でデータを移動させてしまい、監視部３２２で更新された情報をもとに、再度データの配置を実施してもよい。また、各アプリケーション３２１が設けられているエッジサーバ１２０からデータへのアクセス速度を全パターン計算して、全てが速くなる場合に移動させてもよいし、または、多数決で半数が速くなる場合に移動させてもよい。

Ｓ２００１では、分析部３１２は、アクセス速度の速い順にボリュームリストの候補をソートする。そして、分析部３１２は、アクセス速度が移動元より速い候補が見つかるか、全ての候補を比較し終えるまで、Ｓ２００２～Ｓ２００４の処理を繰り返す。

Ｓ２００２では、分析部３１２は、ボリュームリストから未処理の候補を１つ選択する。

Ｓ２００３では、分析部３１２は、Ｓ２００２で選択した候補のアクセス速度が移動元のアクセス速度よりも遅いか否かを判定する。分析部３１２は、遅いと判定した場合、Ｓ２００４に処理を移し、遅くないと判定した場合（速いまたは同等と判定した場合）、Ｓ２００５に処理を移す。

Ｓ２００４では、分析部３１２は、Ｓ２００２で選択した候補をボリュームリストに残し、Ｓ２００２に処理を移す。なお、ボリュームリストに候補が残った場合は、続いて、図２１の処理が行われる。

Ｓ２００５では、分析部３１２は、アクセス速度が移動元より速いまたは同等と判定したボリュームのボリューム名を移動先として抽出（取得）する。なお、ボリューム名が取得された場合は、続いて、図１６の移動処理が行われる。

図２１は、データおよびアプリ移動先決定処理の一例を示す図である。

Ｓ２１０１では、分析部３１２は、移動対象のデータを使用するアプリケーション３２１を移動可能なエッジサーバ１２０の候補をリスト化（サーバリストを生成）し、アプリ移動先抽出処理を行う。

Ｓ２１０２では、分析部３１２は、ボリュームリストから未処理のボリュームの候補を１つ選択する。

Ｓ２１０３では、分析部３１２は、各エッジサーバ１２０の候補と移動先のボリュームの候補とにおけるデータへのアクセス速度を算出する。例えば、分析部３１２は、データの容量とネットワーク帯域幅とからアクセス速度を算出する。

Ｓ２１０４では、分析部３１２は、候補選定処理を行う。

Ｓ２１０５では、分析部３１２は、サーバリストに候補があるか否かを判定する。分析部３１２は、サーバリストに候補があると判定した場合、Ｓ２１０６に処理を移し、サーバリストに候補がないと判定した場合、Ｓ２１０２に処理を移す。

Ｓ２１０６では、分析部３１２は、アクセス速度が速い順にサーバリストの候補をソートする。

Ｓ２１０７では、分析部３１２は、サーバリストの一番上の候補を移動先に決定する。

Ｓ２１０８では、分析部３１２は、Ｓ２１０５においてサーバリストに候補があると判定したときのボリュームの候補を移動先として決定する。

図２２は、期間超過削除処理の一例を示す図である。

Ｓ２２０１では、完了部３１３は、正常なフローで終了したこと（正常終了）を検出する。正常なフローとは、例えば、アプリケーション３２１で複数のデータが処理されるといったフロー、アプリケーション３２１でデータが処理され、処理されたデータがクラウド１０３に送信されるといったフロー等である。

Ｓ２２０２では、完了部３１３は、正常終了を検出した情報をデータ管理部３１１に送信する。正常終了を検出した情報には、正常なフローにおいて処理を行ったアプリケーション３２１のアプリ名、当該アプリケーション３２１で使用されたデータ（正常なフローで使用されたデータ）のデータ識別子が含まれる。

Ｓ２２０３では、データ管理部３１１は、正常なフローで使用されたデータ（データ群）の未処理ラベルを保管ラベルに更新する。

Ｓ２２０４では、データ管理部３１１は、正常なフローで使用されたデータ（データ群）に一意のグループラベルを付与する。

Ｓ２２０５では、データ管理部３１１は、正常なフローで使用されたデータ（データ群）に保管期間（ＴＴＬ）を設定する。

Ｓ２２０６では、データ管理部３１１，３２４は、保管期間が切れるまでに、保管ラベルが付与されたデータに再アクセスがあるか否かを判定する。データ管理部３１１，３２４は、再アクセスがあると判定した場合、Ｓ２２０７に処理を移し、再アクセスがないと判定した場合、Ｓ２２０８に処理を移す。

Ｓ２２０７では、データ管理部３１１は、再アクセスがあるデータの保管期間（ＴＴＬ）を更新する。より具体的には、データ管理部３１１は、新ＴＴＬ ＝ 残ＴＴＬ＋デフォルトＴＴＬを計算する。

Ｓ２２０８では、データ管理部３１１，３２４は、保管期間が切れるまでに再アクセスがなかったデータの保管ラベルを削除ラベルに更新する。

Ｓ２２０９では、データ管理部３１１，３２４は、所定の時間（例えば、１２時間）以内に削除ラベルが付与されたデータにアプリケーション３２１によるアクセスがあるか否かを判定する。データ管理部３１１，３２４は、アクセスがあると判定した場合、Ｓ２２１０に処理を移し、アクセスがないと判定した場合、Ｓ２２１１に処理を移す。

Ｓ２２１０では、データ管理部３１１は、アクセスがあったデータの削除ラベルを保管ラベルに更新する。なお、データ管理部３１１は、当該データに保管期間を設定してもよい。

Ｓ２２１１では、データ管理部３１１は、所定の時間以内にアプリケーション３２１によるアクセスがなかったデータと、当該データに付与されているグループラベルと同一のグループラベルが付与されているデータを削除するように削除部３２５に指示する。削除部３２５は、指示されたデータをストレージ装置２２３から削除する。

図２３は、緊急削除処理の一例を示す図である。

Ｓ２３０１では、データ管理部３２４は、記憶容量の閾値を超えたことを検出する。例えば、データ管理部３２４は、記憶容量の閾値を超えたボリューム（処理対象のボリューム）のボリューム名をデータ管理部３１１に送信する。

Ｓ２３０２では、データ管理部３１１は、処理対象のボリュームのデータを残りの保管期間（残ＴＴＬ）の少ない順でソートする。

Ｓ２３０３では、データ管理部３１１は、残りの保管期間（残ＴＴＬ）が最も少ないデータと当該データに付与されているグループラベルと同一のグループラベルを持つデータと（最上位データ群）の保管ラベルを緊急削除ラベルに更新する。

Ｓ２３０４では、データ管理部３１１は、緊急削除ラベルが付与されているデータを即時削除するように削除部３２５に指示する。削除部３２５は、指示されたデータを削除する。

Ｓ２３０５では、データ管理部３２４は、処理対象のボリュームの記憶容量が閾値を下回るか否かを判定する。データ管理部３２４は、記憶容量が閾値を下回ると判定した場合、処理を終了し、記憶容量が閾値を下回らないと判定した場合、Ｓ２３０３に処理を移す。

本実施の形態によれば、アプリケーションおよびデータをエッジサーバに最適に配置することができる。

（２）付記
上述の実施の形態には、例えば、以下のような内容が含まれる。

上述の実施の形態においては、本発明を運用管理システムに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々のシステム、装置、方法、プログラム、当該プログラムを記憶した記憶媒体に広く適用することができる。

また、上述の実施の形態において、データの処理ラベルを運用管理サーバ１１０で管理する場合について述べたが、これに限るものではない。例えば、ストレージ装置２２３のデータに処理ラベルを付与し、データの処理ラベルをエッジサーバ１２０で管理してもよい。

また、上述の実施の形態において、分析部３１２が、移動対象のアプリケーション３２１の稼働実績の有無でサーバリストの候補をソートすることについて述べたが、これに限るものではない。例えば、分析部３１２は、移動対象のアプリケーション３２１の稼働実績が無いエッジサーバ１２０の候補をサーバリストから削除してもよい。

また、上述の実施の形態において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、上述の実施の形態において、説明の便宜上、ＸＸテーブルを用いて各種のデータを説明したが、データ構造は限定されるものではなく、ＸＸ情報等と表現してもよい。

また、上記の説明において、各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

上述した実施の形態は、例えば、以下の特徴的な構成を有する。

複数のエッジサーバ（例えば、エッジサーバ１２０）を備え、上記複数のエッジサーバの運用を管理するための運用管理システム（例えば、運用管理システム１００）であって、センサ（例えば、センサ１３０）により取得されたデータを記憶する第１の記憶部（例えば、ストレージ装置２２３、ボリューム）を備える第１のエッジサーバ（例えば、エッジサーバ１２０）と、データを処理するアプリケーション（例えば、アプリケーション３２１、コンテナ、ＶＭ）を備える第２のエッジサーバ（例えば、エッジサーバ１２０）と、上記第１の記憶部に記憶されているデータが上記アプリケーションにより処理される際、上記データを示す情報（例えば、データ識別子４０１）と、上記データが記憶されている上記第１の記憶部を示す情報（例えば、ストレージ識別子４０３、保管場所４０４）と、上記アプリケーションを示す情報（アプリ識別子４０５）と、上記アプリケーションが設けられている上記第２のエッジサーバを示す情報（アプリ稼働場所４０７）とを関係付けて関係性情報（例えば、関係性情報１１１、関係性テーブル４００）を生成する情報管理部（例えば、データ管理部３１１，３２４、運用管理サーバ１１０、回路）と、上記情報管理部により生成された関係性情報を出力する出力部（例えば、データ管理部３１１、運用管理サーバ１１０、回路）と、を備える。

上記第１のエッジサーバと上記第２のエッジサーバとは、同じであってもよいし、異なっていてもよい。上記出力部による出力は、ディスプレイへの表示、ストレージ装置２２３への記憶、他のコンピュータへの送信、スピーカによる音声出力、印刷装置による紙媒体等への印刷、プロジェクタによるスクリーン等への投影、その他の態様であってもよい。

上記構成では、関係性情報が出力されるので、例えば、アプリケーションとデータとの関係が把握できるようになり、手動でまたは自動で、アプリケーションおよび／またはデータを最適なエッジサーバに配置することができるようになる。

上記運用管理システムは、上記運用管理システムが備えるエッジサーバに設けられているリソースの負荷が閾値を超過しているか否かを判定する判定部（例えば、監視部３２２、エッジサーバ１２０、回路）と、上記判定部により閾値を超過していると判定されたエッジサーバに設けられている配置対象のアプリケーション（例えば、リソース要求量が最も大きいアプリケーション３２１であってもよいし、Ｉ／Ｏが最も小さいアプリケーション３２１であってもよいし、任意のアプリケーション３２１でもよい。）を、上記エッジサーバとは異なるエッジサーバに配置する配置部（例えば、配置部３２３、エッジサーバ１２０、回路）と、を備える。

なお、アプリケーションが他のエッジサーバに配置された場合、他のエッジサーバに設けられているリソースの負荷が閾値を超過したときは、他のエッジサーバとは異なる他のエッジサーバにアプリケーションが配置される。最終的には、リソースの負荷が閾値を超過しないエッジサーバにアプリケーションが配置されることになる。

上記構成では、リソースの負荷が閾値を超過している特定のエッジサーバのアプリケーションが他のエッジサーバに配置されるので、例えば、特定のエッジサーバの性能が悪化してしまう事態を回避することができる。

上記運用管理システムは、上記アプリケーションの配置先として、上記アプリケーションのリソース要求量よりもリソース空き量が大きいエッジサーバを決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）を備え、上記配置部は、上記エッジサーバに上記アプリケーションを配置する。

上記構成では、リソース空き量をもとに配置先のエッジサーバが決定されるので、例えば、リソースの負荷が閾値を超過している特定のエッジサーバのアプリケーションをより適切に配置することができるようになる。

上記運用管理システムは、上記判定部により閾値を超過していると判定されたエッジサーバが備えるリソースの競合を検出する検出部（例えば、監視部３２２、エッジサーバ１２０、回路）と、上記検出部により検出された結果をもとに、上記エッジサーバに設けられている配置対象のアプリケーションの配置先を決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）と、を備え、上記情報管理部は、上記検出部によりリソースの競合が発生したことが検出された場合、上記リソースの競合に係るアプリケーションを示す情報（例えば、リソース競合発生４０９）を記憶し、上記決定部は、上記配置対象のアプリケーションの配置先として、上記配置対象のアプリケーションとリソースの競合が発生したことがあるアプリケーションが設けられていないエッジサーバを決定し（例えば、図１２参照）、上記配置部は、上記エッジサーバに上記配置対象のアプリケーションを配置する。

上記構成では、アプリケーションの配置先としてリソースの競合が発生したことがあるアプリケーションが設けられていないエッジサーバが決定されるので、例えば、アプリケーションの配置後に直ぐにリソースの負荷が閾値を超過してしまう事態を回避できるようになる。

上記運用管理システムが備えるエッジサーバに設けられているアプリケーションは、コンテナであり、上記運用管理システムは、上記判定部により閾値を超過していると判定されたエッジサーバに設けられている配置対象のコンテナの配置先として、上記コンテナを生成するためのコンテナイメージが存在するエッジサーバを決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）を備える。

上記構成では、リソースの負荷が閾値を超過している特定のエッジサーバのコンテナの配置先として、当該コンテナのコンテナイメージを備えるエッジサーバが決定されるので、例えば、当該エッジサーバが当該コンテナイメージを取得したりする必要がなく、当該コンテナを短時間に配置することができるようになる。

上記運用管理システムは、上記判定部により閾値を超過していると判定された第３のエッジサーバから、上記第３のエッジサーバに設けられている配置対象のアプリケーションが使用するデータへの第１のアクセス速度（例えば、移動元からのアクセス速度）と、上記第３のエッジサーバとは異なる第４のエッジサーバから、上記データへの第２のアクセス速度（例えば、移動先からのアクセス速度）と、を算出する算出部（例えば、分析部３１２、運用管理サーバ１１０、回路）と、上記アプリケーションの配置先として上記第４のエッジサーバを決定し、上記第２のアクセス速度が上記第１のアクセス速度より遅い場合、上記データの容量よりも空き容量が大きい記憶部であって、上記第４のエッジサーバから上記データへのアクセス速度が最も速くなる記憶部を備えるエッジサーバを、上記データの配置先として決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）とを備える。

上記構成では、アプリケーションの再配置によりデータへのアクセス速度が遅くなる場合、当該データを記憶する記憶部が再配置されるので、例えば、リソースの負荷が閾値を超過している場合に、アプリケーションとデータとをそれぞれ適切なエッジサーバに配置することができる。

上記情報管理部は、上記運用管理システムが備えるエッジサーバに設けられているアプリケーションにより一連の処理が終了した場合、上記一連の処理で使用されたデータに同じグループであることを示す情報（例えば、グループラベル）を付与する（例えば、図２２参照）。

上記構成では、アプリケーションの一連の処理で使用されるデータに同じグループラベルが付与されるので、例えば、データをグループ単位に配置することができ、アプリケーションによる処理においてデータのアクセスが効率よくなる。

上記運用管理システムは、上記運用管理システムが備えるエッジサーバにおけるＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）の負荷が閾値を超過しているか否かを判定する判定部（例えば、監視部３２２、エッジサーバ１２０、回路）と、上記判定部により閾値を超過していると判定されたエッジサーバに記憶されている配置対象のデータを、上記エッジサーバとは異なるエッジサーバに配置する配置部（例えば、配置部３２３、エッジサーバ１２０、回路）と、を備える。

上記構成では、Ｉ／Ｏの負荷が閾値を超過している特定のエッジサーバのデータが他のエッジサーバに配置されるので、例えば、特定のエッジサーバの性能が悪化してしまう事態を回避することができる。

上記運用管理システムは、上記データの配置先として、上記データの容量よりも記憶部の空き容量が大きいエッジサーバを決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）を備え、上記配置部は、上記エッジサーバに上記データを配置する。

上記構成では、記憶部の空き容量をもとに配置先のエッジサーバが決定されるので、例えば、Ｉ／Ｏの負荷が閾値を超過している特定のエッジサーバのデータをより適切に配置することができるようになる。

上記運用管理システムは、上記判定部により閾値を超過していると判定されたエッジサーバにおけるＩ／Ｏの競合を検出する検出部（例えば、監視部３２２、エッジサーバ１２０、回路）と、上記検出部により検出された結果をもとに、上記エッジサーバに設けられている配置対象のデータの配置先を決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）と、を備え、上記情報管理部は、上記検出部によりＩ／Ｏの競合が発生したことが検出された場合、上記Ｉ／Ｏの競合に係るデータを示す情報（例えば、Ｉ／Ｏ競合発生４１０）を記憶し、上記決定部は、上記配置対象のデータの配置先として、上記配置対象のデータとＩ／Ｏの競合が発生したことがあるデータを記憶していないエッジサーバを決定し（例えば、図１９参照）、上記配置部は、上記エッジサーバに上記配置対象のデータを配置する。

上記構成では、配置対象のデータの配置先としてＩ／Ｏの競合が発生したことがあるデータを記憶していないエッジサーバが決定されるので、例えば、配置対象のデータの配置後に直ぐにＩ／Ｏの負荷が閾値を超過してしまう事態を回避できるようになる。

上記運用管理システムは、上記判定部により閾値を超過していると判定されたエッジサーバに記憶されている配置対象のデータの配置先として、上記データの配置にかかる時間が最も短いエッジサーバを決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）を備える。

上記構成では、Ｉ／Ｏの負荷が閾値を超過している特定のエッジサーバのデータの配置にかかる時間が最も短いエッジサーバが決定されるので、例えば、当該データを短時間に配置することができるようになる。

上記運用管理システムは、上記判定部により閾値を超過していると判定された第５のエッジサーバに記憶されている配置対象のデータを使用するアプリケーションが設けられている第６のエッジサーバから、上記データへの第１のアクセス速度（例えば、移動元からのアクセス速度）と、上記第６のエッジサーバから、上記データが第７のエッジサーバに配置された際の上記データへの第２のアクセス速度（例えば、移動先からのアクセス速度）と、を算出する算出部（例えば、分析部３１２、運用管理サーバ１１０、回路）と、上記データの配置先として上記第７のエッジサーバを決定し、上記第２のアクセス速度が上記第１のアクセス速度より遅い場合、上記第７のエッジサーバに配置される上記データへのアクセス速度が最も速くなるエッジサーバを、上記アプリケーションの配置先として決定する決定部（例えば、分析部３１２、運用管理サーバ１１０、回路）と、備える。

上記構成では、データの再配置によりアプリケーションによるデータへのアクセス速度が遅くなる場合、当該アプリケーションが再配置されるので、例えば、Ｉ／Ｏの負荷が閾値を超過している場合に、アプリケーションとデータとをそれぞれ適切なエッジサーバに配置することができる。

上記運用管理システムは、上記運用管理システムが備えるエッジサーバに記憶されているデータを削除する削除部（例えば、削除部３２５、エッジサーバ１２０、回路）を備え、上記情報管理部は、上記運用管理システムが備えるエッジサーバに設けられているアプリケーションによりデータが処理された際、上記データに対して、上記データを保管する期間を示す情報（例えば、保管期間４１２）を設定し、上記削除部は、上記情報管理部により設定された期間が経過したデータを削除する（例えば、図２２参照）。

上記構成では、データを保管する期間が設定されるので、例えば、当該期間が経過したデータを不要なデータとして自動で削除することができる。

上記削除部は、上記運用管理システムが備えるエッジサーバの記憶部の空き容量が第１の閾値より少なくなった場合、上記記憶部の空き容量が第２の閾値より大きくなるまで、保管の期間が短いデータから順に削除する（例えば、図２３参照）。

上記構成では、記憶部の空き容量が少なくなった場合、保管期間が短いデータから順に削除されるので、例えば、記憶部の容量が不足することにより発生するエラーを回避することができる。

また上述した構成については、本発明の要旨を超えない範囲において、適宜に、変更したり、組み替えたり、組み合わせたり、省略したりしてもよい。

１００……運用管理システム、１１０……運用管理装置、１２０……エッジサーバ、１３０……センサ。

Claims (15)

1. 複数のエッジサーバを備え、前記複数のエッジサーバの運用を管理するための運用管理システムであって、
   センサにより取得されたデータを記憶する第１の記憶部を備える第１のエッジサーバと、
   データを処理するアプリケーションを備える第２のエッジサーバと、
   前記第１の記憶部に記憶されているデータが前記アプリケーションにより処理される際、前記データを示す情報と、前記データが記憶されている前記第１の記憶部を示す情報と、前記アプリケーションを示す情報と、前記アプリケーションが設けられている前記第２のエッジサーバを示す情報とを関係付けて関係性情報を生成する情報管理部と、
   前記情報管理部により生成された関係性情報を出力する出力部と、
   を備える運用管理システム。
2. 前記運用管理システムが備えるエッジサーバに設けられているリソースの負荷が閾値を超過しているか否かを判定する判定部と、
   前記判定部により閾値を超過していると判定されたエッジサーバに設けられている配置対象のアプリケーションを、前記エッジサーバとは異なるエッジサーバに配置する配置部と、
   を備える請求項１に記載の運用管理システム。
3. 前記アプリケーションの配置先として、前記アプリケーションのリソース要求量よりもリソース空き量が大きいエッジサーバを決定する決定部を備え、
   前記配置部は、前記エッジサーバに前記アプリケーションを配置する、
   請求項２に記載の運用管理システム。
4. 前記判定部により閾値を超過していると判定されたエッジサーバが備えるリソースの競合を検出する検出部と、
   前記検出部により検出された結果をもとに、前記エッジサーバに設けられている配置対象のアプリケーションの配置先を決定する決定部と、を備え、
   前記情報管理部は、前記検出部によりリソースの競合が発生したことが検出された場合、前記リソースの競合に係るアプリケーションを示す情報を記憶し、
   前記決定部は、前記配置対象のアプリケーションの配置先として、前記配置対象のアプリケーションとリソースの競合が発生したことがあるアプリケーションが設けられていないエッジサーバを決定し、
   前記配置部は、前記エッジサーバに前記配置対象のアプリケーションを配置する、
   請求項２に記載の運用管理システム。
5. 前記運用管理システムが備えるエッジサーバに設けられているアプリケーションは、コンテナであり、
   前記判定部により閾値を超過していると判定されたエッジサーバに設けられている配置対象のコンテナの配置先として、前記コンテナを生成するためのコンテナイメージが存在するエッジサーバを決定する決定部を備える、
   請求項２に記載の運用管理システム。
6. 前記判定部により閾値を超過していると判定された第３のエッジサーバから、前記第３のエッジサーバに設けられている配置対象のアプリケーションが使用するデータへの第１のアクセス速度と、前記第３のエッジサーバとは異なる第４のエッジサーバから、前記データへの第２のアクセス速度と、を算出する算出部と、
   前記アプリケーションの配置先として前記第４のエッジサーバを決定し、前記第２のアクセス速度が前記第１のアクセス速度より遅い場合、前記データの容量よりも空き容量が大きい記憶部であって、前記第４のエッジサーバから前記データへのアクセス速度が最も速くなる記憶部を備えるエッジサーバを、前記データの配置先として決定する決定部と、
   を備える請求項２に記載の運用管理システム。
7. 前記情報管理部は、前記運用管理システムが備えるエッジサーバに設けられているアプリケーションにより一連の処理が終了した場合、前記一連の処理で使用されたデータに同じグループであることを示す情報を付与する、
   請求項６に記載の運用管理システム。
8. 前記運用管理システムが備えるエッジサーバにおけるＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）の負荷が閾値を超過しているか否かを判定する判定部と、
   前記判定部により閾値を超過していると判定されたエッジサーバに記憶されている配置対象のデータを、前記エッジサーバとは異なるエッジサーバに配置する配置部と、
   を備える請求項１に記載の運用管理システム。
9. 前記データの配置先として、前記データの容量よりも空き容量が大きいエッジサーバを決定する決定部を備え、
   前記配置部は、前記エッジサーバに前記データを配置する、
   請求項８に記載の運用管理システム。
10. 前記判定部により閾値を超過していると判定されたエッジサーバにおけるＩ／Ｏの競合を検出する検出部と、
    前記検出部により検出された結果をもとに、前記エッジサーバに設けられている配置対象のデータの配置先を決定する決定部と、を備え、
    前記情報管理部は、前記検出部によりＩ／Ｏの競合が発生したことが検出された場合、前記Ｉ／Ｏの競合に係るデータを示す情報を記憶し、
    前記決定部は、前記配置対象のデータの配置先として、前記配置対象のデータとＩ／Ｏの競合が発生したことがあるデータを記憶していないエッジサーバを決定し、
    前記配置部は、前記エッジサーバに前記配置対象のデータを配置する、
    請求項８に記載の運用管理システム。
11. 前記判定部により閾値を超過していると判定されたエッジサーバに記憶されている配置対象のデータの配置先として、前記データの配置にかかる時間が最も短いエッジサーバを決定する決定部を備える、
    請求項８に記載の運用管理システム。
12. 前記判定部により閾値を超過していると判定された第５のエッジサーバに記憶されている配置対象のデータを使用するアプリケーションが設けられている第６のエッジサーバから、前記データへの第１のアクセス速度と、前記第６のエッジサーバから、前記データが第７のエッジサーバに配置された際の前記データへの第２のアクセス速度と、を算出する算出部と、
    前記データの配置先として前記第７のエッジサーバを決定し、前記第２のアクセス速度が前記第１のアクセス速度より遅い場合、前記第７のエッジサーバに配置される前記データへのアクセス速度が最も速くなるエッジサーバを、前記アプリケーションの配置先として決定する決定部と、
    備える請求項８に記載の運用管理システム。
13. 前記運用管理システムが備えるエッジサーバに記憶されているデータを削除する削除部を備え、
    前記情報管理部は、前記運用管理システムが備えるエッジサーバに設けられているアプリケーションによりデータが処理された際、前記データに対して、前記データを保管する期間を示す情報を設定し、
    前記削除部は、前記情報管理部により設定された期間が経過したデータを削除する、
    請求項１に記載の運用管理システム。
14. 前記削除部は、前記運用管理システムが備えるエッジサーバの記憶部の空き容量が第１の閾値より少なくなった場合、前記記憶部の空き容量が第２の閾値より大きくなるまで、保管の期間が短いデータから順に削除する、
    請求項１３に記載の運用管理システム。
15. 複数のエッジサーバを備え、前記複数のエッジサーバの運用を管理するための運用管理システムにおける運用管理方法であって、
    前記運用管理システムは、
    センサにより取得されたデータを記憶する第１の記憶部を備える第１のエッジサーバと、
    データを処理するアプリケーションを備える第２のエッジサーバと、を備え、
    情報管理部が、前記第１の記憶部に記憶されているデータが前記アプリケーションにより処理される際、前記データを示す情報と、前記データが記憶されている前記第１の記憶部を示す情報と、前記アプリケーションを示す情報と、前記アプリケーションが設けられている前記第２のエッジサーバを示す情報とを関係付けて関係性情報を生成することと、
    出力部が、前記情報管理部により生成された関係性情報を出力することと、
    を備える運用管理方法。

Images