1. 개요

로드 밸런싱이란 여러 대의 컴퓨터 자원(CPU, 저장장치 등)에 작업을 고르게 분배하여 트래픽을 효율적으로 관리하는 기술이다. 현대의 웹사이트들은 많은 사람들이 동시에 접속하는 경우가 많아, 단일 서버로 모든 트래픽을 처리하기엔 한계가 있다. 이를 해결하기 위한 두 가지 방법이 있다.

• Scale-up: 하드웨어 성능을 향상시키는 방법
• Scale-out: 여러 대의 서버가 트래픽을 나눠서 처리하도록 구성하는 방법

Scale-out은 무중단 서비스 환경을 구성하기 용이하며, 여러 서버에 트래픽을 균등하게 분배하는 것이 바로 로드 밸런싱이다.

2. 원리

로드 밸런싱은 여러 서버에 부하(Load)를 고르게 나누는 분산식 웹 서비스 구조이다. 로드 밸런서는 클라이언트와 서버 사이에 위치하여 트래픽을 분산시켜 서버의 과부하를 방지한다. 서비스 규모에 따라 서버를 증설할 수 있으며, 로드 밸런서를 통해 이러한 서버들을 관리하여 성능을 최적화할 수 있다.

3. 로드 밸런서의 서버 선택 방식

로드 밸런서의 서버 선택 방식에는 다양한 알고리즘이 사용되며, 각 방식은 트래픽의 특성이나 서버의 상태에 따라 효율성을 달리할 수 있다. 대표적인 서버 선택 방식은 아래와 같다.

3.1. 라운드 로빈(Round Robin)

순차적으로 서버를 선택하여 트래픽을 분산하는 방식이다. 서버 목록에서 첫 번째 서버부터 마지막 서버까지 차례대로 요청을 배분하고, 다시 처음으로 돌아가 반복된다. 이 방식은 각 서버의 처리 능력이나 현재 부하를 고려하지 않고 균등하게 분배하는 것이 특징이다.

• 장점: 단순하고 구현이 쉽다. 서버의 부하 상태를 고려하지 않아도 고르게 분산된다.
• 단점: 각 서버의 성능이나 현재 연결된 세션 수를 고려하지 않기 때문에, 성능이 다르거나 세션이 긴 요청이 있는 환경에서는 비효율적일 수 있다.

3.2. Least Connections

현재 연결된 세션 수가 가장 적은 서버에 요청을 분배하는 방식이다. 이 방식은 각 서버의 부하 상태를 실시간으로 고려하며, 세션이 길어지는 트래픽이나 비대칭적인 요청 분포가 발생하는 환경에서 유용하다.

• 장점: 서버 간의 부하를 실시간으로 반영하여 상대적으로 가벼운 서버에 우선적으로 요청을 분배함으로써 효율성을 높인다.
• 단점: 각 서버의 연결 상태를 지속적으로 모니터링해야 하므로 추가적인 오버헤드가 발생할 수 있다. 또한, 세션 수만을 기준으로 삼기 때문에 요청당 리소스가 큰 경우(e.g. 대형 파일 전송)에는 서버 부하를 완전히 반영하지 못할 수 있다.

3.3. Source(IP 해싱)

클라이언트의 IP 주소를 해싱하여 특정 서버에 트래픽을 분배하는 방식이다. 해시 알고리즘을 사용해 사용자의 IP를 기반으로 항상 같은 서버에 연결되도록 보장한다. 이 방식은 사용자 세션 유지가 중요한 환경에서 주로 사용된다.

• 장점: 특정 사용자가 동일한 서버에 항상 연결되므로, 세션 유지가 중요한 경우(e.g. 사용자 로그인 상태, 지속적인 데이터를 처리하는 웹 애플리케이션 등) 유리하다. 세션 유지에 별도의 처리를 할 필요가 없다.
• 단점: 특정 서버에 트래픽이 몰릴 수 있는 위험이 있다. IP 분포가 불균형할 경우 특정 서버에만 많은 부하가 걸릴 수 있으며, 로드 밸런싱의 효과가 떨어질 수 있다.

4. 로드 밸런서의 종류

