인터럽트 스케줄링 (Interrupt Scheduling)

핵심 인사이트 (3줄 요약)

본질: 인터럽트 스케줄링 (Interrupt Scheduling)은 하드웨어가 발생시키는 수많은 비동기적 인터럽트 신호(IRQ)들을 운영체제가 어떤 코어에, 어떤 우선순위로, 언제 분배하여 처리할 것인지 결정하는 커널 최하단부의 자원 분배 메커니즘이다.

가치: 인터럽트 처리가 특정 코어에만 몰리면 해당 코어의 사용자 프로세스가 굶어 죽는 현상(Livelock)이 발생하므로, 이를 다수의 코어로 분산(IRQ Load Balancing)시켜 시스템 전체의 대역폭과 네트워크 처리량(Throughput)을 극한으로 끌어올린다.

융합: 고속의 네트워크 카드(100Gbps NIC) 환경에서 인터럽트 폭풍(Interrupt Storm)을 방어하기 위해 리눅스는 수신 패킷 처리를 인터럽트(Top Half)와 스레드(Bottom Half)로 쪼개고, **NAPI(병합 폴링)**와 **RPS/RFS(Receive Packet Steering)**를 통해 인터럽트 스케줄링 패러다임을 혁신했다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 마우스 클릭, 디스크 읽기 완료, 네트워크 패킷 도착 등 하드웨어는 CPU에게 즉각적인 처리를 요구하며 인터럽트(Interrupt)를 쏜다. 이때 다중 코어 시스템에서 "어느 코어가 이 인터럽트를 받아 ISR(인터럽트 서비스 루틴)을 실행할지" 동적으로 라우팅하고 분배하는 기술을 뜻한다.
필요성: 싱글 코어 시절에는 무조건 0번 코어가 인터럽트를 다 맞았다. 하지만 멀티 코어 시대에 초당 100만 개의 패킷이 들어올 때 0번 코어 혼자 인터럽트를 다 처리하면, 0번 코어는 100% 커널 모드(sy)에 갇혀 사용자 앱(us)을 돌리지 못하고 뻗어버리며, 나머지 1~7번 코어는 할 일이 없어 노는 기형적인 로드 임밸런스(Load Imbalance)가 발생한다.
💡 비유: 대형 식당에서 손님(하드웨어)이 벨(인터럽트)을 눌렀을 때, '매니저 1명(코어0)만 혼자서 하루 종일 뛰어가서 주문을 받을지', 아니면 '벨이 울릴 때마다 10명의 웨이터(다중 코어)에게 번갈아 가며 주문을 받으라고 분배할지' 정하는 홀 매니징 시스템과 같다.
등장 배경: 과거 1Gbps 랜카드 시절에는 CPU가 버틸 만했으나, 10Gbps, 100Gbps 대역폭 시대가 열리며 '인터럽트 처리 자체의 오버헤드'가 전체 서버 성능을 깎아먹는 최대 주범으로 등극했다. 이를 타파하기 위해 하드웨어적 인터럽트 분배(APIC)와 소프트웨어적 큐잉(NAPI)이 융합하며 발전했다.

  [단일 코어 집중 vs 다중 코어 인터럽트 분산 (IRQ Balancing)]

  (1) 안 좋은 예: 인터럽트 0번 코어 쏠림 (Interrupt Storm)
  [ NIC (랜카드) ] ── (패킷 10만 개 도착) ──▶ [ 코어 0 ] 🚨 (CPU 100% 포화, 터짐)
                                            [ 코어 1 ] (0%)
                                            [ 코어 2 ] (0%)

  (2) 좋은 예: 인터럽트 스케줄링 (IRQ Affinity 분산)
  [ NIC (랜카드) ] ─┬─ (패킷 3만 개) ────▶ [ 코어 0 ] (30% 부하)
   (다중 큐 지원)   ├─ (패킷 3만 개) ────▶ [ 코어 1 ] (30% 부하)
                   └─ (패킷 4만 개) ────▶ [ 코어 2 ] (30% 부하)
   >> 시스템 전체가 여유를 갖고 백엔드 사용자 애플리케이션을 돌릴 수 있다.

[다이어그램 해설] 초고성능 서버 튜닝의 첫걸음은 top 명령어를 쳤을 때 특정 코어의 si (소프트 인터럽트) 혹은 hi (하드 인터럽트) 수치만 100%를 치고 있는지 확인하는 것이다. 코어 1개에 인터럽트가 몰리면 다른 코어가 아무리 널널해도 시스템 네트워크 대역폭은 그 코어 1개의 한계에 갇혀버린다. 인터럽트를 찢어서 던지는 것이 스케줄링의 핵심이다.

