N° 01 — 목록
'분류 전체보기' (197)
-
Data & Platform/Event StreamingKafka - 12. operations
운영과 보안 — 클러스터 건강 유지와 "누가 뭘 할 수 있는가" 통제Kafka를 기본 설정으로 두면 통신이 평문(PLAINTEXT)이고, 아무나 topic에 쓸 수 있다. 개발/테스트에만 허용되는 상태다. 프로덕션에선 (1) 클러스터가 건강한지 감시하고, (2) 누가 접속하고 무엇을 할 수 있는지 통제해야 한다.이 두 축은 독립이 아니다 — 보안이 없으면 누구나 topic을 지울 수 있고, 모니터링이 없으면 broker 장애를 알 수 없다. 프로덕션 운영은 SASL_SSL/SCRAM 설정, 인증서, ACL, JMX 모니터링, KRaft quorum 관리가 얽힌 종합 작업이다. 각 설정이 어떤 위협을 막고 어떤 비용이 드는지를 짚으면서, broker와 client에 보안을 설정하는 단계를 한 호흡으로 추적..
-
Data & Platform/Event StreamingKafka - 11. kafka streams
Kafka Streams — topic의 데이터를 가공(집계·조인·창)하는 라이브러리orders topic에 주문 이벤트가 계속 쌓인다. "5분 단위로 주문 금액을 합산하고 싶다" — 직접 consumer + window 로직 + 상태 저장을 짜면, 장애 시 상태 복구·재처리가 지옥이다. Kafka Streams는 집계·조인·창(windowing) + 상태 저장(state store) + 장애 복구(changelog)를 프레임워크가 알아서 처리한다."직접 짜면 왜 지옥인가"부터 보면 Streams의 가치가 선명해진다 — consumer poll 루프, 상태 저장(RocksDB 연동), 장애 시 상태 복구, partition 재분배 시 상태 이관, exactly-once 보장을 손수 구현하면 수천 줄의 보..
-
Data & Platform/Event StreamingKafka - 10. kafka connect
Kafka Connect — 코드 없이 DB·파일과 Kafka 사이 데이터를 옮기다"DB의 주문 데이터를 Kafka로 옮기고 싶다." producer 코드를 직접 짤 수도 있지만 — 재시작 시 어디까지 읽었는지, 병렬로 어떻게 나눌지, 장애 시 복구를 다 손봐야 한다. Kafka Connect는 이 공통 작업을 프레임워크가 대신 처리한다. 커넥터 설정 하나로 데이터 파이프라인이 완성된다."코드를 안 짜면 뭘 어떻게 설정하지?"가 처음 드는 의문이다. 답은 connector 설정 파일(JSON/properties) + REST API다. 어디서 어디로, 무엇을 옮길지를 선언적으로 정의하면 Connect가 나머지(병렬 분할, 장애 복구, offset 관리)를 알아서 한다. 설정 파일 구조, REST API로..
-
Data & Platform/Event StreamingKafka - 09. schema registry
Schema Registry — 메시지 구조를 안전하게 바꾸는 방법producer가 {"id":1,"name":"alice"}를 보내고 consumer가 읽는다. 그런데 producer가 필드를 추가했다 — {"id":1,"name":"alice","email":"..."}. 옛 consumer는 이걸 못 읽고 크래시난다. Kafka는 value를 바이트로만 저장하고 구조(schema)를 모른다. producer와 consumer가 각자 해석하다가 구조가 어긋나면 깨진다. 이걸 푸는 게 Schema Registry다.여기서 한 가지 전제를 먼저 고정해야 한다 — Schema Registry는 Confluent 확장이며 Apache Kafka core가 아니다. 별도 설치가 필요하고, ASF 공식 문서가 ..
-
Data & Platform/Event StreamingKafka - 08. delivery semantics
"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"하는 설계 패턴의 결과다.전달 보장은 at-most-once, at-least-onc..
-
Data & Platform/Event StreamingKafka - 07. log retention
retention과 compaction — 메시지가 언제, 어떻게 사라지는가운영 6개월차에 디스크가 가득 찼다. Kafka는 메시지를 읽어도 지우지 않는다(장 01·02)고 배웠는데, 그럼 무한정 쌓이는 건가? — 그렇지 않다. topic마다 "언제, 무엇을 지울지" 정책(retention/compaction)을 둬서 오래된 데이터를 정리한다. 하지만 이 정책을 잘못 이해하면, 의도치 않게 중요한 데이터를 날리거나 반대로 디스크를 꽉 채운다.첫 번째 함정부터 짚고 가자: "compaction"은 압축(zip)이 아니다. 같은 key의 옛 메시지를 버리는 것이다. 이 용어 혼동 하나가 운영 착오를 자주 만든다 — "압축 켰으니 용량 절약되겠지"라고 생각했는데, 사실은 key 기반 데이터 보존 정책을 바꾼 ..