Wide-Column & Distributed Schema Physics

1. Overview

와이드 컬럼과 분산 스키마 물리 엔진(Wide-Column & Distributed Schema Physics)은 구글의 Bigtable 논문에서 파생되어, 수백 대의 분산 서버 클러스터에 수백 테라바이트의 거대 테이블을 끊김 없이 저장하고 밀리초(ms) 단위로 쿼리하는 최상위 스케일 아웃(Scale-out) 아키텍처를 해부합니다.

학습자는 단순한 RDBMS 행/열 구조를 넘어 3차원 해시맵(Row Key, Column Family, Timestamp)으로 데이터를 적재하는 **와이드 컬럼 스토어(Apache Cassandra, HBase)**의 논리적 데이터 모델을 뜯어봅니다. 나아가 분산 클러스터에서 단일 장애점(SPOF) 없이 무한 확장을 달성하기 위해 노드 간 링(Ring) 구조를 그리는 **일관된 해싱(Consistent Hashing)**과 **P2P 가십 프로토콜(Gossip Protocol)**을 해부합니다. 마지막으로 쓰기 성능을 극한으로 유지하기 위한 LSM Tree 물리 엔진 튜닝과, CAP 정리 하에서 가용성을 우선시(AP 시스템)하는 조정 가능 일관성(Tunable Consistency)의 엔지니어링 타협을 장악합니다.

2. Scope & Boundaries

In-Scope

• 데이터 모델 (Data Model): Row Key(Partition Key + Clustering Key), Column Family, Cell(Timestamp Versioning), 3차원 해시맵.
• 분산 아키텍처 (Distributed Architecture): Masterless(P2P), 가십 프로토콜(Gossip Protocol), 일관된 해싱(Consistent Hashing)과 파티셔너(Partitioner).
• 데이터 복제와 일관성 (Replication & Consistency): 복제 인자(Replication Factor), 정족수(Quorum), 조정 가능 일관성(Tunable Consistency: ANY, ONE, QUORUM, ALL), Hinted Handoff.
• 물리적 저장 (Storage Engine): MemTable, CommitLog(WAL), SSTable, Tombstone(삭제 마커), Compaction.

Out-of-Scope

• Hadoop 생태계 (HDFS/MapReduce): HBase의 밑바탕이 되는 분산 파일 시스템 깊숙한 원리 → 06-06 Storage Systems 영역으로 위임.
• 복잡한 조인과 텍스트 전문 검색 (Joins & Full-text): Cassandra는 조인(Join)과 LIKE 검색을 근본적으로 지원하지 않음 (안티 패턴).

Boundaries

• 관계형 모델링 vs 쿼리 주도 모델링 (RDBMS vs Cassandra): RDBMS에서는 엔티티 간 관계를 정규화하여 테이블을 쪼개고, 애플리케이션의 다양한 쿼리를 나중에 JOIN과 인덱스로 해결합니다. 하지만 와이드 컬럼(Cassandra)에서는 조인이 없습니다. 따라서 **"화면(클라이언트)이 어떤 쿼리를 던질 것인가"**를 가장 먼저 정의하고, 그 특정 쿼리가 단 한 번의 디스크 접근으로 해결되도록 데이터를 무지막지하게 중복 저장(Denormalization)하는 역방향 데이터 모델링(Query-Driven)이 필수적입니다. RDBMS적 사고방식으로 Cassandra를 설계하면 프로젝트가 파멸합니다.

3. Counterexample

