개발자 노트

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 카프카 클러스터가 하나로만 유지할 수 있어 여러 카프카 클러스터를 보유했을 경우, 커넥트 클러스터도 여러개를 구축해야 했다. 그런데 커넥트의 컨슈머 설..

카프카 관리자 업무를 진행하면서 가장 많이 받는 질문 중 하나는 "파티션 개수는 몇 개가 적당합니까?"이다. 그래서 이번 글은 Confluent 공동 창업자 중 한명인 Jun Rao가 쓴 How to choose the number of topics/partitions in a Kafka cluster? 라는 블로그 글을 인용해서 파티션 숫자와 관련하여 정리한다. 필자의 글은 Jun Rao의 글을 바탕으로 이해한 부분들을 풀어서 썼기 때문에 해당 주제에 관심이 있는 분들은 Jun Rao의 원문을 다시 읽어보시길 추천한다. 많은 파티션은 높은 처리량을 이끈다. 카프카에 기본적인 지식을 가지고 계신 분이라면 카프카가 분산 처리의 목적으로 설계되었음을 안다. 카프카의 분산 처리를 가능하게 하는 핵심 개념이 토..

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

이번 글에서는 카프카 Producer(이하 프로듀서)의 주요 설정 값이 프로듀서의 아키텍처에서 어떤 역할을 하는지 정리한다. 카프카 문서에서는 각 설정값이 설명으로만 나열되어 있어서 이해하기 어려울 수 있다. 그래서 프로듀서의 주요 컴포넌트를 그림으로 표현하고 각 컴포넌트에서 어떤 설정 값을 사용해서 무슨 역할을 하는지 정리할 필요가 있다. 설정을 정리함에 있어서 카프카 문서를 제일 먼저 참조했지만 참고 문서에 포함한 내용도 추가해서 이해를 높이고자 했다. 1. 프로듀서 설정을 분석하는 이유 프로듀서의 정의를 사전에서 찾아보면 '생산자, 제작자'로 나온다. 카프카에서 프로듀서는 말 그래도 데이터를 생산하는 역할을 한다. 프로듀서의 설정값들은 데이터를 브로커에 발송할 때, 발송하는 데이터의 양/ 주기 및 ..

Kafka Cluster를 관리하다 보면 필요에 의해 Topic을 생성했지만 현재는 사용하지 않아서 삭제할 Topic들을 찾아야 할 때가 있다. Broker 설정 중에 자동으로 Topic을 생성해 주는 auto.create.topics.enable 옵션이 있는데 default 값이 true 이다. auto.create.topics.enable=true의 의미는 Producer에 의해서 메세지를 Broker에 전송했는데, 존재하지 않는 topic에 메세지를 전송한 것이라면 해당 Topic을 자동으로 생성하는 것이다. 그래서 테스트를 위해서 여러 Topic에 무분별하게 계속 메세지를 발송했다면 사용하지 않는 Topic들이 늘어나게 된다. 이런 질문을 할 수 있다. 사용하지 않더라도 그냥 Topic을 남겨둬도..

지난 글에 이어서 Kafka Kerberos 인증 설정과 Client (Producer) 테스트에 대한 내용을 설명한다. 바로 시작해 보자. 1. Kafka Broker 설정 Kafak Broker는 2가지 설정을 수정해야 한다. 인증정보를 적는 JAAS 파일을 추가하고 서버 설정 (server.properties)에서 일부 항목을 추가/수정해야 한다. JAAS 파일의 내용을 먼저 보자. 설정에서 주의깊게 볼 부분은 principal이다. 여기에 지난 글에서 만들었던 Broker 용도 Keytab 파일의 경로를 넣어준다. JAAS 파일의 역할은 시작할 Broker에게 Kerberos principal의 정보를 제공해 주는데 있다. 두 번째는 server.properties에서 수정 사항이다. listen..

이번 글에서는 Kafka의 인증 방식 중 Kerberos를 적용하는 방법을 정리하고자 한다. Kerberos는 Hadoop에서도 많이 사용하는 기술이기에 개념을 이해하는 것도 중요하다. 그리고 Kafka에서는 Kerberos 인증을 어떻게 설정하는지도 실습해보자. 처음에는 하나의 글로 Kerberos 서버준비 + Kafka 연동까지 하려고 했으나 내용이 길어져 2개의 글로 나누어서 정리를 하고자 한다. 참고로 Kafka 인증에 대해 썼던 다른 글도 있으니 참고하면 좋다. [Kafka] 인증 - SASL/PLAIN [Kafka] Configurable SASL callback handler 1. Kerberos Kerberos는 티켓을 기반으로 동작하는 암호화 프로토콜로서 클라이언트/ 서버 사이의 인증을 ..

이번글에서는 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 내부적으로..

카프카의 중요 내부 로직을 분석하고 정리해 보고자 한다. 이번 글에서는 컨트롤러에 대해서 살펴보자. 그럼 컨트롤러란 무엇인가? 컨트롤러의 역할을 먼저 살펴보고 동작방식을 분석하자. A Deep Dive into Kafka Controller from confluent 1. 컨트롤러란 무엇인가?클러스터에서 하나의 브로커가 컨트롤러 역할을 한다. 브로커의 상태 체크. 죽은 브로커가 담당한 파티션의 새 리더 선출. 새롭게 선출된 리더 정보를 모든 브로커에 전달. 이름처럼 컨트롤러는 브로커들을 관리한다. 브로커가 정상적인지 상태를 체크하며 죽은 브로커가 있을 경우, 해당 브로커가 가지고 있던 파티션 리더들을 재분배 한다. 카프카는 데이터의 등록/ 소비를 파티션 리더가 모두 담당하므로 브로커의 상태 체크가 원활하..