주로 L4와 L7 로드 밸런서가 많이 사용된다. OSI 7 계층 모델에서 L4는 전송 계층, L7은 애플리케이션 계층을 의미한다. 이 계층에 따라 로드 밸런싱의 정교함이 달라지며, L4부터는 포트 정보를 바탕으로 트래픽 분산이 가능하다.

4.1. L4 로드 밸런서(Layer 4 Load Balancer)

L4 로드 밸런서는 네트워크 계층에서 작동한다. 주로 TCP나 UDP와 같은 전송 계층 프로토콜을 사용해서 클라이언트의 요청을 여러 서버로 분산한다.

4.1.1. 특징

• 작동 방식: 패킷의 소스 IP 주소, 소스 포트, 목적지 IP 주소, 목적지 포트를 기준으로 트래픽을 분산한다. 이 정보는 TCP/UDP 헤더에 포함되어 있으며, 이러한 데이터를 기준으로 요청을 처리한다.
• 트래픽 분산: 트래픽을 직접 분석하지 않고 단순히 네트워크 연결을 기반으로 분배하기 때문에, 세션을 유지하거나 특정 요청의 내용에 따라 트래픽을 분산하는 데에 한계가 있다. 즉, 요청의 데이터(e.g. HTTP 헤더나 콘텐츠)를 분석하지 않고 연결을 처리하는 것이 특징이다.
• 성능: 트래픽 분산을 매우 효율적으로 처리할 수 있다. 애플리케이션 계층에서 일어나는 복잡한 처리 없이 패킷 레벨에서 트래픽을 전달하기 때문에, 대규모 트래픽 처리에 적합하다.

4.1.2. 장점

• 빠르고 간단하다.
  • 애플리케이션 계층까지 도달하지 않기 때문에, 데이터 패킷을 빠르게 분산할 수 있다.
  • 고성능이 요구되는 대규모 네트워크 환경에서 유리하다.
• 프로토콜에 무관하다.
  • HTTP뿐만 아니라 TCP나 UDP를 사용하는 다양한 서비스에 사용할 수 있다.
  • e.g. 데이터베이스나 메일 서버 등 비HTTP 서비스에서 활용 가능

4.1.3. 단점

• 세밀한 제어가 부족하다.
  • 트래픽을 세부적으로 분석하지 않기 때문에 요청의 종류나 사용자의 상태에 따라 적절히 분배하지 못할 수 있다.
  • e.g. 특정 URL을 처리하는 서버가 필요한 경우 적합하지 않다.
• 세션 유지가 어렵다.
  • 사용자의 세션이나 상태를 기반으로 분산하는 기능이 제한적이다.

4.2. L7 로드 밸런서(Layer 7 Load Balancer)

L7 로드 밸런서는 애플리케이션 계층에서 작동한다. HTTP, HTTPS와 같은 애플리케이션 레벨의 프로토콜을 분석하고, 클라이언트의 요청을 보다 정교하게 처리한다.

4.2.1. 특징

• 작동 방식: 요청의 내용(e.g. URL, HTTP 헤더, 쿠키, 메소드 등)을 분석하여 트래픽을 분산한다. 사용자가 요청하는 리소스에 따라 서버를 다르게 지정하거나, 특정 콘텐츠를 처리할 수 있는 서버로 트래픽을 유도할 수 있다.
• 트래픽 분산: HTTP 요청을 이해하고 처리할 수 있으므로 URL 기반, 쿠키 기반, 세션 기반 등 다양한 방식으로 트래픽을 분배할 수 있다. 예를 들어, 특정 URL 패턴에 대한 요청을 특정 서버로 전달하거나, 사용자 데이터를 분석하여 적절한 서버에 할당하는 방식으로 매우 세밀한 로드 밸런싱이 가능하다.
• 성능: 트래픽을 분석하고 처리하는 데 더 많은 리소스를 사용하기 때문에 L4에 비해 성능이 약간 떨어질 수 있다. 하지만 고급 트래픽 제어가 가능하다는 점에서 웹 애플리케이션 환경에서 매우 유용하다.

4.2.2. 장점

• 세밀한 제어가 가능하다.
  • 요청의 내용을 분석하여 더 정교한 트래픽 분배가 가능하다.
  • e.g. 특정 URL로 들어오는 요청만 특정 서버에 전달, 사용자 IP나 쿠키 정보를 바탕으로 분산 조정 가능
