표준 단일 테넌트 논리 앱과 소비 다중 테넌트 논리 앱 간의 차이점

Azure Logic Apps는 앱, 데이터, 서비스 및 시스템을 통합하는 자동화된 논리 앱 워크플로를 만들고 실행하기 위한 클라우드 기반 플랫폼입니다. 이 플랫폼을 사용하면 엔터프라이즈 및 B2B(Business-to-Business) 시나리오를 위한 확장성이 뛰어난 통합 솔루션을 신속하게 개발할 수 있습니다. 논리 앱 리소스를 만들 때 소비 워크플로 유형 또는 표준 워크플로 유형을 선택합니다. 소비 논리 앱에는 다중 테넌트 Azure Logic Apps 또는 통합 서비스 환경에서 실행되는 워크플로가 하나만 있을 수 있습니다. 표준 논리 앱에는 단일 테넌트 Azure Logic Apps 또는 App Service Environment v3(ASE v3)에서 실행되는 하나 이상의 워크플로가 있을 수 있습니다.

만들 논리 앱 리소스를 선택하기 전에 다음 가이드를 검토하여 논리 앱 워크플로 유형이 서로 어떻게 비교되는지 알아봅니다. 그런 다음, 시나리오, 솔루션 요구 사항 및 워크플로를 배포하고 실행하려는 대상에 가장 적합한 논리 앱 워크플로 및 환경을 더 잘 선택할 수 있습니다.

Azure Logic Apps를 새로 사용하는 경우 Azure Logic Apps란 무엇이며 논리 앱 워크플로란?을 검토하세요.

논리 앱 워크플로 유형 및 환경

다음 표에는 소비 논리 앱 워크플로와 표준 논리 앱 워크플로 간의 차이점이 요약되어 있습니다. 또한 워크플로를 배포, 호스팅 및 실행하기 위한 다중 테넌트 환경 및 ISE(통합 서비스 환경)와 단일 테넌트 환경이 어떻게 다른지 알아봅니다.

리소스 종류	이점	리소스 공유 및 사용량	가격 책정 및 청구 모델	한도 관리
논리 앱(소비) 호스트 환경: 다중 테넌트 Azure Logic Apps	- 시작하기가 가장 쉽습니다. - 종량제 - 완전 관리	단일 논리 앱에는 하나의 워크플로만 있을 수 있습니다. Microsoft Entra 테넌트 간 논리 앱 은 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 중복성을 위해 데이터는 쌍을 이루는 지역에 복제본(replica). 고가용성을 위해 GRS(지역 중복 스토리지)가 사용하도록 설정됩니다.	사용(종량제)	Azure Logic Apps는 이러한 한도에 대한 기본값을 관리하지만 특정 한도에 대해 옵션이 있는 경우 이러한 값 중 일부를 변경할 수 있습니다.
논리 앱(소비) 호스트 환경: ISE(통합 서비스 환경) 참고: 2024년 8월 31일에 ISE 옵션이 사용 중지됩니다. 2022년 11월 1일부터 더 이상 ISE를 만들 수 없습니다. 대신 단일 테넌트 Azure Logic Apps에서 실행되고, 여러 워크플로를 포함할 수 있으며, ISE와 동일한 기능과 그 이상을 제공하는 표준 Logic Apps를 만들 수 있습니다.	- 대규모 워크로드에 대한 엔터프라이즈 규모 - 가상 네트워크에 직접 연결하는 20개 이상의 ISE 관련 커넥터 - 포함된 사용량 및 고객 제어 크기 조정을 사용하여 예측 가능한 가격 책정	단일 논리 앱에는 하나의 워크플로만 있을 수 있습니다. 동일한 환경의 논리 앱은 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 데이터는 ISE를 배포하는 동일한 지역에 유지됩니다.	ISE (고정)	Azure Logic Apps는 이러한 한도에 대한 기본값을 관리하지만 특정 한도에 대해 옵션이 있는 경우 이러한 값 중 일부를 변경할 수 있습니다.
논리 앱(표준) 호스트 환경: 단일 테넌트 Azure Logic Apps 참고: 시나리오에 컨테이너 가 필요한 경우 Azure Arc 지원 Logic Apps를 사용하여 단일 테넌트 기반 논리 앱을 만듭니다. 자세한 내용은 Azure Arc 지원 Logic Apps란?	- 단일 테넌트 Azure Logic Apps 런타임을 사용하여 실행. 배포 슬롯은 현재 지원되지 않습니다. - 더 높은 처리량과 대규모 비용 절감을 위한 더 많은 기본 제공 커넥터 - 런타임 및 성능 설정과 관련된 더 많은 제어 및 미세 조정 기능 - 가상 네트워크 및 프라이빗 엔드포인트에 대한 통합 지원 - 사용자 고유의 기본 제공 커넥터를 만듭니다.	단일 논리 앱에는 여러 상태 저장 및 상태 비스테이션 워크플로가 있을 수 있습니다. 단일 논리 앱 및 테넌트에서 워크플로는 동일한 처리(컴퓨팅), 스토리지, 네트워크 등을 공유합니다. 데이터는 논리 앱을 배포하는 동일한 지역에 유지됩니다.	표준은 선택한 가격 책정 계층이 있는 호스팅 계획을 기반으로 합니다. 외부 스토리지를 사용하는 상태 저장 워크플로를 실행하는 경우 Azure Logic Apps 런타임은 Azure Storage 가격 책정을 따르는 스토리지 트랜잭션을 만듭니다.	시나리오의 요구에 따라 여러 제한에 대한 기본값을 변경할 수 있습니다. 중요: 일부 한도에는 하드 상한이 있습니다. Visual Studio Code에서 논리 앱 프로젝트 구성 파일의 기본 제한 값에 대한 변경 내용은 디자이너 환경에 표시되지 않습니다. 자세한 내용은 단일 테넌트 Azure Logic Apps의 논리 앱에 대한 앱 및 환경 설정 편집을 참조 하세요.
논리 앱(표준) 호스트 환경: 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 앱 Service 에코시스템에서 상속된 다른 기능 및 이점을 제공합니다. 예를 들면 Azure App Service Environment v3(Windows 플랜만 해당)에서 단일 테넌트 기반 논리 앱과 해당 워크플로를 만들어 배포하고 실행할 수 있습니다.

