ホーム > 特許ランキング > ソフトバンク株式会社
2022-135765ポッド配置決定装置、ポッド配置決定方法、端末機器、エッジサーバ、サーバ、コンテナシステム、およびプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022135765
(43)【公開日】2022-09-15
(54)【発明の名称】ポッド配置決定装置、ポッド配置決定方法、端末機器、エッジサーバ、サーバ、コンテナシステム、およびプログラム
(51)【国際特許分類】
G06F 9/50 20060101AFI20220908BHJP
G06F 9/455 20060101ALI20220908BHJP
G06F 11/34 20060101ALI20220908BHJP
【ＦＩ】
G06F9/50 120A
G06F9/455 150
G06F11/34 133
【審査請求】有
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2021035782
(22)【出願日】2021-03-05
(71)【出願人】
【識別番号】501440684
【氏名又は名称】ソフトバンク株式会社
(71)【出願人】
【識別番号】899000079
【氏名又は名称】慶應義塾
(74)【代理人】
【識別番号】110000338
【氏名又は名称】特許業務法人ＨＡＲＡＫＥＮＺＯ ＷＯＲＬＤ ＰＡＴＥＮＴ ＆ ＴＲＡＤＥＭＡＲＫ
(72)【発明者】
【氏名】張 亮
(72)【発明者】
【氏名】熊倉 顕
(72)【発明者】
【氏名】前迫 敬介
(72)【発明者】
【氏名】森田 孝裕
(72)【発明者】
【氏名】寺岡 文男
(72)【発明者】
【氏名】渡邊 大記
(72)【発明者】
【氏名】近藤 賢郎
(72)【発明者】
【氏名】安森 涼
(72)【発明者】
【氏名】稲垣 勇佑
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042MA08
5B042MA14
5B042MC09
(57)【要約】
【課題】ネットワーク状況およびリソース状況の双方を考慮したポッド配置を可能とする。
【解決手段】第１ローカルＭＡＮＯ（４３）は、第１ローカルデータストア（４４）に保存された第１拠点に関するネットワーク状況および第１ＭＥＣサーバ（５）のリソース状況と、第１ポッド（８１）が要求するネットワークへの要求事項およびリソースへの要求事項とに基づいて、第１ポッド（８１）を第１ＭＥＣサーバ（５）の第１ワーカノード（５２）に配置するか否かを決定する。
【選択図】図１
【解決手段】第１ローカルＭＡＮＯ（４３）は、第１ローカルデータストア（４４）に保存された第１拠点に関するネットワーク状況および第１ＭＥＣサーバ（５）のリソース状況と、第１ポッド（８１）が要求するネットワークへの要求事項およびリソースへの要求事項とに基づいて、第１ポッド（８１）を第１ＭＥＣサーバ（５）の第１ワーカノード（５２）に配置するか否かを決定する。
【選択図】図１
【特許請求の範囲】
【請求項1】
第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定部と、
前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信部と、
測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信部と、
保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定部とを備えている、ポッド配置決定装置。
前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信部と、
測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信部と、
保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定部とを備えている、ポッド配置決定装置。
【請求項2】
前記決定部は、前記ネットワーク状況が前記ネットワークへの要求事項を満たしており、かつ、前記リソース状況が前記リソースへの要求事項を満たしている場合、前記第１ポッドを前記第１ワーカノードに配置することを決定する、請求項１に記載のポッド配置決定装置。
【請求項3】
前記第１ワーカノードは、異なる複数のコンテナオーケストレーションクラスタに属しており、
前記第１エッジサーバは、前記第１ワーカノードのリソース状況を測定するリソース状況測定部を備えている、請求項１または２に記載のポッド配置決定装置。
前記第１エッジサーバは、前記第１ワーカノードのリソース状況を測定するリソース状況測定部を備えている、請求項１または２に記載のポッド配置決定装置。
【請求項4】
前記第１ポッドのイメージを保存するイメージ保存部をさらに備えている、請求項１～３のいずれか１項に記載のポッド配置決定装置。
【請求項5】
第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定ステップと、
前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信ステップと、
測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信ステップと、
保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定ステップとを有する、ポッド配置決定方法。
前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信ステップと、
測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信ステップと、
保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定ステップとを有する、ポッド配置決定方法。
【請求項6】
異なる複数のコンテナオーケストレーションクラスタに属するワーカノードと、
前記ワーカノードのリソース状況を測定する測定部と、
測定された前記リソース状況をポッド配置決定装置に送信する送信部とを備えている、エッジサーバ。
前記ワーカノードのリソース状況を測定する測定部と、
測定された前記リソース状況をポッド配置決定装置に送信する送信部とを備えている、エッジサーバ。
【請求項7】
請求項１に記載のポッド配置決定装置と、前記第２拠点に配置される第２ポッド配置決定装置とそれぞれ通信可能に接続されるサーバであって、
前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第２ポッド配置決定装置から送信された、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況および前記第２ワーカノードの第２リソース状況とを受信する第１サーバ受信部と、
受信された前記ネットワーク状況、前記リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存するサーバ情報保存部と、
前記アプリケーションを構成する第２ポッドが要求するネットワークへの第２要求事項および前記第２ポッドが要求するリソースへの第２リソース状況を受信する第２サーバ受信部と、
保存された前記第２ネットワーク状況および第２リソース状況と、受信された前記ネットワークへの第２要求事項および前記リソースへの第２要求事項とに基づいて、前記第２ポッドを前記第２ワーカノードに配置するか否かを決定する第２決定部とを備えている、サーバ。
前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第２ポッド配置決定装置から送信された、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況および前記第２ワーカノードの第２リソース状況とを受信する第１サーバ受信部と、
受信された前記ネットワーク状況、前記リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存するサーバ情報保存部と、
前記アプリケーションを構成する第２ポッドが要求するネットワークへの第２要求事項および前記第２ポッドが要求するリソースへの第２リソース状況を受信する第２サーバ受信部と、
保存された前記第２ネットワーク状況および第２リソース状況と、受信された前記ネットワークへの第２要求事項および前記リソースへの第２要求事項とに基づいて、前記第２ポッドを前記第２ワーカノードに配置するか否かを決定する第２決定部とを備えている、サーバ。
【請求項8】
端末機器であって、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが、前記端末機器が接続されるネットワーク内のエッジサーバに配置されており、
前記アプリケーションを起動するための、前記コンテナオーケストレーションクラスタに属していない起動モジュールをさらに備えている、端末機器。
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが、前記端末機器が接続されるネットワーク内のエッジサーバに配置されており、
前記アプリケーションを起動するための、前記コンテナオーケストレーションクラスタに属していない起動モジュールをさらに備えている、端末機器。
【請求項9】
請求項１に記載のポッド配置決定装置と、請求項７に記載のサーバとを少なくとも備えている、コンテナシステム。
【請求項10】
第１拠点に配置される第１エッジサーバおよび第１拠点装置と、第２拠点に配置される第２エッジサーバおよび第２拠点装置と、サーバとを備えているコンテナシステムであって、
前記第１エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第１ワーカノードと、
前記第１ワーカノードの第１リソース状況を測定する第１リソース状況測定部と、
測定された前記第１リソース状況を、前記第１拠点装置に送信する第１リソース状況送信部と、を備えており、
前記第１拠点装置は、
前記第１リソース状況を受信する第１受信部と、
受信された前記第１リソース状況を、前記サーバに送信する第１送信部と、
前記第２エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第２ワーカノードと、
前記第２ワーカノードの第２リソース状況を測定する第２リソース状況測定部と、
測定された前記第２リソース状況を、前記第２拠点装置に送信する第２リソース状況送信部と、を備えており、
前記第２拠点装置は、
前記第２リソース状況を受信する第２受信部と、
受信された前記第２リソース状況を、前記サーバに送信する第２送信部とを備えており、
前記サーバは、
前記第１リソース状況および前記第２リソース状況を受信する第１サーバ受信部と、
受信された前記第１リソース状況および前記第２リソース状況を保存するサーバ情報保存部とを備えている、コンテナシステム。
前記第１エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第１ワーカノードと、
前記第１ワーカノードの第１リソース状況を測定する第１リソース状況測定部と、
測定された前記第１リソース状況を、前記第１拠点装置に送信する第１リソース状況送信部と、を備えており、
前記第１拠点装置は、
前記第１リソース状況を受信する第１受信部と、
受信された前記第１リソース状況を、前記サーバに送信する第１送信部と、
前記第２エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第２ワーカノードと、
前記第２ワーカノードの第２リソース状況を測定する第２リソース状況測定部と、
測定された前記第２リソース状況を、前記第２拠点装置に送信する第２リソース状況送信部と、を備えており、
前記第２拠点装置は、
前記第２リソース状況を受信する第２受信部と、
受信された前記第２リソース状況を、前記サーバに送信する第２送信部とを備えており、
前記サーバは、
前記第１リソース状況および前記第２リソース状況を受信する第１サーバ受信部と、
受信された前記第１リソース状況および前記第２リソース状況を保存するサーバ情報保存部とを備えている、コンテナシステム。
【請求項11】
前記第１拠点装置は、前記第１拠点から前記第２拠点への通信時の第１ネットワーク状況を測定する第１ネットワーク状況測定部をさらに備えており、
前記第１送信部は、測定された前記第１ネットワーク状況および受信された前記第１リソース状況を、前記サーバに送信し、
前記第２拠点装置は、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況を測定する第２ネットワーク状況測定部をさらに備えており、
前記第２送信部は、測定された前記第２ネットワーク状況および受信された前記第２リソース状況を、前記サーバに送信し、
前記第１サーバ受信部は、前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を受信し、
前記サーバ情報保存部は、受信された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存し、
前記サーバは、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２サーバ受信部と、
保存された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ワーカノードおよび前記第２ワーカノードのうちいずれのワーカノードに前記第１ポッドを配置するかを決定する、請求項１０に記載のコンテナシステム。
前記第１送信部は、測定された前記第１ネットワーク状況および受信された前記第１リソース状況を、前記サーバに送信し、
前記第２拠点装置は、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況を測定する第２ネットワーク状況測定部をさらに備えており、
前記第２送信部は、測定された前記第２ネットワーク状況および受信された前記第２リソース状況を、前記サーバに送信し、
前記第１サーバ受信部は、前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を受信し、
前記サーバ情報保存部は、受信された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存し、
前記サーバは、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２サーバ受信部と、
保存された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ワーカノードおよび前記第２ワーカノードのうちいずれのワーカノードに前記第１ポッドを配置するかを決定する、請求項１０に記載のコンテナシステム。
【請求項12】
請求項１に記載のポッド配置決定装置としてコンピュータを機能させるためのプログラムであって、前記測定部、前記保存部、前記第１受信部、前記第２受信部、および前記決定部としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ポッド配置決定装置、ポッド配置決定方法、端末機器、エッジサーバ、サーバ、コンテナシステム、およびプログラムに関する。
【背景技術】
【0002】
パーソナルコンピュータおよび携帯電話などの各種の端末機器においてアプリケーションを実行する際、当該アプリケーションを構成するモジュールの中で負荷が大きいものをネットワーク中に存在するクラウドサーバに実行させることにより、アプリケーションの実行を効率よく行える可能性がある。このような実行の形態はオフロードと呼ばれる。しかし端末機器とクラウドサーバとの間の通信遅延は一般的に大きいため、アプリケーションの応答時間が長くなってしまう可能性がある．そこで従来、端末機器のネットワーク接続地点付近（エッジ）にＭＥＣ（Multi-access Edge Computing）サーバを配置することによって、端末機器とＭＥＣサーバとの間の通信遅延を小さくし、かつＭＥＣサーバにアプリケーションの一部の機能をオフロードすることによって、アプリケーションの応答時間を小さくすることが提案されている。
【0003】
また、端末機器上で動作するアプリケーション（クライアント）と、クラウドサーバで動作するアプリケーション（サーバアプリケーション）とが通信するという形態のアプリケーション（クライアント・サーバ型アプリケーション）も、良く利用されている。このようなアプリケーションでも、クライアントはクラウドサーバと通信するよりもＭＥＣサーバと通信する方が、通信遅延を小さくすることができる。
【0004】
また、物理コンピュータの仮想化技術には、ハイパーバイザ型とコンテナ型とがある。コンテナ型の仮想化技術は、コンテナ間でオペレーティングシステムのカーネルを共有するため、ハイパーバイザ型の仮想化技術と比較して軽量である。さらに、アプリケーションを構成するさまざまなモジュールをそれぞれコンテナとして実現し、アプリケーションを複数のコンテナの集合体として構成することが一般的になっている。
【0005】
コンテナの作成、配置、スケーリング、および状態監視などを自動的に行うシステムを、一般的にコンテナオーケストレーションシステムと呼ぶ。非特許文献１に、代表的なコンテナオーケストレーションシステムとして知られるＫｕｂｅｒｎｅｔｅｓが開示されている。コンテナオーケストレーションシステムでは、１つ以上のコンテナを含むポッドを最小の管理対象とすることが多い。コンテナオーケストレーションシステムでは、データセンタなどのコンピュータクラスタ上に仮想マシンとしてマスターノードおよびワーカノードを配置し、１台のマスターノードと１台以上のワーカノードとによって、コンテナオーケストレーションクラスタを構成する。コンテナオーケストレーションクラスタ内では高可用性および負荷分散を考慮し、マスターノードがワーカノードにポッドを配置することによってポッドクラスタを構成する。
【先行技術文献】
【非特許文献】
【0006】
【非特許文献1】"Kubernetes (K8s)"、［online］、［令和3年2月25日検索］、インターネット〈https://kubernetes.io/ja/>
【発明の概要】
【発明が解決しようとする課題】
【0007】
一般的なコンテナオーケストレーションシステムは、コンテナの配置を決定する際にワーカノードの負荷を考慮する。しかし、ネットワーク状況を考慮していないため、ネットワーク状況が悪い（通信遅延が大きい等）各ワーカノードに各ポッドを配置する恐れがある。また、ワーカノードのリソース状況を考慮していないため、ワーカノードへのポッドの設置に失敗する可能性がある。
【0008】
本発明は前記の課題を解決するためになされたものであり、その目的は、ネットワーク状況およびワーカノードのリソース状況の双方を考慮したポッド配置を可能とすることにある。
【課題を解決するための手段】
【0009】
本発明の一態様に係るポッド配置決定装置は、前記の課題を解決するために、第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定部と、前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信部と、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信部と、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定部とを備えている。
【発明の効果】
【0010】
本発明の一態様によれば、ネットワーク状況およびワーカノードのリソース状況の双方を考慮したポッド配置を可能とするという効果を奏する。
【図面の簡単な説明】
【0011】
【図1】第１実施形態に係るコンテナシステムの構成例を示す図である。
【図2】コンテナシステムがネットワーク状況およびリソース状況を測定する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【図3】ネットワーク状況通知メッセージの一例を示す図である。
【図4】リソース状況通知メッセージの一例を示す図である。
【図5】拠点状況通知メッセージの一例を示す図である。
【図6】端末機器がアプリケーションを起動する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【図7】アプリ起動要求メッセージの一例を示す図である。
【図8】アプリ構成情報要求メッセージの一例を示す図である。
【図9】アプリ構成情報応答メッセージの一例を示す図である。
【図10】ポッド配置決定要求メッセージの一例を示す図である。
【図11】ポッド配置決定要求メッセージの一例を示す図である。
【図12】ポッド配置決定応答メッセージの一例を示す図である。
【図13】ポッド配置決定応答メッセージの一例を示す図である。
【図14】ポッド配置要求メッセージの一例を示す図である。
【図15】ポッド配置要求メッセージの一例を示す図である。
【図16】ポッド配置応答メッセージの一例を示す図である。
【図17】ポッド配置要求メッセージの一例を示す図である。
【図18】ポッド配置応答メッセージの一例を示す図である。
【図19】ポッド配置要求メッセージの一例を示す図である。
【図20】ポッド配置応答メッセージの一例を示す図である。
【図21】ポッド配置応答メッセージの一例を示す図である。
【図22】アプリ起動応答メッセージの一例を示す図である。
【図23】コンテナシステムがアプリケーションを停止する際に実行する一連の処理の流れを示すシーケンス図である。
【図24】アプリ停止要求メッセージの一例を示す図である。
【図25】ポッド停止要求メッセージの一例を示す図である。
【図26】ポッド停止応答メッセージの一例を示す図である。
【図27】アプリ停止応答メッセージの一例を示す図である。
【図28】測定要求メッセージの一例を示す図である。
【図29】測定要求メッセージの一例を示す図である。
【図30】測定要求メッセージの一例を示す図である。
【図31】測定要求メッセージの一例を示す図である。
【図32】測定要求メッセージの一例を示す図である。
【図33】第２実施形態に係るコンテナシステムの構成を示すブロック図である。
【図34】端末機器がクライアントＡｐｐを起動する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【図35】アプリ要求メッセージの一例を示す図である。
【図36】ポッド配置要求メッセージの一例を示す図である。
【図37】ポッド配置応答メッセージの一例を示す図である。
【図38】アプリ応答メッセージの一例を示す図である。
【図39】サーバアプリケーションを停止する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【0012】
〔実施形態１〕
（システムの構成）
図１は、第１実施形態に係るコンテナシステム１の構成例を示す図である。この図に示すように、コンテナシステム１は、端末機器２、クラウドサーバ３（サーバ）、第１拠点装置４（ポッド配置決定装置）、複数の第１ＭＥＣ（Multi-access Edge Computing）サーバ５（第１エッジサーバ）、第２拠点装置６（第２ポッド配置決定装置）、および複数の第２ＭＥＣサーバ７（第２エッジサーバ）を備えている。これらの装置は、ネットワークを介して互いに通信可能に接続されている。ネットワークには、いわゆるクラウドが配置されている。クラウドサーバ３は、クラウドに配置されている。図１には、２つの異なる第１拠点および第２拠点が図示されている。拠点とは、端末機器２が有線または無線でネットワークに接続する接続ポイント付近に位置する物理的な場所のことである。図１では、端末機器２は、第２拠点よりも第１拠点の近くに位置している。第１拠点および第２拠点の識別子を、それぞれBaseID1およびBaseID2とする。
（システムの構成）
図１は、第１実施形態に係るコンテナシステム１の構成例を示す図である。この図に示すように、コンテナシステム１は、端末機器２、クラウドサーバ３（サーバ）、第１拠点装置４（ポッド配置決定装置）、複数の第１ＭＥＣ（Multi-access Edge Computing）サーバ５（第１エッジサーバ）、第２拠点装置６（第２ポッド配置決定装置）、および複数の第２ＭＥＣサーバ７（第２エッジサーバ）を備えている。これらの装置は、ネットワークを介して互いに通信可能に接続されている。ネットワークには、いわゆるクラウドが配置されている。クラウドサーバ３は、クラウドに配置されている。図１には、２つの異なる第１拠点および第２拠点が図示されている。拠点とは、端末機器２が有線または無線でネットワークに接続する接続ポイント付近に位置する物理的な場所のことである。図１では、端末機器２は、第２拠点よりも第１拠点の近くに位置している。第１拠点および第２拠点の識別子を、それぞれBaseID1およびBaseID2とする。
【0013】
端末機器２は、プリファレンスリポジトリ２１、イメージリポジトリ２２、および起動Ａｐｐ２３（起動モジュール）を備えている。端末機器２は、第３ワーカノードとしても機能する。
【0014】
クラウドサーバ３は、グローバルＭＡＮＯ（Management and Orchestration）３１（第１サーバ受信部、第２サーバ受信部、第２決定部）、グローバルデータストア３２（サーバ情報保存部）、およびオリジンイメージリポジトリ３３を備えている。
【0015】
第１拠点に、第１拠点装置４と、ｎ台（ｎは１以上の整数）の第１ＭＥＣサーバ５とが配置されている。第１拠点装置４は、第１マスターノード４１、第１ネットワークモニタ４２（測定部、第１ネットワーク状況測定部）、第１ローカルＭＡＮＯ４３（第２受信部、決定部）、第１ローカルデータストア４４（第１受信部、保存部、第１送信部）、第１ローカルイメージリポジトリ４５（イメージ保存部）、および第１ＡｐｐＡＰＩ４６を備えている。これらのモジュールの識別子を、それぞれMnID1、NmonID1、LManoID1、LdsID1、LirID1、およびAppApiID1とする。各第１ＭＥＣサーバ５は、第１リソースモニタ５１（測定部、リソース状況測定部、第１リソース状況測定部、第１リソース状況送信部）、第１ワーカノード５２、および第４ワーカノード５３を備えている。これらのモジュールの識別子を、それぞれRmonID1、WnID1、およびWnID4とする。
【0016】
第２拠点に、第２拠点装置６と、ｍ台（ｍは１以上の整数）の第２ＭＥＣサーバ７とが配置されている。第２拠点装置６は、第２マスターノード６１、第２ネットワークモニタ６２（第２ネットワーク状況測定部）、第２ローカルＭＡＮＯ６３、第２ローカルデータストア６４（第２受信部、保存部、第２送信部）、第２ローカルイメージリポジトリ６５、および第２ＡｐｐＡＰＩ６６を備えている。これらのモジュールの識別子を、それぞれMnID2、NmonID2、LManoID2、LdsID2、LirID2、およびAppApiID2とする。各第２ＭＥＣサーバ７は、第２リソースモニタ７１（第２リソース状況測定部、第２リソース状況送信部）、第２ワーカノード７２、および第５ワーカノード７３を備えている。これらのモジュールの識別子を、それぞれRmonID2、WnID2、およびWnID5とする。
【0017】
本実施形態では、第１拠点装置４は、１つの独立した物理マシンである。そして、第１拠点装置４内に、仮想マシンとしての第１マスターノード４１が設定されている。これに限らず、第１マスターノード４１は、個別の物理マシンとして動作してもよい。また、各第１ＭＥＣサーバ５は、１つの独立した物理マシンである。そして、各第１ＭＥＣサーバ５内に、仮想マシンとしての第１ワーカノード５２および第４ワーカノード５３が配置されている。これに限らず、第１ワーカノード５２および第４ワーカノード５３は、個別の物理マシンとして動作してもよい。
【0018】
本実施形態では、第２拠点装置６は、１つの独立した物理マシンである。そして、第２拠点装置６内に、仮想マシンとしての第２マスターノード６１が設定されている。これに限らず、第２マスターノード６１は、個別の物理マシンとして動作してもよい。また、各第２ＭＥＣサーバ７は、１つの独立した物理マシンである。そして、各第２ＭＥＣサーバ７内に、仮想マシンとしての第２ワーカノード７２および第５ワーカノード７３が配置されている。これに限らず、第２ワーカノード７２および第５ワーカノード７３は、個別の物理マシンとして動作してもよい。
【0019】
上述した各マスターノードおよび各ワーカノードは、必要に応じて、１つのコンテナオーケストレーションクラスタを構成する。図１の例では、第１マスターノード４１、第３ワーカノード（端末機器２）、第１ワーカノード５２、および第２ワーカノード７２が、ある１つのコンテナオーケストレーションクラスタを構成している。また、特に図示していないが、第２マスターノード６１、第１ワーカノード５２、および第５ワーカノード７３が、他の１つのコンテナオーケストレーションクラスタを構成している。このように、第１ワーカノード５２は、異なる２つのコンテナオーケストレーションクラスタに属している。
【0020】
図１には、第１拠点の近傍で端末機器２のユーザが所定のアプリケーションを起動した際の、各ポッドの配置を示している。本例では、コンテナオーケストレーションクラスタとしてのアプリケーションは、第１ポッド８１、第２ポッド８２、第３ポッド８３、および図示されない中継ポッドを含む４つのポッドによって構成されている。中継ポッドは、コンテナオーケストレーションクラスタ内外の通信を中継するポッドである。
【0021】
端末機器２のユーザの識別子を、UsrID1とする。ユーザの認証認可のための情報を、CredUsr1とする。認証認可のための情報とは、パスワードや電子証明書等である。アプリケーションの識別子をAppID1とする。アプリケーションを構成する４つのポッドの各識別子を、それぞれPodID1、PodID2、PodID3およびRelayPodID1とする。
【0022】
アプリケーションにおける各ポッドの役割はそれぞれ異なる。第１ポッド８１および第２ポッド８２は、アプリケーションを構成する複数のポッドのうち、比較的複雑な処理を担うポッドである。第３ポッド８３は、アプリケーションを構成する複数のポッドのうち、アプリケーションのユーザインタフェースを担うポッドである。ユーザインタフェースを担うポッドは、必ず端末機器２上に配置する必要がある。そのため、第３ポッド８３は必ず端末機器２上に配置すべきポッドである。
【0023】
端末機器２は、ネットワークに接続すると、最寄りの拠点において構成されるコンテナオーケストレーションクラスタに、自ノードである第３ワーカノードを登録する。図１の例では、端末機器２は第１拠点の近傍でネットワークに接続する。これにより端末機器２は、端末機器２の自ノードとしての第３ワーカノードを、第１マスターノード４１が属するコンテナオーケストレーションクラスタに登録する。この結果、端末機器２は、第３ワーカノードとして、第１マスターノード４１が属するコンテナオーケストレーションクラスタに同様に属することになる。
【0024】
（ネットワーク状況およびリソース状況の把握）
図２は、コンテナシステム１がネットワーク状況およびリソース状況を測定する際にコンテナシステム１によって実行される一連の処理の流れを示すシーケンス図である。ステップＳ１において、第１拠点の第１ネットワークモニタ４２は、第２拠点の第２ネットワークモニタ６２と通信することによって、第１拠点から第２拠点への通信時のネットワーク状況（第１ネットワーク状況）を測定する。ネットワーク状況は、例えば、第１ネットワークモニタ４２から第２ネットワークモニタ６２への通信の遅延時間である。あるいは、ネットワーク状況は、第１ネットワークモニタ４２から第２ネットワークモニタ６２に通信する際に利用可能な通信帯域である。ここでは、第１ネットワークモニタ４２は、遅延時間および通信帯域の双方を、ネットワーク状況として測定する。
図２は、コンテナシステム１がネットワーク状況およびリソース状況を測定する際にコンテナシステム１によって実行される一連の処理の流れを示すシーケンス図である。ステップＳ１において、第１拠点の第１ネットワークモニタ４２は、第２拠点の第２ネットワークモニタ６２と通信することによって、第１拠点から第２拠点への通信時のネットワーク状況（第１ネットワーク状況）を測定する。ネットワーク状況は、例えば、第１ネットワークモニタ４２から第２ネットワークモニタ６２への通信の遅延時間である。あるいは、ネットワーク状況は、第１ネットワークモニタ４２から第２ネットワークモニタ６２に通信する際に利用可能な通信帯域である。ここでは、第１ネットワークモニタ４２は、遅延時間および通信帯域の双方を、ネットワーク状況として測定する。
【0025】
図３は、ネットワーク状況通知メッセージの一例を示す図である。ステップＳ２において、第１ネットワークモニタ４２は、測定したネットワーク状況を通知するための、図３に示すようなネットワーク状況通知メッセージを生成し、第１ローカルデータストア４４に送信する。図３に示すように、ネットワーク状況通知メッセージは、複数の異なるフィールドを含んでいる。具体的には、ネットワーク状況通知メッセージは、Typeフィールド、Source IDフィールド、およびNo of Destinationsフィールドを少なくとも含んでいる。Typeフィールドは、このフィールドが含まれるメッセージの種類（タイプ）を示す。図３では、Typeフィールドはネットワーク状況通知メッセージに含まれるので、Typeフィールドの値はネットワーク状況通知メッセージを示す“ネットワーク状況通知”である。Source IDフィールドは、ネットワーク状況の測定元の識別子を示す。図３では、Source IDフィールドの値はNmonID1である。No of Destinationsフィールドは、ネットワーク状況の測定相手の数を示す。図３では、No of Destinationsフィールドの値は１である。
【0026】
ネットワーク状況通知メッセージは、さらに、ネットワーク状況の測定相手ごとに、対応するDestination IDフィールド、Delayフィールド、およびAvailable Bandwidthフィールドの３つ組フィールドを含んでいる。図３では、測定相手は１つ（第２ネットワークモニタ６２）であるため、ネットワーク状況通知メッセージには１つの３つ組フィールドが含まれる。Destination IDフィールドは、ネットワーク状況の測定相手の識別子を表す。図３では、ネットワーク状況通知メッセージの値は、第２ネットワークモニタ６２の識別子すなわちNmonID2である。Delayフィールドは、Source IDフィールドが示す測定元（ここでは第１ネットワークモニタ４２）からDestination IDが示す測定相手（ここでは第２ネットワークモニタ６２）への通信の遅延時間を示す。Available Bandwidthフィールドは、Source IDフィールドが示す測定元（ここでは第１ネットワークモニタ４２）からDestination IDフィールドが示す測定相手（ここでは第２ネットワークモニタ６２）への通信時に利用可能な通信帯域を示す。
【0027】
ステップＳ３において、第１ＭＥＣサーバ５の第１リソースモニタ５１は、第１ＭＥＣサーバ５のリソース状況を測定する。リソースとは、第１ＭＥＣサーバ５において利用可能な計算資源のことである。ここでは、リソース状況として、第１ＭＥＣサーバ５が有する仮想ＣＰＵの数、メモリ容量、ストレージ容量、ＧＰＵの数、およびＧＰＵのメモリ容量を測定する。さらに、リソース状況として、第１ＭＥＣサーバ５が使用中の仮想ＣＰＵの数、メモリ容量、ストレージ容量、ＧＰＵの数、ＧＰＵのメモリ容量をも測定する。
【0028】
図４は、リソース状況通知メッセージの一例を示す図である。ステップＳ４において、第１リソースモニタ５１は、測定したリソース状況を通知するための、図４に示すようなリソース状況通知メッセージを生成し、第１ローカルデータストア４４に送信する。ネットワーク状況通知メッセージは、複数の異なるフィールドを含んでいる。図４の例では、リソース状況通知メッセージは、Typeフィールド、Source IDフィールド、およびNo of Nodesフィールドを少なくとも含んでいる。Typeフィールドの値は、リソース状況通知メッセージのメッセージタイプを示す“リソース状況通知”である。Source IDフィールドは、リソース状況の測定元の識別子を示す。この例では、Source IDフィールドの値は、第１リソースモニタ５１の識別子すなわちRmonID1である。No of Nodesフィールドは、第１ＭＥＣサーバ５に配置されているワーカノードの数を示す。第１ＭＥＣサーバ５には２台のワーカノードが配置されているので、この例では、No of Nodesフィールドの値は２である。
【0029】
リソース状況通知メッセージは、さらに、ワーカノードごとに、Node IDフィールド、CPUsフィールド、Memoryフィールド、Storageフィールド、GPUsフィールド、GPU Memoryフィールド、In Use CPUsフィールド、In Use Memoryフィールド、In Use Storageフィールド、In Use GPUsフィールド、およびIn Use GPU Memoryフィールドを含む１１組のフィールドを含んでいる。Node IDフィールドは、ワーカノードの識別子を示す。CPUsフィールドは、ワーカノードに割り当てられている仮想ＣＰＵの数を示す。Memoryフィールドは、ワーカノードに割り当てられているメモリ容量を示す。Storageフィールドは、ワーカノードに割り当てられているストレージ容量を示す。GPUsフィールドは、ワーカノードに割り当てられているＧＰＵの個数を示す。GPU Memoryフィールドは、ワーカノードに割り当てられているＧＰＵメモリ容量を示す。In Use CPUsフィールドは、ワーカノードが使用中の仮想ＣＰＵの数を示す。In Use Memoryフィールドは、ワーカノードが使用中のメモリ容量を示す。In Use Storageフィールドは、ワーカノードが使用中のストレージ容量を示す。In Use GPUsフィールドは、ワーカノードが使用中のＧＰＵの個数を示す。In Use GPU Memoryフィールドは、ワーカノードが使用中のＧＰＵメモリ容量を示す。
【0030】
図４の例では、リソース状況通知メッセージは、第１ワーカノード５２および第４ワーカノード５３に対応する２つの１１組フィールドを含んでいる。１つ目の１１組フィールドでは、Node IDフィールドの値はWnID1である。CPUsフィールドの値は、第１ワーカノード５２に割り当てられた仮想ＣＰＵの数を示す。Memoryフィールドは第１ワーカノード５２に割り当てられたメモリ容量を示す。Storageフィールドは第１ワーカノード５２に割り当てられたストレージ容量を示す。GPUsフィールドは第１ワーカノード５２に割り当てられたＧＰＵの数を示す。GPU Memoryフィールドは第１ワーカノード５２に割り当てられたＧＰＵメモリ容量を示す。In Use CPUsは第１ワーカノード５２が現在使用中の仮想ＣＰＵの数を示す。In Use Memoryフィールドは第１ワーカノード５２が使用中のメモリ容量を示す。In Use Storageフィールドは第１ワーカノード５２が使用中のストレージ容量を示す。In Use GPUsフィールドは第１ワーカノード５２が使用中のＧＰＵの数を示す。In Use GPU Memoryフィールドは第１ワーカノード５２が使用中のＧＰＵメモリ容量を示す。
【0031】
２つ目の１１組フィールドでは、Node IDフィールドの値はWnID4である。CPUsフィールド等の残りの１０個のフィールドの値は、１つ目の１１組フィールドと同様に、第４ワーカノード５３に関する値を示す。
【0032】
第１拠点内の他の第１ＭＥＣサーバ５が備える第１リソースモニタ５１も、同様に動作することによって、リソース状況通知メッセージを生成し、第１ローカルデータストア４４に通知する。ステップＳ５において、第１ローカルデータストア４４は、第１拠点内の他の第１リソースモニタ５１から通知されたリソース状況およびネットワーク状況を受信する。ステップＳ６において、第１ローカルデータストア４４は、第１拠点における全第１ＭＥＣサーバ５のリソース状況およびネットワーク状況の情報を集約することによって、図５に示すような拠点状況通知メッセージを生成する。この際、第１ローカルデータストア４４は、集約したネットワーク状況および各リソース状況を、自身の記憶スペースに保存する。
【0033】
図５は、拠点状況通知メッセージの一例を示す図である。ステップＳ７において、第１ローカルデータストア４４は、拠点状況通知メッセージをグローバルデータストア３２に通知する。図５の例では、拠点状況通知メッセージは、Typeフィールド、Base IDフィールド、No of Destinationsフィールド、およびNo of Resource Statsフィールドを含む。Typeフィールドの値は、拠点状況通知メッセージのメッセージタイプを示す“拠点状況通知”である。Base IDフィールドは、拠点の識別子を示す。図４の例では、Base IDフィールドの値はBaseID1である。
【0034】
No of Destinationsフィールドは、ネットワーク状況の測定相手の数を示す。図５では、No of Destinationsフィールドの値は１である。拠点状況通知メッセージは、測定相手ごとに、対応するDestination IDフィールド、Delayフィールド、およびAvailable Bandwidthフィールドの３つ組フィールドを含んでいる。これらのフィールドの各値は、図３に示す３つ組フィールドの各値と同一である。
【0035】
No of Resource Statsフィールドは、通知されるリソース状況の個数を示す。この例では、ｎ個の第１ＭＥＣサーバ５におけるリソース状況が通知されるので、No of Resource Statsフィールドの値はｎである。拠点状況通知メッセージは、さらに、図４の各Node IDフィールド以下の２つのフィールド群（全部で１１×２フィールド）を、No of Resource Statsフィールドの値の数だけ含む。この例では、拠点状況通知メッセージは、ｎ個のフィールド群を含む。
【0036】
グローバルデータストア３２は、通知された拠点状況通知メッセージに含まれる、第１拠点のネットワーク状況および第１拠点の各第１ＭＥＣサーバ５における第１ワーカノード５２および第４ワーカノード５３のリソース状況（第１リソース状況）を、自身の記憶スペースに保存する。これ以降、定期的に、ステップＳ１～Ｓ７の一連の処理が繰り返し実行される。
【0037】
詳細な説明は省略するが、第２拠点においても、上述したステップＳ１～Ｓ７と同様の処理が実行される。これにより、グローバルデータストア３２は、通知された拠点状況通知メッセージに含まれる、第２拠点のネットワーク状況（第２ネットワーク状況）および第２拠点の各第２ＭＥＣサーバ７における第２ワーカノード７２および第５ワーカノード７３のリソース状況（第２リソース状況）をも、自身の記憶スペースに保存する。
【0038】
（アプリケーションの起動処理）
図６は、端末機器２がアプリケーションを起動する際にコンテナシステム１によって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、所定のアプリケーションを起動するための操作を端末機器２に入力する。ステップＳ１１において、端末機器２は、この操作を検出すると、アプリケーションを起動させるための起動Ａｐｐ２３を実行する。起動Ａｐｐ２３は、端末機器２内のイメージリポジトリ２２に予め格納されている。起動Ａｐｐ２３は、アプリケーションを起動したり終了したりするために使用されるモジュールである。起動Ａｐｐ２３を実行することによって、アプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３を、コンテナオーケストレーションクラスタ内に配置することができる。しかし起動Ａｐｐ２３は、第１ポッド８１、第２ポッド８２、および第３ポッド８３とは異なり、コンテナオーケストレーションクラスタに属していない。
図６は、端末機器２がアプリケーションを起動する際にコンテナシステム１によって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、所定のアプリケーションを起動するための操作を端末機器２に入力する。ステップＳ１１において、端末機器２は、この操作を検出すると、アプリケーションを起動させるための起動Ａｐｐ２３を実行する。起動Ａｐｐ２３は、端末機器２内のイメージリポジトリ２２に予め格納されている。起動Ａｐｐ２３は、アプリケーションを起動したり終了したりするために使用されるモジュールである。起動Ａｐｐ２３を実行することによって、アプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３を、コンテナオーケストレーションクラスタ内に配置することができる。しかし起動Ａｐｐ２３は、第１ポッド８１、第２ポッド８２、および第３ポッド８３とは異なり、コンテナオーケストレーションクラスタに属していない。
【0039】
実行された起動Ａｐｐ２３は、端末機器２のプリファレンスリポジトリ２１にアクセスし、アプリケーションに関連付けられたプリファレンスを参照する。プリファレンスとは、アプリケーションを起動する際に参照されるパラメータ群である。プリファレンスの内容は、予めユーザによって指定されている。例えば、プリファレンスは、アプリケーションの一部を第１ＭＥＣサーバ５または第２ＭＥＣサーバ７にオフロードすることを希望するかどうかを指定している。本例では、ユーザがオフロードを希望することがプリファレンスにおいて指定されているものとする。なお、プリファレンスの内容は、ユーザではなく、クラウドサーバ３によって予め指定されていてもよい。
【0040】
（アプリ起動要求）
図７は、アプリ起動要求メッセージの一例を示す図である。ステップＳ１２において、起動Ａｐｐ２３は、図７に示すようなアプリ起動要求メッセージを生成し、第１拠点内の第１ＡｐｐＡＰＩ４６に送信する。アプリ起動要求メッセージは、アプリケーションの起動を要求するためのメッセージである。図７の例では、アプリ起動要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、App IDフィールド、およびPreferenceフィールドを含む。Typeフィールドの値は、アプリ起動要求メッセージのメッセージタイプを示す“アプリ起動要求”である。User IDフィールドは、端末機器２のユーザの識別子を示す。図８の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、端末機器２のユーザの認証認可情報を示す。図８の例では、Credentialフィールドの値はCredUsr1である。App IDフィールドは、実行されるアプリケーションの識別子を示す。図８の例では、App IDフィールドの値はAppID1である。Preferenceフィールドは、起動Ａｐｐ２３がプリファレンスリポジトリ２１から読み取った情報を示す。
図７は、アプリ起動要求メッセージの一例を示す図である。ステップＳ１２において、起動Ａｐｐ２３は、図７に示すようなアプリ起動要求メッセージを生成し、第１拠点内の第１ＡｐｐＡＰＩ４６に送信する。アプリ起動要求メッセージは、アプリケーションの起動を要求するためのメッセージである。図７の例では、アプリ起動要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、App IDフィールド、およびPreferenceフィールドを含む。Typeフィールドの値は、アプリ起動要求メッセージのメッセージタイプを示す“アプリ起動要求”である。User IDフィールドは、端末機器２のユーザの識別子を示す。図８の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、端末機器２のユーザの認証認可情報を示す。図８の例では、Credentialフィールドの値はCredUsr1である。App IDフィールドは、実行されるアプリケーションの識別子を示す。図８の例では、App IDフィールドの値はAppID1である。Preferenceフィールドは、起動Ａｐｐ２３がプリファレンスリポジトリ２１から読み取った情報を示す。
【0041】
端末機器２は、ネットワークに接続する際、端末機器２の最寄りの第１拠点に配置される第１ＡｐｐＡＰＩ４６のアドレス等を取得する。ステップＳ１３において、第１ＡｐｐＡＰＩ４６は、受信したアプリ起動要求メッセージに基づいて、端末機器２のユーザの認証および認可を実行する。その際、第１ＡｐｐＡＰＩ４６は、携帯電話網などのコントロールプレーンにアクセスしてもよい。
【0042】
（アプリ構成情報要求）
図８は、アプリ構成情報要求メッセージの一例を示す図である。ステップＳ１４において、第１ＡｐｐＡＰＩ４６は、図８に示すようなアプリ構成情報要求メッセージを生成し、第１ローカルイメージリポジトリ４５に送信する。アプリ構成情報要求メッセージは、アプリケーションのポッド構成情報を要求するためのメッセージである。図８の例では、アプリ構成情報要求メッセージは、TypeフィールドおよびApp IDフィールドを含む。Typeフィールドの値は、アプリ構成情報要求メッセージのメッセージタイプを示す“アプリ構成情報要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。
図８は、アプリ構成情報要求メッセージの一例を示す図である。ステップＳ１４において、第１ＡｐｐＡＰＩ４６は、図８に示すようなアプリ構成情報要求メッセージを生成し、第１ローカルイメージリポジトリ４５に送信する。アプリ構成情報要求メッセージは、アプリケーションのポッド構成情報を要求するためのメッセージである。図８の例では、アプリ構成情報要求メッセージは、TypeフィールドおよびApp IDフィールドを含む。Typeフィールドの値は、アプリ構成情報要求メッセージのメッセージタイプを示す“アプリ構成情報要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。
【0043】
第１ローカルイメージリポジトリ４５は、アプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３のイメージを一時的に保持することができる。第１ローカルイメージリポジトリ４５は、アプリ構成情報要求メッセージを受信した時点において、受信したアプリ構成情報要求メッセージによって示されるアプリケーションのポッドイメージをまだ保持していない。そこで第１ローカルイメージリポジトリ４５は、ステップＳ１５において、受信したアプリ構成情報要求メッセージをオリジンイメージリポジトリ３３に送信する。ここで送信されるアプリ構成情報要求メッセージの構成および内容は、図８に示すアプリ構成情報要求メッセージの構成および内容と同一である。
【0044】
（アプリ構成情報応答）
図９は、アプリ構成情報応答メッセージの一例を示す図である。オリジンイメージリポジトリ３３の記憶スペースには、コンテナシステム１によって実行可能な全アプリケーションの全ポッドイメージが、予め保存されている。オリジンイメージリポジトリ３３は、アプリ構成情報要求メッセージを受信すると、アプリ構成情報要求メッセージによって示されるアプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３のイメージを、自身の記憶スペースから読み出す。オリジンイメージリポジトリ３３は、ステップＳ１６において、読み出した各ポッドイメージに基づいて、図９に示すようなアプリ構成情報応答メッセージを生成し、第１ローカルイメージリポジトリ４５に送信する。
図９は、アプリ構成情報応答メッセージの一例を示す図である。オリジンイメージリポジトリ３３の記憶スペースには、コンテナシステム１によって実行可能な全アプリケーションの全ポッドイメージが、予め保存されている。オリジンイメージリポジトリ３３は、アプリ構成情報要求メッセージを受信すると、アプリ構成情報要求メッセージによって示されるアプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３のイメージを、自身の記憶スペースから読み出す。オリジンイメージリポジトリ３３は、ステップＳ１６において、読み出した各ポッドイメージに基づいて、図９に示すようなアプリ構成情報応答メッセージを生成し、第１ローカルイメージリポジトリ４５に送信する。
【0045】
アプリ構成情報応答メッセージは、アプリケーションのポッド構成情報を応答するためのメッセージである。図９の例では、アプリ構成情報応答メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、アプリ構成情報応答メッセージのメッセージタイプを示す“アプリ構成情報応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、アプリケーションを構成するポッドの数を示す。図９の例では、No of Podsフィールドの値は３である。
【0046】
アプリ構成情報応答メッセージは、１つのポッドについて、Pod IDフィールド、No of CPUsフィールド、Memoryフィールド、Storageフィールド、No of GPUsフィールド、GPU MemoryフィールドおよびNet Reqフィールドを含む７つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。No of CPUsフィールドは、ポッドが必要とする仮想ＣＰＵの数を示す。Memoryフィールドは、ポッドが必要とするメモリ容量を示す。Storageフィールドは、ポッドが必要とするストレージ容量を示す。No of GPUsフィールドは、ポッドが必要とするＧＰＵの数を示す。GPU Memoryフィールドは、ポッドが必要とするＧＰＵメモリ容量を示す。Net Reqフィールドは、ポッドが必要とするネットワークへの要求事項を示す。
【0047】
図９に示す例では、１つ目の７つ組フィールドに含まれるPod IDフィールドは、PodID1である。No of CPUsフィールドは、第１ポッド８１が必要とする仮想ＣＰＵの数を示す。Memoryフィールドは、第１ポッド８１が必要とするメモリ容量を示す。Storageフィールドは、第１ポッド８１が必要とするストレージ容量を示す。No of GPUsフィールドは、第１ポッド８１が必要とするＧＰＵの数を示す。GPU Memoryフィールドは、第１ポッド８１が必要とするＧＰＵメモリ容量を示す。
【0048】
アプリ構成情報応答メッセージは、さらに、第２ポッド８２に関する７つ組フィールドと、第３ポッド８３に関する７つ組フィールドとを含む。
【0049】
第１ローカルイメージリポジトリ４５は、アプリ構成情報応答メッセージを受信すると、受信したアプリ構成情報応答メッセージに含まれるアプリ構成情報を、第１ローカルイメージリポジトリ４５の記憶スペースに一時的に保持する。第１ローカルイメージリポジトリ４５は、記憶スペースが不足した場合は、ＬＲＵ（Least Recently Used）アルゴリズム等にしたがって、記憶スペースを確保する。ステップＳ１７において、第１ローカルイメージリポジトリ４５は、受信したアプリ構成情報応答メッセージを、第１ＡｐｐＡＰＩ４６に送信する。この際に送信されるアプリ構成情報応答メッセージの構成および内容は、図９に示すアプリ構成情報応答メッセージの構成および内容と同一である。
【0050】
（ポッド配置決定要求）
図１０は、ポッド配置決定要求メッセージの一例を示す図である。ステップＳ１８において、第１ＡｐｐＡＰＩ４６は、受信したアプリ構成情報応答メッセージに基づいて、図１０に示すようなポッド配置決定要求メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ポッド配置決定要求は、アプリケーションを構成する第１ポッド８１および第２ポッド８２の配置決定を要求するためのメッセージである。図１０の例では、ポッド配置決定要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定要求メッセージのメッセージタイプを示す“ポッド配置決定要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、アプリケーションを構成するポッドの数を示す。アプリケーションは３個のポッドから構成され、そのうち１つは端末機器２に配置される。そのため図１１の例では、No of Podsフィールドの値は２である。
図１０は、ポッド配置決定要求メッセージの一例を示す図である。ステップＳ１８において、第１ＡｐｐＡＰＩ４６は、受信したアプリ構成情報応答メッセージに基づいて、図１０に示すようなポッド配置決定要求メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ポッド配置決定要求は、アプリケーションを構成する第１ポッド８１および第２ポッド８２の配置決定を要求するためのメッセージである。図１０の例では、ポッド配置決定要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定要求メッセージのメッセージタイプを示す“ポッド配置決定要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、アプリケーションを構成するポッドの数を示す。アプリケーションは３個のポッドから構成され、そのうち１つは端末機器２に配置される。そのため図１１の例では、No of Podsフィールドの値は２である。
【0051】
ポッド配置決定要求メッセージは、ポッドごとに、Pod IDフィールド、No of CPUsフィールド、Memoryフィールド、Storageフィールド、No of GPUsフィールド、GPU Memoryフィールド、およびNet Reqフィールドを含む７つ組フィールドをさらに含む。図１０の例では、ポッド配置決定要求メッセージは、２つの７つ組フィールドを含んでいる。Pod IDフィールドは、ポッドの識別子を示す。No of CPUsフィールドは、ポッドが必要とする仮想ＣＰＵの数を示す。Memoryフィールドは、ポッドが必要とするメモリ容量を示す。Storageフィールドは、ポッドが必要とするストレージ容量を示す。No of GPUsフィールドは、ポッドが必要とするＧＰＵの数を示す。GPU Memoryフィールドは、ポッドが必要とするＧＰＵメモリ容量を示す。Net Reqフィールドは、ポッドが必要とするネットワークへの要求事項を示す。
【0052】
図１０の例では、１つ目の７つ組フィールドに含まれるPod IDフィールドは、第１ポッド８１の識別子を示す。したがって、Pod IDフィールドの値はPodID1である。No of CPUsフィールドは、第１ポッド８１が必要とする仮想ＣＰＵの数を示す。Memoryフィールドは、第１ポッド８１が必要とするメモリ容量を示す。Storageフィールドは、第１ポッド８１が必要とするストレージ容量を示す。No of GPUsフィールドは、第１ポッド８１が必要とするＧＰＵの数を示す。GPU Memoryフィールドは、第１ポッド８１が必要とするＧＰＵメモリ容量を示す。Net Reqフィールドは、第１ポッド８１が必要とするネットワークへの要求事項を示す。No of CPUsフィールド等の残りの６のフィールドは、第１ポッド８１が必要とするリソースへの要求事項を示す。
【0053】
図１０の例では、２つ目の７つ組フィールドに含まれるPod IDフィールドは、第２ポッド８２の識別子を示す。したがって、Pod IDフィールドの値は、PodID2である。２つ目の７つ組フィールドに含まれるNo of CPUsフィールド等の値は、１つ目の７つ組フィールドと同様に、第２ポッド８２に関する値である。したがって、Net Reqフィールドは、第２ポッド８２が必要とするネットワークへの要求事項（第２要求事項）を示す。No of CPUsフィールド等の残りの６のフィールドは、第２ポッド８２が必要とするリソースへの要求事項を示す。
【0054】
（第１ポッド８１の配置決定）
第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第１ポッド８１および第２ポッド８２の全てを、第１拠点内のいずれかのワーカノードに配置できるか否かを判定する。その際、第１ローカルＭＡＮＯ４３は、第１ローカルデータストア４４に保存された、第１拠点に関するネットワーク状況および各第１ＭＥＣサーバ５に関するリソース状況と、受信したポッド配置決定要求メッセージに含まれる第１ポッド８１に関するネットワークへの要求事項およびリソースへの要求事項とに基づいて、第１ポッド８１を第１ワーカノード５２に配置するか否かを決定する。具体的には、第１拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第１ポッド８１に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、第１ローカルデータストア４４に保存された第１拠点内のいずれかの第１ＭＥＣサーバ５のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第１ポッド８１に関するリソース状況の要求事項を満たしているか否かを判定する。
第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第１ポッド８１および第２ポッド８２の全てを、第１拠点内のいずれかのワーカノードに配置できるか否かを判定する。その際、第１ローカルＭＡＮＯ４３は、第１ローカルデータストア４４に保存された、第１拠点に関するネットワーク状況および各第１ＭＥＣサーバ５に関するリソース状況と、受信したポッド配置決定要求メッセージに含まれる第１ポッド８１に関するネットワークへの要求事項およびリソースへの要求事項とに基づいて、第１ポッド８１を第１ワーカノード５２に配置するか否かを決定する。具体的には、第１拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第１ポッド８１に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、第１ローカルデータストア４４に保存された第１拠点内のいずれかの第１ＭＥＣサーバ５のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第１ポッド８１に関するリソース状況の要求事項を満たしているか否かを判定する。
【0055】
ここでは、第１拠点のネットワーク状況が、第１ポッド８１に関するネットワーク状況への要求事項を満たしており、かつ、第１ＭＥＣサーバ５の第１ワーカノード５２のリソース状況が、第１ポッド８１に関するリソースへの要求事項を満たしているものとする。これらの場合、第１ローカルＭＡＮＯ４３は、第１ポッド８１を、第１拠点内の第１ＭＥＣサーバ５の第１ワーカノード５２に配置することを決定する。
【0056】
また、ここでは、第１拠点のネットワーク状況が、第２ポッド８２に関するネットワーク状況の要求を満たしているが、すべての第１ＭＥＣサーバ５の第１ワーカノード５２および第４ワーカノード５３の各リソース状況が、第２ポッド８２に関するリソース状況の要求情報を満たしていないものとする。これにより、第１ローカルＭＡＮＯ４３は、第２ポッド８２については、第１拠点内の全ての第１ＭＥＣサーバ５の第１ワーカノード５２または第４ワーカノード５３に配置できないと判定する。
【0057】
図１１は、ポッド配置決定要求メッセージの一例を示す図である。ステップＳ１９において、第１ローカルＭＡＮＯ４３は、第２ポッド８２を第１拠点に配置することができない場合、第２ポッド８２を第２拠点に配置するために、図１１に示すようなポッド配置決定要求メッセージを生成し、グローバルＭＡＮＯ３１に送信する。ここで送信されるポッド配置決定要求メッセージは、第２ポッド８２の配置決定を要求するためのメッセージである。
【0058】
（第２ポッド８２の配置決定）
ステップＳ２０において、グローバルＭＡＮＯ３１は、ポッド配置決定要求メッセージを受信すると、第２ポッド８２を第２拠点の第２ＭＥＣサーバ７に配置できるか否かを判定する。その際、グローバルＭＡＮＯ３１は、グローバルデータストア３２に保存された、第２拠点のネットワーク状況（第２ネットワーク状況）および各第２ＭＥＣサーバ７のリソース状況と、受信したポッド配置決定要求メッセージに含まれる第２ポッド８２に関するネットワークへの要求事項およびリソースに対する要求事項とに基づいて、第２ポッド８２を第２ワーカノード７２に配置するか否かを決定する。具体的には、第２拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第２ポッド８２に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、グローバルデータストア３２に保存された第２拠点内のいずれかの第２ＭＥＣサーバ７のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第２ポッド８２に関するリソース状況の要求事項を満たしているか否かを判定する。
ステップＳ２０において、グローバルＭＡＮＯ３１は、ポッド配置決定要求メッセージを受信すると、第２ポッド８２を第２拠点の第２ＭＥＣサーバ７に配置できるか否かを判定する。その際、グローバルＭＡＮＯ３１は、グローバルデータストア３２に保存された、第２拠点のネットワーク状況（第２ネットワーク状況）および各第２ＭＥＣサーバ７のリソース状況と、受信したポッド配置決定要求メッセージに含まれる第２ポッド８２に関するネットワークへの要求事項およびリソースに対する要求事項とに基づいて、第２ポッド８２を第２ワーカノード７２に配置するか否かを決定する。具体的には、第２拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第２ポッド８２に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、グローバルデータストア３２に保存された第２拠点内のいずれかの第２ＭＥＣサーバ７のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第２ポッド８２に関するリソース状況の要求事項を満たしているか否かを判定する。
【0059】
ここでは、第２拠点のネットワーク状況が、第２ポッド８２に関するネットワークへの要求事項を満たしており、かつ、第２ＭＥＣサーバ５の第２ワーカノード７２のリソース状況が、第２ポッド８２に関するリソースへの要求事項を満たしているものとする。これらの場合、グローバルＭＡＮＯ３１は、第２ポッド８２を、第２拠点内の第２ＭＥＣサーバ７の第２ワーカノード７２に配置することを決定する。
【0060】
（ポッド配置決定応答）
図１２は、ポッド配置決定応答メッセージの一例を示す図である。ステップＳ２０において、グローバルＭＡＮＯ３１は、図１２に示すようなポッド配置決定応答メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ポッド配置決定応答メッセージは、第２ポッド８２の配置を決定したことを応答するためのメッセージである。図１２の例では、ポッド配置決定応答メッセージは、Typeフィールド、App IDフィールド、No of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定応答メッセージのメッセージタイプを示す“ポッド配置決定応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。図１２の例では、No of Podsフィールドの値は１である。
図１２は、ポッド配置決定応答メッセージの一例を示す図である。ステップＳ２０において、グローバルＭＡＮＯ３１は、図１２に示すようなポッド配置決定応答メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ポッド配置決定応答メッセージは、第２ポッド８２の配置を決定したことを応答するためのメッセージである。図１２の例では、ポッド配置決定応答メッセージは、Typeフィールド、App IDフィールド、No of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定応答メッセージのメッセージタイプを示す“ポッド配置決定応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。図１２の例では、No of Podsフィールドの値は１である。
【0061】
ポッド配置決定応答メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、およびNode IDを含む３つ組フィールドをさらに含む。ここでは、ポッドは１つであるため、ポッド配置決定応答メッセージは１つの３つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。図１２の例では、Pod IDフィールドの値はPodID2である。Base IDフィールドは、ポッドが配置される拠点の識別子を示す。図１２の例では、第２ポッド８２が第２拠点に配置されるので、Base IDフィールドの値はBaseID2である。Node IDフィールドは、ポッドが配置されるワーカノードの識別子を示す。図１２の例では、第２ポッド８２が第２拠点の第２ＭＥＣサーバ７の第２ワーカノード７２に配置されるので、Node IDフィールドはWnID2である。
【0062】
図１３は、ポッド配置決定応答メッセージの一例を示す図である。ステップＳ２１において、第１ローカルＭＡＮＯ４３は、第２ポッド８２に関するポッド配置決定応答メッセージを受信すると、図１３に示すようなポッド配置決定応答メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。図１３に示すポッド配置決定応答メッセージの構成は、図１２に示すポッド配置決定応答メッセージの構成に、第１ポッド８１に関する項目を加えたものである。そのため、図１３に示すポッド配置決定応答メッセージの詳細な説明は省略する。
【0063】
（ポッド配置要求）
図１４は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２２において、第１ＡｐｐＡＰＩ４６は、ポッド配置決定応答メッセージを受信すると、図１５に示すようなポッド配置要求メッセージを生成し、第１マスターノード４１に送信する。ポッド配置要求メッセージは、第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置を要求するためのメッセージである。図１４の例では、ポッド配置要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置要求メッセージのメッセージタイプを示す“ポッド配置要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。図１４の例では、ポッド配置要求メッセージによって３つの第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置が要求されるので、No of Podsフィールドの値は３である。
図１４は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２２において、第１ＡｐｐＡＰＩ４６は、ポッド配置決定応答メッセージを受信すると、図１５に示すようなポッド配置要求メッセージを生成し、第１マスターノード４１に送信する。ポッド配置要求メッセージは、第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置を要求するためのメッセージである。図１４の例では、ポッド配置要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置要求メッセージのメッセージタイプを示す“ポッド配置要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。図１４の例では、ポッド配置要求メッセージによって３つの第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置が要求されるので、No of Podsフィールドの値は３である。
【0064】
ポッド配置要求メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、Node IDフィールド、およびRepository IDフィールドという４つ組フィールドをさらに含む。図１４の例では、３つの第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置が要求されるので、ポッド配置要求メッセージは３つの４つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。Base IDフィールドは、ポッドが配置される拠点の識別子を示す。Node IDフィールドは、ポッドが配置されるワーカノードの識別子を示す。Repository IDフィールドは、ポッドのイメージを取得すべきイメージリポジトリ２２の識別子を示す。
【0065】
図１４の例では、１つ目の４つ組フィールドにおけるPod IDフィールドの値は、第１ポッド８１の識別子すなわちPodID1である。Base IDフィールドの値は、第１ポッド８１が配置される第１拠点の識別子すなわちBaseID1である。Node IDフィールドの値は、第１ポッド８１が配置される第１ワーカノード５２の識別子すなわちWnID1である。Repository IDフィールドの値は、LirID1である。２つ目の４つ組フィールドにおけるPod IDフィールドの値は、第２ポッド８２の識別子すなわちPodID2である。Base IDフィールドの値は、第２ポッド８２が配置される第２拠点の識別子すなわちBaseID2である。Node IDフィールドの値は、第２ポッド８２が配置される第２ワーカノード７２の識別子すなわちWnID2である。Repository IDフィールドの値は、LirID2である。３つ目の４つ組フィールドにおけるPod IDフィールドの値は、第３ポッド８３の識別子すなわちPodID3である。Base IDフィールドの値は、第３ポッド８３が配置される第１拠点の識別子すなわちBaseID1である。Node IDフィールドの値は、第３ポッド８３が配置される第３ワーカノードの識別子すなわちWnID3である。Repository IDフィールドの値は、LirID1である。
【0066】
（第１ポッド８１の配置）
図１５は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２３において、第１マスターノード４１は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、図１５に示すようなポッド配置要求メッセージを生成し、第１ワーカノード５２に送信する。ここで生成されるポッド配置要求メッセージは、第１ポッド８１の配置を要求するためのメッセージである。図１５に示すポッド配置要求メッセージの構成は、図１４に示すポッド配置要求メッセージの構成から、第２ポッド８２および第３ポッド８３の項目を除いたものとなっている。図１５に示す例では、ポッド配置要求メッセージに含まれるNo of Podsフィールドの値は１である。Pod IDフィールドの値は、PodID1である。Base IDフィールドの値は、BaseID1である。Node IDフィールドの値は、WnID1である。Repository IDフィールドの値は、LirID1である。
図１５は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２３において、第１マスターノード４１は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、図１５に示すようなポッド配置要求メッセージを生成し、第１ワーカノード５２に送信する。ここで生成されるポッド配置要求メッセージは、第１ポッド８１の配置を要求するためのメッセージである。図１５に示すポッド配置要求メッセージの構成は、図１４に示すポッド配置要求メッセージの構成から、第２ポッド８２および第３ポッド８３の項目を除いたものとなっている。図１５に示す例では、ポッド配置要求メッセージに含まれるNo of Podsフィールドの値は１である。Pod IDフィールドの値は、PodID1である。Base IDフィールドの値は、BaseID1である。Node IDフィールドの値は、WnID1である。Repository IDフィールドの値は、LirID1である。
【0067】
図１６は、ポッド配置応答メッセージの一例を示す図である。ステップＳ２４において、第１ワーカノード５２は、受信したポッド配置要求メッセージに基づいて、第１ポッド８１を第１ワーカノード５２に配置する。ステップＳ２５において、第１ワーカノード５２は、第１ポッド８１の配置を終了すると、ポッド配置応答メッセージを生成し、第１マスターノード４１に送信する。ポッド配置応答メッセージは、第１ポッド８１の配置を完了したことを応答するためのメッセージである。図１６に示すポッド配置応答メッセージは、TypeフィールドおよびApp IDフィールドを含む。Typeフィールドの値は、ポッド配置応答メッセージのメッセージタイプを示す“ポッド配置応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。
【0068】
ポッド配置応答メッセージは、１つのポッドについて、Pod IDフィールドおよびStatusフィールドからなる２つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。図１６の例では、Pod IDフィールドの値はPodID1である。Statusフィールドは、ポッド配置処理の終了状況を示す。図１６の例では、Statusフィールドの値は、第１ポッド８１の配置の正常終了を示す“ＯＫ”である。
【0069】
（第３ポッド８３の配置）
図１７は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２５において、第１マスターノード４１は、図１７に示すようなポッド配置要求メッセージを生成し、第３ワーカノードに送信する。図１７に示すポッド配置要求メッセージの構成は、図１５に示すポッド配置要求メッセージの構成と同一である。図１７の例では、ポッド配置要求メッセージは、第３ポッド８３の配置に関する各種の情報を含んでいる。第３ワーカノードは、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第３ポッド８３を第３ワーカノードに配置する。
図１７は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２５において、第１マスターノード４１は、図１７に示すようなポッド配置要求メッセージを生成し、第３ワーカノードに送信する。図１７に示すポッド配置要求メッセージの構成は、図１５に示すポッド配置要求メッセージの構成と同一である。図１７の例では、ポッド配置要求メッセージは、第３ポッド８３の配置に関する各種の情報を含んでいる。第３ワーカノードは、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第３ポッド８３を第３ワーカノードに配置する。
【0070】
図１８は、ポッド配置応答メッセージの一例を示す図である。ステップＳ２６において、第３ワーカノードは、第３ポッド８３の配置を終了すると、図１８に示すようなポッド配置応答メッセージを生成し、第１マスターノード４１に送信する。図１８に示すポッド配置応答メッセージの構成は、図１６に示すポッド配置応答メッセージの構成と同一である。図１８の例では、ポッド配置応答メッセージは、第３ポッド８３の配置完了に関する各種の情報を含んでいる。
【0071】
（第２ポッド８２の配置）
図１９は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２７において、第１マスターノード４１は、図１９に示すようなポッド配置要求メッセージを生成し、第４ワーカノード５３に送信する。図１９に示すポッド配置要求メッセージの構成は、図１５に示すポッド配置要求メッセージの構成と同一である。図１９の例では、ポッド配置要求メッセージは、第２ポッド８２の配置に関する各種の情報を含んでいる。第４ワーカノード５３は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第２ポッド８２を第２ワーカノード７２に配置する。
図１９は、ポッド配置要求メッセージの一例を示す図である。ステップＳ２７において、第１マスターノード４１は、図１９に示すようなポッド配置要求メッセージを生成し、第４ワーカノード５３に送信する。図１９に示すポッド配置要求メッセージの構成は、図１５に示すポッド配置要求メッセージの構成と同一である。図１９の例では、ポッド配置要求メッセージは、第２ポッド８２の配置に関する各種の情報を含んでいる。第４ワーカノード５３は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第２ポッド８２を第２ワーカノード７２に配置する。
【0072】
図２０は、ポッド配置応答メッセージの一例を示す図である。ステップＳ２８において、第２ワーカノード７２は、第２ポッド８２の配置を終了すると、図２０に示すようなポッド配置応答メッセージを生成し、第１マスターノード４１に送信する。図２０に示すポッド配置応答メッセージの構成は、図１６に示すポッド配置応答メッセージの構成と同一である。図２０の例では、ポッド配置応答メッセージは、第２ポッド８２の配置完了に関する各種の情報を含んでいる。
【0073】
以上のようにして第１ポッド８１、第２ポッド８２、および第３ポッド８３が正常に配置されることによって、アプリケーションが起動する。なお、第１ポッド８１、第２ポッド８２、および第３ポッド８３の配置順は、図６に示す順番に限らず、任意に変更できる。例えば、第３ポッド８３を最初に配置し、次に第１ポッド８１を配置し、最後に第２ポッド８２を配置してもよい。
【0074】
（ポッド配置応答）
図２１は、ポッド配置応答メッセージの一例を示す図である。ステップＳ２９において、第１マスターノード４１は、図２１に示すようなポッド配置応答メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。図２１に示すポッド配置応答メッセージの構成は、図１６、図１８、および図２０にそれぞれ示す各ポッド配置応答メッセージを統合した構成である。すなわち、図２１に示すポッド配置応答メッセージは、第１ポッド８１、第２ポッド８２、および第３ポッド８３のそれぞれの配置完了に関する情報を含んでいる。
図２１は、ポッド配置応答メッセージの一例を示す図である。ステップＳ２９において、第１マスターノード４１は、図２１に示すようなポッド配置応答メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。図２１に示すポッド配置応答メッセージの構成は、図１６、図１８、および図２０にそれぞれ示す各ポッド配置応答メッセージを統合した構成である。すなわち、図２１に示すポッド配置応答メッセージは、第１ポッド８１、第２ポッド８２、および第３ポッド８３のそれぞれの配置完了に関する情報を含んでいる。
【0075】
図２２は、アプリ起動応答メッセージの一例を示す図である。ステップＳ３０において、第１ＡｐｐＡＰＩ４６は、ポッド配置応答メッセージを受信すると、図２２に示すようなアプリ起動応答メッセージを生成し、起動Ａｐｐ２３に送信する。アプリ起動応答メッセージは、アプリケーションが起動したことを応答するためのメッセージである。図２２に示すアプリ起動応答メッセージは、Typeフィールド、App IDフィールド、およびStatusフィールドを含む。Typeフィールドの値は、アプリ起動応答メッセージのメッセージタイプを示す“アプリ起動応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。Statusフィールドは、配置処理の終了状態を示す。図２２の例では、配置処理の正常終了を示す“ＯＫ”である。
【0076】
以上のようにして起動されたアプリケーションは、第１ポッド８１、第２ポッド８２、および第３ポッド８３が連携して動作することによって、アプリケーションの実行を継続する。アプリケーションが起動したことによって、第１ＭＥＣサーバ５、第２ＭＥＣサーバ７、およびネットワークにおいて利用可能な各リソースが、アプリケーションによって消費されるリソース分だけ減少する。コンテナシステム１は、アプリケーションの起動後においても、図２に示すように、第１拠点と他の拠点との間のネットワークの状況、各第１ＭＥＣサーバ５のリソース状況、第２拠点と他の拠点との間のネットワーク状況、および各第２ＭＥＣサーバ７のリソース状況を定期的に測定する。これにより、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２に保存されるネットワーク状況およびリソース状況を、定期的に更新する。しおたがって、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２にそれぞれ格納される情報を最新の状態に維持することができる。
【0077】
（アプリケーションの停止）
図２３は、コンテナシステム１がアプリケーションを停止する際に実行する一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、所定のアプリケーションを停止させるための操作を、端末機器２に入力する。端末機器２は、この操作を検出すると、起動Ａｐｐ２３にアプリケーションの停止を指示する。
図２３は、コンテナシステム１がアプリケーションを停止する際に実行する一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、所定のアプリケーションを停止させるための操作を、端末機器２に入力する。端末機器２は、この操作を検出すると、起動Ａｐｐ２３にアプリケーションの停止を指示する。
【0078】
図２４は、アプリ停止要求メッセージの一例を示す図である。ステップＳ３１において、起動Ａｐｐ２３は、端末機器２からアプリケーションの停止指示を受けると、図２４に示すようなアプリ停止要求メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。アプリ停止要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、およびApp IDフィールドを含む。Typeフィールドの値は、アプリ停止要求メッセージのメッセージタイプを示す“アプリ停止要求”である。User IDフィールドは、端末機器２のユーザの識別子を示す。図２４の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、ユーザの認証認可情報を含む。図２４の例では、Credentialフィールドの値は、CredUsr1である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。
【0079】
ステップＳ３２において、第１ＡｐｐＡＰＩ４６は、端末機器２のユーザの認証および認可を実行する。その際、第１ＡｐｐＡＰＩ４６は、携帯電話網などのコントロールプレーンにアクセスしてもよい。ステップＳ３３において、第１ＡｐｐＡＰＩ４６は、ユーザの認証および認可に成功すると、受信したアプリ停止要求メッセージを第１マスターノード４１に送信する。
【0080】
図２５は、ポッド停止要求メッセージの一例を示す図である。ステップＳ３４において、第１マスターノード４１は、アプリ停止要求メッセージを受信すると、図２５に示すようなポッド停止要求メッセージを生成し、第１ワーカノード５２に送信する。図２５に示すポッド停止要求メッセージは、第１ポッド８１の停止を要求するためのメッセージである。図２５の例では、ポッド停止要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド停止要求メッセージのメッセージタイプを示す“ポッド停止要求”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、停止されるポッドの数を示す。図２５の例では、No of Podsフィールドの値は１である。
【0081】
ポッド停止要求メッセージは、１つのポッドについて、Pod IDフィールド、Base IDフィールド、およびNode IDフィールドからなる３つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。図２５の例では、Pod IDフィールドの値はPodID1である。Base IDフィールドは、ポッドが配置されている拠点の識別子を示す。図２５の例では、Base IDフィールドの値は、第１ポッド８１が配置されている第１拠点の識別子すなわちBaseID1である。Node IDフィールドは、ポッドが配置されているワーカノードの識別子を示す。図２５の例では、Node IDフィールドの値は、第１ポッド８１が配置されている第１ワーカノード５２の識別子すなわちWnID1である。
【0082】
図２６は、ポッド停止応答メッセージの一例を示す図である。第１ワーカノード５２は、ポッド停止要求メッセージを受信すると、第１ポッド８１を停止する。ステップＳ３５において、第１ワーカノード５２は、第１ポッド８１の停止に成功すると、図２６に示すようなポッド停止応答メッセージを生成し、第１マスターノード４１に送信する。図２６に示すポッド停止応答メッセージは、第１ポッド８１の停止に成功したことを応答するためのメッセージである。図２６の例では、ポッド停止応答メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値はメッセージタイプを示す“ポッド停止応答”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドはポッドの数を示す。この例では１である。
【0083】
ポッド停止応答メッセージは、１つのポッドについて、Pod IDフィールドおよびStatusフィールドからなる２つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。図２６の例では、Pod IDフィールドの値は、停止される第１ポッド８１の識別子すなわちPodID1である。Statusフィールドは、処理の終了状態を示す。図２６の例では、正常終了を示す“ＯＫ”である。
【0084】
ステップＳ３６において、第１マスターノード４１は、第３ポッド８３を停止させるためのポッド停止要求メッセージを生成し、第３ワーカノードに送信する。第３ワーカノードは、ポッド停止要求メッセージを受信すると、第３ポッド８３を停止する。ステップＳ３７において、第３ワーカノードは、第３ポッド８３を停止したことを応答するためのポッド停止応答メッセージを生成し、第１マスターノード４１に送信する。第３ポッド８３の停止時における各処理の手順は、第１ポッド８１の停止時における各処理の手順と同様であるため、詳細な説明を省略する。
【0085】
ステップＳ３８において、第２マスターノード６１は、第２ポッド８２を停止させるためのポッド停止要求メッセージを生成し、第２ワーカノード７２に送信する。第２ワーカノード７２は、ポッド停止要求メッセージを受信すると、第２ポッド８２を停止する。ステップＳ３９において、第２ワーカノード７２は、第２ポッド８２を停止したことを応答するためのポッド停止応答メッセージを生成し、第１マスターノード４１に送信する。第２ポッド８２の停止時における各処理の手順は、第１ポッド８１の停止時における各処理の手順と同様であるため、詳細な説明を省略する。
【0086】
図２７は、アプリ停止応答メッセージの一例を示す図である。ステップＳ４０において、第１マスターノード４１は、アプリ停止応答メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。アプリ停止応答メッセージは、アプリケーションを停止したことを応答するためのメッセージである。図２７の例では、アプリ停止応答メッセージは、Typeフィールド、App IDフィールド、およびStatusフィールドを含む。Typeフィールドの値は、アプリ停止応答メッセージのメッセージタイプを示す“アプリ停止応答”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。Statusフィールドは、処理の終了状態を示す。図２の例では、Statusフィールドの値は、アプリケーション停止の正常終了を示す“ＯＫ”である。
【0087】
ステップＳ４１において、第１ＡｐｐＡＰＩ４６は、アプリ停止応答メッセージを受信すると、受信したアプリ停止応答メッセージを起動Ａｐｐ２３に送信する。ステップＳ４２において、起動Ａｐｐ２３は、アプリ停止応答メッセージを受信すると、終了する。これにより、アプリケーションの終了が完了する。
【0088】
図２８は、測定要求メッセージの一例を示す図である。ステップＳ４３において、第１ＡｐｐＡＰＩ４６は、図２８に示すような測定要求メッセージを生成し、第１ネットワークモニタ４２に送信する。図２８に示す測定要求メッセージは、ネットワーク状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。図２８の例では、No of Targetsフィールドの値は１である。測定要求メッセージは、１つの測定要求対象につき、１つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。図２８の例では、Target IDフィールドの値は、第１ネットワークモニタ４２の識別子すなわちNmonID1である。
【0089】
図２９は、測定要求メッセージの一例を示す図である。ステップＳ４４において、第１ＡｐｐＡＰＩ４６は、図２９に示すような測定要求メッセージを生成し、第１リソースモニタ５１に送信する。図２９に示す測定要求メッセージは、リソース状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。図２９の例では、No of Targetsフィールドの値は１である。測定要求メッセージは、１つの測定要求対象につき、１つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。図２９の例では、Target IDフィールドの値は、第１リソースモニタ５１の識別子すなわちRmonID1である。
【0090】
図３０は、測定要求メッセージの一例を示す図である。ステップＳ４５において、第１ＡｐｐＡＰＩ４６は、図３０に示すような測定要求メッセージを生成し、第２ＡｐｐＡＰＩ６６に送信する。図３０に示す測定要求メッセージは、ネットワーク状況およびリソース状況の測定を要求するためのメッセージである。測定要求メッセージは、TypeフィールドおよびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。図３０の例では、No of Targetsフィールドの値は２である。測定要求メッセージは、１つの測定要求対象につき、１つのTarget IDフィールドをさらに含む。図３０の例では、測定要求メッセージは、２つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。図３０の例では、１つ目のTarget IDフィールドの値は、第２ネットワークモニタ６２の識別子すなわちNmonID2である。２つ目のTarget IDフィールドの値は、第２リソースモニタ７１の識別子すなわちRmonID2である。
【0091】
図３１は、測定要求メッセージの一例を示す図である。ステップＳ４６において、第２ＡｐｐＡＰＩ６６は、図３１に示すような測定要求メッセージを生成し、第２ネットワークモニタ６２に送信する。図３１に示す測定要求メッセージは、ネットワーク状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。図３１の例では、No of Targetsフィールドの値は１である。測定要求メッセージは、１つの測定要求対象につき、１つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。図３１の例では、Target IDフィールドの値は、第２ネットワークモニタ６２の識別子すなわちNmonID2である。
【0092】
図３２は、測定要求メッセージの一例を示す図である。ステップＳ４７において、第２ＡｐｐＡＰＩ６６は、図３２に示すような測定要求メッセージを生成し、第２リソースモニタ７１に送信する。図３２に示す測定要求メッセージは、リソース状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。図３２の例では、No of Targetsフィールドの値は１である。測定要求メッセージは、１つの測定要求対象につき、１つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。図３２の例では、Target IDフィールドの値は、第２リソースモニタ７１の識別子すなわちRmonID2である。
【0093】
ステップＳ４３～Ｓ４７に基づいて、第１ネットワークモニタ４２、第１リソースモニタ５１、第２ネットワークモニタ６２、および第２リソースモニタ７１は、図３に示す一連の処理手順を実行する。これにより、アプリケーション終了後における最新のネットワーク状況およびリソース状況が、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２に反映される。
【0094】
（本実施形態による主要な効果）
第１ＭＥＣサーバ５は、第１リソースモニタ５１によって第１ワーカノード５２のリソース状況を測定し、第１拠点装置４に送信する。第１拠点装置４は、第１ネットワークモニタ４２を使用することによって、第１拠点から第２拠点への通信時のネットワーク状況（通信遅延等）を測定する。これらのネットワーク状況およびリソース状況は、第１ローカルデータストア４４に保存する。第１ローカルＭＡＮＯ４３は、第１ローカルデータストア４４に保存されたネットワーク状況およびリソース状況に基づいて、第１ポッド８１を第１ＭＥＣサーバ５に配置するか否かを決定する。これにより、ネットワーク状況およびリソース状況を考慮した第１ポッド８１の配置が可能になるため、第１ポッド８１を最適な第１ワーカノード５２に配置することができる。
第１ＭＥＣサーバ５は、第１リソースモニタ５１によって第１ワーカノード５２のリソース状況を測定し、第１拠点装置４に送信する。第１拠点装置４は、第１ネットワークモニタ４２を使用することによって、第１拠点から第２拠点への通信時のネットワーク状況（通信遅延等）を測定する。これらのネットワーク状況およびリソース状況は、第１ローカルデータストア４４に保存する。第１ローカルＭＡＮＯ４３は、第１ローカルデータストア４４に保存されたネットワーク状況およびリソース状況に基づいて、第１ポッド８１を第１ＭＥＣサーバ５に配置するか否かを決定する。これにより、ネットワーク状況およびリソース状況を考慮した第１ポッド８１の配置が可能になるため、第１ポッド８１を最適な第１ワーカノード５２に配置することができる。
【0095】
第１ローカルＭＡＮＯ４３は、第１ローカルデータストア４４に保存されたネットワーク状況およびリソース状況に基づいて、第１ポッド８１が要求するネットワークへの要求事項およびリソースへの要求事項を満たす第１ＭＥＣサーバ５に第１ポッド８１を配置することを決定する。これにより、第１ポッド８１を確実に配置することができる。
【0096】
第２ＭＥＣサーバ７は、第２リソースモニタ７１によって第２ワーカノード７２のリソース状況を測定し、第２拠点装置６に送信する。第２拠点装置６は、第２ネットワークモニタ６２を使用することによって、第２拠点から第１拠点への通信時のネットワーク状況（通信遅延等）を測定し、第２ローカルデータストア６４に保存する。これらのネットワーク状況およびリソース状況は、グローバルデータストア３２にも保存される。グローバルＭＡＮＯ３１は、グローバルデータストア３２に保存された第２拠点に関するネットワーク状況およびリソース状況を考慮することによって、第２ポッド８２を第２ＭＥＣサーバ７の第２ワーカノード７２に配置するか否かを決定する。この結果、ネットワーク状況を考慮したポッド配置が可能となるため、通信遅延が少ない等の良好なネットワーク状況にある各ワーカノードに各ポッドを配置することができる。さらに、ネットワークを介して広域分散した拠点間でのポッドの最適な配置が可能となる。
【0097】
第１ＭＥＣサーバ５は、第１ワーカノード５２が複数のコンテナオーケストレーションクラスタに属していたとしても、第１リソースモニタ５１を使用することによって、第１ワーカノード５２の正しいリソース状況を測定することができる。これにより、第１ワーカノード５２の正しいリソース状況に基づいて第１ポッド８１を第１ワーカノード５２に配置するか否かを決定することができるため、第１ポッド８１の配置に失敗する可能性を低下させることができる。
【0098】
同様に、第２ＭＥＣサーバ７は、第２ワーカノード７２が複数のコンテナオーケストレーションクラスタに属していたとしても、第２リソースモニタ７１を使用することによって、第２ワーカノード７２の正しいリソース状況を測定することができる。したがって、クラウドサーバ３は、第１拠点装置４から受信した各第１ＭＥＣサーバ５のリソース状況および第２拠点装置６から受信した各第２ＭＥＣサーバ７のリソース状況をグローバルデータストア３２に保存することによって、全てのワーカノードのリソース状況を正しく把握することができる。
【0099】
コンテナオーケストレーションクラスタとして実行されるアプリケーションの起動後、コンテナオーケストレーションクラスタとして実行されるアプリケーションを構成する第１ポッド８１は、端末機器２が接続されるネットワーク内の第１ＭＥＣサーバ５に配置されている。また、第２ポッド８２は、端末機器２が接続されるネットワーク内の第２ＭＥＣサーバ７に配置されている。さらに、第３ポッド８３は、端末機器２に配置されている。一方、アプリケーションを起動させるための起動Ａｐｐ２３は、コンテナオーケストレーションクラスタに属していない。そのため、アプリケーションの実行中に、起動Ａｐｐ２３と第１ポッド８１、第２ポッド８２、および第３ポッド８３のいずれかとが、中継ポッドを介して通信することはない。さらに、アプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３の間で、中継ポッドを介した通信が行われない。これらにより、アプリケーションの起動時および起動後の実行時において、ポッド間の通信経路が冗長になることを防止することができる。
【0100】
既存のコンテナオーケストレーションシステムに対してコンテナシステム１を新たに導入する際、既存のコンテナオーケストレーションシステムの部分に対する変更は必要としない。そのため、稼働中の既存のコンテナオーケストレーションシステムに対してコンテナシステム１を容易に導入することができる。
【0101】
端末機器２において実行されるアプリケーションの一部を、第１ＭＥＣサーバ５および第２ＭＥＣサーバ７に効率的にオフロードすることができる。
【0102】
（変形例）
コンテナシステム１では、第１ワーカノード５２が複数の異なるコンテナオーケストレーションクラスタに属すると共に、第２ワーカノード７２が複数の異なるコンテナオーケストレーションクラスタに属しても良い。この場合も、第１ＭＥＣサーバ５は、第１リソースモニタ５１を使用することによって、第１ワーカノード５２および第４ワーカノード５３のリソース状況を正確に測定する。測定された各第１ＭＥＣサーバ５のリソース状況は、第１拠点装置４において集約され、かつクラウドサーバ３に送信される。同様に、測定された各第２ＭＥＣサーバ７のリソース状況は、第２拠点装置６において集約され、かつクラウドサーバ３に送信される。クラウドサーバ３は、受信した各リソース状況を、グローバルデータストア３２に保存する。したがって、クラウドサーバ３は、全てのワーカノードのリソース状況を正しく把握することができる。
コンテナシステム１では、第１ワーカノード５２が複数の異なるコンテナオーケストレーションクラスタに属すると共に、第２ワーカノード７２が複数の異なるコンテナオーケストレーションクラスタに属しても良い。この場合も、第１ＭＥＣサーバ５は、第１リソースモニタ５１を使用することによって、第１ワーカノード５２および第４ワーカノード５３のリソース状況を正確に測定する。測定された各第１ＭＥＣサーバ５のリソース状況は、第１拠点装置４において集約され、かつクラウドサーバ３に送信される。同様に、測定された各第２ＭＥＣサーバ７のリソース状況は、第２拠点装置６において集約され、かつクラウドサーバ３に送信される。クラウドサーバ３は、受信した各リソース状況を、グローバルデータストア３２に保存する。したがって、クラウドサーバ３は、全てのワーカノードのリソース状況を正しく把握することができる。
【0103】
さらに、コンテナシステム１では、第１拠点装置４の代わりにクラウドサーバ３が、第１ポッド８１の配置を決定してもよい。本例では、第１ＡｐｐＡＰＩ４６は、図１０に示すポッド配置決定要求メッセージを、第１ローカルＭＡＮＯ４３ではなく、グローバルＭＡＮＯ３１に通知する。グローバルＭＡＮＯ３１は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第１ポッド８１および第２ポッド８２の全てを、第１拠点および第２拠点のうちいずれに配置するのかを決定する。
【0104】
具体的には、グローバルＭＡＮＯ３１は、グローバルデータストア３２に保存された、第１拠点のネットワーク状況、各第１ＭＥＣサーバ５のリソース状況、第２拠点のネットワーク状況、および各第２ＭＥＣサーバ７のリソース状況と、受信したポッド配置決定要求メッセージに含まれる第１ポッド８１に関するネットワークへの要求事項およびリソースに対する要求事項とに基づいて、第１ポッド８１を第１ワーカノード５２および第２ワーカノード７２のうちいずれのワーカノードに設置するのかを決定する。グローバルＭＡＮＯ３１は、例えば、第１拠点のネットワーク状況および第１ＭＥＣサーバ５の第１ワーカノード５２のリソース状況が、第１ポッド８１に関するネットワークへの要求事項およびリソースに対する要求事項を満たす場合、第１ポッド８１を第１ＭＥＣサーバ５の第１ワーカノード５２に配置することを決定する。グローバルＭＡＮＯ３１は、あるいは、第２拠点のネットワーク状況および第２ＭＥＣサーバ７の第２ワーカノード７２のリソース状況が、第１ポッド８１に関するネットワークへの要求事項およびリソースに対する要求事項を満たす場合、第１ポッド８１を第２ＭＥＣサーバ５の第２ワーカノード７２に配置することを決定する。このように、グローバルＭＡＮＯ３１は、各拠点のネットワーク状況および各ワーカノードのネットワーク状況を考慮して、第１ポッド８１を配置すべき最適なＭＥＣサーバ（ワーカノード）を選択することができる。
【0105】
第１ローカルイメージリポジトリ４５は、アプリ構成情報要求メッセージを受信した時点において、受信したアプリ構成情報要求メッセージによって示されるアプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３の各イメージを予め保存していてもよい。この場合、第１ローカルイメージリポジトリ４５は、受信したアプリ構成情報要求メッセージをオリジンイメージリポジトリ３３に送信することなく、アプリ構成情報要求メッセージによって示されるアプリケーションを構成する第１ポッド８１、第２ポッド８２、および第３ポッド８３のイメージを、自身の記憶スペースから読み出す。第１ローカルイメージリポジトリ４５は、読み出した各ポッドイメージに基づいて、図９に示すようなアプリ構成情報応答メッセージを生成し、第１ＡｐｐＡＰＩ４６に送信する。本例では、アプリ構成情報要求メッセージをオリジンイメージリポジトリ３３に送信したり、オリジンイメージリポジトリ３３からアプリ構成情報応答メッセージを受信したりする必要がなくなるため、通信遅延を低減することができる。さらには、クラウドと各拠点との間の通信トラフィックを削減することもできる。
【0106】
〔実施形態２〕
（コンテナシステム１Ａの構成）
図３３は、第２実施形態に係るコンテナシステム１Ａの構成を示すブロック図である。端末機器２Ａは、クライアントＡｐｐ２４を実行している。クライアントＡｐｐ２４は、クライアント・サーバ型アプリケーションにおけるクライアントアプリケーションである。クラウドサーバ３Ａは、サーバＡｐｐ３４を実行している。サーバＡｐｐ３４は、クライアント・サーバ型アプリケーションにおけるサーバアプリケーションである。
（コンテナシステム１Ａの構成）
図３３は、第２実施形態に係るコンテナシステム１Ａの構成を示すブロック図である。端末機器２Ａは、クライアントＡｐｐ２４を実行している。クライアントＡｐｐ２４は、クライアント・サーバ型アプリケーションにおけるクライアントアプリケーションである。クラウドサーバ３Ａは、サーバＡｐｐ３４を実行している。サーバＡｐｐ３４は、クライアント・サーバ型アプリケーションにおけるサーバアプリケーションである。
【0107】
本実施形態では、コンテナオーケストレーションクラスタは、第１マスターノード４１、第１ワーカノード５２、第４ワーカノード５３、および不図示の中継ポッドによって構成されている。図３３は、サーバＡｐｐ３４に対応するサーバアプリケーションが、第１ワーカノード５２上で動作する第１ポッド８１と、第２ワーカノード７２上で動作する第２ポッド８２とによって構成されるコンテナオーケストレーションクラスタとして動作する例を示している。図３４に示す各モジュールの識別子は、実施形態１で説明した各識別子と同一である。ただし、実施形態１では端末機器２で起動されたアプリケーションの識別子であるAppID1を、本実施形態ではサーバＡｐｐ３４に対応するサーバアプリケーションの識別子として扱う。
【0108】
図３４は、端末機器２がクライアントＡｐｐ２４を起動する際にコンテナシステム１Ａによって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、クライアントＡｐｐ２４を起動するための操作を端末機器２に入力する。ステップＳ５１において、端末機器２Ａは、この操作を検出すると、クライアントＡｐｐ２４を起動する。
【0109】
図３５は、アプリ要求メッセージの一例を示す図である。ステップＳ５２において、起動されたクライアントＡｐｐ２４は、サーバＡｐｐ３４にアプリ要求メッセージを送信する。アプリ要求メッセージは、サーバＡｐｐ３４に要求を送信するためのメッセージである。アプリ要求メッセージは、ＨＴＴＰＲｅｑｕｅｓｔメッセージでもよい。なお、サーバＡｐｐ３４は、端末機器２Ａのアドレスから端末機器２Ａに近い拠点が第１拠点であることを知ることができるものとする。
【0110】
アプリ要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、App IDフィールド、およびRequestフィールドを含む。Typeフィールドの値は、アプリ要求メッセージのメッセージタイプを示す“アプリ要求”である。User IDフィールドは、端末機器２のユーザの識別子を示す。図３５の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、ユーザの認証認可情報を含む。図３５の例では、Credentialフィールドの値は、CredUsr1である。App IDフィールドの値は、サーバＡｐｐ３４に対応するサーバアプリケーションの識別子であり、具体的にはAppID1である。Requestフィールドは、クライアントＡｐｐ２４の要求内容を示す。ステップＳ５３において、サーバＡｐｐ３４は、受信したアプリ要求メッセージに基づいて、端末機器２のユーザを認証しかつ認可する。
【0111】
ステップＳ５４において、サーバＡｐｐ３４は、ユーザの認証および認可に成功すると、ポッド配置決定要求メッセージを生成し、第１拠点内の第１ローカルＭＡＮＯ４３に送信する。ポッド配置決定要求メッセージは、サーバＡｐｐ３４に対応するサーバアプリケーションを構成する第１ポッド８１および第２ポッド８２の配置決定を要求するためのメッセージである。このポッド配置決定要求メッセージは、図１０に示すポッド配置決定要求メッセージと同一である。
【0112】
（第１ポッド８１の配置決定）
第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第１ポッド８１および第２ポッド８２の全てを、第１拠点内の各ワーカノードに配置できるか否かを決定する。決定方法の詳細は、第１実施形態のそれと同一であるため、詳細な説明を省略する。ここでは、第１ローカルＭＡＮＯ４３は、第１ポッド８１を第１拠点内の第１ＭＥＣサーバ５の第１ワーカノード５２に配置することを決定するものとする。また、第１ローカルＭＡＮＯ４３はさらに、第２ポッド８２については、第１拠点内の他の全ての第１ＭＥＣサーバ５の第１ワーカノード５２または第４ワーカノード５３に配置できないと決定するものとする。これにより、ステップＳ５５において、第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを生成し、グローバルＭＡＮＯ３１に送信する。ここで送信されるポッド配置決定要求メッセージは、第２ポッド８２の配置決定を要求するためのメッセージである。また、その構成および内容は、図１１に示すポッド配置決定要求メッセージの構成および内容と同一である。
第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第１ポッド８１および第２ポッド８２の全てを、第１拠点内の各ワーカノードに配置できるか否かを決定する。決定方法の詳細は、第１実施形態のそれと同一であるため、詳細な説明を省略する。ここでは、第１ローカルＭＡＮＯ４３は、第１ポッド８１を第１拠点内の第１ＭＥＣサーバ５の第１ワーカノード５２に配置することを決定するものとする。また、第１ローカルＭＡＮＯ４３はさらに、第２ポッド８２については、第１拠点内の他の全ての第１ＭＥＣサーバ５の第１ワーカノード５２または第４ワーカノード５３に配置できないと決定するものとする。これにより、ステップＳ５５において、第１ローカルＭＡＮＯ４３は、ポッド配置決定要求メッセージを生成し、グローバルＭＡＮＯ３１に送信する。ここで送信されるポッド配置決定要求メッセージは、第２ポッド８２の配置決定を要求するためのメッセージである。また、その構成および内容は、図１１に示すポッド配置決定要求メッセージの構成および内容と同一である。
【0113】
（第２ポッド８２の配置決定）
グローバルＭＡＮＯ３１は、ポッド配置決定要求メッセージを受信すると、第２ポッド８２を第２拠点の第２ＭＥＣサーバ７に配置するか否かを決定する。決定方法の詳細は、第１実施形態のそれと同一であるため、詳細な説明は省略する。ここでは、グローバルＭＡＮＯ３１は、第２ポッド８２を第２ＭＥＣサーバ７の第２ワーカノード７２に配置することを決定するものとする。これにより、ステップＳ５６において、グローバルＭＡＮＯ３１は、第１ポッド８１の配置決定を応答するためのポッド配置決定応答メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ここで送信されるポッド配置決定応答メッセージの構成および内容は、図１２に示すポッド配置決定応答メッセージの構成および内容と同一である。
グローバルＭＡＮＯ３１は、ポッド配置決定要求メッセージを受信すると、第２ポッド８２を第２拠点の第２ＭＥＣサーバ７に配置するか否かを決定する。決定方法の詳細は、第１実施形態のそれと同一であるため、詳細な説明は省略する。ここでは、グローバルＭＡＮＯ３１は、第２ポッド８２を第２ＭＥＣサーバ７の第２ワーカノード７２に配置することを決定するものとする。これにより、ステップＳ５６において、グローバルＭＡＮＯ３１は、第１ポッド８１の配置決定を応答するためのポッド配置決定応答メッセージを生成し、第１ローカルＭＡＮＯ４３に送信する。ここで送信されるポッド配置決定応答メッセージの構成および内容は、図１２に示すポッド配置決定応答メッセージの構成および内容と同一である。
【0114】
ステップＳ５７において、第１ローカルＭＡＮＯ４３は、第１ポッド８１および第２ポッド８２の配置決定を応答するためのポッド配置決定応答メッセージを生成し、サーバＡｐｐ３４に送信する。ここで送信されるポッド配置決定応答メッセージの構成および内容は、図１３に示すポッド配置決定応答メッセージの構成および内容と同一である。
【0115】
図３６は、ポッド配置要求メッセージの一例を示す図である。ステップＳ５８において、サーバＡｐｐ３４は、ポッド配置決定応答メッセージを受信すると、図３６に示すようなポッド配置要求メッセージを生成し、第１マスターノード４１に送信する。ポッド配置要求メッセージは、第１ポッド８１および第２ポッド８２の配置を要求するためのメッセージである。図３６の例では、ポッド配置要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置要求メッセージのメッセージタイプを示す“ポッド配置要求”である。App IDフィールドの値は、サーバＡｐｐ３４に対応するサーバアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。図３６の例では、ポッド配置要求メッセージによって３つの第１ポッド８１および第２ポッド８２の配置が要求されるので、No of Podsフィールドの値は２である。
【0116】
ポッド配置要求メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、Node IDフィールド、およびRepository IDフィールドという４つ組フィールドをさらに含む。図３６の例では、２つの第１ポッド８１および第２ポッド８２の配置が要求されるので、ポッド配置要求メッセージは３つの４つ組フィールドをさらに含む。図３６の例では、１つ目の４つ組フィールドにおけるPod IDフィールドの値は、第１ポッド８１の識別子すなわちPodID1である。Base IDフィールドの値は、第１ポッド８１が配置される第１拠点のBaseID1である。Node IDフィールドの値は、第１ポッド８１が配置される第１ワーカノード５２の識別子すなわちWnID1である。Repository IDフィールドの値は、LirID1である。２つ目の４つ組フィールドにおけるPod IDフィールドの値は、第２ポッド８２の識別子すなわちPodID2である。Base IDフィールドの値は、第２ポッド８２が配置される第２拠点の識別子すなわちBaseID2である。Node IDフィールドの値は、第２ポッド８２が配置される第２ワーカノード７２の識別子すなわちWnID2である。Repository IDフィールドの値は、LirID2である。
【0117】
（第１ポッド８１の配置）
ステップＳ５９において、第１マスターノード４１は、ポッド配置要求メッセージを受信すると、第１ポッド８１の配置を要求するためのポッド配置要求メッセージを生成し、第１ワーカノード５２に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、図１５に示すポッド配置要求メッセージの構成および内容と同一である。第１ワーカノード５２は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第１ワーカノード５２に第１ポッド８１を配置する。ステップＳ６０において、第１ワーカノード５２は、第１ポッド８１の配置を応答するためのポッド設置応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、図１６に示すポッド設置応答メッセージの構成および内容と同一である。
ステップＳ５９において、第１マスターノード４１は、ポッド配置要求メッセージを受信すると、第１ポッド８１の配置を要求するためのポッド配置要求メッセージを生成し、第１ワーカノード５２に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、図１５に示すポッド配置要求メッセージの構成および内容と同一である。第１ワーカノード５２は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第１ワーカノード５２に第１ポッド８１を配置する。ステップＳ６０において、第１ワーカノード５２は、第１ポッド８１の配置を応答するためのポッド設置応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、図１６に示すポッド設置応答メッセージの構成および内容と同一である。
【0118】
（第２ポッド８２の配置）
ステップＳ６１において、第１マスターノード４１は、第２ポッド８２の配置を要求するためのポッド配置要求メッセージを生成し、第２ワーカノード７２に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、図１６に示すポッド配置要求メッセージの構成および内容と同一である。第２ワーカノード７２は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第２ワーカノード７２に第２ポッド８２を配置する。ステップＳ６２において、第４ワーカノード５３は、第２ポッド８２の配置を応答するためのポッド設置応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、図１７に示すポッド設置応答メッセージの構成および内容と同一である。
ステップＳ６１において、第１マスターノード４１は、第２ポッド８２の配置を要求するためのポッド配置要求メッセージを生成し、第２ワーカノード７２に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、図１６に示すポッド配置要求メッセージの構成および内容と同一である。第２ワーカノード７２は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第２ワーカノード７２に第２ポッド８２を配置する。ステップＳ６２において、第４ワーカノード５３は、第２ポッド８２の配置を応答するためのポッド設置応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、図１７に示すポッド設置応答メッセージの構成および内容と同一である。
【0119】
図３７は、ポッド配置応答メッセージの一例を示す図である。ステップＳ６３において、第１マスターノード４１は、図３７に示すようなポッド配置応答メッセージを生成し、サーバＡｐｐ３４に送信する。図３７に示すポッド配置応答メッセージの構成は、図１６および図１８にそれぞれ示す各ポッド配置応答メッセージを統合した構成である。すなわち、図２１に示すポッド配置応答メッセージは、第１ポッド８１および第２ポッド８２のそれぞれの配置完了に関する情報を含んでいる。
【0120】
図３８は、アプリ応答メッセージの一例を示す図である。ステップＳ６４において、サーバＡｐｐ３４は、図３８に示すようなアプリ応答メッセージを生成し、クライアントＡｐｐ２４に送信する。アプリ応答メッセージは、サーバＡｐｐ３４に対応するサーバアプリケーションの起動を応答するためのメッセージである。図３８の例では、アプリ応答メッセージは、Typeフィールド、Statusフィールド、Redirectフィールド、およびResponseフィールドを含む。Typeフィールドの値は、アプリ応答メッセージのメッセージタイプを示す“アプリ応答”である。Statusフィールドは、処理の終了状態を示す。この例では、サーバＡｐｐ３４に対応するサーバアプリケーションの起動の正常終了を示す“ＯＫ”である。Redirectフィールドは、これ以降のアプリ要求メッセージの送り先モジュールの識別子を示す。図３８の例では、中継ポッドの識別子すなわちRelayPodID1である。Responseフィールドは、応答内容を示す。
【0121】
以上のようにして起動された、コンテナオーケストレーションクラスタとしてのサーバアプリケーションは、第１ポッド８１および第２ポッド８２が連携して動作することによって、サーバＡｐｐ３４としての実行を継続する。これ以降、クライアントＡｐｐ２４の通信相手は、クラウドサーバ上のサーバＡｐｐ３４ではなく、第１拠点および２に構築された、コンテナオーケストレーションクラスタとしてのサーバアプリケーションである。したがって、ステップＳ６５において、クライアントＡｐｐ２４は、新たなアプリ要求メッセージを、クラウドサーバ上のサーバＡｐｐ３４ではなく、第１ポッド８１が配置される第１ワーカノード５２に送信する。第１ワーカノード５２がアプリ要求メッセージを受信すると、第１ポッド８１は第２ポッド８２と連携して動作することによって、アプリ要求メッセージによって要求される処理を実行する。ステップ６６において、第１ワーカノード５２は、コンテナオーケストレーションクラスタとしてのサーバＡｐｐ３４による処理を応答するためのアプリ応答メッセージを生成し、クライアントＡｐｐ２４に送信する。
【0122】
本実施形態では、コンテナオーケストレーションクラスタとしてのサーバアプリケーションが起動したことによって、第１ＭＥＣサーバ５、第２ＭＥＣサーバ７、およびネットワークにおいて利用可能な各リソースが、サーバＡｐｐ３４に対応するサーバアプリケーションによって消費されるリソース分だけ減少する。コンテナシステム１Ａは、サーバＡｐｐ３４に対応するサーバアプリケーションの起動後においても、図２に示すように、第１拠点のネットワークの状況、各第１ＭＥＣサーバ５のリソース状況、第２拠点のネットワーク状況、および各第２ＭＥＣサーバ７のリソース状況を定期的に測定する。これにより、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２に保存されるネットワーク状況およびリソース状況を、定期的に更新する。したがって、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２にそれぞれ格納される情報を最新の状態に維持することができる。
【0123】
（サーバアプリケーションの停止）
図３９は、サーバアプリケーションを停止する際にコンテナシステム１Ａによって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、サーバＡｐｐ３４として動作するサーバアプリケーションを終了させるための操作を、端末機器２Ａに入力する。ステップＳ７１において、クライアントＡｐｐ２４は、端末機器２Ａがこの操作を検出すると、サーバアプリケーションの終了を要求のためのアプリ終了要求メッセージを生成し、サーバＡｐｐ３４に送信する。ここで送信されるアプリ終了要求メッセージの構成および内容は、図２４に示すアプリ終了要求メッセージの構成および内容と同一である。
図３９は、サーバアプリケーションを停止する際にコンテナシステム１Ａによって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器２を操作し、サーバＡｐｐ３４として動作するサーバアプリケーションを終了させるための操作を、端末機器２Ａに入力する。ステップＳ７１において、クライアントＡｐｐ２４は、端末機器２Ａがこの操作を検出すると、サーバアプリケーションの終了を要求のためのアプリ終了要求メッセージを生成し、サーバＡｐｐ３４に送信する。ここで送信されるアプリ終了要求メッセージの構成および内容は、図２４に示すアプリ終了要求メッセージの構成および内容と同一である。
【0124】
サーバＡｐｐ３４は、クライアントＡｐｐ２４から送信されたアプリ終了要求メッセージを受信する。ステップＳ７２において、サーバＡｐｐ３４は、受信したアプリ終了要求メッセージに基づいて、端末機器２のユーザの認証および認可を実行する。ステップＳ７３において、サーバＡｐｐ３４は、ユーザの認証および認可に成功した場合、受信したアプリ停止要求メッセージを第１マスターノード４１に送信する。
【0125】
第１マスターノード４１は、サーバＡｐｐ３４から送信されたアプリ停止要求メッセージを受信する。ステップＳ７４において、第１マスターノード４１は、第１ポッド８１の停止を要求するためのポッド停止要求メッセージを生成し、第１ワーカノード５２に送信する。ここで送信されるポッド停止要求メッセージの構成および内容は、図２４に示すポッド停止要求メッセージの構成および内容と同一である。
【0126】
第１ワーカノード５２は、第１マスターノード４１から送信されたポッド停止要求メッセージを受信する。第１ワーカノード５２は、ポッド停止要求メッセージを受信すると、第１ポッド８１を停止する。ステップＳ７５において、第１ワーカノード５２は、第１ポッド８１の停止を応答するためのポッド停止応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド停止応答メッセージの構成および内容は、図２６に示すポッド停止応答メッセージの構成および内容と同一である。
【0127】
第１マスターノード４１は、第１ワーカノード５２から送信されたポッド停止応答メッセージを受信する。ステップＳ７６において、第１マスターノード４１は、第２ポッド８２の停止を要求するためのポッド停止要求メッセージを生成し、第２ワーカノード７２に送信する。ここで送信されるポッド停止要求メッセージの構成および内容は、図２７に示すポッド停止要求メッセージの構成および内容と同一である。第２ワーカノード７２は、第１マスターノード４１から送信されたポッド停止要求メッセージを受信する。これにより、第４ワーカノード５３は第２ポッド８２を停止する。第１ポッド８１および第２ポッド８２の双方が停止された結果、サーバＡｐｐ３４に対応するサーバアプリケーションは終了する。
【0128】
ステップＳ７７において、第２ワーカノード７２は、第２ポッド８２の停止を応答するためのポッド停止応答メッセージを生成し、第１マスターノード４１に送信する。ここで送信されるポッド停止応答メッセージの構成および内容は、図２７に示すポッド停止応答メッセージの構成および内容と同一である。
【0129】
ステップＳ７８において、第１マスターノード４１は、サーバアプリケーションの停止を応答するためのアプリ停止応答メッセージを生成し、サーバＡｐｐ３４に送信する。ここで送信されるアプリ停止応答メッセージの構成および内容は、図２７に示すアプリ停止応答メッセージと同一である。ステップＳ７９において、サーバＡｐｐ３４は、受信したアプリ停止応答メッセージを生成し、クライアントＡｐｐ２４に送信する。クライアントＡｐｐ２４は、アプリ停止応答メッセージを受信すると終了する。
【0130】
ステップＳ８０において、サーバＡｐｐ３４は、ネットワーク状況の測定を要求する測定要求メッセージを送信する。ここで送信される測定要求メッセージの構成および内容は、図２８に示す測定要求メッセージの構成および内容と同一である。
【0131】
ステップＳ８１において、サーバＡｐｐ３４は、ネットワーク状況の測定を要求する測定要求メッセージを生成し、第１ネットワークモニタ４２に送信する。ここで送信される測定要求メッセージの構成および内容は、図２８に示す測定要求メッセージの構成および内容と同一である。ステップＳ８２において、サーバＡｐｐ３４は、リソース状況の測定を要求する測定要求メッセージを生成し、第１リソースモニタ５１に送信する。ここで送信される測定要求メッセージの構成および内容は、図２９に示す測定要求メッセージの構成および内容と同一である。ステップＳ８３において、サーバＡｐｐ３４は、ネットワーク状況の測定を要求する測定要求メッセージを生成し、第２ネットワークモニタ６２に送信する。ここで送信される測定要求メッセージの構成および内容は、図３０に示す測定要求メッセージの構成および内容と同一である。ステップＳ８４において、サーバＡｐｐ３４は、リソース状況の測定を要求する測定要求メッセージを生成し、第２リソースモニタ７１に送信する。ここで送信される測定要求メッセージの構成および内容は、図３１に示す測定要求メッセージの構成および内容と同一である。
【0132】
ステップＳ７９～Ｓ８４に基づいて、第１ネットワークモニタ４２、第１リソースモニタ５１、第２ネットワークモニタ６２、および第２リソースモニタ７１は、図３に示す一連の処理手順を実行する。これにより、アプリケーション終了後における最新のネットワーク状況およびリソース状況が、第１ローカルデータストア４４、第２ローカルデータストア６４、およびグローバルデータストア３２に反映される。
【0133】
（本実施形態による主要な効果）
実施形態１のコンテナシステム１によって奏する各効果は、本実施形態においても同様に得られる。さらに、本実施形態では、クライアント・サーバ型アプリケーションを実行する際、サーバアプリケーションを、クライアントアプリケーションの近傍にある第１ＭＥＣサーバ５および第２ＭＥＣサーバ７に効率的に配置することができる。
実施形態１のコンテナシステム１によって奏する各効果は、本実施形態においても同様に得られる。さらに、本実施形態では、クライアント・サーバ型アプリケーションを実行する際、サーバアプリケーションを、クライアントアプリケーションの近傍にある第１ＭＥＣサーバ５および第２ＭＥＣサーバ７に効率的に配置することができる。
【0134】
〔まとめ〕
本発明の態様１に係るポッド配置決定装置は、第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定部と、前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信部と、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信部と、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定部とを備えている構成である。
本発明の態様１に係るポッド配置決定装置は、第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定部と、前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信部と、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信部と、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定部とを備えている構成である。
【0135】
本発明の態様２に係るポッド配置決定装置は、上記の態様１において、前記決定部は、前記ネットワーク状況が前記ネットワークへの要求事項を満たしており、かつ、前記リソース状況が前記リソースへの要求事項を満たしている場合、前記第１ポッドを前記第１ワーカノードに配置することを決定する構成としてもよい。
【0136】
本発明の態様３に係るポッド配置決定装置は、上記の態様１または２において、前記第１ワーカノードは、異なる複数のコンテナオーケストレーションクラスタに属しており、前記第１エッジサーバは、前記第１ワーカノードのリソース状況を測定するリソース状況測定部を備えている構成としてもよい。
【0137】
本発明の態様４に係るポッド配置決定装置は、上記の態様１～３のいずれかにおいて、前記第１ポッドのイメージを保存するイメージ保存部をさらに備えている構成としてもよい。
【0138】
本発明の態様５に係るポッド配置決定方法は、第１ワーカノードを備えている第１エッジサーバが配置される第１拠点から、第２ワーカノードを備えている第２エッジサーバが配置される第２拠点への通信時のネットワーク状況を測定する測定ステップと、前記第１エッジサーバによって測定された前記第１ワーカノードのリソース状況を受信する第１受信ステップと、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２受信ステップと、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ポッドを前記第１ワーカノードに配置するか否かを決定する決定ステップとを有する方法である。
【0139】
本発明の態様６に係るエッジサーバは、異なる複数のコンテナオーケストレーションクラスタに属するワーカノードと、前記ワーカノードのリソース状況を測定する測定部と、測定された前記リソース状況をポッド配置決定装置に送信する送信部とを備えている構成である。
【0140】
本発明の態様７に係るサーバは、ポッド配置決定装置と、前記第２拠点に配置される第２ポッド配置決定装置とそれぞれ通信可能に接続されるサーバであって、前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第２ポッド配置決定装置から送信された、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況および前記第２ワーカノードの第２リソース状況とを受信する第１サーバ受信部と、受信された前記ネットワーク状況、前記リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存するサーバ情報保存部と、前記アプリケーションを構成する第２ポッドが要求するネットワークへの第２要求事項および前記第２ポッドが要求するリソースへの第２リソース状況を受信する第２サーバ受信部と、保存された前記第２ネットワーク状況および第２リソース状況と、受信された前記ネットワークへの第２要求事項および前記リソースへの第２要求事項とに基づいて、前記第２ポッドを前記第２ワーカノードに配置するか否かを決定する第２決定部とを備えている構成である。
【0141】
本発明の態様８に係る端末機器は、端末機器であって、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが、前記端末機器が接続されるネットワーク内のエッジサーバに配置されており、前記アプリケーションを起動するための、前記コンテナオーケストレーションクラスタに属していない起動モジュールをさらに備えている構成である。
【0142】
本発明の態様９に係るコンテナシステムは、上記の態様１に係るポッド配置決定装置と、上記の態様７に係るサーバとを少なくとも備えている構成である。
【0143】
本発明の態様１０に係るコンテナシステムは、第１拠点に配置される第１エッジサーバおよび第１拠点装置と、第２拠点に配置される第２エッジサーバおよび第２拠点装置と、サーバとを備えているコンテナシステムであって、前記第１エッジサーバは、複数の異なるコンテナオーケストレーションクラスタに属する第１ワーカノードと、前記第１ワーカノードの第１リソース状況を測定する第１リソース状況測定部と、測定された前記第１リソース状況を、前記第１拠点装置に送信する第１リソース状況送信部と、を備えており、前記第１拠点装置は、前記第１リソース状況を受信する第１受信部と、受信された前記第１リソース状況を、前記サーバに送信する第１送信部と、前記第２エッジサーバは、複数の異なるコンテナオーケストレーションクラスタに属する第２ワーカノードと、前記第２ワーカノードの第２リソース状況を測定する第２リソース状況測定部と、測定された前記第２リソース状況を、前記第２拠点装置に送信する第２リソース状況送信部と、を備えており、前記第２拠点装置は、前記第２リソース状況を受信する第２受信部と、受信された前記第２リソース状況を、前記サーバに送信する第２送信部とを備えており、前記サーバは、前記第１リソース状況および前記第２リソース状況を受信する第１サーバ受信部と、受信された前記第１リソース状況および前記第２リソース状況を保存するサーバ情報保存部とを備えている構成である。
【0144】
本発明の態様１１に係るコンテナシステムは、上記の態様１０において、前記第１拠点装置は、前記第１拠点から前記第２拠点への通信時の第１ネットワーク状況を測定する第１ネットワーク状況測定部をさらに備えており、前記第１送信部は、測定された前記第１ネットワーク状況および受信された前記第１リソース状況を、前記サーバに送信し、前記第２拠点装置は、前記第２拠点から前記第１拠点への通信時の第２ネットワーク状況を測定する第２ネットワーク状況測定部をさらに備えており、前記第２送信部は、測定された前記第２ネットワーク状況および受信された前記第２リソース状況を、前記サーバに送信し、前記第１サーバ受信部は、前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を受信し、前記サーバ情報保存部は、受信された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況を保存し、前記サーバは、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第１ポッドが要求するネットワークへの要求事項および前記第１ポッドが要求するリソースへの要求事項を受信する第２サーバ受信部と、保存された前記第１ネットワーク状況、前記第１リソース状況、前記第２ネットワーク状況、および前記第２リソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第１ワーカノードおよび前記第２ワーカノードのうちいずれのワーカノードに前記第１ポッドを配置するかを決定する構成としてもよい。
【0145】
本発明の態様１２に係るプログラムは、上記の態様１に係るポッド配置決定装置としてコンピュータを機能させるためのプログラムであって、前記測定部、前記保存部、前記第１受信部、前記第２受信部、および前記決定部としてコンピュータを機能させる構成である。
【0146】
〔実現例〕
第１拠点装置４の各機能ブロック（特に、第１ローカルＭＡＮＯ４３および第１ローカルデータストア４４）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ソフトウェアによって実現してもよい。
第１拠点装置４の各機能ブロック（特に、第１ローカルＭＡＮＯ４３および第１ローカルデータストア４４）は、集積回路（ＩＣチップ）等に形成された論理回路（ハードウェア）によって実現してもよいし、ソフトウェアによって実現してもよい。
【0147】
後者の場合、第１拠点装置４は、各機能を実現するソフトウェアであるプログラムの命令を実行するコンピュータを備えている。このコンピュータは、例えば１つ以上のプロセッサを備えていると共に、前記プログラムを記憶したコンピュータ読み取り可能な記録媒体を備えている。そして、前記コンピュータにおいて、前記プロセッサが前記プログラムを前記記録媒体から読み取って実行することにより、本発明の目的が達成される。
【0148】
前記プロセッサとしては、例えばＣＰＵ（Central Processing Unit）を用いることができる。前記記録媒体としては、「一時的でない有形の媒体」、例えば、ＲＯＭ（Read Only Memory）等の他、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。
【0149】
また、前記プログラムを展開するＲＡＭ（Random Access Memory）などをさらに備えていてもよい。また、前記プログラムは、該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して前記コンピュータに供給されてもよい。なお、本発明の一態様は、前記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【0150】
本発明は前述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態も、本発明の技術的範囲に含まれる。各実施形態にそれぞれ開示された技術的手段を組み合わせることによって、新しい技術的特徴を形成することもできる。
【符号の説明】
【0151】
１、１Ａ コンテナシステム
２、２Ａ 端末機器
３、３Ａ クラウドサーバ
４ 第１拠点装置
５ クラウドサーバ
６ 第２拠点装置
２１ プリファレンスリポジトリ
２２ イメージリポジトリ
２３ 起動Ａｐｐ
２４ クライアントＡｐｐ
３１ グローバルＭＡＮＯ
３２ グローバルデータストア
３３ オリジンイメージリポジトリ
３４ サーバＡｐｐ
４１ 第１マスターノード
４２ 第１ネットワークモニタ
４３ 第１ローカルＭＡＮＯ
４４ 第１ローカルデータストア
４５ 第１ローカルイメージリポジトリ
４６ ＡＰＩ
５１ 第１リソースモニタ
５２ 第１ワーカノード
５３ 第４ワーカノード
６１ 第２マスターノード
６２ 第２ネットワークモニタ
６３ 第２ローカルＭＡＮＯ
６４ 第２ローカルデータストア
６５ 第２ローカルイメージリポジトリ
６６ ＡＰＩ
７１ 第２リソースモニタ
７２ 第２ワーカノード
７３ 第５ワーカノード
８１ 第１ポッド
８２ 第２ポッド
８３ 第３ポッド
２、２Ａ 端末機器
３、３Ａ クラウドサーバ
４ 第１拠点装置
５ クラウドサーバ
６ 第２拠点装置
２１ プリファレンスリポジトリ
２２ イメージリポジトリ
２３ 起動Ａｐｐ
２４ クライアントＡｐｐ
３１ グローバルＭＡＮＯ
３２ グローバルデータストア
３３ オリジンイメージリポジトリ
３４ サーバＡｐｐ
４１ 第１マスターノード
４２ 第１ネットワークモニタ
４３ 第１ローカルＭＡＮＯ
４４ 第１ローカルデータストア
４５ 第１ローカルイメージリポジトリ
４６ ＡＰＩ
５１ 第１リソースモニタ
５２ 第１ワーカノード
５３ 第４ワーカノード
６１ 第２マスターノード
６２ 第２ネットワークモニタ
６３ 第２ローカルＭＡＮＯ
６４ 第２ローカルデータストア
６５ 第２ローカルイメージリポジトリ
６６ ＡＰＩ
７１ 第２リソースモニタ
７２ 第２ワーカノード
７３ 第５ワーカノード
８１ 第１ポッド
８２ 第２ポッド
８３ 第３ポッド
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】