참고
메세지 브로커
NOTE
서비스 - 응용 프로그램이 메시지를 사용하여 서로 통신할 수 있도록하는 소프트웨어!
•
생산자(Publishers)
◦
메시지 전송을 담당하는 애플리케이션
•
구독자(Subscribers)
◦
메시지 브로커에서 대기 중인 메시지를 소비하는 엔드포인트
•
Queue/Topic
◦
파일 시스템의 폴더
◦
메시지 브로커는 이를 사용하여 메시지를 저장한다.
P2P(Point-to-Point) 메시징 모델
NOTE
메시지의 발신자/수신자 사이에 일대일 관계가 설정된다!
지점간 메시징 (1대1 매칭)
•
각 메시지는 한번만 전송되고 소비된다.
•
급여 및 금융 거래처리가 대표적인 예시 (각 지불이 한번만 발생해야함)
PUB/SUB 메시징 모델
NOTE
해당 주제를 구독하는 모든 엔드포인트에 배포된다
발행/구독 모델
•
메시지 발신자는 수신자가 누군지에 대해서 모른다.
•
애플리케이션이 서로 간에 종속성이 적은 이벤트 기반 아키텍쳐 시스템을 구현할 수 있다.
메시지 브로커 VS API
NOTE
동기식 통신(Rest)와 비동기 통신(MQ)를 비교해본다!
REST → 동기식 통신을 사용해서 응답을 기다려야 한다.
MQ → 비동기 통신을 사용해서 응답을 기다릴 필요가 없다.
동기식 통신의 문제점
- 티켓을 구매하기위해 결제하고 확인하고… 해당 작업동안 사용자가 대기해야함.
•
REST를 사용하는 경우 동기식 통신을 사용하게 된다.
◦
메시지를 받는 소비자가 사용할 수 없는 경우 응답을 기다리는 동안 중지됨
◦
두 서비스 모두 장애 조치 및 오류 처리 로직이 설정되야 한다.
•
MQ를 사용하는 경우 비동기 통신을 사용하게 된다.
◦
PUB가 SUB의 응답을 기다릴 필요가 없다.
◦
이를 통해 시스템의 내결함성과 견고성이 향상된다.
메세지 브로커 VS 이벤트 스트리밍 플랫폼
NOTE
이벤트 스트리밍 플랫폼(PUB/SUB 패턴만 지원), MQ(다양한 패턴 지원)
MQ가 다양한 패턴을 지원해줌!
•
이벤트 스트리밍 서비스 전달을 보장하거나 메시지를 수신한 구독자를 추적할 수 없다.
•
토픽은 여러 이벤트 생산자와 소비자가 한 번에 존재할 수 있도록하여 서비스를 쉽게 확장할 수 있다.
메시지 브로커 이점
NOTE
주문을 하고 응답을 기다릴 필요없이 완료를 반환해줌
각 서비스를 분리할 수 있음
•
동시에 실행되지 않을 수 있는 서비스간 통신 제공
◦
PUB/SUB의 활성 여부에 관계없이 메시지 브로커만 있으면 된다.
•
비동기 처리를 도입하여 시스템 성능을 개선했다.
◦
사용량이 많은 작업을 별도의 프로세스에 분산할 수 있다.
•
메시지 전송을 보장하여 신뢰성을 높였다.
◦
메시지 브로커는 재전송 매커니즘을 가진다.
메시지 브로커 단점
NOTE
•
시스템 복잡성 증가
◦
비동기 처리를 사용함에 따라 시스템이 복잡해진다.
◦
전체 아키텍쳐의 새로운 요소가 생기게된다.
◦
구성 요소간의 네트워크 유지나 보안 문제등 고려할 사항이 늘어난다.
•
디버깅이 어려워진다.
◦
메시지 브로커를 사용하게 되면, 알람을 받지 못하게될때 실패 원인을 찾기 어려울 수 있다.
Message Queue vs Message Broekr
NOTE
•
Message Queue (발행/소비되는 데이터 저장)
◦
queue를 사용해 데이터의 전송, 수신 저장하는 어플리케이션들의 통신에 책임을 가진다.
◦
message queue를 통해 데이터가 전달되지만, 내용을 모른다.
•
Message Broker (message queue를 관리)
◦
message queue의 사용을 상속하는 매커니즘
◦
관리되는 데이터들의 정보를 알고 있다.
언제 메시지 브로커를 사용하는가?
NOTE
•
장기 실행 작업 및 중요한 API
•
마이크로 서비스
•
트랜잭션 시스템
메세지 브로커의 에
NOTE
•
RabbitMQ
•
Amazon MQ
•
Apache Kafka
•
Redis
•
Amazon SNS