수신 측 스케일링이 홈 서버 네트워크 부하를 어떻게 분산시키나요?

수신 측 스케일링(Receive-Side Scaling, RSS)은 들어오는 흐름을 해싱하여 여러 NIC 수신 큐에 분산시키고, 각 큐를 서로 다른 CPU 코어와 연결함으로써 홈 서버 네트워크 부하를 분산합니다. 하나의 코어가 거의 모든 수신 인터럽트와 프로토콜 작업을 처리하는 대신, 여러 코어가 독립적인 연결을 병렬로 처리할 수 있습니다.

RSS는 서버가 한 코어가 한계에 도달할 만큼 충분한 패킷을 받을 때 가장 유용합니다. 단일 디스크를 더 빠르게 만들거나 네트워크 용량을 늘리거나 하나의 일반적인 TCP 흐름을 모든 코어에 고르게 나누지는 않습니다. RSS의 역할은 흐름 순서를 유지하면서 패킷 처리 병목 현상을 제거하는 것입니다.

핵심 메커니즘: 여러 수신 큐가 여러 코어에 작업을 전달

멀티 큐 수신 처리가 없으면, 빠른 NIC가 하나의 인터럽트 경로에 작업을 너무 빨리 전달하여 한 CPU 코어가 이를 처리하지 못할 수 있습니다. 다른 코어가 유휴 상태여서 전체 CPU 사용률은 낮아 보일 수 있지만, 처리량은 정체되고 과부하된 코어에서 네트워크 지연이 증가합니다.

RSS는 여러 수신 큐를 사용하여 들어오는 흐름을 동시에 처리할 수 있게 합니다. 각 큐는 자체 인터럽트와 처리 경로를 생성하여 운영 체제가 이미 존재하는 CPU 자원을 더 많이 활용할 수 있게 합니다.

이는 파일 공유, 미디어 스트림, 백업, 컨테이너 앱을 동시에 실행하는 홈 서버에서 중요합니다. 이러한 독립적인 연결들이 RSS가 필요로 하는 병렬 작업을 제공합니다. 반면, 가볍게 사용되는 1GbE 링크는 차이를 느끼기 어려울 수 있습니다.

흐름 해싱은 연결을 분산시키면서 순서를 유지

NIC는 출발지 및 목적지 주소, 포트, 프로토콜과 같은 패킷 헤더 필드에서 해시를 계산합니다. 간접 테이블이 이 해시를 수신 큐에 매핑합니다. 동일한 흐름의 패킷은 보통 같은 큐에 도달하여 병렬 처리가 흐름 순서를 바꾸지 않도록 합니다.

RSS, IRQ 친화성, RPS 간의 관계는 Linux에서 실제 작업이 어디서 실행되는지를 결정합니다. 하드웨어 RSS는 수신 큐를 선택하고, 인터럽트 친화성은 그 큐를 CPU에 연결하며, 소프트웨어 스티어링은 하드웨어 큐가 제한적일 때 이후 프로토콜 작업을 재분배할 수 있습니다.

해싱은 많은 흐름을 통계적으로 균형 있게 분산하지만 완벽하지는 않습니다. 몇몇 무거운 흐름이 하나의 큐에 충돌할 수 있고, 하나의 지배적인 흐름은 한 코어에 묶일 수 있습니다. 그래서 멀티 코어 CPU가 네트워크 부하를 고르게 분산한다고 가정하기보다는 코어별, 큐별 관찰이 더 유용합니다.

큐 수가 많아지면 병목 완화와 CPU 오버헤드 간의 균형 필요

큐 수를 늘리면 병렬 처리 기회가 많아지지만, 인터럽트, 작업 스케줄링, 캐시 이동도 증가합니다. 최적의 큐 수는 NIC 성능, CPU 토폴로지, 트래픽 속도, 패킷을 소비하는 애플리케이션이 수신 처리 근처에서 실행되는지 여부에 따라 달라집니다.

단일 코어 수신 포화에 대한 실용적인 설명은 전체 CPU 사용률이 실제 한계를 숨길 수 있음을 보여줍니다. 유용한 테스트는 한 코어가 인터럽트나 소프트 IRQ 작업에 묶여 있고 다른 코어들이 여유가 있는지 여부입니다.

트래픽이 너무 적어 RSS가 필요하지 않은 경우에는 오버헤드가 증가할 수도 있습니다. 병렬 패킷 분배는 확장성을 개선하지만, 큐 배치와 흐름-코어 지역성은 여전히 효율성에 영향을 미칩니다. 따라서 가능한 모든 큐를 활성화하는 것이 항상 최적화는 아닙니다.

RSS가 홈 서버 병목 현상을 어떻게 바꾸는가

RSS는 수신 경로가 CPU에 묶여 있을 때 도움이 됩니다: 한 코어가 높은 네트워크 처리 부하를 보이고, 여러 클라이언트가 활성화되어 있으며, 저장 장치는 여유가 있을 때입니다. 이더넷 링크가 포화 상태이거나 디스크가 작업 부하를 감당하지 못하거나 암호화가 CPU 시간을 지배하거나 하나의 애플리케이션이 모든 요청을 직렬 처리할 때는 도움이 되지 않습니다.

NIC 큐 카운터, 코어별 인터럽트 부하, 처리량, 애플리케이션 지연을 제어된 변경 전후로 비교하세요. 더 넓은 홈 서버 병목 현상 점검은 네트워크 튜닝 변경이 저장소, 메모리, 컴퓨트 제약을 가리는 것을 방지하는 데 도움이 됩니다.

자주 묻는 질문

RSS가 하나의 TCP 연결을 모든 코어에 나누나요?

보통 그렇지 않습니다. RSS는 순서를 유지하기 위해 하나의 흐름에서 오는 패킷을 같은 큐에 유지합니다. 여러 독립적인 흐름이 여러 큐에 해싱될 때 확장 효과가 가장 분명합니다.

1GbE 홈 서버에서 RSS가 유용한가요?

특히 작은 패킷이 많거나 저전력 CPU를 사용할 때 유용할 수 있지만, 많은 시스템은 1GbE를 한 코어에서 처리할 수 있습니다. RSS를 성능 향상의 필수 기능으로 보기 전에 코어별 부하를 측정하세요.

RSS와 RPS는 같은 것인가요?

아닙니다. RSS는 NIC 하드웨어에서 패킷을 수신 큐로 분배하고, 수신 패킷 스티어링(Receive Packet Steering, RPS)은 소프트웨어에서 관련 분배 단계를 수행합니다. 하드웨어 큐 수가 제한적일 때 서로 보완할 수 있습니다.