Azure Logic Apps에서 워크플로 오류를 진단하고 해결

  • 아티클

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

논리 앱은 앱 워크플로에서 문제를 진단하고 디버깅하도록 도울 수 있는 정보를 생성합니다. Azure Portal을 사용하여 워크플로의 각 단계에 대한 입력, 출력 및 기타 정보를 검토하여 워크플로를 진단할 수 있습니다. 또는 런타임 디버깅을 위해 워크플로에 몇 가지 단계를 추가할 수 있습니다.

트리거 기록 확인

각 워크플로 실행은 일정에 따라 실행되거나 들어오는 요청 또는 이벤트를 기다리는 트리거로 시작합니다. 트리거 기록은 워크플로가 수행한 모든 트리거 시도 및 각 트리거 시도의 입력과 출력에 대한 정보를 나열합니다. 트리거가 실행되지 않으면 다음 단계를 시도합니다.

  1. 소비 논리 앱에서 트리거의 상태를 확인하려면 트리거 기록을 검토합니다. 트리거를 시도하는 방법에 대한 자세한 정보를 보려면 해당 트리거 이벤트를 선택합니다. 예를 들면 다음과 같습니다.

    Screenshot showing Azure portal with Consumption logic app workflow trigger history.

  2. 트리거의 입력을 확인하여 원하는 대로 나타나는지 확인합니다. 기록 창의 입력 링크에서 입력 창을 표시하는 링크를 선택합니다.

    트리거 입력에는 트리거에 필요한 데이터와 워크플로를 시작하는 데 필요한 데이터가 포함됩니다. 이러한 입력을 검토하면 트리거 입력이 올바른지, 조건이 충족 되었는지 여부를 확인하여 워크플로를 계속 진행할 수 있습니다.

    Screenshot showing Consumption logic app workflow trigger inputs.

  3. 트리거 출력이 있는 경우 이를 확인하여 원하는 대로 나타나는지 확인합니다. 기록 창의 출력 링크에서 출력 창을 표시하는 링크를 선택합니다.

    트리거 출력에는 트리거에서 워크플로의 다음 단계로 전달되는 데이터가 포함됩니다. 이러한 출력을 검토하면 워크플로의 다음 단계로 올바른 값 또는 예상 값이 전달되었는지 여부를 확인할 수 있습니다.

    예를 들어 RSS 피드를 찾을 수 없다는 오류 메시지가 표시됩니다.

    Screenshot showing Consumption logic app workflow trigger outputs.

    팁

    인식하지 못하는 콘텐츠가 있으면 Azure Logic Apps의 다양한 콘텐츠 형식에 대해 자세히 알아보세요.

워크플로 실행 기록 확인

트리거가 발생할 때마다 Azure Logic Apps는 워크플로 인스턴스를 만들고 해당 인스턴스를 실행합니다. 실행이 실패하는 경우 다음 단계를 시도하여 해당 실행 중에 발생한 작업을 검토할 수 있습니다. 워크플로의 각 단계에 대한 상태, 입력 및 출력을 검토할 수 있습니다.

  1. 소비 논리 앱에서 워크플로의 실행 상태를 확인하려면 실행 기록을 검토합니다. 해당 상태에서 실행되는 모든 단계를 포함하여 실패한 실행에 대한 자세한 정보를 보려면 실패한 실행을 선택합니다.

    Screenshot showing Azure portal with Consumption logic app workflow runs and a failed run selected.

  2. 실행의 모든 단계가 나타나면 각 단계를 선택하여 셰이프를 확장합니다.

    Screenshot showing Consumption logic app workflow with failed step selected.

  3. 실패한 단계에 대한 입력, 출력 및 오류 메시지를 검토합니다.

    Screenshot showing Consumption logic app workflow with failed step details.

    예를 들어 다음 스크린샷은 실패한 RSS 작업의 출력을 보여 줍니다.

    Screenshot showing Consumption logic app workflow with failed step outputs.

런타임 디버깅 수행

