트래픽이 몰려도 끄떡없는
미래 데이터센터의 비결은 바로 ‘eNLB’

– 고성능 소프트웨어 로드밸런서 기술의 혁신

로드밸런싱, 지금 왜 다시 주목받는가?

IT기기의 보급 및 다양한 AI기반 서비스의 출현은 네트워크 트래픽의 폭발적 증가를 가속화하였습니다. 대량의 트래픽을 처리해야 하는 서비스들은 많게는 수십에서 수백 대의 서버풀을 구성해야 하고, 사용자들의 트래픽을 안정적이고 효율적으로 서버에게 분산해 주는 역할을 하는 기술이 바로 로드밸런싱입니다. 데이터센터에서는 일반적으로 하드웨어 로드밸런서를 사용하고 있지만, 최근에는 단위 시간당 패킷 처리량을 최대화할 수 있는 고성능 소프트웨어 로드밸런서에 대한 필요성이 증가하고 있습니다.

일반적으로 사용하는 소프트웨어 로드밸런서는 커널의 네트워크 스택에서 패킷을 처리하기 때문에 커널 스페이스와 유저 스페이스 간 메모리 복사와 인터럽트를 처리하기 위한 성능저하가 발생합니다. 그리고 로드밸런서가 수신한 대량의 패킷을 효율적으로 분배하기 위하여 사용자의 요청이 특정 서버에게 집중되지 않고 균일하게 분배되도록 보장되어야 합니다.

삼성SDS의 해결책: eBPF 기반 ‘eNLB’

본 연구에서는 로드밸런서에 입력되는 대량의 트래픽이 커널의 네트워크 스택에서 처리되기 전에 eXpress Data Path(XDP)에서 extended Berkeley Packet Filter(eBPF) 프로그램으로 패킷을 전달하여 성능을 향상시키고, Dynamic Load Balancing을 통해 패킷을 서버에 균일하게 분배하는 기술을 적용한 eBPF Network Load Balancer(eNLB)를 소개합니다.

eNLB는 커널스페이스에서 실행되는 eBPF 프로그램으로 그림1과 같이 Client로부터 eNLB를 거쳐 서비스 요청
패킷^* 을 전달받은 Server의 응답 방식에 따라 2가지 동작방식을 지원합니다. 하나는 eNLB를 거쳐 Client로 응답 패킷을 전달하는 Proxy 모드이고, 다른 하나는 eNLB를 거치지 않고 바로 Client에 응답 패킷을 전달하는 L3DSR(Layer 3 Direct Server Return) 모드입니다. 각 모드는 단순히 Server의 응답 패킷 처리뿐만 아니라 Client가 전송한 서비스 요청 패킷이 eNLB를 통해 Server로 최종 전달되기까지의 방식에서도 그 차이를 보입니다. * 패킷 : TCP 프로토콜의 데이터 단위 표현방식이나, 본 문서에서는 UDP 프로토콜의 데이터 단위인 데이터그램(Datagram)도 보편적으로 사용하는 패킷(Packet)으로 용어를 동일하게 적용

[그림1] Server의 응답방식에 따른 eNLB 동작모드

Proxy vs L3DSR - 두 가지 처리 방식

L3DSR 로드밸런싱은 물리적 회선 및 위치 등의 한계를 극복하기 위하여 로드밸런서와 서버 사이에 IP 터널링을 사용하며, 오리지널 패킷을 캡슐화하기 때문에 실효 MTU의 크기가 감소하는 특성을 가집니다. eNLB가 IP터널링을 사용하여 클라이언트로부터 수신한 패킷을 서버로 전달하면, 패킷을 전달받은 서버는 응답 패킷을 로드밸런서를 거치지 않고 클라이언트에게 리턴하는 방식으로 동작합니다. 따라서 Outbound Traffic이 로드밸런서로 전달되지 않아 로드밸런서의 리소스 소모를 줄이고 높은 대역폭을 유지함으로써 낮은 지연 시간을 보장합니다.

[그림2] L3DSR 모드에서의 패킷 흐름도

Proxy 모드에서 로드밸런싱 과정을 살펴보면, 그림3과 같이 기본적으로 eNLB에서 포워딩할 Server가 결정된 뒤, 서비스 요청 패킷을 Server로 NAT(Network Address Translation)^* 를 통해 넘기거나, Server로 전달된 서비스 요청 패킷에 대한 응답 패킷이 다시 eNLB로 유입되었을 때, 이를 Client에 전달될 수 있도록 NAT를 수행하게 됩니다.

