こんにちは。Site Operation本部の深澤と小林です。普段は同じチームのメンバーとしてデータセンターネットワークの運用などを担当しています。
2024年1月17日(水) ~ 19日(金) に開催された JANOG53 Meeting IN HAKATA にて「データセンターネットワークでの輻輳対策どうしてる?」というタイトルで登壇をしました。
この登壇では、データセンターネットワークの輻輳に関する技術や課題、実際にHadoopを用いて行った輻輳制御の検証結果をお話しさせていただきました。
今回は、登壇の内容や質疑応答を書き起こし記事としてレポートしたいと思います。
また、質疑応答でいただいたものを参考に追加検証を行いましたので、そちらの結果を共有もいたします。
1.1. データセンターネットワークと輻輳制御
最初に、この発表を行った背景について解説します。
LINEヤフーは大規模なインフラをオンプレで運用する企業です。
さまざまなサービスを提供するためのアプリケーションやミドルウェアを含むシステムが、データセンターの共通の物理ネットワーク上で通信しています。
これまでのデータセンターネットワークは、クラウドサービスために帯域・拡張性・可用性を追求しアプリケーションのパフォーマンスを最大化する目的で設計されてきました。
アプリケーションのパフォーマンスを決定づけるネッ トワークの重要な要素は3つあると私たちは考えています。
- Topology
- Routing
- Flow/Congestion Control
まずネットワークのトポロジーで、そのネットワーク全体での転送容量(キャパシティ)と拡張性が決まります。
次にルーティングプロトコルによって、そのトポロジー上の伝送路(パス)をどのように効率的に利用し、冗長性を担保するかが決まり、
最後にフロー制御・輻輳制御(ここではまとめて輻輳制御と記載します)によってパケットロスと再送を発生させない頑強なパケット転送を実現します。
私たちはこの3つの要素を適切に設計することで、アプリケーションのパフォーマンスを最大化できると考えています。
トポロジーとルーティングについては、ClosトポロジーとBGP in DC(RFC7938)が課題を解決してきました。
最後の輻輳制御が現在最もホットな課題になっています。
データセンターネットワークの輻輳と対策について語る上で、最初にデータセンターネットワーク上のどこでどのような輻輳が発生するのかについて説明します。
データセンター上での輻輳ポイントは大きく3つに分類されます。
- In-cast Congestion
- 複数の送信元が1つの宛先にデータを同時に送信する多対⼀の通信
- 受信側バッファでtail dropが発⽣する
- 現在のデータ センターネットワークで問題になりやすい
- Out-cast Congestion
- 特定の出⼒キューが総リンク帯域幅を超える速度でデータを送信するときに発⽣する
- 送信元が特定されるため対応は⽐較的容易
- Fabric Congestion
- 不均衡なトラフィック分散やフローの偏り によってファブリック内のバッファでパケットロスが発⽣する
- パケットヘッダのハッシュに依存しない分散方式での対策が推奨される
- (スイッチファブリックモジュール内の輻輳もありますが、ここでは機器間のリンクの偏りをFabric Congestionと記載します)
特に問題になりやすく同時に対策が難しいのが、In-castの問題です。
In-castは複数のサーバから特定のサーバへのMany-to-One(多対一)の通信によって競合が発生する問題で、これはデータセンターネットワークの通信の特性上、発生そのものを防ぐことは困難です。
LINEヤフーのデータセンターネットワークでもIn-castは日常的に発生しています。
もう1つの観点に、どのようなフローが輻輳を起こすのかというものがあります。
データセンタートラフィックには二峰性のあるフローが存在します。
- Mice Flow
- 存続期間が短く低レートな通信
- データセンターのフローの⼤部分を占めるが、総トラフィック量の1~2割程度
- 遅延の影響を受けやすく、クエリや制御メッセージで構 成される
- アプリケーションの性能低下を防ぐため、パケットロスを最⼩限またはゼロにする必要がある
- Elephant Flow
- 存続期間が⻑く⾼レートな通信
- データセンターの総トラフィック量のほとんどが少数のElephant Flow
- バックアップや分散処理などの⼤規模なデータ転送が該当し、⾼いスループットを必要とする
データセンターネットワークでの輻輳は、このElephant Flowが占有するリンクやバッファに先述のIn-castの通信が競合することで発生します。
そのため、ネットワーク運用者としてさまざまなアプリケーションのワークロードに対して最大のスループットを公平に提供する必要があります。
つまり輻輳対策にはEnd-to-Endのホストでの輻輳制御アルゴリズムの調整、もしくはそれに連動するスイッチ側でのバッファ制御が必要です。
私たちのワークロードで現在この輻輳を起こす通信の代表的なものにHadoopがあります。Hadoopの通信の特性上、In-castは避けることはできません。
利用可能な帯域を最大限活用して並列処理を行う思想で設計されているためです。
そういった背景から、Hadoopクラスタのネットワークにはバッファサイズの大きい機器を採用した専用ネットワークを通常のクラウド基盤のネットワークとは別に構築してきました。
スイッチ上のバッファでIn-castをある程度吸収することで、ホスト側やスイッチに追加の設定を行わずに運用負荷を下げる目的でのこの戦略はこれまではうまく機能していました。
しかしクラスタが大規模になるにつれてネットワークにも追加の投資が必要になり、他と異なる構成のネットワークのサイズが大きくなる問題が浮上しました。
私たちのモチベーションとして、
- ハードウェアや構成・設定のバリエーションを増やしたくない
- 可能な限り構築・運⽤のコストパフォーマンスの⾼い標準構成を定義したい
- 今後の機種選定やconfiguration, コスト算出の根拠となるデータが欲しい
があります。理想は単一の標準構成とハードウェアであらゆるワークロードを収容し、ジョブ完了時間を短縮することです。
そのために、まずは今運用しているネットワークで何が起きていて、どのような選択肢があるのかを検証を通して可視化することにしました。
検証を通してデータセンターネットワークの輻輳制御について再考することで、これからのデータセンターネットワークをより強固かつコストパフォーマンス高いものにしたいというのがこのプログラムの背景です。
輻輳制御の検証をするにあたって、各手法を整理します。
私たちはスイッチ側のバッファ管理の観点で輻輳制御を下記のように分類しました。
スイッチ内部のバッファ制御の話と外部の制御の話がありますが、
- スイッチのバッファ実装の選択
- スイッチからホストへの輻輳フィードバックの有無
- ホストのTCP輻輳制御アルゴリズムの選択
で分類しています。
1つ目がスイッチのバッファ容量の選択でDeep Buffer のモデルか Shallow Bufferのモデルかです。この選択によって、その後の組み合わせが変わると仮定しました。
2つ目がスイッチのバッファ輻輳をホストに通知するNetwork Assistを行うかどうかです。何もしない場合はそのままホストの輻輳制御に任せる形です。ネットワーク側がアシストする場合は、ECNなどを用いてホストと連携するものです。これは一般的にバックプレッシャと呼ばれる仕組みです。
3つ目がホストのTCP輻輳制御アルゴリズムで、この違いで差が出るかどうかという点です。標準的な輻輳制御アルゴリズムと、データセンター向けに開発されたアルゴリズムで差が出るかどうかを確認することにしました。
Deep Bufferの機器でもECNなどネットワークアシストの機能を設定できますが、一般的にそのような設定をしないためにDeep Bufferを現場では導入していると理解しているためこのような形になっています。なので、Deep Bufferとバッファのチューニングを実施したShallow Bufferの機器でのアプリケーションパフォーマンス(ジョブ完了時間)を比較することにしました。