JP2023065176A - プログラム、情報処理方法および情報処理装置 - Google Patents

Abstract

【課題】複数の種類のプロキシコンテナが混在する環境で適切な通信方法を利用する。【解決手段】コンテナグループ２０は種類Ｘのプロキシコンテナ２２を有する。コンテナグループ４０は種類Ｙのプロキシコンテナ４２を有する。処理部１２は、プロキシコンテナ２２より宛先にリクエストを送信する際の基準遅延時間を取得する。処理部１２は、コンテナグループ２０のリクエストが異種プロキシ間の通信を中継するコンテナグループ５０を経由してコンテナグループ４０に到達する場合の遅延時間を当該リクエストの数を基に計算する。処理部１２は、遅延時間が基準遅延時間より小さい場合、プロキシコンテナ２２を介してコンテナグループ５０へリクエストを送信する設定を行い、遅延時間が基準遅延時間以上の場合、種類Ｙのプロキシコンテナ２３をコンテナグループ２０に追加し、プロキシコンテナ２３を介してコンテナグループ４０へリクエストを送信する設定を行う。【選択図】図１

Description

本発明はプログラム、情報処理方法および情報処理装置に関する。

コンピュータにおける仮想化技術の１つにコンテナ型仮想化と呼ばれる技術がある。コンテナ型仮想化では、アプリケーションの起動に用いるライブラリなどの資源を纏めたコンテナが、ソフトウェアの実行環境として定義される。例えば、コンピュータにより実現されるノードがコンテナエンジンを実行することで、ノード上にコンテナを形成することができる。ノードは、ＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）などのリソースを有する物理マシンでもよいし、物理マシン上で動作する仮想マシンでもよい。

コンテナは、マイクロサービスと呼ばれる手法により開発されたアプリケーションの実行に用いられることがある。マイクロサービスでは、アプリケーションが機能ごとのサービスに分けて開発される。ノードは、複数のサービスを複数のコンテナにより動作させ、サービス間の連携によりアプリケーションを実行する。サービス間の連携に用いられるネットワーク基盤はサービスメッシュと呼ばれる。サービスメッシュには、サービスごとに配置されるプロキシが用いられる。プロキシもコンテナにより実現される。ノードは、あるサービスのデータを、プロキシを経由して他のサービスに送信することで、サービス間の通信を制御する。例えば、サービスのコンテナとプロキシとして機能するプロキシコンテナとを含むコンテナのグループであるコンテナグループが、ノードへの配備の一単位として用いられることがある。

なお、オーバーレイネットワークに属するオーバーレイノードによる通信経路決定方法が提案されている。当該通信経路決定方法では、オーバーレイノードは、自ノードから着信先ノードへの通信品質を測定しておき、その一方で中継候補ノードから着信先ノードへの通信品質測定結果を中継候補ノードから取得する。オーバーレイノードは、両者の通信品質を比較し、前者の方がよい場合、中継ノードは用いずに着信先ノードへ直接転送する経路を自ノードから着信先ノードへの通信経路とする。オーバーレイノードは、後者がよい場合、最も高品質を提供する中継候補ノードを中継ノードとする通信経路とする。

また、オーバーレイノードが取得する通信品質として、遅延時間とパケット損失率などの複数のＱｏＳ（Quality of Service）を考慮する方法も提案されている。

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

プロキシコンテナには複数の種類が存在する。あるサービスに対して使用されるプロキシコンテナの種類は、例えばサービスの開発に用いられる開発フレームワークに応じて選択される。

このため、あるコンテナグループと他のコンテナグループとで、使用するプロキシコンテナの種類が異なることがある。プロキシコンテナの種類が異なると、通信に用いられるプロトコルが異なり、両コンテナグループ間で通信を行えなくなる。そこで、複数の種類のプロキシコンテナが混在するシステムでサービスメッシュを実現するため、例えば次の方法が考えられる。

第１の方法は、ゲートウェイとして機能するコンテナグループを別途設ける方法である。ゲートウェイは、一方の種類のプロキシコンテナで使用されるプロトコルを、他方の種類のプロキシコンテナで使用されるプロトコルに変換することで、異種のプロキシコンテナ間の通信を中継する。

第２の方法は、サービスのコンテナを含むコンテナグループに、複数の種類のプロキシコンテナを共存させる方法である。この場合、リクエストの送信元のコンテナグループは、宛先のコンテナグループで使用されるプロキシコンテナの種類に応じて、自身が有する複数の種類のプロキシコンテナを使い分ける。

しかし、第１の方法では、第２の方法に比べて消費リソース量を抑えられるが、ゲートウェイでの中継処理により通信の遅延が増大する可能性があるという問題がある。一方、第２の方法では、ゲートウェイを介さないため第１の方法に比べて通信の遅延が抑制されるが、１つのコンテナグループ当たりの消費リソースが増し、配備されるコンテナグループの数の増加に応じて、消費リソース量が過大になり得るという問題がある。

１つの側面では、本発明は、複数の種類のプロキシコンテナが混在する環境において適切な通信方法を利用可能にすることを目的とする。

１つの態様では、プログラムが提供される。このプログラムは、他のコンテナグループとの通信に用いられるプロキシコンテナを含む複数のコンテナが属するコンテナグループであって、第１の種類のプロキシコンテナを有する第１コンテナグループと第２の種類の第１プロキシコンテナを有する第２コンテナグループとを含む複数のコンテナグループを実行する情報処理システムについて、第１コンテナグループから第１の種類のプロキシコンテナにより宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間を取得し、第１コンテナグループからのリクエストが、互いに異なる種類のプロキシコンテナ間の通信を中継する第３コンテナグループを経由して第２コンテナグループに到達する場合の第２遅延時間を、第１コンテナグループから第２コンテナグループへのリクエストの数に基づいて計算し、第２遅延時間が第１遅延時間より小さい場合に、第１コンテナグループから第２コンテナグループへのリクエストを、第１の種類のプロキシコンテナを介して第３コンテナグループへ送信する設定を行い、第２遅延時間が第１遅延時間以上の場合に、第２の種類の第２プロキシコンテナを第１コンテナグループに追加し、第１コンテナグループから第２コンテナグループへのリクエストを、第２プロキシコンテナを介して第２コンテナグループへ送信する設定を行う、処理をコンピュータに実行させる。

また、１つの態様では、情報処理方法が提供される。また、１つの態様では、記憶部と処理部とを有する情報処理装置が提供される。

１つの側面では、複数の種類のプロキシコンテナが混在する環境において適切な通信方法を利用できる。

第１の実施の形態の情報処理装置を説明する図である。 第２の実施の形態の情報処理システムのハードウェア例を示す図である。 管理サーバのハードウェア例を示す図である。 マスターノードによるワーカーノードの制御例を示す図である。 ポッド間の通信の例を示す図である。 サイドカーの種類に応じた通信可否の例を示す図である。 ＧＷ経由の通信の例を示す図である。 異なる種類のサイドカーの共存による通信の例を示す図である。 管理サーバの機能例を示す図である。 サイドカー情報テーブルの例を示す図である。 リクエスト数テーブルの例を示す図である。 基準遅延時間テーブルの例を示す図である。 サービスメッシュタイプテーブルの例を示す図である。 サービスメッシュタイプ別リクエスト数テーブルの例を示す図である。 ＧＷ経由遅延時間テーブルの例を示す図である。 ＩＰアドレステーブルの例を示す図である。 通信方法管理テーブルの例を示す図である。 ＧＷ経由およびサイドカー共存それぞれの通信経路の例を示す図である。 ＧＷ経由時のルーティング設定の例を示す図である。 異なる種類のサイドカー共存時のルーティング設定の例を示す図である。 管理サーバの処理例を示すフローチャートである。 管理サーバの続きの処理例を示すフローチャートである。 管理サーバの続きの処理例を示すフローチャートである。 最大割当リソース量テーブルの例を示す図である。 最大割当リソース量に応じた通信方法の選択例を示す図である。

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
第１の実施の形態を説明する。

図１は、第１の実施の形態の情報処理装置を説明する図である。
情報処理装置１０は、情報処理システム１で実行されるコンテナグループ間の通信を管理する。情報処理装置１０は、記憶部１１および処理部１２を有する。記憶部１１は、ＲＡＭなどの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１２は、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１２はプログラムを実行するプロセッサでもよい。「プロセッサ」は複数のプロセッサの集合（マルチプロセッサ）でもよい。情報処理装置１０は、情報処理システム１に含まれてもよい。

情報処理システム１は、マイクロサービスの手法により開発されたアプリケーションを実行する。情報処理システム１は、１以上のノードを有し、１以上のノード上で複数のコンテナを動作させる。図１ではノードは省略されている。ノードは、物理マシンでもよいし、物理マシン上で動作する仮想マシンでもよい。情報処理システム１は、複数のコンテナにより複数のサービスを実行する。情報処理システム１は、複数のサービスを、プロキシコンテナを介して連携させることで、アプリケーションを実行する。情報処理システム１におけるノードへのサービスの配備の単位は、サービスを実行するコンテナとプロキシコンテナとを含むコンテナグループとなる。

ここで、情報処理システム１では、コンテナの統合管理を行うコンテナオーケストレーションツールが使用される。コンテナオーケストレーションツールは、コンテナの作成および削除やコンテナのクラスタ管理およびコンテナの配備先ノードの決定などのスケジューリングなどを行うソフトウェアである。コンテナオーケストレーションツールの一例には、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）がある。ＫｕｂｅｒｎｅｔｅｓはＫ８ｓと略記される。例えば、Ｋ８ｓでは、ポッド（Pod）と呼ばれるコンテナグループがノードへの配備単位となる。ただし、情報処理システム１は、コンテナオーケストレーションツールとして、Ｋ８ｓ以外のものを用いてもよい。また、プロキシコンテナは、サイドカー（Sidecar）コンテナまたは単にサイドカーと呼ばれることがある。情報処理システム１は、コンテナグループ２０，３０，４０を実行する。

コンテナグループ２０は、コンテナ２１およびプロキシコンテナ２２を有する。コンテナ２１は、第１サービスを実行する。プロキシコンテナ２２の種類はＸである。
コンテナグループ３０は、コンテナ３１およびプロキシコンテナ３２を有する。コンテナ３１は、第２サービスを実行する。プロキシコンテナ３２の種類はＸである。

コンテナグループ４０は、コンテナ４１およびプロキシコンテナ４２を有する。コンテナ４１は、第３サービスを実行する。プロキシコンテナ４２の種類はＹである。
このように、情報処理システム１では、複数の種類のプロキシコンテナが混在する。例えば、Ｋ８ｓ上の複数の種類のプロキシコンテナとしては、ＩｓｔｉｏのＥｎｖｏｙサイドカー、ＬｉｎｋｅｒｄサイドカーおよびＤａｐｒサイドカーなどが挙げられる。

２つのプロキシコンテナは、同種のもの同士であれば、直接通信が可能である。２つのプロキシコンテナは、互いに異なる種類のもの同士であると、直接通信が不可能である。通信に使用される、暗号化などのプロトコルが異なるためである。上記の例の場合、プロキシコンテナ２２，３２は、両方とも種類Ｘである。このため、プロキシコンテナ２２，３２は、直接通信が可能である。

一方、プロキシコンテナ２２は種類Ｘであるが、プロキシコンテナ４２は種類Ｙであり、種類が異なる。このため、プロキシコンテナ２２，４２は直接通信が不可能である。コンテナグループ２０，４０の連携を実現するため、処理部１２は次の方法を用い得る。

第１の方法は、ゲートウェイとして機能するコンテナグループ５０を情報処理システム１に設ける方法である。コンテナグループ５０は、プロキシコンテナ５１，５２を有する。プロキシコンテナ５１の種類はＸである。プロキシコンテナ５２の種類はＹである。コンテナグループ５０は、プロキシコンテナ２２からのリクエストをプロキシコンテナ５１で受信する。コンテナグループ５０は、当該リクエストをプロキシコンテナ５２からプロキシコンテナ４２へ転送する。

第２の方法は、コンテナグループ２０に、種類Ｙのプロキシコンテナ２３を設け、種類Ｘのプロキシコンテナ２２と共存させる方法である。コンテナグループ２０は、プロキシコンテナ２３により、コンテナグループ４０のプロキシコンテナ４２と直接通信可能である。

第１の方法では、第２の方法に比べて消費リソース量を抑えられるが、ゲートウェイによる中継処理のために通信が遅延し得る。一方、第２の方法では、第１の方法に比べて通信の遅延は低減するが、１つのコンテナグループ当たりの消費リソースが増し、配備されるコンテナグループの数の増加に応じて、消費リソース量が過大になり得る。

