これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
今回からは、2025年に公開された論文「Preventing Network Bottlenecks: Accelerating Datacenter Services with Hotspot-Aware Placement for Compute and Storage」に基づいて、Googleのデータセンターで利用されている「ToR（Top of Rack）スイッチのホットリンクを回避してコンテナを配置する技術」について解説します。今回は、このような技術が必要となる背景を説明します。
Googleのデータセンターネットワークの構成には、これまでにいくつかの主要な変更がありましたが、現在は、図1の構成が採用されています。サーバーラックごとに該当ラック内のホストを集約するToR（Top of Rack）スイッチがあり、これらを束ねるAggregation Switchがあります。さらに、複数のAggregation Switchは、Datacenter Network Interconnect（DCNI）と呼ばれるレイヤーで相互接続されています。
図1 現在のデータセンターネットワークの構成（論文より抜粋）
この構成は、Googleが独自開発したJupiterネットワークが基礎になっています。Jupiterネットワークについては、下記から始まる一連の記事に解説があります。
・第13回 1Pbpsのデータセンターネットワークを実現したJupiter（パート1）
Jupiterネットワークでは、図1のDCNIに相当する部分は、Spineブロックと呼ばれるスイッチ群で構成されていましたが、その後、この部分は光スイッチ（OCS: Optical Circuit Switch）に置き換えられました。OCSの導入については、下記から始まる一連の記事に解説があります。
・第136回 Jupiter Evolving：データセンターネットワークでの光スイッチ（OCS）の活用例（パート1）
図1の構成では、任意の2つのホスト間に複数のネットワーク経路が用意されており、ホスト同士の位置関係に依存せず、広い通信帯域が確保されています。このため、ホストにコンテナをデプロイする際は、ホスト間のネットワーク帯域は考慮せずに、ホストのCPU使用率や空きメモリー容量など、ホストそのものの条件に基づいてコンテナの配置が決定されていました。
しかしながら、それぞれのスイッチの使用状況を詳細に調べてみると、これは必ずしも最適とは言えないことがわかりました。図1のネットワーク構成では、ホスト間の通信経路は、大きく、「ホストとToRの間」「ToRとAggregation Blockの間」「DCNI内部」の3つの部分に分かれますが、「ToRとAggregation Blockの間」では、他の部分に比べて高い頻度で輻輳が発生していたのです。図2は、帯域の使用率が75%を超える部分を「ホットリンク」と定義して、ホットリンクが存在する比率を前述の3つの部分で比較したものです。これを見ると、「ToRとAggregation Blockの間」は、他の部分に比べて高い割合でホットリンクが存在することがわかります。
図2 ネットワーク経路内で輻輳が発生する比率（論文より抜粋）
また、次の図3は、ホットリンクが継続する時間の比率を表します。これを見ると5分から14日間まで、広い範囲で分布しており、ホットリンクの発生は突発的な事象ではなく、長時間継続することが読み取れます。
図3 ホットリンクの継続時間の比率（論文より抜粋）
従って、すでにホットリンクが存在するラックのホストにコンテナを配置すると、このコンテナは長時間に渡ってホットリンクの影響を受ける可能性があります。新たにコンテナを配置する際は、ホットリンクが存在するラックを避けて配置した方がよい事がわかります。詳細は次回以降の記事で解説しますが、ホットリンクを避けてコンテナを配置する技術を導入した結果、ホットリンクが存在するToRを90%削減して、分散ファイルシステムの95パーセンタイルのレイテンシーを50%短縮することができたということです。
冒頭の論文では、ホットリンクの発生原因について、ストレージアクセスの影響が大きい点を指摘しています。これを理解するために、まず、Googleのデータセンターにおける分散ストレージの構成を説明しておきます。Googleのデータセンターではアプリケーションが使用するデータは、Colossusと呼ばれる分散ファイルシステムとRamStoreと呼ばれるメモリーベースのストレージに保存されます。そして、Colossusが使用する物理ディスクは、「D」と呼ばれるサーバーによって提供されます。Dサーバーは、大容量のHDD、もしくは、SSDが接続されたサーバーで、Colossusは、ファイルデータを複数のチャンクに分割して複数のDサーバーに分散保存します。これと同様に、RamStoreが使用するメモリーは、大容量メモリーを搭載した「Memory Host」と呼ばれるサーバーによって提供されます。
そして、データセンター内のラックには、Dサーバーのみを搭載したDiskラック、アプリケーションのコンテナをデプロイするためのサーバーのみを搭載したComputeラック、そして、これらが混在したMixedラックがあります。図4はホットリンクが発生するラックタイプの割合を示したもので、DiskラックとMixedラックが90%近くを閉めています。つまり、ホットリンクの大部分は、ストレージアクセスに伴うネットワーク通信に起因すると考えられます。
図4 ホットリンクが発生するラックタイプの割合（論文より抜粋）
ただし、Diskラックを設置する際は、該当のラックに搭載されたディスク容量に応じてネットワークリンクの容量も設計されています。それにもかかわらず、Diskラックでホットリンクが発生する原因として、論文では、ネットワーク設備とディスクのメンテナンス頻度の違いを指摘しています。Diskラックに搭載されたHDDは、一定の頻度で故障に伴って交換されますが、この際、HDD製品の性能向上によって以前よりも大容量で高速なHDDに置き換えられていきます。一方、ラックに搭載されたToRは、HDDほど簡単に交換することができず、ToRのネットワークリンクの容量は簡単には増やせません。このようなメンテナンス頻度の違いにより、当初設計されたリンク容量を超えたディスクアクセスが発生することが、想定外のホットリンクの発生につながっていると考えられます。
今回は、2025年に公開された論文「Preventing Network Bottlenecks: Accelerating Datacenter Services with Hotspot-Aware Placement for Compute and Storage」に基づいて、Googleのデータセンターで利用されている「ToRのホットリンクを回避してコンテナを配置する技術」に関して、ホットリンクを回避した配置が必要となる背景を説明しました。次回は、ホットリンクが及ぼす影響の分析結果を紹介します。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
