주문 API 서버 한 대(8코어)로 운영 중인데, 프로모션 때마다 CPU가 90%를 치고 응답이 늘어진다. 회의에서 "인스턴스 사양을 올리자"는 쪽과 "서버를 여러 대로 늘리자"는 쪽이 맞붙었다. 어느 쪽부터 갈지 정해야 한다.
언제: 거의 항상 이게 먼저다. 코드 변경 없이 인스턴스 타입 한 단계 올리면 끝이라 오늘 당장 적용할 수 있다. 트래픽 성장이 사양 몇 단계 안에서 감당되는 동안, 그리고 세션이나 로컬 캐시 같은 상태가 서버 안에 박혀 있어도 그대로 동작한다.
비용: 천장이 있다 — 가장 큰 인스턴스 위로는 못 간다. 사양이 올라갈수록 가격은 성능보다 가파르게 뛰고, 여전히 한 대라서 그 한 대가 죽으면 서비스 전체가 내려간다. 배포·재시작 때마다 생기는 다운타임도 그대로다.
언제: 단일 머신 천장이 가시권에 들어왔거나, '한 대 죽으면 전체 다운'이 더는 허용 안 될 때. 공장 설비 센서 수집처럼 쓰기가 꾸준히 우상향하는 워크로드는 결국 여기로 온다. 단, 서버가 stateless여야 한다 — 세션은 Redis로, 파일은 S3로 빼는 작업이 먼저다.
비용: 상태 제거(세션 외부화), LB 운영, 인스턴스 수만큼 늘어나는 배포·모니터링이 통째로 따라온다. 그리고 앱을 늘려도 DB는 한 대라 병목이 DB로 옮겨갈 뿐이다 — 거기서 한 번 더 막히면 샤드 키 선정, skew, 리밸런싱이 따라오는 데이터 파티셔닝이라는 진짜 큰 공사가 기다린다.
기본은 스케일 업이다. 코드 한 줄 안 바꾸고 오늘 적용할 수 있는 제일 싼 수가 사양 한 단계 올리기다. 다만 현재 사양이 최대 인스턴스의 절반을 넘었거나, 한 대 장애가 곧 전체 장애인 게 SLA상 더는 허용 안 되는 순간 — 그때 세션부터 외부로 빼서 stateless로 만들고 LB 뒤에 2대 이상으로 간다. DB 쓰기까지 한 대 한계를 넘으면 그때 비로소 파티셔닝이다.
- 인스턴스를 한 단계 올렸는데도 피크 p99가 500ms 위에 머무름 — 수직 확장이 성장 속도를 못 따라간다는 신호
- 현재 사양이 그 패밀리 최대 인스턴스의 절반을 넘었는데 트래픽은 분기마다 2배 — 천장에 닿는 건 시간문제
- 피크마다 요청 큐(스레드 풀 대기)가 수백 건씩 쌓이고, 배포·재시작 한 번에 5분씩 전체 다운 — 한 대 구조의 가용성 한계
- (파티셔닝까지 갔다면) 샤드 하나에 전체 트래픽의 30% 이상이 몰림 — 샤드 키를 잘못 잡았다는 skew 신호
🔧AWS EC2/RDS instance resizeNginx / AWS ALB + Auto Scaling GroupRedis (세션 외부화)Grafana (p99·CPU·queue-depth 대시보드)Postgres 파티셔닝 / Vitess
“I'd scale up first because it's the cheapest move, and go horizontal once we near the ceiling or need redundancy.”
checking microphone…