Client가 Server로 전송한 서비스 요청 패킷이 최초로 eNLB에 유입되면, eNLB는 해당 패킷을 포워딩할 Server 쪽으로 Ingress NAT를 수행하기 위한 정책을 생성하고 이를 BPF Map에 등록합니다. 그리고 동시에, eNLB는 해당 Ingress NAT을 통해 서비스 요청 패킷을 받은 Server의 응답 패킷을 다시 Client에게 전달해주기 위한 Egress NAT 정책도 함께 생성해 등록합니다. 이 후부터는 BPF Map에 등록된 Ingress/Egress NAT 정책을 조회하여 로드밸런싱을 수행하게 됩니다. * NAT : IP패킷의 출발지/목적지 IP주소 및 포트번호를 재기록하여 네트워크 트래픽을 주고 받는 기술

[그림3] Proxy 모드에서 패킷 흐름도

지능형 트래픽 분산: Dynamic Load Balancing

로드 밸런서는 입력된 패킷을 빠르게 처리하는 것뿐만 아니라, 트래픽을 모든 서버에게 균일하게 분배하는 것 역시 중요합니다. 패킷이 서버에 고르게 분산되지 않고 특정 서버에 몰리게 되면 서비스의 latency가 증가하고 심각한 경우 서버에 장애가 발생할 수 있습니다.

Maglev Hashing은 lookup테이블 생성 시 모든 서버가 거의 같은 비율로 포함되어 클라이언트의 패킷이 서버에 균일하게 분산되는 것을 보장합니다. 하지만 특정 서버를 향하는 트래픽이 급격하게 증가하는 등 런타임 시에 발생하는 부하 불균형 문제를 해결할 수 있는 방안은 제시하지 못합니다.

L4 로드 밸런서는 초당 수만~수백만개의 패킷을 실시간으로 처리하기 때문에 트래픽을 고르게 분산하기 위해 연산량이 많은 머신러닝이나 AI기반 모델링을 통한 개선은 적합하지 않습니다. 사용자의 트래픽은 실시간으로 변하며 모델 기반 예측은 실데이터에 후행하는 문제가 발생할 수 있습니다. 따라서, eNLB는 런타임 시 각 서버가 수신하는 부하의 불균형을 측정하고 이를 기반으로 rebalancing을 수행합니다.

패킷을 균일하게 분산하기 위해 서버 별 가중치를 도출하고 로드 밸런싱을 수행하면 서버 별로 수신하는 트래픽의 fairness가 향상됩니다.

[그림4] 알고리즘 별 서버에 분산되는 패킷 예시

성능 실험 - 얼마나 빠르고 효율적인가

먼저 로드밸런서 간 성능 비교를 위해 eNLB와 cilium에 부하를 발생시켜 단위 시간 당 처리되는 사용자의 요청 수와 지연시간을 측정하였습니다. 벤치마크 결과 eNLB는 L3DSR 방식과 Proxy 방식에서 cilium 대비 동일 단위 시간 내 더 많은 패킷을 처리하였습니다.

[그림5] eNLB와 cilium 간 성능 비교 (higher is better)

그리고 평균 지연시간 역시 L3DSR 방식과 Proxy 방식 모두에서 개선된 결과를 확인할 수 있었습니다.

[그림6] eNLB와 cilium 간 지연시간 비교(lower is better)

Cilium 대비 성능을 크게 개선할 수 있었던 이유는 패킷 처리 시 BPF Map 참조 횟수를 최소화하도록 설계하고, 패킷 처리 시 커널 함수를 사용하는 대신 포인터로 데이터에 직접 접근함으로써 성능개선을 달성할 수 있었습니다.

두번째로 Dynamic Load Balancing을 통해 런타임 시에 서버에 부하가 균일하게 분산되는 것을 실험하기 위해, Maglev Hashing만 구현한 대조군과 Rebalancing까지 구현한 실험군을 대상으로 테스트를 진행하였습니다.

일정 시간동안 트래픽을 발생시킨 후 서버 별로 수신한 트래픽의 양을 분석한 결과 Maglev Hashing 알고리즘만 사용했을 때 보다 Rebalancing을 같이 사용했을 때 로드 밸런서가 패킷을 더 균일하게 분산하는 것을 확인할 수 있었습니다.

[그림7] 알고리즘 별 서버에 분배된 사용자 요청 분포도

연구의 의의

이 연구는 소프트웨어 로드 밸런서의 성능 향상을 위하여 패킷이 커널의 네트워크 스택에서 처리되기 전에 XDP레이어에서 eBPF로 구현한 eNLB를 통해 빠르게 처리되는 것을 확인하였습니다. 그리고 Maglev hashing의 한계를 극복하기 위하여 런타임 시 부하 불균형이 발생하는지 판단하고, rebalancing을 수행하여 부하가 특정 서버로 몰리지 않고 균일하게 분산되는 것을 확인하였습니다. 본 연구결과를 통해 소프트웨어 로드 밸런서의 성능향상에 기여할 수 있기를 기대합니다.