저지연 애플리케이션에 대한 요구가 증가하는 현재 로드밸런서에게 있어서 네트워크 성능은 중요한 체크포인트가 되었습니다. 모든 타입의 워크로드 앞단에 배치되는 로드밸런서의 특성상, 로드밸런서의 성능은 전체 서비스의 네트워크 성능과 연관이 깊습니다. 이 포스트에서는 AWS Graviton 2 위에서 LoxiLB를 돌린 뒤 Throughput, 최소 및 평균 대기 시간, 초당 연결 수(CPS) 및 초당 요청 수(RPS)와 같은 네트워크 성능 수치에 대해 논의하려고 합니다. 벤치마크 테스트를 위해 동일한 EC2 인스턴스에서 LoxiLB 와 IPVS, Haproxy와 같이 비교 분석을 했습니다. AWS Graviton 2 프로세서는 최적화된 성능과 비용을 위해 설계한 맞춤형 실리콘인 64bit arm Neoverse 코어 기반으로 작동합니다. 이번 벤치마킹 테스트에서 Arm프로세서를 선택한 이유는 와트당 성능과 계산 효율성이 좋고 실제 엣지를 돌리는데 전력 소비에 있어서 가장 적합하기 때문입니다.
Graviton2 EC2 인스턴스를 실행하기 위해서 우리는 아래 대시보드에 나온 인스턴스 타입을 사용했습니다. (m6g.metal 인스턴스입니다.) :
LoxiLB 설치 및 테스트를 위해 여기에 있는 스크립트를 사용했습니다.
Network Topology
이번 테스트를 위해 사용한 간단한 네트워크 토폴로지입니다. 3개의 엔드포인트를 만들었고 여기에 netserver 서비스를 로드밸런서 뒤에서 실행했습니다. 로드밸런서는 트래픽을 라운드 로빈 방식으로 분산하여 엔드포인트에 전송합니다. 소프트웨어 성능을 평가하기 위해 클라이언트, 로드밸런서 및 워크로드를 실행하기 위해 단일 AWS Graviton-2 기반 EC2 인스턴스(m6g, arm64, 64 vCPU)를 사용했습니다. 동일한 환경에서 LoxiLB와 IPVS 및 haproxy를 비교합니다. iperf(Throughput 측정용)와 netperf(CPS, RPS 및 지연 시간 측정용) 같은 일반적인 성능 측정 툴을 사용했습니다.
Throughput(처리량)
가장 일반적인 성능 지표인 Throughput 벤치마킹 테스트 부터 시작하겠습니다. 트래픽을 처리하는 로드밸런서의 용량과 관련하여 Throughput을 확인하는 것은 중요한 메트릭이 됩니다. 로드밸런서가 들어오는 트래픽을 모두 처리할 수 없으면 병목 현상(보틀넥)이 발생하기 때문입니다. 테스트의 주요 목표는 처리량을 확인하는 것이기 때문에 테스트 응용 프로그램은 사이즈가 크고 패킷을 수를 적게 해서 테스트를 진행했습니다.
iperf를 사용하여 100개의 TCP 스트림에 대해 LoxiLB, IPVS 및 haproxy를 비교했습니다.
LoxiLB가 약 533Gbps의 최대 처리량을 달성했습니다. IPVS는 500Gbps를 조금 넘고 Haproxy는 그 반절도 도달하지 못했습니다. LoxiLB는 eBPF 기반 코어 엔진으로 구성되어있기 때문에 가장 높은 처리량을 보여 줍니다. LoxiLB의 엔진은 리눅스 커널 스택의 TC 계층에서 작동하며, 패킷이 모든 네트워크 계층을 거치지 않고 동일한 계층에서 처리되고 전송됩니다. IPVS의 경우 커널 수준에서 실행되지만 전체 커널 스택을 통과하는 것을 피할 수 없습니다. 따라서 더 많은 프로세스의 처리가 필요하게 되었고, 결과적으로 처리량이 낮아졌습니다. Haproxy는 User Plane에서 모든 것을 하기 때문에 가장 많은 프로세스 처리가 필요하며 그 결과 가장 낮은 성능을 보여줍니다.
Connections per second
CPS(Connections per second)는 L4 Stateful 로드밸런서의 가장 중요한 메트릭입니다. 이 메트릭은 초당 설정(추적 및 등록)할 L4 연결 수를 나타냅니다. ConnTrack 테이블/캐시에 넣기 전에 연결을 확인해야 하기 때문에 새로운 연결을 추적하는 것은 일반적으로 비용이 많이 듭니다. 따라서 로드밸런서가 연결을 얼마나 빨리 추적할 수 있는지가 가장 중요한 성능 지수 중 하나가 됩니다.
이 테스트를 위해 TCP_CRR 옵션을 준 netperf를 사용했습니다. 각 연결/트랜잭션에 대해 netperf는 TCP 연결을 열고 요청 및 응답을 교환한 다음 연결을 닫습니다. 즉, 각 트랜잭션에 대해 새로운 연결이 생성됩니다.
이전 Throughput 테스트에서는 LoxiLB가 IPVS에 비해 5% 정도 앞선 성능을 보여줬지만 이번 테스트에서는 성능 차이가 상당히 크게 나왔습니다. LoxiLB가 월등한 차이를 보여줍니다. 이런 결과가 나오는 이유는 Throughput 테스트와 마찬가지입니다. LoxiLB의 eBPF 기반 코어 엔진은 연결을 더 빠르게 추적하므로 IPVS 및 haproxy보다 더 좋은 성능을 보여줍니다.
Requests per second
이 테스트는 네트워크 패킷을 얼마나 빠르고 효율적으로 처리하는지 확인합니다. 하나의 Conntrack에서 요청을 처리하기 때문에 로드밸런서에 대한 부하를 줄일 수 있습니다. 패킷을 더 빨리 처리할 수 있는 애플리케이션은 분명 더 낮은 Latency을 제공할 것입니다. 이 테스트에서는 로드밸런서의 패킷 처리 능력을 확인하기 위해 점진적으로 패킷을 전송합니다.
이 테스트를 위해 TCP_RR 옵션을 준 netperf를 사용했습니다.
이전 테스트와 동일하게 100개의 Stream을 만들어서 트래픽을 전송했습니다.
LoxiLB가 IPVS, Haproxy보다 더 효율적으로 요청을 처리하는 것을 확인 할 수 있었습니다.
Minimum and Average Latency
이전 세션에서 초당 연결수가 낮을수록 지연율 또한 낮아진다고 말했습니다. Netperf 테스트를 통해서 구한 실제 결과값에 대해서 알아보겠습니다.
결론
LoxiLB는 모든 벤치마킹 테스트에서 두각을 나타냅니다. 이러한 결과에 대한 명백한 이유는 LoxiLB eBPF 코어 엔진이 원스톱 상점처럼 패킷에 대해 모든 프로세스를 처리하기 때문입니다. 이미 eBPF코어 엔진에서 패킷이 처리가 되었기에 커널에서 다시 처리할 필요가 없습니다.
다시 말해, IPVS에서 패킷은 전처리 및 후처리를 위해 전체 커널 스택을 통과해야 하므로 불필요한 지연이 발생합니다. 그리고 Haproxy는 User Plane에서 실행되기 때문에 LoxiLB 또는 IPVS의 성능과 비교할 수 없을 정도로 높습니다.
Note: 이 벤치마크 테스트를 진행하는 동안 haproxy에서 "Connection reset by peer" 오류가 지속적으로 발생하는 것을 관측했습니다. 따라서 모든 테스트가 항상 실행되지는 않았습니다.
저희 블로그가 마음에 드셨기를 바랍니다. 조만간 클라이언트, 로드밸런서 및 워크로드가 별도의 서버에서 실행되는 다중 노드 시나리오에 대한 결과도 발표할 예정입니다.
더 많은 정보는 아래를 참조해주세요:
Commentaires