JP2022092156A - アプリ間通信制御方法およびアプリ間通信制御プログラム - Google Patents

Abstract

【課題】オーケストレーションソフトにおいて、アプリに対するメッセージの転送要求が発生した際に、不要な通信を抑止する。
【解決手段】各ノードにアプリが分散配置され、各ノードが、メッセージの転送先となるノードを示す宛先情報を記憶した振り分けテーブルを備え、コンテナオーケストレーションソフトが、各ノードに配置されたアプリの情報に基づいて、振り分けテーブルを設定するシステムにおいて、通信制御サーバ１は、第１のノードの振り分けテーブルに、第１のノードを示す宛先情報と、第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、第２のノードを示す宛先情報を削除する。
【選択図】図４Ｄ

Description

本発明は、アプリ間通信制御方法などに関する。

コンテナのオーケストレーションを行うＯＳＳ（Open Source Software）がある。例えば、かかるＯＳＳには、一例として、ｋｕｂｅｒｎｅｔｅｓ（ｋ８ｓ）（登録商標）が挙げられる。コンテナオーケストレーションとは、コンテナの作成および削除、コンテナのクラスタ構成の管理、コンテナのオートスケール、コンテナのオートヒーリング、コンテナの配備先のスケジューリングなどの機能のことをいう。ｋ８ｓは、クラウドのコンテナサービスの基盤としても利用される。

ここで、ｋ８ｓの構成の参考例を、図１６を参照して説明する。図１６は、ｋ８ｓの構成の参考例を示す図である。図１６に示すように、ｋ８ｓは、Ｍａｓｔｅｒと、Ｗｏｒｋｅｒとを有する。Ｍａｓｔｅｒは、ｋ８ｓの制御を行うノードである。かかる制御には、ＡＰＩ（Application Programming Interface）、スケジューリングやＤＢ（DataBase）管理の制御がある。Ｗｏｒｋｅｒは、コンテナが実際に稼働するノードである。コンテナは、Ｐｏｄに内包される。Ｗｏｒｋｅｒは、Ｍａｓｔｅｒに定期的に問い合わせて、自身に配備されたコンテナの制御を行う。

図１７は、ｋ８ｓにおけるコンテナ宛て通信の仕組みの参考例を示す図である。図１７に示すように、Ｐｏｄは、ｋ８ｓ内で管理されるコンテナの構成単位である。Ｐｏｄ毎に、ＩＰアドレスが付与され、Ｐｏｄが配備されるＷｏｒｋｅｒ毎にサブネットが異なる。各Ｎｏｄｅ内のｋｕｂｅ－ｐｒｏｘｙが同じアプリが動くＰｏｄを纏めて管理し、サービス（アプリ）宛てのメッセージを各Ｐｏｄに振り分ける。すなわち、ｋｕｂｅ－ｐｒｏｘｙは、同じアプリが動く各ＰｏｄのＩＰアドレスを纏めて管理する振り分けテーブルを参照して、アプリ宛てのメッセージをいずれかのＰｏｄに振り分ける処理を行う。

特開２０２０－９６３５７号公報 特開２０２０－５２７３０号公報

しかしながら、ｋ８ｓのようなオーケストレーションソフトは、自ノードに配備されたＰｏｄにアプリを有していても、振り分けテーブルを参照して、他ノードに配備されたＰｏｄの同一アプリにメッセージを振り分けてしまう場合がある。かかる場合には、不要な通信が発生してしまうという問題がある。

１つの側面では、オーケストレーションソフトにおいて、アプリに対するメッセージの転送要求が発生した際に、不要な通信を抑止することを目的とする。

１つの態様では、アプリ間通信制御方法は、各ノードにアプリが分散配置され、前記各ノードが、メッセージの転送先となるノードを示す宛先情報を記憶した振り分けテーブルを備え、コンテナオーケストレーションソフトが、前記各ノードに配置されたアプリの情報に基づいて、前記振り分けテーブルを設定するシステムにおけるアプリ間通信制御方法であって、第１のノードの振り分けテーブルに、前記第１のノードを示す宛先情報と、前記第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、前記第２のノードを示す宛先情報を削除する、処理をコンピュータが実行する。

１つの態様によれば、オーケストレーションソフトにおいて、アプリに対するメッセージの転送要求が発生した際に、不要な通信を抑止することが可能となる。

図１は、実施例１に係るシステムの構成を示す機能ブロック図である。 図２は、実施例１に係る通信制御サーバの構成を示す機能ブロック図である。 図３は、振り分けテーブル情報のデータ構造の一例を示す図である。 図４Ａは、実施例１に係る振り分けテーブル設定処理の一例を示す図（１）である。 図４Ｂは、実施例１に係る振り分けテーブル設定処理の一例を示す図（２）である。 図４Ｃは、実施例１に係る振り分けテーブル設定処理の一例を示す図（３）である。 図４Ｄは、実施例１に係る振り分けテーブル設定処理の一例を示す図（４）である。 図４Ｅは、実施例１に係る振り分けテーブル設定処理の一例を示す図（５）である。 図５は、実施例１に係る振り分けテーブル設定処理のフローチャートの一例を示す図である。 図６は、実施例２に係るシステムの構成を示す機能ブロック図である。 図７は、実施例２に係る通信制御サーバの構成を示す機能ブロック図である。 図８は、Ｐｏｄ性能情報のデータ構造の一例を示す図である。 図９は、Ｐｏｄ配備情報のデータ構造の一例を示す図である。 図１０は、実施例２に係るコンテナ増減処理のフローチャートの一例を示す図（１）である。 図１１は、実施例２に係るコンテナ増減処理のフローチャートの一例を示す図（２）である。 図１２は、実施例２に係るコンテナ増減処理のフローチャートの一例を示す図（３）である。 図１３は、実施例２に係るＰｏｄ配備情報収集処理のフローチャートの一例を示す図である。 図１４は、実施例２に係るＰｏｄ性能情報収集処理のフローチャートの一例を示す図である。 図１５は、アプリ間通信制御プログラムを実行するコンピュータの一例を示す図である。 図１６は、ｋ８ｓの構成の参考例を示す図である。 図１７は、ｋ８ｓにおけるコンテナ宛て通信の仕組みの参考例を示す図である。 図１８は、複数環境に跨ったｋ８ｓ適用時における問題を説明する図である。 図１９は、ｋ８ｓクラスタを分離させる場合の参考例を示す図である。 図２０は、ｋ８ｓクラスタを分離させる場合の問題を説明する図である。

以下に、本願の開示するアプリ間通信制御方法およびアプリ間通信制御プログラムの実施例を図面に基づいて詳細に説明する。なお、実施例によりこの発明が限定されるものではない。

まず、コンテナのオーケストレーションソフトを適用時における問題を説明する。なお、以降では、コンテナのオーケストレーションソフトをｋｕｂｅｒｎｅｔｅｓ（ｋ８ｓ）として説明する。ｋ８ｓは、各ノードの振り分けテーブルを自動設定する。振り分けテーブルは、クラスタの中のコンテナ化されたアプリが動くＰｏｄのＩＰアドレスを管理するためのテーブルであり、同じアプリが動く各ＰｏｄのＩＰアドレスを纏めて管理する。振り分けテーブルは、各Ｗｏｒｋｅｒに持つ。これにより、ｋ８ｓは、自ノードがアプリを有している場合であっても、他ノードの有する同一アプリへメッセージを振り分けて（転送）してしまい、不要な通信が発生してしまう場合がある。アプリを有するノードとして、クラウドのほか、エッジデバイス、エッジサーバやオンプレミスなどが挙げられる。

ここで、各環境（ノード）でアプリの配備構成が異なる場合がある。かかる場合には、適切な環境上のアプリにアクセスできるように制御する必要がある。図１８は、複数環境に跨ったｋ８ｓ適用時における問題を説明する図である。図１８には、ｋ８ｓのクラスタが構築されている。かかるクラスタには、稼働するアプリが異なるノードとして、エッジデバイスａと、エッジデバイスｂとが適用されている。エッジデバイスａと、エッジデバイスｂには、それぞれ、Ｗｏｒｋｅｒが備わっている。また、クラウドには、ｋ８ｓの制御を行うＭａｓｔｅｒおよびＷｏｒｋｅｒが備わっている。

