개발자 노트

이번글에서는 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]을 보면 쉽게 이해할 수 있다. 원천 토픽이 레코드 중..

이번에는 HBase에 대한 글을 처음으로 쓴다. 필자는 Kafka로 들어온 다양한 데이터를 여러 저장소에 적재하는 기능을 개발하고 있다. 이번에 HBase에 데이터 적재 기능을 추가하게 되었다. 개발을 진행하면서 HBase 활용 측면에서 알아야 하는 기본적인 내용을 정리함으로써 HBase를 도입하려고 하시는 분들에게 참고사항이 되었으면 한다. 1. 아키텍처 먼저 HBase의 아키텍처를 살펴본다. 두 가지 측면으로 나누어서 정리한다. 데이터 구성 HBase 서버 아키텍처 데이터 구성을 알면 HBase로 데이터 적재 시 RowKey, Column Family(이하 컬럼패밀리) 등의 데이터 구조 설계에 도움이 된다. 그리고 HBase의 서버 아키텍처를 알면 클라이언트가 데이터 저장/ 조회할 때의 데이터 흐름을..

스파크 스트리밍에서 데이터 소스로 카프카를 많이 사용한다. 빅 데이터의 스트리밍 처리에서 카프카는 거의 필수로 사용되기 때문이며 스파크 스트리밍이 카프카와의 통합을 잘 지원하기 때문이다. 스파크 스트리밍에서 카프카의 데이터를 가져오는 여러 방법이 있는데 exactly-once를 지원하기 위해 개발된 Direct API for Kafka(이하 직접 모델)를 소개한다. 그리고 기존 리시버 모델과는 무슨 차이가 있는지 살펴보자. 1. 리시버 모델 직접 모델이 나오기 전에 사용되던 리시버 모델이다. 각 executor(이하 익스큐터)에 리시버가 존재하고 리시버에 의해서 카프카의 데이터를 가져온다. 리시버가 카프카 컨슈머가 된다. 내결험성을 위해 리시버는 WAL(Write Ahead Logs)를 기록한다. 데이터..

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

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

이번 글에서는 Amazon에서 제공하는 카프카 관리 서비스인 MSK와 EC2에서 직접 카프카를 설치했을 때의 장단점을 평가한다. 비교를 하게 된 목적은 AWS에서 데이터 처리를 위해 카프카가 필요할 때, 관리형 서비스인 MSK를 쓰면 편리하겠지만 가성비 관점도 포함하여 서비스 선택 시 도움이 되었으면 해서였다. 먼저 MSK를 생성하면 어떤 구조로 이루어져 있는지 보고 동일한 고가용성(HA)으로 EC2에 직접 카프카를 설치하는 방법을 소개한다. 그리고 구축한 MSK, EC2에서 동일한 트래픽의 데이터를 처리할 때 비용 계산을 한다. 마지막으로 운영 효율성 측면에서 비교한다. 1. 아키텍처 1.1 MSK 먼저 MSK의 아키텍처를 보자. MSK도 결국은 카프카이기 때문에 AWS 상에서의 네트워크 구조만 보면 ..

오랜만에 글을 작성한다. 그래서 간단한 내용을 하나 소개한다. 테스트를 위해서 카프카에 임의의 트래픽을 발생할 수 있는데 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의 기본 저장소로 주키퍼를 사용한다. 실습을 진행하면서 주키퍼에 어떻게 ..

나는 매주 시체를 보러 간다 국내도서 저자 : 유성호 출판 : 21세기북스(북이십일) 2019.01.23 상세보기 이 책은 아내가 추천해서 읽었다. 책 제목은 섬뜩한 느낌을 주는데 저자는 '그것이 알고싶다'에 자주 출연하시는 법의학자이다. 위키피디아를 검색해보니 법의학의 정의가 법과 관련된 의학적 문제를 연구하는 과라고 나온다. 책 제목이 말하듯 매주 시체를 보러 갈 수 있는 것은 법의학자로서 시체의 부검을 하고 사인을 분석하는 업무를 하기 때문이다. 글을 이어가기 전에 작가(유성호 교수)의 책 내용을 통한 강의가 TV 프로그램에 있어 참고해보면 좋다. 처음에 책을 읽었을 때는 스릴러 영화를 대하듯이 범죄자의 증거를 찾아 해결하는 이야기를 기대했다. 미제사건을 유능한 형사/ 법의학자가 증거를 찾아내서 해..

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

이번 글에서는 NIO에 포함된 class 중에서 WatchService에 대해서 정리하고자 한다. WatchService는 별도의 thread로 등록된 파일 혹은 디렉토리의 변경사항을 감지해서 이벤트로 리턴한다. 보안 모니터링 및 속성 파일 변경 등 여러 작업에 대한 알림 용도로 사용할 때 유용하다. 예제 코드를 통해서 자세히 살펴보자. WatchService는 FileSystem.newWatchService() 메서드를 통해 생성한다. 생성한 WatchSservice와 감지하고자 하는 종류(ENTRY_MODIFY - 수정)를 등록한다. 무한루프에서 감지를 한다. WathService의 take() 메서드로 변경사항이 발생한 WatchKey를 찾을 때까지 기다린다. WatchKey를 얻으면 WatchEv..