そこで、処理部１２は、次のように、第１の方法と第２の方法とを使い分ける。処理部１２は、コンテナグループ２０または他のコンテナグループが新たに配備されるタイミングや、所定の周期で、下記の処理を行う。なお、コンテナグループ２０が新たに配備される場合、情報処理システム１では、コンテナグループ２０と同じサービスを実行するコンテナグループが既に実行されていてもよい。この場合、実行済のコンテナグループの負荷の一部が新たに配備されるコンテナグループ２０に振り分けられる。また、既存のコンテナグループ２０と同じサービスを実行する他のコンテナグループが新たに配備される場合、実行済のコンテナグループ２０の負荷の一部が新たに配備される他のコンテナグループに振り分けられる。

処理部１２は、コンテナグループ２０からプロキシコンテナ２２を用いて宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間を取得する。処理部１２は、第１遅延時間を記憶部１１に格納する。

例えば、処理部１２は、ユーザによる第１遅延時間の入力を受け付けることで、第１遅延時間を取得してもよい。また、プロキシコンテナによる通信の遅延時間は、プロキシコンテナが単位時間当たりに送信するリクエスト数に比例して変わる。そこで、処理部１２は、種類Ｘのプロキシコンテナに対して公開されている、単位時間当たりに送信する所定のリクエスト数Ａに対する遅延時間Ｔに基づいて、第１遅延時間を計算してもよい。

より具体的には、まず、処理部１２は、プロキシコンテナ２２が単位時間当たりに送信するリクエスト総数Ｂを取得する。処理部１２は、コンテナグループ２０が送信した直近の所定期間のリクエスト数を基にリクエスト総数Ｂを計算してもよい。なお、処理部１２は、各プロキシコンテナから宛先のプロキシコンテナに送信されたリクエスト数を既存の分散トレーシングの技術を用いて取得可能である。例えば、分散トレーシングを提供するツールには、ＪａｅｇｅｒやＺｉｐｋｉｎなどが挙げられる。

また、処理部１２は、コンテナグループ２０と同じサービスを実行する他のコンテナグループを新たに配備する場合、コンテナグループ２０のリクエスト数の一部が他のコンテナグループに振り分けられることを考慮してリクエスト総数Ｂを計算する。一例では、処理部１２は、コンテナグループ２０と新たに配備する他のコンテナグループとで、コンテナグループ２０における直近の所定期間のリクエスト数を按分することでリクエスト総数Ｂを計算し得る。また、コンテナグループ２０を新たに配備する場合、処理部１２は、コンテナグループ２０と同じサービスを実行する既存のコンテナグループに属するプロキシコンテナが送信した直近の所定期間のリクエスト数を基にリクエスト総数Ｂを計算してもよい。

処理部１２は、リクエスト総数Ｂに基づいて、プロキシコンテナ２２から種類Ｘのプロキシコンテナへ直接リクエスト送信を行うとした場合の遅延時間τを、τ＝（Ｂ／Ａ）＊Ｔと計算する。処理部１２は、遅延時間τを第１遅延時間としてもよい。または、処理部１２は、遅延時間τに所定の係数αを乗じた値を、第１遅延時間としてもよい。例えば、係数αは、１より大きい値でもよい。

次に、処理部１２は、プロキシコンテナ２２からのリクエストがコンテナグループ５０を経由してコンテナグループ４０へ到達する場合の第２遅延時間を、コンテナグループ２０からコンテナグループ４０へのリクエストの数に基づいて計算する。前述のように、種類Ｘのプロキシコンテナにおける、単位時間当たりの所定のリクエスト数に応じた遅延時間や種類Ｙのプロキシコンテナにおける、単位時間当たりの所定のリクエスト数に応じた遅延時間は公開されている。そこで、処理部１２は、コンテナグループ２０からコンテナグループ４０を宛先とするリクエスト数と、プロキシコンテナ２２，５１，５２に対して公開されている遅延時間とに基づいて、プロキシコンテナ２２，５１，５２それぞれで生じる遅延時間を計算する。処理部１２は、プロキシコンテナ２２，５１，５２それぞれで生じる遅延時間の合計を第２遅延時間とする。処理部１２は、リクエスト数に基づいて遅延時間を計算することで、各プロキシコンテナ内での処理に応じた遅延時間を直接計測することが難しい場合でも、当該遅延時間を適切に得ることができる。

そして、処理部１２は、第１遅延時間と第２遅延時間とを比較し、比較の結果に応じて、上記の第１の方法を用いるか第２の方法を用いるかを選択する。具体的には、処理部１２は、第２遅延時間が第１遅延時間より小さい場合に、コンテナグループ２０からコンテナグループ４０へのリクエストを、プロキシコンテナ２２を介してコンテナグループ５０へ送信する設定を情報処理システム１に対して行う。

すなわち、処理部１２は、第２遅延時間が第１遅延時間より小さい場合には、コンテナグループ２０からコンテナグループ４０へのリクエストをゲートウェイ経由で送信する第１の方法を選択し、第１の方法を利用するためのルーティング設定を行う。一例では、処理部１２は、コンテナグループ４０を宛先とするリクエストの転送先をプロキシコンテナ５１とするルールを、プロキシコンテナ２２が有する、転送先の情報を保持する所定のテーブルに追加する。これにより、コンテナグループ２０からコンテナグループ４０へのリクエストは、コンテナグループ５０を介して、コンテナグループ４０へ到達する。

なお、コンテナグループ２０にプロキシコンテナ２３が既に存在していることがある。この場合、処理部１２は、コンテナグループ２０からプロキシコンテナ２３を削除する。すなわち、処理部１２は、プロキシコンテナ２３の削除後のコンテナグループ２０を配備し直す。また、ゲートウェイとして用いるコンテナグループ５０が配備されていない場合、処理部１２は、コンテナグループ５０を新たに配備する。

一方、処理部１２は、第２遅延時間が第１遅延時間以上の場合に、コンテナグループ２０にプロキシコンテナ２３を追加する。具体的には、処理部１２は、プロキシコンテナ２３の追加後のコンテナグループ２０を配備し直す。そして、処理部１２は、コンテナグループ２０からコンテナグループ４０へのリクエストを、プロキシコンテナ２３を介してコンテナグループ４０へ送信する設定を情報処理システム１に対して行う。

すなわち、処理部１２は、第２遅延時間が第１遅延時間以上の場合には、コンテナグループ２０からコンテナグループ４０へのリクエストを種類Ｙのプロキシコンテナ２３を用いて直接送信する第２の方法を選択する。そして、処理部１２は、第２の方法を利用するためのルーティング設定を行う。一例では、処理部１２は、コンテナグループ４０を宛先とするリクエストの転送先をプロキシコンテナ４２とするルールを、プロキシコンテナ２３が有する、転送先の情報を保持する所定のテーブルに追加する。また、処理部１２は、コンテナグループ４０を宛先とするリクエストの、コンテナ２１からの転送先をプロキシコンテナ２３とするルールを、コンテナグループ２０が有するｉｐｔａｂｌｅｓなどのルーティング設定情報に追加する。これにより、コンテナグループ２０からコンテナグループ４０へのリクエストは、コンテナグループ５０を介さずに、直接、コンテナグループ４０へ到達する。

情報処理装置１０によれば、情報処理システム１について、第１コンテナグループから第１の種類のプロキシコンテナを用いて宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間が取得される。第１遅延時間は、記憶部１１に記憶される。第１コンテナグループからの当該リクエストが第３コンテナグループを経由して第２コンテナグループに到達する場合の第２遅延時間が、第１コンテナグループから第２コンテナグループへのリクエストの数に基づいて計算される。第３コンテナグループは、互いに異なる種類のプロキシコンテナ間の通信を中継するゲートウェイとして機能する。第２遅延時間が第１遅延時間より小さい場合に、第１コンテナグループから第２コンテナグループへのリクエストを、第１の種類のプロキシコンテナを介して第３コンテナグループへ送信する設定が行われる。第２遅延時間が第１遅延時間以上の場合に、第２の種類の第２プロキシコンテナが第１コンテナグループに追加される。更に、第１コンテナグループから第２コンテナグループへのリクエストが、第２プロキシコンテナを介して第２コンテナグループへ送信する設定が行われる。なお、コンテナグループ２０は、第１コンテナグループの一例である。コンテナグループ４０は、第２コンテナグループの一例である。コンテナグループ５０は、第３コンテナグループの一例である。

これにより、情報処理装置１０は、複数の種類のプロキシコンテナが混在する環境において適切な通信方法を利用できる。具体的には次の通りである。
第２遅延時間が、基準となる第１遅延時間よりも小さい場合、ゲートウェイ経由で通信したとしても、情報処理システム１に対して期待される通信品質は満たされることになる。したがって、この場合、処理部１２は、コンテナグループ２０からコンテナグループ４０へのリクエストを、ゲートウェイ、すなわち、コンテナグループ５０経由とすることで、消費リソース量の抑制を図れる。

一方、第２遅延時間が、基準となる第１遅延時間以上の場合、ゲートウェイ経由での通信では、情報処理システム１に対して期待される通信品質は満たされないことになる。したがって、この場合、処理部１２は、コンテナグループ２０からコンテナグループ４０へのリクエストをゲートウェイ、すなわち、コンテナグループ５０を経由せずに、直接送信とすることで、遅延時間の抑制を図れる。

こうして、処理部１２は、第１遅延時間と第２遅延時間との比較により異種のプロキシコンテナ宛のリクエストをゲートウェイ経由とするか、または、直接送信とするかを選択することで、遅延時間の抑制と消費リソース量の抑制とを両立することができる。

以下では、より具体的な例を用いて、情報処理装置１０の機能を更に詳細に説明する。
［第２の実施の形態］
次に、第２の実施の形態を説明する。

図２は、第２の実施の形態の情報処理システムのハードウェア例を示す図である。
情報処理システム２は、マイクロサービスの手法を用いて開発されたアプリケーションを実行する。情報処理システム２は、アプリケーションにおける複数のサービスを実現する複数のコンテナを実行する。例えば、情報処理システム２は、コンテナオーケストレーションツールとしてＫ８ｓを実行する。情報処理システム２は、Ａｐａｃｈｅ Ｍｅｓｏｓ（Ａｐａｃｈｅは登録商標）などの他のコンテナオーケストレーションツールを用いてもよい。

情報処理システム２は、管理サーバ１００、マスターノード２００およびワーカーノード３００，４００，５００を有する。管理サーバ１００、マスターノード２００およびワーカーノード３００，４００，５００は、ネットワーク６０に接続されている。ネットワーク６０は、例えば、ＬＡＮ（Local Area Network）である。例えば、ネットワーク６０は、ＷＡＮ（Wide Area Network）やインターネットなどの外部ネットワークに接続されてもよい。情報処理システム２は、情報処理システム２が実行するアプリケーションを、外部ネットワークを介して、図示を省略しているクライアントコンピュータにより利用可能としてもよい。

管理サーバ１００は、各ワーカーノードで動作する、異種のサイドカーをもつポッド間の通信方法を管理するサーバコンピュータである。サイドカーは、プロキシコンテナの一例である。ポッドは、ワーカーノードに対するコンテナ配備の一単位であり、コンテナグループの一例である。なお、個々のポッド上のコンテナにより実現されるアプリケーションのサービスが「マイクロサービス」と呼ばれてもよい。管理サーバ１００は、第１の実施の形態の情報処理装置１０の一例である。

マスターノード２００は、コンテナのクラスタ管理、各ワーカーノードと連携するためのＡＰＩ（Application Programming Interface）提供、各ワーカーノードへのコンテナ配備のスケジューリング、ＤＢ（DataBase）管理などを行うサーバコンピュータである。

ワーカーノード３００，４００，５００は、コンテナを実行するサーバコンピュータである。ワーカーノード３００，４００，５００は、マスターノード２００と通信し、コンテナの制御を行う。

図３は、管理サーバのハードウェア例を示す図である。
管理サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、媒体リーダ１０６およびＮＩＣ（Network Interface Card）１０７を有する。なお、ＣＰＵ１０１は、第１の実施の形態の処理部１２の一例である。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１の一例である。

ＣＰＵ１０１は、プログラムの命令を実行するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、ＣＰＵ１０１は複数のプロセッサコアを含んでもよい。また、管理サーバ１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムやＣＰＵ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、管理サーバ１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。

ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。

ＧＰＵ１０４は、ＣＰＵ１０１からの命令に従って、管理サーバ１００に接続されたディスプレイ６１に画像を出力する。ディスプレイ６１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。

入力インタフェース１０５は、管理サーバ１００に接続された入力デバイス６２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス６２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、管理サーバ１００に、複数の種類の入力デバイスが接続されていてもよい。

