コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第14回　1Pbpsのデータセンターネットワークを実現したJupiter（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第14回　1Pbpsのデータセンターネットワークを実現したJupiter（パート2） (中井悦司) 2017年4月

はじめに

　2015年に公開された論文「Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network」をもとにして、Googleのデータセンターで利用されるネットワーク技術を紹介していきます。
　前回は、マルチパスイーサネット技術を用いた、一般的なClosトポロジーネットワークの概要を説明しました。これは、複数経路による負荷分散を用いて、スケーラブルなL2ネットワークを構成する仕組みですが、グーグルでは、このアーキテクチャーをどのように実装してきたのでしょうか？
　今回は、ソフトウェアアーキテクチャーの観点から、この仕組みを紐解いていきます。

独自ソフトウェアによるネットワークスイッチの制御

　前回も説明したように、Closトポロジーネットワークそのものは、グーグル独自の仕組みではありません。マルチパスイーサネットに対応した商用のネットワークスイッチで、Closトポロジーネットワークを構築することも可能です。それでは、なぜ、グーグルでは、独自設計のスイッチの開発を進めたのでしょうか？

　前述の論文では、サーバー機器の性能向上に伴うネットワーク通信量の増加を考えると、ネットワークスイッチにおいても、サーバー機器と同等のペースでの性能向上が求められる点が指摘されています。市販のスイッチチップを用いてネットワークスイッチを設計しておけば、スイッチチップの性能向上に合わせて独自のペースでスイッチのアップグレードを行い、このような性能要求に応えることが可能になるというわけです。

　また、スケールアウト型に構成された多数のスイッチを管理するソフトウェア技術についても説明があります。ベンダーが提供する商用のネットワーク機器は、高機能で汎用性が高いという特徴があります。特に、さまざまな環境・構成での利用に対応するため、多くの場合、スイッチ同士が相互の接続状態を確認しながら協調動作するという自律分散型の制御方式が採用されています。これは、ネットワークの世界では古くから採用されている方式です。しかしながら、Closトポロジーの環境では、スイッチ間の接続経路が膨大になるため、自律分散による制御方式では管理が複雑になる恐れがあります。さらに、構成情報がネットワーク全体に伝搬する時間が長くなり、性能上の問題が発生する可能性もあります。そこで、グーグルでは、スイッチ間の接続状態を集中管理するソフトウェアの開発を進めました。論文では、Firehose、Watchtower、Saturnの3つの世代で採用されている、「Firepath」と呼ばれるソフトウェアアーキテクチャーが解説されています。

　Firepathの基本的な考え方は、次にようになります。まず、データセンター内におけるスイッチの構成（Closトポロジー）を標準化しておき、その構成情報を各スイッチに事前に配布します。各スイッチは、構成情報で指定された役割にしたがって初期設定が行われます。その後、それぞれのスイッチは、自身に接続された他のスイッチとの接続状態を動的に確認していき、接続が確認できない部分があれば、その情報をマスタースイッチに通知します。マスタースイッチは、各スイッチからの通知をそれぞれのスイッチに再配布します。各スイッチは、最初に持っている構成情報とマスタースイッチから受け取った差分情報を総合して実際のネットワーク構成を把握した後、一定のアルゴリズムにもとづいてパケットの転送経路を決定していきます。この際、マスタースイッチとの構成情報のやり取りは、専用のネットワーク経路を用いたUDP/IPマルチキャスト通信で行われます。これは、現代的な言葉でいうと、SDN（Software Defined Network）のコントロールプレーンに当たるものです。グーグルでは、2000年代の半ばにおいて、すでにSDNのアーキテクチャーを独自開発していたことがわかります。

　ちなみに、本来あるべき構成情報を事前に配布しておくという方法には、接続作業のミスを容易に発見できるというメリットもあります。各スイッチは、それぞれのポートに接続されている対向ポートのID番号を確認して、構成情報で指定されたID番号以外のポートを発見した場合は、アラートを発生します。誤った構成のまま、不安定な状態で稼働を継続するという問題を確実に防止することができます。

Firepathのアーキテクチャー

　先の論文では、Firepathのアーキテクチャーが図1のように図解されています。図1の左上は、Closトポロジーを構成するスイッチの内部構造で、図に示された「Firepath Client」がマスタースイッチ上の「Firepath Master」と構成情報のやりとりを行います。「Embedded Stack」はスイッチ本体の機能（パケットの転送処理）を担う部分で、Firepath Clientによって経路情報（Forwarding Table）の更新が行われます。また、Embedded Stackは、他のスイッチとの接続状態をFirepath Clientに伝達する役割も担います。一方、図1の右上は、外部ネットワークとの相互接続を行うCBR（Cluster Border Router）スイッチの内部構造です。これは、Firepath Clientが計算した経路情報をBGPに変換して、外部のBGPルーターに伝達する機能を持ちます。

fig01