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 | 메시지는 중복되지 않지만, 상실될 수 있음 |
| 적어도 1회는 전달 | O | X | 메시지가 중복될 가능은 있지만, 무손실 |
Exactly Once | 1회만 전달 | O | O | 중복되거나 상실되지도 않고 확실하게 메시지가 도달, 성능 저하 |
At Least Once 수준
Ack와 오프셋 개념도입
프로듀셔 <-> 브로커 : 메시지 전송 및 정상수신
브로커 <-> 컨슈머 : 메시지 수신 및 정상처리 offsetCommit 처리
offsetCommit-> 전달범위 보증의 구조, 메시지 재전송시 어디서 부터 할지에 대한 판단 기준
Exactly Once 실현
카프카 유용성이 높아지면서, Exactly Once 수준의 전달보증 요구 상승
-> 카프카 트랜잭션 개념 도입
프로듀서 <-> 브로커 사이 구현 필요
시퀀스 번호로 관리, 중복되는 실행을 제거
브로커 <-> 컨슈머 사이 구현 필요
컨슈머에 대해 트랜잭션 처리
프로듀서 -> 상류시스템, 컨슈머 -> 하류시스템에서도 상태관리 요구 카프카 -> 트랜택션 관리 메커니즘 갖춤 -> 상하류 시스템 필요시, 상태관리를 위한 조건구성 -> 전달 보증
Last updated