Azure Logic Apps의 워크플로에서 Azure Service Bus에 연결

적용 대상: Azure Logic Apps(사용량 + 표준)

이 가이드에서는 Service Bus 커넥터를 사용하여 Azure Logic Apps의 워크플로에서 Azure Service Bus에 액세스하는 방법을 보여줍니다. 그 후 Service Bus의 이벤트에 의해 트리거될 때 실행되거나 다음과 같이 Service Bus 항목을 관리하는 작업을 실행하는 자동화된 워크플로를 만들 수 있습니다.

• 큐, 토픽 및 토픽 구독에 메시지가 도착하거나(자동 완성) 수신되면(보기 잠금) 모니터링합니다.
• 메시지를 보냅니다.
• 토픽 구독을 만들고 삭제합니다.
• 큐 및 토픽 구독에서 메시지를 관리합니다. 예를 들어 가져오기, 지연된 가져오기, 완료, 지연, 중단 및 배달하지 못한 편지가 있습니다.
• 큐 및 토픽 구독에서 메시지 및 세션에 대한 잠금을 갱신합니다.
• 큐 및 토픽에서 세션을 닫습니다.

트리거를 사용하여 Azure Service Bus에서 응답을 가져오고 워크플로의 다른 작업에서 출력을 사용하도록 할 수 있습니다. 또한 다른 작업에서 Service Bus 작업의 출력을 사용하도록 할 수 있습니다.

커넥터 기술 참조

Service Bus 커넥터는 논리 앱 워크플로 유형 및 호스트 환경에 따라 여러 버전이 있습니다.

필수 조건

• Azure 계정 및 구독 Azure 구독이 없는 경우 체험 Azure 계정에 등록합니다.

• Service Bus 네임스페이스 및 메시징 엔터티(예: 큐). 자세한 내용은 다음 설명서를 검토하세요.

  • Service Bus 네임스페이스 만들기

  • Service Bus 네임스페이스 및 큐 만들기

  • 구독을 사용하는 Service Bus 네임스페이스 및 토픽 만들기

• Service Bus 네임스페이스 및 메시지 엔터티에 연결하는 논리 앱 워크플로. Service Bus 트리거를 사용하여 워크플로를 시작하려면 빈 워크플로로 시작해야 합니다. 워크플로에서 Service Bus 작업을 사용하려면 트리거를 사용하여 워크플로를 시작합니다.

• 논리 앱 리소스가 Service Bus 네임스페이스 및 메시지 엔터티에 대한 액세스를 인증하는 데 관리 ID를 사용하는 경우 해당 수준에서 역할 권한을 할당했는지 확인합니다. 예를 들어 큐에 액세스하려면 해당 큐에 필요한 권한을 가진 역할이 관리 ID에 있어야 합니다.

  • 각 논리 앱 리소스는 논리 앱의 워크플로가 다른 메시징 엔터티에 액세스하는 경우에도 하나의 관리 ID만 사용해야 합니다.

  • 큐 또는 토픽 구독에 액세스하는 각 관리 ID는 자체 Service Bus API 연결을 사용해야 합니다.

  • 서로 다른 메시징 엔터티와 메시지를 교환하고 서로 다른 권한이 필요한 Service Bus 작업은 자체 Service Bus API 연결을 사용해야 합니다.

  관리 ID에 대한 자세한 내용은 Azure Logic Apps에서 관리 ID를 사용하여 Azure 리소스에 대한 액세스 인증을 참조하세요.

• 기본적으로 Service Bus 기본 제공 커넥터 작업은 상태 비저장입니다. 상태 저장 모드에서 이러한 작업을 실행하려면 상태 비저장 기본 제공 커넥터에 대해 상태 저장 모드 사용을 참조하세요.

Azure Service Bus 작업에 대한 고려 사항

무한 루프

커넥터 캐시에 저장된 세션의 제한

Service Bus 커넥터는 구독 또는 토픽과 같은 Service Bus 메시지 엔터티별로 한 번에 최대 1,500개의 고유 세션을 커넥터 캐시에 저장할 수 있습니다. 세션 수가 이 한도를 초과하면 오래된 세션이 캐시에서 제거됩니다. 자세한 내용은 메시지 세션을 참조하세요.

