우선 순위 큐 패턴

워크로드가 우선 순위가 낮은 요청보다 더 빠르게 우선 순위가 높은 요청을 처리하도록 서비스에 전송된 요청의 우선 순위를 지정합니다. 이 방법은 하나 이상의 큐로 전송된 메시지를 사용하며 다른 요청 유형 또는 고객에게 다양한 서비스 수준 또는 SLA(서비스 수준 계약)를 제공하는 애플리케이션에 유용합니다.

컨텍스트 및 문제점

워크로드는 중요도 및 긴급도의 다양한 수준으로 작업을 관리하고 처리해야 할 수 있습니다. 일부 작업에는 즉각적인 주의가 필요하지만 다른 작업은 기다릴 수 있습니다. 우선 순위가 높은 작업을 해결하지 못하면 사용자 환경에 영향을 미치고 SLA를 위반할 수 있습니다.

우선 순위에 따라 작업을 효율적으로 처리하려면 워크로드에 따라 작업을 처리하고 실행하는 메커니즘이 필요합니다. 기본적으로 대부분의 워크로드는 FIFO(선착순) 큐 구조를 사용하여 도착하는 순서대로 작업을 처리합니다. 이 방법은 다양한 작업 중요도를 고려하지 않습니다.

해결 방법

우선 순위 큐를 사용하면 워크로드가 도착 순서에 따라 엄격하게 처리하지 않고 우선 순위에 따라 작업을 처리할 수 있습니다. 요청을 보내는 애플리케이션 또는 생산자 는 메시지에 우선 순위 값을 할당하고 소비자 는 메시지를 우선 순위별로 처리합니다. 우선 순위 큐 패턴은 다음 요구 사항을 해결합니다.

  • 다양한 긴급도 및 중요도의 작업을 처리 합니다. 긴급도 및 중요도가 다른 태스크가 있으며 덜 중요한 작업보다 더 중요한 작업을 처리해야 합니다.

  • 다른 SLA를 처리합니다. 다양한 고객에게 다양한 SLA를 제공하고 우선 순위가 높은 고객이 더 나은 성능과 가용성을 받을 수 있도록 해야 합니다.

  • 다양한 워크로드 관리 요구 사항을 수용합니다. 덜 긴급한 작업이 대기할 수 있는 동안 특정 작업을 즉시 해결해야 하는 워크로드가 있습니다.

우선 순위 큐 패턴을 구현하는 두 가지 주요 방법이 있습니다.

  • 단일 큐: 각 메시지에는 우선 순위 값이 할당되고 모든 메시지는 동일한 큐를 사용합니다.

  • 여러 큐: 각 메시지에는 우선 순위 값이 할당되고 우선 순위가 다른 메시지는 별도의 큐를 사용합니다.

단일 큐

단일 큐 접근 방식에서 애플리케이션은 각 메시지에 우선 순위를 할당하고 모든 메시지를 단일 큐로 보냅니다. 큐는 우선 순위별로 메시지를 정리하여 소비자가 우선 순위가 높은 메시지를 먼저 처리하도록 합니다.

메시지 우선 순위를 지원하는 큐 메커니즘을 보여 주는 다이어그램

여러 대기열

여러 큐는 메시지를 우선 순위별로 구분합니다. 애플리케이션은 각 메시지에 우선 순위를 할당하고 소비자가 메시지를 처리하는 우선 순위에 해당하는 큐로 메시지를 전달합니다. 다중 큐 솔루션은 단일 소비자 풀 또는 여러 소비자 풀을 사용할 수 있습니다.

단일 소비자 풀

