[document] 카프카 2.7.x

[heowc]

https://godekdls.github.io/Apache%20Kafka/contents/

http://www.yes24.com/Product/Goods/104410708

[heowc]

인체에서 중추 신경계 해당

• 끊임없이 서로를 연결해주는?

폭 넓은 사례

• 지불 처리 등으로 카프카를 쓰진 않는 듯

단일 솔루션으로 핵심 3가지 기능으로 통해 원하는 end-to-end 이벤트 스트리밍을 구현 가능

• 구독, 발행
• 저장
• 처리 (1,N)

어떻게?

• 고성능 TCP 네트워크 프로토콜
• 서버와 클라이언트로 구성
• 서버
  • 브로커: 스토리지 레이어
  • 카프카 커넥트: 이벤트 스트림
  • 다른 카프카, rdb 등의 기존 시스템과 통합 가능
  • 장점
  • 확장성이 뛰어남
  • 내결함성에 안전한 방식
  • 어느 환경에서나 사용할 수 있다.
  • 디스크에 저장하기 때문에 컨테이터에 하더라도 PV 를 갖추고 있어야 하지 않을까? 🤔

    장애가 나면 다른 서버에서 이어 받아, 데이터 유실없이 지속적인 운영을 보장 그렇다면 장애가 났을 때, 유살될 여지는?

• 클라이언트
  • 네트워크 문제나 장비 장애가 발생해도 내결함성을 유지 가능

    어떻게? 🤔

  • 수십 개의 클라이언트와 REST API, 고수준 카프카 스트림즈 라이브러리 제공

개념과 용어

이벤트

• 이벤트 = 레코드 = 메시지
  • 키, 값, 타임스탬프, 메터데이터(Optional)
  • 키로 인해 순서 보장 가능

    유저 고유 id를 키로 가져가 순서를 보장해볼 수 있을 듯 대신 동일 파티션으로 들어가기 때문에 복제가 필수가 되어야 장애 대응이 가능할 듯? 관련 블로그: https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-%EC%B2%98%EC%9D%8C-%EC%A0%91%ED%95%98%EB%8A%94-kafka/

프로듀서: 이벤트를 발행하는 클라이언트 애플리케이션 컨슈머: 이벤트를 읽고 처리하는 클라이언트 애플리케이션

• 서로 독립적이며 높은 확작성을 달성해준 핵심 설계 요소
• 여러 가지 옵션이 있음 (at least once, at most once, exactly once)

토픽: 이벤트 저장 단위(?)

• 폴더 : 파일 = 토픽 : 이벤트
• n 프로듀서/컨슈머 접근 가능
• 토픽의 이벤트는 필요한 만큼 재차 읽어갈 수 있다
  • 다른 메사장 시스템과 달리 컨슘한 후 삭제하지 않음
  • 토픽별 이벤트 보존 기간 정의 후 오래된 이벤트 폐기

    그래도 너무 큰 메시지를 보내거나 한다면? 하드 디스크가 작다면? 문제가 될 듯? 관련 모니터링은 필수로 보여지며, 설계를 잘 해야할 듯 카프카 <-> 웹소켓 같이 알림 역할의 이벤트라면 굉장히 짧아도 무관할 듯 https://godekdls.github.io/Apache%20Kafka/topic-configuration/#retentionms

파티셔닝: 토픽 분할(?)

• 토픽은 서로 다른 카프카 브로커에 있는 여러 버킷으로 분산된다.

  버킷이란? https://www.confluent.io/blog/prioritize-messages-in-kafka/#defining-buckets https://github.com/riferrei/bucket-priority-pattern https://kafka.apache.org/documentation/#topicconfigs

API 분류

• 어드민
• 프로듀서
• 컨슈머
• 카프카 스트림즈
• 카프카 커넥터

유즈 케이스

• 메시지 시스템
• 활동 트래킹
• 메트릭
• 로그 집계
• 스트리밍 프로세싱

https://hub.docker.com/r/bitnami/kafka

[heowc]

디자인

동기

실시간 데이터 피드를 처리할 수 있는 통합 플랫폼이 되도록 설계

• 실시간 로그 집계

• 대용량 데이터 백로그 -> 짧은 지연 시간으로 데이터 전달

• 파티셔닝도 해야하고 분산 처리도 해야함 😢 -> 파티셔닝 / 컨슈머 탄생

• 스트림 전송 하되 내결함성을 보장 해야함 😢 -> ????

저장

• 메시지를 저장/캐시 -> 파일 시스템에 의존
• 파일 시스템을 어떻게 사용하느냐에 따라 성능이 좌우됨 -> 디스크 구조를 잘만 설계하면 네트워크만큼 빠르게 동작

  잘이 어렵지... 😢

• 하디 드라이브는 나날이 성장하고 있음
  • RAID: https://ko.wikipedia.org/wiki/RAID