例えば、通信の流れがアプリＡ→アプリＢ→アプリＣであるとする。エッジデバイスａ上のＷｏｒｋｅｒには、コンテナ化されたアプリＡがＰｏｄに配備されている。エッジデバイスｂ上のＷｏｒｋｅｒには、コンテナ化されたアプリＡ、アプリＢ、アプリＣがそれぞれのＰｏｄに配備されている。クラウド上のＷｏｒｋｅｒには、コンテナ化されたアプリＡ、アプリＣがそれぞれのＰｏｄに配備されている。ｋ８ｓクラスタ内に同じアプリが複数存在すれば、ｋ８ｓが自動的に振り分けテーブルを作成し、Ｗｏｒｋｅｒが振り分けテーブルを参照してメッセージを配信する（振り分ける）アプリの宛先をランダムに決定する。図１８の例では、アプリＢは、エッジデバイスｂおよびクラウドに存在する。ｋ８ｓは、エッジデバイスｂの振り分けテーブルにクラウドのアプリＢの宛先（ＰｏｄのＩＰアドレス）を自動的に登録する。この結果、ｋ８ｓは、エッジデバイスｂがアプリＢを有している場合であっても、他ノードであるクラウド上の同一アプリＢの宛先をランダムに決定し、決定したアプリＢへメッセージを配信してしまい、不要な通信が発生してしまうという問題がある。

かかる問題に対して、アプリの配備構成が同じエッジデバイス毎にｋ８ｓクラスタを分離させることが考えられる。図１９は、ｋ８ｓクラスタを分離させる場合の参考例を示す図である。なお、図１９に示す振り分けテーブルは、説明の便宜上、アプリＢについてのみ記載されている。図１９に示すように、アプリＡが配備されたエッジデバイスａを１つのｋ８ｓクラスタ＃１に含める。ｋ８ｓクラスタ＃１は、クラウド上にＭａｓｔｅｒを有するとともにＷｏｒｋｅｒにアプリＢおよびアプリＣを配備する。また、アプリＡ、アプリＢ、アプリＣが配備されたエッジデバイスｂを１つのｋ８ｓクラスタ＃２に含める。ｋ８ｓクラスタ＃２は、クラウド上にＭａｓｔｅｒを有するがＷｏｒｋｅｒを有しない。これにより、アプリの配備構成が同じエッジデバイス毎にｋ８ｓクラスタを分けることで、アプリ間の最適な通信を実現することができる。

ところが、アプリの配備構成が同じエッジデバイス毎にｋ８ｓクラスタを分離させるようにすると、クラウド側の利用コストが大きくなる。図２０は、ｋ８ｓクラスタを分離させる場合の問題を説明する図である。図２０では、エッジデバイスが車両である場合について説明する。図２０に示すように、管理するエッジデバイスが例えば５００万台である場合には、アプリの配備構成が同じエッジデバイス毎にｋ８ｓクラスタを分離させようとすると、上段のアプリの配備構成では、エッジデバイスが例えば２５０万台に対し、ｋ８ｓクラスタの数は、例えば１万個となる。下段のアプリの配置構成では、エッジデバイスが例えば２５０万台に対し、ｋ８ｓクラスタの数は、例えば１万個となる。パブリッククラウドのマネージドｋ８ｓを利用する場合、コンテナが稼働するＷｏｒｋｅｒノード以外に、ｋ８ｓクラスタ単位でＭａｓｔｅｒノードに課金が発生してしまう。例えば、上段のように、クラウド側でＰｏｄが構築されない場合でも、エッジデバイスのＷｏｒｋｅｒを管理するためだけにＭａｓｔｅｒが構築されるため、無駄なコストがかかってしまう。特に、大規模なｋ８ｓクラスタが構築される場合には、クラウド側の利用コストが大きくなってしまう。

そこで、以降の実施例では、ｋ８ｓにおいて、アプリの配備構成が同じエッジデバイス毎にクラスタを分けないで、アプリ間通信の不要な通信を抑止する方法について説明する。

［システムの構成］
図１は、実施例１に係るシステムの構成を示す機能ブロック図である。実施例１に係るシステム９は、通信制御サーバ１、エッジデバイス３およびマネージドｋ８ｓ５を有する。通信制御サーバ１およびマネージドｋ８ｓ５は、クラウド上に有する。エッジデバイス３に、コンテナ化されたアプリが配備されている場合には、振り分けテーブル３１が設定されている。マネージドｋ８ｓ５は、コンテナ化されたアプリが配備されている場合には、振り分けテーブル５１が設定されている。なお、システム９では、２個のｋ８ｓクラスタが存在しているが、１個のｋ８ｓクラスタが存在しても良いし、２個以上のｋ８ｓクラスタが存在しても良い。

通信制御サーバ１は、第１のノードの振り分けテーブル３１に設定されているアプリの宛先情報として、第１のノードを示す宛先情報と、第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、第２のノードを示す宛先情報を削除する。これにより、ｋ８ｓは、第１のノードに対象のアプリが配備されている場合には第１のノードを示す宛先を決定するので、不要な通信を抑止できる。

［通信制御サーバの構成］
実施例１に係る通信制御サーバ１の構成を、図２を参照して説明する。図２は、実施例１に係る通信制御サーバの構成を示す機能ブロック図である。図２に示すように、通信制御サーバ１は、振り分けルール実行部１１および振り分けテーブル設定部１２を有する。また、通信制御サーバ１は、Ｗｏｒｋｅｒ単位の振り分けテーブル情報２１を有する。

振り分けテーブル情報２１は、クラスタにおいて、コンテナ化されたアプリが動くＰｏｄの位置情報（ＩＰアドレス）を管理し、同じアプリが動く各ＰｏｄのＩＰアドレスを纏めて管理するための情報である。振り分けテーブル情報２１は、Ｗｏｒｋｅｒ毎の振り分けテーブルの情報である。

ここで、振り分けテーブル情報２１のデータ構造を、図３を参照して説明する。図３は、振り分けテーブル情報のデータ構造の一例を示す図である。図３に示すように、振り分けテーブル情報２１内のＷｏｒｋｅｒ単位の振り分けテーブルは、ＳｅｒｖｉｃｅとＰｏｄ ＩＰとを対応付けて記憶する。Ｓｅｒｖｉｃｅは、アプリで実行されるサービスの名称である。Ｐｏｄ ＩＰは、アプリが動くＰｏｄのＩＰアドレスである。

一例として、あるＷｏｒｋｅｒの振り分けテーブルについて、Ｓｅｒｖｉｃｅが「ａｐｐｂ－ｓｖｃ」である場合に、Ｐｏｄ ＩＰとして「１０．０．０．２」と記憶している。Ｓｅｒｖｉｃｅが「ａｐｐｃ－ｓｖｃ」である場合に、Ｐｏｄ ＩＰとして「１０．０．０．３」と記憶している。

振り分けルール実行部１１は、ｋ８ｓクラスタ内の各Ｗｏｒｋｅｒに対して、各アプリへメッセージを振り分ける際にアプリの宛先を指定するための振り分けルールを実行する。例えば、振り分けルール実行部１１は、ｋ８ｓクラスタ内のＷｏｒｋｅｒを順次選択する。振り分けルール実行部１１は、選択したＷｏｒｋｅｒ上にアプリが動作するＰｏｄが存在する場合には、振り分けテーブル情報２１に、アプリの宛先として当該Ｗｏｒｋｅｒ上のＰｏｄのＩＰアドレスを更新する。また、振り分けルール実行部１１は、選択したＷｏｒｋｅｒ上にアプリが動作するＰｏｄが存在しない場合には、当該Ｗｏｒｋｅｒがエッジデバイスであれば、振り分けテーブル情報２１に、アプリの宛先としてクラウド上のＰｏｄのＩＰアドレスを更新する。

