2편: 로드밸런싱 정복 - 개념, 필요성, 종류

들어가며

웹 서비스가 처음 시작될 때는 하나의 서버만으로도 충분합니다

하지만 사용자가 늘어나고 트래픽이 증가하면서 서버 한 대로는 버틸 수 없는 순간이 찾아오게 됩니다

이때 개발자들은 선택의 기로에 서게 되는데, 더 강력한 서버로 바꿀 것인가? 서버를 여러대로 늘릴 것인가?

→ 이 선택에서 시작되는 것이 바로 로드밸런싱입니다

1. 로드 밸런싱이 필요한 이유

1.1 단일 서버의 한계

하나의 서버에서 모든 요청을 처리하는 경우

사용자 요청 → 서버 → 응답

하지만 시간이 지나면서 문제가 발생함

성능 병목 현상

• CPU 사용률 100%
• 메모리 부족
• 네트워크 대역폭 포화

가용성 문제

• 서버 장애 시 전체 서비스 중단
• 단일 장애점(Single Point of Failure)

확장성 한계

• 트래픽 증가에 대한 대응 어려움
• 특정 시간대 폭증하는 요청 처리 불가

⇒ 이를 해결하기 위해 확장 방식을 선택하게 된다

2. 수직적 확장 vs 수평적 확장

2.1 수직정 확장 (Scale-up)

더 강력한 서버로 업그레이드 하는 방법

기존: CPU 2코어, RAM 4GB, SSD 100GB
업그레이드: CPU 8코어, RAM 32GB, SSD 500GB

장점

• 구현이 간단함(기존 코드 변경 X)
• 네트워크 복잡성X
• 데이터 일관성 문제X

단점

• 비용이 기하급수적으로 증가
• 물리적 한계 존재(더 이상 업게르이드 불가능한 지점)
• 여전히 단일 장애점 문제
• 다운 타임발생 (하드웨어 교체 시)

실제 사례

AWS EC2 인스턴스 비용 비교 (월 기준)
- t3.micro (1vCPU, 1GB RAM): $8.5
- t3.small (2vCPU, 2GB RAM): $16.8
- t3.medium (2vCPU, 4GB RAM): $33.6
- t3.large (2vCPU, 8GB RAM): $67.2
- t3.xlarge (4vCPU, 16GB RAM): $134.4
- t3.2xlarge (8vCPU, 32GB RAM): $268.8

→ 성능이 2배 올라갈 때마다 비용도 2배씩 증가함

2.2 수평적 확장 (Scale-Out)

서버를 여러대로 늘리는 방법

기존: 서버 1대
확장: 서버 4대 (동일한 스펙)

장점

• 비용 효율성 (선형적 비용 증가)
• 무한 확장 가능성
• 장애 복원력 (하나 죽어도 다른 서버들이 살아있음)
• 점진적 확장 가능

단점

• 구현 복잡도 증가
• 네트워크 레이턴시 (=Network Latency): 데이터가 한 지점에서 다른 지점으로 이동하는데 걸리는 시간
• 데이터 일관성 문제
• 세션 관리 복잡성

2.3 수평적 확장을 선택하는 이유

1. 비용 효율성

• 동일한 성능을 더 저렴하게 달성
• 필요에 따라 점진적으로 확장 가능

1. 높은 가용성

• 서버 하나가 죽어도 서비스 지속 가능
• 무중단 배포 가능

1. 지리적 분산

• 전 세계 여러 지역에 서버 배치
• 사용자와 가까운 서버에서 빠른 응답

1. 탄력적 확장

• 트래픽에 따라 자동으로 서버 추가 및 제거
• 클라우드 환경에서 유용

3. 로드밸런싱의 개념

3.1 로드밸런싱

로드밸런싱(Load Balancing)은 여러 서버에 들어오는 요청을 효율적으로 분산시키는 기술

사용자 요청들 → 로드밸런서 → 서버1, 서버2, 서버3, 서버4

3.2 로드밸런서의역할

1. 트래픽 분산

• 들어오는 요청을 여러 서버에 골고루 분배
• 특정 서버에 과부하가 걸리지 않도록 관리

1. 서버 상태 모니터링

• 각 서버의 응답 시간, CPU 사용률 등을 실시간 체크
• 장애가 발생한 서버를 자동으로 제외

1. 세션 관리

• 사용자의 연결 상태를 추적
• 필요에 따라 같은 사용자를 같은 서버로 연결

1. SSL(Secure Socket Layer) 처리

• HTTPS 암호화/복호화 작업을 대신 수행
• 백엔드 서버의 부담 경

3.3 로드밸런싱의 핵심 원리

1. 분산(Distribution)

요청 100개 → 서버 4대
각 서버당 25개씩 처리

1. 중복성(Redundancy)

서버 1대 장애 → 나머지 3대가 커버
서비스 중단 없음

1. 투명성(Transparency)

클라이언트는 서버가 여러 대인지 모름
단일 서버로 인식

4. 로드밸런싱 분류

4.1 계층별 분류

L4 로드밸런싱 (Transport Layer)

• IP 주소와 포트 번호 기반으로 분산
• TCP/UDP 레벨에서 동작
• 빠른 처리 속도
• 단순한 분산 로직

클라이언트 192.168.1.100:12345 → 서버 10.0.0.1:8080
클라이언트 192.168.1.101:12346 → 서버 10.0.0.2:8080

L7 로드밸런싱 (Appplication Layer)

• HTTP 헤더, URL, 쿠키 등 애플리케이션 정보 기반
• 더 정교한 분산 가능
• 상대적으로 느린 처리 속도
• 복잡한 라우팅 로직

/api/users → 서버 그룹 A
/api/orders → 서버 그룹 B
쿠키에 따라 → 특정 서버

