메세지 지향 미들웨어
미들웨어
분산 컴퓨팅 환경에서 애플리케이션 간의 통신과 데이터 관리 입력/출력 기능 등을 지원하는 소프트웨어 계층
데이터 베이스 미들웨어(JDBC), 원격 프로시저 호출(RPC, JSON-RPC), 웹 미들웨어 (Apache Tomcat, Microsoft IIS), 메세지 지향 미들웨어(MOM) 등이 있음
개념
- 어플리케이션들의 메세지를 중간에서 관리해주는 시스템
- MOM의 개념을 가진 프로토콜을 기반으로 다양한 구현체 등장
- 프로토콜
- JMS(Java Messaging System): Java지원 표준 API
- AMQP(Advanced Message Queue Protocol): 미들워어 브로커 간 메세지 교환을 위한 응용계층 표준 프로토콜
- 구현체 (메세지 큐)
- 메세지를 임시로 저장하는 버퍼 역할
- ActiveMQ
- RabbitMQ
- Apache Kafka
- Amazon SQS
- 프로토콜
특징
- 낮은 종속성과 결속성
- 클라이언트 시스템간에 메세지 통신을 중간에서 관리해줌으로써 클라이언트 시스템간의 종속성 및 결속성을 낮춰줌
- 송신자는 수신자의 주소를 몰라도 메세지를 보낼 수 있음
- 높은 안정성
- 주고 받는 메세지를 데이터베이스에 기록하여 백업 가능
- 라우팅 규칙을 활용해 하나의 메세지로도 특정 여러 클라이언트가 받을 수 있도록 지원
단점
- 메세지 전체를 관리하는 시스템 따로 필요
- 이에따른 도입, 운영 비용의 고려
- 전체적인 시스템 구조가 복잡해질 수 있음
- 송수신자가 직접 통신하는 것이 아닌 다수의 서버가 MOM을 이용하므로 구조가 전체적으로 복잡해지고 이에 대한 오버헤드 발생 가능
개념
- 대용량 데이터 처리를 위한 미들웨어
- MQ에 라우팅, 변환, 모니터링 및 관리, 메시징 패턴 (Pub/Sub, Point-to-point) 등의 기능을 추가적으로 제공
- 메세지를 생산하는 Publisher(송신자)와 저장된 메세지를 사용하는 Subscriber/Consumer(수신자) 사이에서 메세지를 전달하는 역할
- 이를 통해 응용 소프트웨어 간에 메세지를 교환할 수 있도록 함
특징
- Publish/Subscribe(Consumer) Pattern
- 송신자가 보낸 메세지를 메세지 큐에 적재하고, 이를 수신자가 받아서 사용하는 구조
- 실시간 데이터 처리 성능이 뛰어남
- 일반적인 방법 (A서버: 데이터를 DB에 적재, B서버: DB에서 데이터 조회)에선 실시간으로 데이터가 쌓이는 테이블을 조회하기 어려움
- 메세지 브로커 사용시, B서버에서 별도의 조회과정이 필요 없이 메세지 큐에 적재되는 메세지를 감시하다가 적재되면 바로 가져다 사용 가능
- 비동기 방식
- 메세지 큐, 토픽과 같은 데이터 구조를 통해 메세지를 임시로 저장해두었다가 적절한 수신자에게 보내줌
- 비동기적으로 메세지를 처리가 가능하기 때문에 대용량 트래픽이 몰리는 경우에도 실제 처리는 일어나지 않고 메세지 큐에 적재만 해두고 Consumer가 처리 가능한 시점에 처리할 수 있기 때문에 부하가 줄 수 줄어듬
- Point to point
- MSA 환경에서 메세지 큐를 활용해서 각 필요한 서비스에 메세지를 전달하고, 각 서비스는 메세지를 받아서 처리하는 방식으로 사용
사용 이유
- 서비스(어플리케이션)간의 의존성 제거
- 서버 수가 유동적이여도 정상적으로 동작
- 송수신측 모두 메세지 브로커의 주소만 알고있다면 메세지를 보내고 받는데 문제 없음
- 수신 측 서버에 문제가 생겨도 정상 동작
- 메세지 큐는 메세지를 유지하고 있으므로 수신 측 서버가 문제가 정상적으로 돌아오면 유지했던 메세지 받을 수 있음
- 서버 수가 유동적이여도 정상적으로 동작
- 메세지 버퍼링
- 수신 측에서 원하는 시점에 메세지를 가져갈 수 있도록 지원
- 다양하고 유연한 통신
장점
- 안정적인 비동기 방식으로 메세지를 교환하여 분산된 시스템/어플리케이션 간의 통신을 도움
- 생산자와 소비자간 중개자 역할을 하여 두 시스템이 완전히 독립적으로 작동할 수 있도록 도움
- 컴포넌트간 느슨한 결합을 도움
단점
- 쿼리를 이용해 원하는 데이터만 필터링 조회 불가능
- 큐에 적재된 내용을 그대로 사용하기 때문
- 따라서 데이터 필터링을 위해 Logstash를 이용 혹은 적재시 필터링된 데이터를 적재해야 함
- 메세지 큐에 적재된 메세지는 주로 7일 보관으로 장기간 보관시 별도의 저장소 이용해야함
구조
- Message Queue
- 메세지가 적재되는 공간
- 큐 자료 구조 형태로 메세지를 다루는 구조, 나아가 MOM의 구현체의 개념인 메세지 전송 구조를 가진 미들웨어
- Message Broker 내부에 메세지가 적재되는 공간
- Topic
- 메세지들의 그룹
Message Broker와 Message Queue의 개념은 서로 모호하게 사용하는 경우가 많다.
전통적인 메세지 브로커
개념
- 메세지 브로커 방식
- 브로커 중심적인 방식으로, 지정된 수신인에게 메세지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메세지 전달에 초점을 맞춤
- AMQP(Advanced Message Queuing Protocol)를 구현하는 오픈 소스 메세지 브로커 소프트웨어
특징
- 쉽고 빠르게 작은 서비스의 메세지 브로커를 구축하기 좋으며 메세지 전달 보장이 필수적
- 단, 메세지 처리 순서와 영속성은 보장되지 않음
- 안정성으로 유명하며 금융 서비스, 전자 상거래 및 IoT 와 같은 다양한 산업에 사용
이벤트 스트리밍 플랫폼
개념
- 이벤트 스트리밍 플랫폼
- 메세지 브로커와 이벤트 스트리밍 플랫폼 모두 이벤트를 수신하고, 이것을 소비자에게 전달하는 같은 목적을 두지만 작동방식에 차이가 있음
- 이벤트 스트리밍 플랫폼은 메세지 브로커와 다르게 topic이라는 것이 event streamer에 저장 됨
topic: kafka에서 메세지를 저장하는 단위
- 분산 스트리밍 플랫폼
- 실시간 데이터 스트림의 높은 처리량, 내결함성 및 확장 가능한 메시징 및 처리를 위해 설계 됨
- 대량의 이벤트를 처리하고 대기 시간이 짧은 메시징 서비스를 제공
특징
- 높은 처리량을 감당할 수 있으며 스케일 아웃이 중요한 경우 사용
- 영속성, 메세지 처리 순서가 보장되나 전달 보장은 필수적이지 않음
- 로그 및 이벤트의 중앙 스토리지 시스템 역할에 적합
- RabbitMQ, Kafka 둘 다 Pulibsh/Subscribe 기반의 메세지 큐 서비스이나 Kafka는 이벤트 브로커이고, RabbitMQ는 메세지 브로커이다.
이벤트 브로커- 이벤트 브로커는 메세지 브로커의 기능을 포함하는 더 큰 범위의 개념이기에 이벤트 브로커가 메세지 브로커 역할을 수행할 수도 있다.
- publisher가 생산한 이벤트를 저장하고, consumer가 해당 이벤트를 사용하더라도 이벤트가 저장된다는 특징으로 이후에 다시 재사용 할 수 있는 장점을 가지고 있다.
메세지 브로커- 중간 다리 역할을 수행하는 broker로 publisher가 생산한 메세지를 큐에 저장하고, consumer가 데이터를 가져가면 즉시 혹은 짧은 시간 내에 큐에서 데이터를 삭제한다.
대용량 데이터 처리를 위한 Message Broker
Message Broker - 왜 사용하는 것일까 ?
[Tech] RabbitMQ와 Kafka의 차이? 메세지 브로커와 이벤트 스트리밍 플랫폼