Distributed Logic & Storage Physics

1. Overview

분산 로직 및 저장 물리(Distributed Logic & Storage Physics, DLP)는 데이터베이스가 단일 컴퓨터(Single Node)의 메모리와 디스크라는 좁은 울타리를 벗어나, 전 세계의 수많은 데이터 센터에 분산 배치될 때 직면하게 되는 가혹한 물리적 한계와 이를 극복하는 공학적 마법을 다룹니다.

물리적으로 떨어진 노드들 간에 데이터를 전송할 때 발생하는 빛의 속도 지연(Latency), 랜선이 끊어지는 네트워크 단절(Network Partition), 그리고 특정 서버의 돌연사(Crash)는 분산 시스템의 상수(Constant)입니다. 학습자는 이런 지옥 같은 환경 속에서도 데이터의 무결성을 지키기 위해 여러 노드가 합의를 이루는 팍소스(Paxos)와 래프트(Raft) 알고리즘을 배웁니다. 또한 디스크 암에 가해지는 쓰기 증폭(Write Amplification) 오버헤드를 타파하는 LSM-Tree(Log-Structured Merge Tree)와 B-Tree의 근본적 차이를 해부하여, 가장 밑바닥의 스토리지 엔진부터 최상단의 분산 트랜잭션(2PC, Saga)까지 관통하는 초고성능 백엔드 설계 철학을 완성합니다.

2. Scope & Boundaries

In-Scope

• 복제와 정합성의 물리 (Replication Mechanics): 동기(Sync) vs 비동기(Async) 복제의 지연 타임, 싱글 리더(Single-Leader), 멀티 리더(Multi-Leader), 리더리스(Leaderless) 복제 충돌 해결.
• 분산 트랜잭션 제어 (Distributed Transactions): 2단계 커밋(2PC, Two-Phase Commit), 분산 락(Distributed Lock), 사가 패턴(Saga Pattern - Choreography & Orchestration).
• 분산 합의와 상태 기계 (Consensus & State Machine): Raft와 Paxos의 과반수(Majority Quorum) 투표, 리더 선출(Leader Election), 스플릿 브레인(Split-Brain) 방어 메커니즘.
• 스토리지 엔진 내부 물리 (Storage Engine Internals): 페이지 캐시(Page Cache), B+Tree의 인플레이스 업데이트(In-place Update), LSM-Tree의 순차 쓰기(Sequential Write) 및 컴팩션(Compaction).

Out-of-Scope

• 네트워크 패킷 단위의 라우팅 프로토콜: TCP 윈도우 사이즈 조절이나 BGP 보더 라우팅의 상세 스펙 → 08-01. Network Fundamentals 영역으로 위임.
• NoSQL 데이터베이스의 논리적 데이터 모델링: 컬럼 패밀리(Column-family)나 도큐먼트(Document) 구조 자체의 설계 → 06-02. NoSQL & Polyglot 영역으로 위임.

Boundaries

• DLP vs. Distributed Systems (07-02): 07-02가 '분산된 서버 간의 연산(Compute) 부하 분산과 일반적인 네트워크 통신 아키텍처'라면, DLP는 오직 **'하드디스크에 데이터를 어떻게 안전하게 쓰고, 그 복사본을 다른 서버로 어떻게 충돌 없이 넘길 것인가'**라는 스토리지(Storage) 정합성에 극도로 초점을 맞춥니다.

3. Counterexample

