확장성 기초
확장성 기초¶
개요¶
이 문서에서는 시스템 확장성(Scalability)의 핵심 개념을 다룹니다. 수직/수평 확장의 차이, Stateless vs Stateful 아키텍처, 그리고 분산 시스템에서 중요한 CAP 정리와 PACELC 이론을 학습합니다.
난이도: ⭐⭐ 예상 학습 시간: 2-3시간 선수 지식: 01_System_Design_Overview.md
목차¶
1. 확장성이란?¶
1.1 정의¶
확장성(Scalability)은 시스템이 증가하는 부하(load)를 처리하기 위해 리소스를 추가할 수 있는 능력입니다.
┌─────────────────────────────────────────────────────────────────┐
│ 확장성이란? │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "시스템이 성장할 수 있는 능력" │
│ │
│ 트래픽 증가 │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │1000│ │10K │ │100K│ │1M │ │10M │ 사용자 수 │
│ └──┬─┘ └──┬─┘ └──┬─┘ └──┬─┘ └──┬─┘ │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ 시스템이 감당할 수 있는가? │ │
│ └────────────────────────────────────────┘ │
│ │
│ 좋은 확장성 = 리소스 추가 시 선형적 성능 향상 │
│ │
└─────────────────────────────────────────────────────────────────┘
1.2 부하(Load)의 측정¶
┌─────────────────────────────────────────────────────────────────┐
│ 부하 측정 지표 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 초당 요청 수 (Requests Per Second) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ • 웹 서버: HTTP 요청/초 │ │
│ │ • 데이터베이스: 쿼리/초 (QPS) │ │
│ │ • API: API 호출/초 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 2. 동시 접속자 수 (Concurrent Users) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ • 동시에 연결된 사용자 수 │ │
│ │ • WebSocket, 스트리밍 서비스에서 중요 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 3. 데이터 크기 (Data Volume) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ • 저장해야 할 데이터 양 │ │
│ │ • 읽기/쓰기 비율 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 4. 복잡도 (Complexity) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ • 요청당 처리 시간 │ │
│ │ • 의존성 수 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2. 수직 확장 vs 수평 확장¶
2.1 수직 확장 (Vertical Scaling / Scale Up)¶
┌─────────────────────────────────────────────────────────────────┐
│ 수직 확장 (Scale Up) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "더 강력한 하드웨어로 업그레이드" │
│ │
│ Before After │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ Server │ │ Server │ │
│ │ ┌──────────┐ │ │ ┌──────────┐ │ │
│ │ │ CPU: 4코어│ │ ──▶ │ │ CPU: 32코어│ │ │
│ │ │ RAM: 16GB │ │ │ │ RAM: 256GB│ │ │
│ │ │ SSD: 500GB│ │ │ │ SSD: 4TB │ │ │
│ │ └──────────┘ │ │ └──────────┘ │ │
│ └────────────────┘ └────────────────┘ │
│ │
│ 장점: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 구현이 단순함 (코드 변경 불필요) │ │
│ │ • 데이터 일관성 유지 용이 │ │
│ │ • 관리가 쉬움 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 단점: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 하드웨어 한계 존재 (무한 확장 불가) │ │
│ │ • 비용이 급격히 증가 (2배 성능 ≠ 2배 비용) │ │
│ │ • 단일 장애점 (SPOF) │ │
│ │ • 업그레이드 시 다운타임 발생 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2.2 수평 확장 (Horizontal Scaling / Scale Out)¶
┌─────────────────────────────────────────────────────────────────┐
│ 수평 확장 (Scale Out) │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "더 많은 서버를 추가" │
│ │
│ Before After │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Server│ │Server│ │Server│ │Server│ │
│ │ 1 │ ──▶ │ 1 │ │ 2 │ │ 3 │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
│ │ │ │ │
│ └─────┼─────┘ │
│ │ │
│ ┌──────────────┐ │
│ │Load Balancer │ │
│ └──────────────┘ │
│ │
│ 장점: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 이론적으로 무한 확장 가능 │ │
│ │ • 비용 효율적 (일반 하드웨어 사용) │ │
│ │ • 고가용성 (한 서버 장애 → 다른 서버가 처리) │ │
│ │ • 무중단 확장 가능 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 단점: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 아키텍처 복잡도 증가 │ │
│ │ • 데이터 일관성 관리 어려움 │ │
│ │ • 세션/상태 관리 필요 │ │
│ │ • 운영/모니터링 복잡 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2.3 비교 요약¶
| 항목 | 수직 확장 | 수평 확장 |
|---|---|---|
| 방법 | 더 강력한 서버 | 더 많은 서버 |
| 확장 한계 | 하드웨어 한계 | 이론적 무한 |
| 비용 | 기하급수적 증가 | 선형적 증가 |
| 복잡도 | 낮음 | 높음 |
| 가용성 | SPOF 위험 | 고가용성 |
| 다운타임 | 업그레이드 시 필요 | 무중단 가능 |
| 적합한 경우 | 초기, 소규모 | 대규모, 분산 |
2.4 실제 적용 예¶
┌─────────────────────────────────────────────────────────────────┐
│ 확장 전략 선택 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 수직 확장이 적합한 경우: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 스타트업 초기 단계 │ │
│ │ • 단일 데이터베이스 (RDB) │ │
│ │ • 상태 관리가 복잡한 레거시 시스템 │ │
│ │ • 비용/시간 제약으로 아키텍처 변경이 어려울 때 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 수평 확장이 적합한 경우: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 대규모 트래픽 처리 │ │
│ │ • Stateless 웹 서버 │ │
│ │ • 마이크로서비스 아키텍처 │ │
│ │ • 클라우드 환경 (Auto Scaling) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 하이브리드 접근: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 웹 서버: 수평 확장 │ │
│ │ • 데이터베이스: 수직 확장 + 복제 │ │
│ │ • 캐시: 수평 확장 (Redis Cluster) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3. Stateless vs Stateful¶
3.1 Stateful 아키텍처¶
┌─────────────────────────────────────────────────────────────────┐
│ Stateful 아키텍처 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "서버가 클라이언트 상태를 저장" │
│ │
│ User A ───▶ Server 1 (세션 A 저장) │
│ User B ───▶ Server 2 (세션 B 저장) │
│ User C ───▶ Server 1 (세션 C 저장) │
│ │
│ 문제 상황: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 1. User A가 Server 2로 라우팅되면? │ │
│ │ │ │
│ │ User A ───▶ Server 2 ──▶ "세션 없음!" (로그아웃) │ │
│ │ │ │
│ │ 2. Server 1이 다운되면? │ │
│ │ │ │
│ │ User A, C ───▶ ??? ──▶ "세션 손실!" (로그아웃) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Sticky Session 필요: │
│ ┌─────────────────┐ │
│ │ Load Balancer │ │
│ │ (Sticky) │ │
│ │ User A → S1 │ │
│ │ User B → S2 │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.2 Stateless 아키텍처¶
┌─────────────────────────────────────────────────────────────────┐
│ Stateless 아키텍처 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ "서버는 상태를 저장하지 않음" │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 모든 상태는 외부 저장소에! │ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ │ Users ───▶ │ Load │ ───▶ ┌───────┐ │ │
│ │ │ Balancer │ │Server1│ │ │
│ │ └─────────────┘ ───▶ │Server2│ │ │
│ │ ───▶│Server3│ │ │
│ │ └───┬───┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌────────────────┐ │ │
│ │ │ Session Store │ │ │
│ │ │ (Redis/DB) │ │ │
│ │ └────────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 장점: │
│ • 어떤 서버로 라우팅되어도 동일하게 처리 │
│ • 서버 추가/제거가 자유로움 │
│ • 서버 장애가 다른 사용자에게 영향 없음 │
│ • Auto Scaling에 적합 │
│ │
└─────────────────────────────────────────────────────────────────┘
3.3 비교¶
| 항목 | Stateful | Stateless |
|---|---|---|
| 상태 저장 | 서버 메모리 | 외부 저장소 |
| 확장성 | 제한적 | 우수 |
| 복잡도 | 낮음 | 외부 저장소 관리 필요 |
| 장애 복구 | 세션 손실 | 빠른 복구 |
| 로드밸런싱 | Sticky Session 필요 | 자유로운 분배 |
| 적합한 경우 | 간단한 시스템 | 대규모 분산 시스템 |
4. 세션 관리 방법¶
4.1 세션 관리 옵션¶
┌─────────────────────────────────────────────────────────────────┐
│ 세션 관리 방법 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Sticky Session (Session Affinity) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ ┌─────────────┐ │ │
│ │ User A ─────────▶│ LB: A→S1 │──────────▶ Server 1 │ │
│ │ (Cookie: S1) │ B→S2 │ │ │
│ │ User B ─────────▶│ C→S1 │──────────▶ Server 2 │ │
│ │ (Cookie: S2) └─────────────┘ │ │
│ │ │ │
│ │ 장점: 구현 단순 │ │
│ │ 단점: 부하 불균형, 서버 장애 시 세션 손실 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 2. Session Replication (세션 복제) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Server 1 │◀───▶│ Server 2 │◀───▶│ Server 3 │ │ │
│ │ │ 세션 A,B,C│ │ 세션 A,B,C│ │ 세션 A,B,C│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ ▲ ▲ ▲ │ │
│ │ └──────────────┴──────────────┘ │ │
│ │ (동기화) │ │
│ │ │ │
│ │ 장점: 장애 복구 용이 │ │
│ │ 단점: 동기화 오버헤드, 확장성 제한 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 3. Centralized Session Store (중앙 집중 저장소) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ │ │
│ │ │ Server 1 │──┐ │ │
│ │ └──────────┘ │ ┌───────────────┐ │ │
│ │ ┌──────────┐ ├─────▶│ Redis/ │ │ │
│ │ │ Server 2 │──┤ │ Memcached │ │ │
│ │ └──────────┘ │ │ (세션 저장) │ │ │
│ │ ┌──────────┐ │ └───────────────┘ │ │
│ │ │ Server 3 │──┘ │ │
│ │ └──────────┘ │ │
│ │ │ │
│ │ 장점: 확장성 우수, Stateless 서버 │ │
│ │ 단점: 추가 인프라 필요, 네트워크 지연 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 4. Client-Side Session (JWT) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Client ────────▶ JWT Token (세션 정보 포함) │ │
│ │ │ │ │
│ │ └──▶ 매 요청 시 토큰 전송 ──▶ 서버가 검증 │ │
│ │ │ │
│ │ 장점: 서버 저장 불필요, 확장성 최고 │ │
│ │ 단점: 토큰 크기 제한, 토큰 무효화 어려움 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.2 세션 관리 방법 비교¶
| 방법 | 확장성 | 복잡도 | 장애 복구 | 추천 상황 |
|---|---|---|---|---|
| Sticky Session | 낮음 | 낮음 | 어려움 | 소규모 |
| Session Replication | 중간 | 높음 | 좋음 | 중규모 |
| Centralized Store | 높음 | 중간 | 좋음 | 대규모 |
| JWT | 최고 | 중간 | N/A | API 서버 |
5. CAP 정리¶
5.1 CAP 정리란?¶
┌─────────────────────────────────────────────────────────────────┐
│ CAP 정리 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 분산 시스템에서 다음 3가지를 동시에 만족할 수 없다: │
│ │
│ Consistency │
│ C │
│ /\ │
│ / \ │
│ / \ │
│ / 동시에 \ │
│ / 3개 불가 \ │
│ /____________\ │
│ A P │
│ Availability Partition │
│ Tolerance │
│ │
│ 네트워크 파티션(P)은 피할 수 없으므로: │
│ 실제로는 C와 A 중 선택해야 함! │
│ │
└─────────────────────────────────────────────────────────────────┘
5.2 각 속성의 의미¶
┌─────────────────────────────────────────────────────────────────┐
│ CAP 속성 상세 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Consistency (일관성) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ "모든 노드가 동일한 데이터를 본다" │ │
│ │ │ │
│ │ Client ──▶ Write X=5 ──▶ Node A │ │
│ │ │ │ │
│ │ (동기화) │ │
│ │ ▼ │ │
│ │ Client ──▶ Read X ───▶ Node B ──▶ X=5 (항상) │ │
│ │ │ │
│ │ 예: 은행 계좌 잔액 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Availability (가용성) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ "모든 요청이 응답을 받는다" (성공/실패 응답) │ │
│ │ │ │
│ │ Client ──▶ Request ──▶ System ──▶ Response (항상) │ │
│ │ │ │
│ │ 장애 상황에서도 응답해야 함 │ │
│ │ 예: 소셜 미디어 피드 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ Partition Tolerance (분할 내성) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ "네트워크 분할에도 시스템이 동작한다" │ │
│ │ │ │
│ │ ┌──────┐ X ┌──────┐ │ │
│ │ │Node A│──────────X──────────│Node B│ │ │
│ │ └──────┘ (네트워크 단절) └──────┘ │ │
│ │ │ │
│ │ 분할된 상태에서도 서비스 지속 │ │
│ │ 분산 시스템에서는 P를 포기할 수 없음! │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5.3 CP vs AP 선택¶
┌─────────────────────────────────────────────────────────────────┐
│ CP vs AP 시스템 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CP (Consistency + Partition Tolerance) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 네트워크 파티션 발생 시: │ │
│ │ • 일관성을 보장하기 위해 일부 노드를 사용 불가로 │ │
│ │ • 가용성 희생 │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 은행 시스템 (잔액 정확성 중요) │ │
│ │ • MongoDB, HBase, Redis (single) │ │
│ │ • Zookeeper, etcd │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ AP (Availability + Partition Tolerance) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 네트워크 파티션 발생 시: │ │
│ │ • 모든 노드가 응답 가능 │ │
│ │ • 일부 데이터가 일시적으로 불일치할 수 있음 │ │
│ │ • Eventual Consistency (최종 일관성) │ │
│ │ │ │
│ │ 예시: │ │
│ │ • 소셜 미디어 (좋아요 수) │ │
│ │ • DNS │ │
│ │ • Cassandra, DynamoDB, CouchDB │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5.4 실제 시스템 분류¶
┌─────────────────────────────────────────────────────────────────┐
│ 시스템별 CAP 분류 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Consistency │
│ ▲ │
│ │ │
│ MongoDB ─────┼───── MySQL │
│ HBase │ PostgreSQL │
│ Redis │ (단일 노드: CA) │
│ Zookeeper │ │
│ etcd │ │
│ │ │
│ │ │
│ ─────────────── ┼ ─────────────────────▶ Availability │
│ │ │
│ │ Cassandra │
│ │ DynamoDB │
│ │ CouchDB │
│ │ Riak │
│ │ │
│ │ │
│ Partition Tolerance │
│ (분산 시스템 필수) │
│ │
└─────────────────────────────────────────────────────────────────┘
6. PACELC 이론¶
6.1 PACELC란?¶
┌─────────────────────────────────────────────────────────────────┐
│ PACELC 이론 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CAP의 확장: 정상 상태에서의 트레이드오프도 고려 │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ IF Partition: │ │
│ │ Choose between Availability and Consistency │ │
│ │ (P → A or C) │ │
│ │ │ │
│ │ ELSE (정상 상태): │ │
│ │ Choose between Latency and Consistency │ │
│ │ (E → L or C) │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ PACELC = (P)artition → (A)vailability vs (C)onsistency │
│ (E)lse → (L)atency vs (C)onsistency │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 네트워크 파티션? │ │
│ │ │ │ │
│ │ ┌───┴───┐ │ │
│ │ │ │ │ │
│ │ Yes No │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ A vs C L vs C │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
6.2 PACELC 시스템 분류¶
┌─────────────────────────────────────────────────────────────────┐
│ PACELC 시스템 분류 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ PA/EL (가용성 + 낮은 지연 선호) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • Cassandra (Quorum 미설정 시) │ │
│ │ • DynamoDB │ │
│ │ 파티션: 가용성 유지, 정상: 빠른 응답 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ PC/EC (일관성 우선) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • MongoDB (default) │ │
│ │ • HBase │ │
│ │ • Zookeeper │ │
│ │ 파티션: 일관성 유지, 정상: 일관성 유지 (지연 감수) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ PA/EC (가용성 + 일관성) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • PNUTS (Yahoo) │ │
│ │ 파티션: 가용성 유지, 정상: 일관성 유지 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ PC/EL (일관성 + 낮은 지연) │ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • Cassandra (Quorum 설정) │ │
│ │ 파티션: 일관성 유지, 정상: 빠른 응답 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
6.3 선택 가이드¶
| 요구사항 | 추천 | 예시 시스템 |
|---|---|---|
| 데이터 정확성 중요 | PC/EC | 금융, 재고 관리 |
| 빠른 응답 중요 | PA/EL | 소셜 미디어, 게임 |
| 균형 | PA/EC 또는 PC/EL | 일반 웹 서비스 |
7. 연습 문제¶
문제 1: 확장 방식 선택¶
다음 시나리오에 적합한 확장 방식을 선택하세요.
a) 초기 스타트업, 일일 사용자 1,000명 b) 대규모 이커머스, 블랙프라이데이 10배 트래픽 c) 복잡한 분석 쿼리를 처리하는 데이터베이스 d) CDN 엣지 서버
문제 2: Stateless 설계¶
쇼핑몰의 장바구니 기능을 Stateless로 설계하세요. 세션을 어디에 저장할 것인지, 왜 그 방식을 선택했는지 설명하세요.
문제 3: CAP 선택¶
다음 서비스에서 CP와 AP 중 무엇을 선택해야 할까요? 이유를 설명하세요.
a) 은행 송금 시스템 b) 페이스북 좋아요 수 c) 온라인 예약 시스템 d) DNS 서버
문제 4: PACELC 분석¶
당신이 설계하는 시스템이 다음 요구사항을 가질 때, PACELC 중 어떤 조합을 선택하시겠습니까?
조건: - 글로벌 서비스 (여러 리전) - 읽기 지연 < 100ms 필수 - 데이터 손실 불가
정답¶
문제 1 정답¶
a) 수직 확장 - 소규모이므로 단순한 접근이 효율적 b) 수평 확장 - Auto Scaling으로 탄력적 대응 c) 수직 확장 - 분석 쿼리는 단일 노드에서 효율적 d) 수평 확장 - 지리적 분산이 필요
문제 2 정답¶
추천: Redis (Centralized Session Store)
이유:
1. Stateless 웹 서버 - 어느 서버로 요청이 가도 동일 처리
2. 빠른 읽기/쓰기 - 장바구니 조회/수정 빈번
3. TTL 지원 - 장바구니 자동 만료
4. 장애 시 복구 용이 - Redis Sentinel/Cluster
대안:
- JWT: 장바구니 크기 제한, 업데이트마다 새 토큰 필요
- DB: 가능하나 Redis보다 느림
문제 3 정답¶
a) CP - 잔액 정확성이 가용성보다 중요 b) AP - 좋아요 수가 잠시 다르더라도 서비스는 계속되어야 함 c) CP - 이중 예약 방지 중요 (강력한 일관성) d) AP - 오래된 정보라도 응답하는 것이 중요
문제 4 정답¶
추천: PC/EL 또는 PA/EC
분석:
- 글로벌 서비스 → P 필수
- 읽기 지연 < 100ms → L (낮은 지연) 중요
- 데이터 손실 불가 → C (일관성) 중요
PC/EL 선택 시:
- 파티션: 일관성 유지 (일부 요청 실패 가능)
- 정상: 빠른 읽기
PA/EC 선택 시:
- 파티션: 가용성 유지 + 나중에 동기화
- 정상: 강력한 일관성
실제 구현:
- 읽기: 로컬 복제본 (L)
- 쓰기: 동기 복제 (C)
- Cassandra + LOCAL_QUORUM
8. 다음 단계¶
확장성 기초를 이해했다면, 네트워크 관련 시스템 설계 요소를 학습하세요.
다음 레슨¶
- 03_Network_Fundamentals_Review.md - DNS, CDN, HTTP/2/3
관련 레슨¶
- 04_Load_Balancing.md - 수평 확장의 핵심
- 07_Distributed_Cache_Systems.md - 세션 저장소
추천 실습¶
- 로컬에서 여러 서버 인스턴스 실행해보기
- Redis를 세션 저장소로 설정해보기
- 자신이 사용하는 서비스가 CP인지 AP인지 분석해보기
9. 참고 자료¶
도서¶
- Designing Data-Intensive Applications - Martin Kleppmann (Chapter 5, 9)
논문¶
- "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services" (2002)
- "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC)
온라인 자료¶
문서 정보 - 최종 수정: 2024년 - 난이도: ⭐⭐ - 예상 학습 시간: 2-3시간