特許 7705203 マイクロサービス間通信の管理方法、システム、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-07-01

(45)【発行日】2025-07-09

(54)【発明の名称】マイクロサービス間通信の管理方法、システム、プログラム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20250702BHJP

【ＦＩ】

G06F9/50 150Z

【請求項の数】 12

(21)【出願番号】P 2023507298

(86)(22)【出願日】2021-07-27

(65)【公表番号】

(43)【公表日】2023-08-24

(86)【国際出願番号】 IB2021056793

(87)【国際公開番号】W WO2022029560

(87)【国際公開日】2022-02-10

【審査請求日】2023-12-12

(31)【優先権主張番号】16/985,265

(32)【優先日】2020-08-05

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】Ｎｅｗ Ｏｒｃｈａｒｄ Ｒｏａｄ， Ａｒｍｏｎｋ， Ｎｅｗ Ｙｏｒｋ １０５０４， Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(74)【代理人】

【識別番号】100120710

【弁理士】

【氏名又は名称】片岡 忠彦

(72)【発明者】

【氏名】チェンバレン、リチャード

(72)【発明者】

【氏名】ピルキントン、アダム、ジョン

(72)【発明者】

【氏名】ヘリヤー、ハワード

【審査官】田中 幸雄

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０３４９１２１（ＵＳ，Ａ１）

【文献】特開２０１０－２８２５３３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

コンピュータの情報処理による方法であって、
複数のマイクロサービス間で通信する要求を受信したことに応答して、複数のマイクロサービス間のトラフィックを監視することによってトラフィックの性質を判定することと、
前記複数のマイクロサービスのそれぞれを、前記監視されるトラフィックの前記判定された性質に基づいて、その個々のオリジン・リソースから共有リソースに再配置することと、
前記複数のマイクロサービスのそれぞれを再配置することが、前記複数のマイクロサービスのそれぞれに関して、前記マイクロサービスの第1のインスタンスをそのオリジン・リソースに維持し、前記マイクロサービスの第２のインスタンスを前記共有リソースで再開始し、前記マイクロサービスの第２のインスタンスをそのオリジン・リソースでシャット・ダウンすることと、
前記複数のマイクロサービスの複数のインスタンスは、異なるモードで実行され、前記複数のマイクロサービスのうちの第１のマイクロサービスの第１のインスタンス、および前記複数のマイクロサービスのうちの第２のマイクロサービスのインスタンスは、同一プロセス中にあり、前記第１のマイクロサービスの第２のインスタンスは、前記複数のマイクロサービスのうちの第3のマイクロサービスからのサービス要求の負荷を共有するために前記第２のインスタンスのオリジン・リソースに残ることと
を含む、方法。

【請求項2】

前記複数のマイクロサービスのそれぞれを再配置することが、
前記複数のマイクロサービスのそれぞれに関して、前記共有リソースで前記マイクロサービスを再開始し、前記マイクロサービスをそのオリジン・リソースでシャット・ダウンすること
を含む、請求項１に記載の方法。

【請求項3】

前記複数のマイクロサービスのそれぞれを再配置することが、
前記複数のマイクロサービスを、それらの個々のオリジン・リソースのそれぞれから前記共有リソースに集めることによって、前記複数のマイクロサービス間通信を再構成すること
を含む、請求項１に記載の方法。

【請求項4】

前記監視されるトラフィックの前記性質が、
前記複数のマイクロサービス間を移動中のデータの量、
前記複数のマイクロサービス間を移動中の前記データのタイプ、および
前記複数のマイクロサービス間を移動中の前記データのフロー・レート
のうちの少なくとも１つを含む、請求項１に記載の方法。

【請求項5】

前記オリジン・リソースおよび前記共有リソースのうちの少なくとも１つが、仮想リソースを含む、請求項１に記載の方法。

【請求項6】

前記仮想リソースが、
ノード、
ノードのポッド、
コンテナ、
ポッドのコンテナ、
プロセス、および
コンテナのプロセス
のうちの１つを含む、請求項５に記載の方法。

【請求項7】

前記複数のマイクロサービスのそれぞれを再配置することが、
前記監視されるトラフィックの前記性質が所定の要件を満足するかどうかを判定することと、
前記監視されるトラフィックの前記性質が前記所定の要件を満足することに応答して、前記複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから前記共有リソースに再配置することと
を含む、請求項１に記載の方法。

【請求項8】

前記所定の要件が、
データの量が所定のしきい値以上であること、
前記データのタイプが所定のタイプであること、および
前記データのフロー・レートが所定のしきい値以上であること
のうちの少なくとも１つを含む、請求項７に記載の方法。

【請求項9】

前記複数のマイクロサービス間のトラフィックを監視することが、
前記複数のマイクロサービス間で通信される要求を受信することと、
前記受信した要求に関連付けられるトラフィックを監視することと
を含む、請求項１に記載の方法。

【請求項10】

請求項１～９の何れか１項に記載の方法を、コンピュータに実行させる、コンピュータ・プログラム。

【請求項11】

請求項１０に記載の前記コンピュータ・プログラムをコンピュータ可読記憶媒体に記憶した、記憶媒体。

【請求項12】

請求項１～９の何れか１項に記載の方法を、コンピュータ・ハードウェアにより実行する、コンピュータ・システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般的にはマイクロサービス間通信に関し、より詳細には複数のマイクロサービス間通信の管理に関する。

【背景技術】

【0002】

従来のマイクロサービスは、ソフトウェア開発技術であり、具体的には、アプリケーションをサービスの集合として用意するサービス指向アーキテクチャ（ＳＯＡ）の構造上のスタイルの変形形態である。故に、マイクロサービス（すなわち、マイクロサービス・アーキテクチャ）は、単一のアプリケーションが多くの疎結合された、独立的にデプロイ可能な小規模コンポーネントまたはサービスから構成される、クラウドネイティブなアーキテクチャ手法を使用する。これらのサービスは、通常、データベースおよびデータ・モデルを含む自分自身のスタックを有し、ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒアプリケーション・プログラミング・インターフェース（ＲＥＳＴ ＡＰＩ）、イベント・ストリーミング、およびメッセージ・ブローカの組合せにより互いに通信する。サービスはまた、通常、ビジネス・ケイパビリティー別に編成され、サービスを区切る線は境界コンテキストと呼ばれることが多い。

【0003】

クラウド環境にデプロイされるマイクロサービスは、通常、クラウドＡＰＩを使用して、互いに通信する。このようなＡＰＩは、通常、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）のＲＥＳＴコールなどのＲＥＳＴコールとして実装される。単純なＲＥＳＴ機能に関して、この機能をサービスするために必要とされる処理のほとんどは、ＡＰＩコールを行うために使用される要求のマーシャリング、送信、およびアンマーシャリングを含む。マーシャリングとは、あるオブジェクトのメモリ表現を記憶または送信に好適なデータ・フォーマットに変換するプロセスを称し、これは通常、データがコンピュータ・プログラム／サービスの異なる部分の間を移動しなければならない場合、またはあるプログラム／サービスから別のプログラム／サービスに移動しなければならない場合に使用される。アンマーシャリングとは、データ・フォーマットを元のメモリ表現に変換することによって、データ・フォーマットをアンパックすることを称する。

