Zero Copy Transfer (제로 카피 전송)

안녕하세요! 오늘은 Zero Copy Transfer에 대해 알아보겠습니다.

 

 

제로카피 전송이란? 데이터를 복사하거나 전송하는 과정에서 중간 버퍼를 사용하지 않고 데이터를 직접 전송하는 방법으로 데이터 이동을 최적화하고 시스템 성능을 향상시키기 위한 방법입니다. 

 

먼저 전통적인 방법과 개선된 방법, 보다 개선된 방법까지 총 3단계를 거쳐 어떻게 달성하게 되었는지 확인해보겠습니다. 

 

 

단계 1. 전통적인 방법

보통 우리는 파일을 읽고 전송한다면 아래와 같은 코드를 작성할 것입니다. 

File.read(fileDesc, buf, len);
Socket.send(socket, buf, len);

 

이것은 내부적으로 아래와 같은 과정을 거치게 됩니다.

 

이 전통적인 과정에서는 총 두 개의 불필요한 작업이 있습니다.

(파일을 읽어서 전송하는 단순한 애플리케이션이라는 가정하에 불필요한 작업이라고 표현하였습니다.)

 

1. read ahead를 위한 중간버퍼 운용

2. application 버퍼로의 복사 

 

첫번째, read ahead는 파일을 페이지 캐시로 미리 읽어들여서 IO 횟수를 줄이는 것인데요, 

이는 몇가지 부작용이 있습니다.

그 중 이 상황에서는, 요청된 데이터의 크기가 커널 버퍼 크기보다 상당히 큰 경우 이 접근 방식 자체가 성능 병목 현상을 일으킬 수 있는 것이 한 가지 부작용입니다.

 

두번째, 해당 애플리케이션에는 굳이 사용자 버퍼로의 복사 과정은 필요 없습니다. 

운영체제 수업 때 배운 것처럼 사용자모드와 커널모드를 오가며 데이터를 버퍼링하는 과정에서 컨텍스트 스위칭이 발생하게 되므로, 

불필요한 오버헤드를 일으키고 있는 것입니다. 

 

단계 2. 개선된 방법 (Zero Copy)

불필요한 것들을 제거하여 데이터를 ReadBuffer에서 SocketBuffer로 직접 전송하여 성능을 향상시킬 수 있고 이것이 Zero Copy Transfer가 나오게 된 배경입니다. 

 

리눅스의 sendfile() 시스템콜로 지원받을 수 있고 JAVA에서는 nio의 transferTo()가 sendfile()시스템콜을 사용하고 있습니다.

 

전통적인 방식과 다르게 컨텍스트 스위칭 비용을 줄이고 중간 버퍼를 3개로 줄였습니다.

하지만 아직 완전한 Zero Copy라고 부를 순 없어 보입니다.

 

만약 네트워크 인터페이스 카드(NIC)가 gather operations을 지원해 준다면 더 줄일 수 있어 보입니다.

 

단계 3. 더 개선된 방법 (Zero Copy)

사용자가 추가로 명시할 건 없습니다. 리눅스 커널 2.4 버전 이후부터 NIC 장비의 Gather Operation 지원을 해준다면 복사본을 더 줄일 수 있습니다. 

 

달라진 점은 데이터가 SocketBuffer로 복사되지 않습니다. 

데이터가 저장된 위치와 데이터 길이에 대한 정보를 포함한 discriptor가 소켓 버퍼에 추가됩니다.

덕분에 DMA는 데이터를 ReadBuffer에서 NIC Buffer에 바로 복사할 수 있게 됩니다. 

 

성능 비교

transferTo() API는 기존 접근 방식에 비해 시간을 약 65% 단축합니다.

이는 웹 서버와 같이 하나의 I/O 채널에서 다른 I/O 채널로 많은 양의 데이터를 복사하는 애플리케이션의 성능을 크게 향상시킬 수 있어보입니다.

하지만 리눅스 특정 커널 버전이나 특정한 라이브러리에서만 지원할 수 있으므로 플랫폼 의존성이 있습니다.

또한 오히려 작은 데이터의 경우 다른 방식이 더 적절할 수 있습니다.

채널 간 많은 양의 데이터를 복사하는 애플리케이션에서 Zero Copy 기술은 성능 향상을 제공할 수 있으나, 은탄환은 없습니다.

모든 상황에 맞는 솔루션은 아니니 장단을 꼼꼼히 확인하고 적용해야 합니다.

 

참고 : https://developer.ibm.com/articles/j-zerocopy/

 

---

오류가 있거나 궁금한 점, 추가적인 정보가 있으면 댓글 부탁드립니다 :)

함께 성장합시다!