[Chap 03] 카프카 기본 개념 설명 (3.1 ~ 3.4.1 Producer API)

[travelbeeee]

현석

• 카프카 브로커
  • 흔히 우리가 말하는 '카프카' 는 카프카 브로커를 의미
  • 보통 카프카 프로듀서, 컨슈머는 개별적인 애플리케이션으로 구성한다. 웹툰에서도 비슷한 형태로 컴포넌트 만들어져있는 것으로 보인다.
    
• 데이터 복제를 위해 최소 카프카 브로커 3대 권장
  • 카프카 브로커의 파티션 사이에서 데이터 복제 지연은 발생안하나??
    • 당연히 Latency 존재
      • 이를 줄이기 위한 여러 설정 들이 있음 ( Producer, Consumer 에서 각각 최적화 가능 )
    • 그럼... 복제 중에 리더 파티션이 죽으면... 데이터 손실이 될 수 있는건가??

[easyfordev]

이지

• 저는... 3장을 다 읽지 못했습니다... 오늘 스터디 끝나고 다 읽고 자겠습니다 ...
  • Producer 코드 짜서 돌려본 분들의 소감이 궁금합니다.
• To 현석님 >> min.insync.replicas 옵션과 acks옵션으로 보장할 수 있습니다.
• 지난번에 궁금했던거 해결해서 공유
• 저자분 블로그 : https://blog.voidmainvoid.net/243
• Kafka 각종 정보(브로커, 토픽, offset ...) UI로 확인하는 방법
  • UI 모니터링 툴 양대산맥
  • Yahoo Kafka Manager : https://github.com/yahoo/CMAK
    • PASTA의 Kafka -- 카프카 매니저도 이거 쓴다
  • Burrow(Linkedin)

[kihyun-yang]

기현

• ((저도, 복제 중 리더 파티션이 죽으면 데이터 손실이 있지 않을까하는 의문이 있었는데 ack와 min.sync.replicas 옵션을 통해 데이터 손실 이슈를 해결할 수 있는 것 같습니다.))
• 프로듀서 선택 옵션 > acks
  • 프로듀서가 전송한 데이터가 브로커들에 정상적으로 저장되었는지 전송 성공 여부 확인하는데 사용되는 옵션.
  • 0, 1, -1(all) 중 하나로 설정 가능
    • 0은 프로듀서가 전송한 즉시 브로커에 데이터 저장 여부와 관계없이 성공 판단
    • default는 1이고 1일 경우, 리더 파티션에 데이터가 저장되면 전송 성공 판단
    • -1은 min.sync.replicas 개수에 해당하는 리더 파티션과 팔로워 파티션에 데이터가 저장되면 성공하는 것으로 판단.

[KKambi]

한비

디스크 기반의 카프카가 빠른 이유?

원본링크
요약본링크

페이지 캐시(디스크 캐시)

• 최근 사용된 디스크 블록을 메모리에 캐시하는 것
• OS는 일반적으로 메인 메모리의 사용되지 않는 부분을 페이지 캐시로 사용
• 그래서 카프카 브로커가 실행되는 장비는 메모리의 크기가 중요하다. (최소 32GB 권장)
• 대신 JVM의 Heap Size는 그리 크지 않아도 된다. (6GB 이상으로 설정할 필요가 없다)

Page cache is transparent to application
어플리케이션에서 파일을 읽는 코드를 수행하지만, 실제로 OS가 이를 페이지 캐시에서 수행한다.
즉, 어플리케이션은 페이지 캐시의 존재를 알 수 없고, 캐시에 직접 접근하거나 이를 변경할 수 없다.
이렇게 존재를 알 수 없기 때문에 투명(transparent)하다고 한다.

Zero Copy Data Transfer

• 일반적인 어플리케이션은 데이터를 메모리에 올려서 작업을 수행한 후 전송
  
• 한 메모리 영역에서 다른 메모리 영역으로 복사하지 않거나, 불필요한 데이터 복사를 피할 수 있게 하는 OS 연산
  
• 대신 SSL을 활성화하면 메모리에 올려야한다고 함

Low-Latency I/O
일반적으로 Sequential I/O를 보장하여, 디스크를 읽는 속도를 증가

• 디스크의 읽기 속도는 파일이 저장된 블록의 위치를 찾는 시간에 크게 영향받음
• 카프카는 데이터를 세그먼트 단위로 분리하여 순차적으로 저장
• 다른 큐와 달리 데이터를 가져가도 토픽 데이터가 삭제되지 않음
• 특정 메세지만을 삭제할 수도 없음 (처음부터 특정 구간까지 삭제)
• 로그 파일 보관 주기 설정으로, 주기적으로 쌓인 순 삭제
• 결국 디스크의 파편화가 잘 발생하지 않아서, Sequential I/O를 보장하기 쉽다.
• 그래서 다른 프로그램의 영향을 받지 않도록 독립적인 파일 시스템에서 운영하길 권장

[meloncha]

민석

페이지 캐시

• OS의 페이지 캐시에 위임하고 OS가 알아서 서버의 유휴 메모리를 페이지 캐시로 사용하여 성능을 향상시킨다
• JVM GC로 인한 성능 저하를 피할 수 있다
• GC를 아예 안 쓰는 것은 아님. JVM에서 캐시를 구현하는 경우 GC가 자주 일어나기 때문에 페이지 캐시 사용

주키퍼 역할

• 코디네이터 역할
• 컨트롤러 선정
• 카프카 클러스터 안의 모든 브로커에 대한 상태 정보를 기록한다
• 관리 계층을 추가하는 문제점이 있어 추후 카프카에서 퇴출될 예정 ( 참고 : https://www.ciokorea.com/news/235594 )

[travelbeeee]

unclean.leader.election.enalbe 속성

• 리더 파티션에만 레코드가 있고 아직 팔로워 파티션에 레코드 복제가 안된 상태에서 리더가 죽었을 때
  • unclean.leader.election.enalbe = true : 유실을 감수함. 복제가 안된 팔로워 파티션을 리더로 승급
  • unclean.leader.election.enalbe = false : 유실을 감수하지 않음. 해당 브로커가 복구될 때까지 중단