카프카(Kafka)는 대용량 실시간 처리를 위해 사용하는 메시징 시스템으로 Pub-Sub 구조로 되어 있다. 

LinkedIn, Twitter, Netflix, Tumblr, Foursquare 등 대용량을 다루는 업체들이 주로 카프카를 사용하고 있다. 

물론 카프라 단독으로 실시간 처리를 구성하지 않고, 스톰(Storm) / 하둡(Hadoop) / HBase 등과 연동해서 활용하는 것이다. 

아직까지 국내에서 카프카를 실제 서비스에 많이 활용하고 있지는 않고

오히려 레디스(Redis)와 같은 메모리(In-Memory) 기반의 메시지 큐나 멤캐쉬(memcached)를 더 많이 사용하는 것 같다.  

하지만 전세계 40여개가 넘는 대용량을 다루는 업체들이 어떻게 카프카(Kafka)를 사용하고 있는지 한번 정리해 보기로 한다. 

카프카(Kafka) 개요

비즈니스 소셜네트워크로 유명한 링크드인(LinkedIn)은 메시징 및 로깅 처리를 위해 ActiveMQ와 Splunk를 사용하고 있었다. 

하지만 링크드인이 점차 글로벌 서비스로 성장하면서 데이터 양이 늘어남에 따라 기존의 기술들은 확장성이 떨어졌다. 

그래서 플럼(Flume)이나 스크라이브(Scribe)와 같은 기술도 검토했지만 결국 확성이 높고 신뢰할 수 있는 시스템을 만들기로 결정했다. 

이렇게 시작된 카프카는 링크드인에서 빠른 처리 속도를 보장하는 분산 메시지 큐로서의 역할을 하게 된다.  

이후 아파치 탑 프로젝트(Apache Top Project)로 등록되면서 버전 0.8임에도 불구하고 점차 사용하는 회사를 늘어나게 된다. 

카프카(Kafka) 구성요소

카프카의 가장 큰 특징은 다른 메시징 시스템과 달리 파일시스템을 이용한다는 점이다. 

메모리에 저장하는 구조가 아니기 때문에 데이터 자체의 휘발성이 없으며 효율적으로 데이터를 보관할 수 있다. 

또한 시스템 자체가 프로듀서(Producer) / 컨슈머(Consumer) / 브로커(Broker)로 매우 간단하게 구성되어 있다. 

프로듀서는 데이터를 카프카로 전달하는 역할을 하고

컨슈머는 카프카에 저장된 데이터를 가져오는 역할을 한다. 

위 그림에서와 같이 여러개의 프로듀서와 컨슈머를 구성할 수 있다. 

이것은 데이터의 수집을 여러 곳에서 할 수 있고 

해당 데이터를 처리하는 것도 활용 범위에 따라 여러개 만들어서 처리할 수 있다는 것이다. 

프로듀서와 컨슈머에 대한 API를 제공함으로써 어떤 서비스와도 잘 결합되게 만들어져 있다는 점도 특징이다. 

특히 빅데이터 분석에 많이 사용하는 하둡(Hadoop/HBase)과 해당 컨슈머를 구성해서 바로 연동할 수 있다. 

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

각 파티션에 들어온 순서대로 저장하고 순차적으로 컨슈머에게 전달해 처리하게 된다. 

물론 파트션에 저장하는 정보의 양도 설정값으로 조정할 수 있다. 

파티션 구조를 효과적으로 사용하고 신뢰성있는 시스템을 구성하기 위해서 카프카 클러스터(Kafka Cluster)를 구성해야 한다. 

카프카 클러스터를 구성하는 장점에 대해 링크드인의 엔지니어인 준 라오(Jun Rao)는 다음과 같이 이야기한다. 

The benefits of Kafka replication

- A producer can continue to publish messages during failure and it can choose between latency and durability, depending on the application

- A consumer continues to receive the correct messages in real time, even when there is failure

마지막으로 카프카 클러스터를 관리하기 위해서 주키퍼(Zookeeper)를 사용해서 각 노드를 모니터링한다.

카프카를 설치하면 주키퍼도 함께 설치되는 것을 확인할 수 있다. 

카프카 서버 구성

실제 카프카를 활용하려고 할 때 클러스터를 구성하는 방법에 대해서 자료가 부족한 것이 사실이다. 

아래 카프카 클러스터를 통해 개념만 한번 정리해 보자. 

위 그림은 카프카 클러스터로 서버 3대를 사용하고 있으며, 주키퍼로 모니터링 하고 있다. 

"zerg.hydra"라는 토픽으로 데이터를 전송하고 있고 파티션은 2개를 사용하고 있다. 

브로커1(broker1)을 보면 P0/R1이 진하게 표시된 것을 알 수 있는데, 이것은 브로커1이 파티션0의 리더(leader)임을 나타내는 것이다. 

정상적인 경우라면 파티션0의 데이터를 읽기 위해서 리더인 브로커1의 데이터를 활용하게 된다. 

만약 브로커1에 문제가 발생한다면, 파티션0가 복제(Replication) 되어 있는 브로커2(broker2)의 데이터를 사용하게 될 것이다. 

이러한 브로커2와 같이 복제 되어 있는 서버를 팔로워(follower)라고 한다. 

그렇다면 이러한 복제(Replication)을 어떻게 구성해야 할까?

구글의 글로벌 분산데이터베이스인 스패너(Spanner)나 아파치의 주키퍼(Zookeeper)는 "Quorum Based" 방식으로 복제(Replication)을 구성하고 있다. 

이 방식은 리더가 모든 팔로워(복제 대상 서버)에 데이터가 전송될 때까지 기다리지 않고,

대부분의 팔로워가 데이터를 수신하면 바로 리더에서 데이터를 처리하도록 한 것이다. 

만약 데이터 처리 중 리더에서 오류가 발생하면, 복제가 완료된 팔로워들 중 하나를 새로운 리더로 추천하는 것이다. 

이렇게 함으로써 모든 팔로워에 복제가 완료될때까지 기다리는 것보다 복제 대기시간을 줄일 수 있게 된다. 

카프카를 제대로 활용하고자 한다면, 데이터 양과 위와 같은 사항들을 잘 고려해서 구성해야 할 것이다.