부하 분산 장치편집자 확인

부하 분산은 네트워크 트래픽이나 컴퓨팅 작업을 여러 서버나 자원에 고르게 분배하는 과정이다. 이는 단일 서버에 과도한 부하가 집중되어 성능 저하나 서비스 중단을 방지하고, 전체 시스템의 처리량, 신뢰성, 가용성을 향상시키는 것을 목표로 한다. 현대의 디지털 서비스는 수많은 사용자의 동시 접속과 대량의 데이터 처리를 요구하기 때문에, 부하 분산은 확장 가능하고 견고한 인프라를 구축하는 데 필수적인 기술이 되었다.

부하 분산의 필요성은 크게 세 가지 측면에서 설명할 수 있다. 첫째는 확장성이다. 사용자 수나 트래픽이 증가할 때 단순히 서버의 성능을 높이는 수직 확장에는 물리적, 경제적 한계가 있다. 부하 분산을 통해 여러 대의 서버를 병렬로 추가하는 수평 확장 방식은 더 유연하고 비용 효율적으로 시스템 규모를 늘릴 수 있게 한다. 둘째는 가용성과 내결함성 향상이다. 한 대의 서버에 장애가 발생하더라도 부하 분산 장치가 정상 서버로 트래픽을 전환함으로써 서비스 중단 시간을 최소화하고 연속성을 보장한다. 셋째는 성능 최적화이다. 지리적으로 분산된 서버에 사용자를 가까운 위치로 연결하거나, 서버의 현재 부하 상태에 따라 트래픽을 분배함으로써 응답 시간을 줄이고 사용자 경험을 개선할 수 있다.

따라서, 웹 애플리케이션, API, 데이터베이스 클러스터, 심지어 DNS 서버에 이르기까지 다양한 IT 인프라에서 부하 분산은 핵심 구성 요소로 자리 잡고 있다. 이는 단순한 트래픽 분배를 넘어 현대 클라우드 네이티브 아키텍처와 마이크로서비스의 기반이 되는 기술이다.

부하 분산 장치는 단순히 트래픽을 여러 서버로 나누는 것을 넘어, 네트워크의 가용성, 안정성, 효율성을 보장하는 여러 핵심 기능을 수행합니다. 그 주요 기능은 트래픽 분배, 고가용성 제공, 성능 최적화, 그리고 보안 강화로 요약할 수 있습니다.

첫째, 트래픽 분배는 가장 기본적인 기능입니다. 사전에 정의된 부하 분산 알고리즘을 통해 들어오는 클라이언트 요청을 백엔드 서버 풀에 고르게 분산시킵니다. 이 과정에서 서버의 현재 부하 상태, 연결 수, 지정된 가중치, 지리적 위치 등 다양한 요소를 고려하여 최적의 대상 서버를 선택합니다. 이를 통해 단일 서버에 과부하가 걸리는 것을 방지하고 전체 시스템의 처리 용량을 극대화합니다.

둘째, 고가용성과 장애 조치를 제공합니다. 부하 분산 장치는 정기적으로 백엔드 서버에 헬스 체크를 수행하여 각 서버의 정상 작동 여부를 모니터링합니다. 건강하지 않은 서버를 감지하면 자동으로 트래픽 분배 대상에서 제외시켜 사용자 요청이 실패한 서버로 전달되는 것을 방지합니다. 이는 시스템의 전체적인 안정성과 무중단 서비스를 가능하게 하는 핵심 메커니즘입니다.

마지막으로, 성능 향상과 보안 강화를 위한 부가 기능을 포함합니다. 대표적으로 SSL/TLS 오프로딩은 암호화된 HTTPS 트래픽의 복호화 작업을 부하 분산 장치가 대신 처리하여 백엔드 서버의 CPU 부하를 줄이고 응답 속도를 높입니다. 또한, 네트워크 트래픽을 집중적으로 관찰하는 위치에 있기 때문에, 기본적인 수준의 트래픽 필터링이나 방화벽과 연동된 보안 정책 적용의 시작점 역할을 하기도 합니다.

라운드 로빈은 가장 기본적이고 널리 사용되는 부하 분산 알고리즘이다. 이 방식은 들어오는 요청을 등록된 서버 목록에 순차적으로 할당한다. 첫 번째 요청은 첫 번째 서버로, 두 번째 요청은 두 번째 서버로 보내는 식으로 순환하며, 마지막 서버에 요청을 보낸 후에는 다시 목록의 처음으로 돌아간다.

