Schema Registry — 메시지 구조를 안전하게 바꾸는 방법producer가 {"id":1,"name":"alice"}를 보내고 consumer가 읽는다. 그런데 producer가 필드를 추가했다 — {"id":1,"name":"alice","email":"..."}. 옛 consumer는 이걸 못 읽고 크래시난다. Kafka는 value를 바이트로만 저장하고 구조(schema)를 모른다. producer와 consumer가 각자 해석하다가 구조가 어긋나면 깨진다. 이걸 푸는 게 Schema Registry다.이 글은 Schema Registry가 뭔지부터 시작해, 실제로 어떻게 설정하고 사용하는지(Schema Registry 기동, Avro schema 정의, producer/consumer s..
"Kafka는 exactly-once인가요" — 질문이 틀렸다"Kafka는 exactly-once를 보장하나요?" — Kafka를 배우면 누구나 받는 질문이다. 답은 "무엇의 exactly-once인지에 따라 다르다"다. 단일 partition 쓰기(idempotent)는 exactly-once다. consume-process-produce 패턴(EOS)도 exactly-once다. 하지만 시스템 외부(DB)까지는 아니다. 이 질문이 틀린 이유는 "exactly-once"를 메시지 자체의 마법 같은 속성으로 생각하기 때문이다. 실제로는 "출력 메시지와 consumer offset을 한 트랜잭션으로 묶어 원자 commit"하는 설계 패턴의 결과다.이 글은 Kafka의 세 가지 전달 보장 — at-most-..
retention과 compaction — 메시지가 언제, 어떻게 사라지는가Kafka는 메시지를 읽어도 지우지 않는다(장 01·02). 그럼 디스크는 계속 찰 수밖에 없나? 아니다 — topic마다 "언제, 무엇을 지울지" 정책(retention/compaction)을 둬서 오래된 데이터를 정리한다. 이 글은 그 두 가지 규칙과 실제 설정 방법을 다룬다.주의할 점부터: "compaction"은 압축(zip)이 아니다. 같은 key의 옛 메시지를 버리는 것이다. 이 용어 혼동이 운영 착오를 자주 만든다.메시지는 영원히 남지 않는다 — 왜 retention이 필요한가Kafka topic은 로그라 메시지가 계속 쌓인다. 하지만 디스크는 유한하다. 그래서 topic마다 정리 정책을 둔다. 두 가지:delete ..
broker가 죽어도 데이터가 안 사라지는 이유 — 복제와 ISRbroker 한 대에 모든 데이터를 두면 그 broker가 죽는 순간 전부 날아간다. 그래서 Kafka는 partition을 복제(replication)한다. 하지만 "복제했다"로 끝이 아니다 — 얼마나 복제해야 안전한지, 복제가 안 끝난 메시지는 consumer에게 보여야 하는지, 리더가 죽으면 누가 이어받는지를 정의해야 한다. Kafka의 답은 ISR(In-Sync Replicas)이라는 동적 쿼럼과 HW(high watermark)라는 commit 경계다.이 글은 Kafka의 내결함성 모델 — f+1개 복제본이 f개 장애까지, 이미 commit된 메시지는 잃지 않는다는 보장 — 을 다룬다. replication.factor=1로 두다가..
consumer group — topic을 여러 consumer가 나눠 읽는 팀orders topic에 주문이 초당 수만 건 쏟아진다. consumer 하나로는 다 못 읽는다. consumer를 여럿 띄워 병렬로 읽고 싶다 — 하지만 같은 메시지를 두 consumer가 동시에 읽으면 중복이 생긴다. 이걸 해결하는 게 consumer group이다. 여러 consumer가 topic의 partition을 서로 겹치지 않게 나눠 읽는 팀이다.이 글은 consumer group이 뭔지, 어떻게 partition을 나누는지, consumer가 들락날락할 때 일어나는 rebalance와 그 비용, 그리고 실제로 어떻게 구성하고 관리하는지까지 다룬다.consumer group이란 — partition을 나눠 읽는 ..
consumer — topic에서 메시지를 읽는 주체orders topic에 주문 이벤트가 쌓인다. 이제 그 메시지를 읽어 처리해야 한다 — 주문 처리 서비스가 읽어가고, 분석 서비스가 따로 읽는다. 이 "topic에서 메시지를 읽는 주체"가 consumer다.이 글은 consumer가 뭔지부터 시작해, 실제 설정과 코드, auto-commit의 위험, LAG 모니터링까지 다룬다.consumer란 — topic에서 메시지를 읽는 클라이언트consumer도 producer처럼 앱에 내장되는 클라이언트 라이브러리다.Java consumer 기본 코드// 1. 설정Properties props = new Properties();props.put("bootstrap.servers", "localhost:9092..
Archive
Schema Registry — 메시지 구조를 안전하게 바꾸는 방법producer가 {"id":1,"name":"alice"}를 보내고 consumer가 읽는다. 그런데 producer가 필드를 추가했다 — {"id":1,"name":"alice","email":"..."}. 옛 consumer는 이걸 못 읽고 크래시난다. Kafka는 value를 바이트로만 저장하고 구조(schema)를 모른다. producer와 consumer가 각자 해석하다가 구조가 어긋나면 깨진다. 이걸 푸는 게 Schema Registry다.이 글은 Schema Registry가 뭔지부터 시작해, 실제로 어떻게 설정하고 사용하는지(Schema Registry 기동, Avro schema 정의, producer/consumer s..
"Kafka는 exactly-once인가요" — 질문이 틀렸다"Kafka는 exactly-once를 보장하나요?" — Kafka를 배우면 누구나 받는 질문이다. 답은 "무엇의 exactly-once인지에 따라 다르다"다. 단일 partition 쓰기(idempotent)는 exactly-once다. consume-process-produce 패턴(EOS)도 exactly-once다. 하지만 시스템 외부(DB)까지는 아니다. 이 질문이 틀린 이유는 "exactly-once"를 메시지 자체의 마법 같은 속성으로 생각하기 때문이다. 실제로는 "출력 메시지와 consumer offset을 한 트랜잭션으로 묶어 원자 commit"하는 설계 패턴의 결과다.이 글은 Kafka의 세 가지 전달 보장 — at-most-..
retention과 compaction — 메시지가 언제, 어떻게 사라지는가Kafka는 메시지를 읽어도 지우지 않는다(장 01·02). 그럼 디스크는 계속 찰 수밖에 없나? 아니다 — topic마다 "언제, 무엇을 지울지" 정책(retention/compaction)을 둬서 오래된 데이터를 정리한다. 이 글은 그 두 가지 규칙과 실제 설정 방법을 다룬다.주의할 점부터: "compaction"은 압축(zip)이 아니다. 같은 key의 옛 메시지를 버리는 것이다. 이 용어 혼동이 운영 착오를 자주 만든다.메시지는 영원히 남지 않는다 — 왜 retention이 필요한가Kafka topic은 로그라 메시지가 계속 쌓인다. 하지만 디스크는 유한하다. 그래서 topic마다 정리 정책을 둔다. 두 가지:delete ..
broker가 죽어도 데이터가 안 사라지는 이유 — 복제와 ISRbroker 한 대에 모든 데이터를 두면 그 broker가 죽는 순간 전부 날아간다. 그래서 Kafka는 partition을 복제(replication)한다. 하지만 "복제했다"로 끝이 아니다 — 얼마나 복제해야 안전한지, 복제가 안 끝난 메시지는 consumer에게 보여야 하는지, 리더가 죽으면 누가 이어받는지를 정의해야 한다. Kafka의 답은 ISR(In-Sync Replicas)이라는 동적 쿼럼과 HW(high watermark)라는 commit 경계다.이 글은 Kafka의 내결함성 모델 — f+1개 복제본이 f개 장애까지, 이미 commit된 메시지는 잃지 않는다는 보장 — 을 다룬다. replication.factor=1로 두다가..
consumer group — topic을 여러 consumer가 나눠 읽는 팀orders topic에 주문이 초당 수만 건 쏟아진다. consumer 하나로는 다 못 읽는다. consumer를 여럿 띄워 병렬로 읽고 싶다 — 하지만 같은 메시지를 두 consumer가 동시에 읽으면 중복이 생긴다. 이걸 해결하는 게 consumer group이다. 여러 consumer가 topic의 partition을 서로 겹치지 않게 나눠 읽는 팀이다.이 글은 consumer group이 뭔지, 어떻게 partition을 나누는지, consumer가 들락날락할 때 일어나는 rebalance와 그 비용, 그리고 실제로 어떻게 구성하고 관리하는지까지 다룬다.consumer group이란 — partition을 나눠 읽는 ..
consumer — topic에서 메시지를 읽는 주체orders topic에 주문 이벤트가 쌓인다. 이제 그 메시지를 읽어 처리해야 한다 — 주문 처리 서비스가 읽어가고, 분석 서비스가 따로 읽는다. 이 "topic에서 메시지를 읽는 주체"가 consumer다.이 글은 consumer가 뭔지부터 시작해, 실제 설정과 코드, auto-commit의 위험, LAG 모니터링까지 다룬다.consumer란 — topic에서 메시지를 읽는 클라이언트consumer도 producer처럼 앱에 내장되는 클라이언트 라이브러리다.Java consumer 기본 코드// 1. 설정Properties props = new Properties();props.put("bootstrap.servers", "localhost:9092..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
