카프카(kafka) 써보기

카프카 ?

Apache Kafka로 분산 스트리밍 플랫폼이다.
대규모의 데이터를 실시간으로 처리하고 전송하는 데 사용된다.
예) 실시간 데이터 피드 , 로그 수집 , 이벤트 스트리밍 등

실시간 데이터 피드

프로듀서 : 사용자가 작성한 게시물을 kafka 특정 토픽 (user-posts 등) 으로 보낸다.
토픽 : user-ports 라는 토픽이 모든 게시물을 담고 있다.
컨슈머 : 타임라인을 업데이트하는 서비스가 이 토픽을 구독해서
새로운 게시물이 도착할 때마다 데이터를 가져와 실시간 피드를 보여준다.

로그 수집

프로듀서 : 각 서버 발생 로그를 토픽별로 전송한다.
예로 토픽 transaction-logs , error-logs 등이다.
토픽 : 각 로그 데이터를 토픽별로 저장한다.
컨슈머 : 실시간으로 토픽 데이터를 수집한다.

이벤트 스트리밍 (예: 실시간 추천 시스템)

프로듀서 : 사용자의 행동 데이터 (clicks , add-to-cart) 를 kafka 토픽 (user-actions) 에 전송한다.
토픽 : user-actions에 모든 행동 이벤트가 순차 기록된다.
컨슈머 : 해당 토픽을 실시간 구독해 사용자 행동 데이터를 분석한다.
또 다른 컨슈머 : 추천 토픽을 구독해 사용자에게 실시간 제품 보여준다.

왜 가능하지? 카프카가 왜 빠르지?

(1) 순차적인 I/O
인접 메모리 블록에서 데이터를 읽거나 쓰는 것으로
디스크 헤드가 직선으로 움직여 동선이 훨씬 빠르다.

(2) Zero Copy
데이터를 네트워크로 전송시, 디스크에서 바로 네트워크 버퍼로 전송 하는 기술이다. 즉 , 중간에 메모리 로드 과정을 스킵한다. (cpu 사용률 줄이고, 데이터 전송속도 높이고)

(3) 페이지 캐시 (Page Cache)
메모리가 자주 로드되는 페이지를 올려놓는 방식을 적극 활용한다고 한다.

(4) 파티셔닝
kafka는 토픽을 여러 파티션으로 나눈다. 이를 병렬 처리함으로써
여러 컨슈머가 서로 다른 파티션을 동시에 읽을 수 있다.

(5) 오프셋 사용
컨슈머는 메세지를 읽을 때 특정 오프셋부터 순차읽기가 가능!
따라서 이전에 처리한 동일 메세지는 재처리하지 않음

결론 : 디스크 기반 영구저장이지만! 위와 같은 이유로 빠른 실시간 데이터 처리가 가능하다. 와 개쩐다.

카프카에 존재하는 개념

• Producer : 데이터 생성 및 kafka에 전송한다.
  예) 사용자 활동 로그를 kafka로 전달

• Comsumer : kafka에서 데이터를 가져가 처리한다.
  예) 수집된 로그 데이터를 분석하기위해 데이터를 가져가는 앱

• Topic : kafka에서 데이터가 저장되는 카테고리
  예) 컨슈머는 특정 Topic에서 데이터를 읽거나 , 프로듀서가 보낸다.

• Broker : kafka의 서버 역할을 하는 노드
  브로커가 여러개이면 kafka는 데이터를 여러 브로커에 분산 저장할 수 있다.

• Partition : 토픽은 여러 파티션으로 나뉘며, 병렬 처리가 가능하다.

메세징 시스템들의 차이점

• redis

  • 인메모리 , pub/sub 방식으로 메시징 구현 가능
  • 빠른 성능 , 하지만 데이터 저장 한계 및 보존 기능 어려움
  • 사용 예시) 채팅 , 캐싱 , 대기열 토큰 등

• rabbitMQ

  • AMQP(Advanced Message Queuing Protocol)를 기반으로 하는 메시지 브로커
  • 메세지 영구 저장 및 다양한 라우팅 패턴이 존재함
  • 복잡한 메시징 패턴이 필요한 경우 사용

• kafka

  • 대규모 데이터 스트리밍과 로그 관리에 최적화
  • 높은 처리량과 확장성이 요구되는 경우 사용

Transactional Outbox Pattern

분산 시스템에서 DB와 메세지 큐 사이의 일관성을 보장하기 위한 패턴으로 흔히 이벤트 기반 시스템이나 MSA 에서 많이 사용됨

필요한 이유

분산 시스템에서 만약 두 작업 중 하나는 실패한다면? -> 불일치 이슈

TOP 로 해결하는 원리

(1) DB에 Outbox 테이블을 생성한다. (보낼 메세지를 임시 저장)
(2) 로직 처리를 하면서 발생한 이벤트를 Outbox 테이블에 기록
(이때 모든 작업은 하나의 트랜잭션으로 묶여있다)
(3) 트랜잭션 커밋시, DB변경사항과 Outbox 테이블 메세지가 확정
(4) if 실패하면 DB변경도 없고, Outbox도 롤백 (@transactional)

(5) 성공했다면, 별도 프로세스가 Outbox를 모니터링해서 새로운 메세지가 있으면 메시지큐나 이벤트 버스로 보내고 Outbox에서 삭제

예시 ) 쇼핑몰 어플리케이션에서 주문을 하는 케이스

(1) 사용자가 주문을 제출함
(2) 서버는 DB에 주문 정보를 insert 함
(3) 동시에 "주문생성" 이라는 이벤트를 Outbox 테이블에 insert함
(4) 트랜잭션이 커밋되면
(5) 별도의 프로세스가 Outbox 테이블 확인 및 메세지 큐로 보냄
(6) 성공적으로 전달되면 Outbox 테이블에서 해당 이벤트 삭제
=> (5)가 실패한다고 해도 , Outbox에는 남아있으니 계속 시도 가능

사용시 장점

• 트랜잭션으로 묶여 작업과 메세지 전달의 일관성 보장
• 만약 전달 실패해도! Outbox 테이블에 정보가 남아있어 재시도 가능

[참고 자료]
https://ssnotebook.tistory.com/entry/Kafka-Kafka%EA%B0%80-%EB%B9%A0%EB%A5%B8-%EC%9D%B4%EC%9C%A0