Azure Logic Apps에 대한 제한 및 구성 참조

소비 논리 앱 워크플로의 경우 동일한 설정이 워크플로가 실행될 수 있는 최대 일 수와 실행 기록을 스토리지에 유지하는 최대 일 수를 제어합니다.

• 다중 테넌트 Azure Logic Apps에서 90일 기본 제한은 최대 제한과 동일합니다. 이 값만 줄일 수 있습니다.

예를 들어 보존 제한을 90일에서 30일로 줄인다고 가정합니다. 60일 된 실행은 실행 기록에서 제거됩니다. 보존 기간을 30일에서 60일로 늘리면 20일의 실행이 실행 기록에 40일 더 유지됩니다.

포털

1. Azure Portal 검색 상자의 디자이너에서 논리 앱 워크플로를 엽니다.

2. 논리 앱 메뉴에서 워크플로 설정을 선택합니다.

3. 런타임 옵션 아래의 실행 기록 보존 기간(일) 목록에서 사용자 지정을 선택합니다.

4. 슬라이더를 끌어 원하는 일 수를 변경합니다.

5. 마쳤으면 워크플로 설정 도구 모음에서 저장을 선택합니다.

ARM 템플릿

Azure Resource Manager 템플릿을 사용하는 경우 이 설정은 Microsoft.Logic 워크플로 템플릿 참조에 설명된 워크플로의 리소스 정의에 속성으로 표시됩니다.

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

표준 논리 앱 워크플로의 경우 90일 기본 제한을 줄이거나 늘릴 수 있지만 논리 앱 리소스 또는 프로젝트에 다음 설정과 해당 값을 추가해야 합니다.

• Workflows.RuntimeConfiguration.RetentionInDays라는 앱 설정

• Runtime.FlowMaintenanceJob.RetentionCooldownInterval이라는 호스트 설정

기본적으로 Workflows.RuntimeConfiguration.RetentionInDays라는 앱 설정은 90일의 데이터를 유지하도록 설정됩니다. Runtime.FlowMaintenanceJob.RetentionCooldownInterval이라는 호스트 설정은 7일마다 삭제할 이전 데이터를 확인하도록 설정됩니다. 이러한 기본값을 그대로 두면 최대 97일의 데이터가 표시될 수 있습니다. 예를 들어, Azure Logic Apps가 X일에 확인하고, X일~90일보다 오래된 데이터를 삭제한 다음, 다시 실행하기 전에 7일 동안 기다린다고 가정합니다. 이 동작으로 인해 작업이 다시 실행되기까지 최대 97일이 되는 데이터가 생성됩니다. 그러나 간격을 1일로 설정했지만 보존 기간(일)을 기본값으로 유지하면 이전 데이터를 삭제할 최대 지연은 90+1일입니다.

포털

1. 다음 단계에 따라 Workflows.RuntimeConfiguration.RetentionInDays라는 앱 설정을 추가하고 워크플로 실행 기록을 유지하려는 일 수로 값을 설정합니다.

2. 다음 단계에 따라 Runtime.FlowMaintenanceJob.RetentionCooldownInterval이라는 호스트 설정을 추가하고 유지하지 않으려는 실행 기록을 확인할 시기와 삭제할 시기 간 간격의 일 수로 값을 설정합니다.

Visual Studio Code

1. 다음 단계에 따라 Workflows.RuntimeConfiguration.RetentionInDays라는 앱 설정을 추가하고 워크플로 실행 기록을 유지하려는 일 수로 값을 설정합니다.

2. 다음 단계에 따라 Runtime.FlowMaintenanceJob.RetentionCooldownInterval이라는 호스트 설정을 추가하고 유지하지 않으려는 실행 기록을 확인할 시기와 삭제할 시기 간 간격의 일 수로 값을 설정합니다.

단일 테넌트 Azure Logic Apps에서 표준 논리 앱 리소스는 스토리지 및 컴퓨팅을 기본 리소스로 사용하여 워크플로를 실행합니다.

스토리지

단일 테넌트 Azure Logic Apps의 상태 저장 워크플로는 런타임 동안 영구 데이터 스토리지에 Azure Table Storage를 사용하고, 워크플로 실행 기록을 유지 관리하기 위해 Azure Blob Storage를 사용하고, 예약을 위해 Azure Queue Storage를 사용합니다. 예를 들어 단일 스토리지 계정을 사용하면 파티션당 최대 2,000개의 요청과 스토리지 계정 수준에서 초당 20,000개 요청의 속도로 상당한 수의 요청을 처리할 수 있습니다. 단일 스토리지 계정은 이러한 임계값을 초과하여 상당히 높은 처리량을 처리할 수 있지만 요청 속도는 제한될 수 있으며 워크플로 실행 속도가 증가함에 따라 워크플로에 파티션 수준 제한 또는 계정 수준 제한이 발생할 수 있습니다. 워크플로가 원활하게 작동하도록 하려면 가능한 제한 사항과 이를 해결할 수 있는 방법을 이해하는 것이 중요합니다.

