Theorems & Consistency Dynamics

1. Overview

분산 시스템 정리와 일관성 역학(Theorems & Consistency Dynamics)은 수천 대의 서버로 쪼개진 현대 클라우드 시스템이 "왜 절대로 완벽할 수 없는지"를 증명하는 분산 컴퓨팅의 가장 차갑고 잔인한 물리 법칙들을 해부합니다.

학습자는 분산 시스템을 구축할 때 겪는 8가지 헛된 착각(Fallacies)을 마주하고, 분할(Partition)된 네트워크 환경에서 가용성(Availability)과 일관성(Consistency) 중 하나는 반드시 버려야 한다는 분산 컴퓨팅의 절대 명제인 CAP 정리를 뜯어봅니다. 나아가 CAP의 단순함을 넘어, 평상시(지연 시간)와 장애시(분할)의 트레이드오프를 4차원으로 쪼개는 PACELC 정리를 해부합니다. 마지막으로, 은행 송금(강한 일관성)부터 SNS 좋아요 갱신(최종적 일관성)까지, 비즈니스 성격에 맞춰 타협선을 긋고 데이터의 동기화 시점을 설계하는 완벽한 인프라 타협 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 분산 컴퓨팅의 8가지 오류 (The 8 Fallacies): 네트워크 신뢰성, 지연 시간 제로(Zero-latency), 무한한 대역폭 등 런타임의 착각.
• CAP Theorem: Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성)의 3자택 2 역학 (CP vs AP).
• PACELC Theorem: CAP를 확장하여 평상시(E)의 Latency(L)와 Consistency(C) 사이의 저울질까지 포괄하는 튜닝 모델.
• Consistency Models (일관성 모델): Strong Consistency (강한 일관성), Eventual Consistency (최종적 일관성), Read-Your-Writes (내가 쓴 건 바로 읽기).

Out-of-Scope

• Raft / Paxos 뗏목 합의 알고리즘: 리더 선출 및 분산 로그 복제 메커니즘 $\rightarrow$ 07-02-02 Consensus Algorithms 영역으로 위임.
• 논리적 시계와 인과성: Lamport Vector Clock 등 이벤트 순서 정렬 $\rightarrow$ 07-02-03 Time & Clocks 영역.

Boundaries

• CA 시스템의 허상 (The Illusion of CA): CAP 정리에서 "우리 시스템은 CA(일관성과 가용성을 모두 챙김)입니다"라고 말하는 것은 분산 시스템 설계에서 가장 무지한 발언입니다. 물리적인 두 대의 서버를 광랜으로 묶었을 때 누군가 랜선을 뽑아버리는 사태(Partition)는 확률의 문제일 뿐 반드시 일어납니다. 따라서 P(분할 내성)는 선택 사항이 아니라 강제되는 물리 법칙이며, 설계자는 결국 "랜선이 끊어졌을 때, 에러를 뱉을 것인가(CP), 아니면 옛날 데이터라도 보여줄 것인가(AP)"라는 단 두 가지 선택지(CP vs AP)만 가질 수 있음을 명확히 긋습니다.

3. Counterexample

• AP 시스템에서 계좌 이체의 파국: 은행 시스템을 설계하며 가용성(A)을 중시한 AP 아키텍처(Cassandra 등)를 채택했습니다. 네트워크 랜선이 끊어져(P) 서울 서버와 부산 서버가 통신을 멈췄습니다. 부산 서버는 최신 잔액(0원)을 모르고 옛날 잔액(100만 원)을 그대로 유저에게 보여주며 출금을 허용(A)해 버립니다. 이는 비즈니스 도메인(금융 = 강한 일관성 CP 필요)과 물리적 인프라 엔진(AP)이 정면충돌하여 회사를 파산하게 만든 아키텍처 실패입니다.
• 강한 일관성(Strong Consistency)의 늪: SNS '좋아요' 기능을 글로벌 3개 대륙(한국, 미국, 유럽) 데이터센터에 동기화합니다. 강한 일관성(CP)을 적용하여, 누군가 '좋아요'를 누르면 3개 대륙의 DB에 모두 기록이 끝날 때까지 유저 화면의 로딩 스피너를 돌립니다(0.5초 대기). 굳이 0.1초 만에 전 세계가 동기화될 필요가 없는 가벼운 데이터임에도 최종적 일관성(Eventual Consistency)을 쓰지 않아 극악의 유저 경험(Latency)을 유발한 오버 엔지니어링입니다.

