[Kafka Study] 02. 카프카 기본 개념과 구조 w/실전 카프카 개발부터 운영까지

책에서는 2장에서 실습 환경 구성을 하고, 3장부터 실습을 하면서 카프카 기본 개념을 설명한다. 그런데 환경 구성에 필요한 VM 인스턴스만 7개이다 보니 기본 구조와 용어를 먼저 이해하고 구축해보는 게 더 좋겠다는 생각이 들었다. 그래서 이번에는 용어만 간단하게 정리해보았다.

기본 개념과 구조

스터디하는 책의 2~3장과 데브원영님의 <아파치 카프카 애플리케이션 프로그래밍>을 기반으로 내가 이해한 카프카의 구조를 그려보았다. 전체 구조를 이해하기까지 시간이 많이 걸렸는데, 이렇게 그려놓고 보니 생각보다 간단한 구조인 것 같다.

1. 프로듀서Producer : 카프카에 메시지를 만들어서 전달하는 클라이언트를 총칭
2. 컨슈머Consumer : 카프카로부터 데이터를 받아 소비하는 클라이언트
3. 카프카Kafka 또는 카프카 클러스터Kafka Cluster : 프로듀서와 컨슈머 사이에서 메시지 브로커 역할을 하는 애플리케이션 또는 그 클러스터
4. 주키퍼Zookeeper 또는 주키퍼 앙상블Zookeeper Ensemble : 카프카가 정상적으로 동작할 수 있도록 카프카의 메타데이터 저장, 브로커의 노드 관리 등의 역할을 하는 애플리케이션 또는 그 앙상블 
5. 브로커Broker : 카프카 애플리케이션이 설치된 서버 또는 노드
6. 토픽Topic : 카프카에서 메시지 피드를 구분하기 위한 저장소
7. 파티션Partition : 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것
8. 세그먼트Segment : 프로듀서가 전송한 실제 메시지가 로그 파일 형태로 브로커의 로컬 디스크에 저장된 것
9. 메시지Message 또는 레코드Record : 프로듀서와 컨슈머가 브로커에서 전송하거나 읽어가는 데이터 조각
10. 리플리케이션Replication : 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 다른 브로커에 분산시키는 동작 

 

 

 

하나씩 뜯어보기

카프카의 기본 구조를 가장 간단하게 표현하면 이렇게 생겼다. 원래는 주키퍼도 있어야 하는데, Apache Kafka 2.8.0 이후로 주키퍼에 의존성을 모두 제거했다고 한다. 오늘 기준 가장 최근 릴리즈 버전은 3.1이니 훨씬 안정화되었을 것이다.

하지만 주키퍼에 의존성을 제거했다고 주키퍼가 필요 없어진 것은 아니라고 한다. 카프카를 쓰기 위해 주키퍼까지 공부하고 구성해야 하는 리소스가 줄었다는 의미이고, 주키퍼와 카프카를 분리해서 관리해보는 것도 가능해졌다고 이해하면 되겠다. 주키퍼는 카프카와만 통신하기 때문에 구조는 아래와 같다.

 

프로듀서Producer와 컨슈머Consumer

카프카는 기본적으로 데이터 버스Data Bus 또는 메시지 버스Message Bus 역할을 한다. 그렇기 때문에 메시지를 만들어서 보내주는 프로듀서와 메시지를 가져가서 소비하는 컨슈머가 있어야 그 메시지를 받아서 저장하고, 다시 전달하는 일을 할 수 있다. 이들은 중앙에 위치한 카프카 애플리케이션의 클라이언트로, 프로듀서 클라이언트와 컨슈머 클라이언트라고도 한다.

프로듀서와 컨슈머는 클라이언트 개수에 따라 1:1, 1:N, N:1, N:N의 관계로 나눌 수 있다. 카프카 에코시스템에서는 클라이언트들과 배치 전송 처리 방식으로 높은 성능을 내기 때문에 주로 N:N 관계에서 필요로 한다. 이러한 구조에서 클라이언트 각각 또는 전부를 통칭해서 '프로듀서'와 '컨슈머'라고 부른다.

