서비스 성장에 따른 NGINX 스케일링 전략
사용자가 늘어나면 서버를 어떻게 확장해야 할까요? 소규모 서비스부터 대규모 분산 환경까지 단계별 아키텍처 진화 과정과 비용 효율적인 스케일업 방법을 알아봅니다.
아키텍처 구조도
현재 구조로 어디까지 버틸 수 있나?
가장 흔한 오해는 "접속자가 조금만 늘어도 NGINX가 터질 것"이라는 걱정입니다. 하지만 NGINX는 태생적으로 가벼운 웹 서버(Event-driven 구조)로 설계되어 매우 적은 메모리로도 엄청난 동시접속을 처리합니다.
핵심
트래픽이 늘어나 서비스가 느려졌다면 십중팔구 NGINX가 아니라 백엔드 애플리케이션(FastAPI, Node.js)이나 DB(PostgreSQL)에서 병목이 생긴 것입니다.
1단계: 백엔드 수평 확장 (가장 먼저 할 일)
VPS 한 대 안에서 CPU와 메모리 여유가 있다면, 가장 먼저 할 일은 서버를 늘리는 게 아니라 백엔드 컨테이너의 갯수(replicas)를 늘리는 것입니다.
services:
server-blue:
image: my-backend
deploy:
replicas: 3 # FastAPI 인스턴스를 3개로 복제별도의 로드밸런서 설정이 없어도 Docker 내부 DNS가 자동으로 라운드로빈(Round-Robin) 방식으로 3개의 컨테이너에 요청을 골고루 분산해 줍니다.
2단계: NGINX 최적화 옵션 켜기
사용자가 늘어나면 NGINX와 백엔드 사이의 통신 비용도 부담이 됩니다. 이때 켜주면 좋은 NGINX 설정들입니다.
# 1. 백엔드 연결 재사용 (연결 맺고 끊는 비용 감소)
upstream quizzer_api {
server server-blue:8000;
keepalive 32;
}
# 2. 정적 파일 브라우저 캐싱 (서버 부하 감소)
location /_next/static/ {
proxy_cache_valid 200 365d;
add_header Cache-Control "public, immutable";
}
# 3. 악성 트래픽 방지 (Rate Limiting)
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
location /api/ {
limit_req zone=api burst=50 nodelay;
}3단계: 서버 분리 (스케일 아웃)
VPS 한 대의 리소스(CPU/RAM)가 꽉 찼다면, 이제 물리적인 서버를 여러 대 두어야 합니다.
단일 서버 구조
- •NGINX, 프론트, 백엔드, DB가 한 서버에 동거
- •하나가 CPU를 독점하면 전체가 다운됨
- •소규모 서비스에 적합 (현재 구조)
분리형 서버 구조
추천- ✓서버 A: L7 로드밸런서 전용 (NGINX-proxy)
- ✓서버 B/C: 애플리케이션 (Next.js, FastAPI)
- ✓서버 D: 데이터베이스 (PostgreSQL)
# 이제 Docker 내부 주소가 아니라 실제 다른 서버 IP를 바라봄
upstream backend_cluster {
server 10.0.1.2:80; # 서버 B
server 10.0.1.3:80; # 서버 C
}4단계: 쿠버네티스(K8s) 도입은 언제?
처음부터 AWS EKS나 쿠버네티스를 쓰면 안 되나요?
오버엔지니어링입니다. 월 수천 명 접속하는 서비스에 K8s를 도입하면 트래픽 처리 비용보다 쿠버네티스 인프라 기본 유지비(Master 노드 등)와 관리자 인건비가 훨씬 더 큽니다.
서버 3~5대를 넘어가서 수동 관리가 도저히 안 될 때 도입을 검토하세요. 이 단계가 되면 NGINX 대신 Ingress Controller를 사용하고, 트래픽에 따라 Pod가 자동으로 늘어나는 오토스케일링을 구축하게 됩니다.
지금 당장 할 수 있는 가장 효과적인 3가지
Cloudflare 연동
무료 CDN을 앞단에 두어 정적 파일 트래픽과 DDoS 방어까지 해결하세요.
DB 인덱스 최적화
Slow 쿼리를 찾아 인덱스만 걸어줘도 서버 응답속도가 10배 이상 빨라집니다.
Redis 활용 극대화
변경이 적고 조회가 많은 데이터는 무조건 Redis에 태우세요.