[Kafka] 아파치 카프카 (Apache Kafka)란?

728x90

SMALL

Apache Kafka (A high-throughput distributed message system)

메시지 큐의 일종이다.
메시지 지향 미들웨어(Message Oriented Middleware : MOM)는 비동기 메시지를 사용하는 다른 응용 프로그램 사이의 데이터 송수신을 의미하는데, MOM을 구현한 시스템을 메시지 큐(Message Queue : MQ)라고 한다.
분산형 스트리밍 플랫폼(A distributed streaming platform)이다. Linked In에서 여러 구직 및 채용 정보들을 한 곳에서 처리(발행/구독)할 수 있는 플랫폼으로 개발이 시작되었다. 발행/구독(Pub/Sub)은 메시지를 특정 수신자에게 직접적으로 보내주는 시스템이 아니고, 메시지를 받기를 원하는 사람이 해당 Topic을 구독함으로써 메시지를 읽어 올 수 있다.

특징

대용량 실시간 로그 처리에 특화되어 설계된 메시징 시스템(MQ)으로 TPS가 매우 우수하다.
메시지를 메모리에 저장하는 기존 메시징 시스템(rabbit MQ, Active MQ)과는 달리 파일에 저장을 하는데, 그로 인해 Kafka를 재시작해도 메시지 유실 우려가 적다.
기본 메시징 시스템에서는 Broker가 Consumer에게 메시지를 Push 해주는 방식인데, Kafka는 Consumer가 Broker로부터 메시지를 직접 가져가는 Pull 방식이다. 그렇기에 Consumer는 자신의 처리 능력만큼의 메시지만 가져와 최적의 성능을 낼 수 있고, 대용량 처리에 특화되었다.

구성요소

Topic, Partition

카프카에 저장되는 메시지는 Topic으로 분류되고, Topic은 여러 개의 Partition으로 나눠질 수 있다.
Partition안에는 Message의 상대적 위치를 나타내는 offset이 있는데 이 offset 정보를 이용해 이전에 가져간 Message의 위치 정보를 알 수 있고, 동시에 들어오는 많은 데이터를 여러 Partition에 나누어 저장하기에 병렬 처리가 가능하다.

Producer, Consumer

Producer는 메시지를 생산(Write)하는 주체, Consumer는 메시지를 소비(Read)하는 주체이다.
Producer와 Consumer는 상호 존재 여부를 알지 못한채 자신에게 주어진 역할만 처리한다. (위 그림에서 Wrties가 Producer)

Consumer Group

Producer에서 생산(Write)한 메시지는 여러개의 파티션에 저장되고, 여러 Consumer는 생산된 메시지를 읽어간다. 하나의 목표를 위해 소비하는 그룹, 즉 하나의 Topic을 읽어가기 위한 Consumer들을 Consumer Group라고 한다.
Consumer Group을 통해 데이터를 병렬로 읽어 빠른 처리 가능, 특정 Consumer에 문제가 생긴 경우 다른 Group의 Consumer가 대신 읽을 수 있게 리밸런싱 되어 장애 상황에도 문제없이 대처 가능하다.
* Topic의 Partition은 Consumer Group와 1:N 매칭, 즉 자신이 읽고 있는 Partition에는 같은 Consumer Group내 다른 Consumer가 읽을 수 없다.
* Partition 개수 > Consumer 개수 : 하나의 Consumer가 2개의 Partition에 접근하여 데이터를 읽는다.
* Partition 개수 < Consumer 개수 : 아무일도 하지 않는 Consumer 발생
* Partiton 개수 = Consumer 개수 : 가장 효과적

Broker, Zookeeper

Broker는 Kafka 서버를 칭한다. 동일한 노드내에서 여러 개의 Broker 서버를 띄울 수 있고, Zookeeper는 이러한 분산 메시지큐의 정보를 관리해주는 역할을 한다.
Kafka를 띄우기 위해서는 반드시 Zookeeper가 실행되어야 한다.

Replication

Kafka에서는 Replication 수를 임의로 지정하여 Topic를 만들 수 있다.
Replication-factor에 3으로 지정하면 Replication 수가 3이 된다.
특정 Broker에 문제가 생겼을 경우 해당 Broker의 역할을 다른 Broker에서 즉각적으로 대신 수행 가능하다.
* Topic-1 Replication-factor : 1
* Topic-2 Replication-factor : 2
* Topic-3 Replication-factor : 3

Replicagtion - leader & follower

Replication은 복제 요소 중 대표인 Leader와 그 외 요소인 Follower로 나누어진다.
Topic으로 통하는 모든 데이터의 Read/Write는 오직 Leader에서 이루어진다.
Follower는 Leaderdhk Sync를 유지함으로써 Leader에 문제가 생긴 경우 Follower 중 하나가 Leader의 역할을 수행한다.
복제된 데이터가 Follower에게 있어서 메시지 유실은 없지만, 복제를 하기 위한 시간과 네트워크 비용이 들기 때문에 데이터의 중요도에 따라 ack 옵션으로 세부 설정 가능

