단일 테넌트 Azure Logic Apps에서 표준 논리 앱의 호스트 및 앱 설정 편집
적용 대상: Azure Logic Apps(표준)
단일 테넌트 Azure Logic Apps에서 표준 논리 앱의 앱 설정에는 해당 논리 앱의 모든 워크플로에 영향을 주는 글로벌 구성 옵션을 지정합니다. 단, 이 설정은 로컬 개발 환경에서 이러한 워크플로가 실행될 때에만 적용됩니다. 로컬에서 실행 중인 워크플로는 로컬 환경 변수로 이러한 앱 설정에 액세스할 수 있으며, 이는 환경 간에 자주 변경될 수 있는 값의 로컬 개발 도구에서 사용됩니다. 예를 들어 이러한 값에는 연결 문자열이 포함될 수 있습니다. Azure에 배포할 경우 앱 설정은 무시되며 배포에 포함되지 않습니다.
또한 논리 앱에는 해당 논리 앱의 모든 워크플로에 적용되는 런타임 구성 설정 및 값을 지정하는 호스트 설정도 있습니다(예: 처리량, 용량, 데이터 크기 등의 기본값, 로컬에서 또는 Azure에서 실행되는지 여부).
앱 설정, 매개 변수 및 배포
다중 테넌트 Azure Logic Apps에서 배포는 논리 앱과 인프라 둘 다에 대한 리소스 프로비전을 결합하고 처리하는 ARM 템플릿(Azure Resource Manager 템플릿)을 바탕으로 합니다. 이 설계는 다양한 개발, 테스트 및 프로덕션 환경에서 논리 앱의 환경 변수를 유지 관리해야 할 때 문제가 됩니다. ARM 템플릿의 모든 항목은 배포 시 정의됩니다. 따라서 한 가지 변수만 변경해야 하더라도 모든 항목을 다시 배포해야 합니다.
단일 테넌트 Azure Logic Apps에서는 앱과 인프라 간에 리소스 프로비전을 구분할 수 있으므로 배포가 더 쉬워집니다. 매개 변수를 사용하여 환경 간에 바뀔 수 있는 값을 추출할 수 있습니다. 워크플로에서 사용할 매개 변수를 정의하면 먼저 워크플로 설계에 집중하고 나중에 환경별 변수를 삽입할 수 있습니다. 앱 설정 및 매개 변수를 사용하면 런타임에서 환경 변수를 호출하고 참조할 수 있습니다. 이렇게 하면 자주 다시 배포할 필요가 없습니다.
앱 설정은 Azure Key Vault와 통합됩니다. 연결 문자열 및 키와 같은 보안 문자열을 직접 참조할 수 있습니다. 배포 시 환경 변수를 정의할 수 있는 ARM 템플릿(Azure Resource Manager 템플릿)과 마찬가지로 논리 앱 워크플로 정의 내에서 앱 설정을 정의할 수 있습니다. 그런 다음, 연결 엔드포인트, 스토리지 문자열 등 동적으로 생성된 인프라 값을 캡처할 수 있습니다. 단, 앱 설정에는 크기 제한이 있으며 Azure Logic Apps의 특정 영역에서는 참조가 불가능합니다.
참고 항목
Key Vault를 사용하는 경우 암호, 자격 증명, 인증서 등의 비밀만 저장해야 합니다. 논리 앱 워크플로에서 Key Vault를 사용하여 워크플로 디자이너가 호출해야 하는 URL 경로와 같은 비밀이 아닌 값을 저장하지 마세요. 디자이너는 Key Vault 리소스 종류를 참조하는 앱 설정을 역참조할 수 없으며, 이로 인해 오류가 발생하고 호출이 실패합니다. 비밀이 아닌 값의 경우 앱 설정에 직접 저장합니다.
배포를 위한 논리 앱 설정에 대한 자세한 내용은 다음 설명서를 참조하세요.
- 환경마다 워크플로에서 바뀌는, 단일 테넌트 Azure Logic Apps 값에 대한 매개 변수 만들기
- 단일 테넌트 기반 논리 앱에 대한 DevOps 배포 개요
- 단일 테넌트 기반 논리 앱에 대한 DevOps 배포 설정
Visual Studio Code 프로젝트 구조
Visual Studio Code에서 논리 앱 프로젝트에는 다음 형식 중 하나가 있습니다.
- 기본 형식인 확장 번들 기반(Node.js)
- 기본 형식에서 변환할 수 있는 NuGet 패키지 기반(.NET)
이러한 형식에 따라 프로젝트에는 약간 다른 폴더와 파일이 포함됩니다. NuGet 기반 프로젝트에는 패키지 및 기타 라이브러리 파일이 포함된 .bin 폴더가 포함되어 있습니다. 번들 기반 프로젝트에는 .bin 폴더 및 기타 파일이 포함되지 않습니다. 일부 시나리오에서는 사용자 지정 기본 제공 작업을 개발하고 실행하려는 경우와 같이 앱을 실행하기 위해 NuGet 기반 프로젝트가 필요합니다. NuGet을 사용하도록 프로젝트를 변환하는 방법을 자세히 알아보려면 기본 제공 커넥터 작성 사용을 검토하세요.
기본 번들 기반 프로젝트의 경우 프로젝트에는 다음 예제와 유사한 폴더 및 파일 구조가 있습니다.
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
프로젝트의 루트 수준에서 다른 항목이 있는 다음 파일 및 폴더를 찾을 수 있습니다.
| 이름 | 폴더 또는 파일 | 설명 |
|---|---|---|
| .vscode | 폴더 | extensions.json, launch.json, settings.json 및 tasks.json 파일과 같은 Visual Studio Code 관련 설정 파일을 포함합니다. |
| 아티팩트 | 폴더 | B2B(Business-to-Business) 시나리오를 지원하는 워크플로에서 정의하고 사용하는 통합 계정 아티팩트를 포함합니다. 예를 들어 예제 구조에는 XML 변환 및 유효성 검사 작업에 대한 맵과 스키마가 포함됩니다. |
| <WorkflowName> | 폴더 | 각 워크플로에 대한 <WorkflowName> 폴더에는 워크플로의 기본 JSON 정의를 포함하는 workflow.json 파일이 포함됩니다. |
| workflow-designtime | 폴더 | 개발 환경 관련 설정 파일을 포함합니다. |
| .funcignore | 파일 | 설치된 Azure Functions Core Tools 관련 정보를 포함합니다. |
| connections.json | 파일 | 워크플로에서 사용하는 관리형 연결 및 Azure 함수에 대한 메타데이터, 엔드포인트 및 키를 포함합니다. 중요: 각 환경에 대해 서로 다른 연결과 함수를 사용하려면 이 connections.json 파일을 매개 변수화하고 엔드포인트를 업데이트해야 합니다. |
| host.json | 파일 | 런타임 관련 구성 설정 및 값(예: 단일 테넌트 Azure Logic Apps 플랫폼, 논리 앱, 워크플로, 트리거 및 작업에 대한 기본 제한)이 포함되어 있습니다. 논리 앱 프로젝트의 루트 수준에서 host.json 메타데이터 파일에는 로컬 또는 Azure에 상관없이 동일한 논리 앱의 모든 워크플로가 실행되는 동안 사용하는 구성 설정 및 기본값이 포함됩니다. 참고: 논리 앱을 만들 때 Visual Studio Code는 스토리지 컨테이너에 backup host.snapshot.*.json 파일을 만듭니다. 논리 앱을 삭제해도 이 백업 파일은 삭제되지 않습니다. 이름이 같은 다른 논리 앱을 만들면 다른 스냅샷 파일이 만들어집니다. 동일한 논리 앱에 대해 최대 10개의 스냅샷만 포함할 수 있습니다. 이 제한을 초과하면 다음 오류가 발생합니다. Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) 이 오류를 해결하려면 스토리지 컨테이너에서 추가 스냅샷 파일을 삭제합니다. |
| local.settings.json | 파일 | 로컬에서 실행하는 동안 워크플로에 사용되는 앱 설정, 연결 문자열 및 기타 설정을 포함합니다. 즉, 이러한 설정 및 값은 로컬 개발 환경에서 프로젝트를 실행하는 경우에만 적용됩니다. Azure에 배포하는 동안 파일 및 설정이 무시되고 배포에 포함되지 않습니다. 이 파일은 로컬 개발 도구에서 appSettings 값으로 사용하는 로컬 환경 변수로 설정 및 값을 저장합니다. 앱 설정 및 매개 변수를 사용하여 런타임 및 배포 시에 이러한 환경 변수를 호출하고 참조할 수 있습니다. 중요: local.settings.json 파일은 비밀을 포함할 수 있으므로 프로젝트 원본 제어에서 이 파일을 제외해야 합니다. |
앱 설정 참조 - local.settings.json
Visual Studio Code의 논리 앱 프로젝트의 루트 수준에서 local.settings.json 파일에는 로컬 개발 환경에서 실행되는 동안 해당 논리 앱의 모든 워크플로에 영향을 주는 전역 구성 옵션이 포함됩니다. 워크플로가 로컬에서 실행될 때 이러한 설정은 로컬 환경 변수로 액세스되며, 워크플로를 실행하는 다양한 환경 간에 해당 값이 바뀔 수 있습니다. 이러한 설정을 보고 관리하려면 앱 설정 관리 - local.settings.json을 참조하세요.
Azure Logic Apps의 앱 설정은 Azure Functions 또는 Azure Web Apps의 앱 설정과 유사하게 작동합니다. 이러한 다른 서비스를 이전에 사용한 적이 있다면 앱 설정에 이미 익숙할 수 있습니다. 자세한 내용은 Azure Functions의 앱 설정 참조 및 Azure Functions Core Tools 작업 - 로컬 설정 파일을 참조하세요.
| 설정 | 기본값 | 설명 |
|---|---|---|
AzureWebJobsStorage |
None | Azure Storage 계정에 대한 연결 문자열을 설정합니다. 자세한 내용은 AzureWebJobsStorage를 참조하세요. |
FUNCTIONS_WORKER_RUNTIME |
node |
논리 앱 리소스 및 워크플로에 사용할 언어 작업자 런타임을 설정합니다. 그러나 다국어 지원이 자동으로 사용하도록 설정되므로 이 설정은 더 이상 필요하지 않습니다. 자세한 내용은 FUNCTIONS_WORKER_RUNTIME을 참조하세요. |
ServiceProviders.Sftp.FileUploadBufferTimeForTrigger |
00:00:20 (20초) |
현재 시간보다 큰 마지막으로 수정된 타임스탬프가 있는 파일을 무시하도록 버퍼 시간을 설정합니다. 이 설정은 대용량 파일 쓰기에 시간이 오래 걸리고 부분적으로 작성된 파일에 대한 데이터를 가져오지 않을 때 유용합니다. |
ServiceProviders.Sftp.OperationTimeout |
00:02:00 (2분) |
모든 작업에서 시간이 초과되기 전에 대기할 시간을 설정합니다. |
ServiceProviders.Sftp.ServerAliveInterval |
00:30:00 (30분) |
지정된 기간 동안 서버와의 데이터 교환이 발생하지 않는 경우 SSH 연결을 활성 상태로 유지하기 위해 "활성 상태 유지" 메시지를 보냅니다. |
ServiceProviders.Sftp.SftpConnectionPoolSize |
2개 연결 |
각 프로세서가 캐시할 수 있는 연결 수를 설정합니다. 캐시할 수 있는 총 연결 수는 ProcessorCount에 설정 값을 곱한 것입니다. |
ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
10 KB(~1,000 파일) |
모니터링되는 폴더의 파일 수에 비례하고 파일을 검색하는 데 사용되는 트리거 상태 엔터티 크기를 킬로바이트 단위로 설정합니다. 파일 수가 1,000개를 초과하면 이 값을 늘입니다. |
ServiceProviders.Sql.QueryTimeout |
00:02:00 (2분) |
SQL 서비스 공급자 작업에 대한 요청 제한 시간 값을 설정합니다. |
WEBSITE_LOAD_ROOT_CERTIFICATES |
None | 신뢰할 수 있는 루트 인증서의 지문을 설정합니다. |
Workflows.Connection.AuthenticationAudience |
없음 | 관리되는 (Azure 호스팅) 연결을 인증할 대상 그룹을 설정합니다. |
Workflows.CustomHostName |
없음 | 워크플로 및 입력-출력 URL에 사용할 호스트 이름을 설정합니다(예: "logic.contoso.com"). 사용자 지정 DNS 이름을 구성하는 방법에 대한 자세한 내용은 기존 사용자 지정 DNS 이름을 Azure App Service에 매핑 및 Azure App Service에서 TLS/SSL 바인딩을 사용하여 사용자 지정 DNS 이름 보안을 참조하세요. |
Workflows.<workflowName>.FlowState |
없음 | <workflowName>의 상태를 설정합니다. |
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays |
없음 | <workflowName>에 대한 실행 기록을 유지하는 데 걸리는 시간(일)을 설정합니다. |
Workflows.RuntimeConfiguration.RetentionInDays |
90일 |
실행이 시작된 후 워크플로 실행 기록을 유지하는 시간(일)을 설정합니다. |
Workflows.WebhookRedirectHostUri |
없음 | 웹후크 콜백 URL에 사용할 호스트 이름을 설정합니다. |
앱 설정 관리 - local.settings.json
앱 설정을 추가, 업데이트 또는 삭제하려면 Azure Portal, Visual Studio Code, Azure CLI 또는 ARM(Bicep) 템플릿에 대한 다음 섹션을 선택하고 검토합니다. 논리 앱별 앱 설정은 사용할 수 있는 앱 설정에 대한 참조 가이드 - local.settings.json을 참조하세요.
포털에서 앱 설정 보기
Azure Portal 검색 상자에서 논리 앱을 찾아 선택합니다.
논리 앱 메뉴의 설정에서 환경 변수를 선택합니다.
환경 변수 페이지의 앱 설정 탭에서 논리 앱에 대한 앱 설정을 검토합니다.
이러한 설정에 대한 자세한 내용은 사용할 수 있는 앱 설정에 대한 참조 가이드 - local.settings.json을 참조하세요.
모든 값을 보려면 값 표시를 선택합니다. 또는 단일 값을 보려면 값 옆에 있는 값 열에서 "eye"를 선택합니다.
포털에서 앱 설정 추가
앱 설정 탭의 목록 하단에 있는 이름 열에 새 설정에 대한 키 또는 이름을 입력합니다.
값에 새 설정의 값을 입력합니다.
새 키-값 쌍을 만들 준비가 되면 적용을 선택합니다.
호스트 설정에 대한 참조 - host.json
Visual Studio Code에서는 논리 앱 프로젝트의 루트 수준에서 host.json 메타데이터 파일에 로컬에서 또는 Azure에서 실행하든 관계 없이 논리 앱 리소스의 모든 워크플로에 적용되는 런타임 설정 및 기본값이 포함됩니다. 이러한 설정을 보고 관리하려면 호스트 설정 관리 - host.json을 참조하세요. 또한 Azure Logic Apps 설명서의 제한 및 구성에서 관련 제한 정보를 확인할 수 있습니다.
작업 오케스트레이션 처리량
다음 설정은 단일 테넌트 Azure Logic Apps에서 워크플로 작업을 실행할 때의 처리량 및 용량에 영향을 미칩니다.
| 설정 | 기본값 | 설명 |
|---|---|---|
Jobs.BackgroundJobs.DispatchingWorkersPulseInterval |
00:00:01 (1초) |
이전 폴링에서 작업이 반환되지 않을 때 작업 디스패처가 작업 큐를 폴링하는 간격을 설정합니다. 이전 폴링에서 작업이 반환되면 작업 디스패처는 즉시 큐를 폴링합니다. |
Jobs.BackgroundJobs.NumPartitionsInJobDefinitionsTable |
4개 작업 파티션 |
작업 정의 테이블의 작업 파티션 수를 설정합니다. 이 값은 파티션 스토리지 제한의 영향을 받는 실행 처리량 크기를 제어합니다. |
Jobs.BackgroundJobs.NumPartitionsInJobTriggersQueue |
1개 작업 큐 |
처리할 작업에 대해 작업 디스패처가 모니터링하는 작업 큐의 수를 설정합니다. 이 값은 작업 큐가 존재하는 스토리지 파티션의 수에도 영향을 줍니다. |
Jobs.BackgroundJobs.NumWorkersPerProcessorCount |
192개 디스패처 작업자 인스턴스 |
프로세서 코어당 디스패처 작업자 인스턴스의 수 또는 작업 디스패처의 수를 설정합니다. 이 값은 코어당 워크플로 실행 수에 영향을 줍니다. |
Jobs.BackgroundJobs.StatelessNumWorkersPerProcessorCount |
192개 디스패처 작업자 인스턴스 |
상태 비저장 실행별로 프로세서 코어당 보유할 디스패처 작업자 인스턴스 또는 작업 디스패처 수를 설정합니다. 이 값은 실행당 처리되는 동시 워크플로 작업 수에 영향을 미칩니다. |
다음 설정은 모두 표준 논리 앱에서 지정된 워크플로를 수동으로 중지하고 즉시 삭제하는 데 사용됩니다.
참고 항목
이러한 설정은 실행 취소하거나 복구할 수 없으므로 로드 또는 성능 테스트 환경과 같은 비프로덕션 환경에서만 주의해서 사용합니다.
| 설정 | 기본값 | 설명 |
|---|---|---|
Jobs.CleanupJobPartitionPrefixes |
None | 지정된 워크플로에 대해 실행된 모든 작업을 즉시 삭제합니다. |
Jobs.SuspendedJobPartitionPartitionPrefixes |
없음 | 지정된 워크플로에 대한 실행 작업을 중지합니다. |
다음 예에서는 각 워크플로 ID 뒤에 콜론(:)이 오고 세미콜론(;)으로 구분되는 이러한 설정의 구문을 보여 줍니다.
"Jobs.CleanupJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2:",
"Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"
되풀이 기반 트리거
| 설정 | 기본값 | 설명 |
|---|---|---|
Microsoft.Azure.Workflows.ServiceProviders.MaximumAllowedTriggerStateSizeInKB |
1KB |
기본 제공 SFTP 트리거와 같은 되풀이 기반 트리거에 허용되는 트리거 상태의 최대 크기를 설정합니다. 트리거 상태는 여러 서비스 공급자 되풀이 기반 트리거 간에 데이터를 유지합니다. 중요: 스토리지 크기에 따라 이 값을 너무 높게 설정하지 않도록 합니다. 스토리지와 성능에 부정적인 영향을 줄 수 있습니다. |
트리거 동시 실행
다음 설정은 기본 제공된 서비스 공급자 기반 커넥터에 대한 되풀이 기반 트리거로 시작하는 워크플로에만 적용됩니다. 함수 기반 트리거로 시작하는 워크플로의 경우 지원되는 경우 일괄 처리를 설정해 볼 수 있습니다. 그러나 일괄 처리가 항상 올바른 솔루션은 아닙니다. 예를 들어, Azure Service Bus 트리거를 사용하면 일괄 처리에서 잠금 기간이 지난 메시지를 보관할 수 있습니다. 결과적으로 해당 메시지에서는 완료 또는 포기와 같은 모든 작업이 실패합니다.
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Trigger.MaximumRunConcurrency |
100개 실행 |
트리거가 시작할 수 있는 최대 동시 실행 수를 설정합니다. 이 값은 트리거의 동시성 정의에 표시됩니다. |
Runtime.Trigger.MaximumWaitingRuns |
200개 실행 |
동시 실행이 최댓값을 충족한 후 대기할 수 있는 최대 실행 수를 설정합니다. 이 값은 트리거의 동시성 정의에 표시됩니다. 자세한 내용은 대기 실행 제한 변경을 참조하세요. |
실행 기간 및 기록 보존
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.FlowRunTimeout |
90.00:00:00 (90일) |
시간 제한을 적용하기 전에 워크플로를 계속 실행할 수 있는 시간을 설정합니다. 이 설정의 최솟값은 7일입니다. 중요: 이 값이 Workflows.RuntimeConfiguration.RetentionInDays라는 앱 설정의 값보다 작거나 같은지 확인합니다. 그렇지 않으면 연관된 작업이 완료되기 전에 실행 기록이 삭제될 수 있습니다. |
Runtime.FlowMaintenanceJob.RetentionCooldownInterval |
7.00:00:00 (7일) |
일 단위의 시간을 더 이상 유지하지 않으려는 실행 기록을 확인하고 삭제할 시점 사이의 간격으로 설정합니다. |
동작 실행
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout |
00:10:00 (10분) |
시간이 초과되고 다시 시도하기 전에 워크플로 동작 작업이 실행되는 시간을 설정합니다. |
입력 및 출력
| 설정 | 기본값 | 설명 |
|---|---|---|
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit |
50 |
소비 논리 앱을 내보내서 만든 표준 논리 앱의 경우 환경 간 워크플로 매개 변수에 대한 기본 제한을 최대 500개까지 변경합니다. |
Runtime.ContentLink.MaximumContentSizeInBytes |
104857600바이트 |
단일 트리거나 작업에서 입력 또는 출력에 허용되는 최대 크기(바이트)를 설정합니다. |
Runtime.FlowRunActionJob.MaximumActionResultSize |
209715200바이트 |
단일 작업에서 결합된 입력 및 출력에 허용되는 최대 크기(바이트)를 설정합니다. |
페이지 매김
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumPageCount |
1000페이지 |
작업에서 페이지 매김을 지원하고 사용하도록 설정된 경우에 런타임에서 반환하거나 처리할 최대 페이지 수를 설정합니다. |
청크
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.FlowRunRetryableActionJobCallback.MaximumContentLengthInBytesForPartialContent |
1073741824바이트 |
작업에서 청크를 지원하고 사용할 수 있도록 설정된 경우에 다운로드하거나 업로드하는 콘텐츠의 최대 크기(바이트)를 설정합니다. |
Runtime.FlowRunRetryableActionJobCallback.MaxChunkSizeInBytes |
52428800바이트 |
작업에서 청크를 지원하고 사용하도록 설정된 경우 각 콘텐츠 청크의 최대 크기(바이트)를 설정합니다. |
Runtime.FlowRunRetryableActionJobCallback.MaximumRequestCountForPartialContent |
1000개 요청 |
작업에서 청크를 지원하고 사용하도록 설정된 경우에 작업 실행 시 콘텐츠 다운로드를 위해 수행할 수 있는 최대 요청 수를 설정합니다. |
콘텐츠를 인라인으로 저장하거나 Blob 사용
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.FlowRunEngine.ForeachMaximumItemsForContentInlining |
20개 항목 |
For each 루프를 실행할 때 각 항목의 값은 테이블 스토리지에 다른 메타데이터와 함께 인라인으로 또는 Blob 스토리지에 별도로 저장됩니다. 다른 메타데이터와 인라인으로 저장할 항목의 수를 설정합니다. |
Runtime.FlowRunRetryableActionJobCallback.MaximumPagesForContentInlining |
20페이지 |
Blob 스토리지에 저장하기 전에 테이블 스토리지에 인라인 콘텐츠로 저장할 최대 페이지 수를 설정합니다. |
Runtime.FlowTriggerSplitOnJob.MaximumItemsForContentInlining |
40개 항목 |
SplitOn 설정에서 배열 항목을 여러 워크플로 인스턴스로 분리하면 각 항목의 값은 테이블 스토리지에 다른 메타데이터와 함께 인라인으로 또는 Blob 스토리지에 별도로 저장됩니다. 인라인으로 저장할 항목 수를 설정합니다. |
Runtime.ScaleUnit.MaximumCharactersForContentInlining |
문자 8192개 |
Blob 스토리지에 저장하기 전에 테이블 스토리지에 인라인으로 저장할 작업 입력 및 출력 문자의 최대 수를 설정합니다. |
for each 루프
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.FlowDefaultForeachItemsLimit |
100000 배열 항목 |
상태 저장 워크플로의 For each 루프에서 처리할 최대 배열 항목 수를 설정합니다. |
Runtime.Backend.FlowDefaultSplitOnItemsLimit |
100000 배열 항목 |
SplitOn 설정에 따라 여러 워크플로 인스턴스로 분리하거나 분할할 최대 배열 항목 수를 설정합니다. |
Runtime.Backend.ForeachDefaultDegreeOfParallelism |
20회 반복 |
For each 루프에서 기본 동시 반복 횟수(병렬화 수준)를 설정합니다. 순차적으로 실행하려면 값을 1로 설정합니다. |
Runtime.Backend.Stateless.FlowDefaultForeachItemsLimit |
100개 항목 |
상태 비저장 워크플로의 For each 루프에서 처리할 최대 배열 항목 수를 설정합니다. |
until 루프
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.MaximumUntilLimitCount |
5000회 반복 |
상태 비저장 워크플로의 Until 작업에서 Count 속성에 허용되는 최대 수를 설정합니다. |
Runtime.Backend.Stateless.FlowRunTimeout |
00:05:00 (5분) |
상태 비저장 워크플로에서 Until 루프의 최대 대기 시간을 설정합니다. |
Runtime.Backend.Stateless.MaximumUntilLimitCount |
100회 반복 |
상태 비저장 워크플로의 Until 작업에서 Count 속성에 허용되는 최대 수를 설정합니다. |
variables
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.DefaultAppendArrayItemsLimit |
100000 배열 항목 |
배열 형식 변수의 최대 항목 수를 설정합니다. |
Runtime.Backend.VariableOperation.MaximumStatelessVariableSize |
상태 비저장 워크플로: 1024자 |
상태 비저장 워크플로에서 사용될 때 변수가 저장할 수 있는 콘텐츠의 최대 크기(문자)를 설정합니다. |
Runtime.Backend.VariableOperation.MaximumVariableSize |
상태 저장 워크플로: 104857600자 |
상태 저장 워크플로에서 사용될 때 변수가 저장할 수 있는 콘텐츠의 최대 크기(문자)를 설정합니다. |
기본 제공 HTTP 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.HttpOperation.DefaultRetryCount |
4회 다시 시도 |
HTTP 트리거 및 작업에 대한 기본 다시 시도 횟수를 설정합니다. |
Runtime.Backend.HttpOperation.DefaultRetryInterval |
00:00:07 (7초) |
HTTP 트리거 및 작업에 대한 기본 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpOperation.DefaultRetryMaximumInterval |
01:00:00 (1시간) |
HTTP 트리거 및 작업에 대한 최대 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpOperation.DefaultRetryMinimumInterval |
00:00:05 (5초) |
HTTP 트리거 및 작업에 대한 최소 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpOperation.MaxContentSize |
104857600바이트 |
트리거가 아닌 HTTP 작업에 대해서만 최대 요청 크기(바이트)를 설정합니다. 자세한 내용은 제한 사항을 참조하세요. |
Runtime.Backend.HttpOperation.RequestTimeout |
00:03:45 (3분 45초) 참고: 기본값은 최댓값이기도 합니다. |
HTTP 트리거 및 작업에 대한 요청 제한 시간 값을 설정합니다. |
기본 제공 HTTP 웹후크 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.HttpWebhookOperation.DefaultRetryCount |
4회 다시 시도 |
HTTP webhook 트리거 및 작업에 대한 기본 다시 시도 횟수를 설정합니다. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryInterval |
00:00:07 (7초) |
HTTP webhook 트리거 및 작업에 대한 기본 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryMaximumInterval |
01:00:00 (1시간) |
HTTP webhook 트리거 및 작업에 대한 최대 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpWebhookOperation.DefaultRetryMinimumInterval |
00:00:05 (5초) |
HTTP webhook 트리거 및 작업에 대한 최소 다시 시도 간격을 설정합니다. |
Runtime.Backend.HttpWebhookOperation.DefaultWakeUpInterval |
01:00:00 (1시간) |
HTTP 웹후크 트리거와 동작 작업에 대한 기본 절전 모드 해제 간격을 설정합니다. |
Runtime.Backend.HttpWebhookOperation.MaxContentSize |
104857600바이트 |
트리거가 아닌 HTTP 웹후크 작업에 대해서만 최대 요청 크기(바이트)를 설정합니다. 자세한 내용은 제한 사항을 참조하세요. |
Runtime.Backend.HttpWebhookOperation.RequestTimeout |
00:02:00 (2분) |
HTTP webhook 트리거 및 작업에 대한 요청 시간 제한 값을 설정합니다. |
기본 제공 Azure Storage 작업
Blob Storage
| 설정 | 기본값 | 설명 |
|---|---|---|
Microsoft.Azure.Workflows.ContentStorage.RequestOptionsThreadCount |
None | Blob 업로드 및 다운로드 작업에 대한 스레드 수를 설정합니다. 이 설정을 사용하여 작업 입력 및 출력에서 콘텐츠를 업로드하고 다운로드할 때 Azure Logic Apps 런타임이 여러 스레드를 사용하도록 강제할 수 있습니다. |
Runtime.ContentStorage.RequestOptionsDeltaBackoff |
00:00:02 (2초) |
Blob 스토리지로 보내는 각 다시 시도 사이의 백오프 간격을 설정합니다. |
Runtime.ContentStorage.RequestOptionsMaximumAttempts |
4회 다시 시도 |
테이블 및 큐 스토리지로 보내는 최대 다시 시도 횟수를 설정합니다. |
Runtime.ContentStorage.RequestOptionsMaximumExecutionTime |
00:02:00 (2분) |
Azure Logic Apps 런타임의 Blob 요청에 대해 다시 시도를 포함한 작업 제한 시간 값을 설정합니다. |
Runtime.ContentStorage.RequestOptionsServerTimeout |
00:00:30 (30초) |
Azure Logic Apps 런타임의 Blob 요청에 대한 시간 제한 값을 설정합니다. |
테이블 및 큐 스토리지
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.DataStorage.RequestOptionsDeltaBackoff |
00:00:02 (2초) |
테이블 및 큐 스토리지로 보내는 각 다시 시도 사이의 백오프 간격을 설정합니다. |
Runtime.DataStorage.RequestOptionsMaximumAttempts |
4회 다시 시도 |
테이블 및 큐 스토리지로 보내는 최대 다시 시도 횟수를 설정합니다. |
Runtime.DataStorage.RequestOptionsMaximumExecutionTime |
00:00:45 (45초) |
Azure Logic Apps 런타임의 테이블 및 큐 스토리지 요청에 대해 다시 시도를 포함한 작업 제한 시간 값을 설정합니다. |
Runtime.DataStorage.RequestOptionsServerTimeout |
00:00:16 (16초) |
Azure Logic Apps 런타임의 테이블 및 큐 스토리지 요청에 대한 제한 시간 값을 설정합니다. |
파일 공유
| 설정 | 기본값 | 설명 |
|---|---|---|
ServiceProviders.AzureFile.MaxFileSizeInBytes |
150000000바이트 |
Azure 파일 공유의 최대 파일 크기(바이트)를 설정합니다. |
기본 제공 Azure Functions 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.FunctionOperation.RequestTimeout |
00:03:45 (3분 45초) |
Azure Functions 작업에 대한 요청 시간 제한 값을 설정합니다. |
Runtime.Backend.FunctionOperation.MaxContentSize |
104857600바이트 |
Azure Functions 작업에 대한 최대 요청 크기(바이트)를 설정합니다. 자세한 내용은 제한 사항을 참조하세요. |
Runtime.Backend.FunctionOperation.DefaultRetryCount |
4회 다시 시도 |
Azure Functions 작업에 대한 기본 다시 시도 횟수를 설정합니다. |
Runtime.Backend.FunctionOperation.DefaultRetryInterval |
00:00:07 (7초) |
Azure Functions 작업에 대한 기본 다시 시도 간격을 설정합니다. |
Runtime.Backend.FunctionOperation.DefaultRetryMaximumInterval |
01:00:00 (1시간) |
Azure Functions 작업에 대한 최대 다시 시도 간격을 설정합니다. |
Runtime.Backend.FunctionOperation.DefaultRetryMinimumInterval |
00:00:05 (5초) |
Azure Functions 작업에 대한 최소 다시 시도 간격을 설정합니다. |
기본 제공 Azure Service Bus 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
ServiceProviders.ServiceBus.MessageSenderOperationTimeout |
00:01:00 (1분) |
기본 제공 Service Bus 작업을 통해 메시지를 보내기 위한 시간 제한을 설정합니다. |
Runtime.ServiceProviders.ServiceBus.MessageSenderPoolSizePerProcessorCount |
메시지 보낸 사람 64명 |
메시지 보낸 사람 풀에서 사용할 프로세서 코어당 Azure Service Bus 메시지 보낸 사람의 수를 설정합니다. |
기본 제공 SFTP 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.ServiceProviders.Sftp.MaxFileSizeInBytes |
2147483648바이트 |
파일 콘텐츠 가져오기(V2) 작업에 대한 최대 파일 크기(바이트)를 설정합니다. |
Runtime.ServiceProviders.Sftp.MaximumFileSizeToReadInBytes |
209715200바이트 |
파일 콘텐츠 가져오기 작업에 대한 최대 파일 크기(바이트)를 설정합니다. 이 작업은 메모리의 파일 콘텐츠를 읽기 때문에 이 값이 참조 가능한 메모리 크기를 초과하지 않는지 확인합니다. |
관리형 커넥터 작업
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.Backend.ApiConnectionOperation.RequestTimeout |
00:02:00 (2분) |
관리형 API 커넥터 트리거 및 작업에 대한 요청 제한 시간 값을 설정합니다. |
Runtime.Backend.ApiConnectionOperation.MaxContentSize |
104857600바이트 |
관리형 API 커넥터 트리거 및 작업에 대한 최대 요청 크기(바이트)를 설정합니다. 자세한 내용은 제한 사항을 참조하세요. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryCount |
4회 다시 시도 |
관리형 API 커넥터 트리거 및 작업에 대한 기본 다시 시도 횟수를 설정합니다. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryInterval |
00:00:07 (7초) |
관리형 API 커넥터 트리거 및 작업에 대한 기본 다시 시도 간격을 설정합니다. |
Runtime.Backend.ApiWebhookOperation.DefaultRetryMaximumInterval |
01:00:00 (1일) |
관리형 API 커넥터 webhook 트리거 및 작업에 대한 최대 다시 시도 간격을 설정합니다. |
Runtime.Backend.ApiConnectionOperation.DefaultRetryMinimumInterval |
00:00:05 (5초) |
관리형 API 커넥터 트리거 및 작업에 대한 최소 다시 시도 간격을 설정합니다. |
Runtime.Backend.ApiWebhookOperation.DefaultWakeUpInterval |
01:00:00 (1일) |
관리형 API 커넥터 웹후크 트리거 및 동작 작업에 대한 기본 절전 모드 해제 간격을 설정합니다. |
다른 모든 작업에 대한 다시 시도 정책
| 설정 | 기본값 | 설명 |
|---|---|---|
Runtime.ScaleMonitor.MaxPollingLatency |
00:00:30 (30초) |
런타임 크기 조정에 대한 최대 폴링 대기 시간을 설정합니다. |
Runtime.Backend.Operation.MaximumRetryCount |
90회 다시 시도 |
워크플로 작업에 대한 다시 시도 정책 정의의 최대 다시 시도 횟수를 설정합니다. |
Runtime.Backend.Operation.MaximumRetryInterval |
01:00:00:01 (1일 및 1초) |
워크플로 작업에 대한 다시 시도 정책 정의의 최대 간격을 설정합니다. |
Runtime.Backend.Operation.MinimumRetryInterval |
00:00:05 (5초) |
워크플로 작업에 대한 다시 시도 정책 정의의 최소 간격을 설정합니다. |
제한 사항
최대 콘텐츠 크기
기본적으로 HTTP 또는 요청과 같은 기본 제공 트리거는 한도 및 구성 참조 - 메시지에 설명된 메시지 크기로 제한됩니다. 한도보다 큰 파일을 처리하려면 콘텐츠를 Azure Blob Storage에 Blob으로 업로드한 다음 Azure Blob 커넥터를 사용하여 콘텐츠를 가져옵니다.
호스트 설정 관리 - host.json
또한 해당 논리 앱의 모든 워크플로에 적용되는 런타임 구성 설정 및 값을 지정하는 호스트 설정을 추가, 업데이트 또는 삭제할 수 있습니다(예: 처리량, 용량, 데이터 크기 등의 기본값, 로컬에서 또는 Azure에서 실행되는지 여부). 논리 앱별 호스트 설정은 사용할 수 있는 런타임 및 배포 설정에 대한 참조 가이드 - host.json을 참조하세요.
Azure Portal - host.json
Azure Portal에서 단일 테넌트 기반 논리 앱의 호스트 설정을 검토하려면 다음 단계를 수행합니다.
Azure Portal 검색 상자에서 논리 앱을 찾아 선택합니다.
논리 앱 메뉴의 개발 도구에서 고급 도구를 선택합니다.
고급 도구 페이지에서 Go를 선택합니다. 그러면 논리 앱에 대한 Kudu 환경이 열립니다.
Kudu 도구 모음의 디버그 콘솔 메뉴에서 CMD를 선택합니다.
Azure Portal에서 논리 앱을 중지합니다.
논리 앱 메뉴에서 개요를 선택합니다.
개요 창의 도구 모음에서 중지를 선택합니다.
논리 앱 메뉴의 개발 도구에서 고급 도구를 선택합니다.
고급 도구 창에서 Go를 선택합니다. 그러면 논리 앱에 대한 Kudu 환경이 열립니다.
Kudu 도구 모음에서 디버그 콘솔 메뉴를 열고 CMD를 선택합니다.
명령 프롬프트를 사용하여 wwwroot 폴더로 이동할 수 있도록 콘솔 창이 열립니다. 또는 콘솔 창 위에 표시된 디렉터리 구조를 찾아볼 수도 있습니다.
wwwroot 폴더의 경로
...\home\site\wwwroot에서 찾아봅니다.콘솔 창 위의 디렉터리 테이블에서 host.json 파일 옆에 있는 편집을 선택합니다.
host.json 파일이 열리면 이전에 논리 앱에 추가된 모든 호스트 설정을 검토합니다.
호스트 설정에 대한 자세한 내용은 사용할 수 있는 호스트 설정에 대한 참조 가이드 - host.json을 참조하세요.
설정을 추가하려면 다음 단계를 수행합니다.
설정을 추가하거나 편집하기 전에 Azure Portal에서 논리 앱을 중지합니다.
- 논리 앱 메뉴에서 개요를 선택합니다.
- 개요 창의 도구 모음에서 중지를 선택합니다.
host.json 파일로 돌아갑니다.
extensionBundle개체 아래에workflow및settings개체를 포함하는extensions개체를 추가합니다. 예를 들면 다음과 같습니다.{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { } } } }settings개체에서 논리 앱의 모든 워크플로에 사용하려는 호스트 설정이 포함된 플랫 목록을 추가합니다. 이러한 워크플로는 로컬에서 또는 Azure에서 실행됩니다. 예를 들면 다음과 같습니다.{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { "Runtime.Trigger.MaximumWaitingRuns": "100" } } } }완료되었으면 논리 앱을 저장해야 합니다.
이제 논리 앱을 다시 시작합니다. 논리 앱의 개요 페이지로 돌아가서 다시 시작을 선택합니다.
Visual Studio Code - host.json
Visual Studio Code에서 논리 앱의 호스트 설정을 검토하려면 다음 단계를 수행합니다.
논리 앱 프로젝트의 루트 프로젝트 수준에서 host.json 파일을 찾아 엽니다.
extensions개체의workflows및settings아래에서 논리 앱에 대해 이전에 추가된 호스트 설정을 검토합니다. 그렇지 않으면extensions개체가 파일에 표시되지 않습니다.호스트 설정에 대한 자세한 내용은 사용할 수 있는 호스트 설정에 대한 참조 가이드 - host.json을 참조하세요.
호스트 설정을 추가하려면 다음 단계를 수행합니다.
host.json 파일의
extensionBundle개체 아래에workflow및settings개체를 포함하는extensions개체를 추가합니다. 예를 들면 다음과 같습니다.{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { } } } }settings개체에서 논리 앱의 모든 워크플로에 사용하려는 호스트 설정이 포함된 플랫 목록을 추가합니다. 이러한 워크플로는 로컬에서 또는 Azure에서 실행됩니다. 예를 들면 다음과 같습니다.{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[1.*, 2.0.0)" }, "extensions": { "workflow": { "settings": { "Runtime.Trigger.MaximumWaitingRuns": "100" } } } }