Kafka

Kafka

- pub/sub 형태의 분산환경에 적절한 메세지 큐임

 

Kafka 를 사용하는 이유

- 분산환경에 적절하기 때문에!! (이유 : 아래 파티션에 서버가 싹싹 붙고 딱)

- 처리 속도가 빠름

kafka 파티션 갯수와 서버 대수의 인과관계

- 여러개의 Partition으로 이루어진 토픽을 Partition 별 로 각 서버가 담당해서 메시지를 처리 한다.

- ConsumerGroup 별 메세지는 1개만 처리함

 

----> 일반적으로 한 ConsumerGroup 그룹을 여러대의 서버가 컨슘하게 되고 (각 서버가 Consumer)

파티션을 각 서버가 나눠서 할당하여 컨슘하는 구조임

Rebalance

Consumer가 추가, 삭제 되면 처리하는 Partition을 재조정(Reassign)하는 작업 

Kafka1.X에서 Rebalance 작업이 일어나면 전체 Consumer가 메시지 Polling을 순간 중단한다.

 

ex) scale up, down 이 되면 컨슈머가 추가 삭제가 일어나는데 이때마다 Rebalance 가 일어나 Consume 이 일시 중단 됐다가 Rebalance 가 완료되면 다시 컨슘 시작

 

여기서 생기는 문제점

: 배포 때마다 Rebalance 가 일어나서 consume 이 안되어 처리가 지연됨, 하루에 여러번 배포하고 scale up, down 이 일어날경우 어떻게 처리할지?

 

-- 11번가에선 Consumer 를 아예 분리했다고 한다. 실제 결제 처리를 하는 도메인 서버에선 컨슘을 하지 않는 구조

 

Kafka Dead Letter

- 메시지를 어떠한 이유로 처리할 수 없는 경우엔 Dead Letter Queue(토픽)로 보낸다. 아래와 같은 이유로 메시지 처리가 실패할 수 있다.

Kafka Retry

- 실패 시에 Retry Topic 에 들어가게 되고 n 번 이상 실패를 할 경우 invalid topic 에 해당 데이터를 넣어 이상데이터를 감지 할 수 있다.

 

메세지 손실이 일어났을 때 (Kafka 메세지 유실 처리를 어떻게 할건지!)

• acks = 0 : 메세지를 받았는지 여부를 확인하지 않음. 빠름
• acks = 1 : 리더가 메세지 받았는지 확인함. 그래서 느림. 대신 손실 가능성이 적음 == 아예 없는건 아님!
  • 그럼에도 불구하고 메세지 손실이 일어나는 경우는 언제인가?

    

    카프카 데이터 플랫폼의 최강자 p.163

    1. 프로듀서가 acks = 1 옵션으로 peter-topic 의 leader 에게 메세지를 보냄
    • 2. peter-topic 을 리더는 메세지를 받은 후, 저장
    • 3. 리더가 받았다는 acks 을 보냄
    • 4. 리더가 죽음 (팔로워가 신규 메세지를 저장하기 전에)
• acks = all 리더 뿐만 아니라 팔로워까지 메세지를 받았는지 확인함. 가장 느리지만 안전성이 가장 높음!
  • 이 경우에서는 브로커의 설정을 건드려야하는데 min.insync.replicas = 1 인경우 리더만 받아도 min 을 충족하기 때문에 팔로워가 받지 않아도 받았다는 acks 을 보내기에 min.insync.replicas = 1 이면 acks = 1 이랑 같음
  • min.insync.replicas =2 (ack 을 보내기 전 최소 2개의 리플리케이션을 유지하는지 확인) 적어도 2로 설정해야지 의미가 있음. 
  • 리플리케이션 팩터가 죽을 수도 있기 때문에 리플리캐이션 팩터는 min 보다 많이 하는 것이 좋다.
  • 권장은 min = 2, factor = 3