다양한 Azure Storage 서비스의 크기 조정 대상 및 제한 사항에 대한 자세한 내용은 다음 설명서를 참조하세요.

• Table Storage에 대한 대상 크기 조정
• Table Storage에 대한 데이터 작업 대상
• Blob Storage에 대한 대상 크기 조정
• Queue Storage에 대한 대상 크기 조정

스토리지 제한에 맞게 논리 앱 크기 조정

다음 권장 사항은 표준 논리 앱 워크플로 크기 조정에 적용됩니다.

• 여러 워크플로에서 워크로드를 공유합니다.

  단일 테넌트 Azure Logic Apps는 이미 여러 파티션에 스토리지 트랜잭션을 분산하여 파티션 수준 제한을 최소화합니다. 그러나 배포를 개선하고 파티션 수준 제한을 완화하려면 단일 워크플로에 의존하지 않고 여러 워크플로에 워크로드를 분산합니다.

• 여러 스토리지 계정에서 워크로드를 공유합니다.

  워크플로에 높은 처리량이 필요한 경우 단일 스토리지 계정에 의존하지 않고 여러 스토리지 계정에 워크로드를 분산하여 처리량을 크게 늘릴 수 있습니다. 최대 32개의 스토리지 계정을 제한으로 사용하도록 표준 논리 앱 리소스를 설정할 수 있습니다. 필요한 스토리지 계정 수를 확인하려면 스토리지 계정당 분당 최대 100,000개의 작업 실행을 목표로 하는 일반적인 지침을 사용합니다. 이 예상치는 대부분의 시나리오에서 잘 작동하지만 워크플로 작업이 계산이 많은 경우(예: 큰 데이터 배열을 처리하는 쿼리 작업) 더 적은 수의 작업 실행을 사용할 수 있습니다. 프로덕션 환경에서 사용하기 전에 부하 테스트를 수행하고 솔루션을 조정해야 합니다.

  여러 스토리지 계정을 사용하도록 설정하려면 표준 논리 앱을 만들기 전에 다음 단계를 수행합니다. 그렇지 않은 경우 만든 후 설정을 변경하면 데이터 손실이 발생하거나 필요한 확장성을 달성하지 못할 수 있습니다.

  1. 사용하려는 스토리지 계정을 만듭니다 . 각 스토리지 계정에 대한 연결 문자열 저장합니다.

  2. 표준 논리 앱을 찾아서 연 다음, Runtime.ScaleUnitsCount 설정이 있는 개체 및 settings 개체를 포함하는 workflow 다음 extensions 개체를 포함하도록 논리 앱의 호스트 설정(host.json 파일)을 편집합니다.

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     다음 예제에서는 스토리지 계정 수로 3을 지정합니다.

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. 논리 앱의 애플리케이션 구성 설정(local.settings.json)을 편집하여 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number>라는 앱 설정을 추가합니다. ConnectionString 및 해당 스토리지 계정은 첫 번째 스토리지 계정 번호가 스토리지 계정 수 00 에서 1을 뺀 다음 구문을 사용하여 연결 문자열 있습니다. 예를 들면 다음과 같습니다.

     앱 설정 이름	값
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     Important

     사용자 이름과 암호가 포함된 연결 문자열과 같은 중요한 정보가 있는 경우 사용 가능한 가장 안전한 인증 흐름을 사용해야 합니다. 예를 들어, 표준 논리 앱 워크플로에서는 securestring 및 secureobject와 같은 보안 데이터 형식이 지원되지 않습니다. 가능한 경우 관리 ID를 사용하여 Azure 리소스에 대한 액세스를 인증하고 필요한 최소한의 권한이 있는 역할을 할당하는 것이 좋습니다.

     이 기능을 사용할 수 없는 경우 앱 설정과 함께 사용할 수 있는 Azure Key Vault와 같은 다른 측정값을 통해 연결 문자열을 보호해야 합니다. 그런 다음 연결 문자열 및 키와 같은 보안 문자열을 직접 참조할 수 있습니다. 배포 시 환경 변수를 정의할 수 있는 ARM 템플릿과 마찬가지로 논리 앱 워크플로 정의 내에서 앱 설정을 정의할 수 있습니다. 그런 다음, 연결 엔드포인트, 스토리지 문자열 등 동적으로 생성된 인프라 값을 캡처할 수 있습니다. 자세한 내용은 Microsoft ID 플랫폼을 사용하여 애플리케이션 등록을 참조하세요.

  4. 논리 앱의 애플리케이션 구성 설정에서 AzureWebJobsStorage 설정 값을 CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString 설정에 있는 것과 동일한 연결 문자열 업데이트합니다.

Compute

표준 논리 앱은 다양한 수준의 가상 CPU 및 메모리를 제공하는 사용 가능한 컴퓨팅 계획 중 하나를 사용하거나 더 많은 컴퓨팅 옵션을 제공하는 App Service Environment v3을 사용하여 실행됩니다.