이 알고리즘의 동작 원리는 단순하다. 로드 밸런서는 내부에 서버 풀의 순서를 유지하며, 각 새로운 연결 요청에 대해 다음 순서의 서버를 선택한다. 모든 서버가 처리 능력과 성능이 동일하다고 가정할 때, 이론적으로는 요청이 모든 서버에 균등하게 분배된다.

라운드 로빈 방식의 주요 장점은 구현이 간단하고 오버헤드가 적다는 점이다. 서버의 현재 부하 상태나 연결 수를 고려하지 않고 순서만으로 결정하기 때문에 결정 로직이 매우 빠르다. 또한 별도의 상태 정보를 유지할 필요가 없어 상태 비저장 방식에 적합하다.

그러나 모든 서버의 성능과 용량이 동일하지 않은 실제 환경에서는 한계를 보인다. 처리 능력이 낮은 서버와 높은 서버에 동일한 양의 요청이 할당되면, 성능이 낮은 서버는 과부하 상태가 될 수 있다. 또한 서버의 현재 부하나 응답 시간, 활성 연결 수 등을 전혀 고려하지 않기 때문에 최적의 분산이 이루어지지 않을 수 있다는 단점이 있다. 이러한 한계를 보완하기 위해 가중치 기반 알고리즘이나 최소 연결 알고리즘 등이 발전되었다.

최소 연결 알고리즘은 부하 분산 장치가 현재 처리 중인 연결 수가 가장 적은 서버로 새 요청을 전달하는 방식이다. 이 방법은 서버마다 처리 능력이 비슷할 때 효과적이며, 각 서버의 실시간 부하 상태를 고려하여 트래픽을 분배한다. 라운드 로빈 알고리즘이 단순히 순서만을 고려하는 반면, 최소 연결 알고리즘은 서버의 현재 작업량을 기준으로 더 공정한 분배를 목표로 한다.

알고리즘은 일반적으로 다음과 같이 동작한다. 부하 분산 장치는 백엔드 서버 풀에 속한 각 서버와의 활성 TCP 연결 수를 지속적으로 추적한다. 새로운 클라이언트 연결 요청이 들어오면, 장치는 자신의 연결 테이블을 확인하여 현재 활성 연결 수가 가장 적은 서버를 선택한다. 선택된 서버로 요청을 전송한 후, 해당 서버에 대한 연결 카운트를 1 증가시킨다. 연결이 종료되면 카운트는 다시 감소한다.

이 방식은 특히 연결이 장시간 유지되는 애플리케이션에서 유리하다. 예를 들어, 데이터베이스 연결이나 긴 세션을 요구하는 실시간 스트리밍 서비스에서 특정 서버에만 연결이 집중되는 것을 방지할 수 있다. 서버의 처리 능력에 차이가 있을 경우, 가중치 기반 알고리즘과 결합된 '가중 최소 연결' 방식으로 변형되어 사용되기도 한다. 이 변형에서는 각 서버에 지정된 가중치를 고려하여, '연결 수 / 가중치' 비율이 가장 낮은 서버를 선택한다.

최소 연결 알고리즘은 서버의 처리 용량이 동질적이고, 연결 지속 시간이 불규칙할 때 라운드 로빈보다 더 균등한 부하 분산을 달성한다. 그러나 단순히 연결 수만을 기준으로 하기 때문에, 각 연결의 실제 리소스 소모량(예: 간단한 API 요청 vs. 대용량 파일 전송)은 고려하지 못하는 한계가 있다.

가중치 기반 알고리즘은 각 서버의 처리 능력이나 용량 차이를 고려하여 부하를 불균등하게 분배하는 방식이다. 단순히 순서대로 요청을 할당하는 라운드 로빈이나 현재 연결 수만을 고려하는 최소 연결 알고리즘과 달리, 사전에 설정된 가중치 값에 따라 더 많은 트래픽을 처리 능력이 높은 서버로 유도한다. 이는 이질적인 하드웨어 사양을 가진 서버 풀을 운영하거나 특정 서버가 더 많은 리소스를 보유한 환경에서 효율적인 자원 활용을 가능하게 한다.

알고리즘의 동작 방식은 일반적으로 다음과 같다. 관리자는 각 서버에 처리 능력에 비례하는 가중치(예: 1에서 10 사이의 정수)를 할당한다. 부하 분산 장치는 이 가중치를 기반으로 서버를 선택할 확률을 계산한다. 예를 들어, 세 대의 서버에 가중치 5, 3, 2가 할당되었다면, 총 가중치 합은 10이 된다. 이 경우 첫 번째 서버는 50%(5/10)의 확률로, 두 번째 서버는 30%의 확률로, 세 번째 서버는 20%의 확률로 요청을 받게 된다.