4. Prerequisites

• 네트워크 기본기 (Basic): RTT (Round Trip Time), 대역폭과 지연 시간. (08-01 OSI Model)
• 트랜잭션 ACID (Basic): 단일 데이터베이스의 무결성 개념. (06-01-03 ACID)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 환상의 파괴, 분산 컴퓨팅의 8가지 오류 (The 8 Fallacies)

• Why to Learn: 모놀리스 환경(로컬 RAM 통신)에서 작성된 코드를 그대로 네트워크 위로 올렸을 때, 시스템이 왜 타임아웃과 패킷 유실로 무너지는지 근본 원인을 직시하기 위함입니다.
• What to Learn:
  • Concepts: The 8 Fallacies of Distributed Computing (네트워크는 신뢰할 수 있다, 지연 시간은 0이다, 대역폭은 무한하다, 토폴로지는 변하지 않는다 등).
  • Skills: 네트워크 단절(Network Partition), 패킷 손실(Packet Loss), 지터(Jitter)에 대한 방어 코드 작성(타임아웃 설정).
• How to Learn:
  • 1단계: 빛의 속도의 한계: 로컬 RAM 접근 시간은 100ns. 서울-뉴욕 패킷 왕복 시간은 200ms. 무려 200만 배의 차이입니다. 함수가 200만 배 늦게 끝나는 상황을 "지연 시간이 0이다"라고 착각한 동기식(Synchronous) 코드의 재앙을 해부합니다.
  • 2단계: 신뢰성의 붕괴: 공유기가 재부팅되거나 케이블이 단선됩니다. 보낸 패킷이 안 왔는데, 처리는 된 건지 아니면 가다가 증발한 건지(Partial Failure) 영원히 알 수 없는 분산 환경의 슈뢰딩거 상태를 뜯어봅니다.
• Implement: 패킷 유실 시뮬레이터. 서버 A가 서버 B에게 "결제 진행" 패킷을 보내지만 무작위로 $30\%$ 확률로 패킷을 드롭. 클라이언트 A는 영원히 기다리다 스레드가 고갈됨. 타임아웃(Timeout) 코드를 추가하여 3초 뒤 강제로 에러를 반환하게 하는 최소한의 네트워크 방어선 렌더링.

Recommended

Core Topic 02: 둘 중 하나는 반드시 죽는다, CAP 정리 (CAP Theorem)

• Why to Learn: 마스터-슬레이브(Master-Slave) DB 구조를 세팅할 때, 슬레이브 서버가 끊어졌을 때 전체 시스템이 어떻게 행동해야 하는지 아키텍처 차원의 물리적 결단을 내리기 위함입니다.
• What to Learn:
  • Concepts: Consistency (일관성 - 모든 노드가 같은 데이터 반환), Availability (가용성 - 모든 요청이 응답을 받음), Partition Tolerance (분할 내성 - 네트워크 단절 시에도 시스템 동작).
  • Skills: 비즈니스 도메인에 따른 CP 시스템(MongoDB, HBase)과 AP 시스템(Cassandra, DynamoDB) 취사선택.
