로드 밸런싱(Load Balancing)에 대해 설명해 주세요.
면접용
로드 밸런싱은 서버를 구축할 때, 서버가 받을 부하를 적절하게 분산시켜주는 모듈을 뜻합니다. 처음에 구축했던 애플리케이션 서버가 트래픽이 많아져, 이에 대한 해결 방안으로 Scale-out 방식을 적용해 서버를 늘릴 경우에 로드밸런싱을 고려해야 합니다.
로드밸런싱 방법에는 Round robin, Random select, least connection 등 다양한 방법이 있으며, 서버의 성능과 상황에 따라 적절한 기법을 사용해야 합니다.
로드밸런서 구축 방법으로는 Proxy를 사용해서 소프트웨어적으로 로직을 작성하는 방법과, L4/L7 switch를 사용하여 데이터센터에서 직접 물리적인 방법으로 서버들을 묶는 하드웨어적 방식이 있습니다.
개념설명
로드밸런싱이란?
**로드(Load)**는 **서버가 받는 부하(트래픽)**를 의미합니다.
그래서 로드밸런싱은 트래픽들을 서버들에게 잘 분산시켜주는 기법을 뜻하고, 이러한 기법이 적용된 모듈이 로드밸런서입니다.
로드밸런서는 클라이언트와 서버 그룹 사이에 위치합니다.
트래픽 증가에 대한 대처방식
어떤 서비스를 런칭했을 때
유저의 쿼리 개수가 천개, 만개로 늘어나고, 유저 수도 몇십만명이라고 가정해봅시다.
그럼 이 경우에 애플리케이선 서버가 하나뿐이라면, 과연 장애 없이 관리할 수 있을까요?
이렇게 트래픽이 늘어났을 때 할 수 있는 방법에는 Scale Up과 Scale Out의 2가지 방법이 있습니다.
image 1 Scale-up (Vertical Scaling)
기존 서버의 사양 자체를 올리는 방법입니다.
ex) CPU 업그레이드, 디스크 추가 등
설계가 쉽지만 성능 향상에 기술적으로 한계가 있습니다.
서버에 장애가 생길 경우 서비스 전체를 이용할 수 없습니다. ⇒ 장애에 영향을 크게 받습니다.
Scale-out (Horizontal Scaling)
기존 서버와 비슷한 성능의 서버를 증설하여 분산시스템을 구축하는 방식입니다.
이때 기존 서버의 부하를 어떻게 분담할 지 고려할 때 로드밸런싱이 필요합니다.
로드밸런서는 클라이언트에서 들어오는 트래픽을 어떤 서버에 보낼지 판단할 수 있습니다.
로드밸런싱 방식
Round Robin(라운드 로빈)
여러 대의 서버가 있을 때, 들어오는 요청을 서버들에게 순차적으로 하나씩 보내는 방식입니다.
하나씩 순차적으로 보내며, 끝에 도달하면 다시 처음으로 돌아와서 보내는 라운드 방식입니다.
모든 서버들이 트래픽을 균일하게 가지게 됩니다.
여러대의 서버가 동일한 스펙을 가지고 있고, 서버와의 연결(세션)이 단기간일 경우에 적합합니다.
Weighted Round Robin(가중 라운드 로빈)
분산시스템을 할 때 현실적으로 모든 서버의 성능을 동등하게 맞추기는 어렵습니다.
만약 성능 낮은 서버가 트래픽을 감당하지 못하고 중단되면, 다른 서버들에게 부하가 더 걸려서 연쇄적으로 중단될 수 있습니다.
따라서 로드밸런서에서 서버의 성능을 감안하고 트래픽을 전송할 필요가 있습니다.
서버들의 스펙을 미리 계산해서 각 서버에 가중치(처리량)를 부여하고, 가중치가 높은 서버에 요청을 우선적으로 전달합니다.
서버A(가중치 3), 서버B(가중치 2)가 있다면 서버A에 3개의 요청을, 서버B에 2개의 요청을 전달하게 됩니다.
Least connection(최소 연결)
애플리케이션 서버에서 로드밸런서에게 트래픽의 양과 커넥션의 개수 여부를 알려주는 방식입니다.
로드밸런스는 그 정보들을 가지고 어디로 요청을 보낼지 판단합니다.
서버들의 상태를 보고 가장 적은 연결 상태를 보이는 서버에게 트래픽을 보냅니다.
서버 - 로드밸런스 간의 실시간 통신이 이루어져야 하므로 조금 더 복잡한 방법입니다.
세션이 길어지거나 서버에 분배된 트래픽들이 일정하지 않을 때 적합한 방법입니다.
Least Response Time(최소 응답 시간)
서버의 현재 연결 상태와 응답 시간을 모두 고려하여 트래픽을 나눕니다.
가장 적은 연결상태와, 가장 짧은 응답시간을 보이는 서버에 우선적으로 요청을 나눕니다.
IP 해시 방식
클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식입니다.
사용자의 IP를 해싱하여 요청을 분배하므로, 사용자는 항상 동일한 서버로 연결됩니다.
Random select
서버를 랜덤하게 골라서 해당 서버에 요청을 보내는 방식입니다.
최악의 경우, 한 서버에만 트래픽이 몰려서 부하가 생길 수 있습니다.
위와 같은 케이스는 드물고, 실제로는 균일하게 가지게 된다고 합니다.
로드밸런싱 구축 방법
소프트웨어적인 방식
기존의 소프트웨어를 활용해, 로직만 구현해서 트래픽을 분산시키는 방식입니다.
HAProxy, Reverse Proxy가 제공하는 기능을 가지고 로드밸런싱을 진행합니다.
ex) nginx, apache같은 웹 서버를 사용합니다.
장점
소프트웨어를 이용하기 때문에 비용이 절감됩니다.
scale-up 시에 환경만 변경해주면 되어서 관리가 쉽습니다.
하드웨어적인 방식
서버는 보통 데이터센터에 위치하므로, 그곳에서 물리적으로 서버를 묶는 방식입니다.
대표적으로 L4 / L7 switch가 있습니다.
L4 로드 밸런싱은 Layer4(네트워크, 전송 계층)의 정보를 바탕으로 트래픽을 분산하는 방법입니다.
IP/포트 기반(패킷 레벨)으로 트래픽을 분산합니다.
데이터 안을 들여다보지 않기 때문에 속도가 빠르고 효율성이 높습니다.
IP가 수시로 바뀌는 경우 연속적인 서비스를 제공하기 어렵습니다.
L7 로드 밸런싱은 Layer 7(응용 계층)의 정보를 바탕으로 트래픽을 분산하는 방법입니다.
IP/포트, 사용자가 요청한 정보(HTTP header, cookie 등)를 바탕으로 트래픽을 분산합니다.
섬세한 라우팅이 가능하고 비정상적인 트래픽을 사전에 필터링 할 수 있어 서비스 안정성이 높습니다.
비용이 L4보다 상대적으로 높습니다.
하드웨어 방식의 장점
안정성이 높습니다.
IDC를 쉽게 접근할 수 없으므로 보안성이 높습니다.
하드웨어 방식의 단점
물리적으로 서버를 묶기 때문에 비용이 많이 듭니다.
만약 로드밸런서가 중단되면?
로드밸런서 한 곳에서 트래픽 분배를 관리하므로, 로드밸런서가 중단될 경우 서비스 자체가 중단될 위험이 있습니다.
SPOF(Single Point of Failure): 전체 시스템에서 특정 포인트에 에러가 났을 때 전체 시스템이 다운되는 경우
그래서 로드밸런서 자체도 scale out을 진행합니다.
master-slave 방식으로 운용합니다.
즉 master가 예기치 못한 상황에서 죽을 때, slave가 이를 이어받아서 서비스는 계속 이어갈 수 있도록 합니다.
참고문서
Last updated