【0004】

機能をサービスすることはまた、ＡＰＩコールがネットワーク上で行われる際、ＡＰＩコールを暗号化および復号化することを含んでもよい。結果として、ＨＴＴＰ ＲＥＳＴファンクション・コールを行うために実行される処理の大半は、アプリケーション・ロジックを使用する代わりに、余分なもしくは間接的なまたはその両方の計算時間、メモリ、帯域幅、あるいはタスクを実行するために必要とされる他のリソース（つまり、コンピューティングのオーバヘッド）によって実施される。

【0005】

クラウド・アプリケーションは、ノード（つまり、クラウド環境におけるワーカ・マシン）の親和性を使用して、ノードに関連付けられたラベルに基づいてポッド（つまり、クラスタ内の実行中コンテナのセットを表現するオブジェクト）をスケジューリングすることができるノードを制約することによって、ネットワーク・トラフィックを最小限に抑えることができる。しかしながら、データを、ＨＴＴＰメッセージへ／からマーシャリングおよびアンマーシャリングするオーバヘッドは、そのままである。加えて、ある組織のセキュリティ要件は、ＨＴＴＰトラフィックがネットワークをＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）として暗号化されて通過することを要求する場合があり、これは必要な処理オーバヘッドをさらに増大させる。

【発明の概要】

【0006】

本発明は、複数のマイクロサービス間通信を管理するためのコンピュータ実装方法を提供するよう試みる。

【0007】

本発明は、処理ユニットによって実行されると提案される方法を実装するための、コンピュータ・プログラム・コードを含むコンピュータ・プログラム製品を提供するようさらに試みる。

【0008】

本発明はまた、このコンピュータ・プログラム・コードを実行するように構成される処理システムを提供するよう試みる。

【0009】

本発明はまた、複数のマイクロサービス間通信を管理するためのシステムを提供するよう試みる。

【0010】

本発明の一態様によると、コンピュータ実装方法が提供される。方法は、複数のマイクロサービス間のトラフィックを監視して、トラフィックの性質を判定することを含む。方法は、監視されるトラフィックの判定された性質に基づいて、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置することを含む。

【0011】

本発明のさらに別の態様によると、コンピュータ・システムが提供される。システムは、複数のマイクロサービス間のトラフィックを監視して、トラフィックの性質を判定するように構成された監視ユニットを含む。システムは、監視されるトラフィックの判定された性質に基づいて、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置するように構成された再配置ユニットをさらに含む。

【0012】

本発明の別の態様によると、コンピュータ・プログラム製品が提供される。コンピュータ・プログラム製品は、プログラム命令が具体化されたコンピュータ可読記憶媒体を含み、処理ユニットによって実行可能なプログラム命令は、処理ユニットに、提案される実施形態に従って方法を実施させる。

【0013】

本発明の別の態様によると、実施形態に従って、少なくとも１つのプロセッサと、コンピュータ・プログラム製品とを含む処理システムが提供される。少なくとも１つのプロセッサは、前記コンピュータ・プログラム製品のコンピュータ・プログラム・コードを実行するように構成される。

【0014】

次に、単なる例として、以下の図面を参照して、本発明の好ましい実施形態を説明する。

【図面の簡単な説明】

【0015】

【図1】本発明の実施形態による、例示の分散システムの図的表現である。

【図2】本発明の実施形態による、例示的な実施形態の態様を実装することができる、例示のシステムのブロック図である。

【図3】本発明の実施形態による、複数のマイクロサービス間通信を管理するためのコンピュータ実装方法のフロー図である。

【図4】本発明の実施形態による、複数のマイクロサービス間通信を管理するためのシステムの例示の実施形態の簡略化されたブロック図である。

【図5】（Ａ）～（Ｅ）は、本発明の実施形態による、複数のマイクロサービス間通信の例示の簡略化されたブロック図である。

【図6】本発明の実施形態による、例示のシステムのブロック図である。

【発明を実施するための形態】

【0016】

図面は概略的に過ぎず、縮尺通りに描かれていないことを理解されたい。また、同一または類似の部分を示すために、同一の参照符号が図面全体で使用されることも理解されたい。

【0017】

本発明の実施形態が方法を構成する、本出願のコンテキストでは、そのような方法はコンピュータによる実行のためのプロセスであり得ること、つまり、コンピュータ実装方法であり得ることを理解されたい。したがって、方法の様々なステップは、コンピュータ・プログラムの様々な部分、例えば１つまたは複数のアルゴリズムの様々な部分を反映する場合がある。

【0018】

また、本出願のコンテキストでは、システムは、単一のデバイス、または本発明の方法の１つまたは複数の実施形態を実行するように構成された、分散デバイスの集合であってもよい。例えば、システムは、本発明の方法の少なくとも１つの実施形態を協働的に実行するための、パーソナル・コンピュータ（ＰＣ）、サーバもしくはＰＣの集合、またはローカル・エリア・ネットワーク、インターネットなどのネットワークを介して接続されたサーバ、あるいはその組合せであってもよい。

【0019】

複数のマイクロサービス間通信を管理するための概念が提案される。そのような概念により、自律的な負荷応答トランスポートおよびトポロジーの操作として、マイクロサービスを最適化することができる。したがって、実施形態は、アプリケーションの変更を必要とするのではなく、アプリケーションの実際のパフォーマンスに基づいて、複数のマイクロサービス間通信のための処理オーバヘッドの動的な削減を容易にすることができる。実施形態は、クラスタ周りでのマイクロサービスの自動的なマイグレーションをさらに容易にすることができる。

【0020】

そのような概念には、マイクロサービスを「ダウン」および「アップ」させる（つまり、マイクロサービスをシャット・ダウンする、および再開始する）一方で、マイクロサービスを再構成するという概念を伴うことができる。マイクロサービスは、マイクロサービス同士の通信に一般的なＡＰＩを使用してもよく、これはマイクロサービス間を移動するネットワーク・トラフィックに基づいて再構成することができる。マイクロサービスを再構成することによって、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ（ＨＴＴＰＳ）、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）、プロセス間通信、および直接ファンクション・コールによる通信間で、通信をやり取りすることができる。

【0021】

実施形態は、サービス間のファンクション・コール、生成されるＡＰＩ上で生じるトラフィックを監視する監視サービス（すなわち、監視ユニット）、およびサービスを「ダウン」および「アップ」させつつサービスがどのように通信するかを再構成する構成サービス（すなわち、再配置ユニット）を抽象化するための、ＡＰＩレイヤと併せて実装されてもよい。ＡＰＩレイヤは、別の高次仕様言語でのインターフェース仕様を含む文書化として生成されてもよい。生成されるＡＰＩレイヤは、複数のＡＰＩを含むことができ、サービス間のコールに使用されてもよい。生成されるＡＰＩは、監視サービスに使用状況（つまり、トラフィック）を自動的にレポートすることができる。

