아파치 카프카(Apache Kafka) 아키텍처 및 동작 방식

| 아파치 카프카(Apache Kafka)란?

 

아파치 카프카(Apache Kafka)는 분산 스트리밍 플랫폼이며 데이터 파이프 라인을 만들 때 주로 사용되는 오픈소스 솔루션입니다. 카프카는 대용량의 실시간 로그처리에 특화되어 있는 솔루션이며 데이터를 유실없이 안전하게 전달하는 것이 주목적인 메세지 시스템에서 Fault-Tolerant한 안정적인 아키텍처와 빠른 퍼포먼스로 데이터를 처리할 수 있습니다.

 

아파치 카프카는 현재 2.x 버전까지 나와있고 초기에 Producer, Consumer 기능에서 0.10.x 버전에서부터 Connectors와 Stream Processors가 추가되었습니다.

 

이 포스팅에서는 Producer, Consumer에 대해서만 다룰 것이며 카프카가 어떤 아키텍처로 구성되어 있고 어떻게 동작하는 지 간략하게 설명하도록 하겠습니다.

 

 

| 아파치 카프카의 특징(Apache Kafka Features)

 

■Publisher Subscriber 모델 : Publisher Subscriber 모델은 데이터 큐를 중간에 두고 서로 간 독립적으로 데이터를 생산하고 소비합니다. 이런 느슨한 결합을 통해 Publisher나 Subscriber가 죽을 시, 서로 간에 의존성이 없으므로 안정적으로 데이터를 처리할 수 있습니다. 또한 설정 역시 간단하게 할 수 있다는 장점이 있습니다.

 

■고가용성(High availability) 및 확장성(Scalability) : 카프카는 클러스터로서 작동합니다. 클러스터로서 작동하므로 Fault-tolerant 한 고가용성 서비스를 제공할 수 있고 분산 처리를 통해 빠른 데이터 처리를 가능하게 합니다. 또한 서버를 수평적으로 늘려 안정성 및 성능을 향상시키는 Scale-out이 가능합니다.

 

■디스크 순차 저장 및 처리(Sequential Store and Process in Disk) : 메세지를 메모리 큐에 적재하는 기존 메세지 시스템과 다르게 카프카는 메세지를 디스크에 순차적으로 저장합니다. 이로서 얻는 이점은 두 가지입니다.

 

1. 서버에 장애가 나도 메세지가 디스크에 저장되어 있으므로 유실걱정이 없습니다.

2. 디스크가 순차적으로 저장되어 있으므로 디스크 I/O가 줄어들어 성능이 빨라집니다.

 

■분산 처리(Distributed Processing) : 카프카는 파티션(Partition)이란 개념을 도입하여 여러개의 파티션을 서버들에 분산시켜 나누어 처리할 수 있습니다. 이로서 메세지를 상황에 맞추어 빠르게 처리할 수 있습니다.

 

| 아파치 카프카 사용 이유(The reason why we use kafka)

 

1.  병렬처리에 의한 데이터 처리율 향상 : 카프카는 아래 보실 아키텍처에 보면 데이터를 병렬로 처리함으로서 데이터를 빠르고 효과적으로 처리할 수 있습니다. disk에 순차적으로 데이터를 적재하기 때문에 임의 접근(random access) 방식보다 훨씬 더 빠르게 데이터를 처리합니다.
2.  데이터 유실 방지 : disk에 적재되기 때문에 만약 불의의 사고로 서버가 다운되었을 시에도 데이터가 유실되는 일 없이 재시작하여 기존 데이터를 안정적으로 처리 가능합니다.
   
   
3.  클러스터링에 의한 고가용성 서비스 : Scale-out이 가능하여 시스템 확장이 용이하며 어떤 하나 혹은 몇 개의 서버가 다운되도 서비스 자체가 중단될 일 없이 시스템이 운용가능합니다. 

 

| 아키텍처 및 구성(Architecture and Components)

 

카프카 공식 문서에 나온 카프카를 나타내는 간단한 아키텍처입니다. (0.9.x 기준)

 

<출처: https://kafka.apache.org/090/documentation.html>

 

카프카 클러스터를 중심으로 프로듀서와 컨슈머가 데이터를 push하고 pull하는 구조입니다. Producer, Consumer는 각기 다른 프로세스에서 비동기로 동작하고 있죠. 이 아키텍처를 좀 더 자세히 표현하면 다음과 같습니다.

 

 

 

 

위 그림을 설명하기 이전에 아키텍처를 구성하고 있는 구성요소들 먼저 설명하도록 하겠습니다.

 

■프로듀서(Producer) : 데이터를 발생시키고 카프카 클러스터(Kafka Cluster)에 적재하는 프로세스입니다.

 

