IT/모바일
애플리케이션 개발부터 파이프라인, 사물인터넷 데이터 허브 구축까지
『실전 아파치 카프카』 중
아파치소프트웨어재단이 2011년 오픈소스로 공개한 카프카Kafka. 카프카는 비즈니스와 구인·구직 기반의 소셜 네트워크 서비스인 링크드인LinkedIn의 수석 엔지니어 제이 크렙스Jay Kreps가 고안했다. 크렙스는 카프카(메시징 시스템) 외에도 볼드모트Voldemort, 분산 키-값 저장소, 삼자Samza, 스트림 처리 시스템 등의 오픈소스 프로젝트를 이끈 인물로, 링크드인에서 개발한 비동기 메시징 시스템에 평소 존경했던 대문호 프란츠 카프카의 이름을 따서 ‘카프카’라 명명했다.
카프카는 글로벌 IT 기업의 상당수가 채택한 분산 스트리밍 플랫폼이다. 링크드인은 여러 대안을 두고 왜 카프카를 독자 개발했는지, 당시 링크드인이 처한 문제는 무엇이고 요구사항은 무엇이었을까? - 편집자 주
프란츠 카프카Hermann Kafaka
오스트리아 헝가리 제국령지금의 체코에서 태어나 독일어를 쓴 유대인 소설가로, 빈센트 반 고흐처럼 예술적 감각이 시대를 앞서간 천재 중의 천재로 평가된다. 출처 : 위키피디아
오스트리아 헝가리 제국령지금의 체코에서 태어나 독일어를 쓴 유대인 소설가로, 빈센트 반 고흐처럼 예술적 감각이 시대를 앞서간 천재 중의 천재로 평가된다. 출처 : 위키피디아
· · ·
링크드인의 고민과 카프카의 탄생
카프카는 2011년 미국 링크드인에서 출발했다. 카프카는 링크드인 웹사이트에서 생성되는 로그를 처리하여 웹사이트 활동을 추적하는 것을 목적으로 개발되었다. 웹사이트에서의 활동은 사용자가 페이지 뷰와 검색 시 키워드 광고의 이용 상황도 포함된다. 웹에서 생성되는 대량의 로그를 분석하여 사용자가 웹에서 하는 활동을 모니터링하고 서비스 개선에 활용하는 것이다. 빅데이터를 어떻게 활용할 것인지가 큰 화제였던 당시 많은 웹 기업에서는 웹사이트에서 생성되는 로그를 활용하기 시작했다. 이러한 상황을 감안하여 지금부터 카프카가 탄생한 배경을 살펴보자. 링크드인이 실현하려는 목표는 다음과 같다.
➊ 높은 처리량으로 실시간 처리한다.
➋ 임의의 타이밍에서 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
➍ 메시지를 잃지 않는다.
➋ 임의의 타이밍에서 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
➍ 메시지를 잃지 않는다.
순서대로 살펴보자.
➊ 높은 처리량으로 실시간 처리한다.
앞서 언급한 바와 같이 링크드인은 전 세계 사용자의 방대한 액세스 데이터를 처리해야 하기에 처리량이 우수해야 한다. 또한 사용자의 활동을 신속하게 파악하거나 사용자의 활동에 따라 즉각 피드백하기 위해서는 사용자의 활동 단위로 실시간 처리가 가능해야 한다. 여기서 말하는 실시간 처리는 수집부터 시작해 수백 밀리초에서 수 초 안에 데이터가 처리되는 처리 방식을 가정하고 있다.
➋ 임의의 타이밍에 데이터를 읽는다.
실시간 처리에 대한 요구가 있는 반면, 링크드인은 기존 시스템에서 수집한 액세스 로그를 일정 시간마다 배치 처리로 취급하고 싶었다. 데이터를 사용하는 타이밍이 반드시 실시간이 아니라 이용 목적에 따라 다를 수 있기 때문에 방대한 데이터를 전달할 때 버퍼 역할도 하기를 원했다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
링크드인에서는 데이터의 발생원인 데이터 소스와 관련된 시스템이 하나가 아니어서 여러 시스템을 통해 데이터를 받아들여야 했다. 또한 이용 목적에 따라 데이터베이스, 데이터 웨어하우스, 아파치 하둡 등 여러 기반이 존재하고 있었다.
당시 대량의 데이터를 처리할 수 있는 기반으로 하둡의 유용성이 인지되어 링크드인도 사용하고 있었는데, 다른 데이터베이스와 데이터 웨어하우스에서 실시하고 있는 처리를 모두 하둡에 이식하는 것은 현실적인 방법이 아니었다. 기존 자산을 활용하기 위해 하둡하고만 연결할 수 있으면 좋다는 것이 아니라, 데이터베이스나 데이터 웨어하우스 등 다른 제품과의 연결을 쉽게 하고 싶다는 요구가 있었다.
➍ 메시지를 잃지 않는다.
취급하는 메시지가 방대하더라도 메시지를 잃어서는 안 됐다. 다만, 링크드인은 당초 이용 목적이 웹에서 사용자 활동을 추적하는 것이었기 때문에 한 건 한 건의 활동을 엄격하게 관리하기보다는 약간의 중복이 있더라도 메시지를 잃지 않는 것이 중요했다. 건마다 엄격하게 관리해 처리 오버헤드processing overhead가 커지는 것은 이미 인식하고 있었으므로, ‘높은 처리량으로 실시간 처리’라는 요건과의 균형을 가미하여 현실적으로 제거해도 좋은 것을 찾아야 했다.
▲ 링크드인 사례
링크드인이 검토한 제품들
링크드인은 이러한 요구를 충족하는 여러 제품을 검토했다. 요구를 부분적으로 충족하는 제품이 있었을지도 모르지만, 포괄적으로 해결할 수 있는 제품은 없었다. 데이터를 전달하거나 데이터를 로드할 때 필요한 제품에는 크게 메시지 큐, 로그 수집, ETL 도구가 있다.
메시지 큐
레코드 단위로 실시간 처리를 할 때 가장 먼저 떠오르는 것이 메시지 큐다. 메시지 큐 제품으로는 IBM의 WebSphere MQ5와 JMSJava Messaging System사양을 따르는 아파치 ActiveMQ, 그 외 RabbitMQ가 있다.
▲ 기존 메시지 큐의 예
메시지 큐에서 제공하는 기능은 제품마다 차이는 있지만 대략 다음과 같이 정리할 수 있다. 모두 링크드인에서 요구하는 사항과 일치하지 않았다.
강력한 전달 보증이 오버 스펙이었다.
IBM WebSphere MQ는 메시지 단위로 트랜잭션을 지원하는 기능이 있다. 하나의 메시지가 정확히 한 번만 전송되는 것을 보증할 수 있다. JMS에도 사양으로 규정되어 있으며, 애플리케이션에서 commit ( )이나 rollback ( )이라고 기술하면 각 커밋/롤백을 할 수 있다. 그러나 링크드인에서 다루는 로그의 성질을 고려하면 엄격한 트랜잭션 관리는 다소 오버 스펙이며, 그보다 ‘높은 처리량’이 우선순위가 더 높은 상황이었다. 메시지는 분실하지 않은 채 송수신 보증을 너무 중시한 나머지 처리량이 나오지 않는 것은 바람직하지 않다는 게 당시의 상황이었다.
스케일 아웃이 용이한 제품이 아니었다.
대량의 메시지를 처리하는 데 1대의 서버로만 대응하는 것은 한계가 있다. 그러므로 처음부터 여러 대의 서버를 사용할 것을 전제할 필요가 있었다. 물론 메시지 큐의 제품에도 클러스터 구성을 취하는 것이 있었지만 실제로는 가용성을 위한 중복 구성에 주안점을 두고 있었다. 처리 성능을 높이는 목적으로 필요 시 노드를 추가할 수 있는 스케일 아웃 기능을 전제로 한 제품이 당시에는 없었다.
메시지가 대량으로 쌓이는 것을 예상하지 않았다.
카프카 등장 이전의 메시지 큐에서는 메시지를 쌓아둘 수 있었는데, 큐에 쌓인 메시지는 즉시 이용되는 것으로 전재했지, 장시간에 걸쳐 대량으로 축적하는 것은 고려하지 않았다.
링크드인은 실시간 처리뿐만 아니라 메시지를 배치 처리하는 것도 가정했다. 일정량의 데이터를 일정 기간마다 묶음으로 받아 데이터 웨어하우스에서 처리하기 위해서는 데이터의 축적 시간이 훨씬 길어야 했지만 기존 메시지 큐로는 감당할 수 없었다.
로그 수집 시스템
실시간으로 데이터를 수집한다는 관점에서 생각할 수 있는 것은 로그 수집을 위한 미들웨어다. 주로 웹 서버 등의 프론트엔드 서버의 로그를 수집하기 위한 것이다. 당시 이 카테고리의 제품으로는 페이스북이 개발한 Scribe와 미국 클라우데라가 개발한 Flume이 있었다.
▲ 기존 로그 수집 기반의 예
기존 로그 수집 기반의 제품은 각 프론트엔드 서버가 로그를 중계용 서버에 전송하고, 거기서 로그를 수집하여 데이터베이스와 분산 파일시스템 HDFSHadoop Distributed File System에 축적한다. 원래 대량의 로그를 처리하는 것을 가정하고 있었기 때문에 분산 환경의 다중 서버 구성으로 이루어져 있다. 그러나 이들 제품을 링크드인에서 사용하기에는 다음과 같은 문제가 있었다.
HDFS로 데이터 축적과 배치 처리만 고려했다.
이들 제품은 대량의 로그를 HDFS에 축적하고 하둡 맵리듀스에서 일괄 처리하는 것이 주목적이다. 링크드인에서도 하둡을 사용하고 있었지만, 동시에 데이터 웨어하우스를 이용한 데이터 분석도 실시하고 있어 모두 하둡에서 동작하도록 애플리케이션을 다시 작성하는 것은 현실적이지 않다.
또한 데이터는 배치 처리로 이용할 뿐만 아니라 실시간으로도 처리하고자 하는 요구가 있었다. 따라서 HDFS를 전제로 하는 로그 집약의 구조로는 불충분하고 동일한 로그 데이터를 다목적으로 활용할 수 있어야 했다.
알기 쉬운 API가 없다.
카프카 이전의 제품은 미들웨어의 구현 사양을 모르면 사용하기 힘들었다. 데이터 송신 쪽과 데이터 수신 쪽에서 사용되는 다양한 제품을 연계하기 위해서는 이용하기 쉬운 송수신 API가 필요했다.
수신하는 쪽이 임의로 메시지를 수신하기 어렵다.
로그 수집 기반 서버에서 그다음 수신 시스템으로 메시지 전달에서, 기존 제품은 로그 수집 기반 서버에서의 ‘push’에 의해 수신자에게 메시지를 전달했다. 그러나 링크드인은 메시지의 다양한 활용이 필요했기 때문에 각 수신자가 자신의 속도나 처리의 빈도에 따라 수신할 수 있어야 했다.
따라서 로그 수집 기반 서버가 그 뒤에 있는 수신 시스템의 수신 여부를 일일이 모니터링하면서 ‘push’하는 것보다는 수신 시스템이 메시지를 갖고 가는 ‘pull’ 방식이 오히려 사용하기 쉽다고 생각했다.
ETL 도구
또 하나의 제품은 데이터 발생원에서 데이터를 추출하고 필요에 따라 변환해 데이터베이스와 데이터 웨어하우스에 로드하는 기능을 갖추고 있는 ETL 도구다.
여기서 ETL 도구로는 DataStage, Interstage, Cosminexus, Informatica PowerCenter, Talend 같은 제품이 있다. ETL 도구에서는 다음과 같은 부분이 요구 사항을 충족하지 못했다고 한다.
데이터를 파일 단위로 다룬다.
카프카 등장 이전에 대량의 데이터를 높은 처리량으로 전달하려면 데이터를 파일 단위 등으로 뭉쳐서 배치 처리로 전송하는 것이 일반적이었다. 이를 실현하기 위해 ETL 도구를 사용했다. 이들 도구는 ‘한 건의 레코드 단위’로 ‘실시간 처리’를 하고 싶다는 링크드인의 요구 사항을 충족하지 않았다.
▲ 기존 ETL 도구의 예
수신하는 쪽이 임의로 메시지를 수신하기 어렵다.
로그 수집과 동일한 논의가 ETL 도구에서도 성립한다. ETL 도구는 데이터를 추출, 변환하여 다른 데이터 저장소에 전달하는 것을 주축으로 하고 있지, 임의의 타이밍에 데이터를 읽을 수 있는 중계 역할까지 하지는 않았다.
· · ·
1.4 카프카를 자체 개발하다
앞서 설명한 것처럼 2009년 당시의 제품들은 링크드인의 요구 사항을 충족시키지 못했기에 카프카 개발을 시작했다. 여기서는 카프카가 링크드인 요구 사항을 어떤 수단으로 실현했는지 살펴보자.
요구 사항
➊ 높은 처리량으로 실시간 처리한다.
➋ 임의의 타이밍에 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
➍ 메시지를 잃지 않는다.
➋ 임의의 타이밍에 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
➍ 메시지를 잃지 않는다.
실현 수단
➊ 메시징 모델과 스케일 아웃형 아키텍처
➋ 디스크로의 데이터 영속화
➌ 이해하기 쉬운 API 제공
➍ 전달 보증
➋ 디스크로의 데이터 영속화
➌ 이해하기 쉬운 API 제공
➍ 전달 보증
주요 대응 관계는 다음 그림과 같다.
▲ 링크드인의 요구 사항과 실현 수단
요구 사항과 실현 수단이 반드시 일대일로 대응하는 것은 아니지만 핵심은 ‘메시징 모델과 스케일 아웃형 아키텍처’다. 아울러 ‘디스크로의 데이터 영속화’도 중요한 고려 사항이었다.
1.4.1메시징 모델과 스케일 아웃
카프카는 다음과 같은 요구 사항을 만족시켜야 했다.
➊ 높은 처리량으로 실시간 처리한다.
➋ 임의의 타이밍에 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
➋ 임의의 타이밍에 데이터를 읽는다.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
이러한 요구 사항을 만족하기 위해 카프카는 메시징 모델을 채택했다. 일반적으로 메시징 모델은 다음 세 가지 요소로 구성된다.
Producer : 메시지 생산자
Broker : 메시지 수집/전달 역할
Consumer : 메시지 소비자
Broker : 메시지 수집/전달 역할
Consumer : 메시지 소비자
▲ 프로듀서, 브로커, 컨슈머
카프카 메시징 모델을 설명하는 데 있어 기존의 메시징 모델인 ‘큐잉(queuing) 모델’과 ‘Publish/Subscribe(펍/섭Pub/Sub) 메시징 모델’ 두 가지 모델을 살펴보자. 카프카는 이 둘의 장점을 갖추고 있다.
큐잉 모델
브로커Broker 안에는 큐가 있다. 프로듀서Producer에서 발행된 메시지가 큐에 담기고, 컨슈머Consumer가 큐에서 메시지를 추출한다. 하나의 큐에 대해 컨슈머가 여러 개일 수 있다. 이 모델은 컨슈머를 여러 개이기 때문에 컨슈머를 늘려 처리량을 확장할 수 있다. 컨슈머가 메시지를 받으면 다른 컨슈머는 해당 메시지를 받을 수 없다.
▲ 큐잉 모델
펍/섭 메시징 모델
이 모델에서는 메시지 생산자인 프로듀서를 ‘퍼블리셔Publisher’, 메시지 소비자의 해당 컨슈머를 ‘서브스크라이버Subscriber’라고 한다. 퍼블리셔가 서브스크라이버에게 직접 메시지를 보내는 것이 아니라 브로커Broker를 통해 전달한다.
퍼블리셔는 누가 그 메시지를 수신하는지 알 수 없고 브로커에 있는 토픽Topic이라고 불리는 카테고리 안에 메시지를 등록한다.
▲ 퍼블리셔와 브로커
한편 서브스크라이버는 여러 개 존재하는 토픽 중 하나를 선택하여 메시지를 받는다. 여러 서브스크라이버가 같은 토픽을 구독하기로 결정한다면, 이들 서브스크라이버는 같은 메시지를 받는다. 다른 토픽에서는 다른 메시지를 받을 수 있다.
▲ 서브스크라이버와 브로커
펍/섭 메시징 모델은 TV나 라디오 전파 수신을 상상하면 이해하기 쉽다. TV 방송국과 라디오 방송국은 개별 가정에서 누가 수신하는지 고려하지 않고 방송 전파를 발신한다. 각 가정은 자신이 보고 싶은 프로그램만 선택하여 방송을 수신한다. 이렇게 하면 발신자와 수신자 연결이 유연한 장점이 있다. 이와 같은 구조를 시스템 간 실현한다고 생각하면 된다. 시스템 아키텍처에 있어서 이 발신자와 수신자의 교환을 중개하는 브로커가 존재함으로써 펍/섭 메시징 모델이 형성된다.
1개의 토픽에 주목한 경우를 큐잉 모델과 비교하면 여럿이 존재하는 모든 서브스크라이버는 같은 메시지를 받게 된다. 병렬로 동작하는 복수의 서브스크라이버에 전달할 수 있다는 장점이 있지만, 같은 메시지에 대한 처리이기 때문에 브로커의 토픽에 축적되는 메시지 그룹 입장에서 보면 처리 능력을 높이는 효과는 없다. 따라서 큐잉 모델과 펍/섭 메시징 모델은 상호간에 장단이 있다.
1.4.2 카프카 메시징 모델
높은 처리량을 실현하기 위해서는 어떻게 확장할 수 있는가가 관건이다. 카프카는 큐잉 모델에서 여러 컨슈머가 분산 처리로 메시지를 소비하는 모델과 펍/섭 메시징 모델에서 실현한 여러 서브스크라이버에 같은 메시지를 전달하고, 토픽 기반으로 전달 내용을 변경하는 모델을 모두 채택했다. 이 모델을 실현하기 위해 ‘컨슈머 그룹Consumer Group’이라는 새로운 개념을 도입하여 컨슈머를 확장할 수 있도록 설계했다.
▲ 컨슈머 확장 구성
여러 컨슈머가 같은 토픽을 분산하여 메시지를 읽음으로써 처리의 확장성을 담보한다. 브로커가 1대일 경우 병목이 일어날 수도 있다. 또한 장기간에 걸쳐 임의의 타이밍에 데이터를 읽도록 하려면 1대만로는 유지할 수 있는 메시지양이 부족할지도 모른다. 따라서 브로커도 복수 구성 가능해 결과적으로는 전체적으로 확장이 가능한 구조다.
1.4.3 디스크로의 데이터 영속화
다음 두 가지 요구에 부응하기 위해 카프카는 브로커에 보낸 메시지를 디스크에 영속화한다.
➋ 임의의 타이밍에 데이터를 읽는다.
➍ 메시지를 잃지 않는다(단, 고장에 의한 최근 메시지 손실 회피 목적은 아님).
➍ 메시지를 잃지 않는다(단, 고장에 의한 최근 메시지 손실 회피 목적은 아님).
메시지 큐에서도 데이터 영속화가 가능한 제품이 있지만 실시간 접속에만 중점을 둔 경우가 많으며 기본적으로 장기 보존을 가정하지 않는다. 배치 처리의 경우 데이터를 일정 기간마다 모아야 할 필요가 있기 때문에 데이터를 메모리에만 유지하는 것은 용량 측면에서 불가능하다. 따라서 카프카의 메시지 영속화는 디스크에서 이루어진다. 카프카는 디스크에 영속화함에도 불구하고 높은 처리량을 제공한다는 특징이 있다.
또한 속속 들어오는 데이터를 한 묶음으로 장기 보존할 수 있기 때문에 카프카를 스토리지 시스템으로도 간주할 수 있다. 이러한 특징을 활용하는 예로는 처리 순서대로 로그를 계속 남기는 커밋 로그 축적용 스토리지 시스템 등을 들 수 있다.
1.4.4 이해하기 쉬운 API 제공
이제 카프카에서 데이터 출입을 쉽게 하는 API에 대해 살펴보자.
➌ 다양한 제품과 시스템에 쉽게 연동한다.
카프카는 프로듀서와 컨슈머를 쉽게 접속할 수 있도록 ‘Connect API’를 제공한다. 각각 이 API를 이용하여 각종 외부 시스템과 접속한다. 또한 API를 기반으로 카프카에 접속하기 위한 프레임워크로 Kafka Connect도 제공한다.
▲ 카프카 커텍트와 카프카 스트림
Kafka Connect와 접속하기 위한 플러그인으로는 커넥터Connector가 개발되어 있으며 데이터베이스, 키 밸류 스토어, 검색 인덱스, 파일시스템 등의 외부 시스템과 접속할 수 있다. 커넥터에는 몇 가지 종류가 있다. 현재 컨플루언트Confluent가 제공하는 커넥터로는 ActiveMQ, IBM MQ, JMS HDFS나, JDBC가 있고, 기타 개발사에서 개발해 컨플루언트가 인정하고 있는 것, 커뮤니티에 의해 개발된 것 등이 있다. 시스템 간 또는 제품 간의 접속을 개별 개발자가 만드는 것은 비효율적이기 때문에 재사용성과 품질 향상을 위해서도 이러한 커넥터들의 존재는 큰 도움이 된다.
또한 카프카상의 데이터를 스트림 처리하는 Streams API를 라이브러리화한 Kafka Streams라는 클라이언트 라이브러리도 있다. 사용자는 Kafka Streams 라이브러리를 이용해서 자바 애플리케이션을 만들고 작동시킬 수 있기 때문에 카프카 입출력에 사용하는 스트림 처리 애플리케이션을 비교적 쉽게 구현할 수 있다.
1.4.5 전달 보증
마지막으로 카프카에서 다음 요구 사항을 어떻게 처리하는지 살펴보자.
➍ 메시지를 잃지 않는다.
메시지 생산자 입장에서 매우 당연한 요구인 메시지를 잃지 않고 전달하는 데 있어 카프카는 전달 보증 기능을 제공한다. 전달 보증 기능으로는 ‘At Most Once’, ‘At Least Once’, ‘Exactly Once’ 세 가지가 있다.
▲ 카프카 전달 보증 수준
앞서 언급했듯이 메시지 큐는 Exactly Once 수준을 주목적으로 하는 경우가 많다. 따라서 트랜잭션 관리를 위한 메커니즘이 마련돼 있다. 그러나 카프카 개발 초기에는 성능을 중시하는, 즉 ‘높은 처리량’을 구현해야 했기 때문에 Exactly Once 수준의 보증은 미루고 최소한 ‘메시지 분실 방지’를 위한 At Least Once 수준으로 전달을 보증했다.
At Least Once를 실현하기 위해 Ack와 오프셋 커밋Offset Commit이라는 개념을 도입했다. Ack는 브로커가 메시지를 수신했을 때 프로듀서에게 수신 완료했다는 응답을 뜻한다. 이것을 이용해 프로듀서가 Ack를 받지 못한 경우에 재전송해야 한다고 판단할 수 있다.
▲ 프로듀서에 Ack 반환
또한 컨슈머가 브로커로부터 메시지를 받을 때 컨슈머가 어디까지 메시지를 받았는지를 관리하기 위한 오프셋이 있다. 이를 이용한 전달 범위 보증의 구조를 오프셋 커밋이라고 한다. 오프셋 커밋은 메시지를 받아 정상적으로 처리를 완료한 다음 오프셋을 업데이트함으로써 어딘가 잘못된 문제로 메시지를 재전송할 때도 어디부터 재전송하면 되는지 판단할 수 있다.
▲ 컨슈머에서 읽은 기록을 오프셋 커밋으로 브로커에 남긴다
Exactly Once 실현
초기 카프카는 At Least Once 수준의 전달을 보증했지만, 카프카의 유용성이 높아지면서 Exactly Once 수준의 전달을 보증하고자 하는 요구가 높아졌다. 그러다 보니 더 높은 전달 보증을 위해 트랜잭션 개념이 추가됐다.
Exactly Once 수준에서는 구체적으로 쌍방간의 실현이 모두 필요하다. 첫 번째는 프로듀서와 브로커의 상호 교환 사이에, 두 번째는 브로커와 컨슈머의 상호 교환 사이에 필요하다. 우선, 프로듀서와 브로커의 상호 교환 사이를 살펴보면 양쪽 모두에서 시퀸스 번호를 관리해 중복되는 실행을 제거한다.
▲ 카프카가 상류 시스템에서 중복 메시지를 제거하는 방법
한편, 브로커와 컨슈머 간 교환에 있어서는 컨슈머에 대해 트랜잭션의 범위를 해석하고, 트랙잭션 중단 시 중단까지의 처리를 파기하는 기능이 있다.
▲ 카프카가 하류 시스템에서 트랜잭션 중단을 해석하는 모습
Exactly Once 수준의 전달을 보증하려면 카프카뿐 아니라 프로듀서에 해당하는 상류upstream 시스템과 컨슈머에 해당하는 하류downstream 시스템에서도 상태를 관리해야 한다. 따라서 카프카 단독으로는 전달 보증을 실현하긴 어렵다. 하지만 적어도 카프카는 트랜잭션 관리 메커니즘을 갖추고 있기 때문에 상류와 하류 시스템 사이에서 필요로 하는 상태 관리를 위한 조건이 갖추어지면 전달은 보증된다.
· · ·
이렇게 구현된 카프카는 2011년 버전 0.7이 출시됐고, 아파치소프트웨어재단에의 아파치 카프카란 이름으로 오픈소스로 풀렸다. 카프카 1.0은 2017년에나 릴리즈됐다. 일정 수준 이상의 커뮤니티가 성숙하고 안전성이 갖춰지는 여타의 오픈소스와 달리, 아파치 카프카는 목표 비전 완성을 기준으로 1.0을 릴리즈했다.
TAG :
이전 글 : 좋은 매니저는 누구인가
최신 콘텐츠