로드밸런싱과 고가용성 아키텍처: 99.99% 가용성 달성 전략
목차
로드밸런싱이란?
로드밸런싱의 정의와 목적
💡 로드밸런싱(Load Balancing): 여러 서버에 네트워크 트래픽을 분산하여 처리함으로써 서비스 가용성과 성능을 향상시키는 기술입니다.
왜 로드밸런싱이 필요한가?
📊 로드밸런싱 도입 전후 비교
[도입 전] [도입 후]
┌─────────┐ ┌─────────┐
│ 사용자 │───────────│ 사용자 │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌─────────┐ ┌─────────────┐
│ Server │ │ Load │
│ (과부하)│ │ Balancer │
│ 🔴 CPU │ │ │ │
│ 95% │ ├────┼────┐ │
└─────────┘ │ ▼ ▼ │
│ ┌────┐┌────┐│
│ │ S1 ││ S2 ││
│ │ 50%││ 50%││
│ └────┘└────┘│
└─────────────┘
단일 장애점 분산 처리 및 장애 격리
L4 vs L7 로드밸런싱
계층별 로드밸런싱 비교
| 구분 | L4 (Transport Layer) | L7 (Application Layer) |
|---|---|---|
| OSI 계층 | 4계층 (TCP/UDP) | 7계층 (HTTP/HTTPS) |
| 기준 정보 | IP, Port | URL, Header, Cookie |
| 속도 | 빠름 (패킷 레벨) | 느림 (프록시) |
| 기능 | 단순 분산 | SSL 종료, 캐싱, 라우팅 |
선택 가이드
| 상황 | 추천 | 이유 |
|---|---|---|
| TCP 기반 게임 서버 | L4 | 낮은 지연 시간 중요 |
| 웹 애플리케이션 | L7 | HTTP 기반 라우팅 필요 |
| 데이터베이스 | L4 | 연결 지속성 필요 |
| API 게이트웨이 | L7 | URL 기반 라우팅, 인증 |
로드밸런싱 알고리즘
주요 알고리즘 비교
| 알고리즘 | 작동 방식 | 장점 | 적합한 경우 |
|---|---|---|---|
| 라운드로빈 | 순서대로 분배 | 단순, 공정 | 동등한 서버 스펙 |
| 가중치 라운드로빈 | 가중치 비율로 분배 | 서버 성능 차이 반영 | 이기종 서버 환경 |
| 최소 연결 | 현재 연결 수가 적은 서버 | 불균등한 처리 시간 대응 | 세션 유지 시간이 다른 경우 |
| IP 해시 | 클라이언트 IP 기반 | 세션 어피니티 보장 | 세션 스티키니스 필요 |
| 최소 응답 시간 | 응답 시간 측정 기반 | 동적 부하 반영 | 성능 변동이 큰 경우 |
고가용성 개념과 SLA
가용성 등급
⏱️ 9의 갯수로 표현하는 가용성
| 가용성 | 연간 다운타임 | 사용 사례 |
|---|---|---|
| 99% (2 nines) | 3.65일 | 내부 개발 시스템 |
| 99.9% (3 nines) | 8.76시간 | 일반 웹 서비스 |
| 99.99% (4 nines) | 52.6분 | 전자상거래, SaaS |
| 99.999% (5 nines) | 5.26분 | 금융, 의료 핵심 시스템 |
고가용성 아키텍처 패턴
다중화 패턴
📊 HA 아키텍처 레벨
레벨 1: 단일 LB
[사용자] ──▶ [LB] ──▶ [Server1]
[Server2]
[Server3]
레벨 2: LB 다중화
[사용자] ──┬──▶ [LB1] ──┬──▶ [Server1]
│ (Active) ├──▶ [Server2]
│ └──▶ [Server3]
│
└──▶ [LB2] ──(Standby - VRRP/Keepalived)
(Passive)
레벨 3: 다중 AZ/DC
[사용자] ──┬──▶ [LB] ──┬──▶ [DC1 서버군]
│ │
│ └──▶ [DC2 서버군] (Geo DNS)
│ (다른 데이터센터)
└──▶ [CDN Edge]
헬스 체크 메커니즘
| 체크 유형 | 간격 | 타임아웃 | 실패 임계값 | 설명 |
|---|---|---|---|---|
| Ping/ICMP | 5초 | 2초 | 3회 | 네트워크 레벨 연결성 |
| HTTP GET | 10초 | 5초 | 2회 | 애플리케이션 상태 확인 |
| TCP Connect | 5초 | 3초 | 3회 | 포트 레벨 확인 |
| 커스텀 스크립트 | 30초 | 10초 | 2회 | 비즈니스 로직 확인 |
데이터센터 로드밸런싱 전략
데이터센터 내/외부 로드밸런싱
🏢 데이터센터 HA 구성
[인터넷] ──▶ [Edge LB] ──┬──▶ [DMZ Web Tier LB] ──▶ [Web Servers]
(Global) │
├──▶ [DR 사이트] (Geo LB)
│
[내부망] ────┬───────────┴──▶ [Internal LB] ──▶ [App Servers]
│ │
│ └──▶ [DB LB] ──▶ [DB Primary]
│ │
│ [DB Standby]
│
└────────────────▶ [Bastion/Jump Host]
하드웨어 vs 소프트웨어 LB
| 구분 | 하드웨어 LB | 소프트웨어 LB |
|---|---|---|
| 예시 | F5, A10, Citrix ADC | Nginx, HAProxy, Envoy |
| 처리량 | 초당 백만 연결+ | 초당 수십만 연결 |
| 비용 | 고가 (10만$+) | 무료 ~ 저가 |
| 유연성 | 제한적 | 매우 높음 |
| 클라우드 | 부적합 | 최적 |
구현 및 설정 가이드
Nginx 로드밸런싱 설정
upstream backend {
least_conn; # 최소 연결 알고리즘
server 10.0.0.1:8080 weight=3; # 가중치 3
server 10.0.0.2:8080 weight=2; # 가중치 2
server 10.0.0.3:8080 backup; # 백업 서버
keepalive 32; # 지속 연결
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 헬스 체크
health_check interval=5 fails=3 passes=2;
}
}
AWS ALB 설정 체크리스트
✅ ALB 설정 검증 리스트
- 타겟 그룹: 인스턴스/IP/Lambda 선택
- 헬스 체크: 경로, 포트, 임계값 설정
- 스티키 세션: 필요시 쿠키 기반 설정
- SSL/TLS: ACM 인증서 연동
- 로그: S3 또는 CloudWatch 로깅 활성화
- WAF: 보안 규칙 연동
결론
로드밸런싱과 고가용성은 현대 IT 인프라의 기초입니다. 단순히 서버를 나누는 것을 넘어 장애에 대한 회복력을 설계하는 것이 핵심입니다.
핵심 요약
🌟 고가용성 성공 공식
적절한 로드밸런싱 + 다중화 + 자동 장애 조치 = 99.99% 가용성 ⚡
체크리스트
- 로드밸런서 다중화 (Active-Passive 또는 Active-Active)
- 서버 헬스 체크 설정
- 세션 어피니티 정책 결정
- 장애 조치 자동화
- 다중 데이터센터/가용영역 구성
- 정기적인 장애 주입 테스트 (Chaos Engineering)
관련 키워드: 로드밸런서, Load Balancer, 고가용성, High Availability, HA, HAProxy, Nginx, ALB, NLB, AWS ELB, L4, L7, Transport Layer, Application Layer, 세션 어피니티, 세션 스티키니스, 헬스 체크, 장애 조치, 다중화, 이중화, 액티브-스탠바이, 액티브-액티브, 데이터센터, SLA, 9’s, Geo DNS, GSLB
참고 자료:
- Nginx Load Balancing Guide
- AWS Load Balancer Best Practices
- HAProxy Documentation
- Google SRE Book - Load Balancing
📝 본 포스트는 2025년 9월 기준 정보를 바탕으로 작성되었습니다.
토요컨설턴시서비시스코리아(주)의 CTO를 맞고 있는 Ike 입니다.
비용효율을 최우선으로 고려하여 SMB고객에게 엔터프라이즈급 품질의 서비스를 제공하는 방법에 흥미를 가지고 있습니다. 또한, 풍부한 현장경험을 바탕으로 가장 현실적인 대안을 제시하고자 노력하고 있습니다.