카프카는 주키퍼에 dependent 함

주키퍼는 - 엄청 reliable한 스토리지. tree 형태의 자료구조. 각 subtree의 루트를 지노드라고 부름

• 여러 서비스가 같이 쓸 수 있음
• 책에서는 peter-kafka라고 지노드를 만들어서 그 아래에 메타데이터를 정리함

브로커 - 머신

토픽 - 이메일 주소

(ch3) 파티션

• 토픽에서 메시지가 나뉘는 기준.
• 예를 들면 1학년이 1학년 1반, 2반, 3반 이렇게 나눠짐
• 파티션 안에서는 ordering이 보장 (메시지의 순서를 오프셋이라고 부름)
• 파티션을 늘리면 처리량이 늘어나지만 오버헤드 역시 분명 존재함
• 늘리기는 쉬운데 줄이기는 어려움 → 작게 시작해서 천천히 늘리자

(ch4) 프로듀서

• 어떤 메시지를 어느 파티션에 보낼지는 프로듀서의 몫 (당연히 ordering gurantee를 생각해서 정해야 함. 기왕이면 같은 유저의 데이터는 같은 파티션에서 처리되면 굿)
• acks 옵션. 결국 보장과 성능의 tradeoff
  • acks=0: 확인 ㄴㄴ. 가장 빠름
  • acks=1: 리더한테 확인했다고 ack를 받아야 함
  • acks=-1(all): 리더+지정된 갯수의 레플리카까지 확인.
• acks=1이 무난무난함

(ch5) 컨슈머

• 컨슈머 그룹 : 같은 토픽을 토픽을 바라보는 컨슈머들
  • 컨슈머 하나는 파티션 여러 개를 바라볼 수 있음
  • 근데 파티션은 컨슈머 하나에만 보낼 수 있음
• 컨슈머 그룹마다 오프셋을 관리하기 때문에 나중에 다른 용도의 컨슈머 그룹을 추가할 수 있음
  • 파티션 별로 어디까지 읽었나 오프셋을 관리
• 오프셋을 관리하는 방법
  • 오토 커밋: 주기적으로 오프셋을 기록
    • 메시지를 놓치는 경우가 생김
  • 수동 커밋: 클라이언트가 오프셋 기록 시점을 관리.
    • eg) 컨슈머가 메시지를 가져와서 디비에 저장하는 경우 - transaction 이 성공하고 나서야 커밋을 하는 것이 좋음
    • 메시지를 중복으로 처리하는 경우가 생김 - 하지만 at least once는 보장이 됨.

(ch6) 운영팁

• 어떤 시스템을 운영하던지 기본적으로
  • 현재 상태 확인 (카프카의 경우 프로듀서, 컨슈머, 오프셋 등등)
  • 노드 삭제/추가
  • 버전, 설정 업데이트
  • 등을 할 줄 알아야 함. 이런 필수적인 시나리오에 대한 명령어가 나와있음
• JMX를 이용한 모니터링, Kafka manager를 이용한 GUI등이 나와있음

(ch7) 예제 파이프라인

• 카프카 로그를 파일비트를 거쳐서 카프카에 쌓고, 이를 나이파이를 이용해서 조건에 따라다른 카프카 토픽이나 ElasticSearch로 라우팅하는 방법

(ch8, ch9) 카프카 스트림과 카프카 SQL

• 스파크 쿼리를 직접 짜냐 SQL을 쓰냐 딱 그 차이.

(ch10)

• GCP PubSub, AWS Kinesis 등이 비싸지만 운영이 편함
• 최대 성능은 직접 운영하는 것만 못함
• 일단 클라우드로 시작하고 이용료 차이 > 인건비가 되면 직접 운영하는 카프카로 가는 것을 추천