4.2 위치별 분류

소프트웨어 로드밸런서

• 서버 애플리케이션으로 구현
• 유연한 설정 가능
• 상대적으로 저렴
• 예시: Nginx, HAProxy, AWS ALB

하드웨어 로드밸런서

• 전용 장비
• 높은 성능
• 비싼 비용
• 예시: F5, Citrix NetScaler

클라우드 로드밸런서

• 클라우드 서비스로 제공
• 관리 부담 최소화
• 자동 확장 가능
• 예시: AWS ELB, Google Cloud Load Balancer

4.3 동작 방식별 분류

정적 로드밸런싱

• 미리 정의된 규칙에 따라 분산
• 서버 상태를 실시간으로 고려하지 않음
• 구현이 간단
• 예시: Round Robin, Weighted Round Robin

동적 로드밸런싱

• 실시간 서버 상태를 고려하여 분산
• 더 정교한 부하 분산 가능
• 구현이 복잡
• 예시: Least Connections, Least Response Time

5. 로드밸런싱의 필요성

5.1 성능 향상

처리량 증가

단일 서버: 1000 RPS
4대 서버: 3500 RPS (3.5배 향상)

응답 시간 단축

단일 서버: 평균 500ms
분산 처리: 평균 200ms

5.2 가용성 보장

장애 복원력

• 한 서버 장애 시 다른 서버가 처리
• 서비스 중단 시간 최소화

무중단 배포

• 서버를 하나씩 업데이트
• 사용자는 서비스 중단을 느끼지 못함

5.3 확장성 제공

수평적 확장

• 트래픽 증가 시 서버 추가만으로 대응
• 비용 효율적인 확장

탄력적 운영

• 피크 시간에 서버 추가
• 한산한 시간에 서버 제거

5.4 보안 강화

DDos 공격 대응

• 트래픽을 여러 서버로 분산

• 공격 영향 최소화

• DDoS 보충

  DDoS(Distributed Denial of Service) 공격이란?

  수많은 좀비 컴퓨터들이 한번에 서버를 공격하는 것

  정상 상황:
  사용자 → 서버 (초당 100개 요청) 
  
  DDoS 공격:
  좀비PC 1000대 → 서버 (초당 100,000개 요청) 

  • 단일 서버일때의 문제
    • 공격 트래픽이 서버에 집중
    • 서버가 과부하로 다운
    • 정상 사용자도 접속 불가
  • 로드밸런싱으로 DDoS 대응

    공격 트래픽 → 로드밸런서 → 4개 서버로 분산
    각 서버가 1/4씩 부담 → 서비스 유지 가능

SSL 오프로딩

• 로드밸런서에서 SSL 처리
• 백엔드 서버 부하 경감
• SSL 오프로딩 보충
  • SSL이란 웹사이트와 브라우저 간의 암호화 통신

    HTTP:  브라우저 ←→ 서버 (평문 통신, 해킹 위험)
    HTTPS: 브라우저 ←🔒→ 서버 (암호화 통신, 안전)

  • 일반적인 HTTPS 처리

    브라우저 → 서버
    1. SSL 핸드셰이크 (암호화 키 교환)
    2. 데이터 암호화/복호화
    3. 응답 암호화/복호화

    → 서버가 암호화 작업까지 다하게 됨(CPU 부담이 증가)
    
  • SSL 오프로딩 로드밸런서가 SSL 암호화작업을 대신 처리

    브라우저 ←🔒→ 로드밸런서 ←→ 서버
             (HTTPS)              (HTTP)

    1. 브라우저 ↔ 로드밸런서: HTTPS 통신
    2. 로드밸런서에서 SSL 복호화
    3. 로드밸런서 ↔ 서버: 일반HTTP 통신 (내부 네트워크라 안전)
    4. 응답 시 로드밸런서에서 다시 SSL 암호화
  • SSL 오프로딩의 장점
    • 백엔드 서버의 CPU 부담 감소로 성능 향상
    • SSL 인증서를 로드밸런서에서만관리하기에 관리의 편의성 증가
    • 백엔드 서버는 더 저렴한 스펙 사용이 가능해지기에 비용 절약 가능

6. 구현 계획

구현 아키텍처

[Spring Boot 로드밸런서:8080] 
           ↓
[Docker Compose로 4개 웹서버]
- 서버1 (포트 5001)
- 서버2 (포트 5002) 
- 서버3 (포트 5003)
- 서버4 (포트 5004)

[Python Flask ML API:9000] ← 7번째 알고리즘용

즉,
사용자 요청들 → [Spring Boot 로드밸런서] → [Docker 4개 서버]

• 각 알고리즘을 정상 상황, 과부하 상황 서버 장애 상황에서 테스트 하여 비교분석 예정

마무리

• 이론을 바탕으로 Docker를 사용해서 4개의 서버 환경을 구축하기
• 6가지 로드밸런싱을 직접 구현 후 성능 테스트하기

Phase 1: 계획 및 이론

• 📋 1편: 목적 및 계획 - 연구 동기와 전체 로드맵
• 🔍 2편: 로드밸런싱 정복 - 개념, 필요성, 종류

Phase 2: 환경 구축 및 설계

• 🐳 3편: Docker 실습 - 4개 서버 환경 구축하기
• ⚙️ 4편: 6가지 알고리즘 탐구 - 각각의 원리와 특징

Phase 3: 구현 및 테스트

• 💻 5편: Spring Boot로 구현하기 - 실제 코딩 과정
• 📊 6편: 성능 테스트 & 결과 분석 - 21회 테스트 데이터

Phase 4: ML 확장 및 마무리

• 🧠 7편: ML로 똑똑하게 만들기 - Flask + 머신러닝
• 🎯 8편: 최종 결과 및 후기 - 성과와 아쉬운 점