JP7411735B2 - マルチクラスタイングレス - Google Patents

Description

この開示は、コンテナ化されたオーケストレーションシステムのためのマルチクラスタイングレスに関する。

背景
（分散システムを介する）いくつかのクラウドベースのサービスは、コンテナ化されたオーケストレーションシステムを提供する。これらのシステムは、ソフトウェアが、仮想マシンのような隔離能力を低いオーバーヘッドと高いスケーラビリティとともに提供することによって開発され、デプロイされ、維持されるやり方を作り変えてきた。ソフトウェアアプリケーションはセキュアな実行環境（たとえば、コンテナまたはポッド）において実行され、同じ場所に位置するポッドはクラスタへとグループ化されてもよく、各クラスタは他のクラスタから隔離される。クラスタ内のポッド間でのトラフィックおよび作業負荷の分散を改良するために、負荷分散装置が通常使用される。レイヤ７（Layer 7：Ｌ７
）負荷分散（すなわちアプリケーション層）が、メッセージの実際のコンテンツの負荷を分散させる。たとえば、Ｌ７負荷分散装置が、ハイパーテキスト転送プロトコル（HyperText Transfer Protocol：ＨＴＴＰ）またはハイパーテキスト転送プロトコルセキュア（HyperText Transfer Protocol Secure：ＨＴＴＰＳ）上で動作し、メッセージのコンテンツに関するルーティング決定を下すかもしれない。コンテナ化されたオーケストレーションシステムのための負荷分散装置は典型的には、単一のクラスタ上で動作するＬ７負荷分散装置である。

概要
この開示の一局面は、マルチクラスタコンテナ化オーケストレーションシステム中にアプリケーション要求の負荷を分散させるための方法を提供する。方法は、ユーザによってデプロイされたソフトウェアアプリケーションをホストする１組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを、データ処理ハードウェアで受信するステップを含む。マルチクラスタサービスは、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を１組の宛先クラスタ間で分散させるために負荷分散コンフィグレーションを使用するように構成される。各宛先クラスタは、ソフトウェアアプリケーションを実行する少なくとも１つのコンテナと、それぞれの地理的領域とを含み、それぞれの地理的領域は、１組の宛先クラスタにおける宛先クラスタのうちの別の１つに関連付けられた少なくとも１つの他の地理的領域と同じであるかまたは異なっている。方法はまた、１組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を、データ処理ハードウェアで受信するステップを含む。アプリケーションレベル要求はクライアントから受信され、クライアントに関連付けられたホスト名および地理的位置を含む。方法はまた、データ処理ハードウェアが、アプリケーションレベル要求の地理的位置と１組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を１組の宛先クラスタにおける宛先クラスタのうちの１つにルーティングするステップを含む。

この開示の実現化例は、以下のオプションの機能のうちの１つ以上を含んでいてもよい。いくつかの実現化例では、アプリケーションレベル要求をルーティングするステップは、１組の宛先クラスタにおけるどの宛先クラスタが、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いかを、１組の宛先クラスタのそれぞれの地理的領域に基づいて判断するステップと、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いそれぞれの地理的領域を有する、１組の宛先クラスタにおける宛先クラスタに、アプリケーションレベル要求をルーティングするステップとを含む。いくつかの例では、アプリケーションレベル要求をルーティングすることはさらに、１組の宛先クラスタにおける各宛先クラスタについてマルチクラスタサービスによって特定されたそれぞれの負荷分散属性に基づいている。受信された負荷分散コンフィグレーションは、マルチクラスタサービスを一意的に識別するユーザ由来サービス名を含んでいてもよい。

いくつかの実現化例では、方法は、データ処理ハードウェアが、マルチクラスタサービスのためのアプリケーションレベルトラフィックをサーブするであろうクラスタレジストリからクラスタを選択するためにマルチクラスタサービスによって特定されたクラスタ選択基準を識別するステップと、データ処理ハードウェアが、マルチクラスタサービスによって特定されたクラスタ選択基準を満たす１つ以上のラベルのそれぞれの組を有する１組の宛先クラスタにおける各宛先クラスタに基づいて、クラスタレジストリから１組の宛先クラスタを選択するステップとを含む。マルチクラスタサービスによって特定されたクラスタ選択基準は、１つ以上の同等性ベースの整合要件、または１つ以上の組ベースの整合要件のうちの少なくとも１つを含んでいてもよい。オプションで、方法はさらに、１組の宛先クラスタにおける各宛先クラスタについて、データ処理ハードウェアが、対応する派生サービスを宛先クラスタ内でインスタンス化するステップを含む。派生サービスは、エンドポイントのグループを含む対応するネットワークエンドポイントグループ（network endpoint group：ＮＥＧ）を作成するように構成される。エンドポイントのグループにおける各エンドポイントは、宛先クラスタのそれぞれのコンテナに関連付けられ、それぞれのインターネットプロトコル（Internet Protocol：ＩＰ）アドレスと、アプリケーションレベルトラフィックをそれぞれのコンテナに直接分散させるためのそれぞれのポートとを含む。

各対応する派生サービスは、いくつかの実現化例では、他の派生サービスの派生サービス名とは異なる、一意的な派生サービス名を含む。派生サービス名はトリミングされたサービス名部分と一意ハッシュ値部分とを有する。トリミングされたサービス名部分はマルチクラスタサービスのユーザ由来サービス名を含み、一意ハッシュ値部分はマルチクラスタサービスのユーザ由来サービス名の一意ハッシュ値を含む。方法は、いくつかの例では、アプリケーションレベル要求を受信するステップに応答して、データ処理ハードウェアが、ユニフォームリソースロケータ（Uniform Resource Locator：ＵＲＬ）マッピングにアクセスするステップをさらに含む。ＵＲＬマッピングは、１つ以上の宛先クラスタのサービスにマッピングする１つ以上のホスト名のリストを特定する。方法はまた、受信されたアプリケーションレベル要求のホスト名が、ＵＲＬマッピングによって特定された１つ以上のホスト名のリストにおけるホスト名のうちの１つを含むかどうかを、データ処理ハードウェアが判断するステップと、受信されたアプリケーションレベル要求のホスト名が、リストにおけるホスト名のうちの１つを含む場合、データ処理ハードウェアが、受信されたアプリケーションレベル要求をサービスに転送するステップとを含む。

アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含んでいてもよい。アプリケーションレベルトラフィックはまた、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）プロトコルを含んでいてもよい。オプションで、アプリケーションレベル要求の少なくとも一部は、トランスポート層セキュリティ（Transport Layer Security：ＴＬＳ）プロトコルを含んでいてもよい。方法は、いくつかの実現化例では、アプリケーションレベル要求をルーティングするステップの前に、１組の宛先クラスタにおける各宛先クラスタについて、宛先クラスタに現在ルーティングされているアプリケーションレベル要求の数が最大要求レートを満たすかどうかを、データ処理ハードウェアが判断するステップと、アプリケーションレベル要求の数が最大要求レートを満たす場合、宛先クラスタへのアプリケーションレベル要求のルーティングを防止するステップとをさらに含む。

この開示の別の局面は、マルチクラスタコンテナ化オーケストレーションシステム中にアプリケーション要求の負荷を分散させるためのシステムを提供する。システムは、データ処理ハードウェアと、データ処理ハードウェアと通信しているメモリハードウェアとを含む。メモリハードウェアは、データ処理ハードウェア上で実行されるとデータ処理ハードウェアに動作を行なわせる命令を格納している。動作は、ユーザによってデプロイされたソフトウェアアプリケーションをホストする１組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを受信することを含む。マルチクラスタサービスは、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を１組の宛先クラスタ間で分散させるために負荷分散コンフィグレーションを使用するように構成される。各宛先クラスタは、ソフトウェアアプリケーションを実行する少なくとも１つのコンテナと、それぞれの地理的領域とを含み、それぞれの地理的領域は、１組の宛先クラスタにおける宛先クラスタのうちの別の１つに関連付けられた少なくとも１つの他の地理的領域と同じであるかまたは異なっている。動作はまた、１組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信することを含む。アプリケーションレベル要求はクライアントから受信され、クライアントに関連付けられたホスト名および地理的位置を含む。動作はまた、アプリケーションレベル要求の地理的位置と１組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を１組の宛先クラスタにおける宛先クラスタのうちの１つにルーティングすることを含む。

この局面は、以下のオプションの機能のうちの１つ以上を含んでいてもよい。いくつかの実現化例では、アプリケーションレベル要求をルーティングすることは、１組の宛先クラスタにおけるどの宛先クラスタが、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いかを、１組の宛先クラスタのそれぞれの地理的領域に基づいて判断することと、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いそれぞれの地理的領域を有する、１組の宛先クラスタにおける宛先クラスタに、アプリケーションレベル要求をルーティングすることとを含む。いくつかの例では、アプリケーションレベル要求をルーティングすることはさらに、１組の宛先クラスタにおける各宛先クラスタについてマルチクラスタサービスによって特定されたそれぞれの負荷分散属性に基づいている。受信された負荷分散コンフィグレーションは、マルチクラスタサービスを一意的に識別するユーザ由来サービス名を含んでいてもよい。

