[학습 테스트로 배워보는 kafka] 2. 카프카 컨셉 빠르게 알아보기

---

해당 시리즈에서 제공하는 모든 소스코드는 github repository 에서 제공됩니다. 자세한 코드와 테스트 케이스는 github repository 에서 확인해주세요.

GitHub - my-research/kafka: apache kafka docs & practical usages(with spring) that i composed

이번 [학습 테스트로 배워보는 kafka] 시리즈는 아래 순서대로 챕터가 구성되고, 시리즈 외로 kafka 관련하여 더욱 많은 학습 정보는 kafka 심화 세션 에서 확인할 수 있습니다.

시리즈 목차

1. 시리즈를 시작하며
2. kafka 빠르게 훑어보고 아는체하기
3. kafka 컨셉과 용어 정리 <-- 현재 글
4. 학습테스트 준비하기
5. 학습 테스트로 kafka producer 알아보기
6. 학습 테스트로 kafka consumer 알아보기
7. 학습 테스트로 partitioning 알아보기
8. 학습 테스트로 consumer group 과 rebalancing 알아보기

학습의 단계별 순서로 목차가 구성되어있으므로 선행되어야 하는 챕터가 존재합니다

---

이번 챕터에서는 kafka 에서 사용되는 용어에 대해서 알아보도록 하겠다

오늘의 목표는 앞선 목표와 동일하게 이 글만 보고도 어디가서 카프카에 대해서 아는체 할 수 있도록 하는 것이다.

 

최대한 핵심만 정확히 구성하려 노력하였으니 짧고 빠르게 집중해서 읽고 어디가서 아는척하자

 

카프카의 6가지의 핵심 요소

 