【0022】

実施形態は、ＡＰＩレイヤとしてＲＥＳＴコールを生成する概念、およびクラウド環境内で実行中の分散マイクロサービス環境内で結果として生じるサービス間トラフィックを分析する概念と併せてさらに実装されてもよい。サービス間で著しい量のトラフィックの移動が特定された場合、マイクロサービスは、シャット・ダウンして互いにより近いマイクロサービスを開始する（または、スケーリング・ダウンして、スケーリング・アップする）ことによって再構成される場合がある。

【0023】

提案される実施形態は、直接ＲＥＳＴコールの代わりに、具体的に生成されるＡＰＩレイヤを使用するためにサービスを適合する概念を採用することができる。結果として、生成されるＡＰＩレイヤは、ＡＰＩコールがどのように行われるかを変更することができる。サービスを同一マシンに再配置することにより、通信から暗号化と復号化のプロセスを除去することができる。サービスを同一コンテナに再配置することは、通信をプロセス間コールに変更することができる。サービスを同一プロセスに再配置することは、通信をプレーンなファンクション・コールに変更することができる。それぞれの場合で、それぞれのサービスについての具体的な情報の要件が低減されるように、サービスを「ブラック・ボックス」として扱うことができる。

【0024】

本発明の実施形態は、マイクロサービス間で送信されているメッセージからの情報が取得され、次いで（例えば、マイクロサービス間通信に必要な距離を低減することによって）マイクロサービスのそれぞれを再分配するために使用されることを認識する。したがって、本発明の実施形態は、このようなマイクロサービス同士を、その元のリソース（すなわち、オリジン・リソース）からマイクロサービスにより共有されるリソース（すなわち、共有リソース）に移動することによって、より近づけることができる。リソースを共有することによって、本発明の実施形態は、マイクロサービス間通信の複雑さを低減し、通信から取得した情報に基づく。そのようなものとして、マイクロサービス間通信の複雑な方法を必要としない情報は、マイクロサービスを近づけることによって、より単純な分散技術により送信することが可能である。

【0025】

提案される実施形態は、２つ以上のマイクロサービスが頻繁に対話する場合、ネットワークを使用する代わりにプロセス間通信を使用するために、２つ以上のコンテナを１つの共有ポッドに移動するという概念、または２つ以上のマイクロサービスを共有コンテナに移動する概念、あるいはその両方をさらに採用する場合がある。

【0026】

提案される実施形態では、複数のマイクロサービスのそれぞれを再配置することは、複数のマイクロサービスのそれぞれに関して、共有リソースでマイクロサービスを再開始し、マイクロサービスをそのオリジン・リソースでシャット・ダウンすることを含んでもよい。この方法では、複数のマイクロサービスは、複数のマイクロサービスのそれぞれによって使用されるリソースが、複数のマイクロサービス全体で共有されるように、互いに近づけられてもよい。結果的に、これは、複数のマイクロサービス間通信に必要とされる処理オーバヘッドを低減することができ、通信の効率が改善される場合がある。

【0027】

いくつかの実施形態では、複数のマイクロサービスのそれぞれを再配置することは、複数のマイクロサービスを、それらの個々のオリジン・リソースのそれぞれから共有リソースに集めることによって、複数のマイクロサービス間通信を再構成することを含む。この方法では、通信は、マイクロサービスが、複数のマイクロサービスのうちの別のマイクロサービスの機能を呼び出すことに関連する処理オーバヘッドを低減するように再構成されてもよい。

【0028】

提案される実施形態では、監視されるトラフィックの性質は、複数のマイクロサービス間を移動中のデータの量、複数のマイクロサービス間を移動中のデータのタイプ、および複数のマイクロサービス間を移動中のデータのフロー・レート、のうちの少なくとも１つを含んでもよい。この方法では、複数のマイクロサービスのそれぞれを再配置するかどうかを判定するために使用される、監視されるトラフィックの多様な性質のスコープは、大きくしてもよい。結果として、複数のマイクロサービスのそれぞれを再配置するためのベースとして用いられる監視されるトラフィックに関する情報が強化されるため、監視されるトラフィックの判定された性質に基づいて複数のマイクロサービスのそれぞれを再配置する有効性および信頼性が改善される場合がある。

【0029】

いくつかの実施形態では、オリジン・リソースおよび共有リソースのうちの少なくとも１つは、仮想リソースを含んでもよい。この方法では、マイクロサービスは、クラウド環境内に配置されてもよく、これはソフトウェア障害時の、可用性と回復の容易さとを改善することができる。このことは、マイクロサービスの管理の中央集権化を改善すること、およびアプリケーション同士の互換性を改善することをさらに可能にする場合がある。加えて、これによって、使用する物理的な機器を少なくすることによって、人件費、電力、および冷却を低減すること、ならびに仮想マシンによるハードウェア共有をアイドル状態の機器に低減することによって、ハードウェアの使用状況を改善することを可能にする。

【0030】

いくつかの実施形態では、仮想リソースは、ノード、ノードのポッド、コンテナ、ポッドのコンテナ、プロセス、およびコンテナのプロセスのうちの１つを含んでもよい。この方法では、複数のマイクロサービス間通信は、複数のマイクロサービス同士を近づけるよう再配置することによって再構成されてもよい。複数のマイクロサービスのそれぞれによって使用される多様な仮想リソースは、複数のマイクロサービスが近くに移動するため、レイテンシが低減された一連の抽象化を表現することができる。複数のマイクロサービスを別個のオリジン・リソースから共有された仮想リソースに再配置することによって、マイクロサービス間通信に必要とされる処理オーバヘッドの量が、低減され得る。

【0031】

いくつかの実施形態では、複数のマイクロサービスのそれぞれを再配置することには、監視されるトラフィックの性質が、所定の要件を満足するかどうかを判定することを含んでもよい。ステップは、監視されるトラフィックの性質が所定の要件を満足することに応答して、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置することをさらに含んでもよい。この方法では、複数のマイクロサービスのそれぞれを再配置する制御のしやすさが改善され得る。結果的に、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置する効率および信頼性を高めることができる。

【0032】

いくつかの実施形態では、所定の要件は、データの量が所定のしきい値以上であること、データのタイプが所定のタイプであること、およびデータのフロー・レートが所定のしきい値以上であることのうちの少なくとも１つを含んでもよい。この方法では、複数のマイクロサービスのそれぞれを再配置するかどうかを判定するために使用される、多様な所定の要件のスコープは、大きくしてもよい。結果として、監視されるトラフィックの判定された性質に基づいて複数のマイクロサービスのそれぞれを再配置する有効性および信頼性が改善される場合がある。

