이직을 한 지 6개월이 돼가면서, 새로운 경험도 하고 있고 기존에 아는 내용에 대해서도 조금 더 확실하게 이해할 수 있는 기간이었다고 생각한다.
그러면서 대부분 주말을 통해 공부를 (조금)하고 블로그를 작성하였는데, 7,8월에는 열심히 글을 쓰긴 했는데, 최근에는 연휴도 있으면서(= 노느라) 글을 많이 못 썼던 것 같다.
투덜 되는 게 길었고, 이번 글에서는 최근 들어 각 회사에서 사용되는 Message Broker, Message Queue 에 대해 정리해보고자 한다.
1. MOM(Message Oriented Middleware)
- Message Broker 와 Message Queue 를 알아보기 전에, MOM(메시지 지향 미들웨어)를 간단하게 알아보겠습니다.
- MOM 은 어플리케이션들의 메시지를 중간에서 관리해주는 시스템입니다.
- MOM 을 두고 여러 계층에서 표준 및 프로토콜이 등장합니다.
- Java 에서 지원하는 표준 API 인 JMS(Java Messaging System)
- 미들웨어 브로커 간 메시지 교환을 위한 Application Layer 표준 프로토콜인 AMQP(Advanced Message Queue Protocol)
- MOM 의 개념과 프로토콜을 활용하여 다양한 구현제가 등장합니다.
- MOM 의 개념적으로는 동일하나, 내부적으로 동작하는 방식, 프로토콜, 기능 등 차이점이 존재합니다.
- ActiveMQ
- RabbitMQ
- Apache Kafka
- Amazon SQS
1-1. 장단점
- 장점
- 변환 : 클라이언트 시스템 간의 종속성 및 결속 성을 낮춰준다.(= 메시지를 보내는 이는 받는 이의 주소를 몰라도 전달이 가능)
- 지속성 : 메세지를 DB에 저장하는 등 백업이 가능하여 안정성을 높여준다.(= 송신 측과 수신 측 동시에 네트워크에 연결되어 있을 필요가 없다.)
- 라우팅 : 라우팅 규칙을 활용하여 하나의 메시지로도 여러 클라이언트가 받을 수 있도록 지원한다.
- 단점
- 메세지 전체를 관리하는 시스템이 필요하다. => 비용, 운영 비용 등이 늘어날 수 있다.
- 전체적인 시스템 구조가 복잡해질 수 있다. => 다수의 서버가 활용하면 구조가 복잡해지고, 오버헤드가 발생할 수 있다.
2. Message Broker(메시지 브로커) 란?
- Message Broker(메세지 브로커) 는 Publisher(송신자)로부터 전달받은 Message(메세지)를 동일한 Topic의 Subscriber(수신자)로 전달해주는 중간 역할을 합니다.
- 메세지가 적재되는 공간을 Message Queue(메시지큐), 메시지의 그룹을 Topic(토픽) 이라고 합니다.
- 메세지 브로커는 정형화된 메시지를 교환을 통해 어플리케이션 간의 소통이 이뤄지는 네트워크 엘리먼트입니다.
- 대표적으로 Kaflka, Redis, RabbitMQ, Celery 가 있습니다.
2-1. Message Broker 의 목적
- Message Broker 는 메시지의 유효성, 전송, 라우팅을 위한 아키텍처 패턴입니다.
- 어플리케이션 사이의 커뮤니케이션을 중재하고 어플리케이션 간의 메세지 전달을 위한 상호 인식을 줄여줌으로서 어플리케이션간의 결합성을 낮춰줍니다.
- 즉, Message Broker 는 어플리케이션으로부터 메시지를 받아 어떤 역할을 수행하는 데 있습니다.
-엔드 포인트를 분리시킬 수 있고, NFR(Non-Functional Requirement)를 충족시키며 중재 함수를 간편하게 재사용합니다.
2-2. Message Broker 사용한 방법
- 일반적인 방법
- 실시간으로 처리하기 위해 최신의 데이터를 빠르게 조회가 필요한데 실시간으로 데이터가 계속 쌓이는 테이블을 빠르게 조회하기는 어렵습니다.
- 조회 성능을 높이기 위해 Index(인덱스)를 걸게 되면, 반대로 Insert 속도가 느려지기 때문에 실시간 처리에 적합하지 않습니다.
- Message Broker 를 사용한 방법
- B 서버에서 데이터를 적재는 하지만 별도의 조회 과정 없이 처리에 대해서는 Message Broker 에게 던져주면서, 메시지를 감시하고 있다가 메시지가 적재되면 A 서버가 조회합니다.
2-3. 장단점
- 장점
- 실시간 데이터 처리를 할 때 DB 에서 조회하여 처리하는 것 보다 성능이 좋다.
- 단점
- DB 에서 조회하면 원하는 데이터만 필터링하여 조회가 가능하지만, 메시지 브로커의 경우 적재된 데이터 그대로를 사용해야 한다. => 적재 시 필터링된 데이터를 적재하던가 적재된 데이터를 필터링하여 사용해야 한다.
- 장기적인 보관을 할 수 없다.
3. Message Queue(메시지 큐)
- Message Queue(= MQ) 란 MOM(메시지 기반의 미들웨어)로 메시지를 이용하여 여러 어플리케이션, 시스템, 서비스들을 연결해주는 솔루션입니다.
- MOM 을 구현한 솔루션으로 비동기 메시지를 사용하는 서비스들 사이에서 데이터를 교환해주는 역할을 합니다.
- Producer(Sender,보내는자) 가 메시지를 큐에 전송하면 Consumer(Receiver,받는자) 가 처리하는 방식으로, Producer 와 Consumer 에 Message Process 가 추가되는 것이 특징입니다.
3-1. AMQP(Advanced Message Queuing Protocol)
- 메세지를 교환할 때 AMQP 란 프르토콜을 사용합니다.
- AMQP는 응용 계층의 MOM 표준으로 프로토콜만 일치한다면 다른 AMQP 를 사용한 어플리케이션과 통신이 가능합니다.
- 이와 다르게 JMS(Java Message Servcie)는 Java 에서 지원하는 표준으로, Java Application 간 통신이 가능하지만 다른 MOM(ex: AMQP)와는 통신할 수가 없습니다.
3-2. 장단점
- 장점
비동기(Asynchronous)
- 메시지 큐는 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고, Queue 에 넣어 두기 때문에 나중에 처리가 가능하다.
- 기존 동기화 방식은 많은 메시지(데이터)가 전송될 경우 병목현상이 생길 수 있고, 뒤에 들어오는 요청에 대한 응답이 지연될 수 있다.
낮은 결합도(Decoupling)
- Producer 와 Consumer 가 독립적으로 행동함으로써 서비스 간 결합도가 낮아진다.
확장성(Scalable)
- 독립적으로 구성됨에 따라 Producer 와 Consumer 가 원하는 대로 확장이 가능하다.
탄력성(Resilience)
- Consumer 서비스가 다운(중지)되더라도 MQ의 어플리케이션이 중단되는 것은 아니다.
- 메시지는 메세지 큐에 남아 있고, Consumer 서비스가 재시작이 되면 추가 설정이나 작업 수행 없이 메세지를 처리할 수 있다.
보장성(Guarantees)
- 메세지 큐는 보관되는 모든 메시지가 결국 Consumer 에게 전달된다는 일반적인 보장을 제공한다.
- 단점
- Queue 가 가득 차서 더는 Queue 에 메시지를 저장할 수 없는 상황에는 메세지를 다른 곳에 보존하거나 버려지게 된다.
- 큐를 운영하기 위한 추가적인 자원이 필요하다.
- 큐에 들어가고 나오는 과정에서 피할 수 없는 오버헤드가 발생할 수 있다.
참고
- https://heodolf.tistory.com/49
- https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/
'Tool, 이론 및 기타 > 이론' 카테고리의 다른 글
| sync, async, blocking, non-blocking 정리 (2) | 2023.02.05 |
|---|---|
| Entity vs DTO vs VO 개념 및 차이점 정리(with. 역할 분리) (0) | 2022.10.18 |
| [Nexacro] 넥사크로 메모장 (0) | 2022.06.01 |
| [금융 IT] 마이데이터(MyData)란? (0) | 2022.06.01 |
| [금융 IT] EAI/FEP/MCI 용어 정리 (0) | 2022.06.01 |