카프카는 문서(Introduction of kafka's terminology에서도 알 수 있듯이 크게 6가지의 용어를 사용한다.

 

1. 카프카의 핵심 서버, broker
2. 카프카의 데이터 저장 테이블, topic
3. 카프카의 업스트림 클라이언트, producer
4. 카프카의 다운스트림 클라이언트, consumer
5. 카프카의 실질적인 메시지 큐, partition
6. 카프카의 핵심 안전요소, replication

 

카프카는 위의 6가지 구성요소를 통해 메시징 인프라를 TCP 네트워크 위에서 제공한다.

 

 

위 그림은 앞선 6가지 구성요소를 표현한 그림이다.

 

자세히 설명하기 전에 먼저 요약해서 정리해보겠다. 정말 바쁘다면!! 이 요약만 보고 넘어가도 좋다.

 

어차피 추후에 우리가 학습테스트를 진행하며 각각의 항목들에 대해서 더 자세히 다루도록 하고 지금 시간은 예열쯤으로 생각하자

 

• broker
  • 카프카 브로커, 핵심 구성요소
  • 카프카로 들어오는 이벤트 데이터의 스토리지 서버
  • 토픽, 파티션, 복제등을 관리
• topic
  • 이벤트의 카테고리
  • 이벤트가 저장되는 단위
  • 프로듀서와 컨슈머가 바라보는 기본적인 단위
• producer
  • 토픽에 메시지를 생산
  • 특정 파티션에도 생산 가능
• consumer
  • 토픽의 메시지를 소비
  • 특정 파티션에도 소비 가능
• partition
  • 카프카 토픽에 존재하는 실제 메시지 저장소

 

1. 카프카의 핵심 서버, broker

Kafka 의 broker 는 앞서 Message Oriented Middleware과 Message Broker의 차이 및 원리 라는 글에서 언급했던 message broker 와 동일한 개념으로 message provider 다.

 

카프카 브로커라고 불리는 컴포넌트는 특정한 upstream producer 로 부터 발생하는 이벤트 스트림을 저장하는 서버이다.

 

카프카 브로커는 이벤트를 저장하는 스토리지 레이어 서버인데, 해당 시리즈의 앞선 파트 1. 카프카 핵심 빠르게 훑어보고 아는체하기 이야기했던 log based architecture 를 위한 실제 데이터 스토리지 엔진이라고 보면 된다.

 

카프카 브로커는 사실상 카프카 인프라의 핵심이고 심장이라고 할 수 있다.

 

아래에서 이야기할 파티션과 리플리케이션들을 관리하기도 하며 producer 와 consumer 로부터 들어오는 read/write request 를 처리한다

 

많은 일을 하는것 처럼 보이지만 confluent 가 제공하는 kafka 101 이라는 학습용 영상에서는 kafka broker dont do a lot, They are intentionally kept very simple 라고 한다.

 

번외로, 카프카 클러스터라는 용어도 많이 들어봤을 것이다

 

이 카프카 클러스터가 바로 여러개의 카프카 브로커들을 묶어놓은 개념이다.

 

즉, 우리는 클러스터의 한 브로커에 connection 을 맺어 상호작용을 하게 된다.

 

재미있는 특징으로는 카프카 브로커는 bootstrap server 로서 역할을 수행한다.

 

bootstrap 은 일반적으로 initialize 단계에서 사용되는 초기화 데이터 혹은 실행을 위한 초기 설정 단계의 작업을 이야기한다.

 

그래서 특정 브로커가 bootstrap server 를 수행하여 다른 브로커들과 연결할 수 있고, 연결된 브로커들 자체가 bootstraping 을 할 수 있다는 것이다.

 

confluent.io

 

그래서 클러스터에 존재하는 모든 브로커 하나 하나가 다른 클러스터의 대표 브로커가 될 수 있다. (이 특성이 고가용성을 지원하는 특성이 된다)

 

결국 클라이언트는 특정 브로커에 접속하여 클러스터 내의 메타데이터 (브로커 목록, 토픽 정보 등)을 가져오고 이 정보를 기반으로 다른 브로커들과 연결할 수 있도록 하는 것이다.

 

2. 카프카의 데이터 저장 테이블, topic

 

topic 은 카테고리라고 생각하면 된다.

 

kafka 로 들어오는 모든 이벤트들에 대해서 토픽이라는 단위로 categorizing 하여 데이터를 storing 한다.

 

이벤트가 저장되는 가장 기본 구성 단위라고 할 수 있고, 토픽을 파일시스템으로 설명하는 것이 가장 일반적이다.

 

토픽이 디렉토리라고 한다면 이벤트들은 해당 디렉토리 내부에 존재하는 파일들이라고 생각하면 된다

 

.
├── order.ordered <- topic
│   ├── event-1
│   ├── event-2
│   ├── event-3
│   ├── event-4
├── member.terminated <- topic
│   ├── event-1
│   ├── event-2
│   └── event-3

 

토픽은 append only 이며, 새 이벤트 메시지가 토픽에 들어와 저장이 된다면 절대 수정될 수 없다.

 

다른 일반적인 큐 형식의 메시징 인프라와 달리 토픽에는 producer 와 consumer 가 여러개 일 수 있는 것을 기억하자

 

역시 kafka 101 영상에서는 토픽을 queue 가 아니라 log of events 라고 표현한다. log 라는 컨셉이 있기에 immutable, append only 그리고 seek by offset 이 자연스러운 것이다.

3. 카프카의 업스트림 클라이언트, producer

 

producer 는 이벤트를 생산하는 클라이언트다.

 

보통 upstream 혹은 생산자 혹은 publisher 라고 표현하기도 하는데, producer 가 topic 에 이벤트를 전송하는 역할을 수행한다

 

 

프로듀서는 원한다면 특정 topic 내의 partition 에도 메시지를 발행할 수 있다

 

자세한 것은 후에 있을 프로듀서 파트에서 더 이야기하도록 하자

 

4. 카프카의 다운스트림 클라이언트, consumer

 

consumer 는 카프카에서 이벤트를 소비하는 클라이언트다.

 

역시 consumer 를 downstream, 소비자 혹은 subscriber 라고 표현한다.

 

consumer 는 특정 토픽에서 이벤트를 읽고 어디까지 읽었는지에 대한 정보를 오프셋 이라는 데이터로 구분한다.

 

일반적인 상황에서는 오프셋이 순차적으로 증가하겠지만, 오프셋을 컨슈머가 결정하여 언제든 특정 위치로부터 데이터를 소비할 수 있다.

 

자세한 것은 역시 후에 있을 컨슈머 파트에서 더 이야기하도록 하자

 

5. 카프카의 실질적인 저장소, partition

 

어떠한 이벤트가 생산자에 의해서 publish 된다면, 실제로는 토픽에 저장되는것이 아니라 토픽에 존재하는 특정 파티션에 저장되는 것이다.

 

카프카는 하나의 토픽 내에서 여러개의 파티션을 만들 수 있도록 하여 처리량을 늘린다.

 

6. 카프카의 핵심 안전요소, replication

 

앞전에 카프카는 high availability 와 scalability 를 지원한다고 했는데, 그 핵심 요소가 바로 이 replication 이다.

 

카프카에서 replication 을 활성화한다면 모든 토픽을 복제하여 장애에 대한 내결함을 갖도록 한다.

 

실제로 데이터가 카프카 브로커로 들어왔을 때 어느 한 토픽에 데이터가 쌓인다면 replication 에 의해서 복제본 토픽에 같이 쌓이게 된다.