媒体リーダ１０６は、記録媒体６３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体６３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。

媒体リーダ１０６は、例えば、記録媒体６３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、ＣＰＵ１０１によって実行される。なお、記録媒体６３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体６３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。

ＮＩＣ１０７は、ネットワーク６０に接続され、ネットワーク６０を介して他のコンピュータと通信を行うインタフェースである。ＮＩＣ１０７は、例えば、スイッチやルータなどの通信装置とケーブルで接続される。

マスターノード２００およびワーカーノード３００，４００，５００も、管理サーバ１００と同様のハードウェアにより実現される。ただし、管理サーバ１００、マスターノード２００およびワーカーノード３００，４００，５００は、ＣＰＵおよびＲＡＭを有する１以上の物理マシン上で動作する複数の仮想マシンにより実現されてもよい。

図４は、マスターノードによるワーカーノードの制御例を示す図である。
マスターノード２００は、管理データ記憶部２１０およびサービス制御部２２０を有する。管理データ記憶部２１０には、マスターノード２００のＲＡＭやＨＤＤなどの記憶領域が用いられる。サービス制御部２２０は、マスターノード２００のＣＰＵがマスターノード２００のＲＡＭに記憶されたプログラムを実行することで実現される。

ワーカーノード３００は、エージェント３１０およびポッド６００を有する。エージェント３１０およびポッド６００は、ワーカーノード３００のＣＰＵがワーカーノード３００のＲＡＭに記憶されたプログラムを実行することで実現される。

ワーカーノード４００は、エージェント４１０およびポッド７００を有する。エージェント４１０およびポッド７００は、ワーカーノード４００のＣＰＵがワーカーノード４００のＲＡＭに記憶されたプログラムを実行することで実現される。

エージェント３１０，４１０は、マスターノード２００の指示に従って、自ノードでポッドを起動する。また、エージェント３１０，４１０は、自ノードのステータスを監視し、マスターノード２００に通知する。エージェント３１０，４１０は、ｋｕｂｅｌｅｔと呼ばれる。

図示を省略しているが、ワーカーノード５００も、ワーカーノード３００，４００と同様に、エージェントおよびポッドを実行する。ワーカーノード３００，４００，５００それぞれは、複数のポッドを実行し得る。

サービス制御部２２０は、エージェント３１０と通信し、ワーカーノード３００上へのポッド６００の配備および起動を指示する。また、サービス制御部２２０は、エージェント３１０と通信し、ワーカーノード３００上で動作するポッド６００の停止や削除を指示することもある。なお、ワーカーノードへのポッドの配備はデプロイと言われることがある。また、ワーカーノードからのポッドの削除はアンデプロイと言われることがある。

サービス制御部２２０は、エージェント４１０と通信し、ワーカーノード４００上へのポッド７００の配備や起動を指示する。また、サービス制御部２２０は、エージェント４１０と通信し、ワーカーノード４００上で動作するポッド７００の停止や削除を指示することもある。

ここで、ポッド６００は、コンテナ６１０およびサイドカー６２０を有する。ポッド７００は、コンテナ７１０およびサイドカー７２０を有する。
コンテナ６１０，７１０は、アプリケーションのプログラムやライブラリなどを１つにまとめたコンポーネントである。コンテナ６１０，７１０それぞれが１つのサービスを実現する。

サイドカー６２０は、ポッド６００と他のポッドとの通信を行うプロキシとして機能するコンポーネントである。サイドカー６２０も、コンテナとして実現される。サイドカー７２０も、サイドカー６２０と同様に、他のポッドとの通信を行うプロキシとして機能する。

また、サービス制御部２２０は、既存の分散トレーシングの技術を用いて、各サイドカーから宛先のサイドカー毎に送信された単位時間当たりのリクエスト数の平均値を取得し、管理データ記憶部２１０に格納する。情報処理システム２で実行される分散トレーシングのツールには、例えばＪａｅｇｅｒやＺｉｐｋｉｎなどがある。

管理サーバ１００は、マスターノード２００にコマンドを入力することで、ワーカーノード３００，４００，５００におけるポッドの配備や起動などを指示したり、管理データ記憶部２１０に保持される情報を取得したりする。例えば、管理データ記憶部２１０は、サービス制御部２２０が各ワーカーノードから取得した、サイドカー間のリクエスト数の計測値などの情報を保持する。管理サーバ１００からマスターノードに入力されるコマンドには、例えばｋｕｂｅｃｔｌコマンドが用いられる。

図５は、ポッド間の通信の例を示す図である。
例えば、ポッド６００は、サイドカー６２０を用いて、ポッド６００ｘと通信する。ポッド６００ｘは、コンテナ６１０ｘおよびサイドカー６２０ｘを有する。例えば、コンテナ６１０からコンテナ６１０ｘへリクエストを送信する場合、コンテナ６１０は、リクエストをサイドカー６２０に転送する。サイドカー６２０は、リクエストの宛先、すなわち、サイドカー６２０ｘのＩＰ（Internet Protocol）アドレスを特定し、当該ＩＰアドレスに基づいて、サイドカー６２０ｘへリクエストを送信する。サイドカー６２０ｘは、受信したリクエストをコンテナ６１０ｘへ転送する。

サイドカー６２０，６２０ｘによるリクエストの宛先に応じた転送先の情報（例えば、転送先のＩＰアドレス）は、コントロールプレーン７０からサイドカー６２０，６２０ｘに提供される。コントロールプレーン７０は、コンテナにより実現され、ワーカーノード３００，４００，５００それぞれで動作する。

コントロールプレーン７０に対して、サイドカー６２０，６２０ｘのレイヤは、データプレーン７１と呼ばれる。コントロールプレーン７０およびデータプレーン７１により、サービスメッシュが実現される。サービスメッシュは、例えばｍＴＬＳ（mutual-TLS）による暗号化、ロードバランシングおよび分散トレーシングなどの、サービス間の通信制御を行う。

Ｋ８ｓ上でサービスメッシュを提供するソフトウェアには、例えば、Ｉｓｔｉｏ、ＬｉｎｋｅｒｄおよびＤａｐｒなどがある。また、Ｋ８ｓ上でサービスメッシュを提供するクラウドサービスには、ＡＷＳ（登録商標） Ａｐｐ ＭｅｓｈやＧＣＰ Ａｎｔｈｏｓ（登録商標）などがある。ＧＣＰはGoogle Cloud Platformの略である。Ｇｏｏｇｌｅは登録商標である。

サービスメッシュのタイプ、すなわち、サイドカーの種類として、何れのものが用いられるかは、サービスの開発に用いられる開発フレームワークに応じて選択される。このため、情報処理システム２では、異なる種類のサイドカーが共存し得る。

図６は、サイドカーの種類に応じた通信可否の例を示す図である。
例えば、コンテナ６１０のサービス名をＡｐｐ１とする。サイドカー６２０は、Ｉｓｔｉｏサイドカー、すなわち、Ｅｎｖｏｙサイドカーであるとする。また、コンテナ７１０のサービス名をＡｐｐ２とする。サイドカー７２０は、Ｄａｐｒサイドカーであるとする。この場合、サイドカー６２０に対するコントロールプレーン７０は、Ｉｓｔｉｏのコントロールプレーンである。Ｄａｐｒのサイドカー７２０に対しては、Ｄａｐｒのコントロールプレーンが各ノードで実行される。

また、情報処理システム２で動作するポッド８００は、コンテナ８１０およびサイドカー８２０を有する。コンテナ８１０のサービス名をＡｐｐ３とする。サイドカー８２０は、Ｉｓｔｉｏサイドカーである。

同種のサイドカー同士は、直接の通信が可能である。例えば、サイドカー６２０，８２０は、何れもＩｓｔｉｏサイドカーであり、同種のサイドカー同士である。したがって、サイドカー６２０，８２０は、直接の通信が可能である。

一方、異種のサイドカー同士は、直接の通信が不可能である。暗号化などの通信のためのプロトコルが異なるためである。例えば、サイドカー６２０はＩｓｔｉｏサイドカーであるが、サイドカー７２０は、Ｄａｐｒサイドカーである。すなわち、サイドカー６２０，７２０は、異種のサイドカー同士である。したがって、サイドカー６２０，７２０は、直接の通信が不可能である。

直接の通信を行えないポッド間の連携を可能にするため、次のような２つの通信方法が考えられる。第１の方法は、異種のサイドカーの間の通信を中継するゲートウェイ（ＧＷ：Gateway）として機能するポッドを設け、ＧＷ経由で異種のサイドカーの間の通信を行う方法である。第２の方法は、リクエストの送信元のポッドに、元のサイドカーとは異なる種類のサイドカーを共存させ、異なる種類のサイドカー宛のリクエスト送信に用いる方法である。

図７は、ＧＷ経由の通信の例を示す図である。
ゲートウェイ９００は、ポッド６００，７００の通信を中継する。ゲートウェイ９００は、サイドカー９１０，９２０を有する。サイドカー９１０はＩｓｔｉｏサイドカーである。サイドカー９２０は、Ｄａｐｒサイドカーである。ゲートウェイ９００は、サイドカー９１０で受信したリクエストをサイドカー９２０から送信することで、Ｉｓｔｉｏサイドカーの通信プロトコルを、Ｄａｐｒサイドカーの通信プロトコルに変換する。あるいは、ゲートウェイ９００は、サイドカー９２０で受信したリクエストをサイドカー９１０から送信することで、Ｄａｐｒサイドカーの通信プロトコルを、Ｉｓｔｉｏサイドカーの通信プロトコルに変換する。リクエストの宛先に応じたリクエストの転送先の情報（例えば、転送先のＩＰアドレス）は、ゲートウェイ９００を動作させるワーカーノードのコントロールプレーンにより、ゲートウェイ９００に提供される。ゲートウェイ９００は、Ｄａｐｒサイドカーの通信プロトコルを、Ｉｓｔｉｏサイドカーの通信プロトコルに変換する処理を行うコンテナを更に有してもよい。

サイドカー６２０は、ポッド７００宛のリクエストをゲートウェイ９００に送信することで、ポッド６００にＤａｐｒサイドカーを設けなくても、ポッド７００と通信できる。
なお、サイドカー６２０は、ポッド８００宛のリクエストについては、サイドカー８２０に直接送信する。

図８は、異なる種類のサイドカーの共存による通信の例を示す図である。
例えば、ポッド６００に、コンテナ６１０およびサイドカー６２０に加えて、サイドカー６３０を設ける。サイドカー６３０は、Ｄａｐｒサイドカーである。したがって、サイドカー６３０，７２０は直接通信が可能である。この場合、コンテナ６１０は、ポッド７００宛のリクエストをサイドカー６３０に転送することで、当該リクエストをポッド７００に送信させることができる。コンテナ６１０は、ポッド８００宛のリクエストについては、サイドカー６２０に転送することで、当該リクエストをポッド８００に送信させることができる。

このように、上記の２つの通信方法により異なる種類のサイドカーを有するポッド同士の通信を可能にすることが考えられる。しかし、ＧＷ経由の通信方法では、異種サイドカーを共存させる通信方法に比べて消費リソース量を抑えられるが、ゲートウェイ９００による中継処理のために通信が遅延する可能性がある。一方、異種サイドカーを共存させる通信方法では、ＧＷ経由の通信方法に比べて通信の遅延は低減するが、１つのコンテナグループ当たりの消費リソースが増し、配備されるコンテナグループの数の増加に応じて、消費リソース量が過大になり得る。また、コントロールプレーン７０も、制御対象のサイドカーの数に応じて、消費リソース量が増大する。例えば、１０００個のサービスおよび２０００個のサイドカーの実行に対するコントロールプレーン７０の消費リソース量は、１ＣＰＵおよびメモリ１．５ＧＢ程度である。なお、各ポッドやコントロールプレーン７０に割り当てられるＣＰＵは、仮想ＣＰＵ（ｖＣＰＵ：virtual CPU）でもよい。

そこで、管理サーバ１００は、ＧＷ経由の通信方法と異種サイドカーを共存させる通信方法とを使い分ける機能を提供する。
図９は、管理サーバの機能例を示す図である。

管理サーバ１００は、記憶部１１０、基準遅延時間計算部１２０、遅延時間計算部１３０および設定変更処理部１４０を有する。記憶部１１０には、ＲＡＭ１０２やＨＤＤ１０３の記憶領域が用いられる。基準遅延時間計算部１２０、遅延時間計算部１３０および設定変更処理部１４０は、ＲＡＭ１０２に記憶されたプログラムをＣＰＵ１０１が実行することで実現される。

