コラム

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

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

CTC 教育サービス

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

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

はじめに

　次回に続いて、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワーク（Jupiterネットワーク）における光スイッチ（OCS: Optical Circuit Switch）の活用例を紹介します。今回は、Aggregation Block間を接続するケーブルの本数を変更して物理的に通信可能な帯域を調整する、Topology Engineeringの仕組みを解説します。

Topology Engineeringの仕組み

　前回に説明したTraffic Engineeringは、Aggregation Block間を直結する経路（Shortest path）だけではなく、1つのAggregation Blockを経由して通信する経路を併用することで、最適な通信帯域の配分を行う仕組みでした。その一方、第137回の記事でも触れた様に、ネットワークを構成する機器を段階的に更新・拡張した場合、性能の異なる機器が混在する環境が生まれます。このような場合は、Traffic Engineeringで通信経路を最適化するだけではなく、物理的な配線を最適化する必要があります。図1は、論文内で紹介されているシンプルな例になります。

fig01

図1 Topology Engineeringによる最適化の例（論文より抜粋）

　図1には3つのAggregation Block（A,B,C）があり、それぞれ、ケーブルを接続するポートが500個ずつあります。つまり、それぞれのAggregation Blockからは500本のケーブルが伸びており、物理的には、250本ずつに分けて他の2個のAggregation Blockと接続する構成が最もシンプルになります。しかしながら、機器の世代によって1本のケーブルあたりの通信速度が異なる場合があります。AとBはケーブル1本あたり200Gbps、Cは100Gbpsの通信速度だとすると、均等に振り分けた構成の場合、各Aggregation Block間の帯域は、図1の左のように偏りがある状態になります。そしてさらに、実際に予想される通信量は、図1の左端の表のようになっていたとします。今の構成のままでは、A-B間の通信帯域が不足することになります。また、A-C間の通信帯域もすでに100%の使用量になっているため、Traffic EngineeringでA-C-Bという経路を追加することもできません。
　実は、この状況は、Traffic Engineeringに加えて、Aggregation Block間の物理的なケーブルの本数を変更するTopology Engineeringを組み合わせることで解決できます。まず、A-B間を300本、そして、A-C間、および、B-C間を200本のケーブルで接続します。この場合、A-B間の帯域は60Tbps、A-C間、および、B-C間の帯域は20Tbpsになります。そして、Traffic Engineeringによって、A-C間の通信経路として、A-B-Cという経路を5Tbpsだけ割り当てます。落ち着いて考えるとわかるように、これによって、左端の表に示した帯域をすべて確保することができます。
　図1は、あくまでも説明用に考えた例ですが、現実のネットワーク構成においても、それぞれの機器の性能と予想される通信量に応じて、Aggregation Block間を接続するケーブルの本数を自由に変更できるメリットは理解できると思います。Jupiterネットワークでは、SDNコントローラーから光スイッチ（OCS）の構成を変更することで、このようなTopology Engineeringを実現しています。物理的な接続を変更する際は、既存のトラフィックに影響を与えない様に段階的に変更する必要があり、1回の変更は数時間かけて行うということです。また、既存のトラフィックデータを用いてシミュレーションした所、Topology Engineeringによる接続変更は、数週間に1回程度で十分な最適化ができるということです。
　実環境におけるTopology Engineeringの効果は、図2のようになります。

fig02

図2 実環境におけるTopology Engineeringの効果（論文より抜粋）
　
　ここでは、A〜Jの10種類のデータセンターネットワークの実データでシミュレーションを行い、Topology Engineeringを実施した場合（赤色のグラフ）としなかった場合（青色のグラフ）の比較結果が示されています。上段のグラフはスループット、下段のグラフはホップ数の平均を示します。Aggregation Block間で直接に通信する場合のホップ数が1で、他のAggregation Blockを経由する場合のホップ数が2になります。特にDの環境では、Topology Engineeringの効果が大きく現れています。Topology Engineeringを実施しない場合、ホップ数の平均が大きく、Traffic Engineeringによって、他のAggregation Blockを経由する経路が多数使用されています。Topology Engineeringを実施することで、Aggregation Block間で直接に通信する経路が増えてホップ数の平均が減少し、その結果、スループットが向上していることが分かります。

次回予告

　今回は、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワークにおける光スイッチ（OCS: Optical Circuit Switch）の活用例、特に、Aggregation Block間を接続するケーブルの本数を変更して物理的に通信可能な帯域を調整する、Topology Engineeringの仕組みを解説しました。
　次回は、最近よく耳にする機械学習ライブラリー「JAX」に関する話題をお届けします。

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