단일 풀 설정에서 모든 큐는 동일한 소비자 풀을 공유합니다. 소비자는 우선 순위가 가장 높은 큐에서 메시지를 먼저 처리하고 우선 순위가 높은 메시지가 더 이상 없는 경우에만 우선 순위가 낮은 큐에서 메시지를 처리합니다. 따라서 단일 소비자 풀은 우선 순위가 낮은 메시지보다 우선 순위가 높은 메시지를 항상 처리합니다. 이 설정을 사용하면 우선 순위가 낮은 메시지가 지속적으로 지연되고 잠재적으로 처리되지 않을 수 있습니다.

모든 우선 순위에 단일 소비자 풀을 사용하는 방법을 보여 주는 다이어그램

다음과 같은 이유로 단일 소비자 풀을 사용합니다.

  • 간단한 관리. 쉬운 설정 및 유지 관리가 우선 순위인 경우 단일 소비자 풀을 사용합니다. 단일 풀은 구성 및 모니터링 복잡성을 줄입니다.

  • 통합 처리 요구 사항. 들어오는 작업이 형식에서 비슷한 경우 단일 소비자 풀을 사용합니다.

여러 사용자 그룹

다중 소비자 풀에서는 각 큐에 전용 소비자 풀이 있습니다. 우선 순위가 높은 큐는 우선 순위가 낮은 큐보다 더 많은 소비자 또는 더 높은 성능 계층을 사용하여 메시지를 더 빠르게 처리합니다.

각 우선 순위에 대해 별도의 소비자 풀을 사용하는 방법을 보여 주는 다이어그램

다음과 같은 이유로 여러 소비자 풀을 사용합니다.

  • 엄격한 성능 요구 사항. 서로 다른 작업 우선 순위에 독립적으로 충족해야 하는 엄격한 성능 요구 사항이 있는 경우 여러 소비자 풀을 사용합니다.

  • 높은 안정성 요구 사항. 안정성 및 오류 격리가 중요하고 한 큐의 문제가 다른 큐에 영향을 미치지 않아야 하는 경우 애플리케이션에 여러 소비자 풀을 사용합니다.

  • 복잡한 애플리케이션. 여러 작업에서 다양한 처리 특성 및 성능 보장이 필요한 복잡한 애플리케이션에 대해 여러 소비자 풀을 사용합니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

일반 권장 사항

  • 우선 순위를 명확하게 정의합니다. 솔루션과 관련된 고유하고 명확한 우선 순위 수준을 설정합니다. 예를 들어 우선 순위가 높은 메시지를 10초 이내에 처리해야 하는 메시지로 정의할 수 있습니다. 우선 순위가 높은 항목을 처리하기 위한 소비자 요구 사항을 식별하고 그에 따라 필요한 리소스를 할당합니다.

  • 소비자 풀을 동적으로 조정합니다. 서비스 중인 큐의 길이에 따라 소비자 풀의 크기를 조정합니다.

  • 큐 상태를 모니터링하세요. 작업에 영향을 미치기 전에 백로그 및 속도 저하를 감지할 수 있도록 큐 깊이, 처리 대기 시간, 배달 수 및 처리량을 추적합니다.

  • 데드 레터 큐를 사용하세요. 하나의 잘못된 메시지가 우선순위 경로를 차단하지 않도록, 설정 가능한 횟수만큼 전달을 시도한 후 포이즌 메시지를 데드 레터 큐로 이동합니다.

  • 서비스 수준의 우선 순위를 지정합니다. 우선 순위가 지정된 가용성 또는 성능이 필요한 비즈니스 요구 사항을 충족하도록 우선 순위 큐를 구현합니다. 예를 들어 우선 순위가 높은 고객은 더 높은 서비스 수준을 받을 수 있으므로 더 나은 성능과 가용성을 경험할 수 있습니다.

  • 우선 순위가 낮은 처리를 고려합니다. 우선 순위가 높은 모든 항목을 우선 순위가 낮은 항목보다 먼저 처리해야 하는지 여부를 결정합니다. 가능하면 이전 메시지의 우선 순위를 동적으로 늘려 우선 순위가 낮은 메시지가 결국 처리되도록 합니다.

  • 비용을 최적화하고 최소화합니다. 사용 가능한 소비자와 함께 중요한 작업을 즉시 처리합니다. 덜 바쁜 시간 동안 덜 중요한 백그라운드 작업을 예약합니다.

    단일 큐를 사용하는 경우 소비자 수를 축소하여 비용을 최적화합니다. 우선 순위가 높은 메시지는 먼저 처리되지만 더 느리게 처리되지만 우선 순위가 낮은 메시지는 더 긴 지연에 직면할 수 있습니다.

  • 수요 최대에서 프로세서를 보호합니다. 생산자 도착률이 소비자 처리 용량을 초과할 수 있는 경우 이 패턴을 Queue-Based 부하 평준화 패턴과 결합합니다. 이 방법은 트래픽 버스트를 버퍼링하고 다운스트림 처리 리소스의 오버로드를 방지하는 데 도움이 됩니다.

