01.카프카 스트림즈

Part 1. 카프카 스트림즈 시작하기

카프카 스트림즈

👉🏻 빅데이터로의 전환

빅데이터로의 전환으로 대량의 데이터를 벌크 처리할 수 있는 능력만으로는 충분하지 않다.

카프카 스트림즈는 이벤트별 레코드 처리를 수행할 수 있게 하는 라이브러리다.

.

👉🏻 스트림 처리를 사용해야 할 경우와 사용하지 말아야 할 경우

데이터에 신속하게 응답하거나 보고해야 하는 경우가 스트림 처리의 좋은 사용 사례

• 신용카드 사기(고정 패턴-위치, 소비 습관)

• 침입 탐지(비정상적인 동작 모니터링)

• 뉴욕시 마라톤과 같은 대규모 경주(센서 데이터 사용)

• 금융 업계(시장 가격과 방향 추적)

데이터가 도착하자마자 즉시 보고하거나 조치를 취해야 하는 경우 스트림 처리가 좋은 방법이다.

.

👉🏻 구매 트랜잭션에서의 관점

Result

📖 요약

카프카 스트림즈는 강력하고 복잡한 스틀미 처리를 위해 처리 노드를 조합한 그래프

배치 처리는 강력하지만 데이터 작업에 대한 실시간 요구를 만족시키기에는 충분하지 않음

데이터, 키/값 쌍, 파티셔닝 및 데이터 복제를 분산하는 것은 분산 애플리케이션에서 매우 중요

카프카 빠르게 살펴보기

카프카는

• 내고장성(fault-tolerant)을 가진 견고한 발행/구독 시스템

• 하나의 카프카 노드를 bloker라 부르고, 여러 개의 가프카 브로커 서버가 cluster를 구성

• 카프카는 producer가 작성한 메시지를 토픽에 저장

• consumer는 토픽을 구독하며, 구독한 토픽에 메시지가 있는지 확인하기 위해 카프카에 접속

데이터 허브로 카프카를 사용하면 아키텍처가 훨씬 간단해진다.
각 애플리케이션은 카프카에 읽고 쓰는 방법만 알고 있으면 된다.
애플리케이션을 추가하거나 제거해도 다른 애플리케이션의 데이터 처리에 영향을 주지 않는다.

카프카 아키텍처

👉🏻 카프카는 메시지 브로커다

• 브로커는 상호 간 유익한 교환이나 거래를 위해 각자 반드시 알 필요가 없는 두 부분을 묶는 중개자

• 프로듀서가 카프카에 메시지를 보내면 메시지가 저장되어 토픽 구독을 통해 컨슈머가 사용

• 주키퍼 노드 클러스터는 카프카와 통신해 토픽 정보를 유지하고 클러스터의 브로커를 추적

• 카프카 토픽의 내부 기술은 카프카가 들어오는 레코드를 기록한 파일인 로그

  • 토픽에 들어오는 메시지의 부하를 관리하기 위해 파티션을 사용

.

👉🏻 카프카는 로그다

• 카프카의 기본 메커니즘은 로그

• 카프카의 맥락에서 로그는 추가만 가능한 시간순으로 완전히 정렬된 레코드 시퀀스

• 로그는 들어오는 레코드가 추가되는 파일로 새로 도착한 각 레코드는 마지막 레코드 뒤에 위치하고, 이 과정은 파일의 레코드를 시간순으로 정렬

• 카프카의 토픽은 토픽 이름으로 분리된 로그

  • 라벨이 붙은 로그라고 할 수 있다.

  • 로그가 머신 클러스터 간에 복제된 후 하나의 머신이 중지되면 해당 서버를 복구하는 것은 쉽다.

  • 단지 로그 파일을 재생하면 되므로..

  • 실패로부터 복구하는 기능은 정확하게 분산 커밋 로그의 역햘

.

👉🏻 카프카와 파티션

• 파티션은 카프카 디자인에서 중요한 부분

  • 성능에 필수적이며, 같은 키를 가진 데이터가 동일한 컨슈머에게 순서대로 전송되도록 보장

  • 같은 키를 가진 메시지를 함께 처리하도록 보장

• 토픽을 파티션으로 분할하면 기본적으로 병렬 스트림에서 토픽에 전달되는 데이터가 분할

  • 이는 카프카가 엄청난 처리량을 달성하는 비결

• 특정 토픽의 용량이 넘치지 않도록 토픽의 메시지를 여러 머신에 분산

.

👉🏻 키에 의한 그룹 데이터 분할

• 키가 null이면 카프카 프로듀서는 라운드 로빈 방식으로 선택된 파티션에 레코드를 씀

  • 메시지 키는 메시지가 이동할 파티션을 결정하는데 사용

• 키의 바이트를 해싱하고 파티션 수를 모듈로 계산해 파티션을 얻음

  • HashCode.(key) % 파티션 수

    • hashCode(AByte) % 2 = 0

    • hashCode(BByte) % 2 = 1

• 동일한 키를 가진 레코드가 항상 동일한 파티션에 순서대로 전송