[Kafka] 1. 개념 정리

이강호·2022년 10월 10일

회사에서 Kafka를 사용해 보았다.
실시간으로 여러 서버에서 발생하는 데이터들을 Kafka에 저장하고, 그 데이터들을 읽어 DB에 저장하기도 하고 다른 시스템에게 전송하기도 했다.
이에 Kafka는 무엇인지, Kafka에서 제공하는 기능에는 어떤 것들이 있는지 찾아보고 정리하고자 한다.

먼저 Kafka를 간단하게 3가지 키워드로 정의해보자.
Kafka의 소개글에서 굵직한 키워드들을 살펴보면,

Event Streaming

Publish and Subscribe

Server and Client

이렇게 3가지 키워드로 정리해 볼 수 있을 것 같다. 하나하나 톺아보도록 하자.

1. Event Streaming

Event는 어떤 순간에 발생한 사건이고, Streaming은 그것을 실시간으로 송수신하는 것으로 볼 수 있다. 그렇다면 Event Streaming은 Event가 발생하면 해당 Event를 알고 싶어하는 곳까지 실시간으로 전송해주는 것을 의미한다.

과거 DB에 저장되는 데이터들은 주로 정적인 값들이었다. 최근에 저장이 필요한 데이터들은 시간과 사건을 나타내는 log의 성질들 가지게 되었고, 이를 저장하기에는 기존의 DB 구조에서는 효율이 떨어졌다. 이에 이러한 log성 값들을 위한 저장소로 Kafka가 등장하게 되었고, Topic이라는 주제 아래에 Partition이라는 분산된 구조로 데이터들을 관리하게 되었다. Kafka가 Event Streaming을 어떻게 하는지는 아래 항목에서 알아보자.

Kafka에서는 Event를 발생시키는 Publisher와 해당 Event를 필요로 하는 Subscriber가 있다. Publisher에서 Event가 발생하면 자신의 Topic에 해당 Event를 Publish하게 된다. 그러면 Kafka Server가 이를 수신하고 저장한 후, Subscriber의 요청이 오면 해당 값을 전달하게 된다. Kafka는 이 과정을 어떻게 빠르게 동작하게 했을까.

그 이유 중 하나는 Kafka가 순차적 접근 방식을 사용하기 때문이다. Kafka는 Topic을 하드 디스크에 저장한다. 하드 디스크는 가격대비 용량은 크지만 데이터 저장 및 탐색 속도는 SSD나 메모리보다 많이 느리다. 그 가장 큰 이유로는 데이터 탐색을 위해 Disk arm의 이동이 필요하기 때문이다. Kafka는 여기서 순차적 접근 방식을 통해 Disk arm의 이동을 최소화하였다. Disk arm의 이동 시간이 줄게 되면 빠르게 데이터를 저장할 수 있고, 비용적 이득도 취할 수 있게 된다.

다음으로 Kafka가 빠른 이유는 Zero-Copy 방식을 사용하기 때문이다. Subscribe 요청이 Kafka Server로 들어오게 되면 Kafka는 해당 요청을 자신의 buffer로 읽어 오지않고, OS에서 바로 NIC(Network Interface Card)로 값을 전송하게 된다. OS에서 Kafka로, Kafka에서 Socket Buffer로, Socket Buffer에서 NIC로 전달되는 과정 안에서 사본의 생성을 생략함을 통해 Kafka는 빠른 속도로 데이터를 전송하게 된다(DMA). 이 과정을 Zero-Copy라고 한다.

3. Server and Client

Kafka는 Server에 데이터를 저장하고 Client의 요청(Publish, Subscribe)을 처리하는 구조를 지닌다. 여기서 Broker라는 개념이 등장하게 된다. Broker는 사전적으로 중개인이라는 의미로 판매자와 구매자 사이에서 중개를 해주는 역할을 의미한다. Kafka에서 Broker는 Publisher로부터 받은 Event 정보를 하드 디스크에 저장하고, Subscriber로부터 온 요청에 따라 Topic을 읽어 전달한다.

이러한 Broker는 한 대 이상의 노드들로 구성되어 Cluster를 이루게 된다. 그 기반에는 Zookeeper라는 코디네이션 개념의 툴이 들어가기도 하는데, 이에 대한 상세 설명은 다음 기회에 다루기로 하자.

Kafka Cluster에는 Leader와 Follower가 있게 된다. Leader는 Publisher나 Subscriber로부터 전달 받은 데이터의 쓰기/읽기 요청을 처리하는 Broker이다. Follower는 Leader의 데이터를 바라보며 이를 복제하기만 한다. 만약 Leader인 Broker가 문제가 생긴다면, Kafka는 Zookeeper를 통해 Follower 중 하나가 Broker의 역할을 수행할 수 있도록 한다.

이렇게 Kafka Cluster에 존재하는 Ledaer와 Follower의 집합을 ISR 그룹 (In Sync Replica)이라고 칭한다. ISR 그룹은 Topic의 Partition 별로 존재하며, 각 Partition 별 ISR에서 Ledaer와 Follower들은 모두 제각각일 수 있다.

이렇게 구성된 Kafka Cluster는 고가용성(HA)이 필요한 환경에서 유용하게 사용된다. 앞서 말했듯이 Leader가 읽기와 쓰기를 처리하다가 이 Broker에 문제가 생기면 다른 Broker들이 역할을 이어받아 수행하기에 Fail-Over 장애 처리에 효과적이다.
.
.
.