• 2단계 커밋(2PC)의 맹목적 도입 (Transaction Fallacy): 마이크로서비스(MSA) 아키텍처를 도입해 놓고, 서비스 A와 서비스 B의 데이터 정합성을 맞추겠다고 전통적인 2PC(Two-Phase Commit) 분산 트랜잭션을 강제하는 행위. 2PC는 코디네이터 노드가 죽었을 때 전체 시스템의 락(Lock)이 해제되지 못해 시스템 전체가 멈춰버리는 치명적인 **블로킹 프로토콜(Blocking Protocol)**입니다. MSA 환경에서는 BASE 사상에 입각한 **사가(Saga) 패턴의 보상 트랜잭션(Compensating Transaction)**으로 풀어야 한다는 물리적 한계를 인지하지 못하면 안티패턴입니다.
• 스플릿 브레인(Split Brain) 무지 (Consensus Fallacy): 두 대의 DB 마스터 서버(Active-Active)를 두고 핑(Ping)으로 헬스 체크만 하도록 구성하는 설계. 둘 사이의 네트워크 케이블이 절단되면 서로 상대방이 죽었다고 판단하고 각자 클라이언트의 쓰기 요청을 받아들여 데이터가 영구적으로 두 갈래로 찢어지는 파국(Split Brain)이 발생합니다. 분산 합의는 무조건 홀수(3, 5, 7) 대의 노드로 구성하여 과반수(Majority) 투표로 단 1명의 리더만 선출하게 하는 쿼럼(Quorum)의 절대 법칙을 무시한 것입니다.

4. Prerequisites

• 관계형 시스템 및 트랜잭션 (Basic): 단일 노드에서의 트랜잭션(ACID)과 락(Lock)에 대한 이해가 분산 트랜잭션을 이해하기 위한 선행 조건입니다. (06-01. RS)
• 운영체제 파일 시스템 물리 (Recommended): 페이지 캐시(Page Cache)와 디스크 순차/랜덤 I/O 속도 차이를 알아야 스토리지 엔진(LSM-Tree)의 설계 의도를 간파할 수 있습니다. (03-03. FS)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 스토리지 엔진 하부 구조 (Storage Engine Internals)

• Why to Learn: 애플리케이션에서 INSERT를 날릴 때, 데이터베이스가 즉시 디스크를 긁어 데이터를 박아 넣는지 아니면 메모리에 모았다가 한 번에 방출하는지를 알아야 수만 TPS(Transaction Per Second)의 부하를 견디는 튜닝이 가능해지기 때문입니다.
• What to Learn:
  • Concepts: 랜덤 I/O vs 순차 I/O, 디스크 플러시(fsync), 쓰기 증폭(Write Amplification).
  • Skills: B-Tree의 인플레이스 업데이트(In-place Update: 기존 데이터를 덮어씀) 메커니즘, LSM-Tree(Log-Structured Merge-Tree)의 멤테이블(MemTable) 순차 쓰기와 SSTable 병합(Compaction).
  • Tools: RocksDB, LevelDB 구조 분석.
  • Trade-offs: B-Tree 기반(MySQL)의 일관된 읽기 속도와 낮은 읽기 증폭 vs LSM-Tree 기반(Cassandra, RocksDB)의 압도적인 순차 쓰기 속도지만 읽을 때 여러 계층을 뒤져야 하는 읽기 증폭 오버헤드.
• How to Learn:
  • 1단계: HDD나 SSD에 데이터를 쓸 때, 랜덤한 위치에 점을 찍듯 저장하는 방식(B-Tree 노드 분할)이 순차적으로 끝에 덧붙이는 방식(Append-only Log)보다 물리적으로 수백 배 느림을 벤치마크 지표로 증명합니다.
  • 2단계: 엄청난 쓰기 부하를 감당하기 위해 데이터베이스가 즉시 디스크에 쓰지 않고 메모리(MemTable)에 들고 있다가 순차적인 파일(SSTable)로 떨어뜨린 뒤 백그라운드에서 병합(Compaction)하는 LSM-Tree 역학을 그립니다.
• Implement: 메모리에 키-값 쌍을 저장하다가 특정 한계치를 넘으면 텍스트 파일에 순차적으로(Append) 내려쓰고, 주기적으로 파일들을 병합(Merge)하여 최신 값만 남기는 미니 LSM-Tree 스토리지 엔진 제작.

Recommended

Core Topic 02: 복제 지연과 복제 토폴로지 역학 (Replication Mechanics)