이 방식의 주요 장점은 인프라 투자 효율성을 높일 수 있다는 점이다. 고사양의 신규 서버에는 높은 가중치를, 구형 서버에는 낮은 가중치를 부여함으로써 전체적인 처리 성능을 최적화한다. 그러나 단점으로는 가중치 설정이 관리자의 경험과 모니터링에 의존하며, 서버의 실제 부하 상태를 실시간으로 완벽히 반영하지 못할 수 있다는 점이 있다. 따라서 초기 가중치 설정과 지속적인 성능 모니터링이 함께 수행되어야 효과를 발휘한다.

지리적/지연 시간 기반 알고리즘은 사용자와 서버 간의 물리적 거리나 네트워크 지연 시간을 주요 판단 기준으로 하여 부하 분산을 수행하는 방법이다. 이 방식은 전 세계적으로 분산된 서버 인프라를 가진 서비스에서 특히 중요성을 가진다. 사용자의 요청을 지리적으로 가장 가까운 데이터 센터나 네트워크 홉이 가장 적은 서버로 라우팅함으로써 응답 시간을 최소화하고 사용자 경험을 향상시키는 것을 목표로 한다.

지리적 기반 라우팅은 사용자의 IP 주소를 기반으로 대략적인 위치(예: 국가, 지역)를 판단하여 미리 정의된 지리적 영역에 할당된 서버 풀로 트래픽을 전달한다. 이는 콘텐츠 전송 네트워크CDN의 동작 원리와 유사하다. 반면, 지연 시간 기반 라우팅은 보다 동적인 방식으로, 주기적으로 측정된 실제 네트워크 왕복 시간RTT이나 활성 프로브를 사용하여 각 서버까지의 현재 지연 시간을 평가한다. 그 후 가장 낮은 지연 시간을 보이는 서버를 선택한다.

이 알고리즘의 구현은 복잡성이 있을 수 있다. 지리적 위치 정보 데이터베이스GeoIP DB의 정확성에 의존하거나, 지속적인 지연 시간 모니터링으로 인한 오버헤드가 발생할 수 있다. 또한, 단순히 지리적으로 가깝다고 해서 항상 네트워크 지연이 최소인 것은 아니므로, 두 방법을 결합하여 사용하는 경우도 흔하다. 주요 클라우드 제공자들의 글로벌 로드 밸런싱 서비스는 종종 이러한 지리적 및 성능 메트릭스를 종합적으로 고려한 라우팅 정책을 제공한다[2].

L4 로드 밸런서는 OSI 모델의 전송 계층(4계층)에서 동작하는 부하 분산 장치이다. 주로 TCP와 UDP 패킷의 헤더 정보, 즉 출발지 및 목적지 IP 주소와 포트 번호를 기반으로 트래픽을 분배한다. 이 방식은 패킷의 페이로드(실제 데이터 내용)를 확인하지 않고 네트워크 레벨의 정보만으로 빠르게 결정을 내리므로 처리 속도가 빠르고 효율적이다. 주로 단순한 연결 분산, 대용량 트래픽 처리, 기본적인 장애 조치에 적합하다.

주요 기능으로는 NAT(Network Address Translation)를 통한 트래픽 전달이 있다. 클라이언트의 요청을 받은 L4 로드 밸런서는 자신의 가상 IP(VIP)를 백엔드 서버의 실제 IP로 변환하여 전송한다. 반대로 서버의 응답도 로드 밸런서를 거쳐 클라이언트에게 전달된다. 이 과정에서 클라이언트는 백엔드 서버의 실제 주소를 알지 못한다. 또한, 헬스 체크를 통해 백엔드 서버의 상태를 모니터링하고 장애가 발생한 서버로는 트래픽을 보내지 않는다.

L4 로드 밸런서는 다음과 같은 일반적인 사용 사례를 가진다.

L7 로드 밸런서와 비교할 때, L4 로드 밸런서는 애플리케이션 계층의 내용(URL, 쿠키, 헤더 값)을 이해하지 못한다는 한계가 있다. 따라서 HTTP 요청의 특정 경로나 콘텐츠 유형에 따라 세부적으로 라우팅하는 콘텐츠 기반 라우팅은 수행할 수 없다. 그러나 그만큼 처리 오버헤드가 적어 초당 처리 가능한 연결 수(Connections Per Second)가 더 높고, 레이턴시가 낮은 경우가 많다.

