한계에 도전: Netflix가 800Gb/s에서 비디오 트래픽을 제공하는 방법

고화질 비디오를 수백만 명의 동시 사용자에게 제공하려면 단순히 빠른 디스크와 큰 파이프만으로는 부족합니다; 저장소에서 네트워크로 비트를 이동시키는 데 기여하지 않는 모든 CPU 사이클과 메모리 복사를 세밀하게 제거해야 합니다. NAB Show에서 진행된 상세 기술 발표에서 Netflix 엔지니어들은 단일 서버의 처리량을 800Gb/s 수준으로 끌어올리기 위해 필요한 아키텍처 진화를 공개했습니다.

이 규모에서는 원시적인 연산 성능이 아니라 메모리 대역폭과 운영체제 커널의 오버헤드가 주요 적입니다. 이러한 속도를 달성하기 위해 Netflix는 특정 워크로드에 집중했습니다: FreeBSD‑current와 NGINX 기반 스택을 사용해 사전 인코딩된 정적 미디어 파일을 제공하는 방식입니다.

데이터 경로의 진화

Netflix가 800Gb/s에 도달한 과정을 이해하려면 CPU와 메모리 버스에 부과되는 "세금"을 줄이기 위해 구현한 최적화 타임라인을 살펴보는 것이 도움이 됩니다.

1. 비동기 Sendfile (2014)

전통적으로 파일을 제공하려면 디스크에서 커널로, 다시 사용자 공간으로, 그리고 다시 커널로 복사한 뒤 네트워크로 전송해야 합니다. Netflix는 sendfile(2)를 활용했는데, 이는 커널이 파일 디스크립터에서 TCP 소켓으로 데이터를 직접 전송하도록 하여 사용자 공간을 완전히 우회합니다.

하지만 표준 sendfile은 디스크 읽기가 느릴 경우 NGINX 워커를 차단할 수 있습니다. Netflix는 비동기 sendfile을 구현해 이 작업을 "fire and forget" 메커니즘으로 전환했습니다. 디스크 읽기가 완료되면 인터럽트 핸들러가 TCP 스택에 데이터를 사용할 수 있음을 알리며 워커 스레드가 멈추는 것을 방지하고, 구형 하드웨어에서 처리량을 23Gb/s에서 36Gb/s로 끌어올렸습니다.

2. 커널 TLS (kTLS) (2016)

현대 트래픽에서는 암호화가 필수이지만 TLS는 일반적으로 sendfile 파이프라인을 깨뜨립니다. 표준 TLS 설정에서는 데이터를 커널에서 사용자 공간으로 복사해 CPU가 암호화한 뒤 다시 커널로 보내야 합니다.

Netflix는 TLS 대칭 암호화를 커널 내부로 이동시켜 이 문제를 해결했습니다. 초기 핸드셰이크는 여전히 사용자 공간에서 이루어지지만, 대량 암호화는 sendfile 파이프라인의 일부로 처리됩니다. 이를 통해 제로 복사 데이터 흐름이 복원되고, 커널과 사용자 공간 사이의 반복 복사로 인한 메모리 대역폭 급증이 사라졌습니다.

3. NUMA 마스터링 (2019)

네트워크 속도가 상승함에 따라 Netflix는 비균일 메모리 아키텍처(NUMA)의 한계에 직면했습니다. 멀티 소켓 시스템에서는 메모리와 I/O 장치가 특정 CPU 코어에 "가깝게" 배치됩니다. 예를 들어 Node 0의 CPU가 Node 1에 연결된 메모리의 데이터를 암호화하고 Node 0에 연결된 NIC를 통해 전송하려면 데이터가 NUMA 패브릭(소켓 간 인터커넥트)을 여러 번 가로질러야 합니다.

최악의 경우, 하나의 패킷이 NUMA 버스를 네 번 가로지를 수 있습니다:

디스크 → 메모리
메모리 → CPU(암호화)
CPU → 메모리(암호화된 데이터)
메모리 → NIC