디버깅에 도움을 주려면 트리거 및 실행 기록을 검토하는 한편, 논리 앱 워크플로에 진단 단계를 추가합니다. 예를 들어, HTTP 요청을 검사하고 정확한 해당 크기, 모양 및 형식을 확인할 수 있도록 Webhook Tester 서비스를 사용하는 단계를 추가할 수 있습니다.

  1. 브라우저에서 Webhook Tester 사이트로 이동하여 생성된 고유 URL을 복사합니다.

  2. 논리 앱에서 테스트하려는 본문 콘텐츠(예: 식, 다른 단계 출력)를 포함하는 HTTP POST 작업을 추가합니다.

  3. Webhook Tester의 URL을 HTTP POST 작업에 붙여 넣습니다.

  4. Azure Logic Apps이 요청을 생성하고 구성하는 방법을 검토하려면 논리 앱 워크플로를 실행합니다. 그런 다음 Webhook Tester 사이트를 다시 방문하여 자세한 내용을 확인할 수 있습니다.

성능 - FAQ(질문과 대답)

워크플로 실행 기간이 모든 워크플로 작업 기간의 합계보다 긴 이유는 무엇인가요?

작업 실행 시 오버헤드 스케줄링이 존재하지만 백 엔드 시스템 로드로 인해 작업 간 대기 시간이 발생할 수 있습니다. 워크플로 실행 기간에는 모든 작업 기간의 합계와 함께 이러한 예약 시간 및 대기 시간이 포함됩니다.

일반적으로 내 워크플로는 10초 이내에 완료됩니다. 그러나 경우에 따라 완료하는 데 훨씬 더 오래 걸릴 수 있습니다. 워크플로가 항상 10초 이내에 완료되도록 하려면 어떻게 해야 하나요?

  • 대기 시간에는 SLA 보장이 없습니다.

  • 소비 워크플로는 다중 테넌트 Azure Logic Apps에서 실행되므로 다른 고객의 워크로드는 워크플로의 성능에 부정적인 영향을 줄 수 있습니다.

  • 보다 예측 가능한 성능을 위해 단일 테넌트 Azure Logic Apps에서 실행되는 표준 워크플로를 만드는 것이 좋습니다. 성능을 향상시키기 위해 스케일 업 또는 스케일 아웃할 수 있는 더 많은 제어 권한이 있습니다.

내 작업은 2분 후에 시간 초과됩니다. 시간 제한 값을 늘리려면 어떻게 해야 하나요?

작업 시간 제한 값은 변경할 수 없으며 2분으로 고정됩니다. HTTP 작업을 사용하고 있고 HTTP 작업에서 호출한 서비스를 소유하고 있는 경우 비동기 패턴을 사용하여 2분 시간 제한을 방지하도록 서비스를 변경할 수 있습니다. 자세한 내용은 폴링 작업 패턴을 사용하여 장기 실행 작업 수행을 검토하세요.

일반적인 문제 - 표준 논리 앱

Azure Storage 계정에서 액세스할 수 없는 아티팩트

표준 논리 앱은 모든 아티팩트를 Azure Storage 계정에 저장합니다. 이러한 아티팩트에 액세스할 수 없는 경우 다음과 같은 오류가 발생할 수 있습니다. 예를 들어 스토리지 계정 자체에 액세스할 수 없거나 스토리지 계정이 방화벽 뒤에 있지만 스토리지 서비스에서 사용할 프라이빗 엔드포인트가 설정되지 않았습니다.

Azure Portal 위치 오류
개요 창 - System.private.corelib:경로 ‘C:\home\site\wwwroot\hostj.son’에 대한 액세스가 거부됨

- Azure.Storage.Blob: 이 요청은 이 작업을 수행할 권한이 없음
워크플로 창 - 호스트 런타임에 연결할 수 없습니다. 오류 세부 정보, 코드: ‘BadRequest’, 메시지: ‘호스트 런타임에서 오류(InternalServerError)가 발생했습니다.’

- 호스트 런타임에 연결할 수 없습니다. 오류 세부 정보, 코드: ‘BadRequest’, 메시지: ‘호스트 런타임에서 오류(ServiceUnavailable)가 발생했습니다.’

