[Network] 로드밸런싱

do_it·2025년 9월 18일
네트워크

network

목록 보기
11/12

0. 로드밸런서(Load Balancer)?

: 서버, 네트워크, 애플리케이션에 들어오는 트래픽을 여러 대의 서버나 리소스에 고르게 분산시켜주는 장치 또는 소프트웨어

→사용자의 요청(트래픽)을 여러 대의 서버에 골고루 나눠주는 교통정리 신호등 같은 역할

but 단순한 트래픽 분산기가 아닌 확장서 / 안정성 / 성능 최적화 / 보안까지 책임지는 핵심 네트워크 인프라 구성요소


등장 배경

→ 웹 서비스가 대규모로 성장하면서 등장한 필수 인프라

  1. 1990년대 : 단일 서버 → 멀티 서버의 필요성
    초창기 웹은 한 서버에서 모든 요청 처리
    인터넷 사용자 증가 → 단일 서버 한계
  2. 1990년대 후반: 하드웨어 로드밸런서 등장
    F5, Cisco 등 네트워크 장비 업체가 로드밸런싱 하드웨어 제공
    주로 L4 수준 분산 분산 처리 (TCP / UDP 기반)
  3. 2000년대: L7 로드밸런싱 필요성 증가
    동적 웹 애플리케이션, 다양한 API 등장
    단순한 연결 분산을 넘어 URL, 쿠키, 세션 기반 라우팅 필요
    → 소프트웨어 기반 로드 밸런서(HAProxy, Nginx) 확산
  4. 2010년 이후: 클라우드 & 마이크로서비스 시대
    클라우드 환경(AWS ELB, GCP LB)에서 관리형 로드밸런서 제공
    쿠버네티스, 서비스 메쉬(Istio, Linkerd) 등장으로 로드밸런싱이 인프라 핵심 요소로 자리잡음

구현 환경 & 사용

환경특징
웹(온프레미스)서버 앞에 설치, Nginx/HAProxy/F5 사용
클라우드클라우드 매니지드 LB(ALB/NLB 등), Auto Scaling 연계
글로벌리전 간 트래픽 분산, DNS 기반 또는 Anycast 활용
  • 웹 서비스:
    대규모 웹 애플리케이션(예: 네이버, 구글, 넷플릭스)에서 사용자 요청을 여러 서버로 분산
  • 데이터베이스:
    읽기 전용 쿼리를 여러 replica DB로 분산
  • 마이크로서비스 아키텍처:
    서비스 간 호출을 분산하고, 장애를 최소화
  • 클라우드 인프라:
    AWS ELB, GCP Load Balancing, Azure Load Balancer 같은 매니지드 서비스로 기본 제공

주요 역할 : 왜 중요한가?

구분(구축 환경)웹(Web, 온프레미스)클라우드(Cloud)글로벌(Global)
구축 위치자체 서버나 IDC 내부VPC 안의 서브넷에 배치됨

퍼블릭 LB는 인터넷에 연결된 서브넷
프라이빗 LB는 내부 서브넷에 연결 | 전 세계 여러 리전/데이터센터 |
| 기술 계층 | 주로 L4/L7 | L4/L7 + 매니지드 서비스 | DNS 기반, Anycast, GSLB |
| 스케일링 방식 | 수평 확장(Scale-out), 세션 스티키(Sticky Session) | Auto Scaling Group, Health Check | 지역 간 트래픽 우회, 리전 단위 스케일링 |
| 운영 관리 | 직접 설정 및 유지보수 필요 | 클라우드 벤더가 관리 | DNS 정책/라우팅 규칙 관리 |
| 장점 | 세밀한 제어, 자체 보안 정책 적용 | 자동화, 고가용성, 빠른 확장 | 전 세계 사용자에게 낮은 레이턴시, 글로벌 장애 대응 |
| 한계 | 확장성 한계(하드웨어 의존성)
, 비용(장비) 부담 | 벤더 종속성, 비용 증가 가능 | 구축/운영 복잡, 비용 매우 높음 |
| 대표 사례 | 기업 내부 웹 서비스, 전자상거래 사이트 | SaaS, 마이크로서비스 아키텍처, 모바일 앱 백엔드 | 글로벌 스트리밍, 게임 서비스, 멀티 리전 웹앱 |
| 대표 기술/제품 | Nginx, HAProxy, F5, LVS | AWS ELB/ALB/NLB, GCP LB, Azure LB, Kubernetes Ingress | Cloudflare, Akamai GSLB, AWS Route 53, NS1 |

  1. 트래픽 분산 → 성능 향상 (Scalability)
  • 하나의 서버가 처리할 수 있는 요청 수에는 한계가 있음
  • 모든 요청이 한 서버로 몰리지 않고, 여러 서버에 요청을 분산시켜 성능을 높임
  1. 장애 극복 (Fault Tolerance) → 가용성 (High Availability)
  • 헬스 체크 (Health Check):
    각 서버의 상태를 주기적으로 확인, 장애가 발생한 서버는 트래픽 대상에서 제외함
  • 특정 서버가 다운되더라도 다른 서버로 트래픽을 보내어 서비스를 멈추지 않게 함
  1. 성능 최적화 (Performance Optimization)
  • 응답 속도가 빠른 서버에 더 많은 요청을 보내거나, 현재 연결이 적은 서버를 우선 선택
  1. 보안 강화
  • 서버의 실제 IP를 감추거나 SSL 인증서 처리를 로드밸런서가 대신 수행
  1. 유연성
  • 특정 요청 패턴(이미지, 동영상, API…등)을 분리하여 적절한 서버로 보내 효율적인 아키택처 설계가 가능함

