시스템 디자인 | System Design
내가 볼려고 작성한 CS 공부.
⚙️ 시스템 디자인 – 대규모 서비스 설계
✅ 1. 시스템 디자인 기초
1.1 클라이언트–서버 구조
대부분의 웹 서비스는 클라이언트(사용자) ↔ 서버(백엔드) 구조를 기본으로 한다.
클라이언트는 요청을 보내고, 서버는 요청을 처리해 응답을 보낸다.
기본 흐름
1
2
브라우저 → 서버 → 데이터베이스
← 응답 반환
현대 웹에서는 이 구조가 다층(3-tier 구조: 클라이언트, 웹서버, DB) 으로 확장된다.
1.2 상태 저장 vs 무상태 서버
시스템 설계에서 “서버가 사용자의 상태를 기억할 것인가” 는 매우 중요한 결정이다.
| 구분 | 상태 저장(Stateful) | 무상태(Stateless) |
|---|---|---|
| 의미 | 서버가 클라이언트 상태를 유지함 | 요청마다 독립적 |
| 예시 | 로그인 세션, 장바구니 | REST API, JWT 인증 |
| 장점 | 사용자 맞춤 처리 가능 | 확장성/유지보수 용이 |
| 단점 | 서버 간 세션 동기화 필요 | 매 요청마다 인증 필요 |
대규모 서비스에서는 대부분 무상태 설계를 기본으로 하되,
필요한 부분에만 상태를 따로 관리한다 (ex: Redis 세션 저장소).
1.3 싱글 서버의 한계
처음에는 하나의 서버로 서비스를 시작할 수 있지만,
유저가 증가하면 다음과 같은 병목이 발생한다:
| 한계 | 설명 |
|---|---|
| CPU | 연산량이 많아지면 느려짐 |
| 메모리 | 캐시/세션 데이터가 쌓이며 부족해짐 |
| 네트워크 | 동시 연결 수 증가 시 속도 저하 |
| 저장소 | DB 읽기/쓰기 한계, 디스크 용량 부족 |
그래서 서버, DB, 스토리지 모두 분리 및 확장이 필요해진다.
이걸 해결하기 위한 방향이 바로 수평/수직 확장, 캐싱, 분산처리, 비동기 시스템 등이다.
1.4 요구사항 분석과 트래픽 예측
시스템 설계의 핵심은 기술보다 요구사항과 데이터 흐름을 먼저 정의하는 것!
요구사항 체크리스트
- 💡 일일 사용자 수 (DAU, MAU)
- 💡 초당 요청 수 (RPS, QPS)
- 💡 데이터 저장량 (일간, 연간)
- 💡 읽기 vs 쓰기 비율
- 💡 응답 시간 기준 (SLI/SLO)
- 💡 장애 허용 수준 (SLA)
이를 기반으로 서버 수, DB 용량, 캐시 전략, 분산 처리 구조 등을 결정한다.
트래픽 예측 예시
- 1일 사용자: 100만 명
- 평균 요청: 5회/1명 → 500만 요청/일
- 초당 요청: 약 58 RPS (500만 / 86400초)
- 피크타임 예측: 최대 500 RPS 예상
이 숫자를 기준으로 로드밸런서, 캐시 용량, DB 샤딩 여부 등을 설계하게 된다.
✅ 2. 확장성과 성능 설계
2.1 수직 확장 vs 수평 확장
성능이 부족할 때 시스템을 확장하는 방법은 크게 2가지다.
| 방식 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 수직 확장 (Scale-Up) | 서버 1대의 CPU, RAM 등을 업그레이드 | 구조 단순, 적용 빠름 | 비용 ↑, 한계 존재 |
| 수평 확장 (Scale-Out) | 서버 대수를 늘려 부하 분산 | 무한 확장 가능 | 구조 복잡, 데이터 분산 고려 |
초기에는 수직 확장이 빠르지만,
대규모 서비스는 반드시 수평 확장 기반으로 설계해야 한다.
2.2 병목 식별 & 제거
전체 시스템의 성능은 가장 느린 부분(병목) 에 의해 결정된다.
주요 병목 지점
| 병목 위치 | 설명 |
|---|---|
| DB | SELECT가 느리거나 인덱스 부재 |
| 네트워크 | 요청량 폭증, 전송 지연 |
| 스토리지 | 디스크 I/O 한계, 대용량 처리 문제 |
| CPU | 과도한 계산, 동시 요청 과부하 |
| 메모리 | 캐시 누락, GC(가비지 컬렉션) 지연 |
시스템 디자인의 목적은 이런 병목을 찾아내고
적절한 캐시, 분산처리, 비동기 구조로 해결하는 데 있다.
2.3 로드 밸런서 구조
로드 밸런서는 클라이언트 요청을 여러 서버에 분산시켜
서버 1대에 과부하가 가지 않게 해준다.
주요 방식
| 방식 | 설명 |
|---|---|
| Round Robin | 순차적으로 분산 |
| Least Connection | 현재 연결 수가 가장 적은 서버로 |
| IP Hash | 같은 사용자(IP)는 항상 같은 서버로 |
구성 예시
1
2
3
4
5
[클라이언트 요청]
↓
[로드 밸런서]
┌────┴────┐
[서버1] [서버2]
웹 서버 앞단에 로드 밸런서를 두면
트래픽 분산 + 서버 확장성 확보 가능
2.4 성능 최적화를 위한 구성 요소들
| 요소 | 역할 |
|---|---|
| CDN | 정적 파일 분산 (이미지, JS, CSS 등) |
| 캐시 | 자주 조회되는 데이터 미리 저장 |
| 비동기 큐 | 작업 지연 없이 처리를 분산 |
| 압축 | 응답 용량 줄이기 (gzip, Brotli 등) |
| DB 튜닝 | 인덱스, 쿼리 최적화, 샤딩 등 |
2.5 예시: 단일 서버 → 수평 확장 구조
1
2
3
4
5
6
7
[클라이언트]
↓
[로드 밸런서]
↓
[서버1] [서버2] [서버3]
↓
[공통 DB] or [샤딩된 DB]
상태 무관하게 구성하면 서버를 계속 늘릴 수 있다 → 확장성 확보
✅ 3. 데이터베이스 설계 & 분산 처리
3.1 읽기/쓰기 분리 (Master–Slave 구조)
DB의 쓰기 처리와 읽기 처리 부하를 분리하는 구조다.
구성 방식
1
2
3
4
5
6
[앱 서버]
↓
┌────────┴────────┐
[쓰기 요청] [읽기 요청]
↓ ↓
[Master DB] ←←← [Slave DB 1, 2...]
| 역할 | 설명 | |——|——| | Master | 모든 쓰기(INSERT, UPDATE) 수행 | | Slave | Master를 복제, 읽기 전용 처리 |
대부분의 읽기 요청을 Slave로 보내 성능과 확장성 향상
3.2 샤딩 (Sharding)
데이터를 수평으로 나누어 여러 DB에 분산 저장하는 기법이다.
| 항목 | 설명 |
|---|---|
| 목적 | 데이터 용량 분산, 처리 속도 향상 |
| 분할 기준 | 사용자 ID, 지역, 해시 등 |
예시
- 유저 ID % 4 → 4개의 샤드로 분할
- 유저 ID 0~999999 → Shard 1
- 유저 ID 1000000~1999999 → Shard 2 …
샤딩 시 JOIN, 트랜잭션 처리 복잡도 ↑ → 이를 위한 설계 전략이 중요
3.3 정규화 vs 비정규화 (설계 관점)
| 구분 | 정규화 | 비정규화 |
|---|---|---|
| 목적 | 데이터 중복 제거 | 조회 속도 향상 |
| 장점 | 일관성, 관리 쉬움 | 빠른 응답, JOIN 제거 |
| 단점 | JOIN 많아져 느림 | 중복 관리 필요 |
시스템 설계에서는 API 응답 속도, DB 부하 등을 고려해
일부 테이블은 비정규화하여 캐시처럼 설계하기도 함
3.4 파티셔닝 (Partitioning)
하나의 테이블을 내부적으로 논리적으로 나누는 기법
DB 엔진이 내부적으로 구분해서 저장/쿼리함 (샤딩과는 다름)
| 종류 | 설명 |
|---|---|
| Range Partitioning | 특정 범위별로 분할 |
| Hash Partitioning | 해시 값 기준 분할 |
| List Partitioning | 특정 값 목록 기준 분할 |
파티셔닝은 물리적 분산은 없지만,
대용량 테이블의 쿼리 성능 최적화에 도움됨
3.5 분산 트랜잭션 처리
데이터가 여러 DB(또는 샤드)에 걸쳐있을 때,
ACID를 만족시키는 트랜잭션을 수행하는 방법
| 방식 | 설명 |
|---|---|
| 2PC (2-Phase Commit) | 준비 단계 + 커밋 단계로 나눠 모든 DB가 동의해야 커밋 |
| SAGA 패턴 | 각 단계별 트랜잭션 실행 + 실패 시 보상 트랜잭션 실행 |
| 멱등성 처리 | 중복 실행돼도 결과가 같은 구조로 API 설계 |
실무에서는 대부분 SAGA 패턴 + 이벤트 기반 처리로 구현
3.6 예시: 확장 가능한 DB 구조 흐름
1
2
3
4
5
6
7
8
[앱 서버]
↓
[쓰기 → Master DB]
[읽기 → Read Replica]
↓
[사용자 수 ↑] → 샤딩 적용
↓
[Shard1, Shard2, Shard3...]
✅ 4. 캐싱 전략 & 메시지 큐
4.1 캐시(Cache) 계층 구조
캐시는 자주 조회되는 데이터를 임시 저장해 빠르게 제공하는 기술이다.
| 계층 | 예시 | 특징 |
|---|---|---|
| 브라우저 캐시 | HTML, JS, 이미지 | 사용자 단 클라이언트 캐시 |
| CDN 캐시 | Cloudflare, Akamai | 전 세계 분산 노드에서 정적 리소스 캐싱 |
| 애플리케이션 캐시 | Redis, Memcached | DB 앞단에서 동적 데이터 캐싱 |
캐시는 성능 최적화와 DB 보호에 필수 요소다.
4.2 Cache Aside 전략 (Lazy Loading)
가장 흔히 쓰이는 캐시 방식.
DB → 캐시 → 클라이언트 순서로 응답을 최적화한다.
동작 흐름
- 캐시에 데이터가 있는지 확인
- 없으면 DB에서 가져오고 → 캐시에 저장
- 클라이언트에게 응답
1
2
3
4
5
6
if cache.hit(key):
return cache.get(key)
else:
data = db.query(key)
cache.set(key, data)
return data
장점: 최신 데이터 보장
단점: 캐시 적중률이 낮을 경우 성능 향상 효과 작음
4.3 Write Through vs Write Back
| 전략 | 설명 | 특징 |
|---|---|---|
| Write Through | 쓰기 요청이 캐시와 DB에 동시에 반영됨 | 데이터 일관성 ↑ |
| Write Back (Write Behind) | 캐시에 먼저 쓰고, 일정 시간 후 DB에 반영 | 성능 ↑, 장애 시 유실 위험 ↑ |
Write Through는 데이터 정합성 우선,
Write Back은 쓰기 많은 시스템에서 성능 극대화
4.4 메시지 큐(Message Queue)
메시지 큐는 요청을 비동기적으로 큐에 저장하고, 소비자가 순차 처리하는 구조다.
작업 처리 지연, 장애 격리, 병렬 처리에 매우 유용하다.
대표 기술
| 메시지 큐 | 특징 |
|---|---|
| Kafka | 대규모 실시간 스트림 처리 |
| RabbitMQ | 신뢰성 높은 메시지 전송 |
| SQS | AWS에서 제공하는 완전 관리형 MQ 서비스 |
구조 예시
1
2
3
[사용자 요청]
↓
[메시지 큐] → [워커 서버] → [DB 반영, 인코딩 등]
예: 주문 요청 → 큐에 저장 → 워커가 나중에 처리 → 사용자에겐 빠른 응답
4.5 Rate Limiting (API 사용량 제어)
과도한 요청을 제한해 서버를 보호하는 전략
로그인 시도, 결제 요청, 봇 공격 방어 등에 필수
구현 방식 예시 (Token Bucket)
- 사용자당 일정량의 토큰 할당
- 요청마다 토큰 1개 소비
- 토큰이 없으면 일정 시간 동안 차단
저장소 예시
| 방법 | 설명 |
|---|---|
| Redis + TTL | 빠르고 가벼운 카운팅 시스템 |
| Nginx + Lua | 트래픽 레벨 제어 |
실시간 속도 조절이 필요한 경우에는 Token Bucket + Redis 조합이 많이 쓰인다
4.6 캐시 무효화 전략
| 방식 | 설명 |
|---|---|
| TTL (Time to Live) | 일정 시간이 지나면 자동 삭제 |
| 수동 삭제 | DB 변경 시 명시적으로 캐시 삭제 |
| LRU / LFU | 오래되거나 적게 쓰인 항목부터 제거 (메모리 부족 시) |
캐시는 무조건 오래 유지한다고 좋은 게 아님 → 정확도 vs 속도 트레이드오프 조절이 핵심
✅ 5. 장애 대응 & 모니터링
5.1 장애 감지와 헬스 체크
시스템은 반드시 장애가 발생한다.
중요한 건 장애를 빨리 감지하고 알람을 주는 것
헬스 체크 종류
| 체크 방식 | 설명 |
|---|---|
| HTTP 헬스 체크 | 정해진 엔드포인트(/health)를 주기적으로 호출 |
| TCP 포트 체크 | 포트 열림 여부 확인 |
| 커스텀 로직 체크 | DB 연결, 캐시 상태, API 응답 속도 등 세부 상태까지 점검 |
예: 클라우드 로드밸런서나 Kubernetes에서 주기적으로 헬스 체크 수행 → 비정상 인스턴스 제외
5.2 장애 복구 전략 (Failover)
자동 복구 흐름
- 헬스 체크 실패 감지
- 장애 서버 자동 제거
- 대체 인스턴스 또는 백업 서버로 전환
| 방식 | 설명 |
|---|---|
| 액티브–패시브 | 메인 서버 죽으면 대기 서버가 즉시 대체 |
| 액티브–액티브 | 모든 서버가 항상 작동 중, 한 서버 죽어도 나머지가 처리 가능 |
| 오토스케일링 | 인프라가 자동으로 확장/축소하며 복구 |
클라우드 환경에서는 Auto Healing + Auto Scaling 구성으로 무중단 복구 가능
5.3 Retry & Circuit Breaker 패턴
Retry
요청 실패 시 일정 시간 후 재시도
단, 지속적인 재시도는 오히려 장애를 악화시킬 수 있음
Circuit Breaker
실패율이 일정 기준 넘으면 회로를 차단(열림)해서
서버 과부하를 예방하고, 일정 시간 후 자동으로 재시도 허용
| 상태 | 설명 |
|---|---|
| Closed | 정상 상태, 요청 통과 |
| Open | 오류 많아 차단 상태 |
| Half-Open | 일부만 허용해 회복 여부 확인 |
Netflix OSS의 Hystrix, Spring Cloud Resilience4J 등이 대표적
5.4 로깅 & 모니터링 시스템
실시간 운영 상태 파악을 위해 모든 서비스의 로그와 지표를 수집해야 한다.
주요 도구
| 기능 | 대표 도구 |
|---|---|
| 로그 수집 | ELK Stack (ElasticSearch, Logstash, Kibana), Fluentd |
| 메트릭 수집 | Prometheus, Grafana |
| 알람 | PagerDuty, Slack 알림, CloudWatch Alarm |
장애 재현 가능성 확보,
비정상 패턴 선제 감지 목적이 핵심이다.
5.5 블루–그린 / 카나리 배포 (무중단 배포 전략)
| 방식 | 설명 |
|---|---|
| 블루–그린 | 기존(Blue)과 새 버전(Green)을 동시에 준비 후 전환 |
| 카나리 배포 | 일부 사용자에게만 새 버전 적용 후 이상 없으면 전체 적용 |
장애 발생 시 즉시 롤백이 가능한 구조가 되어 있어야 한다.
✅ 6. CAP 이론 & 일관성 모델
6.1 CAP 이론이란?
CAP 정리는 분산 시스템에서 동시에 보장할 수 없는 3가지 특성을 말한다.
| 항목 | 설명 |
|---|---|
| C – Consistency | 모든 노드가 같은 데이터를 보여줌 |
| A – Availability | 모든 요청에 대해 응답을 보장 (실패 포함) |
| P – Partition Tolerance | 네트워크 분할(끊김) 상황에서도 시스템이 계속 동작 |
분산 시스템에서는 P는 무조건 고려 대상
따라서 현실적으로는 C vs A 중 하나를 선택해야 한다.
예시
| 시스템 | 선택된 특성 |
|---|---|
| RDB (MySQL) | CP (분할 시 응답 불가하더라도 데이터 정합성 우선) |
| Cassandra, DynamoDB | AP (일관성은 나중에 맞추고, 항상 응답을 보장) |
6.2 BASE 모델
CAP에서 C를 완전히 포기하는 대신,
점진적 일관성을 보장하는 접근
| 구성 | 설명 |
|---|---|
| Basically Available | 항상 응답은 함 (성공이 아닐 수도 있음) |
| Soft state | 상태는 일시적이며, 계속 변할 수 있음 |
| Eventually consistent | 시간이 지나면 결국 일관성 도달 |
BASE는 Eventual Consistency(결국 맞춰짐)를 기반으로 함
→ SNS 타임라인, 쇼핑몰 재고 수량 등에서 활용
6.3 일관성 모델 종류
Strong Consistency
모든 사용자가 항상 최신 데이터를 동시에 조회
RDB, 은행 시스템에서 사용
Eventual Consistency
시간이 지나면 모든 노드가 일관된 상태로 수렴
일부 지연 허용 → NoSQL 계열에서 자주 사용
Causal Consistency
원인–결과 관계를 지키는 선에서만 일관성 보장
예: 댓글 → 게시물보다 먼저 보이면 안 됨
Read-Your-Writes Consistency
내가 작성한 내용은 최소한 나한테는 즉시 보여야 함
6.4 설계 시 고려 포인트
| 조건 | 적합한 일관성 모델 |
|---|---|
| 실시간 금융, 결제 | Strong consistency |
| 대규모 SNS 피드, 쇼핑몰 목록 | Eventual consistency |
| 분산 로그 저장, 메시지 큐 | Causal 또는 Eventual |
| 대규모 API 응답 속도 중시 | BASE 모델 설계 (속도 우선) |
6.5 설계에서 CAP을 활용하는 관점
시스템을 설계할 때는 다 갖추려 하지 말고,
내 서비스에 필요한 우선순위가 뭔지를 정하고 선택해야 함
예:
- 장애 발생 시 무조건 응답이 우선 → Availability 중시 (AP 구조)
- 데이터 정합성이 중요하다면 → Consistency 중시 (CP 구조)
대규모 시스템은 대부분 “AP 기반에 Eventual Consistency로 설계”됨
(속도 우선 + 나중에 정합성 맞추는 구조)
✅ 7. 실시간 시스템 설계
7.1 실시간 시스템이란?
사용자의 입력이나 이벤트에 대해 지연 없이 즉시 반응해야 하는 시스템
대표 사례
- 실시간 채팅 / 메신저
- 실시간 알림(Push Notification)
- 온라인 게임
- 실시간 위치 추적 (택시, 배달 앱)
- 주식 거래, 실시간 스트리밍
7.2 실시간 통신 기술 비교
| 기술 | 특징 | 사용 사례 |
|---|---|---|
| Polling | 일정 간격으로 서버에 요청 | 구현 쉬움, 서버 부하 큼 |
| Long Polling | 서버가 응답 줄 때까지 기다림 | AJAX 알림, Slack |
| SSE (Server-Sent Events) | 서버 → 클라이언트 단방향 통신 | 뉴스, 알림 |
| WebSocket | 양방향 지속 연결 | 채팅, 게임, 실시간 협업 |
WebSocket은 실시간성이 가장 뛰어나며,
클라이언트–서버 간 지속적인 양방향 연결이 가능하다.
7.3 WebSocket 구조
WebSocket은 HTTP로 연결을 시작한 후,
한 번 연결되면 서버와 클라이언트가 자유롭게 메시지를 주고받을 수 있음
1
[클라이언트] ⇄ [WebSocket 서버] ⇄ [Redis Pub/Sub or MQ] ⇄ [DB or 백엔드 로직]
다수의 클라이언트가 동시에 참여하는 경우
메시지를 브로드캐스트하거나 특정 대상에게만 푸시할 수도 있음
7.4 메시지 브로커 활용 (Redis, Kafka 등)
실시간 데이터 전달은 보통 메시지 브로커와 함께 구성
| 브로커 | 설명 |
|---|---|
| Redis Pub/Sub | 간단하고 빠름, 상태 유지 필요 없음 |
| Kafka | 대용량 처리, 메시지 순서 보장 |
| RabbitMQ | 복잡한 라우팅, 안정성 강조 |
예: 채팅 시스템 구조
1
[클라이언트] ⇄ [WebSocket 서버] ⇄ [Redis Pub/Sub] ⇄ [다른 사용자에게 전달]
7.5 확장 설계 고려사항
| 항목 | 설명 |
|---|---|
| 연결 수 | WebSocket은 연결 유지되므로 서버 스펙 고려 필수 |
| 세션 관리 | 상태 저장 필요 시 Redis 등에 세션 저장 |
| 메시지 중복 처리 | 클라이언트가 메시지를 여러 번 받지 않도록 설계 |
| 장애 대응 | 서버 간 메시지 브로드캐스트 동기화 필요 |
7.6 푸시 알림 (Push Notification)
모바일 앱이나 브라우저에서 사용자에게 백그라운드 상태에서도 알림을 전송하는 기능
| 플랫폼 | 기술 |
|---|---|
| Android | FCM (Firebase Cloud Messaging) |
| iOS | APNs (Apple Push Notification Service) |
| Web | Web Push (Service Worker 기반) |
대부분의 푸시 시스템은 알림 메시지를 Queue에 넣고,
백엔드 서버가 외부 Push 플랫폼으로 전송하는 방식으로 구성됨
7.7 실시간 시스템 설계 포인트 요약
- 지속적인 연결 유지 → WebSocket
- 비동기 메시지 처리 → MQ 사용
- 수많은 사용자 처리 → Redis Pub/Sub + Horizontal Scaling
- 모바일 푸시 연동 → 외부 Push API + 토큰 관리 필요
✅ 8. 사례 기반 설계 문제
8.1 URL 단축기 설계 (예: bit.ly)
요구사항
- 긴 URL을 짧은 코드로 압축
- 요청 시 원래 주소로 리디렉션
- 트래픽 많음 (짧은 주소 공유 많음)
- 고유한 코드 생성 (중복 X)
설계 포인트
| 항목 | 설계 |
|---|---|
| 단축키 생성 | 해시(MD5/SHA), Base62 인코딩, 전역 시퀀스 |
| 저장 | Key-Value DB (예: Redis, DynamoDB) |
| 읽기 성능 | 캐싱 필수 (조회가 많음) |
| 확장성 | 코드 충돌 방지 + 수평 확장 가능한 저장소 |
| 보조 기능 | 만료일 설정, 통계 집계, 사용자 계정 연결 등 |
8.2 뉴스피드 / 소셜 피드 설계
요구사항
- 친구/팔로우 기반 타임라인
- 실시간성 + 최신순 정렬
- 좋아요, 댓글, 공유 등 활동 반영
- 피드 추천/정렬 가능
설계 포인트
| 항목 | 설계 |
|---|---|
| 피드 저장 | 유저별 피드 DB (캐싱 + 인덱싱) |
| 데이터 모델 | 팬아웃 방식: 게시글 생성 시 팔로워 피드에 미리 푸시 |
| 실시간 반영 | Redis, Kafka로 이벤트 전파 |
| 정렬 | 최신순, 점수 기반 정렬 |
| 확장 전략 | Read-Heavy → 읽기 복제 + 캐시 계층 강화 |
8.3 대용량 파일 업로드 시스템
요구사항
- 1GB 이상의 파일도 안정적으로 업로드
- 중단 후 재개 가능
- 바이러스 검사 필요
- 업로드 후 처리 (썸네일, 인코딩 등)
설계 포인트
| 항목 | 설계 |
|---|---|
| 업로드 방식 | Multipart Upload + Presigned URL (S3 등) |
| 상태 저장 | Redis로 업로드 진행 상태 관리 |
| 비동기 처리 | 메시지 큐 + 워커로 영상 인코딩, 썸네일 생성 |
| 보안 | 인증된 사용자만 업로드 허용, 파일 검사 필수 |
8.4 동영상 스트리밍 플랫폼 설계
요구사항
- 수백만 유저 대상 스트리밍
- 동시 접속 처리
- 화질별 영상 제공 (Adaptive Streaming)
- 조회수, 추천 반영
설계 포인트
| 항목 | 설계 |
|---|---|
| 업로드 처리 | 영상 업로드 → 인코딩 → 저장 (비동기) |
| 저장소 | Blob Storage (S3, GCS 등) |
| 전송 방식 | HLS, DASH + CDN 캐싱 |
| 사용자 처리 | Redis 세션 관리, 트래픽은 로드밸런서 분산 |
| 데이터 처리 | Kafka로 시청 기록 이벤트 수집 → 추천 모델 학습 |
8.5 사례 설계의 공통 흐름
- 기능 요구사항 + 비기능 요구사항 명확히 분리
- 읽기 vs 쓰기 비율 분석
- 데이터 흐름 정의
- 병목 식별 후: 캐시, 분산 처리, MQ 도입
- 장애 대비 구조 설계 (모니터링, 복제, Retry 등)