[Apache Kafka] 소개

등장배경

기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이었습니다.

기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드인의 수많은 트래픽과 데이터를 처리하기에는 한계가 있었습니다.

이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 링크드인의 몇몇 개발자가 다음과 같은 목표를 가지고 새로운 시스템을 개발하기 시작했습니다

• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리랴을 위한 메시지 최적화
• 데이터가 증가함에 따라 스케일 아웃이 가능한 시스템

카프카를 적용함으로써 모든 이벤트/데이터의 흐름을 중앙에서 관리할수 있게 되었으며, 서비스 아키텍처가 기존에 비해 관리하기 심플해졌습니다.

아파치 카프카

아파치 카프카(Apache Kafka)는 링크드인(LinkedIn)에서 처음 개발된 분산 메시징 시스템입니다.

2011년 오픈소스로 공개되었으며 이후 2012년 10월 아파치 인큐베이터를 종료했습니다. 현재 링크드인에서 카프카를 개발하던 제이 크랩스(Jay Kreps)를 비롯한 일부 엔지니어들이 ‘Confluent’라는 회사를 설립하여 카프카와 관련된 일을 하고 있습니다.

카프카라는 이름은 유명한 작가인 ‘프란츠 카프카(Franz Kafka)’에서 따왔습니다.

카프카의 핵심요소

• Broker : 카프카 애플리케이션 서버 단위
• Topic : 메시지의 논리적 구분 단위, 메시지 발생 및 구독 단위
• Partition : 데이터 분리 단위, 물리적 저장소
• Offset : 각 메시지당 파티션에 할당된 고유 번호
• Consumer : 메시지를 Pulling하는 애플리케이션
• Consumer Group : 같은 토픽을 구독하는 컨슈머들의 묶음
• Produer : 메시지를 브로커로 전송하는 애플리케이션

Publish/Subscribe 시스템

카프카는 기본적으로 Publish-Subscribe 모델을 구현한 분산 메시징 시스템입니다. Publish-Subscribe 모델은 데이터를 만들어내는 프로듀서(Producer, 생산자), 소비하는 컨슈머(Consumer, 소비자) 그리고 이 둘 사이에서 중재자 역할을 하는 브로커(Broker)로 구성된 느슨한 결합(Loosely Coupled)의 시스템입니다.

프로듀서는 브로커를 통해 메시지를 발행(Publish) 합니다. 이 때 메시지를 전달할 대상을 명시하지 않으며 관련 메시지를 구독(Subscribe)할 컨슈머가 브로커에게 요청하여 가져가는 식입니다. 마치 블로그 글을 작성하여 발행하면 블로그 글을 구독하는 독자들이 따로 읽어가는 형태를 생각하면 됩니다.

카프카에서 프로듀서는 특정 토픽(Topic)으로 메시지를 발행할 수 있습니다. 컨슈머 역시 특정 토픽의 메시지를 읽어 갈 수 있습니다. 카프카에서 토픽은 프로듀서와 컨슈머가 만나는 지점이라고 생각할 수 있습니다.

카프카는 수평적인 확장(Scale Out)을 위해 클러스터를 구성합니다. 카프카를 통해 유통되는 메시지가 늘어나면 카프카 브로커의 부담(Load)이 증가하게 되어 클러스터의 규모를 확장할 필요가 있습니다. 카프카는 브로커들의 클러스터링을 위해 아파치 주키퍼(Apache ZooKeeper)를 사용합니다. 주키퍼를 사용하여 브로커의 추가 및 장애상황을 간단하게 대응할 수 있습니다

카프카 클러스터 위에서 프로듀서가 전송한 메시지는 중복 저장(Replication)되어 장애 상황에서도 고가용성(High Availability)을 보장하게 됩니다. 프로듀서가 메시지를 카프카 클러스터로 전송하면 브로커는 또 다른 브로커에게 프로듀서의 메시지를 중복해서 저장하게 됩니다. 만약 한 브로커에 장애가 생기더라도 중복 저장된 복사본을 컨슈머에게 전달 할 수 있으므로 장애 상황에 대비(Fault-tolerant) 할 수 있습니다.

카프카의 특징

1. 다중프로듀서, 다중 컨슈머 카프카는 토픽에 여러 프로듀서가 동시에 메시지를 전송할 수 있습니다. 뿐만 아니라 하나의 프로듀서가 여러 토픽에 메시지를 전송할 수도 있으며, 하나의 컨슈머가 여러 토픽에서 메시지를 읽어 갈 수도 있습니다. 특히 하나의 메시지를 여러 컨슈머가 읽어 갈 수 있는 측면이 카프카의 큰 장점으로 작용합니다.

