# Deploying User-space TCP at Cloud Scale with LUNA > [!abstract] 概要 > TCPは現代の大規模データセンターで主要なトランスポートプロトコルである。しかし、100Gbps級のネットワークやIntel DPDKのようなハードウェア・ソフトウェアの進歩によって性能要求が高まり、カーネルTCPスタックは好ましい選択肢ではなくなっている。 > これまでに、TCP互換のプログラミングモデルを保ちながら大幅な性能向上を実現するユーザーレベルTCPスタックが複数提案されてきたが、大規模な実運用では十分に機能しない場合がある。 > 本論文は、Alibaba Cloudに広く展開されたユーザーレベルTCPスタックLUNAを提示する。 > LUNAの設計では、スレッドモデル、メモリモデル、トラフィックモデルにおける三つのトレードオフを重視する。 > マイクロベンチマークと本番システムから収集した性能統計により、LUNAがカーネルおよび他のユーザーレベル実装に対してスループットを最大3.5倍にし、レイテンシを最大53%削減すると報告する。 > (Source: [[.raw/papers/atc23-zhu-lingjun.pdf]], PDF p.2／印刷 p.673) ## 論文情報 - 著者: [[Lingjun Zhu]]、[[Yifan Shen]]、[[Erci Xu]]、[[Bo Shi]]、[[Ting Fu]]、[[Shu Ma]]、[[Shuguang Chen]]、[[Zhongyu Wang]]、[[Haonan Wu]]、[[Xingyu Liao]]、[[Zhendan Yang]]、[[Zhongqing Chen]]、[[Wei Lin]]、[[Yijun Hou]]、[[Rong Liu]]、[[Chao Shi]]、[[Jiaji Zhu]]、[[Jiesheng Wu]]（[[Alibaba Group]]） - 媒体: 2023 USENIX Annual Technical Conference (USENIX ATC 23) - 開催: 2023-07-10〜2023-07-12、Boston, MA - 掲載ページ: 673〜687 - 備考: Lingjun ZhuとYifan Shenはequal contribution、Erci Xuはcorresponding authorである。 - 公式ページ: https://www.usenix.org/conference/atc23/presentation/zhu-lingjun ## 概要 [[Alibaba Cloud]]はコンピュートとストレージを分離し、フロントエンド計算サーバーとバックエンドストレージを独立に拡張している。NVMe SSDと100〜200Gbps級ネットワークの進歩に対し、カーネルTCPの高いテールレイテンシと低い単一コアスループットが問題になった。 LUNAはLibOS方式でアプリケーションとTCP/IP処理を同じプロセス・スレッドに配置し、DPDKでNICキューを直接処理する。スレッド、メモリ、トラフィックの設計を組み合わせ、性能、既存アプリケーションとの互換性、カーネルTCPとの共存を調整する。(Source: [[.raw/papers/atc23-zhu-lingjun.pdf]], PDF p.2〜6) ## 問題設定 - 対象: Alibaba CloudのEBS、Object Storage Service、Cloud Tablestore Serviceのフロントエンドネットワーク。 - 要求: 100〜200Gbps級リンク、低レイテンシのストレージデバイス、異なるデータセンター・可用性ゾーン間の通信、旧世代ホストとカーネルTCP利用アプリケーションとの互換性。 - カーネルTCPの測定: `knb`で4KBの要求と応答を往復させると、基本RPCレイテンシの中央値は50マイクロ秒、単一コアの最大スループットは600Mbpsだった。EBS高性能クラスのエンドツーエンド要求は100マイクロ秒である。 - 既存ユーザーレベルTCPの課題: スレッド分離によるコンテキストスイッチとコア間通信、コピー中心のメモリ経路、NICの排他的所有、既存ハードウェア・ソフトウェアとの互換性。 - 代替案: 新規トランスポートプロトコル、ユーザー空間TCP、TCPオフロード、RDMA。2017年当時のフロントエンドでは、RDMAのデータセンター間通信とレガシー互換性が不十分だったためLUNAを選択した。 ## 背景: ストレージネットワーク サービスはインターフェース層、機能層、永続化層の三層で構成される。永続化層にはAlibaba Cloudが開発したHDFS類似の分散ファイルシステム[[Pangu]]とChunkstore Serverがある。フロントエンドネットワークは主にTCP、バックエンドネットワークはTCPまたはRDMAを用いる。 **図1: Alibaba Cloudのストレージネットワークアーキテクチャ** ![[_attachments/atc23-zhu-lingjun/fig01-storage-network.png]] (図1。コンピュートサーバーおよび三種類のストレージフロントエンドから、BlockServer、OSS Key-Value Server、Tablestore Engineを経てChunkServerとディスクへ至る、インターフェース・フロントエンドネットワーク・機能・バックエンドネットワーク・永続化の分離を示す。Source: Figure 1, PDF p.3／印刷 p.674) ## 既存方式との比較 **図2: 異なるネットワークスタックのオフラインRPC性能** ![[_attachments/atc23-zhu-lingjun/fig02-stack-performance.png]] (図2。単一コアのRPCレイテンシCDFと、コア数に対する最大スループットを比較する。カーネルTCPの中央値は約50マイクロ秒、単一コアの最大スループットは600Mbpsであり、コア追加だけでは問題を解消できない。Source: Figure 2, PDF p.4／印刷 p.675) | 実装 | カーネル共存 | ゼロコピー | 高スループット | 低レイテンシ | |---|---:|---:|---:|---:| | mTCP | | | | | | VPP | | | ✓ | | | IX | | ✓ | ✓ | ✓ | | LUNA | ✓ | ✓ | ✓ | ✓ | (表1: 既存ユーザーレベルTCPの特性。Source: Table 1, PDF p.5／印刷 p.676) ## 提案手法 ### アーキテクチャ LUNAは、アプリケーションとTCP/IP処理を同じプロセス・アドレス空間で動かすLibOS方式を採用する。各コアのNICマルチキューに対応するスレッドは共有なしで動き、DPDKのPMDでパケットをポーリングする。TCPはRFCに基づき、輻輳制御、フロー制御、RTT推定、SACKを実装する。 **図3: LUNAアーキテクチャ** ![[_attachments/atc23-zhu-lingjun/fig03-luna-architecture.png]] (図3。カーネル側のTCP/IP・ARP・ルートとLUNA側のTCP/IP・Zbuf slab・DPDK PMDを分け、netlinkでルートとARPを同期する。Source: Figure 3, PDF p.5〜6／印刷 p.676〜677) ### スレッドモデル: run-to-completion LUNAはアプリケーション処理とTCP処理を同じスレッドのイベントループで完了させるrun-to-completion(r2c)モデルを採用する。batch-r2cは受信パケットをTCP/IP処理した後にイベントキューを経由してコールバックを呼ぶため、epollやBSD socketに近く互換性が高い。inline-r2cはイベントキューを省略し、パケット処理、コールバック、ヘッダー生成、送信を一つの経路で完了させるため高性能だが、プログラミングモデルの変更が必要である。 **図4: LUNAのスレッドモデル** ![[_attachments/atc23-zhu-lingjun/fig04-thread-model.png]] (図4。アプリケーション、API、TCP/IP、DPDK PMDを同一プロセス内のスレッドへ配置し、カーネルTCP経路とユーザー空間経路を共存させる。Source: Figure 4, PDF p.7／印刷 p.678) **図5: batch-r2cとinline-r2c** ![[_attachments/atc23-zhu-lingjun/fig05-r2c-modes.png]] (図5。batch-r2cはイベント・タスクキューを使う一方、inline-r2cは受信パケットからコールバック・送信までを直結する。EBSではinline-r2c、互換性を重視するオブジェクトストアではbatch-r2cを使う。Source: Figure 5, PDF p.7／印刷 p.678) r2cはコンテキストスイッチを避け、固定サイズのパケットバッチとL1/L2キャッシュ局所性を利用する。一方、アプリケーション処理が停止するとNICキュー溢れ、パケット損失、TCPタイムアウトを招きうる。OSSではNIC I/Oとプロトコル処理を1コアへ置き、アプリケーション処理を他コアへ分離する構成も採用した。 ### メモリモデル: Zbufによる全経路ゼロコピー [[Zbuf]]はDPDKのhugepageを2MBのメモリゾーンへ分割し、各ゾーンを同一サイズのオブジェクトへ分割するユーザーレベルslabサブシステムである。ゾーンのメタデータに物理アドレス、オブジェクトサイズ、位置を保持し、参照カウンタでアプリケーション、TCP送信キュー、複製データの寿命を管理する。 **図6: Zbufの構造** ![[_attachments/atc23-zhu-lingjun/fig06-zbuf-structure.png]] (図6。2MBページをメタデータと2KBまたは4KB級のオブジェクトへ分割する。Source: Figure 6, PDF p.8／印刷 p.679) **図7: LUNAのゼロコピー受信・送信経路** ![[_attachments/atc23-zhu-lingjun/fig07-zero-copy-path.png]] (図7。受信ではNICがZbufオブジェクトへDMAし、LUNAがペイロードポインタをRPCで渡す。送信ではアプリケーションがZbufへ書き、LUNAが別セグメントのTCPヘッダーと結合して送る。Source: Figure 7, PDF p.8〜9／印刷 p.679〜680) 受信・送信のゼロコピーには、読み書き可能なバッファのアドレスと長さを記述するio-vector型APIが必要である。従来のheapのようにZbuf APIでバッファを確保・解放できるため、変更はバッファAPIを中心としたものに抑えられる。 ### トラフィックモデル: カーネルTCPとの共存 LUNAはNICのFlow BifurcationとSR-IOVを使い、ユーザー空間TCPとカーネルTCPを同じNIC上で共存させる。クライアント側ではTCPポート61440〜65535を予約し、アプリケーション、受信キュー、スレッドごとに範囲を分割する。サーバー側では同じ宛先ポートへの接続を送信元ポートでハッシュしてスレッドへ分散する。 **図8: LUNAのトラフィックモデル** ![[_attachments/atc23-zhu-lingjun/fig08-traffic-model.png]] (図8。Flow DirectorでNICキューをカーネル用とLUNA用に分け、ARP・ルートなどの制御プレーンをカーネルからnetlinkでLUNAへ同期する。Source: Figure 8, PDF p.9〜10／印刷 p.680〜681) ARP、ICMP、ルートテーブルなどの制御プレーンはカーネルに任せる。LUNAとカーネルTCPは標準TCPとして互換性を持つが、LUNAとカーネルTCPが直接通信する構成は、異なるLUNA・カーネル版の組み合わせを検証するコストを避けるため採用しない。NICのフローディレクタ規則は、12スレッドと6スレッドの組み合わせで160規則になる例があり、複雑化とパケットドロップの原因になる。 ## 実験設定 - 実験機: Intel Xeon E5-2682 v4 2.50GHz、128GB DRAM、Mellanox ConnectX-4 Lx、2×25Gbpsで合計50Gbps。 - 比較対象: Linux 4.19のカーネルTCP、mTCP、VPP、LUNAのコピー版とゼロコピー版。 - 共通条件: MTU 1500バイト。LinuxはTSO/LRO、LUNAはTSOを有効化。mTCPはTSO非対応、VPPではLRO/TSOを有効化できなかった。 - ワークロード: `knb`による長期TCP接続の4KB RPC。メッセージサイズ、iodepth、コア数を変え、さらにEBS OLTP、EBS動画トランスコード、TableStoreの本番データを比較した。 ## 実験結果 ### マイクロベンチマーク 図9〜12は、メッセージサイズ、iodepth、応答レイテンシ、マルチコア拡張性を一つの図版に収録している。 ![[_attachments/atc23-zhu-lingjun/fig09-12-microbenchmark-overview.png]] (図9〜12。図9は4KBでLUNAゼロコピーが帯域を使い切り、カーネル比3.5倍、mTCP/VPP比50%高い。図10はiodepth 16で帯域を飽和させ、mTCPとカーネルTCPの2倍を示す。図11はゼロコピーがコピー版より99パーセンタイルレイテンシを25%、カーネルTCPより70%削減する。図12は8コアで帯域を使い切り、ほぼ線形に拡張する。Source: Figures 9〜12, PDF p.11／印刷 p.682) ### 本番評価 **図13: EBSのOLTPサービス** ![[_attachments/atc23-zhu-lingjun/fig13-oltp-production.png]] (図13。1時間のトレースで、LUNAはカーネルTCPよりエンドツーエンド平均レイテンシを50%削減し、スループットは同程度だった。LUNA側は顧客差によりI/Oブロックサイズが大きく、単純比較ではない。Source: Figure 13, PDF p.11〜12／印刷 p.682〜683) **図14: EBSの動画トランスコードサービス** ![[_attachments/atc23-zhu-lingjun/fig14-video-production.png]] (図14。ユーザー層I/Oレイテンシが同程度の条件で、LUNAはカーネルTCPよりI/Oスループットを約50%高めた。Source: Figure 14, PDF p.12／印刷 p.683) **図15: TableStoreの更新前後** ![[_attachments/atc23-zhu-lingjun/fig15-ots-latency.png]] (図15。V1.0からV2.0への更新後、エンドツーエンドレイテンシが50〜68%低下した。LUNAの総合性能向上への寄与は30〜50%とオフライン推定された。Source: Figure 15, PDF p.12／印刷 p.683) ## 考察と運用上の教訓 ### 移植性 移植性を、(1)変更なし、(2)APIの置換のみ、(3)API形式は変わるがプログラミングモデルは維持、(4)プログラミングモデルとAPIロジックを全面変更、の4段階に分ける。LUNAは高性能化のために変更を許容しながら、既存アプリケーションの全面的な再設計は避ける(2)と(3)の間を目指す。 ### TCPの調整と障害復旧 **図16: 輻輳制御アルゴリズムの比較** ![[_attachments/atc23-zhu-lingjun/fig16-congestion-control.png]] (図16。Alibaba CloudのストレージネットワークでNewReno、Cubic、HPCCの99パーセンタイルレイテンシとスループットを比較する。多くのサービスではNewRenoで十分であり、VM間通信ではHPCCを使う。Source: Figure 16, PDF p.13／印刷 p.684) LUNAは順序どおりに到着するパケットを高速経路で処理し、データセンターでは順序外パケットが少ないという前提を利用する。初期版はsocket型APIと送信時コピーだったが、DPU搭載サーバーの制約に対応して、シリアライズを除くRPC、inline-r2c、送受信ゼロコピー、Zbuf、io-vector型APIへ進化した。 アプリケーションとRPCフレームワークは別NICポートやToRスイッチを使って再接続し、4スイッチホップ以下というデータセンターの制約からタイムアウトを約4ミリ秒に設定する。最長復旧時間は2秒未満とされる。 ### 適用限界 200〜400Gbpsでは、r2cと浅いバッファの組み合わせがNICキュー溢れとパケットドロップを起こしうる。4KBメッセージで100Gbpsを飽和させるには少なくとも8コアが必要であり、さらに高速なネットワークではハードウェアアクセラレーションが必要になる。TCPのヘッドオブラインブロッキングと障害復旧の制約から、著者らはDPUと協調設計する新プロトコルSolarへ進んでいる。 ## スライドからの補足 発表スライドは、論文の設計・評価を圧縮して示す23ページの資料である。論文と重複しない補足として、LibOSを選んだ理由を「性能を最優先」「頻繁なアップグレードは不要」と整理し、LUNAの進化をsocket-like API・batch-r2c・送信コピーからio-vector型API・inline-r2c・送信ゼロコピーへ時系列で示す。 **発表スライド p.18: LibOS with r2c** ![[_attachments/atc23-zhu-lingjun/slide18-libos-r2c.png]] (LibOS、マイクロカーネル、Sidecar、ディスパッチ方式を比較し、LUNAは性能を最優先し、頻繁な更新を必要としないためr2cを採用したと整理する。Source: [[.raw/slides/atc23-slides-zhu-lingjun/atc23-slides-zhu-lingjun.pdf]], p.18) **発表スライド p.20: Network Evolution** ![[_attachments/atc23-zhu-lingjun/slide20-network-evolution.png]] (LUNA、LUNA-customized RPC、Solarの進化を、API、r2c、ゼロコピー、UDPベース、マルチパス、ハードウェアオフロード、DPU協調の軸で示す。Source: [[.raw/slides/atc23-slides-zhu-lingjun/atc23-slides-zhu-lingjun.pdf]], p.20) ## 強み / 弱点・課題 ### 強み - ユーザーレベルTCPを研究プロトタイプにとどめず、Alibaba Cloudのストレージサービスへ5年以上展開した実運用経験。 - r2c、Zbuf、Flow Bifurcationを組み合わせ、スレッド切り替え、メモリコピー、カーネルTCP共存という異なる制約を同時に扱う。 - 4KB RPCでカーネルTCP、mTCP、VPPを同一条件に近い環境で比較し、本番評価も併記する。 ### 弱点・課題 - r2cはアプリケーションの停止やバーストに弱く、NICキュー溢れ・タイムアウトのリスクがある。 - ゼロコピーはio-vector型APIなどの変更を要求し、カーネルTCPとの直接通信は互換性検証コストのため避けている。 - 評価はConnectX-4 Lx、50Gbps、特定のストレージサービスを中心とし、200〜400Gbps級での挙動は設計上の懸念として述べられる。 ## 出典 - [[.raw/papers/atc23-zhu-lingjun.pdf]] - [[.raw/papers/atc23-zhu-lingjun.txt]] - [USENIX ATC 23 official page](https://www.usenix.org/conference/atc23/presentation/zhu-lingjun) - [From luna to solar: the evolutions of the compute-to-storage networks in Alibaba Cloud](https://doi.org/10.1145/3544216.3544238)