【0033】

提案される実施形態では、複数のマイクロサービス間のトラフィックを監視することは、複数のマイクロサービス間で通信される要求を受信すること、次いで受信した要求に関連付けられるトラフィックを監視することを含んでもよい。この方法では、複数のマイクロサービス間のトラフィックは、複数のマイクロサービス間で通信される受信された要求に基づいて監視されてもよい。これによって、トラフィックを監視するために必要な情報を集めることが、トラフィックのソース（つまり、複数のマイクロサービス間で通信される要求）から直接集めることができるようになる。結果的に、トラフィックを監視する信頼性および効率が改善される場合がある。

【0034】

いくつかの実施形態では、複数のマイクロサービスのそれぞれを再配置することは、複数のマイクロサービスのそれぞれに関して、マイクロサービスの第１のインスタンスをそのオリジン・リソースに維持することと、マイクロサービスの第２のインスタンスを共有リソースで再開始することと、マイクロサービスの第２のインスタンスをそのオリジン・リソースでシャット・ダウンすることとを含んでもよい。この方法では、複数のマイクロサービスのそれぞれは、恒久的に、またはマイクロサービスをそのオリジン・リソースに戻すためにさらなる再配置を要求する代わりに、一時的に再配置されてもよい。加えて、複数のマイクロサービスのそれぞれは、第２のマイクロサービスとの対話に影響を及ぼすことなく、第１のマイクロサービスとの対話（すなわち、通信）に関して再配置されてもよい。結果として、このことにより、複数のマイクロサービスのそれぞれを再配置するために必要とされる時間と処理が低減され、したがって、複数のマイクロサービスのそれぞれを再配置する効率が改善される場合がある。

【0035】

図１は、例示的な実施形態の態様を実装することができる、例示の分散システムの図的表現である。分散システム１００は、例示的な実施形態の態様を実装することができる、コンピュータのネットワークを含んでもよい。分散システム１００は、少なくとも１つのネットワーク１０２を含み、このネットワーク１０２は、分散データ処理システム１００内で共に接続された様々なデバイスとコンピュータとの間に通信リンクを提供するように使用される媒体である。ネットワーク１０２は、有線、無線通信リンク、または光ファイバ・ケーブルなどの接続を含んでもよい。

【0036】

描かれる例では、第１のサーバ１０４および第２のサーバ１０６は、ストレージ・ユニット１０８と共にネットワーク１０２に接続される。加えて、クライアント１１０、１１２、および１１４もまた、ネットワーク１０２に接続される。クライアント１１０、１１２、および１１４は、例えば、パーソナル・コンピュータ、ネットワーク・コンピュータなどであってもよい。描かれる例では、第１のサーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータを、クライアント１１０、１１２、および１１４に与える。クライアント１１０、１１２、および１１４は、描かれる例では第１のサーバ１０４に対するクライアントである。分散処理システム１００は、追加的なサーバ、クライアント、および示されていない他のデバイスを含んでもよい。

【0037】

描かれる例では、分散システム１００は、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＴＣＰ／ＩＰ）のプロトコルのスイートを使用して互いに通信する、ネットワークとゲートウェイとのワールドワイドな集合を表現するネットワーク１０２を伴うインターネットである。インターネットの中核は、主ノードまたはホスト・コンピュータ間の高速データ通信線のバックボーンであり、数千の民間用、政府機関用、教育機関用、ならびにデータおよびメッセージをルーティングする他のコンピュータ・システムから構成される。もちろん、分散システム１００はまた、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）など、複数の異なるタイプのネットワークを含むように実装されてもよい。上述のように、図１は、本発明の様々な実施形態に関するアーキテクチャ上の制限としてではなく、例として意図されており、そのため、図１に示される特定の要素は、本発明の例示的な実施形態が実装される環境に関する限定として考えられてはならない。

【0038】

図２は、例示的な実施形態の態様を実装することができる、例示のシステム２００のブロック図である。システム２００は、本発明の例示的な実施形態のためのコンピュータ使用可能コードまたはプロセスを実装する命令を配置することができる、図１のクライアント１１０などのコンピュータの一例である。例えば、システム２００は、実施形態に従って監視ユニットおよび再配置ユニットを実装するように構成されてもよい。

【0039】

図示される例では、システム２００は、ノース・ブリッジおよびメモリ・コントローラ・ハブ（ＮＢ／ＭＣＨ）２０２、ならびにサウス・ブリッジおよび入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＳＢ／ＩＣＨ）２０４を含む、ハブ・アーキテクチャを採用する。処理ユニット２０６、メイン・メモリ２０８、およびグラフィックス・プロセッサ２１０は、ＮＢ／ＭＣＨ２０２に接続される。グラフィックス・プロセッサ２１０は、アクセラレーテッド・グラフィックス・ポート（ＡＧＰ）を通じてＮＢ／ＭＣＨ２０２に接続されてもよい。

【0040】

図示される例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２は、ＳＢ／ＩＣＨ２０４に接続している。オーディオ・アダプタ２１６、キーボードおよびマウス・アダプタ２２０、モデム２２２、読み取り専用メモリ（ＲＯＭ）２２４、ハード・ディスク・ドライブ（ＨＤＤ）２２６、ＣＤ－ＲＯＭドライブ２３０、ユニバーサル・シリアル・バス（ＵＳＢ）ポートおよび他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４は、第１のバス２３８および第２のバス２４０を通じてＳＢ／ＩＣＨ２０４に接続している。ＰＣＩ／ＰＣＩｅデバイスとしては、例えば、イーサネット（Ｒ）・アダプタ、アドイン・カード、およびノートブック・コンピュータ用のＰＣカードを挙げることができる。ＰＣＩは、カード・バス・コントローラを使用するが、ＰＣＩｅはこれを使用しない。ＲＯＭ２２４は、例えば、フラッシュのｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ（ＢＩＯＳ）であってもよい。

【0041】

ＨＤＤ２２６およびＣＤ－ＲＯＭドライブ２３０は、第２のバス２４０を通じてＳＢ／ＩＣＨ２０４に接続している。ＨＤＤ２２６およびＣＤ－ＲＯＭドライブ２３０は、例えば、ｉｎｔｅｇｒａｔｅｄ ｄｒｉｖｅ ｅｌｅｃｔｒｏｎｉｃｓ（ＩＤＥ）またはｓｅｒｉａｌ ａｄｖａｎｃｅｄ ｔｅｃｈｎｏｌｏｇｙ ａｔｔａｃｈｍｅｎｔ（ＳＡＴＡ）インターフェースを使用することができる。スーパーＩ／Ｏ（ＳＩＯ）デバイス２３６は、ＳＢ／ＩＣＨ２０４に接続されてもよい。

【0042】