📢 섹션 요약 비유: 택배(인터럽트)가 하루에 1만 개 오는데, 경비실 아저씨 1명(코어 0)한테만 전부 다 받으라고 하면 아저씨는 쓰러집니다. 택배차를 여러 동(멀티 코어)으로 흩어지게 해서 경비원 10명이 1천 개씩 나눠 받게 만드는 것이 인터럽트 스케줄링입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

하드웨어 레벨의 인터럽트 라우팅 (APIC)

x86 시스템에서는 인터럽트를 분배하기 위해 CPU 칩 외부에 **I/O APIC (Advanced Programmable Interrupt Controller)**라는 하드웨어 칩이 존재한다.

하드웨어(NIC 등)가 I/O APIC에 핀으로 전기 신호를 쏜다.
I/O APIC는 리눅스 커널이 미리 설정해 둔 '인터럽트 목적지 테이블(Redirection Table)'을 읽는다.
"아, 랜카드(IRQ 10) 신호는 CPU 코어 0, 1, 2, 3에게 라운드 로빈으로 쏴주라고 되어있네!" 하고 판단하여 특정 코어의 Local APIC로 신호를 전달한다.

리눅스의 Top Half 와 Bottom Half (인터럽트 쪼개기)

인터럽트를 받은 코어는 하던 일을 멈추고 ISR(Interrupt Service Routine)을 무조건 즉시 실행해야 한다. 이때 코어가 너무 오랫동안 묶여있으면 다른 급한 인터럽트를 놓친다. 그래서 리눅스는 인터럽트 처리를 두 동강 냈다.

Top Half (하드 인터럽트): "일단 패킷 도착했다고 ACK 쳐주고 메모리에 데이터만 툭 던져놓고 1ms 만에 끝낸다!" (즉시성, 선점 방어)
Bottom Half (소프트 인터럽트, Tasklet): Top Half가 던져놓고 간 패킷 데이터를 여유 있게 압축 해제하고 TCP/IP 스택으로 밀어 올리는 긴 작업. (일반 프로세스처럼 나중에 스케줄링되어 실행됨)

  ┌──────────────────────────────────────────────────────────────────────┐
  │         리눅스 인터럽트 처리의 이원화 구조 (Top & Bottom Half)       │
  ├──────────────────────────────────────────────────────────────────────┤
  │                                                                      │
  │   [ 1단계: Top Half (매우 빠름, 선점 불가 구역) ]                    │
  │   ▶ 랜카드가 패킷 도착 인터럽트(IRQ) 쏨                              │
  │   ▶ 코어가 하던 일 멈추고 NIC 버퍼에서 메모리(Ring Buffer)로 복사    │
  │   ▶ "나머지 긴 작업은 Bottom Half로 예약할게!" 하고 즉시 빠져나옴.   │
  │                                                                      │
  │   [ 2단계: Bottom Half (ksoftirqd 데몬 스케줄링) ]                   │
  │   ▶ 커널 스케줄러가 여유 있을 때 `ksoftirqd/0` (코어 0의 데몬)를 띄움│
  │   ▶ 예약된 패킷들을 꺼내서 TCP 스택 분석, 방화벽(iptables) 룰 검사   │
  │   ▶ 사용자 애플리케이션(Nginx) 소켓으로 데이터 전달 완료             │
  └──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 구조 덕분에 리눅스는 1초에 수십만 번의 인터럽트 폭격을 맞아도 커널이 완전히 얼어붙지 않는다. Top Half는 치고 빠지기의 달인이고, 진짜 무거운 계산은 Bottom Half 데몬(ksoftirqd)으로 위임하여, 일반 프로세스 스케줄러가 인터럽트 후속 작업마저 통제(스케줄링)할 수 있게 만든 천재적 설계다.

📢 섹션 요약 비유: 우체부(랜카드)가 소포를 가져왔을 때, 하던 일 멈추고 1초 만에 문만 열어서 현관에 툭 던져두는 게 Top Half고, 주말에 시간 날 때 현관에 쌓인 박스 100개를 커터칼로 정성스레 뜯어서 거실(애플리케이션)로 옮기는 게 Bottom Half입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

인터럽트 처리 패러다임의 진화: NAPI (New API)

순수 인터럽트 방식의 치명적 결함은 **인터럽트 폭풍(Interrupt Storm)**이다. 초당 10만 개 패킷이 들어오면 10만 번의 잦은 문맥 교환이 발생하여(Livelock) 시스템이 아예 멈춘다. 이를 해결하기 위해 폴링(Polling)과 섞은 NAPI가 등장했다.

