이 문서에서는 다양한 유형의 메시지와 메시징 인프라에 참여하는 엔터티에 대해 설명합니다. 각 메시지 유형의 요구 사항에 따라 이 문서에서는 Azure 메시징 서비스를 권장합니다. 옵션에는 Azure Service Bus 메시징, Azure Event Grid 및 Azure Event Hubs가 포함됩니다. 제품 비교는 메시징 서비스 비교를 참조 하세요.
아키텍처 수준에서 메시지는 다른 엔터티(소비자)가 인식하고 그에 따라 작동할 수 있도록 정보를 배포하기 위해 엔터티(생산자)가 만든 데이터그램입니다. 생산자와 소비자는 중간 엔터티(메시지 broker)를 통해 직접 또는 선택적으로 통신할 수 있습니다. 이 문서에서는 메시지 broker를 사용하는 비동기 메시징에 중점을 둡니다.
메시지를 두 개의 기본 범주로 분류할 수 있습니다. 생산자가 소비자의 작업을 예상하는 경우 해당 메시지는 명령입니다. 메시지가 동작이 수행되었음을 소비자에게 알릴 경우 메시지는 이벤트입니다.
명령
생산자는 소비자가 비즈니스 트랜잭션 범위 내에서 작업을 수행할 의도로 명령을 보냅니다.
명령은 값이 높은 메시지이며 한 번 이상 전달되어야 합니다. 명령이 손실되면 전체 비즈니스 트랜잭션이 실패할 수 있습니다. 또한 명령을 두 번 이상 처리하면 안 됩니다. 이렇게 하면 잘못된 트랜잭션이 발생할 수 있습니다. 고객이 중복 주문을 받거나 두 번 청구될 수 있습니다.
명령은 다중 단계 비즈니스 트랜잭션의 워크플로를 관리하는 데 자주 사용됩니다. 생산자는 비즈니스 논리에 따라 소비자가 메시지를 승인하고 작업 결과를 보고할 것으로 예상할 수 있습니다. 해당 결과에 따라 생산자는 적절한 작업 과정을 선택할 수 있습니다.
이벤트
이벤트는 생산자가 사실을 알리기 위해 제기하는 메시지의 한 유형입니다.
생산자(이 컨텍스트에서 게시자라고 함)는 이벤트가 어떤 작업도 발생한다는 기대가 없습니다.
관심 있는 소비자는 구독하고, 이벤트를 수신 대기하고, 소비 시나리오에 따라 작업을 수행할 수 있습니다. 이벤트에는 구독자가 여러 명이 있거나 구독자가 전혀 없을 수 있습니다. 서로 다른 두 구독자는 서로 다른 동작으로 이벤트에 반응할 수 있으며 서로를 인식하지 못할 수 있습니다.
생산자와 소비자는 느슨하게 결합되고 독립적으로 관리됩니다. 생산자는 소비자가 이벤트를 생산자에게 다시 승인할 것으로 기대하지 않습니다. 이벤트에 더 이상 관심이 없는 소비자는 구독을 취소할 수 있으므로 생산자나 시스템의 전반적인 기능에 영향을 주지 않고 파이프라인에서 소비자를 제거합니다.
이벤트 범주는 두 가지입니다.
프로듀서는 별개의 사실을 알리기 위해 이벤트를 발생합니다. 일반적인 사용 사례는 이벤트 알림입니다. 예를 들어 Azure Resource Manager는 리소스를 만들거나, 수정하거나, 삭제할 때 이벤트를 발생합니다. 이러한 이벤트의 구독자는 경고 이메일을 보내는 논리 앱일 수 있습니다.
생산자는 일정 기간 동안 관련 이벤트를 시퀀스 또는 이벤트 스트림으로 발생시킵니다. 일반적으로 스트림은 통계 평가를 위해 사용됩니다. 평가는 임시 창 내에서 또는 이벤트가 도착할 때 발생할 수 있습니다. 원격 분석은 일반적인 사용 사례입니다(예: 시스템의 상태 및 부하 모니터링). 또 다른 경우는 IoT 디바이스의 이벤트 스트리밍입니다.
이벤트 메시징을 구현하는 일반적인 패턴은 게시자-구독자 패턴입니다.
메시지 broker의 역할 및 이점
중간 메시지 브로커는 생산자에서 소비자로 메시지를 이동하는 기능을 제공하며 더 많은 이점을 제공할 수 있습니다.
분리
메시지 broker는 각각 메시지를 생성하고 사용하는 논리에서 생산자를 소비자와 분리합니다. 복잡한 워크플로에서 broker는 비즈니스 작업을 분리하도록 장려하고 워크플로를 조정하는 데 도움을 줄 수 있습니다.
예를 들어 단일 비즈니스 트랜잭션에는 비즈니스 논리 시퀀스에서 수행되는 고유한 작업이 필요합니다. 생산자는 소비자에게 작업을 시작하도록 알리는 명령을 실행합니다. 소비자는 생산자에 대한 응답을 정렬하기 위해 예약된 별도의 큐에 있는 메시지를 확인합니다. 응답을 받은 후에만 생산자는 시퀀스에서 다음 작업을 시작하는 새 메시지를 보냅니다. 다른 소비자가 해당 메시지를 처리하고 완료 메시지를 응답 큐로 보냅니다. 서비스는 메시징을 사용하여 트랜잭션 워크플로를 조정합니다.
메시지 broker는 임시 분리를 제공합니다. 생산자와 소비자는 동시에 실행할 필요가 없습니다. 생산자는 소비자의 가용성에 관계없이 메시지 broker에 메시지를 보낼 수 있습니다. 반대로 소비자는 생산자의 가용성에 의해 제한되지 않습니다.
예를 들어 웹앱의 사용자 인터페이스는 메시지를 생성하고 큐를 메시지 broker로 사용합니다. 소비자가 준비되면 큐에서 메시지를 검색하고 작업을 수행할 수 있습니다. 임시 분리는 사용자 인터페이스가 응답성을 유지하는 데 도움이 됩니다. 메시지가 비동기적으로 처리되는 동안에는 차단되지 않습니다.
특정 작업은 완료하는 데 시간이 오래 걸릴 수 있습니다. 명령을 실행한 후 생산자는 소비자가 명령을 완료할 때까지 기다릴 필요가 없습니다. 메시지 broker는 메시지를 비동기식으로 처리하는 데 도움이 됩니다.
부하 분산
생산자는 많은 소비자가 서비스하는 많은 메시지를 게시할 수 있습니다. 메시지 broker를 사용하여 서버 간에 처리를 분산하고 처리량을 개선합니다. 소비자는 다른 서버에서 실행하여 부하를 분산할 수 있습니다. 소비자를 동적으로 추가하여 필요에 따라 시스템을 스케일 아웃하거나 제거할 수 있습니다.
경쟁 소비자 패턴은 여러 메시지를 동시에 처리하여 처리량을 최적화하고 확장성 및 가용성을 개선하며 워크로드의 균형을 맞추는 방법을 설명합니다.
로드 평준화
생산자 또는 생산자 그룹이 생성한 메시지의 볼륨은 가변적일 수 있습니다. 경우에 따라 대량의 메시지 급증이 발생할 수 있습니다. 이 작업을 처리하기 위해 소비자를 추가하는 대신 메시지 broker는 버퍼 역할을 할 수 있으며, 소비자는 시스템에 스트레스를 주지 않고 자신의 속도로 메시지를 점진적으로 드레이닝합니다.
큐 기반 부하 평준화 패턴은 자세한 정보를 제공합니다.
신뢰할 수 있는 메시징
메시지 broker는 생산자와 소비자 간의 통신이 실패하더라도 메시지가 손실되지 않도록 합니다. 생산자는 메시지 broker에 메시지를 게시할 수 있으며, 소비자는 통신이 다시 설정될 때 메시지를 검색할 수 있습니다. 생산자는 메시지 broke와의 연결이 끊어지지 않는 한 차단되지 않습니다.
복원력 있는 메시징
메시지 broker는 시스템의 소비자에게 복원력을 추가할 수 있습니다. 소비자가 메시지를 처리하는 동안 실패하면 소비자의 다른 인스턴스가 해당 메시지를 처리할 수 있습니다. 메시지가 broker에 유지되므로 재처리가 가능합니다.
메시지 broker를 위한 기술 선택
Azure는 다양한 기능을 갖춘 여러 메시지 broker 서비스를 제공합니다. 서비스를 선택하기 전에 메시지의 의도와 요구 사항을 결정합니다.
Azure Service Bus 메시징
Azure Service Bus 메시징 큐는 생산자에서 소비자로 명령을 전송하는 데 적합합니다. 다음과 같은 몇 가지 고려 사항이 있습니다.
끌어오기 모델
Service Bus 큐의 소비자는 Service Bus를 지속적으로 폴링하여 새 메시지를 사용할 수 있는지 확인합니다. 클라이언트 SDK 및 Service Bus용 Azure Functions 트리거는 해당 모델을 추상화합니다. 새 메시지를 사용할 수 있으면 소비자의 콜백이 호출되고 메시지가 소비자에게 전송됩니다.
보장된 배달
Service Bus를 사용하면 소비자가 큐를 피킹하고 다른 소비자의 메시지를 잠글 수 있습니다.
메시지의 처리 상태 보고하는 것은 소비자의 책임입니다. 소비자가 메시지를 사용한 것으로 표시하는 경우에만 Service Bus는 큐에서 메시지를 제거합니다. 오류, 시간 제한 또는 충돌이 발생하는 경우 Service Bus는 다른 소비자가 메시지를 검색할 수 있도록 메시지의 잠금을 해제합니다. 이렇게 하면 메시지가 전송 중 손실되지 않습니다.
생산자가 실수로 동일한 메시지를 두 번 보낼 수 있습니다. 예를 들어 메시지를 보낸 후 생산자 인스턴스가 실패합니다. 다른 생산자는 원래 인스턴스를 대체하고 메시지를 다시 보냅니다. Azure Service Bus 큐는 중복 메시지를 검색하고 제거하는 기본 제공 중복 제거 기능을 제공합니다. 메시지가 두 번 배달될 가능성은 여전히 있습니다. 예를 들어 처리하는 동안 소비자가 실패하면 메시지가 큐로 반환되고 동일하거나 다른 소비자에 의해 검색됩니다. 작업이 반복되더라도 시스템 상태가 변경되지 않도록 소비자의 메시지 처리 논리는 idempotent여야 합니다.
메시지 정렬
소비자가 메시지를 보낸 순서대로 받으려면 Service Bus 큐는 세션을 사용하여 FIFO(선점) 주문 배달을 보장합니다. 세션에 하나 이상의 메시지가 있을 수 있습니다. 메시지는 SessionId 속성과 상관 관계가 있습니다. 세션의 일부인 메시지는 만료되지 않습니다. 세션은 다른 소비자가 메시지를 처리하지 못하도록 소비자에 대해 잠글 수 있습니다.
자세한 내용은 메시지 세션을 참조 하세요.
메시지 지속성
Service Bus 큐는 임시 분리를 지원합니다. 소비자를 사용할 수 없거나 메시지를 처리할 수 없는 경우에도 큐에 남아 있습니다.
장기 실행 트랜잭션의 검사점
비즈니스 트랜잭션은 오랫동안 실행할 수 있습니다. 트랜잭션의 각 작업에는 여러 메시지가 있을 수 있습니다. 검사점 지정을 사용하여 워크플로를 조정하고 트랜잭션이 실패할 경우 복원력을 제공합니다.
Service Bus 큐는 세션 상태 기능을 통해 검사점 지정을 허용합니다. 상태 정보는 세션에 속하는 메시지에 대해 큐(SetState)에 증분 방식으로 기록됩니다. 예를 들어 소비자는 경우에 따라 상태(GetState)를 확인하여 진행률을 추적할 수 있습니다. 소비자가 실패하면 다른 소비자는 상태 정보를 사용하여 세션을 다시 시작할 수 있는 마지막으로 알려진 검사점을 확인할 수 있습니다.
DLQ(배달하지 못한 편지 큐)
Service Bus 큐에는 배달하거나 처리할 수 없는 메시지를 보관하는 DLQ(배달하지 못한 편지 큐)라는 기본 하위 큐가 있습니다. Service Bus 또는 소비자의 메시지 처리 논리는 DLQ에 메시지를 추가할 수 있습니다. DLQ는 큐에서 검색될 때까지 메시지를 유지합니다.
다음은 메시지가 DLQ에 있을 수 있는 경우의 예입니다.
포이즌 메시지는 형식이 잘못되었거나 예기치 않은 정보를 포함하기 때문에 처리할 수 없는 메시지입니다. Service Bus 큐에서 큐의 MaxDeliveryCount 속성을 설정하여 포이즌 메시지를 검색할 수 있습니다. 동일한 메시지를 받은 횟수가 해당 속성 값을 초과하면 Service Bus는 메시지를 DLQ로 이동합니다.
메시지가 기간 내에 처리되지 않으면 더 이상 관련이 없을 수 있습니다. Service Bus 큐를 사용하면 생산자가 Time-to-Live 특성이 있는 메시지를 게시할 수 있습니다. 메시지를 받기 전에 이 기간이 만료되면 메시지는 DLQ에 배치됩니다.
DLQ의 메시지를 검사하여 실패 이유를 확인합니다.
하이브리드 솔루션
Service Bus는 온-프레미스 시스템 및 클라우드 솔루션을 브리지합니다. 방화벽 제한으로 인해 온-프레미스 시스템에 도달하기 어려운 경우가 많습니다. 생산자와 소비자(온-프레미스 또는 클라우드일 수 있음)는 모두 Service Bus 큐 엔드포인트를 메시지의 픽업 및 드롭오프 위치로 사용할 수 있습니다.
메시징 브리지 패턴은 이러한 시나리오를 처리하는 또 다른 방법입니다.
토픽 및 구독
Service Bus는 Service Bus 토픽 및 구독을 통해 Publisher-Subscriber 패턴을 지원합니다.
이 기능은 생산자가 여러 소비자에게 메시지를 브로드캐스트하는 방법을 제공합니다. 토픽이 메시지를 받으면 모든 구독 소비자에게 전달됩니다. 필요에 따라 구독에는 소비자가 메시지의 하위 집합을 가져올 수 있는 필터 조건이 있을 수 있습니다. 각 소비자는 큐와 비슷한 방식으로 구독에서 메시지를 검색합니다.
자세한 내용은 Azure Service Bus 토픽을 참조하세요.
Azure Event Grid
불연속 이벤트에는 Azure Event Grid를 사용하는 것이 좋습니다. Event Grid는 Publisher-Subscriber 패턴을 따릅니다. 이벤트 원본이 이벤트를 트리거하면 Event Grid 토픽에 게시됩니다. 이러한 이벤트의 소비자는 이벤트를 처리할 이벤트 유형 및 이벤트 처리기를 지정하여 Event Grid 구독을 만듭니다. 구독자가 없으면 이벤트가 삭제됩니다. 각 이벤트에는 여러 구독이 있을 수 있습니다.
푸시 모델
Event Grid는 푸시 모델의 구독자에게 메시지를 전파합니다. 웹후크가 있는 Event Grid 구독이 있다고 가정합니다. 새 이벤트가 도착하면 Event Grid는 이벤트를 웹후크 엔드포인트에 게시합니다.
Azure와 통합
Azure 리소스에 대한 알림을 받으려면 Event Grid를 선택합니다. 많은 Azure 서비스는 기본 제공 Event Grid 토픽이 있는 이벤트 원본 역할을 합니다. Event Grid는 이벤트 처리기로 구성할 수 있는 다양한 Azure 서비스도 지원합니다. 선택한 이벤트 처리기로 이벤트를 라우팅하기 위해 해당 토픽을 구독하는 것은 쉽습니다. 예를 들어 Blob Storage를 만들거나 삭제할 때 Event Grid를 사용하여 Azure Function을 호출할 수 있습니다.
사용자 지정 토픽
Event Grid와 통합되지 않은 애플리케이션 또는 Azure 서비스에서 이벤트를 보내려는 경우 사용자 지정 Event Grid 토픽을 만듭니다.
예를 들어 전체 비즈니스 트랜잭션의 진행률을 보려면 참여하는 서비스가 개별 비즈니스 작업을 처리할 때 이벤트를 발생시키는 것이 좋습니다. 웹앱은 이러한 이벤트를 표시합니다. 이 작업을 수행하는 한 가지 방법은 사용자 지정 토픽을 만들고 HTTP WebHook을 통해 등록된 웹앱으로 구독을 추가하는 것입니다. 비즈니스 서비스가 사용자 지정 토픽에 이벤트를 보내면 Event Grid가 이벤트를 웹앱에 푸시합니다.
필터링된 이벤트
구독에서 필터를 지정하여 이벤트 하위 집합만 특정 이벤트 처리기로 라우팅하도록 Event Grid에 지시할 수 있습니다. 구독 스키마에서 필터를 지정합니다. 필터와 일치하는 값이 있는 토픽에 전송된 모든 이벤트는 해당 구독에 자동으로 전달됩니다.
예를 들어 다양한 형식의 콘텐츠가 Blob Storage에 업로드됩니다. 파일이 추가될 때마다 이벤트가 발생하고 Event Grid에 게시됩니다. 이벤트 구독에는 이벤트 처리기가 썸네일을 생성할 수 있도록 이미지에 대한 이벤트만 보내는 필터가 있을 수 있습니다.
필터링에 대한 자세한 내용은 Event Grid에 대한 필터 이벤트를 참조하세요.
높은 처리량
Event Grid는 지역별 초당 10,000,000개의 이벤트를 라우팅할 수 있습니다. 매월 처음 100,000개 작업은 무료입니다. 비용 고려 사항은 Event Grid의 비용은 얼마인가요?를 참조하세요.
복원력 있는 배달
이벤트에 대한 성공적인 배달이 명령만큼 중요하지는 않지만 이벤트 유형에 따라 어느 정도 보장이 필요할 수 있습니다. Event Grid는 다시 시도 정책, 만료 시간 및 배달 못한 편지와 같이 사용하도록 설정하고 사용자 지정할 수 있는 기능을 제공합니다. 자세한 내용은 Event Grid 메시지 배달 및 재시도를 참조하세요.
Event Grid의 재시도 프로세스는 복원력에 도움이 될 수 있지만 실패로부터 안전하지는 않습니다. 다시 시도 프로세스에서 Event Grid는 엔드포인트가 오랫동안 응답하지 않는 경우 메시지를 두 번 이상 배달하거나, 건너뛰거나, 일부 재시도를 지연시킬 수 있습니다. 자세한 내용은 다시 시도 일정을 참조 하세요.
배달 못한 편지를 사용하도록 설정하여 배달되지 않은 이벤트를 Blob Storage 계정에 유지할 수 있습니다. Blob Storage 엔드포인트에 메시지를 배달하는 데 지연이 있으며 해당 엔드포인트가 응답하지 않는 경우 Event Grid는 이벤트를 삭제합니다. 자세한 내용은 배달 못한 편지 위치 설정 및 다시 시도 정책을 참조하세요.
Azure Event Hubs
이벤트 스트림 을 사용하는 경우 Azure Event Hubs 가 권장되는 메시지 브로커입니다. 기본적으로 짧은 대기 시간으로 대량의 데이터를 수신할 수 있는 큰 버퍼입니다. 수신된 데이터는 동시 작업을 통해 빠르게 읽을 수 있습니다. 실시간 분석 공급자를 사용하여 수신된 데이터를 변환할 수 있습니다. Event Hubs는 스토리지 계정에 이벤트를 저장하는 기능도 제공합니다.
빠른 수집
Event Hubs는 초당 수백만 개의 이벤트 수집할 수 있습니다. 이벤트는 스트림에만 추가되고 시간별로 정렬됩니다.
끌어오기 모델
Event Grid와 마찬가지로 Event Hubs는 Publisher-Subscriber 기능도 제공합니다. Event Grid와 Event Hubs의 주요 차이점은 구독자가 이벤트 데이터를 사용할 수 있도록 하는 방법에 있습니다. Event Grid는 수집된 데이터를 구독자에게 푸시하는 반면 Event Hubs는 데이터를 끌어오기 모델에서 사용할 수 있도록 합니다. 이벤트가 수신되면 Event Hubs는 이를 스트림에 추가합니다. 구독자는 커서를 관리하고, 스트림에서 앞뒤로 이동하고, 시간 오프셋을 선택하고, 해당 속도로 시퀀스를 재생할 수 있습니다.
스트림 프로세서는 변환 및 통계 분석을 위해 Event Hubs에서 데이터를 가져오는 구독자입니다. 시간 경과에 따른 집계 또는 변칙 검색과 같은 복잡한 처리를 위해 Azure Stream Analytics 및 Apache Spark를 사용합니다.
파티션당 각 이벤트에 대해 작업하려면 이벤트 프로세서 호스트를 사용하거나 Azure Logic Apps와 같은 기본 제공 커넥터를 사용하여 변환 논리를 제공하여 데이터를 끌어올 수 있습니다. 또 다른 옵션은 Azure Functions를 사용하는 것입니다.
분할
파티션은 이벤트 스트림의 일부입니다. 이벤트는 파티션 키를 사용하여 분할됩니다. 예를 들어 여러 IoT 디바이스는 디바이스 데이터를 이벤트 허브로 보냅니다. 파티션 키는 디바이스 식별자입니다. 이벤트가 수집되면 Event Hubs는 이벤트를 별도의 파티션으로 이동합니다. 각 파티션 내에서 모든 이벤트는 시간별로 정렬됩니다.
소비자는 이벤트 데이터를 처리하는 코드의 인스턴스입니다. Event Hubs는 분할된 소비자 패턴을 따릅니다. 각 소비자는 특정 파티션만 읽습니다. 여러 파티션이 있으면 여러 소비자가 스트림을 동시에 읽을 수 있으므로 처리 속도가 빨라집니다.
동일한 소비자의 인스턴스는 단일 소비자 그룹을 구성합니다. 여러 소비자 그룹은 서로 다른 의도로 동일한 스트림을 읽을 수 있습니다. 이벤트 스트림에 온도 센서의 데이터가 있다고 가정합니다. 한 소비자 그룹은 스트림을 읽고 온도 급증과 같은 변칙을 검색할 수 있습니다. 또 다른 스트림은 동일한 스트림을 읽고 임시 창에서 롤링 평균 온도를 계산할 수 있습니다.
Event Hubs는 여러 소비자 그룹을 허용하여 Publisher-Subscriber 패턴을 지원합니다. 각 소비자 그룹은 구독자입니다.
Event Hubs 분할에 대한 자세한 내용은 파티션을 참조 하세요.
Event Hubs 캡처
캡처 기능을 사용하면 이벤트 스트림을 Azure Blob Storage 또는 Data Lake Storage에 저장할 수 있습니다. 스토리지 계정을 사용할 수 없더라도 캡처는 일정 기간 동안 데이터를 유지한 다음 사용 가능한 후 스토리지에 쓰기 때문에 이벤트를 저장하는 방법은 신뢰할 수 있습니다.
스토리지 서비스는 이벤트를 분석하기 위한 추가 기능을 제공할 수도 있습니다. 예를 들어 Blob Storage 계정의 액세스 계층을 활용하여 자주 액세스해야 하는 데이터에 대한 이벤트를 핫 계층에 저장할 수 있습니다. 시각화에 해당 데이터를 사용할 수 있습니다. 또는 보관 계층에 데이터를 저장하고 감사 목적으로 가끔 검색할 수 있습니다.
캡처는 Event Hubs에서 수집한 모든 이벤트를 저장하며 일괄 처리에 유용합니다. MapReduce 함수를 사용하여 데이터에 대한 보고서를 생성할 수 있습니다. 캡처된 데이터는 진실의 근원이 될 수도 있습니다. 데이터를 집계하는 동안 특정 팩트가 누락된 경우 캡처된 데이터를 참조할 수 있습니다.
이 기능에 대한 자세한 내용은 Azure Blob Storage 또는 Azure Data Lake Storage에서 Azure Event Hubs를 통해 이벤트 캡처를 참조하세요.
Apache Kafka 클라이언트 지원
Event Hubs는 Apache Kafka 클라이언트에 대한 엔드포인트를 제공합니다. 기존 클라이언트는 엔드포인트를 가리키고 Event Hubs에 이벤트 전송을 시작하도록 구성을 업데이트할 수 있습니다. 코드를 변경할 필요가 없습니다.
자세한 내용은 Apache Kafka용 Event Hubs를 참조하세요.
크로스오버 시나리오
어떤 경우에는 두 개의 메시징 서비스를 결합하는 것이 유리합니다.
서비스를 결합하면 메시징 시스템의 효율성을 높일 수 있습니다. 예를 들어 비즈니스 트랜잭션에서 Azure Service Bus 큐를 사용하여 메시지를 처리합니다. 소비자가 새 메시지에 대해 큐를 지속적으로 폴링하기 때문에 주로 유휴 상태이고 메시지를 받는 큐는 비효율적입니다. 이벤트 처리기로 Azure Function을 사용하여 Event Grid 구독을 설정할 수 있습니다. 큐가 메시지를 수신하고 수신 대기하는 소비자가 없을 때마다 Event Grid는 큐를 드레이닝하는 Azure Function을 호출하는 알림을 보냅니다.
Service Bus를 Event Grid에 연결하는 방법에 대한 자세한 내용은 Azure Service Bus와 Event Grid 통합 개요를 참조하세요.
메시지 큐 및 이벤트 참조 아키텍처를 사용하는 엔터프라이즈 통합은 Service Bus-Event Grid 통합의 구현을 보여줍니다.
또 다른 예: Event Grid는 일부 이벤트에 워크플로가 필요한 이벤트 집합을 수신하고 다른 이벤트는 알림을 받습니다. 메시지 메타데이터는 이벤트 유형을 나타냅니다. 구분하는 한 가지 방법은 이벤트 구독에서 필터링 기능을 사용하여 메타데이터를 검사 것입니다. 워크플로가 필요한 경우 Event Grid는 워크플로를 Azure Service Bus 큐로 보냅니다. 해당 큐의 수신기는 필요한 작업을 수행할 수 있습니다. 알림 이벤트는 경고 이메일을 보내기 위해 Logic Apps로 전송됩니다.
관련 패턴
비동기 메시징을 구현할 때 다음 패턴을 고려합니다.
- 경쟁 소비자 패턴 여러 소비자가 큐에서 메시지를 읽기 위해 경쟁해야 할 수 있습니다. 이 패턴은 처리량을 최적화하고 확장성 및 가용성을 향상시키고 작업 부하를 분산시키기 위해 여러 메시지를 동시에 처리하는 방법을 설명합니다.
- 우선 순위 큐 패턴. 비즈니스 논리에서 일부 메시지를 다른 메시지보다 처리해야 하는 경우 이 패턴은 우선 순위가 높은 생산자가 게시한 메시지를 우선 순위가 낮은 메시지보다 소비자가 더 빠르게 수신하고 처리하는 방법을 설명합니다.
- 큐 기반 부하 평준화 패턴. 이 패턴은 메시지 broker를 사용하여 생산자와 소비자 간의 버퍼 역할을 하여 두 엔터티에 대한 간헐적인 과부하가 가용성 및 응답성에 미치는 영향을 최소화합니다.
- 재시도 패턴. 생산자 또는 소비자가 큐에 연결할 수 없지만 이 오류의 원인은 일시적이고 빠르게 전달될 수 있습니다. 이 패턴은 이 상황을 처리하여 애플리케이션에 복원력을 추가하는 방법을 설명합니다.
- Scheduler 에이전트 감독자 패턴입니다. 메시징은 워크플로 구현의 일부로 자주 사용됩니다. 이 패턴은 메시징이 분산된 서비스 및 기타 원격 리소스 세트에서 작업 세트를 조정하고 시스템이 실패한 작업을 복구하고 다시 시도할 수 있도록 하는 방법을 보여 줍니다.
- 연출 패턴. 이 패턴은 서비스에서 메시징을 사용하여 비즈니스 트랜잭션의 워크플로를 제어하는 방법을 보여 줍니다.
- 클레임 확인 패턴입니다. 이 패턴은 큰 메시지를 클레임 검사 및 페이로드로 분할하는 방법을 보여 줍니다.