로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법이다. 로드 밸런서는 사용자와 서버 그룹 사이에 위치하며 보이지 않는 촉진자 역할을 하여 모든 리소스 서버가 동일하게 사용되도록 하는 디바이스다.
로드 밸런싱은 애플리케이션 서버와 방문자 또는 클라이언트 간의 인터넷 트래픽을 지시하고 제어한다. 결과적으로 애플리케이션의 가용성, 확장성, 보안 및 성능이 향상된다.
Cf. 자세한 내용이 알고 싶다면, 로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS의 로드 밸런싱의 이점은 무엇인가요? 섹션을 확인하자.
고정된 규칙을 따르며 현재 서버 상태와 무관한 정적 로드밸런싱과, 트래픽을 분산하기 전에 서버의 현재 상태를 검사하는 동적 로드밸런싱으로 나뉜다. 라운드 로빈과 같은 정적 알고리즘은 단순성이 핵심인 상태 비저장 애플리케이션에 이상적이다. 응답성과 가용성에 대한 요구가 높은 복잡한 애플리케이션의 경우 동적 알고리즘을 통해 보다 세밀하게 조정된 부하 분산을 제공한다.
정적 로드 밸런싱 알고리즘은 고정된 규칙을 따르며 현재 서버 상태와 무관하다.
Round Robin
클라이언트 요청이 다른 서비스 인스턴스에 순차적으로 전송되며, 권한 있는 이름 서버(authoritative name server)가 특수 하드웨어나 소프트웨어 대신 로드 밸런싱을 수행한다.
cnn.com 같은 인기 있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다. 중복 웹 서버의 경우, 여러 IP 주소가 하나의 정식 호스트 이름과 연관되어 있고, DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다. Name Server는 서버 팜에 있는 여러 서버의 IP 주소를 차례대로 또는 라운드 로빈 방식으로 반환한다.
RR 로드밸런싱은 구현하기 쉽다.
서버들이 거의 동일한 컴퓨팅 성능과 저장 용량을 가진 경우에 잘 작동한다.
ℹ️ 라운드 로빈 스케줄링
시분할 시스템을 위해 설계된 선점형 스케줄링의 하나로서, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘이다.
Sticky round-robin
RR 알고리즘을 개선한 것으로, 동일한 세션 기반 애플리케이션에 대한 동일한 클라이언트의 후속 요청은 고정(sticky) 요청으로 간주되며, 동일한 인스턴스로 라우팅된다. Stickiness는 쿠키를 사용하거나 명시적 URL rewriting을 통해 이루어진다.
애플리케이션이 세션 정보나 요청 간 상태를 유지해야 할 때 유용하다.
(e.g. e-commerce 장바구니, 웹 기반 이메일 서비스)
특정 사용자 세션이 특히 많은 트래픽을 일으키면 불균형을 가져올 수 있으므로, 트래픽이 예측하기 어렵거나 트래픽 강도 변화의 폭이 큰 경우에는 좋은 선택이 아닐 수 있다.
Weighted round-robin
우선순위 또는 용량에 따라 각 서버에 서로 다른 가중치를 할당할 수 있다. 가중치가 높은 서버는 이름 서버에서 들어오는 애플리케이션 트래픽을 더 많이 수신한다.
서버들의 성능이 다를 때 사용하면 좋다.
수동으로 가중치를 설정해줘야 하고 실시간으로 조절하기 어렵다.
Hash
클라이언트 IP 주소나 URL에 해시 함수를 적용하여 숫자로 변환한 다음 개별 서버에 매핑한다.
서버의 개수가 변하지 않는다면 해시 함수는 같은 입력에 대해 같은 결과를 리턴하므로, 지정된 서버로만 계속 접속하게 된다. 세션을 유지해야하는 사이트(인증, 보안)에서 주로 사용한다.
최적의 해시 함수를 선택하기 어렵다. 해싱 연산이 비싸서 성능 저하를 일으킬 수 있으며, key collision이 발생하면 데이터 불균형과 성능 저하가 발생할 수 있다.
💡 sticky session vs consistent hash
- 공통점: 세션을 유지해야 하는 사이트에서 주로 사용한다.
- 차이점: 해싱은 서버를 scale-out 또는 scale-in 하더라도, 알고리즘에 의해 대부분의 요청이 원래 사용하던 서버에 전송된다.
Cf. why do we need consistent hashing when round robin can distribute the traffic evenly
동적 로드 밸런싱 알고리즘은 트래픽을 분산하기 전에 서버의 현재 상태를 검사한다.
Least connections
연결은 클라이언트와 서버 간의 개방형 통신 채널이다. 클라이언트는 서버에 첫 번째 요청을 전송할 때 서로 활성 연결을 인증하고 설정한다. 최소 연결 방법에서 로드 밸런서는 활성 연결이 가장 적은 서버를 확인하고 해당 서버로 트래픽을 전송한다.
트래픽을 예측할 수 없고 강도가 매우 다양한 환경에서는 좋은 옵션이 될 수 있다.
RR 알고리즘과 마찬가지로 최소 연결 수 알고리즘은 각 서버의 처리 능력을 고려하지 않는다. 따라서 서버의 성능이 서로 다른 환경에서는 최선의 선택이 아닐 수 있다.
Least response time
응답 시간은 서버가 들어오는 요청을 처리하고 응답을 전송하는 데 걸리는 총 시간이다. 최소 응답 시간 방법은 서버 응답 시간과 활성 연결을 결합하여 최상의 서버를 결정한다. 로드 밸런서는 이 알고리즘을 사용하여 모든 사용자에게 더 빠른 서비스를 보장한다.
현재 서버 성능에 매우 유연하게 적응한다.
지속적인 모니터링이 필요하므로, 복잡성과 오버헤드가 늘어난다.
서버 부하 분산을 담당하는 Network Switch를 L4/L7 Switch라고 부르며, Cloud에서는 이를 Load Balancer라고 부른다.
Cf. OSI 7 계층을 기반으로 하여, OSI Layer 4, Layer 7 스위치다.
💡 스위치의 분류
MAC 주소 IP 주소 TCP/UDP 포트번호(1024) 패킷의 내용 0000-0C12-3456 10.1.11 80 GET/ images/abc.gif |----------------|-----------| L2 스위칭 L3 스위칭 |----------------------------------| L4 스위칭 |-------------------------------------------------------| L5 - L7 스위칭
- L2: OSI Layer 2에 속하는 MAC 주소를 참조하여 스위칭하는 장비
- L3: OSI Layer 3에 속하는 IP 주소를 참조하여 스위칭하는 장비
- L4: OSI Layer 3-4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비
- L7: OSI Layer 3-7에 속하는 IP 주소, TCP/UDP 포트 정보와 패킷 내용까지 참조하여 스위칭
전송 계층(L4)에서 로드밸런서는 방화벽 같이 작동한다.
IP 주소와 TCP/UDP port 정보를 이용해서 서버와 클라이언트 연결을 라우팅하며, Source IP 또는 Destination IP를 NAT(Network Address Translation)하여 보낸다.
클라이언트와 서버 간 하나의 TCP 연결이 형성된다.
💡 NAT(Network Address Translation)
IP 주소를 변환하는 기술로, 1개의 실제 공인 IP 주소에, 다량의 가상 사설 IP 주소를 할당 및 매핑한다.
IPv4의 IPv4 주소 고갈 및 라우팅 테이블 대형화 (Routing Scalability)에 대한 해소책으로 사용하기 시작했다.
통상, 방화벽 등과 결합되어 함께 수행되며, 내/외 주소변환 규칙을 외부에서 알 수 없으므로, 내부 망에 대한 정보(내부망 주소,숫자 설정 등)가 외부에 노출되지 않는다. (프라이버시 보호, 은닉)
Cf. http://www.ktword.co.kr/test/view/view.php?no=1676
기본 요구사항을 가지며 트래픽이 높은 경우에 사용한다. (e.g. 데이터베이스 쿼리 분산 또는 일반 웹 트래픽 분산)
OSI 모델의 최상위 계층인 애플리케이션 계층(L7)에서 로드밸런서는 reverse proxy처럼 작동한다. 따라서 두 개의 TCP 연결을 유지한다. (하나는 클라이언트와, 하나는 서버와 연결)
L7 로드밸런서는 HTTP 헤더와 메시지 내용에 포함된 다양한 특성(e.g. URL, 데이터 타입(text, video, graphics), cookie에 있는 정보)을 이용하여 라우팅한다.
유저 데이터, content type, 특정 서버 기능에 기반한 지능형 라우팅이 필요한 복잡한 애플리케이션에 사용한다.
로드 밸런서가 트래픽을 리디렉션하기 위해 클라이언트 요청에서 확인하는 콘텐츠에 따라 로드 밸런싱을 분류할 수 있다.
복잡한 최신 애플리케이션에는 단일 애플리케이션 기능을 전담하는 여러 서버를 포함하는 여러 서버 팜이 있다. Application Load Balancer는 HTTP 헤더 또는 SSL 세션 ID와 같은 요청 콘텐츠를 확인하여 트래픽을 리디렉션한다.
예를 들어, 전자 상거래 애플리케이션에는 제품 디렉터리, 장바구니 및 결제 기능이 있다. Application Load Balancer는 이미지와 비디오를 포함하지만 열린 연결을 유지할 필요가 없는 서버에 제품 검색 요청을 전송한다. 이에 비해 많은 클라이언트 연결을 유지하고 장바구니 데이터를 오랫동안 저장할 수 있는 서버로 장바구니 요청을 전송한다.
Network Load Balancer는 IP 주소 및 기타 네트워크 정보를 검사하여 트래픽을 최적으로 리디렉션한다. 애플리케이션 트래픽의 소스를 추적하고 여러 서버에 고정 IP 주소를 할당할 수 있다. Network Load Balancer는 정적 및 동적 로드 밸런싱 알고리즘을 사용하여 서버 로드를 배포한다.
글로벌 서버 로드 밸런싱은 지리적으로 분산된 여러 서버에서 발생한다. 예를 들어, 회사는 여러 데이터 센터, 여러 국가 및 전 세계의 타사 클라우드 제공업체에 서버를 둘 수 있다. 이 경우 로컬 로드 밸런서는 리전 또는 영역 내에서 애플리케이션 로드를 관리한다. 그리고 클라이언트와 지리적으로 더 가까운 서버 대상으로 트래픽을 리디렉션하려고 한다. 서버 장애가 발생한 경우에만 클라이언트의 지리적 영역 외부의 서버로 트래픽을 리디렉션할 수 있다.
DNS 로드 밸런싱에서는 도메인의 리소스 풀에서 네트워크 요청을 라우팅하도록 도메인을 구성한다. 도메인은 웹 사이트, 메일 시스템, 인쇄 서버 또는 인터넷을 통해 액세스할 수 있는 다른 서비스에 해당할 수 있다. DNS 로드 밸런싱은 애플리케이션 가용성을 유지하고 전역적으로 분산된 리소스 풀에서 네트워크 트래픽을 분산하는 데 유용하다.
Elastic Load Balancing(ELB)은 수신 애플리케이션 트래픽을 AWS 및 온프레미스 리소스 전반의 여러 대상 및 가상 어플라이언스에 자동으로 배포하는 완전 관리형 로드 밸런싱 서비스다. 이를 사용하여 복잡한 구성이나 API 게이트웨이 없이 최신 애플리케이션을 조정할 수 있다. ELB를 사용하여 네 가지 유형의 소프트웨어 로드 밸런서를 설정할 수 있다.
Application load balancer(ALB) | Network Load Balancer(NLB) | Gateway Load Balancer(GLB) | |
---|---|---|---|
OSI 계층 | 애플리케이션 계층인 계층 7에서 작동 | 전송 계층인 계층 4에서 작동 | 네트워크 계층인 계층 3 및 계층 7에서 작동 |
대상 유형 | IP, 인스턴스 및 Lambda 대상 유형에 작동 | IP, 인스턴스 및 ALB 대상 유형에 작동 | IP 및 인스턴스 대상 유형에 작동 |
프록시 동작 | 연결을 종료함 | 연결을 종료함 | 흐름을 종료하지 않음 |
프로토콜 | HTTP, HTTPS 및 gRPC 프로토콜 지원 | TCP, UDP 및 TLS 프로토콜 지원 | IP 기반 라우팅 지원 |
알고리즘 | 라운드 로빈 | 플로우 해시 | 라우팅 테이블 조회 |
Load Balancer vs. Reverse Proxy vs. API Gateway: Demystifying Web Architectures
L4/L7 스위치와 AWS Load Balancer를 자세히 알아보고 싶다면 네트워크 엔지니어 환영의 기술블로그의 다음 시리즈를 참고하자.