고성능 Linux 서버 구조를 공부하다 보면 어느 순간부터는 CPU 계산 성능보다 “인터럽트를 얼마나 효율적으로 처리하느냐”가 훨씬 더 중요한 문제처럼 느껴질 때가 많다. 나도 처음에는 네트워크 카드(NIC)가 패킷이 들어오면 CPU한테 바로 알려주는 게 가장 빠르고 효율적인 방식이라고 생각했었다. 실제로 인터넷 데이터를 받으면 즉시 CPU가 반응하는 게 당연해 보였기 때문이다. 그런데 NAPI 구조와 인터럽트 폭주(Interrupt Storm) 문제를 조금씩 이해하다 보니까, 현대 서버에서는 오히려 “인터럽트를 일부러 덜 발생시키는 방향”으로 계속 최적화가 이루어지고 있다는 걸 알게 됐다. 그리고 그 흐름 속에서 등장하는 대표적인 네트워크 최적화 기술 중 하나가 바로 Interrupt Coalescing이다. 처음 이름을 들었을 때는 굉장히 복잡한 커널 기술처럼 느껴졌는데, 구조를 이해하고 나니까 핵심은 생각보다 단순했다. 바로 “패킷이 올 때마다 CPU를 깨우지 말고, 여러 개를 모아서 한 번에 처리하자”는 개념이었다. 특히 현대 데이터센터나 초고속 네트워크 환경에서는 패킷 수가 엄청나게 많기 때문에, 인터럽트 자체가 CPU 병목이 될 수 있다고 한다. 나도 처음에는 CPU가 계산 때문에 바쁜 줄만 알았는데, 실제 서버는 네트워크 패킷 알림만 처리하다가도 성능이 떨어질 수 있다는 게 꽤 충격적으로 느껴졌다.
예전 방식에서는 패킷마다 CPU 인터럽트가 발생했다
컴퓨터에서 네트워크 데이터가 도착하면 CPU는 그 사실을 알아야 한다. 예전 네트워크 구조에서는 네트워크 카드(NIC)가 패킷 하나가 들어올 때마다 인터럽트를 발생시키는 방식이 일반적이었다. 쉽게 말하면 “패킷 왔어요!”라고 CPU를 계속 깨우는 구조다. 처음에는 나도 이 방식이 가장 자연스럽게 느껴졌다. 데이터가 들어오면 CPU가 바로 처리해야 빠를 것 같았기 때문이다. 실제로 네트워크 트래픽이 적을 때는 이런 구조가 꽤 효율적으로 동작했다고 한다. 문제는 네트워크 속도가 엄청나게 빨라지고 서버 트래픽이 폭발적으로 증가하면서 발생했다. 예를 들어 초당 수십만~수백만 개 패킷이 들어오기 시작하면, NIC는 패킷마다 CPU 인터럽트를 계속 발생시키게 된다. 결국 CPU는 실제 애플리케이션 처리보다 인터럽트 대응 자체에 더 많은 시간을 쓰게 될 수도 있었다. 나도 처음에는 “인터럽트 처리 정도야 CPU가 금방 하지 않을까?”라고 생각했는데, 최신 서버 환경에서는 작은 패킷이 엄청난 속도로 들어오기 때문에 인터럽트 자체가 굉장히 큰 부담이 될 수 있다고 한다. 특히 CPU는 인터럽트가 발생할 때마다 현재 작업 흐름을 잠시 멈추고 네트워크 처리 루틴으로 이동해야 하기 때문에, 캐시 흐름과 파이프라인 효율까지 깨질 수 있다고 한다. 결국 CPU는 실제 중요한 계산보다 “패킷 왔다”는 알림 처리에 자원을 낭비하게 되는 것이다. 그걸 보고 처음으로 “고성능 서버에서는 데이터 처리보다 알림 처리 자체가 병목이 될 수도 있구나”라는 걸 느끼게 됐다.
Interrupt Coalescing은 인터럽트를 일부러 모아서 처리한다
Interrupt Coalescing의 핵심은 굉장히 흥미롭다. 바로 네트워크 카드가 인터럽트를 일부러 지연시키거나 묶어서 전달하는 방식이라는 점이다. 예를 들어 예전 방식에서는 패킷 하나마다 CPU를 깨웠다면, Interrupt Coalescing 구조에서는 NIC가 패킷 여러 개를 잠시 모아두었다가 한 번에 인터럽트를 발생시킨다. 쉽게 말하면 CPU를 너무 자주 깨우지 않도록 “패킷 묶음(batch)” 단위로 처리하는 느낌에 가깝다. 처음에는 나도 “그럼 데이터 처리 늦어지는 거 아닌가?”라는 생각이 들었다. 실제로 Interrupt Coalescing은 약간의 지연(latency)을 발생시킬 수도 있다. 하지만 서버 입장에서는 패킷마다 인터럽트를 발생시키는 것보다 CPU 부담을 훨씬 크게 줄일 수 있기 때문에 전체 처리량(throughput)은 오히려 좋아질 수 있다고 한다. 특히 대규모 서버 환경에서는 CPU가 인터럽트 폭주에 빠지지 않도록 유지하는 게 굉장히 중요하기 때문에, 현대 NIC들은 대부분 Interrupt Coalescing 기능을 적극적으로 사용한다고 한다. 나도 처음에는 네트워크 카드가 단순히 데이터만 전달하는 장치인 줄 알았는데, 실제로는 CPU 부담까지 고려하면서 인터럽트 타이밍 자체를 최적화하고 있다는 점이 꽤 인상 깊었다. 특히 Linux 서버에서는 NAPI와 Interrupt Coalescing이 함께 동작하면서 네트워크 패킷 처리 효율을 훨씬 높여준다고 한다. 결국 현대 네트워크 최적화는 단순히 데이터를 빨리 보내는 문제가 아니라, CPU를 얼마나 효율적으로 쉬게 만들 수 있느냐에 훨씬 가까웠던 것이다.
현대 데이터센터는 Throughput과 Latency 사이 균형까지 고려한다
Interrupt Coalescing을 공부하면서 가장 흥미로웠던 부분 중 하나는 Throughput(전체 처리량)과 Latency(지연 시간) 사이의 균형 문제였다. 예를 들어 인터럽트를 너무 자주 발생시키면 CPU 부담이 커지고 전체 성능이 떨어질 수 있다. 반대로 너무 오래 묶어서 처리하면 응답 지연이 커질 수 있다. 즉, 단순히 “인터럽트를 줄이면 무조건 좋다”가 아니라 서버 목적에 따라 최적의 균형점을 찾아야 하는 것이다. 예를 들어 대용량 파일 다운로드 서버처럼 Throughput이 중요한 환경에서는 인터럽트를 많이 묶는 게 유리할 수 있다. 하지만 실시간 게임 서버나 초저지연(low latency) 트레이딩 시스템 같은 경우는 아주 짧은 지연조차 중요하기 때문에 Interrupt Coalescing 설정을 다르게 가져가기도 한다고 한다. 나도 처음에는 서버 최적화라는 게 그냥 CPU 성능 높이는 문제인 줄 알았는데, 실제로는 네트워크 카드 인터럽트 타이밍까지 조절하면서 CPU와 지연 시간을 균형 맞추는 굉장히 복잡한 세계라는 걸 느끼게 됐다. 특히 지금까지 공부했던 DMA, NAPI, Epoll, Zero-Copy 같은 구조들을 보면 전부 공통점이 있었다. 바로 CPU가 불필요한 작업에 시간을 쓰지 않게 만드는 방향이라는 점이다. Interrupt Coalescing 역시 결국 같은 흐름 위에 있었다. 현대 서버는 단순 계산 속도 경쟁이 아니라, 얼마나 CPU를 효율적으로 사용하고 네트워크 흐름을 안정적으로 유지할 수 있느냐가 핵심이 된 것이다.
한 줄로 정리하면 Interrupt Coalescing은 네트워크 카드가 여러 패킷을 묶어서 한 번에 인터럽트를 발생시키는 기술이며, 인터럽트 폭주를 줄여 CPU 부담을 낮추고 고속 네트워크 환경에서 서버 처리량을 높이는 중요한 최적화 방식이다.