> [!abstract] 概要(abstract の日本語訳) > パブリッククラウドでディスアグリゲートされたストレージが広く採用されているため、クラウドストレージサービスで高性能と高信頼性を実現する鍵はネットワーキングである。Azure では、Remote Direct Memory Access（RDMA）をトランスポートとして選び、その利点を完全に引き出すため、ストレージのフロントエンドトラフィック（計算仮想マシンとストレージクラスタの間）とバックエンドトラフィック（ストレージクラスタ内）の双方で有効にすることを目指した。計算クラスタとストレージクラスタは Azure リージョン内の異なるデータセンターに配置されることがあるため、リージョン規模で RDMA をサポートする必要がある。 > > 本研究は、Azure のストレージワークロードを支えるためにリージョン内 RDMA を展開した経験を示す。インフラストラクチャの高い複雑性と異種性は、異なる種類の RDMA ネットワークインターフェイスカード間の相互運用性問題など、新しい課題をもたらした。著者らはこれらの課題に対処するため、ネットワークインフラストラクチャへ複数の変更を加えた。現在、Azure のトラフィックの約 70% は RDMA であり、リージョン内 RDMA はすべての Azure パブリックリージョンでサポートされている。RDMA は、顕著なディスク I/O 性能改善と CPU コア削減の達成に役立った。 ## 論文情報 - タイトル: Empowering Azure Storage with RDMA - 著者: [[Wei Bai]] ほか、[[Microsoft]] - 媒体: 20th USENIX Symposium on Networked Systems Design and Implementation（NSDI 2023） - 発表: 2023年4月、Boston, MA, USA - PDF: `.raw/papers/nsdi23-bai.pdf` - URL: https://www.usenix.org/conference/nsdi23/presentation/bai ## 概要 本論文は、[[Azure Storage]] のストレージ通信を TCP から [[RDMA]] へ大規模移行した経験論文である。既存ハードウェアを置き換えず、RoCEv2、PFC、DCQCN、[[SONiC]]、独自 RDMA ストレージプロトコル、[[RDMA Estats]] を組み合わせ、単一クラスタではなく Azure リージョン内の複数データセンターをまたぐ RDMA を本番展開した。2023年2月時点で Azure パブリックリージョンの約70%のトラフィックが RDMA となり、全 Azure パブリックリージョンでリージョン内 RDMA をサポートした。 ## 問題設定 Azure は計算資源とストレージ資源を分離し、仮想マシンの仮想ハードディスク（VHD）はストレージクラスタに置く。Azure Storage はフロントエンド、パーティション層、ストリーム層の 3 層で構成され、書き込みは複数の Extent Node へのレプリケーションを伴う。NVMe SSD の性能向上により、ネットワークと TCP/IP スタックの処理遅延・単一コアスループット・CPU 予約がストレージ性能とコストのボトルネックになった。 RDMA 導入の難しさは、バックエンド通信だけでなく、計算クラスタとストレージクラスタ間のフロントエンド通信まで対象にした点にある。容量都合で対応する計算・ストレージクラスタが同一データセンターに配置されないことがあり、リージョン内で数マイクロ秒から最大 2 ミリ秒までの RTT 差を持つネットワークで RDMA を成立させる必要があった。 ## 提案手法 - **ストレージバックエンド: sU-RDMA**: ストレージサーバ間通信向けのユーザ空間 RDMA ライブラリ。ソケット風のバイトストリーム API を上位層へ提供し、事前登録済み共有バッファプール、受信側主導のクレジットベースフロー制御、小・中・大メッセージ別の Send/Write/Read 転送モード、TCP と RDMA の段階的切り替えを実装する。 - **ストレージフロントエンド: sK-RDMA**: 計算サーバのホストドメインで動くディスクドライバが使うカーネル空間 RDMA プロトコル。SMB Direct を拡張し、Fast Memory Registration（FMR）と RDMA Read/Write、Send With Invalidate を用いてディスク I/O を転送する。sU-RDMA と同様にクレジットベースフロー制御と TCP/RDMA 動的切り替えを持つ。 - **データ破損検知**: sK-RDMA と sU-RDMA は、ソフトウェア・ハードウェア由来のサイレントデータ破損を検知するため、すべてのアプリケーションデータに CRC を実装する。 - **RDMA Estats**: RDMA operation ごとに WQE 投稿、NIC 内部、CQE 生成、CQE ポーリングなどのタイムスタンプを収集し、送信側・受信側・ネットワークのどこがボトルネックかを切り分ける。高レイテンシイベント時には NIC/QP state dump も収集する。 - **SONiC によるスイッチ管理**: 異種スイッチ ASIC と複数ベンダ OS の運用負荷を下げるため、SAI に基づくクロスプラットフォームなスイッチ OS [[SONiC]] を開発・展開した。ECN marking、PFC、PFC watchdog、共有バッファモデルを RDMA 展開に必要な機能として提供する。 - **PFC と DCQCN**: パケット損失を防ぐ PFC と、送信レートを制御する DCQCN を併用する。長距離リンクでは PFC headroom pool を共有・オーバーサブスクライブし、異世代 NIC の DCQCN 実装差は Gen2/Gen3 側を Gen1 に近づけるファームウェア変更で緩和した。 ## 新規性 本論文の中心的な新規性は、RDMA を「単一クラスタ内の高速通信」から「リージョン内の複数データセンターをまたぐクラウドストレージの標準トランスポート」へ拡張した点にある。先行する Azure/Bing や Alibaba の RDMA 展開はクラスタ内・バックエンド寄りだったが、本論文はフロントエンドとバックエンドの双方を対象にし、異世代 NIC、異種スイッチ、長距離リンク、サービス更新、フェイルオーバー、診断テレメトリまで含めた運用設計を報告する。 ## 実験設定 - 展開履歴: 2018年にストレージバックエンド RDMA、2019年に顧客向けフロントエンド RDMA、2020年に最初の Azure リージョンでリージョン内 RDMA を有効化した。 - トラフィック測定: 2023年1月18日から2月16日まで、全 Azure パブリックリージョンの全 ToR スイッチのサーバ向けポートカウンタからトラフィック統計を収集した（図1）。 - バックエンド評価: 2018年のテストクラスタで、高 TPS ストレージワークロードを TCP/RDMA 間で切り替え、ストレージサーバ CPU 使用量と Azure Storage Network Protocol 層のメッセージ完了時間を測った（図7・図8）。 - フロントエンド評価: 2018年のテストクラスタで DiskSpd による 8KB read/write ワークロードを生成し、ホストドメイン CPU 使用量を測った（図9）。 - 常時監視評価: 各リージョンに配置したテスト VM が定期的にディスク read/write を生成するストレージ監視サービスで、2022年2月22日から2023年2月22日まで SSD アクセスレイテンシを収集した（図10）。 - 輻輳制御評価: テストクラスタで DCQCN とスイッチバッファを調整し、99パーセンタイルのメッセージ完了時間を指標にした（図11）。付録Bでは 80km ケーブルでリージョン相当の RTT 差を作り、DCQCN の RTT fairness を評価した。 ## 実験結果 - 図1では、2023年初頭の Azure パブリックリージョンのトラフィックの約70%が RDMA だった。 - ストレージバックエンドでは、TCP と比べて RDMA が CPU 使用量を削減し、ネットワークデータ転送を明確に高速化した（図7・図8）。 - ストレージフロントエンドでは、TCP と比べて RDMA がホストドメイン CPU 使用量を最大 34.5% 削減した（図9）。 - SSD アクセスレイテンシでは、RDMA がすべての I/O サイズで TCP より良い平均アクセスレイテンシを示し、1MB I/O が最も恩恵を受けた。1MB read は 23.8%、1MB write は 15.6% のレイテンシ削減だった（図10）。 - 輻輳制御では、PFC のみを調整した後に DCQCN を既定設定で入れるとテイルレイテンシが悪化した。ECN marking パラメータを調整した最適化 DCQCN は PFC のみより良い結果になった（図11）。 - 付録Bでは、約 2µs RTT のフローと約 1.77ms RTT のフローが、40Gbps NIC でほぼ同等の goodput を得た。著者らは、DCQCN はレートベースで RTT に依存しないため RTT unfairness を受けないと結論づける。 ## 運用で発見された問題 - **FMR hidden fence**: sK-RDMA で FMR/Send ペアが送信キューに並ぶと、NIC が実装簡略化のため FMR を先行リクエスト完了後に処理し、Send 間に隠れた fence が生じた。異なるデータセンター間では 1 RTT に 1 Send しか飛ばず、巨大なネットワークパイプを埋められなかった。[[RDMA Estats]] の `T5 - T1` とデータセンター間 RTT の強い相関が診断に使われた。 - **PFC と MACsec**: MACsec 標準が PFC frame の暗号化扱いを規定していなかったため、ベンダ間で暗号化 PFC frame の解釈が一致せず、長距離リンクで高い packet corruption rate として報告された。 - **Congestion leaking**: Gen2 NIC の相互運用機能で、1 NIC から出る全フローが最も遅いフローの送信率に近づく現象が見つかり、NIC firmware の head-of-line blocking が原因と特定された。 - **Loopback RDMA による slow receiver**: 同一サーバ内の複数 RDMA アプリケーションインスタンス間通信と外部通信が NIC 上で共存し、PCIe lane で 2:1 の輻輳を作った。ループバックトラフィックで RDMA を無効化すると PFC frame 送信が止まった。 ## 考察 著者らの教訓は、RDMA ではフェイルオーバーが高価であり、TCP へ戻すには余分な CPU コアが必要になるため、大規模フェイルオーバーは Azure では重大インシデントとして扱われるという点である。さらに、ホスト内ネットワークと物理ネットワークは分離されたものではなく、PCIe、GPU、DPU、NVLink、NIC が絡む「収束したネットワーク」として管理されるべきだと論じる。スイッチバッファは、低レイテンシ輻輳制御があっても RDMA 性能問題と強く相関し、バースト吸収の第一防衛線として重要性が増す。 ## 強み / 弱点・課題 - 強み: Azure パブリックリージョン全体にまたがる本番展開経験を扱い、プロトコル設計、テレメトリ、スイッチ OS、輻輳制御、保守運用、NIC/スイッチ問題の実例を一体として記録している。 - 強み: 単なる性能改善ではなく、異種ハードウェアと漸進的展開を前提にした相互運用性・診断性・保守性の設計を示す。 - 弱点: ほとんどの定量評価は 2018 年のテストクラスタや正規化された値で示されており、本番全体の絶対性能・コスト削減量は限定的にしか公開されない。 - 弱点: ファーストパーティの信頼環境を前提にしており、マルチテナントのセキュリティ分離や顧客管理 RDMA への一般化は主対象ではない。 - 未解決: RDMA NIC・スイッチのマイクロ挙動を体系的に仕様化・テストする方法、ホスト内外をまたぐ収束ネットワークの運用モデル、プログラマブルなスイッチバッファ管理が将来課題として残る。 ## 関連 - エンティティ: [[Azure Storage]] / [[RDMA Estats]] / [[SONiC]] / [[Microsoft]] / [[Wei Bai]] - 概念: [[RDMA]] / [[RDMAネットワーク監視]] / [[分散ストレージ]] / [[オープンネットワーキング]] - 関連 MOC: [[Network - MOC]] / [[Systems for ML - MOC]]