회사에서 kafka를 사용하고 있는데 topic 1개로 데이터 주고 받는 단순 메시지 브로커 역할로만 사용하고 있어서 좀 더 자세하게 알아보고 사용하려고 기초 개념을 정리해봤다.

인프런 강의 데브원영 아파치 카프카 for beginners 들었음.
참고로 유투브에도 그냥 올라와있고 설명 자세하게 잘 해주신다!
내용은 짧은데 불필요한 문장이 없어서 끊어서 듣느라 시간 생각보다 많이 걸렸음.

기초

왜 사용하나?

처음에는 어플리케이션 하나에서 타겟(EX: DB) 하나로 간단한 구조였는데 아키텍처들이 복잡해지면서 어플리케이션과 타겟들이 많아지기 시작함.

소스 애플리케이션과 타겟 애플리케이션 사이의 중간 관리자 역할 > 타겟이 여러 개가 되는 경우 엄청난 장점으로 다가 올 수 있음.

토픽(Topic)

• 데이터베이스의 테이블, 파일시스템의 폴더와 유사한 성질
• 하나의 토픽은 여러개의 파티션으로 구성 될 수 있음

• 하나의 파티션에는 큐와 같이 끝에서부터 데이터가 쌓임
• Consumer는 데이터를 가장 오래된 순서대로 가져감. 이 때 컨슈머가 토픽 내부의 파티션에서 데이터를 가져가더라도 데이터는 삭제되지 않음.
  새로운 컨슈머(컨슈머 그룹이 다른 등 다른 조건 필요함)이 추가되는 경우에 데이터를 추가하기 위함.
• 파티션을 늘리는 경우 (0→1)

⭐ 파티션을 늘리는 것은 가능하지만 줄일 수 없기 때문에 신중하게 늘려야 한다.

파티션을 늘리면 컨슈머 개수를 늘려서 데이터를 분산 처리 할 수 있음.

• 데이터 삭제는 옵션에 따라서 다름. 레코드를 저장하는 최대 시간, 용량

브로커, 복제, ISR

• 브로커란 ?
  • 카프카가 설치되어 있는 서버 단위
  • 보통 3개 이상의 broker로 구성하는 것을 권장함
• 복제 (Replication)
  • 파티션의 고가용성을 위해서 사용됨 > 하나의 브로커에만 데이터를 저장해둔다면 하나의 브로커가 죽었을 때 복구 할 수 있는 방법이 없어지기 때문 = MongoDB 개념과 같음.
  • 개수가 많아지면 브로커의 리소스를 많이 사용하기 때문에 고가용성이 된다고는 볼 수 없음. 데이터 양에 따라서 구성 할 수 있는 것이 중요함.

브로커 개수에 따라서 복제 개수는 이하로 정해짐

원본 하나의 파티션은 Leader Partition / 나머지는 Follower Partition. Leader+Follower 합쳐서 ISR (In Sync Replica)라고 함.

• Leader Partition
  • Producer로 부터 데이터를 받는 주체
  • ack 옵션
    • 0: Producer가 데이터를 받았는지 응답을 확인 하지 않음. 빠르지만 데이터 유실 가능 성 있음.
    • 1: Leader partition이 데이터를 전달 받았는지 응답 값은 받지만, 나머지 파티션에 복제가 잘 됐는지는 체크하지 않음. 데이터 유실 가능 성 있음.
    • all: 1+Follower Partition에 대한 응답 값도 받음. 데이터 유실은 없다고 보면 됨. 속도가 현저히 느림.

파티셔너(Partitioner)

Producer의 레코드는 무조건 파티셔너를 통해서 브로커로 데이터가 전송됨.

데이터를 토픽에 어떤 파티션에 넣을지 결정하는 역할을 하게 됨. 메세지 키에 따라서 다른 파티션에 넣을 수 있음.

동일한 메세지 키를 가진 레코드는 항상 동일한 파티션에 들어 갈 수 있도록 보장함. = 순서를 보장 할 수 있다는 장점. (우리는 session.id를 이용해서 데이터를 넣을 수 있게 되는 걸까?)

메세지 키가 없는 레코드는 라운드 로빈을 기반으로 데이터를 보내게 됨.

기본 파티셔너 이외에 다른 커스텀 파티셔너를 이용해서 어느 파티션에 데이터를 보낼지 정할 수 있음. (EX: VIP 데이터는 좀 더 빠르게 처리 하고 싶은 경우에는 전체 10개의 파티션이 있을 때 vip는 8개를 쓰고 나머지 일반 고객은 2개 쓰게 하는 것..)