記憶部１１０は、各種のサイドカーの処理による遅延時間に関して、当該サイドカーの提供元などにより公開されている性能情報を記憶する。性能情報は、各種のサイドカーについて、単位時間当たりの所定のリクエスト数に応じた遅延時間の情報を含む。性能情報は、例えば該当のサイドカーの提供元ベンダなどのＷｅｂページから取得可能である。本例では、単位時間を１秒とする。記憶部１１０は、当該性能情報を基に、基準遅延時間計算部１２０により計算された基準遅延時間の情報を記憶する。また、記憶部１１０は、現状のリクエスト数に対して各サイドカーに対して計算された遅延時間の情報を記憶する。

基準遅延時間計算部１２０は、性能情報に含まれる、所定のリクエスト数／ｓに応じた遅延時間の情報に基づいて、各ポッドのリクエスト送信に係る基準遅延時間を計算する。なお、リクエスト数／ｓは、１秒当たりのリクエスト数を示す。サイドカーによる通信の遅延時間は、送信するリクエスト数／ｓに比例して大きくなる。基準遅延時間計算部１２０は、あるポッドに関し、本来の単一のサイドカーを用いて、現状のリクエスト数／ｓで送信する場合の遅延時間を、当該ポッドに対する基準遅延時間として計算する。

遅延時間計算部１３０は、各ポッドが異種のサイドカー宛に送信するリクエストの数／ｓを基に、当該リクエストをＧＷ経由で送信する場合の遅延時間を計算する。リクエストをＧＷ経由で送信する場合、遅延時間計算部１３０は、リクエスト送信元のポッドのサイドカーにおける遅延時間と、ゲートウェイ９００のサイドカー９１０，９２０それぞれにおける遅延時間とを加算することで、ＧＷ経由の場合の遅延時間を計算する。

設定変更処理部１４０は、各ポッドについて、基準遅延時間計算部１２０が計算した基準遅延時間と、遅延時間計算部１３０が計算した遅延時間とを比較し、該当のポッドから異種のサイドカー宛のリクエストの送信に用いる通信方法を選択する。ＧＷ経由の場合の遅延時間が基準遅延時間より小さい場合、設定変更処理部１４０は、ＧＷ経由の通信方法を選択する。一方、ＧＷ経由の場合の遅延時間が基準遅延時間以上の場合、設定変更処理部１４０は、異種サイドカーを共存させる通信方法を選択する。設定変更処理部１４０は、選択した通信方法に応じて、マスターノード２００にポッドの構成変更を指示する。後述されるように、ポッドの構成変更は、新たなサイドカーの追加や既存のサイドカーの削除を伴う。例えば、設定変更処理部１４０は、ポッド６００に対する新たなサイドカーの追加や既存のサイドカーの削除に応じて、マスターノード２００が保持する、ポッド６００に対応するイメージデータを変更する。当該イメージデータは、マスターノード２００によりポッド６００の配備に用いられる。

また、ポッド６００からポッド７００宛のリクエストの送信のためにＧＷ経由を選択した場合、設定変更処理部１４０は、当該リクエストをゲートウェイ９００に送信するルーティング設定をポッド６００に行う。なお、後述されるように、設定変更処理部１４０は、ポッド６００の中に、ＧＷ経由でリクエストを送信するためのＩｓｔｉｏサイドカーを、サイドカー６２０とは別個に設けてもよい。

また、ポッド６００からポッド７００宛のリクエストの送信のために、異種サイドカーの共存を選択した場合、設定変更処理部１４０は、サイドカー６３０をポッド６００に追加する。そして、設定変更処理部１４０は、ポッド６００からポッド７００宛のリクエストを、サイドカー６３０を用いて送信するルーティング設定をポッド６００に行う。

例えば、設定変更処理部１４０は、ワーカーノード上に新規のポッドが追加される場合または所定の周期で、新規のポッドが用いる通信方法の設定や、既存のポッドが用いる通信方法の再設定を行う。所定の周期は、例えば、１時間または１日などである。通信方法の再設定により、既存のポッドについて、ＧＷ経由の通信方法から異種サイドカーを共存させる通信方法に変更されることもあるし、逆に、異種サイドカーを共存させる通信方法からＧＷ経由の通信方法に変更されることもある。

なお、ＧＷ経由および異種サイドカーの共存の選択に応じて通信方法を変更する場合、ポッドにサイドカーを追加したり、ポッドからサイドカーを削除したりする構成変更を伴う。この場合、設定変更処理部１４０は、ポッドの再配備、すなわち、ポッドのアンデプロイ、および、構成変更後のポッドのデプロイといった手順を、マスターノード２００に指示する。例えば、設定変更処理部１４０は、同じサービスを実行する複数のポッドが存在する場合、ローリングアップデートやブルーグリーンデプロイメントを行うことで、サービスを停止させずに、ポッドの再配備を行ってもよい。

図１０は、サイドカー情報テーブルの例を示す図である。
サイドカー情報テーブル１１１は、記憶部１１０に予め格納される。サイドカー情報テーブル１１１は、各種のサイドカーの提供元により公開される性能情報である。サイドカー情報テーブル１１１は、サイドカータイプ、項目名および値の項目を含む。サイドカータイプの項目には、サイドカーの種類が登録される。項目名の項目には、性能の項目名が登録される。値の項目には、性能値が登録される。

例えば、サイドカー情報テーブル１１１は、サイドカータイプ「Ｉｓｔｉｏ」、項目名「１０００ｒｅｑ／ｓ時の使用リソース」、値「ＣＰＵ：０．３５、メモリ：４０ＭＢ」のレコードを有する。当該レコードは、Ｉｓｔｉｏサイドカーでは、１秒当たりに送信するリクエスト数が１０００の場合、ＣＰＵを０．３５個、メモリ（ＲＡＭ）を４０ＭＢ（Mega Bytes）使用することを示す。

また、サイドカー情報テーブル１１１は、サイドカータイプ「Ｉｓｔｉｏ」、項目名「１０００ｒｅｑ／ｓ時の遅延時間」、値「２．６５ｍｓ」のレコードを有する。当該レコードは、Ｉｓｔｉｏサイドカーでは、１秒当たりに送信するリクエスト数が１０００の場合、２．６５ｍｓ（ミリ秒）の遅延が発生することを示す。

また、サイドカー情報テーブル１１１は、サイドカータイプ「Ｄａｐｒ」、項目名「１０００ｒｅｑ／ｓ時の使用リソース」、値「ＣＰＵ：０．４８、メモリ：２３ＭＢ」のレコードを有する。当該レコードは、Ｄａｐｒサイドカーでは、１秒当たりに送信するリクエスト数が１０００の場合、ＣＰＵを０．４８個、メモリを２３ＭＢ使用することを示す。

また、サイドカー情報テーブル１１１は、サイドカータイプ「Ｄａｐｒ」、項目名「１０００ｒｅｑ／ｓ時の遅延時間」、値「１．４０ｍｓ」のレコードを有する。当該レコードは、Ｄａｐｒサイドカーでは、１秒当たりに送信するリクエスト数が１０００の場合、１．４０ｍｓの遅延が発生することを示す。

サイドカー情報テーブル１１１にはＩｓｔｉｏやＤａｐｒ以外の種類のサイドカーについても当該サイドカーの提供元により公開されている使用リソースや遅延時間の情報が登録され得る。

図１１は、リクエスト数テーブルの例を示す図である。
リクエスト数テーブル１１２は、送信元のサービスから宛先のサービスに送信された単位時間当たりのリクエスト数の平均値（リクエスト数／ｓ）が記録された情報である。リクエスト数テーブル１１２の情報は、基準遅延時間計算部１２０によりマスターノード２００から取得され、記憶部１１０に格納される。

リクエスト数テーブル１１２は、送信元、宛先およびリクエスト数／ｓの項目を含む。送信元の項目には、送信元のポッドの識別情報として、送信元のポッドにおけるサービスの識別名が登録される。宛先の項目には、宛先のポッドにおけるサービスの識別名が登録される。リクエスト数／ｓの項目には、送信元から宛先に対して１秒当たりに送信されるリクエスト数の平均値が登録される。当該平均値は、例えば、直近の所定期間に送信元から宛先に対して送信されたリクエストの数に基づいて取得される。

例えば、リクエスト数テーブル１１２は、送信元「Ａｐｐ１」、宛先「Ａｐｐ２」、リクエスト数／ｓ「３００」のレコードを有する。当該レコードは、ポッド６００からポッド７００に対して、毎秒３００個のリクエストが送信されることを示す。

また、リクエスト数テーブル１１２は、送信元「Ａｐｐ１」、宛先「Ａｐｐ３」、リクエスト数／ｓ「７００」のレコードを有する。当該レコードは、ポッド６００からポッド８００に対して、毎秒７００個のリクエストが送信されることを示す。

リクエスト数テーブル１１２には、送信元および宛先の他の組に対してもリクエスト数／ｓが登録され得る。
図１２は、基準遅延時間テーブルの例を示す図である。

基準遅延時間テーブル１１３は、基準遅延時間計算部１２０によりリクエスト数テーブル１１２に基づいて生成され、記憶部１１０に格納される。基準遅延時間テーブル１１３は、送信元、タイプおよび基準遅延時間の項目を含む。送信元の項目には、送信元のポッドにおけるサービスの識別名が登録される。タイプの項目には、当該ポッドで動作するサイドカーの種類が登録される。基準遅延時間の項目には、当該ポッドから宛先のポッドへリクエストを送信する場合の基準遅延時間が登録される。

例えば、基準遅延時間テーブル１１３は、送信元「Ａｐｐ１」、タイプ「Ｉｓｔｉｏ」、基準遅延時間「２．６５ｍｓ」のレコードを有する。当該レコードは、ポッド６００のサイドカーの種類が「Ｉｓｔｉｏ」であり、基準遅延時間が２．６５ｍｓであることを示す。

ここで、基準遅延時間計算部１２０は、リクエスト数テーブル１１２に基づいて、次のようにポッド６００に対する基準遅延時間を計算する。まず、基準遅延時間計算部１２０は、リクエスト数テーブル１１２に基づいて、ポッド６００が単位時間当たりに送信する総リクエスト数を計算する。具体的には、基準遅延時間計算部１２０は、ポッド６００が送信する総リクエスト数／ｓ＝３００＋７００＝１０００個／ｓと計算する。

そして、基準遅延時間計算部１２０は、サイドカー情報テーブル１１１に基づき、ポッド６００が元々有する単一のサイドカー６２０を用いて当該総リクエスト数／ｓで送信する場合の遅延時間を、基準遅延時間として計算する。具体的には、サイドカーの遅延時間は、送信するリクエスト数／ｓに比例して大きくなる。サイドカー６２０の種類はＩｓｔｉｏである。サイドカー情報テーブル１１１によれば、Ｉｓｔｉｏサイドカーの「１０００ｒｅｑ／ｓ時の遅延時間」は２．６５ｍｓである。ここで、サイドカー情報テーブル１１１の「１０００ｒｅｑ／ｓ時の遅延時間」における「１０００ｒｅｑ／ｓ」をＡと表記し、ポッド６００に対して基準遅延時間計算部１２０が計算した総リクエスト数／ｓをＢと表記する。基準遅延時間計算部１２０は、ポッド６００に対する基準遅延時間を、（Ｂ／Ａ）＊２．６５＝（１０００／１０００）＊２．６５＝２．６５ｍｓと計算する。

基準遅延時間テーブル１１３には、他のポッドに対しても、基準遅延時間が登録され得る。
図１３は、サービスメッシュタイプテーブルの例を示す図である。

サービスメッシュタイプテーブル１１４は、基準遅延時間計算部１２０によりマスターノード２００から取得され、記憶部１１０に格納される。サービスメッシュタイプテーブル１１４は、ポッドおよびタイプの項目を含む。ポッドの項目には、ポッドにおけるサービスの識別名が登録される。タイプの項目には、当該ポッドで使用されるサービスメッシュタイプ、すなわち、サービスメッシュに使用されるサイドカーの種類が登録される。

例えば、サービスメッシュタイプテーブル１１４は、ポッド「Ａｐｐ１」、タイプ「Ｉｓｔｉｏ」のレコードを有する。当該レコードは、ポッド６００のサイドカーの種類が「Ｉｓｔｉｏ」であることを示す。

サービスメッシュタイプテーブル１１４には、ポッド７００のサイドカーの種類が「Ｄａｐｒ」であることを示すレコードや、ポッド８００のサイドカーの種類が「Ｉｓｔｉｏ」であることを示すレコードも登録される。

図１４は、サービスメッシュタイプ別リクエスト数テーブルの例を示す図である。
サービスメッシュタイプ別リクエスト数テーブル１１５は、遅延時間計算部１３０により、リクエスト数テーブル１１２およびサービスメッシュタイプテーブル１１４に基づいて生成され、記憶部１１０に格納される。サービスメッシュタイプ別リクエスト数テーブル１１５は、送信元、送信元タイプ、宛先タイプおよびリクエスト数／ｓの項目を含む。