akc

ack 값을 설정하여 데이터의 무손실에 더 중요성을 둘 것인지 또는 유실을 어느정도 감수하더라도 속도에 중요성을 둘 것인지를 설정할 수 있다.

0 : Producer는 서버로부터 어떠한 ack도 기다리지 않음, 유실량은 높으나 처리량도 높다.
1 : Leader는 데이터를 기록, 모든 Follower는 확인하지 않음 (Default)
-1(all) : 모든 ISR 확인, 무손실

전체 구성요소 및 흐름

Producer에서 Message Write, Consumer에서 Message Read 할 때 Zookeeper에서 Broker 및 offset 정보를 관리하기 때문에 분산 처리 가능
Zookeeper가 Kafka의 상태와 클러스터 관리를 담당

정해진 Topic에 Producer가 메시지를 Push 해놓으면 Consumer가 필요할 때 해당 메시지를 Pull
Consumer가 메시지를 소비한다고 해서 없어지는게 아니라 Kafka 설정에 의해 삭제

Kafka는 확장성(scale-out)과 고가용성(high availability)을 위하여 Broker들이 클러스터로 구성되어 동작하도록 설계, Broker가 1개밖에 없을 때에도 클러스터로써 동작
클러스터 내의 Broker에 대한 분산 처리는 Apache Zookeeper가 담당

기존 메시징 시스템과의 차이점 (ActiveMQ, RabbitMQ)

대용량 실시간 로그 처리에 특화되어 설계된 메시징 시스템으로써 기존 범용 메시징 시스템대비 TPS 우수,

단 특화된 시스템이기에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.

분산 시스템을 기반으로 설계되었기에 기존 메시징 시스템에 비해 분산 및 복제 구성을 쉽게 할 수 있다.

AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시켰다.

Producer가 Broker에게 다수의 메시지를 전송할 때 각 메시지를 개별로 전송해야하는 기존 메시징 시스템과 달리, 다수의 메시지를 Batch 형태로 Broker에게 한 번에 전달할 수 있어 TCP/IP 라운드 트립 횟수를 줄일 수 있다.

메시지를 기본적으로 메모리에 저장하는 기존 메시징 시스템과는 달리 메시지를 파일 시스템에 저장한다.

파일 시스템에 메시지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장된다.

기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을 수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 파일 시스템에 메시지가 쌓여있어도 성능 감소가 크지 않다.

이러한 기능 때문에 실시간 처리뿐 아니라 주기적인 Batch 작업에 사용할 데이터를 쌓아두는 용도로도 사용된다.

Consumer에 의해 처리된 메시지(Acknowledged Message)를 바로 삭제하는 기존 메시징 시스템과는 달리 처리된 메시지를 삭제하지 않고 파일 시스템에 두었다가 설정된 수명이 지나면 삭제한다.

처리된 메시지를 바로 삭제하지 않기에 메시지 처리 도중 문제가 발생하였거나 처리 로직이 변경되었을 경우 Consumer가 처음부터 다시 처리(rewind)하도록 할 수 있다.

기존 메시징 시스템에서는 Broker가 Consumer에게 메세지를 Push 해 주는 방식인데, Kafka는 Consumer가 Broker로부터 직접 메시지를 필요할 때 가져오는 Pull 방식이다.

따라서 Consumer는 자신의 처리능력만큼의 메시지만 가져오기 때문에 최적의 성능을 낼 수 있다.

기존의 Push 방식 메시징 시스템에서는 Broker가 직접 각 Consumer가 어떤 메시지를 처리해야 하는지 계산하고 어떤 메시지를 처리 중인지 트랙킹 하였는데, Kafka에서는 Consumer가 직접 메시지를 Pull 하므로 Broker의 부담이 줄어든다.

메시지를 Pull 방식으로 가져오므로, 메시지를 쌓아두었다가 주기적으로 처리하는 Batch Consumer의 구현이 가능하다.

성능 비교

일반적으로 하드디스크는 메모리보다 수백-수천 배 이상 느리다.

Kafka는 메모리에 별도의 캐시를 구현하지 않고 OS의 페이지 캐시에 이를 모두 위임한다. OS가 알아서 서버의 유휴 메모리를 페이지 캐시로 활용하여 앞으로 필요할 것으로 예상되는 메시지들을 미리 읽어 디스크 읽기 성능이 향상된다.

Kafka의 메시지는 하드디스크로부터 순차적으로 읽혀지기 때문에 하드디스크의 랜덤 읽기 성능에 대한 단점을 보완함과 동시에 OS 페이지 캐시를 효과적으로 활용할 수 있다.

메시지를 메모리에 저장하지 않기 때문에 메시지가 JVM 객체로 변환되면서 크기가 커지는 것을 방지할 수 있고, JVM의 GC로 인한 성능 저하 또한 피할 수 있다.

참고