가장 헷갈렸던 부분인데, 프로듀서와 컨슈머는 원래 메시지를 전송하거나 전달받는 다른 애플리케이션에 붙는 클라이언트 개념이다. 대부분 자바를 사용하고, (다행히) 파이썬으로도 구현이 가능하다고 한다. 그런데 대규모 아키텍쳐를 구축하면서 매번 프로듀서와 컨슈머 클라이언트를 개발하는건 매우 비효율적이다. 그래서 이를 좀 더 수월하게 개발할 수 있도록 도와주는 도구가 바로 카프카 커넥트Kafka Connect이다. 프로듀서 역할을 하는 소스 커넥터Source Connector와 컨슈머 역할을 하는 싱크 커넥터Sink Connector가 있다.

https://debezium.io/documentation/reference/1.3/architecture.html

 

카프카Kafka 또는 카프카 클러스터Kafka Cluster

카프카는 분산 처리를 하기 때문에 보통 카프카 노드를 3대 이상 구동한다. 이렇게 분산 처리를 하는 카프카 노드들의 그룹을 카프카 클러스터라고 한다. 그리고 카프카 에코시스템에는 하나 이상의 카프카 클러스터를 구축할 수 있고, 이 클러스터들을 주키퍼 앙상블 하나에 연동하기도 한다. 용어의 의미와는 별개로 일반적으로 말하는 '카프카'는 편의상 카프카 클러스터나 카프카 에코시스템을 통칭해서 사용하는 것 같다. 또 하나 카프카와 혼용하는 용어로는 브로커가 있는데, 이건 브로커 순서에서 다시 보자.

 

주키퍼Zookeeper 또는 주키퍼 앙상블Zookeeper Ensemble

주키퍼도 카프카처럼 일반적인 운영 환경에서는 여러 노드를 가진 클러스터 구조로 구축한다. 주키퍼는 고가용성을 목적으로 replicated mode를 수행한다는 점에서 카프카 클러스터링과 차이가 있다. 이러한 주키퍼 특유의 클러스터 구조를 주키퍼 앙상블이라고 한다. 그러니까 주키퍼 앙상블과 카프카 클러스터의 구조는 아래처럼 생겼다고 볼 수 있다.

 

브로커Broker

사실 일반적인 메시징 시스템에서 프로듀서와 컨슈머 사이에는 브로커가 있다. 셀러리Celery 브로커를 예로 들면, Redis나 RabbitMQ같은 서비스를 말한다. 이와 달리, 카프카 에코시스템에서는 카프카가 설치된 서버 또는 노드를 브로커라고 부른다. 일반적으로 하나의 브로커에 카프카를 하나씩 설치해서인지 브로커를 카프카라고 부르는 경우가 있다. 혼동하지 않도록 주의!

카프카의 특징으로 확장성을 꼽는데, 여기에는 브로커가 관련되어 있다. 카프카 클러스터의 리소스가 한계에 도달하면 브로커를 추가해서 시스템을 확장할 수 있다. 운영 중에도 자유롭게 확장할 수 있다는 점이 장점으로 꼽힌다.

이렇게 브로커를 여러 대 붙여서 분산 처리를 한다는 것은 쉽게 이해할 수 있다. 그런데 카프카는 토픽과 파티션, 그리고 세그먼트를 통해 더 높은 성능으로 분산 처리를 하고, 리플리케이션으로 안정성을 확보한다. 각 요소의 관계는 아래와 같다.

(이 그림에서만) 각진 사각형은 물리적 공간, 둥근 사각형은 논리적 공간을 의미한다

 

토픽Topic

카프카에서 프로듀서와 컨슈머가 메시지를 전달하고 전달받는 대상이 바로 이 토픽이다. 토픽은 카프카에서 메시지를 구분하기 위해 사용하는 논리적 단위로, 실제로 메시지가 저장되는 물리적 공간은 하나 이상의 파티션으로 나뉜다. 카프카는 토픽을 기준으로 메시지를 발행하고 소비하기 때문에 하나의 토픽에 속한 메시지들은 논리적으로 같은 주제 또는 문맥(contect)를 가지도록 설계해야 한다.

 

파티션Partition