送信元の項目には、送信元のポッドにおけるサービスの識別名が登録される。送信元タイプの項目には、送信元のポッドにおけるサイドカーの種類が登録される。宛先タイプの項目には、宛先のポッドにおけるサイドカーの種類が登録される。リクエスト数／ｓの項目には、送信元のポッドから宛先のポッドへ送信される１秒あたりのリクエスト数が登録される。

例えば、サービスメッシュタイプ別リクエスト数テーブル１１５は、送信元「Ａｐｐ１」、送信元タイプ「Ｉｓｔｉｏ」、宛先タイプ「Ｄａｐｒ」、リクエスト数／ｓ「３００」のレコードを有する。当該レコードは、ポッド６００から宛先タイプがＤａｐｒのサイドカーを有するポッド７００へ３００個／ｓのリクエストが送信されることを示す。

また、サービスメッシュタイプ別リクエスト数テーブル１１５は、送信元「Ａｐｐ１」、送信元タイプ「Ｉｓｔｉｏ」、宛先タイプ「Ｉｓｔｉｏ」、リクエスト数／ｓ「７００」のレコードを有する。当該レコードは、ポッド６００から宛先タイプがＩｓｔｉｏのサイドカーを有するポッド８００へ７００個／ｓのリクエストが送信されることを示す。

サービスメッシュタイプ別リクエスト数テーブル１１５には、送信元の他のポッドに対しても、宛先タイプ毎に、単位時間当たりのリクエスト数が登録され得る。
図１５は、ＧＷ経由遅延時間テーブルの例を示す図である。

ＧＷ経由遅延時間テーブル１１６は、遅延時間計算部１３０によりサービスメッシュタイプ別リクエスト数テーブル１１５に基づいて生成され、記憶部１１０に格納される。ＧＷ経由遅延時間テーブル１１６は、ポッド、送信元タイプ、宛先タイプおよび遅延時間の項目を含む。

ポッドの項目には、送信元のポッドにおけるサービスの識別名が登録される。送信元タイプの項目には、送信元のポッドにおけるサイドカーの種類が登録される。宛先タイプの項目には、宛先のポッドにおけるサイドカーの種類が登録される。遅延時間の項目には、送信元のポッドから宛先のポッドへ、ゲートウェイ９００を経由してリクエストを送信する場合の遅延時間が登録される。

例えば、ＧＷ経由遅延時間テーブル１１６は、ポッド「Ａｐｐ１」、送信元タイプ「Ｉｓｔｉｏ」、宛先タイプ「Ｄａｐｒ」、遅延時間「２．０１ｍｓ」のレコードを有する。当該レコードは、ポッド６００からポッド７００へのリクエストを、ゲートウェイ９００を経由して送信する場合の遅延時間が２．０１ｍｓであることを示す。

ここで、遅延時間計算部１３０は、ポッド６００からポッド７００へＧＷ経由でリクエストを送信する場合の遅延時間を次のように計算する。
まず、遅延時間計算部１３０は、サービスメッシュタイプ別リクエスト数テーブル１１５に基づいて、ポッド６００のサイドカーの種類「Ｉｓｔｉｏ」に対して、宛先のサイドカーの種類「Ｄａｐｒ」が存在することを特定する。したがって、遅延時間計算部１３０は、ＧＷ経由のリクエスト送信では、ＩｓｔｉｏサイドカーおよびＤａｐｒサイドカーを有するゲートウェイを経由すると特定する。また、遅延時間計算部１３０は、サービスメッシュタイプ別リクエスト数テーブル１１５に基づいて、ポッド６００からＤａｐｒサイドカーへのリクエスト数が３００個／ｓであることを特定する。

この場合、ポッド６００からＤａｐｒサイドカーをもつポッドへ送信されたリクエストは、ポッド６００のＩｓｔｉｏサイドカー、ゲートウェイのＩｓｔｉｏサイドカーおよびゲートウェイのＤａｐｒサイドカーを経由して、宛先のポッドに到達する。したがって、遅延時間計算部１３０は、サイドカー情報テーブル１１１に基づき、（３００／１０００）＊２．６５＋（３００／１０００）＊２．６５＋（３００／１０００）＊１．４０＝２．０１ｍｓを、ＧＷ経由の遅延時間として計算する。

なお、上記の計算例では、１つのゲートウェイが１つの送信元のポッドからのリクエストを中継する場合を示しているが、１つのゲートウェイは、複数の送信元のポッドからのリクエストを中継し得る。１つのゲートウェイが複数の送信元のポッドからのリクエストを中継する場合、遅延時間計算部１３０は、上記の計算式において、ゲートウェイのサイドカーに係る遅延時間の項では、当該ゲートウェイが中継する総リクエスト数を用いる。

ＧＷ経由遅延時間テーブル１１６には、他のポッドに対しても、異種のサイドカーを有する宛先のポッドにリクエストを送信する場合のＧＷ経由の遅延時間が登録され得る。
図１６は、ＩＰアドレステーブルの例を示す図である。

ＩＰアドレステーブル１１７は、各ポッドのＩＰアドレスを示す情報である。ＩＰアドレステーブル１１７は、設定変更処理部１４０により生成される。設定変更処理部１４０は、マスターノード２００から各ポッドのＩＰアドレスを取得し、ＩＰアドレステーブル１１７に登録する。ＩＰアドレステーブル１１７は、ポッドおよびＩＰアドレスの項目を含む。ポッドの項目には、ポッドにおけるサービスの識別名が登録される。ＩＰアドレスの項目には、ＩＰアドレスが登録される。

例えば、ＩＰアドレステーブル１１７は、ポッド「Ａｐｐ１」、ＩＰアドレス「１０．０．０．２」のレコードを有する。当該レコードは、ポッド６００のＩＰアドレスが１０．０．０．２であることを示す。ＩＰアドレステーブル１１７は、ポッド７００のＩＰアドレスが１０．０．０．３であることを示すレコードや、ポッド８００のＩＰアドレスが１０．０．０．４であることを示すレコードも有する。

図１７は、通信方法管理テーブルの例を示す図である。
通信方法管理テーブル１１８は、あるポッドから宛先のポッドへリクエストを送信する場合の通信方法の管理に用いられる情報である。通信方法管理テーブル１１８は、ポッド、宛先タイプおよび通信方法の項目を含む。

ポッドの項目には、ポッドにおけるサービスの識別名が登録される。宛先タイプの項目には、宛先のポッドがもつサイドカーの種類が登録される。通信方法の項目には、該当のポッドから宛先のポッドへのリクエストの送信に用いる通信方法が登録される。通信方法は、「ＧＷ」および「直接」がある。「ＧＷ」は、ＧＷ経由でリクエストを送信することを示す。「直接」は、ＧＷ経由ではなく、送信元のポッドのサイドカーから宛先のポッドのサイドカーへリクエストを直接送信することを示す。

例えば、通信方法管理テーブル１１８は、ポッド「Ａｐｐ１」、宛先タイプ「Ｄａｐｒ」、通信方法「ＧＷ」のレコードを有する。当該レコードは、ポッド６００からＤａｐｒサイドカーを有するポッド７００へのリクエストをＧＷ経由で送信することを示す。

また、通信方法管理テーブル１１８は、ポッド「Ａｐｐ１」、宛先タイプ「Ｉｓｔｉｏ」、通信方法「直接」のレコードを有する。当該レコードは、ポッド６００からＩｓｔｉｏサイドカーを有するポッド８００へのリクエストを直接送信することを示す。

なお、ポッド６００にＤａｐｒのサイドカー６３０を設け、サイドカー６３０を用いてポッド７００と直接通信する場合、ポッド「Ａｐｐ１」、宛先タイプ「Ｄａｐｒ」に対応する通信方法は「直接」となる。

通信方法管理テーブル１１８には、他のポッドについても、宛先タイプ毎の通信方法が登録され得る。
図１８は、ＧＷ経由およびサイドカー共存それぞれの通信経路の例を示す図である。

例えば、ポッド６００とポッド７００とがＧＷ経由で通信する場合、ゲートウェイ９００がポッド６００，７００の間を中継する。ポッド６００，８００の間は同種のサイドカー６２０，８２０により直接通信が可能である。

また、ポッド６００に対し、サイドカー６２０とは別個に、異なる種類のサイドカー６３０を追加してポッド７００との通信に用いるサイドカー共存の場合、ポッド６００，７００の間は同種のサイドカー６３０，７２０により直接通信が可能である。また、ポッド６００，８００の間は同種のサイドカー６２０，８２０により直接通信が可能である。

設定変更処理部１４０は、ポッド６００からポッド７００宛の単位時間当たりのリクエスト数に応じたＧＷ経由の場合の遅延時間と、基準遅延時間との比較に応じて、ポッド６００，７００の通信をＧＷ経由とするか、異種のサイドカー共存により行うかを選択する。コンテナ６１０には、複数の種類のサイドカーと連携するためのライブラリやＡＰＩ呼び出しのロジックなどが予め搭載される。

なお、設定変更処理部１４０は、ＧＷ経由を用いる場合、ポッド７００宛のリクエストをゲートウェイ９００に送信するサイドカー６２０ａを、サイドカー６２０とは別個に、ポッド６００に設ける。サイドカー６２０ａは、Ｉｓｔｉｏサイドカーである。サイドカー６２０は、前述のように、ポッド８００宛のリクエストを、サイドカー８２０に対して、直接送信する。このように、ゲートウェイ９００宛のリクエストを送信するサイドカー６２０ａを別個に設けることで、サイドカー６２０のみを用いてリクエストを転送するよりも、通信の遅延時間を低減できる。特に、設定変更処理部１４０は、サイドカー６２０とは別個にサイドカー６２０ａを設けることで、サイドカー共存での運用中にＧＷ経由の場合として事前に計算された遅延時間と、その後実際にＧＷ経由とした時の遅延時間との乖離を抑制できる。

ここで、サイドカーの消費リソース量は、単位時間に処理するリクエストの数が多いほど大きくなる。サイドカー６２０ａをサイドカー６２０とは別個に設けたとしても、サイドカー６２０，６２０ａそれぞれでリクエストを分担することになる。このため、サイドカー６２０，６２０ａの両方を動作させるためのポッド６００の消費リソース量は、サイドカー６２０単体とする場合よりやや増える程度に抑えられ、サイドカー６２０と異種のサイドカー６３０とを共存させる場合のリソース量よりも少なくなる。

なお、ポッド６００に、ＧＷ宛のサイドカー６２０ａを設けずに、サイドカー６２０単体により、ＧＷ宛およびポッド８００宛のリクエストの転送先を決定することも考えられる。この場合、例えば基準遅延時間計算部１２０は、図１２で説明した方法により計算した基準遅延時間（例えば、２．６５ｍｓという値）に１より大きい係数を乗じた値を、該当のポッドに対する基準遅延時間として決定する。また、遅延時間計算部１３０は、ＧＷ経由の場合の遅延時間を計算する際、ポッド６００が送信する総リクエスト数を用いて、サイドカー６２０による遅延時間を計算し、ゲートウェイ９００での遅延時間と合計して、ＧＷ経由の場合の遅延時間を求める。このように、管理サーバ１００は、サイドカー６２０ａを設けないようにすることもできる。また、ポッド６００において、サイドカー６２０単体により、ＧＷ宛とポッド８００宛の直接通信とを切り替える場合、設定変更処理部１４０は、リクエストの宛先に応じたリクエストの転送先の情報を、Ｉｓｔｉｏのコントロールプレーンを介して、サイドカー６２０に設定してもよい。

設定変更処理部１４０は、ＧＷ経由からサイドカー共存の方法に変更することもできるし、サイドカー共存の方法からＧＷ経由の方法に変更することもできる。例えば、ＧＷ経由の方法からサイドカー共存の方法に変更する場合、設定変更処理部１４０は、ポッド６００に追加するサイドカー６３０に対し、Ｄａｐｒのコントロールプレーンを介してポッド７００宛のリクエストの転送先の情報を設定してもよい。また、サイドカー共存の方法からＧＷ経由の方法に変更する場合、設定変更処理部１４０は、ポッド６００に追加するサイドカー６２０ａに対し、Ｉｓｔｉｏのコントロールプレーンを介して、ポッド７００宛のリクエストの転送先の情報を設定してもよい。更に、サイドカー共存の方法からＧＷ経由の方法に変更する場合、設定変更処理部１４０は、サイドカー９２０に対し、Ｄａｐｒのコントロールプレーンを介して、ポッド７００宛のリクエストの転送先の情報を設定してもよい。