이러한 다중 프로듀서, 다중 컨슈머의 지원을 통해 하나의 카프카 시스템을 통해 다양한 애플리케이션이 데이터를 주고 받을 수 있게 되었으며, 데이터의 생산자/소비자 관계도 유연하게 구성할 수 있게 되었습니다.

1. 파일시스템에 저장 전통적인 메시징 시스템은 프로듀서가 전송한 메시지를 브로커의 메모리 상에 존재하는 큐(Queue)에 유지한다. 이후 컨슈머가 메시지를 읽어가면 큐에서 메시지를 제거한다. 프로듀서가 생성한 메시지는 브로커를 통해 컨슈머에 의해 빠른 시간내에 소빌될 것이라고 가정하고 만들어졌기 때문이다.

카프카는 프로듀서가 생성한 메시지를 브로커가 위치한 서버의 파일 시스템에 저장한다. 따라서 컨슈머는 프로듀서가 생성한 메시지를 바로바로 소비하지 않아도 되며 카프카가 메시지를 보존하고 있는 기간내에서는 언제든지 일어 갈 수 있다.

이런 방식은 프로듀서와 컨슈머의 속도 차이가 있을때 유용하다. 예를 들어 컨슈머 쪽에 장애가 생겼거나 순간적인 네트워크 트래픽 폭주로 처리가 늦어졌을 때 브로커의 동적에 큰 영향을 주지 않으면서 처리 속도를 따라갈 수 있게 해준다. 또 한 컨슈머들이 데이터를 모았다가 처리하는 배치(batch) 처리를 가능하게 해주며, 컨슈머 쪽에서 에러가 생겼을 때 이전에 읽었던 데이터를 다시 읽을 수 있게 해준다.

카프카 브로커가 파일 시스템에 저장한 메시지는 관리자에 의해 설정된 일정 보존 기간동아 사용 가능하며 브로커가 위치한 서버의 파일 시스템에서 삭제된다.

1. 확장성(Scalability) 카프카 클러스터는 운영중에 확장이 용이하도록 설게되었다. 데이터 파이프라인을 구축한 초창기 적은 수의 브러커들로 클러스터를 운영하다가 시스템 트래픽이 높아지면 브로커를 추가해서 클러스터를 확장할 수 있다. 이른바 수평적 확장(Scale-Out)이 쉽게 이루어진다.

카프카 토픽에 메시지를 전송하는 프로듀서 역시 운영중에 얼마든지 증가시킬 수 있다. 카프카에서 메시지를 읽어가는 컨슈머의 경우 컨슈머 그룹에 컨슈머를 추가할 수 있다. 컨슈머 그룹에 컨슈머가 추가되면 컨슈머의 파티션 소유권(Ownership)이 재분배되는 리밸런스 과정을 거쳐 컨슈머 그룹에 속한 컨슈머들이 고르게 파티션을 할당 받게 된다.

카프카 토픽은 내부에서 파티션(Partition)이라는 세분화된 단위로 나뉘어 저장되는데 토픽의 파티션 개수도 운영 중에 추가할 수 있다.

1. 고성능 카프카는 대용량 실시간 로그 처리에 특화되어 있다. 일반적인 범용 메시징 시스템이 지원하는 몇가지 기능을 포기하면서 높은 처리량(Throughput)을 갖도록 설계되었다. 카프카는 불필요한 기능을 제외하고 내부적으로 배치처리, 분산처리와 같은 다양한 기법을 사용해 성능을 최대로 끌어냈다.

2. 컨슈머의 pull 방식

기존 메시징 시스템의 브로커가 컨슈머에게 데이터를 전달해주는 “Push 방식”을 채택한 경우가 많았다. 카프카는 컨슈머가 브로커에게서 메시지를 가져오는 “Pull 방식”을 채택했다

Pull방식을 사용하면 컨슈머의 처리량을 브로커가 고민할 필요가 없다. 컨슈머는 자신이 처리할 수 있는 만큼의 메시지만 브로커에게서 가져가면 되기 때문이다. 만일 컨슈머의 처리속도가 프로듀서의 생산 속도보다 느리다면 컨슈머를 추가하여 처리량을 늘릴 수 있다. 또한 메시지를 모았다가 한번에 처리할 수있는 배치처리도 간단하게 구현할 수 있다.

참조링크

• https://velog.io/@jaehyeong/Apache-Kafka%EC%95%84%ED%8C%8C%EC%B9%98-%EC%B9%B4%ED%94%84%EC%B9%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
• https://soft.plusblog.co.kr/3