コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第137回　Jupiter Evolving：データセンターネットワークでの光スイッチ（OCS）の活用例（パート2）

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

CTC 教育サービス

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

第137回　Jupiter Evolving：データセンターネットワークでの光スイッチ（OCS）の活用例（パート2） (中井悦司) 2022年10月

はじめに

　前回に続いて、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワーク（Jupiterネットワーク）における光スイッチ（OCS: Optical Circuit Switch）の活用例を紹介します。今回は、Jupiterネットワークに光スイッチが必要とされた背景と、光スイッチを組み込んだアーキテクチャーの概要を説明します。

Closトポロジーの課題

　光スイッチを導入する以前のJupiterネットワークは、図1のように、ToR、Aggregation Block、Spineの3層からなる「Closトポロジー」のアーキテクチャーを採用していました。サーバーラックに搭載されたToR（Top of Rackスイッチ）をAggregation Blockに集約した後、さらに複数のAggregation Blockを最上位のSpineで相互接続する形になります（図1）。

fig01

図1 Closトポロジー構成（Google CloudのBlog記事より転載）

　図1を見ると分かるように、それぞれのAggregation BlockとSpineはフルメッシュで相互接続されており、Aggregation Block間には複数の通信経路が存在します。これら複数の経路を同時に使用して負荷分散することで、広い通信帯域を実現しています。しかしながら冒頭の論文によると、この構成には、ネットワークの規模を拡張するためにSpineを後から追加する、もしくは、新しい機器に交換することが困難という課題がありました。Aggregation BlockとSpineの間は多数のケーブルで接続されており、Spineを交換・追加する際は、既存の配線を手作業で変更する必要があります。既存の配線の物理変更は、作業コストも大きく、作業ミスで障害を引き起こすリスクも高くなります。
　また、このような手作業を経て新しいSpineを追加したとしても、新しい機器の性能を最大限に利用できない場合があります。図1では、100Gb/sでの通信をサポートする機器と200Gb/sでの通信をサポートする新しい機器が混在した状況が示されていますが、単純なフルメッシュ接続にした場合、新しい機器は大部分の接続において100Gb/sでの通信を行います。つまり、物理的にはバランスの取れた配線であっても、機器の性能を考慮すると、論理的にはバランスの悪い構成になってしまうのです。データセンターネットワークのシステムは、一度構築した環境を長い期間に渡って使い続けることなりますが、これまでの環境は、新しい機器に入れ替えながら段階的にシステムを更新・拡張することが困難だったのです。

Jupiterへの光スイッチの導入

　Jupiterの開発チームでは、上記の課題を解決するためにAggregation BlockとSpineの間に「DCNI（Datacenter network interconnection layer）」を導入しました（図2）。DCNIは多数の光スイッチを並列に配置したレイヤーで、それぞれのAggregation Blockは、すべての光スイッチと光ケーブルで接続しておきます。同様に、それぞれのSpineもすべての光スイッチと接続します。前回説明したように、光スイッチは対向するポートの接続先を自由に変更することができるので、これにより、Aggregation Blockから出ているそれぞれの光ケーブルについて、接続先のSpineを自由に切り替えることができます。

fig02

図2 DCNIによるAggregation BlockとSpineの接続（論文より抜粋）

　そして、この仕組みを利用すると、図3のように新しいSpineを段階的に追加することができます。

fig03

図3 DCNIを利用してSpineを段階的に追加する様子（論文より抜粋）

　図3の左上では、2個のAggregation Blockと2個のSpineが512台の光スイッチからなるDCNIを介して接続されています。つまり、それぞれのAggrigation Block、および、Spineからは、512本ずつの光ケーブルが伸びており、それぞれが異なる光スイッチに接続されます。そして、これらの接続をそれぞれのブロック間で均等に振り分ける様に光スイッチを設定します。つまり、1つのAggregation Blockから伸びた512本のケーブルは、半分の215本が一方のSpine、残り半分の215本がもう一方のSpineに接続されます。論理的には、左下の図のような構成になります。
　次に、その右の図は、新しいAggregation BlockとSpineを1つずつ追加した状態です。青色のラインが新しく追加された光ケーブルになります。この時、光スイッチの設定を変更することで、それぞれのAggregation BlockとSpineを接続する光ケーブルの本数を自由に調整することができます。Aggregation Blockから伸びる512本の光ケーブルを3つのSpineに対して1/3ずつに振り分けることもできますし、あるいは、3つのSpineの性能に差がある場合は、特定のSpineに対する接続本数を増やして、そのSpineを通るトラフィックを多くするといった対応が可能になります。Aggregation BlockやSpineを追加する際、新しく追加する部分の光ケーブル（青色のライン）は手作業による配線が必要ですが、既存の光ケーブルについては、物理的な再配線は必要ありません。

Spineを用いない構成への変更

　ここまで、DCNIを導入した当初の構成を説明しましたが、実はその後、さらなる構成の変更がありました。光スイッチによって接続先を自由に変更できる利点があれば、そもそもSpineはなくても構わないのではないか、というアイデアが生まれたのです。具体的には、図4のような構成になります。

fig04

図4 Spineを用いない構成例（論文より抜粋）

　図4は上段が論理的な接続図で、下段が物理的な接続図になります。AとBの2個のAggregation Blockからなる構成、および、さらに2個のAggregation Blockを追加して、A、B、C、Dの4個のAggregation Blockからなる構成に拡張した状態が例として示されています。まず、2個のAggregation Blockからなる構成では、それぞれから伸びた光ケーブルが1対1で接続されています。そして、4個のAggregation Blockからなる構成では、1つのAggregation Blockから見て、1/3ずつの光ケーブルで3つのAggregation Blockと接続される形になります。下段の物理図では、すべてのブロックがフルメッシュでDCNIと接続されていますが、論理的には、上段の図のように光ケーブルごとに接続先が振り分けられている点に注意してください。
　理論上は、Spineがある方が利用可能な通信経路のパターンが多くなり、より柔軟な通信経路の最適化が可能になりますが、Jupiterの開発チームは、Googleのデータセンターにおけるネットワーク通信のパターンを分析した結果、次回以降に説明するネットワーク最適化の技術を活用すれば、Spineが無くても問題ないという判断に至りました。これにより、Spineに使用する機器のコストを削減できたということです。

次回予告

　今回は、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワークにおける光スイッチ（OCS: Optical Circuit Switch）の活用例、特にJupiterネットワークに光スイッチが必要とされた背景と、光スイッチを組み込んだアーキテクチャーの概要を紹介しました。次回は、このアーキテクチャーを用いて、ネットワーク通信を最適化する仕組みを解説したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