표준 논리 앱은 Azure 함수 앱이 여러 함수를 호스트하는 방법과 유사하게 여러 워크플로를 호스트할 수 있는 리소스 구조를 도입합니다. 1 대 다 매핑을 사용하면 동일한 논리 앱 및 테넌트에서 워크플로가 컴퓨팅 및 처리 리소스를 공유하므로 근접성으로 인해 성능이 향상됩니다. 이 구조는 논리 앱 리소스와 워크플로 간에 1 대 1 매핑이 있는 소비 논리 앱 리소스와 다릅니다.

이식성, 유연성 및 성능 향상에 대해 자세히 알아보려면 다음 섹션을 계속 검토하세요. 단일 테넌트 Azure Logic Apps 런타임 및 Azure Functions 확장성에 대한 자세한 내용은 다음 설명서를 검토하세요.

• 어디서나 실행되는 Azure Logic Apps - 런타임 심층 살펴보기
• Azure Functions 소개
• Azure Functions 트리거 및 바인딩

이식성 및 유연성

표준 논리 앱 및 워크플로를 만들 때 Azure 앱 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 템플릿을 사용하여 해당 용도로 사용하는 다른 프로세스 및 파이프라인과 함께 해당 리소스를 별도로 프로비전할 수 있습니다.

앱을 배포하려면 아티팩트 파일을 호스트 환경에 복사한 다음, 앱을 시작하여 워크플로를 실행합니다. 또는 이미 잘 알고 사용하고 있는 도구와 프로세스를 사용하여 아티팩트를 배포 파이프라인에 통합합니다. 이렇게 하면 개발에 사용하는 기술 스택에 관계 없이 선택한 자체 도구를 사용하여 배포할 수 있습니다.

표준 빌드 및 배포 옵션을 사용하면 인프라 배포와는 별도로 앱 개발에 집중할 수 있습니다. 따라서 일반 앱에 사용하는 여러 유사하거나 동일한 배포 옵션을 적용할 수 있는 보다 일반적인 프로젝트 모델을 얻게 됩니다. 또한 앱에 대한 배포 파이프라인을 빌드할 때와 프로덕션에 게시하기 전에 필요한 테스트 및 유효성 검사를 실행할 때 보다 일관된 환경의 이점을 누릴 수 있습니다.

성능