위에 말한 것처럼 토픽에 속한 메시지들이 실제로 저장되는 물리적 공간을 파티션이라고 한다. 파티션은 위 그림에서와 같이 브로커 내부에서 하나 이상의 공간으로 나뉘어있다. 독특한 점은 토픽과 파티션이 1:1 또는 1:N의 관계가 아니라 N:N의 관계로 할당된다는 것이다. 위 그림에서는 표현하기 어려워서 한 토픽 안에 여러 파티션이 있는 1:N의 관계처럼 그렸지만, 실제로는 아래 그림처럼 N:N 관계로 저장된다. 이때, 파티션은 카프카 클러스터의 모든 파티션에 골고루 나뉜다는 점이 중요하다. 리더 파티션과 팔로워 파티션으로 설명하는데, 이건 뒤에서 더 자세히 다루기 때문에 나중에 다시 공부해야겠다.

https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matteR

 

세그먼트Segment

마지막으로 파티션 내부에 저장되는 메시지의 실체인 세그먼트가 있다. 세그먼트는 어떤 물리적 또는 논리적 공간이 아니라 로컬디스크에 log 파일 형태로 저장된 실제 메시지 데이터를 말한다. 구조를 표현한 그림에서 00000.log, 00001.log 등으로 적어놓은 파일들이 세그먼트를 의미한다.

이렇게 카프카는 토픽과 파티션, 세그먼트를 통해 메시지를 관리한다. 여기에서 카프카의 핵심 개념 중 하나인 리플리케이션을 알아야 한다.

 

리플리케이션Replication

리플리케이션은 메시지 복제본Replica을 여러 개 생성하고, 이를 카프카 클러스터의 여러 브로커에 분산 저장해서 안정성을 확보하는 중요한 동작이다. 토픽을 만들면서 replication-factor 옵션으로 리플리카의 개수를 지정할 수 있다. 카프카에서는 리플리케이션 팩터를 3으로 설정하도록 권장하고 있고, 운영 시에는 목적에 따라 1개에서 3개까지 설정하는 것이 일반적이라고 한다.

• 데이터가 일부 유실되어도 무관하고, 데이터의 처리 속도가 중요한 경우: 1~2개
• 금융 정보와 같이 데이터 유실이 일어나면 안 되는 경우: 3개

카프카는 복제한 모든 데이터를 사용하지 않고, 원본과 리플리케이션을 리더Leader와 팔로워Follower로 구분하여 용도를 달리한다. 일반적인 상황에서 프로듀서와 컨슈머의 모든 읽기/쓰기 요청은 리더가 처리한다. 그동안 팔로워는 리더로부터 리플리케이션만 하다가 리더 또는 리더가 있는 브로커에서 문제가 발생하는 등의 경우에 활용된다. 자세한 내용은 4장에서 더 다룬다고 한다.

 

 

 

---

​

이제 카프카를 공부할 준비가 된 것 같다. 다음 장에서는 실습 환경을 구축하고, 예제를 통해서 프로듀서와 컨슈머의 기본 동작을 공부할 것이다.

 

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본 동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

 

※ 참고 자료와 이미지 출처 ※

[1] 실전 카프카 개발부터 운영까지, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791189909345#N
[2] 아파치 카프카 애플리케이션 프로그래밍 with 자바, http://www.kyobobook.co.kr/product/detailViewKor.laf?
[3] kafka강의2 | Topic이란? Pub/Sub 구조, https://pearlluck.tistory.com/289​
[4] 동물원을 탈출한 카프카 - Zookeeper-less Kafka, https://psm1782.medium.com/%EB%8F%99%EB%AC%BC%EC%9B%90%EC%9D%84-%ED%83%88%EC%B6%9C%ED%95%9C-%EC%B9%B4%ED%94%84%EC%B9%B4-zookeeper-less-kafka-a71cba58d5d9
[5] [Kafka] 카프카 커넥트, https://velog.io/@ehdrms2034/Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4-%EC%BB%A4%EB%84%A5%ED%8A%B8
[6] [Apache Zookeeper] 주키퍼의 기본 특징, https://jaemunbro.medium.com/zookeeper-%EC%A3%BC%ED%82%A4%ED%8D%BC%EC%9D%98-%EA%B8%B0%EB%B3%B8-%ED%8A%B9%EC%A7%95-7da2a51351c5
[7] [Kafka 101] 카프카 메시지와 토픽과 파티션 (Kafka Message, Topic and Partition), https://always-kimkim.tistory.com/entry/kaafka101-message-topic-partition
[8] Introduction to apache kafka, confluent and why they matter, https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matteR