다중 큐 권장 사항

  • 처리 속도를 모니터링합니다. 메시지가 예상 속도로 처리되도록 하려면 우선 순위가 높은 큐 및 낮은 우선 순위 큐의 처리 속도를 지속적으로 모니터링합니다.

  • 선점 및 일시 중단을 구현합니다. 단일 소비자 풀에서 여러 큐를 사용하는 경우 우선 순위가 낮은 큐보다 우선 순위가 높은 큐가 항상 서비스되도록 하는 알고리즘을 구현합니다.

  • 큐 비용을 고려하십시오. 큐 확인 및 처리와 관련된 재정적 비용을 알고 있어야 합니다. 일부 큐 서비스는 메시지 게시, 검색 및 쿼리에 대한 요금을 부과합니다. 이러한 수수료는 큐 수에 따라 증가할 수 있습니다.

이 패턴을 사용하는 경우

다음과 같은 경우 이 패턴을 사용합니다.

  • 프리미엄 및 표준 고객 요청과 같은 다양한 작업 클래스에 대해 서로 다른 대기 시간 또는 서비스 수준 목표를 충족해야 합니다.

  • 작업은 한꺼번에 몰려오므로, 우선순위가 높은 메시지를 먼저 처리하고 우선순위가 낮은 작업은 미루어 핵심 운영을 보호해야 합니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

  • 모든 작업 항목은 비즈니스 중요도가 비슷하며 엄격한 FIFO 처리는 우선 순위 기반 일정보다 더 중요합니다.

  • 작업에는 우선 순위 수준에서 강력한 순서 종속성이 있으며 우선 순위별로 작업 순서를 다시 지정하면 일관성 없는 결과가 발생하거나 복잡한 조정 논리가 필요할 수 있습니다.

워크로드 디자인

워크로드 디자인에서 우선 순위 큐 패턴을 사용하여 Azure Well-Architected 프레임워크 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

핵심 요소 이 패턴으로 핵심 목표를 지원하는 방법
안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. 비즈니스 우선 순위에 따라 항목을 분리하면 가장 중요한 작업에 안정성 노력을 집중할 수 있습니다.

- RE:02 중요 흐름
성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다. 비즈니스 우선 순위에 따라 항목을 분리하면 가장 시간이 중요한 작업에 성능 노력을 집중할 수 있습니다.

- PE:09 핵심 흐름

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

Example

GitHub 우선 순위 큐 패턴 예제는 Azure Service Bus 토픽 및 구독을 사용하는 우선 순위 큐 패턴의 구현을 보여 줍니다. 이 예제에서는 보안 스토리지 계정, 모니터링을 위한 Application Insights 리소스 및 Service Bus 네임스페이스를 배포하여 보낸 사람 및 소비자 함수 간의 통신을 사용하도록 설정합니다.