1-1. L4 로드 밸런서 & L7 로드 밸런서

  • 대규모 서비스에서는 L4 + L7 혼합을 많이 사용
  • L4로 1차 분산 (대규모 트래픽 처리)
  • L7로 2차 라우팅 (세밀한 서비스 제어)
계층구현 방식특징
L4 (전송 계층)TCP/UDP 패킷 단위 라우팅- IP/포트 기반 요청 분산- 상태 정보 최소- 고성능, 빠름
L7 (애플리케이션 계층)HTTP/HTTPS, gRPC 요청 내용 분석- URL, 쿠키, 헤더 기반 분산 가능- 세션 유지, SSL 종료 가능- 부하 조절 정책 다양

(1) L4 로드밸런서 (Transport Layer, 전송 계층)

[동작 원리]

  • IP 주소와 포트 번호 기반으로 분산
  • TCP/UDP 연결 기반으로 분산

[장점]

  • OSI 계층이 낮은 수준에서 동작하므로 처리 오버헤드가 작고 빠름
  • 대규모 요청에 적합 (수십만 ~ 수백만)

[적합한 서비스 예시]

  • 게임 서버 (UDP 기반, 많은 세션)
  • 동영상 스트리밍 (http / https 단순 분산)
  • 실시간 채팅 / 메시징 서비스 (TCP 연결 기반)
  • 단순 웹 서버 확장 (정적 파일 서비스)

(2) L7 로드밸런서 (Application Layer, 응용 계층)

[동작 원리]

  • HTTP, HTTPS등 애플리케이션 계층의 데이터를 기반으로 분산
  • 요청 URL, 헤더, 쿠키 등의 조건에 따라 트래픽 라우팅 가능

[장점]

  • 지능적 라우팅: 세밀한 분기 처리 가능
  • SSL 종료 (HTTPS 복호화)처리 가능
  • API Gateway 처럼 특정 요청을 특정 서비스로 연결 가능

[단점]

  • 마이크로서비스 아키텍처 (URL별로 다른 서비스 호출)
  • REST API 서버 (/user, /order, /payment 등을 다른 서버에 분산)
  • 멀티 테넌트 서비스 (쿠키/도메인 기반으로 서버 분리)

1-2. SSL 종료 (TLS Termination)?

L7 로드밸런서는 애플리케이션 계층의 데이터를 이해하고 다룰 수 있기 때문에, HTTPS 요청의 암호화를 풀어서 처리하는 기능(TLS Termination)을 자주 담당

SSL(Secure Sockets Layer):
인터넷에서 데이터를 암호화해서 안전하게 주고받기 위한 보안 프로토콜

  • 현재는 SSL의 후속인 TLS(Transport Layer Security)가 주로 쓰임
    (SSL이라는 용어가 관습적으로 계속 사용됨)
  • 핵심 기능:
    1. 암호화(Encryption): 데이터가 전송 중 노출되지 않도록 보호
    2. 인증(Authentication): 서버(또는 클라이언트)의 신원을 인증 (예: 인증서)
    3. 무결성(Integrity): 데이터가 중간에 변조되지 않았음을 보장

👉 HTTPS = HTTP + SSL/TLS

SSL & 로드밸런싱

로드밸런서는 클라이언트와 서버 사이에서 트래픽을 중계

