MirrorMaker 2 — 클러스터 경계를 넘는 복제, 그리고 offset 동기화의 함정서울 리전의 Kafka 클러스터가 장애 났다. DR 사이트(도쿄)에 복제해둔 토픽 데이터는 살아 있다. 하지만 장애 복구팀이 가장 먼저 듣는 질문은 이것이다: "consumer offset은요?" 데이터는 복제됐지만, consumer 그룹이 어디까지 읽었는지는 복제되지 않았다. 수천 개의 partition에 대해 consumer가 마지막으로 읽은 위치를 모른다 — 백로그를 처음부터 다시 처리하거나, 하루 전 체크포인트로 수동 복구해야 한다.이것이 MirrorMaker 1 시절의 현실이었다. MirrorMaker 2(MM2)는 이 문제를 근본적으로 다시 설계했다 — 데이터만 복제하는 것이 아니라, consumer of..
운영과 보안 — 클러스터 건강 유지와 "누가 뭘 할 수 있는가" 통제Kafka를 기본 설정으로 두면 통신이 평문(PLAINTEXT)이고, 아무나 topic에 쓸 수 있다. 개발/테스트에만 허용되는 상태다. 프로덕션에선 (1) 클러스터가 건강한지 감시하고, (2) 누가 접속하고 무엇을 할 수 있는지 통제해야 한다.이 글은 Kafka 운영의 두 축과, 실제로 보안을 어떻게 적용하는지(SASL_SSL/SCRAM 설정, 인증서, ACL)까지 다룬다. 읽고 나면 broker와 client에 보안을 설정할 수 있다.운영의 두 축클러스터 건강 — broker가 살아있고, 복제가 따라잡고, 리더가 정상인가.보안 — 인증(누가), 인가(뭘 할 수 있는가), 암호화(통신 노출 여부).클러스터 건강 — KRaft와 복제 감..
Kafka Streams — topic의 데이터를 가공(집계·조인·창)하는 라이브러리orders topic에 주문 이벤트가 계속 쌓인다. "5분 단위로 주문 금액을 합산하고 싶다" — 직접 consumer + window 로직 + 상태 저장을 짜면, 장애 시 상태 복구·재처리가 지옥이다. Kafka Streams는 집계·조인·창(windowing) + 상태 저장(state store) + 장애 복구(changelog)를 프레임워크가 알아서 처리한다.이 글은 Streams가 뭔지부터 시작해, 실제로 앱을 어떻게 만들고 실행하는지(Maven 설정, topology 코드, 실행)까지 다룬다. 읽고 나면 간단한 스트림 처리 앱을 만들 수 있다.Streams란 — 앱에 내장되는 스트림 처리 라이브러리Kafka S..
Kafka Connect — 코드 없이 DB·파일과 Kafka 사이 데이터를 옮기다"DB의 주문 데이터를 Kafka로 옮기고 싶다." producer 코드를 직접 짤 수도 있지만 — 재시작 시 어디까지 읽었는지, 병렬로 어떻게 나눌지, 장애 시 복구를 다 손봐야 한다. Kafka Connect는 이 공통 작업을 프레임워크가 대신 처리한다. 커넥터 설정 하나로 데이터 파이프라인이 완성된다.이 글은 Connect가 뭔지부터 시작해, 실제로 어떻게 구성하고 실행하는지(설정 파일, connector JSON, REST API 관리)까지 다룬다. 읽고 나면 "파일→Kafka→파일" 파이프라인을 직접 구성할 수 있다.Connect란 — 커넥터 기반 데이터 파이프라인 프레임워크Connect는 데이터를 Kafka와 외..
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-..
Archive
MirrorMaker 2 — 클러스터 경계를 넘는 복제, 그리고 offset 동기화의 함정서울 리전의 Kafka 클러스터가 장애 났다. DR 사이트(도쿄)에 복제해둔 토픽 데이터는 살아 있다. 하지만 장애 복구팀이 가장 먼저 듣는 질문은 이것이다: "consumer offset은요?" 데이터는 복제됐지만, consumer 그룹이 어디까지 읽었는지는 복제되지 않았다. 수천 개의 partition에 대해 consumer가 마지막으로 읽은 위치를 모른다 — 백로그를 처음부터 다시 처리하거나, 하루 전 체크포인트로 수동 복구해야 한다.이것이 MirrorMaker 1 시절의 현실이었다. MirrorMaker 2(MM2)는 이 문제를 근본적으로 다시 설계했다 — 데이터만 복제하는 것이 아니라, consumer of..
운영과 보안 — 클러스터 건강 유지와 "누가 뭘 할 수 있는가" 통제Kafka를 기본 설정으로 두면 통신이 평문(PLAINTEXT)이고, 아무나 topic에 쓸 수 있다. 개발/테스트에만 허용되는 상태다. 프로덕션에선 (1) 클러스터가 건강한지 감시하고, (2) 누가 접속하고 무엇을 할 수 있는지 통제해야 한다.이 글은 Kafka 운영의 두 축과, 실제로 보안을 어떻게 적용하는지(SASL_SSL/SCRAM 설정, 인증서, ACL)까지 다룬다. 읽고 나면 broker와 client에 보안을 설정할 수 있다.운영의 두 축클러스터 건강 — broker가 살아있고, 복제가 따라잡고, 리더가 정상인가.보안 — 인증(누가), 인가(뭘 할 수 있는가), 암호화(통신 노출 여부).클러스터 건강 — KRaft와 복제 감..
Kafka Streams — topic의 데이터를 가공(집계·조인·창)하는 라이브러리orders topic에 주문 이벤트가 계속 쌓인다. "5분 단위로 주문 금액을 합산하고 싶다" — 직접 consumer + window 로직 + 상태 저장을 짜면, 장애 시 상태 복구·재처리가 지옥이다. Kafka Streams는 집계·조인·창(windowing) + 상태 저장(state store) + 장애 복구(changelog)를 프레임워크가 알아서 처리한다.이 글은 Streams가 뭔지부터 시작해, 실제로 앱을 어떻게 만들고 실행하는지(Maven 설정, topology 코드, 실행)까지 다룬다. 읽고 나면 간단한 스트림 처리 앱을 만들 수 있다.Streams란 — 앱에 내장되는 스트림 처리 라이브러리Kafka S..
Kafka Connect — 코드 없이 DB·파일과 Kafka 사이 데이터를 옮기다"DB의 주문 데이터를 Kafka로 옮기고 싶다." producer 코드를 직접 짤 수도 있지만 — 재시작 시 어디까지 읽었는지, 병렬로 어떻게 나눌지, 장애 시 복구를 다 손봐야 한다. Kafka Connect는 이 공통 작업을 프레임워크가 대신 처리한다. 커넥터 설정 하나로 데이터 파이프라인이 완성된다.이 글은 Connect가 뭔지부터 시작해, 실제로 어떻게 구성하고 실행하는지(설정 파일, connector JSON, REST API 관리)까지 다룬다. 읽고 나면 "파일→Kafka→파일" 파이프라인을 직접 구성할 수 있다.Connect란 — 커넥터 기반 데이터 파이프라인 프레임워크Connect는 데이터를 Kafka와 외..
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-..
wall
방문 흔적을 남겨주세요. 질문이나 인사 모두 환영합니다.
