로드 밸런싱과 게이트웨이

핵심 질문

단일 서버가 감당하지 못할 때, 트래픽을 "똑똑하게" 여러 서버 인스턴스에 분배하려면 어떻게 해야 할까? 로드 밸런서는 현대 분산 시스템의 "분배원"입니다. 이 글은 실제 사례(버블티 가게 계산대, 택배 분류, 교통 통제)를 통해 로드 밸런싱의 설계 철학과 엔지니어링 실무를 깊이 있게 이해합니다.

1. 왜 "로드 밸런싱"이 필요한가?

1.1 실제 사례로 시작: 한 웹사이트의 아키텍처 진화

한 스타트업이 사용자 수가 빠르게 증가하면서 심각한 성능 문제에 직면했습니다:

상황 재현:

1단계: 단일 서버
사용자 → 서버(1코어 2GB)
       ↓
  일간 활성 사용자 1000명 → 활성 시간: 1000명이 동시 접속
       ↓
문제: CPU 100%, 응답 느림, 빈번한 다운타임

단일 서버의 치명적 문제

성능 병목: CPU 100%, 응답 시간 > 5초
단일 장애점: 서버가 다운되면 전체 웹사이트 사용 불가
확장 어려움: 수직 업그레이드(CPU, 메모리 추가)만 가능하고, 비용이 많이 들며 한계가 있음

개선된 아키텍처(로드 밸런서 도입):

2단계: 다중 서버 + 로드 밸런서
사용자 → 로드 밸런서(Nginx)
       ↓
     ├→ 서버 1 (1코어 2GB)
     ├→ 서버 2 (1코어 2GB)
     └→ 서버 3 (1코어 2GB)

1.2 로드 밸런싱의 생활 속 비유

버블티 가게 계산대

인기 있는 버블티 가게를 운영한다고 상상해 보세요:

계산대 1개: 손님이 줄을 서고, 뒤에 있는 사람은 기다리지 못해 나쁜 리뷰
계산대 3개: 직원이 손님을 다른 계산대로 분배하고, 효율이 3배 향상

로드 밸런서가 바로 "계산대 분배원"입니다:

사용자(손님) → 서비스 요청
로드 밸런서(분배원) → 요청을 다른 서버에 분배
서버(계산대) → 요청 처리

传统架构单点

🖥️

Web Server

负载: 95% 🔥

→

负载均衡架构分布式

⚖️L4 Load Balancer

🖥️

📦四层负载均衡 (L4)

工作原理

基于传输层信息（IP地址+端口）进行流量分发。不关心应用层内容，只做"快递分拣"，因此性能极高。

典型产品

LVS (Linux Virtual Server)HAProxy (TCP模式)AWS NLBAzure Load Balancer

适用场景

需要极高吞吐量的场景
TCP/UDP流量分发
不需要内容识别的场景
微服务间通信

性能对比一览

类型

处理层

性能

灵活性

成本

硬件负载均衡

L4/L7

$$$$$

四层负载均衡

L4 (传输层)

七层负载均衡

L7 (应用层)

$$$

软件负载均衡

L4/L7

2. 로드 밸런싱이란 무엇인가?

2.1 4계층 로드 밸런싱(L4): 문패만 본다

전송 계층(TCP/UDP)에서 작동하며, 택배 기사가 집의 문패(IP 주소+포트 번호)만 보고, 집에서 무엇을 하는지는 신경 쓰지 않는 것과 같습니다.

특징:

속도 매우 빠름: 단순한 주소 전달만 하고, 데이터 패킷 내용을 분석하지 않음
적용 시나리오: 데이터베이스 연결, Redis 캐시, 장기 연결 게임 서버
대표 제품: LVS(Linux Virtual Server), AWS NLB, Azure Load Balancer

2.2 7계층 로드 밸런싱(L7): 소포 내용물 검사

애플리케이션 계층(HTTP/HTTPS)에서 작동하며, 택배 기사가 문패뿐만 아니라 소포를 열어 내용물을 검사하고 내용에 따라 배달 방법을 결정하는 것과 같습니다.

특징:

스마트 라우팅: URL 경로, HTTP 헤더, 쿠키 등에 따라 세분화된 라우팅 가능
고급 기능: SSL 오프로딩, 콘텐츠 캐싱, 압축, 보안 WAF
적용 시나리오: 웹 애플리케이션, API 게이트웨이, 마이크로서비스 아키텍처
대표 제품: Nginx, HAProxy, AWS ALB, Envoy