なお、振り分けルール実行部１１は、エッジデバイスのＷｏｒｋｅｒ上にアプリが動作するＰｏｄが存在する場合には、振り分けテーブル情報２１に、このアプリの宛先として当該Ｗｏｒｋｅｒ上のＰｏｄのＩＰアドレスを更新すると説明した。そして、振り分けルール実行部１１は、エッジデバイスのＷｏｒｋｅｒ上にこのアプリが動作するＰｏｄが存在しない場合には、クラスタ上のＰｏｄのＩＰアドレスを更新すると説明した。しかしながら、振り分けルール実行部１１は、これに限定されず、ｋ８ｓの従来技術により振り分けテーブル情報２１を設定し、振り分けテーブル情報２１に含まれる対象のノードの振り分けテーブルにアプリの宛先としてこのノードを示す宛先と他のノードを示す宛先が設定されている場合には、対象のノードを優先して、他のノードを示す宛先を削除するようにしても良い。また、振り分けルール実行部１１は、振り分けテーブル情報２１に含まれる対象のノードの振り分けテーブルにアプリの宛先としてクラウドを示す宛先と、対象のノードと異なる他のノードを示す宛先が設定されている場合に、クラウドを優先して、他のノードを示す宛先を削除するようにしても良い。また、振り分けルール実行部１１は、クラウドのＷｏｒｋｅｒノードの振り分けテーブルには、クラウド内に配備されたＰｏｄの宛先のみを登録すれば良い。

振り分けテーブル設定部１２は、ｋ８ｓクラスタ内の各Ｗｏｒｋｅｒに対して、振り分けテーブル情報２１への更新を反映する。例えば、振り分けテーブル設定部１２は、振り分けテーブル情報２１を参照して、選択したＷｏｒｋｅｒに関し、既存の振り分けテーブルに変更がある場合には、選択したＷｏｒｋｅｒ上の振り分けテーブル３１、５１に更新を反映する。

［振り分けテーブル設定処理の一例］
図４Ａ～図４Ｅは、実施例１に係る振り分けテーブル設定処理の一例を示す図である。

図４Ａでは、初期状態として、エッジデバイスｂのみがｋ８ｓクラスタ内のＷｏｒｋｅｒノードとして管理されているとする。振り分けルール実行部１１は、ｋ８ｓにより、アプリについてＰｏｄのＩＰアドレスを振り分けテーブル情報２１に更新する。なお、図４Ａで示す振り分けテーブルは、振り分けテーブル情報２１に含まれるエッジデバイスｂのＷｏｒｋｅｒ用の振り分けテーブルであるとする。以降、図４Ｂ～図４Ｅで示す振り分けテーブルも、振り分けテーブル情報２１の中のそれぞれのＷｏｒｋｅｒ用の振り分けテーブルであるとする。ここでは、エッジデバイスｂのＷｏｒｋｅｒ用の振り分けテーブルには、アプリＡ、アプリＢ、アプリＣについて、エッジデバイスｂ上のＰｏｄのＩＰアドレスが設定されている。

図４Ｂでは、エッジデバイスａが追加直後の状態である。振り分けルール実行部１１は、ｋ８ｓにより、アプリについてＰｏｄのＩＰアドレスを振り分けテーブル情報２１に更新する。ここでは、エッジデバイスａのＷｏｒｋｅｒ用の振り分けテーブルには、ｋ８ｓによりエッジデバイスｂ上のＰｏｄが振り分け先として設定されている。

図４Ｃでは、エッジデバイスａおよびクラウド上にＰｏｄが配備された状態である。エッジデバイスａには、アプリＡのＰｏｄのみが配備されている。クラウド上には、アプリＢのＰｏｄおよびアプリＣのＰｏｄがそれぞれ配備されている。振り分けルール実行部１１は、新たなＰｏｄが配備され、ｋ８ｓにより、各Ｗｏｒｋｅｒ上の振り分けテーブルのＰｏｄの宛先に全Ｐｏｄの情報を設定する。ここでは、エッジデバイスａのＷｏｒｋｅｒ用の振り分けテーブルには、自身のＷｏｒｋｅｒに配備されたアプリＡのＰｏｄのＩＰアドレス（１０．０．１．１）の他、クラウド上のＷｏｒｋｅｒに配備されたアプリＢのＰｏｄのＩＰアドレス（１０．０．０．２）およびアプリＣのＰｏｄのＩＰアドレス（１０．０．０．３）が追加される。すなわち、エッジデバイスａのＷｏｒｋｅｒ用の振り分けテーブルには、ｋ８ｓクラスタ内の全ＰｏｄのＩＰアドレスの情報が設定される。同様に、クラウド上のＷｏｒｋｅｒ用の振り分けテーブルにも、ｋ８ｓクラスタ内の全ＰｏｄのＩＰアドレスの情報が設定される。同様に、エッジデバイスｂのＷｏｒｋｅｒ用の振り分けテーブルにも、ｋ８ｓクラスタ内の全ＰｏｄのＩＰアドレスの情報が設定される。

図４Ｄでは、各Ｗｏｒｋｅｒ上の振り分けテーブルが、以下のように更新される。振り分けルール実行部１１は、振り分けテーブル情報２１に含まれる振り分けテーブルにアプリの宛先として自身のノードを示す宛先と他のノードを示す宛先が設定されている場合には、他のノードを示す宛先を削除する。

ここでは、エッジデバイスａでは、振り分けルール実行部１１は、アプリＡについて、振り分けテーブルに宛先として自身のノードを示す宛先と他のノードを示す宛先が設定されているので、他のノードを示す宛先（１０．０．１．９）を削除する。また、振り分けルール実行部１１は、アプリＢ、アプリＣについて、振り分けテーブルに宛先として自身のノードを示す宛先が設定されていないので、クラウド上のノードを示す宛先を残し、他のノードを示す宛先（１０．０．１．１０）、（１０．０．１．１１）を削除する。つまり、アプリＡは、自身のエッジデバイスａのＷｏｒｋｅｒ上で稼働するＰｏｄを宛先とし、アプリＢおよびアプリＣは、クラウド上のＰｏｄを宛先とする。

エッジデバイスｂでは、振り分けルール実行部１１は、アプリＡ，Ｂ，Ｃについて、振り分けテーブルに宛先として自身のノードを示す宛先と他のノードを示す宛先が設定されているので、他のノードを示す宛先を削除する。つまり、アプリＡ，Ｂ，Ｃは、自身のエッジデバイスｂのＷｏｒｋｅｒ上で稼働するＰｏｄを宛先とする。

クラウドでは、振り分けルール実行部１１は、アプリＢ，Ｃについて、振り分けテーブルに宛先として自身のノードを示す宛先と他のノードを示す宛先が設定されているので、他のノードを示す宛先（１０．０．１．１０）、（１０．０．１．１１）を削除する。また、振り分けルール実行部１１は、アプリＡについて、振り分けテーブルに宛先として自身のノードを示す宛先が設定されていないので、他のノードを示す宛先（１０．０．１．９）、（１０．０．１．１）を削除する。つまり、アプリＢ，Ｃは、自身のクラスタのＷｏｒｋｅｒ上で稼働するＰｏｄを宛先とする。アプリＡは、クラウド上にＰｏｄが配備されていないので、宛先として削除される。

図４Ｅに示すように、各Ｗｏｒｋｅｒ上の更新された振り分けテーブルが、表わされている。振り分けテーブル設定部１２は、ｋ８ｓクラスタ内の各Ｗｏｒｋｅｒに対して、振り分けテーブル情報２１への更新を反映する。エッジデバイスｂでは、ｋ８ｓは、振り分けテーブル３１を参照して、メッセージを配信する、アプリＡ，Ｂ，Ｃの宛先を、エッジデバイスｂ上の宛先に決定する。エッジデバイスａでは、ｋ８ｓは、振り分けテーブル３１を参照して、メッセージを配信する、アプリＡの宛先を、エッジデバイスａ上の宛先に決定する。また、ｋ８ｓは、振り分けテーブル３１を参照して、メッセージを配信する、アプリＢ，Ｃの宛先を、クラウド上の宛先に決定する。