SSL이 적용된 트래픽(HTTPS)은 요청이 암호화되어 있어 단순 분산이 어려워
URL, 헤더, 쿠키 같은 L7 정보를 확인할 수 없음

→ 로드밸런싱에서 SSL 처리를 어떻게 하느냐?가 중요
⇒ 둘의 관계 : 암호화된 트래픽을 분산할 때, SSL을 LB에서 처리할지 서버에서 처리할지 결정

방식설명특징
SSL Termination (종료)LB에서 SSL을 해제(복호화)하고, 내부 서버에는 평문 HTTP로 전달LB에서 CPU 부담 있음, 내부 통신은 암호화되지 않음
SSL Passthrough (투과)LB가 암호화된 트래픽을 그대로 서버로 전달, 서버에서 SSL 해제LB 부담 적음, 서버가 SSL 인증서 관리해야 함
SSL OffloadingLB에서 SSL 해제 후, 추가 기능(캐싱, 압축, 라우팅 등)을 적용한 뒤 서버로 전달Termination의 확장판, 고급 기능 활용 가능

TLS Termination

: 로드 밸런서나 프록시 서버가 클라이언트와 서버 사이의 TLS 암호화 연결을 중간에서 해제(복호화)하는 것

  • 클라이언트 → 로드밸런서 구간: HTTPS (암호화)
  • 로드밸런서 → 백엔드 서버 구간: HTTP(평문)

[장점]

  1. 서버 부하 감소
    https 암복호화 연산은 cpu 리소스를 많이 사용하는데,
    로드밸런서가 대신 처리하면 애플리케이션 서버는 비즈니스 로직에만 집중할 수 있음
  2. 중앙 집중적 인증서 관리
    각 서버마다 SSL 인증서를 설치, 갱신할 필요 없음
    로드밸런서에서만 인증서를 관리하면 됨 → 운영 효율성 증대
  3. 트래픽 제어 가능
    복호화된 상태에서 HTTP 헤더, URL, 쿠키를 분석할 수 있어 정교한 L7 라우팅 가능
    WAF(Web Application Firewall)와 같은 보안 정책 적용도 용이
  4. 모니터링 / 로깅 용이
    암호화가 풀린 요청을 확인할 수 있으므로, 접근 로그 / 분석이 더 쉽고 상세해짐

[단점]

  1. 로드밸런서 부하 증가
    암호화 / 복호화 연산이 모두 로드밸런서에서 발생
    대규모 트래픽 환경에서는 성능 한계가 문제될 수 있음
  2. 단일 장애 지점 (Single Point of Failure)
    인증서와 암호화 처리를 모두 로드밸런서가 담당하기 때문에, 장애 시 전체 서비스에 영향
  3. 복잡성 증가
    보안을 강화하려면 로드밸런서 → 서버 구간도 HTTPS (Re-encryption) 설정을 추가해야 함
  4. 보안 약화 가능성
    로드밸런서 이후 구간(내부망)에서는 평문(HTTP)으로 전달되는 경우가 많음
    내부 네트워크가 안전하지 않다면 데이터 노출 위험있음

⇒ 상황에 따라 SSL 종료만 쓰거나 SSL+ 재암호화 혼합해서 사용

[cf.] 로드밸런싱 알고리즘

알고리즘설명활용 예
Round Robin순서대로 서버 선택서버 부하 균일할 때
Least Connections연결 수 가장 적은 서버 선택세션 길이가 다양할 때
IP Hash / Sticky Session클라이언트 IP 또는 세션 기반
특정 IP의 요청은 항상 같은 서버로 보냄세션 상태 유지 필요할 때
Weighted Round Robin / Least Connections성능이 좋은 서버에 더 많은 트래픽 할당서버 성능이 균일하지 않을 때

1-3. Sticky Session

: 같은 사용자의 요청을 항상 같은 서버로 보내도록 고정하는 방법

항목설명
문제로드밸런서가 요청을 분산시킬 때, 사용자 세션이 서버 간에 공유되지 않으면 로그인 상태 등이 유지되지 않음
해결책스티키 세션을 적용하면 같은 사용자의 요청을 동일 서버로 보내므로 세션 유지 가능
로드밸런서 역할클라이언트 식별자(쿠키, IP 등)를 바탕으로 요청을 같은 서버로 라우팅
단점특정 서버에 부하 집중 가능, 장애 시 세션 손실 위험
  • 일반적인 로드밸런서
    요청이 들어오면 라운드로빈, IP 해시 등으로 서버를 선택
    → 같은 사용자의 연속 요청도 다른 서버로 갈 수 있음
  • 문제점
    서버가 세션 상태를 메모리에 저장할 때, 다른 서버로 가면 세션 정보가 없어짐
    → 로그인, 장바구니 등 문제 발생
  • Sticky session 적용
    LB가 특정 사용자를 특정 서버에 계속 연결함으로써 세션 상태 문제 해결

