비동기 방식으로 메세지를 전달함 ex) Queue, Broadcast, Multicast 등
메세지를 통해 여러 분산되어 있는 시스템간의 Connector 역할로 결합성을 낮춤
메세지를 발행하는 Publisher (Producer), 소비하는 Subscribe (Consumer)로 구성되어 있음
메세지를 전달하는 과정에서 보관, 라우팅, 변환할 수 있다는 장점이 있음
보관 : 한 은행 시스템에서 고객의 송금 요청이 발생했지만, 수신 측 시스템이 일시적으로 다운된 경우에도 메시지 지향 미들웨어가 해당 요청을 큐에 저장해 둠. 수신 시스템이 복구되면 메시지가 자동으로 처리되어 송금이 완료됨.
라우팅 : 전자상거래 플랫폼에서 주문이 발생하면, 해당 주문 메시지는 여러 백엔드 시스템(예: 재고 관리, 결제 처리, 배송 시스템)으로 라우팅되어 각각의 시스템이 필요한 작업을 수행할 수 있음. 이 과정에서 메시지는 각 시스템의 요구에 맞게 변환되거나 필터링될 수도 있음.
변환 : 한 시스템에서 XML 형식으로 전달된 주문 메시지가, 다른 시스템에서는 JSON 형식으로 처리되어야 할 때, 메시지 지향 미들웨어는 이를 자동으로 변환하여 수신 측 시스템이 문제없이 처리할 수 있도록 도움. 이로 인해 시스템 간의 결합도가 낮아지고, 확장성이 향상됨.
* 미들웨어 : 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해주는 소프트웨어
메시지 큐(Message Queue)
Queue 라는 자료구조를 채택해서 메세지를 전달하는 시스템이며, 메세지 지향 미들웨어(MOM) 을 구현한 시스템
작은 데이터를 빈번하게 전송할 때, 사용함
MSA의 주요 목표인 독립성, 확장성, 그리고 유연한 통신을 지원하기 때문에 MSA(Microservice Architecture) 에서 아키텍처의 핵심적인 역할을 함
장점
비동기(Asynchronous): Queue에 넣어두기 때문에 나중에 처리할 수 있음
낮은결합도(Decoupling): 애플리케이션과 분리할 수 있음
탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않음
과잉(Redundancy): 실패 할 경우 재실행이 가능함
신뢰성(Guarantees): 작업이 처리된 걸 확인할 수 있음
확장성(Scalable): 다수의 프로세스들이 큐에 메시지를 보낼 수 있음
단점
큐가 가득 차서 더는 큐에 메시지를 저장할 수 없는 상황에는 메시지를 다른 곳에 보존하거나 버림
메시지 큐의 크기는 생각보다 작기 때문에 송신측이 수신측보다 빠르다면 문제가 자주 발생할 소지가 있음
사용하는 경우
서버 부하가 많은 작업
부하 분산
데이터 손실 방지
메시지 큐(Message Queue) 시스템
RabbitMQ
AMQP 프로토콜을 구현해 놓은 메세지 큐
처리 구조
Producer가 Broker로 메세지를 보냄
Broker내 Exchange에서 해당하는 Key에 맞게 Queue에 분배함(Binding)
해당 Queue를 구독하는 Consumer가 메세지를 소비함
AMQP(Advanced Message Queue Protocol)
Exchange : Producer 로 부터 전달받은 메세지를 어떤 메세지 큐로 전송할지 결정하는 장소 (라우팅 기능) Binding : Exchange 와 Queue 와의 관계 (특정 Exchange가 특정 Queue 에 메세지를 보내도록 정의함)
장점
유연하고 복잡한 라우팅이 가능
관리 UI 존재
거의 모든 언어와 운영체제를 지원
20kb/sec 정도의 속도
데이터 처리 보단, 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용
단점
메세지 큐 서버가 종료 후 재가동시 큐 내용은 모두 삭제됨 (데이터 손실 위험)
Producer와 Consumer의 결합도가 높음
ActiveMQ
JMS 스펙을 조금 더 사용하기 편리하게 구현한 오픈소스 메시지 브로커
RabbitMQ와 더불어 현재 대표적인 메시지 브로커로 사용되고 있음
Message Broker : 목적지에 안전하게 메세지를 건네주는 중개자 역할
Destination
Queue : 메세지가 전달되는 통로, 메세지를 받는 Consumer 가 다수일 때연결된 순서로 제공 (경합 o)
Topic : Queue와 비슷하지만, 메세지를 받는 Consumer 가 다수일 때 모두에게 제공 (경합 x)
장점
클러스터링 기능을 통해 여러 서버 간에 부하를 분산할 수 있어 대규모 트래픽을 처리하는 데 적합
메시지를 영구적으로 저장하고 복구할 수 있는 기능을 제공 (시스템 장애 발생 시에도 데이터 손실 없이 복구할 수 있도록 도움)
메시지 필터링, 우선순위 메시지, 트랜잭션 처리 등 다양한 고급 기능을 제공하여 애플리케이션의 요구에 맞게 조정할 수 있음
단점
Java 기반으로 동작하기 때문에, 특히 많은 수의 작은 메시지를 처리할 때 성능 저하가 발생할 수 있음
다양한 설정 옵션으로 인해 초기 설정 및 관리가 복잡할 수 있으며, 신규 사용자에게는 학습 곡선이 존재
대용량 데이터 처리에 특화된 솔루션이 아니며, Kafka와 같은 대규모 로그 처리에는 적합하지 않음
JMS (Java Message Service) - 메세지 큐 및 Publish - Subscribe 패턴과 같은 메세지 기반 통신을 추상화하고 표준화한 API (Java MOM 표준 API) - 다른 시스템의 프로그램이나 다른 프로그래밍 언어로 작성된 프로그램이 메시지를 통해 서로 조정할 수 있도록 함
Kafka
Linked-in 에서 개발한 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼
Pub-Sub 모델의 메시지 큐 형태로 동작하며 분산환경에 특화되어 있으며, Fortune 100개 기업 중 80% 이상이 Kafka를 사용함
RabbitMQ, ActiveMQ 와는 달리 이벤트 브로커임
메시지를 메모리에 저장하는 기존 메시징 시스템과는 달리 파일에 저장을 하는데 그로 인해 카프카를 재시작해도 메시지 유실 우려가 적음
- 기본 메시징 시스템(rabbitMQ, ActiveMQ)에서는 브로커(Broker)가 컨슈머(consumer)에게 메시지를 push해 주는 방식 - Kafka는 컨슈머(Consumer)가 브로커(Broker)로부터 메시지를 직접 가져가는 pull 방식으로 동작 →컨슈머는 자신의 처리 능력만큼의 메시지만 가져와 최적의 성능을 낼 수 있음
파일 시스템을 활용한 고성능 디자인 하드디스크는 메모리보다 수백배 느리지만 하드디스크의 순차적 읽기에 대한 성능은 메모리보다 크게 떨어지지 않음
대용량 분산 시스템이 필요한 경우 Kafka 구축, 그 외에는 Queue 기능에서 신뢰성과 안전성을 좀 더 보장하는 ActiveMQ 혹은 RabbitMQ을 사용