• 파티션 키 오설정으로 인한 핫스팟 폭발 (Hotspot & Tombstone Hell): 트위터 같은 앱을 만들며 모든 유저의 게시물을 partition_key = 'all_posts' 라는 단일 해시 키 하나에 몰아넣은 경우. 클러스터 노드가 100대 있어도, 특정 해시 키 데이터는 단 1대의 특정 노드(파티션 리더)에만 집중 할당됩니다(Hotspot). 99대의 노드는 놀고 1대만 디스크 I/O가 폭발해 다운됩니다. 데이터가 고르게 분산되도록 user_id나 YYYY-MM-DD로 파티션 키를 분산시켜야 하는 클러스터 엔진의 물리적 특성을 무시한 설계입니다.
• 수시 삭제(Delete)로 인한 디스크 용량 초과와 성능 저하 (Tombstone Overload): 디스크 용량을 줄이겠다고 만료된 데이터를 쿼리문으로 계속 DELETE함. 와이드 컬럼 스토어 내부 엔진(LSM Tree)은 데이터를 지울 때 진짜로 지우지 않고 "삭제 마커(Tombstone)"라는 새로운 레코드를 **추가(Insert)**합니다. 즉, 지울수록 디스크 용량이 늘어나고, 읽을 때마다 마커를 필터링하느라 CPU가 낭비됩니다. 불필요한 데이터는 DELETE 대신 컬럼 자체의 수명 설정 기능(TTL, Time To Live)을 사용하여 엔진이 병합(Compaction) 시 알아서 버리게 해야 합니다.

4. Prerequisites

• LSM Tree 구조 (Basic): MemTable과 SSTable의 쓰기/병합 메커니즘. (06-02-01 Key-Value Store)
• 분산 시스템 CAP 정리 (Basic): 가용성(Availability)과 일관성(Consistency)의 트레이드오프 이해. (07-02-01 Theorems & Consistency)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 무한히 늘어나는 테이블 공간, 와이드 컬럼 데이터 모델 (3D Hash Map)

• Why to Learn: RDBMS처럼 행마다 컬럼 개수와 타입이 꽉 차 있는(Dense) 형태가 아니라, 행마다 컬럼이 10개 혹은 100만 개(희소, Sparse)일 수도 있는 빅데이터용 3차원 구조의 패러다임을 꿰기 위함입니다.
• What to Learn:
  • Concepts: Column Family, Row Key (Partition Key + Clustering Key), 타임스탬프 튜플(Map<RowKey, Map<ColumnKey, Value>>), 와이드 로우(Wide Row).
  • Skills: Cassandra CQL (Cassandra Query Language) 쿼리 모델링.
• How to Learn:
  • 1단계: Primary Key의 두 얼굴: 1단계 Partition Key는 수백 대의 서버 중 어느 서버(해시 구간)에 저장할지 결정. 2단계 Clustering Key는 그 서버의 디스크 안에서 데이터를 어떻게 "정렬"하여 쌓을지 결정. IoT 센서 데이터를 '지역'으로 파티셔닝하고 '시간'으로 클러스터링하는 물리적 배치를 해부합니다.
  • 2단계: 컬럼이 무한대로 늘어난다: RDBMS는 새로운 컬럼 추가 시 ALTER TABLE이 필요하지만, 와이드 컬럼은 단지 Map 구조 안에 동적으로 새로운 Key-Value 쌍을 밀어넣을 뿐입니다(Schema-free). 한 Row 안에 컬럼을 20억 개까지 동적으로 늘려도 되는 유연성을 뜯어봅니다.
• Implement: 파이썬 중첩 딕셔너리로 와이드 컬럼 흉내내기. db = {}. db["partition_seoul"] = {"time_1000_temp": 24.5, "time_1001_humid": 80}. 이런 식으로 특정 파티션 키 하위에 컬럼들을 동적으로 추가. db["partition_seoul"] 조회 시 시간순으로 정렬(Clustering)된 컬럼 배열을 반환하는 구조 텍스트 렌더링 데모.

Recommended

Core Topic 02: 마스터의 죽음을 극복하다, 가십 프로토콜과 P2P 클러스터 (Gossip Protocol)

• Why to Learn: 넷플릭스(Netflix)가 AWS 리전 전체가 다운되어도 살아남는 좀비 같은 서비스(Chaos Monkey 방어력)를 만든 비결, 바로 '마스터 노드'가 없는 순수 P2P 클러스터의 상태 동기화 역학을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Master-Slave 병목 한계, P2P(Peer-to-Peer) 아키텍처, 단일 장애점(SPOF) 회피, 가십 프로토콜(Gossip Protocol / Epidemic Protocol), 하트비트(Heartbeat), 시드 노드(Seed Node).
  • Skills: 클러스터 노드 장애(Node Down) 탐지 원리 이해.
