💡 Intro

Kafka는 많은 서비스에서 백엔드로 사용하고 있습니다. 저는 Kafka의 ‘K’ 정도만 알고 있기 때문에, 오늘은 Kafka의 개념과 기본 구조에 대해서 알아보려고 합니다.

🔎 Kafka의 탄생

링크드인은 사이트가 급속도로 성장하면서 기존의 End to End 연결 방식이었던 아키텍처로는 복잡도, 데이터 파이프라인 관리 등의 어려움 때문에 새로운 아키텍처가 필요로 해졌습니다. 이를 해결하기 위해 링크드인은 Kafka라는 메시징 분산 스트리밍 플랫폼을 개발하게 되었습니다.

당시 링크드인의 요구사항은 1.높은 처리량으로 데이터를 실시간으로 처리 가능 해야 하며, 2.메시지의 영속성을 보장해 주고, 3.Scale out이 용이 해야 한다 등이 있었습니다. 하지만 당시의 제품들은 높은 처리량이 우선 순위였던 링크드인의 요구사항보다 트랜젝션의 관리가 너무 오버스펙이거나, 메시지 큐로 데이터를 쌓긴 하지만 장시간 쌓이는 것은 고려하지 않는 등의 문제로 충족시키지 못했습니다. 당시 링크드인의 자세한 요구사항은 🌎한빛미디어-링크드인은 왜 카프카를 만들었나을 통해 확인 하실 수 있습니다.

What is Apache Kafka?

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. - 출처: Apache Kafka

Apache Kafka의 공식사이트에서는 Apache Kafka란 수천 개의 기업이 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션을 위해 사용하는 오픈 소스 분산 이벤트 스트리밍 플랫폼이라고 설명합니다. 즉, Kafka는 데이터를 생성하는 어플리케이션과 데이터를 소비하는 어플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어, 처리, 관리 역할을 하며 Publish-Subscribe 모델을 구현한 분산 메시징 시스템입니다.

Message Queue란? 프로그램 간 데이터를 교환할 때 사용하는 통신 방법 중 하나이며 🌎Message-Oriented Middleware의 구현을 의미합니다.

Apache Kafka의 특징

1. Kafka의 topic에 여러 프로듀서가 동시에 메시지를 전송할 수 있으며, Kafka topic의 메시지를 여러 컨슈머들이 동시에 읽어 갈 수 있습니다. 때문에, 다중 프로듀서/컨슈머의 지원으로 하나의 Kafka 시스템을 통해 다양한 애플리케이션이 데이터를 주고 받을 수 있습니다.
2. Kafka는 프로듀서가 생성한 메시지를 브로커가 위치한 서버의 파일 시스템에 저장할 수 있기 때문에, 데이터의 영속성을 보장해 줍니다.
3. Scale out 즉, 확장성이 용이합니다. 프로듀서, 컨슈머, 브로커등을 운영중에 추가할 수 있으며 예를 들어 초창기에 적은 수의 브로커들로 클러스터를 운영하다가 시스템 트래픽이 높아지면 브로커를 추가해서 클러스터를 확장할 수 있습니다.
4. Kafka는 Push가 아닌 컨슈머가 브로커에게서 메시지를 가져오는 Pull방식이기 때문에 컨슈머의 처리량을 브로커가 고민할 필요가 없습니다. 즉, 컨슈머는 자신이 처리할 수 있는 만큼의 메시지만 브로커에게서 가져가면 되기 때문에 최적의 메시지처리 성능을 가질 수 있습니다.

Apache Kafka의 아키텍처

이미지 1. Kafka 아키텍처(출처: Developer.holee Blog)

Kafka는 Publish-Subscribe 모델을 기반으로 동작하며, 위 이미와 같이 크게 producer, consumer, broker, Zookeeper로 구성됩니다. Producer는 특정 topic의 메시지를 생성한 뒤 해당 메시지를 broker에 전달합니다. Broker가 전달받은 메시지를 topic별로(Foo, bar) 분류하여 쌓아놓으면, 해당 topic을 구독하는 consumer들이 메시지를 가져가서 처리합니다. 클러스터 내의 broker에 대한 분산 처리는 이미지 1. Kafka 아키텍처와 같이 🌎Apache ZooKeeper가 담당합니다.

여담으로, Apache Kafka에 대한 자료를 찾다가 Apache Kafka에서 Zookeeper을 제거한다는 소식이 있다는 것을 알게되었습니다. 🌎아파치 카프카에서 ‘주키퍼’ 빠진다…”내부 메타데이터 프로토콜로 대체”

조금 더 깊이 들어 가기 전, Apache Kafka의 기본 개념은 아래와 같습니다.

