서버 과부하와 로드 밸런싱
서버 1개일 때 문제점 (편의점 비유)
상황:
- 손님 A: "담배 주세요" (3초)
- 손님 B: "도시락 데워주세요" (30초) ← 전자레인지 대기
- 손님 C: "택배 보내려고요" (60초) ← 포장 작업
- 손님 D: "담배 주세요" (3초)
처리 순서:
A → B (30초 대기) → C (60초 대기) → D
손님 D 입장:
- 앞에 3명 기다림
- 담배 사는데 3초면 되는데 93초 기다림
- 화남 → 다른 편의점 감
→ 이게 "서버 과부하"
웹 서버 3개 (편의점 직원 3명) = 로드 밸런싱
상황:
- 직원 1: 손님 A (담배)
- 직원 2: 손님 B (도시락)
- 직원 3: 손님 C (택배)
- 손님 D 들어옴
처리:
- 직원 1이 손님 A 끝냄 (3초)
- 손님 D를 바로 처리 (3초)
손님 D 입장:
- 3초만에 끝남
- 만족
→ 이게 "로드 밸런싱"
실제 웹 서비스로 설명
네이버 접속 과정
1. 브라우저에 naver.com 입력
2. 웹 서버에 요청 도착
3. 웹 서버가 HTML/CSS/JS 전달 (빠름 - 3초)
4. 로그인 버튼 클릭
5. 애플리케이션 서버에서 DB 확인 (느림 - 30초)
서버 1개일 때 문제
시나리오: 동시 접속자 1000명
[웹 서버 1개]
요청 1: 네이버 메인 페이지 (HTML) - 0.1초
요청 2: 로그인 처리 (DB 조회) - 2초 ← 느림
요청 3: 검색 (DB 조회) - 3초 ← 느림
요청 4: 메인 페이지 (HTML) - 0.1초 ← 하지만 앞에 3명 대기
...
1000번째 요청:
- 앞에 999명 기다려야 함
- 평균 1초씩 걸린다면 999초 대기
- 16분 기다림
- 사용자: "이 사이트 왜 이렇게 느려?" → 이탈
→ 매출 손실
서버 여러 개일 때
[웹 서버 10개 + 로드 밸런서]
사용자 1000명
↓
[로드 밸런서] ← "교통 정리하는 경찰"
/ | | \
서버1 서버2 ... 서버10
(100명)(100명) (100명)
각 서버가 100명씩만 처리
→ 대기 시간 10배 감소
→ 사용자 만족
금융 거래 예시
은행 앱 시나리오
평소 (낮 시간):
- 동시 접속: 1만 명
- 웹 서버 10개로 충분
월말 (급여일):
- 동시 접속: 50만 명 ← 50배 증가!
- 웹 서버 10개로는 부족
- 대기 시간 50배 증가
- 사용자: "앱이 먹통이네"
해결책: 서버 자동 확장
평소:
[웹 서버 10개]
→ 비용 절약
급여일:
[웹 서버 500개] ← 자동 증설 (Auto Scaling)
→ 원활한 서비스
→ 다음 날 다시 10개로 축소
→ 이게 "클라우드의 힘"
웹 서버 vs 애플리케이션 서버
웹 서버 (빠른 일 담당)
역할:
- HTML, CSS, JS 파일 전달
- 이미지, 동영상 전달
- 정적 파일 서빙
특징:
✅ 매우 빠름 (0.01초)
✅ 복잡한 연산 없음
✅ 많이 늘려도 비용 저렴
예시:
- Nginx
- Apache
- CloudFront (CDN)
애플리케이션 서버 (복잡한 일 담당)
역할:
- 로그인 처리 (DB 조회)
- 결제 처리 (외부 API 호출)
- 데이터 계산 (복잡한 로직)
특징:
⏰ 느림 (1-5초)
CPU/메모리 많이 씀
비용 비쌈
예시:
- Node.js
- Django
- Spring Boot
왜 분리하나?
분리 안 하면
[서버 1개가 모든 일 처리]
요청 1: 이미지 달라 (0.01초)
요청 2: 로그인 해줘 (2초) ← DB 조회 중
요청 3: 이미지 달라 (0.01초) ← 하지만 요청2 끝날 때까지 대기
→ 간단한 요청도 느려짐
→ 비효율
분리하면
[웹 서버] - 빠른 일
요청 1: 이미지 달라 (0.01초) ✅ 즉시 처리
요청 3: 이미지 달라 (0.01초) ✅ 즉시 처리
[앱 서버] - 느린 일
요청 2: 로그인 해줘 (2초) ← 여기서만 느림
→ 빠른 건 빠르게, 느린 건 따로
→ 효율적
실제 구조 (금융 서비스)
[사용자]
↓
[CDN - 이미지/CSS]
↓
[로드 밸런서] ← 교통 정리
/ | \
[웹서버1][웹서버2][웹서버3] ← HTML 전달
\ | /
[로드 밸런서] ← 또 교통 정리
/ | \
[앱서버1][앱서버2][앱서버3] ← 로그인/결제
\ | /
[데이터베이스]
평소: 웹서버 10개 + 앱서버 5개
급여일: 웹서버 100개 + 앱서버 50개 (자동 증설)
핵심 정리
서버 여러 개 = 효율적인 이유
1. 병렬 처리
- 1명이 100개 vs 10명이 10개씩
- 10배 빠름
2. 장애 대응
- 서버 1개 고장나도 나머지 9개 작동
- 서비스 중단 없음
3. 비용 효율
- 필요할 때만 늘림
- 평소엔 최소한만 운영
4. 역할 분담
- 웹서버: 빠른 일
- 앱서버: 복잡한 일
- 각자 전문 분야에 집중
당신이 만든 것으로 비유
마케팅 데이터 자동화
[현재 구조 - 서버 1개]
- BigQuery 쿼리 (30초)
- Looker Studio 업데이트 (10초)
- Slack 알림 (1초)
→ 순차 처리: 총 41초
[개선 구조 - 서버 3개]
- 서버 1: BigQuery 쿼리 (30초)
- 서버 2: Looker Studio (10초) ← 동시 진행
- 서버 3: Slack 알림 (1초) ← 동시 진행
→ 병렬 처리: 총 30초 (가장 오래 걸리는 것 기준)
다음에 배울 것들
오늘: 웹서버 vs 앱서버
다음: 로드 밸런서 (어떻게 분산시킬까?)
그다음: Docker (서버 쉽게 늘리기)
나중: Kubernetes (자동으로 늘렸다 줄였다)
→ 다 연결되어 있음!
작성일: 2025-10-29