Apache Kafka 개념 정리

728x90

Apache Kafka 개념

오픈 소스 분산형 이벤트 스트리밍 플랫폼으로 고성능의 데이터 파이프 라이닝, 스트리밍 분석,데이터 통합과 업무에 필수적인 어플리케이션을 위한 수많은 기업들에서 사용됨
아파치 소프트웨어 재단이 스칼라로 개발한 오픈 소스 메시지 브로커 프로젝트이고, 이 프로젝트는 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것이 목표
분산 트랜잭션 로그로 구성된, 상당히 확장 가능한 pub/sub 메시지 큐로 정의할 수 있으며, 스트리밍 데이터를 처리하기 위한 기업 인프라를 위한 고부가 가치 기능이고, 디자인은 트랜잭션 로그에 많은 영향을 받았음
대표적인 메시징 시스템으로 Kafka, RabbitMQ, ActiveMQ가 있음

Kafka 아키텍쳐

Zookeeper(Apache Zookeeper)
- 본래 Zookeeper의 용도는 클러스터 최신 설정정보 관리, 동기화, 리더 채택 등 클러스터의 서버들이 공유하는 데이터를 관리하기 위해 사용
- 클러스터를 관리하는 Zookeeper 없이는 Kafka 구동이 불가능하고, 즉, Kafka 서버를 가동하려면 Zookeeper를 먼저 가동해줘야 함
Broker
- Kafka Server
- 한 클러스터 내에서 Kafka server를 여러 대 띄울수 있음
Topic
- 메시지가 생산되고 소비되는 주제
  - 예를 들어, 카톡 단체방 A, B가 있는데, A 방으로 보낸 메시지가 B 방에 노출되면 안되기 때문에, A 방에서 생산된 메시지는 A 방에 존재하는 사람들(구독한 사람)에게만 보여져야 함
- 주제에 따라 여러 topic을 생성하면 됨(email topic, sms topic, push topic...)
Partition
- Topic 내에서 메시지가 분산되어 저장되는 단위
  - 한 Topic에 Partition이 3개 있다면, 3개의 Partition에 대해서 메시지가 분산되어 저장됨
  - 이 때 Queue 방식으로 저장되므로 Partition의 끄트머리에 저장이 되어 Partition 내에서는 순서를 보장해주지만, Partition끼리는 메시지 순서를 보장해주지 않음
Log
- Partition의 한 칸을 Log라고 하며, Log는 key, value, timestamp로 구성됨
Offset
- Partition의 각 메시지를 식별할 수 있는 유니크한 값
  - 메시지를 소비하는 Consumer가 읽을 차례를 의미하므로 Partition마다 별도로 관리됨
  - 0부터 시작하여 1씩 증가

Producer & Consumer Group

메시지 생산/소비
- Producer
  - Producer는 정해진 Topic으로 메시지를 기록
  - Partition이 여러 개 있을 경우, 기록될 Partition의 선택은 기본적으로 Round-Robin 방식을 따름
    - Partition이 여러 개 있으면 병렬 처리라는 이점이 있지만, Partition 개수는 주의해서 잘 설정해줘야 함
  - 각 Partition 내에서는 가장 마지막 offset 뒤에 신규 메시지가 저장되므로, Partition 내에서는 순서가 보장되며 기록됨
    - 하지만 실제 메시지가 사용되는 순서는 순서가 보장되지 않으며, 그 이유는 Consumer의 동작 방식을 이해해야 함
