Toward microsecond Tail Latency and Terabit Ethernet: Disaggregating the Host Network Stack 1

이 포스트는 sigcomm 22의 Netchannel [https://dl.acm.org/doi/pdf/10.1145/3544216.3544230] 를 번역하여 정리한 글입니다.

 

이 논문은 이전에 정리했던 sigcomm 21의 Understanding Host Network Stack Overheads 논문의 후속 논문이라고 볼 수 있습니다.

 

초록

 오늘날 많이 전개된 네트워크 스택의 정적이고 강하게 결합된 packet 처리 파이프라인은 최신 하드웨어를 완벽하게 사용하는 것을 어렵게 만든다. 

 논문에서는 disaggregated 네트워크 스택 구조인 NetChannel을 제안한다. 이 NetChannel은 Terabit Ethernet 위에서 μs-scale application을 위한 구조이다. 이 구조는 packet 처리 파이프라인에서의 각 레이어에 할당된 자원들을 적절하게 스케쥴링하고 독립적으로 스케일링하는 것을 가능케 한다. 우리의 제안은

 

  (1) 단일 스레드가 수백 Gbps link를 달성할 수 있고,

  (2) 작고 많은 메세지를 처리하는 과정에서 응용의 스레드 수와 관계없이 CPU core에 비례하여 성능을 얻어낼 수 있으며,   

  (3) line rate (연결 회선 대역폭)를 거의 다 쓰는 상황에서도 latency에 민감한 응용들을 격리하여 μs-scale의 tail latency를 유지할 수 있음

 

을 보인다.

 

서론

 host 네트워크 스택은 수많은 곳에 전개되었고 크나큰 성공을 거뒀지만, 여러 구석에서 심각한 결함이 있다: (1) 비효율적인 packet 처리 파이프라인, (2) latency에 민감한 응용과 throughput을 많이 사용하는 응용을 분리할 수 없는 부분, (3) 엄격하고 복잡한 구현, (4) 비효율적인 전송 계층 (L4) 등등. 이러한 비판들은 연구자들로 하여금 interface, semantics, placement를 변화시키면서 재미있는 디자인을 만들어내게 만들었다. 

 

 이 논문에서는 Linux 네트워크 스택의 많은 결함들이 위의 interface, semantics, placement에서 오기보다는 core 구조에 있음을 말하고자 한다. 특히, Linux 네트워크 스택은 태초부터 모든 응용들이 엄격하게 설계된 동일한 pipe를 타도록 되어 있었다. 그 엄격한 구조는 다음과 같다:

 Dedicated pipes: 각 응용 및 스레드들은 dedicated pipe의 끝단에서 데이터를 제출하고 (tx-side socket을 통해), 반대편의 끝단 (rx-side socket)에 전달한다.

 Tightly-integrated packet processing pipeline: 각 파이프는 각자의 소켓에 할당되고, 각자 독립적인 L4 작업 (CC, flow control 등)을 수행한다. 그리고 이들은 시스템에 존재하는 다른 파이프들과 완전히 독립적으로 운영된다.

 Static pipes: 전체 packet 처리 파이프라인은 파이프가 생성될 때 결정되고, 다른 파이프와 host의 자원을 고려하지 않은채 끝까지 변경되지 않는다. 

 

 이와 같은 구조는 인터넷과 데이터센터 초창기에 매우 적합했다. 왜냐하면 병목 지점이 network core (이는 말단 host가 아닌 내부 스위치/라우터 등을 의미)에 있었음에 따라, host 자원을 크게 고려하지 않아도 됐기 때문이다. 그러나 link bandwidth가 급격하게 증가하고 host 자원에 대한 기술 동향은 침체되어 있었기에, 병목 지점이 host로 옮겨오게 되었다. Section 2에서는 실험을 통해 문제 배경을 다룬다. 새로운 아이디어를 실험하는 것도 굉장히 어려웠다. 성능 관련 패치가 네트워크 스택 파이프라인 속에 강하게 결합되어있기 때문. 이 덕분에 새로운 프로토콜이나 기법을 도입하는 것이 불가능하지는 않지만 굉장히 어려웠다. 당연하게도, 현재 네트워크 스택은 Terabit Ethernet 시대를 맞이하는데 위기에 처해있다. 이 논문의 목표는 해당 문제를 해결하고자, 네트워크 스택을 재구성하는데 지적 기반을 마련하는 것에 있다.

 

The Netchannel Architecture

NetChannel Architecture Overview

 

 NetChannel은 오늘날 강하게 통합 되어있던 packet 처리 파이프라인을 약하게 결합된 3개의 layer로 분리하였다 (Figure 1). 애플리케이션은 Virtual Network System (VNS) 계층과 상호작용하며, 이 VNS는 표준화된 인터페이스를 제공한다. 내부적으로, VNS는 애플리케이션 버퍼와 커널 버퍼사이의 데이터 전송을 인터페이스의 시맨틱을 지키면서 가능케 한다. NetChannel의 코어는 channel 추상화를 이용해 네트워크와 remote 서버를 멀티큐로서 추상화한 레이어인 Net Driver로 구성된다. 특히, NetDriver 계층은 애플리케이션 버퍼와 코어에서 packet 처리 과정을 분리했다: 하나의 코어 위에서 구동되는 애플리케이션이 읽거나 쓰는 data는 하나 혹은 그 이상의 channels에 애플리케이션 시맨틱을 깨뜨리지 않고 매핑시킬 수 있다. 각 channel은 congestion control이나 flow control같은 프로토콜 기능들을 독립적으로 구현할 수 있으며, 동적으로 하드웨어 큐에 패밍될 수 있다. 그리고 이 channel의 수는 애플리케이션의 스레드 개수 및 사용중인 코어 개수와 관계없이 독립적으로 자유자재 늘리고 줄일 수 있다. VNS와 NetDriver 계층 사이에는 NetScheduler 계층이 존재한다. 이는 개별적인 코어의 사용량, 애플리케이션 버퍼 사용량, channel 버퍼 사용량 정보를 이용해서 각 core/버퍼의 데이터를 잘게 쪼개어 각 channel에 multiplexing 및 demultiplexing을 수행한다.

 

 이 구조는 Linux의 스토리지 스택 구조와 비슷하다고 한다. 스토리지는 기존에도 Host에 병목이 있었기 때문에, 이 과정은 우연히 비슷해진 것이 아니고, 새로운 스토리지 기술 통합 및 애플리케이션 자원을 고려하는 올바른 구조를 향해 진화한 방식이라고 이야기한다. 

 

 NetChannel Benefits

 NetChannel의 주된 이익은 기존 네트워크 스택에 대해서 기존 프로토콜 (TCP, DCTCP, BBR) 구현의 수정 없이 새로운 운영 포인트를 제공한다는 점이다. 이러한 새로운 운영 방식은 곧바로 NetChannel의 disaggregated architecture 이끌었다: 각 리소스의 독립적인 scaling을 가능하게 할 뿐만 아니라, 여러 channel으로의 data demultiplexing과 multiplexing을 유연하게 만들어 준다. 각각의 코어, 애플리케이션, 그리고 각각의 channel들은 packet을 입맛에 맞게 multiplexing, demultiplexing을 할 수 있다. 추가로, NetScheduler와 결합하여 latency에 민감한 애플리케이션들을 throughput-bound 애플리케이션에서 격리시키는 등의 기능을 활용한다. 이 기법을 통해서 throughput-bound 애플리케이션의 성능은 기존과 가깝게 유지하면서도, latency에 민감한 응용들은 tail latency를 기존 네트워크 스택과 비교하여 17.5배 끌어올릴 수 있었다.

 

 NetChannel의 두 번째 이익은 네트워크 스택의 확장성에 있다. 예를 들어, NetChannel은 애플리케이션 개발자로 하여금 네트워크 성능을 끌어올리기 위해 직접 튜닝(thread의 개수, connection, socket의 개수 등)을 해야 하는 부담을 줄여준다. NetChnnael은 또한 프로토콜이나 스케쥴러를 새롭게 디자인했을 때, 실험이 쉽다는 장점이 있다. NetChannel 구조에서 새로운 전송 프로토콜을 구현하는 것은 "device driver"를 새로 쓰는 것과 유사하다. 

 

 이는 스토리지 스택 (새로운 하드웨어 및 프로토콜의 발전이 device driver를 통해서 이루어지기에 네트워크 스택보다 상대적으로 쉬우며, 여러 block layer scheduler의 화합을 통해서 각자가 원하는 성능의 애플리케이션을 간단하게 작성할 수 있다.)과 닮았으며, Netchannel이 더 넓고 꾸준히 발전할 수 있는 네트워크 스택 디자인의 생태계를 이끌 수 있기를 희망한다. 마지막으로, NetChannel은 오픈소스이고, github에서 찾을 수 있다.

 

 논문에서 커버하지 않는 내용:

 1. NetChannel 구조는 per-core 성능을 개선하기 위한 최근의 연구와 상호 보완적이다. 섹션 5에서 다루지만, io_uring의 인터페이스가 Netchannel의 구조에서도 여전히 이익을 얻을 수 있다. 

 2. NetChannel 구조는 네트워크 스택의 위치와 상관이 없다. 즉, hardware, in-kernel, userspace 중에 어디에 둘 지와는 독립적인 이야기다. 누군가가 NetChannel을 userspace에 잘 구현해서 또 다른 이익을 얻을 수도 있다. 하지만 이 논문에서는 kernel에 구현함으로써 기존의 in-kernel 네트워크 스택과의 비교를 선택했으며, 그 이유로는 기존 커널의 오래된 노력들, 안정성, 그리고 수많은 시스템에서 쓰이고 있음에 있다. userspace 내에 구현 및 hardware 내에 구현은 또다른 추후 연구 방향로 남겨놓는다.