처리 방식	동작 원리	부하 시 시스템 상태
순수 인터럽트 (과거)	패킷 1개당 인터럽트 1번 발생	10만 개 오면 10만 번 인터럽트 발생. Livelock 발생 (사망)
순수 폴링 (Polling)	주기적으로 "패킷 왔어?" 계속 물어봄	패킷이 없을 때도 계속 물어보느라 CPU 100% 낭비
NAPI (하이브리드)	첫 패킷은 인터럽트로 받음. 그 이후 폭주하면 인터럽트를 끄고 폴링 모드로 전환하여 버퍼의 수천 개 패킷을 한 방에 퍼옴.	패킷이 없으면 조용(절약). 패킷 폭주 시 인터럽트 오버헤드 0으로 삭제. 극한의 효율

소프트웨어적 인터럽트 로드 밸런싱: RPS / RFS

하드웨어(랜카드 다중 큐)가 인터럽트를 코어별로 쪼개주지 못하는 저가형 랜카드를 쓸 때, 리눅스 커널이 소프트웨어로 가상의 다중 큐를 만들어 0번 코어에 들어온 패킷들을 1~7번 코어로 던져주는 기술이다.

RPS (Receive Packet Steering): 패킷의 IP/Port 해시값을 구해 1번, 2번, 3번 코어에 골고루 분배한다. (소프트웨어 라운드 로빈)
RFS (Receive Flow Steering): RPS보다 더 똑똑하다. 이 패킷을 받아서 최종적으로 처리할 Nginx 애플리케이션(스레드)이 3번 코어에서 돌고 있다면, 굳이 1번 코어에 안 주고 3번 코어에게 핀포인트로 패킷을 던져 캐시 적중률(Affinity)을 100%로 보장한다.
📢 섹션 요약 비유: NAPI는 첫 손님이 벨(인터럽트)을 누르면 매니저가 나가서 문을 활짝 열어놓고 수백 명을 줄 세워 한 번에 처리(폴링)하는 기법이고, RFS는 들어온 손님의 관상(IP/Port)을 보고 그 손님을 가장 잘 아는 전담 웨이터(특정 코어)에게 콕 집어 배정해 주는 지능형 매니징입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

Irqbalance 데몬의 튜닝 (끄느냐 마느냐): 범용 리눅스는 부팅 시 irqbalance라는 데몬을 띄워놓는다. 이 녀석은 10초마다 각 코어의 부하를 검사해서, 0번에 인터럽트가 몰리면 APIC 설정을 바꿔 1, 2, 3번으로 이사(Balancing)시켜 준다.
- 문제 발생: 고성능 DB(Redis, Oracle) 서버에서 이 데몬이 계속 인터럽트 목적지를 바꾸면, 패킷이 도착하는 코어와 연산하는 코어가 엇갈려 지독한 캐시 미스가 발생하고 응답 지연이 튄다.
- 실무 조치 (격리 전략): 초고도 성능 튜닝 시 엔지니어는 아예 systemctl stop irqbalance로 오지랖 데몬을 꺼버린다. 그리고 smp_affinity 파일을 직접 수정하여 랜카드 1번 큐는 코어 1번에, 2번 큐는 코어 2번에 영구적으로 수동 결박(Pinning)시킨다.
K8s 클라우드에서의 100G NIC / DPDK 커널 우회: 5G 통신망의 패킷 스위칭(UPF) 컨테이너는 초당 수천만 개의 패킷을 받아야 한다. 이때 NAPI든 RPS든 리눅스 커널 스케줄러가 개입하는 순간 아무리 잘 짜도 10G 이상의 대역폭을 감당 못 하고 병목이 걸린다.
- 아키텍처 결단: 패킷이 랜카드에 들어올 때 커널로 인터럽트를 쏘는 것(IRQ) 자체를 금지한다. 대신 유저 스페이스의 애플리케이션 스레드가 코어를 100% 독점한 상태로 랜카드 메모리(NIC RX Ring)를 직접 무한 폴링(Polling)하여 퍼 나른다. 이것이 인텔의 **DPDK (Data Plane Development Kit)**이자, 커널 인터럽트 스케줄링을 통째로 부정하고 우회(Bypass)하는 클라우드 네트워크 아키텍처의 정점이다.

  ┌───────────────────────────────────────────────────────────────────────┐
  │     고대역폭(10G+) 서버의 인터럽트 처리 성능 최적화 의사결정 트리     │
  ├───────────────────────────────────────────────────────────────────────┤
  │                                                                       │
  │   [서버 튜닝: Top 명령어 상 'si(softirq)'가 1개 코어에서 100% 임]     │
  │                │                                                      │
  │                ▼ 랜카드가 하드웨어 다중 큐(RSS)를 지원하는가?         │
  │      [지원함 (Multi-Queue NIC)]                                       │
  │       ├─▶ 조치 1: irqbalance 끄기                                     │
  │       └─▶ 조치 2: 각 NIC 큐별로 smp_affinity에 코어 1:1 매핑          │
  │                                                                       │
  │      [지원 안 함 (Single-Queue 저가형 NIC)]                           │
  │       ├─▶ 조치 1: 리눅스 커널 RPS/RFS 활성화 (`echo f > rps_cpus`)    │
  │       └─▶ 조치 2: 소프트웨어적으로 인터럽트 부하를 타 코어로 강제 산란│
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 리눅스 서버 운영의 가장 흔하면서도 치명적인 병목 해결법이다. 랜카드는 10G를 샀는데 다운로드 속도가 1G밖에 안 나온다면 100% 확률로 0번 코어 하나만 si 부하를 맞고 장렬히 전사한 것이다. 이를 여러 코어로 찢어주기만 하면(Affinity 튜닝) 별도의 하드웨어 추가 없이 속도가 4배, 8배로 선형 증가하는 마법을 볼 수 있다.