いくつかの実現化例では、動作は、マルチクラスタサービスのためのアプリケーションレベルトラフィックをサーブするであろうクラスタレジストリからクラスタを選択するためにマルチクラスタサービスによって特定されたクラスタ選択基準を識別することと、マルチクラスタサービスによって特定されたクラスタ選択基準を満たす１つ以上のラベルのそれぞれの組を有する１組の宛先クラスタにおける各宛先クラスタに基づいて、クラスタレジストリから１組の宛先クラスタを選択することとを含む。マルチクラスタサービスによって特定されたクラスタ選択基準は、１つ以上の同等性ベースの整合要件、または１つ以上の組ベースの整合要件のうちの少なくとも１つを含んでいてもよい。オプションで、動作はさらに、１組の宛先クラスタにおける各宛先クラスタについて、対応する派生サービスを宛先クラスタ内でインスタンス化することを含む。派生サービスは、エンドポイントのグループを含む対応するネットワークエンドポイントグループ（ＮＥＧ）を作成するように構成される。エンドポイントのグループにおける各エンドポイントは、宛先クラスタのそれぞれのコンテナに関連付けられ、それぞれのインターネットプロトコル（ＩＰ）
アドレスと、アプリケーションレベルトラフィックをそれぞれのコンテナに直接分散させるためのそれぞれのポートとを含む。

各対応する派生サービスは、いくつかの実現化例では、他の派生サービスの派生サービス名とは異なる、一意的な派生サービス名を含む。派生サービス名はトリミングされたサービス名部分と一意ハッシュ値部分とを有する。トリミングされたサービス名部分はマルチクラスタサービスのユーザ由来サービス名を含み、一意ハッシュ値部分はマルチクラスタサービスのユーザ由来サービス名の一意ハッシュ値を含む。動作は、いくつかの例では、アプリケーションレベル要求を受信することに応答して、ユニフォームリソースロケータ（ＵＲＬ）マッピングにアクセスすることをさらに含む。ＵＲＬマッピングは、１つ以上の宛先クラスタのサービスにマッピングする１つ以上のホスト名のリストを特定する。動作はまた、受信されたアプリケーションレベル要求のホスト名が、ＵＲＬマッピングによって特定された１つ以上のホスト名のリストにおけるホスト名のうちの１つを含むかどうかを判断することと、受信されたアプリケーションレベル要求のホスト名が、リストにおけるホスト名のうちの１つを含む場合、受信されたアプリケーションレベル要求をサービスに転送することとを含む。

アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含んでいてもよい。アプリケーションレベルトラフィックはまた、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）プロトコルを含んでいてもよい。オプションで、アプリケーションレベル要求の少なくとも一部は、トランスポート層セキュリティ（ＴＬＳ）プロトコルを含んでいてもよい。動作は、いくつかの実現化例では、アプリケーションレベル要求をルーティングする前に、１組の宛先クラスタにおける各宛先クラスタについて、宛先クラスタに現在ルーティングされているアプリケーションレベル要求の数が最大要求レートを満たすかどうかを判断することと、アプリケーションレベル要求の数が最大要求レートを満たす場合、宛先クラスタへのアプリケーションレベル要求のルーティングを防止することとをさらに含む。

この開示の１つ以上の実現化例の詳細が、添付図面および以下の説明において述べられる。他の局面、特徴、および利点は、説明および図面から、ならびに請求項から明らかになるであろう。

図面の説明

コンテナ化されたオーケストレーションシステムの複数のクラスタ間でアプリケーションレベルトラフィックの負荷を分散させるための例示的なシステムの概略図である。 図１のシステムの例示的なマルチクラスタコントローラの概略図である。 ネットワークエンドポイントグループを含むコンテナ負荷分散装置の例示的なコンポーネントの概略図である。 ネットワークエンドポイントグループを含むコンテナ負荷分散装置の例示的なコンポーネントの概略図である。 図１のシステムの例示的なマルチクラスタイングレスの概略図である。 コンテナ化されたシステムでリソースを節約するための例示的な方法のフローチャートである。 ここに説明されるシステムおよび方法を実現するために使用され得る例示的なコンピューティングデバイスの概略図である。

さまざまな図面における同じ参照符号は、同じ要素を示す。
詳細な説明
コンテナ化されたアプリケーションと、コンテナ化されたアプリケーションをオーケストレーションするシステムとは、リモートおよび分散コンピューティングにおける進歩に少なくとも部分的に起因して、ますます普及している。コンテナ化されたアプリケーション（すなわち、仮想化）は、隔離されたユーザまたはアプリケーション空間インスタンスの存在を可能にする。各インスタンス（すなわち、コンテナ）は、実行が必要なすべてのリソース（たとえばストレージ、ネットワークアクセスなど）へのアクセスを有するそれ自体のパーソナルコンピュータとして、アプリケーションに現われる場合がある。しかしながら、コンテナ内のアプリケーションは、そのそれぞれのコンテナに割り当てられたリソースを見て当該リソースにアクセスすることしかできないであろう。これは、分散環境またはクラウド環境におけるアプリケーションのセキュリティ、モビリティ、スケーリング、およびアップグレードを容易にする。

コンテナは典型的には、単一のアプリケーションまたはプロセスまたはサービスに限定されるであろう。いくつかのコンテナオーケストレーションシステムは、最小の利用可能な演算器としてポッドをデプロイする。ポッドとは、１つ以上のコンテナのグループであり、ポッド内の各コンテナは、隔離境界（たとえばＩＰアドレス）を共有する。コントローラは、ポッド内のリソースを制御する。コントローラは、ポッド、コンテナ、およびリソースの健全性を監視すること（および、必要であれば、ポッド／コンテナを作り直すこと）に関与している。コントローラはまた、ポッドを複製しスケーリングすること、および、（ポッドにとって）外部の事象について監視することに関与している。

ポッドは典型的には一時的で代替可能なリソースであるため、それらは頻繁に作成され破壊される（すなわち、スケールインまたはスケールアウトされる）。いくつかのポッド（すなわち、バックエンド）が他のポッド（すなわち、フロントエンド）に機能性を提供するため、どのバックエンドがフロントエンドのための必要な機能性を提供するかをフロントエンドに追跡させるためにサービスが作成される。サービスとは、論理的な１組のポッドと、それらにアクセスするためのポリシーとを定義する抽象的概念である。すなわち、１つ以上のポッドが、バックエンドを対応するフロントエンドに結び付けるサービスのターゲットとされる。サービスは、選択基準に整合するポッドをターゲットとしてもよい。いくつかの例では、選択基準はラベル選択を含む。すなわち、ポッドはラベルを含んでいてもよく、サービスは、同等性ベースまたは組ベースのラベル整合によって所望のポッドを選択してもよい。

単一の物理マシン（すなわち、コンピュータまたはサーバ）が、１つ以上のコンテナ（たとえばポッド）をホストする。コンテナオーケストレーションシステムはしばしば、物理マシンのクラスタを使用して、多くのポッド間で複数のコンテナ化されたアプリケーションを調整するであろう。典型的には、クラスタにおける各マシンは、１つ以上のマシンがマスターサーバとして機能し、残りのマシンがノードとして機能する状態で、同じ場所に位置する（すなわち、マシンは地理的に互いの近くに位置する）。マスターサーバは、たとえば、クライアントのためにアプリケーションプログラムインターフェイス（ＡＰＩ）を公開すること、ノードの健全性をチェックすること、通信をオーケストレーションすること、スケジューリングすることなどによって、クラスタのための主要制御プレーンおよびゲートウェイとして作用する。ノードは、ローカルリソースおよび外部リソースを使用して作業負荷を受け入れて実行することに関与しており、各ノードは、マスターサーバによって命令されるようにコンテナを作成し破壊する。クライアントは、マスターサーバと（たとえば直接、またはライブラリを介して）通信することによってクラスタと相互作用する。クラスタ内のノードは概して、マスターサーバによって許可される場合を除き、クラスタの外部の接触から隔離され分離される。

負荷分散は複数のコンピューティングリソース間での作業負荷の分散を改良し、分散システムはしばしば、コンテナオーケストレーションシステムの分散される性質に起因して、レイヤ７（Ｌ７）負荷分散を実現する。レイヤ７負荷分散は高レベルのアプリケーション層（すなわちレイヤ７）で動作し、それは、送信されたメッセージの実際のコンテンツを伴う。ハイパーテキスト転送プロトコル（ＨＴＴＰ）およびハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）は、インターネット上のウェブサイトトラフィックのための主流のＬ７プロトコルである。高レベルのため、Ｌ７負荷分散装置は、他のレイヤ負荷分散装置（たとえば、レイヤ４負荷分散装置）よりも洗練されたやり方で、ネットワークトラフィックをルーティングし得る。一般に、Ｌ７負荷分散装置は、ネットワークトラフィックを終了させ、トラフィック内のメッセージコンテンツを分析する。次に、Ｌ７負荷分散装置は、メッセージのコンテンツに基づいて（たとえば、ＨＴＴＰクッキーに基づいて）トラフィックをルーティングしてもよい。次に、Ｌ７負荷分散装置は、適切な宛先ノードへの新たな接続を作成してもよい。

