GCP を支えるロードバランサの設計を公開
2016年3月23日水曜日
* この投稿は米国時間 3 月 16 日、Developer Advocate (Maglev fan) の Maglev and Paul Newson と Technical Lead の Daniel E. Eisenbud によって投稿されたもの(投稿はこちら)の抄訳です。
NSDI ‘16 において Google は、 Google Compute Engine ロードバランシングを pre-worming なしで毎秒数 100 万のリクエストへの対応可能にする Google のロードバランサ Maglev [1] の詳細をご説明いたします。
Google にはネットワークの周辺機器を自前で構築してきた長い歴史がありますので、 2008 年以降、 Google のサービスのトラフィックのほとんどを担ってきたロードバランサも自前で構築したことは当たり前と言えるかもしれません。
Google のデータセンターまわりでトラフィックを実行するカスタム Jupiter ファブリックと異なり、Maglev ロードバランサは普通のサーバー上、つまりサービス自体が使用しているものと同一のハードウェアで動きます。
ハードウェア ロードバランサは、フェイルオーバーを実行可能にするために、少なくとも半分のロードバランシング性能を無駄にしながらアクティブ／パッシブ構成の中でデプロイされるのが通常です。
Maglev ロードバランサはアクティブ／パッシブ構成で動いていません。代わりに、流入するパケットをすべての Maglev に広げるために等コストマルチパス (ECMP) ルートを使用します。そしてこれは特定のパケットをどの Maglev が受信しているかにかかわらず、的確なバックエンド サーバーにパケットを転送するために、整合性のあるハッシュ化テクニックを使用します。
クラスタ内のすべての Maglev はアクティブで、優秀な動きをします。 Maglev のひとつが作動できなくなると、ほかの Maglev が追加のトラフィックを担います。この N+1 冗長方式では、常にアイドル状態で待機するリソースが少なく済むため、従来のハードウェア ロードバランサのアクティブ／パッシブ構成よりもコストパフォーマンスが良くなります。
Google の非常に柔軟なクラスタ管理テクノロジーである Borg では、使われていない容量やその他の操作上の判断を活用するために、 Google のエンジニアがサービスワークロードをクラスタ間で動かすことができます。
Google Cloud Platform では、 Google の顧客が区域や領域間でワークロードを動かせる似たような柔軟性を持っています。特定のクラスタ内で混じり合って動いているサービスは時とともに変化し、ロードバランシング性能の需要の変化を招くことにもなることを意味します。
Maglev はクラスタ内にすでにある同一のサーバーを利用するシンプルなもうひとつの方法にすぎないので、 Maglev ではロードバランシング性能の追加と削減が簡単です。ネットワーク機能を持たせるのに普通のサーバーを使用することをネットワーク機能仮想化 (NFV) といいます。
Google のインフラストラクチャで NFV が効率的に作動するように、Google は長年多大な労力を捧げてきました。Maglev が示しているように、 NFV はネットワーク化する性能の追加と削減を容易にしますが、 NFV テクノロジーを展開する能力を持っていれば、新しいカスタム ハードウェアの追加なしに新しいネットワーク化サービスを増やすことができます。
GCP ユーザーにはどのようなメリットがあるでしょうか？暖気運転やその他のプロビジョニング手段を必要とせずに毎秒ゼロから 100 万リクエスト までスケールできたことを覚えていることでしょう。
Maglev によって Google クラスタはすでに Google スケールでトラフィックを管理しているため、これが可能なのです。新しいMaglev を追加しなくても、毎秒 100 万のさらなるリクエストの追加にも対応できるだけの十分なヘッドルームがあります。既存の Maglev の活用を増やすだけのことなのです。
もちろん、 Maglev の利用が一定以上を超える場合にはさらなる Maglev が必要になってきます。Maglev はクラスタ内にすでに存在している同一のサーバーハードウェア上で展開されるため、性能を容易に追加することが可能なのです。
Google Cloud Platform のデベロッパーはロードバランシング性能を気にする必要はありません。Google の Maglev とそれを管理する Site Reliability Engineers チームがユーザーの代わりをします。トラフィックが急増していることに気づいていても、みなさんは顧客に素晴らしいエクスペリエンスを提供することに集中してください。Googleが問題を片付けますから。
[1] D. E. Eisenbud, C. Yi, C. Contavalli, C. Smith, R. Kononov, E. Mann-Hielscher, A. Cilingiroglu, B. Cheyney, W. Shang, and J. D. Hosein. Maglev: A Fast and Reliable Software Network Load Balancer, 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), 2016
- Posted by Paul Newson, Developer Advocate (Maglev fan)
NSDI ‘16 において Google は、 Google Compute Engine ロードバランシングを pre-worming なしで毎秒数 100 万のリクエストへの対応可能にする Google のロードバランサ Maglev [1] の詳細をご説明いたします。
Google にはネットワークの周辺機器を自前で構築してきた長い歴史がありますので、 2008 年以降、 Google のサービスのトラフィックのほとんどを担ってきたロードバランサも自前で構築したことは当たり前と言えるかもしれません。
Google のデータセンターまわりでトラフィックを実行するカスタム Jupiter ファブリックと異なり、Maglev ロードバランサは普通のサーバー上、つまりサービス自体が使用しているものと同一のハードウェアで動きます。
ハードウェア ロードバランサは、フェイルオーバーを実行可能にするために、少なくとも半分のロードバランシング性能を無駄にしながらアクティブ／パッシブ構成の中でデプロイされるのが通常です。
Maglev ロードバランサはアクティブ／パッシブ構成で動いていません。代わりに、流入するパケットをすべての Maglev に広げるために等コストマルチパス (ECMP) ルートを使用します。そしてこれは特定のパケットをどの Maglev が受信しているかにかかわらず、的確なバックエンド サーバーにパケットを転送するために、整合性のあるハッシュ化テクニックを使用します。
クラスタ内のすべての Maglev はアクティブで、優秀な動きをします。 Maglev のひとつが作動できなくなると、ほかの Maglev が追加のトラフィックを担います。この N+1 冗長方式では、常にアイドル状態で待機するリソースが少なく済むため、従来のハードウェア ロードバランサのアクティブ／パッシブ構成よりもコストパフォーマンスが良くなります。
Google の非常に柔軟なクラスタ管理テクノロジーである Borg では、使われていない容量やその他の操作上の判断を活用するために、 Google のエンジニアがサービスワークロードをクラスタ間で動かすことができます。
Google Cloud Platform では、 Google の顧客が区域や領域間でワークロードを動かせる似たような柔軟性を持っています。特定のクラスタ内で混じり合って動いているサービスは時とともに変化し、ロードバランシング性能の需要の変化を招くことにもなることを意味します。
Maglev はクラスタ内にすでにある同一のサーバーを利用するシンプルなもうひとつの方法にすぎないので、 Maglev ではロードバランシング性能の追加と削減が簡単です。ネットワーク機能を持たせるのに普通のサーバーを使用することをネットワーク機能仮想化 (NFV) といいます。
Google のインフラストラクチャで NFV が効率的に作動するように、Google は長年多大な労力を捧げてきました。Maglev が示しているように、 NFV はネットワーク化する性能の追加と削減を容易にしますが、 NFV テクノロジーを展開する能力を持っていれば、新しいカスタム ハードウェアの追加なしに新しいネットワーク化サービスを増やすことができます。
GCP ユーザーにはどのようなメリットがあるでしょうか？暖気運転やその他のプロビジョニング手段を必要とせずに毎秒ゼロから 100 万リクエスト までスケールできたことを覚えていることでしょう。
Maglev によって Google クラスタはすでに Google スケールでトラフィックを管理しているため、これが可能なのです。新しいMaglev を追加しなくても、毎秒 100 万のさらなるリクエストの追加にも対応できるだけの十分なヘッドルームがあります。既存の Maglev の活用を増やすだけのことなのです。
もちろん、 Maglev の利用が一定以上を超える場合にはさらなる Maglev が必要になってきます。Maglev はクラスタ内にすでに存在している同一のサーバーハードウェア上で展開されるため、性能を容易に追加することが可能なのです。
Google Cloud Platform のデベロッパーはロードバランシング性能を気にする必要はありません。Google の Maglev とそれを管理する Site Reliability Engineers チームがユーザーの代わりをします。トラフィックが急増していることに気づいていても、みなさんは顧客に素晴らしいエクスペリエンスを提供することに集中してください。Googleが問題を片付けますから。
[1] D. E. Eisenbud, C. Yi, C. Contavalli, C. Smith, R. Kononov, E. Mann-Hielscher, A. Cilingiroglu, B. Cheyney, W. Shang, and J. D. Hosein. Maglev: A Fast and Reliable Software Network Load Balancer, 13th USENIX Symposium on Networked Systems Design and Implementation (NSDI 16), 2016
- Posted by Paul Newson, Developer Advocate (Maglev fan)
0 件のコメント :
コメントを投稿