[Infra] MQ(Message Queue)

# Outline

- Message 란?

시스템에서 시스템으로 Processing되는 정보의 단위이다. 패킷, 프레임 등등 우리가 일종의 정보를 부르는 것과 같다.

- Queue(큐) 란?

2023.11.15 - [Computer Science/Data Structure] - [Data Structure] 선형 - 큐(Queue)

[Data Structure] 선형 - 큐(Queue)

-  Asynchronous(비동기) 란?

2024.01.22 - [Computer Science/Network] - [Network] Async & Sync (비동기와 동기)

[Network] Async & Sync (비동기와 동기)

-  Decoupling(분산)?

"비동조" 라고도 한다. 분산처리를 말한다.

- Middleware(미들웨어) 란?

운영체제와 Application 중간에서 조정과 중개역할을 수행하는 소프트웨어이다.(DB 등등)

3-Tier 클/서 구조에 미들웨어가 존재한다.

- MOM(Message Oriented Middleware) 란?

일반적으로 비동기 메시지 전달에 기초한 것을 말한다. 

• 보관: Message를 백업하여 네트워크 연결을 유지하지 않아도 된다.
• 라우팅: 직접 메시지를 라우팅하기 때문에 하나의 메시지를 여러 수신자에게 배포가 가능하다.(멀티)
• 변환: 송수신 측의 Request에 따라 메시지를 변환할 수 있다.(Message Broker)

- Message Broker 란?

Publisher(Producer)로 전달받은 메시지를 Message Broker를 Subscriber (Consumer) 로 전달해주는 중간 역할이며 응용 소프트웨어간에 메시지를 교환할 수 있게한다.

Message Broker 안에 Message Queue와 Topic이라는 메시지 그룹이 있다. 즉, Message Queue는 자료구조로 Message를 저장하는 것이고 Message Broker는 이러한 자료구조를 관리하는 별도의 시스템이다. 

---

# Detail

개괄적으로 용어를 정리하면서 MQ가 어떻게 동작하고 MOM인지 알았다. MQ와 DB를 같은 미들웨어 레벨에 두고 이해를 하면 더 공부하기가 쉬웠다.

 

RDBS는 우리가 조회,삽입,삭제와 같은 작업을 수행한다. 그러면 DB에서 관련 요청을 처리하게 된다. 이렇게 정리를 해보면 상당히 느리다.

• 데이터 입력받기
• 데이터 INSERT
• 100000만개의 튜플에서 원하는 값 SELECT하기

그렇다면 위에서 설명한  MQ를 사용해보면 어떨까?

먼저 Producer가 데이터를 생산하고 Message Broker에게 Consumer에게 전달하고 요청한다.

 

위가 끝이다. 생산하고, 보낸다. 조회의 과정이 빠져있다.

또한, 장점으로는 중간에 Processing과정에서 Process가 죽어버려도 MQ가 살아있기 때문에 데이터가 유실될 가능성은 적다.

 

많은 양의 데이터를 처리할때도 좋다. Decoupling을 통하여 분산 처리 환경을 만들 수 있다. 원하는 Topic에 구독을 해두고 Queue를 보고있다가 내가 원하는 Message가 왔을때 보내거나 가져올수 있다는 것이다.

 

# Message Life Cycle

1. Produecer는 Message를 Queue에 보내고 Message Queue는 Consumer가 사용할때까지 Message를 유지하고 보관
2. Consumer가 Message를 사용할 준비가 되면 Queue에서 Message를 사용. 단, Message를 Queue에서 즉시 삭제하지 않고 사용처리가 완료될때까지 lock한다.
3. Consumer가 메시지를 처리하고 Queue에서 Message를 삭제

# Fuctional

• At-least-once-processing
  • 메시지를 넣으면 무조건 최소 한번을 실행된다.
• Exactly-once processing
  • Producer가 중복된 Message를 올릴 수 있다. [MessageId]를 활용하여 중복제거역할을 수행한다.Consumer에게 1번만 메시지가 전달된다.
• Message ordering
  • Message 순서 설정을 하여 특정 서비스별로 활용을 용이하게 해준다.
  • Standard Queues: 순서를 보장하지는 않지만 높은 처리량을 보여준다.
  • FIFO Queues: 순서를 보장하며 제한된 처리량을 보여준다.
  • 두가지중 선택을 하려면 적합한 Queue를 선택해야한다.

