개발자 노트

이번 글에서는 Kafka Connect를 쿠버네티스(이하 K8s)에서 구축하기 위해 도커 이미지를 만드는 방법에 대해서 설명하려고 한다. 이 말을 들었을 때, "왜 이미지를 따로 만들지?"라고 생각할 수 있다. 왜냐하면 컨플루언트에서 제공하는 도커 이미지가 있기 때문이다. 하지만 필자는 직접 이미지를 만들기로 했다. 이유는 Kafka Connect 내에 따로 개발한 Connector들을 빌드할 때, 해당 Connector들을 포함한 Kafka Connect 도커 이미지를 만들고 싶었다. 그리고 현재 운영 중인 환경과 동일한 버전으로 구성된 도커 이미지를 만들어서 환경 차이에 따라 혹시 발생할지 모르는 문제를 피하고 싶었기 때문이다. 그럼 도커 이미지를 만드는 내용에 들어가기 앞서 왜 쿠버네티스 환경에서 ..

MirrorMaker2(이하 MM2)는 띄우는데는 여러 방법이 있다. 분산 환경으로 한정하면 2가지 방법이 있다. 그것은 MM2 전용 클러스를 띄우거나 기존 Connect 클러스터에 MM2를 추가하는 것이다. 기존 Connect 클러스터에는 MM2를 추가한다는 표현을 썼는데, MM2가 Source Connector를 구현한 방식으로 개발되었기 때문이다. 이번 글에서는 기존 Connect 클러스터에 MM2 관련 Source Connector를 추가하는 방법에 대해서 설명한다. 1. Connect 클러스터를 활용하는 이유 본격적인 활용 방법에 대해서 설명을 하기 전에 기존 Connect 클러스터를 활용하는 이유에 대해서 설명하고자 한다. 사실 가장 큰 이유는 기존에 운영 중인 Conenct 클러스터가 있다면..

이번글에서는 Connect의 에러처리와 관련하여 정리한다. 에러처리와 관련하여 주요한 업데이트가 2.0과 2.6 버전에서 있었다. 2.6 버전에서의 추가 기능은 2.0의 기능 확장이라고 할 수 있는데, 자체적으로 개발한 plugin의 에러처리에 활용된다. 먼저 2.0 버전에서 처음 나온 개념인 dead queue letter에 대해 알아보자. 1. dead letter queue dead letter queue는 이름에서 유추할 수 있듯이 실패한 레코드를 보관하는 별도의 큐이다. 카프카는 dead letter queue로 원천 데이터가 보관된 토픽이 아닌 별도의 토픽으로 설정한다. 그리고 실패한 레코드의 메타정보도 포함시켜 저장한다. 아래 [그림 1]을 보면 쉽게 이해할 수 있다. 원천 토픽이 레코드 중..

Kafka Connect와 관련되어 가장 중요한 업데이트라고 생각되는 Incremental Cooperative Rebalancing에 대해서 설명한다. 필자가 가장 중요하다고 생각하는 이유는 Connect 운영하면서 제일 심각한 문제로 생각되던 부분이 개선되었기 때문이다. 개선이 된 부분은 컨슈머의 리밸런싱 동작과 연관이 있다. 그럼 변경되기 이전의 동작방식과 비교하면서 Incremental Cooperative Rebalancing를 이해해보자. 1. 2.3.0 이전 Connect 리밴런싱 전략 이번 글에서 설명하는 Incremental Cooperative Rebalancing는 2.3 버전에서 소개되었다. 그럼 그 이전 버전에서는 커넥트 컨슈머의 리밸런싱이 어떻게 이루어졌는지 보자. 먼저 결론을 ..