상관 관계가 지정된 메시지를 순서대로 보내기

관련 메시지를 특정 순서로 보내야 하는 경우에는 Service Bus 커넥터와 순차 호위(convoy) 패턴을 사용하여 워크플로를 만들 수 있습니다. 상호 관련된 메시지에는 Azure Service Bus의 세션 ID와 같이 해당 메시지 간 관계를 정의하는 속성이 있습니다.

사용량 논리 앱 워크플로를 만들 때, 순차 호위(convoy) 패턴을 구현하는 Service Bus 세션을 사용하여 상관 관계가 지정된 순서대로 배달 템플릿을 선택할 수 있습니다. 자세한 내용은 관련 메시지를 순서대로 보내기를 참조하세요.

큰 메시지 지원

큰 메시지 지원은 Service Bus 기본 제공 커넥터 작업을 사용하는 경우에만 표준 워크플로에 사용할 수 있습니다. 예를 들어 기본 제공 트리거와 작업을 각각 사용하여 큰 메시지를 받고 보낼 수 있습니다.

Service Bus 관리 커넥터의 경우 프리미엄 계층 Service Bus 네임스페이스를 사용하는 경우에도 최대 메시지 크기는 1MB로 제한됩니다.

메시지를 받고 보내는 시간 제한 늘리기

Service Bus 기본 제공 작업을 사용하는 표준 워크플로에서 메시지를 받고 보내는 시간 제한을 늘릴 수 있습니다. 예를 들어 메시지를 받는 시간 제한을 늘리려면 Azure Functions 확장에서 다음 설정을 변경합니다.

{
   "version": "2.0",
   "extensionBundle": {
      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
      "version": "[1.*, 2.0.0)"
   },
   "extensions": {
      "serviceBus": {
         "batchOptions": {
            "operationTimeout": "00:15:00"
         }
      }  
   }
}

메시지 보내기 시간 제한을 늘리려면 ServiceProviders.ServiceBus.MessageSenderOperationTimeout 앱 설정을 추가합니다.

Service Bus 관리형 커넥터 트리거

• Service Bus 관리형 커넥터의 모든 트리거는 긴 폴링입니다. 이 유형의 트리거는 모든 메시지를 처리한 다음, 더 많은 메시지가 큐 또는 토픽 구독에 나타날 때까지 30초 동안 기다립니다. 30초 동안 표시되는 메시지가 없으면 트리거 실행을 건너뜁니다. 그렇지 않으면 큐 또는 토픽 구독이 빈 상태가 될 때까지 트리거는 메시지를 계속 읽습니다. 다음 트리거 폴링은 트리거의 속성에 지정된 되풀이 간격을 기준으로 합니다.

• 큐에 하나 이상의 메시지가 도착할 때(자동 완성) 트리거와 같은 일부 트리거는 하나 이상의 메시지를 반환할 수 있습니다. 이러한 트리거가 발생되면 1과 트리거의 최대 메시지 수 속성으로 지정된 메시지 수 사이의 값을 반환합니다.

  참고 항목

  자동 완성 트리거는 메시지를 자동으로 완성하지만 다음에 Service Bus를 호출해야만 완료됩니다. 이 동작은 워크플로 설계에 영향을 줄 수 있습니다. 예를 들어 워크플로가 제한된 상태로 전환되는 경우 이 변경으로 인해 중복 메시지가 나타날 수 있으므로 자동 완성 트리거의 동시성을 변경하지 마세요. 동시성 컨트롤을 변경하면 다음과 같은 조건이 만들어집니다.

  • 제한된 트리거는 WorkflowRunInProgress 코드와 함께 건너뜁니다.

  • 완료 작업이 실행되지 않습니다.

  • 다음 트리거 실행은 폴링 간격 후에 발생합니다.

  Service Bus 잠금 기간을 폴링 간격보다 긴 값으로 설정해야 합니다. 그러나 이 설정에도 불구하고 워크플로가 다음 폴링 간격에 제한된 상태로 유지되는 경우 메시지가 완료되지 않을 수 있습니다.

  Service Bus 자동 완성 트리거에서 동시성을 변경해야 하는 경우 워크플로를 처음 저장하기 전에 이 변경을 수행하지 마세요. 동시성을 변경하기 위해 트리거를 편집하기 전에 먼저 워크플로를 만들고 저장합니다.

