IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ グーグル インコーポレイテッドの特許一覧

<>
  • 特開-マルチクラスタイングレス 図1
  • 特開-マルチクラスタイングレス 図2
  • 特開-マルチクラスタイングレス 図3A
  • 特開-マルチクラスタイングレス 図3B
  • 特開-マルチクラスタイングレス 図4
  • 特開-マルチクラスタイングレス 図5
  • 特開-マルチクラスタイングレス 図6
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024041790
(43)【公開日】2024-03-27
(54)【発明の名称】マルチクラスタイングレス
(51)【国際特許分類】
   G06F 9/50 20060101AFI20240319BHJP
   G06F 9/455 20180101ALI20240319BHJP
【FI】
G06F9/50 150C
G06F9/455 150
【審査請求】有
【請求項の数】21
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2023218014
(22)【出願日】2023-12-25
(62)【分割の表示】P 2022107793の分割
【原出願日】2019-11-21
(31)【優先権主張番号】16/372,220
(32)【優先日】2019-04-01
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】502208397
【氏名又は名称】グーグル エルエルシー
【氏名又は名称原語表記】Google LLC
【住所又は居所原語表記】1600 Amphitheatre Parkway 94043 Mountain View, CA U.S.A.
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】パーワ,マンジョット
(72)【発明者】
【氏名】デリオ,マシュー
(72)【発明者】
【氏名】ドゥ,ボウェイ
(72)【発明者】
【氏名】ラムクマール,ロヒット
(72)【発明者】
【氏名】ジンダル,ニクヒル
(72)【発明者】
【氏名】ベル,クリスチャン
(57)【要約】      (修正有)
【課題】アプリケーション要求の負荷を分散させる。
【解決手段】システム100において、マルチクラスタ負荷分散装置130は、ユーザによってデプロイされたソフトウェアアプリケーション124をホストする1組の宛先クラスタ120へのアクセスを管理するマルチクラスタサービス210のための、負荷分散コンフィグレーション132を受信する。マルチクラスタサービスは、アプリケーションレベルトラフィックの負荷を1組の宛先クラスタ間で分散させるために負荷分散構成を使用する。各宛先クラスタは、ソフトウェアアプリケーションを実行する少なくとも1つのコンテナと、それぞれの地理的領域121とを含む。宛先クラスタは、ホストするソフトウェアアプリケーションに向けられたアプリケーションレベル要求30をクライアント10から受信する。アプリケーションレベル要求はクライアントに関連付けられたホスト名32および地理的位置34を含む。
【選択図】図1
【特許請求の範囲】
【請求項1】
方法(500)であって、
ユーザ(12)によってデプロイされたソフトウェアアプリケーション(124)をホストする1組の宛先クラスタ(120)へのアクセスを管理するマルチクラスタサービス(210)のための負荷分散コンフィグレーション(132)を、データ処理ハードウェア(118)で受信するステップを含み、前記マルチクラスタサービス(210)は、前記ソフトウェアアプリケーション(124)に関連付けられたアプリケーションレベルトラフィックの負荷を前記1組の宛先クラスタ(120)間で分散させるために前記負荷分散コンフィグレーション(132)を使用するように構成され、各宛先クラスタ(120)は、
前記ソフトウェアアプリケーション(124)を実行する少なくとも1つのコンテナ(122)と、
それぞれの地理的領域(121)とを含み、前記それぞれの地理的領域(121)は、前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)のうちの別の1つに関連付けられた少なくとも1つの他の地理的領域(121)と同じであるかまたは異なっており、前記方法はさらに、
前記1組の宛先クラスタ(120)にわたってホストされた前記ソフトウェアアプリケーション(124)に向けられたアプリケーションレベル要求(30)を、前記データ処理ハードウェア(118)で受信するステップを含み、前記アプリケーションレベル要求(30)はクライアント(10)から受信され、前記クライアント(10)に関連付けられたホスト名(32)および地理的位置(34)を含み、前記方法はさらに、
前記データ処理ハードウェア(118)が、前記アプリケーションレベル要求(30)の前記地理的位置(34)と前記1組の宛先クラスタ(120)の前記それぞれの地理的領域(121)とに基づいて、前記アプリケーションレベル要求(30)を前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)のうちの1つにルーティングするステップを含む、方法(500)。
【請求項2】
前記アプリケーションレベル要求(30)をルーティングするステップは、
前記1組の宛先クラスタ(120)におけるどの宛先クラスタ(120)が、前記アプリケーションレベル要求(30)の前記クライアント(10)に関連付けられた前記地理的位置(34)に最も近いかを、前記1組の宛先クラスタ(120)の前記それぞれの地理的位置(34)に基づいて判断するステップと、
前記アプリケーションレベル要求(30)の前記クライアント(10)に関連付けられた前記地理的位置(34)に最も近い前記それぞれの地理的位置(34)を有する、前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)に、前記アプリケーションレベル要求(30)をルーティングするステップとを含む、請求項1に記載の方法(500)。
【請求項3】
前記アプリケーションレベル要求(30)をルーティングすることはさらに、前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について前記マルチクラスタサービス(210)によって特定されたそれぞれの負荷分散属性(420)に基づいている、請求項1または2に記載の方法(500)。
【請求項4】
受信された前記負荷分散コンフィグレーション(132)は、前記マルチクラスタサービス(210)を一意的に識別するユーザ由来サービス名(211)を含む、請求項1~3のいずれか1項に記載の方法(500)。
【請求項5】
前記データ処理ハードウェア(118)が、前記マルチクラスタサービス(210)のためのアプリケーションレベルトラフィックをサーブするであろう既知のクラスタ(12
0)のリストからクラスタ(120)を選択するために前記マルチクラスタサービス(210)によって特定されたクラスタ選択基準(213)を識別するステップと、
前記データ処理ハードウェア(118)が、前記マルチクラスタサービス(210)によって特定された前記クラスタ選択基準(213)を満たす1つ以上のラベル(216)のそれぞれの組を有する前記1組の宛先クラスタ(120)における各宛先クラスタ(120)に基づいて、前記既知のクラスタ(120)のリストから前記1組の宛先クラスタ(120)を選択するステップとをさらに含む、請求項1~4のいずれか1項に記載の方法(500)。
【請求項6】
前記マルチクラスタサービス(210)によって特定された前記クラスタ選択基準(213)は、1つ以上の同等性ベースの整合要件、または1つ以上の組ベースの整合要件のうちの少なくとも1つを含む、請求項5に記載の方法(500)。
【請求項7】
前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について、前記データ処理ハードウェア(118)が、対応する派生サービス(220)を前記宛先クラスタ(120)内でインスタンス化するステップをさらに含み、前記対応する派生サービス(220)は、エンドポイント(231)のグループを含む対応するネットワークエンドポイントグループ(NEG)(230)を作成するように構成され、前記エンドポイント(231)のグループにおける各エンドポイント(231)は、前記宛先クラスタ(120)のそれぞれのコンテナ(122)に関連付けられ、それぞれのインターネットプロトコル(IP)アドレスと、アプリケーションレベルトラフィックを前記それぞれのコンテナ(122)に直接分散させるためのそれぞれのポート(244)とを含む、請求項1~6のいずれか1項に記載の方法(500)。
【請求項8】
各対応する派生サービス(220)は、他の派生サービス(220)の派生サービス名(221)とは異なる、一意的な派生サービス名(221)を含み、前記派生サービス名(221)はトリミングされたサービス名部分と一意ハッシュ値部分とを有し、前記トリミングされたサービス名部分は前記マルチクラスタサービス(210)のユーザ由来サービス名(211)を含み、前記一意ハッシュ値部分は前記マルチクラスタサービス(210)の前記ユーザ由来サービス名(211)の一意ハッシュ値を含む、請求項7に記載の方法(500)。
【請求項9】
前記方法は、前記アプリケーションレベル要求(30)を受信するステップに応答して、
前記データ処理ハードウェア(118)が、ユニフォームリソースロケータ(URL)マッピングにアクセスするステップをさらに含み、前記URLマッピング(410)は、前記宛先クラスタ(120)のうちの1つ以上のサービスにマッピングする1つ以上のホスト名(412)のリストを特定し、前記方法はさらに、
受信された前記アプリケーションレベル要求(30)の前記ホスト名(32)が、前記URLマッピング(410)によって特定された前記1つ以上のホスト名(412)のリストにおける前記1つのホスト名(412)のうちの1つを含むかどうかを、前記データ処理ハードウェア(118)が判断するステップと、
受信された前記アプリケーションレベル要求(30)の前記ホスト名(32)が、前記1つ以上のホスト名(412)を含む場合、前記データ処理ハードウェア(118)が、受信された前記アプリケーションレベル要求(30)を前記サービスに転送するステップとを含む、請求項1~8のいずれか1項に記載の方法(500)。
【請求項10】
前記アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル(HTTP)を含む、請求項1~9のいずれか1項に記載の方法(500)。
【請求項11】
前記アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコルセキュア(HTTPS)プロトコルを含む、請求項1~10のいずれか1項に記載の方法(500)。
【請求項12】
前記アプリケーションレベル要求(30)の少なくとも一部は、トランスポート層セキュリティ(TLS)プロトコルを含む、請求項1~11のいずれか1項に記載の方法(500)。
【請求項13】
前記アプリケーションレベル要求(30)をルーティングするステップの前に、
前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について、
前記宛先クラスタ(120)に現在ルーティングされているアプリケーションレベル要求(30)の数が最大要求レートを満たすかどうかを、前記データ処理ハードウェア(118)が判断するステップと、
前記アプリケーションレベル要求(30)の数が前記最大要求レートを満たす場合、前記宛先クラスタ(120)への前記アプリケーションレベル要求(30)のルーティングを防止するステップとをさらに含む、請求項1~12のいずれか1項に記載の方法(500)。
【請求項14】
システム(100)であって、
データ処理ハードウェア(118)と、
前記データ処理ハードウェア(118)と通信しているメモリハードウェア(116)とを含み、前記メモリハードウェア(116)は、前記データ処理ハードウェア(118)上で実行されると前記データ処理ハードウェア(118)に動作を行なわせる命令を格納しており、前記動作は、
ユーザ(12)によってデプロイされたソフトウェアアプリケーション(124)をホストする1組の宛先クラスタ(120)へのアクセスを管理するマルチクラスタサービス(210)のための負荷分散コンフィグレーション(132)を受信することを含み、前記マルチクラスタサービス(210)は、前記ソフトウェアアプリケーション(124)に関連付けられたアプリケーションレベルトラフィックの負荷を前記1組の宛先クラスタ(120)間で分散させるために前記負荷分散コンフィグレーション(132)を使用するように構成され、各宛先クラスタ(120)は、
前記ソフトウェアアプリケーション(124)を実行する少なくとも1つのコンテナ(122)と、
それぞれの地理的領域(121)とを含み、前記それぞれの地理的領域(121)は、前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)のうちの別の1つに関連付けられた少なくとも1つの他の地理的領域(121)と同じであるかまたは異なっており、前記動作はさらに、
前記1組の宛先クラスタ(120)にわたってホストされた前記ソフトウェアアプリケーション(124)に向けられたアプリケーションレベル要求(30)を受信することを含み、前記アプリケーションレベル要求(30)はクライアント(10)から受信され、前記クライアント(10)に関連付けられたホスト名(32)および地理的位置(34)を含み、前記動作はさらに、
前記アプリケーションレベル要求(30)の前記地理的位置(34)と前記1組の宛先クラスタ(120)の前記それぞれの地理的領域(121)とに基づいて、前記アプリケーションレベル要求(30)を前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)のうちの1つにルーティングすることを含む、システム(100)。
【請求項15】
前記アプリケーションレベル要求(30)をルーティングすることは、
前記1組の宛先クラスタ(120)におけるどの宛先クラスタ(120)が、前記アプリケーションレベル要求(30)の前記クライアント(10)に関連付けられた前記地理
的位置(34)に最も近いかを、前記1組の宛先クラスタ(120)の前記それぞれの地理的位置(34)に基づいて判断することと、
前記アプリケーションレベル要求(30)の前記クライアント(10)に関連付けられた前記地理的位置(34)に最も近い前記それぞれの地理的位置(34)を有する、前記1組の宛先クラスタ(120)における前記宛先クラスタ(120)に、前記アプリケーションレベル要求(30)をルーティングすることとを含む、請求項14に記載のシステム(100)。
【請求項16】
前記アプリケーションレベル要求(30)をルーティングすることはさらに、前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について前記マルチクラスタサービス(210)によって特定されたそれぞれの負荷分散属性(420)に基づいている、請求項14または15に記載のシステム(100)。
【請求項17】
受信された前記負荷分散コンフィグレーション(132)は、前記マルチクラスタサービス(210)を一意的に識別するユーザ由来サービス名(211)を含む、請求項14~16のいずれか1項に記載のシステム(100)。
【請求項18】
前記動作はさらに、
前記マルチクラスタサービス(210)のためのアプリケーションレベルトラフィックをサーブするであろう既知のクラスタ(120)のリストからクラスタ(120)を選択するために前記マルチクラスタサービス(210)によって特定されたクラスタ選択基準(213)を識別することと、
前記マルチクラスタサービス(210)によって特定された前記クラスタ選択基準(213)を満たす1つ以上のラベル(216)のそれぞれの組を有する前記1組の宛先クラスタ(120)における各宛先クラスタ(120)に基づいて、前記既知のクラスタ(120)のリストから前記1組の宛先クラスタ(120)を選択することとを含む、請求項14~17のいずれか1項に記載のシステム(100)。
【請求項19】
前記マルチクラスタサービス(210)によって特定された前記クラスタ選択基準(213)は、1つ以上の同等性ベースの整合要件、または1つ以上の組ベースの整合要件のうちの少なくとも1つを含む、請求項18に記載のシステム(100)。
【請求項20】
前記動作はさらに、前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について、対応する派生サービス(220)を前記宛先クラスタ(120)内でインスタンス化することを含み、前記対応する派生サービス(220)は、エンドポイント(231)のグループを含む対応するネットワークエンドポイントグループ(NEG)(230)を作成するように構成され、前記エンドポイント(231)のグループにおける各エンドポイント(231)は、前記宛先クラスタ(120)のそれぞれのコンテナ(122)に関連付けられ、それぞれのインターネットプロトコル(IP)アドレスと、アプリケーションレベルトラフィックを前記それぞれのコンテナ(122)に直接分散させるためのそれぞれのポート(244)とを含む、請求項14~19のいずれか1項に記載のシステム(100)。
【請求項21】
各対応する派生サービス(220)は、他の派生サービス(220)の派生サービス名(221)とは異なる、一意的な派生サービス名(221)を含み、前記派生サービス名(221)はトリミングされたサービス名部分と一意ハッシュ値部分とを有し、前記トリミングされたサービス名部分は前記マルチクラスタサービス(210)のユーザ由来サービス名(211)を含み、前記一意ハッシュ値部分は前記マルチクラスタサービス(210)の前記ユーザ由来サービス名(211)の一意ハッシュ値を含む、請求項20に記載のシステム(100)。
【請求項22】
前記動作はさらに、前記アプリケーションレベル要求(30)を受信することに応答して、
ユニフォームリソースロケータ(URL)マッピングにアクセスすることを含み、前記URLマッピング(410)は、前記宛先クラスタ(120)のうちの1つ以上のサービスにマッピングする1つ以上のホスト名(412)のリストを特定し、前記動作はさらに、
受信された前記アプリケーションレベル要求(30)の前記ホスト名(32)が、前記URLマッピング(410)によって特定された前記1つ以上のホスト名(412)のリストにおける前記1つのホスト名(412)のうちの1つを含むかどうかを判断することと、
受信された前記アプリケーションレベル要求(30)の前記ホスト名(32)が、前記1つ以上のホスト名(412)のうちの1つを含む場合、受信された前記アプリケーションレベル要求(30)を前記サービスに転送することとを含む、請求項14~21のいずれか1項に記載のシステム(100)。
【請求項23】
前記アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル(HTTP)を含む、請求項14~22のいずれか1項に記載のシステム(100)。
【請求項24】
前記アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコルセキュア(HTTPS)プロトコルを含む、請求項14~23のいずれか1項に記載のシステム(100)。
【請求項25】
前記アプリケーションレベル要求(30)の少なくとも一部は、トランスポート層セキュリティ(TLS)プロトコルを含む、請求項14~24のいずれか1項に記載のシステム(100)。
【請求項26】
前記動作はさらに、前記アプリケーションレベル要求(30)をルーティングする前に、
前記1組の宛先クラスタ(120)における各宛先クラスタ(120)について、
前記宛先クラスタ(120)に現在ルーティングされているアプリケーションレベル要求(30)の数が最大要求レートを満たすかどうかを判断することと、
前記アプリケーションレベル要求(30)の数が前記最大要求レートを満たす場合、前記宛先クラスタ(120)への前記アプリケーションレベル要求(30)のルーティングを防止することとを含む、請求項14~25のいずれか1項に記載の方法(500)。
【発明の詳細な説明】
【技術分野】
【0001】
この開示は、コンテナ化されたオーケストレーションシステムのためのマルチクラスタイングレスに関する。
【背景技術】
【0002】
背景
(分散システムを介する)いくつかのクラウドベースのサービスは、コンテナ化されたオーケストレーションシステムを提供する。これらのシステムは、ソフトウェアが、仮想マシンのような隔離能力を低いオーバーヘッドと高いスケーラビリティとともに提供することによって開発され、デプロイされ、維持されるやり方を作り変えてきた。ソフトウェアアプリケーションはセキュアな実行環境(たとえば、コンテナまたはポッド)において実行され、同じ場所に位置するポッドはクラスタへとグループ化されてもよく、各クラスタは他のクラスタから隔離される。クラスタ内のポッド間でのトラフィックおよび作業負荷の分散を改良するために、負荷分散装置が通常使用される。レイヤ7(Layer 7:L7
)負荷分散(すなわちアプリケーション層)が、メッセージの実際のコンテンツの負荷を分散させる。たとえば、L7負荷分散装置が、ハイパーテキスト転送プロトコル(HyperText Transfer Protocol:HTTP)またはハイパーテキスト転送プロトコルセキュア(HyperText Transfer Protocol Secure:HTTPS)上で動作し、メッセージのコンテン
ツに関するルーティング決定を下すかもしれない。コンテナ化されたオーケストレーションシステムのための負荷分散装置は典型的には、単一のクラスタ上で動作するL7負荷分散装置である。
【発明の概要】
【課題を解決するための手段】
【0003】
概要
この開示の一局面は、マルチクラスタコンテナ化オーケストレーションシステム中にアプリケーション要求の負荷を分散させるための方法を提供する。方法は、ユーザによってデプロイされたソフトウェアアプリケーションをホストする1組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを、データ処理ハードウェアで受信するステップを含む。マルチクラスタサービスは、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を1組の宛先クラスタ間で分散させるために負荷分散コンフィグレーションを使用するように構成される。各宛先クラスタは、ソフトウェアアプリケーションを実行する少なくとも1つのコンテナと、それぞれの地理的領域とを含み、それぞれの地理的領域は、1組の宛先クラスタにおける宛先クラスタのうちの別の1つに関連付けられた少なくとも1つの他の地理的領域と同じであるかまたは異なっている。方法はまた、1組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を、データ処理ハードウェアで受信するステップを含む。アプリケーションレベル要求はクライアントから受信され、クライアントに関連付けられたホスト名および地理的位置を含む。方法はまた、データ処理ハードウェアが、アプリケーションレベル要求の地理的位置と1組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を1組の宛先クラスタにおける宛先クラスタのうちの1つにルーティングするステップを含む。
【0004】
この開示の実現化例は、以下のオプションの機能のうちの1つ以上を含んでいてもよい。いくつかの実現化例では、アプリケーションレベル要求をルーティングするステップは、1組の宛先クラスタにおけるどの宛先クラスタが、アプリケーションレベル要求のクラ
イアントに関連付けられた地理的位置に最も近いかを、1組の宛先クラスタのそれぞれの地理的領域に基づいて判断するステップと、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いそれぞれの地理的領域を有する、1組の宛先クラスタにおける宛先クラスタに、アプリケーションレベル要求をルーティングするステップとを含む。いくつかの例では、アプリケーションレベル要求をルーティングすることはさらに、1組の宛先クラスタにおける各宛先クラスタについてマルチクラスタサービスによって特定されたそれぞれの負荷分散属性に基づいている。受信された負荷分散コンフィグレーションは、マルチクラスタサービスを一意的に識別するユーザ由来サービス名を含んでいてもよい。
【0005】
いくつかの実現化例では、方法は、データ処理ハードウェアが、マルチクラスタサービスのためのアプリケーションレベルトラフィックをサーブするであろうクラスタレジストリからクラスタを選択するためにマルチクラスタサービスによって特定されたクラスタ選択基準を識別するステップと、データ処理ハードウェアが、マルチクラスタサービスによって特定されたクラスタ選択基準を満たす1つ以上のラベルのそれぞれの組を有する1組の宛先クラスタにおける各宛先クラスタに基づいて、クラスタレジストリから1組の宛先クラスタを選択するステップとを含む。マルチクラスタサービスによって特定されたクラスタ選択基準は、1つ以上の同等性ベースの整合要件、または1つ以上の組ベースの整合要件のうちの少なくとも1つを含んでいてもよい。オプションで、方法はさらに、1組の宛先クラスタにおける各宛先クラスタについて、データ処理ハードウェアが、対応する派生サービスを宛先クラスタ内でインスタンス化するステップを含む。派生サービスは、エンドポイントのグループを含む対応するネットワークエンドポイントグループ(network endpoint group:NEG)を作成するように構成される。エンドポイントのグループにおける各エンドポイントは、宛先クラスタのそれぞれのコンテナに関連付けられ、それぞれのインターネットプロトコル(Internet Protocol:IP)アドレスと、アプリケーショ
ンレベルトラフィックをそれぞれのコンテナに直接分散させるためのそれぞれのポートとを含む。
【0006】
各対応する派生サービスは、いくつかの実現化例では、他の派生サービスの派生サービス名とは異なる、一意的な派生サービス名を含む。派生サービス名はトリミングされたサービス名部分と一意ハッシュ値部分とを有する。トリミングされたサービス名部分はマルチクラスタサービスのユーザ由来サービス名を含み、一意ハッシュ値部分はマルチクラスタサービスのユーザ由来サービス名の一意ハッシュ値を含む。方法は、いくつかの例では、アプリケーションレベル要求を受信するステップに応答して、データ処理ハードウェアが、ユニフォームリソースロケータ(Uniform Resource Locator:URL)マッピングにアクセスするステップをさらに含む。URLマッピングは、1つ以上の宛先クラスタのサービスにマッピングする1つ以上のホスト名のリストを特定する。方法はまた、受信されたアプリケーションレベル要求のホスト名が、URLマッピングによって特定された1つ以上のホスト名のリストにおけるホスト名のうちの1つを含むかどうかを、データ処理ハードウェアが判断するステップと、受信されたアプリケーションレベル要求のホスト名が、リストにおけるホスト名のうちの1つを含む場合、データ処理ハードウェアが、受信されたアプリケーションレベル要求をサービスに転送するステップとを含む。
【0007】
アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル(HTTP)を含んでいてもよい。アプリケーションレベルトラフィックはまた、ハイパーテキスト転送プロトコルセキュア(HTTPS)プロトコルを含んでいてもよい。オプションで、アプリケーションレベル要求の少なくとも一部は、トランスポート層セキュリティ(Transport Layer Security:TLS)プロトコルを含んでいてもよい。方法は、いくつかの実現化例では、アプリケーションレベル要求をルーティングするステップの前に、1組の宛先クラスタにおける各宛先クラスタについて、宛先クラスタに現在ルーティングされてい
るアプリケーションレベル要求の数が最大要求レートを満たすかどうかを、データ処理ハードウェアが判断するステップと、アプリケーションレベル要求の数が最大要求レートを満たす場合、宛先クラスタへのアプリケーションレベル要求のルーティングを防止するステップとをさらに含む。
【0008】
この開示の別の局面は、マルチクラスタコンテナ化オーケストレーションシステム中にアプリケーション要求の負荷を分散させるためのシステムを提供する。システムは、データ処理ハードウェアと、データ処理ハードウェアと通信しているメモリハードウェアとを含む。メモリハードウェアは、データ処理ハードウェア上で実行されるとデータ処理ハードウェアに動作を行なわせる命令を格納している。動作は、ユーザによってデプロイされたソフトウェアアプリケーションをホストする1組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを受信することを含む。マルチクラスタサービスは、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を1組の宛先クラスタ間で分散させるために負荷分散コンフィグレーションを使用するように構成される。各宛先クラスタは、ソフトウェアアプリケーションを実行する少なくとも1つのコンテナと、それぞれの地理的領域とを含み、それぞれの地理的領域は、1組の宛先クラスタにおける宛先クラスタのうちの別の1つに関連付けられた少なくとも1つの他の地理的領域と同じであるかまたは異なっている。動作はまた、1組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信することを含む。アプリケーションレベル要求はクライアントから受信され、クライアントに関連付けられたホスト名および地理的位置を含む。動作はまた、アプリケーションレベル要求の地理的位置と1組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を1組の宛先クラスタにおける宛先クラスタのうちの1つにルーティングすることを含む。
【0009】
この局面は、以下のオプションの機能のうちの1つ以上を含んでいてもよい。いくつかの実現化例では、アプリケーションレベル要求をルーティングすることは、1組の宛先クラスタにおけるどの宛先クラスタが、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いかを、1組の宛先クラスタのそれぞれの地理的領域に基づいて判断することと、アプリケーションレベル要求のクライアントに関連付けられた地理的位置に最も近いそれぞれの地理的領域を有する、1組の宛先クラスタにおける宛先クラスタに、アプリケーションレベル要求をルーティングすることとを含む。いくつかの例では、アプリケーションレベル要求をルーティングすることはさらに、1組の宛先クラスタにおける各宛先クラスタについてマルチクラスタサービスによって特定されたそれぞれの負荷分散属性に基づいている。受信された負荷分散コンフィグレーションは、マルチクラスタサービスを一意的に識別するユーザ由来サービス名を含んでいてもよい。
【0010】
いくつかの実現化例では、動作は、マルチクラスタサービスのためのアプリケーションレベルトラフィックをサーブするであろうクラスタレジストリからクラスタを選択するためにマルチクラスタサービスによって特定されたクラスタ選択基準を識別することと、マルチクラスタサービスによって特定されたクラスタ選択基準を満たす1つ以上のラベルのそれぞれの組を有する1組の宛先クラスタにおける各宛先クラスタに基づいて、クラスタレジストリから1組の宛先クラスタを選択することとを含む。マルチクラスタサービスによって特定されたクラスタ選択基準は、1つ以上の同等性ベースの整合要件、または1つ以上の組ベースの整合要件のうちの少なくとも1つを含んでいてもよい。オプションで、動作はさらに、1組の宛先クラスタにおける各宛先クラスタについて、対応する派生サービスを宛先クラスタ内でインスタンス化することを含む。派生サービスは、エンドポイントのグループを含む対応するネットワークエンドポイントグループ(NEG)を作成するように構成される。エンドポイントのグループにおける各エンドポイントは、宛先クラスタのそれぞれのコンテナに関連付けられ、それぞれのインターネットプロトコル(IP)
アドレスと、アプリケーションレベルトラフィックをそれぞれのコンテナに直接分散させるためのそれぞれのポートとを含む。
【0011】
各対応する派生サービスは、いくつかの実現化例では、他の派生サービスの派生サービス名とは異なる、一意的な派生サービス名を含む。派生サービス名はトリミングされたサービス名部分と一意ハッシュ値部分とを有する。トリミングされたサービス名部分はマルチクラスタサービスのユーザ由来サービス名を含み、一意ハッシュ値部分はマルチクラスタサービスのユーザ由来サービス名の一意ハッシュ値を含む。動作は、いくつかの例では、アプリケーションレベル要求を受信することに応答して、ユニフォームリソースロケータ(URL)マッピングにアクセスすることをさらに含む。URLマッピングは、1つ以上の宛先クラスタのサービスにマッピングする1つ以上のホスト名のリストを特定する。動作はまた、受信されたアプリケーションレベル要求のホスト名が、URLマッピングによって特定された1つ以上のホスト名のリストにおけるホスト名のうちの1つを含むかどうかを判断することと、受信されたアプリケーションレベル要求のホスト名が、リストにおけるホスト名のうちの1つを含む場合、受信されたアプリケーションレベル要求をサービスに転送することとを含む。
【0012】
アプリケーションレベルトラフィックは、ハイパーテキスト転送プロトコル(HTTP)を含んでいてもよい。アプリケーションレベルトラフィックはまた、ハイパーテキスト転送プロトコルセキュア(HTTPS)プロトコルを含んでいてもよい。オプションで、アプリケーションレベル要求の少なくとも一部は、トランスポート層セキュリティ(TLS)プロトコルを含んでいてもよい。動作は、いくつかの実現化例では、アプリケーションレベル要求をルーティングする前に、1組の宛先クラスタにおける各宛先クラスタについて、宛先クラスタに現在ルーティングされているアプリケーションレベル要求の数が最大要求レートを満たすかどうかを判断することと、アプリケーションレベル要求の数が最大要求レートを満たす場合、宛先クラスタへのアプリケーションレベル要求のルーティングを防止することとをさらに含む。
【0013】
この開示の1つ以上の実現化例の詳細が、添付図面および以下の説明において述べられる。他の局面、特徴、および利点は、説明および図面から、ならびに請求項から明らかになるであろう。
【0014】
図面の説明
【図面の簡単な説明】
【0015】
図1】コンテナ化されたオーケストレーションシステムの複数のクラスタ間でアプリケーションレベルトラフィックの負荷を分散させるための例示的なシステムの概略図である。
図2図1のシステムの例示的なマルチクラスタコントローラの概略図である。
図3A】ネットワークエンドポイントグループを含むコンテナ負荷分散装置の例示的なコンポーネントの概略図である。
図3B】ネットワークエンドポイントグループを含むコンテナ負荷分散装置の例示的なコンポーネントの概略図である。
図4図1のシステムの例示的なマルチクラスタイングレスの概略図である。
図5】コンテナ化されたシステムでリソースを節約するための例示的な方法のフローチャートである。
図6】ここに説明されるシステムおよび方法を実現するために使用され得る例示的なコンピューティングデバイスの概略図である。
【発明を実施するための形態】
【0016】
さまざまな図面における同じ参照符号は、同じ要素を示す。
詳細な説明
コンテナ化されたアプリケーションと、コンテナ化されたアプリケーションをオーケストレーションするシステムとは、リモートおよび分散コンピューティングにおける進歩に少なくとも部分的に起因して、ますます普及している。コンテナ化されたアプリケーション(すなわち、仮想化)は、隔離されたユーザまたはアプリケーション空間インスタンスの存在を可能にする。各インスタンス(すなわち、コンテナ)は、実行が必要なすべてのリソース(たとえばストレージ、ネットワークアクセスなど)へのアクセスを有するそれ自体のパーソナルコンピュータとして、アプリケーションに現われる場合がある。しかしながら、コンテナ内のアプリケーションは、そのそれぞれのコンテナに割り当てられたリソースを見て当該リソースにアクセスすることしかできないであろう。これは、分散環境またはクラウド環境におけるアプリケーションのセキュリティ、モビリティ、スケーリング、およびアップグレードを容易にする。
【0017】
コンテナは典型的には、単一のアプリケーションまたはプロセスまたはサービスに限定されるであろう。いくつかのコンテナオーケストレーションシステムは、最小の利用可能な演算器としてポッドをデプロイする。ポッドとは、1つ以上のコンテナのグループであり、ポッド内の各コンテナは、隔離境界(たとえばIPアドレス)を共有する。コントローラは、ポッド内のリソースを制御する。コントローラは、ポッド、コンテナ、およびリソースの健全性を監視すること(および、必要であれば、ポッド/コンテナを作り直すこと)に関与している。コントローラはまた、ポッドを複製しスケーリングすること、および、(ポッドにとって)外部の事象について監視することに関与している。
【0018】
ポッドは典型的には一時的で代替可能なリソースであるため、それらは頻繁に作成され破壊される(すなわち、スケールインまたはスケールアウトされる)。いくつかのポッド(すなわち、バックエンド)が他のポッド(すなわち、フロントエンド)に機能性を提供するため、どのバックエンドがフロントエンドのための必要な機能性を提供するかをフロントエンドに追跡させるためにサービスが作成される。サービスとは、論理的な1組のポッドと、それらにアクセスするためのポリシーとを定義する抽象的概念である。すなわち、1つ以上のポッドが、バックエンドを対応するフロントエンドに結び付けるサービスのターゲットとされる。サービスは、選択基準に整合するポッドをターゲットとしてもよい。いくつかの例では、選択基準はラベル選択を含む。すなわち、ポッドはラベルを含んでいてもよく、サービスは、同等性ベースまたは組ベースのラベル整合によって所望のポッドを選択してもよい。
【0019】
単一の物理マシン(すなわち、コンピュータまたはサーバ)が、1つ以上のコンテナ(たとえばポッド)をホストする。コンテナオーケストレーションシステムはしばしば、物理マシンのクラスタを使用して、多くのポッド間で複数のコンテナ化されたアプリケーションを調整するであろう。典型的には、クラスタにおける各マシンは、1つ以上のマシンがマスターサーバとして機能し、残りのマシンがノードとして機能する状態で、同じ場所に位置する(すなわち、マシンは地理的に互いの近くに位置する)。マスターサーバは、たとえば、クライアントのためにアプリケーションプログラムインターフェイス(API)を公開すること、ノードの健全性をチェックすること、通信をオーケストレーションすること、スケジューリングすることなどによって、クラスタのための主要制御プレーンおよびゲートウェイとして作用する。ノードは、ローカルリソースおよび外部リソースを使用して作業負荷を受け入れて実行することに関与しており、各ノードは、マスターサーバによって命令されるようにコンテナを作成し破壊する。クライアントは、マスターサーバと(たとえば直接、またはライブラリを介して)通信することによってクラスタと相互作用する。クラスタ内のノードは概して、マスターサーバによって許可される場合を除き、クラスタの外部の接触から隔離され分離される。
【0020】
負荷分散は複数のコンピューティングリソース間での作業負荷の分散を改良し、分散システムはしばしば、コンテナオーケストレーションシステムの分散される性質に起因して、レイヤ7(L7)負荷分散を実現する。レイヤ7負荷分散は高レベルのアプリケーション層(すなわちレイヤ7)で動作し、それは、送信されたメッセージの実際のコンテンツを伴う。ハイパーテキスト転送プロトコル(HTTP)およびハイパーテキスト転送プロトコルセキュア(HTTPS)は、インターネット上のウェブサイトトラフィックのための主流のL7プロトコルである。高レベルのため、L7負荷分散装置は、他のレイヤ負荷分散装置(たとえば、レイヤ4負荷分散装置)よりも洗練されたやり方で、ネットワークトラフィックをルーティングし得る。一般に、L7負荷分散装置は、ネットワークトラフィックを終了させ、トラフィック内のメッセージコンテンツを分析する。次に、L7負荷分散装置は、メッセージのコンテンツに基づいて(たとえば、HTTPクッキーに基づいて)トラフィックをルーティングしてもよい。次に、L7負荷分散装置は、適切な宛先ノードへの新たな接続を作成してもよい。
【0021】
現在のコンテナオーケストレーションシステムは典型的には、単一のクラスタをターゲットとするL7負荷分散を提供するに過ぎない。すなわち、各クラスタは、個々の構成を示すコンフィグレーション(configuration)を必要とする別個の負荷分散装置を必要と
し、トラフィックは、単一のクラスタ内で分散され得るに過ぎない。トラフィックを適切なクラスタ(たとえば、ソースクライアントに地理的に最も近いクラスタ)にルーティングするには、別個のドメインが必要とされ得る。たとえば、asia.shopping.comは、アジ
アに位置するクラスタにルーティングしてもよく、一方、europe.shopping.comは、ヨー
ロッパのクラスタにルーティングしてもよい。このため、それは、コンテナオーケストレーションシステムにおける複数のクラスタにわたって、高度に利用可能でグローバルに分散されたL7サービスをサーブする負荷分散装置にとって有利であろう。この例を続けると、複数のクラスタをサービスする負荷分散装置は、shopping.comに対するHTTP(S)要求を、当該HTTP(S)要求のソースおよび/またはクラスタでの容量に基づいて、アジアのクラスタまたはヨーロッパのクラスタにルーティングすることができるであろう。
【0022】
ここでの実現化例は、ソフトウェアアプリケーションに関連付けられたアプリケーションレベルトラフィックの負荷を1組の宛先クラスタ間で分散させるための、コンテナオーケストレーションシステムのマルチクラスタ負荷分散装置に向けられる。マルチクラスタ負荷分散装置は、1組の宛先クラスタへのアクセスを管理するマルチクラスタサービスのための負荷分散コンフィグレーションを受信する。ここで使用されるように、負荷分散コンフィグレーションは、イングレスコンフィグレーションと呼ばれてもよい。各宛先クラスタは、(他のポッドまたはクラスタから少なくとも部分的に隔離された)セキュアな実行環境においてソフトウェアアプリケーションを実行する少なくとも1つのポッドと、それぞれの地理的領域とを含む。いくつかのシナリオでは、少なくとも1つのポッド/コンテナは、セキュアでない環境においてソフトウェアアプリケーションを実行する。各クラスタは、異なる地理的領域を有していてもよい。マルチクラスタ負荷分散装置は、1組の宛先クラスタにわたってホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信し、負荷分散装置は、アプリケーションレベル要求の地理的位置と1組の宛先クラスタのそれぞれの地理的領域とに基づいて、アプリケーションレベル要求を宛先クラスタのうちの1つにルーティングする。このため、負荷分散装置は、複数のクラスタをターゲットとしつつ、当該クラスタのすべてにわたって管理および構成の単一の点を提供する。負荷分散装置は、コンテナ固有の負荷分散(すなわち、トラフィックをポッドに直接分散させること)を利用してもよく、クラスタがオフラインになると、ホストされたサービスのための高い利用可能性を提供する。
【0023】
ここで図1を参照して、いくつかの実現化例では、例示的なシステム100は、リモートシステム114を含む。リモートシステム114は、スケーラブル/柔軟なコンピューティングリソース118(たとえばデータ処理ハードウェア)および/またはストレージリソース116(たとえばメモリハードウェア)を有する、単一のコンピュータ、複数のコンピュータ、または分散システム(たとえばクラウド環境)であってもよい。リモートシステム114は、ネットワーク112aを介して、1つ以上のクラスタ120、120a~nと通信し、各クラスタ120は、1つ以上のアプリケーション124を各々実行する1つ以上のポッド122、122a~nを含む。ここでの例は1つ以上のポッド122を含むクラスタ120を説明するが、クラスタ120は、本開示の範囲から逸脱することなく、1つ以上のソフトウェアアプリケーション124を実行するための任意のタイプのコンテナを含んでいてもよい。いくつかの例では、クラスタ120のうちの1つ以上の一部またはすべてが、リモートシステム114上で実行される。いくつかのポッド122は同じアプリケーション124を実行してもよく、一方、同じクラスタ120または異なるクラスタ120内のいくつかのポッド122は異なるアプリケーション124を実行してもよい。たとえば、各クラスタ120は、ショッピングアプリケーション124を実行するポッド122を含んでいてもよい。サービス123とは、同じクラスタ120内の複数のポッド122上で実行される1つ以上のアプリケーション124を表わす。前述の例を続けると、ショッピングサービス123は、複数のポッド122上で実行されているショッピングアプリケーション124を使用してもよい。たとえば、ショッピングアプリケーション124を実行しているすべてのポッド122は、ショッピングサービス123に関連付けられてもよく、各それぞれのポッド122は、ショッピングサービス123を使用する要求30を満たすための代替可能なリソースであってもよい。
【0024】
各クラスタ120はまた、それぞれの地理的領域121、121a~nに関連付けられる。たとえば、クラスタ120aは、アジアの地理的領域121aに関連付けられてもよく、クラスタ120bは、ヨーロッパの地理的領域121bに関連付けられてもよく、クラスタ120nは、北米の地理的領域121nに関連付けられてもよい。すなわち、各クラスタ120は、クラスタ120が物理的に位置する場所の地理的領域121に関連付けられてもよい。各クラスタ120は異なる地理的領域121に位置していてもよいが、いくつかの例では、複数のクラスタ120が同じ地理的領域121を共有する。
【0025】
リモートシステム114はまた、ネットワーク112bを介して、1つ以上のクライアント10、10a~nと通信している。ネットワーク112a、112bは、同じネットワークであっても、異なるネットワークであってもよい。各クライアント10は、デスクトップワークステーション、ラップトップワークステーション、モバイルデバイス(たとえば、スマートフォンまたはタブレット)、ウェアラブルデバイス、スマート機器、スマートディスプレイ、またはスマートスピーカといった任意の好適なコンピューティングデバイスに対応していてもよい。クライアントは、ネットワーク112bを介して、アプリケーションレベル要求30、30a~nをリモートシステム114に送信する。アプリケーションレベル要求30は、アプリケーションプロトコルのメッセージに対応する。たとえば、アプリケーションレベル要求30は、HTTPまたはHTTPSメッセージを含んでいてもよい。すなわち、アプリケーションレベル要求30は、クライアント10からのHTTP(S)要求メッセージに対応していてもよい。オプションで、アプリケーションレベル要求30は、追加の通信セキュリティを提供するために、TLSプロトコルを含んでいてもよい。
【0026】
リモートシステム114は、いくつかの例では、マルチクラスタ負荷分散装置130を実行し、それは、アプリケーションレベル要求30と、アプリケーションレベル要求30の負荷を分散させるように負荷分散装置130を構成する負荷分散コンフィグレーション(たとえばイングレスコンフィグレーション)132とを受信する。各アプリケーション
レベル要求30は、ソースクライアント10に関連付けられたホスト名32および地理的位置34を含む。ホスト名32は、宛先ネットワークホスト(すなわち、共通の権限下にある1つ以上のコンピュータ)を識別する選択基準(たとえばラベル)に対応する。たとえば、http://my-shop.comは、HTTPプロトコルとmy-shop.comというホスト名とを示
すユニフォームリソースロケータ(URL)である。地理的位置34は、それぞれのクライアント10の物理的位置(たとえば、インターネットプロトコル(IP)アドレス)に対応する。いくつかのアプリケーションレベル要求30は、パス名33を追加で含んでいてもよい。たとえば、http:/my-shop.com/sportsというURLは、my-shop.comというホ
スト名と、/sportsというパス名とを示す。
【0027】
負荷分散装置130は、ユーザ12のためにソフトウェアアプリケーション124をホストするクラスタ120(宛先クラスタ120とも呼ばれる)へのアクセスを管理する。すなわち、負荷分散コンフィグレーション(たとえばイングレスコンフィグレーション)132によって提供されたコンフィグレーションを使用して、負荷分散装置130は、宛先クラスタ120上のソフトウェアアプリケーション124に向けられるアプリケーションレベル要求30を受信し、アプリケーションレベル要求30の地理的位置34と宛先クラスタ120のそれぞれの地理的領域121とに基づいて、各アプリケーションレベル要求30を宛先クラスタ120のうちの1つにルーティングする。たとえば、それぞれのアプリケーションレベル要求30に関連付けられた地理的位置34が、アプリケーションレベル要求30が北米から生じたことを示す場合、負荷分散装置130は、アプリケーションレベル要求30を、対応する地理的領域121n(すなわち北米)を有するクラスタ120nにルーティングしてもよい。
【0028】
図1を引き続き参照して、いくつかの実現化例では、マルチクラスタコントローラ200が負荷分散コンフィグレーション132を受信し、負荷分散コンフィグレーション132を使用してマルチクラスタイングレス400を構成する。マルチクラスタコントローラ200によって構成されたマルチクラスタイングレス400は、クラスタ120上で実行されているソフトウェアアプリケーション124へのURLパスのマッピング(すなわち、URLマッピング410)を含む。すなわち、マルチクラスタイングレス400がそれぞれのクラスタ120のそれぞれのポッド122内で実行されているそれぞれのソフトウェアアプリケーション124に向けられたアプリケーションレベル要求30を受信した場合、マルチクラスタイングレス400は、アプリケーションレベル要求30の地理的位置34および関連するソフトウェアアプリケーション124に基づいて、URLマッピング410を使用してアプリケーションレベル要求30を適切なクラスタ120にルーティングする。ユーザ12は、アプリケーション124またはサービス123をホストするための宛先クラスタ120の作成者に対応していてもよい。そのため、ユーザ12は、負荷分散コンフィグレーション132を、マルチクラスタ負荷分散装置130のマルチクラスタコントローラ200に提供してもよい。
【0029】
ここで図2を参照して、マルチクラスタコントローラ200は、いくつかの例では、負荷分散コンフィグレーション132のマルチクラスタサービス210を受信することに関与している。たとえば、マルチクラスタ負荷分散装置130は、負荷分散コンフィグレーション132に基づいてマルチクラスタサービス210をインスタンス化してもよい。マルチクラスタサービス210とは、複数のクラスタ120にまたがるリソースを表わす。いくつかの例では、負荷分散コンフィグレーション132は、マルチクラスタサービス210を一意的に識別するユーザ由来サービス名211(すなわち、ユーザ12に由来するサービス名)を含む。マルチクラスタサービス210は、いくつかの実現化例では、クラスタ選択区分212を含み、それは、どのクラスタ120が宛先クラスタ120であるかと、当該宛先クラスタ120の負荷分散特性とを定義する。すなわち、クラスタ選択区分212は、マルチクラスタサービス210のためのアプリケーションレベルトラフィック
(すなわち、アプリケーションレベル要求30)をサーブするであろう既知のクラスタのリスト125からクラスタ120を選択するためにマルチクラスタサービス210によって特定されたクラスタ選択基準213を識別する。既知のクラスタリスト125は、既知のクラスタ120のレジストリを含んでいてもよく、または、単にクラスタレジストリを指してもよく、クラスタレジストリは、リモートシステム114のストレージリソース116上に格納され、ユーザ12が所有/作成するかまたはアクセスを有する複数のクラスタを含んでいてもよい。クラスタ選択基準213を使用して、マルチクラスタコントローラ200は次に、マルチクラスタサービス210によって特定されたクラスタ選択基準213を満たす1つ以上のラベル216のそれぞれの組を有する各宛先クラスタ120に基づいて、クラスタレジストリ125から1組の宛先クラスタ120を選択する。すなわち、選択されたクラスタ120は、クラスタ120がユニットとして選択されることを可能にするための共通の1組のラベル216を、クラスタ120のすべてにわたって共有していてもよい。オプションで、マルチクラスタサービス210によって特定されたクラスタ選択基準213は、1つ以上の同等性ベースの整合要件(たとえば、環境=生産)、または1つ以上の組ベースの整合要件(たとえば、(生産、qa)における環境)のうちの少なくとも1つを含む。
【0030】
マルチクラスタサービス210はまた、マルチクラスタコントローラ200が各宛先クラスタ120および負荷分散装置130においてインスタンス化/作成するサービス220を定義するサービステンプレート214を含んでいてもよい。いくつかの例では、マルチクラスタサービス210を定義することにより、マルチクラスタコントローラ200は、派生サービス220を宛先クラスタ120において自動的にインスタンス化してもよい。図示された例では、マルチクラスタコントローラ200は、マルチクラスタサービス210を(クラスタ選択区分212およびサービステンプレート214とともに)受信し、対応する派生リソース(すなわちショッピングサービス220)を各宛先クラスタ120a、120b、120cにおいてインスタンス化する。マルチクラスタコントローラ200は、派生サービス220のライフサイクル(たとえば、サービス220を作成し、同期させ、削除すること)全体を自動的に管理してもよい。マルチクラスタコントローラ200は、作成(create)、読取り(read)、更新(update)、および削除(delete)(CRUD)動作を使用して、派生サービス220をインスタンス化して管理してもよい。このため、マルチクラスタサービス210(たとえばショッピングサービス)に対応するアプリケーションレベル要求30は、マルチクラスタイングレス400を介して、適切な宛先クラスタ120の派生サービス220にルーティングしてもよい。
【0031】
各対応する派生サービス220は、他の派生サービス220の派生サービス名221とは異なる、一意的な派生サービス名221を含んでいてもよい。たとえば、派生サービス名221は、トリミングされたサービス名部分と、一意ハッシュ値部分とを有する。トリミングされたサービス名部分は、マルチクラスタサービス210のユーザ由来サービス名211を含んでいてもよく、一意ハッシュ値部分は、マルチクラスタサービス210のユーザ由来サービス名の一意ハッシュ値を含んでいてもよい。各派生サービス220についてのそれぞれの一意的な派生サービス名221は、ユーザ定義サービス123の名前との対立を回避してもよい。
【0032】
いくつかの例では、派生サービス220は、エンドポイント231、231a~nのグループを含む対応するネットワークエンドポイントグループ(NEG)230を作成する。エンドポイント231のグループにおける各エンドポイント231は、対応する宛先クラスタ120のそれぞれのポッド122に関連付けられる。各エンドポイント231は、それぞれのインターネットプロトコル(IP)アドレス242と、アプリケーションレベルトラフィック(すなわち、要求30)をそれぞれのポッド122に直接分散させるためのそれぞれのポート244とを含む。すなわち、NEG230は、バックエンドサービス
のためのバックエンドとして動作するクラスタリソースのための、IPアドレス242とポート244との組合せの集合を表わすリソースであり、IPアドレス242とポート244との各組合せは、ネットワークエンドポイント231と呼ばれる。NEG230は、HTTP(S)、伝送制御プロキシ(Transmission Control Proxy:TCP)プロキシ、およびSSLプロキシ負荷分散装置といったバックエンドサービスにおけるバックエンドとして使用されてもよい。NEGバックエンドは、IPアドレス242とポート244とを特定することによって、ポッド122内で動作するアプリケーションまたはコンテナ中にトラフィックを細かい粒度で分散させることを容易にする。同じクラスタ120におけるエンドポイント231(たとえばポッド122)が、NEG230に割り当てられてもよい。NEG230は、コンテナ負荷分散装置240(すなわち、クラスタ120におけるマシンまたはポッド122中にトラフィックを分散させるための負荷分散装置)においてバックエンドサービスのためのバックエンドとして機能してもよい。各宛先クラスタ120は、それぞれのNEG230をプログラムするための対応するNEGコントローラ232を含んでいてもよい。
【0033】
他の例では、クラスタ120は、NEG230の代わりにインスタンスグループを実現する。インスタンスグループは、NEG230と同様に、エンドポイント(たとえば仮想マシンインスタンス)の集合を単一のエンティティとしてともにグループ化し、IPテーブルを使用することによって要求30を適切なエンドポイントにルーティングする。インスタンスグループは、自動スケーリングを有するかまたは有さない管理されたインスタンスグループであってもよく、もしくは、管理されていないインスタンスグループであってもよい。
【0034】
インスタンスグループの代わりにNEG230を実現する場合、マルチクラスタコントローラ200は、システム100の他のコンポーネントによる容易な検索のために、各NEG230の名前(すなわちラベル)を格納してもよい。各NEG230は、NEGコントローラ232によって管理されるファイアウォールを含んでいてもよく、各NEGが一意的な1組のポート244を開放することを可能にする。それに代えて、またはそれに加えて、マルチクラスタコントローラ200は、すべての宛先クラスタ120のポート範囲に影響を与えるファイアウォールコントローラをインスタンス化してもよい。ファイアウォールコントローラは、たとえば、ポート範囲全体が開いていることを保証し、次に、各個々のNEGコントローラ232がそのそれぞれのポート範囲をカスタマイズすることを可能にし得る。
【0035】
ここで図3Aおよび図3Bを参照して、いくつかの例では、リモートシステム114は、コンテナ負荷分散装置240を実現するために追加のコンポーネントを実行する。たとえば、転送ルール310は、アプリケーションレベル要求30を、それぞれのクラスタ120のグローバル外部IPアドレスから、適切なターゲットプロキシ320(図3A)に向けてもよい。転送ルール310は、IPアドレス、ポート、およびプロトコルによって、ターゲットプロキシ320と、URLマッピング330(たとえばURLマッピング410)と、1つ以上のバックエンドサービス340、すなわちサービス123(図1)とからなる負荷分散構成に、要求30をルーティングする。各転送ルール310は、クラスタ120のための単一のグローバルIPアドレスを提供してもよい。ターゲットプロキシ320は、クライアント10からの接続(たとえば、HTTPおよびHTTPS接続)を終了させる。ターゲットプロキシ320は、受信された各要求30をURLマッピング330と照合して、要求30にとってどのバックエンドサービス340が適切であるかを判断する。HTTPS接続をルーティングする場合、ターゲットプロキシ320は、負荷分散装置240とクライアント10との間の通信を認証するための1つ以上のセキュアソケット層(Secure Sockets Layer:SSL)証明書を含んでいてもよい。
【0036】
図3Bに示すように、IPテーブルルールを介してトラフィックを(同じノード/仮想マシン内にあってもなくてもよい)コンテナ(たとえばポッド)122にルーティングするインスタンスグループとは異なり、NEG230は、トラフィック(すなわち、要求30)を受信するべきコンテナ(たとえばポッド)122にトラフィックが直接ルーティングされることを可能にし、それは、余分のネットワークホップを排除する。減少したネットワークホップは、ネットワークの待ち時間およびスループットの双方を向上させる。
【0037】
URLマッピング330は、適切なバックエンドサービス340への要求30のURLベースのルーティングのための整合パターンを定義する。いくつかの例では、デフォルトサービス340は、特定されたホストルールまたはパス整合ルールに整合しないあらゆる要求30を扱うために定義される。オプションで、マルチクラスタコントローラ200は、派生したデフォルトサービスを宛先クラスタ120において作成してもよい。要求30のコンテンツベースのルーティングのために、URLマッピング330は、URLコンポーネントを調べることによって要求30を分割し、要求30を異なる組のバックエンド340に送信する。複数のバックエンドサービス340が、URLマッピング330から参照されてもよい。
【0038】
バックエンドサービス340は、入ってきた要求30を、取り付けられたNEG230の1つ以上のエンドポイントに向ける。バックエンドサービス340は、たとえば、その取り付けられたバックエンドのサーブ容量、ゾーン、およびインスタンス健全性に基づいて、各要求30を、接続されたNEG230のうちの1つの適切なエンドポイントに向ける。エンドポイントサーブ容量は、CPUまたは1秒あたりの要求数(requests per second:RPS)(すなわち、エンドポイントが1秒あたりに処理できる要求30の量)に
基づいていてもよい。各バックエンドサービス340はまた、NEG230のエンドポイントに対してどの健全性チェックを行なうかを特定してもよい。
【0039】
ここで図4を参照して、マルチクラスタコントローラ200は、ユーザ由来サービス名211を使用して、マルチクラスタイングレス400と、マルチクラスタイングレス400によって定義されたマルチクラスタサービス210とを管理する。マルチクラスタイングレス400は、レイヤ7プロトコルおよび終了設定(たとえば、トランスポート層セキュリティ(TLS)証明書)を含み、URLマッピング410は、宛先クラスタ120上で実行される1つ以上のサービス123にマッピングする1つ以上のホスト名412および/またはURLパスのリストを特定する。各宛先クラスタ120は、マルチクラスタサービス210と通信するそれぞれの派生サービス220を含む。マルチクラスタコントローラ200が受信するソフトウェアアプリケーション124(またはサービス123)に向けられた各アプリケーションレベル要求30について、マルチクラスタコントローラ200は、受信されたアプリケーションレベル要求30のホスト名32が、URLマッピング410によって特定された1つ以上のホスト名412のリストにおけるホスト名412のうちの1つを含むかどうかを判断する。それに代えて、またはそれに加えて、コントローラ200は、受信されたアプリケーションレベル要求30のURLパス33が、URLマッピング410によって特定されたパス413のリストにおけるパスのうちの1つを含むかどうかを判断してもよい。受信されたアプリケーションレベル要求30のホスト名32(および/またはパス33)が、リストにおけるホスト名412(および/またはパス413)のうちの1つを含む場合、マルチクラスタコントローラ200は、受信されたアプリケーションレベル要求30を、アプリケーション124またはサービス123(たとえばショッピングサービス)に関連付けられたマルチクラスタサービス210に転送する。ここで、マルチクラスタサービスコントローラ200は、受信されたアプリケーションレベル要求30の負荷を、デプロイされたサービス123を実行する宛先クラスタ120、120a~cのうちの1つのそれぞれの宛先サービス220に分散させる任務を負う。いくつかの実現化例では、マルチクラスタサービスコントローラ200は、宛先クラスタ
120のそれぞれの地理的領域121a~cに基づいて、どの宛先クラスタ120が要求30の地理的位置34(たとえば、要求30を送信したクライアント10に関連付けられた位置34)に最も近いかを判断する。マルチクラスタコントローラ200は、マルチクラスタサービス210によって定義されたルーティング決定を介して、アプリケーションレベル要求30を、アプリケーションレベル要求30のクライアント10に関連付けられた地理的位置34に最も近いそれぞれの地理的領域121を有する宛先クラスタ120にルーティングしてもよい。
【0040】
図示された例では、クライアント10aは東京に位置し、クライアント10bはサンノゼに位置し、クライアント10cはボストンに位置する。また、ショッピングサービス123を実行する1組の宛先クラスタ120は、東京の地理的領域121aに関連付けられた第1のクラスタ120aと、サンフランシスコの地理的領域121bに関連付けられた第2のクラスタ120bと、ニューヨークシティの地理的領域121cに関連付けられた第3のクラスタ120cとを含む。各クライアント10a、10b、10cは、それぞれのアプリケーションレベル要求30a、30b、30cを送信し、それらはコントローラ200によって受信される。コントローラ200は、要求30に関連付けられた地理的位置34(すなわち、東京、サンノゼ、およびボストン)に基づいて、要求30aをクラスタ120aにルーティングし、要求30bをクラスタ120bにルーティングし、要求30cをクラスタ120cにルーティングする。いくつかの例では、マルチクラスタコントローラ200は、最小の待ち時間(すなわち、要求30がクライアント10からそれぞれのクラスタ120まで進むのにかかる時間の量)に関連付けられたクラスタ120に基づいて、各要求30をルーティングする。すなわち、各宛先クラスタ120は、クライアント10からのそれぞれの待ち時間を有し、マルチクラスタコントローラ200は、時間の任意の所与のインスタンスで各宛先クラスタ120の最小待ち時間を有するクラスタ120に、要求30をルーティングしてもよい。他の例では、マルチクラスタコントローラ200は、要求の地理的位置34に関連付けられた領域ラベルとクラスタ120の地理的領域121に関連付けられた領域ラベルとを整合させる同等性に基づいて、各要求をルーティングする。たとえば、要求30は、「アジア」に対応する領域ラベルを含んでいてもよく、マルチクラスタイングレス400は、要求30を、整合する領域ラベル(すなわち「アジア」)を有するクラスタにルーティングしてもよい。
【0041】
いくつかの例では、コントローラ200は、マルチクラスタサービス210によって特定されたそれぞれの負荷分散(load balancing:LB)属性420に基づいて、要求30をルーティングする。たとえば、アプリケーションレベル要求30は、最も近い(すなわち、地理的に最も近い)利用可能なクラスタ120に常にルーティングされてもよい。いくつかの実現化例では、クラスタ120は、クライアントの要望に応えるために、自動的にスケーリングする(たとえば、各クラスタ120内のコンテナ(たとえばポッド)122の数を増加または減少させる)であろう。この例では、各クラスタは、実際には、無限のリソースを有し、このため、クライアント10は、最も近いクラスタ120に常にルーティングされるであろう。クライアントの要望に基づいてリソースの数をクラスタごとに自動的にスケーリングすることにより、クラスタ120ごとの利用量(すなわち、利用可能なリソース全体に対する使用リソースのパーセンテージ)は、高いままである。図4の例では、クラスタ120が、クライアントの要望に応えるために無限の容量を有する場合、クラスタ120は、負荷分散装置130がサンノゼおよびボストンからよりも東京からより多数のアプリケーションレベル要求30(すなわち、1秒あたりの要求数)を受信している場合に、東京の地理的領域121a内の第1のクラスタ120aがエンドユーザの要望の増加を満たすためにリソース/コンテナ122(たとえばポッド)の数をスケールアップするように、エンドユーザの要望を満たすために動的にスケーリングしてもよい。また、他の地理的領域121b、121c内の第2および第3のクラスタ120b、120cのうちの少なくとも1つが、対応する地理的位置34でのエンドユーザの要望に基づ
いてスケールダウンしてもよい。負荷分散装置130が要求30を最も近い地理的領域121にルーティングするこれらの自動スケーリングシナリオでは、クラスタ120は、ステートフルなサービス123を提供するために、互いに状態を同期させるように要求され得る。負荷分散装置130は、クラスタ120の各々での動的容量に基づいて連続的に更新してもよい。
【0042】
他の実現化例では、クラスタ120は、固定されたリソース容量を有する(すなわち、クラスタ120はスケーリングしない)。この状況では、アプリケーションレベル要求30をルーティングする前に、マルチクラスタコントローラ200は、各宛先クラスタ120について、宛先クラスタ120に現在ルーティングされているアプリケーションレベル要求30の数(たとえば、1秒あたりの要求数)が最大要求レートを満たすかどうかを判断する。アプリケーションレベル要求30の数が最大要求レートを満たす場合、マルチクラスタコントローラ200は、宛先クラスタ120へのアプリケーションレベル要求30のルーティングを防止する。すなわち、負荷分散属性420は最大要求レート(すなわち、最大RPS)を含んでいてもよく、この状況では、上述のような地理的領域121に基づく最も近いクラスタが、そのしきい値RPSを満たすかまたは上回る場合、マルチクラスタイングレス400は、(たとえば、待ち時間または領域ラベルに基づいて)要求30を次に最も近いクラスタ120にルーティングしてもよい。2番目に近いクラスタ120もその最大RPSを上回る場合、マルチクラスタイングレス40は、3番目の最も近いクラスタ120に移る、というようになってもよい。また、宛先クラスタ120のうちの少なくとも1つに関連付けられた固定されたリソース容量は、他の宛先クラスタ120に関連付けられた固定されたリソース容量とは異なっていてもよい。
【0043】
負荷分散属性420は、それに加えて、またはそれに代えて、アプリケーションレベル要求30が、要求30に応える容量を有する地理的に最も近いクラスタ120にルーティングされるようにする、マルチクラウドおよび/またはハイブリッド負荷分散属性を含んでいてもよい。クラスタ120は、別のクラウドコンピューティングネットワークにあってもよく、または、さらには、アプリケーションレベル要求30が生じたのと同じ地理的位置34にあってもよい(たとえば、オンプレミス)。これは、単一のクラウドコンピューティングネットワークにおける複数の地域的機能停止に対する回復力がある、高度に利用可能なサービスを可能にし、新たなクラウドコンピューティングネットワークの開始を容易にする。
【0044】
各クラスタ120は個別化された負荷分散属性420を受信してもよく、または、同じ属性420がすべての宛先クラスタ120に適用されてもよい。ユーザ12が負荷分散属性420を提供しない場合、マルチクラスタイングレス400は、デフォルト挙動(たとえば、最小待ち時間を有するクラスタ120)に基づいてルーティングしてもよい。
【0045】
いくつかの実現化例では、負荷分散属性420は、データ局所性ルーティング属性を含む。すなわち、負荷分散属性は、HTTP(S)ヘッダ情報(たとえばHTTPクッキー)に基づいて、アプリケーションレベル要求30をクラスタ120にルーティングしてもよい。これは、クライアント10が、それらのアプリケーションレベル要求30を、それらのデータをすでにホストしているクラスタ120の地理的位置/領域121にルーティングさせ、あらゆるデータレジデンシー要件または法則を満たすのに役立つことを可能にする。そのため、1組の宛先クラスタ120にわたって実行されている根底的なサービス123のために、単一のIPアドレスを発行するだけでよい。データレジデンシーとは一般に、クライアントデータが特定の国の境界内で処理および/または格納されなければならないという要件として定義される。オプションで、クラスタ120は、複数の組のクライアント10を同時にサーブするために、互いの間でデータを同期させる。ここで、リソース/コンテナ/ポッド122は、エンドユーザの要望に基づいて、それぞれのクラスタ
内でスケールアップまたはダウンしてもよい。同期されたデータはまた、クラスタ120が障害を起こすかまたは他の態様で不健全である場合に、アプリケーションレベル要求30が代替的なクラスタ120にルーティング変更されること可能にする。負荷分散属性420は、アプリケーションレベル要求30がHTTPクッキーまたはgeo-ヘッダなどのHTTP(S)ヘッダ情報に基づいて単一のクラスタ内のサービスにルーティングされる、クライアントベースのルーティングを含む。これは、負荷分散装置130が容易にクライアント10をグループ化して異なるサービスにルーティングすることを可能にする。
【0046】
負荷分散属性420はまた、トラフィック分割のための属性を含んでいてもよい。トラフィック分割属性は、負荷分散装置130が、ユーザ12によって定義されたクラスタ120間のパーセンテージ(%)分割またはRPS比率に基づいて、アプリケーションレベル要求30をクラスタ120にルーティングすることを可能にする。すなわち、各クラスタは、総トラフィック(すなわち、アプリケーションレベル要求30)のパーセンテージを(たとえばユーザ12によって)割り当てられてもよく、コントローラ200は、割り当てられたパーセンテージに基づいて、アプリケーションレベル要求30をクラスタ120にランダムにルーティングしてもよい。そのようなトラフィック分割は、新しい地理的領域121におけるクラスタ120への作業負荷の移行を容易にする。なぜなら、新しい地理的領域121におけるクラスタ120は、ゆっくり育てられ得る(すなわち、小さいパーセンテージから始めて、時間とともにパーセンテージを増加させる;カナリアデプロイメントと呼ばれることもある)ためである。トラフィック分割のための属性を特定する負荷分散属性420は、マルチ領域分割または領域内分割を可能にしてもよい。マルチ領域分割では、トラフィックは、地理的領域121にわたって分割されてもよい。そのため、所与の地理的領域34における同じクライアント10からの複数のアプリケーションレベル要求30は、2つ以上の地理的領域121におけるクラスタ120にルーティングされてもよい。たとえば、ボストンにいるクライアント10cは、複数のアプリケーションレベル要求30を発行してもよく、それにより、負荷分散装置130は、これらの要求30の一部を、ニューヨークシティに関連付けられた地理的領域121cにおける第3の宛先クラスタ120cにルーティングし、これらの要求30の残りの部分を、東京に関連付けられた地理的領域121aにおける第1の宛先クラスタ120aにルーティングする。領域内分割では、トラフィックは、同じ地理的領域121内でのみ分割されてもよい。すなわち、領域内分割では、アプリケーションレベル要求30は、同じ地理的領域121内でのみ分割されてもよく、一方、領域間トラフィックは影響されない。たとえば、東京にいるクライアント10は、アジアに関連付けられた地理的領域121に位置する2つの別個のクラスタ120間で分割されてもよいが、ヨーロッパに関連付けられた地理的領域121を有するクラスタにはルーティングされない。負荷分散属性420はまた、クラスタ内トラフィック分割を可能にしてもよい。クラスタ内トラフィック分割では、アプリケーションレベル要求30は、割り当てられた(すなわち、負荷分散属性420によって割り当てられた)パーセンテージに基づいて、単一のクラスタ120内のサービスにランダムにルーティングされてもよい。これは、たとえば、サービスの新バージョンの検査を可能にする。すなわち、トラフィックの大部分がサービスのオリジナルバージョンにルーティングされている一方で、サービスの新バージョンは検査のために小さいパーセンテージのトラフィックでルーティングされてもよい。
【0047】
図5は、マルチクラスタコンテナ化オーケストレーションシステム100中にアプリケーションレベル要求30の負荷を分散させるための例示的な方法500のフローチャートである。方法500は、図1~4を参照して説明されてもよい。方法500は、動作502で、ユーザ12によってデプロイされたソフトウェアアプリケーション124をホストする1組の宛先クラスタ120へのアクセスを管理するマルチクラスタ負荷分散装置130のための負荷分散コンフィグレーション132を、データ処理ハードウェア118で受信するステップで始まる。マルチクラスタ負荷分散装置130は、ソフトウェアアプリケ
ーション124に関連付けられたアプリケーションレベルトラフィック30の負荷を1組の宛先クラスタ120間で分散させるために負荷分散コンフィグレーション132を使用するように構成される。各宛先クラスタ120は、ソフトウェアアプリケーション124を実行する少なくとも1つのコンテナ122と、それぞれの地理的領域121とを含み、それぞれの地理的領域121は、1組の宛先クラスタ120における宛先クラスタ120のうちの別の1つに関連付けられた少なくとも1つの他の地理的領域121と同じであるかまたは異なっている。
【0048】
動作504で、方法500は、1組の宛先クラスタ120にわたってホストされたソフトウェアアプリケーション124に向けられたアプリケーションレベル要求30を、データ処理ハードウェア118で受信するステップを含む。アプリケーションレベル要求30はクライアント10から受信され、クライアント10に関連付けられたホスト名32および地理的位置34を含む。アプリケーションレベル要求30はまた、パス名33を含み得る。動作506で、方法500は、データ処理ハードウェア118が、アプリケーションレベル要求30の地理的位置34と1組の宛先クラスタ120のそれぞれの地理的領域121とに基づいて、アプリケーションレベル要求30を1組の宛先クラスタにおける宛先クラスタ120のうちの1つにルーティングするステップを含む。
【0049】
図6は、この文書で説明されるシステムおよび方法を実現するために使用され得る例示的なコンピューティングデバイス600の概略図である。コンピューティングデバイス600は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータといった、さまざまな形態のデジタルコンピュータを表わすよう意図されている。ここに示すコンポーネント、それらの接続および関係、ならびにそれらの機能は単なる例示であることが意図されており、この文書で説明される、および/または請求項に記載のこの発明の実現化例を限定するよう意図されてはいない。
【0050】
コンピューティングデバイス600は、プロセッサ610と、メモリ620と、記憶装置630と、メモリ620および高速拡張ポート650に接続している高速インターフェイス/コントローラ640と、低速バス670および記憶装置630に接続している低速インターフェイス/コントローラ660とを含む。コンポーネント610、620、630、640、650、および660の各々は、さまざまなバスを使用して相互接続されており、共通のマザーボード上にまたは他の態様で適宜搭載されてもよい。プロセッサ610は、コンピューティングデバイス600内で実行される命令を処理可能であり、これらの命令は、グラフィカルユーザインターフェイス(graphical user interface:GUI)のためのグラフィック情報を、高速インターフェイス640に結合されたディスプレイ680などの外部入出力デバイス上に表示するために、メモリ620内または記憶装置630上に格納された命令を含む。他の実現化例では、複数のプロセッサおよび/または複数のバスが、複数のメモリおよび複数のタイプのメモリとともに適宜使用されてもよい。また、複数のコンピューティングデバイス600が接続されてもよく、各デバイスは(たとえば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとして)必要な動作の部分を提供する。
【0051】
メモリ620は、情報をコンピューティングデバイス600内に非一時的に格納する。メモリ620は、コンピュータ読取可能媒体、揮発性メモリユニット、または不揮発性メモリユニットであってもよい。非一時的メモリ620は、プログラム(たとえば命令のシーケンス)またはデータ(たとえばプログラム状態情報)を、コンピューティングデバイス600による使用のために一時的または永続的に格納するために使用される物理デバイスであってもよい。不揮発性メモリの例は、フラッシュメモリおよび読出専用メモリ(read-only memory:ROM)/プログラマブル読出専用メモリ(programmable read-only m
emory:PROM)/消去可能プログラマブル読出専用メモリ(erasable programmable read-only memory:EPROM)/電子的消去可能プログラマブル読出専用メモリ(electronically erasable programmable read-only memory:EEPROM)(たとえば、典型的にはブートプログラムなどのファームウェアのために使用される)を含むものの、それらに限定されない。揮発性メモリの例は、ランダムアクセスメモリ(random access memory:RAM)、ダイナミックランダムアクセスメモリ(dynamic random access memory:DRAM)、スタティックランダムアクセスメモリ(static random access memory:S
RAM)、相変化メモリ(phase change memory:PCM)、およびディスクまたはテー
プを含むものの、それらに限定されない。
【0052】
記憶装置630は、コンピューティングデバイス600のための大容量記憶を提供可能である。いくつかの実現化例では、記憶装置630は、コンピュータ読取可能媒体である。さまざまな異なる実現化例では、記憶装置630は、フロッピー(登録商標)ディスクデバイス、ハードディスクデバイス、光ディスクデバイス、もしくはテープデバイス、フラッシュメモリまたは他の同様のソリッドステートメモリデバイス、もしくは、ストレージエリアネットワークまたは他の構成におけるデバイスを含むデバイスのアレイであってもよい。追加の実現化例では、コンピュータプログラム製品が情報担体において有形に具現化される。コンピュータプログラム製品は、実行されると上述のような1つ以上の方法を行なう命令を含む。情報担体は、メモリ620、記憶装置630、またはプロセッサ610上のメモリといった、コンピュータ読取可能媒体または機械読取可能媒体である。
【0053】
高速コントローラ640はコンピューティングデバイス600のための帯域幅集約的な動作を管理し、一方、低速コントローラ660はより低い帯域幅集約的な動作を管理する。役目のそのような割当ては例示に過ぎない。いくつかの実現化例では、高速コントローラ640は、メモリ620、ディスプレイ680に(たとえば、グラフィックスプロセッサまたはアクセラレータを介して)結合されるとともに、さまざまな拡張カード(図示せず)を受け付け得る高速拡張ポート650に結合される。いくつかの実現化例では、低速コントローラ660は、記憶装置630および低速拡張ポート690に結合される。さまざまな通信ポート(たとえば、USB、ブルートゥース(登録商標)、イーサネット(登録商標)、無線イーサネット)を含み得る低速拡張ポート690は、キーボード、ポインティングデバイス、スキャナなどの1つ以上の入出力デバイスに、もしくは、スイッチまたはルータなどのネットワーキングデバイスに、たとえばネットワークアダプタを介して結合されてもよい。
【0054】
コンピューティングデバイス600は、図に示すように多くの異なる形態で実現されてもよい。たとえばそれは、標準サーバ600aとして、またはそのようなサーバ600aのグループで複数回実現されてもよく、ラップトップコンピュータ600bとして、またはラックサーバシステム600cの一部として実現されてもよい。
【0055】
ここに説明されるシステムおよび手法のさまざまな実現化例は、デジタル電子および/または光学回路、集積回路、特別に設計されたASIC(application specific integrated circuit:特定用途向け集積回路)、コンピュータハードウェア、ファームウェア、
ソフトウェア、および/またはそれらの組合せにおいて実現され得る。これらのさまざまな実現化例は、データおよび命令を記憶システムとの間で送受信するように結合された、専用または汎用であり得る少なくとも1つのプログラマブルプロセッサと、少なくとも1つの入力デバイスと、少なくとも1つの出力デバイスとを含むプログラマブルシステム上で実行可能および/または解釈可能である1つ以上のコンピュータプログラムにおける実現を含み得る。
【0056】
ソフトウェアアプリケーション(すなわち、ソフトウェアリソース)とは、コンピュー
ティングデバイスにタスクを行なわせるコンピュータソフトウェアを指していてもよい。いくつかの例では、ソフトウェアアプリケーションは、「アプリケーション」、「アプリ」、または「プログラム」と呼ばれてもよい。例示的なアプリケーションは、システム診断アプリケーション、システム管理アプリケーション、システム保守アプリケーション、文書処理アプリケーション、表計算アプリケーション、メッセージングアプリケーション、メディアストリーミングアプリケーション、ソーシャルネットワーキングアプリケーション、およびゲーミングアプリケーションを含むものの、それらに限定されない。
【0057】
これらのコンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られている)は、プログラマブルプロセッサのための機械命令を含み、高レベルの手続き型および/またはオブジェクト指向プログラミング言語で、および/またはアセンブリ/機械語で実現され得る。ここに使用されるように、「機械読取可能媒体」および「コンピュータ読取可能媒体」という用語は、機械命令および/またはデータをプログラマブルプロセッサに提供するために使用される任意のコンピュータプログラム製品、非一時的コンピュータ読取可能媒体、機器および/またはデバイス(たとえば磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス(Programmable Logic Device:PLD))を指し、機械命令を機械読取可能信号として受信す
る機械読取可能媒体を含む。「機械読取可能信号」という用語は、機械命令および/またはデータをプログラマブルプロセッサに提供するために使用される任意の信号を指す。
【0058】
この明細書で説明されるプロセスおよび論理フローは、データ処理ハードウェアとも呼ばれる1つ以上のプログラマブルプロセッサが、入力データに基づいて動作することおよび出力を生成することによって機能を行なうために1つ以上のコンピュータプログラムを実行することによって行なわれ得る。プロセスおよび論理フローはまた、たとえばFPGA(field programmable gate array:フィールドプログラマブルゲートアレイ)または
ASIC(特定用途向け集積回路)といった専用論理回路によって行なわれ得る。コンピュータプログラムの実行にとって好適であるプロセッサは、一例として、汎用および専用マイクロプロセッサと、任意の種類のデジタルコンピュータの任意の1つ以上のプロセッサとを含む。一般に、プロセッサは、命令およびデータを、読出専用メモリまたはランダムアクセスメモリまたはそれら双方から受信するであろう。コンピュータの本質的要素は、命令を行なうためのプロセッサと、命令およびデータを格納するための1つ以上のメモリデバイスとである。一般に、コンピュータはまた、たとえば磁気ディスク、光磁気ディスク、または光ディスクといった、データを格納するための1つ以上の大容量記憶装置を含むであろう。もしくは、当該大容量記憶装置からデータを受信し、または当該大容量記憶装置にデータを転送し、またはそれら双方を行なうように動作可能に結合されるであろう。しかしながら、コンピュータは、そのようなデバイスを有する必要はない。コンピュータプログラム命令およびデータを格納するのに好適であるコンピュータ読取可能媒体は、あらゆる形態の不揮発性メモリ、媒体、およびメモリデバイスを含み、一例として、半導体メモリ装置、たとえばEPROM、EEPROM、およびフラッシュメモリデバイス;磁気ディスク、たとえば内部ハードディスクまたはリムーバブルディスク;光磁気ディスク;ならびに、CD ROMおよびDVD-ROMディスクを含む。プロセッサおよびメモリは、専用論理回路によって補足され、または専用論理回路に組込まれ得る。
【0059】
ユーザとの相互作用を提供するために、この開示の1つ以上の局面は、情報をユーザに表示するためのディスプレイデバイス、たとえばCRT(cathode ray tube:陰極線管)、LCD(liquid crystal display:液晶ディスプレイ)モニター、またはタッチスクリーンと、オプションで、ユーザがコンピュータへの入力を提供できるようにするキーボードおよびポインティングデバイス、たとえばマウスまたはトラックボールとを有するコンピュータ上で実現され得る。他の種類のデバイスも同様に、ユーザとの相互作用を提供するために使用され得る。たとえば、ユーザに提供されるフィードバックは、任意の形態の
感覚フィードバック、たとえば視覚フィードバック、聴覚フィードバック、または触覚フィードバックであり得る。また、ユーザからの入力は、音響入力、音声入力、または触覚入力を含む任意の形態で受信され得る。加えて、コンピュータは、ユーザによって使用されるデバイスに文書を送信し、当該デバイスから文書を受信することによって、たとえば、ユーザのクライアントデバイス上のウェブブラウザから受信された要求に応答してウェブページを当該ウェブブラウザに送信することによって、ユーザと相互作用することができる。
【0060】
多くの実現化例が説明されてきた。にもかかわらず、この開示の精神および範囲から逸脱することなく、さまざまな変更を行なってもよいということが理解されるであろう。したがって、他の実現化例は、請求の範囲内にある。
図1
図2
図3A
図3B
図4
図5
図6
【手続補正書】
【提出日】2024-01-23
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
データ処理ハードウェアによって実行されると前記データ処理ハードウェアに動作を行なわせる、コンピュータにより実現される方法であって、前記動作は、
分散システムの負荷分散装置を介して、前記分散システムの複数の地域ゾーン上でホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信することを含み、前記複数の地域ゾーンのうちの各地域ゾーンは、それぞれのノードグループを定義する対応するクラスタを含み、前記対応するクラスタは、前記ソフトウェアアプリケーションを実行する複数のコンテナポッドを含み、前記動作はさらに、
前記負荷分散装置を介して、前記アプリケーションレベル要求を、地理的位置に基づいて、前記複数の地域ゾーンのうちの特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることと、
前記負荷分散装置を介して、および、前記対応するクラスタの動的容量に基づいて、前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記複数のコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記アプリケーションレベル要求に関連付けられたトラフィック負荷を満たす能力を上回ると判断することと、
前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記複数のコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記アプリケーションレベル要求に関連付けられた前記トラフィック負荷を満たす前記能力を上回ると判断することに基づいて、前記特定の地域ゾーンの前記対応するクラスタの前記複数のコンテナポッドのうちの1つ以上のコンテナポッドを、前記アプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために必要とされる数まで除去することによって、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングすることと、
前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングした後で、前記負荷分散装置で、前記対応するクラスタの残りのコンテナポッドの数に基づいて、前記対応するクラスタの前記動的容量を更新することとを含む、方法。
【請求項2】
前記動作はさらに、前記負荷分散装置を介して、前記アプリケーションレベル要求を、前記アプリケーションレベル要求に関連付けられた前記ソフトウェアアプリケーションに基づいて、前記複数の地域ゾーンのうちの1つの地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることを含む、請求項1に記載の方法。
【請求項3】
前記アプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、前記アプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含む、請求項1または2に記載の方法。
【請求項4】
前記地理的位置は、前記アプリケーションレベル要求に関連付けられている、請求項1~3のいずれか1項に記載の方法。
【請求項5】
各それぞれのノードグループは、マルチクラスタサービスによって中央管理される、請求項1~4のいずれか1項に記載の方法。
【請求項6】
前記それぞれのノードグループは、それぞれのインターネットプロトコル(IP)アドレスと、アプリケーションレベルトラフィックを前記複数のコンテナポッドのうちの前記1つ以上のコンテナポッドに直接分散させるためのそれぞれのポートとを含む、請求項1~5のいずれか1項に記載の方法。
【請求項7】
前記アプリケーションレベル要求は、ハイパーテキスト転送プロトコル(HTTP)を含む、請求項1~6のいずれか1項に記載の方法。
【請求項8】
前記アプリケーションレベル要求は、ハイパーテキスト転送プロトコルセキュア(HTTPS)を含む、請求項1~7のいずれか1項に記載の方法。
【請求項9】
前記アプリケーションレベル要求は、トランスポート層セキュリティ(TLS)プロトコルを含む、請求項1~8のいずれか1項に記載の方法。
【請求項10】
各クラスタは、個別化された負荷分散属性を含む、請求項1~9のいずれか1項に記載の方法。
【請求項11】
システムであって、
データ処理ハードウェアと、
前記データ処理ハードウェアと通信しているメモリハードウェアとを含み、前記メモリハードウェアは、前記データ処理ハードウェア上で実行されると前記データ処理ハードウェアに動作を行なわせる命令を格納しており、前記動作は、
分散システムの負荷分散装置を介して、前記分散システムの複数の地域ゾーン上でホストされたソフトウェアアプリケーションに向けられたアプリケーションレベル要求を受信することを含み、前記複数の地域ゾーンのうちの各地域ゾーンは、それぞれのノードグループを定義する対応するクラスタを含み、前記対応するクラスタは、前記ソフトウェアアプリケーションを実行する複数のコンテナポッドを含み、前記動作はさらに、
前記負荷分散装置を介して、前記アプリケーションレベル要求を、地理的位置に基づいて、前記複数の地域ゾーンのうちの特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることと、
前記負荷分散装置を介して、および、前記対応するクラスタの動的容量に基づいて、前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記複数のコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記アプリケーションレベル要求に関連付けられたトラフィック負荷を満たす能力を上回ると判断することと、
前記特定の地域ゾーンの前記対応するクラスタの前記ソフトウェアアプリケーションを実行する前記複数のコンテナポッドが、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングされた前記アプリケーションレベル要求に関連付けられた前記トラフィック負荷を満たす前記能力を上回ると判断することに基づいて、前記特定の地域ゾーンの前記対応するクラスタの前記複数のコンテナポッドのうちの1つ以上のコンテナポッドを、前記アプリケーションレベル要求に関連付けられた前記トラフィック負荷をサポートするために必要とされる数まで除去することによって、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングすることと、
前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループをスケーリングした後で、前記負荷分散装置で、前記対応するクラスタの残りのコンテナポッドの数に基づいて、前記対応するクラスタの前記動的容量を更新することとを含む、システム。
【請求項12】
前記動作はさらに、前記負荷分散装置を介して、前記アプリケーションレベル要求を、前記アプリケーションレベル要求に関連付けられた前記ソフトウェアアプリケーションに基づいて、前記複数の地域ゾーンのうちの1つの地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることを含む、請求項11に記載のシステム。
【請求項13】
前記アプリケーションレベル要求を、前記特定の地域ゾーンの前記対応するクラスタの前記それぞれのノードグループにルーティングすることは、前記アプリケーションレベル要求の負荷を前記複数の地域ゾーン間で分散させることを含む、請求項11または12に記載のシステム。
【請求項14】
前記地理的位置は、前記アプリケーションレベル要求に関連付けられている、請求項11~13のいずれか1項に記載のシステム。
【請求項15】
各それぞれのノードグループは、マルチクラスタサービスによって中央管理される、請求項11~14のいずれか1項に記載のシステム。
【請求項16】
前記それぞれのノードグループは、それぞれのインターネットプロトコル(IP)アドレスと、アプリケーションレベルトラフィックを前記複数のコンテナポッドのうちの前記1つ以上のコンテナポッドに直接分散させるためのそれぞれのポートとを含む、請求項11~15のいずれか1項に記載のシステム。
【請求項17】
前記アプリケーションレベル要求は、ハイパーテキスト転送プロトコル(HTTP)を含む、請求項11~16のいずれか1項に記載のシステム。
【請求項18】
前記アプリケーションレベル要求は、ハイパーテキスト転送プロトコルセキュア(HTTPS)を含む、請求項11~17のいずれか1項に記載のシステム。
【請求項19】
前記アプリケーションレベル要求は、トランスポート層セキュリティ(TLS)プロトコルを含む、請求項11~18のいずれか1項に記載のシステム。
【請求項20】
各クラスタは、個別化された負荷分散属性を含む、請求項11~19のいずれか1項に記載のシステム。
【請求項21】
請求項1~10のいずれか1項に記載の方法をコンピュータに実行させるためのプログラム。
【手続補正2】
【補正対象書類名】図面
【補正対象項目名】図3B
【補正方法】変更
【補正の内容】
図3B
【手続補正3】
【補正対象書類名】図面
【補正対象項目名】図5
【補正方法】変更
【補正の内容】
図5
【外国語明細書】