메세지 큐(MQ)
MQ 란?
클라이언트의 요청을 큐에 저장하고 Consumer이 필요할 때 꺼내쓰는 아키텍처.
장점
- 비동기(Asynchronous)
- 메시지 큐는 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고, 큐에 넣어 두기 때문에 나중에 처리할 수 있다.
- 낮은 결합도(Decoupling)
- 생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다. 이는 확장성과 직결된다.
예시
만약
A,B1가 직접적으로 통신한다고 가정해보자. 그리고 이 때,B1를 확장해서 같은 기능을 수행하는B2을 만든다고 가정해보자. 이렇게 되면A는B2와 통신하는 로직을 새롭게 설정해야만 한다.반면
A와B1사이에 메세지 큐가 있다면,B2를B1이 속한 소비자 그룹에 추가하기만 하면 된다. 즉,A,B1를 수정하지 않아도 서비스를 확장할 수 있다!
- 생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다. 이는 확장성과 직결된다.
- 확장성(Scalable)
- 생산자 서비스 혹은 소비자 서비스를 원하는 대로 확장할 수 있기 때문에 확장성이 좋다.
- 탄력성(Resilience)
- 소비자 서비스가 다운되더라도 어플리케이션이 중단되는 것은 아니다. 메시지는 메시지 큐에 남아 있다. 소비자 서비스가 다시 시작될 때마다 추가 설정이나 작업을 수행하지 않고도 메시지 처리를 시작할 수 있다.
예시
카프카의 경우, 각각의 파티션은 소비자 별 최근 읽은 위치를 기록한다. 따라서 소비자 서비스가 다운 되더라도 마지막 읽은 위치부터 순서대로 진행할 수 있다.
- 소비자 서비스가 다운되더라도 어플리케이션이 중단되는 것은 아니다. 메시지는 메시지 큐에 남아 있다. 소비자 서비스가 다시 시작될 때마다 추가 설정이나 작업을 수행하지 않고도 메시지 처리를 시작할 수 있다.
- 보장성(Guarantees)
- 메시지 큐는 큐에 보관되는 모든 메시지가 결국 소비자 서비스에게 전달된다는 일반적인 보장을 제공한다.
단점
- 언제 메세지가 소비되는지 모르기때문에 즉각적인 서비스가 불가능하다.
Message Queue, MQ
What is MQ?
MQ is an architecture where client requests are stored in a queue and Consumers take them out when needed.
Advantages
- Asynchronous
- A message queue does not synchronously process storage and transmission of produced messages. It puts them into the queue, so they can be processed later.
- Decoupling
- Producer services and consumer services act independently, reducing coupling between services. This is directly related to scalability.
Example
Assume
AandB1communicate directly. Now assumeB2, which performs the same function, is created by scalingB1. In that case,Aneeds to newly configure logic to communicate withB2.But if there is a message queue between
AandB1, you only need to addB2to the consumer group thatB1belongs to. In other words, the service can be scaled without modifyingAorB1.
- Producer services and consumer services act independently, reducing coupling between services. This is directly related to scalability.
- Scalable
- Scalability is good because producer services or consumer services can be expanded as needed.
- Resilience
- Even if a consumer service goes down, the application itself does not stop. Messages remain in the message queue. Whenever the consumer service starts again, it can start processing messages without additional setup or work.
Example
In Kafka, each partition records the latest read position for each consumer. So even if the consumer service goes down, it can continue sequentially from the last read position.
- Even if a consumer service goes down, the application itself does not stop. Messages remain in the message queue. Whenever the consumer service starts again, it can start processing messages without additional setup or work.
- Guarantees
- Message queues generally guarantee that all messages stored in the queue will eventually be delivered to the consumer service.
Disadvantage
- Since you do not know exactly when a message will be consumed, immediate service is not possible.