• How to Learn:
  • 1단계: 가십(소문) 전파: 클러스터 내 100대의 노드. 각 노드는 1초마다 무작위 3대에게 "내 상태, 그리고 내가 아는 다른 노드들의 상태 정보(버전 포함)"를 보냅니다. 전염병 퍼지듯 단 몇 초 만에 100대 전체가 서로가 살아있는지, 죽었는지 메타데이터를 통일(Convergence)하는 알고리즘을 해부합니다.
  • 2단계: SPOF의 소멸: 마스터 노드가 없으므로, 클라이언트 앱은 클러스터 내의 "아무 노드(Coordinator)"나 붙어서 쿼리를 날리면 됩니다. 해당 노드가 가십으로 파악한 해시 맵을 보고 데이터를 가진 진짜 노드에게 알아서 백그라운드로 토스(Routing)해주는 역학을 뜯어봅니다.
• Implement: 파이썬 GossipNode 클래스 시뮬레이션. 노드 A, B, C, D 4개 생성. 각자 빈 딕셔너리(상태 맵) 소유. 루프를 돌며 랜덤으로 타 노드와 교신하여 상태 맵 갱신(버전 번호가 더 높은 최신 상태로 병합). 10번째 루프에서 노드 C를 고의로 정지(시간 갱신 중단). 이후 몇 턴 만에 다른 노드들이 'C가 응답 없음'을 인지하는지 관찰하는 시뮬레이션 로깅.

Practical

Core Topic 03: 데이터 이주의 최소화, 일관된 해싱 엔진 (Consistent Hashing)

• Why to Learn: 서비스가 커져서 3대의 서버 캐시/DB를 4대로 늘릴 때, hash(key) % 3 방식을 쓰면 기존 데이터의 70%가 위치를 잃고 재배치되어야 하는 재앙을 물리적으로 틀어막는 분산 해싱 알고리즘을 장악하기 위함입니다.
• What to Learn:
  • Concepts: 모듈러 해싱의 한계(Rebalancing Avalanche), 해시 링(Hash Ring 0~2^127), 노드 토큰 할당, 가상 노드(Virtual Nodes, Vnodes), 데이터 파티셔닝(Partitioning).
  • Skills: 클러스터 스케일 아웃(Scale-out) 시 데이터 이동량(I/O 부하) 예측.
• How to Learn:
  • 1단계: 링(Ring)을 긋다: 0부터 100까지의 해시 링. 서버 A는 033, B는 3466, C는 67~100 담당. 데이터 'Apple'의 해시값이 40이면 시계방향으로 돌아 서버 B에 저장. 서버 3대를 링 위에 배치하는 물리 공간의 추상화를 해부합니다.
  • 2단계: 우아한 스케일 아웃: 서버 D를 새로 추가. 모듈러 연산 붕괴 없이, A, B, C가 가진 링 영역 중 일부 구간만 D에게 떼어줌(가상 노드 기법 활용). 전체 데이터 중 정확히 $1/4$ 의 데이터만 백그라운드 네트워크로 이주(Migration)하면 끝나는 놀라운 확장 엔진을 뜯어봅니다.
• Implement: 모듈러 해싱 vs 일관된 해싱 데이터 셔플링 비교 파이썬. 데이터 1,000건 해시 생성(md5). 노드 3대에서 4대로 변경. 1) hash % 3 → hash % 4 변경 시 키 매핑이 바뀐 횟수 카운트(약 75% 변경). 2) bisect 모듈을 활용한 해시 링 구성 적용 시 4대 변경. 키 매핑 변경 횟수 카운트(약 25% 변경, 추가된 노드로만 이동). 링 기법의 압도적 효율성 콘솔 출력 증명.

Advanced

Core Topic 04: 스피드와 정확성의 거래, 조정 가능 일관성 (Tunable Consistency & Quorum)