これにより、通信制御サーバ１は、エッジデバイス毎に振り分けルールに基づいて振り分けテーブル３１を制御することで、通信の最適化を実現できる。すなわち、通信制御サーバ１は、不要な通信を抑止することが可能となる。例えばエッジデバイスｂは、ｋ８ｓがアプリＢの宛先として設定したクラウドのＰｏｄ ＩＤが削除されることで、デバイス間の通信が必要ない自装置内のアプリＢを宛先とすることが可能となる。そして、通信制御サーバ１は、ｋ８ｓクラスタ内でＰｏｄの構成が異なるエッジデバイスを管理することにより、ｋ８ｓクラスタ数を減らし、クラウドの利用コストを抑制することが可能となる。

また、クラウドシステムでは、セキュリティの観点で、エッジデバイス間のクラウドを経由した通信を禁止していることがある。この場合、図４Ｃのようにｋ８ｓがエッジデバイスｂの振り分けテーブル３１にエッジデバイスａのＰｏｄを示す宛先（１０．０．１．１）を追加すると、エッジデバイスｂにおいてアプリＡへの通信が発生した際に、エッジデバイスａのアプリＡにメッセージが送信されることが発生する。しかし、エッジデバイスｂからエッジデバイスａへの通信は禁止されているため、当該メッセージがエッジデバイスａへ送達されることはない。仮に送達された場合、再送する等の無駄な処理を行う必要が生じるが、上述のような削除処理を実行することで、このような無駄な処理を抑止することが可能となる。

なお、ｋ８ｓは、デバイスの負荷に応じてＰｏｄを他のデバイスに複製することで、負荷分散を実現する機能（オートスケーリング機能）を有する。この機能は、有効／無効をシステムの管理者が設定することが可能となっている。ここで、オートスケーリング機能が有効となっているシステムにおいて、ｋ８ｓが例えばエッジデバイスｂの負荷が高くなったことを検知して、アプリＢのＰｏｄをクラウド上に複製することがある。この複製処理に伴って、ｋ８ｓはエッジデバイスｂの振り分けテーブル３１に、クラウドに複製されたＰｏｄを示す宛先を追加する。これにより、エッジデバイスｂのアプリＡからのメッセージは、エッジデバイスｂ上のアプリＡとクラウド上のアプリＡの二つに振り分けられるため、エッジデバイスｂの負荷分散が実現される。

しかし、上述のような削除処理を実行した場合、負荷分散のためにエッジデバイスｂの振り分けテーブル３１に追加されたクラウドのＰｏｄを示す宛先が削除されてしまい、負荷分散効果が得られなくなることが考えられる。

このような状況が生じることを防ぐため、オートスケーリング機能の設定が有効になっているか無効になっているかを判断し、無効となっていると判断された場合に、上述の削除処理を実行することが考えられる。すなわち、このような判断を行うことで、オートスケーリング機能を使用していないシステムでのみ、削除処理を行うように制御することが可能となる。

［振り分けテーブル設定処理のフローチャート］
図５は、実施例１に係る振り分けテーブル設定処理のフローチャートの一例を示す図である。なお、図５では、ｋ８ｓが設定した振り分けテーブル情報２１から不要な通信が発生する設定を削除する処理について説明する。図５に示すように、振り分けルール実行部１１は、振り分けテーブル情報２１に設定するアプリの設定依頼を受信する（ステップＳ１１）。振り分けルール実行部１１は、全Ｗｏｒｋｅｒの探索を完了したか否かを判定する（ステップＳ１２）。全Ｗｏｒｋｅｒの探索を完了したと判定した場合には（ステップＳ１２；Ｙｅｓ）、振り分けルール実行部１１は、振り分けテーブル設定処理を終了する。

一方、全Ｗｏｒｋｅｒの探索を完了していないと判定した場合には（ステップＳ１２；Ｎｏ）、振り分けルール実行部１１は、Ｗｏｒｋｅｒを選択する（ステップＳ１２Ａ）。振り分けルール実行部１１は、選択したＷｏｒｋｅｒ上にアプリが存在するか否かを判定する（ステップＳ１３）。選択したＷｏｒｋｅｒ上にアプリが存在しないと判定した場合には（ステップＳ１３；Ｎｏ）、振り分けルール実行部１１は、次のＷｏｒｋｅｒを探索すべく、ステップＳ１２に移行する。

一方、選択したＷｏｒｋｅｒ上にアプリが存在すると判定した場合には（ステップＳ１３；Ｙｅｓ）、振り分けルール実行部１１は、ｋ８ｓクラスタ上の設定アプリの探索を完了するか否かを判定する（ステップＳ１４）。設定アプリの探索を完了しないと判定した場合には（ステップＳ１４；Ｎｏ）、振り分けルール実行部１１は、選択したＷｏｒｋｅｒ上に設定アプリのＰｏｄが存在するか否かを判定する（ステップＳ１６）。

選択したＷｏｒｋｅｒ上に設定アプリのＰｏｄが存在すると判定した場合には（ステップＳ１６；Ｙｅｓ）、振り分けルール実行部１１は、振り分けテーブル情報２１に対して、アプリの宛先として選択したＷｏｒｋｅｒ上のＰｏｄのＩＰアドレスを指定する（ステップＳ１７）。すなわち、振り分けルール実行部１１は、振り分けテーブル情報２１に含まれる選択Ｗｏｒｋｅｒの振り分けテーブルに他のＷｏｒｋｅｒを示すＩＰアドレスが設定されている場合には、選択Ｗｏｒｋｅｒを優先して、他のＷｏｒｋｅｒを示すＩＰアドレスを削除する。そして、振り分けルール実行部１１は、設定アプリの次の探索をすべく、ステップＳ１４に移行する。

選択したＷｏｒｋｅｒ上に設定アプリのＰｏｄが存在しないと判定した場合には（ステップＳ１６；Ｎｏ）、振り分けルール実行部１１は、選択したＷｏｒｋｅｒがエッジデバイスまたはオンプレ上で稼働しているか否かを判定する（ステップＳ１８）。選択したＷｏｒｋｅｒがエッジデバイスまたはオンプレ上で稼働していると判定した場合には（ステップＳ１８；Ｙｅｓ）、振り分けルール実行部１１は、振り分けテーブル情報２１に対して、アプリの宛先としてクラウド上のＰｏｄのＩＰアドレスを指定する（ステップＳ１９）。すなわち、振り分けルール実行部１１は、振り分けテーブル情報２１に含まれる選択Ｗｏｒｋｅｒと異なる他のＷｏｒｋｅｒを示すＩＰアドレスが設定されている場合には、クラウドを優先して、他のＷｏｒｋｅｒを示すＩＰアドレスを削除する。そして、振り分けルール実行部１１は、設定アプリの次の探索をすべく、ステップＳ１４に移行する。

選択したＷｏｒｋｅｒがエッジデバイスまたはオンプレ上で稼働していないと判定した場合には（ステップＳ１８；Ｎｏ）、振り分けルール実行部１１は、以下の処理を行う。すなわち、振り分けルール実行部１１は、選択したＷｏｒｋｅｒがクラウド上で稼働しているので、アプリの宛先を未指定とする（ステップＳ２０）。そして、振り分けルール実行部１１は、設定アプリの次の探索をすべく、ステップＳ１４に移行する。

ステップＳ１４において、設定アプリの探索を完了したと判定した場合には（ステップＳ１４；Ｙｅｓ）、振り分けテーブル設定部１２は、選択したＷｏｒｋｅｒについて、既存の振り分けテーブル３１に変更が有るか否かを判定する（ステップＳ２１）。既存の振り分けテーブル３１に変更が有ると判定した場合には（ステップＳ２１；Ｙｅｓ）、振り分けテーブル設定部１２は、選択したＷｏｒｋｅｒ上の振り分けテーブル３１に設定を反映する（ステップＳ２２）。そして、振り分けテーブル設定部１２は、次のＷｏｒｋｅｒを選択すべく、ステップＳ１２に移行する。

