Kafka

회사에 카프카, 데이터 플랫폼의 최강자 책의 저자인 고승범 님이 오셔서
Kafka에 대해 발표를 한적이 있는데 그 때 적었던 내용.
막 적다 보니까 뭘 쓴건 지도 모르겠다;;;
일단 기록 저장용으로 옮겨본다

Kafka란?

Kafka®는 실시간 데이터 파이프 라인 및 스트리밍 앱을 구축하는 데 사용됩니다. 수평 확장 성, 내결함성, 빠른 속도를 자랑하며 수천 개의 회사에서 생산됩니다.

• 메세지 브로커
• High Throughtput
• 실시간 로그 통합
• 무중단(장비의 장애)
• 이기종과의 호환성
• 간단한 스케일 아웃
• 프로듀서와 컨슈머 역할 분리

성능 테스트시

• kafka (초당 300만) vs rabbitMQ (초당 100만)
• kafka와 rabbitMQ의 가장 큰차이는 zookeeper가 있다는건가?
• kafka에서는 producer와 consumer간에 topic으로만 메세지 처리
• rabbitMQ는 ….. 복잡하데요

kafka의 성능

• message크기가 작을수록 성능이 좋다
• broker가 많을수록 성능이 좋다
• replica는 작을수록 성능이 좋다 - message가 중요하면 3으로 설정 * 손실되도 좋다라고 하면 1이나 2로 설정하는게 좋다
• partition은 클수록 성능이 좋다 : 파티션 수는 늘리면 줄일수가 없다.

kakao - 하루에 kafka가 얼마나 쓰이고있는지?

• (메세지처리량) 1800억건
• 205TB / day in
• 350 TB / day out
• 들어오는거보다 나가는양이많다?
• 단일토픽하나로 가장 처리량이 높았던건 초당 80만
• 2년 운영하면서 큰장애는 2건.

kakao kafka사용시 장애 이슈

• ISR (In-Synk Replicas) 축소
  • 현재 복제되고있는구성원
  • 리더만 읽고 쓰기
  • 팔로워들은 리더를 주기적으로 동기화
  • ISR의 구성원만이 리더의 자격을 갖는다
  • isr축소 버그가 있음 (0.10.1.0)
• Rack Power
  • broker는 idc랙별로 분산해서 놓는게 좋습니다.
  • 장애또는 이슈로 인한 리더가 변경되는경우…..
    • 여러개의 broker가 있는 경우 장애로 리더가 자주 변경되게 되면 broker간의 sync 가 안맞게 된다 이경우 sync가 맞지 않은 broker가 장애로 인해 리더가 된다면……
      기존 리더로 부터 메세지 복제가 이루어 져야 한다. 그런데 기존 리더가 올라오지 않는다면?????
      기다려야 할지 아니면 먼저 올라온 broker가 리더로서의 역할을 해야 할지..

Use Case (KaKao)

로그를 통합하고 싶어요
CS때문에 각 서버에서 Grep하고 있어요….

• MSA
  단점?? 카프카를 쓰면 다 해결된데요 ㅋㅋㅋㅋ
• RabbitMQ Log System
  kibana

Producer

손실없이 kafka로 보내는것

Producer ACKS

• ACKS 는 크게 3가지 타입으로 나누어져있음 ( 0, 1, ALL)
• 0 : Message를 매우 빠르게 전송할수 있지만 리더가 받았는지 알수 없음
• 1 : Message전송도 빠른 편이고 파티션의 리더가 받았는지 확인 (가장많이 사용)
• ALL : Message 전송은 느리지만 손실없는 전송 가능
• 1는 손실가능성이 있음….

ACK1은 안전한가?

리더가 메세지를 받고 저장후 producer에게 잘받았다고 전달을 하고
바로 리더가 down되는경우 (sync가 안맞는 경우)는… 손실이 일어날 수 있다.

파티션…?

특정 파티션만 메세지를 못가져오고있어요
특정 파티션의 사이즈가 이상해요
Producer가 message를 보낼때 key value방식으로 보내는데
key를 안보낼 수 있다…
전송 방식은 RB
key를 주게 되는경우 특정 파티션으로 전달이 되는데
key가 중복이 되는경우…. ?

컨슈머가 자꾸 죽는경우…

ack 설정값을 잘봐요… 메세지 손실때문에 그런건가?

Consumer

브로커의 리더 파티션에서 message 를 가져오는역활

파티션이 하나일때 :
파티션의 오프셋 순서대로 가져 옵니다

파티션이 0개 이상일때 : 파티션별로 오프셋 순서대로 가져온다
한가지 보장할수 없는건 파티션 번호의 순서대로 가져오지 않는다.
파티션별루 오프셋 번호는 동일 (오프셋 0, 오프셋 1, 오프셋 2 …)

파티션이 늘어나면 성능이 좋은 장점은 있지만
message가 꼬일수 있다. (해결방법은 timestamp를 이용)

하나의 파티션에는 하나의 컨슈머만 가능?

컨슈머 그룹을 이용한 멀티 컨슈머

commit

컨슈머는 파티션의 몇번째 오프셋까지 가져왓는지 표시
이러한 행동을 commit 한다고 합
rebalancing이나 컨슈머 재시작시 commit된 위치부터 시작
auto commit / manual commit이 있다지만 auto commit을 사용
auto commit을 사용할 때 중복에 대한 예외처리를 해주면 좋다..

LAG

Burrow : lag 체크 할수 있는 툴

Operational Tips

파티션 수 늘려주세요 ??

파티션은 늘리면 줄일 수가 없어요…. 잘생각해서 늘려야함
lag이 밀린다면 partition을 늘려주는게 좋다. (파티션을 늘리면서 컨슈머를 늘려줘야함)

디스크 공간이 부족해요??

retention.hours 168 (7일) - global
카프카 메세지 기본 보관값이 7일이에요
카카오는 3일로 줄여놨다고 합니다.
그중에 메세지 사이즈가 큰거는 별도로 줄이고 있다고 합니다.
retention.ms = 86400000 (1일)
토픽마다 보관 주기를 할 수 있어요

scale out??

기존 카프카를 복사하고 브로커 아이디만 유니크하게 바꿔서 올리면 되요?
새로운 추가 작업은 쉽지만
기존 운영중에 사용량이 많은 브로커에 대해 대안을 위한 스케일 아웃시에는
조금 복잡하다고 합니다 먼소린지 모르겠음