Kafka Connect(이하 커넥트) 2.3.0 개선사항에 대한 두 번재 글이다. Logging 개선에 대해서 살펴본다. 기존 커넥트의 로그는 커넥트에 포함된 작업의 로그들이 구분되지 않고 뒤섞여서 확인하기 쉽지 않았다. 특히 리밸런스 과정이 일어나면 커넥트가 담당하는 파티션들이 변경되는데 로그가 구분이 안되니 어떤 작업이 진행중인지 명확하게 알 수 없었다. KIP-449: Add connector contexts to Connect worker logs을 통해서 커넥트에 포함된 작업들의 로그를 쉽게 분리해서 볼 수 있다. 적용하는 방법은 간단하다. 기존 connect log4j 설정의 패턴을 다음과 같이 바꾸면 된다. # 과거 버전 설정 log4j.appender.stdout.layout.Conver..

Kafka 2.3.0 버전에서는 Connect(이하 커넥트) 관련 개선사항이 많았다. 관련 내용을 계속 정리해 갈 예정인데, 첫 번째 글로 KIP-458: Connector Client Config Override Policy에 대해서 정리한다. KIP(Key Improvement Proposals) 문서 제목에서 알 수 있듯이 Connector에 포함된 Client(Producer, Consumer)의 설정을 override 할 수 있게 되었다. 필자가 해당 내용에 대해서 관심을 갖게 된 이유는 커넥트에 포함된 Sink Connector들의 Source 카프카 클러스터가 하나로만 유지할 수 있어 여러 카프카 클러스터를 보유했을 경우, 커넥트 클러스터도 여러개를 구축해야 했다. 그런데 커넥트의 컨슈머 설..

이번글은 Kafka Connect를 distributed mode로 사용할 때 필자가 실수했던 내용을 공유하는 목적이다. Kafka Connect는 Standalone, Distributed 2가지의 mode가 있다. 테스트나 로컬에서 데이터를 이동할 때는 Standalone을 사용하지만 대부분의 운영 상황에서는 Distributed mode를 사용하게 된다. 필자의 실수에 대한 내용을 간략히 기술하면 다음과 같다. Custom한 Connector를 개발한 이후, Connect에 plugin을 배포하고 실행했다. REST API로 하나의 Job을 실행했다. 정상적으로 동작했다. 여러개의 Job의 동작 유무를 확인하기 위해 추가로 Job을 실행했다. 에러가 발생 에러의 내용은 다음과 같다. org.apac..

이번글에서는 2019-11-20 날짜에 confluent 블로그에 게시된 글을 토대로 ksqlDB를 전반적으로 소개하고자 한다. 아래 글의 내용은 대부분 confluent 블로그의 내용을 이해한 만큼 정리한 것이다. 내용에서 ksqlDB의 내부 아키텍처 부분은 제외했는데 ksqlDB를 테스트해보고 아키텍처 설명과 함께 다른 글로 정리하려고 한다. ksqlDB에서 특징을 2가지로 구분해서 설명한다. Pull queries, Connector Management. Feature 1 : Pull queries 지속적인 스트림 형태로 들어오는 데이터에서 특정 키 값으로 조회하려는 것은 불가능하다. 지속적으로 변화하는 스트림에서 데이터를 밀어낸다는 의미로 push queries라는 명칭으로 부르기로 한다. 이러한..

이번 글에서는 Kafka Connect 관련된 내용을 소개하고자 한다. Connect에 대한 전반적인 개요 글은 아니고 Sink Connector에서 offset 처리에 대한 내용이다. Sink Connector?Offset 관련 설명을 하기 전에 Sink Connector에 대해서는 기본적인 소개가 필요하다. 아래 그림으로 Connect의 전체적인 개념을 쉽게 이해해 보자. Connect는 크게 Source/ Sink Connector로 구성되어 있다. Sink Connector는 그림에서 표시한 부분으로서 Kafka의 데이터를 다른 저장소에 넣는데 사용한다. Sink의 사전적 의미에 '밀어넣다'가 포함되어 있는데 다른 저장소에 데이터를 밀어넣는다고 이해하면 된다. Sink Connector 내부적으로..