Apache Kafka나 RabbitMQ와 같이 MessageQueue를 활용하는 방법들이 있다.
MessageQueue란 무엇이고 어떤 패턴들이 존재할까? 알아보도록 하자
Message Queue
Message
Message란 무엇일까?
한 시스템에서 또 다른 시스템으로 process 되는 게 예상되어지는 information의 한 조각이다.
ex) Data payload, file, meta data 등등
Queue
Queue란?
FIFO(First in First Out)형식의 자료구조를 의미한다.
순차적으로 진행되는 Process에 사용
Message는 순차적으로 Queue에 들어오게 되고,
Queue는 순차적으로 들어오는 Message를 받아서 갖고 있다가 하나하나 순서에 맞게 전달한다.
MessageBroker란?
Message Broker는 queue가 정의되어 있는 third-party software라고 볼 수 있다.
Message Broker는 응용프로그램들 사이에서 Message를 전달하는 미들웨어 역할을 하게 된다.
다양한 유형의 Message를 다른 Queue로 라우팅 하기 위한 규칙들도 제공한다.
Message Broker는 Message를 제공하는 Producer와 소비하는 Consumer 사이에서 사용되는 API set가 있다.
즉 MessageQueue는 data structre로 Message를 보관하는 방법이고,
MessageBroker는 Queue를 관리하는 별도의 구성 요소라고 볼 수 있다.
MessageQueue로 보는 비동기 예시
Email이 훌륭한 예시가 되어준다.
Email의 경우 Email을 보낼 수 있지만 응답하는 것에 대해서는 지금 당장 할 수도 있고 이후에 처리할 수도 있다.
받은 편지함으로 들어가기 때문인데 이 받은 편지함을 보관된 메시지의 Queue라고 볼 수 있다.
원하는 시점에서 Message의 리스트를 확인할 수 있고 길어질수록 쌓이는 Message들이 있을 수 있다.
하지만 Email이 직장에서 사용하는 계정이라면 즉각적으로 확인하고 응답해야 되며 이와 같이 바로바로 확인하고 응답해야 되는 Email도 존재한다.
상대방이 받았는지, 응답을 하는지에 대한 걱정 없이 Message를 이동시킬 수 있으며(의존적이지 않음)
시나리오와 시점에 따라서 순서대로 축적되어있는 Queue를 활용하는 시점을 다르게 가져갈 수 있다.
Lifecycle of a message
들어가기 앞서.
Producer : Message를 전달하는 사람(or App or component)
Cosumer : Message를 소비하는 사람(or App or component)
Producer와 Consumer는 Role 즉 역할이 고정적이 아니므로 언제든 변경될 수 있다.
즉 한 번은 Producer 일 수 있고 한번은 Consumer일 수 도 있다.
생명 주기
- Producer는 message를 queue에 보낸다 Consumer는 현재 Message를 사용하거나 사용하지 못할 수도 있기 때문에 Queue는 Consumer가 사용할 수 있을 때까지 Message를 유지, 보관함
- Consumer는 message를 처리할 준비가 되면 queue에서 Message를 검색/사용함, queue는 message를 즉시 삭제하지 않으며 consumer가 처리를 완료할 때까지 유지함.
queue는 일시적으로 message를 다른 사용자가 참조하지 못하도록 lock을 걸게 됨. - Consumer가 message를 처리하고 queue에서 message가 삭제됨.
Messaging Pattern
One-way Messaging
- point-to-point messaging 이라고도 알려져 있음.
- producer는 consumer가 특정 시점에 message를 검색하고 처리할 것을 기대하고
Queue에 message를 보냄. - consumer는 queue에서 message를 검색하고 처리하며
여기서 producer는 consumer의 존재나 message가 어떻게 process 되는지 알지 못하며
consumer의 응답을 기다리지 않는다. 즉 Consumer의 응답에 의존적이지 않는다.
Request/response messaging
이 패턴의 경우에는 consumer가 response message를 보낼 별도의 message queue 형태의 communication channel이 필요함
- Producer는 Request Queue에 Message를 보낸 뒤 Reply Queue로부터 Consumer에 response가 나오기를 기대하며
Consumer는 message를 처리한 다음에 Reply Queue에 response message를 전달한다.
- 만약 response가 설정해 놓은 or 정상적인 time interval 안에 도착하지 않는다면 Producer는 두 가지를 선택할 수 있다.
- Message를 다시 보낸다
- timeout 처리를 해버린다
- 만약 response가 설정해 놓은 or 정상적인 time interval 안에 도착하지 않는다면 Producer는 두 가지를 선택할 수 있다.
Pub/Sub(Publish, Subscribe)
Producer는 message를 queue에 보내고 다수의 consumer는 copy 된 message를 load 할 수 있음.
consumer는 message에 대해서 경쟁하지 않는다.
오직 topic에만 관심이 있으며 message를 보낸 producer에 의존적이지 않는다.
producer 역시 어떤 consumer가 message 지를 소비했는지에 대해 관심이 없으며 의존적이지 않는다.
- 각각의 Consumer들은 특정한 Message attributes or value에 대해서 검사 확인하는 filter를 만들 수 있다.
- topic으로 전송된 message가 filter에서 설정한 값과 일치하는 Message의 경우
자동으로 subscription으로 fowarded 해주게 된다.- 여기서의 topic은 위 그림과 같이 Producer가 message를 보내는 queue의 역할을 하게 된다.
- Consumer는 Subscription에서 queue에서 message를 가져오듯 가져오게 된다.
Consumer들이 공통으로 알아야 하는 event들이 발생했을 때 사용되기가 좋음.
Message Queue의 특징
At-least-once processing
- 그 어떤 상황에서도 MessageQueue 인프라 내에서 Message는 일단 Queue에 보내지면 손실되었는지 Consumer에게 전달되었는지 확인을 한다.
- Consumer가 message를 process 하는 동안 message에 lock을 걸고 해당 consumer가 message를 정상 처리하지 못하는 경우 lock을 풀어서 다른 consumer 가 message에 접근할 수 있게 한다.
- Message Queue에 보관되는 모든 메시지는 결국 Consumer에게 한 번은 전달된다는 일반적인 보장을 제공한다.
Exactly-once processing
- Producer가 message를 queue에 보내는 도중 어떠한 network 상의 문제로 다운이 되고 다른 Producer가 이전 process를 이어서 한 경우 Message Queue는 동일한 message가 두 번 보내질 가능 성이 있다.
- Message Id를 기반으로 전달된 Message Id를 내부적으로 유지 관리하며 새로운 Message가 도착할 시
id를 확인하고 이미 전달된 경우 삭제하도록 처리할 수 있다.- Consumer에게 정확하게 한 번만 Message가 전달되도록 할 수 있다.
상황에 따른 Message ordering
- 대부분의 Message Queue는 두 가지 유형을 제공한다.
- 두 방식에 대해서는 자세한 부분은 추후 포스팅할 예정입니다.
여기서는 간단한 특징 정도만 확인하도록 하겠습니다.- standard queues
- Message 순서가 보장되지 않을 수도 있지만 아주 높은 처리량을 제공한다
- 순서가 보장되지 않아도 되나 처리량에서 이점을 얻을 수 있는 상황들에 사용
ex) 사용자 아바타, 이미지 크기 조정, 사용자 가입 정보 처리
- FIFO queues
- Message는 엄격하게 전송된 순서로 전달된다, 대신 처리량이 제한적이다.
- 순서가 반드시 보장되어야 하는 상황들에 사용이 가능하다
ex) 재고 조정, 계좌 거래
- standard queues
- 두 방식에 대해서는 자세한 부분은 추후 포스팅할 예정입니다.
Priority messaging
- Message Queue에서 Message가 추가되는 위치를 결정하기 위해 Message에 우선순위를 할당하여
우선순위가 더 높은 Message를 먼저 처리되도록 할 수 있다.
Message Queue의 이점
Decoupling
- Producer와 Consumer가 서로에게 의존적이지 않게 되므로 유연한 시스템 설계가 가능하다.
- Producer와 Consumer는 결국 Role 즉 역할이며 해당 역할을 할 수 있는
applicaltion 내 컴포넌트, msa 내에서 micro service 간 의존도가 떨어지게 된다.
Messaging Processing을 확장할 수 있다.
- 여러 Consumer에게 message process를 분산하여 (로드 밸런싱) 애플리케이션이 확장되고 처리량이 올라가더라도
부담을 줄일 수 있다. - Producer가 다수의 Cosumer에게 처리되는 많은 양의 Message를 Queue에 보내게 된다고 해도
Queue의 길이에 따라서 Message를 처리하는 Consumer를 추가해서 Scaling을 통해 처리량을 올릴 수 있다.- MessageQueue에 대기하는 Message들이 제거되어 짐에 따라 Consumer의 수는 다시 조절할 수 있다.
- 트래픽 급증(spike)을 완화하는 버퍼, 부하분산(로드 레벨링)의 역할을 할 수 있다.
출처 : https://learn.microsoft.com/ko-kr/azure/architecture/patterns/queue-based-load-leveling
- 특정 시간 특정 상황에 급작스럽게 여러 Producer가 보내는 Message burst, trafic spike로부터
Consumer를 보호할 수 있다. - Message Queue는 buffer 역할을 하며 Consumer가 System에 많은 리스소를 가져가지 않고 평소에 처리 속도로
Message를 점차적으로 배출할 수 있도록 한다. - 시간과 비용이 많이 드는 작업을 처리하기 위해 그때그때 Consumer를 추가할 필요가 없어진다.
플랫폼 통합
- 서로 다른 플랫폼에서 실행되는 구성요소를 통합 가능하다.
- 기술 이기 종성
Resilience
- Message Queue는 application 구성 요소 간 Message를 안정적으로 교환할 수 있다.
- Consumer가 실패하더라도 응답에 의존적이지 않기 때문에 Queue는 Message를 다른 Consumer에게 전달한다
DLQ(Dead Letter Queue)
- Consumer가 죽더라도 Message는 Queue에 남아 있게 되며 Consumer Service가 다시 시작될 때 추가 설정이나 작업을 수행하지 않고도 Message 처리가 가능하다
- DLQ는 전달되거나 처리될 수 없는 메시지를 보관하는 MessageQueue에 내장된 특수 Queue이다.
- 모든 Consumer는 Message를 DLQ에 넣을 수 있다.
- DLQ는 대부분의 경우 Queue에 검색될 때까지 Message를 유지한다.
Message expiration
- Queue가 Message를 보관하고 있을 시간제한을 둘 수 있다.
- 설정한 시간 내에 Consumer가 Message를 처리하지 않는다면 해당 Message는 DLQ에 넣게 된다
- Consumer가 처리하지 않은 Message들이 Queue에 무제한으로 쌓이는 것을 방지할 수 있다.
주의 사항
Poison Message
poison message는 형식이 잘못되었거나 예상하지 않은 정보가 포함되어 있어 처리할 수 없는 message이다
- Consumer는 예외를 throw 하고 실패할 수 있다
- Message는 Queue로 다시 돌아간다
- 또 다른 Consumer가 예외를 throw 한다 이과정이 반복된다
- 무한 루프
- CPU 사용량 빠르게 증가
- ㅜㅜ
poison message를 감지하고 빠르게 제거하는 것이 중요하다.
일반적으로 poison message는 DLQ에 들어가게 된다
Message Queue와 MessageQueue의 특징들, 이점들, Message를 전달하는 패턴들에 대해서 공부해봤습니다.
많은 양의 처리량을 처리할 수 있다는점, 확장에 용이한점, 원하는 시점에서 데이터 처리가 가능한점, 다양한 플랫폼과 연동이 가능한점, message 유실의 가능성이 매우 적다는점 등 상당한 장점이 있고 활용하기 위해 앞으로도 학습을 계속 이어가려고 합니다.
감사합니다.
참조
https://www.youtube.com/watch?v=xErwDaOc-Gs&ab_channel=IBMTechnology <what is a message queue?>
The Stuff That Every Developer Should Know About Message Queues
A primer on asynchronous messaging with message queues
medium.com
https://learn.microsoft.com/ko-kr/azure/architecture/patterns/queue-based-load-leveling
큐 기반 부하 평준화 패턴 - Azure Architecture Center
작업 그리고 그 작업이 일시적인 높은 부하를 부드럽게 처리하기 위해 호출하는 서비스 사이에서 버퍼 역할을 하는 큐를 사용합니다.
learn.microsoft.com
댓글