순차 호위(convoy) 패턴

다른 메시지 그룹의 처리를 차단하지 않고 정의된 순서대로 관련 메시지 세트를 처리합니다.

컨텍스트 및 문제점

애플리케이션은 들어오는 순서대로 메시지 시퀀스를 처리하면서도 증가된 부하를 처리하도록 확장할 수 있어야 하는 경우가 많습니다. 분산 아키텍처에서는 작업자가 경쟁 소비자 패턴을 사용하여 독립적으로 크기를 조정하고 메시지를 독립적으로 끌어올 수 있기 때문에 이러한 메시지를 순서대로 처리하는 것은 간단하지 않습니다.

예를 들어 주문 추적 시스템은 해당 주문에 대한 주문 및 관련 작업을 포함하는 원장을 받습니다. 이러한 작업은 주문을 만들거나, 주문에 트랜잭션을 추가하거나, 과거 트랜잭션을 수정하거나, 주문을 삭제하는 것입니다. 이 시스템에서는 FIFO(선입선출) 방식으로 작업을 수행해야 하지만 주문 수준에서만 수행해야 합니다. 그러나 초기 큐는 인터리브될 수 있는 많은 주문에 대한 트랜잭션이 포함된 원장을 받습니다.

솔루션

관련 메시지를 큐 시스템 내의 범주로 푸시하고 큐 수신기가 한 번에 하나의 범주, 하나의 메시지에서만 잠그고 끌어오게 합니다.

일반적인 순차 호위(convoy) 패턴은 다음과 같습니다.

큐에서 다음 다이어그램과 같이 다양한 범주에 대한 메시지가 인터리브될 수 있습니다.

문제 및 고려 사항

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

• 범주/배율 단위 들어오는 메시지의 어떤 속성을 스케일 아웃할 수 있나요? 주문 추적 시나리오에서 이 속성은 주문 ID입니다.
• 처리량. 대상 메시지 처리량은 무엇인가요? 매우 높은 경우 FIFO 요구 사항을 재고해야 할 수 있습니다. 예를 들어 시작/끝 메시지를 적용하고 시간별로 정렬한 다음, 처리를 위해 일괄 처리를 보낼 수 있나요?
• 서비스 기능 메시지 버스를 선택하면 큐 또는 큐의 범주 내에서 메시지를 한 번에 하나씩 처리할 수 있나요?
• 진화성 새 메시지 범주를 시스템에 추가하려면 어떻게 해야 할까요? 예를 들어 위에서 설명한 원장 시스템이 특정 고객이라고 가정합니다. 새 고객을 온보딩해야 하는 경우 고객 ID별로 작업을 배포하는 원장 프로세서 세트를 사용할 수 있나요?
• 메시지를 보낼 때 네트워크 대기 시간이 가변적이기 때문에 소비자가 메시지를 순서대로 수신할 수 있습니다. 순서를 확인하려면 시퀀스 번호를 사용하는 것이 좋습니다. 트랜잭션의 마지막 메시지에 특별한 "시퀀스 끝" 플래그를 포함할 수도 있습니다. Spark 또는 Azure Stream Analytics와 같은 스트림 처리 기술은 시간 범위 내에서 메시지를 순서대로 처리할 수 있습니다.

이 패턴을 사용해야 하는 경우

다음 경우에 이 패턴을 사용합니다.

• 메시지가 순서대로 도착하여 동일한 순서로 처리되어야 합니다.
• 도착하는 메시지는 범주가 시스템의 배율 단위가 되는 방식으로 "분류"될 수 있습니다.

다음 경우에는 이 패턴이 적합하지 않습니다.

• FIFO 요구 사항이 시스템에서 수행할 수 있는 크기 조정을 제한하기 때문에 매우 높은 처리량 시나리오(수백만 개의 메시지/분 또는 초)

워크로드 디자인

설계자는 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하기 위해 워크로드 디자인에 순차적 호송 패턴을 사용하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

예시

Azure에서 이 패턴은 Azure Service Bus 메시지 세션을 사용하여 구현될 수 있습니다. 소비자의 경우 Service Bus 피킹 잠금 커넥터와 함께 Logic Apps를 사용하거나 Service Bus 트리거와 함께 Azure Functions를 사용할 수 있습니다.

이전 주문 추적 예제의 경우 각 원장 메시지를 받은 순서대로 처리하고 각 트랜잭션을 범주가 주문 ID로 설정된 다른 큐로 보냅니다. 트랜잭션은 이 시나리오에서 여러 주문에 걸쳐서는 안 되므로 소비자는 각 범주를 병렬로 처리하지만 범주 내에서는 FIFO를 처리합니다.

원장 프로세서 팬은 첫 번째 큐에서 각 메시지의 콘텐츠를 일괄 처리 해제하여 메시지를 출력합니다.

원장 프로세서는 다음을 처리합니다.

1. 한 번에 한 트랜잭션씩 원장을 찾아갑니다.
2. 주문 ID와 일치하도록 메시지의 세션 ID를 설정합니다.
3. 세션 ID가 주문 ID로 설정된 보조 큐에 각 원장 트랜잭션을 보냅니다.

소비자는 큐에서 순서대로 일치하는 주문 ID가 있는 모든 메시지를 처리하는 보조 큐를 수신 대기합니다. 소비자는 피킹 잠금 모드를 사용합니다.

확장성을 고려할 때 원장 큐는 기본 병목 상태입니다. 원장에 게시된 다른 트랜잭션은 동일한 주문 ID를 참조할 수 있습니다. 그러나 서버리스 환경의 주문 수로 원장 뒤의 메시지가 팬아웃할 수 있습니다.

다음 단계

이 패턴의 구현과 관련된 정보는 다음과 같습니다.

• 메시지 세션: FIFO(첫 번째, 첫 번째)
• Peek-Lock 메시지(비 파괴적 읽기)
• Service Bus 세션을 사용하여 Logic Apps에서 상관 관계가 있는 메시지 배달 순서(MSDN 블로그)