Apache Kafka

카프카

분산시스템 메시지 처리

broker의 모임 = kafka cluster

zookeeper: 클러스터 서버들이 공유하는 데이터 관리

→ broker에 분산 처리된 메시지 큐의 정보 관리(카프카의 노드 관리, topic의 offset 정보 저장)

broker: kafka server/ 한 클러스터 내에서 여러개의 kafka server(broker)가 동작한다.

topic: 메시지가 생성되고 소비되는 주제. 다른 토픽들과 isolation (구독한 consumer에게만 보여짐)

partition: 파란 네모들 한 줄. topic 내에서 메시지가 분산되어 저장되는 단위. 한 topic에 있는 n개의 partition에 메시지가 분산되어 저장.

• partition 내에서는 queue 형태로 순서 보장 (offset 이용)
• partition끼리는 순서보장 X
• 한 번에 하나의 reader (한 파티션에 동시에 여러 consumer가 접근해서 읽어올 수 없다.)

log: 파란 네모 한 칸. key-value-timestamp로 구성

 

 

실제로는 topic과 partition이 위 그림처럼 분산저장되어있는 듯 하다.

(broker:3개, /// topic명: T1, partition 개수: 3 /// topic명: T2, partition 개수: 3 /// topic1, 2의 replication=1으로 가정)

분산 저장은 자동으로 되지만, 사용자가 원한다면 수동으로 재배치 가능

토픽 생성 시

    새로운 토픽을 생성하게 되면 브로커 간 파티션을 할당하는 방법을 결정한다.

    1) partition replica가 브로커 간 고르게 분산

    2) 각 partition의 replica는 서로 다른 브로커에 할당

---

consumer group

consumer는 사실 consumer instance 여러개로 이루어진 consumer group이다.

group 내의 instance들은 서로 정보를 공유하고 있음 → 한 서버가 다운되어도 대체 가능

1. 가용성
   consumer server 하나가 다운되어도 다른 서버가 대체할 수 있음
   여러 대의 consumer instance를 설정함으로써 안정성 확보
2. offset 관리
   각 그룹마다 서로 다른 offset을 유지함으로써 한 개의 topic에서 여러개의 consumer group이 접근해서 가져올 수 있음

* Partition-Instance 관계

       1:1인게 가장 이상적

       topic의 partition 수가 많다면 그만큼 instance 수를 늘려서 데이터를 빠르게 가져올 수 있다.

       → 그러나 topic partition 수는 늘릴 수 있지만 다시 줄일수는 없으므로 무작정 늘리면 안된다.

       # partitions >= # instances

 

메시지 보존 기간

       consumer가 메시지를 소비했다고 해서 바로 사라지지 않고 설정된 보존기간이 지나야 사라짐.

       default = 7일, log.retention.hours 설정을 통해 변경 가능

 

---

Replication

복제를 하면 zookeeper가 알아서 broker에 분산저장 시켜줌

기본 RF(replication factor) = 3

replication은 topic마다 각각 설정할 수 있다. → 데이터의 중요도에 따라 중요한 topic은 replication↑, 상대적으로 덜 중요한 topic은 replication↓으로 설정하는 방식을 통해 안정성 설정 가능

 

leader와 follower

위 그림에서 topic1은 replication을 2, topic2는 3으로 설정한 모습이다.

카프카에서는 leader와 follower를 설정하는데, producer, consumer와의 모든 통신은 leader에서 이루어지고 follower는 leader의 정보를 복사한다.

leader가 죽으면 follower 중 하나가 leader로 선출되며 이는 zookeeper에 의해 이루어진다.

producer config 정보에서 ack 옵션

       producer가 메시지를 보낼 때 옵션을 선택해서 보낼 수 있는데, ack도 그 중 하나.

1. ack=0
   producer가 메시지를 보내고 kafka로부터 별다른 ack를 받지 않음
   메시지유실가능성 上, 속도 上
2. ack=1 (default)
   producer가 msg를 leader에게 보내고
   ack를 producer에게 보냄
   → follwer에게 복제가 되기 전에 leader에 실패가 발생하면 메시지 유실 가능성이 있음
   메시지유실가능성 中, 속도 中
3. ack=all(-1)
   producer가 msg를 leader에게 보내고
   follower가 복사를 다 했는지까지 기다림 (모든 ISR 확인)
   → leader에 어느 순간 실패가 발생해도 follower에 복제된 데이터가 확실하게 있으므로 msg 유실이 없음
   메시지유실가능성 下, 속도 下

---

Exactly-once-Delivery(kafka streams api)

       정확히 한 번의 메시지 전송 보장. 중복된 메시지와 유실된 메시지 모두 비허용

 

enable.idempotence=true로 설정

→ 멱등성(=동일 연산을 여러번 수행해도 결과변화가 없음)

1. producer msg 전송 멱등성 보장
   동일한 msg 정보를 여러번 보내면 이 정보는 broker의 kafka log에만 기록됨
   → 중복된 메시지가 발생할 가능성 차단
   TCP가 패킷에 seq 포함해서 흐름을 제어하는 것 처럼 각 msg에 seq를 둬서 중복 msg를 처리한다.
2. 트랜잭션
   atomic write 보장: 트랜잭션 api
   kafka streams api