これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
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）スイッチのホットリンクを回避してコンテナを配置する技術」について解説します。今回は、ホットリンクを回避するためのBorgスケジューラーの拡張とその効果を説明します。
前回の記事では、ToRスイッチの帯域使用率がストレージアクセスのテイルレイテンシーに及ぼす影響を解説しました。特に、ストレージへのデータの書き込み処理は帯域使用率の影響を受けやすく、帯域使用率が75%を超える「ホットリンク」を回避する事で、書き込み処理のテイルレイテンシーを大きく改善できる可能性があります。冒頭の論文では、Borgのスケジューラーにホットリンクを回避する機能を追加することで、テイルレイテンシーの改善を実現した結果が報告されています。論文内では、該当の機能を「UTP（ToR-Utilization aware Task Placement and migration）」、および、「CCP（ToR-Capacity aware Chunk Placement）」と呼んでいます。
UTPとCCPの仕組みを理解する前提として、これらを導入する以前のBorgスケジューラーについて簡単に説明します。まず、Borgは、Googleのデータセンターで標準的に使用されているコンテナ管理システムです。Borgについては、下記から始まる一連の記事に解説があります。
・第32回 アプリケーション実行基盤の標準環境 Borg（パート1）
アプリケーションを構成するタスク（マイクロサービス）のデプロイをBorgにリクエストすると、Borgスケジューラーは、該当タスクが必要とするCPUやメモリーなどのリソースに基づいて、タスクをデプロイするサーバーを選択します。また、稼働中のタスクを動的に他のサーバーにマイグレーションすることもあります。この際、膨大な数のサーバーからさまざまな条件を考慮して最適なサーバーを選択する必要がありますが、すべてのサーバーを網羅的にチェックするのは時間がかかるため、一定数のサーバーをランダムに選択して、その中から最適なサーバーを選択します。
ただし、UTP／CCPを導入する以前のスケジューラーは、ネットワーク帯域に関する考慮は行いません。CPUやメモリーは、デプロイ先のサーバーだけを見て判断できますが、ネットワーク帯域については、デプロイ先のサーバーだけではなく、デプロイしたタスクがどのストレージにアクセスするかを考慮する必要があり、最適化の計算処理が膨大になる恐れがあり、スケジューラーの機能からは除外されていました。
Borgスケジューラーにホットリンクを回避する機能を追加するにあたり、UTPでは、「ネットワーク帯域の使用率を最適化する」という考え方ではなく、よりシンプルに、「帯域使用率が75%を超えるホットリンクが発生しているラックを避ける」というアプローチを採用しています。前回の記事で見たように、帯域使用率が75%を超えるとテイルレイテンシーが急速に悪化するという目安があるので、そのようなラックを避けてタスクを配置するだけでも十分な効果があると考えられます。また、あるラックで新たにホットリンクが発生した場合は、該当ラック内のサーバーで稼働するタスクの中で、ネットワーク帯域使用量が大きく、また、マイグレーションの影響が小さいタスクを選択して、他のラックのサーバーにマイグレーションを行います。
次の図1は、UTPの導入効果を示したデータです。ホットリンクの発生箇所としては、ストレージにアクセスするタスクがデプロイされたラックと、ストレージ機能を提供するDサーバーが稼働するラックの2箇所が考えられます。UTPは、ストレージにアクセスするタスクをデプロイするラックを選択する機能ですので、ここでは、タスクがデプロイされるCompute Hostから外向きのリンクに発生するホットリンクを計測しています。図1の左は、該当のリンクにホットリンクが存在する割合の変化を時系列で示したもので、UTP導入以前の値を1としています。背景がグリーンの部分でUTPが導入されており、UTP導入後は、ホットリンクの割合が1以下に減少していることがわかります。平均で90%のホットリンクが削減できたということです。また、図1の右は、該当リンクの帯域使用率を平均値（赤色のグラフ）および98パーセンタイルでの値（青色のグラフ）で示します。UTPの導入により98パーセンタイルでの値が減少しており、帯域使用率が逼迫する状況が低減されていることがわかります。
図1 UTPの導入効果（論文より抜粋）
また、図2は、UTPによるQuerySysベンチマークの改善効果を表します。前回の記事で説明したように、QuerySysは、データベースのバックエンドで利用される汎用的なクエリーエンジンで、QuerySysの開発チームでは、いくつかのパターンのベンチマークを用意しています。図2からは、すべてのベンチマークで95パーセンタイルのテイルレイテンシーが改善していることがわかります。特に改善効果が大きいShuffle Flushは、シャッフル時にメモリーキャッシュが不足してHDDに対するキャッシュの書き込み処理が発生するパターンのベンチマークです。
図2 UTPによるQuerySysベンチマークの改善効果（論文より抜粋）
もう一方のCCPは、ストレージ機能を提供するDサーバーのラックにおけるホットリンクを回避する仕組みです。分散ファイルシステムのColossusは、ファイルデータを複数のチャンクに分割して複数のDサーバーに分散保存しますが、CCPは、チャンクを保存するDサーバーを選択する際の優先順位付けを行います。
この仕組みは、図3の計測データに基づきます。ここでは、ラック全体のディクス容量とToRのネットワーク帯域の比率を元に、ラックをHigh、Medium、Lowの3つに分類しており、Highは、導入時のガイドラインで決められた以上のネットワーク帯域を持っており、Medium、Lowの順にネットワーク帯域の比率が下がります。そして、図3のグラフは、ToRのネットワーク帯域使用率ごとの3種類のラックの比率を示します。ネットワーク帯域使用率が上がるにつれて、Middle、Lowのラックの割合が増えています。したがって、Highのラックを優先的に使用することでホットリンクの発生を回避できることがわかります。そこで、CCPは、チャンクを保存するDサーバーを決定する際に、上述のHigh、Mideium、Lowの順番に優先順位を付けて選択します。アプリケーションのタスクと異なり、ファイルチャンクは永続的に保存されるものなので、配置時点で発生しているホットリンクではなく、将来的にホットリンクが発生する可能性を低減するための仕組みになります。
図3 ディスク容量／ネットワーク帯域の比率と帯域使用率の関係（論文より抜粋）
そして、次の図4は、CCPの導入効果を表します。データセンター内のクラスターをいくつかのグループに分けて、それぞれのグループに対して、CCPを導入した際の95パーセンタイルレイテンシーの減少率を示しています。ここでは、Colossusからのデータ読み出し処理全体のレイテンシー（青色のグラフ）とネットワーク通信部分のレイテンシー（赤色のグラフ）が示されています。Colossusの処理全体で見て、30%～60%の削減が実現されています。
図4 CCPの導入効果（論文より抜粋）
今回は、2025年に公開された論文「Preventing Network Bottlenecks: Accelerating Datacenter Services with Hotspot-Aware Placement for Compute and Storage」に基づいて、Googleのデータセンターで利用されている「ToRのホットリンクを回避してコンテナを配置する技術」に関して、ホットリンクを回避するためのBorgスケジューラーの拡張とその効果を説明しました。
次回は、大規模言語モデルを用いたソフトウェアの自動バグ修正に関する話題をお届けします。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python Power Platform 最新技術動向 生成AI Docker Kubernetes