一方、既存の振り分けテーブル３１に変更が無いと判定した場合には（ステップＳ２１；Ｎｏ）、振り分けテーブル設定部１２は、何もしないで、次のＷｏｒｋｅｒを選択すべく、ステップＳ１２に移行する。

［実施例１の効果］
このようにして、上記実施例１では、コンテナオーケストレーションソフトが、各ノードに配置されたアプリの情報に基づいて、振り分けテーブル３１を設定する。振り分けルール実行部１１は、第１のノードの振り分けテーブルに、第１のノードを示す宛先情報と、第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、第２のノードを示す宛先情報を削除する。かかる構成によれば、振り分けルール実行部１１は、第１のノードに対してメッセージの第１のアプリへの転送の依頼を受け取ると、振り分けテーブル３１を参照して第１のノードを示す宛先情報の第１のアプリへメッセージを転送することで不要な通信を抑止できる。言い換えれば、振り分けルール実行部１１は、第２のノードを示す宛先情報を削除することで、第１のノードを示す宛先情報を利用することとなり、第１のノードと異なる第２のノードを示す宛先情報を利用した場合の不要な通信を抑止することが可能となる。

また、上記実施例１では、振り分けルール実行部１１は、コンテナオーケストレーションソフトにおいて、オートスケーリング機能が無効と設定されている場合に、第２のノードを示す宛先情報を削除する。かかる構成によれば、振り分けルール実行部１１は、オートスケーリング機能を使用していないシステムでのみ、削除処理を行うように制御することが可能となる。

また、上記実施例１では、振り分けルール実行部１１は、第１のノードの振り分けテーブルに、クラウドを示す宛先情報と、第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、第２のノードを示す宛先情報を削除する。かかる構成によれば、振り分けルール実行部１１は、第１のノードに対してメッセージの第１のアプリへの転送の依頼を受け取ると、第１のアプリが第１のノードになくても、クラウド上の第１のアプリへメッセージを転送することで、不要な通信を抑止できる。

ところで、実施例１では、振り分けルール実行部１１は、第１のノードの振り分けテーブル３１に、第１のアプリの宛先情報として、第１のノードを示す宛先情報と、第２のノードを示す宛先情報が設定されている場合、第２のノードを示す宛先情報を削除する。実施例２では、これに限定されず、さらに、Ｗｏｒｋｅｒ上のアプリが動作するＰｏｄのリソースの負荷に応じて、Ｐｏｄの配備を増減するようにしても良い。これにより、アプリ間の通信遅延を抑制することができる。なお、以降、Ｐｏｄの配備の増減は、Ｐｏｄに内包されるコンテナの配備の増減という場合がある。

そこで、実施例２に係る通信制御サーバ１は、Ｗｏｒｋｅｒ上のアプリが動作するＰｏｄのリソースの負荷に応じて、Ｐｏｄの配備を増減する場合を説明する。なお、実施例２では、高負荷とは、リソースの使用率が第１の割合を超える場合のことをいい、第１の割合は、変更することができる。ここでいう低負荷とは、リソースの使用率が、第１の割合より小さい第２の割合を超えない場合のことをいい、第２の割合は、変更することができる。

［システムの構成］
図６は、実施例２に係るシステムの構成を示す機能ブロック図である。なお、実施例１の図１に示すシステム９と同一の構成については同一符号を付すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、通信制御サーバ１を通信制御サーバ１Ａに変更した点である。また、実施例１と実施例２とが異なるところは、クラスタ内のマネージドｋ８ｓ５に監視ツール５２を追加した点である。

監視ツール５２は、ｋ８ｓクラスタ内のＰｏｄを監視し、性能情報などを収集する。監視ツール５２には、一例として、プロメテウス（Prometheus（登録商標））などが挙げられるが、これに限定されない。

［通信制御サーバの構成］
図７は、実施例２に係る通信制御サーバの構成を示す機能ブロック図である。なお、実施例１の図２に示す通信制御サーバ１と同一の構成については同一符号を付すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、振り分けルール実行部１１を振り分けルール実行部１１Ａに変更した点である。また、実施例１と実施例２とが異なるところは、Ｐｏｄ性能情報収集部１３、Ｐｏｄ配備情報収集部１４、Ｐｏｄ配備制御部１５を追加した点である。また、実施例１と実施例２とが異なるところは、Ｐｏｄ性能情報２２、Ｐｏｄ配備情報２３を追加した点である。

Ｐｏｄ性能情報２２は、Ｐｏｄ毎の性能情報である。性能情報には、ＣＰＵやメモリなどのリソースの使用率が挙げられる。なお、Ｐｏｄ性能情報２２は、例えば、Ｐｏｄ性能情報収集部１３によって定期的に登録される。

ここで、Ｐｏｄ性能情報２２のデータ構造を、図８を参照して説明する。図８は、Ｐｏｄ性能情報のデータ構造の一例を示す図である。図８に示すように、Ｐｏｄ性能情報２２は、Ｐｏｄ名、ＣＰＵ使用率およびＭｅｍ使用率を対応付けた情報である。Ｐｏｄ名は、Ｐｏｄを一意に識別できる名称である。ＣＰＵ使用率は、リソースの１つとしてのＣＰＵを使用している割合であり、ＣＰＵの性能情報を示す。Ｍｅｍ使用率は、リソースの１つとしてのメモリを使用している割合であり、メモリの性能情報を示す。一例として、Ｐｏｄ名が「Ａｐｐ Ａ１」である場合、ＣＰＵ使用率として「１０％」、Ｍｅｍ使用率として「３０％」を記憶している。

図７に戻って、Ｐｏｄ配備情報２３は、Ｐｏｄの配備情報である。なお、Ｐｏｄ配備情報２３は、例えば、Ｐｏｄ配備情報収集部１４によって定期的に登録される。

ここで、Ｐｏｄ配備情報２３のデータ構造を、図９を参照して説明する。図９は、Ｐｏｄ配備情報のデータ構造の一例を示す図である。図９に示すように、Ｐｏｄ配備情報２３は、Ｐｏｄ名、ＷｏｒｋｅｒノードおよびＩＰを対応付けた情報である。Ｐｏｄ名は、Ｐｏｄを一意に識別できる名称である。Ｗｏｒｋｅｒノードは、Ｗｏｒｋｅｒを識別する情報である。ＩＰは、ＩＰアドレスを示す。一例として、Ｐｏｄ名が「Ａｐｐ Ａ１」である場合、Ｗｏｒｋｅｒノードとして「エッジデバイス＃１」、ＩＰとして「１０．０．１．１０／２９」と記憶している。

図７に戻って、振り分けルール実行部１１Ａは、ｋ８ｓクラスタ内の各Ｗｏｒｋｅｒに対して、振り分けテーブルを設定するために振り分けルールを実行する。例えば、振り分けルール実行部１１Ａは、アプリの初期配備時に、Ｗｏｒｋｅｒ毎に、以下の処理を行う。振り分けルール実行部１１Ａは、対象のＷｏｒｋｅｒ上にアプリが動作するＰｏｄが存在する場合には、振り分けテーブル情報２１に、アプリの宛先として当該Ｗｏｒｋｅｒ上のＰｏｄのＩＰアドレスを更新する。また、振り分けルール実行部１１Ａは、対象のＷｏｒｋｅｒ上にアプリが動作するＰｏｄが存在しない場合には、対象のＷｏｒｋｅｒがエッジデバイスであれば、振り分けテーブル情報２１に、アプリの宛先としてクラウド上のＰｏｄのＩＰアドレスを更新する。つまり、振り分けルール実行部１１Ａは、ｋ８ｓの従来技術により振り分けテーブル情報２１を設定し、振り分けテーブル情報２１に含まれる対象のノードの振り分けテーブルにアプリの宛先としてこのノードを示す宛先と他のノードを示す宛先が設定されている場合には、他のノードを示す宛先を削除する。

