아파치 카프카 정리

2020-04-05

Why ?

  • 성능 관점이라기 보다는 다양한 분산 시스템에서 데이터 제어에 적합해 보여서 공부 시작.
  • http 보다는 메시지 기반 통합
  • 순차처리, 펍섭, 큐잉 등 다양한 기능이 있는것으로 보임
  • Kafka as a Storage System 의 관점에서

왜 카프카를 알아야 하는가?

  • 링크드인이 rabbitmq, redis 등을 이용하여 분산환경 데이터 흐름을 제어하는데 유지보수에 어려움을 느껴 카프카를 만들었다고 함. 데이터를 중앙관리하기 위함

  • 카프카 왜 잘되나?

      1. 성능 좋음(분산/병렬처리, 실시간성)
      1. 확장성 뛰어남( 브로커 수평확장 가능, fault tolerant )
      1. undeleted log ( 컨슈머가 데이터 처리하더라도 큐에서 제거되지 않음 )
  • 꼭 데이터 많은 데이터를 처리하기 위한것은 아니다. 데이터 양이 적어도 카프카를 사용해도 좋다.
  • 카프가 생태계 계속 성장 중이다

사례와 대표적 기능

메시지 큐, 로그 수집, ETL(Extract / Trnasform / Load ) 등의 대체제

  • 데이터 허브 : 여러 시스템 사이에서 데이터를 상호 교환
  • 로그 수집 : 여러 서버에서 생성된 로그를 수집하고 축적할 곳에 연결
  • 웹 활동 분석 : 실시간 대시보드와 이상 탐지/부정 검출 등 활동을 파악
  • 사물인터넷: 센서등 다양한 디바이스 데이터 수신 후 송신
  • 이벤트 소싱: CQRS 방식으로 대량의 이벤트를 유연하게 처리

기술 정리 내용

Topic

  • 파일시스템의 폴더와 유사 이름을 가질 수 있다.
  • 목적별로 토픽을 나누면 됨.

Partition

  • 하나의 토픽에는 여러개의 파티션이 가능

    • 파티션이 여러개면 메시지는 라운드로빈으로 적재 됨
    • 파티션을 늘리는건 신중해야함. 파티션을 다시 줄일 수는 없다.
    • 파티션을 늘리면 분산처리 → 퍼포먼스
  • 컨슈머는 파티션에서 가장 오래된 순서로 데이터를 가져간다.
  • 컨슈머가 컨슘해도 파티션에 데이터가 남음.

  • 여러 컨슈머가 하나의 메시지를 가져갈 수 있는 구조. ( 물론 옵션과 컨슈머 그룹 설정에 따라 다름 )

    • 주문이 발생했을 때 재고/알림/유저정보 등 컨슈머를 N 개 가져가면 loose coupling 이겠지

Producer

  • 토픽에 메시지 생성, 처리 실패/재시도 가능
  • kafa clients 라이브러리를 통해 사용가능. 다만 브로커와 클라이언트 하위호환 조심할것.
  • 카프카 브로커의 주소목록은 2개이상의 아이피와 포트를 설정하여 고가용성을 확보하는게 좋음
  • 프로드셔에서 레코드에 키 해슁되어 파티셔닝에 사용된다.

Broker, Replication, ISR

  • 메시지 수집/전달 역할
  • 가용성 보장하기위해 카프카도 클러스터를 둠 ( 3개 이상을 권장함, Master - Slave 구조 )
  • Broker 는 Leader (master ) 와 Follower ( salve ) 구조이고 이를 합쳐 ISR( In sync replica ), Ledaer 는 승계될 수 있는 구조

  • 프로듀서 ACK 동작 ( Producer 가 Borker를 보낼 때 )

    • 0 - 리더 브로커에 데이터를 전송하고 응답값을 안받음 ⇒ 데이터 유실 가능, 속도는 빠름
    • 1 - 리더 브로커에 데이터를 전송하고 응답값을 받음 ⇒ 데이터 유실 가능(브로커간 동기화 이슈), 속도는 빠름
    • ALL - 리더와 팔로어 브로커에게 모두 데이터 동기화 확인 응답을 받음 ⇒ 데이터 유실 없음, 속도는 현저히 느림

