Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
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)
0 件のコメント :
コメントを投稿
Labels
App Engine
AppScale
BigQuery
Billing Alerts
Cloud Bigtable
Cloud Consoleアプリ
Cloud Dataproc
Cloud Debugger
Cloud monitoring
cloud Pub/Sub
Cloud SQL
Cloud Storage
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Deployment Manager
Developers
Firebase
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Launcher
Google Cloud Logging
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud Storage Nearline
Google Genomics
IoT
Kubernetes
MySQL
Next
OLDISM
Panda
Puppet
Startups
Vision API
Vitess
イベント
コンピューティング
サポート
スタートガイド
ストレージ
セミナー
ソリューション: メディア
データセンター
ビッグデータ
運用管理
機械学習
月刊ニュース
資格、認定
新機能、アップデート
導入事例
料金
Archive
2016
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
1
2014
12
11
10
9
8
6
5
4
3
2
Feed
Follow @GoogleCloud_jp
0 件のコメント :
コメントを投稿