로드밸런서 알아보기

서비스를 운영하다보면 초기에는 단일 서버만으로도 충분하지만 조금씩 부하가 생길 수 있어요. 이건 단순히 실제 서비스 사용자의 요청 뿐만 아니라 서비스 내부적인 여러 서버 간 통신 구조에서도 발생할 수 있죠. 사용자가 요청한 서버 이외에 다른 연계된 서버에 부하도 분산할 필요가 있어요. 이때 우리는 로드 밸런싱(부하 분산) 기능이 포함된 미들웨어를 도입해요.

로드밸런서가 필요한 이유

서비스에 사용자 요청이 많아지면 단순하게 서버 성능을 높이는 스케일 업 을 시도할 수 있어요. 그러다가, 서버 성능을 올리는 비용보다 여러대의 서버를 동시에 스케일 아웃 해서 실행해두고 분산시켜서 처리하는게 더 효율적인 경우가 오나봐요.

CDN(Content Delivery Network)

서비스에서 필요한 정적 컨텐츠는 대부분 서버에서 직접 제공하기 보다는 CDN(Content Delivery Network) (ex. Amazon CloudFront) 을 대신 이용하는데요. 사용자와 가까운 지역의 엣지 서버가 대신 제공함으로써 본래 서버로 요청되는 트래픽을 줄여서 부하를 줄이는게 목적이에요.

2025년 11월 18일 Cloudflare 서비스 중단처럼 트래픽을 분산하려고 도입했으나 오히려 외부 의존성에 의해 서비스 제공이 불가능해진 대규모 장애 사례도 있긴해요.

L4 그리고 L7

그리고 로드밸런서에 대해서 검색하면 L4 그리고 L7 로드밸런서가 나오는데요. 이건 네트워크 개념에서 TCP/UDP(레이어 4) 와 HTTP(레이어 7) 단계를 말하는 거에요. 트래픽을 어느 단계에서 분산시킬 것이냐는 의미에요.

L4 로드밸런서

레이어 4 에서는 TCP 그리고 UDP 와 같은 프로토콜과 아이피, 포트로만 구분할 수 있어요. 그래서 단순하고 빠르게 트래픽을 분산하겠다는 의미에요.

L7 로드밸런서

레이어 7 에서는 HTTP 요청 정보까지 활용할 수 있기 때문에 더 유연하게 트래픽을 분산 시킬 수 있어요. 그래서 대부분의 웹 서비스에서는 L7 로드밸런서를 주로 사용하게 되죠.

예를 들어, 다중 테넌트의 SaaS 환경에서 HTTP 요청 헤더에 포함된 테넌트 ID(X-Tenant-ID) 를 보고 해당 테넌트가 할당된 전용 서버 클러스터 로 트래픽을 격리시킬 수 있어요.

소프트웨어 기반 로드밸런서

온프레미스 환경(서버실)에서는 L4 스위치 라는 물리적 네트워크 설비를 두는데요. 클라우드 환경에서는 소프트웨어 기반의 로드밸런서 가 사용돼요. 소프트웨어 기반 로드밸런서에서 L4 로드밸런서로 동작한다는 건 데이터의 TCP/IP 패킷만 해석해서 아이피와 포트로 분산시키겠다는 의미예요.

흔히 L4 로드밸런서는 빠르고 L7 로드밸런서는 상대적으로 느리다고 요약되는데요. 사실 로드밸런서가 트래픽을 분산시키는데 소요되는 시간은 1 ~ 10ms 이내 로 사람이 인지하기 어려운 수준이에요. 따라서, L4 로드밸런서가 필요하다 는 말이 회의에 언급되면 HTTP 프로토콜이 사용되지 않거나, 대규모 트래픽이 발생하는 환경 이다라고 예상할 수 있어요.

오픈소스 로드밸런서

실무에서 대표적으로 활용되는 소프트웨어 기반 로드밸런서는 다음과 같아요.

• HAProxy 또는 Nginx
• Envoy Gateway - 쿠버네티스 환경에서 선택되는 L7 사이드카 프록시