• 운영체제 또한 성장하고 있음
  • read-ahead (미리 읽기): https://en.wikipedia.org/wiki/Readahead
  • write-behind (write-back, 뒤에 쓰기): https://en.wikipedia.org/wiki/Cache_(computing)#WRITE-BEHIND
• JVM 힙, OS 통합 캐시, 페이지 캐시 등등 여러 캐시에 저장됨
• 그래서 파일 시스템을 사용/페이지 캐시에만 의존
  • GC에서 나름 자유로워짐
  • warm-up이 필요없음
  • 간단해진 코드

저장

• 보통 메시지 시스템은 컨슈머당 대기열을 persistent 데이터 구조로 사용
• 관련해서는 b-tree 같은 랜덤 엑세스 데이터 구조로 메시지에 대한 메타데이터를 유지
• 하지만 b-tree는 비용이 상당히 크다 - O(log N)
  • https://hamait.tistory.com/403
  • 디스크 연산에선 여러 제한때문에 트리구조는 비효율적이다.
• 그래서 로깅 솔루션처럼 간단한 읽기 연산과 파일 append 연산을 기반으로 구성
  • 모든 연산이 O(1), 읽기와 쓰기가 서로 블로킹하지 않음
  • HDD를 써도 좋은 성능을 보여줌
  • https://team-platform.tistory.com/6

    데이터 크기와 왜 전혀 상관이 없을까? 🤔 Record ID, https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=k97b1114&logNo=140152019847

효율성

• 카프카는 매우 빠르기 떄문에 인프라로 인해 병목이 되지 않는다.
• 비효율성의 원인
  1. 작은 I/O 연산이 많거나
     • 메세지를 그룹으로 추상화 = 메세지 셋
     • 네트워크 왕복의 오브헤드를 분할

       producer/consumer 모두 batch-size를 조절할 수 있음

  2. 바이트 복사가 과도하게 이루어 지거나
     • 프로듀서, 브로커, 컨슈머 모두 표준화된 바이너리 메세지 포맷을 사용
     • 브로커가 관리하는 것은 쉽게 얘기하면 파일의 디렉토리일 뿐
     • 공통 포멧이기 때문에 -> 네트워크로 전송하는 핵심 연산을 최적화 할 수 있다.
     • 최신 유닉스 OS에서는 페이지 캐시에서 소켓 데이터 전송을 고도로 최적화함
     • sendfile - https://man7.org/linux/man-pages/man2/sendfile.2.html
     • 네티는 어떻게 하고 있을까?
     • 네이티브는 역시 sendfile을 사용하고 있음 👍
     • https://github.com/netty/netty/blob/6cd9020fda4b6f9056688e5ddba9e4126fac5303/transport-native-kqueue/src/main/c/netty_kqueue_bsdsocket.c
     • https://github.com/netty/netty/blob/6b3ec62e6e4e19a85304aecd8cb5331a3fcc70be/transport-native-epoll/src/main/c/netty_epoll_linuxsocket.c
     • 반복해서 복사할 필요 없음
     • 한번만 페이지 캐시에 데이터를 복사하여 재사용 가능
     • page cache + sendfile 조합으로 대부분이 완전히 캐시로만 데이터를 서빙하고 디스크 읽기를 전혀 볼 수 없음 👍

배치 압축

• 네트워크 대역폭 병목
• 하나씩 압축하면 압축률이 떨어짐
• 그래서 카프카는 배치 처리 포맷으로 압축 지원
• producer -> (압축) -> broker -> (해제) -> consumer
• gzip, snappy, lz4, zstandard etc...

[heowc]

리더가 프로듀서에게 메시지를 받았다면, 이를 팔로워에게 알리는가? 아니면 팔로워는 리더의 오프셋이 증가했는지 어떻게 인지하는가? -> 팔로워가 자기 오프셋보다 높은 값을 리더에게 일단 찔러봄

리더에게 리더에포크를 요청을 보낼 수 없을 정도의 장애 상황이라면? -> TBD

[heowc]

https://web.archive.org/web/20120619234320/http://sna-projects.com/blog/2009/08/introducing-the-nio-socketserver-implementation/

[heowc]

4장 내부 동작 원리

카프카 리플리케이션

• 브로커 장애에도 연속적으로 안정적인 서비스를 제공하기 위함
• 데이터 유실 방지
• replication factor

궁금점

1. 리더는 토픽단위 인가?
   • 파티션 단위...
2. 리더에게만 메시지를 주고받는다면 브로커를 늘렸을때 안정성 이외에 효과는 무엇이며 어떻게 생기는지?
   • 다시 생각해보면, 브로커를 늘린다고 파티션이 느는것은 아니다. 고로, 브로커가 많이지면 그만큼 파티션이 보다 분산될 것이고 이로인해 사이드 이펙트가 덜(?) 해질 것으로 예상
3. 키를 넣으면 순서보장을 위해 특정 파티션에만 들어가는데 이 관계랑 어떻게 연계되는지?
   • TBD. 파티셔너? 5장에서 확인 ✅