컨슈머 랙

• Lag이란? 파티션에 데이터가 들어가게 되면 데이터는 offset이라는 숫자가 매겨지게 됨. 컨슈머가 마지막으로 읽은 offset과 프로듀서가 마지막으로 넣은 offset의 차이
  

프로듀서와 컨슈머의 상태에 대해서 유추 가능하며, 컨슈머 상태를 모니터링 할 때 사용함. 

Lag은 여러 개가 존재 할 수 있음. 

컨슈머 상태에서 Lag을 수집하는 것은 컨슈머에 의존 상태가 생기기 때문에 위험 할 수 있음. 

• 카프카 버로우 (Burrow)

  • Kafka Lag을 모니터링 할 수 있기 위해 링크드인에서 배포 한 독립적인 오픈소스

  • 멀티 카프카 클러스터를 연동해서 확인 할 수 있도록 함.

    참고 : https://blog.voidmainvoid.net/244

Kafka vs RabbitMQ vs Redis Queue

메시징 플랫폼

1. 메시지 브로커
2. 이벤트 브로커

메시지 브로커는 이벤트 브로커로 역할을 할 수 없음

이벤트 브로커는 메시지 브로커의 역할을 할 수 있음

메시지 브로커 > 대규모 메시지 기반 미들웨어 아키텍처에서 사용되어 왔음

• 특징: 메시지를 받아서 처리 하고 나면 즉시/짧은 시간 내에 삭제되는 구조
• 미들웨어: 서비스하는 어플리케이션들을 보다 효율적으로 아키텍처들을 연결하는 요소 소프트웨어 (ex: 메시징 플랫폼, 인증 플랫폼, 데이터베이스 … )
• 데이터를 보내고, 처리하고, 삭제한다.
• Redis Queue, RabbitMQ..

이벤트 브로커 > 이벤트(메세지)라고 이야기하는 레코드를 딱 하나만 보관하고 인덱스를 통해 개별 엑세스를 관리함/ 업무상 필요한 시간 동안 이벤트 보관 가능.

• 데이터를 삭제하지 않음. 서비스에서 나오는 딱 한 번 이벤트를 DB에 저장하듯이 사용 할 수 있음. 장애 발생 시 장애 발생한 시점부터 재처리 할 수 있음. 많은 양의 실시간 데이터를 확인 할 수 있음.
• Kafka, AWS 키네시스

프로듀서

• Kafka Topic에 전송 할 메세지(데이터)를 생산하는 역할
• 특정 Topic으로 데이터를 publish하고 처리 실패 여부를 알고 재시도 가능
• Kafka Client와 Broker의 버전이 잘 맞아서 하위 호환성이 맞도록 해야 함.

컨슈머

• Topic의 파티션으로부터 데이터를 Polling해서 데이터베이스나 또 다른 어플리케이션으로 이동 시킴
• Partion offset 위치 기록
• 컨슈머 그룹을 통해 병렬처리 가능, 파티션 개수에 따라 컨슈머 개수를 만들면 병렬 처리하여 더 빠르게 처리 가능 함
• 컨슈머는 파티션 개수보다 작은 것들로 저장
• 자바에서 가져와서 Elasticsearch로 넣기도 한다고 함…. 신기하넹…..

카프카 스트림즈

이 부분은 장점일 잘 와닿지 않았음.

• 카프카 라이브러리로 배포 됨.
• 카프카와 완벽 호환된다.
• 유실, 중복 처리되지 않고 딱 한 번만 처리 될 수 있음. = 안전하고 빠르게 처리 가능.
• 스케쥴링 도구가 필요 없음.

카프카 커넥트

• 카프카에서 공식적으로 제공하는 컴포넌트 중 하나 = 중요한 플랫폼, 데이터 파이프라인 플랫폼

• 반복적인 작업에 효과적임

• 카프카 커넥트 (Kafka Connect)

  • 커넥터를 동작하도록 실행해주는 프로세스, 파이프라인으로 동작하는 커넥터를 실행히시키기 위해서는 커넥트를 실행시켜야 함.

• 커넥터 (Kafka Connector)

  • 템플릿과 같은 특정 동작을 하게 하는 코드 뭉치 (jar 패키지)
  • 파이프라인에 필요한 동작들과 설정, 실행 메서드를이 포함되어 있음.
  • 커넥터 종류는 2가지
  1. 특정 저장소에 저장하는 역할 (Consumer) - 싱크 커넥터 > 내가 필요한 부분은 이 부분.
  2. 특정 저장소에서 데이터를 가져와서 사용하는 역할