Written by Google Gemini 2.5 Pro
- Deep Research 정리 문서: https://docs.google.com/document/d/1Bwx6voatv_vBj-aGnSgc7PJZmKLdmLi7Ll5-xGqgZ9s/edit?tab=t.0
📌 1. 로드밸런싱의 개념과 필요성
가. 로드밸런싱이란?
- 로드밸런싱은 애플리케이션에 가해지는 트래픽 부하(Load)를 여러 대의 서버에 효율적으로 분산(Balancing)하는 기술이다.
- 이 작업을 수행하는 하드웨어 또는 소프트웨어를
로드밸런서(Load Balancer)라고 하며, 클라이언트와 서버 그룹 사이에 위치하여 ‘교통 경찰’ 역할을 수행한다.
나. 로드밸런싱의 핵심 이점
고가용성: 일부 서버에 장애가 발생해도 정상 작동하는 다른 서버로 트래픽을 자동 전환하여 서비스 중단을 방지한다.확장성: 트래픽 증감에 따라 서버를 유연하게 추가하거나 제거하여 시스템 규모를 손쉽게 조정할 수 있다.성능 향상: 특정 서버의 과부하를 막고 자원을 최적으로 활용하여 전체적인 응답 속도를 개선할 수 있다.보안 강화: DDoS와 같은 공격 트래픽을 분산시키고, 웹 방화벽(WAF)과 연동하여 보안 위협을 완화한다.
다. 로드밸런싱의 필요성: Scale-Up vs Scale-Out
- 과거에는 서버 성능을 높이는
스케일업(Scale-Up)방식으로 트래픽 증가에 대응했지만, 비용이 비싸고 성능 향상에 한계가 있으며, 서버 자체가단일 장애점(SPOF, Single Point of Failure)이 되는 치명적 단점이 있었다. - 이를 극복하기 위해 여러 대의 서버를 추가하는
스케일아웃(Scale-Out)방식이 등장했으며, 이 방식의 이점을 극대화하기 위해 여러 서버에 트래픽을 지능적으로 분배하는 로드밸런싱이 필수 기술이 되었다.
라. L4 vs L7 로드밸런서
| 특징 | L4 (전송 계층) | L7 (애플리케이션 계층) |
|---|---|---|
| 분산 기준 | IP 주소, 포트 번호 | HTTP 헤더, 쿠키, URL 등 콘텐츠 정보 |
| 장점 | 패킷 내용 미확인으로 처리 속도 빠름, 비용 저렴 | 콘텐츠 기반의 정교하고 지능적인 라우팅 가능 |
| 단점 | 단순 IP/포트 기반 분산만 가능, 세밀한 제어 불가 | 패킷 내용 분석으로 인한 부하 및 비용 증가 |
📌 2. 로드밸런싱 알고리즘과 기술 원리
가. 정적 알고리즘
서버의 현재 상태와 무관하게, 사전에 정의된 규칙에 따라 요청을 분배한다.
라운드 로빈 (Round Robin): 요청을 서버 목록에 따라 순차적으로 분배하는 가장 기본적인 방식가중 라운드 로빈 (Weighted Round Robin): 서버의 처리 성능에 따라 가중치를 부여하고, 가중치가 높은 서버에 더 많은 요청을 할당하는 방식IP 해시 (IP Hash): 클라이언트의 IP 주소를 해싱하여 특정 서버로만 요청을 보내 세션 유지를 도움
나. 동적 알고리즘
서버의 실시간 부하 상태를 확인하여 최적의 서버로 요청을 분배한다.
최소 연결 (Least Connection): 현재 연결 수가 가장 적은 서버로 요청을 보내, 세션이 길어지는 서비스에 유리하다.최소 응답 시간 (Least Response Time): 연결이 가장 적으면서 응답 시간도 가장 빠른 서버로 요청을 보내 사용자 경험을 극대화한다.
다. 로드밸런서 이전의 부하 분산: DNS 라운드 로빈
- 전용 로드밸런서가 보편화되기 전에는, 하나의 도메인에 여러 서버의 IP를 등록하고 DNS 서버가 이를 순차적으로 응답해주는
DNS 라운드 로빈방식을 사용했다. - 하지만 이 방식은 서버의 장애 여부를 감지하지 못하고, DNS 캐시 문제로 인해 부하가 균등하게 분산되지 않는 명확한 한계가 있었다.
📌 3. 장애 대응 및 고가용성
가. 장애 감지: 헬스 체크 (Health Check)
- 로드밸런서는 주기적으로 백엔드 서버의 상태를 점검(헬스 체크)하여 장애 여부를 판단한다.
- L4 헬스 체크는 포트 활성화 여부를, L7 헬스 체크는 실제 애플리케이션의 정상 응답(예: HTTP 200 OK) 여부를 확인하여 더 정확한 장애 감지가 가능하다.
나. 자동화된 장애 처리 (Failover)
- 헬스 체크를 통해 특정 서버에 장애가 감지되면, 로드밸런서는 해당 서버를 트래픽 분배 대상에서 즉시 제외하고 나머지 정상 서버로만 요청을 자동 전환한다.
- 장애가 복구되면 다시 트래픽 분배 대상에 포함시켜 서비스 연속성을 보장한다.
다. 단일 장애점(SPOF) 제거: 이중화 구성
- 로드밸런서 자체의 장애에 대비하기 위해, 두 대 이상의 로드밸런서를 클러스터로 구성하여 이중화한다.
Active-Standby: 한 대(Active)가 동작하고 다른 한 대(Standby)는 대기하다가, 장애 발생 시 Standby 장비가 즉시 역할을 이어받는 방식이다.Active-Active: 두 대 이상의 장비가 동시에 트래픽을 처리하여 자원 효율성을 높이고 장애 발생 시에도 중단 없이 서비스를 운영하는 방식이다.
📌 4. 클라우드 플랫폼별 로드밸런서 비교: AWS vs NCP
| 기능 | AWS (Elastic Load Balancing) | NCP (Load Balancer) |
|---|---|---|
| L7 (Application) | Application Load Balancer (ALB): 경로, 헤더 등 정교한 L7 라우팅 규칙 제공. 대상 그룹에 EC2, 컨테이너, Lambda 등 다양한 리소스 지정 가능. | Application Load Balancer: 고정 IP 제공, URL 경로 및 호스트 헤더 기반 라우팅 지원. |
| L4 (Network) | Network Load Balancer (NLB): 초저지연, 고성능 L4 처리. 고정 IP(Elastic IP) 할당 가능. | Network LB: DSR(Direct Server Return) 모드 지원으로 응답 성능 극대화. |
| 알고리즘 | ALB: 라운드 로빈, 최소 미결 요청NLB: 플로우 해시 | 라운드 로빈, 최소 연결, 소스 IP 해시 |
| 요금 정책 | 시간당 요금 + LCU(처리 용량 단위) 기반의 복잡한 종량제 | 성능 등급(Small/Medium/Large)에 따른 고정 시간당 요금 + 아웃바운드 트래픽 기반으로 예측 용이 |
📌 5. 핵심 과제: 세션 유지(Session Persistence) 문제와 해결 방안
- 로드밸런싱 환경에서는 클라이언트의 요청이 매번 다른 서버로 전달될 수 있어, 로그인 정보와 같은 세션 데이터가 유지되지 않는 문제가 발생한다.
- 이를 ‘세션 불일치’ 문제라고 하며, 해결을 위해 특정 사용자의 요청을 하나의 서버로 고정시키는 ‘세션 유지’ 기술이 필요하다.
가. IP 해시 방식 (IP Hash Method)
동작 원리
- 클라이언트의 출발지 IP 주소를 해시 함수에 입력하여 그 결과값에 따라 특정 서버를 고정적으로 할당한다.
- 클라이언트의 IP가 바뀌지 않는 한, 모든 요청은 항상 같은 서버로 전달된다.
장점
- 별도의 설정 없이 간단하게 세션 유지를 구현할 수 있다.
단점
- 여러 사용자가 하나의 공인 IP를 공유하는 환경(예: 대기업, 공공기관의 NAT)에서는 모든 요청이 단 하나의 서버에만 집중되어 로드밸런싱의 의미가 퇴색된다.
- 또한, 모바일 환경처럼 사용자의 IP가 자주 바뀌면 세션이 끊어지는 문제가 발생한다.
나. 스티키 세션 (Sticky Session / 쿠키 기반)
동작 원리
- 클라이언트의 첫 요청 시, 로드밸런서나 애플리케이션 서버가 클라이언트의 브라우저에 특정 서버 정보를 담은 쿠키를 심는다.
- 이후 클라이언트가 요청을 보낼 때마다 로드밸런서는 이 쿠키를 확인하여 지정된 서버로 요청을 전달함으로써 세션을 고정시킨다.
장점
- IP 주소 대신 고유한 쿠키를 사용하므로, NAT 환경의 IP 중복 문제를 해결할 수 있다.
단점
- 특정 서버에 사용자가 몰릴 경우 부하가 불균등해질 수 있으며, 가장 큰 문제는 세션이 고정된 서버에 장애가 발생하면 해당 서버에 저장된 모든 세션 정보가 유실된다는 점이다.
다. 세션 스토리지 분리
- IP 해시와 스티키 세션은 구현이 간단하지만 근본적인 한계를 가진다. 이 때문에 현대적인 아키텍처에서는 세션 스토리지 분리 방식을 선호한다.
- 이는 세션 데이터를 각 서버의 메모리가 아닌, 모든 서버가 접근할 수 있는 별도의 외부 저장소(예: Redis, Memcached와 같은 인메모리 데이터베이스)에 저장하는 방식이다.
- 이 방식을 사용하면 사용자의 요청이 어떤 서버로 전달되든 동일한 세션 데이터에 접근할 수 있어 로드밸런싱과 고가용성을 동시에 달성할 수 있다.
- 다만, 세션 저장소 자체가 또 다른 단일 장애점이 되지 않도록 이중화 구성이 필요하다.