- Consumer Group(관련 자료 : https://www.popit.kr/kafka-consumer-group/)
  - Consumer Group은 하나의 Topic을 담당하며, Topic은 여러 개의 Consumer Group이 접근할 수 있지만, 하나의 Consumer Group은 하나의 Topic에만 접근할 수 있음
  - Consumer Group은 컨슈머 인스턴스들을 대표하는 그룹
  - Consumer Instance는 하나의 프로세스 또는 하나의 서버라고 할 수 있음
  - Offset은 파티션안에 데이터 위치를 유니크한 숫자로 표시한 것을 말하고, 컨슈머는 자신이 어디까지 데이터를 가져갔는지 offset을 이용해서 관리함
  - Partition의 개수 >= Consumer 인스턴스의 갯수 유지하는 것이 좋음
  - 주의할 점은 한 번 Partition을 늘리면 다시 줄일 수 없기 때문에, 처리량을 잘 고려하여 Partition과 Consumer의 개수를 선택해야 할 것
  - 1) Partition 접근하는 Consumer 관리 : Consumer Group 내에서 Consumer 인스턴스들은 Topic내에 Partition에서 다음에 소비할 offset이 어디인지 공유하면서 메시지를 소비하기 때문에 다음에 소비할 offset을 잘 관리할 수 있음
    - 예를 들어 Consumer Group이 없을 경우, 하나의 Partition에 2개의 Consumer가 동시에 접근한다면 어떤 Consumer가 몇 번의 offset을 소비해야 하는지 알 수 없게 됨
    - 즉, Consumer Group을 통해 하나의 Partition에는 하나의 Consumer 인스턴스만 접근할 수 있도록 관리함
  - 2) offset을 공유하여 고가용성을 확보 : Partition에는 하나의 Consumer 인스턴스만 접근할 수 있기 때문에, 특정 Consumer 인스턴스에 에러가 발생했을 시 다른 Consumer 인스턴스는 에러가 발생한 Consumer 인스턴스가 소비하던 Partition을 소비하게 됨
    - 즉, Consumer가 다운될 때를 대비해 Consumer Group의 Consumer 인스턴스들은 offset을 공유하고 있으며, 이를 통해 고가용성이 확보됨

Consumer Design

Kafka와 마찬가지로, 대표적인 메시징 시스템인 RabbitMQ, ActiveMQ도 분산 큐 시스템(Distributed Queue System)
RabbitMQ
- Message Broker가 Consumer에게 메시지를 push하는 방식
  - Broker는 Consumer의 처리여부에 관계없이 push를 하므로, 메시지 소비 속도보다 생산 속도가 빠를 경우 Consumer에 부하를 주게 됨
  - RabbitMQ는 DRAM을 사용하므로 buffer를 사용하지만, DRAM을 다 사용하면 disk에 저장함
  - 따라서 batch 같이 큰 작업에서는 disk로 메시지를 읽어올 경우 지연이 발생함
Kafka
- Consumer가 Broker로부터 메시지를 pull하는 방식
  - Consumer가 처리할 수 있을 때 메시지를 가져오므로 자원을 효율적으로 사용
  - Kafka는 애초에 메시지를 disk에 저장하고, 이미 처리한 과거의 offset으로 자유롭게 움직일 수 있으므로 batch 작업에서 자원의 낭비라던지 지연이 발생하지 않음
  - 메시지를 쌓아두었다가 처리하는 batch Consumer 구현도 가능
  - 데이터가 없음에도 정기적인 polling으로 인해 자원을 낭비하는 문제가 있지만, 이러한 단점을 보완하기 위해 실제 데이터가 도착할 때까지 long poll 대기를 할 수 있는 parameter를 지원함

Replication

Topic을 생성할 때, --replication-factor 옵션을 부여하면 복제본(replication)을 생성할 수 있음
Replication이란 Zookeeper가 leader가 되는 Partition을 정하고, Partition을 각 broker마다 복제를 하는 것을 말하며, 이때 leader를 복제하는 partition을 follow라고 함
- leader : 메시지를 생산하고 소비하는 작업은 모두 leader broker에서 이뤄짐
- follower : 나머지 follower들은 leader를 복제하기만 함
- 이는 고가용성을 위한것이며, 혹시 leader가 죽었을 경우 follower 중 하나가 leader가 되어야 하기 때문에, follower는 leader와 싱크를 맞추고 있는 것(In-Sync Replica, ISR)