System Design 실전 플레이북
3줄 요약
- 실전 플레이북은 기술 목록이 아니라 설계 리뷰와 장애 대응에서 무엇을 먼저 판단할지 정하는 순서다.
- 좋은 답변은 영향 범위, 증거 지표, 임시 완화, 정합성 손상, owner, 후속 설계 변경을 분리한다.
- 이 챕터는 신규 기능, 트래픽 급증, 캐시 정합성, 큐 적체, 설계 문서 작성 상황을 회수 가능한 runbook으로 바꾼다.
핵심 정리
- 설계 리뷰는 구현 전 승인 절차다. API, 상태 owner, 피크 트래픽, 실패 응답, 롤백 조건이 빠지면 보류한다.
- 트래픽 급증 대응은 증설보다 병목 식별이 먼저다. DB, Redis, connection pool, queue, 외부 API 중 어디가 포화됐는지 본다.
- 캐시 정합성 대응은 빠른 삭제가 전부가 아니다. 최종 진실의 원천, stale 허용 범위, key 범위, 재생성 순서를 고정해야 한다.
- 큐 적체와 retry 폭주는 처리량 문제가 아니라 증폭 문제일 수 있다. producer 제한, retry 중단, DLQ 분리, replay 조건을 나눠야 한다.
- 설계 문서는 예쁜 양식이 아니라 결정 기록이다. 대안, trade-off, 포기한 것, 관측 지표, 되돌릴 방법이 남아야 한다.
판단 순서
- 사용자 영향: 누가 실패를 보고 있고, 매출·정산·보안·데이터 오염 중 무엇이 걸려 있는가?
- 증거: p95, error rate, queue age, cache hit rate, DB CPU, lock wait, 외부 API 응답 중 어떤 지표가 변했는가?
- 즉시 완화: 차단, 감속, 우회, fallback, feature flag, batch 중단 중 무엇이 가장 작게 위험을 줄이는가?
- 정합성: 이미 잘못 쓴 데이터가 있는가, 오래된 값을 보여준 것인가, 중복 실행이 발생했는가?
- 책임 경계: API owner, 데이터 owner, 운영 owner, 고객 공지 owner가 분리되어 있는가?
- 후속 조치: 임시 조치를 제거할 조건과 근본 설계 변경의 검증 방법이 있는가?
상세본 구성
01. 신규 기능 설계 리뷰 Runbook 상세.md: 쿠폰 발급 API를 예로 설계 리뷰 승인·보류 기준을 정리한다.02. 트래픽 급증 대응 설계 Runbook 상세.md: 이벤트 트래픽 급증에서 병목을 찾고 traffic shed를 적용하는 순서를 다룬다.03. Cache 정합성 문제 대응 Runbook 상세.md: 가격·재고 값이 오래 보이는 상황에서 key, TTL, invalidation, rebuild를 판단한다.04. Queue 적체와 Retry 폭주 대응 Runbook 상세.md: 알림 worker 적체와 provider 429가 retry 폭주로 번질 때의 차단 순서를 다룬다.05. 설계 문서 작성 템플릿 상세.md: 결정이 회수되도록 배경, 대안, 선택, 지표, 롤백, 미해결 질문을 남기는 법을 정리한다.
헷갈리는 지점
- 원인 분석을 먼저 끝내야 대응할 수 있다고 생각하기 쉽다.
- 실전에서는 사용자 영향이 크면 완화가 먼저다.
- 원인 분석은 완화 이후에 증거를 보존한 상태에서 진행한다.
- 서버를 늘리면 급증 대응이 된다고 오해하기 쉽다.
- 병목이 DB lock, Redis hot key, 외부 API quota라면 서버 증설은 장애를 키운다.
- 먼저 요청을 줄이거나 비싼 경로를 우회해야 한다.
- 캐시는 성능 문제라고만 보기 쉽다.
- 캐시는 정합성, 고객 신뢰, 데이터 owner 문제다.
- stale 값을 허용할 수 있는 화면과 허용할 수 없는 명령을 분리해야 한다.
- 큐는 안정성을 높인다고만 보기 쉽다.
- 큐는 장애를 늦게 보이게 만들 수 있고 retry로 downstream을 더 세게 때릴 수 있다.
- oldest message age와 retry rate를 함께 봐야 한다.
확인 질문
- 확인 질문: runbook에서 가장 먼저 볼 것은 무엇인가?
- 답변: 기술 원인이 아니라 사용자 영향과 되돌릴 수 없는 데이터 손상 여부다.
- 확인 질문: 설계 문서가 승인되려면 무엇이 있어야 하는가?
- 답변: 선택 이유, 포기한 대안, 바뀌는 설계 축, 관측 지표, 롤백 조건이 있어야 한다.
- 확인 질문: 이 챕터가 바꾸는 설계 축은 무엇인가?
- 답변: 성능, 정합성, 장애 격리, 운영 복잡도를 상황별로 분리해 판단하게 만든다.
참고 자료 기준