표준 논리 앱을 사용하면 동일한 단일 논리 앱 리소스 및 테넌트에서 여러 워크플로를 만들고 실행할 수 있습니다. 이 1대 다 매핑을 통해 이러한 워크플로는 컴퓨팅, 처리, 스토리지 및 네트워크와 같은 리소스를 공유하므로 근접성으로 인해 성능이 향상됩니다.

표준 논리 앱 리소스 및 단일 테넌트 Azure Logic Apps 런타임은 더 인기 있는 관리형 커넥터를 기본 제공 커넥터 작업으로 사용할 수 있도록 하여 또 다른 중요한 개선을 제공합니다. 예를 들어 Azure Service Bus, Azure Event Hubs, SQL Server 등에 대한 기본 제공 커넥터 작업을 사용할 수 있습니다. 한편, 관리형 커넥터 버전은 계속 사용할 수 있으며 계속 작동합니다.

새 기본 제공 커넥터 작업을 사용하는 경우 기본 제공 연결 또는 서비스 공급자 연결이라는 연결을 만듭니다. 관리되는 연결에 대응하는 API 연결은 ARM 템플릿을 사용하여 배포해야 하는 Azure 리소스로 별도로 만들어지고 실행됩니다. 기본 제공 작업 및 해당 연결은 워크플로를 실행하는 동일한 프로세스에서 로컬로 실행됩니다. 둘 다 단일 테넌트 Azure Logic Apps 런타임에서 호스트됩니다. 따라서 기본 제공 작업 및 연결은 워크플로와의 근접성으로 인해 더 나은 성능을 제공합니다. 이 디자인은 서비스 공급자 연결이 동일한 빌드 아티팩트로 패키지되므로 배포 파이프라인에서도 잘 작동합니다.

데이터 상주

표준 논리 앱 리소스는 단일 테넌트 Azure Logic Apps에서 호스트되며, 이러한 논리 앱 리소스를 배포하는 지역 외부의 데이터를 저장, 처리 또는 복제본(replica) 않습니다. 즉, 워크플로의 데이터는 부모 리소스를 만들고 배포하는 동일한 지역에 유지됩니다.

Azure 가상 네트워크의 리소스에 직접 액세스

단일 테넌트 Azure Logic Apps 또는 ISE(통합 서비스 환경)에서 실행되는 워크플로는 VM(가상 머신), 다른 서비스 및 Azure 가상 네트워크에 있는 시스템과 같은 보안 리소스에 직접 액세스할 수 있습니다.

단일 테넌트 Azure Logic Apps와 ISE는 모두 Azure Logic Apps 서비스의 전용 인스턴스이며, 전용 리소스를 사용하며, 다중 테넌트 Azure Logic Apps와 별도로 실행됩니다. 전용 인스턴스에서 워크플로를 실행하면 다른 Azure 테넌트가 앱 성능에 미칠 수 있는 영향을 줄일 수 있습니다("시끄러운 이웃" 효과라고도 함).

단일 테넌트 Azure Logic Apps 및 ISE도 다음과 같은 이점을 제공합니다.

• 다중 테넌트 Azure Logic Apps의 논리 앱에서 공유하는 고정 IP 주소와는 별개인 사용자 고유의 고정 IP 주소입니다. 대상 시스템과 통신하도록 단일 공용, 정적 및 예측 가능한 아웃바운드 IP 주소를 설정할 수도 있습니다. 이렇게 하면 각 ISE에 대한 해당 대상 시스템에서 추가 방화벽을 설정할 필요가 없습니다.

• 실행 지속 시간, 스토리지 보존, 처리량, 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 앱 Service REST API* 참고: 표준 논리 앱 REST API는 Azure 앱 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 Portal	기존 ISE 리소스에 배포된 소비 논리 앱	빠른 시작과 동일 : 다중 테넌트 Azure Logic Apps - Azure Portal에서 예제 소비 논리 앱 워크플로를 만들지만 다중 테넌트 지역이 아닌 ISE를 선택합니다.

개발 환경이 사용량 또는 표준 논리 앱 리소스 중 어느 것을 만드는 지에 따라 달라지지만 Azure 구독에서 배포된 모든 논리 앱을 찾아서 액세스할 수 있습니다.

