CPU를 해방하라: 네트워크 전송 효율을 극대화하는 'Zero Copy' 기술의 해부

이것도 책에서 본겁니다. 아니 가끔 복사 붙여넣기 하면 너무 많은거 복붙하면 프리징 현상 뜨지않습니까. 그러다 보니 갑자기 궁금해지기도 했고 책에서 본것도 있어서 한번 적어볼게요.

보이지 않는 비용, 데이터 이동의 세금

고성능 네트워크 서버를 설계할 때 우리는 흔히 CPU의 클럭 속도나 네트워크 카드의 대역폭(Bandwidth)에 집중합니다. 하지만 초당 수기가바이트(GB/s) 단위의 트래픽을 처리하는 환경에서 진정한 병목은 의외로 '데이터 자체를 옮기는 과정'에서 발생합니다.

 

디스크에 있는 파일을 네트워크로 전송한다고 가정해 봅시다. 애플리케이션은 단순히 파일을 읽어서 소켓에 쓰는 코드를 실행하지만, 운영체제 내부에서는 이 데이터를 메모리의 이쪽 방에서 저쪽 방으로 옮기기 위해 CPU가 쉴 새 없이 자원을 소모해야 합니다.

 

이 과정에서 발생하는 막대한 CPU 사이클과 컨텍스트 스위칭(Context Switching) 비용은 시스템 전체의 처리량(Throughput)을 갉아먹는 숨겨진 세금과 같습니다. 오늘은 이 비효율적인 세금을 없애고, 데이터가 커널 내부의 고속도로를 타고 직행하도록 만드는 Zero Copy(제로 카피) 기술의 원리와 적용 사례를 깊이 있게 파헤쳐 보겠습니다.

---

전통적인 접근의 비효율: read()와 write()의 고단한 여정

Zero Copy의 위력을 이해하려면 먼저 전통적인 데이터 전송 방식이 왜 비효율적인지 물리적 흐름을 분석해야 합니다. 일반적인 웹 서버가 정적 파일(이미지, HTML 등)을 클라이언트에게 전송할 때 발생하는 프로세스는 다음과 같습니다.

4-Copy, 4-Context Switch 메커니즘

애플리케이션이 read()와 write() 시스템 콜을 호출할 때, 데이터는 다음과 같은 경로를 거칩니다.

1. read() 호출 (User → Kernel): 커널 모드로 전환됩니다. 디스크의 데이터를 DMA가 커널 공간의 페이지 캐시(Read Buffer)로 읽어옵니다. (Copy 1: DMA)
2. 데이터 반환 (Kernel → User): 커널 공간의 데이터를 유저 공간 버퍼로 복사합니다. 이때 CPU가 직접 개입하며, 유저 모드로 전환됩니다. (Copy 2: CPU)
3. write() 호출 (User → Kernel): 다시 커널 모드로 전환됩니다. 유저 공간의 데이터를 커널 공간의 소켓 버퍼(Socket Buffer)로 복사합니다. (Copy 3: CPU)
4. NIC 전송 (Kernel → NIC): 소켓 버퍼의 데이터를 네트워크 카드로 보냅니다. (Copy 4: DMA)

결론적으로, 데이터가 한 번 나갈 때마다 총 4번의 복사와 4번의 컨텍스트 스위칭이 발생합니다. 특히 2번과 3번 과정에서 발생하는 CPU 복사는 CPU가 비즈니스 로직 연산 대신 '단순 상자 옮기기'에 자원을 낭비하게 만드는 주범입니다.

---

Zero Copy의 혁명: 커널 내부의 직통 고속도로

Zero Copy는 "애플리케이션이 데이터를 가공하지 않는다면, 굳이 유저 공간으로 데이터를 가져올 필요가 있는가?"라는 질문에서 출발합니다.

출처 : 생성형 이미지, Zero Copy 란, Gemini

mmap(): 가상 메모리 매핑의 마법

mmap()은 파일의 내용을 유저 공간의 메모리 주소와 직접 매핑합니다.

• 원리: 유저 버퍼로 데이터를 복사하는 대신, 유저 공간과 커널 공간이 동일한 커널 페이지 캐시 주소를 가리키게 합니다.
• 장점: read() 시 발생하는 CPU 복사 1회를 제거합니다. 하지만 여전히 write() 시 소켓 버퍼로의 CPU 복사는 남아있습니다.

sendfile(): 정적 파일 전송의 구원자

리눅스 커널 2.1에서 도입된 sendfile()은 파일 디스크립터(FD) 간의 데이터를 커널 내부에서 직접 이동시킵니다.

