『가상 면접 사례로 배우는 대규모 시스템 설계 기초』를 읽고, 직접 시스템을 설계한 뒤 서로의 설계와 책의 사례를 비교하는 스터디입니다.
책의 구조를 암기하기보다 다음 두 질문에 답할 수 있는 것을 목표로 합니다.
- 왜 이 구조를 선택했는가?
- 요구사항이나 상황이 바뀌면 어떻게 수정할 것인가?
- 인원: 백엔드 개발자 4명
- 기간: 총 8주
- 일정: 매주 수요일 20:00~22:00
- 교재: 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』
- 대상: 시스템 설계 경험이 많지 않은 2~4년 차 백엔드 개발자
| 이름 | GitHub |
|---|---|
| 박기현 (스터디장) | @qkrrlgus114 |
| chapakook | @chapakook |
| Sim Bo Kyung | @simbokyung98 |
| xogns4909 | @xogns4909 |
매주 다음 과정을 반복합니다.
- 해당 범위를 미리 읽고 주요 개념을 학습한다.
- 공통 요구사항을 확인한다.
- 책을 덮고 각자 시스템을 설계한다.
- 각자의 구조와 선택 이유를 발표한다.
- 토론을 통해 팀의 최종 설계를 만든다.
- 팀의 설계와 책의 설계를 비교한다.
- 장애나 트래픽 증가 조건을 하나 추가한다.
- 설계를 수정하고 핵심 원칙을 정리한다.
책으로 개념 학습 → 직접 설계 → 설계 비교 → 통합 설계 → 책과 비교 → 조건 변경 → 설계 개선
책의 설계와 다르다는 이유만으로 틀린 설계로 판단하지 않습니다. 요구사항과 트레이드오프를 설명할 수 있는지를 중요하게 봅니다.
| 주차 | 읽을 범위 | 메인 설계 | 추가 조건 |
|---|---|---|---|
| 1주차 | 1~3장 | 게시물 서비스 규모 확장 | 사용자와 트래픽 100배 증가 |
| 2주차 | 4~5장 | 분산 처리율 제한 장치 | Redis 또는 Rate Limiter 장애 |
| 3주차 | 6~7장 | 분산 Key-Value 저장소 | 노드 또는 데이터센터 장애 |
| 4주차 | 8~9장 | URL 단축기 | 인기 URL에 트래픽 집중 |
| 5주차 | 10~11장 | 뉴스 피드 및 알림 시스템 | 팔로워 5천만 명인 사용자 |
| 6주차 | 12장 | 채팅 시스템 | 메시지 중복·순서 변경 |
| 7주차 | 13~14장 | 유튜브 및 검색어 자동완성 | 트랜스코딩 작업 서버 장애 |
| 8주차 | 15~16장 | Google Drive | 두 기기에서 같은 파일 동시 수정 |
주차별 핵심 개념
- QPS와 저장량 추정
- 로드밸런서와 무상태 서버
- 캐시와 CDN
- DB 복제와 샤딩
- 시스템 설계의 기본 진행 순서
- 토큰 버킷과 이동 윈도
- 분산 환경의 상태 공유
- 경쟁 조건과 원자적 연산
- 해시 링과 가상 노드
- 서버 증감에 따른 데이터 재배치
- 안정 해시 기반 파티셔닝
- 데이터 복제
N,R,W정족수- 강한 일관성과 최종적 일관성
- 장애 감지와 복구
- 분산 유일 ID 생성
- 단축 URL 생성과 리다이렉트
- Base62와 키 충돌
- 읽기 중심 서비스의 캐시
- URL Frontier
- URL 및 콘텐츠 중복 제거
- robots.txt와 politeness
- 쓰기 시 fan-out과 읽기 시 fan-out
- Push·Pull·혼합 방식
- 유명 사용자 문제
- 메시지 큐와 비동기 처리
- 알림 재시도와 중복 방지
- 외부 서비스 장애 격리
- WebSocket 연결 관리
- 메시지 저장과 전달
- 메시지 ID와 순서
- 오프라인 메시지
- 다중 기기 동기화
- 접속 상태와 heartbeat
- 분할 업로드
- 트랜스코딩 작업 DAG
- 메시지 큐와 작업 서버
- CDN 기반 동영상 재생
- Trie와 Top-K 검색어
- 검색 데이터 집계와 갱신
- 파일 블록 분할
- 오브젝트 저장소와 메타데이터 DB
- 중복 제거와 변경분 전송
- 파일 버전 관리
- 동시 수정 충돌
- 변경 알림과 장애 복구
| 시간 | 진행 |
|---|---|
| 20:00~20:10 | 지난주 복습 및 이번 주 요구사항 확정 |
| 20:10~20:25 | 핵심 개념과 질문 확인 |
| 20:25~20:45 | 각자 메인 문제 설계 |
| 20:45~21:01 | 한 명당 4분씩 설계 발표 |
| 21:01~21:25 | 토론을 통해 하나의 설계로 통합 |
| 21:25~21:35 | 휴식 |
| 21:35~21:50 | 팀의 설계와 책의 설계 비교 |
| 21:50~21:58 | 장애 또는 트래픽 증가 조건 적용 |
| 21:58~22:00 | 핵심 설계 원칙 3개 정리 |
모든 문제는 다음 순서로 접근합니다.
- 기능 요구사항
- 비기능 요구사항
- 규모 추정
- API
- 데이터 모델
- 개략적 아키텍처
- 핵심 컴포넌트 상세 설계
- 장애 대응
- 트레이드오프
- 트래픽 증가에 따른 확장 방법
매주 해당 범위를 읽고 다음 내용을 간단히 준비합니다.
- 핵심 요구사항 3개
- QPS와 저장량의 대략적인 계산
- 중요하다고 생각한 개념
- 고민되는 설계 선택 1개
- 이해되지 않은 내용 1개
완성된 아키텍처나 PPT는 준비하지 않습니다. 실제 설계는 스터디 시간에 책을 덮고 진행합니다.
한 명당 발표 시간은 4분입니다.
- 핵심 요구사항: 30초
- 전체 구조: 90초
- 중요한 선택 두 가지와 이유: 90초
- 가장 불안하거나 자신 없는 부분: 30초
구성요소를 나열하기보다 선택 이유와 트레이드오프 설명에 집중합니다.
의견이 다른 경우 다음 질문으로 결정합니다.
- 어떤 요구사항 때문에 필요한가?
- 해당 구성요소를 제거하면 어떤 문제가 발생하는가?
- 무엇을 얻고 무엇을 포기하는가?
- 더 단순하게 해결할 방법은 없는가?
- 장애가 발생하면 어디까지 영향을 받는가?
- 트래픽이 10배 증가해도 사용할 수 있는가?
각자의 설계를 전부 합치는 것이 아니라, 필요성이 설명되는 구성요소만 최종 설계에 포함합니다.
매주 다음 내용을 기록합니다.
- 최종 통합 아키텍처
- 주요 설계 결정과 이유
- 책의 설계와 달랐던 부분
- 추가 조건에 따른 변경 사항
- 해결하지 못한 질문
- 재사용할 수 있는 설계 원칙 3개
장문의 회의록이나 발표 자료는 작성하지 않습니다.
매주 다음 역할을 돌아가면서 맡습니다.
- 진행자: 문제와 요구사항 준비 및 토론 진행
- 시간 관리자: 단계별 시간 관리
- 설계 기록자: 통합 아키텍처 작성
- 결과 기록자: 결정 사항과 설계 원칙 정리
역할과 관계없이 네 명 모두 개인 설계와 발표에 참여합니다.