[AZ-204] Azure Message Queue

게시 2025/01/10

9 분읽는 시간

Azure Message Queue에는 Storage Queue와 Service Bus Queue 두개가 존재한다.

Azure Service Bus를 사용해야할 때?

솔루션을 설계하는데 있어 Queue에서 Polling되지 않고도 메세지를 수신할 수 있는 경우, Queue의 FIFO를 보장해야하는 경우, 자동 중복 검색을 지원 해야하는 경우, 병렬 장기 실행 스트리밍을 실행하는 경우 Service Bus Queue를 사용할 수 있다.

Storage Queue를 사용하는 경우?

80GB보다 많은 메세지는 Queue에 저장해야한다. 또한 메세지 처리 진행률을 추적하고 메세지의 충돌 처리에 대해서는 Storage Queue가 장점을 가진다.

Azure Service Bus

Azure Service Bus란

Service Bub는 AP와 Service를 분리하는 목적으로 주로 사용된다. 메세지를 사용하여 서로 다른 AP와 통신한다. 주로 주문, 판매 같은 1:n 서비스에 있어 주로 사용되어진다.

주요 기능으로는 예약 배달, 순서를 지정 저장하는 메세지 세션, 중복 검색, 유후 상태에서 자동 삭제를 지정할 수 있다.

Azure Service Bus에서 Queue와 같은 FIFO를 보증하기 위해서는 메세지 세션을 설정해야한다.

Service Bus 계층

Standard : 가변적 처리량, 가변 대기시간, 256kb의 메세지 크기
Premium : 예측 가능한 성능과 고정된 가겨 책정. 최대 크기는 100mb

수신 모드

Service Bus가 메세지를 수신하는데 있어 두 가지 모드를 지정 가능하다

수신 및 삭제

Service Bus가 소비자로부터 요청을 받고 Service Bus는 이걸 사용됨으로 표시한다. 이는 구현이 간단하고 빠르지만 메세지가 손실된 위험이 있다.

피킹 잠금

소비자로부터 요청을 받으면 이 요청을 잠금(Peak)으로 되고 AP에 반환한다. 그리고 AP가 서비스를 처리하고 사용됨으로 표시(Compelete)한다. 만약 어떠한 요청이 발생해 AP에서 이용이 불가능하다면 Peak을 해제하고 다른 AP가 이를 이용할 수 있다. 또한 특정 잠금시간이 초과되도 Peak이 풀린다.

이는 메세지가 손실되지 않고 방지 될 수 있으며 실패할 경우 재처리가 가능하다

토픽 및 구독

일반적으로 Queue는 단일 소비자가 처리를 한다. 하지만 토픽 및 구독은 일대다 방식으로 각 게시자가 메제지에 토픽을 보내면 하나 이상의 구독자는 이에 대한 복사본을 수령한다.

이런 수령에 있어 추가 필터를 사용가능할 수 있다 → 이는 소비자가 직접 원본 토픽에게 메세지를 전달 받는것이 아니라는 것을 의미 한다.

보내는 기능 → 토픽

받는 기능 → 구독

이것은 부하 분산과 경쟁 소비자를 가능하게 한다.

추가 필터

구독 필터를 통해 메세지를 효율적으로 라우팅이 가능하다. 필터에 사용할 수 있는 유형은 SQL, Correlation, Boolean이 있다.

규칙 및 동작

특정 특성을 가진 메세지로 처리를 하기 위해서는 desired 속성이 있는 메세지를 찾아 특정 작업을 수행하도록 구독을 구성하면 된다.

구독은 이러한 모든 메세지 중 조건에 맞는 메세지만 가상 구독 큐에 복사를 한다. 이러한 동작을 필터 동작이라고 한다. Azure 토픽의 필터 조건에 사용되는 필터는 SQL, Boolean, Correlation이 있다.

Azure Service Bus의 구성

Azure Servuce Bus는 두가지 큰 구성 요소를 가지고 있는데 페이로드와 메타데이터이다.

페이로드는 메세지의 실제 내용으로 이진 데이터로 구성된다. 이는 Service Bus의 처리 영역이 아니며 Service Bus는 주로 메타데이터를 보는데 브로커속성(시스템 정의속성으로 주로 라우팅 정보), 사용자 속성(AP 정의값으로 키-값쌍 주문번호 - 중요도) 로 구성되어 있다.

라우팅 방식

Service Bus는 다양한 라우팅 방식을 지원한다.

단순 요청/회신

게시자(송신자)가 큐에 메세지는 보낸다. (보낼때 ReplyTo 속성에 회신받은 큐의 주소를 담는다._)
소비자(수신자)가 처리를 하는데 이때 어떤 작업의 처리를 한건지 알려줘야한다.
1. 최초로 메세지를 받을때 MessageID 라는 고유한 ID가 존재한다. (MessageId = 12345)
2. 소비자는 어떤 작업을 해야하는지를 알려주어하는데… 이때 CorrelatioID 에 어떤 작업을 했는지 회신한다. CorrelationID = 12345 로 어떤 요청의 응답인지 기록
게시게시자는 이걸 보고(CorrealationID) 소비자가 어떤 작업의 결과인지 알 수 있게 된다!

멀티캐스트 요청/회신

게시자가 요청을 여러 소비자에게 보낸다. 그리고 각 구독자가 메세지를 처리하고 회신한다.

멀티플렉싱

멀티캐스트와 비슷하지만 필터링을 통해 원하는 특성 소비자에게만 송신하는 방식 SessionId를 사용 하거나 회신 큐를 공유해서 사용 가능

페이로드 직렬화

페이로드는 이진화된 데이터로 전송되며 이는 Service Bus가 처리하지 않는다. ContentType 속성을 사용하여 이를 통해 AP 속성 값에 제안되는 형식을 MIME 콘텐트 형식으로 지정하여 페이로드를 설명할 수 있다.

Azure Storage

대량의 메세지를 저장하며 HTTP, HTTPS를 사용하여 메세지에 엑세스 할 수 있다. 이러한 큐의 크기는 64KB로 이러한 큐는 스토리지 계정 용량의 한계까지 수백만개의 메세지를 포함할 수 있다.

이러한 큐를 URL형식(https://myaccount.queue.core.windows.net/images-to-download)를 사용하여 제공가능하며 큐의 이름은 반드시 소문자여야한다.

TTL을 지정할 수 있으며 기본 TTL과 최대 TTL은 7일이다.

Azure Storage Queue는 기본적으로 FIFO를 보장하지 않은것을 명심하자

Azure, Azure 204