Azure Service Bus 세션을 사용하면 관련 메시지의 바인딩되지 않은 시퀀스를 공동 및 순서대로 처리할 수 있습니다. 세션은 선입선출(FIFO) 및 요청-응답 패턴에서 사용할 수 있습니다. 이 문서에서는 Service Bus를 사용할 때 세션을 사용하여 이러한 패턴을 구현하는 방법을 보여 줍니다.
비고
Service Bus의 기본 계층에서는 세션을 지원하지 않습니다. 표준 및 프리미엄 계층은 세션을 지원합니다. 이러한 계층 간의 차이점은 Service Bus 가격 책정을 참조하세요.
FIFO(선입선출) 패턴
Service Bus 큐 또는 구독에서 메시지를 처리하는 FIFO 처리를 수행하려면 세션을 사용합니다. Service Bus는 메시지 간 관계의 특성에 대한 규범이 아니며 메시지 시퀀스가 시작되거나 끝나는 위치를 결정하기 위한 특정 모델을 정의하지도 않습니다.
발신자는 애플리케이션에서 정의한 고유 식별자에 세션 ID 속성을 설정하여 토픽 또는 큐에 메시지를 제출할 때 세션을 시작할 수 있습니다. AMQP 1.0 프로토콜 수준에서 이 값은 그룹 ID 속성에 매핑됩니다.
세션 인식 큐 또는 구독에서 세션 ID가 있는 메시지가 하나 이상 있는 경우 세션이 존재하게 됩니다. 세션이 있으면 세션이 만료되거나 사라지는 시간에 대한 정의된 시간 또는 API가 없습니다. 이론적으로는 오늘 세션, 1년 후의 다음 메시지에 대한 메시지를 받을 수 있으며 세션 ID가 일치하는 경우 세션은 Service Bus 관점에서 동일합니다.
그러나 일반적으로 애플리케이션은 관련 메시지 집합이 시작되고 끝나는 위치를 정의합니다. Service Bus는 특정 규칙을 적용하지 않습니다. 예를 들어 애플리케이션은 첫 번째 메시지의 Label 속성을 시작으로, 중간 메시지를 콘텐츠로 설정하고, 마지막 메시지를 종료하도록 설정할 수 있습니다. 콘텐츠 메시지의 상대 위치는 시작 메시지 SequenceNumber에서 현재 메시지 SequenceNumber 델타로 계산할 수 있습니다.
중요합니다
큐 또는 구독에서 세션을 사용하도록 설정하면 클라이언트 애플리케이션은 더 이상 일반 메시지를 보내거나 받을 수 없습니다. 클라이언트는 세션 ID를 설정하고 세션을 수락하여 받은 메시지를 세션의 일부로 보내야 합니다. 클라이언트는 세션이 활성화된 큐나 구독을 여전히 열람할 수 있습니다. 메시지 검색을 참조하세요.
세션에 대한 API는 큐 및 구독 클라이언트에 있습니다. 세션 및 메시지를 수신하는 방법에는 명령적 모델, 메시지를 받는 시기 및 방법을 수동으로 제어하는 명령적 모델 및 메시지 루프 및 처리를 자동으로 관리하여 작업을 간소화하는 처리기 기반 모델이라는 두 가지 방법이 있습니다.
샘플의 경우 샘플 섹션의 링크를 사용합니다.
세션 기능
세션은 교차된 메시지 스트림을 동시 디멀티플렉싱 하여 순서대로 배달되도록 보존하고 보장합니다.
클라이언트는 세션을 수락하는 세션 수신기를 만듭니다. 클라이언트가 세션을 수락하고 보유하는 경우 클라이언트는 큐 또는 구독에서 해당 세션의 세션 ID 가 있는 모든 메시지에 대한 단독 잠금을 보유합니다. 나중에 도착하는 세션 ID 가 있는 모든 메시지에 대한 단독 잠금을 보유합니다.
잠금은 수신기에서 닫기 메서드를 호출하거나 잠금이 만료될 때 해제됩니다. 수신기에는 잠금을 갱신하는 방법도 있습니다. 대신 자동 잠금 갱신 기능을 사용하여 잠금을 계속 갱신할 기간을 지정할 수 있습니다. 세션 잠금은 파일에 대한 배타적 잠금처럼 처리되어야 합니다. 즉, 애플리케이션이 더 이상 필요하지 않거나 추가 메시지를 기대하지 않는 즉시 세션을 닫아야 합니다.
다수의 동시 수신자가 큐에서 풀링되면 특정 세션에 속하는 메시지는 해당 세션에 대한 잠금을 보유하고 있는 특정 수신자에게 전달됩니다. 이 작업을 사용하면 한 큐 또는 구독의 섞인 메시지 스트림이 서로 다른 수신기로 깔끔하게 분할되고, 서비스 쪽에서 잠금 관리가 Service Bus 내부에서 수행되기 때문에 해당 수신기들은 다른 클라이언트 머신에서도 사용할 수 있습니다.
이전 그림에서는 세 개의 동시 세션 수신기를 보여 줍니다. = 4가 있는 SessionId 한 세션에는 활성 소유 클라이언트가 없으므로 이 특정 세션에서 메시지가 배달되지 않습니다. 세션은 하위 큐와 같은 여러 가지 방법으로 작동합니다.
세션 수신기가 보유한 세션 잠금은 피킹 잠금 해결 모드에서 사용하는 메시지 잠금에 대한 우산입니다. 하나의 수신기만 세션에 대한 잠금을 가질 수 있습니다. 수신자는 많은 처리 중인 메시지를 가질 수 있지만, 메시지는 순서대로 수신됩니다. 메시지를 중단하면 다음 수신 작업과 함께 동일한 메시지가 다시 제공됩니다.
메시지 세션 상태
워크플로가 고가용성 고가용성 클라우드 시스템에서 처리되는 경우 특정 세션과 연결된 워크플로 처리기는 예기치 않은 오류로부터 복구할 수 있어야 하며 작업이 시작된 다른 프로세스 또는 컴퓨터에서 부분적으로 완료된 작업을 다시 시작할 수 있어야 합니다.
세션 상태 기능을 사용하면 브로커 내에서 메시지 세션의 애플리케이션 정의 주석을 사용할 수 있으므로 새 프로세서에서 세션을 획득할 때 해당 세션에 상대적으로 기록된 처리 상태를 즉시 사용할 수 있습니다.
Service Bus 관점에서 메시지 세션 상태는 Service Bus 표준의 경우 256KB, Service Bus Premium의 경우 100MB인 메시지 크기의 데이터를 저장할 수 있는 불투명한 이진 개체입니다. 세션에 상대적인 처리 상태는 세션 상태 내에서 유지되거나 세션 상태가 이러한 정보를 보유하는 일부 스토리지 위치 또는 데이터베이스 레코드를 가리킬 수 있습니다.
세션 상태를 SetState관리하는 메서드 및 GetState세션 수신기 개체에서 찾을 수 있습니다. 이전에 세션 상태가 없었던 세션은 에 대한 null 참조를 반환합니다 GetState. 수신기의 메서드에 null SetState 을 전달하여 이전에 설정한 세션 상태를 지울 수 있습니다.
세션의 모든 메시지가 사용되는 경우에도 세션 상태가 지워지지 않는 한( null 반환) 유지됩니다.
큐 또는 구독에 저장된 세션 상태는 해당 엔터티의 스토리지 할당량에 포함됩니다. 애플리케이션이 세션을 마치면 추가 관리 비용을 피하기 위해 유지된 상태를 정리하는 것이 권장됩니다.
배달 수의 영향
세션 컨텍스트에서 메시지당 배달 횟수 정의는 세션이 없는 경우 정의와 약간 다릅니다. 다음은 배달 횟수가 증가되는 시기를 요약한 표입니다.
| 시나리오 | 메시지의 배달 횟수가 증가했습니까? |
|---|---|
| 세션이 수락되었지만 세션 잠금이 만료됩니다(시간 제한으로 인해). | 예 |
| 세션이 수락되고 세션 내의 메시지가 완료되지 않고(잠긴 경우에도) 세션이 닫힙니다. | 아니오 |
| 세션이 수락되고 메시지가 완료된 다음 세션이 명시적으로 닫힙니다. | N/A(표준 흐름입니다. 여기서 메시지는 세션에서 제거됩니다. |
요청-응답 패턴
요청-회신 패턴은 보낸 사람 애플리케이션이 요청을 보낼 수 있도록 하고 수신자가 보낸 사람 애플리케이션에 응답을 올바르게 보낼 수 있는 방법을 제공하는 잘 설정된 통합 패턴입니다. 이 패턴은 일반적으로 애플리케이션이 응답을 보내기 위해 수명이 짧은 큐 또는 토픽이 필요합니다. 이 시나리오에서 세션은 비슷한 의미 체계를 가진 간단한 대체 솔루션을 제공합니다.
여러 애플리케이션은 특정 헤더 매개 변수가 발신자 애플리케이션을 고유하게 식별하도록 설정된 단일 요청 큐로 요청을 보낼 수 있습니다. 수신자 애플리케이션은 큐에 들어오는 요청을 처리하고 세션 사용 큐에서 회신을 전송하여 세션 ID를 발신자가 요청 메시지에서 보낸 고유 식별자로 설정할 수 있습니다. 그런 다음 요청을 보낸 애플리케이션은 특정 세션 ID에 대한 메시지를 수신하고 회신을 올바르게 처리할 수 있습니다.
비고
초기 요청을 보내는 애플리케이션은 세션 ID에 대해 알고 응답이 예상되는 세션이 잠기도록 세션을 수락하는 데 사용해야 합니다. 애플리케이션 인스턴스를 세션 ID로 고유하게 식별하는 GUID를 사용하는 것이 좋습니다. 큐에서 특정 수신기가 응답을 잠그고 처리할 수 있도록, 세션 수신기에는 세션 처리기나 시간 제한이 지정되어 있지 않아야 합니다.
시퀀싱 대 세션
시퀀스 번호 는 자체적으로 큐 순서와 메시지의 추출 순서를 보장하지만 세션이 필요한 처리 순서는 보장하지 않습니다.
큐에 세 개의 메시지와 두 명의 소비자가 있다고 가정해 보겠습니다.
- 소비자 1은 메시지 1을 선택합니다.
- 소비자 2는 메시지 2를 선택합니다.
- 소비자 2는 메시지 2 처리를 완료하고 메시지 3을 선택하지만 소비자 1은 아직 메시지 1 처리를 수행하지 않습니다.
- 소비자 2는 메시지 3 처리를 완료하지만 소비자 1은 아직 메시지 1을 처리하지 않습니다.
- 마지막으로 소비자 1이 메시지 1 처리를 완료합니다.
따라서 메시지는 메시지 2, 메시지 3 및 메시지 1 순서로 처리됩니다. 메시지 1, 2 및 3을 순서대로 처리해야 하는 경우 세션을 사용해야 합니다.
메시지를 순서대로 검색해야 하는 경우 세션을 사용할 필요가 없습니다. 메시지를 순서대로 처리해야 하는 경우 세션을 사용합니다. 집합의 메시지 1, 4, 8, 다른 집합의 2, 3 및 6일 수 있는 함께 속한 메시지에 동일한 세션 ID를 설정해야 합니다.
메시지 만료
세션이 활성화된 큐나 토픽의 구독에서 메시지는 세션 수준에서 잠깁니다. TTL(Time-to-Live) 기간이 만료된 모든 메시지는 엔터티의 메시징 만료 설정에서 '데드 레터 처리'가 활성화되어 있는지에 따라 해당 세션과 관련된 모든 메시지가 삭제되거나 데드 레터로 처리됩니다. 즉, TTL을 통과한 세션에 단일 메시지가 있는 경우 세션의 모든 메시지가 만료됩니다. 메시지는 활성 수신기가 있는 경우에만 만료됩니다. 자세한 내용은 메시지 만료를 참조하세요.
샘플
Azure Portal, PowerShell, CLI, Resource Manager 템플릿, .NET, Java, Python 및 JavaScript를 사용하여 큐를 만드는 동안 메시지 세션을 사용하도록 설정할 수 있습니다. 자세한 내용은 메시지 세션 사용을 참조하세요.
선택한 언어로 샘플을 사용하여 Azure Service Bus 기능을 살펴봅니다.
- .그물
- 자바
- 파이썬
- JavaScript