가상 면접 사례로 배우는 대규모 시스템 설계 기초 2
읽은 기간
시리즈 작성 기간: 6개월로 2주마다 1장씩 진행했기에 상당히 시간이 걸렸다. 그러나 양이 많지 않아서 1장을 읽는데는 거의 1시간도 소비되지 않았던 것 같다.
추천 대상
- 면접을 준비하는 개발자 (시스템 구조를 물어보는 면접)
- 대규모 트래픽의 구조를 맛보고 싶은 백엔드 엔지니어
- 분산 시스템의 대략적인 구조를 알고싶은 사람
핵심 내용 정리
이 책은 실제 면접에서 나올 법한 13가지 시스템을 설계하는 과정을 보여준다. 1권이 기초였다면, 2권은 좀 더 특화된 도메인을 다룬다.
근접성 서비스
문제: 내 주변 음식점/주유소 어떻게 찾지?
위치 검색 알고리즘 비교
┌──────────┬─────────────────────────────────┐
│ 지오해시 │ 구현 쉬움, Redis 연동 용이 │
│ 쿼드트리 │ K번째 근처 데이터 조회 가능 │
└──────────┴─────────────────────────────────┘핵심 포인트:
- Redis Sorted Set으로 지오해시 저장
- 읽기가 압도적 → 단일 리더 복제 구조
- KEDA로 이벤트 기반 자동 스케일링
주변 친구
문제: 5마일 내 친구 실시간으로 어떻게 보여주지? (DAU 1억명)
WebSocket vs Long Polling
↓
WebSocket 선택 (지연시간 ↓, 오버헤드 ↓)아키텍처:
- Redis Pub/Sub: 위치 변경 브로드캐스트 (서버 140대 필요)
- Cassandra: 위치 이력 저장 (쓰기 최적화)
- Consistent Hashing: 분산 서버 부하 분배
구글 맵
핵심 개념들:
- 지오코딩: "강남역" → (37.5000, 127.0350)
- 지오해싱: 좌표 → "wydmuwq7" (압축 문자열)
- A 알고리즘*: f(n) = g(n) + h(n) 으로 최적 경로 탐색
경로 안내 타일: 계층적 구조
상위 타일 (고속도로)
↓
중위 타일 (주요 도로)
↓
하위 타일 (이면 도로)최적화: 정적 타일은 CDN 캐싱, 벡터로 대역폭 절감
분산 메시지 큐
Kafka 같은 메시지 큐를 직접 설계한다면?
파티션 기반 아키텍처
┌────────────────────────────────────┐
│ 토픽 → 파티션들 (각각 FIFO 큐) │
│ WAL → 순차적 디스크 접근 │
│ Zero Copy → 커널 버퍼 직접 전송 │
└────────────────────────────────────┘메시지 전달 보장
| 방식 | 설명 |
|---|---|
| 최대 한 번 | 유실 가능, 중복 없음 |
| 최소 한 번 | 유실 없음, 중복 가능 |
| 정확히 한 번 | 유실 없음, 중복 없음 (비용 높음) |
지표 모니터링 및 경보 시스템
Pull vs Push: 일반적으로 Pull(Prometheus) 권장
-
디버깅 용이
-
health check 간편
시계열 DB 구조 (Prometheus)
메모리 → WAL → 블록 (압축)
↓
다운샘플링 → 콜드 스토리지결론: 시각화/경보는 상용품(Grafana, PagerDuty) 쓰는 게 낫다
광고 클릭 이벤트 집계
요구사항: 1초 이내 모든 프로세스 완료 (RTB)
이중 DB 전략
├─ 원시 데이터: Cassandra/S3 (쓰기 최적화)
└─ 집계 데이터: NoSQL (읽기/쓰기 균형)
롤업 기법: 동일 시간대 데이터 사전 집계
→ 저장 공간 수십~수백 배 축소
Druid 선택 이유: MapReduce의 동기적 처리 한계 극복 + 실시간 OLAP
호텔 예약 시스템
동시성 제어가 핵심:
// 비관적 락 - 충돌 많을 때
SELECT * FROM rooms WHERE id = ? FOR UPDATE
// 낙관적 락 - 충돌 적을 때
UPDATE rooms SET ... WHERE id = ? AND version = ?분산 환경에서:
- Redis/Zookeeper로 분산 락
- TTL로 데드락 방지
- 사가(Saga) 패턴으로 보상 트랜잭션
분산 이메일 서비스
프로토콜 정리:
-
SMTP: 송신
-
IMAP: 동기화 (여러 기기)
-
POP3: 다운로드 (한 기기)
샤딩 전략: user_id를 파티션 키로 → 사용자 데이터 일관성 보장
검색 최적화: LSM 트리로 랜덤 쓰기 → 순차 쓰기 변환
nines 내구성 (99.999999999%) 달성 방법:
Erasure Coding
데이터 → 9개 조각 분할 → 5개만으로 복원 가능
(저장 효율 + 안정성)
핵심 구조:
- 메타데이터 DB: 키 → 물리위치 매핑
- Raft 합의: 분산 레플리카 일관성
- LSM 트리: HDD 순차 I/O 최적화
실시간 게임 순위표
왜 Redis Sorted Set인가?
| 저장소 | 문제점 |
|-------|---------------------------|
| RDB | 수백만 레코드에서 성능 저하 |
| NoSQL | GSI 필요, 복잡 |
| Redis | O(log N) 자동 정렬, Skip List |보안: 클라이언트 → 순위표 서비스 직접 통신 금지 (점수 위조 방지)
결제 시스템
정확히 한번(Exactly Once) 전달:
프로듀서: enable.idempotence=true, acks=all
컨슈머: DB에 소비 기록 → 중복 처리 방지
DLQ(Dead Letter Queue): 실패 메시지 별도 보관 → 재시도/분석
전자 지갑
금융 거래는 원자성 필수 → Redis 클러스터 부적절
분산 트랜잭션 패턴 비교:
| 패턴 | 특징 | 단점 |
|---|---|---|
| 2PC | 준비→확정 | 블로킹, 단일 장애점 |
| TCC | 예약 개념, 비블로킹 | 구현 복잡 |
| SAGA | 보상 트랜잭션 | 격리성 문제 |
이벤트 소싱: 현재 상태 대신 모든 이벤트 저장 → 감사 추적 가능
증권 거래소
극한의 성능 요구사항: 99.99% 가용성 (일일 장애 허용: 8.64초)
핵심 컴포넌트
├─ Sequencer: 주문 순서 정렬 (결정론적)
├─ mmap + /dev/shm: 프로세스 간 메모리 공유
└─ Colocation: 거래소 DC에 서버 직접 설치
FIX Protocol: 전 세계 증권사 표준 프로토콜
실무에서 바로 쓸 수 있는 패턴들
위치 기반 서비스
지오해시 + Redis Sorted Set
→ 빠른 근접 검색
실시간 통신
WebSocket + Redis Pub/Sub + Consistent Hashing
→ 대규모 브로드캐스트
분산 트랜잭션
TCC or SAGA + 이벤트 소싱
→ 마이크로서비스 환경 일관성
대용량 집계
Kafka → Druid + 롤업
→ 실시간 OLAP 분석
종합 평가
1권보다 도메인이 특화되어 있어서 재밌게 읽었다. 특히 결제/전자지갑/증권거래소 챕터는 금융 도메인 특유의 요구사항(정확성, 감사 추적, 극한의 가용성)을 잘 다루고 있다. 다른 도메인의 구조가 궁금하다면 이를 참고
면접 준비용으로도 좋지만, 실제 시스템 설계할 때 레퍼런스로 쓰기에도 괜찮다. 다만 각 챕터가 개요 수준이라 깊이 있는 구현은 별도로 공부해야 한다.
⭐⭐⭐ (3/5)