現在のコンテナオーケストレーションシステムは典型的には、単一のクラスタをターゲットとするＬ７負荷分散を提供するに過ぎない。すなわち、各クラスタは、個々の構成を示すコンフィグレーション（configuration）を必要とする別個の負荷分散装置を必要とし、トラフィックは、単一のクラスタ内で分散され得るに過ぎない。トラフィックを適切なクラスタ（たとえば、ソースクライアントに地理的に最も近いクラスタ）にルーティングするには、別個のドメインが必要とされ得る。たとえば、asia.shopping.comは、アジ
アに位置するクラスタにルーティングしてもよく、一方、europe.shopping.comは、ヨー
ロッパのクラスタにルーティングしてもよい。このため、それは、コンテナオーケストレーションシステムにおける複数のクラスタにわたって、高度に利用可能でグローバルに分散されたＬ７サービスをサーブする負荷分散装置にとって有利であろう。この例を続けると、複数のクラスタをサービスする負荷分散装置は、shopping.comに対するＨＴＴＰ（Ｓ）要求を、当該ＨＴＴＰ（Ｓ）要求のソースおよび／またはクラスタでの容量に基づいて、アジアのクラスタまたはヨーロッパのクラスタにルーティングすることができるであろう。

ここでの実現化例は、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を１組の宛先クラスタ間で分散させるための、コンテナオーケストレーションシステムのマルチクラスタ負荷分散装置に向けられる。マルチクラスタ負荷分散装置は、１組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを受信する。ここで使用されるように、負荷分散コンフィグレーションは、イングレスコンフィグレーションと呼ばれてもよい。各宛先クラスタは、（他のポッドまたはクラスタから少なくとも部分的に隔離された）セキュアな実行環境においてソフトウェアアプリケーションを実行する少なくとも１つのポッドと、それぞれの地理的領域とを含む。いくつかのシナリオでは、少なくとも１つのポッド／コンテナは、セキュアでない環境においてソフトウェアアプリケーションを実行する。各クラスタは、異なる地理的領域を有していてもよい。マルチクラスタ負荷分散装置は、１組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信し、負荷分散装置は、アプリケーションレベル要求の地理的位置と１組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を宛先クラスタのうちの１つにルーティングする。このため、負荷分散装置は、複数のクラスタをターゲットとしつつ、当該クラスタのすべてにわたって管理および構成の単一の点を提供する。負荷分散装置は、コンテナ固有の負荷分散（すなわち、トラフィックをポッドに直接分散させること）を利用してもよく、クラスタがオフラインになると、ホストされたサービスのための高い利用可能性を提供する。

ここで図１を参照して、いくつかの実現化例では、例示的なシステム１００は、リモートシステム１１４を含む。リモートシステム１１４は、スケーラブル／柔軟なコンピューティングリソース１１８（たとえばデータ処理ハードウェア）および／またはストレージリソース１１６（たとえばメモリハードウェア）を有する、単一のコンピュータ、複数のコンピュータ、または分散システム（たとえばクラウド環境）であってもよい。リモートシステム１１４は、ネットワーク１１２ａを介して、１つ以上のクラスタ１２０、１２０ａ～ｎと通信し、各クラスタ１２０は、１つ以上のアプリケーション１２４を各々実行する１つ以上のポッド１２２、１２２ａ～ｎを含む。ここでの例は１つ以上のポッド１２２を含むクラスタ１２０を説明するが、クラスタ１２０は、本開示の範囲から逸脱することなく、１つ以上のソフトウェアアプリケーション１２４を実行するための任意のタイプのコンテナを含んでいてもよい。いくつかの例では、クラスタ１２０のうちの１つ以上の一部またはすべてが、リモートシステム１１４上で実行される。いくつかのポッド１２２は同じアプリケーション１２４を実行してもよく、一方、同じクラスタ１２０または異なるクラスタ１２０内のいくつかのポッド１２２は異なるアプリケーション１２４を実行してもよい。たとえば、各クラスタ１２０は、ショッピングアプリケーション１２４を実行するポッド１２２を含んでいてもよい。サービス１２３とは、同じクラスタ１２０内の複数のポッド１２２上で実行される１つ以上のアプリケーション１２４を表わす。前述の例を続けると、ショッピングサービス１２３は、複数のポッド１２２上で実行されているショッピングアプリケーション１２４を使用してもよい。たとえば、ショッピングアプリケーション１２４を実行しているすべてのポッド１２２は、ショッピングサービス１２３に関連付けられてもよく、各それぞれのポッド１２２は、ショッピングサービス１２３を使用する要求３０を満たすための代替可能なリソースであってもよい。

各クラスタ１２０はまた、それぞれの地理的領域１２１、１２１ａ～ｎに関連付けられる。たとえば、クラスタ１２０ａは、アジアの地理的領域１２１ａに関連付けられてもよく、クラスタ１２０ｂは、ヨーロッパの地理的領域１２１ｂに関連付けられてもよく、クラスタ１２０ｎは、北米の地理的領域１２１ｎに関連付けられてもよい。すなわち、各クラスタ１２０は、クラスタ１２０が物理的に位置する場所の地理的領域１２１に関連付けられてもよい。各クラスタ１２０は異なる地理的領域１２１に位置していてもよいが、いくつかの例では、複数のクラスタ１２０が同じ地理的領域１２１を共有する。

リモートシステム１１４はまた、ネットワーク１１２ｂを介して、１つ以上のクライアント１０、１０ａ～ｎと通信している。ネットワーク１１２ａ、１１２ｂは、同じネットワークであっても、異なるネットワークであってもよい。各クライアント１０は、デスクトップワークステーション、ラップトップワークステーション、モバイルデバイス（たとえば、スマートフォンまたはタブレット）、ウェアラブルデバイス、スマート機器、スマートディスプレイ、またはスマートスピーカといった任意の好適なコンピューティングデバイスに対応していてもよい。クライアントは、ネットワーク１１２ｂを介して、アプリケーションレベル要求３０、３０ａ～ｎをリモートシステム１１４に送信する。アプリケーションレベル要求３０は、アプリケーションプロトコルのメッセージに対応する。たとえば、アプリケーションレベル要求３０は、ＨＴＴＰまたはＨＴＴＰＳメッセージを含んでいてもよい。すなわち、アプリケーションレベル要求３０は、クライアント１０からのＨＴＴＰ（Ｓ）要求メッセージに対応していてもよい。オプションで、アプリケーションレベル要求３０は、追加の通信セキュリティを提供するために、ＴＬＳプロトコルを含んでいてもよい。

リモートシステム１１４は、いくつかの例では、マルチクラスタ負荷分散装置１３０を実行し、それは、アプリケーションレベル要求３０と、アプリケーションレベル要求３０の負荷を分散させるように負荷分散装置１３０を構成する負荷分散コンフィグレーション（たとえばイングレスコンフィグレーション）１３２とを受信する。各アプリケーション
レベル要求３０は、ソースクライアント１０に関連付けられたホスト名３２および地理的位置３４を含む。ホスト名３２は、宛先ネットワークホスト（すなわち、共通の権限下にある１つ以上のコンピュータ）を識別する選択基準（たとえばラベル）に対応する。たとえば、http://my-shop.comは、ＨＴＴＰプロトコルとmy-shop.comというホスト名とを示
すユニフォームリソースロケータ（ＵＲＬ）である。地理的位置３４は、それぞれのクライアント１０の物理的位置（たとえば、インターネットプロトコル（ＩＰ）アドレス）に対応する。いくつかのアプリケーションレベル要求３０は、パス名３３を追加で含んでいてもよい。たとえば、http:/my-shop.com/sportsというＵＲＬは、my-shop.comというホ
スト名と、/sportsというパス名とを示す。

負荷分散装置１３０は、ユーザ１２のためにソフトウェアアプリケーション１２４をホストするクラスタ１２０（宛先クラスタ１２０とも呼ばれる）へのアクセスを管理する。すなわち、負荷分散コンフィグレーション（たとえばイングレスコンフィグレーション）１３２によって提供されたコンフィグレーションを使用して、負荷分散装置１３０は、宛先クラスタ１２０上のソフトウェアアプリケーション１２４に向けられるアプリケーションレベル要求３０を受信し、アプリケーションレベル要求３０の地理的位置３４と宛先クラスタ１２０のそれぞれの地理的領域１２１とに基づいて、各アプリケーションレベル要求３０を宛先クラスタ１２０のうちの１つにルーティングする。たとえば、それぞれのアプリケーションレベル要求３０に関連付けられた地理的位置３４が、アプリケーションレベル要求３０が北米から生じたことを示す場合、負荷分散装置１３０は、アプリケーションレベル要求３０を、対応する地理的領域１２１ｎ（すなわち北米）を有するクラスタ１２０ｎにルーティングしてもよい。