■카프카 클러스터(Kafka Cluster) : 카프카 서버로 이루어진 클러스터를 말합니다. 카프카 클러스터를 이루는 각 요소는 다음과 같습니다.

 - 브로커(Broker) : 카프카 서버를 말합니다.

 - 주키퍼(Zookeeper) : 주키퍼(Zookeeper)는 분산 코디네이션 시스템입니다. 카프카 브로커를 하나의 클러스터로 코디네이팅하는 역할을 하며 나중에 이야기할 카프카 클러스터의 리더(Leader)를 발탁하는 방식도 주키퍼가 제공하는 기능을 이용합니다.

 - 토픽(Topic) : 카프카 클러스터에 데이터를 관리할 시 그 기준이 되는 개념입니다. 토픽은 카프카 클러스터에서 여러개 만들 수 있으며 하나의 토픽은 1개 이상의 파티션(Partition)으로 구성되어 있습니다. 어떤 데이터를 관리하는 하나의 그룹이라 생각하시면 됩니다.

 - 파티션(Partition) : 각 토픽 당 데이터를 분산 처리하는 단위입니다. 카프카에서는 토픽 안에 파티션을 나누어 그 수대로 데이터를 분산처리합니다. 카프카 옵션에서 지정한 replica의 수만큼 파티션이 각 서버들에게 복제됩니다.

 - 리더, 팔로워(Leader, Follower) : 카프카에서는 각 파티션당 복제된 파티션 중에서 하나의 리더가 선출됩니다. 이 리더는 모든 읽기, 쓰기 연산을 담당하게 됩니다. 리더를 제외한 나머지는 팔로워가 되고 이 팔로워들은 단순히 리더의 데이터를 복사하는 역할만 하게 됩니다.

 

■컨슈머그룹(Consumer Group) : 컨슈머의 집합을 구성하는 단위입니다. 카프카에서는 컨슈머 그룹으로서 데이터를 처리하며 컨슈머 그룹 안의 컨슈머 수만큼 파티션의 데이터를 분산처리하게 됩니다.

 

위 그림에서는 Producer가 데이터를 카프카에 적재하고 있으며 그 저장된 데이터를 Consumer Group A와 B가 각각 자신이 처리해야될 Topic Foo와 Bar를 가져오는 그림입니다.

 

Foo와 Bar은 각각 3개의 파티션으로 나뉘어져 있으며 이 각각의 파티션들은 3개의 복제본으로 복제됩니다. 3개의 복제본 중에는 하나의 리더가 선출되게 되고(하늘색으로 칠해진 파티션) 이 리더가 모든 데이터의 읽기, 쓰기 연산을 담당하게 됩니다.

중요한 것은 이 파티션들은 운영 도중 그 수를 늘릴 수 있지만 절대 줄일 수 없습니다. 이 때문에 파티션을 늘리는 것은 신중하게 고려해서 결정해야될 문제가 됩니다.

 

카프카 클러스터에서 데이터를 가져오게 될 때는 컨슈머 그룹(Consumer Group)단위로 가져오게 됩니다. 이 컨슈머 그룹은 자신이 가져와야하는 토픽 안의 파티션의 데이터를 Pull하게 되고 각각 컨슈머 그룹안의 컨슈머들이 파티션이 나뉘어져 있는 만큼 데이터를 처리하게 됩니다.

 

 

| 파티션 읽기, 쓰기(Kafka Partition, Read, Write)

 

 

아파치 카프카에서의 쓰기, 읽기 연산은 카프카 클러스터 내의 리더 파티션들에게만 적용됩니다. 하늘색으로 칠해진 각 파티션들은 리더 파티션이며 이 파티션들에게 프로듀서가 쓰기 연산을 진행합니다. 그리고 리더 파티션에 쓰기가 진행되고 난 후 업데이트된 데이터는 각 파티션들의 복제본들에게로 복사됩니다.

 

아래는 프로듀서가 어떻게 각 파티션들에 Write 연산을 진행하는 지 설명하는 그림입니다.

 

 

위에서 언급했듯 카프카는 데이터를 순차적으로 디스크에 저장합니다. 따라서 프로듀서는 순차적으로 저장된 데이터 뒤에 붙이는 append 형식으로 write 연산을 진행하게 됩니다. 이 때 파티션들은 각각의 데이터들의 순차적인 집합인 오프셋(offset)으로 구성되어 있습니다.

 

컨슈머그룹의 각 컨슈머들은 파티션의 오프셋을 기준으로 데이터를 순차적으로 처리하게 됩니다. (먼저 들어온 순서부터) 중요한 것은, 컨슈머들은 컨슈머 그룹으로 나뉘어서 데이터를 분산 처리하게 되고 같은 컨슈머 그룹 내에 있는 컨슈머끼리 같은 파티션의 데이터를 처리할 수 없습니다.  

 

파티션에 저장되어 있는 데이터들은 순차적으로 데이터가 저장되어 있으며 이 데이터들은 설정값에 따라 데이터를 디스크에 보관하게 됩니다. (2.x 기준 default 7일)

 

 

위 그림은 컨슈머 그룹단위로 그룹 내 컨슈머들이 각각의 파티션의 데이터를 처리하는 모습을 나타낸 것입니다.

 

만일 컨슈머와 파티션의 개수가 같다면 컨슈머는 각 파티션을 1:1로 맡게 됩니다. 만일 컨슈머 그룹 안의 컨슈머의 개수가 파티션의 개수보다 적을 경우 컨슈머 중 하나가 남는 파티션의 데이터를 처리하게 됩니다. 눈여겨 볼 것은 만일 컨슈머의 개수가 파티션의  개수보다 많을 경우 남는 컨슈머는 파티션이 개수가 많아질 때까지 대기하게 됩니다.