핵심 요약
서버 한 대의 한계에 다다르면 같은 앱을 여러 대로 띄우고, 그 앞에 로드 밸런서를 두어 들어오는 요청을 나눠 보낸다. 이것이 수평 확장의 기본이다. 핵심 고민은 세 가지 — 어떻게 나눌지(알고리즘), 세션을 어떻게 유지할지, 죽은 서버를 어떻게 뺄지(헬스체크).
1. 분산 알고리즘
| 방식 | 동작 |
|---|---|
| 라운드로빈 | 순서대로 골고루. 가장 단순·기본 |
| least connections | 연결이 가장 적은 서버로. 요청 처리 시간이 제각각일 때 유리 |
| IP 해시 | 클라이언트 IP로 서버 고정. 세션 유지에 쓰임 |
| weighted | 스펙 좋은 서버에 가중치 더 |
2. 세션 문제 — 스티키 세션 vs 외부 저장
서버마다 로그인 세션을 메모리에 들고 있으면, 다음 요청이 다른 서버로 가서 로그아웃된 것처럼 보인다. 해결책은 둘.
- 스티키 세션 — 같은 사용자를 늘 같은 서버로(IP 해시 등). 간단하지만 그 서버가 죽으면 세션 유실, 분산도 고르지 않음
- 외부 세션 저장(권장) — 세션을 Redis 같은 공유 저장소에 두면 어느 서버로 가도 동일. 서버를 무상태(stateless)로 만드는 정석
3. 헬스체크
로드 밸런서는 각 서버에 주기적으로 /health 같은 경로를 찔러 살아있는 서버에만 트래픽을 보낸다. 배포 시 우아한 종료(graceful shutdown)와 연동하면 무중단 배포가 된다.
4. L4 vs L7
- L4(전송 계층) — IP·포트 기준으로 빠르게 분배. 내용은 안 봄
- L7(응용 계층) — URL·헤더·쿠키를 보고 라우팅(예:
/api는 API 서버로). nginx·HAProxy·ALB가 대표적. 더 똑똑하지만 오버헤드↑
자주 묻는 질문
로드 밸런서 자체가 죽으면요?
단일 장애점이 되지 않도록 로드 밸런서도 이중화합니다. 클라우드의 관리형 LB(ALB/NLB 등)는 내부적으로 다중화돼 있어 이 부담을 덜어줍니다.
스티키 세션과 외부 세션 중 뭐가 낫나요?
확장성·안정성 면에서 외부 세션 저장(Redis 등)이 정석입니다. 서버가 무상태가 되어 자유롭게 늘리고 줄일 수 있습니다. 스티키 세션은 임시방편으로만 쓰세요.
헬스체크는 무엇을 확인해야 하나요?
단순히 프로세스가 떠 있는지(liveness)뿐 아니라, DB 연결 등 실제로 요청을 처리할 수 있는지(readiness)를 확인하는 게 좋습니다. 종료 시작 시 헬스체크를 먼저 실패시키면 무중단 배포가 됩니다.
댓글 0