図１を引き続き参照して、いくつかの実現化例では、マルチクラスタコントローラ２００が負荷分散コンフィグレーション１３２を受信し、負荷分散コンフィグレーション１３２を使用してマルチクラスタイングレス４００を構成する。マルチクラスタコントローラ２００によって構成されたマルチクラスタイングレス４００は、クラスタ１２０上で実行されているソフトウェアアプリケーション１２４へのＵＲＬパスのマッピング（すなわち、ＵＲＬマッピング４１０）を含む。すなわち、マルチクラスタイングレス４００がそれぞれのクラスタ１２０のそれぞれのポッド１２２内で実行されているそれぞれのソフトウェアアプリケーション１２４に向けられたアプリケーションレベル要求３０を受信した場合、マルチクラスタイングレス４００は、アプリケーションレベル要求３０の地理的位置３４および関連するソフトウェアアプリケーション１２４に基づいて、ＵＲＬマッピング４１０を使用してアプリケーションレベル要求３０を適切なクラスタ１２０にルーティングする。ユーザ１２は、アプリケーション１２４またはサービス１２３をホストするための宛先クラスタ１２０の作成者に対応していてもよい。そのため、ユーザ１２は、負荷分散コンフィグレーション１３２を、マルチクラスタ負荷分散装置１３０のマルチクラスタコントローラ２００に提供してもよい。

ここで図２を参照して、マルチクラスタコントローラ２００は、いくつかの例では、負荷分散コンフィグレーション１３２のマルチクラスタサービス２１０を受信することに関与している。たとえば、マルチクラスタ負荷分散装置１３０は、負荷分散コンフィグレーション１３２に基づいてマルチクラスタサービス２１０をインスタンス化してもよい。マルチクラスタサービス２１０とは、複数のクラスタ１２０にまたがるリソースを表わす。いくつかの例では、負荷分散コンフィグレーション１３２は、マルチクラスタサービス２１０を一意的に識別するユーザ由来サービス名２１１（すなわち、ユーザ１２に由来するサービス名）を含む。マルチクラスタサービス２１０は、いくつかの実現化例では、クラスタ選択区分２１２を含み、それは、どのクラスタ１２０が宛先クラスタ１２０であるかと、当該宛先クラスタ１２０の負荷分散特性とを定義する。すなわち、クラスタ選択区分２１２は、マルチクラスタサービス２１０のためのアプリケーションレベルトラフィック（すなわち、アプリケーションレベル要求３０）をサーブするであろう既知のクラスタのリスト１２５からクラスタ１２０を選択するためにマルチクラスタサービス２１０によって特定されたクラスタ選択基準２１３を識別する。既知のクラスタリスト１２５は、既知のクラスタ１２０のレジストリを含んでいてもよく、または、単にクラスタレジストリを指してもよく、クラスタレジストリは、リモートシステム１１４のストレージリソース１１６上に格納され、ユーザ１２が所有／作成するかまたはアクセスを有する複数のクラスタを含んでいてもよい。クラスタ選択基準２１３を使用して、マルチクラスタコントローラ２００は次に、マルチクラスタサービス２１０によって特定されたクラスタ選択基準２１３を満たす１つ以上のラベル２１６のそれぞれの組を有する各宛先クラスタ１２０に基づいて、クラスタレジストリ１２５から１組の宛先クラスタ１２０を選択する。すなわち、選択されたクラスタ１２０は、クラスタ１２０がユニットとして選択されることを可能にするための共通の１組のラベル２１６を、クラスタ１２０のすべてにわたって共有していてもよい。オプションで、マルチクラスタサービス２１０によって特定されたクラスタ選択基準２１３は、１つ以上の同等性ベースの整合要件（たとえば、環境＝生産）、または１つ以上の組ベースの整合要件（たとえば、（生産、ｑａ）における環境）のうちの少なくとも１つを含む。

マルチクラスタサービス２１０はまた、マルチクラスタコントローラ２００が各宛先クラスタ１２０および負荷分散装置１３０においてインスタンス化／作成するサービス２２０を定義するサービステンプレート２１４を含んでいてもよい。いくつかの例では、マルチクラスタサービス２１０を定義することにより、マルチクラスタコントローラ２００は、派生サービス２２０を宛先クラスタ１２０において自動的にインスタンス化してもよい。図示された例では、マルチクラスタコントローラ２００は、マルチクラスタサービス２１０を（クラスタ選択区分２１２およびサービステンプレート２１４とともに）受信し、対応する派生リソース（すなわちショッピングサービス２２０）を各宛先クラスタ１２０ａ、１２０ｂ、１２０ｃにおいてインスタンス化する。マルチクラスタコントローラ２００は、派生サービス２２０のライフサイクル（たとえば、サービス２２０を作成し、同期させ、削除すること）全体を自動的に管理してもよい。マルチクラスタコントローラ２００は、作成（create）、読取り（read）、更新（update）、および削除（delete）（ＣＲＵＤ）動作を使用して、派生サービス２２０をインスタンス化して管理してもよい。このため、マルチクラスタサービス２１０（たとえばショッピングサービス）に対応するアプリケーションレベル要求３０は、マルチクラスタイングレス４００を介して、適切な宛先クラスタ１２０の派生サービス２２０にルーティングしてもよい。

各対応する派生サービス２２０は、他の派生サービス２２０の派生サービス名２２１とは異なる、一意的な派生サービス名２２１を含んでいてもよい。たとえば、派生サービス名２２１は、トリミングされたサービス名部分と、一意ハッシュ値部分とを有する。トリミングされたサービス名部分は、マルチクラスタサービス２１０のユーザ由来サービス名２１１を含んでいてもよく、一意ハッシュ値部分は、マルチクラスタサービス２１０のユーザ由来サービス名の一意ハッシュ値を含んでいてもよい。各派生サービス２２０についてのそれぞれの一意的な派生サービス名２２１は、ユーザ定義サービス１２３の名前との対立を回避してもよい。

いくつかの例では、派生サービス２２０は、エンドポイント２３１、２３１ａ～ｎのグループを含む対応するネットワークエンドポイントグループ（ＮＥＧ）２３０を作成する。エンドポイント２３１のグループにおける各エンドポイント２３１は、対応する宛先クラスタ１２０のそれぞれのポッド１２２に関連付けられる。各エンドポイント２３１は、それぞれのインターネットプロトコル（ＩＰ）アドレス２４２と、アプリケーションレベルトラフィック（すなわち、要求３０）をそれぞれのポッド１２２に直接分散させるためのそれぞれのポート２４４とを含む。すなわち、ＮＥＧ２３０は、バックエンドサービスのためのバックエンドとして動作するクラスタリソースのための、ＩＰアドレス２４２とポート２４４との組合せの集合を表わすリソースであり、ＩＰアドレス２４２とポート２４４との各組合せは、ネットワークエンドポイント２３１と呼ばれる。ＮＥＧ２３０は、ＨＴＴＰ（Ｓ）、伝送制御プロキシ（Transmission Control Proxy：ＴＣＰ）プロキシ、およびＳＳＬプロキシ負荷分散装置といったバックエンドサービスにおけるバックエンドとして使用されてもよい。ＮＥＧバックエンドは、ＩＰアドレス２４２とポート２４４とを特定することによって、ポッド１２２内で動作するアプリケーションまたはコンテナ中にトラフィックを細かい粒度で分散させることを容易にする。同じクラスタ１２０におけるエンドポイント２３１（たとえばポッド１２２）が、ＮＥＧ２３０に割り当てられてもよい。ＮＥＧ２３０は、コンテナ負荷分散装置２４０（すなわち、クラスタ１２０におけるマシンまたはポッド１２２中にトラフィックを分散させるための負荷分散装置）においてバックエンドサービスのためのバックエンドとして機能してもよい。各宛先クラスタ１２０は、それぞれのＮＥＧ２３０をプログラムするための対応するＮＥＧコントローラ２３２を含んでいてもよい。

他の例では、クラスタ１２０は、ＮＥＧ２３０の代わりにインスタンスグループを実現する。インスタンスグループは、ＮＥＧ２３０と同様に、エンドポイント（たとえば仮想マシンインスタンス）の集合を単一のエンティティとしてともにグループ化し、ＩＰテーブルを使用することによって要求３０を適切なエンドポイントにルーティングする。インスタンスグループは、自動スケーリングを有するかまたは有さない管理されたインスタンスグループであってもよく、もしくは、管理されていないインスタンスグループであってもよい。

インスタンスグループの代わりにＮＥＧ２３０を実現する場合、マルチクラスタコントローラ２００は、システム１００の他のコンポーネントによる容易な検索のために、各ＮＥＧ２３０の名前（すなわちラベル）を格納してもよい。各ＮＥＧ２３０は、ＮＥＧコントローラ２３２によって管理されるファイアウォールを含んでいてもよく、各ＮＥＧが一意的な１組のポート２４４を開放することを可能にする。それに代えて、またはそれに加えて、マルチクラスタコントローラ２００は、すべての宛先クラスタ１２０のポート範囲に影響を与えるファイアウォールコントローラをインスタンス化してもよい。ファイアウォールコントローラは、たとえば、ポート範囲全体が開いていることを保証し、次に、各個々のＮＥＧコントローラ２３２がそのそれぞれのポート範囲をカスタマイズすることを可能にし得る。