L7 로드 밸런서는 OSI 모델의 응용 계층(7계층)에서 동작하는 부하 분산 장치이다. L4 로드 밸런서가 IP 주소와 포트 번호 같은 전송 계층 정보만을 기반으로 트래픽을 분산하는 반면, L7 로드 밸런서는 HTTP 헤더, URL, 쿠키, 실제 메시지 내용과 같은 응용 계층 데이터를 분석하여 더 지능적인 라우팅 결정을 내릴 수 있다. 이로 인해 특정 URL 경로에 대한 요청을 전용 서버 풀로 보내거나, 사용자 디바이스 유형(모바일/데스크톱)에 따라 다른 서버로 연결하는 등 세밀한 트래픽 제어가 가능해진다.

주요 기능으로는 콘텐츠 기반 라우팅이 있다. 예를 들어, /images 경로로 오는 요청은 이미지 서버 풀로, /api 경로로 오는 요청은 애플리케이션 서버 풀로 분기할 수 있다. 또한, SSL/TLS 오프로딩을 수행하여 백엔드 서버의 암호화/복호화 부하를 줄이고, HTTP/1.1에서 HTTP/2로의 프로토콜 변환, 요청/응답 헤더의 수정 또는 추가 같은 기능도 제공한다. 이러한 특징은 현대적인 마이크로서비스 아키텍처 환경에서 각 서비스별로 트래픽을 라우팅할 때 특히 유용하다.

L7 로드 밸런서의 동작 방식을 간략히 나타내면 다음과 같다.

그러나 패킷의 페이로드를 검사해야 하므로 L4 로드 밸런서에 비해 처리 지연이 더 길고, 컴퓨팅 리소스 소모가 크다는 단점이 있다. 또한, 암호화된 HTTPS 트래픽을 처리하려면 로드 밸런서가 SSL/TLS 복호화를 수행해야 하므로, 이에 대한 보안 및 키 관리 정책이 필수적으로 요구된다.

하드웨어 로드 밸런서는 ASIC이나 FPGA 같은 전용 하드웨어 칩셋 위에서 동작하는 독립형 물리적 장비이다. 고성능과 저지연 처리가 요구되는 대규모 엔터프라이즈 환경에서 전통적으로 사용되었다. 이 유형은 일반적으로 높은 처리량과 초고속 패킷 포워딩 성능을 제공하며, 내장된 보안 기능과 안정성이 특징이다. 그러나 초기 구매 비용이 높고, 확장이나 기능 업데이트에 물리적 교체나 추가 구매가 필요할 수 있다는 단점이 있다.

소프트웨어 로드 밬런서는 범용 서버 하드웨어나 가상 머신, 컨테이너 환경에서 애플리케이션 소프트웨어 형태로 실행된다. 클라우드 컴퓨팅 환경의 확산과 함께 그 활용도가 크게 증가했다. 대표적인 예로는 NGINX, HAProxy, Envoy 등이 있다. 이 유형은 하드웨어 의존성이 낮아 유연한 배포와 확장이 가능하며, 비용 효율성이 높다. 또한 DevOps 문화와 통합되어 CI/CD 파이프라인을 통해 구성 관리와 배포가 자동화되기 쉽다.

다음 표는 두 유형의 주요 특징을 비교한 것이다.

현대 트렌드는 하이브리드 접근법으로 발전하고 있다. 많은 벤더들이 소프트웨어 정의 네트워킹 원리를 적용한 어플라이언스를 제공하거나, 클라우드 서비스 형태의 완전 관리형 로드 밸런서를 출시하고 있다. 이는 하드웨어의 성능과 소프트웨어의 유연성을 결합하려는 시도이다. 최종 선택은 예산, 성능 요구사항, 운영 환경의 복잡성, 그리고 필요한 유연성 수준에 따라 결정된다.

액티브-스탠바이는 부하 분산 장치를 이중화하여 고가용성을 확보하는 전통적인 아키텍처 방식이다. 이 구성에서는 두 대 이상의 로드 밸런서가 사용되며, 그중 한 대만 실제 트래픽을 처리하는 액티브(활성) 역할을 담당한다. 나머지 장치는 대기 상태인 스탠바이(대기) 모드로 운영되어 액티브 장치에 문제가 발생할 경우를 대비한다.

액티브 장치는 모든 클라이언트 요청을 수신하여 백엔드 서버 풀에 분배하는 주된 작업을 수행한다. 스탠바이 장치는 액티브 장치의 상태를 지속적으로 모니터링하며, 일반적으로 트래픽을 처리하지 않는다. 두 장치는 헬스 체크 신호(예: 헬로 패킷)를 주고받아 서로의 정상 작동 여부를 확인한다. 이 상태 동기화는 VRRP나 HSRP와 같은 페일오버 프로토콜을 통해 관리되는 경우가 많다.