• 세션 유지가 용이하다.
  • 특정 사용자가 항상 같은 서버에 연결되도록 보장하는 등, 사용자 상태 기반의 트래픽 관리가 가능하다.
• SSL 종료
  • HTTPS 요청에 대해 SSL/TLS 인증을 처리하고, 암호화를 해제한 후 내부 서버로 전달할 수 있다.
  • 이를 통해 서버는 암호화 부담 없이 요청을 처리할 수 있다.

4.2.3. 단점

• 리소스 소모
  • 애플리케이션 계층에서 요청을 분석하기 때문에 L4보다 더 많은 리소스를 소모하기 때문에, 대규모 트래픽 처리 시 성능 저하가 발생할 수 있다.
• 프로토콜 한정
  • 주로 HTTP/HTTPS 기반의 트래픽에 활용되므로, TCP와 UDP같은 비HTTP 서비스에는 적합하지 않다.

5. 로드 밸런서의 장애 대비

로드 밸런서가 여러 서버로 트래픽을 분산시키는 중요한 역할을 하지만, 그 로드 밸런서 자체가 장애를 겪으면 어떻게 될까?

이러한 문제를 예방하고 서비스의 무중단 가동을 보장하기 위해 로드 밸런서의 이중화가 필요하다.

5.1. 로드 밸런서의 이중화

로드 밸런서 이중화는 동일한 네트워크 내에서 두 개 이상의 로드 밸런서가 함께 동작 하여, 한쪽이 장애를 겪을 때 다른 쪽이 자동으로 그 역할을 대신하는 구조를 의미한다. 이중화된 로드 밸런서들은 서로의 상태를 지속적으로 모니터링하고, 문제가 발생하면 즉시 트래픽을 다른 로드 밸런서로 전환하여 서비스의 중단을 방지한다.

• Active-Passive 방식
  • Active 로드 밸런서: 평상시 모든 트래픽을 처리하는 주 로드 밸런서
  • Passive 로드 밸런서: 대기 상태에서 Active 로드 밸런서를 모니터링한다. Active 로드 밸런서가 장애를 겪으면, Passive 로드 밸런서가 즉시 활성화되어 트래픽을 처리한다.
• Active-Active 방식
  • 두 개 이상의 로드 밸런서가 동시에 활성된 상태에서 트래픽을 분산 처리한다. 각각의 로드 밸런서가 일부 트래픽을 처리하며, 한쪽이 장애를 겪으면 나머지가 자동으로 모든 트래픽을 처리한다.

5.2. Health Check

이중화된 로드 밸런서들이 서로의 상태를 실시간으로 모니터링하기 위해 사용하는 것이 Health Check이다. Health Check는 로드 밸런서가 주기적으로 서로의 상태를 점검하는 기능으로, 정상적인 통신이 이루어지고 있는지 확인한다.

📌 Health Check의 동작 방식

1. 로드 밸런서들은 정기적인 요청을 통해 서로가 정상적으로 작동하고 있는지 확인한다.
2. 만약 응답이 없거나, 이상이 감지되면 장애가 발생한 것으로 간주한다.
3. 이를 통해 트래픽 처리를 맡고 있는 로드 밸런서에 문제가 발생하면, 즉시 다른 로드 밸런서가 그 역할을 대신하게 된다.

5.3. 가상 IP(VIP)와 트래픽 전환

VIP(Virtual IP)는 로드 밸런서의 장애 발생 시 트래픽을 자동으로 다른 로드 밸런서로 전환하는 중요한 역할을 한다. VIP는 실제 물리적 IP가 아니라, 클라이언트가 접속하는 논리적인 IP 주소이다. 즉, 물리적으로 특정 서버에 고정되어 있는 것이 아니라, 여러 장비나 서버 사이에서 동적으로 할당될 수 있는 IP 주소다.

• 주 로드 밸런서가 장애를 겪으면, VIP는 대기 중인 여분의 로드 밸런서로 전환된다.
• 클라이언트는 VIP에 접속하여 서비스에 접근하므로, 클라이언트는 장애 상황을 인식하지 못한 채 서비스를 지속해서 사용할 수 있다.

Reference

• CS-Study/Network/로드밸런싱.md
• Network Load Balancing: Round Robin vs Least Connections