[구현 방식]

방식설명
쿠키 기반(Cookie-based)LB가 사용자 브라우저에 쿠키를 심고, 쿠키 값으로 요청을 특정 서버로 라우팅
IP 해시 기반(IP Hash)사용자의 IP를 해시 계산 → 항상 같은 서버로 연결
세션 토큰 기반애플리케이션이 발급한 세션 토큰으로 LB에서 라우팅

2. [클라우드]

1. ALB vs NLB (L7 vs L4)

구분L4 (전송 계층)L7 (애플리케이션 계층)
특징TCP/UDP 기반, 빠르고 고성능HTTP/HTTPS 기반, URL/Host/Cookie 라우팅 가능
장점저지연, 수백만 TPS 처리 가능세밀한 트래픽 제어, SSL/TLS 종료, Sticky Session 가능
AWS 예시NLBALB
활용 사례게임 서버, 금융 트랜잭션, IoT웹 애플리케이션, REST API, 마이크로서비스

2. 글로벌 트래픽 관리

Global LB vs DNS 기반 트래픽 분산

구분Global LBDNS 기반 분산 (Route 53, Cloud DNS 등)
방식Anycast IP 또는 글로벌 인프라 기반 라우팅DNS 응답을 다르게 반환 (Geo, Latency, Weighted)
특징전 세계 사용자에게 하나의 IP 제공, 지연 최소화클라이언트 DNS 캐시 영향 → 빠른 Failover 어려움
장점빠른 장애 감지 및 트래픽 재라우팅, 실시간 글로벌 최적화단순하고 저비용, DNS 기반 정책 다양
한계서비스 비용이 높음캐싱 문제로 즉각적 트래픽 전환이 어렵다

3. SSL/TLS Termination & ACM

  • SSL/TLS Termination: 로드 밸런서에서 암호화 트래픽 해제 → 서버는 평문 HTTP 처리
  • ACM (AWS Certificate Manager): SSL/TLS 인증서를 자동 발급·갱신 관리
  • 장점:
    • 서버 부하 감소 (암호화 연산 LB에서 처리)
    • 인증서 관리 단순화 (중앙 집중 관리)
    • L7 기능 활용 가능 (헤더 기반 라우팅, WAF 연계)

4. Auto Scaling과 LB 연동 방식

  • 로드 밸런서는 Auto Scaling Group(ASG) 과 자동 연계됨
  • 프로세스:
    1. 트래픽 증가 → Auto Scaling이 새 인스턴스 생성
    2. LB Health Check를 통과하면 Target Group에 자동 등록
    3. 트래픽 감소 → 인스턴스 자동 제거 & LB 대상에서 해제
  • 효과: 무중단 서비스 확장/축소 가능

5. 멀티 리전/하이브리드 아키텍처에서 LB 설계

  • 멀티 리전: 각 리전에 LB 배치 → 글로벌 LB 또는 DNS 기반으로 트래픽 분산
    • 장점: 장애 시 DR(Disaster Recovery) 가능, 사용자 지연 최소화
    • 고려: 데이터 동기화, 비용 증가
  • 하이브리드: 온프레미스 + 클라우드 LB 혼합
    • 전용 회선(VPN/Direct Connect)으로 연결
    • 클라우드 LB + 온프레미스 LB 이중 구성

6. CDN(Content Delivery Network)과 글로벌 트래픽 관리

  • CDN: 전 세계 PoP(Point of Presence)에 콘텐츠 캐싱 → 사용자에게 가장 가까운 서버에서 콘텐츠 제공
  • LB vs CDN 차이:
    • LB: 애플리케이션 서버 트래픽 분산
    • CDN: 정적/캐싱 가능한 콘텐츠 최적화 제공
  • 함께 사용하는 구조:
    • 클라이언트 → CDN (캐싱/Edge 보안) → LB (동적 요청 처리) → 서버
  • 효과:
    • 응답 속도 개선
    • 서버 부하 감소
    • 글로벌 트래픽 최적화
profile
do_it
이전 포스트

[Network] VPC

다음 포스트

[Network] 프록시

0개의 댓글