ここで図３Ａおよび図３Ｂを参照して、いくつかの例では、リモートシステム１１４は、コンテナ負荷分散装置２４０を実現するために追加のコンポーネントを実行する。たとえば、転送ルール３１０は、アプリケーションレベル要求３０を、それぞれのクラスタ１２０のグローバル外部ＩＰアドレスから、適切なターゲットプロキシ３２０（図３Ａ）に向けてもよい。転送ルール３１０は、ＩＰアドレス、ポート、およびプロトコルによって、ターゲットプロキシ３２０と、ＵＲＬマッピング３３０（たとえばＵＲＬマッピング４１０）と、１つ以上のバックエンドサービス３４０、すなわちサービス１２３（図１）とからなる負荷分散構成に、要求３０をルーティングする。各転送ルール３１０は、クラスタ１２０のための単一のグローバルＩＰアドレスを提供してもよい。ターゲットプロキシ３２０は、クライアント１０からの接続（たとえば、ＨＴＴＰおよびＨＴＴＰＳ接続）を終了させる。ターゲットプロキシ３２０は、受信された各要求３０をＵＲＬマッピング３３０と照合して、要求３０にとってどのバックエンドサービス３４０が適切であるかを判断する。ＨＴＴＰＳ接続をルーティングする場合、ターゲットプロキシ３２０は、負荷分散装置２４０とクライアント１０との間の通信を認証するための１つ以上のセキュアソケット層（Secure Sockets Layer：ＳＳＬ）証明書を含んでいてもよい。

図３Ｂに示すように、ＩＰテーブルルールを介してトラフィックを（同じノード／仮想マシン内にあってもなくてもよい）コンテナ（たとえばポッド）１２２にルーティングするインスタンスグループとは異なり、ＮＥＧ２３０は、トラフィック（すなわち、要求３０）を受信するべきコンテナ（たとえばポッド）１２２にトラフィックが直接ルーティングされることを可能にし、それは、余分のネットワークホップを排除する。減少したネットワークホップは、ネットワークの待ち時間およびスループットの双方を向上させる。

ＵＲＬマッピング３３０は、適切なバックエンドサービス３４０への要求３０のＵＲＬベースのルーティングのための整合パターンを定義する。いくつかの例では、デフォルトサービス３４０は、特定されたホストルールまたはパス整合ルールに整合しないあらゆる要求３０を扱うために定義される。オプションで、マルチクラスタコントローラ２００は、派生したデフォルトサービスを宛先クラスタ１２０において作成してもよい。要求３０のコンテンツベースのルーティングのために、ＵＲＬマッピング３３０は、ＵＲＬコンポーネントを調べることによって要求３０を分割し、要求３０を異なる組のバックエンド３４０に送信する。複数のバックエンドサービス３４０が、ＵＲＬマッピング３３０から参照されてもよい。

バックエンドサービス３４０は、入ってきた要求３０を、取り付けられたＮＥＧ２３０の１つ以上のエンドポイントに向ける。バックエンドサービス３４０は、たとえば、その取り付けられたバックエンドのサーブ容量、ゾーン、およびインスタンス健全性に基づいて、各要求３０を、接続されたＮＥＧ２３０のうちの１つの適切なエンドポイントに向ける。エンドポイントサーブ容量は、ＣＰＵまたは１秒あたりの要求数（requests per second：ＲＰＳ）（すなわち、エンドポイントが１秒あたりに処理できる要求３０の量）に基づいていてもよい。各バックエンドサービス３４０はまた、ＮＥＧ２３０のエンドポイントに対してどの健全性チェックを行なうかを特定してもよい。

ここで図４を参照して、マルチクラスタコントローラ２００は、ユーザ由来サービス名２１１を使用して、マルチクラスタイングレス４００と、マルチクラスタイングレス４００によって定義されたマルチクラスタサービス２１０とを管理する。マルチクラスタイングレス４００は、レイヤ７プロトコルおよび終了設定（たとえば、トランスポート層セキュリティ（ＴＬＳ）証明書）を含み、ＵＲＬマッピング４１０は、宛先クラスタ１２０上で実行される１つ以上のサービス１２３にマッピングする１つ以上のホスト名４１２および／またはＵＲＬパスのリストを特定する。各宛先クラスタ１２０は、マルチクラスタサービス２１０と通信するそれぞれの派生サービス２２０を含む。マルチクラスタコントローラ２００が受信するソフトウェアアプリケーション１２４（またはサービス１２３）に向けられた各アプリケーションレベル要求３０について、マルチクラスタコントローラ２００は、受信されたアプリケーションレベル要求３０のホスト名３２が、ＵＲＬマッピング４１０によって特定された１つ以上のホスト名４１２のリストにおけるホスト名４１２のうちの１つを含むかどうかを判断する。それに代えて、またはそれに加えて、コントローラ２００は、受信されたアプリケーションレベル要求３０のＵＲＬパス３３が、ＵＲＬマッピング４１０によって特定されたパス４１３のリストにおけるパスのうちの１つを含むかどうかを判断してもよい。受信されたアプリケーションレベル要求３０のホスト名３２（および／またはパス３３）が、リストにおけるホスト名４１２（および／またはパス４１３）のうちの１つを含む場合、マルチクラスタコントローラ２００は、受信されたアプリケーションレベル要求３０を、アプリケーション１２４またはサービス１２３（たとえばショッピングサービス）に関連付けられたマルチクラスタサービス２１０に転送する。ここで、マルチクラスタサービスコントローラ２００は、受信されたアプリケーションレベル要求３０の負荷を、デプロイされたサービス１２３を実行する宛先クラスタ１２０、１２０ａ～ｃのうちの１つのそれぞれの宛先サービス２２０に分散させる任務を負う。いくつかの実現化例では、マルチクラスタサービスコントローラ２００は、宛先クラスタ
１２０のそれぞれの地理的領域１２１ａ～ｃに基づいて、どの宛先クラスタ１２０が要求３０の地理的位置３４（たとえば、要求３０を送信したクライアント１０に関連付けられた位置３４）に最も近いかを判断する。マルチクラスタコントローラ２００は、マルチクラスタサービス２１０によって定義されたルーティング決定を介して、アプリケーションレベル要求３０を、アプリケーションレベル要求３０のクライアント１０に関連付けられた地理的位置３４に最も近いそれぞれの地理的領域１２１を有する宛先クラスタ１２０にルーティングしてもよい。

図示された例では、クライアント１０ａは東京に位置し、クライアント１０ｂはサンノゼに位置し、クライアント１０ｃはボストンに位置する。また、ショッピングサービス１２３を実行する１組の宛先クラスタ１２０は、東京の地理的領域１２１ａに関連付けられた第１のクラスタ１２０ａと、サンフランシスコの地理的領域１２１ｂに関連付けられた第２のクラスタ１２０ｂと、ニューヨークシティの地理的領域１２１ｃに関連付けられた第３のクラスタ１２０ｃとを含む。各クライアント１０ａ、１０ｂ、１０ｃは、それぞれのアプリケーションレベル要求３０ａ、３０ｂ、３０ｃを送信し、それらはコントローラ２００によって受信される。コントローラ２００は、要求３０に関連付けられた地理的位置３４（すなわち、東京、サンノゼ、およびボストン）に基づいて、要求３０ａをクラスタ１２０ａにルーティングし、要求３０ｂをクラスタ１２０ｂにルーティングし、要求３０ｃをクラスタ１２０ｃにルーティングする。いくつかの例では、マルチクラスタコントローラ２００は、最小の待ち時間（すなわち、要求３０がクライアント１０からそれぞれのクラスタ１２０まで進むのにかかる時間の量）に関連付けられたクラスタ１２０に基づいて、各要求３０をルーティングする。すなわち、各宛先クラスタ１２０は、クライアント１０からのそれぞれの待ち時間を有し、マルチクラスタコントローラ２００は、時間の任意の所与のインスタンスで各宛先クラスタ１２０の最小待ち時間を有するクラスタ１２０に、要求３０をルーティングしてもよい。他の例では、マルチクラスタコントローラ２００は、要求の地理的位置３４に関連付けられた領域ラベルとクラスタ１２０の地理的領域１２１に関連付けられた領域ラベルとを整合させる同等性に基づいて、各要求をルーティングする。たとえば、要求３０は、「アジア」に対応する領域ラベルを含んでいてもよく、マルチクラスタイングレス４００は、要求３０を、整合する領域ラベル（すなわち「アジア」）を有するクラスタにルーティングしてもよい。

いくつかの例では、コントローラ２００は、マルチクラスタサービス２１０によって特定されたそれぞれの負荷分散（load balancing：ＬＢ）属性４２０に基づいて、要求３０をルーティングする。たとえば、アプリケーションレベル要求３０は、最も近い（すなわち、地理的に最も近い）利用可能なクラスタ１２０に常にルーティングされてもよい。いくつかの実現化例では、クラスタ１２０は、クライアントの要望に応えるために、自動的にスケーリングする（たとえば、各クラスタ１２０内のコンテナ（たとえばポッド）１２２の数を増加または減少させる）であろう。この例では、各クラスタは、実際には、無限のリソースを有し、このため、クライアント１０は、最も近いクラスタ１２０に常にルーティングされるであろう。クライアントの要望に基づいてリソースの数をクラスタごとに自動的にスケーリングすることにより、クラスタ１２０ごとの利用量（すなわち、利用可能なリソース全体に対する使用リソースのパーセンテージ）は、高いままである。図４の例では、クラスタ１２０が、クライアントの要望に応えるために無限の容量を有する場合、クラスタ１２０は、負荷分散装置１３０がサンノゼおよびボストンからよりも東京からより多数のアプリケーションレベル要求３０（すなわち、１秒あたりの要求数）を受信している場合に、東京の地理的領域１２１ａ内の第１のクラスタ１２０ａがエンドユーザの要望の増加を満たすためにリソース／コンテナ１２２（たとえばポッド）の数をスケールアップするように、エンドユーザの要望を満たすために動的にスケーリングしてもよい。また、他の地理的領域１２１ｂ、１２１ｃ内の第２および第３のクラスタ１２０ｂ、１２０ｃのうちの少なくとも１つが、対応する地理的位置３４でのエンドユーザの要望に基づいてスケールダウンしてもよい。負荷分散装置１３０が要求３０を最も近い地理的領域１２１にルーティングするこれらの自動スケーリングシナリオでは、クラスタ１２０は、ステートフルなサービス１２３を提供するために、互いに状態を同期させるように要求され得る。負荷分散装置１３０は、クラスタ１２０の各々での動的容量に基づいて連続的に更新してもよい。