4. 컨트롤러 브로커가 장애로인해 종료되거나 자연스럽게 종료된다면?
   • 리더와 비슷하게(?) 방식으로 확인 및 재선출
   • https://www.gojek.io/blog/when-kafka-went-offshore

[heowc]

5장. 프로듀서의 내부 동작 원리와 구현

파티셔너

• 브로커에 전달하기 전 미리 파티션를 정하고 나누는 역할
• 라운드 로빈
• 스티키 파티셔닝
  • 메시지 순서가 중요하지 않다면 효과적👍
  • 지연시간 30퍼 감소
  • cpu 사용률 감소
  • https://cwiki.apache.org/confluence/display/KAFKA/KIP-480%3A+Sticky+Partitioner

카프카 배치

• 목적에 따라 배치/미배치
  • batch.size, linger.ms 조절

중복없는 전송

• PID(프로듀서 ID), 메시지번호
• 기존 대비 최대 20퍼 성능 감소

정확히 한번 전송

• 트랜잭션과 같은 전체적인 프로세스
• 중복없는 전송은 해당 기능의 일부 기능

궁금증

1. 라운드로빈 전략으로 인해 프로듀서에 너무 만은 레코드가 쌓이게 되진 않을까? 그래서 시간 값은 필수여야 하는가?
2. 프로듀서에 쌓이는 메시지는 메모리에 쌓이는데 이를 변경할 수 있는가?
3. flush(), beginTransaction() 이 하는 일? 예제 코드만 보자면 메시지에 대해서 트랜잭선 처리를 하는지 알기 어려움.. 코드확인 필요 (파티셔너의 영향으로 롤백 가능성은?)
4. TBD

[heowc]

스태틱 멤버십

• 배포시에 유용

리밸런싱은 컨슈머 그룹 전체를 대상이기 때문에 부담이 많은 작업 중 하나이다

레인지 파티샨 할당 전략

• 서로 다른 토픽의 동일 키를 할당하면 좋은 점??

컨슈머 그룹에 컨슈머가 하나면 리밸런싱이 일어날까..?

The default partition.assignment.strategy is changed to "[RangeAssignor, CooperativeStickyAssignor]", which will use the RangeAssignor by default, but allows upgrading to the CooperativeStickyAssignor with just a single rolling bounce that removes the RangeAssignor from the list. Please check the client upgrade path guide here for more detail.

[heowc]

8장 카프카 버전 업그레이드와 확장

업그레이드

다양한 이유로 주기적인 버전 업그레이드는 필수이다.

• 성능 향상
• 추가 기능
• 보안 취약점

릴리즈 노트 확인

• https://blogs.apache.org/kafka/
• https://archive.apache.org/dist/kafka/

버저닝

• 카프카는 현재 시맨팅 버저닝을 사용 중
• {MAJOR}.{MINOR}.{PATCH}
• 버전에 따른 차이점을 잘 파악하고 버전 업그레이드를 진행하자

버전 업그레이드

• 버전에 따라 대응하는 방법: https://kafka.apache.org/documentation/#upgrade
• 2.1 -> 2.6
  1. 2.6 설치
  2. 실행 전 다음 옵션 적용
     • inter.broker.protocol.version=2.1
     • log.message.protocol.version=2.1
  3. 롤링 업그레이드
     • 파티션의 리더 변경 등으로 일시적으로 리더를 못찾거나 타임아웃 발생
  4. 옵션 제거 (기본설정 적용)
  5. 롤링 업그레이드

설정이나 환경 문제로 예상치 못한 문제가 생길 수 있으니 개발 서버와 운영서버을 동일한 환경으로 맞추고 사전 테스트를 해볼 것

확장

• 규모 산정을 예측하기 어려움...
• 그리고 상황에 따라서 브로커를 추가하고 파티션을 다시 고르게 배치할 필요성이 있음

파티션 재배치

• kafka-reassign-partitions.sh 도구 활용
  • 
  • ReassignPartitionsCommand.scala
• KafkaAdminClient#alterPartitionReassignments(...)

주의사항

• 카프카 사용량이 낮을 때 진행하는 것을 추천
  • why?) 브로커 리플리케이션
  • 리더, 팔로워, 워터마크, 리더에포크...
• 보관 주기를 작게 변경 후 재배치 추천
• 토픽 하나씩 재배치 추천

3.0 이후

• log.message.format.version 제거 예정
  • https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/config/TopicConfig.java#L176...L194
• inter.broker.protocol.version은 kraft 적용 중인 3.3 이상은 사용 안됨
  • https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaConfig.scala#L1812...L1833

[heowc]

protocol.version 처리 방식

• https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaServer.scala#L326
• https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/ApiVersionManager.scala
• https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/protocol/ApiKeys.java

[heowc]

보안

내부 시스템으로 사용되어 기본적으로 설정되어 있지 않음