BEGINNER18분기초 개념확장성

0에서 수백만 사용자까지 확장

사용자가 늘어날 때 무엇이 먼저 병목이 되고, 어떤 순서로 고쳐야 하는가. 확장 단계마다의 판단 근거와 비용 트레이드오프를 정리합니다.

운영자 직접 작성·기술 검토·최종 검토 2026.08.29

3분 요약

개념 이해

면접 답변

실무 확장

진도 저장 ✓

⚡30초 핵심 요약

병목은 한 번에 오지 않습니다. 캐시 적중률이 올라도 쓰기 IOPS가 그대로면 캐시 증설은 다음 답이 아닙니다. 읽기 병목은 캐시·읽기 복제본(Replica)으로 줄이고, 쓰기 여유가 30% 아래이며 6개월 내 용량 한계가 예상될 때만 샤딩합니다.

예시 목표 사용자 (설계 가정)DAU 100만 명

예상 피크 처리량 (계산 결과)약 1,160 QPS

목표 가용성 (설계 가정)99.9%

DESIGN DECISION · 설계 판단

지표가 어떻게 바뀔 때 다음 확장 단계로 넘어갈 것인가?

예시 DAU 100만 명 설계 가정

예시 피크 QPS 약 1,160 QPS 계산 결과

읽기 : 쓰기 95 : 5 설계 가정

최종 선택

관측 기반 캐시 → Replica → 샤딩 전환과 롤백

읽기 병목은 캐시와 Replica로 먼저 줄입니다. 쿼리·인덱스 최적화 뒤에도 쓰기 여유가 30% 아래이고 6개월 내 용량 한계가 예상될 때만 샤딩을 시작합니다.

선택 이유

캐시 적중률과 DB CPU 변화로 첫 병목이 실제로 이동했는지 확인할 수 있습니다.
Replica lag와 read-after-write 라우팅을 분리해 읽기 확장 중 사용자 정합성을 지킵니다.
샤딩 전에 교차 질의 비율과 롤백 조건을 계측해 되돌리기 어려운 복잡도를 늦춥니다.

포기한 대안

성장 예측만으로 초기 전면 샤딩

쓰기 한계가 확인되기 전에 샤딩하면 교차 샤드 질의와 리샤딩 운영을 먼저 떠안고 더 싼 읽기 최적화의 효과를 놓칩니다.

감수한 단점

캐시는 오래된 읽기와 stampede를, Replica는 복제 지연을 추가합니다.
전환이 늦으면 피크에서 여유가 급격히 줄지만 너무 빠르면 유휴 비용과 운영 표면이 커집니다.
샤드 키를 잘못 고르면 쓰기 용량을 얻고도 핵심 질의가 느려질 수 있습니다.

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

장애 시나리오와 대응

# 장애 대응

!세션 유실

LB가 요청을 다른 서버로 보내면 로컬 세션이 사라져 재로그인이 반복됩니다.

대응 · 스티키 세션 대신 Redis 등 외부 세션 저장소로 이관

↻캐시 스탬피드

핫 키들이 동시에 만료되면 순간적으로 DB에 요청이 몰려 응답이 멈춥니다.

대응 · TTL 지터 부여, 조기 재계산, 동일 키 요청 병합

⌁복제 지연

Replica에서 읽으면 방금 쓴 데이터가 보이지 않아 사용자가 혼란을 겪습니다.

대응 · read-after-write 범위는 Primary로 라우팅 + lag 모니터링

◇리샤딩 폭탄

초기 샤딩 키를 잘못 잡으면 데이터 이동 비용이 감당할 수 없이 커집니다.

대응 · 일관된 해싱과 여유 샤드 수로 초기 설계, 편차 상시 관측

06 · OPERATIONS

보안·관측·비용·출처

# 운영

영역

확인할 것

판단 기준

주의점

보안·개인정보

멀티 리전 저장 위치·캐시 TTL

지역 규제와 삭제 전파

캐시에 개인정보 최소화

관측

QPS, p95/p99, cache hit, replica lag

단계 전환 전후 추세 비교

평균 지연만으로 판단 금지

비용

캐시·복제·샤딩·리전별 증분

월 비용 표시는 설계 가정

샤딩은 되돌리기 비용 큼

출처

The Tail at Scale · AWS Builders' Library

검토일 2026-08-29

특정 클라우드 가격으로 일반화하지 않음

면접 모드 · 추가 질문05:00

“사용자가 1만 명에서 100만 명으로 늘어난다고 할 때, 어떤 순서로 시스템을 바꾸시겠습니까? 각 단계로 넘어간 근거를 무엇으로 제시하시겠습니까?”

답변 구조 보기 4단계

현재 규모와 목표 규모를 수치로 고정한다(추정).
병목이 생길 계층을 예측하고 순서를 정한다.
각 단계의 도입 트리거 지표를 제시한다.
마지막에 비용·복잡도 트레이드오프를 스스로 언급한다. 이번 선택: 읽기 병목은 캐시·Replica로 먼저 줄이고 쓰기·용량 한계가 확인될 때만 샤딩한다. 깨지는 신호: 적중률이 올라도 Primary 쓰기 IOPS와 p95가 떨어지지 않는다. 다음 검증: 단계별 트래픽 전환과 롤백을 부하 시험에서 반복하고, 병목이 실제로 다음 계층으로 이동했는지 확인한다.

INTERVIEW ↔ PRACTICE · 면접과 실무의 차이

병목 이동을 지표로 증명하고 다음 단계를 멈출 조건 정하기

INTERVIEW · 면접

구성 요소 목록 대신 병목·변경·효과·다음 신호 순서로 답합니다.

캐시 전후의 적중률·DB CPU·p95 변화를 설명합니다.
Replica lag와 read-after-write 예외를 답합니다.
쓰기 여유·용량 예측·교차 질의로 샤딩 조건을 고정합니다.

PRACTICE · 실무

10% 단위 트래픽 전환과 롤백으로 병목 이동을 재현합니다.

단계별 p95·DB IOPS·커넥션·캐시 적중률을 비교합니다.
Replica lag 3초 초과 때 Primary 라우팅을 검증합니다.
샤딩 후 교차 요청 2% 이하와 쓰기 여유 40% 이상을 확인합니다.

NEXT CASE STUDY분산 레이트 리미터 설계

→

REAL PROJECT CASE

AI Systems Atlas에서 이 개념 보기

문서 수와 관계 밀도가 증가할 때 저장·조회·화면 투영을 서로 다른 확장 경계로 나누는 사례입니다.

실제 구현 해설 보기 →

EDITORIAL NOTES

작성·검토·참고 자료

콘텐츠 원칙: 이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
작성·기술 검수: 프로젝트 운영자가 직접 작성·기술 검토했습니다. 주제별 공식·1차 자료와 명시적인 설계 가정을 확인하며, 독립적인 제3자 검수가 아닙니다. 경력 범위와 검수 원칙 보기
최종 검토: 2026-08-29
예상 학습 시간: 18분

참고 자료

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 (독립 재집필, 문장·이미지 미사용)

사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.