他の実現化例では、クラスタ１２０は、固定されたリソース容量を有する（すなわち、クラスタ１２０はスケーリングしない）。この状況では、アプリケーションレベル要求３０をルーティングする前に、マルチクラスタコントローラ２００は、各宛先クラスタ１２０について、宛先クラスタ１２０に現在ルーティングされているアプリケーションレベル要求３０の数（たとえば、１秒あたりの要求数）が最大要求レートを満たすかどうかを判断する。アプリケーションレベル要求３０の数が最大要求レートを満たす場合、マルチクラスタコントローラ２００は、宛先クラスタ１２０へのアプリケーションレベル要求３０のルーティングを防止する。すなわち、負荷分散属性４２０は最大要求レート（すなわち、最大ＲＰＳ）を含んでいてもよく、この状況では、上述のような地理的領域１２１に基づく最も近いクラスタが、そのしきい値ＲＰＳを満たすかまたは上回る場合、マルチクラスタイングレス４００は、（たとえば、待ち時間または領域ラベルに基づいて）要求３０を次に最も近いクラスタ１２０にルーティングしてもよい。２番目に近いクラスタ１２０もその最大ＲＰＳを上回る場合、マルチクラスタイングレス４０は、３番目の最も近いクラスタ１２０に移る、というようになってもよい。また、宛先クラスタ１２０のうちの少なくとも１つに関連付けられた固定されたリソース容量は、他の宛先クラスタ１２０に関連付けられた固定されたリソース容量とは異なっていてもよい。

負荷分散属性４２０は、それに加えて、またはそれに代えて、アプリケーションレベル要求３０が、要求３０に応える容量を有する地理的に最も近いクラスタ１２０にルーティングされるようにする、マルチクラウドおよび／またはハイブリッド負荷分散属性を含んでいてもよい。クラスタ１２０は、別のクラウドコンピューティングネットワークにあってもよく、または、さらには、アプリケーションレベル要求３０が生じたのと同じ地理的位置３４にあってもよい（たとえば、オンプレミス）。これは、単一のクラウドコンピューティングネットワークにおける複数の地域的機能停止に対する回復力がある、高度に利用可能なサービスを可能にし、新たなクラウドコンピューティングネットワークの開始を容易にする。

各クラスタ１２０は個別化された負荷分散属性４２０を受信してもよく、または、同じ属性４２０がすべての宛先クラスタ１２０に適用されてもよい。ユーザ１２が負荷分散属性４２０を提供しない場合、マルチクラスタイングレス４００は、デフォルト挙動（たとえば、最小待ち時間を有するクラスタ１２０）に基づいてルーティングしてもよい。

いくつかの実現化例では、負荷分散属性４２０は、データ局所性ルーティング属性を含む。すなわち、負荷分散属性は、ＨＴＴＰ（Ｓ）ヘッダ情報（たとえばＨＴＴＰクッキー）に基づいて、アプリケーションレベル要求３０をクラスタ１２０にルーティングしてもよい。これは、クライアント１０が、それらのアプリケーションレベル要求３０を、それらのデータをすでにホストしているクラスタ１２０の地理的位置／領域１２１にルーティングさせ、あらゆるデータレジデンシー要件または法則を満たすのに役立つことを可能にする。そのため、１組の宛先クラスタ１２０にわたって実行されている根底的なサービス１２３のために、単一のＩＰアドレスを発行するだけでよい。データレジデンシーとは一般に、クライアントデータが特定の国の境界内で処理および／または格納されなければならないという要件として定義される。オプションで、クラスタ１２０は、複数の組のクライアント１０を同時にサーブするために、互いの間でデータを同期させる。ここで、リソース／コンテナ／ポッド１２２は、エンドユーザの要望に基づいて、それぞれのクラスタ
内でスケールアップまたはダウンしてもよい。同期されたデータはまた、クラスタ１２０が障害を起こすかまたは他の態様で不健全である場合に、アプリケーションレベル要求３０が代替的なクラスタ１２０にルーティング変更されること可能にする。負荷分散属性４２０は、アプリケーションレベル要求３０がＨＴＴＰクッキーまたはｇｅｏ－ヘッダなどのＨＴＴＰ（Ｓ）ヘッダ情報に基づいて単一のクラスタ内のサービスにルーティングされる、クライアントベースのルーティングを含む。これは、負荷分散装置１３０が容易にクライアント１０をグループ化して異なるサービスにルーティングすることを可能にする。

負荷分散属性４２０はまた、トラフィック分割のための属性を含んでいてもよい。トラフィック分割属性は、負荷分散装置１３０が、ユーザ１２によって定義されたクラスタ１２０間のパーセンテージ（％）分割またはＲＰＳ比率に基づいて、アプリケーションレベル要求３０をクラスタ１２０にルーティングすることを可能にする。すなわち、各クラスタは、総トラフィック（すなわち、アプリケーションレベル要求３０）のパーセンテージを（たとえばユーザ１２によって）割り当てられてもよく、コントローラ２００は、割り当てられたパーセンテージに基づいて、アプリケーションレベル要求３０をクラスタ１２０にランダムにルーティングしてもよい。そのようなトラフィック分割は、新しい地理的領域１２１におけるクラスタ１２０への作業負荷の移行を容易にする。なぜなら、新しい地理的領域１２１におけるクラスタ１２０は、ゆっくり育てられ得る（すなわち、小さいパーセンテージから始めて、時間とともにパーセンテージを増加させる；カナリアデプロイメントと呼ばれることもある）ためである。トラフィック分割のための属性を特定する負荷分散属性４２０は、マルチ領域分割または領域内分割を可能にしてもよい。マルチ領域分割では、トラフィックは、地理的領域１２１にわたって分割されてもよい。そのため、所与の地理的領域３４における同じクライアント１０からの複数のアプリケーションレベル要求３０は、２つ以上の地理的領域１２１におけるクラスタ１２０にルーティングされてもよい。たとえば、ボストンにいるクライアント１０ｃは、複数のアプリケーションレベル要求３０を発行してもよく、それにより、負荷分散装置１３０は、これらの要求３０の一部を、ニューヨークシティに関連付けられた地理的領域１２１ｃにおける第３の宛先クラスタ１２０ｃにルーティングし、これらの要求３０の残りの部分を、東京に関連付けられた地理的領域１２１ａにおける第１の宛先クラスタ１２０ａにルーティングする。領域内分割では、トラフィックは、同じ地理的領域１２１内でのみ分割されてもよい。すなわち、領域内分割では、アプリケーションレベル要求３０は、同じ地理的領域１２１内でのみ分割されてもよく、一方、領域間トラフィックは影響されない。たとえば、東京にいるクライアント１０は、アジアに関連付けられた地理的領域１２１に位置する２つの別個のクラスタ１２０間で分割されてもよいが、ヨーロッパに関連付けられた地理的領域１２１を有するクラスタにはルーティングされない。負荷分散属性４２０はまた、クラスタ内トラフィック分割を可能にしてもよい。クラスタ内トラフィック分割では、アプリケーションレベル要求３０は、割り当てられた（すなわち、負荷分散属性４２０によって割り当てられた）パーセンテージに基づいて、単一のクラスタ１２０内のサービスにランダムにルーティングされてもよい。これは、たとえば、サービスの新バージョンの検査を可能にする。すなわち、トラフィックの大部分がサービスのオリジナルバージョンにルーティングされている一方で、サービスの新バージョンは検査のために小さいパーセンテージのトラフィックでルーティングされてもよい。

図５は、マルチクラスタコンテナ化オーケストレーションシステム１００中にアプリケーションレベル要求３０の負荷を分散させるための例示的な方法５００のフローチャートである。方法５００は、図１～４を参照して説明されてもよい。方法５００は、動作５０２で、ユーザ１２によってデプロイされたソフトウェアアプリケーション１２４をホストする１組の宛先クラスタ１２０へのアクセスを管理するマルチクラスタ負荷分散装置１３０のための負荷分散コンフィグレーション１３２を、データ処理ハードウェア１１８で受信するステップで始まる。マルチクラスタ負荷分散装置１３０は、ソフトウェアアプリケ
ーション１２４に関連付けられたアプリケーションレベルトラフィック３０の負荷を１組の宛先クラスタ１２０間で分散させるために負荷分散コンフィグレーション１３２を使用するように構成される。各宛先クラスタ１２０は、ソフトウェアアプリケーション１２４を実行する少なくとも１つのコンテナ１２２と、それぞれの地理的領域１２１とを含み、それぞれの地理的領域１２１は、１組の宛先クラスタ１２０における宛先クラスタ１２０のうちの別の１つに関連付けられた少なくとも１つの他の地理的領域１２１と同じであるかまたは異なっている。

