개발자 노트

이번 글에서는 MongoDB에 대한 글을 처음으로 작성하려고 한다. 개발 중인 프로젝트에서 MongoDB를 사용하고 있는데 너무 오래된 과거 버전을 사용하고 있어서 업그레이드를 진행했다. 업그레이드하면서 ReplicaSet 구성, 인증 설정, mongodump/mongorestore를 통한 데이터 백업/복원을 진행했는데 정리를 하고자 한다. 물론 MongoDB 공식 문서에 설명이 잘 나와 있지만 한글로 정리하는 것도 의미가 있을 것 같았다. 작업을 진행할 때, 필자의 글로 전체적인 과정을 습득하고 세부적인 내용은 공식 문서에서 추가로 내용을 검토하는 것을 추천한다. 그리고 MongoDB는 업그레이드할 때, Rolling으로 업그레이드를 지원한다. 하지만 업그레이드 지원 버전의 한계가 있어서 너무 오래된 ..

업무가 많아서 기술 정리를 하지 못했었는데 오랜만에 블로그 글을 작성해 본다. 이번글에서는 MirrorMaker2(이하 MM2) 관련 내용을 소개한다. 최근 MM2로 미러링을 하던 카프카 클러스터의 이전을 계획하면서 MM2가 미러링 처리한 시점을 확인해야 했고, 이전 시점에 MM2에 처리한 토픽의 오프셋 이후부터 다시 미러링하도록 작업해야 했다. 그래서 MM2에서 미러링 처리한 데이터의 토픽/오프셋을 어떻게 관리하고, MM2를 새로 시작하거나 이전할 때 앞서 처리한 오프셋의 위치를 확인해 다시 미러링을 하는지 분석하게 되었다. 이번 글에서는 MM2 이전을 하는 과정에 포커스를 맞추지만 MM2의 오프셋 관리방식도 같이 소개한다. 1. MM2 구동시 시작되는 Connector MM2는 기본적으로 Kafka ..

오랜만에 글을 작성한다. 그래서 간단한 내용을 하나 소개한다. 테스트를 위해서 카프카에 임의의 트래픽을 발생할 수 있는데 kafka-producer-perf-test.sh command를 사용하면 된다. 이것을 살펴보자. kafka-producer-perf-test.sh을 파라미터 없이 실행하면 옵션 항목을 볼 수 있다. 주요한 옵션만 살펴보자. 파라미터 설명 --topoic 데이터를 보낼 토픽 --num-records 전송할 메세지의 개수 --throughput 대략적인 messages/sec으로 처리량을 조절한다. -1을 설정할 경우 처리량 조정없이 계속 보낸다. --producer-props 프로듀서 설정. 필수 설정인 bootstrap.servers 등을 넣을 수 있다. --record-size ..

이번글에서는 Burrow에 관한 글을 쓰고자 한다. Burrow는 Kafka consumer group의 LAG을 모니터링 할 때, 가장 많이 사용하는 어플리케이션 중에 하나이다. Burrow에 대한 설명과 간단한 사용법에 대한 내용은 다른 글들이 많이 존재해서 필자는 최근 인증과 관련된 설정 추가와 관련해서 추가 검토했던 사항 위주로 설명하고자 한다. 그렇다고 Burrow에 대한 설명을 제외하면 기술할 내용에 대한 이해가 떨어질 수 있어 간략한 설명은 한다. 1. Burrow란? Burrow는 링크드인에서 처음 개발한 오픈소스이다. Github readme의 처음 제목을 보면 다음과 같다. Burrow - Kafka Consumer Lag Checking Burrow의 사용 목적은 Consumer La..

이번글에서는 SCRAM 인증에 대해서 살펴보고자 한다. 앞선 2개의 글(SASL/PLAIN, Kerberos) 에서 SASL 인증을 사용했을 때, 대략적인 설정 방법은 비슷하기 때문에 참고하면 좋다. 그래서 이 글에서는 SCRAM의 특징과 다른 인증과의 차이점이 무엇인지 살펴보면 의미가 있을 것 같다. 1. SCRAM? SCRAM은 Salted Challenge Response Authentication Mechanism의 약칭이다. 간단히 설명하면 전통적인 사용자/비밀번호를 통해 인증을 처리하는데 비밀번호를 암호화해서 저장하는 방식이다. 카프카에서는 SCRAM-SHA-256과 SCRAM-SHA-512를 지원한다. 카프카는 SCRAM의 기본 저장소로 주키퍼를 사용한다. 실습을 진행하면서 주키퍼에 어떻게 ..

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

이번 글은 하둡 생태계에서 많이 사용되는 파일 포맷인 Parquet (이하 파케이)에 대해 정리한다. 글의 포함된 설명 중 많은 부분은 하둡 완벽 가이드에서 발췌한 것임을 밝힌다. 파케이는 columnar 저장 포맷이다. 구글에서 발표한 논문 Dremel: Interactive Analysis of Web-Scale Datasets를 토대로 Twitter, Cloudera에서 같이 개발했다. columnar 포맷을 기존에 많이 사용하던 Row 기반 포맷과 비교하면 이해하는데 도움이 된다. 전통적인 row 기반 저장 방식은 A1, B1, C1과 같이 같은 row 값이 연속적으로 저장된다. 반면에 columnar 저장 방식은 A1, A2, A3과 같이 컬럼의 데이터가 연속된 구조로 저장한다. columnar..

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