N° 01 — 목록
'partition' (3)
-
Software Architecture/Distributed SystemsDistributed Systems - 02. CAP PACELC
일관성 모델 — 강과 최종 그 사이의 스펙트럼2018년 한 SaaS 회사에서 사용자가 프로필을 수정한 직후 "저장됐다"는 메시지를 받고, 새로고침하니 예전 프로필이 떴다. 사용자는 "저장이 안 됐나?"라고 생각하고 다시 저장했다. 같은 데이터가 두 번 쓰였다. 결제 주소까지 두 번 변경돼, 뒷배송 처리에 며칠이 걸렸다. 원인은 — 쓰기 요청이 마스터 DB에 갔고, 읽기 요청이 읽기 복제본(비동기 복제)에 갔는데, 복제 지연으로 복제본엔 아직 새 데이터가 안 반영됐기 때문이었다. 이런 현상을 "강한 일관성 vs 최종 일관성"이라는 이분법으로 설명하면 핵심이 빠진다. 강도의 스펙트럼이 있고, 그 사이에 여러 모델이 있다. 이 글은 그 스펙트럼을 정리한다.비유로 감 잡기 — 뉴스 전파의 여러 형태어떤 사건이 ..
-
Data & Platform/Event StreamingKafka - 02. topic and partition
topic과 partition — 메시지를 어디에, 어떻게 쌓을 것인가쇼핑몰에서 주문이 들어온다. 이 주문 데이터를 어디에 쌓을까? Kafka에선 topic이라는 곳에 넣는다. "주문" topic, "클릭 로그" topic, "결제" topic처럼 용도별로 topic을 나눠 메시지를 분류한다. 그런데 주문이 초당 수만 건씩 쏟아지면 topic 하나로는 감당이 안 된다 — 그래서 topic을 여러 조각으로 쪼개는데, 그 조각이 partition이다.여기서 대부분이 처음 만나는 함정이 하나 있다. partition 수는 나중에 늘릴 수 있지만, 늘리는 순간 같은 key의 메시지가 다른 partition으로 흩어진다. "사용자 A의 주문은 항상 같은 partition에 있을 것"이라는 가정이 한 번에 깨진다...
-
Data & Platform/Event StreamingKafka - 01. architecture
Kafka는 큐가 아니다 — 영속적 분산 로그가 만든 모든 차이Kafka를 처음 배우는 사람 대부분은 "메시지 큐"라는 설명을 듣고 RabbitMQ처럼 생각한다. 그래서 "소비했는데 왜 데이터가 남지?", "왜 메시지 순서가 섞이지?" 같은 오해에 빠진다. 이 오해의 뿌리는 단 하나다 — Kafka는 소비하면 사라지는 큐가 아니라, 영속적이고 파티션 내 순서가 보장되는 분산 로그다. 이 하나의 차이가 Kafka의 모든 설계(복제, 컨슈머 그룹, retention, 전달 의미론)를 설명한다.이 핵심 추상 — partition = append-only log — 을 중심으로 Kafka가 무엇인지, 왜 그렇게 설계됐는지, 그리고 왜 "빠르다"는 평가가 마법이 아니라 설계의 결과인지를 추적한다. retentio..