動作５０４で、方法５００は、１組の宛先クラスタ１２０にわたってホストされたソフトウェアアプリケーション１２４に向けられたアプリケーションレベル要求３０を、データ処理ハードウェア１１８で受信するステップを含む。アプリケーションレベル要求３０はクライアント１０から受信され、クライアント１０に関連付けられたホスト名３２および地理的位置３４を含む。アプリケーションレベル要求３０はまた、パス名３３を含み得る。動作５０６で、方法５００は、データ処理ハードウェア１１８が、アプリケーションレベル要求３０の地理的位置３４と１組の宛先クラスタ１２０のそれぞれの地理的領域１２１とに基づいて、アプリケーションレベル要求３０を１組の宛先クラスタにおける宛先クラスタ１２０のうちの１つにルーティングするステップを含む。

図６は、この文書で説明されるシステムおよび方法を実現するために使用され得る例示的なコンピューティングデバイス６００の概略図である。コンピューティングデバイス６００は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータといった、さまざまな形態のデジタルコンピュータを表わすよう意図されている。ここに示すコンポーネント、それらの接続および関係、ならびにそれらの機能は単なる例示であることが意図されており、この文書で説明される、および／または請求項に記載のこの発明の実現化例を限定するよう意図されてはいない。

コンピューティングデバイス６００は、プロセッサ６１０と、メモリ６２０と、記憶装置６３０と、メモリ６２０および高速拡張ポート６５０に接続している高速インターフェイス／コントローラ６４０と、低速バス６７０および記憶装置６３０に接続している低速インターフェイス／コントローラ６６０とを含む。コンポーネント６１０、６２０、６３０、６４０、６５０、および６６０の各々は、さまざまなバスを使用して相互接続されており、共通のマザーボード上にまたは他の態様で適宜搭載されてもよい。プロセッサ６１０は、コンピューティングデバイス６００内で実行される命令を処理可能であり、これらの命令は、グラフィカルユーザインターフェイス（graphical user interface：ＧＵＩ）のためのグラフィック情報を、高速インターフェイス６４０に結合されたディスプレイ６８０などの外部入出力デバイス上に表示するために、メモリ６２０内または記憶装置６３０上に格納された命令を含む。他の実現化例では、複数のプロセッサおよび／または複数のバスが、複数のメモリおよび複数のタイプのメモリとともに適宜使用されてもよい。また、複数のコンピューティングデバイス６００が接続されてもよく、各デバイスは（たとえば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとして）必要な動作の部分を提供する。

メモリ６２０は、情報をコンピューティングデバイス６００内に非一時的に格納する。メモリ６２０は、コンピュータ読取可能媒体、揮発性メモリユニット、または不揮発性メモリユニットであってもよい。非一時的メモリ６２０は、プログラム（たとえば命令のシーケンス）またはデータ（たとえばプログラム状態情報）を、コンピューティングデバイス６００による使用のために一時的または永続的に格納するために使用される物理デバイスであってもよい。不揮発性メモリの例は、フラッシュメモリおよび読出専用メモリ（read-only memory：ＲＯＭ）／プログラマブル読出専用メモリ（programmable read-only memory：ＰＲＯＭ）／消去可能プログラマブル読出専用メモリ（erasable programmable read-only memory：ＥＰＲＯＭ）／電子的消去可能プログラマブル読出専用メモリ（electronically erasable programmable read-only memory：ＥＥＰＲＯＭ）（たとえば、典型的にはブートプログラムなどのファームウェアのために使用される）を含むものの、それらに限定されない。揮発性メモリの例は、ランダムアクセスメモリ（random access memory：ＲＡＭ）、ダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）、スタティックランダムアクセスメモリ（static random access memory：ＳＲＡＭ）、相変化メモリ（phase change memory：ＰＣＭ）、およびディスクまたはテープを含むものの、それらに限定されない。

記憶装置６３０は、コンピューティングデバイス６００のための大容量記憶を提供可能である。いくつかの実現化例では、記憶装置６３０は、コンピュータ読取可能媒体である。さまざまな異なる実現化例では、記憶装置６３０は、フロッピー（登録商標）ディスクデバイス、ハードディスクデバイス、光ディスクデバイス、もしくはテープデバイス、フラッシュメモリまたは他の同様のソリッドステートメモリデバイス、もしくは、ストレージエリアネットワークまたは他の構成におけるデバイスを含むデバイスのアレイであってもよい。追加の実現化例では、コンピュータプログラム製品が情報担体において有形に具現化される。コンピュータプログラム製品は、実行されると上述のような１つ以上の方法を行なう命令を含む。情報担体は、メモリ６２０、記憶装置６３０、またはプロセッサ６１０上のメモリといった、コンピュータ読取可能媒体または機械読取可能媒体である。

高速コントローラ６４０はコンピューティングデバイス６００のための帯域幅集約的な動作を管理し、一方、低速コントローラ６６０はより低い帯域幅集約的な動作を管理する。役目のそのような割当ては例示に過ぎない。いくつかの実現化例では、高速コントローラ６４０は、メモリ６２０、ディスプレイ６８０に（たとえば、グラフィックスプロセッサまたはアクセラレータを介して）結合されるとともに、さまざまな拡張カード（図示せず）を受け付け得る高速拡張ポート６５０に結合される。いくつかの実現化例では、低速コントローラ６６０は、記憶装置６３０および低速拡張ポート６９０に結合される。さまざまな通信ポート（たとえば、ＵＳＢ、ブルートゥース（登録商標）、イーサネット（登録商標）、無線イーサネット）を含み得る低速拡張ポート６９０は、キーボード、ポインティングデバイス、スキャナなどの１つ以上の入出力デバイスに、もしくは、スイッチまたはルータなどのネットワーキングデバイスに、たとえばネットワークアダプタを介して結合されてもよい。

コンピューティングデバイス６００は、図に示すように多くの異なる形態で実現されてもよい。たとえばそれは、標準サーバ６００ａとして、またはそのようなサーバ６００ａのグループで複数回実現されてもよく、ラップトップコンピュータ６００ｂとして、またはラックサーバシステム６００ｃの一部として実現されてもよい。

ここに説明されるシステムおよび手法のさまざまな実現化例は、デジタル電子および／または光学回路、集積回路、特別に設計されたＡＳＩＣ（application specific integrated circuit：特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組合せにおいて実現され得る。これらのさまざまな実現化例は、データおよび命令を記憶システムとの間で送受信するように結合された、専用または汎用であり得る少なくとも１つのプログラマブルプロセッサと、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを含むプログラマブルシステム上で実行可能および／または解釈可能である１つ以上のコンピュータプログラムにおける実現を含み得る。

ソフトウェアアプリケーション（すなわち、ソフトウェアリソース）とは、コンピュー
ティングデバイスにタスクを行なわせるコンピュータソフトウェアを指していてもよい。いくつかの例では、ソフトウェアアプリケーションは、「アプリケーション」、「アプリ」、または「プログラム」と呼ばれてもよい。例示的なアプリケーションは、システム診断アプリケーション、システム管理アプリケーション、システム保守アプリケーション、文書処理アプリケーション、表計算アプリケーション、メッセージングアプリケーション、メディアストリーミングアプリケーション、ソーシャルネットワーキングアプリケーション、およびゲーミングアプリケーションを含むものの、それらに限定されない。

これらのコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られている）は、プログラマブルプロセッサのための機械命令を含み、高レベルの手続き型および／またはオブジェクト指向プログラミング言語で、および／またはアセンブリ／機械語で実現され得る。ここに使用されるように、「機械読取可能媒体」および「コンピュータ読取可能媒体」という用語は、機械命令および／またはデータをプログラマブルプロセッサに提供するために使用される任意のコンピュータプログラム製品、非一時的コンピュータ読取可能媒体、機器および／またはデバイス（たとえば磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（Programmable Logic Device：ＰＬＤ））を指し、機械命令を機械読取可能信号として受信す
る機械読取可能媒体を含む。「機械読取可能信号」という用語は、機械命令および／またはデータをプログラマブルプロセッサに提供するために使用される任意の信号を指す。

