Interrupt Coalescing은 네트워크 지연에 어떤 영향을 미칠까? 성능 최적화의 핵심 비밀
초고속 기가비트 네트워크 환경에서 서버의 성능을 극한으로 끌어올리다 보면, 시스템의 자원 효율성과 응답 속도라는 두 가지 가치가 정면으로 충돌하는 지점을 만나게 됩니다. 그 중심에 있는 대표적인 기술이 바로 Interrupt Coalescing(인터럽트 조합 또는 병합)입니다. 랜카드(NIC) 레벨에서 지원하는 이 기술은 CPU의 오버헤드를 줄이는 일등 공신이지만, 역설적으로 ‘네트워크 지연 시간(Latency)’에는 치명적인 독이 될 수도 있습니다. 본 포스팅에서는 Interrupt Coalescing의 동작 원리와 이것이 지연 시간에 미치는 양면성을 심도 있게 분석해 보겠습니다.
1. Interrupt Coalescing(인터럽트 조합)이란 무엇인가?
Interrupt Coalescing은 네트워크 카드(NIC)에 패킷이 도착할 때마다 CPU에 즉각 하드웨어 인터럽트(IRQ)를 발생시키지 않고, 일정 조건(패킷 수 또는 시간)이 충족될 때까지 인터럽트 발생을 의도적으로 지연시키고 모아서 한 번에 알리는 하드웨어 기술입니다.
과거 100Mbps 시절에는 패킷당 하나의 인터럽트를 처리하는 것이 문제가 없었으나, 10Gbps, 100Gbps 환경에서는 초당 수천만 개의 패킷(PPS)이 유입됩니다. 만약 패킷마다 인터럽트가 발생하면 CPU는 콘텍스트 스위칭(Context Switching) 오버헤드로 인해 아무런 연산도 하지 못하고 마비되는 ‘인터럽트 폭풍(Interrupt Storm)’을 겪게 됩니다. Interrupt Coalescing은 이러한 CPU의 비명을 막아주는 방어선입니다.
2. Interrupt Coalescing을 조절하는 두 가지 핵심 파라미터
NIC 드라이버는 보통 다음 두 가지 장치를 통해 인터럽트를 묶어서 터뜨립니다.
- 패킷 기반 임계치 (Packet-based Threshold): “패킷이 RX 링 버퍼에 10개 쌓이면 인터럽트를 한 번 걸어라.”
- 시간 기반 타이머 (Time-based Timer / Adaptive Moderation): “패킷이 하나라도 들어온 시점부터 50μs(마이크로초) 동안 기다렸다가, 그동안 모인 패킷들을 처리하도록 인터럽트를 걸어라.”
현대 고성능 랜카드들은 트래픽 양을 실시간으로 감지하여 이 두 값을 동적으로 조절하는 ‘Adaptive(적응형) Interrupt Moderation’ 기능을 기본적으로 탑재하고 있습니다.
3. Interrupt Coalescing이 네트워크 지연(Latency)에 미치는 영향
이 기술은 서버 전체의 처리량(Throughput)을 늘려주지만, 개별 패킷의 반응 속도인 지연 시간(Latency)에는 부정적인 영향을 미칩니다.
3.1 패킷 대기 지연(Packet Delay)의 발생
가장 먼저 도착한 패킷은 뒤이어 올 패킷들이나 설정된 타이머가 만료될 때까지 NIC의 링 버퍼에서 ‘대기’해야 합니다. 만약 타이머가 100μs로 설정되어 있다면, 해당 패킷은 아무런 이유 없이 네트워크 카드가 자기를 붙잡아둔 탓에 100μs만큼의 고정적인 지연 시간을 손해 보게 됩니다.
3.2 초저지연(Ultra Low Latency) 환경에서의 치명타
1분 1초가 아닌, 1μs 단위로 승패가 갈리는 HFT(고주파 주식 거래) 시스템, 실시간 금융 체결, 대규모 온라인 FPS 게임 서버 등에서는 이 미세한 대기 시간이 누적되어 서비스 품질 저하를 일으킵니다. 지연 시간의 가변성(Jitter) 또한 커지게 되어 안정적인 응답 속도를 보장하기 어렵습니다.
4. 처리량(Throughput) vs 지연 시간(Latency) 트레이드오프
Interrupt Coalescing 설정에 따른 시스템 성능 변화를 직관적으로 비교해 보았습니다.
| 구분 | Interrupt Coalescing 활성화 (기본값) | Interrupt Coalescing 비활성화 (Disable) |
|---|---|---|
| 개별 패킷 지연 (Latency) | 증가 (타이머/패킷 카운트만큼 대기) | 최소화 (패킷 도착 즉시 CPU 전달) |
| 지연 시간 변동성 (Jitter) | 상대적으로 높음 | 매우 낮음 (일정한 성능 보장) |
| CPU 점유율 (SoftIRQ 부하) | 낮음 (한 번에 묶어서 효율적 처리) | 매우 높음 (인터럽트 폭풍 위험) |
| 최대 처리량 (Throughput) | 높음 (대규모 트래픽 처리에 유리) | 낮음 (CPU 병목으로 패킷 드랍 발생 가능) |
| 적합한 서비스 환경 | 웹 서버, 파일 전송(FTP), 스트리밍 | 주식 거래(HFT), 게임 서버, 실시간 제어 |
5. 실무 엔지니어를 위한 튜닝 가이드
자신이 운영하는 서비스의 성격이 ‘초저지연 응답’을 최우선으로 한다면, 리눅스 커널과 NIC 드라이버 설정을 통해 이 값을 조정해야 합니다.
- 현재 상태 확인:
ethtool -c eth0명령어를 통해 현재 인터럽트 병합 설정을 확인합니다. - 실시간 적응형 모드 해제 및 지연 최소화:
ethtool -C eth0 adaptive-rx off adaptive-tx off ethtool -C eth0 rx-usecs 0 tx-usecs 0위 설정을 통해 대기 타이머를 0으로 만들면 패킷이 들어오는 즉시 인터럽트가 발생하여 지연 시간을 최소화할 수 있습니다.
- 주의사항: 이를 적용할 경우 CPU 코어 중 일부(네트워크 인터럽트를 담당하는 코어)의 점유율이 급격히 치솟을 수 있으므로, 반드시 RSS(Receive Side Scaling) 기술을 함께 적용하여 인터럽트 부하를 여러 코어로 분산시켜야 합니다.
결론: 정답은 없고 최적의 균형만 있을 뿐
과거 해외 금융 피드 수신 시스템을 구축할 때 간헐적으로 튀는 지연 시간 때문에 고생한 적이 있습니다. 범인은 NIC 드라이버의 Adaptive Coalescing 알고리즘이었고, 이를 강제로 끄고 rx-usecs를 0으로 튜닝한 뒤에야 99.9퍼센틸(p99) 지연 시간이 획기적으로 안정화되는 것을 목격했습니다.
Interrupt Coalescing이 네트워크 지연에 미치는 영향은 명확합니다. “CPU 자원을 아끼고 전체 파이프라인의 처리량을 올리는 대신, 개별 패킷의 즉각적인 반응성을 희생하는 것”입니다. 2026년 현재처럼 클라우드 네이티브와 마이크로서비스가 촘촘히 얽힌 구조에서는 미세한 하부 레이어의 지연이 전체 시스템의 레이턴시 스파이크로 이어질 수 있습니다. 무조건 설정을 켜거나 끄기보다는, 인프라의 CPU 여유 자원과 서비스가 요구하는 Latency SLA(서비스 수준 계약)를 면밀히 분석하여 가장 완벽한 타협점을 찾아내는 아키텍처적 감각이 필요합니다.