オペレーティング・システムは、処理ユニット２０６で実行される。オペレーティング・システムは、図２のシステム２００内の様々なコンポーネントを協働させて制御を実現する。クライアントとしては、オペレーティング・システムは市販のオペレーティング・システムであってもよい。Ｊａｖａ（Ｒ）（ＴＭ）プログラミング・システムなどのオブジェクト指向プログラミング・システムは、オペレーティング・システムと併せて実行されてもよく、システム２００で実行中のＪａｖａ（Ｒ）（ＴＭ）プログラムまたはアプリケーションからオペレーティング・システムにコールを与える。

【0043】

サーバとしては、システム２００は、例えば、Ａｄｖａｎｃｅｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｅｘｅｃｕｔｉｖｅ（ＡＩＸ（Ｒ））オペレーティング・システムまたはＬＩＮＵＸ（Ｒ）オペレーティング・システムで実行される、ＩＢＭ（Ｒ）ｅＳｅｒｖｅｒ（ＴＭ）Ｓｙｓｔｅｍ ｐ（Ｒ）コンピュータ・システムであってもよい。システム２００は、処理ユニット２０６内に複数のプロセッサを含む、シンメトリック・マルチプロセッサ（ＳＭＰ）のシステムであってもよい。代替的に、シングル・プロセッサのシステムが採用されてもよい。

【0044】

オペレーティング・システム、プログラミング・システム、およびアプリケーションもしくはプログラム用の命令は、ＨＤＤ２２６などの記憶デバイスに配置され、処理ユニット２０６による実行用にメイン・メモリ２０８にロードされてもよい。同様に、一実施形態による、１つまたは複数のメッセージ処理プログラムは、記憶デバイスまたはメイン・メモリ２０８あるいはその両方によって記憶されるように構成されてもよい。

【0045】

本発明の例示的な実施形態のためのプロセスは、例えば、メイン・メモリ２０８、ＲＯＭ２２４などのメモリ、または１つもしくは複数の周辺デバイス２２６および２３０に配置されるコンピュータ使用可能プログラム・コードを用いて処理ユニット２０６によって実施されてもよい。

【0046】

図２に示されるような第１のバス２３８または第２のバス２４０などのバス・システムは、１つまたは複数のバスを含んでもよい。当然ながら、バス・システムは、通信ファブリックまたはアーキテクチャに付属の、異なるコンポーネントまたはデバイス間でのデータの転送を実現するあらゆるタイプの通信ファブリックまたはアーキテクチャを用いて実装することができる。図２のモデム２２２またはネットワーク・アダプタ２１２などの通信ユニットは、データの送受信に用いられる１つまたは複数のデバイスを含んでもよい。メモリとしては、例えば、メイン・メモリ２０８、ＲＯＭ２２４、または図２のＮＢ／ＭＣＨ２０２にあるようなキャッシュを挙げることができる。

【0047】

当業者であれば、図１および図２のハードウェアは、実装形態に応じて変わってもよいことが諒解されるであろう。図１および図２で図示されるハードウェアに加えて、またはその代わりに、フラッシュ・メモリ、等価な非揮発性メモリ、または光学ディスク・ドライブなどの他の内部的ハードウェアまたは周辺デバイスが使用されてもよい。また、例示的な実施形態のプロセスは、本発明の思想および範囲から逸脱することなく前述のシステム以外のマルチプロセッサ・データ処理システムに適用されてもよい。

【0048】

さらには、システム２００は、クライアント・コンピューティング・デバイス、サーバ・コンピューティング・デバイス、タブレット・コンピュータ、ラップトップ・コンピュータ、電話または他の通信デバイス、携帯情報端末（ＰＤＡ）などを含む、いくつかの異なるデータ処理システムのいずれの形態を取ってもよい。いくつかの図示される例では、システム２００は、例えば、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方を記憶するために非揮発性メモリを実現するようフラッシュ・メモリで構成されたポータブルのコンピューティング・デバイスであってもよい。故に、システム２００は、本質的に、アーキテクチャ上の制限なく、あらゆる既知のまたは後に開発されるデータ処理システムであってもよい。

【0049】

次に図３を参照すると、複数のマイクロサービス間通信を管理するためのコンピュータ実装方法のフロー図が描かれている。

【0050】

ステップ３１０は、複数のマイクロサービス間のトラフィックを監視して、トラフィックの性質を判定することを含む。

【0051】

ここでは、ステップ３１０は、ステップ３１２および３１４を含む。ステップ３１２は、複数のマイクロサービス間で通信される要求を受信することを含む。ステップ３１４は、受信した要求に関連付けられるトラフィックを監視することを含む。

【0052】

具体的には、監視されるトラフィックの性質は、複数のマイクロサービス間を移動中のデータの量、複数のマイクロサービス間を移動中のデータのタイプ、および複数のマイクロサービス間を移動中のデータのフロー・レート、のうちの少なくとも１つを含む。

【0053】

ステップ３２０は、監視されるトラフィックの判定された性質に基づいて、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置することを含む。

【0054】

この実施形態では、ステップ３２０は、ステップ３２２および３２４を含む。ステップ３２２は、監視されるトラフィックの性質が所定の要件を満足するかどうか判定することを含む。ステップ３２４は、監視されるトラフィックの性質が所定の要件を満足することに応答して、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置することを含む。

【0055】

例として、所定の要件は、データの量が所定のしきい値以上であること、データのタイプが所定のタイプであること、およびデータのフロー・レートが所定のしきい値以上であることのうちの少なくとも１つを含む。

【0056】

ステップ３２０は、複数のマイクロサービスのそれぞれに関して、共有リソースでマイクロサービスを再開始し、マイクロサービスをそのオリジン・リソースでシャット・ダウンすることを含む。

【0057】

この実施形態では、ステップ３２０は、複数のマイクロサービスを、それらの個々のオリジン・リソースのそれぞれから共有リソースに集めることによって、複数のマイクロサービス間通信を再構成することをさらに含む。

【0058】

この実施形態では、ステップ３２０は、複数のマイクロサービスのそれぞれに関して、マイクロサービスの第１のインスタンスをそのオリジン・リソースに維持することと、マイクロサービスの第２のインスタンスを共有リソースで再開始することと、マイクロサービスの第２のインスタンスをそのオリジン・リソースでシャット・ダウンすることとを含む。例えば、複数のマイクロサービスの複数のインスタンスは、異なるモードで実行される。複数のマイクロサービスのそれぞれのインスタンスは、その個々のオリジン・リソースから共有リソースに再配置される。一例では、第１のマイクロサービスの第１のインスタンス、および第２のマイクロサービスのインスタンスは、同一プロセス中にあるが、第１のマイクロサービスの第２のインスタンスは、第３のマイクロサービスからのサービス要求の負荷を共有するために別個のノード内に単体で残る。別の例では、サービス同士の対話はルートによって表現される。ルートＡＢは、マイクロサービスＡからマイクロサービスＢへのルートを含み、ルートＣＢは、マイクロサービスＣからマイクロサービスＢへのルートを含む。この例では、ルートＡＢは、かなり使用され（つまり、高い水準のトラフィックを含む）、ルートＣＢはあまり使用されない（つまり、低い水準のトラフィックを含む）。このシナリオでは、マイクロサービスＢの第２のインスタンスは、マイクロサービスＡとの共有リソースで再開始され、そのオリジン・リソースでシャット・ダウンされる。マイクロサービスＢの第１のインスタンス（すなわち、オリジナルのインスタンス）は、ルートＣＢが影響されないように、そのオリジン・リソースに残される（つまり、維持される）。