• Why to Learn: "돈(트랜잭션)은 모든 서버에 완벽히 써져야 하지만(느림), 좋아요 숫자는 한 대에만 써져도 괜찮다(빠름)." 비즈니스 요구사항에 맞춰 RDBMS가 제공할 수 없는 CAP 정리의 줄타기(Tunable Consistency)를 엔진 레벨에서 튜닝하기 위해서입니다.
• What to Learn:
  • Concepts: 복제 인자(Replication Factor: 데이터 복제본 개수), 일관성 수준(Consistency Level: ONE, QUORUM, ALL), 리드 리페어(Read Repair), 힌티드 핸드오프(Hinted Handoff).
  • Skills: 정합성 보장 공식: $R(\text{읽기 노드 수}) + W(\text{쓰기 노드 수}) > N(\text{전체 복제본 수})$ 적용.
• How to Learn:
  • 1단계: 성능 중심 (W=1, R=1): 3군데 복제(N=3)되지만, 클라이언트가 쓰기 시 "1군데만 쓰여도 바로 성공 응답(W=1)". 엄청나게 빠르지만 다른 2대 복제 전에 1번 노드가 죽으면 데이터 분실(가용성 극대화, 정합성 희생).
  • 2단계: Quorum(다수결) 중심 (W=2, R=2): $N=3$ 일 때, 2대(과반수)에 쓰기가 완료되어야 성공(W=2), 읽을 때도 2대에서 읽어와 최신 버전을 고름(R=2). $2+2 > 3$ 이므로 읽을 때 반드시 가장 최신 쓰기 데이터를 보장(강한 일관성 달성). 시스템 성능과 신뢰성의 타협 수식을 뜯어봅니다.
• Implement: 간단한 Quorum 읽기/쓰기 시뮬레이터 로직 구현. 3개 원소가 들어있는 노드 배열 [A, B, C]. 각 원소는 {'version': 1, 'val': 'old'}. 쓰기 연산 W=2 실행(A, B 2개 원소 버전을 2로 'new' 업데이트). 읽기 연산 R=1 실행 시 재수 없게 C를 고르면 'old' 데이터를 반환하는 낡은 읽기(Stale Read) 발생. 읽기 연산 R=2로 변경하여 B, C를 함께 읽고 높은 버전(2)을 판정해 최종 반환하는 Quorum 안정성 입증 테스트.

7. Terminology

8. References

Primary

• [P1] CS2023 - Parallel and Distributed Computing (PDC) - Distributed Storage
• [P5] SFIA - Data Modeling and Design (DTAN) - Big Data NoSQL

Secondary

• [Designing Data-Intensive Applications] Martin Kleppmann - Partitioning and Replication
• [Bigtable: A Distributed Storage System for Structured Data] Google Whitepaper

Industry

• [Apache Cassandra Documentation] - Architecture (Gossip, Ring, Tunable Consistency)
• [DataStax Academy] - Cassandra Data Modeling (Query-Driven Design)

9. Final Checklist

Primary

• Partition Key와 Clustering Key가 각각 수백 대의 노드 라우팅과 로컬 디스크 내 정렬에 어떻게 기여하는지 설명할 수 있는가?
• 와이드 컬럼 모델링에서 조인(Join) 없이 요구사항을 충족시키기 위해 '쿼리 주도(Query-Driven)' 비정규화 역설계를 할 수 있는가?

Secondary

• 마스터-슬레이브 아키텍처의 한계를 극복하기 위해 가십 프로토콜(Gossip)이 어떻게 무중단 클러스터를 형성하는지 해부할 수 있는가?
• 노드를 3대에서 4대로 증설할 때, 모듈러 해싱의 문제점(데이터 75% 이주)을 일관된 해싱(Consistent Hashing)이 어떻게 방어하는지 증명할 수 있는가?

Industry

• 정족수 공식($R + W > N$)을 적용하여, 성능이 중요할 때와 금융 정합성이 중요할 때의 Tunable Consistency 값을 설계할 수 있는가?
• Cassandra에서 만료된 데이터를 쿼리문으로 계속 DELETE 할 때(Tombstone 폭발) 발생하는 스토리지 팽창과 조회 병목 현상을 논증할 수 있는가?