コラム

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

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

CTC 教育サービス

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

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

はじめに

　次回に続いて、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワーク（Jupiterネットワーク）における光スイッチ（OCS: Optical Circuit Switch）の活用例を紹介します。今回は、Spineを取り除いた新しいアーキテクチャーにおいて、ネットワーク通信を最適化する仕組みの1つであるTraffic Engineeringを解説します。

Jupiterのコントロールプレーン

　Jupiterを含むGoogleのネットワークシステムは、Orionと呼ばれる分散型のSDN（Software Defined Network）コントローラーで制御されています。OrionとJupiterの関係については第105回の記事で解説していますが、図1のように色分けされた複数のコントローラーがそれぞれの配下のSpineの構成、および、該当のSpineとAggregation Blockの通信を管理します。コントローラーを分割することにより、特定のコントローラーが停止してもネットワークシステム全体に影響しないように設計されています。

fig01

図1 Jupiterの全体構成、および、Orionとの関係（論文より抜粋）

　光スイッチを導入してSpineを取り除いた新しい構成でも、これと同様に複数のコントローラーによる管理が行われます（図2）。ここでは、光スイッチ（OCN）を4つのグループに分けて、それぞれを異なるコントローラーで管理することにより、コントローラーの障害による影響範囲を限定的にしています。

fig02

図2 光スイッチを導入した環境（論文より抜粋）

　そして、光スイッチやAggregation Blockを実際にコントロールする方法として、Aggregation Blockに対する「Traffic Engineering」と光スイッチに対する「Topology Engineering」の2種類の最適化が行われます。Topology Engineeringは、前回の図3で説明した様に、Aggregation Block間を接続するケーブルの本数を変更して、物理的に通信可能な帯域を調整する方法です。Topology Engineeringの詳細は次回に説明することにして、ここでは先にTraffic Engineeringを解説します。

Traffic Engineeringの仕組み

　論文内で紹介されているTraffic Engineeringのシンプルな例は、図3のようになります。ここでは、3個のAggregation Block (A、B、C) があり、それぞれが100Gbpsの256本のケーブルで相互接続されています。つまり、それぞれのAggregation Block間には、100Gbps×256=25Tbpsの帯域が確保されています。この場合、各ブロック間の通信には、それぞれの直結された経路を使用するのが最もシンプルな構成となります。図3の左はこの状態を表します。

fig03

図3 Traffic Engineeringの適用例（論文より抜粋）

　しかしながら、実際に発生するネットワーク通信をモニタリングした所、A-C間の通信量が特に多く、25Tbpsの帯域では不足する可能性があることが分かったとします。この場合、A-B間、および、B-C間の通信帯域の一部をA-C間の通信用に割り当てるという方法があります。つまり、A-C間の通信においては、A-C間を直結する経路に加えて、Bを挟んで、A-B-Cという経路での通信もできるようにするのです。この際、A-B間、および、B-C間の通信帯域のどれだけをA-C間の通信に割り当てるかは、Aggregation Blockの設定によって調整することができます。モニタリングで得られたデータに基づいて、最適な通信帯域の配分を決定して、Orionのコントローラーから各Aggregation Blockの設定を自動変更する仕組みが用意されており、これがJupiterネットワークのTraffic Engineeringの仕組みになります。
　このような通信経路の最適化は数秒から数分の単位で実施されているということですが、論文の中では、突発的なトラフィックのバーストに対応する工夫も紹介されています。図4のように、3つのブロックがそれぞれ4Tbpsの帯域で接続されており、モニタリングデータから、A-B間、B-C間の通信量はそれぞれ最大2Tbpsと判断したとします。この状況で、通信帯域の割り当て方法として、図4の下にある(a)と(b)の2種類について考えてみます。

fig04

図4 トラフィックのバーストに対応する工夫の例（論文より抜粋）

　(a)は、それぞれのブロックを直結する経路のみを使用するというシンプルな設定です。一方、(b)は、A-B間については、直結する経路とCを経由する経路を50%ずつ使用して、A-C間については、直結する経路とBを経由する経路を50%ずつ使用するという設定になります。この2つの設定を比べると、実は、(b)の方がバーストに強いことが分かります。仮に、A-B間の通信が（予想を越えて）突発的に4Tbpsまで増加したとすると、(a)の場合、A-B間を直結する経路の帯域使用量は4Tbps、すなわち、100%の限界まで達してしまいます。一方、(b)の場合は、直結する経路とCを経由する経路を2TB/sずつ使用するので、A-C間のトラフィック（こちらは予想通りの2Tbpsとします）を加えても、最大の帯域使用量は3Tbps、すなわち、75%でおさえられます。Traffic Engineeringを実施するアルゴリズムは、このような点も考慮して最適な経路の割り当てを決定するということです。なお、理論上は、A-B-C-Dのように2つ以上のブロックを経由する経路を使用することもできますが、通信のレイテンシーが悪化する恐れがあるため、途中で経由するブロックは最大でも1つに制限しています。

次回予告

　今回は、2022年に公開された論文「Jupiter Evolving: Transforming Google's Datacenter Network via Optical Circuit Switches and Software-Defined Networking」を元にして、Googleのデータセンターネットワークにおける光スイッチ（OCS: Optical Circuit Switch）の活用例、特に、ネットワーク通信を最適化するTraffic Engineeringの仕組みを解説しました。次回は、もう1つの最適化の仕組みであるTopology Engineeringについて解説します。

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