また、振り分けルール実行部１１Ａは、Ｗｏｒｋｅｒ毎に、Ｐｏｄ性能情報２２に基づいてコンテナ（Ｐｏｄ）の増減処理を実行し、振り分けテーブルを設定するために振り分けルールを実行する。なお、コンテナ増減処理は、例えば、定期的に実行されれば良い。

例えば、振り分けルール実行部１１Ａは、Ｗｏｒｋｅｒ毎に、以下の処理を行う。

一例として、振り分けルール実行部１１Ａは、対象のＷｏｒｋｅｒがエッジデバイス３上で実行されている場合には、以下の処理を行う。振り分けルール実行部１１Ａは、Ｐｏｄ性能情報２２を参照して、エッジデバイス３上のアプリのＰｏｄのリソースの使用率が高負荷になった場合には、クラウド上の同一アプリのコンテナリソースを利用するようにする。一例として、振り分けルール実行部１１Ａは、クラウド上に対象のアプリのＰｏｄが存在する場合には、振り分けテーブル情報２１に、対象のアプリの宛先として、実行中のＷｏｒｋｅｒ上のＰｏｄとクラウド上のＰｏｄのＩＰアドレスを指定する。振り分けルール実行部１１Ａは、クラウド上に対象のアプリのＰｏｄが存在しない場合には、クラウド上に対象のアプリのＰｏｄを配備（構築）するようにＰｏｄ配備制御部１５に指示する。これは、アプリの性能を向上させるためである。性能を向上させるためにＰｏｄの台数を増やすことを「スケールアウト」という。そして、振り分けルール実行部１１Ａは、振り分けテーブル情報２１に、対象のアプリの宛先として、実行中のＷｏｒｋｅｒ上のＰｏｄとクラウド上のＰｏｄのＩＰアドレスを指定する。

なお、対象のアプリの通信先のアプリが存在する場合には、振り分けルール実行部１１Ａは、以下の処理を行なえば良い。すなわち、振り分けルール実行部１１Ａは、クラウド上に対象のアプリのＰｏｄおよび通信先のアプリのＰｏｄが存在する場合には、振り分けテーブル情報２１に、対象のアプリおよび通信先のアプリの宛先として、実行中のＷｏｒｋｅｒ上のＰｏｄとクラウド上のＰｏｄのＩＰアドレスを指定すれば良い。振り分けルール実行部１１Ａは、クラウド上に対象のアプリのＰｏｄおよび通信先のアプリのＰｏｄが存在しない場合には、クラウド上に対象のアプリのＰｏｄおよび通信先のアプリのＰｏｄを配備（構築）するようにＰｏｄ配備制御部１５に指示する。すなわち、振り分けルール実行部１１Ａは、対象のアプリのＰｏｄおよび通信先のアプリのＰｏｄをスケールアウトする。そして、振り分けルール実行部１１Ａは、振り分けテーブル情報２１に、対象のアプリの宛先として、実行中のＷｏｒｋｅｒ上のＰｏｄとクラウド上のＰｏｄのＩＰアドレスを指定すれば良い。

また、対象のＷｏｒｋｅｒがエッジデバイス３上で実行されている場合の別の例として、振り分けルール実行部１１Ａは、Ｐｏｄ性能情報２２を参照して、エッジデバイス３上のアプリのＰｏｄのリソースの使用率が低負荷になった場合には、以下の処理を行う。振り分けルール実行部１１Ａは、クラウド上のアプリのＰｏｄのリソースを利用している場合にはこの利用を停止するようにする。一例として、振り分けルール実行部１１Ａは、振り分けテーブル情報２１のエッジデバイス３のＷｏｒｋｅｒの情報から、クラウド上の対象のアプリのＰｏｄのＩＰアドレスを削除する。

また、別の例として、振り分けルール実行部１１Ａは、対象のＷｏｒｋｅｒがクラウド上で実行されている場合には、以下の処理を行う。振り分けルール実行部１１Ａは、Ｐｏｄ性能情報２２を参照して、クラウド上のアプリのＰｏｄのリソースの使用率が高負荷になった場合には、クラウド上のアプリのＰｏｄをスケールアウトするようにＰｏｄ配備制御部１５に指示する。一例として、振り分けルール実行部１１Ａは、スケールアウトにより新規に構築されたＰｏｄのＩＰアドレスを、振り分けテーブル情報２１のクラウドのＷｏｒｋｅｒの情報に追加する。

また、対象のＷｏｒｋｅｒがエッジデバイス３上で実行されている場合の別の例として、振り分けルール実行部１１Ａは、Ｐｏｄ性能情報２２を参照して、クラウド上のアプリのＰｏｄのリソースの使用率が低負荷になった場合には、以下の処理を行う。振り分けルール実行部１１Ａは、クラウド上のアプリのＰｏｄを減らすようにＰｏｄ配備制御部１５に指示する。Ｐｏｄの台数を減らすことを「スケールイン」という。一例として、振り分けルール実行部１１Ａは、振り分けテーブル情報２１の、スケールインにより削除されたＰｏｄのアプリを利用しているエッジデバイス３やクラウドのＷｏｒｋｅｒの情報から、削除されたＰｏｄのＩＰアドレスを削除する。

Ｐｏｄ性能情報収集部１３は、各Ｐｏｄの性能情報を定期的に収集する。例えば、Ｐｏｄ性能情報収集部１３は、監視ツール５２に対して、各Ｐｏｄの性能情報を問い合わせる。そして、Ｐｏｄ性能情報収集部１３は、監視ツール５２から取得した各Ｐｏｄの性能情報をＰｏｄ性能情報２２に保持する。

Ｐｏｄ配備情報収集部１４は、各Ｐｏｄの配備情報を定期的に収集する。例えば、Ｐｏｄ配備情報収集部１４は、Ｍａｓｔｅｒに対して、各Ｐｏｄの配備情報を問い合わせる。そして、Ｐｏｄ配備情報収集部１４は、Ｍａｓｔｅｒから取得した各Ｐｏｄの配備情報をＰｏｄ配備情報２３に保持する。

Ｐｏｄ配備制御部１５は、振り分けルール実行部１１Ａからの指示に応じて、クラウド上にアプリのＰｏｄを増や（新規配備）したり、減らしたりする。

［コンテナ増減処理のフローチャート］
図１０～図１２は、実施例２に係るコンテナ増減処理のフローチャートの一例を示す図である。なお、コンテナ増減処理は、Ｗｏｒｋｅｒ毎に、例えば定期的に実行される。以降のフローチャートは、あるＷｏｒｋｅｒの処理について記載する。

図１０に示すように、振り分けルール実行部１１Ａは、所定のタイミングでコンテナ増減処理を開始する（ステップＳ３１）。振り分けルール実行部１１Ａは、ｋ８ｓクラスタ上の全アプリの探索を完了したか否かを判定する（ステップＳ３２）。ｋ８ｓクラスタ上の全アプリの探索を完了していないと判定した場合には（ステップＳ３２；Ｎｏ）、振り分けルール実行部１１Ａは、未だ探索が完了していないアプリを選択する（ステップＳ３３）。

そして、振り分けルール実行部１１Ａは、Ｗｏｒｋｅｒ上に選択したアプリのＰｏｄが存在するか否かを判定する（ステップＳ３４）。Ｗｏｒｋｅｒ上に選択したアプリのＰｏｄが存在しないと判定した場合には（ステップＳ３４；Ｎｏ）、振り分けルール実行部１１Ａは、ステップＳ５１に移行する。

一方、Ｗｏｒｋｅｒ上に選択したアプリのＰｏｄが存在すると判定した場合には（ステップＳ３４；Ｙｅｓ）、振り分けルール実行部１１Ａは、Ｗｏｒｋｅｒはエッジ／オンプレ上で稼働しているか否かを判定する（ステップＳ３５）。Ｗｏｒｋｅｒはエッジ／オンプレ上で稼働していないと判定した場合には（ステップＳ３５；Ｎｏ）、振り分けルール実行部１１Ａは、ステップＳ５１に移行する。