【0059】

ここでは、オリジン・リソースおよび共有リソースのうちの少なくとも１つは、仮想リソースを含む。

【0060】

例として、仮想リソースは、ノード、ノードのポッド、コンテナ、ポッドのコンテナ、プロセス、コンテナのプロセスのうちの１つを含む。例えば、２つの別個のノードにある２つのマイクロサービスは、シャット・ダウンされ、共有ノードで再開始される。別の例では、同一ノード上の２つのマイクロサービスは、シャット・ダウンされ、共有ポッド内部でアップされ得る。別の例では、同一ポッド上の２つのマイクロサービスは、シャット・ダウンされ、２つのプロセスとして共有コンテナ内でアップされ得る。別の例では、２つの別個のプロセス内の２つのマイクロサービスは、シャット・ダウンされ、共有プロセス内部でアップされ得る。

【0061】

例えば、上で開示される仮想リソースのリストは、リソースが互いに近くに配置されたためレイテンシが低減された一連の抽象化を表現している。一例では、２つの別個のノードに配置された２つのマイクロサービス同士の通信は、別個のサーバ間のネットワーク・トラフィックを含む。一例では、２つの別個のコンテナに配置された２つのマイクロサービス同士の通信は、共有サーバ上のネットワーク・トラフィックを含む。一例では、２つの別個のプロセスに配置された２つのマイクロサービス同士の通信は、プロセス間コールを含む。一例では、共有プロセスに配置された２つのマイクロサービス同士の通信は、直接コールを含む。マイクロサービスが再配置される程度は、クラウド環境のインフラストラクチャおよびマイクロサービスのランタイムに依存する（つまり、マイクロサービスが管理された、動的な、またはコンパイルされたランタイムを含むかどうか）。

【0062】

別の実施形態では、複数のマイクロサービスのそれぞれの個々のオリジン・リソースは、複数のマイクロサービスの共有されたオリジン・リソースを含む。この例では、複数のマイクロサービスは、以前に使えなくっており、今度は複数のマイクロサービスのそれぞれを、その個々のオリジン・リソース（つまり、以前に使えなくなった複数のマイクロサービスの共有オリジン・リソース）から共有リソース（つまり、共有宛先リソース）に再配置することによって拡大されている。例えば、共有リソースには、複数のマイクロサービスのオリジン・リソースが含まれる。そのようなものとして、複数のマイクロサービスは、複数のマイクロサービスによって共有されるオリジン・リソースから、複数のマイクロサービスのうちの少なくとも１つが以前に配置されてあった共有リソースに分散される。

【0063】

次に図４を参照すると、複数のマイクロサービス間通信を管理するためのシステムの例示の実施形態の簡略化されたブロック図が描かれている。

【0064】

システムは、複数のマイクロサービス間のトラフィックを監視して、トラフィックの性質を判定するように構成された監視ユニット４１０を含む。システムは、監視されるトラフィックの判定された性質に基づいて、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置するように構成された再配置ユニット４２０をさらに含む。

【0065】

ここでは、監視ユニット４１０は、マイクロサービス間で通信される要求を受信するように構成された受信ユニット４１２を含む。監視ユニット４１０は、受信された要求に関連付けられるトラフィックを監視するようにさらに構成される。

【0066】

例として、監視されるトラフィックの性質は、複数のマイクロサービス間を移動中のデータの量、複数のマイクロサービス間を移動中のデータのタイプ、および複数のマイクロサービス間を移動中のデータのフロー・レート、のうちの少なくとも１つを含む。

【0067】

ここでは、再配置ユニット４２０は、複数のマイクロサービスのそれぞれに関して、共有リソースでマイクロサービスを再開始し、マイクロサービスをそのオリジン・リソースでシャット・ダウンするように構成された再開始ユニット４２２を含む。

【0068】

再配置ユニット４２０は、複数のマイクロサービスを、それらの個々のオリジン・リソースのそれぞれから共有リソースに集めることによって、複数のマイクロサービス間通信を再構成するように構成された再構成ユニット４２４を含む。

【0069】

この実施形態では、再配置ユニット４２０は、監視されるトラフィックの性質が所定の要件を満足するかどうかを判定するように、また監視されるトラフィックの性質が所定の要件を満足することに応答して、複数のマイクロサービスのそれぞれを、その個々のオリジン・リソースから共有リソースに再配置するようにさらに構成される。

【0070】

例として、所定の要件は、データの量が所定のしきい値以上であること、データのタイプが所定のタイプであること、およびデータのフロー・レートが所定のしきい値以上であることのうちの少なくとも１つを含む。

【0071】

この実施形態では、再開始ユニット４２２は、複数のマイクロサービスのそれぞれに関して、マイクロサービスの第１のインスタンスをそのオリジン・リソースに維持することと、マイクロサービスの第２のインスタンスを共有リソースで再開始することと、マイクロサービスの第２のインスタンスをそのオリジン・リソースでシャット・ダウンすることとを行うようにさらに構成される。

【0072】

具体的には、オリジン・リソースおよび共有リソースのうちの少なくとも１つは、仮想リソースを含む。

【0073】

例として、仮想リソースは、ノード、ノードのポッド、コンテナ、ポッドのコンテナ、プロセス、コンテナのプロセスのうちの１つを含む。

【0074】

次に図５（Ａ）～図５（Ｅ）を参照すると、複数のマイクロサービス間通信の例の簡略化されたブロック図が描かれている。

【0075】

一例では、サービスＡ５２０およびサービスＢ５２２は、２つの異なるマイクロサービスを、コンテナ・オーケストレーション・システム内に分散されたアプリケーション内に提供する。サービスＡ５２０は、公開されているアプリケーション・プログラミング・インターフェース（ＡＰＩ）、例えばＯｐｅｎＡＰＩ上でサービスＢ５２２を頻繁に呼び出す。サービスＡ５２０とサービスＢ５２２の両方は、アプリケーションとしてオープンソースの、クロスプラットフォームなランタイム環境に実装される。アプリケーションは、標準ベースのオペレーティング・システム（ＯＳ）イメージ上で、コンテナ内でコードを実行するために使用される複数のレイヤを含むファイル、つまりオペレーティング・システム、実行可能ファイル、およびオペレーティング・システム上のプログラムに関するあらゆるデータ・ファイル（例えば、システム・イメージ、ディスク・イメージ、またはプロセス・イメージ）を含むファイルにビルドされる。いったんビルドされると、アプリケーションは、コンテナ・オーケストレーション・システム内のポッド内にコンテナとしてデプロイされる。