• How to Learn:
  • 1단계: 랜선 자르기(P): 서울 마스터 서버와 부산 슬레이브 서버 사이의 랜선이 잘립니다(Partition). 이때 유저가 부산 서버에 데이터를 요청합니다.
  • 2단계: 잔인한 선택지: 부산 서버가 "마스터와 연락이 끊겨 최신 데이터인지 확신할 수 없으니, 차라리 에러(500)를 내뱉을게"라고 선언하면 이는 가용성(A)을 버리고 일관성(C)을 택한 CP 시스템입니다. 반대로 부산 서버가 "최신이 아닐 수도 있지만, 서비스가 죽는 것보단 나으니 일단 내가 가진 옛날 데이터를 보여줄게"라고 하면 일관성(C)을 버리고 가용성(A)을 택한 AP 시스템이 되는 물리법칙을 해부합니다.
• Implement: 로컬 프로세스 2개를 띄우고 P(Partition) 상태 주입 스크립트. Node_A(Master)와 Node_B(Slave). 동기화 중단 버튼을 눌러(P 발생), B에게 쿼리를 날릴 때 '오류 반환(CP 모드)'과 '구버전 데이터 반환(AP 모드)'의 두 가지 설정 분기 데모.

Practical

Core Topic 03: 평상시의 저울질, PACELC 정리 (PACELC Theorem)

• Why to Learn: CAP 정리는 '장애(P)'가 났을 때만의 이야기입니다. 장애가 없는 완벽하고 평화로운 상태(E)에서도 '일관성(C)'과 '응답 속도(Latency)'가 피 터지게 싸우는 미세 튜닝의 세계를 장악하기 위함입니다.
• What to Learn:
  • Concepts: PACELC (If P $\rightarrow$ A or C, Else $\rightarrow$ L or C), Replication Factor (복제 계수), Write Quorum (쓰기 정족수), Latency vs Consistency.
  • Skills: 읽기/쓰기 정족수(Quorum) 튜닝으로 일관성과 지연 시간 조율.
• How to Learn:
  • 1단계: Else(E) 상황의 딜레마: 네트워크가 아주 쾌적합니다. 한국 서버에서 글을 썼습니다. 미국, 유럽 서버 2곳에 복사본을 쏴야 합니다.
  • 2단계: L vs C: 미국, 유럽이 "내 디스크에 잘 저장했어"라고 ACK 응답을 보낼 때까지 유저에게 로딩 창을 띄운다면(동기식 복제), 완벽한 일관성(C)을 얻지만 응답 속도(Latency)는 수백 밀리초로 느려집니다(EC 시스템). 반대로 미국/유럽에 던져놓기만 하고 유저에겐 바로 "완료!" 응답을 주면(비동기 복제), 0.01초 만에 응답(L)을 주지만 아주 짧은 순간 데이터 불일치가 일어납니다(EL 시스템). 이 지독한 트레이드오프를 뜯어봅니다.
• Implement: 동기 vs 비동기 복제 시뮬레이터. 마스터 1대, 슬레이브 2대. 1) Strong_Consistency_Write(): 3대 모두 저장 성공 시까지 대기(응답 지연 300ms 렌더링). 2) Low_Latency_Write(): 마스터 저장 즉시 리턴(응답 지연 10ms 렌더링), 하지만 50ms 후 슬레이브를 읽으면 구버전 데이터가 나오는 현상 렌더링.

Advanced

Core Topic 04: 시간의 마법, 최종적 일관성과 타협 (Eventual Consistency & Models)

• Why to Learn: 전 세계 규모의 서비스(SNS, 유튜브 등)가 미친 듯한 트래픽과 가용성을 확보하면서도, 영리한 속임수(모델)를 통해 유저가 불일치를 체감하지 못하게 만드는 최상위 아키텍처 패턴을 세우기 위함입니다.
• What to Learn:
  • Concepts: Strong Consistency(강한 일관성), Eventual Consistency(최종적 일관성), Read-Your-Writes(내가 쓴 건 읽기 보장), Monotonic Reads(단조 읽기).
  • Skills: 비즈니스 유스케이스별 적정 일관성 모델 맵핑.