この明細書で説明されるプロセスおよび論理フローは、データ処理ハードウェアとも呼ばれる１つ以上のプログラマブルプロセッサが、入力データに基づいて動作することおよび出力を生成することによって機能を行なうために１つ以上のコンピュータプログラムを実行することによって行なわれ得る。プロセスおよび論理フローはまた、たとえばＦＰＧＡ（field programmable gate array：フィールドプログラマブルゲートアレイ）または
ＡＳＩＣ（特定用途向け集積回路）といった専用論理回路によって行なわれ得る。コンピュータプログラムの実行にとって好適であるプロセッサは、一例として、汎用および専用マイクロプロセッサと、任意の種類のデジタルコンピュータの任意の１つ以上のプロセッサとを含む。一般に、プロセッサは、命令およびデータを、読出専用メモリまたはランダムアクセスメモリまたはそれら双方から受信するであろう。コンピュータの本質的要素は、命令を行なうためのプロセッサと、命令およびデータを格納するための１つ以上のメモリデバイスとである。一般に、コンピュータはまた、たとえば磁気ディスク、光磁気ディスク、または光ディスクといった、データを格納するための１つ以上の大容量記憶装置を含むであろう。もしくは、当該大容量記憶装置からデータを受信し、または当該大容量記憶装置にデータを転送し、またはそれら双方を行なうように動作可能に結合されるであろう。しかしながら、コンピュータは、そのようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを格納するのに好適であるコンピュータ読取可能媒体は、あらゆる形態の不揮発性メモリ、媒体、およびメモリデバイスを含み、一例として、半導体メモリ装置、たとえばＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイス；磁気ディスク、たとえば内部ハードディスクまたはリムーバブルディスク；光磁気ディスク；ならびに、ＣＤ ＲＯＭおよびＤＶＤ－ＲＯＭディスクを含む。プロセッサおよびメモリは、専用論理回路によって補足され、または専用論理回路に組込まれ得る。

ユーザとの相互作用を提供するために、この開示の１つ以上の局面は、情報をユーザに表示するためのディスプレイデバイス、たとえばＣＲＴ（cathode ray tube：陰極線管）、ＬＣＤ（liquid crystal display：液晶ディスプレイ）モニター、またはタッチスクリーンと、オプションで、ユーザがコンピュータへの入力を提供できるようにするキーボードおよびポインティングデバイス、たとえばマウスまたはトラックボールとを有するコンピュータ上で実現され得る。他の種類のデバイスも同様に、ユーザとの相互作用を提供するために使用され得る。たとえば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、たとえば視覚フィードバック、聴覚フィードバック、または触覚フィードバックであり得る。また、ユーザからの入力は、音響入力、音声入力、または触覚入力を含む任意の形態で受信され得る。加えて、コンピュータは、ユーザによって使用されるデバイスに文書を送信し、当該デバイスから文書を受信することによって、たとえば、ユーザのクライアントデバイス上のウェブブラウザから受信された要求に応答してウェブページを当該ウェブブラウザに送信することによって、ユーザと相互作用することができる。

多くの実現化例が説明されてきた。にもかかわらず、この開示の精神および範囲から逸脱することなく、さまざまな変更を行なってもよいということが理解されるであろう。したがって、他の実現化例は、請求の範囲内にある。

Claims (23)

1. データ処理ハードウェアによって実行されると前記データ処理ハードウェアに動作を行なわせる、コンピュータにより実現される方法であって、前記動作は、
   分散システムの複数の地域ゾーン上でホストされたソフトウェアアプリケーションに向けられた複数のアプリケーションレベル要求を、１つ以上のクライアントから受信することを含み、前記複数の地域ゾーンのうちの各地域ゾーンは、それぞれのノードグループに対して定義するコンテナポッドの対応するクラスタを含み、前記対応するクラスタは、前記ソフトウェアアプリケーションを実行する少なくとも１つのコンテナポッドを含み、前記動作はさらに、
   前記複数のアプリケーションレベル要求のうちの１つ以上のアプリケーションレベル要求を、前記複数の地域ゾーンのうちの特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることと、
   前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記少なくとも１つのコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記１つ以上のアプリケーションレベル要求に関連付けられたトラフィック負荷を満たすことができるかどうかを判断することと、
   前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記少なくとも１つのコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷を満たすことができない場合、前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために、前記特定の地域ゾーンの前記対応するクラスタにおいて１つ以上の新しいコンテナポッドをインスタンス化することによって、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングすることと、
   前記スケーリングの後に、前記複数の地域ゾーンのうちの各地域ゾーンの対応するクラスタの間でデータを同期させることとを含む、方法。
2. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、前記１つ以上のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含む、請求項１に記載の方法。
3. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、負荷分散コンフィグレーションに基づいて前記複数のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含み、前記負荷分散コンフィグレーションは、前記複数のアプリケーションレベル要求を、コンテナポッドの地理的に利用可能な最も近いクラスタにルーティングする、請求項１または２に記載の方法。
4. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、負荷分散コンフィグレーションに基づいて前記複数のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含み、前記負荷分散コンフィグレーションは、前記１つ以上のクライアントのうちのそれぞれのクライアントによって確立される、請求項１または２に記載の方法。
5. 前記特定の地域ゾーンは、前記１つ以上の前記アプリケーションレベル要求の地理的位置に基づいている、請求項１から４のいずれか１項に記載の方法。
6. それぞれのノードグループは、マルチクラスタサービスによって中央管理される、請求項１から５のいずれか１項に記載の方法。
7. 前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために１つ以上の新しいコンテナポッドをインスタンス化することは、開始テンプレートを使用して前記１つ以上の新しいコンテナポッドを生成することを含み、前記開始テンプレートは、それぞれの新しいコンテナポッドで前記ソフトウェアアプリケーションを作成するように構成される、請求項１から６のいずれか１項に記載の方法。
8. 前記それぞれのノードグループは、それぞれのインターネットプロトコル（ＩＰ）アドレスと、アプリケーションレベルトラフィックを１つ以上のコンテナポッドに直接分散させるためのそれぞれのポートとを含む、請求項１から７のいずれか１項に記載の方法。
9. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含む、請求項１から８のいずれか１項に記載の方法。
10. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）を含む、請求項１から９のいずれか１項に記載の方法。
11. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、トランスポート層セキュリティ（ＴＬＳ）プロトコルを含む、請求項１から１０のいずれか１項に記載の方法。
12. システムであって、
    データ処理ハードウェアと、
    前記データ処理ハードウェアと通信しているメモリハードウェアとを含み、前記メモリハードウェアは、前記データ処理ハードウェア上で実行されると前記データ処理ハードウェアに動作を行なわせる命令を格納しており、前記動作は、
    分散システムの複数の地域ゾーン上でホストされたソフトウェアアプリケーションに向けられた複数のアプリケーションレベル要求を、１つ以上のクライアントから受信することを含み、前記複数の地域ゾーンのうちの各地域ゾーンは、それぞれのノードグループに対して定義するコンテナポッドの対応するクラスタを含み、前記対応するクラスタは、前記ソフトウェアアプリケーションを実行する少なくとも１つのコンテナポッドを含み、前記動作はさらに、
    前記複数のアプリケーションレベル要求のうちの１つ以上のアプリケーションレベル要求を、前記複数の地域ゾーンのうちの特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることと、
    前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記少なくとも１つのコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記１つ以上のアプリケーションレベル要求に関連付けられたトラフィック負荷を満たすことができるかどうかを判断することと、
    前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記少なくとも１つのコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷を満たすことができない場合、前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために、前記特定の地域ゾーンの前記対応するクラスタにおいて１つ以上の新しいコンテナポッドをインスタンス化することによって、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングすることと、
    前記スケーリングの後に、前記複数の地域ゾーンのうちの各地域ゾーンの対応するクラスタの間でデータを同期させることとを含む、システム。
13. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、前記１つ以上のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含む、請求項１２に記載のシステム。
14. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、負荷分散コンフィグレーションに基づいて前記複数のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含み、前記負荷分散コンフィグレーションは、前記複数のアプリケーションレベル要求を、コンテナポッドの地理的に利用可能な最も近いクラスタにルーティングする、請求項１２または１３に記載のシステム。
15. 前記複数のアプリケーションレベル要求のうちの前記１つ以上のアプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、負荷分散コンフィグレーションに基づいて前記複数のアプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含み、前記負荷分散コンフィグレーションは、前記１つ以上のクライアントのうちのそれぞれのクライアントによって確立される、請求項１２または１３に記載のシステム。
16. 前記特定の地域ゾーンは、前記１つ以上のアプリケーションレベル要求の地理的位置に基づいている、請求項１２から１５のいずれか１項に記載のシステム。
17. それぞれのノードグループは、マルチクラスタサービスによって中央管理される、請求項１２から１６のいずれか１項に記載のシステム。
18. 前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルー
    ティングされた前記１つ以上のアプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために１つ以上の新しいコンテナポッドをインスタンス化することは、開始テンプレートを使用して前記１つ以上の新しいコンテナポッドを生成することを含み、前記開始テンプレートは、それぞれの新しいコンテナポッドで前記ソフトウェアアプリケーションを作成するように構成される、請求項１２から１７のいずれか１項に記載のシステム。
19. 前記それぞれのノードグループは、それぞれのインターネットプロトコル（ＩＰ）アドレスと、アプリケーションレベルトラフィックを１つ以上のコンテナポッドに直接分散させるためのそれぞれのポートとを含む、請求項１２から１８のいずれか１項に記載のシステム。
20. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を含む、請求項１２から１９のいずれか１項に記載のシステム。
21. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）を含む、請求項１２から２０のいずれか１項に記載のシステム。
22. 前記複数のアプリケーションレベル要求のうちの各アプリケーションレベル要求は、トランスポート層セキュリティ（ＴＬＳ）プロトコルを含む、請求項１２から２１のいずれか１項に記載のシステム。
23. 請求項１～１１のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。

Images