예를 들어 Azure Portal에서 Logic Apps 페이지에는 소비 및 표준 논리 앱 리소스가 모두 표시됩니다. 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 트리거와 같은 기본 제공 트리거를 선택합니다. 이러한 트리거는 Azure Logic Appss 런타임에서 기본적으로 실행됩니다. 되풀이 트리거는 상태 비저장 워크플로에 사용할 수 없으며 상태 저장 워크플로에만 사용할 수 있습니다. 제한되거나 사용할 수 없거나 지원되지 않는 트리거, 작업 및 커넥터에 대한 자세한 내용은 변경됨, 제한됨, 사용할 수 없음 또는 지원되지 않는 기능을 참조 하세요.

  상태 비저장 워크플로는 동기적으로만 실행되므로, 상태 저장 워크플로에서 사용되는 표준 비동기 작업 패턴을 사용하지 않습니다. 대신 "202 ACCEPTED" 응답을 반환하는 모든 HTTP 기반 작업은 워크플로 실행의 다음 단계로 계속됩니다. 응답에 location 헤더가 포함된 경우 상태 비저장 워크플로는 지정된 URI를 폴링하여 상태를 확인하지 않습니다. 표준 비동기 작업 패턴을 따르려면 상태 저장 워크플로를 대신 사용합니다.

  디버깅을 더 쉽게 수행하려면 성능에 영향을 주는 상태 비저장 워크플로에 대해 실행 기록을 사용하도록 설정한 다음, 완료되면 실행 기록을 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 Visual Studio Code 에서 단일 테넌트 기반 워크플로 만들기 또는 Azure Portal에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.

Important

만들 때 구현할 워크플로 형식(상태 저장 또는 상태 비저장)을 결정해야 합니다. 만들기 후 워크플로 형식을 변경하면 런타임 오류가 발생합니다.

상태 저장 워크플로와 상태 비저장 워크플로의 차이점 요약

상태 저장	상태 비저장
실행 기록, 입력, 출력 저장	기본적으로 실행 기록, 입력 또는 출력을 저장하지 않음
관리되는 커넥터 트리거를 사용할 수 있고 허용함	관리되는 커넥터 트리거를 사용할 수 없거나 허용하지 않음
청크 지원	청크를 지원하지 않음
비동기 작업 지원	비동기 작업을 지원하지 않음
호스트 구성에서 최대 기본 실행 기간 편집	최대 기간이 5분 미만인 워크플로에 가장 적합함
큰 메시지 처리	작은 메시지 크기(64KB 미만)를 처리하는 데 가장 적합함

상태 저장 워크플로와 상태 비지방 워크플로 간의 중첩된 동작 차이점

요청 트리거, HTTP 웹후크 트리거 또는 Api커넥트ionWebhook 형식이 있고 HTTPS 요청을 받을 수 있는 관리형 커넥터 트리거를 사용하여 동일한 표준 논리 앱에 있는 다른 워크플로에서 워크플로를 호출할 수 있도록 할 수 있습니다.

다음 목록은 상위 워크플로가 하위 워크플로를 호출한 후 중첩된 워크플로가 따를 수 있는 동작 패턴을 설명합니다.

• 비동기 폴링 패턴

  상위 워크플로는 하위 워크플로가 초기 호출에 응답할 때까지 기다리지 않습니다. 그러나 부모는 자식이 실행을 마칠 때까지 자식의 실행 기록을 계속 확인합니다. 기본적으로 상태 저장 워크플로는 요청 제한 시간을 초과할 수 있는 장기 실행 자식 워크플로에 적합한 이 패턴을 따릅니다.

• 동기 패턴("자체 유도")

  하위 워크플로는 202 ACCEPTED 응답을 즉시 반환하여 상위 워크플로의 호출을 확인합니다. 그러나 부모는 자식이 결과를 반환할 때까지 기다리지 않습니다. 대신 부모는 워크플로의 다음 작업을 계속 진행하고 자식 실행이 완료되면 결과를 받습니다. 응답 작업을 포함하지 않는 자식 상태 저장 워크플로는 항상 동기 패턴을 따르고 사용자가 검토할 수 있도록 실행 기록을 제공합니다.

  이 동작을 사용하도록 설정하려면 워크플로의 JSON 정의에서 속성을 DisableAsyncPattern.로 설정합니다operationOptions. 자세한 내용은 트리거 및 작업 유형 - 작업 옵션을 참조 하세요.