단일 테넌트 Azure Logic Apps는 증가하는 부하를 효과적으로 처리하도록 동적으로 확장됩니다. 논리 앱은 다음과 같은 기본 요소를 사용하여 크기를 조정할지 여부를 결정합니다.

• 트리거

  크기 조정 요구 사항을 결정하기 위해 scaler는 논리 앱에서 각 워크플로를 시작하는 트리거를 분석합니다. 예를 들어 Service Bus 트리거가 있는 워크플로의 경우 큐 길이가 지속적으로 증가하는 경우 스케일러가 작업자 인스턴스를 추가하는 작업을 수행하여 더 많은 메시지를 처리할 수 있습니다. 마찬가지로 요청 트리거가 있는 워크플로의 경우 요청 대기 시간이 상승 추세를 경험하는 경우 스케일러가 작업자 인스턴스 수를 늘려 요청 부하를 보다 효율적으로 분산합니다. 작업자 인스턴스에 대한 자세한 내용은 Azure Logic Apps(표준) - 런타임 심층 분석을 참조 하세요.

• 워크플로 작업 실행 지연

  런타임에 워크플로 작업은 실행을 위해 대기 중인 개별 작업으로 나뉩니다. 작업 디스패처는 정기적으로 작업 큐를 폴링하여 이러한 작업을 검색하고 실행합니다. 그러나 컴퓨팅 용량이 이러한 작업을 선택하기에 충분하지 않은 경우 더 긴 시간 동안 큐에 유지되므로 실행 지연이 증가합니다. Scaler는 이 상황을 모니터링하고 실행 지연을 제어하기 위해 크기 조정 결정을 내립니다. 런타임이 작업을 예약하고 실행하는 방법에 대한 자세한 내용은 Azure Logic Apps(표준) - 런타임 심층 분석을 참조 하세요.

  또한 Scaler는 최소 및 최대 작업자 인스턴스 카운터 구성을 고려하여 현재 작업자 인스턴스 수 추가, 제거 또는 유지 관리와 같은 크기 조정 결정을 내릴지 여부를 결정합니다. 일반적으로 배율 조정기에서는 약 15~30초 간격으로 이러한 결정을 내립니다. 따라서 최대 부하를 효과적으로 처리할 수 있도록 이 램프업 시간과 논리 앱의 크기 조정 속도에 미치는 영향을 고려합니다. 예를 들어 워크로드에서 논리 앱을 1개의 작업자 인스턴스에서 100개의 작업자 인스턴스로 확장해야 하는 경우 램프업만으로도 25~50분이 걸릴 수 있습니다. 단일 테넌트 Azure Logic Apps 크기 조정은 동일한 Azure Functions 크기 조정 인프라를 공유합니다.

더 빠른 크기 조정을 위해 논리 앱 컴퓨팅 구성

• 여러 논리 앱에서 워크로드를 공유합니다.

  각 논리 앱은 독립적으로 크기를 조정할 수 있으므로 둘 이상의 논리 앱에 워크로드를 분산하면 크기 조정 속도가 크게 빨라질 수 있습니다. 예를 들어 두 논리 앱은 단일 논리 앱과 동일한 기간에 작업자 인스턴스 수의 두 배로 확장할 수 있습니다. 여러 앱 간에 워크로드를 분할하면 확장성을 효과적으로 곱하고 더 빠른 크기 조정 결과를 얻을 수 있습니다.

• 미리 준비된 인스턴스를 사용합니다.

  시나리오에 더 빠른 진입 시간이 필요한 경우 미리 설치된 인스턴스를 사용하는 것이 좋습니다. 최대 로드 시간이 결정적이면 자동화 작업을 사용하여 일정에 따라 이러한 전전 인스턴스를 조정할 수 있습니다. 자세한 내용은 자동화 작업(미리 보기)을 만들어 Azure 리소스 관리 및 비용 모니터링을 참조하세요.

다중 테넌트 Azure Logic Apps에는 5분마다 실행되는 작업 수에 대한 기본 제한이 있습니다. 기본값을 최대값으로 올리려면 미리 보기 상태인 높은 처리량 모드를 사용하도록 설정할 수 있습니다. 또는 단일 논리 앱 및 워크플로에 의존하지 않고 여러 논리 앱 및 워크플로에 워크로드를 분산합니다.

포털에서 높은 처리량 사용

1. Azure Portal의 논리 앱 메뉴에 있는 설정에서 워크플로 설정을 선택합니다.

2. 런타임 옵션>높은 처리량에서 설정을 켜기로 변경합니다.

   

Resource Manager 템플릿에서 높은 처리량 사용

논리 앱을 배포하기 위해 ARM 템플릿에서 이 설정을 사용하도록 설정하려면 논리 앱의 리소스 정의에 대한 개체에서 properties 속성이 다음과 같이 operationOptions 설정된 개체를 OptimizedForHighThroughput추가 runtimeConfiguration 합니다.

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

논리 앱 리소스 정의에 대한 자세한 내용은 개요: Azure Resource Manager 템플릿을 사용하여 Azure Logic Apps에 대한 배포 자동화를 검토 하세요.