2.3 L4 vs L7 비교

차원	4계층 로드 밸런싱(L4)	7계층 로드 밸런싱(L7)
작동 계층	전송 계층(TCP/UDP)	애플리케이션 계층(HTTP/HTTPS)
의사결정 근거	IP 주소 + 포트 번호	URL, Header, Cookie, Body
처리 속도	매우 빠름(커널 모드 처리)	비교적 빠름(사용자 모드 분석)
기능 풍부도	기본 전달	SSL 오프로딩, 캐싱, 압축, WAF
대표적 시나리오	데이터베이스, 게임, 장기 연결	웹 애플리케이션, API 게이트웨이, 마이크로서비스
대표 제품	LVS, AWS NLB	Nginx, HAProxy, AWS ALB

3. 핵심 질문 1: "고장 난" 서버가 계속 접속을 받지 않도록 하려면?

3.1 헬스 체크: "아픈" 서버가 시스템을 끌어내리지 않도록 방지

⚖️

负载均衡器

定期主动探测

✅

❌

🖥️

Server 1

10.0.1.10

健康

响应时间

25ms

失败率

0.1%

连续成功

5/3

🖥️

Server 2

10.0.1.11

健康

响应时间

30ms

失败率

0.2%

连续成功

4/3

🖥️

Server 3

10.0.1.12

故障

响应时间

3500ms

失败率

15%

连续成功

0/3

🔍主动健康检查

负载均衡器主动向后端服务器发送探测请求（如HTTP /health、TCP握手等），根据响应判断服务器健康状态。这是最常用的健康检查方式。

关键配置参数

检查间隔

两次检查之间的时间间隔

超时时间

等待响应的最大时间

健康阈值

判定为健康所需的连续成功次数

不健康阈值

判定为不健康所需的连续失败次数

✅ 优点

检测结果准确可靠，能真实反映服务状态
可以精确配置检查参数和阈值
不依赖实际业务流量，无流量时也能检测

❌ 缺点

产生额外的探测流量和系统开销
检查间隔期间发生的故障不能立即发现
需要后端服务提供健康检查端点

3.2 능동형 헬스 체크 vs 수동형 헬스 체크

능동형 헬스 체크(Active Health Check): 로드 밸런서가 능동적으로 서버에 "아직 살아 있나요?"라고 물어봄

정기적으로 탐지 요청 전송(예: HTTP /health, TCP ping)
응답 타임아웃 또는 에러 코드 반환 시 비정상으로 판단
장점: 감지 결과가 정확하고 신뢰할 수 있음
단점: 추가 탐지 트래픽 발생

수동형 헬스 체크(Passive Health Check): 로드 밸런서가 실제 비즈니스 트래픽의 응답을 "관찰"

실제 요청의 응답 시간, 에러율을 통계
연속 여러 번 실패하면 비정상으로 판단
장점: 추가 트래픽이 발생하지 않음
단점: 충분한 트래픽 샘플이 있어야 판단 가능

4. 핵심 질문 2: "단골 손님"이 항상 같은 "계산원"을 찾도록 보장하려면?

4.1 세션 지속성: "단골 손님"이 항상 같은 "계산원"을 찾도록

应用场景：

👤

用户A

👥

用户B

👨‍💼

用户C

请求

↓

⚖️负载均衡器

🍪

Cookie 插入

通过HTTP Cookie保持会话

会话映射表

sess_abc123→Server 1

sess_def456→Server 2

sess_ghi789→Server 1

↓

🖥️

Server 1

10.0.1.10

✓

选中

🖥️

Server 2

10.0.1.11

✓

🖥️

Server 3

10.0.1.12

✗

↑

三种会话保持机制对比

🍪Cookie 插入

✓不受客户端IP变化影响

✓首次请求即可保持会话

✗客户端需支持Cookie

✗存在Cookie被禁用的风险

#️⃣IP Hash

✓无需客户端支持任何机制

✓无状态，LB重启不影响会话

✗客户端IP变化会丢失会话

✗难以做到真正的负载均衡

📝粘性会话

✓结合Cookie和IP两种方式优势

✓支持会话复制和故障转移

✗实现复杂，需要应用支持

✗会话复制带来性能开销