一方、Ｗｏｒｋｅｒはエッジ／オンプレ上で稼働していると判定した場合には（ステップＳ３５；Ｙｅｓ）、振り分けルール実行部１１Ａは、ステップＳ３６に移行する。ステップＳ３６において、振り分けルール実行部１１Ａは、Ｐｏｄのリソース使用率が高負荷であるか否かを判定する（ステップＳ３６）。Ｐｏｄのリソース使用率が高負荷であると判定した場合には（ステップＳ３６；Ｙｅｓ）、振り分けルール実行部１１Ａは、クラウド上に利用可能な、選択したアプリのＰｏｄと通信先アプリのＰｏｄとが存在するか否かを判定する（ステップＳ３７）。

クラウド上に利用可能な、選択したアプリのＰｏｄと通信先アプリのＰｏｄとが存在すると判定した場合には（ステップＳ３７；Ｙｅｓ）、振り分けルール実行部１１Ａは、アプリの宛先として実行中のＷｏｒｋｅｒ上のＰｏｄとクラウド上のＰｏｄのＩＰアドレスを指定する（ステップＳ３８）。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

一方、クラウド上に利用可能な、選択したアプリのＰｏｄと通信先アプリのＰｏｄとが存在しないと判定した場合には（ステップＳ３７；Ｎｏ）、振り分けルール実行部１１Ａは、クラウド上に選択アプリのＰｏｄおよび通信先アプリのＰｏｄを新規構築する（ステップＳ３９）。すなわち、振り分けルール実行部１１Ａは、選択アプリのＰｏｄおよび通信先アプリのＰｏｄをスケールアウトする。

そして、振り分けルール実行部１１Ａは、アプリの宛先として、実行中のＷｏｒｋｅｒ上のＰｏｄと、新規構築したクラウド上の選択アプリのＰｏｄのＩＰアドレスを指定する（ステップＳ４０）。このとき、振り分けルール実行部１１Ａは、クラウドのＷｏｒｋｅｒにもクラウド上のＰｏｄのＩＰアドレスを指定する。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

ステップＳ３６において、Ｐｏｄのリソース使用率が高負荷でないと判定した場合には（ステップＳ３６；Ｎｏ）、振り分けルール実行部１１Ａは、Ｐｏｄのリソース使用率が低負荷であるか否かを判定する（ステップＳ４１）。Ｐｏｄのリソース使用率が低負荷であると判定した場合には（ステップＳ４１；Ｙｅｓ）、振り分けルール実行部１１Ａは、アプリの宛先として実行中のＷｏｒｋｅｒ上のＰｏｄのＩＰアドレスを指定する（ステップＳ４２）。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

一方、Ｐｏｄのリソース使用率が低負荷であると判定した場合には（ステップＳ４１；Ｎｏ）、振り分けルール実行部１１Ａは、アプリの宛先は既存の設定から変更しない（ステップＳ４３）。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

ステップＳ５１において、振り分けルール実行部１１Ａは、クラウド上の選択したアプリのＰｏｄのリソース使用率が高負荷であるか否かを判定する（ステップＳ５１）。クラウド上の選択したアプリのＰｏｄのリソース使用率が高負荷であると判定した場合には（ステップＳ５１；Ｙｅｓ）、振り分けルール実行部１１Ａは、クラウド上にアプリのＰｏｄを新規構築する（ステップＳ５２）。すなわち、振り分けルール実行部１１Ａは、アプリのＰｏｄをスケールアウトする。

そして、振り分けルール実行部１１Ａは、アプリの宛先として、既存のＰｏｄと新規構築したＰｏｄのＩＰアドレスを指定する（ステップＳ５３）。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

一方、クラウド上の選択したアプリのＰｏｄのリソース使用率が高負荷でないと判定した場合には（ステップＳ５１；Ｎｏ）、振り分けルール実行部１１Ａは、クラウド上の選択したアプリのＰｏｄのリソース使用率が低負荷であるか否かを判定する（ステップＳ５４）。クラウド上の選択したアプリのＰｏｄのリソース使用率が低負荷でないと判定した場合には（ステップＳ５４；Ｎｏ）、振り分けルール実行部１１Ａは、ステップＳ５８に移行する。一方、クラウド上の選択したアプリのＰｏｄのリソース使用率が低負荷であると判定した場合には（ステップＳ５４；Ｙｅｓ）、振り分けルール実行部１１Ａは、クラウド上に同一アプリのＰｏｄが他に存在するか否かを判定する（ステップＳ５５）。

クラウド上に同一アプリのＰｏｄが他に存在しないと判定した場合には（ステップＳ５５；Ｎｏ）、振り分けルール実行部１１Ａは、ステップＳ５８に移行する。一方、クラウド上に同一アプリのＰｏｄが他に存在すると判定した場合には（ステップＳ５５；Ｙｅｓ）、振り分けルール実行部１１Ａは、他に存在するＰｏｄを削除する（ステップＳ５６）。すなわち、振り分けルール実行部１１Ａは、他Ｐｏｄをスケールインする。

そして、振り分けルール実行部１１Ａは、アプリの宛先として、削除したＰｏｄ以外のアプリのＰｏｄのＩＰを指定する（ステップＳ５７）。このとき、振り分けルール実行部１１Ａは、エッジ／オンプレ上のＷｏｒｋｅｒが削除Ｐｏｄを利用していた場合には、削除されたＰｏｄのＩＰアドレスを削除する。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

ステップＳ５８において、振り分けルール実行部１１Ａは、アプリの宛先は既存の設定から変更しない（ステップＳ５８）。そして、振り分けルール実行部１１Ａは、次のアプリを選択すべく、ステップＳ３２に移行する。

［Ｐｏｄ配備情報収集処理のフローチャート］
図１３は、実施例２に係るＰｏｄ配備情報収集処理のフローチャートの一例を示す図である。なお、Ｐｏｄ配備情報収集処理は、例えば定期的に実行される。

図１３に示すように、所定のタイミングで、Ｐｏｄ配備情報収集部１４は、Ｐｏｄ配備情報をＭａｓｔｅｒに問い合わせる（ステップＳ６１）。そして、Ｐｏｄ配備情報収集部１４は、問い合わせた結果、受け取ったＰｏｄ配備情報をＰｏｄ配備情報２３のＤＢに登録する（ステップＳ６２）。そして、Ｐｏｄ配備情報収集部１４は、Ｐｏｄ配備情報収集処理を終了する。

［Ｐｏｄ性能情報収集処理のフローチャート］
図１４は、実施例２に係るＰｏｄ性能情報収集処理のフローチャートの一例を示す図である。なお、Ｐｏｄ性能情報収集処理は、例えば定期的に実行される。

図１４に示すように、所定のタイミングで、Ｐｏｄ性能情報収集部１３は、各Ｐｏｄの性能情報を監視ツール５２に問い合わせる（ステップＳ７１）。そして、Ｐｏｄ性能情報収集部１３は、問い合わせた結果、受け取った各Ｐｏｄの性能情報をＰｏｄ性能情報２２のＤＢに登録する（ステップＳ７２）。そして、Ｐｏｄ性能情報収集部１３は、Ｐｏｄ性能情報収集処理を終了する。

［実施例２の効果］
このようにして、上記実施例２では、通信制御サーバ１は、システムがクラウドとクラウドでないデバイスとを含み、クラウドでないデバイスの特定のノードのリソースに負荷がかかっている場合、以下の処理を行う。通信制御サーバ１は、クラウドに特定のノード上の負荷をかけているアプリと同一のアプリが存在する場合には、特定のノードの振り分けテーブルにクラウドのアプリの宛先情報を追加する。かかる構成によれば、通信制御サーバ１は、クラウドでないデバイスの特定のノードのリソースに負荷がかかっている場合であっても、クラウドのアプリを利用させるようにすることで、性能を向上させることができる。

