IT Knowledge/Network/images/06-로드-밸런싱과-리버스-프록시-diagram.svg

로드 밸런싱과 리버스 프록시

로드 밸런서는 요청을 여러 서버에 분산시키고, 리버스 프록시는 서버 앞에서 요청을 대신 처리합니다.

🎯 이 파일을 학습하면 무엇을 알게 될까요?

이 파일을 학습하면 다음을 할 수 있게 됩니다:

로드 밸런싱의 필요성과 원리 이해
다양한 로드 밸런싱 알고리즘 파악
리버스 프록시의 역할과 장점 이해
실제로 로드 밸런서와 리버스 프록시 구성 가능

🧠 학습 전 생각해볼 질문

왜 로드 밸런싱이 필요할까요?
- 하나의 서버로 모든 요청을 처리하면 어떤 문제가 발생할까요?
- 서버가 다운되면 어떻게 될까요?
로드 밸런서는 어떻게 작동할까요?
- 요청을 어떤 서버로 보낼지 결정할까요?
- 서버 상태를 어떻게 감시할까요?
리버스 프록시는 포워드 프록시와 어떻게 다를까요?
- 왜 “리버스(Reverse)“라고 부를까요?

📖 1. 로드 밸런싱이란?

1.1 로드 밸런싱의 정의

**로드 밸런싱(Load Balancing)**는 여러 서버에 요청을 분산시켜 부하를 최적화하는 기술입니다.

비유: 쇼핑몰 카운터

하나의 카운터: 대기줄이 길어짐

여러 카운터: 대기줄이 짧아짐

1.2 왜 로드 밸런싱이 필요한가?

문제 상황: 단일 서버

사용자 1000명 → 서버 1대 (과부하)

문제:
1. 응답 속도 느림
2. 서버 다운 가능성 높음
3. 확장성 제한

해결: 로드 밸런싱

사용자 1000명 → 로드 밸런서 → 서버 4대 (각 250명 처리)

장점:
1. 응답 속도 빠름
2. 서버 다운에도 서비스 유지
3. 확장성 좋음

1.3 로드 밸런싱의 이점

이점	설명
고가용성	서버 다운에도 서비스 유지
확장성	쉽게 서버 추가 가능
성능 최적화	각 서버에 적절한 부하 분배
보안 강화	DDoS 공격 분산
유지보수 용이	서버 교체 중에도 서비스 유지

🔍 2. 로드 밸런싱 알고리즘

2.1 기본 알고리즘

1. 라운드 로빈 (Round Robin)

요청 1 → 서버 A
요청 2 → 서버 B
요청 3 → 서버 C
요청 4 → 서버 A
...

특징: 서버에 순차적으로 요청 전송

장점:

구현이 간단함
서버 성능이 비슷할 때 효율적

단점:

서버 성능이 다르면 비효율적
서버 상태를 고려하지 않음

2. 최소 연결 (Least Connections)

서버 A: 5개 연결
서버 B: 3개 연결
서버 C: 2개 연결

요청 → 서버 C (연결이 가장 적음)

장점:

서버 부하를 고려
응답 시간이 다를 때 효율적

단점:

연결 수만 고려 (실제 부하는 고려 안 함)

3. 소스 IP 해시 (Source IP Hash)

클라이언트 IP: 192.168.1.1
해시(192.168.1.1) % 3 = 서버 B

특징: 같은 클라이언트는 항상 같은 서버로

장점:

세션 유지에 좋음
캐시 효율적

단점:

부하 분산이 불균형할 수 있음

4. 최소 응답 시간 (Least Response Time)

서버 A: 응답 50ms
서버 B: 응답 20ms
서버 C: 응답 30ms

요청 → 서버 B (응답이 가장 빠름)

장점:

응답 속도 최적화
서버 성능 고려

단점:

복잡한 계산 필요
실시간 모니터링 필요

2.2 알고리즘 비교

알고리즘	복잡도	세션 유지	성능 고려	사용 사례
라운드 로빈	낮음	❌	❌	동일한 서버
최소 연결	중간	❌	부분적	다양한 요청
소스 IP 해시	중간	✅	❌	세션 유지 필요
최소 응답 시간	높음	❌	✅	성능 최적화

🏗️ 3. 로드 밸런서 유형

3.1 L4 로드 밸런서

L4 (Transport Layer) 로드 밸런서는 IP 주소와 포트를 기반으로 요청을 분산합니다.

IP: 192.168.1.1, Port: 80 → 서버 A
IP: 192.168.1.2, Port: 80 → 서버 B

특징:

속도가 빠름
간단한 구현
콘텐츠 확인 불가

도구: HAProxy, LVS

3.2 L7 로드 밸런서

L7 (Application Layer) 로드 밸런서는 HTTP 헤더, URL, 쿠키 등을 기반으로 요청을 분산합니다.

URL: /api/v1 → 서버 A
URL: /api/v2 → 서버 B
URL: /static → 서버 C

특징:

콘텐츠 기반 라우팅
더 정교한 제어
속도 느림

도구: Nginx, AWS ALB

3.3 비교

