(인프라 5) Kernel Bypass
저지연 트레이딩에서 핵심 기술 중 하나인 kernel bypass 기술을 설명합니다. 일반적인 패킷 수신 경로, OpenOnload, libvma, DPDK의 차이점, AMD/NVIDIA Smart NIC 등을 다룹니다
이전 글: 미니원장
이 글은 매매 시스템 - 인프라 시리즈의 다섯 번째 글입니다.
다음 글: 오버클럭 서버
지금까지 코로케이션, FEP, 미니원장 등 서버 외부의 이야기를 다뤘습니다. 이번에는 서버 내부, 특히 네트워크 스택을 살펴보겠습니다.
일반적인 패킷 수신 경로
네트워크 패킷이 애플리케이션에 도달하기까지 다음 단계를 거칩니다.
1
2
3
+-------+ +-------------------+ +-------------+
| NIC | --> | Kernel (+ Driver) | --> | Application |
+-------+ +-------------------+ +-------------+
드라이버는 커널의 일부입니다. 커널 영역 안에서 네트워크 드라이버가 동작하고, 그 위에 TCP/IP 스택이 올라가는 구조입니다.
- 드라이버: NIC(랜카드)와 OS 사이의 통역사입니다. NIC 제조사마다 하드웨어가 다르기 때문에, 드라이버가 NIC와 통신하는 방법을 OS에 알려줍니다.
- TCP/IP 스택: 도착한 패킷을 분류하고 정리하는 센터입니다. 받는 사람 주소 확인(IP), 패킷 순서 정렬(TCP), 파손된 패킷 재요청 등을 처리합니다.
1
2
3
4
5
6
7
8
NIC: "01001010..." (전기 신호)
|
드라이버: "이건 패킷이야" (번역)
|
TCP/IP 스택: "이 패킷은 80번 포트로 가는 HTTP 데이터고,
순서는 3번째야" (분류/정리)
|
애플리케이션: OMS, 웹페이지 등
상세 흐름 (일반적인 패킷 수신 경로)
1
2
3
4
+-----+ DMA +---------+ IRQ +-----+ TCP/IP +--------+ syscall +-----+
| NIC | -----> | Ring | -----> | CPU | -------> | Kernel | --------> | App |
+-----+ | Buffer | +-----+ | Stack | +-----+
+---------+ +--------+
- DMA 전송: NIC가 CPU 개입 없이 패킷을 커널의 Ring Buffer로 직접 복사합니다.
- 인터럽트: NIC가 CPU에 “패킷 왔어”라고 알립니다. CPU는 현재 작업을 중단하고 핸들러를 실행합니다.
- 커널 스택: TCP/IP 처리(헤더 파싱, 체크섬 검증, 순서 정렬 등)를 수행합니다.
- 컨텍스트 스위칭:
recv()시스템 콜로 커널 모드 ↔ 유저 모드를 오가며 데이터를 복사합니다.
Kernel Bypass란?
Kernel bypass는 이름 그대로 커널을 건너뛰는 방식입니다.
일반 경로 vs Kernel Bypass
1
2
3
4
5
6
7
8
9
10
11
[ Traditional ]
+-----+ DMA +--------+ IRQ +--------+ TCP/IP +--------+ syscall +-----+
| NIC | ----> | Kernel | ----> | Kernel | -------> | Kernel | --------> | App |
+-----+ | Buffer | | Driver | | Stack | +-----+
+--------+ +--------+ +--------+
[ Kernel Bypass ]
+-----+ DMA +-------------+ polling +-------------+
| NIC | ----> | User Buffer | --------> | Application |
+-----+ | (mmap) | +-------------+
+-------------+
위 그림에서 보듯이, 기존 방식에서는 NIC → 커널 버퍼 → 커널 스택 → 유저 버퍼로 데이터가 여러 번 복사되고, 그 사이에 인터럽트와 컨텍스트 스위칭이 발생합니다.
Kernel bypass에서는 NIC가 유저 공간에 직접 매핑된 버퍼로 DMA 전송합니다. 애플리케이션은 이 버퍼를 직접 읽습니다. 인터럽트 대신 폴링(busy-wait)으로 패킷 도착을 확인하는 경우가 많습니다.
어떻게 커널을 우회할까?
일반 경로에서 NIC는 패킷이 오면 인터럽트를 발생시켜 CPU에 알립니다. CPU는 하던 일을 멈추고 패킷을 처리합니다. 이 과정에서 지연이 발생합니다.
Kernel bypass는 이 방식을 바꿉니다:
- 폴링(Polling): CPU가 “패킷 왔나?” 하고 계속 확인합니다. 인터럽트를 기다리지 않으므로 즉시 처리할 수 있습니다.
- 메모리 직접 접근: NIC가 애플리케이션이 볼 수 있는 메모리에 직접 씁니다. 커널을 거쳐 복사할 필요가 없습니다.
| 항목 | 일반 경로 | Kernel Bypass |
|---|---|---|
| 패킷 감지 | 인터럽트 (“패킷 왔어!”) | 폴링 (“패킷 왔나?”) |
| 메모리 복사 | 커널 → 앱 복사 | 없음 (직접 읽음) |
| CPU 사용 | 필요할 때만 | 100% 고정 (전용 코어) |
폴링은 누군가가 해줘야 합니다. DPDK를 사용하면 CPU가 이 작업을 담당하는데, 그만큼 트레이딩 로직에 쓸 CPU 자원이 줄어드는 단점이 있습니다.
주요 Kernel Bypass 솔루션
Kernel bypass 자체는 소프트웨어 기술입니다. 대표적인 솔루션으로 OpenOnload, libvma, DPDK가 있습니다.
OpenOnload (AMD/Solarflare)
OpenOnload는 AMD(구 Solarflare)에서 제공하는 kernel bypass 라이브러리입니다. BSD 소켓 API를 그대로 노출하므로, 애플리케이션 수정 없이 사용할 수 있습니다.
사용법은 간단합니다. 애플리케이션 실행 시 onload를 앞에 붙이면 됩니다:
1
onload ./my_trading_app
내부적으로는 LD_PRELOAD를 사용해 libonload.so를 먼저 로드합니다. 이 라이브러리가 socket(), recv(), send() 등의 함수를 가로채서 커널을 우회하는 구현으로 대체합니다.
libvma (NVIDIA/Mellanox)
libvma는 NVIDIA(구 Mellanox)에서 제공하는 kernel bypass 라이브러리입니다. RDMA 호환 NIC에서 동작합니다.
마찬가지로 LD_PRELOAD로 사용합니다:
1
LD_PRELOAD=libvma.so ./my_trading_app
지연시간 최적화 옵션을 추가할 수도 있습니다:
1
LD_PRELOAD=libvma.so VMA_SPEC=latency ./my_trading_app
DPDK (Intel 오픈소스)
DPDK는 Intel에서 시작한 오픈소스 프레임워크로, 현재는 Linux Foundation에서 관리합니다.
OpenOnload나 libvma와 달리 DPDK는 네트워크 스택 자체를 사용자가 직접 구현해야 합니다. BSD 소켓 API를 제공하지 않으므로 애플리케이션을 DPDK API에 맞게 작성해야 합니다.
장점은 유연성입니다. 원하는 대로 스택을 튜닝할 수 있습니다. 단점은 난이도가 높고 개발 비용이 많이 든다는 점입니다.
Smart NIC
위 솔루션들은 커널을 우회하지만, 패킷을 처리하고 애플리케이션으로 전달하는 작업에는 여전히 CPU 자원이 필요합니다.
네트워크 처리 자체를 NIC에서 수행하는 장치도 있습니다. Smart NIC은 FPGA나 ARM 같은 프로그래머블 프로세서를 탑재해 CPU의 네트워크 관련 작업을 오프로드합니다.
| 벤더 | 제품군 |
|---|---|
| AMD (Solarflare) | X2522, X4 시리즈 |
| NVIDIA (Mellanox) | ConnectX 시리즈 |
CPU는 네트워크 처리에서 해방되어 트레이딩 로직에만 집중할 수 있습니다.
AMD vs NVIDIA: 인수의 역사
현재 저지연 네트워크 시장은 AMD와 NVIDIA가 양분하고 있습니다. 두 회사 모두 인수를 통해 이 시장에 진입했습니다.
AMD 계열: Solarflare → Xilinx → AMD
| 시기 | 내용 |
|---|---|
| 2001년 | Solarflare 설립, 저지연 NIC 개발 시작 |
| 2017년 | Xilinx가 Solarflare에 전략적 투자 |
| 2019년 7월 | Xilinx가 Solarflare 인수 완료 |
| 2020년 10월 | AMD가 Xilinx 인수 발표 ($35B) |
| 2022년 2월 | AMD-Xilinx 인수 완료 |
| 2023년 6월 | Xilinx 브랜드 폐지, AMD로 통합 |
Solarflare는 주요 거래소, 투자은행, 헤지펀드에서 널리 사용되어 금융권에서 탄탄한 입지를 갖고 있었습니다.
NVIDIA 계열: Mellanox → NVIDIA
| 시기 | 내용 |
|---|---|
| 1999년 | Mellanox 설립 (이스라엘) |
| 2019년 3월 | NVIDIA가 Mellanox 인수 발표 ($6.9B) |
| 2020년 4월 | 인수 완료 |
| 2020년 이후 | Mellanox 브랜드 폐지, NVIDIA Networking으로 통합 |
Mellanox는 InfiniBand와 RDMA 기술로 HPC(고성능 컴퓨팅) 시장에서 강세를 보였습니다. NVIDIA는 이 기술을 AI 데이터센터 네트워킹의 핵심으로 활용하고 있습니다.
HFT에서의 선택
HFT 업계에서는 AMD(구 Solarflare) 제품이 가장 많이 쓰입니다. 금융권에 특화된 오랜 역사와 OpenOnload의 검증된 안정성 때문입니다.
현재 X4 시리즈까지 출시되었지만, X2522도 여전히 많이 사용됩니다.
X2522는 PTP(정밀 시간 동기화)와 TCPDirect 라이센스를 포함해 업체에 따라 250만 원에서 300만 원 정도입니다.
정리
| 방식 | 특징 | 난이도 |
|---|---|---|
| OpenOnload | BSD 소켓 API 호환, AMD NIC 필요 | 낮음 |
| libvma | BSD 소켓 API 호환, NVIDIA NIC 필요 | 낮음 |
| DPDK | 직접 스택 구현, 범용 NIC 가능 | 높음 |
지연시간을 줄이려면 커널을 건너뛰어야 합니다. 커널을 건너뛰려면 전용 라이브러리와 NIC가 필요합니다. 얼마나 투자할 수 있느냐에 따라 선택지가 달라집니다.
투자는 단순히 돈만을 의미하지 않습니다. 개발 시간과 런타임 성능, 금전 비용과 CPU 자원 등 여러 요소를 함께 고려해야 합니다. 현재 국내에서는 AMD의 X2522를 많이 사용합니다.
다음 글에서는 오버클럭 서버에 대해 알아 보겠습니다.
