Message Queue를 사용하는 이유

AMQP를 구현한 MOM(Message Oriented Middleware) 시스템은 Kafka, RabbitMQ, Active MQ, AWS SQS, Java JMS 등이 존재한다.

시스템간의 연관이 많아지는 구조에서 (SOA, MSA 등) 서비스간 결합도를 낮추고, 비동기 요청, 성능, 안정성 등 여러가지 이점이 있어서 메시징 시스템을 사용하게 된다.

장/단점에 대해서 더 알아보면

서비스간의 결합성이 낮아지므로 각자의 비즈니스 로직에만 집중

메시지 처리 방식은 Message Broker에 위

각 서비스는 Client를 통해 메시지를 보내고 받기만 하면 됨

각 서비스는 비동기 방식으로 메시지를 보내기만 하면, Message Broker에서 순서 보장, 메시지 전송 보장등을 처리

메시징 시스템이 잠깐 다운되어도 각 서비스에는 직접적인 영향을 미치지 않음

단점

함수 호출, 공유메모리 사용 방식보다 메시징 시스템을 사용했을 때 호출 구간이 늘어나므로 네트워크 비용 발생

Message Broker 구축, 예를 들면 kafka 클러스터 구축에 필요한 금전, 인적자원에 대한 비용

어떨 때 사용하면 좋을까?

Failover
서버간 데이터를 주고 받을 때 항상 시스템 장애를 염두해두어야 하는데, 서버에 문제나 네트워크의 문제에 대한 Failover 할 수 있다.

서버 부하가 많은 작업
서버 부하가 많은 경우 원하는 만큼의 메세지를 소비하는 것이 가능하다.

부하 분산에 용이하다.
한 큐에 여러 consumer가 존재할 수 있기 때문에 부하 분산이 가능하고, Scaling 대응에 적합하다.

데이터 손실 방지
consumer가 broker에 처리 완료에 대한 응답을 주지 않은 경우(메세지 처리 중 문제가 발생하는 경우) 브로커는 큐에 메세지를 다시 넣어 처리할 수 있게 할 수 있음