액티브 장치에 장애가 감지되면, 사전에 정의된 페일오버 절차가 시작된다. 스탠바이 장치는 액티브 역할을 인계받아 VIP(가상 IP 주소)를 자신의 인터페이스에 연결하고, 트래픽 처리와 세션 지속성을 담당하기 시작한다. 이 전환 과정은 일반적으로 수 초 이내에 완료되어 서비스 중단 시간을 최소화한다.

이 방식의 주요 장점은 구성이 비교적 단순하고 예측 가능하다는 점이다. 그러나 단점은 스탠바이 장치가 대기 중일 때 하드웨어 리소스를 전혀 활용하지 않아 자원 효율성이 낮다는 것이다. 또한, 페일오버 시 기존 TCP 연결 중 일부가 끊어질 수 있으며, 액티브 장치가 복구된 후 다시 스탠바이 모드로 전환하는 과정(페일백)이 추가로 필요하다.

액티브-액티브 아키텍처는 두 개 이상의 부하 분산 장치가 모두 활성 상태로 운영되어 트래픽을 동시에 처리하는 구성 방식이다. 이 방식에서는 모든 로드 밸런서가 실시간으로 서비스를 제공하며, 들어오는 요청을 공유하거나 분산된 방식으로 처리한다. 일반적으로 DNS 라운드 로빈이나 애니캐스트 같은 기술을 통해 클라이언트 요청이 여러 활성 로드 밸런서로 분배된다. 모든 노드가 활성 상태이므로 시스템 전체의 처리 용량과 자원 활용도가 극대화된다.

이 아키텍처의 주요 장점은 높은 가용성과 확장성이다. 한 대의 로드 밸런서에 장애가 발생하더라도 다른 활성 노드가 즉시 남은 트래픽을 수용하여 서비스 중단을 방지한다. 또한, 트래픽 증가 시 단순히 새로운 로드 밸런서를 액티브 풀에 추가함으로써 수평적 확장이 용이하다. 하지만 모든 노드가 상태 정보(예: 세션 지속성 테이블)를 공유하거나 동기화해야 하므로, 설계와 운영이 더 복잡해질 수 있다.

구현 방식은 주로 두 가지로 나뉜다. 첫째는 공유 IP 주소(VIP)를 사용하는 방식으로, VRRP나 GLBP 같은 프로토콜을 통해 여러 장비가 하나의 가상 IP를 공유하며 장애 조치를 수행한다. 둘째는 각 로드 밸런서가 고유 IP를 가지며, DNS를 통해 클라이언트를 여러 IP로 분산시키는 방식이다. 후자의 경우, DNS TTL 설정과 클라이언트의 DNS 캐싱 동작을 신중히 관리해야 한다.

액티브-액티브 구성은 고가용성이 절실한 금융 거래 시스템, 대규모 이커머스 플랫폼, 실시간 미디어 스트리밍 서비스 등에서 널리 채택된다.

글로벌 서버 로드 밸런싱은 지리적으로 분산된 여러 데이터 센터나 포인트 오브 프레전스에 위치한 서버 풀에 트래픽을 분배하는 기술이다. 이는 단일 데이터 센터 내의 서버 간 부하를 분산하는 전통적인 로드 밸런싱의 범위를 확장하여, 전 세계 사용자에게 가장 가까운 또는 최적의 성능을 제공하는 위치로 연결을 유도한다. 주요 목표는 사용자 경험을 향상시키는 것으로, 지연 시간을 최소화하고 가용성을 극대화하며 재해 복구 전략을 구현하는 데 필수적이다.

GSLB는 일반적으로 DNS 기반으로 작동한다. 사용자가 도메인 이름을 요청하면, GSLB 솔루션은 사전에 정의된 정책과 실시간 상태 확인 정보를 바탕으로 가장 적합한 데이터 센터의 IP 주소를 응답한다. 결정을 내리는 주요 정책 요소는 다음과 같다.

이 기술은 액티브-액티브 또는 액티브-스탠바이 아키텍처와 결합되어 사용된다. 액티브-액티브 구성에서는 여러 데이터 센터가 동시에 트래픽을 처리하여 용량과 성능을 확장한다. 반면, 액티브-스탠바이 구성에서는 주 데이터 센터가 모든 트래픽을 처리하다가 장애 발생 시에만 대기 중인 사이트로 트래픽이 전환되어 비즈니스 연속성을 보장한다.