• How to Learn:
  • 1단계: 최종적 일관성(Eventual Consistency): 당장 슬레이브 서버들 간에 데이터가 다르더라도, 시스템에 새로운 쓰기 멈추고 놔두면 "언젠가는(Eventual)" 모든 서버가 똑같은 데이터 상태로 수렴하게 된다는 타협적인 물리 법칙을 해부합니다. SNS 좋아요 수나 유튜브 조회수에 완벽한 일관성은 오버엔지니어링입니다.
  • 2단계: Read-Your-Writes (내가 쓴 건 읽기): 유저가 자기 프로필 사진을 바꿨는데(Master 저장 완료), 바로 새로고침을 했더니 Slave 서버로 연결되어 옛날 사진이 뜨면 유저는 "버그다!"라고 화를 냅니다. 이를 막기 위해, 유저가 방금 자신이 업데이트한 데이터는 무조건 Master(또는 최신 캐시)에서 읽게 해주는 영리한 세션 스티키(Session Sticky) 일관성 트릭을 뜯어봅니다.
• Implement: Read-Your-Writes 보장 라우터 스크립트. 유저가 UPDATE 쿼리를 날리면 redis_cache에 last_write_timestamp를 기록. 1초 뒤 SELECT 시 캐시 타임스탬프를 확인하여, 방금 쓰기가 일어났으면 복제 지연이 있는 Slave가 아니라 무조건 Master DB로 쿼리를 라우팅하는 '세션 기반 일관성 방어' 로직 구현.

7. Terminology

8. References

Primary

• [P1] CS2023 - Parallel and Distributed Computing (PDC) - Distributed Systems Properties
• [P5] SFIA - Systems Design (DESN) - Distributed Architectures

Secondary

• [Designing Data-Intensive Applications] Martin Kleppmann - Distributed Data and the Trouble with Distributed Systems
• [CAP Twelve Years Later: How the "Rules" Have Changed] Eric Brewer - CAP Theorem Revisited

Industry

• [AWS Architecture Blog] - Consistency Models in Distributed Systems
• [Google Cloud Architecture Center] - Trade-offs in Distributed Database Design

9. Final Checklist

Primary

• 단일 RDBMS 환경의 완벽한 ACID 무결성이, 왜 수백 대의 노드로 이루어진 분산 시스템 위로 올라가는 순간 물리적으로 박살나는지 설명할 수 있는가?
• 네트워크 분할(P) 상황에서 에러를 뱉는 시스템(CP)과 구버전 데이터를 뱉는 시스템(AP)의 비즈니스적 장단점을 금융업과 SNS 도메인을 비교하여 증명할 수 있는가?

Secondary

• 네트워크 장애가 없는 평화로운 상태(Else)에서도, 완벽한 일관성(C)을 보장하려면 응답 속도(Latency)가 반드시 희생되어야 한다는 PACELC 법칙의 역학을 해부할 수 있는가?
• 카산드라(Cassandra)와 같은 링 아키텍처에서 쓰기 정족수(W)와 읽기 정족수(R)의 합이 전체 노드 수(N)보다 클 때($R + W > N$) 강한 일관성을 획득하는 공식을 묘사할 수 있는가?

Industry

• 최종적 일관성(Eventual Consistency)을 채택한 아키텍처에서 유저가 자신의 글을 썼는데 즉시 보이지 않는 버그를 막기 위해, '내가 쓴 건 읽기 보장(Read-Your-Writes)' 라우팅 패턴을 어떻게 설계할지 논증할 수 있는가?
• 두 네트워크가 단절되어 양쪽에서 각각 마스터(Master)로 활동하며 데이터를 받아먹는 분할 뇌(Split Brain) 현상이 발생했을 때, 네트워크 복구 후 이를 어떻게 병합(Conflict Resolution)할지 아키텍처 관점으로 튜닝할 수 있는가?