次に、設定変更処理部１４０によるポッド６００内のルーティング設定を説明する。まず、サイドカー６２０ａを介してＧＷ経由でポッド７００へのリクエストを送信する場合のルーティング設定を説明する。

図１９は、ＧＷ経由時のルーティング設定の例を示す図である。
設定変更処理部１４０は、ポッド６００が保持するｉｐｔａｂｌｅｓの転送先テーブル６４０に、宛先ＩＰ毎の転送先のサイドカーを示す情報を登録する。転送先テーブル６４０は、コンテナ６１０によるリクエストの転送先の決定に用いられる。転送先テーブル６４０は、宛先ＩＰおよび転送先の項目を含む。

宛先ＩＰの項目には、リクエストの宛先となるポッドのＩＰアドレスが登録される。転送先の項目には、当該宛先に応じたリクエストの転送先のサイドカーを示す情報が登録される。ここで、転送先のサイドカーを示す情報は、ローカルホストアドレス「１２７．０．０．１」と、ポート番号との組となる。すなわち、ポッド６００内に存在するサイドカー６２０，６２０ａは、コンテナ６１０からは当該ポート番号によって区別される。一例では、サイドカー６２０ａに対応するポート番号は「９０００」である。サイドカー６２０に対応するポート番号は「９００１」である。

例えば、設定変更処理部１４０は、ＩＰアドレステーブル１１７に基づいて、Ｄａｐｒサイドカーを有する宛先のポッド７００のＩＰアドレス「１０．０．０．３」を取得する。そして、設定変更処理部１４０は、転送先テーブル６４０の宛先ＩＰの項目に「１０．０．０．３」を設定し、当該宛先ＩＰに対する転送先の項目に「１２７．０．０．１：９０００」を設定する。サイドカー６２０ａは、コントロールプレーン７０の制御により、コンテナ６１０から転送されたリクエストをゲートウェイ９００へ送信する。例えば、設定変更処理部１４０は、コントロールプレーン７０を介して、コンテナ６１０からのリクエストの転送先をゲートウェイ９００とするルール情報をサイドカー６２０ａに設定してもよい。

また、設定変更処理部１４０は、転送先テーブル６４０の宛先ＩＰの項目にデフォルトルート「０．０．０．０」を設定し、当該デフォルトルートに対する転送先の項目に「１２７．０．０．１：９００１」を設定する。これにより、宛先ＩＰアドレスが「１０．０．０．３」以外のリクエストは、コンテナ６１０からサイドカー６２０に転送される。

次に、サイドカー６３０を介してポッド７００へリクエストを直接送信する場合のルーティング設定を説明する。
図２０は、異なる種類のサイドカー共存時のルーティング設定の例を示す図である。

本例では、サイドカー６３０に対応するポート番号は「９００２」である。この場合、設定変更処理部１４０は、転送先テーブル６４０の宛先ＩＰ「１０．０．０．３」に対して、転送先「１２７．０．０．１：９００２」を設定する。サイドカー６３０は、Ｄａｐｒのコントロールプレーンの制御により、コンテナ６１０から転送されたリクエストをポッド７００へ送信する。例えば、設定変更処理部１４０は、Ｄａｐｒのコントロールプレーンを介して、コンテナ６１０からのリクエストの転送先をポッド７００とするルール情報をサイドカー６３０に設定してもよい。設定変更処理部１４０は、デフォルトルート「０．０．０．０」に対しては、図１９と同様に転送先「１２７．０．０．１：９００１」を設定する。

このように、設定変更処理部１４０は、ＧＷ経由とするか、または、異なる種類のサイドカー共存による直接送信とするかに応じて転送先テーブル６４０の設定変更を行うことで、コンテナ６１０によるリクエストの送信ルートを制御することができる。

なお、設定変更処理部１４０は、図１９，２０で例示したポッド６００に対する設定変更を、マスターノード２００を介して行うことができる。
次に、管理サーバ１００の処理手順を説明する。

図２１は、管理サーバの処理例を示すフローチャートである。
（Ｓ１０）基準遅延時間計算部１２０は、サービスメッシュ構成設計依頼を受信する。サービスメッシュ構成設計依頼は、新たなポッドが何れかのワーカーノードに配備される場合や、所定の周期で管理サーバ１００に入力される。

（Ｓ１１）基準遅延時間計算部１２０は、処理対象のポッドを１つ選択する。処理対象のポッドの選択候補は、既に動作中のポッドを含む。処理対象のポッドの選択候補は、新規ポッドが配備される場合、当該新規ポッドを含む。ステップＳ１１で選択された処理対象のポッドは、下記のステップにおいて該当ポッドと表記される。

（Ｓ１２）基準遅延時間計算部１２０は、該当ポッドが送信する宛先ごとのリクエスト数／ｓをマスターノード２００から取得し、リクエスト数テーブル１１２に登録する。基準遅延時間計算部１２０は、該当ポッドの宛先毎の送信リクエスト数／ｓを合算した総リクエスト数／ｓを計算する。

なお、基準遅延時間計算部１２０は、該当ポッドが新規ポッドの場合は、新規ポッドと同じサービスを実行する既存ポッドのリクエスト数の一部を新規ポッドに割り振るように新規ポッドが送信する宛先毎のリクエスト数／ｓを求めることが考えられる。例えば、あるサービスを実行する既存ポッドがｍ個で、新規ポッドの追加により、同サービスを実行するポッド数がｍ＋１個になる場合がある。この場合、基準遅延時間計算部１２０は、各既存ポッドの宛先毎のリクエスト数／ｓの和を（ｍ＋１）等分して既存ポッドおよび新規ポッドそれぞれの宛先毎のリクエスト数／ｓを求めてもよい。これにより、基準遅延時間計算部１２０は、新規ポッドおよび既存ポッドそれぞれに対し、新規ポッド追加後の宛先毎のリクエスト数／ｓを求めることができる。

また、該当ポッドが新規ポッドの場合で、新規ポッドと同じサービスを実行する既存ポッドが存在しない場合、基準遅延時間計算部１２０は、該当ポッドの宛先毎のリクエスト数／ｓを０とすることが考えられる。

（Ｓ１３）基準遅延時間計算部１２０は、ステップＳ１２で計算した総リクエスト数／ｓと、サイドカー情報テーブル１１１とに基づいて、該当ポッド内のサイドカーを経由する基準遅延時間を計算する。基準遅延時間の計算の対象となるサイドカーは、該当ポッドが元々利用する種類のサイドカー（デフォルトの種類のサイドカー）である。基準遅延時間計算部１２０は、計算した基準遅延時間を、基準遅延時間テーブル１１３に登録する。なお、ステップＳ１３において、基準遅延時間計算部１２０は、マスターノード２００から該当ポッドおよび宛先ポッドのサイドカーの種類を取得し、サービスメッシュタイプテーブル１１４に登録する。基準遅延時間計算部１２０は、サービスメッシュタイプテーブル１１４から該当ポッドのデフォルトの種類のサイドカーを特定し得る。

（Ｓ１４）遅延時間計算部１３０は、サービスメッシュタイプテーブル１１４に基づいて、宛先ポッドのサービスメッシュタイプ、すなわち、宛先ポッドのサイドカーの種類を取得する。遅延時間計算部１３０は、該当ポッドに関し、リクエスト数テーブル１１２に基づいて、宛先ポッドのサイドカーの種類ごとのリクエスト数を計算し、サービスメッシュタイプ別リクエスト数テーブル１１５に登録する。

（Ｓ１５）遅延時間計算部１３０は、サービスメッシュタイプ別リクエスト数テーブル１１５から該当ポッドに対する宛先ポッドを１つ選択し、宛先ポッドのサイドカーの種類が、該当ポッドと同一であるか否かを判定する。同一である場合、遅延時間計算部１３０は、ステップＳ１６に処理を進める。同一でない場合、遅延時間計算部１３０は、図２２のステップＳ１９に処理を進める。なお、宛先ポッドのサービスメッシュタイプは、サービスメッシュタイプ別リクエスト数テーブル１１５の宛先タイプに相当する。

（Ｓ１６）設定変更処理部１４０は、該当ポッドのｉｐｔａｂｌｅｓにおける転送先テーブルにおいて、サービスを実行するコンテナによるデフォルトルートの転送先を自身のサービスメッシュ用サイドカーに設定する。自身のサービスメッシュ用サイドカーは、該当ポッドにおけるデフォルトの種類のサイドカーに相当する。

（Ｓ１７）設定変更処理部１４０は、該当ポッドの宛先の全サービスメッシュタイプに対し、構成設計、すなわち、ステップＳ１５以降の処理が完了したか否かを判定する。未処理のサービスメッシュタイプがある場合、設定変更処理部１４０は、ステップＳ１５に処理を進める。該当ポッドの宛先の全サービスメッシュタイプについて構成設計が完了した場合、設定変更処理部１４０は、ステップＳ１８に処理を進める。

（Ｓ１８）設定変更処理部１４０は、処理対象候補の全ポッドに対して、構成設計の処理が完了したか否かを判定する。全ポッドに対して構成設計の処理を完了した場合、設定変更処理部１４０は当該処理を終了する。未処理のポッドがある場合、設定変更処理部１４０は、ステップＳ１１に処理を進める。

図２２は、管理サーバの続きの処理例を示すフローチャートである。
（Ｓ１９）遅延時間計算部１３０は、サイドカー情報テーブル１１１およびサービスメッシュタイプ別リクエスト数テーブル１１５に基づいて、該当ポッドから宛先ポッドに対するＧＷ経由の場合の遅延時間を計算する。遅延時間計算部１３０は、計算した遅延時間を、ＧＷ経由遅延時間テーブル１１６に登録する。

（Ｓ２０）設定変更処理部１４０は、基準遅延時間テーブル１１３およびＧＷ経由遅延時間テーブル１１６に基づいて、該当ポッドから宛先ポッドに対するＧＷ経由の場合の遅延時間が、該当ポッドの基準遅延時間より小さいか否かを判定する。ＧＷ経由の場合の遅延時間が、該当ポッドの基準遅延時間より小さい場合、設定変更処理部１４０は、図２３のステップＳ２７に処理を進める。ＧＷ経由の場合の遅延時間が、該当ポッドの基準遅延時間以上の場合、設定変更処理部１４０は、ステップＳ２１に処理を進める。

（Ｓ２１）設定変更処理部１４０は、宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに既に存在するか否かを判定する。宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに既に存在する場合、設定変更処理部１４０は、ステップＳ２５に処理を進める。宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに存在しない場合、設定変更処理部１４０は、ステップＳ２２に処理を進める。

なお、設定変更処理部１４０は、該当ポッドに存在するサイドカーと当該サイドカーの種類とを示す情報を、マスターノード２００に問い合わせることで取得することができる。また、設定変更処理部１４０は、通信方法管理テーブル１１８に該当ポッドのレコードが登録済の場合、当該レコードに基づいて、該当ポッドに存在するサイドカーと当該サイドカーの種類とを取得してもよい。

（Ｓ２２）設定変更処理部１４０は、該当ポッドにＧＷ宛サイドカーが既に存在するか否かを判定する。該当ポッドにＧＷ宛サイドカーが既に存在する場合、設定変更処理部１４０は、ステップＳ２３に処理を進める。該当ポッドにＧＷ宛サイドカーが存在しない場合、設定変更処理部１４０は、ステップＳ２４に処理を進める。

（Ｓ２３）設定変更処理部１４０は、該当ポッドに対して、宛先ポッドのサービスメッシュタイプ用のサイドカーの作成およびＧＷ宛サイドカーの削除を行う。すなわち、設定変更処理部１４０は、マスターノード２００に該当ポッドのアンデプロイを指示し、宛先ポッドのサービスメッシュタイプ用のサイドカーの作成およびＧＷ宛サイドカーの削除後の該当ポッドのデプロイを、マスターノード２００に指示する。これにより、何れかのワーカーノードに、該当ポッドが再配備され、該当ポッドが起動する。そして、設定変更処理部１４０は、ステップＳ２５に処理を進める。

（Ｓ２４）設定変更処理部１４０は、該当ポッドに対して、宛先ポッドのサービスメッシュタイプ用のサイドカーの作成を行う。すなわち、設定変更処理部１４０は、マスターノード２００に該当ポッドのアンデプロイを指示し、宛先ポッドのサービスメッシュタイプ用のサイドカーの作成後の該当ポッドのデプロイを、マスターノード２００に指示する。これにより、何れかのワーカーノードに、該当ポッドが再配備され、該当ポッドが起動する。そして、設定変更処理部１４０は、ステップＳ２５に処理を進める。