GSLB 구현은 글로벌 서비스를 제공하는 기업에게 중요한 장점을 제공한다. 사용자는 항상 가장 반응이 빠른 사이트에 연결되어 웹 페이지 로딩 시간이나 애플리케이션 응답 시간이 개선된다. 또한 한 지역에 장애가 발생하더라도 다른 지역의 서비스로 트래픽이 자동으로 재라우팅되므로 서비스 중단 시간이 최소화된다. 이는 자연 재해나 대규모 네트워크 장애와 같은 상황에서도 서비스 가용성을 유지하는 데 결정적인 역할을 한다.

HTTP 부하 분산은 OSI 모델의 응용 계층에서 동작하며, HTTP 요청의 내용을 분석하여 트래픽을 분배한다. 이 방식은 라운드 로빈이나 최소 연결과 같은 기본적인 방법보다 더 지능적인 라우팅이 가능하다. 예를 들어, 요청 URL 경로, 쿠키, HTTP 헤더 정보를 기반으로 특정 서버 풀로 요청을 보낼 수 있다. 이는 마이크로서비스 아키텍처에서 /api/users 경로는 A 서버 그룹으로, /static/images 경로는 B 서버 그룹으로 라우팅하는 세밀한 트래픽 관리에 필수적이다.

HTTPS 부하 분산은 SSL/TLS로 암호화된 트래픽을 처리한다. 이때 로드 밸런서는 SSL 오프로딩 기능을 수행하여 백엔드 서버의 암호화/복호화 부담을 줄일 수 있다. 클라이언트와 로드 밸런서 사이의 연결은 HTTPS로 유지되면서, 로드 밸런서와 백엔드 서버 사이에서는 일반 HTTP로 통신할 수 있다[3]. 이를 통해 서버의 CPU 리소스를 절약하고 성능을 향상시킨다.

HTTP/HTTPS 부하 분산의 주요 구성 요소와 특징은 다음과 같다.

이러한 기능들은 웹 애플리케이션 방화벽 통합, 요청/응답 재작성, 콘텐츠 전송 네트워크와의 연동 등 고급 보안 및 성능 최적화의 기반을 제공한다. 현대의 클라우드 컴퓨팅 서비스는 이러한 HTTP/HTTPS 부하 분산 기능을 관리형 서비스로 제공하여 구성과 확장을 단순화한다.

TCP/UDP 부하 분산은 부하 분산 장치가 전송 계층에서 동작하며, TCP 또는 UDP 패킷의 헤더 정보를 기반으로 트래픽을 분배하는 방식을 의미한다. 이 방식은 주로 L4 로드 밸런서에 의해 수행되며, 패킷의 출발지 및 목적지 IP 주소와 포트 번호를 주요 판단 기준으로 사용한다. 응용 계층의 내용을 분석하지 않고 네트워크 연결 수준에서 분산을 처리하기 때문에 효율적이고 지연 시간이 짧은 것이 특징이다.

TCP 부하 분산은 가상 IP로 들어오는 클라이언트의 연결 요청(SYN 패킷)을 받아, 미리 정의된 알고리즘에 따라 백엔드 서버 중 하나로 연결을 전달한다. 이후 해당 서버와 클라이언트 간의 세션이 설정되면, 로드 밸런서는 두 방향의 패킷을 전달하는 역할을 계속 수행한다. 반면, UDP 부하 분산은 연결 지향적이지 않은 UDP 프로토콜의 특성상, 각각의 UDP 데이터그램을 독립적으로 백엔드 서버로 라우팅한다. 일반적인 사용 사례는 다음과 같다.

이러한 방식의 장점은 처리 속도가 빠르고 리소스 소모가 적다는 점이다. 그러나 패킷의 페이로드 내용을 확인하지 않기 때문에, 같은 TCP 연결 내에서도 특정 URL이나 쿠키 기반의 세션을 고려한 세부적인 라우팅은 불가능하다. 이는 L7 부하 분산과 구분되는 핵심적인 차이점이다.

SSL/TLS 오프로딩은 부하 분산 장치가 클라이언트와의 SSL/TLS 암호화 연결을 종료하고, 복호화된 일반 텍스트 트래픽을 백엔드 서버로 전달하는 기능이다. 이 과정에서 암호화 및 복호화에 필요한 높은 수준의 CPU 연산 부담이 로드 밸런서로 옮겨지게 된다. 백엔드 서버들은 암호화 처리를 하지 않아도 되므로 컴퓨팅 자원을 핵심 애플리케이션 로직 처리에 집중할 수 있다.

