Kakfa란 ? (개념, 동작원리)

https://yous3163.tistory.com/27

메세지 큐

 

카프카에 대해 이해하기 위해선 메시지 큐에 대해 선행학습이 필요하다.

 

카프카란 메세지 큐 종류 중 하나로써 rabbitmq와 더불어 가장 많이 쓰이는 메시지 큐 이다.

 

 

Apache Kafka 란? 

Apache Kafka는 Linkedin 개발된 분산 메시징 시스템으로써, 2011년 오픈소스로 공개되었다. 대용량의 실시간 로그처리에 특화된 아키텍처 설계를 통하여 기존 메시징 시스템보다 우수한 TPS를 보여주고 있다.

 

Kafka는 대용량 실시간 처리를 위해 사용하는 메시징 시스템으로, Pub-Sub 구조(발행-구독 public-subscribe)로 되어 있다. Linkedin, Twitter, Netflix, Tumblr 등 대용량 데이터를 다루는 업체들이 주로 Kafka를 사용하고 있으며, kafka 단독으로 처리하지는 않고, Hadoop 이나 HBase 등과 연동 하여 활용을 하는 편이다. 

 

 

 

 

 

Kafka의 기본 구성 요소와 동작

Kafka는 발행-구독(public-subscribe) 모델을 기반으로 동작하며, 크게 producer, consumer, broker 로 구성되어 있다.

https://d2.naver.com/helloworld/0974525

 

Kafka는 확장성(scale-out)과 고가용성(high avialabilty)를 위하여 broker들이 클러스터로 구성되어 동작하도록 설계되어 있다. 심지어 broker가 1개 밖에 없을 때에도 클러스터로써 동작한다. 클러스터 내의 broker에 대한 분산 처리는 아래 그림과 같이 Apache Zookeeper가 담당한다.

 

 

자 그럼 기존 메시징 시스템과의 차이가 무엇인가? (RabbitMQ / ActiveMQ)

 

Kafka의 가장 큰 특징은 다른 메시징 시스템과는 다르게 파일 시스템을 이용. 메모리에 저장하는 구조가 아니기 때문에 데이터 자체의 휘발성이 없으며 효율적으로 데이터를 보관할 수 있도록 구현되어 있다.

 

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

 

대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템으로써 기존 범용 메시징 시스템 대비 TPS가 매우 우수하다. 단, 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.

 

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

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

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

기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을 수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 메시지를 파일 시스템에 저장하기 때문에 메시지를 많이 쌓아두어도 성능이 크게 감소하지 않는다. 또한 많은 메시지를 쌓아둘 수 있기 때문에, 실시간 처리 뿐만 아니라 주기적인 batch 작업에 사용할 데이터를 쌓아두는 용도로도 활용할 수 있다.

Counsumer에 의해 처리된 메시지(acknowledged message)를 곧바로 삭제하는 기존  메시징 시스템과는 달리 처리된 메시지를 삭제하지 않고 파일 시스템에 그대로 두었다가 설정된 수명이 지나면 삭제한다. 처리된 메시지를 일정 기간동안 삭제하지 않기 때문에 메시지 처리 도중 문제가 발생하였거나 처리 로직이 변경되는 경우 consumer가 메시지를 처음부터 다시 처리(rewind)하도록 할 수 있다.

기존의 메시징 시스템에서는 broker가 consumer에게 메시지를 push 해주는 방식인데 비해, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작한다.

 

Topic 과 Partition

 

 

 

Kafka에서는 토픽(Topic)을 설정해서 데이터를 전송하고, 각 토픽을 기준으로 파티션을 구성해 저장한다.

각 파티션에 들어온 순서대로 저장하고 Consumer에게 순차적으로 전달해 처리. 파티션에 따라 저장하는 정보의 양도 설정 값으로 조정 가능하다.

 

파티션 구조를 효과적으로 사용하고 신뢰성 있는 시스템을 구성하기 위해 Kafka Cluster를 구성 해야 하며 Kafka Cluster를 관리하기 위해 주키퍼(Zookeeper)를 사용해서 각 노드를 모니터링한다.

 

 

 

 

Kafka 서버 구성

 

아래는 Kafka Cluster의 개념도이다.

 

Kafka Cluster 개념도

천천히 살펴보자

Kafka Cluster로 서버 3대를 이용하고 있으며 주키퍼로 모니터링 하고 있다. "zerg.hydra" 라는 토픽으로 데이터를 전송하고 있고 파티션은 2개씩 사용한다.

 

broker1 을 보면 P0/R1 이 진하게 표시된 것을 알 수 있는데, 이는 broker1 이 파티션 0의 리더 임을 나타내는 것이다. 정상적인 경우라면 파티션 0의 데이터를 읽기 위해 리더인 broker1 의 데이터를 활용하게 되는데, 만약 broker1 에 문제가 발생한다면 파티션 0이 복제되어 있는 broker2 의 데이터를 사용하게 될 것이다. 이러한 broker2 와 같이 복제되어 있는 서버를 팔로워(follower)라고 한다.

 

신뢰성 있는 시스템을 위해 복제를 구성할 때 구글의 글로벌 분산데이터베이스인 스패너(Spanner)나 아파치의 주키퍼는 "Quorum Based" 방식으로 복제를 구성하고 있다. 이 방식은 리더가 모든 팔로워에 데이터가 전송될 때까지 기다리지 않고, 대부분의 팔로워가 데이터를 수신하면 바로 리더에서 데이터를 처리하도록 하는 것이다. 만약 데이터 처리중 오류가 발생하면, 복제가 완료된 팔로워들 중 하나를 새로운 리더로 추천하여 처리하도록 한다.

 

요약:

Kafka는 메시지 큐 종류 중 하나로서 대용량 실시간 로그처리에 특화되어있다. 기존의 메시지 큐 시스템과는 다르게 파일 시스템을 이용하여 데이터 영속성이 보장된다. 또한 단순한 메시지 헤더를 지닌 TCP 기반의 프로토콜을 사용하여 오버헤드를 감소시켰고 메시지 처리 중 오류가 발생해도 메시지를 처음부터 다시 처리할 수 있다. 

 

 

참조

---

https://dhsim86.github.io/web/2017/03/22/spring_boot_features_06-post.html

Dongho Sim's dev story|Spring Boot Reference Guide Review 08 : Messaging with Kafka