検索
ニュース

グーグルのソフトウェアネットワークロードバランサー「Maglev」の仕組みGoogle Cloud PlatformのNFV実装

グーグルはソフトウェアネットワークロードバランサー「Maglev」の詳細を現在開催中のNSDI ‘16で発表することを明らかにし、公式ブログでこの技術を解説した。

Share
Tweet
LINE
Hatena

 米グーグルは2016年3月16日(米国時間)、自社で開発したソフトウェアネットワークロードバランサー「Maglev」の詳細を「NSDI '16」で発表することを公式ブログで明らかにした。

 NSDI '16は2016年3月16〜18日に米カリフォルニア州サンタクララで開催されるシンポジウム「13th USENIX Symposium on Networked Systems Design and Implementation」の略称。グーグルのIaaS(Infrastructure as a Service)「Google Compute Engine」では、Maglevのロードバランシングによって、プレウォーミングなしで1秒当たり100万件のリクエストに対応できるという。

 公式ブログによると、グーグルは長年、ネットワーク機器を独自に開発しており、ネットワークロードバランサーも2008年以来、同社が開発した「Jupiter」(グーグルの最新世代カスタムネットワーク機器の社内での呼称)ファブリックがグーグルの各サービスへのトラフィックのほとんどを処理してきたという。Maglevは、Jupiterファブリックとは異なり、通常のサーバ(グーグルのサービス自体が使用するのと同じハードウェア)で動作する。


一般的なハードウェア型ネットワークロードバランサー(左)とMagrev(右)の違い

 ハードウェア型のネットワークロードバランサは、アクティブ/パッシブ構成でフェイルオーバーを実現することが多いが、MaglevはEqual-Cost Multi-Path(ECMP)ルーティングを使用して、受信パケットを全てのMaglevノードに分散する。これらのMaglevノードは一貫したハッシュ技術を使って、パケットを適切なサービスバックエンドサーバに転送する。クラスタ内のMaglevノードの1つが使用不能になると、他のMaglevノードがその分のトラフィックを伝送できるようになっており、グーグルは、「このN+1の冗長性は、従来のハードウェア型ネットワークロードバランサーのアクティブ/パッシブ構成よりもコスト対効果が高い。意図的にアイドル状態にされるリソースが少なくなるからだ」と説明している。


Maglevの動作イメージ

 柔軟性の高いグーグルのクラスタ管理技術「Borg」のおかげで、グーグルのエンジニアは必要に応じてサービスワークロードをクラスタ間で移動できる。また、グーグルの開発者向けクラウドプラットフォーム「Google Cloud Platform」(GCP)のユーザーは、ワークロードをゾーンやリージョン間で同じように柔軟に移動できるが、これは、特定のクラスタで動作するサービスの組み合わせが時間とともに変わり、それに伴ってロードバランシングキャパシティーの要求も変わるということを意味する。

 だが、Maglevはこうしたサービスと同じく、クラスタ内のサーバを使用して機能するので「Maglevのロードバランシングキャパシティーを追加または削除するのは簡単だ」とグーグルは述べている。

 最近では、クラウドサービス事業者らを中心に仮想化技術を活用してネットワーク機能を汎用的なPCサーバ上で実現する「ネットワーク機能仮想化(Network Functions Virtualization:NFV)」の導入が進んでおり、グーグルも長年、自社インフラではNFVの活用に取り組んできたという。ブログでは、「Maglevが示すように、NFVはネットワークキャパシティーの追加、削除を容易にするだけでなく、NFV技術を展開できれば、新しいカスタムハードウェアを追加しなくても、新しいネットワークサービスを追加できる」と、NFVのメリットを強調している。

 またグーグルは、Maglevの使用量がしきい値を超えると、Maglevノードの追加が必要になるが、そうした作業を含む管理はグーグルの専門技術者が行うので、Google Cloud Platformのユーザーはロードバランシングを気に掛けることなく、アプリケーション開発に集中できると述べている。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る