개발자 노트

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..