• Why to Learn: 본사 DB에 데이터를 쓰고 해외 지사 DB에서 즉시 읽었을 때 데이터가 보이지 않는 현상을 버그가 아닌 물리적 인과관계로 해석하기 위함입니다.
• What to Learn:
  • Concepts: 싱글 리더(Single-Leader), 멀티 리더(Multi-Leader), 리더리스(Leaderless), 동기(Synchronous) vs 비동기(Asynchronous) 복제.
  • Skills: 복제 지연(Replication Lag)에 따른 Read-after-Write(자신이 쓴 데이터는 즉시 읽기) 일관성 해결법, 다중 리더 환경에서의 충돌(Conflict) 병합 로직.
  • Tools: MySQL Binlog / PostgreSQL WAL 복제 모니터링, 벡터 시계(Vector Clocks).
  • Trade-offs: 동기식 복제로 노드 하나가 죽어도 완벽한 데이터를 보존하지만 쓰기 속도가 노드 통신 지연의 총합만큼 끔찍하게 느려지는 단점 vs 비동기식 복제의 쾌속 응답 속도지만 리더가 죽는 순간 아직 전파되지 않은 데이터가 영구 증발하는 리스크.
• How to Learn:
  • 1단계: 유저가 자신의 프로필 사진을 바꾸자마자(Leader Write), 0.1초 뒤 화면을 새로고침했는데(Follower Read) 구형 사진이 보이는 문제를 파악하고, "사용자 본인의 쓰기는 리더에서 강제 읽기"라는 라우팅 로직을 설계합니다.
  • 2단계: 두 데이터 센터(Active-Active)에서 동시에 동일한 로우(Row)를 수정할 때 발생하는 충돌을 LWW(Last Write Wins - 타임스탬프 기반)로 버리거나, 애플리케이션 코드가 직접 두 버전을 병합하도록(Git Merge처럼) 유도하는 물리적 갈림길을 분석합니다.
• Implement: 마스터-슬레이브 형태의 파일 복제 데몬을 만들고, 인위적인 네트워크 딜레이(Sleep)를 주어 클라이언트가 0.5초 이내에 읽기 요청을 보낼 경우 Stale Data Exception을 발생시키는 복제 지연 시뮬레이터.

Practical

Core Topic 03: 분산 합의와 리더 선출 (Distributed Consensus)

• Why to Learn: 중앙 통제기가 없는 상태에서 서버 여러 대가 동시에 "내가 리더(Master)다"라고 외치며 클러스터를 붕괴시키는 파국을 수학적으로 완벽히 통제하기 위해서입니다.
• What to Learn:
  • Concepts: 합의(Consensus), 래프트(Raft), 팍소스(Paxos), 리더 선출(Leader Election), 스플릿 브레인(Split-Brain).
  • Skills: 에포크(Epoch)와 텀(Term) 관리, 과반수(Majority Quorum) 정족수 확보 물리, 펜싱 토큰(Fencing Token)을 이용한 가짜 리더 차단.
  • Tools: ETCD, Apache ZooKeeper 작동 메커니즘 디버깅, Jepsen 테스트 리포트.
  • Trade-offs: 네트워크 단절 시 다수결(Quorum)을 얻지 못한 소수 파티션의 노드들을 스스로 기능을 정지시켜(CP 특성) 서비스 장애(Downtime)를 유발하지만, 데이터의 충돌은 절대 허용하지 않는 강고한 무결성 보장.
• How to Learn:
  • 1단계: 노드 5대 중 리더가 죽으면, 남은 4대 중 가장 먼저 타임아웃이 발생한 후보자(Candidate)가 선거(Election)를 열고 3표(과반수) 이상을 얻어 새 리더로 즉시 승격하는 Raft 알고리즘의 선거 논리를 추적합니다.
  • 2단계: 죽은 줄 알았던 구형 리더가 네트워크 복구 후 깨어나 "나에게 데이터를 써라!"라고 명령할 때, 새 리더가 발급한 펜싱 토큰(일련번호 5)이 구형 리더의 토큰(일련번호 4)보다 높음을 파악하여 시스템이 구형 리더를 즉각 무시하는 차단 방벽을 그립니다.
• Implement: 3개의 스레드(노드)가 백그라운드 핑(Ping) 통신을 하다가 리더 스레드를 강제로 종료시켰을 때, 남은 두 스레드가 투표를 진행해 리더 권한을 이양받는 간단한 리더 선출(Leader Election) FSM 코드.

Advanced

Core Topic 04: 분산 트랜잭션과 사가 오케스트레이션 (Distributed Transactions)

