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

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

[＠IT]

　米グーグルは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のユーザーはロードバランシングを気に掛けることなく、アプリケーション開発に集中できると述べている。