> [!abstract] 概要(USENIX abstract の日本語訳) > 高速な RDMA ネットワークは、低レイテンシと CPU オーバーヘッド削減のため、業界で急速に採用が進んでいる。RDMA を本番環境で使用できることを検証するには、システム管理者は、異常な性能挙動(想定外の低スループット、PFC pause frame ストームなど)を引き起こしうるアプリケーションワークロードの集合を理解する必要がある。我々は Collie を設計・実装した。これは、ハードウェア内部設計へのアクセスを必要とせずに、ユーザーが RDMA サブシステムの性能異常を体系的に発見するためのツールである。個々のハードウェアデバイス(NIC、メモリ、PCIe など)を個別にテストする代わりに、Collie はホリスティックであり、アプリケーションワークロードの包括的な探索空間を構築する。次に Collie は焼きなまし法(simulated annealing)を使い、RDMA 関連の性能カウンタおよび診断カウンタを極値領域へ駆動することで、性能異常を引き起こすワークロードを発見する。我々は様々な RDMA NIC・CPU・その他ハードウェアコンポーネントの組み合わせで Collie を評価した。Collie は 15 件の新規性能異常を発見した。そのすべてがハードウェアベンダーに承認されている。そのうち 7 件は我々が報告した後にすでに修正されている。また、RDMA RPC ライブラリおよび RDMA 分散機械学習フレームワークにおける性能異常回避のために Collie を使用した経験も報告する。 ## 論文情報 - タイトル: Collie: Finding Performance Anomalies in RDMA Subsystems - 著者: Xinhao Kong(Duke University・ByteDance Inc.)、Yibo Zhu・Huaping Zhou・Zhuo Jiang・Jianxi Ye・Chuanxiong Guo(いずれも ByteDance Inc.)、Danyang Zhuo(Duke University) - 媒体: 19th USENIX Symposium on Networked Systems Design and Implementation(NSDI '22)、2022年4月4〜6日、Renton, WA, USA - コード: https://github.com/bytedance/Collie ## 概要 Collie は、RDMA サブシステム(RNIC とそれに接続する CPU・PCIe・メモリ・GPU 等のホスト側ハードウェア)が引き起こす性能異常を、ハードウェア内部設計を知らなくても体系的に発見するツールである。verbs API という「狭いウエスト」の programming abstraction を起点にアプリケーションワークロードの探索空間を構築し、ベンダー提供の性能カウンタ・診断カウンタを焼きなまし法で駆動して異常を探索する。8 種類の商用 RDMA サブシステムで評価し、事前に把握していた 3 件の異常をすべて再現したうえで、新たに 15 件を発見した。 ## 問題設定 - 入力: RDMA サブシステム(RNIC・CPU・PCIe・メモリ・GPU の組み合わせからなる 2 台のサーバとコモディティスイッチ)、およびベンダーが提供する性能カウンタ・診断カウンタへのアクセス。 - 出力: 性能異常(PFC pause frame の発生、または RNIC 仕様上のビット/秒・パケット/秒上限に対し実効スループットが 20% 以上低い状態)を引き起こすアプリケーションワークロードの集合と、その必要条件(minimal feature set, MFS)。 - 前提: RNIC やその他ハードウェアコンポーネントはブラックボックスであり、内部設計にはアクセスできない。ネットワーク自体は単一スイッチ・パケットロスなしという単純化した環境を仮定し、ホスト側で発生するワークロード起因の異常のみを対象とする。 ## 提案手法 - **異常の定義**: 論文は性能異常を精密に定義できる 2 種類に限定する。(1) ネットワークが輻輳していないのに PFC pause frame が発生する、(2) スループットが RNIC 仕様のビット/秒・パケット/秒いずれの上限でも律速されていない(実測が上限より 20% 以上低い)。レイテンシは、ゼロ負荷時の仕様値以外に正しさを定義する基準がないため異常定義には用いない。 - **アーキテクチャ**: Collie は 3 コンポーネントから構成される(Figure 2)。(1) workload engine: RDMA トラフィックを実際にセットアップして送受信する。(2) anomaly monitor: 性能異常を検知し MFS を計算する。(3) workload generator: 焼きなまし法(Simulated Annealing)に基づき、収集したカウンタと現在の探索空間から次に試すワークロードパターンを決定する。 **Figure 2: Collie のシステム概要** ![[_attachments/nsdi22-paper-kong/fig02-system-overview.png]] (Figure 2. Workload Generator が Simulated Annealing でワークロードパターンを決め、Workload Engine が RDMA サブシステムにトラフィックをセットアップし、Anomaly Monitor がスループット・PFC pause frame から異常を検知して MFS を生成し、その結果が Workload Generator へフィードバックされる。Source: 論文 Figure 2。) - **探索空間の構築(developer's perspective)**: 図1に示すように RDMA サブシステムには TX/RX engine・MMU・NIC cache・PCIe・複数の CPU ソケット・GPU など多数の潜在的ボトルネック(赤丸で示される 16 箇所)が存在するが、Collie はこれらハードウェア内部を直接モデル化する代わりに、標準 verbs ライブラリが公開する 4 つの探索次元を用いてワークロードを構成する。 **Figure 1: RDMA サブシステムの構成例** ![[_attachments/nsdi22-paper-kong/fig01-rdma-subsystem.png]] (Figure 1. RNIC 内部(TX/RX engine・MMU・NIC cache・TX/RX buffer)と、それが接続するサーバ側ハードウェア(2 ソケット CPU・PCIe スイッチ・GPU・NVSwitch)の構成例。赤丸(1〜16)は性能ボトルネックになりうる箇所を示す。Source: 論文 Figure 1。) 4 つの探索次元は verbs API の抽象(Figure 3: Memory Region・Queue Pair・Work Queue Element・Completion Queue)から導出される。 - **Dimension 1(ホストトポロジ)**: トラフィックがサーバ内のどこ(NUMA-affinitive DRAM か、PCIe と SMP interconnect を跨ぐ GPU メモリか)から/へ流れるかを決める。 - **Dimension 2(メモリ割り当て設定)**: 登録する memory region (MR) の数とサイズ。RNIC の MMU はアドレス変換テーブルのキャッシュ容量が有限であり、MR が多い/大きいとキャッシュミスや Intel DDIO 経由の CPU 最終レベルキャッシュミスを誘発しうる。MR 数の上限は 200K、サイズは物理サーバに pin 可能なメモリ総量で制約する。 - **Dimension 3(トランスポート設定)**: QP タイプ(RC/UC/UD)、QP 数、opcode(SEND/RECV, WRITE, READ)、SG list と WQE の使い方の組み合わせ。QP 数の上限は 20K に設定し、SG list と WQE は Σmᵢ = k(k はメッセージ数、n は WQE 数、mᵢ は i 番目 WQE の SG 要素数)という式でパラメータ化する。 - **Dimension 4(メッセージパターン)**: n 要素のリクエストベクトルとして表現し、i 番目のリクエストが i+1 番目以降 n 番目までのリクエストに影響しうると仮定する(それ以降には影響しないとみなす)。n は RNIC の Processing Unit 数とパイプラインステージ数の積として設定し、リクエストサイズは MTU とバースト長に基づき離散化する。メッセージの inter-arrival time は探索空間を大きく広げるため今回は考慮しない。 **Figure 3: RDMA プログラミング抽象** ![[_attachments/nsdi22-paper-kong/fig03-programming-abstractions.png]] (Figure 3. `ibv_reg_mr`(Dimension 1・2)、`ibv_create_qp`/`ibv_modify_qp`(Dimension 3)、`ibv_post_send`/`ibv_post_recv`(Dimension 4)、`ibv_create_cq`(Dimension 3)、`ibv_poll_cq`(Dimension 4)という verbs API 呼び出しと、Memory Region・Queue Pair・Work Queue Element・Completion Queue という抽象の対応関係。Source: 論文 Figure 3。) - **探索アルゴリズム(Algorithm 1)**: 焼きなまし法(Simulated Annealing, SA)をベースに、性能異常の集合 S(各要素は MFS)を維持する。ランダムな初期ワークロードから開始し、各反復で 4 探索次元のいずれかを変異させて新ワークロード Pnew を生成、既存の MFS に合致する場合はスキップする。性能カウンタは値を B−A/A(低い方向へ駆動)、診断カウンタは A−B/B(高い方向へ駆動)としてエネルギー差 ΔE を計算し、ΔE < 0 なら遷移、そうでなければ確率 exp(−ΔE/T) で遷移する。新たな異常を検知したら MFS を構築して S に追加し、ランダムな別の点から探索を再開する。標準 SA と異なり、大域最適解の発見自体は目的とせず、緩めた温度・減衰係数を用いて局所解からの脱出を優先する。 - **Minimal Feature Set (MFS) アルゴリズム**: 発見した異常workloadが持つ複数の特徴のうち、実際にどの特徴が異常の再現に必要かをヒューリスティックに判定する。探索次元は 4 種類・少数の要因しかないため、各次元について代替値でテストし直すだけで済む(例: UD で異常が起きたら RC・UC でも起きるか試し、起きなければ UD が MFS に含まれる)。連続的な次元(QP 数など)は手動で離散区間に分割してテストする。MFS は探索中の重複テスト回避(効率化)と、探索後の開発者向けの回避策提示(どの条件を崩せば異常を避けられるか)の 2 つの役割を持つ。 - **異常検知条件**: PFC pause の閾値は pause duration ratio 0.1% を下限とする(接続確立直後などに生じる少数の pause frame をノイズとして許容するが 0 は許容しない)。スループット閾値は RNIC 仕様の bits/秒・packets/秒いずれかの上限に対し 20% 低い場合とする。カウンタは 1 秒ごとに提供され、Collie は 1 反復あたり 4 回取得して平均する。 - **実装**: workload generator と anomaly monitor は Python(約 2100 行)、workload engine は C/C++(約 2000 行)で実装。verbs API と rdma-core-34.0 を使用し、Mellanox RNIC は mlx5 ドライバ(OFED 5.2-1.0.4.0)、Broadcom RNIC は bnxt ドライバ(1.10.1.216.2.89.0)を用いる。接続確立は TCP のアウトオブバンド通信で行う。 ## 新規性 - 既存のテスト手法は (1) Perftest・OSU micro-benchmarks のような単純なベンチマークトラフィック、(2) 代表的な実アプリケーションの実行、の 2 種類に限られ、いずれも既知・単純なワークロードしか試さないため、実アプリケーションが引き起こす複雑な異常を体系的には発見できない。Collie は開発者視点(verbs 抽象)からブラックボックスなハードウェアに対する包括的な探索空間を構築し、性能・診断カウンタという「非独占的な」ハードウェア信号を探索の指針に用いる点で新規性がある。 - 白箱(white-box)ファジングのようにソースコードのカバレッジを使う代わりに、ハードウェアカウンタをカバレッジ相当のフィードバック信号として用いる点が、ソフトウェアのグレイボックスファジングとの主な違いである(§9 Related Work)。 - 論文執筆時点で著者らの知る限り、Collie は RDMA サブシステム全体の性能異常を体系的に発見する初のツールである。 ## 実験設定 - **評価対象**: 8 種類の RDMA サブシステム(Table 1)。RNIC は Mellanox CX-5 DX(25/100 Gbps)、CX-6 DX(100/200 Gbps)、CX-6 VPI(200 Gbps)、Broadcom P2100G(100 Gbps)を含む。CPU は Intel Xeon 3 種、AMD EPYC 1 種。GPU 搭載構成(V100、A100)を含む。CPU の具体的な型番は秘匿のため番号で表記される。 **Table 1: テストベッド RDMA サブシステム構成** | Type | RNIC | Speed | CPU | PCIe | NPS | Memory | GPU | BIOS | Kernel | |---|---|---|---|---|---|---|---|---|---| | A | CX-5 DX | 25 Gbps | Intel Xeon CPU 1 | 3.0 x 16 | 1 | 128 GB | - | INSYDE | 4.19 | | B | CX-5 DX | 100 Gbps | Intel Xeon CPU 2 | 3.0 x 16 | 1 | 768 GB | - | AMI | 4.14 | | C | CX-5 DX | 100 Gbps | Intel Xeon CPU 2 | 3.0 x 16 | 1 | 384 GB | V100 | AMI | 5.4 | | D | CX-6 DX | 100 Gbps | Intel Xeon CPU 2 | 3.0 x 16 | 1 | 768 GB | - | AMI | 4.14 | | E | CX-6 DX | 200 Gbps | AMD EPYC CPU 1 | 4.0 x 16 | 1 | 2 TB | A100 | AMI | 5.4 | | F | CX-6 DX | 200 Gbps | Intel Xeon CPU 3 | 4.0 x 16 | 1 | 2 TB | A100 | AMI | 5.4 | | G | CX-6 VPI | 200 Gbps | AMD EPYC CPU 1 | 4.0 x 16 | 2 | 2 TB | - | AMI | 5.4 | | H | P2100G | 100 Gbps | Intel Xeon CPU 2 | 3.0 x 16 | 1 | 384 GB | - | AMI | 5.4 | (Table 1. CPU の具体的な型番は秘匿のため連番で表記。Source: 論文 Table 1。) - **比較対象**: (1) ランダム入力生成(探索空間内でランダムにワークロードを試す)、(2) Bayesian Optimization(BO、診断カウンタ値を最適化対象とする)。BO と Collie はいずれも公平のため MFS で強化して比較する。 - **評価指標**: 発見した異常数、各異常を発見するまでの累積実行時間(分)。診断カウンタの値は観測最大値で正規化して比較。 ## 実験結果 - Collie は 8 種類のサブシステムで、事前に把握していた既知異常 3 件をすべて再現し、新たに 15 件、合計 18 件の性能異常を発見した(Table 2 は subsystem F・H の 18 件を掲載。他サブシステムの異常は F の部分集合)。全件をベンダーに報告して承認され、7 件はファームウェア更新または詳細な設定変更で修正済み。既存手法(Perftest による手動チューニング)で再現できたのは #3・#8・#13・#15 の 4 件のみ。 **Table 2: subsystem F・H で発見された性能異常(発生条件)** | # | RNIC | 方向 | Transport | MTU | WQE | SGE | WQ depth | メッセージパターン | QP数 | 症状 | |---|---|---|---|---|---|---|---|---|---|---| | 1 | CX-6 | - | UD SEND | - | ≥64 | - | ≥256 | - | - | pause frame | | 2 | CX-6 | - | UD SEND | - | ≤8 | - | ≥1024 | ≤1KB | ≥≈16 | low throughput | | 3 | CX-6 | - | RC READ | 1K | - | - | - | ≥16KB | - | pause frame | | 4 | CX-6 | Bi- | RC READ | - | ≥32 | ≥4 | - | - | ≥≈160 | pause frame | | 5 | CX-6 | - | RC SEND | 1K | ≥64 | - | ≥1024 | ≥2KB かつ ≤8KB | - | pause frame | | 6 | CX-6 | - | RC SEND | 1K | ≤16 | ≥2 | ≥1024 | ≤1KB | ≥≈32 | low throughput | | 7 | CX-6 | - | RC WRITE | - | No | - | - | ≤1KB かつ ≥≈12K MRs | - | low throughput | | 8 | CX-6 | - | RC WRITE | - | No | - | ≤16 | ≤1KB | ≥≈500 | low throughput | | 9 | CX-6 | Bi- | - | - | - | ≥3 | - | mix of ≤1KB & ≥64KB | - | pause frame | | 10 | CX-6 | Bi- | RC WRITE | - | ≥64 | - | - | mix of ≤1KB & ≥64KB | ≥≈320 | pause frame | | 11 | CX-6 | 双方向クロスソケットトラフィック(特定 AMD サーバ) | | | | | | | | pause frame | | 12 | CX-6 | 特定の GPU-Direct RDMA トラフィック(特定サーバ) | | | | | | | | pause frame | | 13 | CX-6 | loop traffic と受信トラフィックの共存 | | | | | | | | pause frame | | 14 | P2100 | Bi- | RC | 4K | - | ≥4 | - | - | ≥≈1300 | low throughput | | 15 | P2100 | - | UD SEND | - | - | - | ≥64 | - | ≥≈32 | pause frame | | 16 | P2100 | - | RC READ | 1K | ≥8 | - | - | - | ≥≈500 | pause frame | | 17 | P2100 | - | RC SEND | - | ≤16 | - | ≥128 | ≤1KB | ≥≈64 | pause frame | | 18 | P2100 | Bi- | RC | 1K | ≥32 | - | - | ≤64KB | ≥≈30 | pause frame | (Table 2. 緑色でハイライトされた異常(#2, #4-7, #9-12, #14, #16-18)が新規発見。残りは Collie 構築前から既知だった異常。Source: 論文 Table 2。) - **代表的な異常の例**: Anomaly #4(双方向 RC READ、大きな WQE バッチサイズ、長い SG list、少数コネクションで PFC pause frame を誘発)は Perftest では WQE・SG list のバッチ戦略を柔軟に設定できないため発見不可能だった。Anomaly #10(双方向 RC WRITE、大きな WQE バッチサイズ、mixサイズのメッセージパターン、少数コネクションで PFC pause frame)は、本番 RDMA RPC ライブラリのタイムアウト値変更(バッチサイズ拡大)により偶然条件が揃って再現された。 - **探索効率の比較(Figure 4)**: ランダム入力は単純な条件で発見できる 7 件までしか到達できず、BO も限られた時間内で 8 件までしか発見できなかった(10 時間実行)。Collie はこれらを上回るペースで異常を発見し続けた。 **Figure 4: 異常発見までの平均所要時間(ランダム・BO・Collie 比較)** ![[_attachments/nsdi22-paper-kong/fig04-search-time-vs-random-bo.png]] (Figure 4. ランダム入力生成は 7 件、BO は 8 件までしか発見できなかったのに対し、Collie は 13 件まで発見し続けた。エラーバーは標準偏差。Source: 論文 Figure 4。) - **診断カウンタと MFS の寄与(Figure 5)**: 性能カウンタのみを使う Collie (Perf) はすでに 13 件中 11 件(既知 3 件を含む)を発見できた。診断カウンタを併用する Collie (Diag) はさらに高速化し、性能カウンタでは変化が見えない Anomaly #7・#8 のような異常も、RNIC 内部キャッシュミスの増加という診断カウンタの変化から捕捉できた。MFS を併用すると、MFS なしの SA(Diag) と比べておよそ半分の時間で全異常を発見できた。 **Figure 5: 診断カウンタ有無・MFS 有無別の異常発見所要時間** ![[_attachments/nsdi22-paper-kong/fig05-search-time-diag-vs-perf-mfs.png]] (Figure 5. Collie(Diag)が最も高速に多くの異常を発見し、MFS なし(w/o MFS)構成はいずれも劣る。Source: 論文 Figure 5。) - **診断カウンタの推移例(Figure 6)**: Receive WQE Cache Miss カウンタを例に、ランダム入力生成ではカウンタ値がほとんど上昇しないのに対し、Collie は診断カウンタ値を高い領域へ駆動しつつ、既発見の異常領域への重複テストを MFS で回避することで効率的に多くの異常を発見した。 **Figure 6: 診断カウンタ値(Receive WQE Cache Miss)の探索時間推移** ![[_attachments/nsdi22-paper-kong/fig06-diagnostic-counter-trace.png]] (Figure 6. 正規化した Receive WQE Cache Miss カウンタの推移。赤い×はCollie、赤い三角はランダム入力生成、赤い四角はMFSなしCollieが発見した異常を示す。Collie(青線)は新たな異常を発見した直後の数分間、MFS抽出のためカウンタ値がフラットになる。Source: 論文 Figure 6。) - **アプリケーション設計への適用(§7.3)**: (1) 自社開発の RDMA RPC ライブラリの設計・実装で、Collie は READ・大きな WQE バッチサイズ・長い SG list の組み合わせが Anomaly #4 の制限探索空間に該当すること、SEND/RECV で大きな receive queue を確保すると Anomaly #5 を誘発しうることを示し、開発者は WRITE によるバッチ転送と receive queue depth の慎重な設定で回避した。(2) BytePS ベースの分散機械学習(DML)アプリケーションが新サブシステム E で Anomaly #9 に遭遇し、複数ベンダーと数週間協働しても原因が特定できなかった際、Collie の MFS(長い SG list によるテンソル+メタデータ送信、短長混在メッセージパターン)と突き合わせることで該当条件を特定し、ベンダー修正を待たずに開発者が回避した。 ## 考察 - **ホリスティックな性能テスト/チューニングの重要性**: 発見された異常の根本原因は RNIC 内部・PCIe コントローラ・ホストトポロジ(クロスソケット通信)にまたがっており、RDMA サブシステム全体を対象にした統合テストの必要性を裏付ける。MTU・PCIe・NUMA・IOMMU 等の設定は、Anomaly #14 と #6 の比較からも分かるように、あらゆるサブシステムに通用する最適値は存在しない。 - **opaque な資源制約**: 既存の RDMA 仮想化・性能分離研究は QP・MR・CQ・pinned memory・帯域といった可視な資源を対象とするが、RNIC の限られたキャッシュ(QPC・receive WQE 用)という不可視な資源が性能分離を損なう可能性を、Anomaly #1・#3・#4・#5 が示す。 - **End-to-end フロー制御の欠如**: 本番 Ethernet ベース RDMA(RoCEv2)には TCP のスライディングウィンドウに相当する end-to-end フロー制御が存在せず、hop-by-hop の PFC のみに依存する。Anomaly #9・#12 のようにホスト側の受信制限が RNIC の outbound rate を低下させるケースは、PFC がこの欠如を補う唯一の機構であることの限界を示す。IRN(Mittal+ 2018)がネットワーク内挙動を扱うのに対し、Collie はホスト側でも PFC pause frame が発生しうることを追加で示した。 - 論文自身が明記する限界として、Collie は根本原因(root cause)そのものを特定する設計ではない(RNIC の black-box な性質による)。複数の MFS が実は同一のハードウェアバグに起因する可能性があるが、探索効率化と開発者へのガイダンスという MFS の目的には支障がないとしている。 ## 強み / 弱点・課題 - **強み**: - ハードウェア内部知識やベンダー固有の proprietary な情報に依存せず、標準 verbs API という「狭いウエスト」の抽象のみで探索空間を構築するため、任意の RDMA サブシステム(RoCEv2 だけでなく InfiniBand を含む可能性)に一般化しやすい設計思想を持つ(§8 Generality of Collie)。 - 性能カウンタと診断カウンタという商用 RNIC が既に提供する情報のみをフィードバック信号として使うため、追加のハードウェア計装が不要。 - MFS アルゴリズムにより、探索効率化と開発者へのアクチュエーション可能な回避策提示という 2 つの目的を同時に達成する。 - 実運用(RDMA RPC ライブラリ・BytePS ベース DML アプリケーション)での有効性を、ベンダー承認・修正実績を伴って実証している。 - **弱点・課題(論文自身が §8 Discussion and Future Work で述べる限界)**: - 探索空間は 2 台の RNIC・パケットロスなしという単純化されたネットワーク環境を前提とし、制御パス挙動やリクエスト間の inter-arrival time は現時点で考慮していない。 - 探索空間の全体サイズはおよそ 10^36 に達し、網羅的な探索は不可能。焼きなまし法以外の探索アルゴリズム(強化学習等)による改善の余地があると著者らも認めている。 - 異常の根本原因の完全な特定はできない(ブラックボックスなハードウェアという制約による)。