4.2 세 가지 세션 지속성 메커니즘 비교

메커니즘	구현 원리	장점	단점	적용 시나리오
쿠키 삽입	LB가 응답에 쿠키를 삽입하고, 이후 요청이 이 쿠키를 포함	IP 변경의 영향을 받지 않으며, 첫 요청부터 지속 가능	클라이언트가 쿠키를 지원해야 하며, 비활성화될 수 있음	이커머스 장바구니, 로그인 상태 유지
IP 해시	클라이언트 IP를 해시하여 특정 서버에 매핑	클라이언트 지원 불필요, 상태 비저장	IP 변경 시 세션 상실, 균등 분배 어려움	쿠키 미지원 환경, WebSocket
스티키 세션 테이블	LB가 세션-서버 매핑 테이블을 유지	세션 복제와 장애 조치 지원	LB 메모리 점유, 추가 동기화 필요	고가용성 요구가 엄격한 시나리오

5. 핵심 질문 3: 무중단 배포를 어떻게 구현할 것인가?

5.1 블루-그린 배포: "원클릭 전환" 무중단 배포

🔵

蓝环境

v1.0.0

100% 流量

🟢

绿环境

v1.1.0

0% 流量

用户流量

👤

↓

⚖️

负载均衡器

当前指向: 🔵 蓝环境

↓

🔵蓝环境v1.0.0

🖥️B1●

🖥️B2●

🖥️B3●

🟢绿环境v1.1.0

🖥️G1●

🖥️G2●

🖥️G3●

蓝绿部署流程

绿环境部署

在绿环境部署新版本，进行冒烟测试

→

切换流量

将负载均衡器指向绿环境，流量瞬间切换

→

监控观察

观察绿环境运行状态，确认无异常

→

蓝环境升级

在蓝环境部署新版本，为下次切换做准备

蓝绿部署优缺点

✅优点

零停机时间：流量切换在毫秒级完成，用户无感知
快速回滚：发现问题可立即切回原环境，风险可控
完整的预发布测试：新环境可完整测试后再接管流量
数据一致性：无需处理新旧版本同时运行时的兼容问题

❌缺点

资源成本高：需要同时维护两套完整环境，服务器成本翻倍
数据库兼容性挑战：如果涉及数据库Schema变更，需要特别处理兼容性
预热问题：新环境启动后可能需要时间预热缓存、连接池等
不适合有状态服务：对于长连接、会话保持要求高的场景处理复杂

5.2 카나리아 배포: "작은 걸음으로 빠르게" 그레이들 전략

流量分配比例拖动滑块调整新旧版本流量占比

稳定版 v1.0.090%

金丝雀 v1.1.010%

实时流量模拟总请求: 0 | 稳定版: 0 | 金丝雀: 0

用户请求

→

负载均衡器

⚖️

Canary:10%

→

后端服务

稳定版 v1.0.0

📦S1

📦S2

📦S3

金丝雀 v1.1.0

🧪C1

🧪C2

金丝雀发布最佳实践

📊渐进式放量

1% → 5% → 10% → 25% → 50% → 100%
每个阶段观察至少15-30分钟
关键指标：错误率、延迟、吞吐量

🎯精准用户选择

内部员工/测试用户先行
按地域：选择特定区域用户
按用户属性：VIP用户或普通用户
按设备类型：iOS/Android/Web

🛡️自动回滚机制

错误率超过阈值自动回滚
P99延迟异常触发告警
关键业务指标下降自动回滚
一键回滚：30秒内恢复旧版本

📈监控与指标

基础设施：CPU、内存、磁盘、网络
应用指标：QPS、错误率、延迟分布
业务指标：转化率、订单量、收入
用户体验：页面加载时间、交互延迟

6. 핵심 질문 4: 시스템이 스스로 "숨을 쉬게" 하려면?

6.1 자동 스케일링: 시스템이 레스토랑처럼 "유연하게 인력 배치"

扩容指标：

实时监控实时

💻CPU使用率

45%

扩容阈值: 70%缩容阈值: 30%

🧠内存使用率

60%

扩容阈值: 75%缩容阈值: 40%

⚡QPS

650req/s

扩容阈值: 1000/s目标: 800/s

🖥️运行实例

3个实例

最小: 2最大: 10

扩缩容历史最近 5 次操作

📈

扩容: 2 → 3 实例

CPU使用率超过70%