배포에는 세 개의 함수 앱, 즉 송신 앱 하나와 소비자 앱 두 개가 포함됩니다. 소비자 앱은 다양한 최대 인스턴스 수를 사용하여 메시지 우선 순위를 시뮬레이션합니다. 함수는 funcPriorityQueueConsumerHigh 200개의 인스턴스로 확장할 수 있지만 funcPriorityQueueConsumerLow 함수는 40개의 인스턴스로 제한됩니다. 모든 함수 앱은 Flex 사용 계획을 사용하며 진단 및 모니터링을 위해 Application Insights에 연결됩니다.

역할 할당은 관리 ID를 사용하여 Service Bus 및 스토리지에 대한 보안 액세스 권한을 부여합니다. 모든 함수 앱은 동일한 스토리지 계정 및 Application Insights 리소스를 공유합니다. 이 구성은 관찰 가능성 및 로깅을 중앙 집중화합니다.

다음 다이어그램은 우선 순위 큐 아키텍처를 보여줍니다.

Service Bus 사용하여 우선 순위 큐를 구현하는 방법을 보여 주는 다이어그램

위의 다이어그램에서:

  1. 애플리케이션(생산자). PriorityQueueSender 애플리케이션은 메시지를 만들고, 각 메시지에 Priority라는 사용자 지정 애플리케이션 속성을 할당하며, Priority 값을 High 또는 Low로 설정합니다.

  2. 메시지 브로커 및 주제. Service Bus 메시지 브로커는 명명messages된 단일 Service Bus 토픽으로 메시지를 보냅니다. Service Bus SQL 필터를 사용하여 각 메시지를 해당 값에 Priority 따라 우선 순위가 높거나 우선 순위가 낮은 구독으로 라우팅합니다.

  3. 여러 소비자 풀. PriorityQueueConsumerHigh 및 PriorityQueueConsumerLow 소비자 풀은 Azure Functions Service Bus 트리거를 사용하여 고우선순위 또는 저우선순위 구독의 메시지에 반응합니다.

예제의 역할 예제의 Azure 서비스 예제의 이름
애플리케이션(생산자) Azure Functions 앱 우선순위 큐 발신자
메시지 브로커 Azure Service Bus (아주르 서비스 버스) <사용자의 서비스 버스 네임스페이스>
메시지 항목 Azure Service Bus 토픽 messages
메시지 구독 Azure Service Bus 구독 highPriority
lowPriority
소비자 Azure Functions 앱 PriorityQueueConsumerHigh
PriorityQueueConsumerLow

다음 단계

  • Service Bus 큐, 토픽 및 구독: Service Bus 개체와 큐 및 토픽의 차이점을 살펴봅니다.
  • 중복 검색: 발신자가 불확실한 전송 후 다시 시도하면 Service Bus 중복 메시지를 거부하는 방법을 알아봅니다.
  • 데드 레터 큐: 조사하거나 다시 처리할 수 있도록 Service Bus가 처리할 수 없는 메시지를 데드 레터 큐로 이동하는 방법을 알아봅니다.
  • Azure Queue Storage란?: Azure Queue Storage 핵심 개념을 검토하여 Service Bus 큐와 비교합니다.

다음 패턴은 이 패턴을 구현할 때 유용할 수 있습니다.

  • Queue-Based 부하 평준화 패턴: 큐를 요청 유입과 처리 사이의 버퍼로 사용합니다. 버스트 보호 및 차별화된 처리가 모두 필요한 경우 우선 순위 큐 패턴과 함께 사용합니다.

  • 경쟁 소비자 패턴: 동일한 큐를 수신 대기하고 작업을 병렬로 처리하여 처리량을 늘리는 여러 소비자를 구현합니다. 각 메시지를 처리하는 소비자는 하나뿐입니다.

  • 제한 패턴: 큐를 사용하여 요청 속도를 관리하여 제한을 구현합니다. 우선 순위 메시징을 사용하여 중요 애플리케이션 또는 중요도가 높은 고객의 요청에 덜 중요한 요청보다 우선 순위를 지정합니다.