Kafka

아파치 카프카(Apache Kafka)

​

아프치 카프카는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산 데이터 스트리밍 플랫폼으로

링크드인에서 처음 출발하게 되었습니다.

​

카프카는 게시 / 구독 메시징 모델을 사용하는데

구독자가 특정 토픽이나 이벤트에 대해서 어떤 구독 의사를 등록하고,

해당 이벤트에 대한 일련의 통지를 받는 비동기 방식으로 동작하게 됩니다.

​

아파치 카프카의 특징(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)

병렬처리에 의한 데이터 처리율 향상 : 카프카는 아래 보실 아키텍처에 보면 데이터를 병렬로 처리함으로서 데이터를 빠르고 효과적으로 처리할 수 있습니다. disk에 순차적으로 데이터를 적재하기 때문에 임의 접근(random access) 방식보다 훨씬 더 빠르게 데이터를 처리합니다.

데이터 유실 방지 : disk에 적재되기 때문에 만약 불의의 사고로 서버가 다운되었을 시에도 데이터가 유실되는 일 없이 재시작하여 기존 데이터를 안정적으로 처리 가능합니다.

클러스터링에 의한 고가용성 서비스 : Scale-out이 가능하여 시스템 확장이 용이하며 어떤 하나 혹은 몇 개의 서버가 다운되도 서비스 자체가 중단될 일 없이 시스템이 운용가능합니다.

​

카프카 구성요소들

■프로듀서(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하게 되고 각각 컨슈머 그룹안의 컨슈머들이 파티션이 나뉘어져 있는 만큼 데이터를 처리하게 됩니다.

실시간 데이터 분석 플랫폼 구조

네이버 TV연예 서비스에서 사용하는 실시간 데이터 분석 플랫폼의 구조는 다음 그림과 같다.