# Advantage

• Message Queue는 안정적인(신뢰있는) Messaging 할 수있다.
  • Message Queue는 안정적으로 application component에 Message를 전달해준다. consumer가 메시지를 전달 받더라도 다른 Consumer에게 전달 할 수 있다.
  • Message는 오직 하나의 Consumer들에게만 사용된다. Message가 처리되고 있을때는 Message는 Lock처리되어있고 처리에 실패한다면 timeout을 주고 다른 Consumer에게 이를 던진다. 그러한 이유로 "At-least-once-processing" 동작할 수 있다.

• Message Queue는 workloads를 Decoupling한다.
  • Producer와 Consumer는 서로 상관하지 않는다. 즉, Message Queue에 Message를 Producer는 던지고 Consumer도 던지지만, 비동기로 동작하여 response를 기다리지 않는다.
  • Decoupling 함으로써 확장에 용이해진다.
• Message Queue는 messaging processing을 확장에 용이하다.
  • Load Balancing
    • 다수의 Consumers들에게 분산 저리가 가능하여 확장할 수 있다. 

      

  • Load leveling
    • 트래픽이 몰릴때 smooth하게 만들 수 있다.
• Message Queue는 크로스 플랫폼 통합을 할 수 있다.

 

# One-way Messaging

https://medium.com/event-driven-utopia/the-stuff-that-every-developer-should-know-about-message-queues -a9452ac9c9d

 

Point to Point Messaging이라고 하며, 비동기로 동작을 한다. 즉, Producer는 일단 Message Queue에 처리할 것을 생각하고 때려박는다.  Consumer는 Queue에서 Message를 검색하고 처리한다. Producer는 Consumer가 처리한 것에 대해서 응답을 기다리지 않는다. 즉, Producer는 Consumer 응답에 의존적이지 않다.

 

# Request - Response Messaging

https://medium.com/event-driven-utopia/the-stuff-that-every-developer-should-know-about-message-queues-a9452ac9c9d

 

one-way Messaging 패턴과 다르게 Consumer의 응답에 의존한다. 위의 MQ 패턴은 두개의 Queue를 통해 Channel을 형성하여 Consumer가 Queue의 Message를 잘 처리했는지 Reply Queue에 response Message를 전달한다.

response가 정상적인 time interval안에 도착하지 않으면 다시 Message를 보내거나 timeout 처리를 한다.

 

# Broadcast Messaging 

 

https://medium.com/event-driven-utopia/the-stuff-that-every-developer-should-know-about-message-queues-a9452ac9c9d

Pub-Sub messaging, fanout messaging 로 알려져있다. Producer는 queue에 메시지를 보내고 다수의 Consumer가 복사된 Message를 읽을 수 있다. Consumer는 Message를 놓고 경쟁할 필요가 없어진다는 것이다. 

 

"경쟁할 필요가 없다"라는 의미는 다수의 Consumers들은 Queue의 담긴 Message만 중요하고  Producer도 어떤 Message를 Consumer가 사용하는지 상관이 없어 의존적이지 않단 이야기 이다.

 

또한, 추가로 filter를 적용하여 Message를 필터링 할 수 있다. filtering된 Message는 Subscribe를 해둔 Consumers들에게 전달된다. DB랑 비교를 했을때 DB는 Query를 날려서 원하는 데이터를 조회해올 수 있는데 Message은 세세한 Control은 이루어지지 않더라도 Message를 Filter할 수 있다는 것이다.

---

# Summary

Middleware인 MQ에 대해서 알아보았다. DB같은 레벨에서 놓고 보니깐 공부하고 어려운 이론은 아니였던것 같다. MQ 솔루션을 JD를 확인하면 볼 수 있다. 카프카, Rabbit MQ등등

 

작성하다보니 Redis로 MQ를 만들 수 있을 거 같다는 생각을 들었다. 실무에서 실질적으로 사용을 안하고 AWS SQS를 공부하면서 MQ에 대해서 집고 넘어가자는 취지로 한 내용이라 이론위주의 학습이 Main이여서 부족한 느낌이 있다.

 

Spring으로 공부하면서 DB 과 MQ를 비교해보아야겠다.

 

# 출처

https://medium.com/event-driven-utopia/the-stuff-that-every-developer-should-know-about-message-queues-a9452ac9c9d

The Stuff That Every Developer Should Know About Message Queues