사내에서 Kafka 도입에 대한 발표가 있어서.. 정리차 한글자씩 적어보려한다.
MQ 란?
→ Producer, Consumer가 존재하며 Producer는 메시지를 큐에 전송하고 Consumer가 큐의 메시지를 처리하는 방식이다.
→ MQ를 사용하면 비동기로 요청을 처리하고 queue에 저장하여 consumer에게 병목을 줄여줄 수 있는데 장단점은 존재한다.
왜 쓸까?
→ 일반적으로 Server-Client 구조에서는 사용자가 요청을 하면 Server에서는 Request에 대한 처리를 한 후 Response 한다. 이런 간단한 구조는 MQ와 같은 미들웨어를 사용할 필요가 없다.
→ MQ의 종류에도 RabbitMQ, Kafka, ActiveMQ 등 여러가지 MQ들이 존재한다. 각 시스템 목적에 맞춰 사용하는게 가장 바람직하다.
Application ↔ System 통신
→ 서버간 데이터를 주고받을때 항상 시스템 장애를 염두해둬야한다. 만약 서버가 죽거나 서버 점검 등으로 다운타임이 발생하는 동안에는 요청을 보낼 수 없다. 요청하는 서버에서 Failover 처리를 해놓고 연계 시스템이 다시 살아났을때 요청을 보내는 방법도 있지만 MQ를 이용하면 더욱 간편하게 처리할 수 있다.
→ 아래 그림과 같이 Message가 Queue에 쌓였다면 Consumer에서 메시지를 소비하기 전까지 Message queue에 보관되게된다. 만약 Consumer쪽 Server가 Fail 되었다면 MQ에 보관되는 것이다.
장점
→ 비동기, 비동조, 탄력적, 과잉, 보증, 확장성
→부하분산
→데이터 손실 방지.
→ Failover 커버 가능.
OSS Message Queue
RabbitMQ
- AMQT 프로토콜을 구현 해놓은 프로그램
- 신뢰성 – 안정성과 성능을 충족할 수 있도록 다양한 기능 제공
- 유연한 라우팅 – Message Queue가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅 가능
- 클러스터링 – 로컬네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링 할 수 있고 논리적인 브로커도 가능 하다.
- 관리 UI가 있어 편하게 관리 가능하다
- 거의 모든 언어와 운영체제 지원
- 오픈소스이며 상업적 지원
ActiveMQ
- 아파치 ActiveMQ 는 풀 자바 메시지 서비스(JMS) 클라이언트와 함께 자바로 만든 오픈소스 메시지 브로커이다. 이 시스템은 “엔터프라이즈 기능” – 이 경우는 하나 이상의 클라이언트와 서버간의 커뮤니케이션을 증진시키는 – 을 제공한다. JMS 1.1 을 통해 자바 뿐만 아니라 다른 “교차언어”를 사용하는 클라이언트를 지원한다. 커뮤니케이션은 컴퓨터 클러스터링및 가상메모리, 캐쉬 그리고 저널 지속성을 제외한 어떤 데이터베이스를 JMS 지속성 제공자로 이용할 수 있는 등의 특징들을 통해 운영된다.
Kafka
- 대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템으로써 기존 범용 메시징 시스템대비 TPS가 매우 우수하다. 단, 특화된 시스템이기 때문에 범용 메시징 시스템에서 제공하는 다양한 기능들은 제공되지 않는다.
- 분산 시스템을 기본으로 설계되었기 때문에, 기존 메시징 시스템에 비해 분산 및 복제 구성을 손쉽게 할 수 있다.
- AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시켰다.
- Producer가 broker에게 다수의 메시지를 전송할 때 각 메시지를 개별적으로 전송해야하는 기존 메시징 시스템과는 달리, 다수의 메시지를 batch형태로 broker에게 한 번에 전달할 수 있어 TCP/IP 라운드트립 횟수를 줄일 수 있다.
- 메시지를 기본적으로 메모리에 저장하는 기존 메시징 시스템과는 달리 메시지를 파일 시스템에 저장한다.
- 파일 시스템에 메시지를 저장하기 때문에 별도의 설정을 하지 않아도 데이터의 영속성(durability)이 보장된다.
- 기존 메시징 시스템에서는 처리되지 않고 남아있는 메시지의 수가 많을 수록 시스템의 성능이 크게 감소하였으나, Kafka에서는 메시지를 파일 시스템에 저장하기 때문에 메시지를 많이 쌓아두어도 성능이 크게 감소하지 않는다. 또한 많은 메시지를 쌓아둘 수 있기 때문에, 실시간 처리뿐만 아니라 주기적인 batch작업에 사용할 데이터를 쌓아두는 용도로도 사용할 수 있다.
- Consumer에 의해 처리된 메시지(acknowledged message)를 곧바로 삭제하는 기존 메시징 시스템과는 달리 처리된 메시지를 삭제하지 않고 파일 시스템에 그대로 두었다가 설정된 수명이 지나면 삭제한다. 처리된 메시지를 일정 기간동안 삭제하지 않기 때문에 메시지 처리 도중 문제가 발생하였거나 처리 로직이 변경되었을 경우 consumer가 메시지를 처음부터 다시 처리(rewind)하도록 할 수 있다.
- 기존의 메시징 시스템에서는 broker가 consumer에게 메시지를 push해 주는 방식인데 반해, Kafka는 consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식으로 동작한다. 따라서 consumer는 자신의 처리능력만큼의 메시지만 broker로부터 가져오기 때문에 최적의 성능을 낼 수 있다.
- 기존의 push 방식의 메시징 시스템에서는 broker가 직접 각 consumer가 어떤 메시지를 처리해야 하는지 계산하고 어떤 메시지를 처리 중인지 트랙킹하였는데, Kafka에서는 consumer가 직접 필요한 메시지를 broker로부터 pull하므로 broker의 consumer와 메시지 관리에 대한 부담이 경감되었다.
- 메시지를 pull 방식으로 가져오므로, 메시지를 쌓아두었다가 주기적으로 처리하는 batch consumer의 구현이 가능하다.
(참고.)
https://12bme.tistory.com/176 (Message Queue (MQ) 란 무엇일까)
https://kji6252.github.io/2015/12/18/message-quere/(최신 메시지 큐(Messgae Queue) MQ 기술)
2020/10/12 - [Delvelopment/Kafka] - [Kafka] Topic 메세지 보관주기 설정 (MSK)
2020/08/21 - [Delvelopment/Kafka] - MQ (Message queue)란?
2020/08/05 - [Delvelopment/Self-MSA구축기] - [Kafka Tool] KaDeck 이용해 Topic, Message생성하기.
2020/06/29 - [Delvelopment/Kafka] - [Spring Boot, kafka] 스프링 프로젝트에 kafka 리스너 적용기.
2020/06/29 - [Delvelopment/Kafka] - [MAC, Kafka] 맥에 Kafka 설치 하고 토픽생성. (Docker, homebrew, Apache)
'Delvelopment > Kafka' 카테고리의 다른 글
| [Kafka] Topic 메세지 보관주기 설정 (MSK) (0) | 2020.10.12 |
|---|---|
| [kafka Connect] 주기적으로 수행되는 무거운 쿼리 ALL_OBJECTS (table.poll.interval.ms) (3) | 2020.10.12 |
| [Spring Boot, kafka] 스프링 프로젝트에 kafka 리스너 적용기. (0) | 2020.06.29 |
| [MAC, Kafka] 맥에 Kafka 설치 하고 토픽생성. (Docker, homebrew, Apache) (2) | 2020.06.29 |
| [Apache Kafka] Kafka 란? (0) | 2020.05.21 |
댓글