Service Bus 기본 제공 커넥터 트리거

Service Bus 기본 제공 커넥터의 경우 비 세션 트리거는 커넥터에서 완전히 관리되는 연속 폴링 트리거 패턴을 따릅니다. 이 패턴에는 큐 또는 토픽 구독의 메시지를 지속적으로 확인하는 트리거가 있습니다. 세션 트리거는 긴 폴링 트리거 패턴을 따르며, 해당 구성은 clientRetryOptions:tryTimeout이라는 Azure Functions 설정에 의해 제어됩니다. 현재 Service Bus 기본 제공 트리거에 대한 구성 설정은 논리 앱의 host.json 파일에 정의된 Azure Functions 호스트 확장과 디자이너 또는 코드 보기를 통해 설정할 수 있는 논리 앱의 워크플로에 정의된 트리거 설정 간에 공유됩니다. 이 섹션에서는 두 설정 위치를 모두 설명합니다.

• 표준 워크플로에서 큐에서 메시지를 사용할 수 있는 경우 트리거와 같은 일부 트리거는 하나 이상의 메시지를 반환할 수 있습니다. 이러한 트리거가 실행되면 메시지 수와 메시지 수 사이에서 반환됩니다. 이 유형의 트리거와 최대 메시지 수 매개 변수가 지원되지 않는 경우에도 host.json 파일의 maxMessageBatchSize 속성을 사용하여 수신된 메시지 수를 제어할 수 있습니다. 이 파일을 찾으려면 표준 논리 앱에 대한 호스트 및 앱 설정 편집을 참조하세요.

  "extensions": {
    "serviceBus": {
        "maxMessageBatchSize": 25
    }
  }
  

• 디자이너 또는 코드에서 Service Bus 트리거에서 동시성을 사용하도록 설정할 수도 있습니다.

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100
      }
  }
  

  일괄 처리를 사용하여 동시성을 설정하는 경우 전체 일괄 처리 크기보다 큰 동시 실행 수를 유지합니다. 이렇게 하면 메시지 읽기가 대기 상태로 전환되지 않으며 읽을 때 항상 선택됩니다. 경우에 따라 트리거는 일괄 처리 크기의 최대 두 배까지 가질 수 있습니다.

• 동시성을 활성화하면 SplitOn 제한이 100개 항목으로 줄어듭니다. 이 동작은 Service Bus 트리거뿐만 아니라 모든 트리거에 대해 true입니다. 동시성을 사용하도록 설정하는 모든 트리거에서 지정된 일괄 처리 크기가 이 제한보다 작은지 확인합니다.

• 트리거가 동시성 설정을 초과할 수 있는 몇 가지 시나리오가 있습니다. 이러한 실행에 실패하는 대신 Azure Logic Apps는 시작할 수 있을 때까지 대기 상태로 큐에 대기합니다. maximumWaitingRuns 설정은 대기 상태에서 허용되는 실행 수를 제어합니다.

  "runtimeConfiguration": {
      "concurrency": {
          "runs": 100,
          "maximumWaitingRuns": 50
      }
  }
  

  Service Bus 트리거를 사용하면 메시지 잠금 시간 제한보다 오래 기다리지 않도록 이러한 변경 내용을 신중하게 테스트해야 합니다. 기본값에 대한 자세한 내용은 여기에서 동시성 및 일괄 처리 해제 제한을 참조하세요.

• 동시성을 사용하도록 설정하면 기본적으로 일괄 처리 읽기 사이에 30초 지연이 있습니다. 이 지연은 트리거를 느리게 하여 다음 목표를 달성합니다.

  • 동시성을 적용할 실행 수를 확인하기 위해 전송되는 스토리지 호출 수를 줄입니다.

  • 메시지를 찾을 수 없는 경우 30초 길이의 폴링이 있는 Service Bus 관리 커넥터 트리거의 동작을 모방합니다.

  이 지연을 변경할 수 있지만 기본값에 대한 변경 내용을 신중하게 테스트해야 합니다.

  "workflow": {
      "settings": {
          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
      }
  }
  
  