【0076】

開発の間、サービスＡ５２０は、サービスＢ５２２の公開されているアプリケーション・プログラミング・インターフェース定義（例えば、ＯｐｅｎＡＰＩの定義）から生成されたアプリケーション・プログラミング・インターフェースを使用して開発（つまり、生成）される。一実施形態では、これは、後に正常な依存関係としてサービスＡ５２０に含むことが可能なパッケージ・マネージャを作成するために、クライアント側のウェブ・アプリケーション向けのスキャフォールディング・ツールによって生成される。サービスＡ５２０の生成されたコードは、サービスＡ５２０からサービスＢ５２２へのコールを取り扱う。生成されたコードは、ビルド時間設定パラメータ、デプロイ時間設定パラメータ、およびランタイム設定パラメータのうちの少なくとも１つに基づいて適当なトランスポートを判定する。例えば、ビルド時間に、サービスＡ５２０およびサービスＢ５２２の両方が同一コンテナにパッケージングされる。例えば、デプロイ時間に、サービスＡ５２０とサービスＢ５２２のどちらがインスタンスによって開始されるかを特定する設定パラメータ（例えば、環境変数）を用いてコンテナのインスタンスが開始される。例えば、ランタイムでは、サービスＡ５２０とサービスＢ５２２の両方のインスタンスが、自身の負荷を監視ユニット４１０にレポートする。

【0077】

図５（Ａ）は、サービスＡ５２０とサービスＢ５２２との間のノード間通信を描いている。サービス同士がノード５１０間で通信するように、サービスＡ５２０は、第１のノード５１０にあり、サービスＢ５２２は、第２のノード５１０にある。Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）は、サービスＡ５２０とサービスＢ５２２との間のメッセージのマーシャリング、暗号化、ネットワーキング、復号化、そしてアンマーシャリングを含む。図５（Ｂ）は、サービスＡ５２０とサービスＢ５２２との間のポッド間通信（つまり、ノード内通信）を描いている。サービス同士がポッド５１２間で通信するように、サービスＡ５２０は、第１のポッド５１２にあり、サービスＢ５２２は、第２のポッド５１２にある。両方のポッドは、同一ノード５１０内にある。Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）はサービスＡ５２０とサービスＢ５２２との間のメッセージのマーシャリング、暗号化、復号化、そしてアンマーシャリングを含む。図５（Ｃ）は、サービスＡ５２０とサービスＢ５２２との間のコンテナ間通信（つまり、ポッド内通信）を描いている。サービス同士がコンテナ５１４間で通信するように、サービスＡ５２０は、第１のコンテナ５１４にあり、サービスＢ５２２は、第２のコンテナ５１４にある。両方のコンテナ５１４は、同一ポッド５１２内にある。Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）はサービスＡ５２０とサービスＢ５２２との間のメッセージのマーシャリングおよびアンマーシャリングを含む。図５（Ｄ）は、サービスＡ５２０とサービスＢ５２２との間のプロセス間通信（つまり、コンテナ内通信）を描いている。サービス同士がプロセス間で通信するように、サービスＡ５２０は、第１のプロセスにあり、サービスＢ５２２は、第２のプロセスにある。両方のプロセスは、同一コンテナ５１４内にある。プロセス間通信には、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌが関与しない。図５（Ｅ）は、サービスＡ５２０とサービスＢ５２２との間のイン・プロセスのファンクション・コールを描いている。サービス同士が共有プロセス内部で通信するように、サービスＡ５２０およびサービスＢ５２２は、共有プロセス内にある。プロセス間通信には、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌが関与しない。

【0078】

コンテナ・オーケストレーション・システム全体の負荷が変化すると、サービスＡ５２０とサービスＢとが通信する方法が変わる（つまり再配置ユニット４２０によって）。例えば、通信は、Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）（図５（Ｂ））を使用するポッド間通信から、ＴＬＳを用いないコンテナ間のポッド内通信（図５（Ｃ））に変わる。結果として、メッセージを暗号化および復号化するために必要なオーバヘッドが、もはや必要とされず、節約される。

【0079】

別の例では、個々のコンテナは、サービスＡ５２０およびサービスＢ５２２のそれらのイン・プロセス・インスタンスを開始および停止するように指示される。サービスＡ５２０およびサービスＢ５２２は、共に共有コンテナ内にパッケージングされるため、サービスＡ５２０の実行中のインスタンスは、ＡＰＩレイヤがＨＴＴＰ ＲＥＳＴコールを行うことから実際のファンクション・コールを行うことに変わるように（図５（Ｅ））、サービスＢ５２２の自分自身のインスタンスを開始することが可能である。

【0080】

一例では、監視ユニットは、ＡＰＩコールをカウントする、またはプロファイリングもしくは他の計装などの高度な既知のメトリクスを使用する、あるいはその両方を行って、通信に関連する処理オーバヘッドをレポートする（つまり、複数のマイクロサービス間のトラフィックを監視して、トラフィックの性質を判定する）。再配置ユニットは、ヒューリスティックな技術を使用してどのようにサービスを組織化するかを決定する。例えば、再配置ユニットは、請求対象のメモリ料金を低減するべく、全体的な応答時間を優先するべきか、または使用中のコンテナの数を最小限に抑えるべきか、冗長性のために独立的なインスタンスをいくつ維持するべきかに関する規則を有する。このような技術は、異なるプロファイルとして定義することが可能であり、例えば、ソフトウェア開発者のローカル・システムで実行する使用中のコンテナの数を最小値にスケーリングする開発プロファイルが定義される

【0081】

さらなる例として、図６に図示されるように、実施形態は、コンピュータ・システム７０を含んでもよく、コンピュータ・システム７０は、ネットワーク化されたシステム７の一部を形成してもよい。例えば、再配置ユニットは、コンピュータ・システム７０によって実装される。コンピュータ・システム／サーバ７０のコンポーネントは、例えば、プロセッサまたは処理ユニット７１、システム・メモリ７４、およびシステム・メモリ７４を含む様々なシステム・コンポーネントを処理ユニット７１に連結するバス９０を含む、１つまたは複数の処理配置構成を含むことができるが、それに限定されない。

【0082】

システム・メモリ７４は、ランダム・アクセス・メモリ（ＲＡＭ）７５またはキャッシュ・メモリ７６あるいはその両方などの揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ７０は、他のリムーバブル／非リムーバブルの、揮発性／非揮発性のコンピュータ・システム記憶媒体をさらに含むことができる。そのような事例において、それぞれは１つまたは複数のデータ媒体インターフェースによってバス９０へ接続することができる。メモリ７４は、提案される実施形態の機能を実行するように構成される１セット（例えば、少なくとも１つ）のプログラム・モジュールを有する少なくとも１つのプログラム製品を含むことができる。例えば、メモリ７４は、システムに複数のマイクロサービス間通信を管理するための方法を実行させる、処理ユニット７１によって実行可能なプログラムを有するコンピュータ・プログラム製品を含んでもよい。

