캐시 stampede
만료된 인기 키로 인해 같은 원본 읽기가 동시에 몰리고 p99가 급증합니다.
대응 · single-flight, TTL jitter, 음성 캐시, 원본 요청 상한을 두고 미스 폭주 부하 시험을 합니다.
시스템 디자인
문제 풀이 프레임워크
요구사항을 묻고, 수치를 가정하고, 단순한 흐름에서 병목과 실패를 찾은 뒤 운영 가능한 선택으로 좁혀 가는 설계 순서입니다.
개념 이해면접 답변운영 관점진도 저장
30초 핵심 요약
프레임워크의 목적은 멋진 구성도를 빨리 그리는 것이 아닙니다. 기능·SLO·규모를 확인하고, 최소 데이터 흐름으로 시작해 가장 위험한 병목을 검증 가능한 가정으로 바꾸는 것입니다. 캐시·큐·복제는 그 가정을 지키는 역할이 분명할 때 추가합니다.
첫 질문누가 무엇을 약속받나?
첫 그림동기·비동기 데이터 흐름
첫 검증장애 중 SLO를 지키는가?
01 · REQUIREMENTS
# 요구사항답보다 질문을 먼저 고정한다
“빠르게”, “실시간”, “확장 가능”은 설계 조건이 아닙니다. 핵심 사용자 여정, 정확해야 하는 데이터, 지연·가용성·비용의 우선순위를 질문으로 좁혀야 합니다.
Q1핵심 여정
조회·작성·삭제 중 무엇이 성공해야 제품 가치가 유지되는지 적습니다.
Q2약속의 수치화
p95 지연, 성공률, 반영 지연처럼 관찰 가능한 목표로 바꿉니다.
Q3데이터 경계
접근 권한, 삭제, 보관, 감사가 필요한 필드를 구분합니다.
Q4가정의 등록
확인하지 못한 사실은 출처·검증일·대체 시나리오와 함께 남깁니다.
설계 가정 · 이 예시는 읽기가 쓰기보다 많은 공개 콘텐츠 서비스입니다. 실제 제품의 규정·사용자 행동·목표 수치는 운영 데이터로 대체해야 합니다.
02 · DESIGN LOOP
# 아키텍처요구사항을 병목 검증으로 연결한다
각 상자는 특정 제품이나 클라우드 서비스를 뜻하지 않습니다. 요구사항이 데이터 경로와 검증 항목으로 바뀌는 순서를 보여 주는 독립적인 설계 지도입니다.
문제 풀이 흐름 SVG DIAGRAM · 가정은 측정으로 교체
사실과 가정의 분리 · SLO와 오류 예산은 운영 목표를 논의하는 방식입니다. 반면 “피크 12배”나 “5초 내 반영”은 이 서비스의 설계 가정이므로 부하 시험·실측으로 검증합니다.
03 · DATA FLOW
# 처리 흐름최소 흐름을 먼저 설명한다
예시 콘텐츠 서비스의 쓰기는 인증·검증 후 원본과 이벤트를 기록하고, 비동기 작업자가 후보 목록과 검색 인덱스를 갱신합니다. 읽기는 캐시에서 후보를 가져오고 부족분만 원본으로 보충합니다.
1입력 보호
인증, 권한, 크기, 속도 제한을 엣지와 서비스 경계에서 확인합니다.
2내구성 기록
원본과 전달할 이벤트의 원자성 경계를 명시해 유실을 막습니다.
3비동기 파생
중복 이벤트도 버전·멱등 키로 합쳐 목록과 인덱스를 갱신합니다.
4읽기 보정
캐시 미스 폭주를 제어하고 표시 직전 삭제·권한을 재확인합니다.
04 · TRADEOFFS
# 트레이드오프무엇을 얻고 무엇을 감수하는가
선택
강점
대가
결정 신호
동기 fan-out
목록 읽기가 단순
인기 작성자 쓰기 폭발
최신성과 작은 팔로워 집합이 핵심일 때
읽기 시 조합
쓰기 부하가 평탄
읽기 지연과 캐시 복잡도
쓰기 변동이 크고 약간의 지연을 허용할 때
강한 동기 복제
최신 읽기 보장 강화
지연과 가용성 감소 가능
오래된 값이 금전·재고 위험을 만들 때
비동기 복제
경로 격리·낮은 지연
일시적 오래된 결과
피드·검색처럼 보정 가능한 화면일 때
05 · FAILURE MODES
# 장애 대응복구가 아니라 검증까지 설계한다
이벤트 작업자 지연
새 게시물, 검색, 삭제 전파가 늦어져 파생 데이터가 원본과 벌어집니다.
대응 · oldest event age 경보, 재처리, 멱등 적용, 읽기 시 원본 보정으로 보호합니다.
저장소 failover
리더 장애와 재선출 동안 읽기 오류·복제 지연이 증가할 수 있습니다.
대응 · 실패 전환 훈련, 제한된 캐시 응답, 데이터 최신성 확인 후 트래픽 복귀를 실행합니다.
핫 파티션
특정 사용자나 키 하나가 균등한 전체 평균을 무력화하고 한 샤드만 포화시킵니다.
대응 · 키별 QPS 관측, 요청 병합, 키 분할, 일부 사용자 저하 응답을 준비합니다.
06 · OPERATIONS
# 운영운영 조건까지 문서에 남긴다
영역
관찰할 신호
운영 결정
놓치기 쉬운 제약
보안·개인정보
권한 거부, 삭제 전파, 접근 감사
최소 권한·비밀 회전·데이터 분류
본문·토큰을 로그·추적 속성에 넣지 않음
관측 가능성
성공률, p95/p99, lag, cache miss
증상 중심 경보와 runbook
평균·CPU 하나로 SLO 판단 금지
비용
egress, 복제, 로그 보관, 유휴 용량
요청·바이트·보관 기간 단위 모델
저비용 선택이 복구 목표를 깨면 총비용 증가
변경·복구
배포 오류, rollback 시간, 오류 예산
점진 배포·중단 기준·복구 훈련
자동화도 권한과 되돌림 경계를 가져야 함
공식 관점 · Google SRE의 SLO 가이드와 AWS Well-Architected의 Reliability·Cost Optimization 자료는 목표, 복구, 비용을 반복적으로 측정하고 개선하는 운영 원칙을 제공합니다.
면접 모드 · 추가 질문05:00
“읽기 중심 피드 서비스에서 게시 후 수 초 내 반영을 약속해야 합니다. 어떤 요구사항을 확인하고, 어떤 경로를 동기·비동기로 나누며, 캐시 미스 폭주와 작업자 지연을 어떻게 감지·완화·검증하겠습니까?”
요구사항과 SLO단순 흐름과 병목장애·운영 검증
NEXT FOUNDATION0에서 수백만 사용자까지 확장
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- Google SRE, Service Level Objectives — SLO와 오류 예산을 설계·운영 목표로 다루는 공식 가이드입니다.
- Google SRE, Monitoring Distributed Systems — 증상 중심 모니터링과 운영 지표를 다루는 1차 자료입니다.
- AWS, AWS Well-Architected Reliability Pillar — 장애 복구, 변경 관리, 수요 관리에 관한 공식 프레임워크입니다.
- AWS, AWS Well-Architected Cost Optimization Pillar — 비용을 지속적으로 측정·개선하는 공식 가이드입니다. 이 원고의 일반 원칙은 위 공식 자료를 참고해 독립적으로 재구성했습니다. 제품 규모, 수치, SLO, 보존 기간, 컴포넌트 선택은 별도로 표시한 **설계 가정**이며 공급자 보장이나 법률 자문이 아닙니다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.