표준 단일 테넌트 논리 앱과 사용량 다중 테넌트 논리 앱 간의 차이점
Azure Logic Apps는 앱, 데이터, 서비스 및 시스템이 통합되어 있는 자동화된 논리 앱 워크플로를 만들고 실행할 수 있는 클라우드 기반 플랫폼입니다. 이 플랫폼을 사용하면 엔터프라이즈 및 B2B(Business-to-Business) 시나리오를 위한 확장성이 뛰어난 통합 솔루션을 신속하게 개발할 수 있습니다. 논리 앱 리소스를 만들 때 사용량 또는 표준 호스팅 옵션을 선택합니다. 사용량 논리 앱은 다중 테넌트 Azure Logic Apps에서 실행되는 워크플로를 하나만 가질 수 있습니다. 표준 논리 앱은 단일 테넌트 Azure Logic Apps 또는 ASE v3(App Service Environment v3)에서 실행되는 하나 이상의 워크플로를 가질 수 있습니다.
만들 논리 앱 리소스를 선택하기 전에 다음 가이드를 검토하여 논리 앱 워크플로 유형이 서로 어떻게 다른지 알아봅니다. 이는 시나리오, 솔루션 요구 사항 및 워크플로를 배포하고 실행하려는 대상에 가장 적합한 논리 앱 워크플로 및 환경을 선택하는 데 도움이 됩니다.
Azure Logic Apps를 처음 사용하는 경우 Azure Logic Apps란? 및 논리 앱 워크플로란?을 검토합니다.
논리 앱 워크플로 유형 및 환경
다음 표에는 사용량 논리 앱 워크플로와 표준 논리 앱 워크플로 간의 차이점이 요약되어 있습니다. 또한 워크플로를 배포, 호스팅하고 실행하는 데 있어서 단일 테넌트 환경과 다중 테넌트 환경의 차이점도 알아봅니다.
| 호스팅 옵션 | 이점 | 리소스 공유 및 사용 | 가격 책정 및 대금 청구 모델 | 한도 관리 |
|---|---|---|---|---|
| 소비 호스트 환경: 다중 테넌트 Azure Logic Apps |
- 시작하기 가장 쉬움 - 사용한 만큼 요금을 지불하려는 경우. - 완전 관리형 |
단일 논리 앱 리소스는 단 하나의 워크플로만 가질 수 있습니다. 모든 논리 앱은 Microsoft Entra 테넌트에 걸쳐 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 중복성을 위해 데이터는 쌍을 이루는 지역에 복제됩니다. 고가용성을 위해 GRS(지역 중복 스토리지)가 사용하도록 설정됩니다. |
사용(종량제) | Azure Logic Apps는 이러한 한도에 대한 기본값을 관리하지만 특정 한도에 대해 옵션이 있는 경우 이러한 값 중 일부를 변경할 수 있습니다. |
| 표준(워크플로 서비스 계획) 호스트 환경: 단일 테넌트 Azure Logic Apps 참고: 시나리오에 컨테이너가 필요한 경우 Azure Arc 지원 Logic Apps를 사용하여 단일 테넌트 기반 논리 앱을 만듭니다. 자세한 내용은 Azure Arc 지원 Logic Apps란?을 검토하세요. |
- 단일 테넌트 런타임에 호스트된 더 많은 기본 제공 커넥터로 대규모 더 높은 처리량과 더 낮은 비용 제공 - 런타임 및 성능 설정에 대한 제어 및 미세 조정 기능 증가 - 가상 네트워크 및 프라이빗 엔드포인트에 대한 통합 지원 - 자체 기본 제공 커넥터 생성 |
단일 논리 앱 리소스에는 여러 개의 상태 저장 및 상태 비저장 워크플로가 있을 수 있습니다. 단일 논리 앱 및 테넌트의 워크플로는 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 데이터는 논리 앱을 배포하는 동일한 지역에 유지됩니다. |
표준 - 가격 책정 계층을 선택한 호스팅 계획을 기반으로 합니다. 외부 스토리지를 사용하는 상태 저장 워크플로를 실행하는 경우 Azure Logic Apps 런타임은 Azure Storage 가격 책정을 따르는 스토리지 트랜잭션을 만듭니다. |
시나리오의 요구 사항에 따라 다양한 한도에 대한 기본값을 변경할 수 있습니다. 중요: 일부 한도에는 하드 상한이 있습니다. Visual Studio Code에서 논리 앱 프로젝트 구성 파일의 기본 제한 값에 변경한 사항은 디자이너 환경에 표시되지 않습니다. 자세한 내용은 단일 테넌트 Azure Logic Apps에서 논리 앱에 대한 앱 및 환경 설정 편집을 참조하세요. |
| 표준(App Service Environment v3) 호스트 환경: ASEv3(App Service Environment v3) - Windows 플랜만 해당 |
단일 테넌트와 동일한 기능 그리고 다음과 같은 이점이 있습니다. - 논리 앱을 완전히 격리합니다. - 단일 테넌트 Azure Logic Apps보다 많은 논리 앱을 만들고 실행합니다. - 논리 앱을 몇 개나 만들고 실행하든, ASE App Service 요금제 비용만 지불합니다. - 자동 스케일링을 사용할 수도 있고, 더 많은 가상 머신 인스턴스 또는 다른 App Service 요금제를 사용하여 수동으로 스케일링할 수도 있습니다. - 선택한 ASEv3에서 네트워크 설정을 상속합니다. 예를 들어 내부 ASE에 배포한 경우 워크플로는 ASE와 연결된 가상 네트워크의 리소스에 액세스할 수 있으며 내부 액세스 지점이 있을 수 있습니다. 참고: 내부 ASE 외부에서 액세스하는 경우 해당 ASE의 워크플로에 대한 실행 기록에서 작업 입력 및 출력에 액세스할 수 없습니다. |
단일 논리 앱에는 여러 상태 저장 및 상태 비저장 워크플로가 있을 수 있습니다. 단일 논리 앱 및 테넌트의 워크플로는 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 데이터는 논리 앱을 배포하는 동일한 지역에 유지됩니다. |
App Service 계획 | 시나리오의 요구 사항에 따라 다양한 한도에 대한 기본값을 변경할 수 있습니다. 중요: 일부 한도에는 하드 상한이 있습니다. Visual Studio Code에서 논리 앱 프로젝트 구성 파일의 기본 제한 값에 변경한 사항은 디자이너 환경에 표시되지 않습니다. 자세한 내용은 단일 테넌트 Azure Logic Apps에서 논리 앱에 대한 앱 및 환경 설정 편집을 참조하세요. |
표준 논리 앱 및 워크플로
표준 논리 앱 및 워크플로는 다시 디자인된 단일 테넌트 Azure Logic Apps 런타임으로 제공됩니다. 이 런타임은 Azure Functions 확장성 모델을 사용하며 Azure Functions 런타임에 확장으로 호스트됩니다. 이러한 설계는 논리 앱을 위한 이식성, 유연성 및 더 우수한 성능과 Azure Functions 플랫폼 및 Azure App Service 에코시스템에서 상속된 기타 기능 및 이점을 제공합니다. 예를 들면 Azure App Service Environment v3(Windows 플랜만 해당)에서 단일 테넌트 기반 논리 앱과 해당 워크플로를 만들어 배포하고 실행할 수 있습니다.
표준 논리 앱은 Azure 함수 앱이 여러 함수를 호스트하는 방법과 비슷하게 여러 워크플로를 호스트할 수 있는 리소스 구조를 도입합니다. 일대다 매핑을 통해 동일한 논리 앱 및 테넌트에서 워크플로가 컴퓨팅 및 처리 리소스를 공유하므로 근접성으로 인해 더 우수한 성능을 제공합니다. 이 구조는 논리 앱 리소스와 워크플로 간에 일대일 매핑되는 사용량 논리 앱 리소스와 다릅니다.
이식성, 유연성 및 성능 향상에 대해 자세히 알아보려면 다음 섹션을 계속 검토하세요. 단일 테넌트 Azure Logic Apps 런타임 및 Azure Functions 확장성에 대한 자세한 내용은 다음 설명서를 참조하세요.
이식성 및 유연성
표준 논리 앱 및 워크플로를 만들 때 Azure App Service Environment v3(Windows 플랜만 해당)와 같은 다른 환경에서 워크플로를 배포하고 실행할 수 있습니다. Azure Logic Apps(표준) 확장에서 Visual Studio Code를 사용하는 경우 Azure에 배포하지 않고도 개발 환경에서 로컬로 워크플로를 개발하고 빌드, 실행할 수 있습니다. 시나리오에 컨테이너가 필요한 경우 Azure Arc 지원 Logic Apps를 사용하여 단일 테넌트 논리 앱을 만들 수 있습니다. 자세한 내용은 Azure Arc 지원 Logic Apps란?을 참조하세요.
이러한 기능은 Azure에서 기존의 실행 중인 리소스를 토대로 개발을 진행해야 하는 다중 테넌트 모델에 비해 크게 개선된 것으로 상당한 이점을 제공합니다. 사용량 논리 앱 리소스 배포를 자동화하는 다중 테넌트 모델은 앱과 인프라 모두에 대한 리소스 프로비전을 결합하고 처리하는 ARM 템플릿(Azure Resource Manager 템플릿)을 기반으로 합니다.
표준 논리 앱 리소스를 사용하면 인프라 배포와 앱 배포를 분리할 수 있으므로 배포가 더 쉬워집니다. 단일 테넌트 Azure Logic Apps 런타임 및 워크플로를 논리 앱 리소스 또는 프로젝트의 일부로 함께 패키지화할 수 있습니다. 논리 앱 리소스를 즉시 배포할 수 있는 아티팩트로 빌드, 어셈블 및 압축하는 일반 단계 또는 작업을 사용할 수 있습니다. 인프라를 배포할 때 여전히 ARM 템플릿을 사용하여 해당 용도로 사용하는 다른 프로세스 및 파이프라인과 함께 해당 리소스를 별도로 프로비전할 수 있습니다.
앱을 배포하려면 아티팩트를 호스트 환경에 복사한 다음, 앱을 시작하여 워크플로를 실행합니다. 또는 이미 잘 알고 사용하고 있는 도구와 프로세스를 사용하여 아티팩트를 배포 파이프라인에 통합합니다. 이렇게 하면 개발에 사용하는 기술 스택에 관계 없이 선택한 자체 도구를 사용하여 배포할 수 있습니다.
표준 빌드 및 배포 옵션을 사용하면 인프라 배포와는 별도로 앱 개발에 집중할 수 있습니다. 따라서 일반 앱에 사용하는 여러 유사하거나 동일한 배포 옵션을 적용할 수 있는 보다 일반적인 프로젝트 모델을 얻게 됩니다. 또한 앱에 대한 배포 파이프라인을 빌드할 때와 프로덕션에 게시하기 전에 필요한 테스트 및 유효성 검사를 실행할 때 보다 일관된 환경의 이점을 누릴 수 있습니다.
성능
표준 논리 앱을 사용하면 동일한 단일 논리 앱 리소스 및 테넌트에서 여러 워크플로를 만들고 실행할 수 있습니다. 이 일대다 매핑을 사용하면 이러한 워크플로에서 컴퓨팅, 처리, 스토리지 및 네트워크와 같은 리소스를 공유하며 이들 리소스가 근접해 있어 더 우수한 성능을 제공합니다.
표준 논리 앱 리소스 종류 및 단일 테넌트 Azure Logic Apps 런타임은 더 널리 사용되는 관리형 커넥터를 기본 제공 커넥터 작업으로 사용할 수 있도록 하여 또 다른 중요한 향상을 제공합니다. 예를 들어 Azure Service Bus, Azure Event Hubs, SQL Server 등에 대해 기본 제공 커넥터 작업을 사용할 수 있습니다. 한편, 관리형 커넥터 버전도 여전히 사용할 수 있으며 계속 작동합니다.
새로운 기본 제공 커넥터 작업을 사용하여 만든 연결은 기본 제공 연결 또는 서비스 공급자 연결이라고 합니다. 관리형 연결에서는 이를 API 연결이라고 하며, ARM 템플릿을 사용하여 배포해야 하는 Azure 리소스로 별도로 생성되고 실행됩니다. 기본 제공 작업 및 해당 연결은 워크플로를 실행하는 동일한 프로세스에서 로컬로 실행됩니다. 둘 다 단일 테넌트 Azure Logic Apps 런타임에서 호스트됩니다. 따라서 워크플로에 근접해 있으므로 기본 제공 작업 및 연결을 통해 성능을 향상시킬 수 있습니다. 이 설계는 서비스 공급자 연결이 동일한 빌드 아티팩트로 패키지화되므로 배포 파이프라인에서도 잘 작동합니다.
데이터 보존
표준 논리 앱 리소스는 단일 테넌트 Azure Logic Apps에서 호스트되며, 이러한 논리 앱 리소스를 배포하는 지역 외부에서 데이터를 저장, 처리하거나 복제하지 않습니다. 즉, 워크플로의 데이터는 부모 리소스를 만들어 배포하는 동일한 지역에 유지됩니다.
Azure Virtual Network의 리소스에 직접 액세스
단일 테넌트 Azure Logic Apps에서 실행되는 워크플로는 Azure 가상 네트워크에 있는 VM(가상 머신), 다른 서비스 및 시스템과 같은 보안 리소스에 직접 액세스할 수 있습니다.
단일 테넌트 Azure Logic Apps는 Azure Logic Apps 서비스의 전용 인스턴스이며, 전용 리소스를 사용하고 다중 테넌트 Azure Logic Apps와 별도로 실행됩니다. 전용 인스턴스에서 워크플로를 실행하면 다른 Azure 테넌트가 앱 성능에 줄 수 있는 영향("사용량이 많은 인접 항목" 효과로 알려짐)을 줄일 수 있습니다.
단일 테넌트 Azure Logic Apps는 다음과 같은 이점도 제공합니다.
다중 테넌트 Azure Logic Apps의 논리 앱에서 공유하는 고정 IP 주소와는 별개의 고정 IP 주소입니다. 대상 시스템과 통신하도록 단일 공용, 정적 및 예측 가능한 아웃바운드 IP 주소를 설정할 수도 있습니다. 이렇게 하면 대상 시스템에 추가 방화벽을 설치할 필요가 없습니다.
실행 지속 시간, 스토리지 보존, 처리량, HTTP 요청 및 응답 시간 제한, 메시지 크기 및 사용자 지정 커넥터 요청에 대한 제한이 증가합니다. 자세한 내용은 Azure Logic Apps에 대한 제한 및 구성을 참조하세요.
옵션 만들기, 빌드 및 배포
원하는 환경에 따라 논리 앱 리소스를 만들 때 다음과 같은 여러 옵션이 있습니다.
단일 테넌트 환경
| 옵션 | 리소스 및 도구 | 자세한 정보 |
|---|---|---|
| Azure Portal | 표준 논리 앱 | 단일 테넌트 Azure Logic Apps - Azure Portal에서 표준 논리 앱 워크플로 예제 만들기 |
| Visual Studio Code | Azure Logic Apps(표준) 확장 | 단일 테넌트 Azure Logic Apps - Visual Studio Code에서 표준 논리 앱 워크플로 예제 만들기 |
| Azure CLI | Logic Apps Azure CLI 확장 | az logicapp |
| Azure Resource Manager | - 로컬 - DevOps |
단일 테넌트 Azure Logic Apps |
| Azure Arc 지원 Logic Apps | Azure Arc 지원 Logic Apps 샘플 | - Azure Arc 지원 Logic Apps란? - Azure Arc 지원 Logic Apps를 사용하여 단일 테넌트 기반 논리 앱 워크플로 만들기 및 배포 |
| Azure REST API | Azure App Service REST API* 참고: 표준 논리 앱 REST API는 Azure App Service REST API에 포함됩니다. |
Azure REST API 시작하기 참조 |
다중 테넌트 환경
| 옵션 | 리소스 및 도구 | 자세한 정보 |
|---|---|---|
| Azure Portal | 사용량 논리 앱 | 빠른 시작: 다중 테넌트 Azure Logic Apps에서 사용량 논리 앱 워크플로 예제 만들기 - Azure Portal |
| Visual Studio Code | Azure Logic Apps(사용량) 확장 | 빠른 시작: 다중 테넌트 Azure Logic Apps에서 사용량 논리 앱 워크플로 예제 만들기 - Visual Studio Code |
| Azure CLI | Logic Apps Azure CLI 확장 | - 빠른 시작: 다중 테넌트 Azure Logic Apps에서 사용량 논리 앱 워크플로 만들기 및 관리 - Azure CLI - az logic |
| Azure Resource Manager | 논리 앱 만들기 ARM 템플릿 | 빠른 시작: 다중 테넌트 Azure Logic Apps에서 사용량 논리 앱 워크플로 만들기 및 배포 - ARM 템플릿 |
| Azure PowerShell | Az. LogicApp 모듈 | Azure PowerShell 시작 |
| Azure REST API | Azure Logic Apps REST API | Azure REST API 시작하기 참조 |
개발 환경이 사용량 또는 표준 논리 앱 리소스 중 어느 것을 만드는 지에 따라 달라지지만 Azure 구독에서 배포된 모든 논리 앱을 찾아서 액세스할 수 있습니다.
예를 들어 Azure Portal에서 논리 앱 페이지에는 사용량 및 표준 논리 앱 리소스가 모두 표시됩니다. Visual Studio Code에서 배포된 논리 앱은 Azure 구독 아래에 표시되지만 사용량 논리 앱은 Azure Logic Apps(사용량) 확장 아래의 Azure 창에 표시되고 표준 논리 앱은 리소스 섹션 아래에 표시됩니다.
상태 저장 및 상태 비저장 워크플로
표준 논리 앱 내에서 다음 워크플로 유형을 만들 수 있습니다.
상태 저장
이전 이벤트의 데이터를 유지, 검토 또는 참조해야 하는 경우 상태 저장 워크플로를 만듭니다. 이러한 워크플로는 모든 작업의 입력, 출력 및 상태를 외부 스토리지에 저장합니다. 이 정보를 통해 각 실행이 완료된 후 워크플로 실행 세부 정보 및 기록을 검토할 수 있습니다. 상태 저장 워크플로는 중단이 발생할 때 높은 복원력을 제공합니다. 서비스 및 시스템이 복원된 후에는 저장된 상태로부터 중단된 실행을 다시 생성하고 워크플로를 다시 실행하여 완료할 수 있습니다. 상태 저장 워크플로는 상태 비저장 워크플로보다 훨씬 긴 시간 동안 계속해서 실행 가능합니다.
기본적으로 다중 테넌트/단일 테넌트 Azure Logic Apps에서 모두 상태 저장 워크플로는 비동기적으로 실행됩니다. 모든 HTTP 기반 동작은 표준 비동기 작업 패턴을 따릅니다. HTTP 작업이 엔드포인트, 서비스, 시스템 또는 API에 요청을 호출하거나 보낸 후 요청 수신자는 즉시 "202 ACCEPTED" 응답을 반환합니다. 이 코드는 수신기에서 요청을 수락했지만 처리가 완료되지 않았음을 확인합니다. 응답에는 수신기에서 처리를 중지하고 ‘200 정상’ 성공 응답 또는 202가 아닌 다른 응답을 반환할 때까지 호출자가 비동기 요청의 상태를 폴링하거나 확인하는 데 사용할 수 있는 URI 및 새로 고침 ID를 지정하는
location헤더가 포함될 수 있습니다. 하지만 호출자가 요청 처리가 완료될 때까지 기다릴 필요가 없고 계속 다음 작업을 실행할 수 있습니다. 자세한 내용은 비동기 마이크로서비스 통합에 마이크로서비스 자율성 적용을 참조하세요.상태 비저장
나중에 검토할 수 있도록 각 실행이 완료된 후 외부 스토리지에서 이전 이벤트의 데이터를 유지, 검토 또는 참조할 필요가 없는 경우에는 상태 비저장 워크플로를 만듭니다. 이 워크플로는 외부 스토리지가 아니라 ‘메모리 내에만’ 각 작업의 모든 입출력과 해당 상태를 저장합니다. 결과적으로 상태 비저장 워크플로는 외부 스토리지가 워크플로 실행 세부 정보 및 기록을 저장하지 않기 때문에 일반적으로 5분 이내에 완료되는 더 짧은 실행, 더 빠른 응답 시간, 더 높은 처리량 및 감소된 실행 비용으로 더 빠른 성능을 제공합니다. 그러나 중단이 발생하면 중단된 실행이 자동으로 복원되지 않으므로 호출자는 중단된 실행을 수동으로 다시 제출해야 합니다.
상태 비저장 워크플로는 총 크기가 64KB를 초과하지 않는 파일과 같은 데이터 또는 콘텐츠를 처리할 때 최상의 성능을 제공합니다. 여러 개의 큰 첨부 파일과 같이 콘텐츠 크기가 더 커지면 워크플로 성능이 크게 저하되거나 메모리 부족 예외로 인해 워크플로가 충돌할 수도 있습니다. 워크플로가 더 큰 콘텐츠 크기를 처리해야 하는 경우에는 상태 저장 워크플로를 대신 사용합니다.
참고 항목
상태 비저장 워크플로에서는 워크플로 실행 일정을 지정하지 않은 경우에만 푸시 트리거를 사용할 수 있습니다. 이러한 웹후크 기반 트리거는 이벤트가 발생하거나 데이터가 사용 가능해질 때까지 기다립니다. 예를 들어, 되풀이 트리거는 상태 저장 워크플로에만 사용할 수 있습니다. 워크플로를 시작하려면 요청, Event Hubs 또는 Service Bus 트리거와 같은 푸시 트리거를 선택합니다. 제한된/사용할 수 없는/지원되지 않는 트리거, 작업 및 커넥터에 대한 자세한 내용은 변경된 기능, 제한된 기능, 사용할 수 없는 기능 또는 지원되지 않는 기능을 참조하세요.
상태 비저장 워크플로는 동기적으로만 실행되므로, 상태 저장 워크플로에서 사용되는 표준 비동기 작업 패턴을 사용하지 않습니다. 대신 "202 ACCEPTED" 응답을 반환하는 모든 HTTP 기반 작업은 워크플로 실행의 다음 단계로 계속됩니다. 응답에
location헤더가 포함된 경우 상태 비저장 워크플로는 지정된 URI를 폴링하여 상태를 확인하지 않습니다. 표준 비동기 작업 패턴을 따르려면 상태 저장 워크플로를 대신 사용합니다.간편한 디버깅을 위해 상태 비저장 워크플로에 실행 기록을 사용하도록 설정하고, 모두 마친 후 실행 기록을 사용하지 않도록 설정할 수 있습니다. 실행 기록을 사용하면 성능에 약간의 영향이 있습니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기 또는 Azure Portal에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.
Important
만들 때 구현할 워크플로 형식(상태 저장 또는 상태 비저장)을 결정해야 합니다. 만들기 후 워크플로 형식을 변경하면 런타임 오류가 발생합니다.
상태 저장 워크플로와 상태 비저장 워크플로의 차이점 요약
| 상태 저장 | 상태 비저장 |
|---|---|
| 실행 기록, 입력, 출력 저장 | 기본적으로 실행 기록, 입력 또는 출력을 저장하지 않음 |
| 관리되는 커넥터 트리거를 사용할 수 있고 허용함 | 관리되는 커넥터 트리거를 사용할 수 없거나 허용하지 않음 |
| 청크 지원 | 청크를 지원하지 않음 |
| 비동기 작업 지원 | 비동기 작업을 지원하지 않음 |
| 호스트 구성에서 최대 기본 실행 기간 편집 | 최대 기간이 5분 미만인 워크플로에 가장 적합함 |
| 큰 메시지 처리 | 작은 메시지 크기(64KB 미만)를 처리하는 데 가장 적합함 |
상태 저장 워크플로와 상태 비저장 워크플로의 중첩된 동작 차이점
요청 트리거, HTTP Webhook 트리거 또는 ApiConnectionWebhook 유형을 포함하고 있으며 HTTPS 요청을 받을 수 있는 관리형 커넥터 트리거를 사용하여 동일한 표준 논리 앱에 있는 다른 워크플로에서 호출 가능한 워크플로를 만들 수 있습니다.
다음 목록은 상위 워크플로가 하위 워크플로를 호출한 후 중첩된 워크플로가 따를 수 있는 동작 패턴을 설명합니다.
비동기 폴링 패턴
상위 워크플로는 하위 워크플로가 초기 호출에 응답할 때까지 기다리지 않습니다. 그러나 부모는 자식이 실행을 마칠 때까지 자식의 실행 기록을 계속 확인합니다. 기본적으로 상태 저장 워크플로는 이 패턴을 따릅니다. 이 패턴은 요청 시간 제한을 초과할 가능성이 있는 장기 실행 자식 워크플로에 적합합니다.
동기 패턴("자체 유도")
하위 워크플로는
202 ACCEPTED응답을 즉시 반환하여 상위 워크플로의 호출을 확인합니다. 그러나 부모는 자식이 결과를 반환할 때까지 기다리지 않습니다. 대신 부모는 워크플로의 다음 작업을 계속 진행하고 자식 실행이 완료되면 결과를 받습니다. 응답 작업을 포함하지 않는 자식 상태 저장 워크플로는 항상 동기 패턴을 따르고 사용자가 검토할 수 있도록 실행 기록을 제공합니다.이 동작을 사용하려면 워크플로의 JSON 정의에서
operationOptions속성을DisableAsyncPattern으로 설정합니다. 자세한 내용은 트리거 및 작업 형식 - 작업 옵션을 참조하세요.트리거 및 대기
상태 비저장 워크플로는 메모리에서 실행됩니다. 따라서 상위 워크플로가 자식 상태 비저장 워크플로를 호출하면 부모는 자식의 결과를 반환하는 응답을 기다립니다. 이 패턴은 기본 제공 HTTP 트리거 또는 작업을 사용하여 하위 워크플로를 호출할 때와 비슷한 방식으로 작동합니다. 응답 작업이 없는 자식 상태 비저장 워크플로는 즉시
202 ACCEPTED응답을 반환하지만, 부모는 자식이 완료될 때까지 기다렸다가 다음 작업을 계속합니다. 이러한 동작은 자식 상태 비저장 워크플로에만 적용됩니다.
다음 표에서는 부모 및 자식 항목이 상태 저장, 상태 비저장 또는 혼합 워크플로 형식인지 여부에 따라 하위 워크플로의 동작을 식별합니다. 테이블 뒤의 목록
| 부모 워크플로 | 하위 워크플로 | 자식 동작 |
|---|---|---|
| 상태 저장 | 상태 저장 | 비동기 또는 "operationOptions": "DisableAsyncPattern" 설정을 사용하는 동기 |
| 상태 저장 | 상태 비저장 | 트리거 및 대기 |
| 상태 비저장 | 상태 저장 | 동기 |
| 상태 비저장 | 상태 비저장 | 트리거 및 대기 |
단일 테넌트 모델의 다른 기능
단일 테넌트 모델 및 표준 논리 앱에는 다음과 같은 많은 최신 기능과 새로운 기능이 포함되어 있습니다.
SaaS(Software as a Service) 및 PaaS(Platform as a Service) 앱과 서비스를 위한 수백 가지의 관리형 커넥터와 온-프레미스 시스템을 위한 커넥터를 사용하여 논리 앱과 워크플로를 만들 수 있습니다.
이제 표준 워크플로에서 더 많은 관리형 커넥터를 기본 제공 커넥터로 사용할 수 있습니다. 기본 제공 버전은 단일 테넌트 Azure Logic Apps 런타임에서 기본적으로 실행됩니다. 일부 기본 제공 커넥터는 비공식적으로 서비스 공급자 커넥터라고도 합니다. 목록을 보려면 소비 및 표준의 기본 제공 커넥터를 검토하세요.
단일 테넌트 Azure Logic Apps 확장 프레임워크를 사용하여 필요한 모든 서비스에 대해 고유한 사용자 지정 기본 제공 커넥터를 만들 수 있습니다. Azure Service Bus 및 SQL Server와 같은 기본 제공 커넥터와 유사하게 사용자 지정 기본 제공 커넥터는 단일 테넌트 런타임과 동일한 프로세스에서 실행되기 때문에 더 높은 처리량, 짧은 대기 시간 및 로컬 연결을 제공합니다. 그러나 사용자 지정 기본 제공 커넥터는 현재 지원되지 않는 사용자 지정 관리 커넥터와 유사하지 않습니다. 자세한 내용은 사용자 지정 커넥터 개요 및 단일 테넌트 Azure Logic Apps에서 표준 논리 앱용 사용자 지정 기본 제공 커넥터 만들기를 검토하세요.
통합 계정 없이 Liquid 작업과 XML 작업에 다음 작업을 사용할 수 있습니다. 이 작업에는 다음 작업이 포함됩니다.
XML: XML 변환, XML 유효성 검사
Liquid: JSON 간 변환, JSON에서 텍스트로 변환, XML에서 JSON으로 변환, XML에서 텍스트로 변환
참고 항목
표준 워크플로에서 이러한 작업을 사용하려면 Liquid 맵, XML 맵 또는 XML 스키마가 있어야 합니다. 스키마 및 맵 섹션이 포함된 아티팩트 아래 논리 앱 리소스 메뉴의 Azure Portal에서 이 아티팩트를 업로드할 수 있습니다. 또는 각 Mpas 및 Schemas 폴더를 사용하여 Visual Studio Code 프로젝트의 Artifacts 폴더에 이 아티팩트를 추가할 수 있습니다. 그런 다음, 동일한 논리 앱 내의 여러 워크플로에서 이 아티팩트를 사용할 수 있습니다.
Azure Logic Apps는 클라우드 연결 런타임 엔드포인트에 요청을 보내는 데 사용할 수 있는 SAS(공유 액세스 서명) 연결 문자열을 생성하기 때문에 표준 논리 앱 워크플로를 어디서나 실행할 수 있습니다. Azure Logic Apps는 Azure에 배포할 때 관련 값을 Azure Key Vault에 쉽게 저장할 수 있도록 이 연결 문자열을 다른 애플리케이션과 함께 저장합니다.
표준 논리 앱 워크플로는 시스템 할당 관리 ID 및 여러 사용자가 할당한 관리 ID를 동시에 사용하도록 설정하는 기능을 지원하지만, 한 번에 하나의 ID만 선택할 수 있습니다. 기본 제공 서비스 공급자 기반 커넥터는 시스템 할당 ID 사용을 지원하지만, 현재는 SQL Server 및 HTTP 커넥터를 제외하고 인증을 위해 사용자 할당 관리 ID를 선택할 수 없습니다.
참고 항목
기본적으로 시스템이 할당한 ID는 런타임에 연결을 인증하는 데 사용하도록 이미 설정되어 있습니다. 이 ID는 연결을 만들 때 사용하는 인증 자격 증명이나 연결 문자열과는 다릅니다. 이 ID를 사용하지 않도록 설정하면 실행 시 연결이 작동하지 않습니다. 이 설정을 보려면 논리 앱 메뉴의 설정에서 ID를 선택합니다.
Visual Studio Code 개발 환경에서 논리 앱 및 워크플로를 로컬로 실행, 테스트 및 디버그할 수 있습니다.
논리 앱을 실행하고 테스트하기 전에 워크플로에 대한 workflow.json 파일 내에 중단점을 추가하고 사용하면 디버깅을 더 쉽게 수행할 수 있습니다. 하지만 현재는 트리거가 아닌 작업에만 중단점이 지원됩니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.
Visual Studio Code에서 Azure, Azure Arc 지원 Logic Apps 등의 다양한 호스팅 환경에 논리 앱과 워크플로를 직접 게시하거나 배포합니다.
Azure 구독 및 논리 앱 설정에서 지원하는 경우 Application Insights를 사용하여 논리 앱에 진단 로깅 및 추적 기능을 사용하도록 설정합니다.
Azure Functions와 마찬가지로 Azure Functions 프리미엄 플랜을 사용하여 논리 앱을 만들고 배포할 때 Azure 가상 네트워크와 비공개로 연결하고 통합하는 기능을 비롯한 네트워킹 기능을 사용합니다. 자세한 내용은 다음 설명서를 검토하세요.
표준 논리 앱의 개별 워크플로에서 사용하는 관리형 연결을 위한 액세스 키를 다시 생성합니다. 이 작업의 경우 논리 앱 리소스 수준이 아닌 워크플로 수준에서 사용량 논리 앱에 대해 동일한 단계를 수행합니다.
표준용 기본 제공 커넥터
표준 워크플로는 사용량 워크플로와 동일한 기본 제공 커넥터를 사용할 수 있지만 전부 사용할 수 있는 것은 아닙니다. 반대로 표준 워크플로에는 사용량 워크플로에서 사용할 수 없는 많은 기본 제공 커넥터가 있습니다.
예를 들어 표준 워크플로에는 Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP 및 SQL Server 등에 대한 관리형 커넥터와 기본 제공 커넥터가 모두 있습니다. 사용량 워크플로에는 동일한 기본 제공 커넥터 버전이 없지만 Azure API Management 및 Azure App Services와 같은 다른 기본 제공 커넥터를 사용할 수 있습니다.
단일 테넌트 Azure Logic Apps에서 특정 특성을 가진 기본 제공 커넥터를 비공식적으로 서비스 공급자라고 합니다. 일부 기본 제공 커넥터는 기본 서비스에 대한 연결을 인증하는 한 가지 방법만 지원합니다. 다른 기본 제공 커넥터는 연결 문자열, Microsoft Entra ID 또는 관리 ID 사용과 같은 옵션을 제공할 수 있습니다. 모든 기본 제공 커넥터는 다시 디자인된 Azure Logic Apps 런타임과 동일한 프로세스에서 실행됩니다. 자세한 내용은 표준 논리 앱 워크플로에 대한 기본 제공 커넥터 목록을 검토하세요.
Important
성공적인 작업을 확인하기 위해 서비스 공급자 기반 트리거를 올바르게 설정하고 테스트해야 합니다. 서비스 공급자 기반 트리거가 실패하면 불필요한 크기 조정이 발생할 수 있으므로 청구 비용이 크게 증가할 수 있습니다. 예를 들어 일반적인 실수는 논리 앱에 Service Bus 큐, Azure Storage Blob 컨테이너 등과 같은 대상에 대한 액세스 권한을 부여하지 않고 트리거를 설정하는 것입니다. 또한 문제를 즉시 감지하고 해결할 수 있도록 이러한 트리거를 항상 모니터링해야 합니다.
변경된 기능, 제한된 기능, 사용할 수 없는 기능 또는 지원되지 않는 기능
표준 논리 앱 워크플로에서는 이러한 기능이 변경되었거나, 현재 제한되어 있거나, 사용할 수 없거나, 지원되지 않습니다.
트리거 및 동작: 기본 제공 트리거와 동작은 Azure Logic Apps에서 기본적으로 실행되며, 관리되는 커넥터는 Azure에서 공유 리소스를 사용하여 호스트 및 실행됩니다. 표준 워크플로의 경우 현재 슬라이딩 윈도우, Azure App Service 및 Azure API Management와 같은 일부 기본 제공 트리거 및 작업을 사용할 수 없습니다. 상태 저장 또는 상태 비저장 워크플로를 시작하려면 요청, Event Hubs 또는 Service Bus 트리거와 같은 기본 제공 트리거를 사용합니다. 되풀이 트리거는 상태 저장 워크플로에 사용할 수 있지만 상태 비저장 워크플로에는 사용할 수 없습니다. 디자이너에서 기본 제공 트리거 및 작업은 앱 내 레이블과 함께 표시되고 관리형 커넥터 트리거 및 작업은 공유 레이블과 함께 표시됩니다.
상태 비저장 워크플로는 워크플로 실행 일정을 지정하지 않은 푸시 트리거만 사용할 수 있습니다. 이러한 웹후크 기반 트리거는 이벤트가 발생하거나 데이터가 사용 가능해질 때까지 기다립니다. 예를 들어, 되풀이 트리거는 상태 저장 워크플로에만 사용할 수 있습니다. 워크플로를 시작하려면 요청, Event Hubs 또는 Service Bus 트리거와 같은 푸시 트리거를 선택합니다. 상태 비저장 워크플로에 대해 관리되는 커넥터를 사용하도록 설정할 수 있지만 커넥터 갤러리에는 추가할 수 있는 관리되는 커넥터 폴링 트리거가 표시되지 않습니다.
참고 항목
Visual Studio Code에서 로컬로 실행하려면 webhook 기반 트리거 및 작업에서 추가 설정이 필요합니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.
다음 트리거 및 작업이 변경되었거나 현재 제한되거나 지원되지 않거나 사용할 수 없습니다.
기본 제공 작업 Azure Functions - Azure 함수 선택은 이제 Azure Function 작업 - Azure 함수 호출입니다. 이 작업은 현재 HTTP 트리거 템플릿에서 만든 함수에 대해서만 작동합니다.
Azure Portal에서 사용자 환경을 통해 연결을 만들어 액세스할 수 있는 HTTP 트리거 함수를 선택할 수 있습니다. 코드 보기 또는 workflow.json 파일에서 함수 작업의 JSON 정의를 살펴보면 작업이
connectionName참조를 통해 함수를 참조한다는 것을 알 수 있습니다. 이 버전은 함수 정보를 연결로 추상화하며, 이 내용은 Visual Studio Code에서 연결을 만든 후에 사용할 수 있는 논리 앱 프로젝트의 connections.json 파일에서 찾을 수 있습니다.참고 항목
단일 테넌트 모델에서 함수 작업은 쿼리 문자열 인증만 지원합니다. Azure Logic Apps는 연결을 설정할 때 함수에서 기본 키를 가져오고, 이 키를 앱의 설정에 저장하며, 함수를 호출할 때 이 키를 인증에 사용합니다.
다중 테넌트 모델과 마찬가지로 이 키를 갱신하는 경우, 예컨대 포털의 Azure Functions 환경을 통해, 잘못된 키로 인해 함수 작업이 더 이상 작동하지 않습니다. 이 문제를 해결하려면 호출하려는 함수에 대한 연결을 다시 만들거나 앱의 설정을 새 키로 업데이트해야 합니다.
기본 제공 작업 인라인 코드의 이름이 인라인 코드 작업으로 바뀌고, 더 이상 통합 계정이 필요하지 않고, 제한 사항이 업데이트되었습니다.
기본 제공 작업 Azure Logic Apps - 논리 앱 워크플로 선택은 이제 워크플로 작업 - 이 워크플로 앱의 워크플로 호출입니다.
Gmail 커넥터는 현재 지원되지 않습니다.
사용자 지정 관리형 커넥터는 현재 지원되지 않습니다. 하지만 Visual Studio Code를 사용하는 경우에는 사용자 지정 기본 제공 작업을 만들 수 있습니다. 자세한 내용은 Visual Studio Code를 사용하여 단일 테넌트 기반 워크플로 만들기를 참조하세요.
표준 논리 앱 워크플로는 하나의 트리거만 가질 수 있으며 여러 트리거를 지원하지 않습니다.
인증: 다음 인증 유형은 현재 표준 워크플로에 사용할 수 없습니다.
요청 트리거 및 HTTP 웹후크 트리거와 같은 요청 기반 트리거에 대한 인바운드 호출에 대한 Microsoft Entra ID OAuth(Microsoft Entra ID Open Authentication).
관리 ID 인증: 시스템 할당 및 사용자가 할당한 관리 ID가 모두 지원됩니다. 기본적으로 시스템 할당 관리 ID는 자동으로 사용 설정됩니다. 그러나 대부분의 기본 제공 서비스 공급자 기반 커넥터는 현재 인증을 위해 사용자가 할당한 관리 ID 선택을 지원하지 않습니다.
XML 변환: 현재 XSLT 1.0만 지원됩니다.
Visual Studio Code에서 중단점 디버깅: 워크플로에 대한 workflow.json 파일 내에서 중단점을 추가하고 사용할 수 있지만, 현재는 트리거가 아닌 작업에만 중단점이 지원됩니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.
트리거 기록 및 실행 기록: 표준 논리 앱의 경우 논리 앱 리소스 수준이 아닌 워크플로 수준에서 트리거 기록 및 실행 기록이 Azure Portal에 표시됩니다. 자세한 내용은 Azure Portal을 사용하여 단일 테넌트 기반 워크플로 만들기를 참조하세요.
워크플로 실행 기록 백업 및 복원: 표준 논리 앱은 현재 워크플로 실행 기록 백업 및 복원을 지원하지 않습니다.
Terraform 템플릿: 완전한 인프라 배포를 위해 표준 논리 앱 리소스와 함께 이러한 템플릿을 사용할 수 없습니다. 자세한 내용은 Azure에서 Terraform이란?을 참조하세요.
Azure API Management: 현재는 표준 논리 앱 리소스를 Azure API Management로 가져올 수 없습니다. 그러나 사용량 논리 앱 리소스를 가져올 수 있습니다.
엄격한 네트워크 및 방화벽 트래픽 권한
현재 환경에 트래픽을 제한하는 엄격한 네트워크 요구 사항 또는 방화벽이 있는 경우 워크플로의 트리거 또는 작업 연결에 대한 액세스를 허용해야 합니다. 필요에 따라 서비스 태그의 트래픽을 허용하고 Azure App Service와 동일한 수준의 제한 또는 정책을 사용할 수 있습니다. 또한 연결에 대한 FQDN(정규화된 도메인 이름)을 찾아 사용해야 합니다. 자세한 내용은 다음 문서에서 해당 섹션을 검토합니다.
다음 단계
단일 테넌트 Azure Logic Apps에 대한 여러분의 의견을 듣고 싶습니다.
- 버그 또는 문제가 발견되는 경우 GitHub에서 문제를 알려주세요.
- 이 사용자 의견 양식을 사용하여 질문, 요청, 의견 및 기타 피드백을 보내주세요.