• 트리거 및 대기

  상태 비저장 워크플로는 메모리에서 실행됩니다. 따라서 상위 워크플로가 자식 상태 비저장 워크플로를 호출하면 부모는 자식의 결과를 반환하는 응답을 기다립니다. 이 패턴은 기본 제공 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 Operations 및 XML Operations에 대해 다음 작업을 사용할 수 있습니다. 이 작업에는 다음 작업이 포함됩니다.

    • XML: XML 변환, XML 유효성 검사

    • Liquid: JSON을 JSON으로 변환하고, JSON을 텍스트로 변환하고, XML을 JSON으로 변환하고 , XML을 텍스트로 변환

    참고 항목

    표준 워크플로에서 이러한 작업을 사용하려면 Liquid 맵, XML 맵 또는 XML 스키마가 있어야 합니다. 스키마 및 지도 섹션을 포함하는 아티팩트 아래에 있는 논리 앱의 리소스 메뉴에서 Azure Portal에서 이러한 아티팩트 업로드할 수 있습니다. 또는 각 지도 및 스키마 폴더를 사용하여 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 Premium 계획을 사용하여 논리 앱을 만들고 배포할 때 Azure Functions와 유사하게 Azure 가상 네트워크와 비공개로 연결 및 통합과 같은 네트워킹 기능에 액세스합니다. 자세한 내용은 다음 설명서를 검토하세요.

  • Azure Functions 네트워킹 옵션

  • 어디서나 실행되는 Azure Logic Apps - Azure Logic Apps를 사용하여 네트워킹 가능성

• 표준 논리 앱에서 개별 워크플로에서 사용하는 관리되는 연결에 대한 액세스 키를 다시 생성합니다. 이 작업의 경우 논리 앱 리소스 수준이 아닌 워크플로 수준에서 소비 논리 앱에 대해 동일한 단계를 수행합니다.

표준용 기본 제공 커넥터

표준 워크플로는 대부분의 동일한 기본 제공 커넥터를 소비 워크플로로 사용할 수 있지만 전부는 아닙니다. 그 반대의 경우도 마찬가지입니다. 표준 워크플로에는 소비 워크플로에서 사용할 수 없는 많은 기본 제공 커넥터가 있습니다.

예를 들어 표준 워크플로에는 Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server 등에 대한 관리형 커넥터와 기본 제공 커넥터가 모두 있습니다. 소비 워크플로에는 동일한 기본 제공 커넥터 버전이 없지만 Azure API Management 및 Azure 앱 Services와 같은 다른 기본 제공 커넥터를 사용할 수 있습니다.

단일 테넌트 Azure Logic Apps에서 특정 특성을 가진 기본 제공 커넥터를 비공식적으로 서비스 공급자라고 합니다. 일부 기본 제공 커넥터는 기본 서비스에 대한 연결을 인증하는 한 가지 방법만 지원합니다. 다른 기본 제공 커넥터는 연결 문자열, Microsoft Entra ID 또는 관리 ID 사용과 같은 옵션을 제공할 수 있습니다. 모든 기본 제공 커넥터는 다시 디자인된 Azure Logic Apps 런타임과 동일한 프로세스에서 실행됩니다. 자세한 내용은 표준 논리 앱 워크플로에 대한 기본 제공 커넥터 목록을 검토하세요.

변경됨, 제한됨, 사용할 수 없음 또는 지원되지 않는 기능

표준 논리 앱 워크플로의 경우 이러한 기능이 변경되었거나 현재 제한되거나 사용할 수 없거나 지원되지 않습니다.

