Apache Kafka 찍먹을 위한 초간단 정리

카프카란?

• 한마디로 말하자면 메시징 시스템이다.
• MSA 환경의 서로 다른 서비스에서 메시지를 발행하고, 구독하여 처리하는 형태로 이용하는 것이 대표적이다.

 

초간단 용어 정리

• 프로듀서
  • 메시지를 발행한다.
• 컨슈머
  • 메시지를 받아 처리한다.

• 토픽 / 파티션
  • 파티션은 간단히 말하자면 메시지를 담은 메시지 큐이다
  • 토픽은 여러 개의 파티션을 담는 단위이다.

 

 

 

 

 

 

 

 

 

 

 

토픽 / 파티션

• 하나의 파티션에는 물리적인 file 매핑된다.
• 해당 file에 데이터가 쌓이는 형식이고, 삭제 없이 추가만 되는 형식이기 때문에 디스크임에도 불구하고 매우 빠르다.
• 파티션은 삭제 없이 추가만 가능하다.

 

Producer

• 메시지를 생성하여 카프카로 전송한다.
• 특정 파티션에 발행되도록 key를 통해 지정하여 전송할 수 있다.
• 만약 지정하지 않는다면 round-robin 방식을 통해 할당된다.
• 이렇듯 어떤 파티션에 저장될지를 결정하는 것은 카프카 내부의 파티셔너 이다.

 

Consumer

• 특정 파티션을 구독하여 이를 통해 특정 작업을 수행한다.
• 가장 오래된 데이터부터 순서대로 읽는다. 따라서 같은 파티션에 발행되었다면 읽기 순서가 보장된다.
• 컨슈머가 메시지를 읽더라도 메시지는 삭제되지 않는다.
  • 그렇다면 메시지는 언제 삭제될까? 파티션의 메시지가 삭제되는 시간, 크기 등을 따로 설정하여 삭제할 수 있다.
• 같은 파티션은 여러 컨슈머에 의해 구독될 수 있다. 즉, 같은 메시지에 대해 여러 컨슈머에서 처리할 수 있다.
  • ex) 상품 주문완료 메시지 발행
    • 컨슈머 1) 주문완료 알림톡 발송
    • 컨슈머 2) 로그 적재
    • 컨슈머 3) 배송 관련 데이터 생성
• 만약 컨슈머의 수가 파티션 수보다 적다면 남은 컨슈머는 아무 작업도 하지 않는다.

 

Consumer Lag

• 프로듀서가 넣은 데이터의 offset과 컨슈머가 가져간 메시지의 offset 간의 차이이다.
• Lag이 클수록 컨슈머가 처리하는 속도보다 데이터를 쌓는 속도가 빠르다는 의미이다.
• 해결방법
  • 컨슈머, 파티션 개수 늘리기
    • 파티션 개수는 다시 줄일 수 없음에 유의해야 한다.
  • 컨슈머 늘리기
    • 새로운 서버를 증설하는 것이므로 비용이 발생한다.

 

Consumer Group

• 특정 토픽을 구독하는 그룹
• 각 컨슈머그룹은 offset을 통해 각자의 읽기 순서가 보장된다.
  • offset을 단순히 말하자면 해당 컨슈머 그룹이 마지막으로 읽은 데이터 번호이다.
  • offest+1번을 읽으면 다음 것을 읽을 수 있게 되는 것!
  • 동일한 컨슈머 그룹명을 유지한다면 컨슈머그룹이 죽었다가 다시 떠도 컨슈머그룹명-offset이 카프카에 저장되어 있기 때문에 다시 작업을 시작할 수 있다.
• 해당 그룹 안에서 특정 컨슈머가 특정 토픽을 담당하도록 구현할 수 있다. 이를 파티션 소유권이라 한다.

 

Broker / Cluster

• 하나의 카프카 서버를 브로커라고 한다.
• 카프카는 대부분 여러 대의 브로커로 운영한다. → 이를 클러스터라고 한다.
• 클러스터 내부에 여러 대의 브로커가 존재하는 것!
• 그중 하나는 클러스터의 컨트롤러 기능을 수행한다.
  • 클러스터 내의 각 브로커에게 담당 파티션을 할당
  • 브로커들이 정상적으로 동작하는지 모니터링

 

Rebalancing

• 파티션, 컨슈머의 수가 변경되어 새롭게 매핑하는 것을 말한다.
• 이는 배포할 때마다 일어난다. 컨슈머가 죽었다가 다시 살아나는 것이기 때문!
• 2.3 이전버전에서는 리밸런싱 하는 동안 컨슈머는 멈춘다. ( stop the world )
  • 카프카가 리밸런싱 하느라 메시지를 줄 수 없기 때문.
  • 2.3 이후 버전에서는 해결되었으니 더는 걱정할 필요가 없다!
    • 카프카 전체가 리밸런싱 하느라 멈추는 것이 아니라, 영향이 없는 작업들은 그대로 두고 영향이 있는 곳만 멈춘다.

 

Replication

• 다른 broker에 메시지를 복제해 두는 것
• 메시지 발행은 단 하나의 Leader 브로커에만 한다! follower들은 복제만 한다.
• 특정 broker(Leader)가 죽어도 복제본을 가지고 있는 broker(Follower)에서 작업을 이어나갈 수 있도록 위함이다.
  • 죽는 순간 follower 중 하나가 leader가 된다
• 메시지 발행이 어디까지 되는지를 보장하냐에 따라 ack 0,1, all로 나뉜다.
  • 0 : 발생요청 보내고 끝
  • 1 : Leader가 받았음을 확인하고 끝
  • all : Follower 복제까지 다 이뤄져야 끝
• replication 개수는 broker의 개수보다 많아질 수 없다.
  • 다른 broker에 저장하는 거니까 broker가 없다면 당연히 replication도 못한다.

 

중복 메시지

• 데이터를 읽었지만 처리 못했거나, 처리했음을 반환하지 못하여 메시지가 중복으로 처리되는 현상을 말한다.
• 배포 시 처리 도중 중단되거나 이를 반환하지 못해 자주 발생한다.
• 해결방법
  • 배포 중단 직전, 새로운 메시지를 받지 않고 기존에 처리하고 있던 로직이 실행되는 동안 잠시 기다린다.
  • 중복 메시지를 방지하는 로직을 추가적으로 작성한다.