Message Queue?
Message Queue란 무엇일까?
Message Queue와 Message를 전달하는 패턴 그리고 특징들에 대해서
공부해보자!
Message Queueing
Message란 무엇일까?
one systemd에서 another system(appliacation)으로 process 되는 게 예상되는 지는 information 또는 Data의 한 조각
ex) Data payload, file, metaData ……
Queue
순차적으로 진행되는 process
Message는 순차적으로 queue에 들어오게 되고
Queue는 순차적으로 들어오는 Message를 받아서 갖고 있다가
하나하나 순서에 맞게 전달한다.
Message Broker?
queue가 정의되어 있는 software
메시지 송신자로부터 수신자에게 중계를 하는 역할 등 다양한 역할을 수행함.
ex) Kafka
- Email로 보는 message queue의 비동기 예시
Email은 자유롭게 보낼 수 있고 이후 응답하는 것에 대해서는 지금 당장 할 수도 있고 이후에 처리 할 수도 있다.
왜? why? 받은 편지함으로 들어가기 때문, 받은 편지함은 보관된 메세지의 Queue라고 볼 수 있다.
사용자는 원하는 시점에서 그 메시지 리스트를 확인할 수 있다.
길어지면 길어질수록 쌓여있는 메시지들이 있고
직장 내에서 사용하는 이메일과 같이 즉각적으로 확인하고 응답해야 되는 이메일도 존재한다.
시나리오와 시점에 따라서 순서대로 축적되어 있는 Queue를 활용하는 시점이 달라진다.
상대방이 받았는, 응답을 하는지에 대한 걱정 없이 해당 메시지를 이동시킬 수 있다.
Messaging Pattern
🚀 One-way Messaging
- Producer : 메시지를 전달하는 사람
- Consumer : 메시지를 소비하는 사람
- Producer와 Consumer는 Role 즉 역할이므로 고정적이 아니며 언제든 변경될 수 있음
한 번은 제공자일 수 있고 한 번은 소비자일 수 있음.
ex) web service 관련 개발을 끝내고 service 로직 결과에 대한 JSON object를
이후에 데이터베이스에 insert 시키기 위해 또는 다른 시스템에 insert 시키기 위해 queue에 넣어둡니다.
다른 service가 JSON을 받아서 처리해야 하고 response 보내줘야 하는 상황에 의존적이지 않고 Message 전달하는 게 보장된다.
Message를 다른 시스템에 보내고 응답을 받을 수 있다.
Producer는 Consumer의 존재나 Message가 어떻게 처리되고 있는지를 알지 못한다.
Consumer의 응답에 의존적이지 않는다.
그렇기 때문에 Consumer의 응답을 기다리지 않아도 된다.
point-to-point messaging Style 이라고 불리기도 함.
🚀 Request / Reply(Response)
-
이 패턴은 RPC(Remote Procedure Call)이라고도 불립니다.
-
Producer는 Request Queue에 Message를 보낸 뒤
-
Reply Queue로부터 Consumer에 response가 나오기를 기대한다.
-
만약 response가 정상적인 interval 기간 안에 도착하지 않는다면
Producer는 두 가지를 선택할 수 있다.- Message를 다시 보낸다
- timeout 처리를 해버린다
-
이 패턴의 경우에는 consumer가 response 메시지를 보낼 별도의 message queue 형태의 communication channel이 필요하다.
🚀 Pubsub(Publish, Subscribe)
-
producer는 message를 queue에 보내고 다수의 consumer는 같은 copy 된 message를 load 할 수 있습니다.
이 지점에서의 포인트는 이 패턴에서 consumer는 message에 대해서 경쟁하지 않는다. -
각각의 Consumer들은 Message attributes에 대해 구체적으로 특정한 values에 대해 검사, 확인하는 filter를 만들 수 있습니다.
-
topic으로 전송된 attribute values가 filter에서 설정한 값과 일치하는 Message의 경우 자동으로 subscription으로 forwarded 해준다.
-
Consumer는 Subscription에서 message를 queue에서 가져오듯 가져옵니다.
Consumer들이 공통으로 알아야 하는 event들이 발생했을 때 사용되기가 좋습니다.
publisher/subscriber model을 구현하는 데 있어서도 좋습니다.
message queues 일반적인 공통 기능들.
At-least-once processing
- 그 어떤 상황에서도 Message Queue 인프라 내에서 Message를 일단 Queue에 보낸다면 Message가 손실이 되었는지 Consumer에게 전달이 되었는지 확인함.
- Message Queue는 보관되는 모든 메시지를 결국 소비자에게 전달된다는 일반적 보장 제공
Exactly-once processing
- Message Queue에는 중복된 Message가 존재할 수 있다.
- 대부분의 Message Queue는 built In으로 중복 Message를 탐지, 제거하는 기능이 들어가 있다.
- Message Id를 기반으로 작동하는데 전달된 Message Id를 내부적으로 유지 관리하며 새로운 Message가 도착할 시 id를 확인하고 이미 전달된 경우 삭제한다.
- 이런 과정을 거치면서 Consumer에게 정확하게 한 번만 Message가 전달된다.
Message ordering
- 금융 서비스, 전자상거래, 데이터베이스 테이블 업데이트와 같은 경우에 특정 순서로 Message를 사용하는 경우 가 존재한다.
- 대부분의 Message Queue는 두 가지 유형을 제공한다.
- standard queues
- 메시지 순서가 보장되지 않을 수도 있지만 높은 처리량을 제공
- ex) 사용자 아바타, 이미지 크기 조정, 사용자 가입 정보 처리
- FIFO queues
- 메시지는 전송된 순서로 전달됨, 제한된 처리량을 제공
- ex) 재고 조정, 계좌 거래
- standard queues
Priority messaging
- Message Queue에서 Message가 추가되는 위치를 결정하기 위해 Message에 우선순위를 할당하여 우선순위가 더 높은 Message가 먼저 처리되도록 할 수 있다.
message queue를 사용하는 이점
Scalable message processing
- 분리된 애플리케이션에 대해서 확장성을 보장할 수 있다.
- Producer와 Consumer 간 서비스를 확장하는데 무리가 없다.
- Message Queue는 여러 Consumer에게 Processing을 분산시켜서 전체 처리량을 향상시킨다,
- 로드 밸런싱과 부하 분산
- Producer가 다수의 Consumer에게 처리되는 많은 양의 Message를 Queue에 보내는 환경이 있을 수 있다,
- queue의 길이가 길어진다면 Message 처리를 하는 Consumer를 동적으로 추가해서 sacling 할 수 있다.
- Message Queue에 대기하는 Message들이 제거됨에 따라 Consumer는 삭제할 수 있다.
- Consumer를 독립적인 다른 서버에서 실행하여 부하를 분산할 수 있음
- 트래픽 급증(spike)을 완화하는 버퍼, 부하 분산 역할(Load Leveling)을 한다.
출처 : https://learn.microsoft.com/ko-kr/azure/architecture/patterns/queue-based-load-leveling
- Message Queue는 갑작스럽게 여러 Producer가 보내는 Message burst, trafic spike로부터 Consumer를 보호할 수 있다.
- 위에 그림을 보면 Message Queue는 buffer 역할을 하며 Consumer가 System에 stress를 주지 않고 평소에 진행하던 스피드로 Message를 점차적으로 배출할 수 있도록 한다.
- 시간과 비용이 많이 드는 작업을 처리하기 위해 Consumer를 추가할 필요가 없다.
cross-platform integration
- 서로 다른 플랫폼에서 실행되는 구성요소를 통합 가능
- 언어의 이기종성
Decoupling
- Producer와 Consumer 간 결합도가 낮아짐
Resilience
- Message Queue를 사용하면 application 구성 요소 간 Message를 안정적으로 교환할 수 있음.
- Consumer가 실패하더라도 Queue는 Message를 다른 Consumer에게 전달함.
- Consumer의 응답에 의존적이지 않음
DLQ(Dead Letter Queue)
- Consumer가 죽어도 Message는 Queue에 남아있게 됨
Consumer Service가 다시 시작될 때 추가 설정이나 작업을 수행하지 않고도 Message 처리 가능 - DLQ는 전달되거나 처리될 수 없는 메시지를 보관하는 Message Queue에 내장된 특수 Queue
- Message Queue 자체, 모든 Consumer는 Message를 DLQ에 넣을 수 있음.
- DLQ는 대부분의 경우 Queue에서 검색될 때까지 Message를 유지함.
Message expiration(Time-bound message processing)
- Consumer가 Message를 사용할 때 Queue는 다른 소비자가 사용할 수 없도록 시간제한을 걸어 메시지를 잠금.
잠금 기간 동안 메시지를 삭제하지 못하면 다른 Consumer가 Message를 사용 가능. - Consumer가 Message를 처리하는 동안 실패하면 Queue는 다른 Consumer가 Message를 검색하고 처리할 수 있도록 Message에 대한 잠금을 해제하여 Message가 최소 한 번은 처리되도록 함.
- ex) 2시간만 Message 처리를 할 수 있도록 한다면 시간이 만료되면 폐기되고 Message Queue는 일반적으로 만료된 Message를 DLQ에 넣음
😨 Warning
☠️ Poison message
poison message는 형식이 잘못되었거나 예상하지 않은 정보가 포함되어 있어 처리할 수 없는 메시지입니다.
- Consumer는 예외를 throw 하고 실패할 수 있음
- Message는 다시 Queue로 돌아감
- 또 다른 Consumer가 예외를 throw 하고 이 과정이 반복됨
- 무한 루프
- CPU 사용량 폭증
- 사망
- poison message를 감지하고 빠르게 제거하는것 이 중요함
- 일반적으로 poison message는 DLQ에 들어가게 됨
참조
What is a Message Queue?
The Stuff That Every Developer Should Know About Message Queues
큐 기반 부하 평준화 패턴 - Azure Architecture Center
