7단계 — 단일 서버 철학

분산·MSA·Kubernetes — 이 모든 게 복잡함 을 추가해요. 트래픽이 진짜로 1대로 안 될 때까지는 단일 서버가 답입니다.

단일 서버 = 작지 않다

t3.medium (2vCPU, 4GB) 한 대로:

• Postgres (관리형 DB 비슷한 안정)
• Redis (캐시·세션)
• 백엔드 API 컨테이너
• 프론트 컨테이너
• Caddy (HTTPS·라우팅)

이 모두를 띄우고 수천 RPS 를 처리할 수 있어요. 대부분의 사이드 프로젝트·SaaS MVP 는 1대로 충분.

단일 서버의 장점 5

1. 복잡함 0 — docker compose up 한 줄
2. 비용 5% — Kubernetes 클러스터 대비 1/20
3. 디버깅 쉬움 — 모든 로그가 한 머신에
4. 보안 표면 작음 — 1 IP, 3 포트
5. 백업 단순 — pg_dump + S3 sync

한계가 보일 때

다음 세 가지 신호 가 동시에 보일 때 분산을 고려:

• CPU 80% 이상 이 평일 내내
• DB 풀 고갈 이 정기적
• 재시작 시 다운타임 이 비즈니스에 손해

이 셋이 안 보이면 1대로 충분.

1대로 견디는 패턴 5

1. healthcheck 자동 재시작

restart: unless-stopped
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/api/health"]
  interval: 30s

2. 일일 자동 백업

# /etc/cron.daily/pg-backup
docker exec postgres pg_dump -U user myapp | \
  gzip | \
  aws s3 cp - s3://my-backups/pg/$(date +%Y%m%d).sql.gz

3. 모니터링 — 외부 ping

UptimeRobot 무료. 5분마다 /api/health 호출 → 다운 시 슬랙 알림.

4. 수직 스케일 우선

CPU 가 부족하면 t3.medium → t3.large 인스턴스 변경 (재부팅 필요). 수평 스케일 (여러 대 분산) 보다 훨씬 단순.

5. 지역별 CDN

정적 파일은 S3 + CloudFront 또는 Cloudflare. 서버 부담을 1/10 로.

그래서 언제 분산?

이 셋 모두에 ✅:

• 100k RPS+ 정기적
• 99.99%+ uptime SLA 가 비즈니스 약속
• 팀이 분산 시스템 운영 경험 보유

위 셋이 안 갖춰진 단계에서 분산하면 문제만 늘어요.

직접 해 보기

지금까지 만든 강좌 프로젝트들을 EC2 t3.small 한 대에 모아 띄워 보세요. Caddy + Docker compose + PG + Redis + 앱 — 한 머신으로 다 됩니다.

강좌를 마치며

이 강좌는 끝났어요. 단일 서버 1대로 단단하게 운영하면서 트래픽이 진짜 늘어날 때 그제야 분산을 고민해도 늦지 않습니다.

다음으로 security-foundations (출시 예정) 또는 backend-with-spring 강좌를 만나 보세요.

더 깊이

• 단일 서버 철학 노트