1. 개요 및 특징

개요

  • IBM MQ (IBM WebSqure MQ)

    • 메시지 단위 트랜잭션 처리 가능

    • 강력한 전달 보증 (무손실)

  • Kafka

    • 높은 처리량 우선, 대량데이터 실시간 처리

    • 클러스터링에 대한 요구 반영, 스케일 아웃 기능

    • 배치처리, 실시간 처리 둘다 가능

    • pull 방식선호, push 수신쪽 커버가 가능하다면 나쁘지 않은 선택

    • 확장 : 카프카 확장, 수신 pull방식 선호.

    • 다양한 제품(하둡,스파크,ES 등)과 시스템과 연동용이

    • 데이터 무손실

    • 이해하기 쉬운 API, 전달보증, 데이터 영속화

카프카 메시징 모델

  • Producer : 메시지 생산자

  • Broker : 메시지 수집/전달

  • Consumer : 메시지 소비자

메시징 모델 - 큐잉모델

프로듀서 -> 브로커 -> 컨슈머 처리 순

  • 브로커 : 큐 생성

  • 프로듀서 : 메시지 생성 -> 큐 저장

  • 컨슈머 : 큐 -> 메시지 추출 (추출되면, 다른 컨슈머는 추출 못함)

1개의 큐에 여러 개의 컨슈머가 대응. 큐:컨슈머 = 1:M 관계 -> 그림

하나의 큐메시지는 컨슈머에 의해 병렬처리. 처리된 메시지는 큐에서 사라지고, 1메시지 1컨슈머에 의해 처리됨

메시징 모델 - Publish / Subscribe (펍/섭) 모델

  • 프로듀서 -> 퍼블리셔(Publisher)로 매핑

  • 컨슈머 -> 섭스크라이버(Subscriber)로 매핑

  • Publisher -> Broker(토픽) -> Subscirber

  • Publisher : 수신자 알수 없음, 브로커의 토픽에 메시지 전달

  • Subscirber : 토픽에서 메시지를 추출

  • 여러 Publisher가 메시지 송신 가능 -> A토픽 <- 여러 Subscriber가 동일 메시지를 수신 가능

  • 큐잉과 차이 -> 여러 Subscirber가 동일한 메시지를 수신 가능

브로커를 끼우는 장점

  • 시스템 변경에 대해 유연한 아키텍처 구성이 가능

  • 프로듀서 -> 브로커만 신경 씀

  • 컨슈머 -> 브로커만 신경 씀

브로커가 없다면

프로듀서 <-> 컨슈머로 서로 강한 결합도를 갖게 된다. 즉 시스템 구성, 토폴로지에서 각각에 대해 신경을 쓰고 알아야한다. 구성 관계 수는 N x M이 되게 됨. 프로듀서 -> 브로커 <- 컨슈머는 구성 관계를 N + M으로 변경해주는 역할을 하게 되므로, 시스템 구성의 신경을 줄일 수 있음.

메시징 모델 - 카프카

큐잉모델 -> 여러 컨슈머가 분산 처리로 메시지 소비 펍/섭 모델 -> 여러 Subscriber에 동일메시지 전달, 토픽기반으로 전달 내용 변경 => 컨슈머 그룹이라는 개념 도입 => 브로커도 복수 구성 -> 확장 용이

디스크 영속화

  • 임의의 타이밍에 데이터를 Read

  • 메시지 잃지 않음(무손실). 단, 고장에 의한 최근 메시지 손실 회피목적은 아님 ??

    • 사실 데이터 손실에 대한 대안은 메시지복제로 구현한다고 파악하는 것이 자연스러움

    • 복제본이 브로커 내에 존재하고 있다면

  • 메모리에서 이루어지는 것은 용량면에서 불리.. -> 카프카는 디스크에서 영속화가 가능하며, 심지어 높은처리량 제공

이해하기 쉬운 API 제공

  • Connect API : 프로듀서, 컨슈머를 쉽게 접속할 수 있또록 제공

  • Kafka Connect : API 기반 카프카 접속

  • 컨플루언트 제공 : ActiveMQ, IBM MQ, JMS HDFS, JDBC 등

  • 기타 개발사 및 커뮤니티 개발자 개발

  • Streams API : Kafka Streams

전달보증

3가지 수준으로 관리

종류

개요

재전송 유무

중복삭제 유무

비고

At Most Once

1회는 전달을 시도

X

X

메시지는 중복되지 않지만, 상실될 수 있음

At Least Once

적어도 1회는 전달

O

X

메시지가 중복될 가능은 있지만, 무손실

Exactly Once

1회만 전달

O

O

중복되거나 상실되지도 않고 확실하게 메시지가 도달, 성능 저하

At Least Once 수준

  • Ack와 오프셋 개념도입

  • 프로듀셔 <-> 브로커 : 메시지 전송 및 정상수신

  • 브로커 <-> 컨슈머 : 메시지 수신 및 정상처리 offsetCommit 처리

    • offsetCommit -> 전달범위 보증의 구조, 메시지 재전송시 어디서 부터 할지에 대한 판단 기준

Exactly Once 실현

카프카 유용성이 높아지면서, Exactly Once 수준의 전달보증 요구 상승 -> 카프카 트랜잭션 개념 도입

  1. 프로듀서 <-> 브로커 사이 구현 필요

    • 시퀀스 번호로 관리, 중복되는 실행을 제거

  2. 브로커 <-> 컨슈머 사이 구현 필요

    • 컨슈머에 대해 트랜잭션 처리

프로듀서 -> 상류시스템, 컨슈머 -> 하류시스템에서도 상태관리 요구 카프카 -> 트랜택션 관리 메커니즘 갖춤 -> 상하류 시스템 필요시, 상태관리를 위한 조건구성 -> 전달 보증

Previous실전 Apache KafkaNext2. 카프카 기초

Last updated

Was this helpful?