また、上記実施例２では、通信制御サーバ１は、クラウドに特定のノード上の負荷をかけているアプリと同一のアプリが存在しない場合には、クラウドに当該アプリのコンテナを新たに構築する。そして、通信制御サーバ１は、特定のノードの振り分けテーブルにクラウドのアプリの宛先情報を追加する。かかる構成によれば、通信制御サーバ１は、クラウドでないデバイス側の特定のノードのリソースに負荷がかかっている場合であって、クラウドに該当のアプリが存在しない場合であっても、クラウドに該当のアプリのコンテナを新たに構築することで、クラウドのアプリを利用させるようにすることで、性能を向上させることができる。

また、上記実施例２では、通信制御サーバ１は、さらに、クラウドに特定のノード上の負荷をかけているアプリと同一のアプリおよび当該アプリの通信先のアプリが存在しない場合には、クラウドに当該アプリのコンテナおよび当該アプリの通信先のアプリのコンテナを新たに構築する。そして、通信制御サーバ１は、特定のノードの振り分けテーブルにクラウドのアプリの宛先情報および当該アプリの通信先のアプリの宛先情報を追加する。かかる構成によれば、通信制御サーバ１は、クラウドに該当するアプリに加えて該当するアプリの通信先のアプリが存在しない場合には、クラウドにどちらのアプリのコンテナを新たに構築することで、環境を跨る通信を抑制することができる。この結果、通信制御サーバ１は、不要な通信を抑止できる。

また、上記実施例２では、通信制御サーバ１は、クラウドのリソースに負荷がかかっている場合には、クラウドに負荷をかけているアプリのコンテナを新たに構築する。そして、通信制御サーバ１は、クラウドの振り分けテーブルに新たに構築したコンテナの宛先情報を追加する。かかる構成によれば、通信制御サーバ１は、クラウドに負荷がかかっている場合であっても、負荷をかけているアプリと同一のアプリのコンテナを新たに構築することで、構築した方のコンテナを利用させるようにすることで、性能を向上させることができる。

また、上記実施例２では、通信制御サーバ１は、さらに、クラウドのリソースの負荷が減少した場合には、クラウドに負荷が減少したアプリと同一のアプリのコンテナが他に存在する場合には、クラウドに負荷をかけているアプリのコンテナと他のコンテナのいずれかを削除する。そして、通信制御サーバ１は、クラウド側の振り分けテーブルの、削除したコンテナの宛先情報を削除する。かかる構成によれば、通信制御サーバ１は、クラウドの不要なコンテナを削除することで、クラウドのコンテナを整理することができる。

［その他］
なお、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、振り分けルール実行部１１と、振り分けテーブル設定部１２とを１個の部として統合しても良い。一方、振り分けルール実行部１１Ａを、アプリの初期配備時の実行部と、アプリを配備後の実行部とに分散しても良い。また、図示しないが振り分けテーブル情報２１などを記憶する記憶部を通信制御サーバ１の外部装置としてネットワーク経由で接続するようにしても良い。

また、実施例１、２では、通信制御サーバ１が、クラウド上に設置されると説明したが、これに限定されない。通信制御サーバ１は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した各機能を搭載することによって実現することができる。

また、上記実施例１、２で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図２に示した通信制御サーバ１と同様の機能を実現するアプリ間通信制御プログラムを実行するコンピュータの一例を説明する。図１５は、アプリ間通信制御プログラムを実行するコンピュータの一例を示す図である。

図１５に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ（Hard Disk Drive）２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、アプリ間通信制御プログラム２０５ａおよびアプリ間通信制御処理関連情報２０５ｂを記憶する。

ＣＰＵ２０３は、アプリ間通信制御プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、通信制御サーバ１の各機能部に対応する。アプリ間通信制御処理関連情報２０５ｂは、振り分けテーブル情報２１などに対応する。そして、例えばリムーバブルディスク２１１が、アプリ間通信制御プログラム２０５ａなどの各情報を記憶する。

なお、アプリ間通信制御プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory）、ＤＶＤ（Digital Versatile Disk）、光磁気ディスク、ＩＣ（Integrated Circuit）カードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらからアプリ間通信制御プログラム２０５ａを読み出して実行するようにしても良い。

１、１Ａ 通信制御サーバ
３ エッジデバイス
５ マネージドｋ８ｓ
９ システム
１１，１１Ａ 振り分けルール実行部
１２ 振り分けテーブル設定部
１３ Ｐｏｄ性能情報収集部
１４ Ｐｏｄ配備情報収集部
１５ Ｐｏｄ配備制御部
２１ 振り分けテーブル情報
２２ Ｐｏｄ性能情報
２３ Ｐｏｄ配備情報
３１，５１ 振り分けテーブル

Claims (9)

1. 各ノードにアプリが分散配置され、
   前記各ノードが、メッセージの転送先となるノードを示す宛先情報を記憶した振り分けテーブルを備え、
   コンテナオーケストレーションソフトが、前記各ノードに配置されたアプリの情報に基づいて、前記振り分けテーブルを設定するシステムにおけるアプリ間通信制御方法であって、
   第１のノードの振り分けテーブルに、前記第１のノードを示す宛先情報と、前記第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、前記第２のノードを示す宛先情報を削除する
   処理をコンピュータが実行することを特徴とするアプリ間通信制御方法。
2. 前記コンテナオーケストレーションソフトにおいて、オートスケーリング機能が無効と設定されている場合に、前記第２のノードを示す宛先情報を削除する
   ことを特徴とする請求項１に記載のアプリ間通信制御方法。
3. 前記削除する処理は、第１のノードの前記振り分けテーブルに、クラウドを示す宛先情報と、前記第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、前記第２のノードを示す宛先情報を削除する
   ことを特徴とする請求項１に記載のアプリ間通信制御方法。
4. 前記システムは、クラウドとクラウドでないデバイスとを含み、前記クラウドでないデバイスの特定のノードのリソースに負荷がかかっており、かつ前記クラウドに前記特定のノード上の負荷をかけているアプリと同一のアプリが存在する場合には、前記特定のノードの前記振り分けテーブルに前記クラウドのアプリの宛先情報を追加する
   ことを特徴とする請求項１に記載のアプリ間通信制御方法。
5. 前記クラウドに前記特定のノード上の負荷をかけているアプリと同一のアプリが存在しない場合には、前記クラウドに当該アプリのコンテナを新たに構築し、前記特定のノードの前記振り分けテーブルに前記クラウドのアプリの宛先情報を追加する
   ことを特徴とする請求項４に記載のアプリ間通信制御方法。
6. 前記クラウドに前記特定のノード上の負荷をかけているアプリと同一のアプリおよび当該アプリの通信先のアプリが存在しない場合には、前記クラウドに当該アプリのコンテナおよび当該アプリの通信先のアプリのコンテナを新たに構築し、前記特定のノードの前記振り分けテーブルに前記クラウド側のアプリの宛先情報および当該アプリの通信先のアプリの宛先情報を追加する
   ことを特徴とする請求項５に記載のアプリ間通信制御方法。
7. 前記クラウドのリソースに負荷がかかっている場合には、前記クラウドに負荷をかけているアプリのコンテナを新たに構築し、前記クラウドの前記振り分けテーブルに新たに構築したコンテナの宛先情報を追加する
   ことを特徴とする請求項４に記載のアプリ間通信制御方法。
8. 前記クラウドのリソースの負荷が減少した場合には、前記クラウドに負荷が減少したアプリと同一のアプリのコンテナが他に存在する場合には、前記クラウドに負荷をかけているアプリのコンテナと他のコンテナのいずれかを削除し、前記クラウドの前記振り分けテーブルの削除したコンテナの宛先情報を削除する
   ことを特徴とする請求項７に記載のアプリ間通信制御方法。
9. コンテナオーケストレーションソフトが、各ノードに分散配置されたアプリの情報に基づいて、各ノードに備える振り分けテーブルであってメッセージの転送先となるノードを示す宛先情報を記憶した振り分けテーブルを設定し、
   第１のノードの振り分けテーブルに、前記第１のノードを示す宛先情報と、前記第１のノードと異なる第２のノードを示す宛先情報が設定されている場合に、前記第２のノードを示す宛先情報を削除する
   処理をコンピュータに実行させることを特徴とするアプリ間通信制御プログラム。

Images