일본 IDC 물리 서버 운영 시 멀티코어 환경에서 네트워크 인터럽트 쏠림 현상을 진단하고 smp_affinity, RPS, RFS 커널 설정을 통해 패킷 처리 병목을 해소하는 실무 가이드입니다.
고성능 물리 서버를 일본 IDC 환경에서 운영할 때 네트워크 트래픽 증가로 인해 특정 CPU 코어의 사용량이 급증하고 패킷 드롭이 발생하는 현상을 접할 수 있습니다. 멀티코어 시스템에서는 네트워크 인터페이스 카드(NIC)가 들어오는 패킷을 처리하기 위해 CPU에 하드웨어 인터럽트(IRQ)를 발생시키는데, 기본 커널 설정에서는 이 인터럽트가 특정 CPU 코어에 집중되는 경향이 있습니다.
특정 코어만 높은 CPU 점유율을 기록하고 나머지 코어는 여유가 있는 비대칭 상태가 지속되면 처리 지연과 패킷 유실로 이어집니다. 이러한 병목 현상은 물리 서버의 하드웨어 리소스를 효율적으로 활용하지 못하게 하므로, 커널 레벨에서 인터럽트를 분산시키는 처리 체계가 필요합니다.
네트워크 인터럽트 편중 현상과 패킷 처리 병목의 이해
네트워크 트래픽이 수신되면 NIC는 하드웨어 인터럽트를 신호로 보내 CPU가 수신 버퍼의 데이터를 처리하도록 요청합니다. 이때 단일 CPU 코어가 모든 하드웨어 인터럽트 및 소프트웨어 인터럽트(SoftIRQ)를 전담하게 되면 해당 코어의 처리 능력이 한계에 도달하여 시스템 전체 패킷 처리량이 제한될 수 있습니다.
특히 수신 패킷 수(PPS)가 높은 웹 서비스나 API 서버 환경에서는 코어 간 부하 불균형이 네트워크 지연으로 직결됩니다. 따라서 시스템 운영자는 커널과 NIC 간의 인터럽트 전달 구조를 이해하고 수동 또는 자동 분산 체계를 구성해야 합니다.
CPU smp_affinity 설정을 통한 하드웨어 인터럽트 분산
하드웨어 인터럽트 분산의 첫 번째 단계는 NIC의 IRQ 번호를 확인하고 각 IRQ가 지정된 CPU 코어에서 처리되도록 smp_affinity 또는 smp_affinity_list 파라미터를 설정하는 것입니다.
1. IRQ 번호 및 패킷 수신 큐 확인
/proc/interrupts 파일을 조회하여 사용 중인 네트워크 카드의 IRQ 할당 상태를 점검합니다. Multi-queue를 지원하는 NIC의 경우 큐 개수만큼 IRQ가 분할되어 존재하는지 확인해야 합니다.
2. smp_affinity 비트마스크 설정
/proc/irq/{IRQ_NUMBER}/smp_affinity 파일에 CPU 코어 비트마스크를 지정하여 특정 IRQ 요청을 처리할 코어를 지정합니다. 예를 들어 multi-queue NIC의 각 큐를 개별 코어에 1:1로 매핑하면 특정 코어로의 하드웨어 인터럽트 쏠림 현상을 예방할 수 있습니다.
3. irqbalance 데몬 동작 점검
시스템에 irqbalance 데몬이 활성화되어 있다면 수동으로 지정한 smp_affinity 설정이 재조정될 수 있습니다. 정교한 코어 바인딩 체계를 운영하는 환경에서는 irqbalance 서비스를 비활성화하거나 특정 IRQ를 예외로 등록하는 사전 검토가 필요합니다.
소프트웨어 기반 패킷 분산: RPS 및 RFS 설정
단일 수신 큐만을 지원하는 NIC를 사용하거나, 하드웨어 큐 개수보다 CPU 코어 수가 많은 서버 환경에서는 하드웨어 분산만으로 한계가 존재합니다. 이때 Linux 커널의 RPS(Receive Packet Steering)와 RFS(Receive Flow Steering) 기능을 병행 활용합니다.
RPS(Receive Packet Steering) 적용 방안
RPS는 수신된 패킷을 커널 내부 소프트웨어 단에서 여러 CPU 코어로 분산시키는 기술입니다. /sys/class/net/{interface}/queues/rx-0/rps_cpus 파일에 소프트웨어 인터럽트를 처리할 CPU 비트마스크를 지정하여 SoftIRQ 부하를 분산시킬 수 있습니다.
RFS(Receive Flow Steering) 및 소켓 연동
RPS가 해시 기반으로 패킷을 코어에 무작위 분산한다면, RFS는 해당 소켓 애플리케이션이 실제 실행 중인 CPU 코어를 추적하여 패킷을 전달합니다. 이를 통해 CPU 캐시 미스(Cache Miss)를 줄이고 컨텍스트 스위칭 비용을 절감하는 효과를 기대할 수 있습니다. RFS 적용 시 sysctl의 rps_sock_flow_entries와 각 큐의 rps_flow_cnt 설정을 함께 상향 조정해야 합니다.
NIC 하드웨어 Offloading과 Interrupt Coalescing 연동
커널 파라미터 최적화와 더불어 네트워크 카드의 하드웨어 Offloading 기능 제어도 함께 검토해야 합니다.
1. Interrupt Coalescing (ethtool -C)
인터럽트 조절 기능은 패킷이 수신될 때마다 즉시 IRQ를 발생시키지 않고 일정 시간이나 패킷 개수만큼 모아서 처리하는 방식입니다. 지나치게 높은 인터럽트 발생 빈도를 줄여 CPU 점유율을 대폭 낮출 수 있지만, 대기 시간이 너무 길어지면 네트워크 응답 지연을 유발할 수 있으므로 워크로드 특성에 맞게 조율해야 합니다.
2. LRO / GRO 기능 확인
Large Receive Offload(LRO)나 Generic Receive Offload(GRO)는 여러 패킷을 하나의 큰 데이터 단위로 합쳐 커널에 전달함으로써 처리 효율을 높입니다. 대용량 트래픽 처리 시 유용하지만, 방화벽이나 패킷 포워딩 장비로 작동하는 서버 환경에서는 동작 방식을 사전에 검증해야 합니다.
물리 서버 네트워크 성능 최적화 체크리스트 및 비교
시스템 환경 및 하드웨어 구성에 따라 적용해야 하는 기술의 우선순위가 달라질 수 있습니다. 아래 표는 각 기술별 주요 기능과 적용 타겟을 정리한 내용입니다.
| 최적화 기법 | 주요 역할 | 적용 대상 환경 | 고려해야 할 사항 |
|---|---|---|---|
| smp_affinity | 하드웨어 IRQ를 특정 CPU 코어에 고정 | Multi-queue 지원 NIC 환경 | irqbalance 데몬 설정과의 충돌 여부 |
| RPS | SoftIRQ 패킷 처리를 여러 코어로 분산 | Single-queue NIC 또는 대규모 멀티코어 | CPU 소프트웨어 처리 오버헤드 검토 |
| RFS | 소켓 애플리케이션 실행 코어로 패킷 전달 | 응답 속도에 민감한 Latency-sensitive 서비스 | 소켓 흐름 테이블 메모리 사용량 증가 |
| Interrupt Coalescing | IRQ 발생 주기를 조정하여 CPU 부하 경감 | 고트래픽 패킷 수신 서버 | 네트워크 패킷 대기 지연 시간 변화 점검 |
HARU IDC 물리 서버 호스팅 환경에서는 고객의 트래픽 패턴과 서버 사양에 맞춰 네트워크 인터럽트 구조와 NIC 하드웨어 설정을 안전하게 검증할 수 있는 인프라 여건을 제공합니다.
실무 운영 관점에서의 고려사항 및 결론
네트워크 인터럽트 최적화는 단순히 커널 파라미터를 변경하는 것에 그치지 않고, 시스템의 NUMA(Non-Uniform Memory Access) 아키텍처까지 함께 고려해야 최적의 성능을 낼 수 있습니다. NIC가 물리적으로 연결된 PCIe 슬롯과 동일한 NUMA 노드에 속한 CPU 코어로 IRQ 및 RPS를 지정해야 노드 간 메모리 접근으로 인한 지연을 최소화할 수 있습니다.
또한 설정 적용 후에는 nstat, mpstat, /proc/net/softnet_stat 등의 모니터링 도구를 활용하여 SoftIRQ 드롭이나 패킷 유실 여부를 지속적으로 모니터링해야 합니다. 수치를 일률적으로 적용하기보다는 서비스의 트래픽 흐름을 점검하며 단계적으로 적용하는 실무 절차가 권장됩니다.
HARU IDC의 엔지니어링 지원 체계와 물리 서버 운영 노하우를 바탕으로, 일본 리전 인프라에서 발생할 수 있는 네트워크 병목 현상을 체계적으로 진단하고 안정적인 서비스 운영 환경을 구현할 수 있습니다.
CDN과 글로벌 전송 구성이 필요하신가요?
원본 서버, DNS, CDN, 보안 구성을 서비스 환경에 맞춰 함께 검토해드립니다.