주요 동작 방식은 다음과 같다. 클라이언트는 로드 밸런서와 SSL 핸드셰이크를 수행하여 안전한 연결을 수립한다. 로드 밸런서는 클라이언트의 인증서를 검증하고 세션 키를 협상하여 트래픽을 복호화한다. 이후 로드 밸런서는 선택된 부하 분산 알고리즘에 따라 복호화된 요청을 백엔드 서버로 전달한다. 일반적으로 백엔드 서버까지의 내부 네트워크는 신뢰할 수 있는 영역으로 간주되어 암호화되지 않은 HTTP 트래픽이 전송되거나, 필요에 따라 별도의 인증서를 사용해 서버와 로드 밸런서 간에 새로운 암호화 채널을 구성하기도 한다[4].

이 기술의 장점과 고려사항은 아래 표와 같다.

SSL/TLS 오프로딩은 특히 HTTPS 트래픽이 주를 이루는 현대 웹 서비스에서 서버 자원 효율화와 중앙 집중식 보안 정책 적용을 위해 널리 사용된다.

부하 분산 장치가 백엔드 서버 풀의 정상 여부를 지속적으로 확인하는 프로세스를 헬스 체크라고 한다. 이는 장애가 발생한 서버로 트래픽이 전달되는 것을 방지하여 서비스의 가용성과 안정성을 보장하는 핵심 기능이다. 헬스 체크는 주기적으로 각 서버에 프로브 요청을 보내고, 응답의 성공 여부 또는 지연 시간을 기준으로 서버의 상태를 판단한다.

헬스 체크는 크게 두 가지 방식으로 구분된다. 첫째는 액티브 헬스 체크로, 로드 밸런서가 능동적으로 서버에 정해진 간격으로 요청(예: ICMP 핑, TCP 연결 시도, 특정 HTTP 경로 요청)을 보내는 방식이다. 둘째는 패시브 헬스 체크로, 실제 사용자 트래픽을 처리하는 과정에서 서버의 응답(예: 연결 시간 초과, HTTP 5xx 오류 코드)을 모니터링하여 상태를 추론하는 방식이다. 일반적으로 두 방식을 조합하여 사용한다.

주요 헬스 체크 메커니즘은 다음과 같다.

헬스 체크 결과에 따라 서버는 정상, 비정상, 또는 유예 상태로 분류된다. 비정상으로 판단된 서버는 로드 밸런싱 풀에서 자동으로 제외되며, 설정된 횟수만큼 연속해서 정상 응답을 받으면 다시 풀에 포함된다. 이 과정을 통해 서비스는 무중단 운영과 자동화된 장애 복구가 가능해진다.

세션 지속성은 부하 분산 장치가 동일한 클라이언트로부터의 요청을 항상 동일한 백엔드 서버로 전달하도록 보장하는 메커니즘이다. 이는 클라이언트의 상태 정보(세션)가 특정 서버에 저장되어 있는 경우, 그 서버로 요청이 지속적으로 전달되어야 정상적인 서비스가 가능하기 때문에 필요하다. 예를 들어, 사용자의 장바구니 정보나 로그인 상태가 하나의 서버에 저장되어 있을 때, 이후 요청이 다른 서버로 전달되면 해당 정보를 잃게 된다. 세션 지속성은 이러한 문제를 해결하여 사용자 경험을 보장한다.

세션 지속성을 구현하는 주요 방법은 다음과 같다.

이러한 지속성은 설정된 시간 동안 유지되거나, 명시적으로 종료될 때까지 유지된다. 그러나 지나친 세션 지속성은 서버 간 부하의 불균형을 초래할 수 있다. 한 서버에 많은 세션이 고정되면 그 서버의 부하가 높아지는 반면, 다른 서버는 상대적으로 유휴 상태가 될 수 있다. 따라서 세션 지속성의 시간을 적절히 설정하거나, 세션 클러스터링이나 외부 세션 저장소(예: Redis, Memcached)를 활용하여 상태 정보를 서버에서 분리하는 아키텍처를 고려하기도 한다.

AWS Elastic Load Balancing은 아마존 웹 서비스 환경에서 제공하는 관리형 부하 분산 서비스이다. 이 서비스는 애플리케이션의 트래픽을 여러 EC2 인스턴스, 컨테이너, IP 주소와 같은 여러 대상에 자동으로 분배한다. ELB는 애플리케이션의 내결함성을 높이고 확장성을 제공하는 데 핵심적인 역할을 한다.

AWS는 애플리케이션의 요구 사항에 따라 선택할 수 있는 여러 유형의 로드 밸런서를 제공한다. 주요 유형은 다음과 같다.

