[Kafka] 카프카 개념, Topic, Broker, Partition, Lag, Burrow 등 기초편

** 본 글은 dev원영 님의 카프카 기초 강의를 기반으로 작성되었습니다.

Kafka

• Application 혹은 서비스와 연결 된 데이터 소스가 많아 짐에 따라 데이터 파이프라인의 관리가 힘듬
• 데이터 소스와 실제 애플리케이션의 Coupling 을 약하게 만들려는 의도
• Fault Tolerance / High Throughput / Low Latency
• Queue 의 한 종류라고 알면 됨

---

Topic?

• 데이터가 들어가는 공간
• AMQP 와는 다르게 동작

1. Partition이 하나 인 경우

• Kafka 는 하나의 큐처럼 작동함 (FIFO)
• 하나의 컨슈머가 record 를 가져가도 삭제 되지 않음.
• consumer 그룹이 다를 경우 이전 데이터를 다른 어플리케이션이 가져 갈 수 있음
  • 조건
    • 컨슈머 그룹이 다를 것
    • auto.offset.reset = earliest 로 설정 되어 있을 것
  • 동일 데이터에 대해서 두번 처리 가능

2. Partition 이 두 개 인 경우

• key 가 null 일 경우 Round Robin 으로 데이터가 축적 됨
• key 를 지정할 경우 지정 된 키의 해쉬값에 해당하는 파티션으로 데이터 축적
• 파티션은 늘리는건 가능하지만 줄일 수는 없음
• 파티션을 늘리면 컨슈머를 늘려서 데이터 분산 처리가 가능함.
• Record 최대 보존 시간과 최대 보존 크기 (byte) 설정 가능
  • log.retention.ms 최대 record 보존 시간
  • log.retention.byte 최대 Record 보존 크기

---

Kafka Broker

• kafka 가 설치 되어 있는 서버 단위. 즉 노드 단위

Replication & ack

Replication (복제본)

• Broker 의 크기보다 클 수 없음.
• Leader partition 하나, 나머지는 Follower partition
• 오직 Leader Partition 만 프로듀서와 상호작용함.1.
  • ISR 에 속해 있는 구성원 만이 리더의 자격을 가질 수 있음.
  • Replica 그룹으로 관리하며 ISR 그룹 안에 구성원이 리더가 자신의 역할을 못하는 경우 (죽는 다던지..) 팔로워가 리더로 선정됨.

  2. #1. 
     ISR에 속해 있는 구성원만이 리더의 자격을 가질 수 
     
     Replica 그룹으로 관리하며 ISR 그룹안에 구성원이 리더가 자신의 역할을 하지 못하게 되는 경우(예기치 못하게 죽는다던지..) 팔로워가 리더로 선정되며 그 역할을 대신한다.
     

• 이 구성을 ISR(In-Sync-Replication) 이라고 함

그럼 Replication 이 많을 수록 좋을까?

• ㄴㄴ. 카프카 브로커의 리소스 사용량 증가
• 보통 브로커가 3개 이상일때 Replication=3 을 Max 로 사용함

ack

• ack = 0
  • Only Request
  • 제대로 전송 됐는지, 복제 되었는지 확인 불가
  • 속도 빠름
• ack = 1
  • Request & Response (to/from leader partition)
  • 제대로 전송 됐는지만 확인
• ack = 2
  • Request & Response (to/from all partition)
  • 제대로 전송 / 제대로 복제를 확인함.
  • 느림

---

파티셔너 (Partitioner)

• 파티셔너는 기본적으로 hash table 이며, key 에 대한 해시 값을 기준으로 파티션을 결정하기 때문에 항상성을 보장함.
• 순서를 지켜서 데이터 처리 가능!

기존 Default Partitioner (Default - No Key)

• Producer는 RoundRobin 방식으로 파티션에 메세지를 분배함.
• 메시지가 쌓이는 속도가 많지 않을 경우 Record Batch 를 꽉 채우지 못하고 레코드 적재
• 상당히 비효율적일 수 있음.

UniformStickyPartitioner (Default - No Key)

• 배치를 꽉 채운 다음에 파티션에 데이터를 적재하자는 것.

Custom Partitioner

• 이 방식을 커스터마이징 하여 특정 Partition에 특정 데이터를 넣어줄 수 있음.
  • ProducerRecord 의 Topic, Key, Value 에 따라..

• 이거 어디다가 씀?
  • 예를 들어, VIP 고객의 Throughput 을 올려주고 싶고, 파티션이 10개라고 하자
  • Topic 이 "VIP" 라면, 파티션 8개에 레코드를 고루 할당하고, "General" 일 경우 2개에만 할당하면, VIP 에 대한 처리량을 늘려줄 수 있음.
  • 즉 비즈니스 로직으로 적용 가능

---

Lag

• 그림과 같이 컨슈머가 읽은 offset 과 프로듀서가 넣은 offset 의 차이 값이다.
• lag 은 파티션이 여러개일 때 여러개가 존재 할 수 있다.

Consumer lag 이 너무 커질 때

• 카프카 토픽에 저장된 데이터가 너무 많아지면 lag 의 값은 점점 커진다.
  • 처리해야 할 양 증가
  • 토픽 저장소의 한계를 넘어섬

1. 해결책: 파티션의 개수를 늘림

• 컨슈머 그룹의 병렬 처리 속도는 Consume 하는 파티션의 수에 의해 제한됨.
• 따라서 파티션이 많아지면 당연히 Throughput 은 높아짐.

2. (참고) 파티션 개수를 늘릴 때 문제점

https://knight76.tistory.com/entry/kafka-lag-생긴다고-파티션-추가하는-것에-대해

1. 오픈 파일 핸들이 더 필요함
2. 가용성이 떨어질 수 있음.
3. E2E 대기 시간의 증가
4. Producer / Consumer 클라이언트에서 소비하는 메모리 증가

---

Burrow

https://blog.voidmainvoid.net/243

1. 기존 lag 모니터링의 어려움..

• 기존 Kafka client의 consumer의 metrics() method를 사용하여 lag metric(records-lag-max)을 기록할수 있지만, 이는 가장 뒤처진 파티션의 현재 지연을 보여주므로 다른 파티션에서의 정상작동을 잘 감지하기가 어렵다.
• 또한, consumer자체가 정상작동함을 가정해야한다.(컨슈머가 멈추면 lag감지 불가) → Consumer Dependency!!
• Consumer Lag 수집 모듈을 따로 개발해야 함

• 실제로는 모두 정상 작동하고 있으나, .. lag-threshold-value = 250 일 때, B와 D는 이상이 있다고 감지 한다.