이러한 혼잡은 CPU 정체를 초래합니다. Netflix는 Disk Centric Siloing을 도입해 읽기, 암호화, 전송 과정이 데이터가 위치한 NUMA 노드에서 이루어지도록 했습니다. "Strict Disk Centric Siloing"으로 전환하면서 대량 데이터가 NUMA 버스를 가로지르는 경우를 완전히 없애 패브릭 포화도를 크게 낮췄습니다.

최종 도약: 인라인 하드웨어 kTLS (2022)

NUMA 최적화에도 불구하고 소프트웨어 기반 kTLS는 사용 가능한 CPU 사이클의 거의 절반을 차지합니다. 400Gb/s 장벽을 깨기 위해 Netflix는 NVIDIA(Mellanox)와 협력해 ConnectX‑6 Dx NIC를 이용한 Inline Hardware kTLS를 구현했습니다.

하드웨어 오프로드를 통해 커널은 암호화 키를 NIC에 직접 전달합니다. 데이터는 디스크에서 메모리로 흐른 뒤 평문 그대로 NIC로 바로 전달되고, NIC는 전송 중에 데이터를 실시간으로 암호화합니다.

이 효과는 두 가지입니다:

CPU 경감: 호스트 CPU가 대량 암호화 과정에 관여하지 않게 됩니다.
메모리 대역폭 감소: 메모리 대역폭 요구량이 절반으로 줄어듭니다(≈400GB/s에서 ≈200GB/s로, 800Gb/s 스트림 기준). 이는 CPU가 암호화를 위해 데이터를 읽고 쓰는 작업이 사라지기 때문입니다.

800Gb/s 실험 결과

Dell R7525 서버(듀얼 AMD EPYC 7713 CPU, 4개 Mellanox ConnectX‑6 Dx NIC)로 Netflix는 이 아키텍처의 한계를 테스트했습니다. 720Gb/s에 도달하기까지 여러 차례 반복이 있었습니다:

Initial Result (420Gb/s): 소켓 간 xGMI 링크의 AMD 동적 링크 폭 관리(DLWM) 제한.
Forced Link Width (500Gb/s): xGMI를 x16 및 18GT/s로 강제 설정했지만 NVMe 사분면 간 I/O 분배 불균형으로 정체 발생.
Disk Centric Siloing (670Gb/s): DMA 처리 방식을 바꿔 xGMI 해싱을 개선했으나 페이지 데몬에 약간의 압력이 가해짐.
Strict Disk Centric Siloing (720Gb/s): 디스크가 있는 NUMA 노드와 동일한 위치에 egress NIC를 배치해 720Gb/s 달성. 이 시점에서 병목은 CPU에서 NIC 출력 감소로 전환됐으며, 일부 NIC는 94Gb/s, 다른 NIC는 84Gb/s 수준으로 콘텐츠 인기 때문에 차이가 발생했습니다.

기술 종합 및 커뮤니티 관점

이 아키텍처는 고성능 네트워킹에서 근본적인 변화를 보여줍니다: "모두 오프로드"로의 이동. 데이터 플레인을 커널로, 그리고 하드웨어로 밀어넣음으로써 Netflix는 CPU의 역할을 데이터 처리자가 아닌 코디네이터로 최소화했습니다.

커뮤니티 관점에서 일부 관찰자는 정적이며 이미 암호화된 DRM 콘텐츠에 TLS가 필요하냐는 의문을 제기했습니다. 그러나 "TLS everywhere"라는 산업 트렌드는 보안·프라이버시 이점과 표준화된 하드웨어 오프로드 활용 가능성이 오버헤드를 능가한다는 점을 시사합니다. 또한 이 스택에서 FreeBSD를 사용한 것은 네트워크 스택에 대한 미세 제어가 중요한 특수 고처리량 네트워킹 작업에서 BSD 커널의 지속적인 relevance를 강조합니다.