(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-08
(45)【発行日】2023-12-18
(54)【発明の名称】サーバ、およびコンテナシステム
(51)【国際特許分類】
G06F 9/50 20060101AFI20231211BHJP
G06F 9/455 20180101ALI20231211BHJP
G06F 11/34 20060101ALI20231211BHJP
【FI】
G06F9/50 120A
G06F9/455 150
G06F11/34 133
(21)【出願番号】P 2021035782
(22)【出願日】2021-03-05
【審査請求日】2022-03-15
【前置審査】
(73)【特許権者】
【識別番号】501440684
【氏名又は名称】ソフトバンク株式会社
(73)【特許権者】
【識別番号】598121341
【氏名又は名称】慶應義塾
(74)【代理人】
【識別番号】110000338
【氏名又は名称】弁理士法人 HARAKENZO WORLD PATENT & TRADEMARK
(72)【発明者】
【氏名】張 亮
(72)【発明者】
【氏名】熊倉 顕
(72)【発明者】
【氏名】前迫 敬介
(72)【発明者】
【氏名】森田 孝裕
(72)【発明者】
【氏名】寺岡 文男
(72)【発明者】
【氏名】渡邊 大記
(72)【発明者】
【氏名】近藤 賢郎
(72)【発明者】
【氏名】安森 涼
(72)【発明者】
【氏名】稲垣 勇佑
【審査官】三坂 敏夫
(56)【参考文献】
【文献】特開2020-160775(JP,A)
【文献】特開2021-009604(JP,A)
【文献】羽原 拓哉 他,データ収集基盤機能の動的配置手法に関する検討,電気学会研究会資料,一般社団法人電気学会,2020年09月01日,第27頁-第32頁,CMN-20-38
【文献】通信ビルエッジを活用したGPU・データレイクの技術開発,NTT技術ジャーナル ,一般社団法人電気通信協会,2020年12月01日,第32巻 第12号,第66頁-第70頁
【文献】山中 広明 他,実験環境構築が容易なエッジコンピューティングテストベッドの実装と評価,電子情報通信学会技術研究報告,一般社団法人電子情報通信学会,2021年01月13日,Vol.120 No.314,第104頁-第109頁
(58)【調査した分野】(Int.Cl.,DB名)
G06F 9/455-9/54
G06F 11/34
(57)【特許請求の範囲】
【請求項1】
(1)第1ワーカノードを備えている第1エッジサーバが配置される第1拠点から、第2ワーカノードを備えている第2エッジサーバが配置される第2拠点への通信時のネットワーク状況を測定する測定部、(2)前記第1エッジサーバによって測定された前記第1ワーカノードのリソース状況を受信する第1受信部、(3)測定されたネットワーク状況および受信されたリソース状況を保存する保存部、(4)コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2受信部、及び、(5)保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ポッドを前記第1ワーカノードに配置するか否かを決定する決定部を備えているポッド配置決定装置と、前記第2拠点に配置される第2ポッド配置決定装置とそれぞれ通信可能に接続されるサーバであって、
前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第2ポッド配置決定装置から送信された、前記第2拠点から前記第1拠点への通信時の第2ネットワーク状況および前記第2ワーカノードの第2リソース状況とを受信する第1サーバ受信部と、
受信された前記ネットワーク状況、前記リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を保存するサーバ情報保存部と、
前記アプリケーションを構成する第2ポッドが要求するネットワークへの第2要求事項および前記第2ポッドが要求するリソースへの第2リソース状況を受信する第2サーバ受信部と、
保存された前記第2ネットワーク状況および第2リソース状況と、受信された前記ネットワークへの第2要求事項および前記リソースへの第2要求事項とに基づいて、前記第2ポッドを前記第2ワーカノードに配置するか否かを決定する第2決定部とを備えている、サーバ。
【請求項2】
ポッド配置決定装置とサーバとを少なくとも備えているコンテナシステムであって、
前記ポッド配置決定装置は、
第1ワーカノードを備えている第1エッジサーバが配置される第1拠点から、第2ワーカノードを備えている第2エッジサーバが配置される第2拠点への通信時のネットワーク状況を測定する測定部と、
前記第1エッジサーバによって測定された前記第1ワーカノードのリソース状況を受信する第1受信部と、
測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2受信部と、
保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ポッドを前記第1ワーカノードに配置するか否かを決定する決定部と
を備えており、
前記サーバは、前記ポッド配置決定装置と前記第2拠点に配置される第2ポッド配置決定装置とそれぞれ通信可能に接続されるサーバであって、
前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第2ポッド配置決定装置から送信された、前記第2拠点から前記第1拠点への通信時の第2ネットワーク状況および前記第2ワーカノードの第2リソース状況とを受信する第1サーバ受信部と、
受信された前記ネットワーク状況、前記リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を保存するサーバ情報保存部と、
前記アプリケーションを構成する第2ポッドが要求するネットワークへの第2要求事項および前記第2ポッドが要求するリソースへの第2リソース状況を受信する第2サーバ受信部と、
保存された前記第2ネットワーク状況および第2リソース状況と、受信された前記ネットワークへの第2要求事項および前記リソースへの第2要求事項とに基づいて、前記第2ポッドを前記第2ワーカノードに配置するか否かを決定する第2決定部とを備えているコンテナシステム。
【請求項3】
第1拠点に配置される第1エッジサーバおよび第1拠点装置と、第2拠点に配置される第2エッジサーバおよび第2拠点装置と、サーバとを備えているコンテナシステムであって、
前記第1エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第1ワーカノードと、
前記第1ワーカノードの第1リソース状況を測定する第1リソース状況測定部と、
測定された前記第1リソース状況を、前記第1拠点装置に送信する第1リソース状況送信部と、を備えており、
前記第1拠点装置は、
前記第1リソース状況を受信する第1受信部と、
受信された前記第1リソース状況を、前記サーバに送信する第1送信部と、
前記第2エッジサーバは、
複数の異なるコンテナオーケストレーションクラスタに属する第2ワーカノードと、
前記第2ワーカノードの第2リソース状況を測定する第2リソース状況測定部と、
測定された前記第2リソース状況を、前記第2拠点装置に送信する第2リソース状況送信部と、を備えており、
前記第2拠点装置は、
前記第2リソース状況を受信する第2受信部と、
受信された前記第2リソース状況を、前記サーバに送信する第2送信部とを備えており、
前記サーバは、
前記第1リソース状況および前記第2リソース状況を受信する第1サーバ受信部と、
受信された前記第1リソース状況および前記第2リソース状況を保存するサーバ情報保存部とを備えている、コンテナシステム。
【請求項4】
前記第1拠点装置は、前記第1拠点から前記第2拠点への通信時の第1ネットワーク状況を測定する第1ネットワーク状況測定部をさらに備えており、
前記第1送信部は、測定された前記第1ネットワーク状況および受信された前記第1リソース状況を、前記サーバに送信し、
前記第2拠点装置は、前記第2拠点から前記第1拠点への通信時の第2ネットワーク状況を測定する第2ネットワーク状況測定部をさらに備えており、
前記第2送信部は、測定された前記第2ネットワーク状況および受信された前記第2リソース状況を、前記サーバに送信し、
前記第1サーバ受信部は、前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を受信し、
前記サーバ情報保存部は、受信された前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を保存し、
前記サーバは、
コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2サーバ受信部と、
保存された前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ワーカノードおよび前記第2ワーカノードのうちいずれのワーカノードに前記第1ポッドを配置するかを決定する、請求項
3に記載のコンテナシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ポッド配置決定装置、ポッド配置決定方法、端末機器、エッジサーバ、サーバ、コンテナシステム、およびプログラムに関する。
【背景技術】
【0002】
パーソナルコンピュータおよび携帯電話などの各種の端末機器においてアプリケーションを実行する際、当該アプリケーションを構成するモジュールの中で負荷が大きいものをネットワーク中に存在するクラウドサーバに実行させることにより、アプリケーションの実行を効率よく行える可能性がある。このような実行の形態はオフロードと呼ばれる。しかし端末機器とクラウドサーバとの間の通信遅延は一般的に大きいため、アプリケーションの応答時間が長くなってしまう可能性がある.そこで従来、端末機器のネットワーク接続地点付近(エッジ)にMEC(Multi-access Edge Computing)サーバを配置することによって、端末機器とMECサーバとの間の通信遅延を小さくし、かつMECサーバにアプリケーションの一部の機能をオフロードすることによって、アプリケーションの応答時間を小さくすることが提案されている。
【0003】
また、端末機器上で動作するアプリケーション(クライアント)と、クラウドサーバで動作するアプリケーション(サーバアプリケーション)とが通信するという形態のアプリケーション(クライアント・サーバ型アプリケーション)も、良く利用されている。このようなアプリケーションでも、クライアントはクラウドサーバと通信するよりもMECサーバと通信する方が、通信遅延を小さくすることができる。
【0004】
また、物理コンピュータの仮想化技術には、ハイパーバイザ型とコンテナ型とがある。コンテナ型の仮想化技術は、コンテナ間でオペレーティングシステムのカーネルを共有するため、ハイパーバイザ型の仮想化技術と比較して軽量である。さらに、アプリケーションを構成するさまざまなモジュールをそれぞれコンテナとして実現し、アプリケーションを複数のコンテナの集合体として構成することが一般的になっている。
【0005】
コンテナの作成、配置、スケーリング、および状態監視などを自動的に行うシステムを、一般的にコンテナオーケストレーションシステムと呼ぶ。非特許文献1に、代表的なコンテナオーケストレーションシステムとして知られるKubernetesが開示されている。コンテナオーケストレーションシステムでは、1つ以上のコンテナを含むポッドを最小の管理対象とすることが多い。コンテナオーケストレーションシステムでは、データセンタなどのコンピュータクラスタ上に仮想マシンとしてマスターノードおよびワーカノードを配置し、1台のマスターノードと1台以上のワーカノードとによって、コンテナオーケストレーションクラスタを構成する。コンテナオーケストレーションクラスタ内では高可用性および負荷分散を考慮し、マスターノードがワーカノードにポッドを配置することによってポッドクラスタを構成する。
【先行技術文献】
【非特許文献】
【0006】
【文献】"Kubernetes (K8s)"、[online]、[令和3年2月25日検索]、インターネット〈https://kubernetes.io/ja/>
【発明の概要】
【発明が解決しようとする課題】
【0007】
一般的なコンテナオーケストレーションシステムは、コンテナの配置を決定する際にワーカノードの負荷を考慮する。しかし、ネットワーク状況を考慮していないため、ネットワーク状況が悪い(通信遅延が大きい等)各ワーカノードに各ポッドを配置する恐れがある。また、ワーカノードのリソース状況を考慮していないため、ワーカノードへのポッドの設置に失敗する可能性がある。
【0008】
本発明は前記の課題を解決するためになされたものであり、その目的は、ネットワーク状況およびワーカノードのリソース状況の双方を考慮したポッド配置を可能とすることにある。
【課題を解決するための手段】
【0009】
本発明の一態様に係るポッド配置決定装置は、前記の課題を解決するために、第1ワーカノードを備えている第1エッジサーバが配置される第1拠点から、第2ワーカノードを備えている第2エッジサーバが配置される第2拠点への通信時のネットワーク状況を測定する測定部と、前記第1エッジサーバによって測定された前記第1ワーカノードのリソース状況を受信する第1受信部と、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2受信部と、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ポッドを前記第1ワーカノードに配置するか否かを決定する決定部とを備えている。
【発明の効果】
【0010】
本発明の一態様によれば、ネットワーク状況およびワーカノードのリソース状況の双方を考慮したポッド配置を可能とするという効果を奏する。
【図面の簡単な説明】
【0011】
【
図1】第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】第2実施形態に係るコンテナシステムの構成を示すブロック図である。
【
図34】端末機器がクライアントAppを起動する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【
図35】アプリ要求メッセージの一例を示す図である。
【
図36】ポッド配置要求メッセージの一例を示す図である。
【
図37】ポッド配置応答メッセージの一例を示す図である。
【
図38】アプリ応答メッセージの一例を示す図である。
【
図39】サーバアプリケーションを停止する際にコンテナシステムによって実行される一連の処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【0012】
〔実施形態1〕
(システムの構成)
図1は、第1実施形態に係るコンテナシステム1の構成例を示す図である。この図に示すように、コンテナシステム1は、端末機器2、クラウドサーバ3(サーバ)、第1拠点装置4(ポッド配置決定装置)、複数の第1MEC(Multi-access Edge Computing)サーバ5(第1エッジサーバ)、第2拠点装置6(第2ポッド配置決定装置)、および複数の第2MECサーバ7(第2エッジサーバ)を備えている。これらの装置は、ネットワークを介して互いに通信可能に接続されている。ネットワークには、いわゆるクラウドが配置されている。クラウドサーバ3は、クラウドに配置されている。
図1には、2つの異なる第1拠点および第2拠点が図示されている。拠点とは、端末機器2が有線または無線でネットワークに接続する接続ポイント付近に位置する物理的な場所のことである。
図1では、端末機器2は、第2拠点よりも第1拠点の近くに位置している。第1拠点および第2拠点の識別子を、それぞれBaseID1およびBaseID2とする。
【0013】
端末機器2は、プリファレンスリポジトリ21、イメージリポジトリ22、および起動App23(起動モジュール)を備えている。端末機器2は、第3ワーカノードとしても機能する。
【0014】
クラウドサーバ3は、グローバルMANO(Management and Orchestration)31(第1サーバ受信部、第2サーバ受信部、第2決定部)、グローバルデータストア32(サーバ情報保存部)、およびオリジンイメージリポジトリ33を備えている。
【0015】
第1拠点に、第1拠点装置4と、n台(nは1以上の整数)の第1MECサーバ5とが配置されている。第1拠点装置4は、第1マスターノード41、第1ネットワークモニタ42(測定部、第1ネットワーク状況測定部)、第1ローカルMANO43(第2受信部、決定部)、第1ローカルデータストア44(第1受信部、保存部、第1送信部)、第1ローカルイメージリポジトリ45(イメージ保存部)、および第1AppAPI46を備えている。これらのモジュールの識別子を、それぞれMnID1、NmonID1、LManoID1、LdsID1、LirID1、およびAppApiID1とする。各第1MECサーバ5は、第1リソースモニタ51(測定部、リソース状況測定部、第1リソース状況測定部、第1リソース状況送信部)、第1ワーカノード52、および第4ワーカノード53を備えている。これらのモジュールの識別子を、それぞれRmonID1、WnID1、およびWnID4とする。
【0016】
第2拠点に、第2拠点装置6と、m台(mは1以上の整数)の第2MECサーバ7とが配置されている。第2拠点装置6は、第2マスターノード61、第2ネットワークモニタ62(第2ネットワーク状況測定部)、第2ローカルMANO63、第2ローカルデータストア64(第2受信部、保存部、第2送信部)、第2ローカルイメージリポジトリ65、および第2AppAPI66を備えている。これらのモジュールの識別子を、それぞれMnID2、NmonID2、LManoID2、LdsID2、LirID2、およびAppApiID2とする。各第2MECサーバ7は、第2リソースモニタ71(第2リソース状況測定部、第2リソース状況送信部)、第2ワーカノード72、および第5ワーカノード73を備えている。これらのモジュールの識別子を、それぞれRmonID2、WnID2、およびWnID5とする。
【0017】
本実施形態では、第1拠点装置4は、1つの独立した物理マシンである。そして、第1拠点装置4内に、仮想マシンとしての第1マスターノード41が設定されている。これに限らず、第1マスターノード41は、個別の物理マシンとして動作してもよい。また、各第1MECサーバ5は、1つの独立した物理マシンである。そして、各第1MECサーバ5内に、仮想マシンとしての第1ワーカノード52および第4ワーカノード53が配置されている。これに限らず、第1ワーカノード52および第4ワーカノード53は、個別の物理マシンとして動作してもよい。
【0018】
本実施形態では、第2拠点装置6は、1つの独立した物理マシンである。そして、第2拠点装置6内に、仮想マシンとしての第2マスターノード61が設定されている。これに限らず、第2マスターノード61は、個別の物理マシンとして動作してもよい。また、各第2MECサーバ7は、1つの独立した物理マシンである。そして、各第2MECサーバ7内に、仮想マシンとしての第2ワーカノード72および第5ワーカノード73が配置されている。これに限らず、第2ワーカノード72および第5ワーカノード73は、個別の物理マシンとして動作してもよい。
【0019】
上述した各マスターノードおよび各ワーカノードは、必要に応じて、1つのコンテナオーケストレーションクラスタを構成する。
図1の例では、第1マスターノード41、第3ワーカノード(端末機器2)、第1ワーカノード52、および第2ワーカノード72が、ある1つのコンテナオーケストレーションクラスタを構成している。また、特に図示していないが、第2マスターノード61、第1ワーカノード52、および第5ワーカノード73が、他の1つのコンテナオーケストレーションクラスタを構成している。このように、第1ワーカノード52は、異なる2つのコンテナオーケストレーションクラスタに属している。
【0020】
図1には、第1拠点の近傍で端末機器2のユーザが所定のアプリケーションを起動した際の、各ポッドの配置を示している。本例では、コンテナオーケストレーションクラスタとしてのアプリケーションは、第1ポッド81、第2ポッド82、第3ポッド83、および図示されない中継ポッドを含む4つのポッドによって構成されている。中継ポッドは、コンテナオーケストレーションクラスタ内外の通信を中継するポッドである。
【0021】
端末機器2のユーザの識別子を、UsrID1とする。ユーザの認証認可のための情報を、CredUsr1とする。認証認可のための情報とは、パスワードや電子証明書等である。アプリケーションの識別子をAppID1とする。アプリケーションを構成する4つのポッドの各識別子を、それぞれPodID1、PodID2、PodID3およびRelayPodID1とする。
【0022】
アプリケーションにおける各ポッドの役割はそれぞれ異なる。第1ポッド81および第2ポッド82は、アプリケーションを構成する複数のポッドのうち、比較的複雑な処理を担うポッドである。第3ポッド83は、アプリケーションを構成する複数のポッドのうち、アプリケーションのユーザインタフェースを担うポッドである。ユーザインタフェースを担うポッドは、必ず端末機器2上に配置する必要がある。そのため、第3ポッド83は必ず端末機器2上に配置すべきポッドである。
【0023】
端末機器2は、ネットワークに接続すると、最寄りの拠点において構成されるコンテナオーケストレーションクラスタに、自ノードである第3ワーカノードを登録する。
図1の例では、端末機器2は第1拠点の近傍でネットワークに接続する。これにより端末機器2は、端末機器2の自ノードとしての第3ワーカノードを、第1マスターノード41が属するコンテナオーケストレーションクラスタに登録する。この結果、端末機器2は、第3ワーカノードとして、第1マスターノード41が属するコンテナオーケストレーションクラスタに同様に属することになる。
【0024】
(ネットワーク状況およびリソース状況の把握)
図2は、コンテナシステム1がネットワーク状況およびリソース状況を測定する際にコンテナシステム1によって実行される一連の処理の流れを示すシーケンス図である。ステップS1において、第1拠点の第1ネットワークモニタ42は、第2拠点の第2ネットワークモニタ62と通信することによって、第1拠点から第2拠点への通信時のネットワーク状況(第1ネットワーク状況)を測定する。ネットワーク状況は、例えば、第1ネットワークモニタ42から第2ネットワークモニタ62への通信の遅延時間である。あるいは、ネットワーク状況は、第1ネットワークモニタ42から第2ネットワークモニタ62に通信する際に利用可能な通信帯域である。ここでは、第1ネットワークモニタ42は、遅延時間および通信帯域の双方を、ネットワーク状況として測定する。
【0025】
図3は、ネットワーク状況通知メッセージの一例を示す図である。ステップS2において、第1ネットワークモニタ42は、測定したネットワーク状況を通知するための、
図3に示すようなネットワーク状況通知メッセージを生成し、第1ローカルデータストア44に送信する。
図3に示すように、ネットワーク状況通知メッセージは、複数の異なるフィールドを含んでいる。具体的には、ネットワーク状況通知メッセージは、Typeフィールド、Source IDフィールド、およびNo of Destinationsフィールドを少なくとも含んでいる。Typeフィールドは、このフィールドが含まれるメッセージの種類(タイプ)を示す。
図3では、Typeフィールドはネットワーク状況通知メッセージに含まれるので、Typeフィールドの値はネットワーク状況通知メッセージを示す“ネットワーク状況通知”である。Source IDフィールドは、ネットワーク状況の測定元の識別子を示す。
図3では、Source IDフィールドの値はNmonID1である。No of Destinationsフィールドは、ネットワーク状況の測定相手の数を示す。
図3では、No of Destinationsフィールドの値は1である。
【0026】
ネットワーク状況通知メッセージは、さらに、ネットワーク状況の測定相手ごとに、対応するDestination IDフィールド、Delayフィールド、およびAvailable Bandwidthフィールドの3つ組フィールドを含んでいる。
図3では、測定相手は1つ(第2ネットワークモニタ62)であるため、ネットワーク状況通知メッセージには1つの3つ組フィールドが含まれる。Destination IDフィールドは、ネットワーク状況の測定相手の識別子を表す。
図3では、ネットワーク状況通知メッセージの値は、第2ネットワークモニタ62の識別子すなわちNmonID2である。Delayフィールドは、Source IDフィールドが示す測定元(ここでは第1ネットワークモニタ42)からDestination IDが示す測定相手(ここでは第2ネットワークモニタ62)への通信の遅延時間を示す。Available Bandwidthフィールドは、Source IDフィールドが示す測定元(ここでは第1ネットワークモニタ42)からDestination IDフィールドが示す測定相手(ここでは第2ネットワークモニタ62)への通信時に利用可能な通信帯域を示す。
【0027】
ステップS3において、第1MECサーバ5の第1リソースモニタ51は、第1MECサーバ5のリソース状況を測定する。リソースとは、第1MECサーバ5において利用可能な計算資源のことである。ここでは、リソース状況として、第1MECサーバ5が有する仮想CPUの数、メモリ容量、ストレージ容量、GPUの数、およびGPUのメモリ容量を測定する。さらに、リソース状況として、第1MECサーバ5が使用中の仮想CPUの数、メモリ容量、ストレージ容量、GPUの数、GPUのメモリ容量をも測定する。
【0028】
図4は、リソース状況通知メッセージの一例を示す図である。ステップS4において、第1リソースモニタ51は、測定したリソース状況を通知するための、
図4に示すようなリソース状況通知メッセージを生成し、第1ローカルデータストア44に送信する。ネットワーク状況通知メッセージは、複数の異なるフィールドを含んでいる。
図4の例では、リソース状況通知メッセージは、Typeフィールド、Source IDフィールド、およびNo of Nodesフィールドを少なくとも含んでいる。Typeフィールドの値は、リソース状況通知メッセージのメッセージタイプを示す“リソース状況通知”である。Source IDフィールドは、リソース状況の測定元の識別子を示す。この例では、Source IDフィールドの値は、第1リソースモニタ51の識別子すなわちRmonID1である。No of Nodesフィールドは、第1MECサーバ5に配置されているワーカノードの数を示す。第1MECサーバ5には2台のワーカノードが配置されているので、この例では、No of Nodesフィールドの値は2である。
【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フィールドを含む11組のフィールドを含んでいる。Node IDフィールドは、ワーカノードの識別子を示す。CPUsフィールドは、ワーカノードに割り当てられている仮想CPUの数を示す。Memoryフィールドは、ワーカノードに割り当てられているメモリ容量を示す。Storageフィールドは、ワーカノードに割り当てられているストレージ容量を示す。GPUsフィールドは、ワーカノードに割り当てられているGPUの個数を示す。GPU Memoryフィールドは、ワーカノードに割り当てられているGPUメモリ容量を示す。In Use CPUsフィールドは、ワーカノードが使用中の仮想CPUの数を示す。In Use Memoryフィールドは、ワーカノードが使用中のメモリ容量を示す。In Use Storageフィールドは、ワーカノードが使用中のストレージ容量を示す。In Use GPUsフィールドは、ワーカノードが使用中のGPUの個数を示す。In Use GPU Memoryフィールドは、ワーカノードが使用中のGPUメモリ容量を示す。
【0030】
図4の例では、リソース状況通知メッセージは、第1ワーカノード52および第4ワーカノード53に対応する2つの11組フィールドを含んでいる。1つ目の11組フィールドでは、Node IDフィールドの値はWnID1である。CPUsフィールドの値は、第1ワーカノード52に割り当てられた仮想CPUの数を示す。Memoryフィールドは第1ワーカノード52に割り当てられたメモリ容量を示す。Storageフィールドは第1ワーカノード52に割り当てられたストレージ容量を示す。GPUsフィールドは第1ワーカノード52に割り当てられたGPUの数を示す。GPU Memoryフィールドは第1ワーカノード52に割り当てられたGPUメモリ容量を示す。In Use CPUsは第1ワーカノード52が現在使用中の仮想CPUの数を示す。In Use Memoryフィールドは第1ワーカノード52が使用中のメモリ容量を示す。In Use Storageフィールドは第1ワーカノード52が使用中のストレージ容量を示す。In Use GPUsフィールドは第1ワーカノード52が使用中のGPUの数を示す。In Use GPU Memoryフィールドは第1ワーカノード52が使用中のGPUメモリ容量を示す。
【0031】
2つ目の11組フィールドでは、Node IDフィールドの値はWnID4である。CPUsフィールド等の残りの10個のフィールドの値は、1つ目の11組フィールドと同様に、第4ワーカノード53に関する値を示す。
【0032】
第1拠点内の他の第1MECサーバ5が備える第1リソースモニタ51も、同様に動作することによって、リソース状況通知メッセージを生成し、第1ローカルデータストア44に通知する。ステップS5において、第1ローカルデータストア44は、第1拠点内の他の第1リソースモニタ51から通知されたリソース状況およびネットワーク状況を受信する。ステップS6において、第1ローカルデータストア44は、第1拠点における全第1MECサーバ5のリソース状況およびネットワーク状況の情報を集約することによって、
図5に示すような拠点状況通知メッセージを生成する。この際、第1ローカルデータストア44は、集約したネットワーク状況および各リソース状況を、自身の記憶スペースに保存する。
【0033】
図5は、拠点状況通知メッセージの一例を示す図である。ステップS7において、第1ローカルデータストア44は、拠点状況通知メッセージをグローバルデータストア32に通知する。
図5の例では、拠点状況通知メッセージは、Typeフィールド、Base IDフィールド、No of Destinationsフィールド、およびNo of Resource Statsフィールドを含む。Typeフィールドの値は、拠点状況通知メッセージのメッセージタイプを示す“拠点状況通知”である。Base IDフィールドは、拠点の識別子を示す。
図4の例では、Base IDフィールドの値はBaseID1である。
【0034】
No of Destinationsフィールドは、ネットワーク状況の測定相手の数を示す。
図5では、No of Destinationsフィールドの値は1である。拠点状況通知メッセージは、測定相手ごとに、対応するDestination IDフィールド、Delayフィールド、およびAvailable Bandwidthフィールドの3つ組フィールドを含んでいる。これらのフィールドの各値は、
図3に示す3つ組フィールドの各値と同一である。
【0035】
No of Resource Statsフィールドは、通知されるリソース状況の個数を示す。この例では、n個の第1MECサーバ5におけるリソース状況が通知されるので、No of Resource Statsフィールドの値はnである。拠点状況通知メッセージは、さらに、
図4の各Node IDフィールド以下の2つのフィールド群(全部で11×2フィールド)を、No of Resource Statsフィールドの値の数だけ含む。この例では、拠点状況通知メッセージは、n個のフィールド群を含む。
【0036】
グローバルデータストア32は、通知された拠点状況通知メッセージに含まれる、第1拠点のネットワーク状況および第1拠点の各第1MECサーバ5における第1ワーカノード52および第4ワーカノード53のリソース状況(第1リソース状況)を、自身の記憶スペースに保存する。これ以降、定期的に、ステップS1~S7の一連の処理が繰り返し実行される。
【0037】
詳細な説明は省略するが、第2拠点においても、上述したステップS1~S7と同様の処理が実行される。これにより、グローバルデータストア32は、通知された拠点状況通知メッセージに含まれる、第2拠点のネットワーク状況(第2ネットワーク状況)および第2拠点の各第2MECサーバ7における第2ワーカノード72および第5ワーカノード73のリソース状況(第2リソース状況)をも、自身の記憶スペースに保存する。
【0038】
(アプリケーションの起動処理)
図6は、端末機器2がアプリケーションを起動する際にコンテナシステム1によって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器2を操作し、所定のアプリケーションを起動するための操作を端末機器2に入力する。ステップS11において、端末機器2は、この操作を検出すると、アプリケーションを起動させるための起動App23を実行する。起動App23は、端末機器2内のイメージリポジトリ22に予め格納されている。起動App23は、アプリケーションを起動したり終了したりするために使用されるモジュールである。起動App23を実行することによって、アプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83を、コンテナオーケストレーションクラスタ内に配置することができる。しかし起動App23は、第1ポッド81、第2ポッド82、および第3ポッド83とは異なり、コンテナオーケストレーションクラスタに属していない。
【0039】
実行された起動App23は、端末機器2のプリファレンスリポジトリ21にアクセスし、アプリケーションに関連付けられたプリファレンスを参照する。プリファレンスとは、アプリケーションを起動する際に参照されるパラメータ群である。プリファレンスの内容は、予めユーザによって指定されている。例えば、プリファレンスは、アプリケーションの一部を第1MECサーバ5または第2MECサーバ7にオフロードすることを希望するかどうかを指定している。本例では、ユーザがオフロードを希望することがプリファレンスにおいて指定されているものとする。なお、プリファレンスの内容は、ユーザではなく、クラウドサーバ3によって予め指定されていてもよい。
【0040】
(アプリ起動要求)
図7は、アプリ起動要求メッセージの一例を示す図である。ステップS12において、起動App23は、
図7に示すようなアプリ起動要求メッセージを生成し、第1拠点内の第1AppAPI46に送信する。アプリ起動要求メッセージは、アプリケーションの起動を要求するためのメッセージである。
図7の例では、アプリ起動要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、App IDフィールド、およびPreferenceフィールドを含む。Typeフィールドの値は、アプリ起動要求メッセージのメッセージタイプを示す“アプリ起動要求”である。User IDフィールドは、端末機器2のユーザの識別子を示す。
図8の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、端末機器2のユーザの認証認可情報を示す。
図8の例では、Credentialフィールドの値はCredUsr1である。App IDフィールドは、実行されるアプリケーションの識別子を示す。
図8の例では、App IDフィールドの値はAppID1である。Preferenceフィールドは、起動App23がプリファレンスリポジトリ21から読み取った情報を示す。
【0041】
端末機器2は、ネットワークに接続する際、端末機器2の最寄りの第1拠点に配置される第1AppAPI46のアドレス等を取得する。ステップS13において、第1AppAPI46は、受信したアプリ起動要求メッセージに基づいて、端末機器2のユーザの認証および認可を実行する。その際、第1AppAPI46は、携帯電話網などのコントロールプレーンにアクセスしてもよい。
【0042】
(アプリ構成情報要求)
図8は、アプリ構成情報要求メッセージの一例を示す図である。ステップS14において、第1AppAPI46は、
図8に示すようなアプリ構成情報要求メッセージを生成し、第1ローカルイメージリポジトリ45に送信する。アプリ構成情報要求メッセージは、アプリケーションのポッド構成情報を要求するためのメッセージである。
図8の例では、アプリ構成情報要求メッセージは、TypeフィールドおよびApp IDフィールドを含む。Typeフィールドの値は、アプリ構成情報要求メッセージのメッセージタイプを示す“アプリ構成情報要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。
【0043】
第1ローカルイメージリポジトリ45は、アプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83のイメージを一時的に保持することができる。第1ローカルイメージリポジトリ45は、アプリ構成情報要求メッセージを受信した時点において、受信したアプリ構成情報要求メッセージによって示されるアプリケーションのポッドイメージをまだ保持していない。そこで第1ローカルイメージリポジトリ45は、ステップS15において、受信したアプリ構成情報要求メッセージをオリジンイメージリポジトリ33に送信する。ここで送信されるアプリ構成情報要求メッセージの構成および内容は、
図8に示すアプリ構成情報要求メッセージの構成および内容と同一である。
【0044】
(アプリ構成情報応答)
図9は、アプリ構成情報応答メッセージの一例を示す図である。オリジンイメージリポジトリ33の記憶スペースには、コンテナシステム1によって実行可能な全アプリケーションの全ポッドイメージが、予め保存されている。オリジンイメージリポジトリ33は、アプリ構成情報要求メッセージを受信すると、アプリ構成情報要求メッセージによって示されるアプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83のイメージを、自身の記憶スペースから読み出す。オリジンイメージリポジトリ33は、ステップS16において、読み出した各ポッドイメージに基づいて、
図9に示すようなアプリ構成情報応答メッセージを生成し、第1ローカルイメージリポジトリ45に送信する。
【0045】
アプリ構成情報応答メッセージは、アプリケーションのポッド構成情報を応答するためのメッセージである。
図9の例では、アプリ構成情報応答メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、アプリ構成情報応答メッセージのメッセージタイプを示す“アプリ構成情報応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、アプリケーションを構成するポッドの数を示す。
図9の例では、No of Podsフィールドの値は3である。
【0046】
アプリ構成情報応答メッセージは、1つのポッドについて、Pod IDフィールド、No of CPUsフィールド、Memoryフィールド、Storageフィールド、No of GPUsフィールド、GPU MemoryフィールドおよびNet Reqフィールドを含む7つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。No of CPUsフィールドは、ポッドが必要とする仮想CPUの数を示す。Memoryフィールドは、ポッドが必要とするメモリ容量を示す。Storageフィールドは、ポッドが必要とするストレージ容量を示す。No of GPUsフィールドは、ポッドが必要とするGPUの数を示す。GPU Memoryフィールドは、ポッドが必要とするGPUメモリ容量を示す。Net Reqフィールドは、ポッドが必要とするネットワークへの要求事項を示す。
【0047】
図9に示す例では、1つ目の7つ組フィールドに含まれるPod IDフィールドは、PodID1である。No of CPUsフィールドは、第1ポッド81が必要とする仮想CPUの数を示す。Memoryフィールドは、第1ポッド81が必要とするメモリ容量を示す。Storageフィールドは、第1ポッド81が必要とするストレージ容量を示す。No of GPUsフィールドは、第1ポッド81が必要とするGPUの数を示す。GPU Memoryフィールドは、第1ポッド81が必要とするGPUメモリ容量を示す。
【0048】
アプリ構成情報応答メッセージは、さらに、第2ポッド82に関する7つ組フィールドと、第3ポッド83に関する7つ組フィールドとを含む。
【0049】
第1ローカルイメージリポジトリ45は、アプリ構成情報応答メッセージを受信すると、受信したアプリ構成情報応答メッセージに含まれるアプリ構成情報を、第1ローカルイメージリポジトリ45の記憶スペースに一時的に保持する。第1ローカルイメージリポジトリ45は、記憶スペースが不足した場合は、LRU(Least Recently Used)アルゴリズム等にしたがって、記憶スペースを確保する。ステップS17において、第1ローカルイメージリポジトリ45は、受信したアプリ構成情報応答メッセージを、第1AppAPI46に送信する。この際に送信されるアプリ構成情報応答メッセージの構成および内容は、
図9に示すアプリ構成情報応答メッセージの構成および内容と同一である。
【0050】
(ポッド配置決定要求)
図10は、ポッド配置決定要求メッセージの一例を示す図である。ステップS18において、第1AppAPI46は、受信したアプリ構成情報応答メッセージに基づいて、
図10に示すようなポッド配置決定要求メッセージを生成し、第1ローカルMANO43に送信する。ポッド配置決定要求は、アプリケーションを構成する第1ポッド81および第2ポッド82の配置決定を要求するためのメッセージである。
図10の例では、ポッド配置決定要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定要求メッセージのメッセージタイプを示す“ポッド配置決定要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、アプリケーションを構成するポッドの数を示す。アプリケーションは3個のポッドから構成され、そのうち1つは端末機器2に配置される。そのため
図11の例では、No of Podsフィールドの値は2である。
【0051】
ポッド配置決定要求メッセージは、ポッドごとに、Pod IDフィールド、No of CPUsフィールド、Memoryフィールド、Storageフィールド、No of GPUsフィールド、GPU Memoryフィールド、およびNet Reqフィールドを含む7つ組フィールドをさらに含む。
図10の例では、ポッド配置決定要求メッセージは、2つの7つ組フィールドを含んでいる。Pod IDフィールドは、ポッドの識別子を示す。No of CPUsフィールドは、ポッドが必要とする仮想CPUの数を示す。Memoryフィールドは、ポッドが必要とするメモリ容量を示す。Storageフィールドは、ポッドが必要とするストレージ容量を示す。No of GPUsフィールドは、ポッドが必要とするGPUの数を示す。GPU Memoryフィールドは、ポッドが必要とするGPUメモリ容量を示す。Net Reqフィールドは、ポッドが必要とするネットワークへの要求事項を示す。
【0052】
図10の例では、1つ目の7つ組フィールドに含まれるPod IDフィールドは、第1ポッド81の識別子を示す。したがって、Pod IDフィールドの値はPodID1である。No of CPUsフィールドは、第1ポッド81が必要とする仮想CPUの数を示す。Memoryフィールドは、第1ポッド81が必要とするメモリ容量を示す。Storageフィールドは、第1ポッド81が必要とするストレージ容量を示す。No of GPUsフィールドは、第1ポッド81が必要とするGPUの数を示す。GPU Memoryフィールドは、第1ポッド81が必要とするGPUメモリ容量を示す。Net Reqフィールドは、第1ポッド81が必要とするネットワークへの要求事項を示す。No of CPUsフィールド等の残りの6のフィールドは、第1ポッド81が必要とするリソースへの要求事項を示す。
【0053】
図10の例では、2つ目の7つ組フィールドに含まれるPod IDフィールドは、第2ポッド82の識別子を示す。したがって、Pod IDフィールドの値は、PodID2である。2つ目の7つ組フィールドに含まれるNo of CPUsフィールド等の値は、1つ目の7つ組フィールドと同様に、第2ポッド82に関する値である。したがって、Net Reqフィールドは、第2ポッド82が必要とするネットワークへの要求事項(第2要求事項)を示す。No of CPUsフィールド等の残りの6のフィールドは、第2ポッド82が必要とするリソースへの要求事項を示す。
【0054】
(第1ポッド81の配置決定)
第1ローカルMANO43は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第1ポッド81および第2ポッド82の全てを、第1拠点内のいずれかのワーカノードに配置できるか否かを判定する。その際、第1ローカルMANO43は、第1ローカルデータストア44に保存された、第1拠点に関するネットワーク状況および各第1MECサーバ5に関するリソース状況と、受信したポッド配置決定要求メッセージに含まれる第1ポッド81に関するネットワークへの要求事項およびリソースへの要求事項とに基づいて、第1ポッド81を第1ワーカノード52に配置するか否かを決定する。具体的には、第1拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第1ポッド81に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、第1ローカルデータストア44に保存された第1拠点内のいずれかの第1MECサーバ5のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第1ポッド81に関するリソース状況の要求事項を満たしているか否かを判定する。
【0055】
ここでは、第1拠点のネットワーク状況が、第1ポッド81に関するネットワーク状況への要求事項を満たしており、かつ、第1MECサーバ5の第1ワーカノード52のリソース状況が、第1ポッド81に関するリソースへの要求事項を満たしているものとする。これらの場合、第1ローカルMANO43は、第1ポッド81を、第1拠点内の第1MECサーバ5の第1ワーカノード52に配置することを決定する。
【0056】
また、ここでは、第1拠点のネットワーク状況が、第2ポッド82に関するネットワーク状況の要求を満たしているが、すべての第1MECサーバ5の第1ワーカノード52および第4ワーカノード53の各リソース状況が、第2ポッド82に関するリソース状況の要求情報を満たしていないものとする。これにより、第1ローカルMANO43は、第2ポッド82については、第1拠点内の全ての第1MECサーバ5の第1ワーカノード52または第4ワーカノード53に配置できないと判定する。
【0057】
図11は、ポッド配置決定要求メッセージの一例を示す図である。ステップS19において、第1ローカルMANO43は、第2ポッド82を第1拠点に配置することができない場合、第2ポッド82を第2拠点に配置するために、
図11に示すようなポッド配置決定要求メッセージを生成し、グローバルMANO31に送信する。ここで送信されるポッド配置決定要求メッセージは、第2ポッド82の配置決定を要求するためのメッセージである。
【0058】
(第2ポッド82の配置決定)
ステップS20において、グローバルMANO31は、ポッド配置決定要求メッセージを受信すると、第2ポッド82を第2拠点の第2MECサーバ7に配置できるか否かを判定する。その際、グローバルMANO31は、グローバルデータストア32に保存された、第2拠点のネットワーク状況(第2ネットワーク状況)および各第2MECサーバ7のリソース状況と、受信したポッド配置決定要求メッセージに含まれる第2ポッド82に関するネットワークへの要求事項およびリソースに対する要求事項とに基づいて、第2ポッド82を第2ワーカノード72に配置するか否かを決定する。具体的には、第2拠点に関するネットワーク状況が、ポッド配置決定要求メッセージ内に含まれる第2ポッド82に関するネットワークへの要求情報を満たしているか否かを、まず判定する。満たしていると判定した場合、次に、グローバルデータストア32に保存された第2拠点内のいずれかの第2MECサーバ7のリソース状況が、ポッド配置決定要求メッセージ内に含まれる第2ポッド82に関するリソース状況の要求事項を満たしているか否かを判定する。
【0059】
ここでは、第2拠点のネットワーク状況が、第2ポッド82に関するネットワークへの要求事項を満たしており、かつ、第2MECサーバ5の第2ワーカノード72のリソース状況が、第2ポッド82に関するリソースへの要求事項を満たしているものとする。これらの場合、グローバルMANO31は、第2ポッド82を、第2拠点内の第2MECサーバ7の第2ワーカノード72に配置することを決定する。
【0060】
(ポッド配置決定応答)
図12は、ポッド配置決定応答メッセージの一例を示す図である。ステップS20において、グローバルMANO31は、
図12に示すようなポッド配置決定応答メッセージを生成し、第1ローカルMANO43に送信する。ポッド配置決定応答メッセージは、第2ポッド82の配置を決定したことを応答するためのメッセージである。
図12の例では、ポッド配置決定応答メッセージは、Typeフィールド、App IDフィールド、No of Podsフィールドを含む。Typeフィールドの値は、ポッド配置決定応答メッセージのメッセージタイプを示す“ポッド配置決定応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。
図12の例では、No of Podsフィールドの値は1である。
【0061】
ポッド配置決定応答メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、およびNode IDを含む3つ組フィールドをさらに含む。ここでは、ポッドは1つであるため、ポッド配置決定応答メッセージは1つの3つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。
図12の例では、Pod IDフィールドの値はPodID2である。Base IDフィールドは、ポッドが配置される拠点の識別子を示す。
図12の例では、第2ポッド82が第2拠点に配置されるので、Base IDフィールドの値はBaseID2である。Node IDフィールドは、ポッドが配置されるワーカノードの識別子を示す。
図12の例では、第2ポッド82が第2拠点の第2MECサーバ7の第2ワーカノード72に配置されるので、Node IDフィールドはWnID2である。
【0062】
図13は、ポッド配置決定応答メッセージの一例を示す図である。ステップS21において、第1ローカルMANO43は、第2ポッド82に関するポッド配置決定応答メッセージを受信すると、
図13に示すようなポッド配置決定応答メッセージを生成し、第1AppAPI46に送信する。
図13に示すポッド配置決定応答メッセージの構成は、
図12に示すポッド配置決定応答メッセージの構成に、第1ポッド81に関する項目を加えたものである。そのため、
図13に示すポッド配置決定応答メッセージの詳細な説明は省略する。
【0063】
(ポッド配置要求)
図14は、ポッド配置要求メッセージの一例を示す図である。ステップS22において、第1AppAPI46は、ポッド配置決定応答メッセージを受信すると、
図15に示すようなポッド配置要求メッセージを生成し、第1マスターノード41に送信する。ポッド配置要求メッセージは、第1ポッド81、第2ポッド82、および第3ポッド83の配置を要求するためのメッセージである。
図14の例では、ポッド配置要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置要求メッセージのメッセージタイプを示す“ポッド配置要求”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。
図14の例では、ポッド配置要求メッセージによって3つの第1ポッド81、第2ポッド82、および第3ポッド83の配置が要求されるので、No of Podsフィールドの値は3である。
【0064】
ポッド配置要求メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、Node IDフィールド、およびRepository IDフィールドという4つ組フィールドをさらに含む。
図14の例では、3つの第1ポッド81、第2ポッド82、および第3ポッド83の配置が要求されるので、ポッド配置要求メッセージは3つの4つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。Base IDフィールドは、ポッドが配置される拠点の識別子を示す。Node IDフィールドは、ポッドが配置されるワーカノードの識別子を示す。Repository IDフィールドは、ポッドのイメージを取得すべきイメージリポジトリ22の識別子を示す。
【0065】
図14の例では、1つ目の4つ組フィールドにおけるPod IDフィールドの値は、第1ポッド81の識別子すなわちPodID1である。Base IDフィールドの値は、第1ポッド81が配置される第1拠点の識別子すなわちBaseID1である。Node IDフィールドの値は、第1ポッド81が配置される第1ワーカノード52の識別子すなわちWnID1である。Repository IDフィールドの値は、LirID1である。2つ目の4つ組フィールドにおけるPod IDフィールドの値は、第2ポッド82の識別子すなわちPodID2である。Base IDフィールドの値は、第2ポッド82が配置される第2拠点の識別子すなわちBaseID2である。Node IDフィールドの値は、第2ポッド82が配置される第2ワーカノード72の識別子すなわちWnID2である。Repository IDフィールドの値は、LirID2である。3つ目の4つ組フィールドにおけるPod IDフィールドの値は、第3ポッド83の識別子すなわちPodID3である。Base IDフィールドの値は、第3ポッド83が配置される第1拠点の識別子すなわちBaseID1である。Node IDフィールドの値は、第3ポッド83が配置される第3ワーカノードの識別子すなわちWnID3である。Repository IDフィールドの値は、LirID1である。
【0066】
(第1ポッド81の配置)
図15は、ポッド配置要求メッセージの一例を示す図である。ステップS23において、第1マスターノード41は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、
図15に示すようなポッド配置要求メッセージを生成し、第1ワーカノード52に送信する。ここで生成されるポッド配置要求メッセージは、第1ポッド81の配置を要求するためのメッセージである。
図15に示すポッド配置要求メッセージの構成は、
図14に示すポッド配置要求メッセージの構成から、第2ポッド82および第3ポッド83の項目を除いたものとなっている。
図15に示す例では、ポッド配置要求メッセージに含まれるNo of Podsフィールドの値は1である。Pod IDフィールドの値は、PodID1である。Base IDフィールドの値は、BaseID1である。Node IDフィールドの値は、WnID1である。Repository IDフィールドの値は、LirID1である。
【0067】
図16は、ポッド配置応答メッセージの一例を示す図である。ステップS24において、第1ワーカノード52は、受信したポッド配置要求メッセージに基づいて、第1ポッド81を第1ワーカノード52に配置する。ステップS25において、第1ワーカノード52は、第1ポッド81の配置を終了すると、ポッド配置応答メッセージを生成し、第1マスターノード41に送信する。ポッド配置応答メッセージは、第1ポッド81の配置を完了したことを応答するためのメッセージである。
図16に示すポッド配置応答メッセージは、TypeフィールドおよびApp IDフィールドを含む。Typeフィールドの値は、ポッド配置応答メッセージのメッセージタイプを示す“ポッド配置応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。
【0068】
ポッド配置応答メッセージは、1つのポッドについて、Pod IDフィールドおよびStatusフィールドからなる2つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。
図16の例では、Pod IDフィールドの値はPodID1である。Statusフィールドは、ポッド配置処理の終了状況を示す。
図16の例では、Statusフィールドの値は、第1ポッド81の配置の正常終了を示す“OK”である。
【0069】
(第3ポッド83の配置)
図17は、ポッド配置要求メッセージの一例を示す図である。ステップS25において、第1マスターノード41は、
図17に示すようなポッド配置要求メッセージを生成し、第3ワーカノードに送信する。
図17に示すポッド配置要求メッセージの構成は、
図15に示すポッド配置要求メッセージの構成と同一である。
図17の例では、ポッド配置要求メッセージは、第3ポッド83の配置に関する各種の情報を含んでいる。第3ワーカノードは、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第3ポッド83を第3ワーカノードに配置する。
【0070】
図18は、ポッド配置応答メッセージの一例を示す図である。ステップS26において、第3ワーカノードは、第3ポッド83の配置を終了すると、
図18に示すようなポッド配置応答メッセージを生成し、第1マスターノード41に送信する。
図18に示すポッド配置応答メッセージの構成は、
図16に示すポッド配置応答メッセージの構成と同一である。
図18の例では、ポッド配置応答メッセージは、第3ポッド83の配置完了に関する各種の情報を含んでいる。
【0071】
(第2ポッド82の配置)
図19は、ポッド配置要求メッセージの一例を示す図である。ステップS27において、第1マスターノード41は、
図19に示すようなポッド配置要求メッセージを生成し、第4ワーカノード53に送信する。
図19に示すポッド配置要求メッセージの構成は、
図15に示すポッド配置要求メッセージの構成と同一である。
図19の例では、ポッド配置要求メッセージは、第2ポッド82の配置に関する各種の情報を含んでいる。第4ワーカノード53は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第2ポッド82を第2ワーカノード72に配置する。
【0072】
図20は、ポッド配置応答メッセージの一例を示す図である。ステップS28において、第2ワーカノード72は、第2ポッド82の配置を終了すると、
図20に示すようなポッド配置応答メッセージを生成し、第1マスターノード41に送信する。
図20に示すポッド配置応答メッセージの構成は、
図16に示すポッド配置応答メッセージの構成と同一である。
図20の例では、ポッド配置応答メッセージは、第2ポッド82の配置完了に関する各種の情報を含んでいる。
【0073】
以上のようにして第1ポッド81、第2ポッド82、および第3ポッド83が正常に配置されることによって、アプリケーションが起動する。なお、第1ポッド81、第2ポッド82、および第3ポッド83の配置順は、
図6に示す順番に限らず、任意に変更できる。例えば、第3ポッド83を最初に配置し、次に第1ポッド81を配置し、最後に第2ポッド82を配置してもよい。
【0074】
(ポッド配置応答)
図21は、ポッド配置応答メッセージの一例を示す図である。ステップS29において、第1マスターノード41は、
図21に示すようなポッド配置応答メッセージを生成し、第1AppAPI46に送信する。
図21に示すポッド配置応答メッセージの構成は、
図16、
図18、および
図20にそれぞれ示す各ポッド配置応答メッセージを統合した構成である。すなわち、
図21に示すポッド配置応答メッセージは、第1ポッド81、第2ポッド82、および第3ポッド83のそれぞれの配置完了に関する情報を含んでいる。
【0075】
図22は、アプリ起動応答メッセージの一例を示す図である。ステップS30において、第1AppAPI46は、ポッド配置応答メッセージを受信すると、
図22に示すようなアプリ起動応答メッセージを生成し、起動App23に送信する。アプリ起動応答メッセージは、アプリケーションが起動したことを応答するためのメッセージである。
図22に示すアプリ起動応答メッセージは、Typeフィールド、App IDフィールド、およびStatusフィールドを含む。Typeフィールドの値は、アプリ起動応答メッセージのメッセージタイプを示す“アプリ起動応答”である。App IDフィールドの値は、実行されるアプリケーションの識別子であり、具体的にはAppID1である。Statusフィールドは、配置処理の終了状態を示す。
図22の例では、配置処理の正常終了を示す“OK”である。
【0076】
以上のようにして起動されたアプリケーションは、第1ポッド81、第2ポッド82、および第3ポッド83が連携して動作することによって、アプリケーションの実行を継続する。アプリケーションが起動したことによって、第1MECサーバ5、第2MECサーバ7、およびネットワークにおいて利用可能な各リソースが、アプリケーションによって消費されるリソース分だけ減少する。コンテナシステム1は、アプリケーションの起動後においても、
図2に示すように、第1拠点と他の拠点との間のネットワークの状況、各第1MECサーバ5のリソース状況、第2拠点と他の拠点との間のネットワーク状況、および各第2MECサーバ7のリソース状況を定期的に測定する。これにより、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32に保存されるネットワーク状況およびリソース状況を、定期的に更新する。しおたがって、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32にそれぞれ格納される情報を最新の状態に維持することができる。
【0077】
(アプリケーションの停止)
図23は、コンテナシステム1がアプリケーションを停止する際に実行する一連の処理の流れを示すシーケンス図である。ユーザは、端末機器2を操作し、所定のアプリケーションを停止させるための操作を、端末機器2に入力する。端末機器2は、この操作を検出すると、起動App23にアプリケーションの停止を指示する。
【0078】
図24は、アプリ停止要求メッセージの一例を示す図である。ステップS31において、起動App23は、端末機器2からアプリケーションの停止指示を受けると、
図24に示すようなアプリ停止要求メッセージを生成し、第1AppAPI46に送信する。アプリ停止要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、およびApp IDフィールドを含む。Typeフィールドの値は、アプリ停止要求メッセージのメッセージタイプを示す“アプリ停止要求”である。User IDフィールドは、端末機器2のユーザの識別子を示す。
図24の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、ユーザの認証認可情報を含む。
図24の例では、Credentialフィールドの値は、CredUsr1である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。
【0079】
ステップS32において、第1AppAPI46は、端末機器2のユーザの認証および認可を実行する。その際、第1AppAPI46は、携帯電話網などのコントロールプレーンにアクセスしてもよい。ステップS33において、第1AppAPI46は、ユーザの認証および認可に成功すると、受信したアプリ停止要求メッセージを第1マスターノード41に送信する。
【0080】
図25は、ポッド停止要求メッセージの一例を示す図である。ステップS34において、第1マスターノード41は、アプリ停止要求メッセージを受信すると、
図25に示すようなポッド停止要求メッセージを生成し、第1ワーカノード52に送信する。
図25に示すポッド停止要求メッセージは、第1ポッド81の停止を要求するためのメッセージである。
図25の例では、ポッド停止要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド停止要求メッセージのメッセージタイプを示す“ポッド停止要求”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、停止されるポッドの数を示す。
図25の例では、No of Podsフィールドの値は1である。
【0081】
ポッド停止要求メッセージは、1つのポッドについて、Pod IDフィールド、Base IDフィールド、およびNode IDフィールドからなる3つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。
図25の例では、Pod IDフィールドの値はPodID1である。Base IDフィールドは、ポッドが配置されている拠点の識別子を示す。
図25の例では、Base IDフィールドの値は、第1ポッド81が配置されている第1拠点の識別子すなわちBaseID1である。Node IDフィールドは、ポッドが配置されているワーカノードの識別子を示す。
図25の例では、Node IDフィールドの値は、第1ポッド81が配置されている第1ワーカノード52の識別子すなわちWnID1である。
【0082】
図26は、ポッド停止応答メッセージの一例を示す図である。第1ワーカノード52は、ポッド停止要求メッセージを受信すると、第1ポッド81を停止する。ステップS35において、第1ワーカノード52は、第1ポッド81の停止に成功すると、
図26に示すようなポッド停止応答メッセージを生成し、第1マスターノード41に送信する。
図26に示すポッド停止応答メッセージは、第1ポッド81の停止に成功したことを応答するためのメッセージである。
図26の例では、ポッド停止応答メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値はメッセージタイプを示す“ポッド停止応答”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドはポッドの数を示す。この例では1である。
【0083】
ポッド停止応答メッセージは、1つのポッドについて、Pod IDフィールドおよびStatusフィールドからなる2つ組フィールドをさらに含む。Pod IDフィールドは、ポッドの識別子を示す。
図26の例では、Pod IDフィールドの値は、停止される第1ポッド81の識別子すなわちPodID1である。Statusフィールドは、処理の終了状態を示す。
図26の例では、正常終了を示す“OK”である。
【0084】
ステップS36において、第1マスターノード41は、第3ポッド83を停止させるためのポッド停止要求メッセージを生成し、第3ワーカノードに送信する。第3ワーカノードは、ポッド停止要求メッセージを受信すると、第3ポッド83を停止する。ステップS37において、第3ワーカノードは、第3ポッド83を停止したことを応答するためのポッド停止応答メッセージを生成し、第1マスターノード41に送信する。第3ポッド83の停止時における各処理の手順は、第1ポッド81の停止時における各処理の手順と同様であるため、詳細な説明を省略する。
【0085】
ステップS38において、第2マスターノード61は、第2ポッド82を停止させるためのポッド停止要求メッセージを生成し、第2ワーカノード72に送信する。第2ワーカノード72は、ポッド停止要求メッセージを受信すると、第2ポッド82を停止する。ステップS39において、第2ワーカノード72は、第2ポッド82を停止したことを応答するためのポッド停止応答メッセージを生成し、第1マスターノード41に送信する。第2ポッド82の停止時における各処理の手順は、第1ポッド81の停止時における各処理の手順と同様であるため、詳細な説明を省略する。
【0086】
図27は、アプリ停止応答メッセージの一例を示す図である。ステップS40において、第1マスターノード41は、アプリ停止応答メッセージを生成し、第1AppAPI46に送信する。アプリ停止応答メッセージは、アプリケーションを停止したことを応答するためのメッセージである。
図27の例では、アプリ停止応答メッセージは、Typeフィールド、App IDフィールド、およびStatusフィールドを含む。Typeフィールドの値は、アプリ停止応答メッセージのメッセージタイプを示す“アプリ停止応答”である。App IDフィールドの値は、停止されるアプリケーションの識別子であり、具体的にはAppID1である。Statusフィールドは、処理の終了状態を示す。
図2の例では、Statusフィールドの値は、アプリケーション停止の正常終了を示す“OK”である。
【0087】
ステップS41において、第1AppAPI46は、アプリ停止応答メッセージを受信すると、受信したアプリ停止応答メッセージを起動App23に送信する。ステップS42において、起動App23は、アプリ停止応答メッセージを受信すると、終了する。これにより、アプリケーションの終了が完了する。
【0088】
図28は、測定要求メッセージの一例を示す図である。ステップS43において、第1AppAPI46は、
図28に示すような測定要求メッセージを生成し、第1ネットワークモニタ42に送信する。
図28に示す測定要求メッセージは、ネットワーク状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。
図28の例では、No of Targetsフィールドの値は1である。測定要求メッセージは、1つの測定要求対象につき、1つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。
図28の例では、Target IDフィールドの値は、第1ネットワークモニタ42の識別子すなわちNmonID1である。
【0089】
図29は、測定要求メッセージの一例を示す図である。ステップS44において、第1AppAPI46は、
図29に示すような測定要求メッセージを生成し、第1リソースモニタ51に送信する。
図29に示す測定要求メッセージは、リソース状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。
図29の例では、No of Targetsフィールドの値は1である。測定要求メッセージは、1つの測定要求対象につき、1つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。
図29の例では、Target IDフィールドの値は、第1リソースモニタ51の識別子すなわちRmonID1である。
【0090】
図30は、測定要求メッセージの一例を示す図である。ステップS45において、第1AppAPI46は、
図30に示すような測定要求メッセージを生成し、第2AppAPI66に送信する。
図30に示す測定要求メッセージは、ネットワーク状況およびリソース状況の測定を要求するためのメッセージである。測定要求メッセージは、TypeフィールドおよびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。
図30の例では、No of Targetsフィールドの値は2である。測定要求メッセージは、1つの測定要求対象につき、1つのTarget IDフィールドをさらに含む。
図30の例では、測定要求メッセージは、2つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。
図30の例では、1つ目のTarget IDフィールドの値は、第2ネットワークモニタ62の識別子すなわちNmonID2である。2つ目のTarget IDフィールドの値は、第2リソースモニタ71の識別子すなわちRmonID2である。
【0091】
図31は、測定要求メッセージの一例を示す図である。ステップS46において、第2AppAPI66は、
図31に示すような測定要求メッセージを生成し、第2ネットワークモニタ62に送信する。
図31に示す測定要求メッセージは、ネットワーク状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。
図31の例では、No of Targetsフィールドの値は1である。測定要求メッセージは、1つの測定要求対象につき、1つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。
図31の例では、Target IDフィールドの値は、第2ネットワークモニタ62の識別子すなわちNmonID2である。
【0092】
図32は、測定要求メッセージの一例を示す図である。ステップS47において、第2AppAPI66は、
図32に示すような測定要求メッセージを生成し、第2リソースモニタ71に送信する。
図32に示す測定要求メッセージは、リソース状況の測定を要求するためのメッセージである。測定要求メッセージは、Typeフィールド、およびNo of Targetsフィールドを含む。Typeフィールドの値は、測定要求メッセージのメッセージタイプを示す“測定要求”である。No of Targetsフィールドは、測定要求対象の個数を示す。
図32の例では、No of Targetsフィールドの値は1である。測定要求メッセージは、1つの測定要求対象につき、1つのTarget IDフィールドをさらに含む。Target IDフィールドは、測定を要求するモジュールの識別子を示す。
図32の例では、Target IDフィールドの値は、第2リソースモニタ71の識別子すなわちRmonID2である。
【0093】
ステップS43~S47に基づいて、第1ネットワークモニタ42、第1リソースモニタ51、第2ネットワークモニタ62、および第2リソースモニタ71は、
図3に示す一連の処理手順を実行する。これにより、アプリケーション終了後における最新のネットワーク状況およびリソース状況が、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32に反映される。
【0094】
(本実施形態による主要な効果)
第1MECサーバ5は、第1リソースモニタ51によって第1ワーカノード52のリソース状況を測定し、第1拠点装置4に送信する。第1拠点装置4は、第1ネットワークモニタ42を使用することによって、第1拠点から第2拠点への通信時のネットワーク状況(通信遅延等)を測定する。これらのネットワーク状況およびリソース状況は、第1ローカルデータストア44に保存する。第1ローカルMANO43は、第1ローカルデータストア44に保存されたネットワーク状況およびリソース状況に基づいて、第1ポッド81を第1MECサーバ5に配置するか否かを決定する。これにより、ネットワーク状況およびリソース状況を考慮した第1ポッド81の配置が可能になるため、第1ポッド81を最適な第1ワーカノード52に配置することができる。
【0095】
第1ローカルMANO43は、第1ローカルデータストア44に保存されたネットワーク状況およびリソース状況に基づいて、第1ポッド81が要求するネットワークへの要求事項およびリソースへの要求事項を満たす第1MECサーバ5に第1ポッド81を配置することを決定する。これにより、第1ポッド81を確実に配置することができる。
【0096】
第2MECサーバ7は、第2リソースモニタ71によって第2ワーカノード72のリソース状況を測定し、第2拠点装置6に送信する。第2拠点装置6は、第2ネットワークモニタ62を使用することによって、第2拠点から第1拠点への通信時のネットワーク状況(通信遅延等)を測定し、第2ローカルデータストア64に保存する。これらのネットワーク状況およびリソース状況は、グローバルデータストア32にも保存される。グローバルMANO31は、グローバルデータストア32に保存された第2拠点に関するネットワーク状況およびリソース状況を考慮することによって、第2ポッド82を第2MECサーバ7の第2ワーカノード72に配置するか否かを決定する。この結果、ネットワーク状況を考慮したポッド配置が可能となるため、通信遅延が少ない等の良好なネットワーク状況にある各ワーカノードに各ポッドを配置することができる。さらに、ネットワークを介して広域分散した拠点間でのポッドの最適な配置が可能となる。
【0097】
第1MECサーバ5は、第1ワーカノード52が複数のコンテナオーケストレーションクラスタに属していたとしても、第1リソースモニタ51を使用することによって、第1ワーカノード52の正しいリソース状況を測定することができる。これにより、第1ワーカノード52の正しいリソース状況に基づいて第1ポッド81を第1ワーカノード52に配置するか否かを決定することができるため、第1ポッド81の配置に失敗する可能性を低下させることができる。
【0098】
同様に、第2MECサーバ7は、第2ワーカノード72が複数のコンテナオーケストレーションクラスタに属していたとしても、第2リソースモニタ71を使用することによって、第2ワーカノード72の正しいリソース状況を測定することができる。したがって、クラウドサーバ3は、第1拠点装置4から受信した各第1MECサーバ5のリソース状況および第2拠点装置6から受信した各第2MECサーバ7のリソース状況をグローバルデータストア32に保存することによって、全てのワーカノードのリソース状況を正しく把握することができる。
【0099】
コンテナオーケストレーションクラスタとして実行されるアプリケーションの起動後、コンテナオーケストレーションクラスタとして実行されるアプリケーションを構成する第1ポッド81は、端末機器2が接続されるネットワーク内の第1MECサーバ5に配置されている。また、第2ポッド82は、端末機器2が接続されるネットワーク内の第2MECサーバ7に配置されている。さらに、第3ポッド83は、端末機器2に配置されている。一方、アプリケーションを起動させるための起動App23は、コンテナオーケストレーションクラスタに属していない。そのため、アプリケーションの実行中に、起動App23と第1ポッド81、第2ポッド82、および第3ポッド83のいずれかとが、中継ポッドを介して通信することはない。さらに、アプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83の間で、中継ポッドを介した通信が行われない。これらにより、アプリケーションの起動時および起動後の実行時において、ポッド間の通信経路が冗長になることを防止することができる。
【0100】
既存のコンテナオーケストレーションシステムに対してコンテナシステム1を新たに導入する際、既存のコンテナオーケストレーションシステムの部分に対する変更は必要としない。そのため、稼働中の既存のコンテナオーケストレーションシステムに対してコンテナシステム1を容易に導入することができる。
【0101】
端末機器2において実行されるアプリケーションの一部を、第1MECサーバ5および第2MECサーバ7に効率的にオフロードすることができる。
【0102】
(変形例)
コンテナシステム1では、第1ワーカノード52が複数の異なるコンテナオーケストレーションクラスタに属すると共に、第2ワーカノード72が複数の異なるコンテナオーケストレーションクラスタに属しても良い。この場合も、第1MECサーバ5は、第1リソースモニタ51を使用することによって、第1ワーカノード52および第4ワーカノード53のリソース状況を正確に測定する。測定された各第1MECサーバ5のリソース状況は、第1拠点装置4において集約され、かつクラウドサーバ3に送信される。同様に、測定された各第2MECサーバ7のリソース状況は、第2拠点装置6において集約され、かつクラウドサーバ3に送信される。クラウドサーバ3は、受信した各リソース状況を、グローバルデータストア32に保存する。したがって、クラウドサーバ3は、全てのワーカノードのリソース状況を正しく把握することができる。
【0103】
さらに、コンテナシステム1では、第1拠点装置4の代わりにクラウドサーバ3が、第1ポッド81の配置を決定してもよい。本例では、第1AppAPI46は、
図10に示すポッド配置決定要求メッセージを、第1ローカルMANO43ではなく、グローバルMANO31に通知する。グローバルMANO31は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第1ポッド81および第2ポッド82の全てを、第1拠点および第2拠点のうちいずれに配置するのかを決定する。
【0104】
具体的には、グローバルMANO31は、グローバルデータストア32に保存された、第1拠点のネットワーク状況、各第1MECサーバ5のリソース状況、第2拠点のネットワーク状況、および各第2MECサーバ7のリソース状況と、受信したポッド配置決定要求メッセージに含まれる第1ポッド81に関するネットワークへの要求事項およびリソースに対する要求事項とに基づいて、第1ポッド81を第1ワーカノード52および第2ワーカノード72のうちいずれのワーカノードに設置するのかを決定する。グローバルMANO31は、例えば、第1拠点のネットワーク状況および第1MECサーバ5の第1ワーカノード52のリソース状況が、第1ポッド81に関するネットワークへの要求事項およびリソースに対する要求事項を満たす場合、第1ポッド81を第1MECサーバ5の第1ワーカノード52に配置することを決定する。グローバルMANO31は、あるいは、第2拠点のネットワーク状況および第2MECサーバ7の第2ワーカノード72のリソース状況が、第1ポッド81に関するネットワークへの要求事項およびリソースに対する要求事項を満たす場合、第1ポッド81を第2MECサーバ5の第2ワーカノード72に配置することを決定する。このように、グローバルMANO31は、各拠点のネットワーク状況および各ワーカノードのネットワーク状況を考慮して、第1ポッド81を配置すべき最適なMECサーバ(ワーカノード)を選択することができる。
【0105】
第1ローカルイメージリポジトリ45は、アプリ構成情報要求メッセージを受信した時点において、受信したアプリ構成情報要求メッセージによって示されるアプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83の各イメージを予め保存していてもよい。この場合、第1ローカルイメージリポジトリ45は、受信したアプリ構成情報要求メッセージをオリジンイメージリポジトリ33に送信することなく、アプリ構成情報要求メッセージによって示されるアプリケーションを構成する第1ポッド81、第2ポッド82、および第3ポッド83のイメージを、自身の記憶スペースから読み出す。第1ローカルイメージリポジトリ45は、読み出した各ポッドイメージに基づいて、
図9に示すようなアプリ構成情報応答メッセージを生成し、第1AppAPI46に送信する。本例では、アプリ構成情報要求メッセージをオリジンイメージリポジトリ33に送信したり、オリジンイメージリポジトリ33からアプリ構成情報応答メッセージを受信したりする必要がなくなるため、通信遅延を低減することができる。さらには、クラウドと各拠点との間の通信トラフィックを削減することもできる。
【0106】
〔実施形態2〕
(コンテナシステム1Aの構成)
図33は、第2実施形態に係るコンテナシステム1Aの構成を示すブロック図である。端末機器2Aは、クライアントApp24を実行している。クライアントApp24は、クライアント・サーバ型アプリケーションにおけるクライアントアプリケーションである。クラウドサーバ3Aは、サーバApp34を実行している。サーバApp34は、クライアント・サーバ型アプリケーションにおけるサーバアプリケーションである。
【0107】
本実施形態では、コンテナオーケストレーションクラスタは、第1マスターノード41、第1ワーカノード52、第4ワーカノード53、および不図示の中継ポッドによって構成されている。
図33は、サーバApp34に対応するサーバアプリケーションが、第1ワーカノード52上で動作する第1ポッド81と、第2ワーカノード72上で動作する第2ポッド82とによって構成されるコンテナオーケストレーションクラスタとして動作する例を示している。
図34に示す各モジュールの識別子は、実施形態1で説明した各識別子と同一である。ただし、実施形態1では端末機器2で起動されたアプリケーションの識別子であるAppID1を、本実施形態ではサーバApp34に対応するサーバアプリケーションの識別子として扱う。
【0108】
図34は、端末機器2がクライアントApp24を起動する際にコンテナシステム1Aによって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器2を操作し、クライアントApp24を起動するための操作を端末機器2に入力する。ステップS51において、端末機器2Aは、この操作を検出すると、クライアントApp24を起動する。
【0109】
図35は、アプリ要求メッセージの一例を示す図である。ステップS52において、起動されたクライアントApp24は、サーバApp34にアプリ要求メッセージを送信する。アプリ要求メッセージは、サーバApp34に要求を送信するためのメッセージである。アプリ要求メッセージは、HTTPRequestメッセージでもよい。なお、サーバApp34は、端末機器2Aのアドレスから端末機器2Aに近い拠点が第1拠点であることを知ることができるものとする。
【0110】
アプリ要求メッセージは、Typeフィールド、User IDフィールド、Credentialフィールド、App IDフィールド、およびRequestフィールドを含む。Typeフィールドの値は、アプリ要求メッセージのメッセージタイプを示す“アプリ要求”である。User IDフィールドは、端末機器2のユーザの識別子を示す。
図35の例では、User IDフィールドの値はUsrID1である。Credentialフィールドは、ユーザの認証認可情報を含む。
図35の例では、Credentialフィールドの値は、CredUsr1である。App IDフィールドの値は、サーバApp34に対応するサーバアプリケーションの識別子であり、具体的にはAppID1である。Requestフィールドは、クライアントApp24の要求内容を示す。ステップS53において、サーバApp34は、受信したアプリ要求メッセージに基づいて、端末機器2のユーザを認証しかつ認可する。
【0111】
ステップS54において、サーバApp34は、ユーザの認証および認可に成功すると、ポッド配置決定要求メッセージを生成し、第1拠点内の第1ローカルMANO43に送信する。ポッド配置決定要求メッセージは、サーバApp34に対応するサーバアプリケーションを構成する第1ポッド81および第2ポッド82の配置決定を要求するためのメッセージである。このポッド配置決定要求メッセージは、
図10に示すポッド配置決定要求メッセージと同一である。
【0112】
(第1ポッド81の配置決定)
第1ローカルMANO43は、ポッド配置決定要求メッセージを受信すると、受信したポッド配置決定要求メッセージによって示される第1ポッド81および第2ポッド82の全てを、第1拠点内の各ワーカノードに配置できるか否かを決定する。決定方法の詳細は、第1実施形態のそれと同一であるため、詳細な説明を省略する。ここでは、第1ローカルMANO43は、第1ポッド81を第1拠点内の第1MECサーバ5の第1ワーカノード52に配置することを決定するものとする。また、第1ローカルMANO43はさらに、第2ポッド82については、第1拠点内の他の全ての第1MECサーバ5の第1ワーカノード52または第4ワーカノード53に配置できないと決定するものとする。これにより、ステップS55において、第1ローカルMANO43は、ポッド配置決定要求メッセージを生成し、グローバルMANO31に送信する。ここで送信されるポッド配置決定要求メッセージは、第2ポッド82の配置決定を要求するためのメッセージである。また、その構成および内容は、
図11に示すポッド配置決定要求メッセージの構成および内容と同一である。
【0113】
(第2ポッド82の配置決定)
グローバルMANO31は、ポッド配置決定要求メッセージを受信すると、第2ポッド82を第2拠点の第2MECサーバ7に配置するか否かを決定する。決定方法の詳細は、第1実施形態のそれと同一であるため、詳細な説明は省略する。ここでは、グローバルMANO31は、第2ポッド82を第2MECサーバ7の第2ワーカノード72に配置することを決定するものとする。これにより、ステップS56において、グローバルMANO31は、第1ポッド81の配置決定を応答するためのポッド配置決定応答メッセージを生成し、第1ローカルMANO43に送信する。ここで送信されるポッド配置決定応答メッセージの構成および内容は、
図12に示すポッド配置決定応答メッセージの構成および内容と同一である。
【0114】
ステップS57において、第1ローカルMANO43は、第1ポッド81および第2ポッド82の配置決定を応答するためのポッド配置決定応答メッセージを生成し、サーバApp34に送信する。ここで送信されるポッド配置決定応答メッセージの構成および内容は、
図13に示すポッド配置決定応答メッセージの構成および内容と同一である。
【0115】
図36は、ポッド配置要求メッセージの一例を示す図である。ステップS58において、サーバApp34は、ポッド配置決定応答メッセージを受信すると、
図36に示すようなポッド配置要求メッセージを生成し、第1マスターノード41に送信する。ポッド配置要求メッセージは、第1ポッド81および第2ポッド82の配置を要求するためのメッセージである。
図36の例では、ポッド配置要求メッセージは、Typeフィールド、App IDフィールド、およびNo of Podsフィールドを含む。Typeフィールドの値は、ポッド配置要求メッセージのメッセージタイプを示す“ポッド配置要求”である。App IDフィールドの値は、サーバApp34に対応するサーバアプリケーションの識別子であり、具体的にはAppID1である。No of Podsフィールドは、ポッドの数を示す。
図36の例では、ポッド配置要求メッセージによって3つの第1ポッド81および第2ポッド82の配置が要求されるので、No of Podsフィールドの値は2である。
【0116】
ポッド配置要求メッセージは、ポッドごとに、Pod IDフィールド、Base IDフィールド、Node IDフィールド、およびRepository IDフィールドという4つ組フィールドをさらに含む。
図36の例では、2つの第1ポッド81および第2ポッド82の配置が要求されるので、ポッド配置要求メッセージは3つの4つ組フィールドをさらに含む。
図36の例では、1つ目の4つ組フィールドにおけるPod IDフィールドの値は、第1ポッド81の識別子すなわちPodID1である。Base IDフィールドの値は、第1ポッド81が配置される第1拠点のBaseID1である。Node IDフィールドの値は、第1ポッド81が配置される第1ワーカノード52の識別子すなわちWnID1である。Repository IDフィールドの値は、LirID1である。2つ目の4つ組フィールドにおけるPod IDフィールドの値は、第2ポッド82の識別子すなわちPodID2である。Base IDフィールドの値は、第2ポッド82が配置される第2拠点の識別子すなわちBaseID2である。Node IDフィールドの値は、第2ポッド82が配置される第2ワーカノード72の識別子すなわちWnID2である。Repository IDフィールドの値は、LirID2である。
【0117】
(第1ポッド81の配置)
ステップS59において、第1マスターノード41は、ポッド配置要求メッセージを受信すると、第1ポッド81の配置を要求するためのポッド配置要求メッセージを生成し、第1ワーカノード52に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、
図15に示すポッド配置要求メッセージの構成および内容と同一である。第1ワーカノード52は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第1ワーカノード52に第1ポッド81を配置する。ステップS60において、第1ワーカノード52は、第1ポッド81の配置を応答するためのポッド設置応答メッセージを生成し、第1マスターノード41に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、
図16に示すポッド設置応答メッセージの構成および内容と同一である。
【0118】
(第2ポッド82の配置)
ステップS61において、第1マスターノード41は、第2ポッド82の配置を要求するためのポッド配置要求メッセージを生成し、第2ワーカノード72に送信する。ここで送信されるポッド配置要求メッセージの構成および内容は、
図16に示すポッド配置要求メッセージの構成および内容と同一である。第2ワーカノード72は、ポッド配置要求メッセージを受信すると、受信したポッド配置要求メッセージに基づいて、第2ワーカノード72に第2ポッド82を配置する。ステップS62において、第4ワーカノード53は、第2ポッド82の配置を応答するためのポッド設置応答メッセージを生成し、第1マスターノード41に送信する。ここで送信されるポッド設置応答メッセージの構成および内容は、
図17に示すポッド設置応答メッセージの構成および内容と同一である。
【0119】
図37は、ポッド配置応答メッセージの一例を示す図である。ステップS63において、第1マスターノード41は、
図37に示すようなポッド配置応答メッセージを生成し、サーバApp34に送信する。
図37に示すポッド配置応答メッセージの構成は、
図16および
図18にそれぞれ示す各ポッド配置応答メッセージを統合した構成である。すなわち、
図21に示すポッド配置応答メッセージは、第1ポッド81および第2ポッド82のそれぞれの配置完了に関する情報を含んでいる。
【0120】
図38は、アプリ応答メッセージの一例を示す図である。ステップS64において、サーバApp34は、
図38に示すようなアプリ応答メッセージを生成し、クライアントApp24に送信する。アプリ応答メッセージは、サーバApp34に対応するサーバアプリケーションの起動を応答するためのメッセージである。
図38の例では、アプリ応答メッセージは、Typeフィールド、Statusフィールド、Redirectフィールド、およびResponseフィールドを含む。Typeフィールドの値は、アプリ応答メッセージのメッセージタイプを示す“アプリ応答”である。Statusフィールドは、処理の終了状態を示す。この例では、サーバApp34に対応するサーバアプリケーションの起動の正常終了を示す“OK”である。Redirectフィールドは、これ以降のアプリ要求メッセージの送り先モジュールの識別子を示す。
図38の例では、中継ポッドの識別子すなわちRelayPodID1である。Responseフィールドは、応答内容を示す。
【0121】
以上のようにして起動された、コンテナオーケストレーションクラスタとしてのサーバアプリケーションは、第1ポッド81および第2ポッド82が連携して動作することによって、サーバApp34としての実行を継続する。これ以降、クライアントApp24の通信相手は、クラウドサーバ上のサーバApp34ではなく、第1拠点および2に構築された、コンテナオーケストレーションクラスタとしてのサーバアプリケーションである。したがって、ステップS65において、クライアントApp24は、新たなアプリ要求メッセージを、クラウドサーバ上のサーバApp34ではなく、第1ポッド81が配置される第1ワーカノード52に送信する。第1ワーカノード52がアプリ要求メッセージを受信すると、第1ポッド81は第2ポッド82と連携して動作することによって、アプリ要求メッセージによって要求される処理を実行する。ステップ66において、第1ワーカノード52は、コンテナオーケストレーションクラスタとしてのサーバApp34による処理を応答するためのアプリ応答メッセージを生成し、クライアントApp24に送信する。
【0122】
本実施形態では、コンテナオーケストレーションクラスタとしてのサーバアプリケーションが起動したことによって、第1MECサーバ5、第2MECサーバ7、およびネットワークにおいて利用可能な各リソースが、サーバApp34に対応するサーバアプリケーションによって消費されるリソース分だけ減少する。コンテナシステム1Aは、サーバApp34に対応するサーバアプリケーションの起動後においても、
図2に示すように、第1拠点のネットワークの状況、各第1MECサーバ5のリソース状況、第2拠点のネットワーク状況、および各第2MECサーバ7のリソース状況を定期的に測定する。これにより、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32に保存されるネットワーク状況およびリソース状況を、定期的に更新する。したがって、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32にそれぞれ格納される情報を最新の状態に維持することができる。
【0123】
(サーバアプリケーションの停止)
図39は、サーバアプリケーションを停止する際にコンテナシステム1Aによって実行される一連の処理の流れを示すシーケンス図である。ユーザは、端末機器2を操作し、サーバApp34として動作するサーバアプリケーションを終了させるための操作を、端末機器2Aに入力する。ステップS71において、クライアントApp24は、端末機器2Aがこの操作を検出すると、サーバアプリケーションの終了を要求のためのアプリ終了要求メッセージを生成し、サーバApp34に送信する。ここで送信されるアプリ終了要求メッセージの構成および内容は、
図24に示すアプリ終了要求メッセージの構成および内容と同一である。
【0124】
サーバApp34は、クライアントApp24から送信されたアプリ終了要求メッセージを受信する。ステップS72において、サーバApp34は、受信したアプリ終了要求メッセージに基づいて、端末機器2のユーザの認証および認可を実行する。ステップS73において、サーバApp34は、ユーザの認証および認可に成功した場合、受信したアプリ停止要求メッセージを第1マスターノード41に送信する。
【0125】
第1マスターノード41は、サーバApp34から送信されたアプリ停止要求メッセージを受信する。ステップS74において、第1マスターノード41は、第1ポッド81の停止を要求するためのポッド停止要求メッセージを生成し、第1ワーカノード52に送信する。ここで送信されるポッド停止要求メッセージの構成および内容は、
図24に示すポッド停止要求メッセージの構成および内容と同一である。
【0126】
第1ワーカノード52は、第1マスターノード41から送信されたポッド停止要求メッセージを受信する。第1ワーカノード52は、ポッド停止要求メッセージを受信すると、第1ポッド81を停止する。ステップS75において、第1ワーカノード52は、第1ポッド81の停止を応答するためのポッド停止応答メッセージを生成し、第1マスターノード41に送信する。ここで送信されるポッド停止応答メッセージの構成および内容は、
図26に示すポッド停止応答メッセージの構成および内容と同一である。
【0127】
第1マスターノード41は、第1ワーカノード52から送信されたポッド停止応答メッセージを受信する。ステップS76において、第1マスターノード41は、第2ポッド82の停止を要求するためのポッド停止要求メッセージを生成し、第2ワーカノード72に送信する。ここで送信されるポッド停止要求メッセージの構成および内容は、
図27に示すポッド停止要求メッセージの構成および内容と同一である。第2ワーカノード72は、第1マスターノード41から送信されたポッド停止要求メッセージを受信する。これにより、第4ワーカノード53は第2ポッド82を停止する。第1ポッド81および第2ポッド82の双方が停止された結果、サーバApp34に対応するサーバアプリケーションは終了する。
【0128】
ステップS77において、第2ワーカノード72は、第2ポッド82の停止を応答するためのポッド停止応答メッセージを生成し、第1マスターノード41に送信する。ここで送信されるポッド停止応答メッセージの構成および内容は、
図27に示すポッド停止応答メッセージの構成および内容と同一である。
【0129】
ステップS78において、第1マスターノード41は、サーバアプリケーションの停止を応答するためのアプリ停止応答メッセージを生成し、サーバApp34に送信する。ここで送信されるアプリ停止応答メッセージの構成および内容は、
図27に示すアプリ停止応答メッセージと同一である。ステップS79において、サーバApp34は、受信したアプリ停止応答メッセージを生成し、クライアントApp24に送信する。クライアントApp24は、アプリ停止応答メッセージを受信すると終了する。
【0130】
ステップS80において、サーバApp34は、ネットワーク状況の測定を要求する測定要求メッセージを送信する。ここで送信される測定要求メッセージの構成および内容は、
図28に示す測定要求メッセージの構成および内容と同一である。
【0131】
ステップS81において、サーバApp34は、ネットワーク状況の測定を要求する測定要求メッセージを生成し、第1ネットワークモニタ42に送信する。ここで送信される測定要求メッセージの構成および内容は、
図28に示す測定要求メッセージの構成および内容と同一である。ステップS82において、サーバApp34は、リソース状況の測定を要求する測定要求メッセージを生成し、第1リソースモニタ51に送信する。ここで送信される測定要求メッセージの構成および内容は、
図29に示す測定要求メッセージの構成および内容と同一である。ステップS83において、サーバApp34は、ネットワーク状況の測定を要求する測定要求メッセージを生成し、第2ネットワークモニタ62に送信する。ここで送信される測定要求メッセージの構成および内容は、
図30に示す測定要求メッセージの構成および内容と同一である。ステップS84において、サーバApp34は、リソース状況の測定を要求する測定要求メッセージを生成し、第2リソースモニタ71に送信する。ここで送信される測定要求メッセージの構成および内容は、
図31に示す測定要求メッセージの構成および内容と同一である。
【0132】
ステップS79~S84に基づいて、第1ネットワークモニタ42、第1リソースモニタ51、第2ネットワークモニタ62、および第2リソースモニタ71は、
図3に示す一連の処理手順を実行する。これにより、アプリケーション終了後における最新のネットワーク状況およびリソース状況が、第1ローカルデータストア44、第2ローカルデータストア64、およびグローバルデータストア32に反映される。
【0133】
(本実施形態による主要な効果)
実施形態1のコンテナシステム1によって奏する各効果は、本実施形態においても同様に得られる。さらに、本実施形態では、クライアント・サーバ型アプリケーションを実行する際、サーバアプリケーションを、クライアントアプリケーションの近傍にある第1MECサーバ5および第2MECサーバ7に効率的に配置することができる。
【0134】
〔まとめ〕
本発明の態様1に係るポッド配置決定装置は、第1ワーカノードを備えている第1エッジサーバが配置される第1拠点から、第2ワーカノードを備えている第2エッジサーバが配置される第2拠点への通信時のネットワーク状況を測定する測定部と、前記第1エッジサーバによって測定された前記第1ワーカノードのリソース状況を受信する第1受信部と、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2受信部と、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ポッドを前記第1ワーカノードに配置するか否かを決定する決定部とを備えている構成である。
【0135】
本発明の態様2に係るポッド配置決定装置は、上記の態様1において、前記決定部は、前記ネットワーク状況が前記ネットワークへの要求事項を満たしており、かつ、前記リソース状況が前記リソースへの要求事項を満たしている場合、前記第1ポッドを前記第1ワーカノードに配置することを決定する構成としてもよい。
【0136】
本発明の態様3に係るポッド配置決定装置は、上記の態様1または2において、前記第1ワーカノードは、異なる複数のコンテナオーケストレーションクラスタに属しており、前記第1エッジサーバは、前記第1ワーカノードのリソース状況を測定するリソース状況測定部を備えている構成としてもよい。
【0137】
本発明の態様4に係るポッド配置決定装置は、上記の態様1~3のいずれかにおいて、前記第1ポッドのイメージを保存するイメージ保存部をさらに備えている構成としてもよい。
【0138】
本発明の態様5に係るポッド配置決定方法は、第1ワーカノードを備えている第1エッジサーバが配置される第1拠点から、第2ワーカノードを備えている第2エッジサーバが配置される第2拠点への通信時のネットワーク状況を測定する測定ステップと、前記第1エッジサーバによって測定された前記第1ワーカノードのリソース状況を受信する第1受信ステップと、測定されたネットワーク状況および受信されたリソース状況を保存する保存部と、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2受信ステップと、保存された前記ネットワーク状況およびリソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ポッドを前記第1ワーカノードに配置するか否かを決定する決定ステップとを有する方法である。
【0139】
本発明の態様6に係るエッジサーバは、異なる複数のコンテナオーケストレーションクラスタに属するワーカノードと、前記ワーカノードのリソース状況を測定する測定部と、測定された前記リソース状況をポッド配置決定装置に送信する送信部とを備えている構成である。
【0140】
本発明の態様7に係るサーバは、ポッド配置決定装置と、前記第2拠点に配置される第2ポッド配置決定装置とそれぞれ通信可能に接続されるサーバであって、前記ポッド配置決定装置から送信された前記ネットワーク状況および前記リソース状況と、前記第2ポッド配置決定装置から送信された、前記第2拠点から前記第1拠点への通信時の第2ネットワーク状況および前記第2ワーカノードの第2リソース状況とを受信する第1サーバ受信部と、受信された前記ネットワーク状況、前記リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を保存するサーバ情報保存部と、前記アプリケーションを構成する第2ポッドが要求するネットワークへの第2要求事項および前記第2ポッドが要求するリソースへの第2リソース状況を受信する第2サーバ受信部と、保存された前記第2ネットワーク状況および第2リソース状況と、受信された前記ネットワークへの第2要求事項および前記リソースへの第2要求事項とに基づいて、前記第2ポッドを前記第2ワーカノードに配置するか否かを決定する第2決定部とを備えている構成である。
【0141】
本発明の態様8に係る端末機器は、端末機器であって、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが、前記端末機器が接続されるネットワーク内のエッジサーバに配置されており、前記アプリケーションを起動するための、前記コンテナオーケストレーションクラスタに属していない起動モジュールをさらに備えている構成である。
【0142】
本発明の態様9に係るコンテナシステムは、上記の態様1に係るポッド配置決定装置と、上記の態様7に係るサーバとを少なくとも備えている構成である。
【0143】
本発明の態様10に係るコンテナシステムは、第1拠点に配置される第1エッジサーバおよび第1拠点装置と、第2拠点に配置される第2エッジサーバおよび第2拠点装置と、サーバとを備えているコンテナシステムであって、前記第1エッジサーバは、複数の異なるコンテナオーケストレーションクラスタに属する第1ワーカノードと、前記第1ワーカノードの第1リソース状況を測定する第1リソース状況測定部と、測定された前記第1リソース状況を、前記第1拠点装置に送信する第1リソース状況送信部と、を備えており、前記第1拠点装置は、前記第1リソース状況を受信する第1受信部と、受信された前記第1リソース状況を、前記サーバに送信する第1送信部と、前記第2エッジサーバは、複数の異なるコンテナオーケストレーションクラスタに属する第2ワーカノードと、前記第2ワーカノードの第2リソース状況を測定する第2リソース状況測定部と、測定された前記第2リソース状況を、前記第2拠点装置に送信する第2リソース状況送信部と、を備えており、前記第2拠点装置は、前記第2リソース状況を受信する第2受信部と、受信された前記第2リソース状況を、前記サーバに送信する第2送信部とを備えており、前記サーバは、前記第1リソース状況および前記第2リソース状況を受信する第1サーバ受信部と、受信された前記第1リソース状況および前記第2リソース状況を保存するサーバ情報保存部とを備えている構成である。
【0144】
本発明の態様11に係るコンテナシステムは、上記の態様10において、前記第1拠点装置は、前記第1拠点から前記第2拠点への通信時の第1ネットワーク状況を測定する第1ネットワーク状況測定部をさらに備えており、前記第1送信部は、測定された前記第1ネットワーク状況および受信された前記第1リソース状況を、前記サーバに送信し、前記第2拠点装置は、前記第2拠点から前記第1拠点への通信時の第2ネットワーク状況を測定する第2ネットワーク状況測定部をさらに備えており、前記第2送信部は、測定された前記第2ネットワーク状況および受信された前記第2リソース状況を、前記サーバに送信し、前記第1サーバ受信部は、前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を受信し、前記サーバ情報保存部は、受信された前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況を保存し、前記サーバは、コンテナオーケストレーションクラスタとしてのアプリケーションを構成する第1ポッドが要求するネットワークへの要求事項および前記第1ポッドが要求するリソースへの要求事項を受信する第2サーバ受信部と、保存された前記第1ネットワーク状況、前記第1リソース状況、前記第2ネットワーク状況、および前記第2リソース状況と、受信された前記ネットワークへの要求事項および前記リソースへの要求事項とに基づいて、前記第1ワーカノードおよび前記第2ワーカノードのうちいずれのワーカノードに前記第1ポッドを配置するかを決定する構成としてもよい。
【0145】
本発明の態様12に係るプログラムは、上記の態様1に係るポッド配置決定装置としてコンピュータを機能させるためのプログラムであって、前記測定部、前記保存部、前記第1受信部、前記第2受信部、および前記決定部としてコンピュータを機能させる構成である。
【0146】
〔実現例〕
第1拠点装置4の各機能ブロック(特に、第1ローカルMANO43および第1ローカルデータストア44)は、集積回路(ICチップ)等に形成された論理回路(ハードウェア)によって実現してもよいし、ソフトウェアによって実現してもよい。
【0147】
後者の場合、第1拠点装置4は、各機能を実現するソフトウェアであるプログラムの命令を実行するコンピュータを備えている。このコンピュータは、例えば1つ以上のプロセッサを備えていると共に、前記プログラムを記憶したコンピュータ読み取り可能な記録媒体を備えている。そして、前記コンピュータにおいて、前記プロセッサが前記プログラムを前記記録媒体から読み取って実行することにより、本発明の目的が達成される。
【0148】
前記プロセッサとしては、例えばCPU(Central Processing Unit)を用いることができる。前記記録媒体としては、「一時的でない有形の媒体」、例えば、ROM(Read Only Memory)等の他、テープ、ディスク、カード、半導体メモリ、プログラマブルな論理回路などを用いることができる。
【0149】
また、前記プログラムを展開するRAM(Random Access Memory)などをさらに備えていてもよい。また、前記プログラムは、該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して前記コンピュータに供給されてもよい。なお、本発明の一態様は、前記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【0150】
本発明は前述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態も、本発明の技術的範囲に含まれる。各実施形態にそれぞれ開示された技術的手段を組み合わせることによって、新しい技術的特徴を形成することもできる。
【符号の説明】
【0151】
1、1A コンテナシステム
2、2A 端末機器
3、3A クラウドサーバ
4 第1拠点装置
5 クラウドサーバ
6 第2拠点装置
21 プリファレンスリポジトリ
22 イメージリポジトリ
23 起動App
24 クライアントApp
31 グローバルMANO
32 グローバルデータストア
33 オリジンイメージリポジトリ
34 サーバApp
41 第1マスターノード
42 第1ネットワークモニタ
43 第1ローカルMANO
44 第1ローカルデータストア
45 第1ローカルイメージリポジトリ
46 API
51 第1リソースモニタ
52 第1ワーカノード
53 第4ワーカノード
61 第2マスターノード
62 第2ネットワークモニタ
63 第2ローカルMANO
64 第2ローカルデータストア
65 第2ローカルイメージリポジトリ
66 API
71 第2リソースモニタ
72 第2ワーカノード
73 第5ワーカノード
81 第1ポッド
82 第2ポッド
83 第3ポッド