항목	L4	L7
계층	전송 계층 (TCP/UDP)	응용 계층 (HTTP)
기준	IP, 포트	URL, 헤더, 쿠키
속도	빠름	느림
기능	기본적	고급
도구	HAProxy, LVS	Nginx, AWS ALB

🔀 4. 리버스 프록시란?

4.1 리버스 프록시의 정의

**리버스 프록시(Reverse Proxy)**는 서버 앞에서 클라이언트 요청을 대신 받아 처리하는 서버입니다.

비유: 식당 접수 담당

손님은 접수 담당에게 주문

접수 담당은 주방에 주문 전달

손님은 주방 위치를 모름

4.2 포워드 프록시 vs 리버스 프록시

포워드 프록시

클라이언트 → 포워드 프록시 → 인터넷

용도:
- 익명성 유지
- 콘텐츠 필터링
- 캐싱

리버스 프록시

인터넷 → 리버스 프록시 → 서버

용도:
- 로드 밸런싱
- 보안 강화
- 캐싱
- SSL 종료

특징	포워드 프록시	리버스 프록시
위치	클라이언트 앞	서버 앞
목적	클라이언트 보호	서버 보호
보여짐	클라이언트 IP 숨김	서버 IP 숨김
주요 기능	익명성, 필터링	로드 밸런싱, 보안

🛡️ 5. 리버스 프록시의 역할

5.1 주요 기능

1. 로드 밸런싱

요청 → 리버스 프록시 → 서버 A
요청 → 리버스 프록시 → 서버 B
요청 → 리버스 프록시 → 서버 C

2. 캐싱

정적 파일: 이미지, CSS, JS
캐시: 첫 요청 후 저장

장점: 빠른 응답, 서버 부하 감소

3. SSL 종료 (SSL Termination)

HTTPS 요청 → 리버스 프록시 (암호화 해제)
              ↓
         HTTP 요청 → 서버

장점: 서버 부하 감소, 인증서 관리 용이

4. 보안 강화

- DDoS 공격 방어
- 악성 요청 차단
- IP 차단
- WAF(Web Application Firewall)

5. 컨텐츠 기반 라우팅

URL: /api/v1 → 서버 A
URL: /api/v2 → 서버 B
URL: /static → 서버 C

🛠️ 6. 실무에서의 구성

6.1 Nginx 로드 밸런서 설정

upstream backend {
    # 라운드 로빈 (기본)
    server 192.168.1.10:80;
    server 192.168.1.11:80;
    server 192.168.1.12:80;
 
    # 최소 연결
    # least_conn;
 
    # IP 해시
    # ip_hash;
}
 
server {
    listen 80;
    server_name example.com;
 
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

6.2 Nginx 리버스 프록시 설정

server {
    listen 80;
    server_name example.com;
 
    location / {
        proxy_pass http://192.168.1.10:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
 
    # 캐싱 설정
    location /static/ {
        proxy_pass http://192.168.1.10:8080;
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
    }
}
 
# SSL 종료
server {
    listen 443 ssl;
    server_name example.com;
 
    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;
 
    location / {
        proxy_pass http://backend;
    }
}

6.3 HAProxy 로드 밸런서 설정

frontend http-in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    server s1 192.168.1.10:80 check
    server s2 192.168.1.11:80 check
    server s3 192.168.1.12:80 check

6.4 AWS ALB (Application Load Balancer)

# ALB 생성
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-123 subnet-456 \
  --security-groups sg-789
 
# 타겟 그룹 생성
aws elbv2 create-target-group \
  --name my-targets \
  --protocol HTTP \
  --port 80 \
  --vpc-id vpc-abc123
 
# 리스너 생성
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:... \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:...

🎓 7. 고급 주제

7.1 헬스 체크 (Health Check)

헬스 체크는 서버의 상태를 주기적으로 확인합니다.

헬스 체크 → GET /health
           ↓
      200 OK → 정상
      503 Service Unavailable → 비정상

Nginx 헬스 체크

upstream backend {
    server 192.168.1.10:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:80 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:80 max_fails=3 fail_timeout=30s;
}

7.2 세션 유지 (Session Persistence)

세션 유지는 같은 클라이언트가 항상 같은 서버로 요청하도록 합니다.

방법 1: IP 해시

upstream backend {
    ip_hash;
    server 192.168.1.10:80;
    server 192.168.1.11:80;
}

방법 2: 쿠키

upstream backend {
    server 192.168.1.10:80 cookie server1;
    server 192.168.1.11:80 cookie server2;
}

7.3 글로벌 로드 밸런싱 (GSLB)

글로벌 로드 밸런싱은 전 세계 지역에 요청을 분산합니다.

사용자 (한국) → GSLB → 한국 서버
사용자 (미국) → GSLB → 미국 서버
사용자 (유럽) → GSLB → 유럽 서버

도구: AWS Route 53, Cloudflare, Akamai

✅ 8. 학습 체크리스트

기초 개념

로드 밸런싱의 정의와 필요성 이해
리버스 프록시의 정의 이해
포워드 프록시와 리버스 프록시 차이 이해