N° 01 — 목록
'Data & Platform/Event Streaming' (13)
-
Data & Platform/Event StreamingKafka - 07. log retention
retention과 compaction — 메시지가 언제, 어떻게 사라지는가운영 6개월차에 디스크가 가득 찼다. Kafka는 메시지를 읽어도 지우지 않는다(장 01·02)고 배웠는데, 그럼 무한정 쌓이는 건가? — 그렇지 않다. topic마다 "언제, 무엇을 지울지" 정책(retention/compaction)을 둬서 오래된 데이터를 정리한다. 하지만 이 정책을 잘못 이해하면, 의도치 않게 중요한 데이터를 날리거나 반대로 디스크를 꽉 채운다.첫 번째 함정부터 짚고 가자: "compaction"은 압축(zip)이 아니다. 같은 key의 옛 메시지를 버리는 것이다. 이 용어 혼동 하나가 운영 착오를 자주 만든다 — "압축 켰으니 용량 절약되겠지"라고 생각했는데, 사실은 key 기반 데이터 보존 정책을 바꾼 ..
-
Data & Platform/Event StreamingKafka - 06. replication
broker가 죽어도 데이터가 안 사라지는 이유 — 복제와 ISRbroker 한 대에 모든 데이터를 두면 그 broker가 죽는 순간 전부 날아간다. 그래서 Kafka는 partition을 복제(replication)한다. 하지만 "복제했다"로 끝이 아니다 — 얼마나 복제해야 안전한지, 복제가 안 끝난 메시지는 consumer에게 보여야 하는지, 리더가 죽으면 누가 이어받는지를 정의해야 한다. Kafka의 답은 ISR(In-Sync Replicas)이라는 동적 쿼럼과 HW(high watermark)라는 commit 경계다.이 두 장치가 만드는 핵심 보장은 한 줄이다: f+1개 복제본이 f개 장애까지, 이미 commit된 메시지는 잃지 않는다. replication.factor=1로 두다가 broker ..
-
Data & Platform/Event StreamingKafka - 05. consumer group
consumer group — 병렬로 읽되 중복은 막는 팀orders topic에 주문이 초당 수만 건 쏟아진다. consumer 하나로는 다 못 읽는다. consumer를 여럿 띄워 병렬로 읽고 싶다 — 하지만 같은 메시지를 두 consumer가 동시에 읽으면 중복이 생긴다. 이 모순을 푸는 장치가 consumer group이다. 여러 consumer가 topic의 partition을 서로 겹치지 않게 나눠 읽는 팀.여기서 "partition을 겹치지 않게 나눈다"가 단순한 규칙이 아니다 — consumer가 합류하고 이탈할 때마다 partition을 다시 나눠야 하고(rebalance), 그 과정에서 구형 프로토콜은 모든 consumer를 멈추게 한다(stop-the-world). Kafka 4.0의..
-
Data & Platform/Event StreamingKafka - 04. consumer
consumer — 읽었다고 끝이 아니다, commit이 끝이다consumer가 poll()을 호출해 batch를 받아왔다. 처리를 시작했다. 그런데 처리 도중 프로세스가 크래시 났다 — auto-commit이 켜져 있었다면, 방금 받은 batch는 이미 "읽었다"고 표시돼 있어서, 재시작해도 그 batch는 다시 오지 않는다. 메시지가 조용히 사라진다. Kafka consumer 설계에서 가장 흔하게 만나는 유실 지점이다.이 함정의 뿌리는 "읽기 = 소비 완료"라는 착각이다. Kafka에선 읽기(poll)와 소비 완료(commit)가 분리돼 있고, 그 사이에 애플리케이션 처리가 끼어든다. auto-commit은 이 둘을 "읽자마자 commit"으로 합쳐버려 처리 실패 시 유실을 만든다. 신뢰성이 필요하..
-
Data & Platform/Event StreamingKafka - 03. producer
producer — send가 반환됐다고 도달한 게 아니다주문 API가 producer.send(orderEvent)를 호출했다. 메서드는 즉시 반환됐다. 그런데 이 순간 메시지는 broker에 도달한 게 아니다 — accumulator라는 배치 버퍼에 쌓여 있을 뿐이고, 배경 스레드가 나중에 보낸다. "send가 반환됐으니 안전하겠지"라고 가정하면, 장애 순간에 accumulator에 남아 있던 메시지들이 전부 날아간다. 이게 producer를 다룰 때 가장 먼저 부딪히는 함정이다.producer는 애플리케이션에 내장되는 클라이언트다. 별도 서버가 아니라 주문 API·배치 잡·로그 수집기 같은 앱 프로세스 안에서 동작한다. 비동기 send, batch, acks, idempotent producer가 ..
-
Data & Platform/Event StreamingKafka - 02. topic and partition
topic과 partition — 메시지를 어디에, 어떻게 쌓을 것인가쇼핑몰에서 주문이 들어온다. 이 주문 데이터를 어디에 쌓을까? Kafka에선 topic이라는 곳에 넣는다. "주문" topic, "클릭 로그" topic, "결제" topic처럼 용도별로 topic을 나눠 메시지를 분류한다. 그런데 주문이 초당 수만 건씩 쏟아지면 topic 하나로는 감당이 안 된다 — 그래서 topic을 여러 조각으로 쪼개는데, 그 조각이 partition이다.여기서 대부분이 처음 만나는 함정이 하나 있다. partition 수는 나중에 늘릴 수 있지만, 늘리는 순간 같은 key의 메시지가 다른 partition으로 흩어진다. "사용자 A의 주문은 항상 같은 partition에 있을 것"이라는 가정이 한 번에 깨진다...