Consumer

  • 카프카는 컨슈머가 데이터를 가져가더라도 데이터가 브로커(토픽)에서 빠지지 않음.
  • 데이터를 가져오는 것을 폴링(polling)이라고 한다.
  • 데이터를 가져오고, Partiion 의 offset 위치를 기록(commit ) 하며, Consumer Group 을 통해 병렬 처리 가능
  • 프로듀서와 마찬가지로 kafa clients 라이브러리를 통해 사용가능. 다만 브로커와 클라이언트 하위호환 조심할것.
  • polling loop 는 보통 while(true) 에 cousumer.poll(waiting).
  • 처리는 단위는Record
  • 파티션 내의 데이터는 컨슈머 그룹별로/토픽별로/파티션별로 offset number 를 갖게됨. 결국 컨슈머가 어디까지 데이터를 읽었느냐의 문제. 컨슈머가 이슈가 발생하더라도, 처리하던 offset 이후부터 다시 실행. 즉 컨슈머 처리 롤백이 가능함. 즉 메시지 가져갔다가 처리가 잘 안되면 offset commit 구조로 재시도 가능.

  • 컨슈머 그룹이 같을 때

    https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ea8fc2d0-515c-4ad1-ab6a-4f56d5a7afb1/Screen_Shot_2020-03-30_at_4.47.20_PM.png

    • 파티션보다 컨슈머가 많을 때, 컨슈머는 동작하지 않는다. 파티션에 동시에 여러 컨슈머가 붙을수 없다. ( 컨슈머 1개 파티션2개 ⇒ 가능, 컨슈머 3개 파티션 3개 ⇒ 1개 컨슈머 논다 )

  • 컨슈머 그룹이 다를 떄

    • 컨슈머 그룹끼리는 영향을 받지 않는다.

    https://s3-us-west-2.amazonaws.com/secure.notion-static.com/57564e90-6d03-44d7-8276-049951de06d0/Screen_Shot_2020-03-30_at_4.48.18_PM.png

Consumer Lag

  • 파티션안에서 프로듀서가 마지막으로 넣은 offset 과 컨슈머가 마지막으로 읽은 offset 의 차이를 기반으로 함
  • 토픽의 여러 파티션이 존재할 경우, 파티션마다 랙이 여러개임. records-lag-max 가 파티션 여러개중 가장 높은 것. 컨슈머의 성능 모니터링에 lag 을 잘 살펴야 함. burrow 같은 lag checking 모니터링 라이브러리 있음.

via Queuing / Pubsub

  • 큐잉과 펍섭 이 둘의 특징을 겸비한 형태로 만들어졌음.

카프카 데이터 영속화의 목적 ( 디스크에 메시지 저장함 )

  • 고장에 의한 최근 메시지 손실 회피 목적으로 영속화하는 것은 아니다. 브로커 메모리에 메시지가 들어가면 송신완료로 간주하는 특성을 보면 잘 알 수 있다. ( 메모리에서 디스크 장애났을 때를 보호하기 위해 저장하는 뜻이 아님 )

전달보증

  • At most one, At least one, Exactly One 다양하게 신뢰성과 성능의 tradeoff 옵션을 제공.
  • 처음에는 트랜잭셔널 모델이 카프카에 없었으나, Exactly One 을 지원하면서 결국 트랜잭션 개념이 도입됨.

CQRS 와 카프카

  • 이벤트 소싱이란 상태변화 하나하나를 이벤트로 취급하여 순서대로 기록. 마치 디비 트랜잭션 로그 같은 것. 카프카 메시지는 순차적으로 기록되기 때문에 이벤트소싱에 적합하다.
  • CQRS(커맨트 쿼리 책임 분리)란 데이터 갱신과 문의 처리를 분리하는 개념이다. 제공하는 서비스에 따라 기록과 읽기의 액세스 패턴이 크게 다를 수 있다. 또한 기록되는 데이터는 동일하더라도 그 데이터를 여러 목적으로 사용하고 싶은 경우도 있다.

Stream

  • 스트림 처리는 실시간으로 셍성되는 데이터를 순차적으로 처리하는 방식.
  • 실시간 생성 데이터를 스트림 데이터라고 부르기도 한다. 가령 클릭로그, 센서데이터 측정된 데이터 등 스트림 데이터의 경우 대게 작은 단위로 지속적으로 보낸다 스트림

데이터 허브 with Kafka Connect

Kafka connect란

  • 다른 시스템과의 데이터 연계에 사용한다. 카프카에 데이터를 넣거나, 데이터를 추출하는 과정을 간단히 하기 위해 만들어졌다.
  • 데이터를 넣는 프로듀서 쪽 커넥터를 소스(source)라 부르고, 데이터를 출력하는 컨슈머 쪽의 커넥터를 싱크(sink)라고 한다. 이런 커넥터로 입출력을 손쉽게 할 수 있다.

참고자료

Buy Me A Coffee