• 프로듀서(Producer) : 데이터를 발생시키고 Kafka 클러스터에 적재하는 프로세스입니다.
• 카프카 클러스터(Kafka Cluster) : 카프카 클러스터는 카프카 서버로 이루어진 클러스터를 말하며, 카프카 클러스터를 이루는 각 요소는 다음과 같습니다.
• 토픽(Topic) : Kafka 클러스터에 데이터를 관리할 시 그 기준이 되는 개념입니다. 토픽은 Kafka 클러스터에서 여러개 만들 수 있으며 하나의 토픽은 1개 이상의 파티션으로 구성되어 있습니다.
• 브로커(Broker) : Broker는 실행 된 Kafka serve 중 1대를 뜻합니다.
• 파티션(Partition) : 각 토픽 당 데이터를 분산 처리하는 단위입니다. Kafka에서는 토픽 안에 파티션을 나누어 그 수 대로 데이터를 분산처리합니다.
• Offset : 파티션 내의 각 레코드를 고유하게 식별하는 순차적인 ID를 뜻합니다.
• 주키퍼(Zookeeper) : 주키퍼는 분산 코디네이션 시스템입니다. Kafka 브로커를 하나의 클러스터로 코디네이팅하는 역할을 합니다.
• 컨슈머 그룹(Consumer Group) : 컨슈머의 집합을 구성하는 단위입니다. 카프카에서는 컨슈머 그룹으로서 데이터를 처리하며 컨슈머 그룹 안의 컨슈머 수만큼 파티션의 데이터를 분산처리하게 됩니다.
• Broker Partition Replication : Replication은 각 Topic의 Partition들을 Kafka Cluster내의 다른 Broker들로 복제하는 것을 말하며 Topic생성 시 Replication의 수를 지정할 수 있습니다. 생성된 Replication은 Leader와 Follower로 나뉘어 ISR(In Sync Replica)이라는 일종의 Replication Group을 형성하여 관리됩니다.
• ISR(In Sync Replica) : Reader, Follower 파티션이 모두 동기화된 상태를 말합니다.

Kafka 아키텍처의 구성요소

1. Topic과 Partition

이미지 2. Kafka Topic(출처: Apache Kafka)

하나의 topic이 3개의 partition에 분산되어 순차적으로 저장되어지는데, 이 때 각 partition은 0부터 1씩 증가하는 offset 값(고유 ID)을 메시지에 부여합니다. offset 값은 partition마다 별도로 관리되기 때문에 topic내에서 메시지를 식별할 때는 partition 번호와 offset 값을 함께 사용합니다.

2. Broker

Kafka Cluster는 여러대의 broker(server)로 구성되어져 있습니다. 보통 3개 이상의 broker로 클러스터를 운영하며, 각각의 broker는 고유한 id 값으로 구분되어집니다.

이미지 3. Replication(파란색이 리더)

Replication은 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전 하게 하기 위해 사용됩니다. Kafka의 데이터 복제는 파티션 단위로 이루어집니다. 위와 같이 3개의 broker가 있을 때, 복제된 파티션은 1개의 리더(leader)와 N-1개의 팔로워(follower)로 구성됩니다. 각각의 팔로워는 리더의 오프셋을 확인하고, 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 리더로부터 데이터를 가져와서 자신의 파티션에 저장합니다. 파티션의 데이터가 복제되므로 복제 개수만큼의 비용이 발생하게 되지만 데이터의 안전이 보장되기 때문에 이러한 비용을 감수하고 복제를 수행한다고 합니다.

이미지 4. Replication-error

여기서 갑자기 리더의 broker에 error가 발생하게 된다면, 팔로워 파티션 중 하나가 리더 파티션의 지위를 넘겨받게 됩니다. 이를 통해 데이터가 유실되지 않고 데이터의 안전성을 보장할 수 있게 됩니다.

3. Consumers와 Consumer Groups

이미지 5. Consumer Groups

Kafka의 파티션은 consumer group당 오로지 하나의 컨슈머의 접근만을 허용합니다. 따라서 동일한 consumer group에 속하는 컨슈머끼리는 동일한 파티션에 접근할 수 없습니다. 만일, 컨슈머가 추가/제거되면 추가/제거된 컨슈머가 속한 consumer group 내의 컨슈머들의 파티션 재분배가 발생하고, broker가 추가/제거되면 전체 consumer group에서 파티션 재분배가 발생합니다.

위의 그림과 같이 consumer group을 구성하는 컨슈머의 수가 파티션의 수보다 작으면 하나의 컨슈머가 여러 개의 파티션을 소유할 수 있습니다. 하지만, 반대로 컨슈머의 수가 파티션의 수보다 많다면 몇몇 컨슈머는 수행 하는 것이 없이 놀고 있을 수 있습니다. 때문에 파티션 개수와 컨슈머 수의 적절한 설정이 필요합니다.

끝맺음

Apache Kafka는 근래에 가졌던 가장 최고의 관심사 였는데, 오늘 공부를 해보면서 이론만으로는 부족하다는 느낌을 절실히 경험했습니다. 다음 포스팅에는 이론이 아닌 실전편의 Kafka를 포스팅 해보려고 합니다! 공부하면서 포스팅을 하다보니 많은 부족한 점이 있을 수 있습니다. 혹여나 내용에 이상이 있다면 댓글로 알려주시면 감사드립니다! 😀👍

[참고자료]

• Apache Kafka Docs
• 서해바다 - Apache Kafka 기본 개념 총정리
• Message Oriented Middleware
• 링크드인은 왜 Kafka를 만들었나
• Developer.holee - Apache Kafka
• https://zookeeper.apache.org/