（Ｓ２５）設定変更処理部１４０は、該当ポッドに対応する宛先ポッドのＩＰアドレスをマスターノード２００から取得し、ＩＰアドレステーブル１１７に登録する。
（Ｓ２６）設定変更処理部１４０は、ＩＰアドレステーブル１１７に基づいて、宛先ポッドのＩＰアドレスの転送先を、宛先ポッドのサービスメッシュタイプ用サイドカーに設定する。すなわち、設定変更処理部１４０は、該当ポッドのサービスを実行するコンテナから宛先ポッドのＩＰアドレスへのリクエストを、当該コンテナから宛先ポッドのサービスメッシュタイプ用サイドカーへ転送する設定を、該当ポッドのｉｐｔａｂｌｅｓに設定する。また、設定変更処理部１４０は、通信方法管理テーブル１１８に該当ポッドの通信方法のレコードを登録する。そして、設定変更処理部１４０は、図２１のステップＳ１７に処理を進める。

図２３は、管理サーバの続きの処理例を示すフローチャートである。
（Ｓ２７）設定変更処理部１４０は、該当ポッドから宛先ポッドのサービスメッシュタイプへのリクエストを中継するゲートウェイ（ＧＷ）が既に存在するか否かを判定する。当該ゲートウェイが既に存在する場合、設定変更処理部１４０は、ステップＳ２９に処理を進める。当該ゲートウェイが存在しない場合、設定変更処理部１４０は、ステップＳ２８に処理を進める。

（Ｓ２８）設定変更処理部１４０は、ゲートウェイの作成を行う。具体的には、設定変更処理部１４０は、該当ポッドのサービスメッシュタイプから宛先ポッドのサービスメッシュタイプへのリクエストを中継するゲートウェイとして機能するポッドの配備を、マスターノード２００に指示する。これにより、何れかのワーカーノードにゲートウェイのポッドが配備され、起動する。

（Ｓ２９）設定変更処理部１４０は、宛先ポッドのＩＰアドレスをマスターノード２００から取得し、ＩＰアドレステーブル１１７に登録する。
（Ｓ３０）設定変更処理部１４０は、該当ポッドにＧＷ宛サイドカーが既に存在するか否かを判定する。該当ポッドにＧＷ宛サイドカーが既に存在する場合、設定変更処理部１４０は、ステップＳ３４に処理を進める。該当ポッドにＧＷ宛サイドカーが存在しない場合、設定変更処理部１４０は、ステップＳ３１に処理を進める。

（Ｓ３１）設定変更処理部１４０は、宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに既に存在するか否かを判定する。宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに既に存在する場合、設定変更処理部１４０は、ステップＳ３２に処理を進める。宛先ポッドのサービスメッシュタイプ用のサイドカーが該当ポッドに存在しない場合、設定変更処理部１４０は、ステップＳ３３に処理を進める。

（Ｓ３２）設定変更処理部１４０は、該当ポッドに対して、ＧＷ宛サイドカーの作成および宛先ポッドのサービスメッシュタイプ用のサイドカーの削除を行う。すなわち、設定変更処理部１４０は、マスターノード２００に該当ポッドのアンデプロイを指示し、ＧＷ宛サイドカーの作成および宛先ポッドのサービスメッシュタイプ用のサイドカーの削除後の該当ポッドのデプロイを、マスターノード２００に指示する。これにより、何れかのワーカーノードに、該当ポッドが再配備され、該当ポッドが起動する。そして、設定変更処理部１４０は、ステップＳ３４に処理を進める。

（Ｓ３３）設定変更処理部１４０は、該当ポッドに対して、ＧＷ宛サイドカーの作成を行う。すなわち、設定変更処理部１４０は、マスターノード２００に該当ポッドのアンデプロイを指示し、ＧＷ宛サイドカーの作成後の該当ポッドのデプロイを、マスターノード２００に指示する。これにより、何れかのワーカーノードに、該当ポッドが再配備され、該当ポッドが起動する。そして、設定変更処理部１４０は、ステップＳ３４に処理を進める。

（Ｓ３４）設定変更処理部１４０は、ＩＰアドレステーブル１１７に基づいて、宛先ポッドのＩＰアドレスの転送先を、ＧＷ宛サイドカーに設定する。すなわち、設定変更処理部１４０は、該当ポッドのサービスを実行するコンテナから宛先ポッドのＩＰアドレスへのリクエストを、ＧＷ宛サイドカーへ転送する設定を、該当ポッドのｉｐｔａｂｌｅｓに設定する。また、設定変更処理部１４０は、通信方法管理テーブル１１８に該当ポッドの通信方法のレコードを登録する。そして、設定変更処理部１４０は、図２１のステップＳ１７に処理を進める。

なお、上記の手順を行った結果、例えば、ゲートウェイ９００が何れのリクエストの中継にも用いられなくなることもある。この場合、設定変更処理部１４０は、ゲートウェイ９００のアンデプロイをマスターノード２００に指示し、ゲートウェイ９００をアンデプロイさせてもよい。また、設定変更処理部１４０は、ステップＳ２３，Ｓ２４，Ｓ３２，Ｓ３３の該当ポッドの再配備の際には、再配備前後で、該当ポッドのｉｐｔａｂｌｅｓの設定情報が保持されるように制御する。

また、設定変更処理部１４０は、１つのポッドについて、ステップＳ１５から、図２２，２３の手順を含むステップＳ１７までの処理を繰り返し行う場合がある。この場合、設定変更処理部１４０は、当該繰り返しの中でポッドの再配備を行わず、当該繰り返しが全て完了してから、すなわち、ステップＳ１７ ＹＥＳの直後に当該ポッドの再配備を１回行って、サイドカーに関する構成変更の全てを該当ポッドに反映させてもよい。そして、その後、設定変更処理部１４０は、宛先ポッドのＩＰアドレス毎の転送先のサイドカーを、該当ポッドのｉｐｔａｂｌｅｓに設定してもよい。

このようにして、管理サーバ１００は、あるポッドから異なる種類のサイドカーをもつ他のポッドへのリクエストを、ＧＷ経由で送信する方法と、送信元ポッドに宛先と同じ種類のサイドカーを設けて当該サイドカーを用いて直接送信する方法とを使い分ける。管理サーバ１００は、基準遅延時間と該当ポッドからＧＷ経由で送信する場合の遅延時間との比較により異種のプロキシコンテナ宛のリクエストをＧＷ経由とするか、直接送信とするかを選択することで、遅延時間の抑制と消費リソース量の抑制とを両立できる。

なお、各ポッドに対して、当該ポッドに対して許容される最大割当リソース量が予め定められていることがある。この場合、設定変更処理部１４０は、各ポッドの最大割当リソース量に基づいて、ＧＷ経由の送信とするか否かを決定してもよい。

図２４は、最大割当リソース量テーブルの例を示す図である。
最大割当リソース量テーブル１１９は、記憶部１１０に予め格納される。最大割当リソース量テーブル１１９は、ポッド、ＣＰＵおよびメモリの項目を含む。ポッドの項目には、該当のポッドにおけるサービスの識別名が登録される。ＣＰＵの項目には、該当のポッドに対するＣＰＵの最大割当量が登録される。メモリの項目には、該当のポッドに対するメモリの最大割当量が登録される。

例えば、最大割当リソース量テーブル１１９は、ポッド「Ａｐｐ１」、ＣＰＵ「３」、メモリ「２００ＭＢ」のレコードを有する。当該レコードは、ポッド６００に対する最大割当リソース量がＣＰＵ３個、メモリ２００ＭＢであることを示す。最大割当リソース量テーブル１１９には他のポッドに対する最大割当リソース量も登録され得る。

図２５は、最大割当リソース量に応じた通信方法の選択例を示す図である。
設定変更処理部１４０は、ＧＷ経由の場合の遅延時間が基準遅延時間より小さい場合でも、異種サイドカーをポッド６００に共存させた場合のポッド６００の総割当リソース量が、最大割当リソース量以下であれば、ポッド６００に異種サイドカーを共存させる。

例えば、ポッド６００におけるコンテナ６１０の消費リソース量はＣＰＵ２個であり、メモリ１００ＭＢである。また、サイドカー６２０の消費リソース量はＣＰＵ０．３５個であり、メモリ４０ＭＢである。更に、サイドカー６３０の消費リソース量はＣＰＵ０．４８個であり、メモリ２３ＭＢである。したがって、ポッド６００の総割当リソース量は、これらの合計であり、ＣＰＵ２．８３個、メモリ１６３ＭＢである。

設定変更処理部１４０は、最大割当リソース量テーブル１１９におけるポッド６００の最大割当リソース量と、総割当リソース量とを、ＣＰＵおよびメモリ毎に比較する。そして、ＣＰＵおよびメモリの両方について、総割当リソース量が最大割当リソース量以下の場合、設定変更処理部１４０は、ＧＷ経由ではなく、サイドカー共存による直接送信を選択する。ＣＰＵおよびメモリの少なくとも一方について、総割当リソース量が最大割当リソース量より大きい場合、設定変更処理部１４０は、ＧＷ経由の場合の遅延時間と基準遅延時間との比較に応じて、ＧＷ経由かサイドカー共存による直接送信かを選択する。

設定変更処理部１４０は、図２５の処理を行う場合、ステップＳ１９の直前に、該当ポッドについて総割当リソース量と最大割当リソース量との比較を行う。そして、総割当リソース量が最大割当リソース量以下の場合、設定変更処理部１４０は、ステップＳ２１に処理を進める。また、総割当リソース量が最大割当リソース量より大きい場合、設定変更処理部１４０は、ステップＳ２０に処理を進める。なお、設定変更処理部１４０は、ＧＷ経由の場合の遅延時間が基準遅延時間以上のとき、該当ポッドにサイドカーを共存させることになるが、その場合は、該当ポッドの総割当リソース量が最大割当リソース量を超えることを許容する。

このように、管理サーバ１００は、該当ポッドに対して許容されている割当リソース量に余裕がある場合には、ＧＷ経由ではなく、サイドカー共存によるリクエスト送信を選択することで、ポッド間の通信の遅延時間の低減を図ってもよい。

以上説明したように、管理サーバ１００は、例えば次の処理を実行する。
情報処理システム２は、第１の種類のプロキシコンテナを有する第１コンテナグループと第２の種類の第１プロキシコンテナを有する第２コンテナグループとを含む複数のコンテナグループを実行する。１つのコンテナグループには、サービスのコンテナと他のコンテナグループとの通信に用いられるプロキシコンテナとを含む複数のコンテナが属する。基準遅延時間計算部１２０は、第１コンテナグループから第１の種類のプロキシコンテナにより宛先のコンテナグループにリクエストを送信する際の基準の遅延時間である第１遅延時間を取得する。遅延時間計算部１３０は、第１コンテナグループから第２コンテナグループへのリクエストの数に基づいて第２遅延時間を計算する。第２遅延時間は、第１コンテナグループからのリクエストが互いに異なる種類のプロキシコンテナ間の通信を中継する第３コンテナグループを経由して第２コンテナグループに到達する場合の遅延時間である。設定変更処理部１４０は、第２遅延時間が第１遅延時間より小さい場合に、第１コンテナグループから第２コンテナグループへのリクエストを、第１の種類のプロキシコンテナを介して第３コンテナグループへ送信する設定を行う。設定変更処理部１４０は、第２遅延時間が第１遅延時間以上の場合に、第２の種類の第２プロキシコンテナを第１コンテナグループに追加する。また、設定変更処理部１４０は、第１コンテナグループから第２コンテナグループへのリクエストを、第２プロキシコンテナを介して第２コンテナグループへ送信する設定を行う。

これにより、管理サーバ１００は、複数の種類のプロキシコンテナが混在する環境において適切な通信方法を利用できる。また、基準遅延時間計算部１２０や遅延時間計算部１３０は、リクエスト数に基づいて遅延時間を計算することで、各プロキシコンテナ内での処理に応じた遅延時間の計測が難しい場合でも、当該遅延時間を適切に得ることができる。

第２遅延時間が第１遅延時間よりも小さい場合、ＧＷ経由で通信したとしても、情報処理システム２に対して期待される通信品質は満たされることになる。したがって、この場合、設定変更処理部１４０は、第１コンテナグループから第２コンテナグループへのリクエストを、ゲートウェイ、すなわち、第３コンテナグループ経由とすることで、消費リソース量の抑制を図れる。

一方、第２遅延時間が第１遅延時間以上の場合、ＧＷ経由での通信では、情報処理システム２に対して期待される通信品質は満たされないことになる。したがって、この場合、設定変更処理部１４０は、第１コンテナグループから第２コンテナグループへのリクエストをゲートウェイ、すなわち、第３コンテナグループを経由せずに、直接送信とすることで、遅延時間の抑制を図れる。