📢 섹션 요약 비유: 8차선 고속도로(10G 랜카드)를 뚫어놨는데 톨게이트 직원(인터럽트 처리 코어)이 1명뿐이라 차가 다 막힌 상태입니다. 직원을 8명 고용해서 각 차선에 세워두는(Affinity 매핑) 세팅을 해줘야 진짜 고속도로가 됩니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

인터럽트 스케줄링(IRQ Affinity, RPS/RFS)을 시스템 워크로드에 맞게 정밀하게 분산시키면, 특정 CPU 코어의 Livelock 마비를 막고, I/O 디바이스(NVMe, NIC)가 가진 물리적 최대 대역폭(Throughput)을 리눅스 커널 병목 없이 100%까지 극한으로 끌어올릴 수 있다.

결론 및 미래 전망

과거의 인터럽트 스케줄링은 "어떻게 하면 커널이 덜 아프게 인터럽트를 잘 받을까"에 집중했다. 하지만 데이터 단위가 TB(테라바이트), 100Gbps로 폭증하는 클라우드 환경에서는 **"인터럽트 자체가 죄악(Overhead)"**으로 규정되었다. 미래의 패러다임은 CPU가 인터럽트를 처리하는 대신, 스마트 랜카드(SmartNIC/DPU)가 내장된 ARM 코어로 직접 패킷을 까서 분산시키거나(하드웨어 오프로딩), eBPF(XDP) 기술을 통해 커널 스택 깊이 들어오기 전에 초입에서 패킷을 드롭(Drop)해버려 CPU 인터럽트 자체를 무효화하는 '제로 오버헤드(Zero Overhead)' 아키텍처로 진화하고 있다.

📢 섹션 요약 비유: 옛날엔 쏟아지는 스팸 우편(인터럽트)을 어떻게 직원 10명이 효율적으로 분리수거할지 고민했다면, 미래 기술은 아예 우체국(SmartNIC) 단에서 스팸 필터를 걸어 회사 문턱(CPU)으로 배달조차 못 하게 원천 차단하는 혁신적 방향으로 가고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
문맥 교환 (Context Switch)	인터럽트가 뜰 때마다 밥 먹듯이 발생하는 오버헤드로, 이 비용을 줄이는 것이 인터럽트 스케줄링의 알파요 오메가다.
NAPI (하이브리드 폴링)	인터럽트 폭풍에 맞아 죽을 뻔한 리눅스를 살려낸 구원투수로, 인터럽트와 무한 폴링의 장점만 스위칭하는 천재적 기법이다.
캐시 친화도 (Cache Affinity)	인터럽트(IRQ)를 아무 코어에나 뿌리지 않고, 패킷을 읽을 앱이 있는 특정 코어로만 쏴주는 이유(RFS)의 근본 원인이다.
DPDK (Data Plane Development Kit)	OS 커널의 인터럽트 스케줄링이 너무 무거워서, 아예 커널을 무시하고 유저가 직접 100% 독점해 패킷을 푸는 커널 바이패스 기술이다.
Top Half / Bottom Half	인터럽트가 커널을 너무 오래 멈추게 하는 걸 막으려고, 즉시 처리할 것과 나중에 할 것(Tasklet)을 반으로 쪼갠 설계다.

👶 어린이를 위한 3줄 비유 설명

엄마(CPU 코어 0번) 혼자 요리를 하고 있는데, 아빠, 언니, 오빠(하드웨어들)가 동시에 "밥 줘! 물 줘! 휴지 줘!" 하고 벨(인터럽트)을 마구 누르면 엄마가 쓰러지겠죠?
그래서 가족회의를 해서 인터럽트 스케줄링을 짰어요. 아빠 벨이 울리면 첫째 아들(코어 1번)이 가고, 언니 벨이 울리면 둘째 딸(코어 2번)이 가기로 규칙을 나눈 거예요.
이렇게 벨소리(인터럽트)를 여러 명에게 골고루 찢어서 분배해 주면, 엄마도 안 쓰러지고 가족들 심부름도 빛의 속도로 빨리 해결되는 평화로운 집이 된답니다!