1단계 - Service Bus 네임스페이스에 대한 액세스 확인

논리 앱 리소스가 Service Bus 네임스페이스에 액세스할 수 있는지 확인하려면 다음 단계를 수행합니다.

1. Azure Portal에서 Service Bus 네임스페이스를 엽니다.

2. 네임스페이스 메뉴의 설정에서 공유 액세스 정책을 선택합니다. 클레임 아래에서 해당 네임스페이스에 대한 관리 권한이 있는지 확인합니다.

   

2단계 - 연결 인증 요구 사항 가져오기

나중에 Service Bus 트리거 또는 작업을 처음으로 추가할 때, 연결 인증 유형을 비롯한 연결 정보를 묻는 메시지가 표시됩니다. 논리 앱 워크플로 유형, Service Bus 커넥터 버전 및 선택한 인증 유형에 따라 다음 항목이 필요합니다.

관리형 커넥터 인증(사용량 및 표준 워크플로)

기본 제공 커넥터 인증(표준 워크플로만 해당)

Service Bus 네임스페이스의 연결 문자열 가져오기

Service Bus 트리거 또는 작업을 추가할 때 연결을 만들려면 Service Bus 네임스페이스에 대한 연결 문자열이 있어야 합니다. 연결 문자열은 sb:// 접두사로 시작합니다.

1. Azure Portal에서 Service Bus 네임스페이스를 엽니다.

2. 네임스페이스 메뉴의 설정에서 공유 액세스 정책을 선택합니다.

3. 공유 액세스 정책 창에서 RootManageSharedAccessKey를 선택합니다.

4. 기본 또는 보조 연결 문자열 옆에 있는 복사 단추를 선택합니다.

   

   참고 항목

   문자열이 특정 메시지 엔터티가 아닌 네임스페이스에 대한 문자열인지 확인하려면 EntityPath 매개 변수에 대한 연결 문자열을 검색합니다. 이 매개 변수가 발견되면 연결 문자열은 특정 엔터티에 대한 것이며, 워크플로에 사용할 올바른 문자열이 아닙니다.

5. 나중에 사용할 연결 문자열을 저장합니다.

Service Bus 네임스페이스의 엔드포인트 URL 가져오기

Service Bus 관리 커넥터를 사용하는 경우 Microsoft Entra 통합 또는 Logic Apps 관리 ID 인증 유형을 선택하면 이 엔드포인트 URL이 필요합니다. 엔드포인트 URL은 sb:// 접두사로 시작합니다.

1. Azure Portal에서 Service Bus 네임스페이스를 엽니다.

2. 네임스페이스 메뉴의 설정에서 속성을 선택합니다.

3. 속성 아래 Service Bus 엔드포인트 옆에서 엔드포인트 URL을 복사하여 나중에 서비스 버스 엔드포인트 URL을 제공해야 할 때 사용할 수 있도록 저장합니다.

Service Bus 네임스페이스의 정규화된 이름 가져오기

1. Azure Portal에서 Service Bus 네임스페이스를 엽니다.

2. 네임스페이스 메뉴에서 개요를 선택합니다.

3. 개요 창에서 호스트 이름 속성을 찾고, 정규화된 이름(예: <your-Service-Bus-namespace.servicebus.windows.net>)을 복사합니다.

3단계: 옵션 1 - Service Bus 트리거 추가

다음 단계에서는 Azure Portal을 사용합니다. 그러나 적절한 Azure Logic Apps 확장이 있으면 다음 도구를 사용하여 논리 앱 워크플로를 만들 수도 있습니다.

• 사용 워크플로: Visual Studio Code
• 표준 워크플로: Visual Studio Code

3단계: 옵션 2 - Service Bus 작업 추가

다음 단계에서는 Azure Portal을 사용하지만 적절한 Azure Logic Apps 확장을 사용하면 다음 도구를 사용하여 논리 앱 워크플로를 빌드할 수도 있습니다.

• 사용 워크플로: Visual Studio Code
• 표준 워크플로: Visual Studio Code

Service Bus 기본 제공 커넥터 앱 설정

