diff --git "a/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/00_\354\235\270\353\215\261\354\212\244.md" "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/00_\354\235\270\353\215\261\354\212\244.md" new file mode 100644 index 0000000..b841a00 --- /dev/null +++ "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/00_\354\235\270\353\215\261\354\212\244.md" @@ -0,0 +1,90 @@ +# 안정 해시 설계 — STEP별 정리 노트 + +> 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 5장 학습 노트 +> 설계를 시작하기 전에 알아야 할 개념을 STEP 순서대로 정리한다. + +--- + +## 이 노트의 목적 + +안정 해시(consistent hashing)는 **"요청·데이터를 여러 서버에 고르게 나눈다"** 는 +한 줄짜리 목표를 위한 기술이다. 하지만 이 목표를 **서버가 수시로 늘고 줄어드는(수평 확장)** +환경에서도 지키려는 순간, 단순한 해시로는 무너진다. + +각 STEP은 *기능 추가*가 아니라 **"앞 단계가 만든 문제를 푸는 다음 결정"** 이다. + +> 📌 이 장은 6장(키-값 저장소)의 데이터 분산에서도 그대로 쓰인다. +> 6장 노트 [STEP2 — 데이터 분산](../../06-키값저장소설계/정리노트/02_STEP2_데이터분산_안정해시.md) 과 함께 보면 좋다. + +--- + +## 왜 "hash % N" 으로 끝나지 않는가 + +N개의 서버에 부하를 나누는 가장 단순한 방법은 나머지 연산이다. + +``` +serverIndex = hash(key) % N (N = 서버 개수) +``` + +서버 수가 **고정**이고 데이터가 균등하면 이걸로 충분하다. +문제는 이 구조가 **서버가 늘거나 줄면 곧바로 무너진다**는 점이다. + +| 벽 | 무엇이 막히나 | 결과 | +| --- | --- | --- | +| **재배치 폭발** | 서버 1대만 죽어도 `% N`의 N이 바뀌어 **거의 모든 키**의 서버 인덱스가 달라짐 | 대규모 캐시 미스 → 시스템 마비 | +| **파티션 불균등** | 서버를 링에 그냥 올리면 담당 해시 공간 크기가 제각각 | 특정 서버 과부하 | +| **키 쏠림(hotspot)** | 키가 특정 서버에 몰림 | 부하 불균형·확장 무의미 | + +> 그래서 **왜 단순 해시가 안 되는가(STEP1) → 해시 링으로 어떻게 푸는가(STEP2) → 균등 분포를 어떻게 보장하는가(STEP3, 가상 노드)** 라는 결정이 이어진다. + +--- + +## 설계 로드맵 + +```mermaid +flowchart TD + R[목표: 데이터를 서버에 고르게 + 확장에 강하게] --> S1[STEP1 rehash 문제
단순 hash %% N의 한계] + S1 --> P1[서버가 늘고 줄어도
재배치를 최소화하려면?] + P1 --> S2[STEP2 안정 해시 원리
해시 링·시계방향 조회] + S2 --> P2[근데 파티션·키가
고르게 안 나뉜다면?] + P2 --> S3[STEP3 가상 노드
균등 분포·재배치 범위] +``` + +--- + +## STEP 목록 + +| STEP | 주제 | 핵심 키워드 | 푸는 문제 | +|:---:|------|-----------|----------| +| [STEP 1](01_STEP1_rehash문제_단순해시의한계.md) | 재배치(rehash) 문제 | `hash % N`, 경계 재계산, 캐시 미스 | 단순 해시는 왜 확장에 실패하나 | +| [STEP 2](02_STEP2_안정해시_원리_해시링.md) | 안정 해시 원리 | 해시 공간·해시 링, 시계방향 조회, k/n | 서버가 변해도 이동을 어떻게 최소화하나 | +| [STEP 3](03_STEP3_가상노드_균등분포.md) | 가상 노드 · 균등 분포 | 파티션/키 불균등, virtual node, 표준편차, 재배치 범위 | 데이터를 어떻게 고르게 나누나 | +| [흐름 통합](04_흐름통합_데이터분산부터_벡터시계.md) | 분산 저장 → 벡터 시계 | 복제 N, 정족수 W·R, 벡터 시계 | 5장 파티션이 6장 데이터 흐름으로 어떻게 확장되나 | + +### 각 STEP에서 깊게 다루는 것 + +| STEP | 세부 내용 | +| --- | --- | +| STEP 1 | `hash % N` 동작, 서버 4→3 변동 시 **표 5-1/5-2 재계산 실측**, 왜 캐시 미스 폭풍이 나는지, "안정 해시" 정의(k/n) | +| STEP 2 | SHA-1 해시 공간(0 ~ 2¹⁶⁰-1) → 해시 링, 서버·키를 **modulo 없이** 링에 매핑, 시계방향 최초 서버 조회, 서버 **추가/삭제 시 영향 범위** | +| STEP 3 | 기본 구현의 두 문제(파티션·키 불균등), **가상 노드(replica)**, 가상 노드 수 ↔ 표준편차 트레이드오프, 재배치할 키의 범위 결정, 실사용처 | + +--- + +## 학습 우선순위 + +1. **핵심**: STEP 2(해시 링 원리)와 STEP 3(가상 노드). 이 장의 본체이자 면접 단골. +2. **먼저 잡을 것**: STEP 1의 `hash % N` 재배치 문제 — "왜 안정 해시가 필요한가"의 근거. +3. **말로 설명 가능해야**: 서버 추가/삭제 시 **k/n 개만 이동**한다는 것, 가상 노드가 푸는 **두 문제**. +4. 레퍼런스 시스템(모두 안정 해시 채택): + - **아마존 다이나모(DynamoDB)**, **아파치 카산드라** — 데이터 파티셔닝 + - **디스코드(Discord)** — 대규모 동시 접속 채팅 + - **아카마이(Akamai) CDN**, **매그레브(Maglev)** — 부하 분산 + +--- + +## 빠른 복습 — 3문장 요약 + +> 단순 `hash % N`은 서버가 하나만 변해도 **거의 모든 키를 재배치**해 확장이 불가능하다(STEP1). +> 서버와 키를 **같은 해시 링**에 올리고 시계방향 첫 서버에 저장하면, 서버 변동 시 **인접 구간(k/n)만** 이동한다(STEP2). +> 남은 불균등(파티션·키 쏠림)은 서버 하나를 링의 **여러 지점(가상 노드)** 에 올려 해소한다(STEP3). diff --git "a/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/01_STEP1_rehash\353\254\270\354\240\234_\353\213\250\354\210\234\355\225\264\354\213\234\354\235\230\355\225\234\352\263\204.md" "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/01_STEP1_rehash\353\254\270\354\240\234_\353\213\250\354\210\234\355\225\264\354\213\234\354\235\230\355\225\234\352\263\204.md" new file mode 100644 index 0000000..0517769 --- /dev/null +++ "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/01_STEP1_rehash\353\254\270\354\240\234_\353\213\250\354\210\234\355\225\264\354\213\234\354\235\230\355\225\234\352\263\204.md" @@ -0,0 +1,118 @@ +# STEP 1. 재배치(rehash) 문제 — 단순 해시는 왜 확장에 실패하나 + +> 안정 해시가 **왜 필요한지**를 만드는 출발점. +> `hash(key) % N` 은 서버 수가 고정일 땐 완벽하지만, 서버가 하나만 변해도 **거의 모든 키가 이동**한다. + +--- + +## 0. 먼저: 우리가 풀려는 것 + +수평 확장(horizontal scaling)의 핵심은 **요청·데이터를 여러 서버에 고르게 나누는 것**이다. +그래서 필요한 건 딱 하나 — "이 키는 어느 서버가 담당하는가?"를 정하는 규칙(**키 → 서버 매핑**). + +가장 흔한 규칙이 나머지 연산이다. + +``` +serverIndex = hash(key) % N (N = 서버 개수) +``` + +- 키를 해시해서 큰 정수로 만들고, 서버 수 N으로 나눈 **나머지**를 서버 번호로 쓴다. +- 서버가 4대면 모든 키는 0~3 중 하나에 결정적으로 매핑된다. + +> 핵심: 이 방식은 **N이 절대 안 변할 때만** 안전하다. + +--- + +## 1. 단순 해시가 잘 도는 경우 (N=4) + +키 8개를 4대 서버에 `hash % 4` 로 나눈 예시(원문 표 5-1). + +| 키 | 해시 | 해시 % 4 (서버 인덱스) | +| ---- | -------- | :-------------------: | +| key0 | 18358617 | 1 | +| key1 | 26143584 | 0 | +| key2 | 18131146 | 2 | +| key3 | 35863496 | 0 | +| key4 | 34085809 | 1 | +| key5 | 27581703 | 3 | +| key6 | 38164978 | 2 | +| key7 | 22530351 | 3 | + +``` +서버0: key1, key3 서버1: key0, key4 +서버2: key2, key6 서버3: key5, key7 +``` + +> 서버 풀 크기가 **고정**이고 데이터 분포가 균등하면 이걸로 충분히 잘 동작한다. + +--- + +## 2. ⚠️ 서버 하나가 죽으면 — 재배치 폭발 + +서버 1번이 장애로 빠져 **N이 4 → 3** 으로 바뀌면, 해시 값은 그대로여도 **나누는 수가 바뀌어** 서버 인덱스가 재계산된다(원문 표 5-2, `hash % 3`). + +| 키 | 해시 | %4 (이전) | %3 (이후) | 이동? | +| ---- | -------- | :-------: | :-------: | :---: | +| key0 | 18358617 | 1 | **0** | ✅ | +| key1 | 26143584 | 0 | 0 | — | +| key2 | 18131146 | 2 | **1** | ✅ | +| key3 | 35863496 | 0 | **2** | ✅ | +| key4 | 34085809 | 1 | 1 | — | +| key5 | 27581703 | 3 | **0** | ✅ | +| key6 | 38164978 | 2 | **1** | ✅ | +| key7 | 22530351 | 3 | **0** | ✅ | + +**8개 중 6개**의 위치가 바뀌었다. 죽은 서버(1번)에 있던 키뿐 아니라 **멀쩡한 서버의 키까지** 대부분 재배치된다. + +```mermaid +flowchart LR + A["서버 1대 장애
(N: 4 → 3)"] --> B["나누는 수 변경
hash %% 4 → hash %% 3"] + B --> C["거의 모든 키의
서버 인덱스 재계산"] + C --> D["대부분 클라이언트가
데이터 없는 엉뚱한 서버 접속"] + D --> E["대규모 캐시 미스 폭풍
→ 시스템 마비"] +``` + +> 핵심: `% N` 은 **N에 전역적으로 의존**하기 때문에, N이 1만 변해도 매핑 전체가 흔들린다. + +--- + +## 3. 그래서 필요한 성질 — "안정" 해시 + +원하는 것은 **서버가 변해도 최소한의 키만 움직이는** 매핑이다. 위키피디아의 정의: + +> 안정 해시는 해시 테이블 크기가 조정될 때 평균적으로 **오직 k/n 개의 키만 재배치**하는 해시 기술이다. +> (k = 키의 개수, n = 슬롯(서버)의 개수) + +| | 단순 해시 (`% N`) | 안정 해시 | +| --- | --- | --- | +| 서버 변동 시 이동량 | **거의 전부** (≈ k) | 평균 **k/n** | +| N에 대한 의존 | 전역 의존 | 국소적(인접 구간만) | +| 확장성 | ❌ 사실상 불가 | ✅ 무중단 확장 | + +> 즉, 전통적 해시 테이블은 슬롯 수가 바뀌면 대부분 키를 옮기지만, 안정 해시는 **평균 k/n 개만** 옮긴다. +> "어떻게 그게 가능한가"가 STEP 2다. + +--- + +## ✅ STEP 1 체크리스트 + +- [ ] `serverIndex = hash(key) % N` 이 무엇을 하는지 한 줄로 설명할 수 있다 +- [ ] 단순 해시가 **언제** 잘 동작하는지(고정 N·균등 분포) 안다 +- [ ] 서버 4→3 변동 시 **왜 대부분 키가 이동**하는지 표로 설명할 수 있다 +- [ ] 재배치가 왜 "대규모 캐시 미스"로 이어지는지 안다 +- [ ] 안정 해시의 정의(**평균 k/n 개만 이동**)를 말할 수 있다 + +--- + +## 💬 예상 면접 질문 + +**Q1. `hash(key) % N` 방식의 문제는 무엇인가?** +> 서버 수 N이 바뀌면(추가/장애) 나누는 수가 달라져 **거의 모든 키의 서버 인덱스가 재계산**된다. 대부분의 클라이언트가 데이터 없는 서버로 접속해 대규모 캐시 미스가 발생하고, 사실상 확장이 불가능하다. + +**Q2. 왜 죽지 않은 서버의 키까지 이동하나?** +> `% N`은 **N에 전역적으로 의존**한다. N이 4→3으로 바뀌면 나머지 값 자체가 달라지므로, 장애 서버와 무관한 키도 새 서버 인덱스로 재계산된다. 예시(표 5-1→5-2)에선 8개 중 6개가 이동한다. + +**Q3. "안정 해시"의 정의를 말해달라.** +> 해시 테이블(서버) 크기가 조정될 때 **평균적으로 k/n 개의 키만 재배치**하는 해시 기술이다(k=키 수, n=서버 수). 전통적 해시가 슬롯 변경 시 거의 전부를 옮기는 것과 대비된다. + +➡️ 다음: [STEP 2 — 안정 해시 원리(해시 링)](02_STEP2_안정해시_원리_해시링.md) diff --git "a/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/02_STEP2_\354\225\210\354\240\225\355\225\264\354\213\234_\354\233\220\353\246\254_\355\225\264\354\213\234\353\247\201.md" "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/02_STEP2_\354\225\210\354\240\225\355\225\264\354\213\234_\354\233\220\353\246\254_\355\225\264\354\213\234\353\247\201.md" new file mode 100644 index 0000000..eed1bd7 --- /dev/null +++ "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/02_STEP2_\354\225\210\354\240\225\355\225\264\354\213\234_\354\233\220\353\246\254_\355\225\264\354\213\234\353\247\201.md" @@ -0,0 +1,138 @@ +# STEP 2. 안정 해시 원리 — 해시 링으로 어떻게 이동을 최소화하나 + +> STEP1의 답: 서버 수 N에 의존하는 `% N`을 버리고, **서버와 키를 같은 원(해시 링)** 위에 올린다. +> 그러면 서버가 변해도 **인접 구간의 키(평균 k/n)만** 이동한다. + +--- + +## 0. 먼저: 핵심 전환 — "나눗셈"에서 "링 위의 위치"로 + +단순 해시는 `hash(key) % N` 처럼 **N으로 나눈다**. 그래서 N이 흔들리면 전부 흔들렸다. +안정 해시는 나머지 연산을 **쓰지 않는다.** 대신 서버도 키도 링 위의 **한 점**으로 보고, +"이 키에서 가장 가까운(시계방향) 서버는 누구인가"라는 **국소적 질문**으로 바꾼다. + +> 핵심: 매핑을 **전역(N에 의존)** 에서 **국소(이웃 서버에만 의존)** 로 바꾼 것이 안정 해시의 전부다. + +--- + +## 1. 해시 공간과 해시 링 + +- 해시 함수 f로 **SHA-1**을 쓴다고 하자. 출력 범위(해시 공간)는 **0 ~ 2¹⁶⁰ - 1**. +- 이 일직선 공간의 **양 끝(0과 2¹⁶⁰-1)을 구부려 맞붙이면** 원형의 **해시 링(hash ring)** 이 된다. + +```mermaid +flowchart LR + L["일직선 해시 공간
x0=0 ················ xn=2¹⁶⁰-1"] -->|양 끝을 접는다| R["원형 해시 링
(xn과 x0가 한 점에서 만남)"] +``` + +> 링에는 시작도 끝도 없다. 시계방향으로 돌면 값이 커지다가 최대값 다음 0으로 돌아온다. + +--- + +## 2. 서버와 키를 링에 올린다 (modulo 없음) + +- **서버**: 서버의 IP나 이름을 해시 f에 넣어 나온 값 → 링 위의 위치. (예: 서버 0~3 → s0, s1, s2, s3) +- **키**: 같은 방식으로 키도 링 위의 한 점. (예: key0~3 → k0, k1, k2, k3) + +> ⚠️ 여기 쓰는 해시 함수는 STEP1의 함수와 **다르며, 나머지 연산 %를 쓰지 않는다.** 서버와 키를 같은 링 위에 "그냥 뿌린다". + +--- + +## 3. 서버 조회 — 시계방향 최초 서버 규칙 + +키가 저장되는 서버는, **그 키의 위치에서 시계방향으로 링을 돌다 처음 만나는 서버**다. + +```mermaid +flowchart LR + K["키 위치"] -->|시계방향 탐색| S["처음 만난 서버 = 담당 서버"] +``` + +원문 그림 5-7 예시(서버 s0~s3, 키 k0~k3가 번갈아 배치): + +| 키 | 시계방향 첫 서버 | 저장 위치 | +| --- | --- | --- | +| key0 | s0 | 서버 0 | +| key1 | s1 | 서버 1 | +| key2 | s2 | 서버 2 | +| key3 | s3 | 서버 3 | + +> 핵심: 담당 서버를 찾는 데 **N이 등장하지 않는다.** "내 위치에서 시계방향 이웃"만 보면 된다. + +--- + +## 4. 서버 추가 — 영향받는 키는 국소적 + +새 서버를 링에 올리면, **그 서버와 반시계 방향 직전 서버 사이 구간의 키만** 새 서버로 이동한다. 나머지는 그대로. + +원문 그림 5-8: 서버 4(s4)가 **s0과 k0 사이**에 추가되는 경우. + +```mermaid +flowchart LR + B["추가 전
key0 → 시계방향 첫 서버 s0"] --> A["추가 후
key0 → 이제 s4가 먼저 만남
→ key0만 s4로 이동"] + A --> N["k1, k2, k3은 담당 서버 그대로"] +``` + +- 추가 전 key0은 서버 0에 있었지만, s4가 k0 바로 뒤(시계방향)에 끼어들면서 **key0만** s4로 재배치. +- 다른 키들은 자기 시계방향 첫 서버가 그대로라 **이동 없음**. + +--- + +## 5. 서버 제거 — 역시 국소적 + +서버 하나가 빠지면, **그 서버가 담당하던 구간의 키만** 시계방향 다음 서버로 넘어간다. + +원문 그림 5-9: 서버 1(s1)이 삭제되는 경우. + +- s1이 담당하던 key1만 시계방향 다음 서버인 **서버 2로 재배치**. +- 나머지 키(key0, key2, key3)는 영향 없음. + +```mermaid +flowchart LR + D["서버 1(s1) 삭제"] --> M["s1 담당 구간의 key1만
시계방향 다음 서버 s2로 이동"] + M --> U["k0, k2, k3은 그대로"] +``` + +> 핵심: 추가든 삭제든 **바뀌는 건 인접한 한 구간뿐.** 평균 이동량이 **k/n** 인 이유가 여기 있다. + +--- + +## 6. 단순 해시 vs 안정 해시 — 서버 변동 대응 + +| 상황 | 단순 해시 (`% N`) | 안정 해시 (해시 링) | +| --- | --- | --- | +| 서버 추가 | 거의 모든 키 재계산 | 새 서버~직전 서버 **구간의 키만** | +| 서버 삭제 | 거의 모든 키 재계산 | 삭제 서버 담당 **구간의 키만** | +| 평균 이동량 | ≈ k (전부) | **k/n** | +| 담당 서버 계산 | N에 의존 | 링 위 시계방향 이웃 | + +> 이것만으로 "서버가 변할 때 이동 최소화" 요구는 해결됐다. +> 하지만 아직 **"고르게 나뉜다"** 는 보장은 없다 — 그게 STEP 3. + +--- + +## ✅ STEP 2 체크리스트 + +- [ ] 해시 공간(0 ~ 2¹⁶⁰-1)을 링으로 만드는 과정을 설명할 수 있다 +- [ ] 안정 해시는 **나머지 연산 %를 쓰지 않는다**는 점을 안다 +- [ ] 키의 담당 서버를 찾는 규칙(**시계방향 최초 서버**)을 말할 수 있다 +- [ ] 서버 추가 시 **key0만 이동**하는 그림 5-8을 설명할 수 있다 +- [ ] 서버 삭제 시 **key1만 이동**하는 그림 5-9를 설명할 수 있다 +- [ ] 평균 이동량이 **k/n** 인 이유(인접 구간만 변함)를 안다 + +--- + +## 💬 예상 면접 질문 + +**Q1. 안정 해시는 키가 저장될 서버를 어떻게 정하나?** +> 서버와 키를 같은 **해시 링** 위에 매핑하고, 키 위치에서 **시계방향으로 돌다 처음 만나는 서버**에 저장한다. 나머지 연산 없이 링 위의 이웃 관계만 본다. + +**Q2. 단순 해시와 달리 왜 재배치가 적은가?** +> 담당 서버가 **N이 아니라 링 위 인접 이웃**에만 의존하기 때문이다. 서버를 추가/삭제해도 변하는 건 그 서버에 인접한 한 구간뿐이라, 평균 **k/n 개**만 이동한다. + +**Q3. 서버를 추가할 때 정확히 어떤 키가 이동하나?** +> 새 서버 위치에서 **반시계 방향으로 직전 서버까지의 구간**에 있던 키들만 새 서버로 넘어간다. 그림 5-8에선 s4가 s0 앞에 끼면서 그 구간의 key0만 이동하고 나머지는 그대로다. + +**Q4. 여기서 SHA-1을 쓰는 이유와 해시 공간 크기는?** +> 출력이 **0 ~ 2¹⁶⁰-1** 로 매우 넓어 서버·키를 링 위에 충돌 없이 고르게 흩뿌리기 좋다. 이 공간의 양 끝을 이어 원형 링으로 사용한다. + +➡️ 이전: [STEP 1 — rehash 문제](01_STEP1_rehash문제_단순해시의한계.md) | 다음: [STEP 3 — 가상 노드](03_STEP3_가상노드_균등분포.md) diff --git "a/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/03_STEP3_\352\260\200\354\203\201\353\205\270\353\223\234_\352\267\240\353\223\261\353\266\204\355\217\254.md" "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/03_STEP3_\352\260\200\354\203\201\353\205\270\353\223\234_\352\267\240\353\223\261\353\266\204\355\217\254.md" new file mode 100644 index 0000000..51658eb --- /dev/null +++ "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/03_STEP3_\352\260\200\354\203\201\353\205\270\353\223\234_\352\267\240\353\223\261\353\266\204\355\217\254.md" @@ -0,0 +1,157 @@ +# STEP 3. 가상 노드 · 균등 분포 — 데이터를 어떻게 고르게 나누나 + +> STEP2의 해시 링은 "이동 최소화"는 풀었지만 **"고르게 나뉜다"** 는 보장이 없다. +> 기본 구현엔 두 가지 불균등 문제가 있고, 이를 **가상 노드(virtual node)** 로 해결한다. + +--- + +## 0. 먼저: 기본 안정 해시의 절차와 그 한계 + +기본 안정 해시(MIT에서 처음 제안)의 절차는 단순하다. + +1. 서버와 키를 균등 분포 해시 함수로 링에 배치한다. +2. 키에서 시계방향으로 탐색해 만나는 최초의 서버가 담당 서버다. + +문제는 이 "링에 그냥 올린다"가 **고른 분포를 보장하지 않는다**는 점이다. + +--- + +## 1. 기본 구현의 두 가지 문제 + +| # | 문제 | 무엇이 잘못되나 | 결과 | +| :-: | --- | --- | --- | +| 1 | **파티션 크기 불균등** | 인접 서버 사이 해시 공간(=파티션)이 제각각. 서버 삭제 시 특히 심해짐 | 어떤 서버는 아주 좁은 구간, 어떤 서버는 아주 넓은 구간 담당 | +| 2 | **키 분포 불균등** | 서버들이 링 한쪽에 몰리면 키도 한 서버에 쏠림 | 특정 서버 과부하(hotspot), 어떤 서버는 데이터 0 | + +> **파티션(partition)** = 링에서 인접한 두 서버 사이의 해시 공간 = 한 서버가 담당하는 구간. + +### 문제 1 — 삭제로 파티션이 2배가 되는 예 (그림 5-10) + +s1이 삭제되면 s1이 담당하던 구간이 시계방향 다음 서버 s2에 흡수되어, **s2의 파티션이 다른 서버 대비 약 2배**로 커진다. + +```mermaid +flowchart LR + B["삭제 전
s1, s2가 비슷한 크기 담당"] --> A["s1 삭제 후
s2가 s1 구간까지 흡수
→ s2 파티션 ≈ 2배"] +``` + +### 문제 2 — 키가 한 서버에 쏠리는 예 (그림 5-11) + +서버들이 링의 한쪽에 몰려 배치되면, 서버 1·3은 데이터가 거의 없고 **대부분의 키가 서버 2에 보관**된다. + +> 핵심: 서버 "1개 = 링 위 점 1개" 라면, 그 점들이 우연히 몰릴 때 분포가 무너진다. + +--- + +## 2. 해결: 가상 노드 (Virtual Node / Replica) + +**아이디어**: 서버 하나를 링 위 **한 점이 아니라 여러 점**으로 올린다. + +- 서버 0을 배치할 때 s0 하나 대신 **s0_0, s0_1, s0_2** 처럼 여러 가상 노드를 쓴다. +- 서버 1도 s1_0, s1_1, s1_2 … (원문 예시는 서버당 3개지만, 실제로는 훨씬 큰 값). +- 따라서 각 서버는 **하나가 아닌 여러 개의 파티션**을 담당한다. + +```mermaid +flowchart TB + subgraph ring["가상 노드로 흩뿌린 링"] + direction LR + a((s0_0)) --- b((s1_0)) --- c((s0_1)) --- d((s1_1)) --- e((s0_2)) --- f((s1_2)) + end +``` + +- 키 조회 규칙은 동일: 키에서 시계방향으로 만나는 **최초의 가상 노드**가 나타내는 실제 서버가 담당. +- 예(그림 5-13): k0에서 시계방향 첫 가상 노드가 **s1_1** → 실제로는 **서버 1**에 저장. + +> 한 서버가 링 곳곳에 여러 점으로 흩어지니, 담당 구간이 링 전체에 골고루 퍼져 **몰림·불균등이 완화**된다. + +--- + +## 3. 가상 노드 수 ↔ 균등도 (트레이드오프) + +가상 노드를 늘릴수록 키 분포가 고르게 되고 **표준 편차(standard deviation)** 가 작아진다. +(표준 편차 = 데이터가 얼마나 퍼져 있는지의 척도 → 작을수록 고르게 분포) + +| 가상 노드 수 (서버당) | 표준 편차 (평균 대비) | +| :-: | :-: | +| 100개 | 약 **10%** | +| 200개 | 약 **5%** | +| 더 늘리면 | 더 작아짐 | + +- ✅ 가상 노드가 많을수록 분포가 균등해진다. +- ❌ 대신 가상 노드 위치 데이터를 저장할 **공간이 더 필요**하다. +- ➡️ **타협(tradeoff)** 이 필요 — 시스템 요구사항에 맞게 적절히 조정한다. + +> 🏢 부수 효과: 성능 좋은 **이기종 서버**엔 가상 노드를 더 많이 할당해 부하 비중을 키울 수도 있다. + +--- + +## 4. 재배치할 키의 범위 결정 + +서버가 추가/삭제되면 **어느 범위의 키만** 옮기면 되는지가 명확하다. + +| 이벤트 | 재배치 대상 범위 | 원문 | +| --- | --- | --- | +| **서버 추가** | 새 노드(s4)부터 **반시계 방향 첫 서버(s3)까지** 구간의 키 → 새 노드로 | 그림 5-14 | +| **서버 삭제** | 삭제 노드(s1)부터 **반시계 방향 첫 서버(s0)까지** 구간의 키 → 시계방향 다음 서버(s2)로 | 그림 5-15 | + +```mermaid +flowchart LR + ADD["서버 s4 추가"] --> R1["s3 ~ s4 구간 키를 s4로 이동"] + DEL["서버 s1 삭제"] --> R2["s0 ~ s1 구간 키를 s2로 이동"] +``` + +> 핵심: 재배치는 항상 **인접한 한 구간**에 국한된다 → 평균 k/n. + +--- + +## 5. 안정 해시의 이점 정리 (마치며) + +| 이점 | 설명 | +| --- | --- | +| **재배치 최소화** | 서버 추가/삭제 시 이동하는 키 수가 **최소화**(평균 k/n) | +| **수평 확장 용이** | 데이터가 고르게 분포 → 서버 증설로 규모 확장 쉬움 | +| **핫스팟(hotspot) 완화** | 특정 샤드에 몰리는 유명인 데이터(케이티 페리·저스틴 비버 등) 예시처럼, 데이터를 고르게 분배해 과부하 가능성을 줄임 | + +### 🏢 실제 사용처 + +- **아마존 다이나모(DynamoDB)** — 파티셔닝 컴포넌트 +- **아파치 카산드라(Apache Cassandra)** — 클러스터 데이터 파티셔닝 +- **디스코드(Discord)** — 채팅 애플리케이션 +- **아카마이(Akamai) CDN** +- **매그레브(Maglev)** — 네트워크 부하 분산기 + +> ⚠️ 주의: 안정 해시 + 가상 노드는 핫스팟을 **완화**할 뿐 완전히 없애지는 못한다. 극단적으로 한 키에 트래픽이 몰리면 별도 대책(캐싱·복제 등)이 필요하다. + +--- + +## ✅ STEP 3 체크리스트 + +- [ ] 기본 안정 해시의 두 문제(파티션 불균등·키 불균등)를 설명할 수 있다 +- [ ] 서버 삭제 시 파티션이 2배가 되는 상황(그림 5-10)을 안다 +- [ ] 가상 노드가 무엇이고 왜 분포를 고르게 하는지 말할 수 있다 +- [ ] 가상 노드 수와 표준 편차의 관계(많을수록 ↓, 100→10%·200→5%)를 안다 +- [ ] 가상 노드의 트레이드오프(균등도 ↔ 저장 공간)를 설명할 수 있다 +- [ ] 서버 추가/삭제 시 재배치되는 키의 **범위**를 그림으로 설명할 수 있다 + +--- + +## 💬 예상 면접 질문 + +**Q1. 기본 안정 해시에는 어떤 문제가 있나?** +> 두 가지다. ① 인접 서버 사이 **파티션 크기가 불균등**해 어떤 서버는 넓고 어떤 서버는 좁은 구간을 담당한다(삭제 시 특히 심함). ② 서버가 링 한쪽에 몰리면 **키가 특정 서버에 쏠린다(hotspot)**. + +**Q2. 가상 노드(virtual node)는 무엇이고 왜 쓰나?** +> 서버 하나를 링 위 **여러 지점**으로 매핑한 것이다(s0 → s0_0, s0_1, s0_2 …). 한 서버가 링 곳곳에 흩어져 담당 구간이 골고루 퍼지므로, 파티션·키 불균등이 완화된다. + +**Q3. 가상 노드 수는 많을수록 좋은가?** +> 많을수록 표준 편차가 작아져 분포가 고르게 된다(서버당 100개면 평균의 ~10%, 200개면 ~5%). 하지만 가상 노드 정보를 저장할 **공간이 더 든다.** 요구사항에 맞춰 균등도와 메모리 사이에서 **타협**해야 한다. + +**Q4. 서버를 추가/삭제할 때 어떤 키를 옮기나?** +> 추가 시엔 새 노드부터 **반시계 방향 직전 서버까지** 구간의 키를 새 노드로, 삭제 시엔 삭제 노드부터 **반시계 방향 직전 서버까지** 구간의 키를 시계방향 다음 서버로 옮긴다. 항상 인접 구간에만 국한된다. + +**Q5. 안정 해시가 핫스팟을 완전히 해결하나?** +> 아니다. 데이터를 고르게 분배해 **가능성을 줄일** 뿐이다. 특정 유명인 데이터처럼 한 지점에 트래픽이 극단적으로 몰리면 캐싱·추가 복제 등 별도 대책이 필요하다. + +**Q6. 성능이 다른 이기종 서버는 어떻게 다루나?** +> 성능 좋은 서버에 **가상 노드를 더 많이 할당**하면 담당 키 비중이 커진다. 가상 노드 구조의 부수적 이점이다. + +➡️ 이전: [STEP 2 — 안정 해시 원리](02_STEP2_안정해시_원리_해시링.md) | 처음: [00 인덱스](00_인덱스.md) diff --git "a/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/04_\355\235\220\353\246\204\355\206\265\355\225\251_\353\215\260\354\235\264\355\204\260\353\266\204\354\202\260\353\266\200\355\204\260_\353\262\241\355\204\260\354\213\234\352\263\204.md" "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/04_\355\235\220\353\246\204\355\206\265\355\225\251_\353\215\260\354\235\264\355\204\260\353\266\204\354\202\260\353\266\200\355\204\260_\353\262\241\355\204\260\354\213\234\352\263\204.md" new file mode 100644 index 0000000..490fd4d --- /dev/null +++ "b/05-\354\225\210\354\240\225\355\225\264\354\213\234\354\204\244\352\263\204/\354\240\225\353\246\254\353\205\270\355\212\270/04_\355\235\220\353\246\204\355\206\265\355\225\251_\353\215\260\354\235\264\355\204\260\353\266\204\354\202\260\353\266\200\355\204\260_\353\262\241\355\204\260\354\213\234\352\263\204.md" @@ -0,0 +1,217 @@ +# 흐름 통합 — 데이터 분산 저장부터 벡터 시계까지 + +> **5장 안정 해시(분산 저장)** 가 **6장 키-값 저장소(복제·정족수·충돌 해소)** 로 어떻게 확장되는지 +> 하나의 데이터 흐름으로 꿰는 다리(bridge) 노트. +> 각 단계의 상세는 6장 STEP 노트로 링크한다. 여기서는 **"왜 이 순서로 이어지는가"** 를 본다. + +--- + +## 0. 큰 그림 — 같은 해시 링 위에 4층이 쌓인다 + +```mermaid +flowchart LR + A["① 분산 저장 (5장)
키 → 담당 노드
= 어디에"] + B["② 복제 계수 N
시계방향 N개에 복사
= 몇 벌"] + C["③ 정족수 W·R
N개 중 몇 개에 쓰고 읽나
= 얼마나 맞출까"] + D["④ 충돌 해소
벡터 시계로 버전 판별
= 갈라지면 어떻게"] + A --> B --> C --> D +``` + +> 핵심: 네 단계 모두 **5장이 정의한 해시 링을 그대로 재사용**한다. 5장은 "링 위 위치로 담당 노드를 정하는 규칙"만 주고, 6장은 그 규칙을 반복 적용해 복제·정족수·충돌 해소를 얹는다. + +--- + +## 1. 왜 이 흐름인가 — 문제의 사슬 + +각 단계는 *기능 추가*가 아니라 **앞 단계가 만든 문제를 푸는 다음 결정**이다. + +| 단계 | 앞 단계가 남긴 문제 | 이 단계의 답 | 새로 생기는 문제 | +| --- | --- | --- | --- | +| ① 분산 저장 | `hash % N`은 서버 변동 시 전부 재배치 | 안정 해시 링 (담당 노드 = 시계방향 첫 노드) | 담당 노드 1곳이 죽으면 그 데이터 조각 소실 | +| ② 복제 N | 노드 하나 죽으면 데이터 유실 | 시계방향 **N개 노드**에 복제 | 복제본이 여러 개 → "어느 게 최신?" | +| ③ 정족수 W·R | 어느 복제본이 최신인지 모호 | **W개에 쓰고 R개를 읽어** `W+R>N`이면 최신 보장 | W를 느슨히 두면 동시 쓰기로 값이 갈라짐 | +| ④ 벡터 시계 | 갈라진 버전 중 뭐가 맞나 | `[서버:카운터]`로 **조상/충돌 판별** 후 병합 | 목록 길이·클라이언트 복잡도 (완화책 존재) | + +--- + +## 2. ① 데이터 분산 저장 (파티션 / 안정 해시) — 5장 + +### ❓ 먼저 짚기: 파티션은 "분산 저장"인가, "마스터 저장 후 복제"인가? + +> **답: 데이터 분산 저장(샤딩)이다. 마스터-복제가 아니다.** + +안정 해시가 답하는 질문은 딱 하나 — **"이 키는 어느 노드가 담당(소유)하는가?"** 즉 **어디에 둘지**만 정한다. 복사본을 만드는 일(복제)과는 **완전히 별개의 축**이다. + +| | 안정 해시 파티션 (5장) | 마스터-복제 방식 | +| --- | --- | --- | +| 저장 위치 | 키마다 **담당 노드가 다름** (링 위치로 결정) | 모든 쓰기가 **하나의 마스터**로 | +| 성격 | **분산(수평 분할)** | **복제(같은 데이터 복사)** | +| 구조 | **탈중앙** — 단일 마스터 없음 | 중앙 마스터 존재 | + +- 안정 해시는 **탈중앙(decentralized)**: key0은 노드0이, key1은 노드1이 담당하는 식으로 **키마다 담당 노드가 흩어진다.** "모두 마스터에 넣고 복제"하는 구조가 아니다. +- "담당 노드"를 그 키의 **primary(주 사본)** 라 부를 수는 있지만, 이건 **키마다 다른** primary이지 **전역 단일 마스터가 아니다.** +- 복제(마스터-복제가 아니라 "시계방향 N개 복사")는 **이 위에 얹는 별개 단계** → 아래 ②. + +### 파티션 자체 정리 + +- **파티션** = 링에서 인접한 두 노드 사이의 해시 공간 = 한 노드가 담당하는 키 구간. +- 키는 **시계방향 첫 노드 한 곳**에 저장 (이 단계엔 복제도 마스터도 없음 — 순수 "어디에 둘지"). +- 서버 추가/삭제 시 **인접 구간의 키(평균 k/n)만** 이동 → 무중단 확장. + +> 📎 상세: [5장 STEP2 해시 링 원리](02_STEP2_안정해시_원리_해시링.md) · [5장 STEP3 가상 노드](03_STEP3_가상노드_균등분포.md) + +--- + +## 3. ② 복제 계수 N — 6장 STEP3 + +담당 노드에서 멈추지 않고, **링을 시계방향으로 계속 돌며 N개 노드**에 같은 데이터를 복제한다. + +- **N = 복제 계수** (보통 3). key0 담당이 노드1이면 → 노드1·2·3에 저장. +- ⚠️ **가상 노드 함정**: 시계방향 N개의 *가상* 노드가 같은 *물리* 서버일 수 있음 → **이미 만난 물리 노드는 건너뛰고** 서로 다른 물리 노드 N개를 고른다. +- **멀티 DC**: 복제본을 서로 다른 데이터 센터에 분산 → DC 하나가 통째로 죽어도 보존. + +```mermaid +flowchart LR + K[key0 위치] --> N1((노드1)) + N1 -->|복제| N2((노드2)) + N2 -->|복제| N3((노드3)) + subgraph rep["N=3"] + N1 + N2 + N3 + end +``` + +> 📎 상세: [6장 STEP3 데이터 복제](../../06-키값저장소설계/정리노트/03_STEP3_데이터복제.md) + +--- + +## 4. ③ 정족수 W·R — 6장 STEP4 + +복제본이 N개가 되면 "어느 게 최신?" 문제가 생긴다. 세 숫자로 일관성↔지연을 조율한다. + +| 기호 | 의미 | +|:---:|---| +| **N** | 복제본 개수 | +| **W** | 쓰기 정족수 — W개 노드의 ACK를 받아야 "썼다" | +| **R** | 읽기 정족수 — R개 노드에서 응답을 받아야 "읽었다" | + +**핵심 공식:** +``` +W + R > N ⟹ 쓰기 집합 ∩ 읽기 집합 ≠ ∅ ⟹ 항상 최신값 (강한 일관성) +``` + +| 설정 (N=3) | 성격 | W+R>N? | +| --- | --- | :---: | +| W=3, R=1 | 쓰기 느림 / 읽기 빠름 | ✅ | +| W=1, R=3 | 쓰기 빠름 / 읽기 느림 | ✅ | +| **W=2, R=2** | **균형 (흔한 선택)** | ✅ | +| W=1, R=1 | 둘 다 빠름 | ❌ (최종 일관성) | + +- **코디네이터(coordinator)**: 클라이언트와 복제 노드 사이의 프록시. 링을 보고 담당 N개를 찾아 쓰기/읽기를 전파하고, W개/R개 응답을 모아 결과를 돌려준다. + +> 📎 상세: [6장 STEP4 일관성·정족수](../../06-키값저장소설계/정리노트/04_STEP4_일관성_정족수.md) + +--- + +## 5. ④ 충돌 해소 (벡터 시계) — 6장 STEP5 + +W를 느슨하게 두거나 네트워크 분할이 있으면 **동시 쓰기로 같은 키에 갈라진 버전**이 생긴다. + +- **왜 타임스탬프(LWW) 안 되나**: 서버 간 시계 어긋남(clock skew)으로 나중 쓴 값이 버려질 수 있음 → **인과관계** 추적 필요. +- **벡터 시계**: 버전마다 `[서버:카운터]` 목록. 서버 Si가 쓰면 `[Si,c]` 있으면 +1, 없으면 `[Si,1]` 추가. + +**충돌 판정:** + +| 관계 | 판정 | 처리 | +| --- | --- | --- | +| X의 모든 카운터 ≤ Y | X는 Y의 **조상** | Y로 자동 덮어씀 | +| 서로 ≤ 불성립 | **충돌** (형제 버전) | **클라이언트가 병합** | + +- 저장소는 충돌을 **감지·보존**만, 병합 책임은 **클라이언트**. (예: 아마존 장바구니 → 두 버전 **합집합**) + +> 📎 상세: [6장 STEP5 충돌 해소·벡터 시계](../../06-키값저장소설계/정리노트/05_STEP5_충돌해소_벡터시계.md) + +--- + +## 6. 한 번에 따라가기 — key0 하나의 일생 (N=3, W=2, R=2) + +```mermaid +sequenceDiagram + participant C as Client + participant Co as Coordinator + participant N1 as 노드1 + participant N2 as 노드2 + participant N3 as 노드3 + + Note over Co: ① 링에서 key0 담당 = 시계방향 노드1,2,3 (②복제 N=3) + C->>Co: put(key0, "v2") + Co->>N1: write v2 + Co->>N2: write v2 + Co->>N3: write v2 + N1-->>Co: ACK + N2-->>Co: ACK + Note over Co: ③ W=2 충족 → 성공 (N3 지연 무관) + Co-->>C: OK + + C->>Co: get(key0) + Co->>N2: read + Co->>N3: read + N2-->>Co: v2 [Sx,2] + N3-->>Co: v1 [Sx,1] (아직 옛값) + Note over Co: ④ 벡터 시계 비교 → v1은 v2의 조상 → v2가 최신 + Co-->>C: v2 +``` + +- **①②**: 안정 해시로 담당 3개 노드 결정 → 복제. +- **③**: 쓰기 집합 {N1,N2}, 읽기 집합 {N2,N3} → 교집합 **{N2}** 보장(`W+R=4>3`) → 읽기는 반드시 v2를 봄. +- **④**: N3가 옛값 v1을 줘도 벡터 시계로 **v1 ⊂ v2 (조상)** 판정 → v2 채택. 만약 두 값이 서로 조상이 아니면 **충돌**로 보존 후 클라이언트 병합. + +--- + +## 7. 용어 한 장 정리 + +| 용어 | 한 줄 정의 | 소속 | +| --- | --- | --- | +| 파티션 | 링에서 한 노드가 담당하는 키 구간 | 5장 | +| 가상 노드 | 서버 하나를 링 위 여러 점으로 올린 것 | 5장 | +| 복제 계수 N | 같은 데이터를 저장하는 노드 수 | 6장 | +| W / R | 쓰기 / 읽기 정족수 | 6장 | +| W+R>N | 쓰기·읽기 집합이 겹쳐 강한 일관성 보장 | 6장 | +| 코디네이터 | 쓰기/읽기를 복제본에 전파·수집하는 프록시 | 6장 | +| 벡터 시계 | `[서버:카운터]`로 버전 인과관계 추적 | 6장 | +| 조상/형제 | 덮어쓰기 가능 / 충돌(병합 필요) | 6장 | + +--- + +## ✅ 통합 체크리스트 + +- [ ] 파티션(분산 저장)과 복제가 **다른 축**임을 설명할 수 있다 +- [ ] 복제본 N개를 안정 해시 링에서 고르는 규칙(시계방향, 물리 노드 중복 제외)을 안다 +- [ ] `W+R>N`이 왜 강한 일관성을 보장하는지(집합 교집합) 말할 수 있다 +- [ ] 느슨한 정족수가 동시 쓰기 충돌을 낳음을 안다 +- [ ] 벡터 시계로 조상/충돌을 판정하고 충돌은 클라이언트가 병합함을 안다 +- [ ] key 하나의 put→복제→정족수 read→버전 판정 흐름을 그림 없이 설명할 수 있다 + +--- + +## 💬 예상 면접 질문 (통합) + +**Q0. 안정 해시의 파티션은 데이터 분산 저장인가, 마스터에 저장 후 복제하는 것인가?** +> **분산 저장(샤딩)이다.** 안정 해시는 "이 키를 어느 노드가 담당하는가(어디에 둘지)"만 정하고, 키마다 담당 노드가 흩어지는 **탈중앙 구조**다. 단일 마스터에 모아 복제하는 방식이 아니다. 복제는 이 위에 얹는 별개 축(②)이다. + +**Q1. 안정 해시(파티션)와 복제는 어떻게 결합되나?** +> 안정 해시로 키의 담당 노드(시계방향 첫 노드)를 정한 뒤, **거기서 시계방향으로 이어지는 서로 다른 물리 노드 N개**에 복제한다. 파티션은 "어디에", 복제는 "몇 벌"을 담당하는 별개 축이지만 같은 링을 공유한다. + +**Q2. N=3에서 강한 일관성과 빠른 응답을 각각 어떻게 얻나?** +> 강한 일관성은 `W+R>N`을 만족하도록(예: W=2,R=2) 잡는다. 쓰기·읽기 집합이 겹쳐 항상 최신값을 본다. 빠른 응답이 우선이면 W=1,R=1처럼 느슨히 둔다(최종 일관성). + +**Q3. 정족수를 느슨히 두면 무슨 문제가 생기고 어떻게 푸나?** +> 동시 쓰기로 같은 키에 갈라진 버전이 생긴다. **벡터 시계**로 버전 간 조상/충돌을 판별해, 조상 관계면 자동 덮어쓰고 충돌(형제)이면 저장소가 보존한 뒤 **클라이언트가 병합**(예: 장바구니 합집합)한다. + +**Q4. 이 흐름 전체를 한 문장으로 요약하면?** +> 안정 해시로 **나누고(파티션)**, 시계방향 N개에 **복제하고(N)**, W·R로 **일관성을 조율하고(정족수)**, 갈라지면 **벡터 시계로 판별·병합(충돌 해소)** 한다. + +--- + +➡️ 관련: [5장 인덱스](00_인덱스.md) · [6장 인덱스](../../06-키값저장소설계/정리노트/00_인덱스.md) · 다음 흐름 [6장 STEP6 장애 처리](../../06-키값저장소설계/정리노트/06_STEP6_장애처리.md)