• 트리거 및 작업: 기본 제공 트리거 및 작업은 Azure Logic Apps에서 기본적으로 실행되며 관리되는 커넥터는 Azure에서 공유 리소스를 사용하여 호스트되고 실행됩니다. 표준 워크플로의 경우 슬라이딩 윈도우, Azure 앱 서비스 및 Azure API Management와 같은 일부 기본 제공 트리거 및 작업을 현재 사용할 수 없습니다. 상태 저장 또는 상태 비저장 워크플로를 시작하려면 요청, Event Hubs 또는 Service Bus 트리거와 같은 기본 제공 트리거를 사용합니다. 되풀이 트리거는 상태 저장 워크플로에 사용할 수 있지만 상태 비저장 워크플로에는 사용할 수 없습니다. 디자이너에서 기본 제공 트리거 및 작업은 앱 내 레이블과 함께 표시되고 관리형 커넥터 트리거 및 작업은 공유 레이블과 함께 표시됩니다.

  상태 비저장 워크플로의 경우 관리 커넥터 작업을 사용할 수 있지만 관리 커넥터 트리거는 사용할 수 없습니다. 상태 비저장 워크플로에 대해 관리되는 커넥터를 사용하도록 설정할 수 있지만 디자이너는 추가할 관리되는 커넥터 트리거를 표시하지 않습니다.

  참고 항목

  Visual Studio Code에서 로컬로 실행하려면 웹후크 기반 트리거 및 작업에 추가 설정이 필요합니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.

  • 다음 트리거 및 작업이 변경되었거나 현재 제한되거나 지원되지 않거나 사용할 수 없습니다.

    • 기본 제공 작업인 Azure Functions - 이제 Azure Functions 작업인 Azure 함수 선택 - Azure 함수 호출 이 작업은 현재 HTTP 트리거 템플릿에서 만든 함수에 대해서만 작동합니다.

      Azure Portal에서 사용자 환경을 통해 연결을 만들어 액세스할 수 있는 HTTP 트리거 함수를 선택할 수 있습니다. 코드 뷰에서 함수 작업의 JSON 정의를 검사하거나 Visual Studio Code를 사용하여 workflow.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 Open Authentication(Microsoft Entra ID OAuth)입니다.

  • 관리 ID 인증: 시스템 할당 및 사용자 할당 관리 ID 지원을 모두 사용할 수 있습니다. 기본적으로 시스템 할당 관리 ID는 자동으로 사용하도록 설정됩니다. 그러나 대부분의 기본 제공 서비스 공급자 기반 커넥터는 현재 인증을 위해 사용자 할당 관리 ID 선택을 지원하지 않습니다.

• XML 변환: 현재 XSLT 1.0만 지원됩니다.

• Visual Studio Code의 중단점 디버깅: 워크플로에 대해 workflow.json 파일 내에서 중단점을 추가하고 사용할 수 있지만 중단점은 트리거가 아닌 현재 작업에 대해서만 지원됩니다. 자세한 내용은 Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기를 참조하세요.

• 트리거 기록 및 실행 기록: 표준 논리 앱의 경우 Azure Portal의 트리거 기록 및 실행 기록이 논리 앱 리소스 수준이 아닌 워크플로 수준에 표시됩니다. 자세한 내용은 Azure Portal을 사용하여 단일 테넌트 기반 워크플로 만들기를 참조하세요.

• 워크플로 실행 기록에 대한 백업 및 복원: 표준 논리 앱은 현재 워크플로 실행 기록에 대한 백업 및 복원을 지원하지 않습니다.

• 배포 대상: ISE(통합 서비스 환경) 또는 Azure 배포 슬롯에 표준 논리 앱 리소스를 배포할 수 없습니다.

• Azure API Management: 현재 표준 논리 앱 리소스를 Azure API Management로 가져올 수 없습니다. 그러나 소비 논리 앱 리소스를 가져올 수 있습니다.

엄격한 네트워크 및 방화벽 트래픽 권한

현재 환경에 트래픽을 제한하는 엄격한 네트워크 요구 사항 또는 방화벽이 있는 경우 워크플로의 트리거 또는 작업 연결에 대한 액세스를 허용해야 합니다. 필요에 따라 서비스 태그의 트래픽을 허용하고 Azure App Service와 동일한 수준의 제한 또는 정책을 사용할 수 있습니다. 또한 연결에 대한 FQDN(정규화된 도메인 이름)을 찾아 사용해야 합니다. 자세한 내용은 다음 문서에서 해당 섹션을 검토합니다.

• 단일 테넌트 논리 앱에 대한 방화벽 권한 - Azure Portal
• 단일 테넌트 논리 앱에 대한 방화벽 권한 - Visual Studio Code

다음 단계

• Azure Portal에서 단일 테넌트 기반 워크플로 만들기
• Visual Studio Code에서 단일 테넌트 기반 워크플로 만들기

또한 단일 테넌트 Azure Logic Apps를 사용하는 환경에 대해서도 듣고 싶습니다.

• 버그 또는 문제가 발견되는 경우 GitHub에서 문제를 알려주세요.
• 질문, 요청, 의견 및 기타 피드백 의 경우 이 피드백 양식을 사용합니다.