튼튼발자 개발 성장기🏋️

아주 예전에는 쇼핑몰에서 며칠 있다가 쿠폰 알림이 와도 그런가 보다 했는데, 이 블로그 글을 읽고 나니까 이제는 실시간으로 맞춤 알림이 오지 않으면 뭔가 이상하다고 느끼게 된 이유를 알겠다. 요즘 사용자들은 서비스에 더 민감하고 빠른 반응을 기대하는 것 같다. 그래서 이 글에서 강조하고 있는 ODI의 한계와 CDC로 마이그레이션하는 과정이 재미졌다. 나도 2년 전에 Kafka CDC 기반으로 데이터베이스 싱크를 맞춘 경험이 있는데, 그 때 삽질(?)했던게 새록새록 떠올랐다.CDC와 OGG, Kafka 조합의 의미나도 데이터 동기화 프로젝트를 했던 적이 있었는데 역시 배치는 데이터 일관성 맞추기가 참 힘들었고 사용자의 행동이 서비스에 바로바로 반영이 안 돼서 불편한 부분이 존재한다. 그런데 여기선 OGG로..

이전에는 CDC 기반 Kafka를 통한 데이터 동기화의 동작 원리를 알아보았다.이번에는 Kafka와 Kafka connect를 Dockerizing해보겠다. 들어가기에 앞서 source connector에 사용될 사용자는 아래와 같은 권한이 필요하다.grant select, reload, replication client, replication slave on *.* to '{username}'@'%'; 아래 docker-compose.yaml 파일 내용을 살펴보자services: kafdrop: image: obsidiandynamics/kafdrop:latest container_name: kafdrop restart: "always" ports: - "9000:900..

1. Debezium MySQL Source Connector란?Debezium은 데이터베이스의 변경 이벤트를 감지하고 이를 Kafka에 발행해주는 CDC 플랫폼인데, MySQL Source Connector는 binlog를 기반으로 작동하여 INSERT, UPDATE, DELETE 이벤트를 실시간으로 처리한다.2. binlog란?MySQL의 binlog(binary log)는 데이터 변경 사항을 이진 포맷으로 기록한 로그파일이다. binlog은 주로 MySQL replication에서 사용된다. 쉽게 말하면 binlog는 데이터가 변경되는 모든 이벤트를 가지고 있기때문에 replication 혹은 데이터 복구 등에 사용될 수 있다.3. Debezium의 동작 원리MySQL에 replication cli..

1. 토픽과 파티션1.1 적정 파티션 개수토픽은 카프카에서 데이터를 관리하는 기본 단위이며, 각 토픽은 여러 개의 파티션으로 구성된다. 파티션은 데이터의 분산을 가능하게 하며, 병렬 처리를 통해 성능을 최적화할 수 있다. 적정 파티션 개수를 결정하는 것은 매우 중요하다. 어떻게 설정하느냐에 따라서 성능을 좌우하기 때문이다. 적절한 파티션 개수는 다음 요소에 따라 결정된다.프로듀서/컨슈머 수: 높은 병렬 처리를 위해 파티션 수를 컨슈머 스레드(혹은 프로세스) 수와 비슷하게 맞추는 것이 이상적이다.데이터 처리량: 파티션 수가 많을수록 병목 현상이 줄어들며, 데이터 처리량이 증가한다.브로커 수: 파티션은 브로커에 분산되므로 브로커의 수에 따라 파티션 수를 조정해야 한다.ISR(In-Sync Replicas)와..

카프카 커넥트(Kafka Connect)는 Apache Kafka의 데이터 통합 프레임워크로, 다양한 데이터 소스와 싱크를 Kafka로 연결하여 실시간으로 데이터를 전송하고 처리할 수 있도록 도와준다. 카프카 커넥트는 소스 시스템(데이터베이스, 파일 시스템, 메시지 큐 등)으로부터 데이터를 Kafka 토픽으로 가져오거나, Kafka 토픽에서 데이터를 추출하여 타겟 시스템(데이터베이스, Elasticsearch, HDFS 등)으로 보낼 수 있다. 카프카 커넥트는 확장 가능하고 유연한 아키텍처를 가지고 있으며, 단일 노드부터 클러스터 환경까지 지원한다. 커넥터와 태스크(Connector and Task)카프카 커넥트에서 커넥터(Connector)는 데이터 통합 작업을 구성하는 기본 단위다. 각 커넥터는 특정..

1. 카프카 스트림즈란? 카프카 스트림즈(Kafka Streams)는 카프카에서 스트리밍 데이터를 실시간으로 처리하고 분석하기 위한 자바 라이브러리다. 기존의 데이터 처리 시스템과는 달리, 카프카 스트림즈는 데이터가 들어오는 즉시 이를 처리하고 결과를 다시 카프카 토픽에 기록할 수 있다. 카프카 스트림즈는 MSA 아키텍처에 적합하며, 높은 처리량과 확장성을 제공한다. 스트림즈 애플리케이션은 스레드를 1개 이상 생성할 수 있으며, 스레드는 1개 이상의 태스크(Task)를 갖는다.이 태스크의 수는 파티션의 수와 일치하도록 한다. 기본적으로 라이브환경에서는 안정적으로 운영할 수 있도록 2개 이상의 서버로 구성하여 스트림즈 애플리케이션을 운영한다.1.1 KStreamsKStreams는 카프카 스트림즈에서 가장 ..

카프카 클라이언트는 카프카 브로커와 상호 작용하기 위한 다양한 API를 제공한다. 클라이언트는 프로듀서, 컨슈머, 관리자 등 역할에 따라 세분화되어 있으며, 각 클라이언트는 특정 기능을 수행한다. 이번 포스트에서는 이들 클라이언트가 어떻게 동작하며, 어떤 기능을 제공하는지에 대한 내용을 작성한다.Producer APIProducer API는 데이터를 카프카 브로커에 보내는 역할을 한다. 데이터를 생성하여 특정 토픽에 메시지를 발행하는 역할을 하며, 다양한 설정 옵션을 통해 메시지 전송의 신뢰성, 성능, 순서를 조정할 수 있다.[그림 1]과 같이 프로듀서가 send()를 호출한다고해서 바로 전달되는 것이 아니다. 파티셔너로부터 어떤 토픽의 파티션으로 전달할지 정해진다. 현재는 기본 파티셔너는 Uniform..

카프카 브로커 · 클러스터 · 주키퍼Apache Kafka는 분산형 스트리밍 플랫폼으로, 대량의 데이터를 빠르고 신뢰성 있게 처리할 수 있는 기능을 제공한다. Kafka는 브로커, 클러스터 그리고 주키퍼로 구성된다. 데이터 저장, 전송데이터 저장: Kafka에서 데이터는 주로 토픽(topic)이라는 단위로 저장된다. 토픽은 데이터 스트림의 카테고리라고도 할 수 있다. 각 토픽은 파티션(partition)으로 나뉘며, 파티션은 순차적으로 레코드(record)를 저장한다. 이때 각 레코드는 고유한 오프셋(offset)을 가진다. 파티션을 이용하여 데이터 저장의 병렬 처리가 가능해진다. 보통 파티션 개수만큼 컨슈머를 생성하여 병렬처리한다.데이터 전송: Kafka 브로커는 프로듀서(producer)로부터 데이터..