• 작동 방식: sendfile(socket_fd, file_fd, ...) 호출 한 번으로 커널 공간 안에서 페이지 캐시의 데이터를 소켓 버퍼로 즉시 복사합니다.
• 성과: 컨텍스트 스위칭을 4회에서 2회로 줄이고, 유저 공간으로의 복사를 원천 차단합니다.

진정한 완성: Scatter/Gather DMA

sendfile()도 커널 내부에서 '페이지 캐시 → 소켓 버퍼'로의 CPU 복사가 1회 발생합니다. 이를 0으로 만들기 위해서는 NIC 하드웨어의 도움이 필요합니다.

 

출처 : 생성형 이미지, Scatter/Gather , Gemini

• Scatter/Gather 기능 지원 시: 커널은 데이터를 복사하지 않습니다. 대신 데이터가 위치한 메모리 주소와 길이 정보(Descriptor) 만을 소켓 버퍼에 기록합니다. NIC의 DMA 엔진은 이 디스크립터를 읽어 페이지 캐시에서 직접 데이터를 긁어(Gather) 네트워크로 쏩니다.
• 최종 결과: CPU 복사 0회, 오직 DMA 복사 2회만 남는 '진정한 Zero Copy'가 완성됩니다.

---

splice(): 중계 서버를 위한 파이프라인 최적화

sendfile()이 파일과 소켓 간 전송에 특화되었다면, splice()는 두 개의 소켓 사이에서 데이터를 중계할 때 빛을 발합니다.

• 메커니즘: 데이터 자체를 옮기지 않고, 데이터가 담긴 커널 메모리 페이지의 포인터(참조)만을 이동시킵니다.
• 실무 활용: L7 프록시 서버나 리버스 프록시(Nginx 등)에서 클라이언트 소켓의 데이터를 서버 소켓으로 넘길 때 사용됩니다. 데이터가 유저 공간을 거치지 않으므로 처리량이 비약적으로 상승합니다.

---

적용 사례와 기술적 트레이드오프

Apache Kafka와 Nginx의 비결

• Apache Kafka: 카프카 브로커가 초당 수백만 건의 메시지를 쏟아낼 수 있는 이유는 sendfile() 덕분입니다. 디스크의 로그 세그먼트를 컨슈머에게 보낼 때 JVM 힙 메모리로 데이터를 올리지 않습니다. 이는 GC(Garbage Collection) 부하를 제거하는 결정적인 효과도 가져옵니다.
• Nginx: sendfile on; 옵션은 정적 파일 서빙 성능을 몇 배로 끌어올립니다.

Zero Copy의 한계: 데이터 가공의 문제

Zero Copy의 치명적인 단점은 "CPU가 데이터를 만질 수 없다"는 것입니다.

• 문제: 데이터를 암호화(HTTPS/TLS)하거나 압축해야 한다면 CPU가 데이터를 유저 공간으로 가져와 연산해야 하므로 Zero Copy를 쓸 수 없습니다.
• 현대적 해결책 (kTLS): 최근 리눅스 커널은 kTLS(Kernel TLS)를 지원합니다. 커널 내부에서 대칭키 암호화를 수행함으로써, 암호화된 트래픽도 Zero Copy로 전송할 수 있는 길을 열었습니다.

---

CPU에게 본연의 임무를 허하라

고성능 시스템 아키텍처의 핵심은 각 컴포넌트가 가장 잘하는 일에 집중하게 만드는 것입니다. CPU는 복잡한 비즈니스 로직을 연산하고 데이터를 판단하는 데 쓰여야지, 단순한 짐꾼처럼 메모리 블록을 이리저리 옮기는 데 낭비되어서는 안 됩니다.

Zero Copy 기술은 데이터의 이동 경로를 최적화하여 커널과 하드웨어가 이 '단순 노동'을 전담하게 합니다. 그 결과 애플리케이션은 더 적은 자원으로 더 많은 트래픽을 처리하며, 지연 시간($ms$)을 최소화할 수 있습니다. 보이지 않는 커널 내부의 고속도로를 설계하고 활용하는 것, 그것이 바로 극한의 성능을 추구하는 엔지니어링의 정수입니다.

 

복사 붙여넣기는 참 편한 기능이에요. 누가 만든지는 모르겠지만 이 기능이 없었다면 제 인생은 끝났을 겁니다. 3만줄 이런거 손으로 직접 치거나 파일 옮길 생각하면 벌써 끔찍하네요.

---

참조 항목:

• Linux Man Pages: sendfile(2), splice(2) 시스템 콜 상세 규격.
• RFC 7323: TCP Extensions for High Performance 및 커널 내부 전송 아키텍처.
• Kafka Tech Blog: "It's all about the OS: Zero Copy and Page Cache".
• Phil Karlton: "Computer Science에는 두 가지 어려운 문제가 있다. 캐시 무효화와 이름 짓기다."