ALB는 가장 널리 사용되는 유형으로, HTTP 요청의 내용(예: URL 경로, 호스트 헤더)을 기반으로 트래픽을 라우팅하는 고급 라우팅 기능을 제공한다. 이를 통해 단일 로드 밸런서 뒤에서 여러 애플리케이션 또는 서비스를 운영할 수 있다. 또한 웹소켓 및 HTTP/2와 같은 최신 프로토콜을 기본적으로 지원하며, SSL/TLS 암호 해독(오프로딩)을 수행하여 백엔드 서버의 부하를 줄인다.

ELB/ALB는 AWS 클라우드의 다른 서비스와 긴밀하게 통합되어 운영을 단순화한다. Auto Scaling 그룹과 연동되어 트래픽 증가에 따라 자동으로 백엔드 용량을 확장하거나 축소할 수 있다. 또한 Amazon CloudWatch를 통해 로드 밸런서와 백엔드 대상의 상태, 트래픽 지표를 모니터링할 수 있다. 사용자는 로드 밸런서를 생성하고 대상 그룹을 구성하는 것만으로 서비스를 시작할 수 있으며, 하드웨어 프로비저닝이나 소프트웨어 유지 관리에 대한 부담이 없다는 것이 관리형 서비스의 주요 장점이다.

Azure Load Balancer는 마이크로소프트 애저 클라우드 플랫폼에서 제공하는 완전 관리형 부하 분산 장치 서비스이다. 애저 가상 머신, 가상 머신 확장 집합, 컨테이너 인스턴스와 같은 리소스로 들어오는 트래픽을 분산하여 애플리케이션의 가용성과 확장성을 높인다.

Azure Load Balancer는 두 가지 기본 계층(SKU)으로 제공된다. Standard SKU와 Basic SKU가 있으며, 기능과 성능에 차이가 있다. Standard SKU는 고가용성, 영역 중복성, 더 높은 규모의 백엔드 풀, 가용성 영역 지원, 보안 강화를 위한 아웃바운드 연결 관리 등 향상된 기능을 제공한다. 반면 Basic SKU는 더 간단한 시나리오와 개발/테스트 환경에 적합한 기본적인 부하 분산 기능을 제공한다.

이 서비스는 OSI 모델의 전송 계층(계층 4)에서 동작하며, TCP와 UDP 프로토콜을 기반으로 트래픽을 분산한다. 주요 구성 요소는 다음과 같다.

Azure Load Balancer는 공용 로드 밸런서와 내부(프라이빗) 로드 밸런서로 구분된다. 공용 로드 밸런서는 인터넷에서 들어오는 트래픽을 가상 네트워크 내부의 리소스로 분산시키고, 내부 로드 밸런서는 가상 네트워크 내부의 트래픽만을 분산한다. 또한, 아웃바운드 연결을 자동으로 제공하여 백엔드 인스턴스들이 인터넷이나 다른 서비스와 통신할 수 있게 한다.

Google Cloud Load Balancing은 구글 클라우드 플랫폼에서 제공하는 완전 관리형 부하 분산 서비스이다. 이 서비스는 단일 지역 또는 전 세계에 분산된 인스턴스 그룹, 컨테이너, 가상 머신에 트래픽을 분산시키도록 설계되었다. 사용자는 인프라를 프로비저닝하거나 관리할 필요 없이 고가용성과 확장성을 확보할 수 있다.

Google Cloud Load Balancing은 여러 유형을 제공하며, 각각 다른 계층과 사용 사례에 최적화되어 있다. 주요 유형은 다음과 같다.

이 서비스는 자동 확장, 통합 상태 확인, SSL/TLS 오프로딩과 같은 기능을 포함한다. 특히 글로벌 외부 부하 분산은 애니캐스트 기술을 활용하여 사용자 요청을 지리적으로 가장 가까운 정상 백엔드로 자동 라우팅하여 지연 시간을 최소화한다[6]. 또한 Cloud CDN과 통합되어 정적 및 동적 콘텐츠 전송 성능을 향상시킬 수 있다.

운영 측면에서 Google Cloud Load Balancing은 Cloud Monitoring 및 Cloud Logging과 완전히 통합되어 실시간 성능 메트릭, 로그, 추적 데이터를 제공한다. 이를 통해 운영자는 트래픽 패턴을 분석하고, 문제를 진단하며, 비용을 최적화할 수 있다. 모든 부하 분산 유형은 관리 콘솔, gcloud 명령줄 도구, 또는 Terraform과 같은 IaC 도구를 통해 구성 및 관리된다.