전체 글
-
일관성 코어 (Consistent Core) & 리스 (Lease)Development/Architecture 2026. 8. 17. 20:58
일관성 코어 (Consistent Core) & 리스 (Lease)1. 일관성 코어 — 합의는 클러스터 크기와 함께 스케일하지 않는다문제1,000노드 클러스터가 Raft를 직접 돌린다면 정족수가 501이다. 쓰기마다 501개의 ack를기다려야 하고, 하트비트가 1,000개씩 오가며, 리더 선출 때는 1,000노드가 투표전을 벌인다.정족수 기반 합의의 비용은 노드 수에 비례해 나빠지는데, 우리가 노드를 늘리는 이유는데이터와 처리량 때문이지 합의 참여자를 늘리고 싶어서가 아니다. 요구가 어긋나 있다.그런데 잘 보면, 큰 클러스터에서 강한 일관성이 필요한 데이터는 아주 작다. 어떤 노드가살아있는가, 어떤 파티션을 어떤 노드가 담당하는가, 클러스터 설정값 — 메타데이터뿐이다.실제 데이터 읽기/쓰기는 파티셔닝과 ..
-
시계 제한 대기 (Clock-Bound Wait)Development/Architecture 2026. 8. 17. 20:58
시계 제한 대기 (Clock-Bound Wait) — 시계 오차를 시간으로 지불하기1. 문제: HLC로도 안 잡히는 순서가 있다HLC의 인과율 보장에는 숨은 전제가 있다. 인과가 시스템이 볼 수 있는 메시지를 타고 흐를때만 작동한다는 것이다. max 규칙이 시계를 당겨주는 것은 타임스탬프가 실려 다닐 때뿐이다.그런데 현실의 인과는 시스템 밖으로도 흐른다.10:00.000 클라이언트1 → 서버 A에 쓰기: X = 1 A의 시계는 빠름 → 실제보다 미래의 타임스탬프 부여10:00.001 클라이언트1이 클라이언트2에게 슬랙으로 알림: "X 썼어, 확인해봐"10:00.002 클라이언트2 → 서버 B에 쓰기: Y = 1 B의 시계는 느림 → X보다 작은 타임스탬프 부여실제..
-
램포트 시계 & 하이브리드 시계Development/Architecture 2026. 8. 17. 20:55
램포트 시계 & 하이브리드 시계 — 분산 시스템에서 시간을 다루는 법1. 문제: 분산 시스템에 "지금"은 없다서버들의 물리 시계는 어긋난다. NTP로 동기화해도 수 ms의 오차(clock skew)가 남고,가상머신에서는 시계가 멈췄다 튀기도 하며, NTP 보정 과정에서 한 노드의 시계가 뒤로점프하기도 한다. 시계가 뒤로 가면 "나중 사건이 더 작은 타임스탬프"를 받아 순서가 꼬인다.그런데 곰곰이 보면, 우리가 정말 필요한 것은 "몇 시 몇 분"이라는 절대 시각이 아니라 대부분"어떤 사건이 어떤 사건보다 먼저였는가"라는 순서다. Lamport의 1978년 논문("Time, Clocks,and the Ordering of Events")의 통찰이 바로 이것이다. 시계를 버리고 순서만 남기자.happened-..
-
버전 벡터 (Version Vector)Development/Architecture 2026. 8. 9. 21:28
1. 배경: 리더가 없는 복제리더 기반 복제는 순서가 하나이므로 충돌이라는 개념 자체가 없다. 대신 대가가 있다. 리더가죽으면 선출까지 쓰기가 멈추고, 지리적으로 분산된 환경에서는 모든 쓰기가 리더까지 왕복해야한다. 그래서 반대편 설계가 있다. 아무 레플리카나 쓰기를 받는다(leaderless / multi-master).Amazon Dynamo 논문이 대표이고 Riak, Cassandra, DynamoDB가 이 계열이다. 가용성은극대화되지만 새로운 문제가 생긴다. 같은 데이터가 서로 다른 노드에서 동시에 갱신되면,누가 최신인지 어떻게 아는가?타임스탬프(LWW)로는 왜 안 되는가"타임스탬프 붙여서 늦은 쪽이 이긴다"(Last-Write-Wins)는 두 가지 문제가 있다. 첫째, 서버들의물리 시계는 완벽히..