브로커리스 아키텍처의 서비스는 메세지를 서로 직접 교환한다.
장점
- 송신자가 보낸 메시지가 브로커를 거쳐 수신자로 이동하는 것이 아닐, 송신자에서 수신자로 직접 전달되므로 네트워크 트래픽이 가볍고 지연 시간이 짧다.
- 메시지 브로커가 성능 병목점이나 SPOF(단일 정야좀)가 될 일이 없다.
- 메시지 브로커를 설정/관리할 필요가 없으므로 운영 복잡도가 낮다.
단점
- 서비스가 서로의 위치를 알고 있어야 하므로 서비스 디스커버리 메커니즘을 사용해야한다.
- 메시지 교환시 송신자/수신자 모두 실행중이어야 하므로 강ㅇ성이 떨어진다.
- 전달 보장같은 메커니즘을 구현하기가 어렵다.
메시지 브로커는 모든 메시지가 지나가는 중간 지점이다. 송신자가 메시지 브로커에 메시지를 쓰면 메시지 브로커는 메시지를 수신자에게 전달한다. 메시지 브로커의 가장 큰 장점은 송신자가 컨슈머의 네트워크 위치를 몰라도 된다는 점이다. 또 컨슈머가 메시지를 처리할 수 있을때 까지 메시지 브로커에 메시지를 버퍼링할 수도 있다.
장점
- 느슨한 결함: 클라이언트는 채널에 메세지를 보니는 식으로만 요청하면 된다. 서비스 인스턴스를 몰라도 되므로 디스커버리 매커니즘이 필요없다.
- 메시지 버퍼링: 메시지 브로커는 처리 가능한 시점까지 메시지를 버퍼링한다. HTTP같은 동기 요청/응답 프로토콜을 쓰면 교환이 일어나는 동안 클라이언트/서비스 모두 가동중이어야 하지만 메시징을 쓰면 컨슈머가 처리할 수 있을 때까지 그냥 큐에 메시지가 쌓이게 된다. 덕분에 수행이 지연되거나 서버가 잠시 불능 상태가 되어도, 다시 복구되면 요청을 다시 처리할 수 있다.
단점
- 성능 병목 가능성: 메시지 브로커가 성능 병목점이 될 위험이 있다. (하지만 다행이 요즘 메시지 브로커는, 대부분 확장이 잘 되도록 설계되어있어 문제가 줄어들었다.)
- 단일 장애점 가능성: 메시지 브로커는 가용성이 높아야 한다. 모든 중요한 메세지들이 모이는 메시지 브로커에서 데이터가 유실되거나 장애가 생기면, 큰 SPOF가 될 수 있다.
- 운영 복잡도: 메시징 시스템 역시 설치, 구성, 운영해야할 시스템 컴포넌트이기 때문에 운영 복잡도를 가중시킬 수 있다.
메시지 브로커로 자주 쓰이는 제품으로는 다음과 같은 것들이 있다. 각 소프트웨어마다 메시지 패널이 구현되어있는 방식이 조금씩 다르다.
| 메시지 브로커 | 점대점 채널 | 발행-구독 채널 |
|---|---|---|
| JMS | 큐 | 토픽 |
| 아파치 카프카 | 토픽 | 토픽 |
| AMQP 브로커(ex. RabbitMQ) | 익스체인지+큐 | 팬아웃 익스체인지, 컨슈머 개별 큐 |
| AWS 키네시스 | 스트림 | 스트림 |
| AWS SQS | 큐 | - |