• Why to Learn: '재고 차감(Inventory DB)'과 '결제 승인(Payment DB)'이라는 찢어진 시스템 사이에서, 어느 한쪽만 성공하고 한쪽은 실패하는 돈 잃는 버그를 원천 봉쇄하는 마이크로서비스 설계의 정점을 찍기 위해서입니다.
• What to Learn:
  • Concepts: 2PC(Two-Phase Commit), 코디네이터(Coordinator), 사가(Saga) 패턴, 이벤트 소싱(Event Sourcing).
  • Skills: 보상 트랜잭션(Compensating Transaction), 코레오그래피(Choreography) 기반 비동기 이벤트 통신, 아웃박스 패턴(Transactional Outbox).
  • Tools: Kafka 기반 이벤트 스트리밍, AWS Step Functions(오케스트레이터).
  • Trade-offs: 코디네이터 노드의 단일 장애점(SPOF) 리스크를 안고 가는 2PC의 동기식 완벽 정합성 vs 데이터 일관성이 깨진 상태로 수 초를 버텨야 하지만 시스템 결합도를 극단적으로 낮춰 무한히 확장 가능한 사가(Saga) 비동기 패턴.
• How to Learn:
  • 1단계: 주문 API가 호출될 때 주문 DB에 데이터 저장과 동시에 Kafka 메시지를 발행하려 하면 둘 중 하나만 실패하는 듀얼 라이트(Dual Write) 문제가 터짐을 증명하고, 이를 동일 DB 내의 Outbox 테이블에 같이 트랜잭션으로 묶어버리는 해법을 설계합니다.
  • 2단계: A 서비스(결제 성공) → B 서비스(재고 차감 성공) → C 서비스(배송 실패)로 이어지는 흐름에서, DB 롤백이 불가능하므로 역순으로 '배송 취소 → 재고 복구 → 결제 취소'라는 보상 API를 호출해 상태를 되돌리는 Saga 오케스트레이션 상태 기계를 설계합니다.
• Implement: 3개의 마이크로서비스(주문, 결제, 재고) 모의 환경을 띄우고 중앙 오케스트레이터가 순차적으로 HTTP 호출을 돌리다 마지막 노드에서 고의 오류(500)를 뱉었을 때, 앞선 노드들의 취소(Cancel) 엔드포인트를 호출하여 롤백을 수행하는 사가 프레임워크 뼈대.

7. Terminology

8. References

Primary References

• [P1] CS2023 - DM/Scalable & Distributed Data — Distributed DB principles.
• [P2] SWEBOK - Computing Foundations — Fundamental logic and storage.

Secondary References

• [Designing Data-Intensive Applications (DDIA)] Martin Kleppmann — The modern authority on DLP.
• [Distributed Systems] van Steen & Tanenbaum — Theoretical foundations.

Industry References

• [Spanner: Google's Globally-Distributed Database] — Landmark industry paper.
• [Amazon Dynamo: A Highly Available Key-value Store] — Foundation of AP systems.

9. Final Checklist

Primary Checklist

• 노드 간 데이터 복제 방식을 비동기(Async)로 설정했을 때, 장애 발생 시 '데이터 유실'이 일어나는 물리적 메커니즘을 설명 가능한가? (P1)
• 5대의 노드로 구성된 클러스터에서 쿼럼(Quorum)을 만족하기 위해 필요한 최소 정상 노드 수를 계산할 수 있는가? (P1)

Secondary Checklist

• 쓰기 요청이 폭주하는 로그 시스템에서 B+ Tree 대신 LSM-tree를 선택해야 하는 물리적 성능 근거를 제시할 수 있는가?
• 사가(Saga) 패턴에서 '보상 트랜잭션'이 실제 DB 롤백과 물리적으로 어떻게 다른지(데이터 변경 이력 관점) 이해하는가?

Industry Checklist

• 클라우드 DB 서비스(Aurora, Spanner 등)의 가용 영역(AZ) 간 복제 지연 로그를 보고 네트워크 이슈를 식별 가능한가? (SFIA)
• 전 세계에 배포된 데이터베이스에서 '물리적 시계의 불일치'가 순서 보장(Ordering)에 미치는 치명적 영향을 논할 수 있는가?