- 호스트 런타임에 연결할 수 없습니다. 오류 세부 정보, 코드: ‘BadRequest’, 메시지: ‘호스트 런타임에서 오류(BadGateway)가 발생했습니다.’
워크플로 만들기 및 실행 중 - 워크플로를 저장하지 못함

- 디자이너의 오류: GetCallFailed. 페치 작업 실패

- ajaxExtended 호출 실패

문제 해결 옵션

다음 목록에는 이러한 오류의 가능한 원인과 문제를 해결하는 데 도움이 되는 단계가 포함되어 있습니다.

  • 퍼블릭 스토리지 계정의 경우 다음과 같은 방법으로 스토리지 계정에 대한 액세스를 확인합니다.

    연결에 실패하는 경우 연결 문자열의 SAS(공유 액세스 서명) 키가 가장 최근 키인지 확인합니다.

  • 방화벽 뒤에 있는 스토리지 계정인 경우 다음과 같은 방법으로 스토리지 계정에 대한 액세스를 확인합니다.

    • 스토리지 계정에서 방화벽 제한을 사용하는 경우 Blob, 파일, 테이블 및 큐 스토리지 서비스에 대해 프라이빗 엔드포인트가 설정되어 있는지 확인합니다.

    • Azure Storage Explorer를 사용하여 스토리지 계정의 연결을 확인합니다.

    연결 문제가 있으면 다음 단계로 계속합니다.

    1. 논리 앱과 통합된 동일한 가상 네트워크에서 다른 서브넷에 넣을 수 있는 Azure 가상 머신을 만듭니다.

    2. 명령 프롬프트에서 nslookup을 실행하여 Blob, 파일, 테이블 및 큐 스토리지 서비스가 예상된 IP 주소로 확인되는지 검사합니다.

      구문: nslookup [StorageaccountHostName] [OptionalDNSServer]

      Blob: nslookup {StorageaccountName}.blob.core.windows.net

      파일: nslookup {StorageaccountName}.file.core.windows.net

      테이블: nslookup {StorageaccountName}.table.core.windows.net

      큐: nslookup {StorageaccountName}.queue.core.windows.net

      • 스토리지 서비스에 서비스 엔드포인트가 있는 경우 서비스는 공용 IP 주소로 확인됩니다.

      • 스토리지 서비스에 프라이빗 엔드포인트가 있는 경우 서비스는 해당 NIC(네트워크 인터페이스 컨트롤러) 개인 IP 주소로 확인됩니다.

    3. 이전 DNS(도메인 이름 서버) 쿼리가 성공적으로 확인되면 psping 또는 tcpping 명령을 실행하여 포트 443을 통해 스토리지 계정에 대한 연결을 확인합니다.

      구문: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

      Blob: psping {StorageaccountName}.blob.core.windows.net:443

      파일: psping {StorageaccountName}.file.core.windows.net:443

      테이블: psping {StorageaccountName}.table.core.windows.net:443

      큐: psping {StorageaccountName}.queue.core.windows.net:443

    4. Azure 가상 머신에서 각 스토리지 서비스를 확인할 수 있는 경우 확인을 위해 가상 머신에서 사용하는 DNS를 찾습니다.

      1. 논리 앱의 WEBSITE_DNS_SERVER 앱 설정을 DNS로 설정하고 DNS가 성공적으로 작동하는지 확인합니다.

      2. 표준 논리 앱에서 VNet 통합이 적절한 가상 네트워크 및 서브넷을 사용해 올바르게 설정되었는지 확인합니다.

    5. 스토리지 계정의 프라이빗 엔드포인트 서비스에 프라이빗 Azure DNS 영역을 사용하는 경우 논리 앱의 통합 가상 네트워크에 가상 네트워크 링크 가 만들어졌는지 확인합니다.

자세한 내용은 서비스 또는 프라이빗 엔드포인트를 사용하여 방화벽 뒤에 있는 스토리지 계정에 표준 논리 앱 배포를 검토하세요.

다음 단계