표준 논리 앱 리소스에서 Service Bus 기본 제공 커넥터에는 메시지 전송 시간 제한, 메시지 풀의 프로세서 코어당 메시지 보낸 사람 수와 같은 다양한 임계값을 제어하는 앱 설정이 포함되어 있습니다. 자세한 내용은 앱 설정 참조 - local.settings.json을 검토하세요.

Service Bus 기본 제공 트리거를 사용하여 데드레터 큐에서 메시지 읽기

표준 워크플로에서 큐 또는 토픽 구독의 데드레터 큐에서 메시지를 읽으려면 지정된 트리거를 사용하여 다음 단계를 수행합니다.

1. 시나리오에 따라 빈 워크플로에 큐에서 메시지를 사용할 수 있는 경우 또는 토픽 구독에서 메시지를 사용할 수 있는 경우(peek-lock)라는 Service Bus 기본 제공 커넥터 트리거를 추가합니다.

2. 트리거에서 다음 매개 변수 값을 설정하여 다른 큐와 마찬가지로 액세스할 수 있는 큐 또는 토픽 구독의 기본 데드레터 큐를 지정합니다.

   • 큐 트리거에서 메시지를 사용할 수 있는 경우 트리거: 큐 이름 매개 변수를 queuename/$deadletterqueue로 설정합니다.

   • 토픽 구독에서 메시지를 사용할 수 있는 경우(peek-lock) 트리거: 토픽 이름 매개 변수를 topicname/Subscriptions/subscriptionname/$deadletterqueue로 설정합니다.

   자세한 내용은 Service Bus 데드레터 큐 개요를 참조하세요.

문제 해결

워크플로 업데이트 적용 지연

Service Bus 트리거의 폴링 간격이 짧은 경우(예: 10초) 워크플로 업데이트가 최대 10분 동안 적용되지 않을 수 있습니다. 이 문제를 해결하려면 논리 앱 리소스를 사용하지 않도록 설정하고 변경한 다음, 논리 앱 리소스를 다시 사용하도록 설정하면 됩니다.

사용 가능한 세션이 없거나 다른 수신기에 의해 잠겨 있을 수 있음

경우에 따라 메시지 완료 또는 세션 갱신과 같은 작업에서 다음과 같은 오류가 발생합니다.

{
  "status": 400,
  "error": {
    "message": "No session available to complete the message with the lock token 'ce440818-f26f-4a04-aca8-555555555555'."
  }
}

경우에 따라 다음 오류로 인해 세션 기반 트리거가 실패할 수 있습니다.

{
  "status": 400,
  "error": {
    "message": "Communication with the Service Bus namespace 'xxxx' and 'yyyy' entity failed. The requested session 'zzzz' cannot be accepted. It may be locked by another receiver."
  }
}

Service Bus 커넥터는 메모리 내 캐시를 사용하여 세션과 연결된 모든 작업을 지원합니다. Service Bus 메시지 수신기는 메시지를 수신하는 역할 인스턴스(가상 머신)의 메모리에 캐시됩니다. 모든 요청을 처리하기 위해, 모든 연결 호출은 이 동일한 역할 인스턴스로 라우팅됩니다. 세션의 모든 Service Bus 작업에는 특정 세션에 대한 메시지를 수신하는 동일한 수신기가 필요하기 때문에 이 동작이 필요합니다.

인프라 업데이트, 커넥터 배포 등의 이유로 인해 요청이 동일한 역할 인스턴스로 경로 지정되지 않을 가능성이 있습니다. 이 이벤트가 발생하면 다음 이유 중 하나로 인해 요청이 실패합니다.

• 세션에서 작업을 수행하는 수신기는 요청을 수행하는 역할 인스턴스에서 사용할 수 없습니다.

• 새 역할 인스턴스는 이전 역할 인스턴스에서 시간이 초과되었거나 닫혀 있지 않은 세션을 가져오려고 합니다.

이 오류가 가끔 발생하는 한, 이 오류는 예상된 것입니다. 이 오류가 발생해도 메시지는 계속 Service Bus에 유지됩니다. 다음 트리거 또는 워크플로 실행에서 메시지를 다시 처리하려고 시도합니다.

다음 단계

• Azure Logic Apps용 관리형 커넥터
• Azure Logic Apps에 대한 기본 제공 커넥터
• Azure Logic Apps의 커넥터란?