【0083】

１セット（例えば、少なくとも１つ）のプログラム・モジュール７９を有するプログラム／ユーティリティ７８は、メモリ７４に記憶されてもよい。プログラム・モジュール７９は、一般的に複数のマイクロサービス間通信を管理するための提案される実施形態の、機能または方法あるいはその両方を実行する。

【0084】

コンピュータ・システム／サーバ７０はまた、キーボード、ポインティング・デバイス、ディスプレイ８５などの１つもしくは複数の外部デバイス８０、ユーザがコンピュータ・システム／サーバ７０と対話できるようにする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ７０が１つもしくは複数の他のコンピューティング・デバイスと通信できるようにするあらゆるデバイス（例えば、ネットワーク・カード、モデムなど）、あるいはその組合せと通信することができる。そのような通信は入力／出力（Ｉ／Ｏ）インターフェース７２を介して行うことができる。さらになお、コンピュータ・システム／サーバ７０は、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ）、またはネットワーク・アダプタ７３を介するパブリック・ネットワーク（例えば、インターネット）あるいはその組合せなど、１つまたは複数のネットワークと通信することができる（例えば、再作成されたコンテンツをシステムまたはユーザに通信するために）。

【0085】

本出願のコンテキストでは、本発明の実施形態が方法を構成しているが、そのような方法はコンピュータによる実行のためのプロセスであること、つまり、コンピュータ実装方法であることを理解されたい。したがって、方法の様々なステップは、コンピュータ・プログラムの様々な部分、例えば１つまたは複数のアルゴリズムの様々な部分を反映する。

【0086】

本発明は、システム、方法、またはコンピュータ・プログラム製品あるいはその組合せであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体を含むことができる。

【0087】

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のための命令を保持および記憶することができる有形のデバイスであり得る。コンピュータ可読記憶媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイスまたは前述のあらゆる適切な組合せであってもよいが、それに限定はしない。コンピュータ可読記憶媒体のより具体的な例の非網羅的な列挙としては、以下が挙げられる：ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、ストレージ・クラス・メモリ（ＳＣＭ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリ・スティック、フロッピ（Ｒ）・ディスク、命令が記録されたパンチカードまたは溝に刻まれた構造などの機械的にエンコードされたデバイス、および前述のあらゆる適切な組合せ。本明細書において使用される場合、コンピュータ可読記憶媒体は、電波もしくは他の自由に伝搬する電磁波、導波路もしくは他の送信媒体を介して伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、または電線を介して伝送される電気的信号など、一過性の信号そのものであると解釈されてはならない。

【0088】

本明細書において説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体から、個別のコンピューティング／処理デバイスに、あるいは、例えばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワークもしくは無線ネットワークまたはその組合せなどのネットワークを介して、外部のコンピュータまたは外部のストレージ・デバイスに、ダウンロードすることができる。ネットワークは、銅の送信ケーブル、光学送信ファイバ、無線送信、ルータ、ファイヤウォール、スイッチ、ゲートウェイ・コンピュータまたはエッジ・サーバあるいはその組合せを含むことができる。それぞれのコンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、個別のコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶するためにコンピュータ可読プログラム命令を転送する。

【0089】

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、あるいはＳｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語などの従来的な手続き型プログラミング言語もしくは類似するプログラミング言語、を含む１つまたは複数のプログラミング言語のあらゆる組合せで記述された、ソース・コードまたはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、すべてユーザのコンピュータ上で、一部はユーザのコンピュータ上でスタンドアロンのソフトウェア・パッケージとして、一部はユーザのコンピュータ上で一部は遠隔のコンピュータ上で、またはすべて遠隔のコンピュータ上もしくはサーバ上で、実行することができる。後者のシナリオでは、遠隔のコンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含むあらゆるタイプのネットワークを介してユーザのコンピュータに接続することができ、または接続は外部のコンピュータ（例えば、インターネット・サービス・プロバイダを使用するインターネットを介して）に対してなされてもよい。一部の実施形態において、例えば、プログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実施するために、コンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行して電子回路を個別化することができる。

【0090】

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照しながら本明細書において説明される。フローチャート図またはブロック図あるいはその両方のそれぞれのブロック、およびフローチャート図またはブロック図あるいはその両方におけるブロックの組合せは、コンピュータ可読プログラム命令によって実装されることが理解されよう。

【0091】

これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラマブル・データ処理装置のプロセッサを介して実行する命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実装する手段を作成すべく、汎用コンピュータ、特殊目的コンピュータ、または他のプログラマブル・データ処理装置のプロセッサに提供されて機械を作るものであってよい。これらのコンピュータ可読プログラム命令はまた、命令が記憶されているコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実装するための命令を含む製造物品を備えるべく、コンピュータ、プログラマブル・データ処理装置、または他のデバイスあるいはその組合せに特定のやり方で機能するように指示することができるコンピュータ可読記憶媒体に記憶されてもよい。

【0092】

コンピュータ可読プログラム命令はまた、コンピュータ、他のプログラマブル装置、または他のデバイスで実行する命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックに指定される機能／動作を実装するように、コンピュータ実装プロセスを作るべく、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードされ、コンピュータ、他のプログラマブル装置、または他のデバイス上で一連の動作ステップを実施させるものであってもよい。

【0093】

図面中のフローチャートおよびブロック図は、本発明の様々な実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装形態の、アーキテクチャ、機能性、および動作を図示している。この点において、フローチャートまたはブロック図のそれぞれのブロックは、指定される論理機能を実装するための１つまたは複数の実行可能な命令を含む、命令のモジュール、セグメント、または部分を表現することができる。一部の代替的な実装形態において、ブロックにおいて示した機能は図面で示した順とは異なるように発生してもよい。例えば、連続して示される２つのブロックは、実際には実質的に同時に実行されてもよく、またはブロックは関与する機能によっては、時に逆の順で実行されてもよい。ブロック図またはフローチャート図あるいはその両方のそれぞれのブロック、およびブロック図またはフローチャート図あるいはその両方のブロックの組合せは、指定される機能もしくは動作を実施する、または特殊目的ハードウェアとコンピュータ命令との組合せを実行する、特殊目的ハードウェア・ベースのシステムによって実装されることにも留意されたい。

【0094】

例示を目的として本発明の様々な実施形態の説明を提示してきたが、網羅的であること、または開示された実施形態に限定することは意図されていない。説明された実施形態の範囲および思想から逸脱することなく、多くの変更形態および変形形態が当業者にとって明らかとなろう。本明細書において使用される用語法は、実施形態の原理、実践的な用途もしくは市場で見られる技術より優れた技術的な改善を最良に説明するため、または当業者の他の者が本明細書において開示される実施形態を理解できるように選ばれたものである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】