평소에는 문제없던 사이트가 광고 캠페인 하루 만에 다운되는 경우가 있습니다. 원인은 서버 한 대의 성능이 아니라, 트래픽이 몰릴 때 이를 여러 서버로 “나눠줄 방법”이 없었기 때문입니다. 로드밸런싱과 클라우드 아키텍처는 서버를 늘리는 기술이 아니라, 늘어난 서버가 하나처럼 동작하도록 트래픽을 분배하는 설계입니다.
서버 한 대의 한계는 어디서 드러나는가
단일 서버 구조는 평시 트래픽에서는 문제가 없지만, 아래 상황에서 한계가 명확히 드러납니다.
| 상황 | 단일 서버에서의 결과 |
|---|---|
| 이벤트·광고로 순간 접속 급증 | CPU·메모리 포화로 응답 지연 또는 다운 |
| 서버 점검·배포 | 점검 시간 동안 전체 서비스 중단 |
| 특정 지역에서 접속 지연 | 물리적으로 먼 지역 사용자의 응답 속도 저하 |
서버를 더 좋은 사양으로 바꾸는 것(수직 확장)은 한계가 명확합니다. 결국 여러 대를 두고 나눠 처리하는 수평 확장 구조가 필요해지는 시점이 옵니다.
로드밸런서가 실제로 하는 일
로드밸런서는 단순히 트래픽을 “반씩 나누는” 장치가 아닙니다. 실무에서는 아래 역할을 함께 수행합니다.
- 서버 상태를 주기적으로 확인(헬스체크)해 응답 없는 서버는 트래픽 배분에서 자동 제외
- 서버별 현재 부하를 고려해 가장 여유 있는 서버로 요청을 배분
- SSL 처리를 로드밸런서 단에서 집중 처리해 뒷단 서버의 부담을 줄임
- 특정 사용자의 요청을 항상 같은 서버로 보내야 하는 경우(세션 유지)를 위한 고정 라우팅 지원
이 중 헬스체크 기능이 특히 중요합니다. 서버 한 대에 장애가 생겨도 로드밸런서가 즉시 감지해 트래픽을 나머지 서버로만 보내면, 사용자는 장애를 전혀 체감하지 못합니다.
세션 관리: 서버가 여러 대일 때 로그인이 풀리는 이유
서버를 여러 대로 늘렸을 때 가장 흔하게 겪는 버그가 “로그인이 자꾸 풀린다”입니다. 원인은 세션 정보가 서버 한 대의 메모리에만 저장되어 있어, 다음 요청이 다른 서버로 가면 로그인 정보를 찾지 못하기 때문입니다.
- 세션 정보를 모든 서버가 공유하는 별도 저장소(중앙 캐시)로 분리
- 또는 로드밸런서가 같은 사용자를 항상 같은 서버로 보내도록 고정 라우팅 설정
- 장기적으로는 인증 정보를 서버 상태에 의존하지 않는 토큰 방식으로 전환
이 문제를 해결하지 않고 서버만 늘리면, 오히려 확장 이전보다 사용자 경험이 나빠지는 역효과가 발생합니다.
오토스케일: 트래픽에 따라 서버 수를 자동으로 조절
항상 최대 트래픽에 맞춰 서버를 유지하면 평시에는 비용이 낭비됩니다. 오토스케일은 트래픽에 따라 서버 수를 자동으로 늘리고 줄이는 구조입니다.
- CPU·메모리 사용률이 일정 기준을 넘으면 서버를 자동으로 추가
- 트래픽이 줄어들면 일정 시간 후 서버를 자동으로 축소해 비용 절감
- 예상되는 대형 이벤트(할인전) 전에는 최소 서버 수를 미리 늘려두는 사전 스케일링 병행
오토스케일만 믿고 사전 대응 없이 대형 이벤트를 진행하면, 스케일이 실제로 늘어나는 몇 분 사이에 이미 장애가 발생할 수 있어 사전 스케일링과 함께 설계해야 합니다.
DB는 왜 웹서버처럼 쉽게 늘릴 수 없는가
웹서버는 상태를 갖지 않도록 설계하면 여러 대로 쉽게 늘릴 수 있지만, 데이터베이스는 데이터 정합성 때문에 단순히 여러 대로 늘리기 어렵습니다.
읽기 복제본 — 조회 위주의 트래픽을 복제 서버로 분산해 원본 서버의 부담을 줄이는 방식이 일반적입니다.
쓰기 분산 — 데이터를 여러 서버로 나누는 것(샤딩)은 설계가 복잡해 트래픽이 매우 큰 경우에만 고려합니다.
대부분의 서비스는 읽기 복제본 도입만으로도 상당한 확장 여력을 얻을 수 있습니다. DB 자체의 쿼리 효율화도 병행해야 하며, 이 부분은 DB 튜닝 가이드에서 다룹니다.
지역 분산: CDN과 로드밸런싱의 역할 차이
CDN과 로드밸런서는 비슷해 보이지만 역할이 다릅니다. CDN은 이미지·CSS 같은 정적 파일을 사용자와 가까운 위치에서 전달하는 데 특화되어 있고, 로드밸런서는 동적 요청(로그인, 주문 등)을 여러 서버로 분배하는 역할을 합니다.
- 정적 자원은 CDN으로 분산해 원본 서버 부담을 줄임
- 동적 요청은 로드밸런서를 거쳐 가장 여유 있는 서버로 전달
- 두 계층을 함께 쓰면 정적·동적 트래픽 각각에 맞는 최적화가 가능
둘 중 하나만 적용하면 나머지 영역에서 병목이 그대로 남습니다.
아키텍처 도입 전 던져야 할 질문
모든 사이트가 처음부터 복잡한 분산 구조를 가질 필요는 없습니다. 아래 질문에 답해보면 필요한 시점을 가늠할 수 있습니다.
- 특정 이벤트나 시즌에 트래픽이 평시 대비 몇 배로 뛰는가
- 장애·점검 중 서비스가 완전히 멈춰도 되는가, 아니면 무중단이 필수인가
- 해외 사용자 비중이 늘고 있어 지역별 응답 속도가 중요해지고 있는가
이 중 하나라도 “예”라면 로드밸런싱·클라우드 아키텍처 도입을 검토할 시점입니다. 현재 트래픽 패턴을 알려주시면 맞는 구조를 제안해 드립니다.
자주 묻는 질문 (FAQ)
서버를 몇 대부터 로드밸런서가 필요한가요? +
대수보다 트래픽 안정성이 기준입니다. 서버 한 대로도 평시에 문제없다면 당장은 필요하지 않지만, 장애 시 무중단이 필요하다면 두 대부터도 의미가 있습니다.
오토스케일만 있으면 트래픽 급증에 완전히 대응되나요? +
오토스케일은 몇 분 정도의 반응 시간이 필요하기 때문에, 예상되는 대형 이벤트에는 사전 스케일링을 함께 적용해야 안전합니다.
DB도 서버처럼 여러 대로 늘리면 되나요? +
단순 복제로 늘리는 것은 읽기 트래픽 분산에는 효과적이지만, 쓰기 트래픽 분산(샤딩)은 설계가 복잡해 신중한 검토가 필요합니다.
CDN만 있으면 로드밸런서는 필요 없나요? +
CDN은 정적 파일 전달에 특화되어 있고, 로그인·주문 같은 동적 처리는 로드밸런서와 여러 서버가 함께 필요합니다.
이런 구조로 전환하는 데 비용이 많이 드나요? +
트래픽 규모에 맞춰 단계적으로 확장하면 초기 비용을 최소화할 수 있습니다. 처음부터 과도한 규모로 설계하기보다 현재 트래픽에 맞는 구조로 시작하는 것을 권장합니다.