# Mitigating Scalability Walls of RDMA-based Container Networks > [!abstract] 概要(abstract の日本語訳) > 最先端の技術として、RDMAオフロードされたコンテナネットワーク(RCN)はコンテナ間に高性能なデータ通信を提供できる。しかしこれはRCNの規模に左右されるようであり、データセンターで数百万個のコンテナが同時に稼働すると、性能は急激かつ予期せず低下する。特に我々は、性能問題の大半がRDMA NIC(RNIC)に関連しており、その設計・実装上の欠陥がRCNの「スケーラビリティ壁(scalability wall)」を構成しうることを観測した。しかしこの推測を検証するには、今日のRNICの内部への可視性が限られているという課題がある。このジレンマに対処するため、より実用的な取り組みは、RNICのコンポーネントと機能性の共通の抽象化に基づいて性能問題の最も可能性の高い原因を推論することである。具体的には、組み合わせ的な因果テスト(combinatorial causal testing)を実施し、RNICのアーキテクチャモデルを効率的に推論し、その性能モデルを効果的に近似し、それによってNF(ネットワーク機能)オフロードスケジュールを先回り型(proactive)に最適化する。我々はこの設計をScalaCNと名付けた実用システムに具現化した。本番ワークロードでの評価によれば、ScalaCNが推論した原因の82%を解消した後、エンドツーエンドのネットワーク帯域幅は1.4倍に増加し、パケット転送レイテンシは31%減少する。我々はRNICの性能問題と最も可能性の高い原因を関連ベンダーに報告し、そのすべてが心強いことに確認された。我々は現在、それらを修正するためベンダーと緊密に協働している。 ## 論文情報 - タイトル: Mitigating Scalability Walls of RDMA-based Container Networks - 著者: Wei Liu¹²、Kun Qian²、Zhenhua Li¹、Feng Qian³、[[Tianyin Xu]]⁴、Yunhao Liu¹、Yu Guan²、Shuhong Zhu²、Hongfei Xu²、Lanlan Xi²、Chao Qin²、Ennan Zhai²(¹[[Tsinghua University]] ²Alibaba Cloud ³[[University of Southern California]] ⁴[[University of Illinois Urbana-Champaign]]) - 媒体: 22nd USENIX Symposium on Networked Systems Design and Implementation(NSDI '25, 2025-04-28〜30, Philadelphia, PA, USA) - コード・データ: https://scala-cn.github.io で一部公開 - 本番運用: Alibaba Cloud のコンテナ化 RCN で継続監視(2023-04-15〜2024-04-15)、ScalaCN は段階的に本番導入中 ## 概要 コンテナは軽量・可搬なため、大規模モデル訓練やマイクロサービスなどクラウド上のワークロード実行基盤として広く使われている。今日の主要なコンテナサービス事業者(CSP)は、コンテナ間通信を高速化するために SR-IOV を用いて RDMA NIC(RNIC)へパケット転送や VXLAN カプセル化をオフロードした「RDMAオフロードコンテナネットワーク(RCN)」を採用する。しかし著者らは、Alibaba Cloud の本番 RCN(~8K ホスト・~40K RNIC・平均 0.5M/ピーク~1M コンテナ)の運用で、コンテナ数が増えるとエンドツーエンド性能が急激かつ予期せず劣化する「スケーラビリティ壁」を観測した。継続監視基盤の分析により、この壁は主に 8 つの症状(仮想スイッチ・カーネルドライバ・RNIC ハードウェアの各層で発現)として現れ、いずれも RNIC の設計・実装欠陥に起因することが分かった。RNIC の内部実装はクローズドソースで可視性が乏しいため、著者らは RNIC の共通抽象(RDMA verb と eSwitch のマッチングテーブル)からトポロジ制約に基づき有効な構成空間を絞り込み、局所感応度分析(local sensitivity analysis)と順列除去(permutation removal)で因果関係を推論する「combinatorial causal testing」という greybox 手法を考案した。この手法を実装したシステム ScalaCN は、推論した性能モデルに基づき、フローテーブルのマッチングマスクを階層化(hyper mask + cascading mask)して再編成することで RNIC のクリティカルパスを能動的に最適化する。 ## 問題設定 - **対象**: overlay 方式のコンテナネットワーク(コンテナネットワークには Bridge・Host・Overlay の 3 方式があり、ホスト間接続性と隔離性を両立する overlay 方式が主流。Table 2)。各ホストの OVS(Open vSwitch)が VXLAN カプセル化とポート転送を担い、SR-IOV で仮想化された RNIC がその処理をハードウェアオフロードする。 ![[_attachments/nsdi25-liu-wei/fig01-overlay-container-network.png]] (Figure 1. overlay 方式コンテナネットワークの例。Host A/B のコンテナは VXLAN オーバーレイ上の IP を持ち、物理スイッチ/ルータのアンダーレイを介して通信する。) TCP から VXLAN オフロード・さらに RDMA オフロードへ移行すると帯域幅は 21.17→50.31→~180 Gbps、レイテンシは 87.31→54.51→2.7 µs へ改善する。 ![[_attachments/nsdi25-liu-wei/fig02-perf-comparison-offload.png]] (Figure 2. TCP → VXLAN オフロード → RDMA オフロードの順にハードウェアオフロードを進めると、帯域幅は 21.17→50.31→~180 Gbps、レイテンシは 87.31→54.51→2.7 µs へ改善する。) - **観測されたスケーラビリティ壁**: アクティブコンテナが 0.4M→0.8M に増えると、エンドツーエンド帯域幅が最大 87% 低下し、パケット転送レイテンシが最大 34 倍に増加する。監視期間(2023-04-15〜2024-04-15)中に 14,251 件の性能問題が観測され、うち 94%(13,396 件)が Table 1 の 8 症状(S1-S8)に集約される。 - S1(仮想スイッチ、17.1%): 7K+ フローがオフロードされると RNIC のフローテーブルで lookup miss が続発し、フローが繰り返しソフトウェア処理へ fallback する(最大 18 倍の性能劣化)。 ![[_attachments/nsdi25-liu-wei/fig03-s1-repetitive-reoffload.png]] (Figure 3. S1 の本番トレース。同一設定で訓練する 3 コンテナのうち Container 2/3 が繰り返しフロー再オフロードで最大 18 倍のスループット低下を示す。) - S2/S3(RNIC ドライバ、計 11.1%): ドライバが RNIC のタイムアウト応答を処理できずカーネルが停滞(S2)、またはフロー作成失敗時に null pointer を free してカーネルがクラッシュ(S3)。新しい RNIC(E810・CX-7・BF-3)ほどカーネル障害率(FPY)が高い。 ![[_attachments/nsdi25-liu-wei/fig04-kernel-fpy.png]] (Figure 4. RNIC モデル別のカーネル障害率(FPY、対数軸)。リリース年が新しい RNIC(E810・CX-7・BF-3)ほど FPY が高い。) - S4-S8(RNIC ハードウェア、計 71.8%): フロー削除の遅延(S4)、フローカウンタの非タイムリーな更新による誤った非活性化判定(S5)、~10K フローオフロード時の特定フローの持続的な性能劣化(S6)、VF unbind 時の PCIe リンクダウン(S7)、VXLAN カプセル化コンテキストのバッファ枯渇による無応答(S8)。 ![[_attachments/nsdi25-liu-wei/fig05-s6-flow4-latency.png]] (Figure 5. CX-7 で新規フロー(Flow 4)がオフロードされると、その特定フローだけでなく既存の Flow 1-3 のレイテンシも約 3 倍に悪化する(S6 の例)。) ![[_attachments/nsdi25-liu-wei/fig06-workload-impact-cx6.png]] (Figure 6. CX-6 の RDMA write 性能。オフロードフロー数が 7,200 を超えると帯域幅が 13-37% 低下・レイテンシが 27-34% 増加し、その後ワークロードが下がっても短時間(~6 分)は回復しない。) - **課題**: 今日の商用 RNIC は内部設計がクローズドソースでベンダーへの相談も有効でない(大規模本番環境の再現が困難、実ワークロードの共有も不可)。RNIC の eSwitch は高度に設定可能で、単純に総当たりで組み合わせを探索すると O(k^n) 通り(n はテーブル数、k は平均エントリ数。本番では n, k ともに 100 規模)という組み合わせ爆発に直面する。 ## 提案手法 ScalaCN はオフラインの combinatorial causal testing とランタイムの性能予測・最適化からなる。 ![[_attachments/nsdi25-liu-wei/fig07-scalacn-architecture.png]] (Figure 7. ScalaCN のアーキテクチャ概観。オフラインの combinatorial causal testing で性能モデルを得て、ランタイムでクロスレイヤー監視・予測・フローテーブル再最適化を行う。) - **combinatorial causal testing(§4.1)**: RNIC を RDMA verb・eSwitch のマッチングテーブル・アクションリストという共通コンポーネントに抽象化する。 ![[_attachments/nsdi25-liu-wei/fig08-rnic-abstracted-components.png]] (Figure 8. RCN における RNIC の共通(抽象化された)コンポーネント。コンテナ/VXLAN からのパケットが RNIC で処理され宛先ポートへ送られる。) パケットループや到達不能を生む無効な組み合わせをトポロジ制約でフィルタする。 ![[_attachments/nsdi25-liu-wei/fig09-topological-restrictions.png]] (Figure 9. コンポーネント組み合わせに対するトポロジ制約の例。パケットループや到達不能を生む組み合わせ(Packet B・C)は無効として除外する。) これにより探索空間を O(k^n) から O(k·n^2)(k はサブネット数、n はサブネットあたり平均コンテナ数)へ削減する。有効なアーキテクチャモデルごとにテストトラフィックを流し、症状が出た時点で各次元(マッチングマスク数など)を局所感応度分析で振ってクリティカルパス上の可能性が高いコンポーネントを推定する。 ![[_attachments/nsdi25-liu-wei/fig10-sensitivity-matching-mask.png]] (Figure 10. CX-6 のマッチングマスク数に関する感応度分析。send/write verb の帯域幅・レイテンシはマスク数に強く影響されるが read verb はほぼ影響を受けない。) ![[_attachments/nsdi25-liu-wei/fig11-matching-mask-queue-impact.png]] (Figure 11. CX-7 において、キュー中の飛行中パケットの平均マッチングマスク照会数が増えるほど send/write 性能が劣化する。) さらに順列除去で寄与しないコンポーネントを除去して原因を絞り込む。 - **性能の解釈と予測(§4.2)**: 上記の解析で、フローテーブルのマッチングマスク数が RNIC 性能のボトルネックであることを突き止めた。帯域幅は動径基底関数(radial basis function)、レイテンシは線形関数でフィッティングでき(式1・式2)、goodness of fit 0.92-0.94(Table 3 に CX-4/5/6/7・BF-3・E810 各機種のフィッティングパラメータを掲載)。 ![[_attachments/nsdi25-liu-wei/fig12-fitting-bandwidth-cx6.png]] (Figure 12. CX-6 の帯域幅を式(1)の動径基底関数でフィッティングした結果(goodness of fit 0.93)。) この式で得た予測モデルを用いてランタイムに性能劣化を先回りで予測する。 - **オンデマンド性能最適化(§4.3)**: 性能が経験的閾値(5%)を超えて劣化すると予測されたら、フローテーブルのマッチングマスクを「hyper mask(全ヘッダフィールドを exact match、最優先で照会)」と「cascading mask(新規パターン用、locality score = 過去60秒の一致パケット数×マスク長 で優先度付け)」の 2 階層に再編成する(CPU の多段キャッシュに類似)。 ![[_attachments/nsdi25-liu-wei/fig13-hyper-cascading-mask-opt.png]] (Figure 13. フローエントリ(FE)を hyper matching mask へ活性化することで RNIC 性能を最適化する仕組み。) hyper mask は LRU でエントリを入れ替え、10 分間無通信の cascading mask は削除する。 - **一般化可能性と実装(§4.4-4.5)**: RDMA verb と eSwitch という共通抽象に基づくため新しい RNIC への適用は個別のパラメータフィッティングのみで済む。オンチップ SRAM(QPC 等)の資源競合にも拡張可能だが、これはハードウェアの再設計が必要な限界として扱う。C/C++ 38K 行・Python 13K 行で実装し、LTL(linear temporal logic)ベースの状態検証(付録 A、LamaConv でオートマトン生成)で予測誤りを補正する。 ## 新規性 - **大規模本番 RCN における「スケーラビリティ壁」の初の実証研究**: RNIC 由来の性能問題を 8 症状に体系化し、コンテナ規模と性能劣化の定量的関係(帯域幅 -87%、レイテンシ +34倍)を示した最初の研究(§1 の貢献第1点)。 - **greybox な combinatorial causal testing**: 既存のブラックボックステスト([67])やホワイトボックス解析([54])と異なり、RNIC の共通アーキテクチャに関するドメイン知識でトポロジ制約を課し、組み合わせ爆発(O(k^n))を多項式オーダー(O(k·n^2))へ圧縮する。付録の実験では、この手法がブルートフォース探索より約 60 倍高速(平均 3.6 時間 対 9 日超)に収束することを確認した。 - **hyper/cascading mask による能動的な NF オフロードスケジューリング**: RNIC 内部のマッチングマスク照会というこれまで見過ごされてきたクリティカルパスに着目し、ハードウェアの再設計なしにソフトウェア側だけで緩和する方法を示した。 ## 実験設定 - **マイクロベンチマーク**: 50 ホスト×各 4 RNIC(CX-4/CX-5/CX-6/CX-7/BF-3/E810 のいずれか)の中規模 RCN。実運用アプリケーション(大規模モデル訓練・マイクロサービス)由来のトラフィックを用い、1 日あたり O(4M) フロー・RNIC あたり 150-400 Gbps の集約スループットを生成。RDMA perftest で帯域幅・レイテンシを計測。異なる RNIC モデル間の相互運用は本番でも避けているため測定対象外。 - **本番ワークロード評価**: 実際の RCN 上で ScalaCN 適用前後の帯域幅改善・レイテンシ削減を測定。 ## 実験結果 - **スケーラビリティ**: デフォルトの OVS オフロード戦略では、オフロードフロー数が増えるほど全 RNIC モデルで送信帯域幅が急減する(例: CX-4 は 41% 低下、E810 は絶対値で 70 Gbps 低下)。ScalaCN 適用時は 15K フローでもほぼ低下せず、デフォルト比で平均集約帯域幅を **40.4%** 改善、平均パケット転送レイテンシを **30.5%** 削減した。 ![[_attachments/nsdi25-liu-wei/fig14-bandwidth-with-without-scalacn.png]] (Figure 14. ScalaCN 適用の有無による RNIC 集約帯域幅。デフォルトはオフロードフロー数の増加とともに急減するが、ScalaCN 適用時はほぼ低下しない。) ![[_attachments/nsdi25-liu-wei/fig15-latency-with-without-scalacn.png]] (Figure 15. ScalaCN 適用の有無による RNIC レイテンシ。図14 と同じ傾向で、ScalaCN 適用時にレイテンシの急増を抑制する。) - **フロー起動遅延**: RCN 規模が増すとフロー起動遅延も増加するが、その 70% は OVS 起因で、ScalaCN 由来の追加遅延は 18%(ドライバの 12% に近い水準)にとどまる。 ![[_attachments/nsdi25-liu-wei/fig16-startup-delay-breakdown.png]] (Figure 16. フロー起動遅延の内訳。OVS が全体の約 70% を占め、ScalaCN の追加分は約 18%(ドライバの 12% に近い水準)。) - **予測精度**: ScalaCN の予測バイアスは最大 +2.82%(RNIC のパケットキュー利用率)で、帯域幅 98.9%・レイテンシ 98.5% の高精度を達成。SVM 等の代表的な機械学習ベースライン([44, 69])は最大バイアス -53.98%(帯域幅)/+76.76%(レイテンシ)と精度が低い。 ![[_attachments/nsdi25-liu-wei/fig17-prediction-bias.png]] (Figure 17. RNIC 性能予測のバイアス分布(CDF)。ScalaCN は帯域幅・レイテンシとも最大 2.82% 程度に収まるが、ベースライン手法は最大 76.76%/-63.81% まで乖離する。) - **本番ワークロードでの改善**: 平均で帯域幅 **+17%**・レイテンシ **-15%** を達成し、RNIC モデルごとの最大改善は帯域幅 43.9%(CX-4)〜28.5%(CX-7)、レイテンシ 39.0%(CX-4)〜26.9%(BF-3)。E810(Intel)でも同様の傾向(誌面の都合で図は省略)。早期に登場した CX-4 の改善が最も大きい(マッチングマスク照会の削減効果が、ハードウェアが遅い旧世代ほど顕著なため)。一方、通信量が少ない計算集約タスクでは hyper mask へのフロー追加コストにより <5% の性能低下が <0.03% の RNIC で発生する。 ![[_attachments/nsdi25-liu-wei/fig18-bandwidth-improvement-cdf.png]] (Figure 18. 本番ワークロードにおける RNIC モデル別の帯域幅改善率の CDF。CX-4 が最大 43.93%・平均 21.59% と最も改善幅が大きい。) ![[_attachments/nsdi25-liu-wei/fig19-latency-reduction-cdf.png]] (Figure 19. 本番ワークロードにおける RNIC モデル別のレイテンシ削減率の CDF。CX-4 が最大 39.01%・平均 18.85% と最も改善幅が大きい。) - **オーバーヘッド**: フローオフロード規模に対しほぼ線形に増加し、単一 CPU コアで最大 ~5% に収束。ホストは通常数十コアを持つため実効的には無視できる水準。 ![[_attachments/nsdi25-liu-wei/fig20-cpu-utilization-overhead.png]] (Figure 20. 本番ワークロードにおける ScalaCN の CPU 使用率。ホストフロー数の増加に対しほぼ線形に増え、単一コアで ~5% に収束する。) - **付録の追加結果**: combinatorial causal testing は RNIC モデルあたり平均 3.6 時間で収束し、全構成を総当たりする場合(9 日超)より約 60 倍高速。小規模バーストフローへの負の影響は、hyper mask 導入の有無に関わらず初回パケットの OVS lookup miss 遅延が支配的なため無視できる水準にとどまる。 ## 考察 - **抽象化してからテストする**: ネットワーク機器のクローズドな内部を扱う際は、ハードウェアデータシート・OSS ドライバ・共通 API から一般的な抽象を先に用意すると、性能テストの探索空間を効果的に絞れる。 - **ブラックボックスなハードウェアも実用上は理解可能**: RNIC の内部を完全にプロファイルできなくても、クリティカルパスに着目すれば基本的なアーキテクチャと性能モデルを推定でき、ハードウェアの再設計なしに CSP 側だけで能動的な緩和策(フローオフロードの再編成)が取れる。 - **ベンダーとの協働**: 報告した原因はすべてベンダーに確認され、C1・C2・C3・C5 はドライバ/ファームウェアの修正パッチが既にリリース済み。C4・C6・C7・C8 はソフトウェアとハードウェアの協調チューニングを要するため継続対応中。 ## 強み / 弱点・課題 - **強み**: 大規模本番環境での初の実証研究であり、RNIC 6 機種(NVIDIA CX-4/5/6/7・BlueField-3、Intel E810)横断で有効性を確認。ベンダーからの確認を得て実際に修正パッチへつながった実効性。単一 CPU コア 5% 未満という低オーバーヘッドで本番へ段階導入中。 - **弱点・課題**: 推論した原因のうち 18% は on-chip SRAM(QPC 等)の資源競合などハードウェアの再設計を要する限界に起因し、ScalaCN 単独では解決できない。通信量の少ない計算集約タスクでは hyper mask へのフロー挿入コストにより軽微(<5%)な性能低下が発生しうる(該当は <0.03% の RNIC のみ)。RNIC の共通抽象の特定自体は一度限りの手動作業が必要である。 ## 関連 - 同じ Alibaba Cloud・Tsinghua University 系の RDMA/コンテナネットワーク障害研究: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]](同じ Wei Liu・Zhenhua Li・Ennan Zhai らが著者。SkeletonHunter は overlay/underlay の接続性障害の検知・箇所特定、本論文は RNIC ハードウェアの性能劣化の原因推論と緩和という相補的な着眼点)。 - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[ホスト内ネットワークボトルネック]] / [[マルチテナントRDMA性能分離]]。