こうして、管理サーバ１００は、第１遅延時間と第２遅延時間との比較により異種のプロキシコンテナ宛のリクエストをゲートウェイ経由とするか、または、直接送信とするかを選択することで、遅延時間の抑制と消費リソース量の抑制とを両立することができる。

なお、ポッド６００は、第１コンテナグループの一例である。ポッド７００は、第２コンテナグループの一例である。ゲートウェイ９００は、第３コンテナグループの一例である。サイドカー６２０，６２０ａは、第１の種類のプロキシコンテナの一例である。サイドカー７２０は、第２の種類の第１プロキシコンテナの一例である。サイドカー６３０は、第２の種類の第２プロキシコンテナの一例である。

例えば、設定変更処理部１４０は、第２遅延時間が第１遅延時間より小さく、かつ、第１コンテナグループに第２プロキシコンテナが存在する場合、第２プロキシコンテナを第１コンテナグループから削除する。

これにより、管理サーバ１００は、不要なプロキシコンテナを第１コンテナグループから削除でき、第１コンテナグループによる消費リソース量を低減できる。
また、設定変更処理部１４０は、第２遅延時間が第１遅延時間より小さい場合に、リクエストを第３コンテナグループへ送信する第１の種類のプロキシコンテナを第１コンテナグループに追加する。そして、設定変更処理部１４０は、第２遅延時間が第１遅延時間以上であり、かつ、追加された第１の種類のプロキシコンテナが第１コンテナグループに存在する場合、追加された第１の種類のプロキシコンテナを第１コンテナグループから削除する。

これにより、管理サーバ１００は、第１コンテナグループから第３コンテナグループ経由のリクエスト送信の遅延時間を低減できる。また、管理サーバ１００は、不要なプロキシコンテナを第１コンテナグループから削除でき、第１コンテナグループによる消費リソース量を低減できる。なお、サイドカー６２０ａは、リクエストを第３コンテナグループへ送信する第１の種類のプロキシコンテナとして追加されたプロキシコンテナの一例である。

基準遅延時間計算部１２０は、第１遅延時間の取得では、第１コンテナグループから単位時間に送信される全てのリクエストの数に基づいて、第１遅延時間を計算する。例えば、基準遅延時間計算部１２０は、当該全てのリクエストを第１の種類のプロキシコンテナを用いて第３コンテナグループを経由せずに送信する場合に第１の種類のプロキシコンテナで発生する遅延時間を、第１遅延時間として計算してもよい。

これにより、管理サーバ１００は、第１の種類のプロキシコンテナを単体で用いてリクエストを直接送信する場合に生じる遅延時間よりも小さくなるように、コンテナグループ間の通信を制御できる。管理サーバ１００は、例えば第１の種類のプロキシコンテナで発生する遅延時間を、当該プロキシコンテナの提供元により公開されている、単位時間当たりの所定リクエスト数に応じた遅延時間から求めることができる。

また、第３コンテナグループは、第１の種類のプロキシコンテナと第２の種類のプロキシコンテナとを有する。第３コンテナグループは、第３コンテナグループに属する第１の種類のプロキシコンテナを用いて第１コンテナグループからリクエストを受信する。第３コンテナグループは、第３コンテナグループに属する第２の種類のプロキシコンテナを用いて第２コンテナグループに当該リクエストを転送する。

これにより、管理サーバ１００は、各種のプロキシコンテナを用いて、ゲートウェイとして機能する第３コンテナグループを容易に作成し、情報処理システム２に追加することができる。

遅延時間計算部１３０は、第２遅延時間の計算では、第１コンテナグループから第２コンテナグループへ単位時間に送信されるリクエストの数に基づいて、第２遅延時間を計算する。すなわち、遅延時間計算部１３０は、第１コンテナグループに属する第１の種類のプロキシコンテナ、第３コンテナグループに属する第１の種類のプロキシコンテナおよび第３コンテナグループに属する第２の種類のプロキシコンテナそれぞれで発生する遅延時間を計算する。遅延時間計算部１３０は、計算した各遅延時間の和を、第２遅延時間とする。

これにより、管理サーバ１００は、ゲートウェイとして機能する第３コンテナグループを経由する場合の遅延時間を適切に計算できる。管理サーバ１００は、例えば各プロキシコンテナで発生する遅延時間を、該当のプロキシコンテナの提供元により公開されている、単位時間当たりの所定リクエスト数に応じた遅延時間から求めることができる。

また、設定変更処理部１４０は、第１コンテナグループに対する最大割当リソース量を示す情報に基づいて、第１コンテナグループに第２の種類の第２プロキシコンテナを追加したときの第１コンテナグループの総割当リソース量と最大割当リソース量とを比較する。設定変更処理部１４０は、総割当リソース量が最大割当リソース量以下の場合は、第２遅延時間が第１遅延時間より小さい場合でも、第１コンテナグループに第２プロキシコンテナを追加する。そして、設定変更処理部１４０は、第１コンテナグループから第２コンテナグループへのリクエストを、第２プロキシコンテナを介して第２コンテナグループへ送信する設定を行う。

これにより、管理サーバ１００は、第１コンテナグループに割当可能なリソース量に余裕がある場合には、遅延時間の一層の低減を図れる。なお、最大割当リソース量テーブル１１９は、第１コンテナグループに対する最大割当リソース量を示す情報の一例である。

また、設定変更処理部１４０は、第２遅延時間が第１遅延時間より小さく、かつ、第３コンテナグループが情報処理システム２にない場合、第３コンテナグループを情報処理システム２に追加する。

これにより、管理サーバ１００は、ゲートウェイとして機能する第３コンテナグループを用いた通信経路を情報処理システム２に適切に設けることができる。
ここで、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、ＣＰＵ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体６３に記録できる。

例えば、プログラムを記録した記録媒体６３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体６３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

１ 情報処理システム
１０ 情報処理装置
１１ 記憶部
１２ 処理部
２０，３０，４０，５０ コンテナグループ
２１，３１，４１ コンテナ
２２，３２，４２，５１，５２ プロキシコンテナ

Claims (10)

1. 他のコンテナグループとの通信に用いられるプロキシコンテナを含む複数のコンテナが属するコンテナグループであって、第１の種類のプロキシコンテナを有する第１コンテナグループと第２の種類の第１プロキシコンテナを有する第２コンテナグループとを含む複数のコンテナグループを実行する情報処理システムについて、第１コンテナグループから前記第１の種類のプロキシコンテナにより宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間を取得し、
   前記第１コンテナグループからの前記リクエストが、互いに異なる種類のプロキシコンテナ間の通信を中継する第３コンテナグループを経由して前記第２コンテナグループに到達する場合の第２遅延時間を、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストの数に基づいて計算し、
   前記第２遅延時間が前記第１遅延時間より小さい場合に、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第１の種類のプロキシコンテナを介して前記第３コンテナグループへ送信する設定を行い、前記第２遅延時間が前記第１遅延時間以上の場合に、前記第２の種類の第２プロキシコンテナを前記第１コンテナグループに追加し、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第２プロキシコンテナを介して前記第２コンテナグループへ送信する設定を行う、
   処理をコンピュータに実行させるプログラム。
2. 前記第２遅延時間が前記第１遅延時間より小さく、かつ、前記第１コンテナグループに前記第２プロキシコンテナが存在する場合、前記第２プロキシコンテナを前記第１コンテナグループから削除する、
   処理を前記コンピュータに更に実行させる請求項１記載のプログラム。
3. 前記第２遅延時間が前記第１遅延時間より小さい場合に、前記リクエストを前記第３コンテナグループへ送信する前記第１の種類のプロキシコンテナを前記第１コンテナグループに追加し、
   前記第２遅延時間が前記第１遅延時間以上であり、かつ、追加された前記第１の種類のプロキシコンテナが前記第１コンテナグループに存在する場合、追加された前記第１の種類のプロキシコンテナを前記第１コンテナグループから削除する、
   処理を前記コンピュータに更に実行させる請求項１記載のプログラム。
4. 前記第１遅延時間の取得では、前記第１コンテナグループから単位時間に送信される全てのリクエストの数に基づいて、前記全てのリクエストを前記第１の種類のプロキシコンテナを用いて前記第３コンテナグループを経由せずに送信する場合に前記第１の種類のプロキシコンテナで発生する遅延時間を、前記第１遅延時間として計算する、
   処理を前記コンピュータに実行させる請求項１記載のプログラム。
5. 前記第３コンテナグループは、
   前記第１の種類のプロキシコンテナと前記第２の種類のプロキシコンテナとを有し、
   前記第３コンテナグループに属する前記第１の種類のプロキシコンテナを用いて前記第１コンテナグループから前記リクエストを受信し、前記第３コンテナグループに属する前記第２の種類のプロキシコンテナを用いて前記第２コンテナグループに前記リクエストを転送する、
   請求項１記載のプログラム。
6. 前記第２遅延時間の計算では、前記第１コンテナグループから前記第２コンテナグループへ単位時間に送信される前記リクエストの数に基づいて、前記第１コンテナグループに属する前記第１の種類のプロキシコンテナ、前記第３コンテナグループに属する前記第１の種類のプロキシコンテナおよび前記第３コンテナグループに属する前記第２の種類のプロキシコンテナそれぞれで発生する遅延時間を計算し、計算した各遅延時間の和を、前記第２遅延時間とする、
   処理を前記コンピュータに実行させる請求項５記載のプログラム。
7. 前記第１コンテナグループに対する最大割当リソース量を示す情報に基づいて、前記第１コンテナグループに前記第２プロキシコンテナを追加したときの前記第１コンテナグループの総割当リソース量と前記最大割当リソース量とを比較し、
   前記総割当リソース量が前記最大割当リソース量以下の場合は、前記第２遅延時間が前記第１遅延時間より小さい場合でも、前記第１コンテナグループに前記第２プロキシコンテナを追加し、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第２プロキシコンテナを介して前記第２コンテナグループへ送信する設定を行う、
   処理を前記コンピュータに更に実行させる請求項１記載のプログラム。
8. 前記第２遅延時間が前記第１遅延時間より小さく、かつ、前記第３コンテナグループが前記情報処理システムにない場合、前記第３コンテナグループを前記情報処理システムに追加する、
   処理を前記コンピュータに更に実行させる請求項１記載のプログラム。
9. コンピュータが、
   他のコンテナグループとの通信に用いられるプロキシコンテナを含む複数のコンテナが属するコンテナグループであって、第１の種類のプロキシコンテナを有する第１コンテナグループと第２の種類の第１プロキシコンテナを有する第２コンテナグループとを含む複数のコンテナグループを実行する情報処理システムについて、第１コンテナグループから前記第１の種類のプロキシコンテナにより宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間を取得し、
   前記第１コンテナグループからの前記リクエストが、互いに異なる種類のプロキシコンテナ間の通信を中継する第３コンテナグループを経由して前記第２コンテナグループに到達する場合の第２遅延時間を、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストの数に基づいて計算し、
   前記第２遅延時間が前記第１遅延時間より小さい場合に、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第１の種類のプロキシコンテナを介して前記第３コンテナグループへ送信する設定を行い、前記第２遅延時間が前記第１遅延時間以上の場合に、前記第２の種類の第２プロキシコンテナを前記第１コンテナグループに追加し、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第２プロキシコンテナを介して前記第２コンテナグループへ送信する設定を行う、
   情報処理方法。
10. 他のコンテナグループとの通信に用いられるプロキシコンテナを含む複数のコンテナが属するコンテナグループであって、第１の種類のプロキシコンテナを有する第１コンテナグループと第２の種類の第１プロキシコンテナを有する第２コンテナグループとを含む複数のコンテナグループを実行する情報処理システムについて、第１コンテナグループから前記第１の種類のプロキシコンテナにより宛先のコンテナグループへリクエストを送信する際の基準の遅延時間である第１遅延時間を記憶する記憶部と、
    前記第１コンテナグループからの前記リクエストが、互いに異なる種類のプロキシコンテナ間の通信を中継する第３コンテナグループを経由して前記第２コンテナグループに到達する場合の第２遅延時間を、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストの数に基づいて計算し、
    前記第２遅延時間が前記第１遅延時間より小さい場合に、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第１の種類のプロキシコンテナを介して前記第３コンテナグループへ送信する設定を行い、前記第２遅延時間が前記第１遅延時間以上の場合に、前記第２の種類の第２プロキシコンテナを前記第１コンテナグループに追加し、前記第１コンテナグループから前記第２コンテナグループへの前記リクエストを、前記第２プロキシコンテナを介して前記第２コンテナグループへ送信する設定を行う、処理部と、
    を有する情報処理装置。

Images