세션 유실
LB가 요청을 다른 서버로 보내면 로컬 세션이 사라져 재로그인이 반복됩니다.
대응 · 스티키 세션 대신 Redis 등 외부 세션 저장소로 이관
0에서 수백만 사용자까지 확장
사용자가 늘어날 때 무엇이 먼저 병목이 되고, 어떤 순서로 고쳐야 하는가. 확장 단계마다의 판단 근거와 비용 트레이드오프를 정리합니다.
3분 요약
개념 이해
면접 답변
실무 확장
진도 저장 ✓
30초 핵심 요약
병목은 한 번에 오지 않습니다. 웹 트래픽 → DB 읽기 → DB 쓰기 → 지역 거리 순서로 한 계층씩 막히므로, 막힌 계층에 가장 싼 해법(캐시 · 복제 · 샤딩 순)을 단계적으로 적용하는 것이 확장의 기본 패턴입니다. 각 단계로 넘어가는 판단은 감이 아니라 관측 지표로 합니다.
예시 목표 사용자 (설계 가정)DAU 100만 명
예상 피크 처리량 (계산 결과)약 1,160 QPS
목표 가용성 (설계 가정)99.9%
01 · REQUIREMENTS
# 요구사항확장에서 무엇을 지켜야 하는가?
확장은 성능만의 문제가 아니라 중단 없음, 비용, 측정 가능성을 함께 만족해야 하는 작업입니다.
F1단계적 성장
트래픽 증가에 맞춰 구조를 단계적으로 바꿉니다.
F2무중단 전환
다음 단계로 넘어갈 때 서비스가 멈추지 않아야 합니다.
F3비용 통제
단계별 비용 증가분을 정량화하고 추적합니다.
F4지표 기반 판단
확장 시점은 관측 값으로 결정합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처확장 단계별 아키텍처 진화
한 번에 거대 구조를 만들지 않습니다. 각 단계는 이전 단계의 병목을 해소하는 최소 변경이며, 사용자 규모와 비용은 함께 올라갑니다.
확장 단계별 요청 경로와 비용 변화 SVG DIAGRAM · 확대 가능
◉단일 서버STAGE 1 · Web+DB 한 대
▦캐시 · CDNSTAGE 2 · 반복 읽기 차단
⇄LB + 웹 팜STAGE 3 · 무상태 웹 계층
⧉복제 → 샤딩STAGE 4 · 읽기 분리 후 쓰기 분할
↗멀티 리전STAGE 5 · CDN + 리전별 복제
설계 포인트 — 확장 수단은 "저렴하고 되돌리기 쉬운 것부터" 적용합니다. 캐시 제거는 쉽지만 샤딩 해체는 매우 어렵습니다. 그래서 샤딩은 필요 시점 직전까지 미루는 것이 일반적인 판단입니다.
03 · SCALING STAGES
# 처리 흐름확장은 어떤 순서로 진행되는가?
단계 전환의 트리거는 지표입니다. CPU 포화, DB 커넥션 고갈, p95 지연 상승이 관측되면 다음 단계를 검토합니다.
1병목 측정
CPU·DB 커넥션·p95 지연으로 다음에 막힐 계층을 확인합니다.
2읽기 줄이기
캐시와 CDN으로 DB 접근 자체를 차단합니다. 가장 싼 단계입니다.
3웹 계층 무상태화
LB 뒤에서 서버를 자유롭게 증설하도록 세션을 외부화합니다.
4데이터 계층 분리
복제로 읽기를 나누고, 쓰기 병목이 오면 샤딩으로 분할합니다.
04 · TRADEOFFS
# 트레이드오프확장 옵션 비교
같은 성능 문제라도 어떤 수단으로 풀지에 따라 비용 곡선과 운영 부담이 크게 달라집니다.
옵션
적용 시점
강점
주의점
수직 확장
초기
설정 단순, 즉효
하드웨어 상한 · SPOF 유지
수평 확장
웹 계층 먼저
무중단 용량 증설
무상태 전제 · 세션 외부화 필요
캐시 · CDN
반복 읽기 많을 때
원가 대비 효과 최대
무효화 정책 실패 시 오래된 데이터
DB 복제
읽기 비중 클 때
읽기 확장 + 백업
복제 지연으로 정합성 체감 문제
샤딩
쓰기 병목 때
쓰기·용량 한계 돌파
교차 샤드 질의 · 리샤딩 비용
05 · FAILURE MODES
# 장애 대응장애 시나리오와 대응
캐시 스탬피드
핫 키들이 동시에 만료되면 순간적으로 DB에 요청이 몰려 응답이 멈춥니다.
대응 · TTL 지터 부여, 조기 재계산, 동일 키 요청 병합
복제 지연
Replica에서 읽으면 방금 쓴 데이터가 보이지 않아 사용자가 혼란을 겪습니다.
대응 · read-after-write 범위는 Primary로 라우팅 + lag 모니터링
리샤딩 폭탄
초기 샤딩 키를 잘못 잡으면 데이터 이동 비용이 감당할 수 없이 커집니다.
대응 · 일관된 해싱과 여유 샤드 수로 초기 설계, 편차 상시 관측
06 · OPERATIONS
# 운영보안·관측·비용·출처
영역
확인할 것
판단 기준
주의점
보안·개인정보
멀티 리전 저장 위치·캐시 TTL
지역 규제와 삭제 전파
캐시에 개인정보 최소화
관측
QPS, p95/p99, cache hit, replica lag
단계 전환 전후 추세 비교
평균 지연만으로 판단 금지
비용
캐시·복제·샤딩·리전별 증분
월 비용 표시는 설계 가정
샤딩은 되돌리기 비용 큼
면접 모드 · 추가 질문05:00
“사용자가 1만 명에서 100만 명으로 늘어난다고 할 때, 어떤 순서로 시스템을 바꾸시겠습니까? 각 단계로 넘어간 근거를 무엇으로 제시하시겠습니까?”
답변 구조 보기힌트 1개예상 꼬리 질문
NEXT CASE STUDY분산 레이트 리미터 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- The Tail at Scale (Google Research) — 대규모 서비스에서 p99 등 tail latency를 별도 관측해야 하는 이유를 검토했다.
- Amazon Builders' Library: Caching challenges and strategies — 캐시 장애·hot key·downstream 보호의 운영 관점을 검토했다.
- Amazon Dynamo paper (SOSP 2007) — 복제·파티셔닝·고가용성의 기본 트레이드오프를 교차 검토했다.
- 본 문서의 모든 수치는 `설계 가정` 또는 `계산 결과`이며 제품 사실이 아니다.
- 주제 구성 참고: liquidslr/system-design-notes (독립 재집필, 문장·이미지 미사용)
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.