다음을 통해 공유


Azure Logic Apps 규칙 엔진 실행에 대한 최적화(미리 보기)

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

Important

이 기능은 미리 보기로 제공되고 Microsoft Azure 미리 보기의 추가 사용 약관이 적용됩니다.

Azure Logic Apps 규칙 엔진은 Microsoft 규칙 작성기를 사용하여 만들 수 있는 규칙 집합에 대한 실행 컨텍스트를 제공합니다. 이 가이드에서는 규칙 엔진의 작동 방식에 대한 핵심 개념을 설명하고 작업 및 실행에 대한 최적화 권장 사항을 제공합니다.

핵심 구성 요소

  • 규칙 집합 실행기

    이 구성 요소는 규칙 조건 평가 및 작업 실행을 담당하는 알고리즘을 구현합니다. 기본 규칙 집합 실행기는 메모리 내 작업을 최적화하도록 설계된 차별 네트워크 기반 정방향 체인 유추 엔진입니다.

  • 규칙 집합 번역기

    이 구성 요소는 RuleSet 개체를 입력으로 사용하고 규칙 집합의 실행 가능한 표현을 생성합니다. 기본 메모리 내 변환기에서는 규칙 집합 정의에서 컴파일된 차별 네트워크를 만듭니다.

  • 규칙 집합 추적 인터셉터

    이 구성 요소는 규칙 집합 실행기에서 출력을 수신하고 해당 출력을 규칙 집합 추적 및 모니터링 도구로 전달합니다.

조건 평가 및 작업 실행

Azure Logic Apps 규칙 엔진은 .NET 개체 또는 XML 문서에 규칙을 연결할 수 있는 매우 효율적인 유추 엔진입니다. 규칙 엔진은 다음 단계를 사용하여 규칙 집합 실행에 3단계 알고리즘을 사용합니다.

  • 성냥

    일치 단계에서 규칙 엔진은 규칙 조건에 정의된 조건자를 사용하여 규칙 엔진의 작업 메모리에 유지 관리되는 개체 참조인 팩트 형식을 사용하는 조건자에 대해 팩트를 일치합니다. 효율성을 위해 규칙 집합의 모든 규칙에서 패턴 일치가 발생하고 규칙 간에 공유되는 조건은 한 번만 일치합니다. 규칙 엔진은 작업 메모리에 부분 조건 일치를 저장하여 후속 패턴 일치 작업을 신속하게 수행할 수 있습니다. 패턴 일치 단계의 출력에는 규칙 엔진의 의제에 대한 업데이트가 포함됩니다.

  • 충돌 해결

    충돌 해결 단계에서 규칙 엔진은 실행 후보인 규칙을 검사하여 미리 결정된 해결 체계에 따라 실행할 다음 규칙 작업 집합을 결정합니다. 규칙 엔진은 일치 단계에서 찾은 모든 후보 규칙을 규칙 엔진의 의제에 추가합니다.

    기본 충돌 해결 체계는 규칙 집합 내의 규칙 우선 순위를 기반으로 합니다. 우선 순위는 Microsoft 규칙 작성기에서 구성할 수 있는 규칙 속성입니다. 숫자가 클수록 우선 순위가 높습니다. 여러 규칙이 트리거되면 규칙 엔진은 우선 순위가 높은 작업을 먼저 실행합니다.

  • 동작

    작업 단계에서 규칙 엔진은 해결된 규칙에서 작업을 실행합니다. 규칙 작업은 규칙 엔진에 새 팩트를 어설션할 수 있으며, 이로 인해 주기가 계속되며 정방향 체인이라고도 합니다.

    Important

    알고리즘은 현재 실행 중인 규칙을 선점하지 않습니다. 규칙 엔진은 일치 단계가 반복되기 전에 현재 실행 중인 규칙의 모든 작업을 실행합니다. 그러나 규칙 엔진의 의제에 대한 다른 규칙은 경기 단계가 다시 시작되기 전에 실행되지 않습니다. 일치 단계에서 규칙 엔진이 실행되기 전에 해당 규칙을 의제에서 제거할 수 있습니다.

예시

다음 예제에서는 일치, 충돌 해결 및 작업의 3단계 알고리즘이 작동하는 방법을 보여 줍니다.

규칙 1: 소득 평가

  • 선언적 표현

    신청자의 소득 대 대출 비율이 0.2 미만인 경우에만 신청자의 신용 등급을 받습니다.

  • IF - 비즈니스 개체를 사용한 THEN 표현

    IF Application.Income / Property.Price < 0.2
    THEN Assert new CreditRating( Application)
    

규칙 2: 신용 등급 평가

  • 선언적 표현

    신청자의 신용 등급이 725를 초과하는 경우에만 신청자를 승인합니다.

  • IF - 비즈니스 개체를 사용한 다음 표현:

    IF Application.SSN = CreditRating.SSN AND CreditRating.Value > 725
    THEN SendApprovalLetter(Application)
    

다음 표에서는 팩트를 요약합니다.

사실 설명 필드
애플리케이션 주택 대출 응용 프로그램을 나타내는 XML 문서입니다. - 소득: $65,000
- SSN: XXX-XX-XXXX
속성 구매할 속성을 나타내는 XML 문서입니다. - 가격: $225,000
CreditRating 대출 신청자의 신용 등급이 포함된 XML 문서입니다. - 값: 0-800
- SSN: XXX-XX-XXXX

작업 메모리 및 의제에 대한 업데이트

처음에는 규칙 엔진의 작업 메모리 및 의제가 비어 있습니다. 애플리케이션에서 애플리케이션속성 팩트를 추가한 후 규칙 엔진은 다음과 같이 작업 메모리 및 의제를 업데이트합니다.

작업 메모리 어젠더
-신청
-재산
규칙 1
  • 규칙 엔진은 일치 단계에서 Application.Income/ Property.Price 0.2 조건이 true로 평가되므로 규칙 엔진이 규칙 1 < 을 의제에 추가합니다.

  • 작업 메모리에 CreditRating 팩트가 없으므로 규칙 2의 조건이 평가되지 않습니다.

  • 규칙 1은 의제의 유일한 규칙이므로 규칙이 실행되고 의제에서 사라집니다.

  • 규칙 1은 작업 메모리에 추가되는 신청자의 CreditRating 문서인 새 사실을 생성하는 단일 작업을 정의합니다.

  • 규칙 1이 실행을 완료하면 컨트롤이 일치 단계로 돌아갑니다.

    일치하는 유일한 새 개체는 CreditRating 팩트이므로 일치 단계의 결과는 다음과 같습니다.

    작업 메모리 어젠더
    -신청
    -재산
    - CreditRating
    규칙 2
  • 이제 규칙 2가 실행되어 지원자에게 승인서를 보내는 함수를 호출합니다.

  • 규칙 2가 완료되면 컨트롤이 일치 단계로 돌아갑니다. 그러나 더 이상 일치시킬 수 있는 새 팩트가 없고 안건이 비어 있으므로 앞으로 연결이 종료되고 규칙 집합 실행이 완료됩니다.

의제 및 우선 순위

Azure Logic Apps 규칙 엔진이 규칙을 평가하고 작업을 실행하는 방법을 이해하려면 의제우선 순위개념에 대해서도 알아보세요.

어젠더

규칙 엔진의 의제는 실행을 위한 규칙을 큐에 대기하는 일정입니다. 의제는 엔진 인스턴스에 대해 존재하며 일련의 규칙 집합이 아닌 단일 규칙 집합에서 작동합니다. 팩트가 작업 메모리에 어설션되고 규칙의 조건이 충족되면 엔진은 규칙을 의제에 배치하고 우선 순위에 따라 해당 규칙을 실행합니다. 엔진은 우선 순위 위에서 아래로 규칙의 작업을 실행한 다음 안건에 대한 다음 규칙에 대한 작업을 실행합니다.

규칙 엔진은 규칙의 작업을 블록으로 처리하므로 엔진이 다음 규칙으로 이동하기 전에 모든 작업이 실행됩니다. 규칙 블록의 모든 작업은 블록의 다른 작업에 관계없이 실행됩니다. 어설션에 대한 자세한 내용은 제어 함수를 사용하여 규칙 엔진 최적화를 참조 하세요 .

다음 예제에서는 안건 작동 방식을 보여 줍니다.

규칙 1

IF
Fact1 == 1
THEN
Action1
Action2

규칙 2

IF
Fact1 > 0
THEN
Action3
Action4

값이 1인 Fact1 팩트가 엔진에 어설션되면 규칙 1과 규칙 2 모두 조건이 충족됩니다. 따라서 엔진은 두 규칙을 모두 의제로 이동하여 작업을 실행합니다.

작업 메모리 어젠더
팩트 1(value=1) 규칙 1:
- Action1
- Action2

규칙 2:
- Action3
- Action4

우선 순위

기본적으로 모든 규칙은 실행 우선 순위로 0으로 설정됩니다. 그러나 각 개별 규칙에서 이 우선 순위를 변경할 수 있습니다. 우선 순위는 우선 순위가 더 큰 0의 양쪽에 해당할 수 있습니다. 엔진은 가장 높은 우선 순위에서 가장 낮은 우선 순위로 작업을 실행합니다.

다음 예제에서는 우선 순위가 규칙에 대한 순서 실행에 미치는 영향을 보여 줍니다.

규칙 1(우선 순위 = 0)

IF
Fact1 == 1
THEN
Discount = 10%

규칙 2(우선 순위 = 10)

IF
Fact1 > 0
THEN
Discount = 15%

두 규칙의 조건이 모두 충족되지만 우선 순위가 높기 때문에 규칙 2가 먼저 실행됩니다. 다음 표와 같이 규칙 1에 대해 실행된 작업의 결과로 인해 최종 할인이 10%입니다.

작업 메모리 어젠더
Fact1(value=1) 규칙 2:
할인: 15%

규칙 1:
할인: 10%

작업 부작용

동작의 실행이 개체의 상태 또는 조건에서 사용되는 용어에 영향을 주는 경우 이 작업은 해당 개체 또는 용어에 "부작용"이 있다고 합니다. 이 구는 작업에 부작용이 있다는 것을 의미하지는 않지만 개체 또는 용어가 하나 이상의 작업의 영향을 받을 수 있습니다.

예를 들어 다음과 같은 규칙이 있다고 가정합니다.

규칙 1

IF OrderForm.ItemCount > 100
THEN OrderForm.Status = "Important"

규칙 2

IF OrderList.IsFromMember = true
THEN OrderForm.UpdateStatus("Important")

이 예제에서 OrderForm.UpdateStatus는 OrderForm.Status"부작용"이 있습니다. 즉, OrderForm.Status는 하나 이상의 작업의 영향을 받을 수 있습니다.

.NET 클래스 멤버에 대한 SideEffects 속성은 기본값으로 true로 설정되므로 규칙 엔진이 부작용이 있는 멤버를 캐싱하지 못하게 합니다. 이 예제에서 규칙 엔진은 작업 메모리에 OrderForm.Status를 캐시하지 않습니다. 대신 엔진은 엔진이 규칙 1을 평가할 때마다 OrderForm.Status최신 값을 가져옵니다. SideEffects 속성 값이 false면 엔진이 OrderForm.Status를 처음으로 평가할 때 규칙 엔진에서 값을 캐시합니다. 그러나 이후 정방향 체인 시나리오 평가의 경우 엔진은 캐시된 값을 사용합니다.

Microsoft 규칙 작성기는 현재 SideEffects 속성 값을 수정하는 방법을 제공하지 않습니다. 그러나 Microsoft인 비즈니스 규칙 프레임워크를 통해 SideEffects 속성 값을 프로그래밍 방식으로 설정할 수 있습니다. NET 규격 클래스 라이브러리. ClassMemberBinding 클래스를 사용하여 규칙 조건 및 작업에 사용되는 개체 메서드, 속성 및 필드를 지정하여 바인딩 시 이 값을 설정합니다. ClassMemberBinding 클래스에는 SideEffects라는 속성이 있으며 멤버에 액세스하면 해당 값이 변경되는지 여부를 나타내는 부울 값이 포함되어 있습니다.

성능 고려 사항

이 섹션에서는 다양한 시나리오에서 Azure Logic Apps 규칙 엔진이 수행하는 방법과 구성 및 튜닝 매개 변수에 대한 다양한 값을 설명합니다.

팩트 형식

규칙 엔진은 XML 팩트 액세스보다 .NET 팩트 액세스 시간이 적습니다. 규칙 집합에서 .NET 팩트 또는 XML 팩트 사용 중에서 선택할 수 있는 경우 성능 향상을 위해 .NET 팩트를 사용하는 것이 좋습니다.

규칙 우선 순위

규칙의 우선 순위 설정은 우선 순위가 더 높은 숫자가 많은 0어느 한 쪽까지 다양할 수 있습니다. 작업은 가장 높은 우선 순위에서 가장 낮은 우선 순위까지 순서대로 실행됩니다. 규칙 집합이 Assert 또는 Update 호출을 사용하여 정방향 체인 동작을 구현하는 경우 Priority 속성을 사용하여 체인을 최적화할 수 있습니다.

예를 들어 규칙 2규칙 1로 설정된 값에 대한 종속성이 있다고 가정합니다. 규칙 1의 우선 순위가 더 높은 경우 규칙 2는 규칙 1이 실행되고 값을 업데이트한 후에만 실행됩니다. 반대로 규칙 2의 우선 순위가 더 높은 경우 규칙이 한 번 실행된 다음 규칙 1이 실행되고 규칙 2의 조건에서 팩트를 업데이트한 후 다시 실행됩니다. 이 시나리오는 올바른 결과를 생성하거나 생성하지 않을 수도 있지만, 분명히 두 번 실행하면 성능에 영향을 미치며 한 번만 발생합니다.

자세한 내용은 Microsoft 규칙 작성기를 사용하여 규칙 만들기를 참조하세요.

논리 OR 연산자

규칙 엔진은 논리 AND 연산자를 실행하도록 최적화되고 엔진이 분리형 표준 형식으로 구문 분석한 규칙을 재구성하여 논리 OR 연산자가 최상위 수준에서만 사용되도록 합니다.

조건에서 더 많은 논리 OR 연산자를 사용하는 경우 증가는 규칙 엔진의 분석 네트워크를 확장하는 더 많은 순열을 만듭니다. 따라서 규칙 엔진이 규칙을 정규화하는 데 시간이 오래 걸릴 수 있습니다.

다음 목록에서는 이 문제에 대한 가능한 해결 방법을 제공합니다.

  • OR 연산자가 최상위 수준에만 있도록 규칙을 분리형 표준 형식으로 변경합니다.

    Microsoft 규칙 작성기에서 규칙을 일반 형식으로 만드는 것이 까다로울 수 있으므로 프로그래밍 방식으로 규칙을 만드는 것이 어려울 수 있습니다.

  • OR 작업을 수행하고 부울 값을 반환하는 도우미 구성 요소를 개발한 다음 규칙에서 구성 요소를 사용합니다.

  • 규칙을 여러 규칙으로 분할하고 규칙이 이전에 실행된 규칙에 의해 설정된 플래그를 확인하도록 하거나 이전에 실행한 규칙이 어설션한 개체를 사용합니다. 예를 들면 다음과 같습니다.

    • 규칙 1: IF (a == 1 OR a == 3) THEN b = true

      규칙 2: IF (b == true) THEN …

    • 규칙 1: IF (a == 1 OR a == 3) THEN Assert(new c())

      규칙 2: IF (c.flag == true) THEN …

호출 업데이트

Update 함수는 규칙 엔진의 작업 메모리에 존재하는 팩트를 업데이트하여 조건에서 업데이트된 팩트를 사용하는 모든 규칙에 대한 재평가를 수행합니다. 이 동작은 업데이트 함수 호출이 비용이 많이 들 수 있으며, 특히 업데이트된 팩트 때문에 많은 규칙에서 재평가가 필요한 경우 비용이 많이 들 수 있습니다. 경우에 따라 규칙을 다시 평가하지 않아도 됩니다.

예를 들어 다음 규칙을 고려합니다.

규칙 1

IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)

규칙 2

IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)

규칙 집합의 나머지 모든 규칙은 해당 조건에서 StatusObj.Flag를 사용합니다. StatusObj 개체에서 Update 함수를 호출하면 모든 규칙이 다시 평가됩니다. 금액 필드에 값이 무엇이든 간에 규칙 1규칙 2를 제외한 모든 규칙은 업데이트 호출 전에 한 번, 업데이트 호출 후에 한 번씩 두 번 평가됩니다.

대신 규칙 집합을 호출하기 전에 플래그 값을 false설정한 다음 규칙 집합에서 규칙 1사용하여 플래그를 설정할 수 있습니다. 이 경우 Update 함수는 Amount 값이 5보다 큰 경우에만 호출됩니다. 크기가 5보다 작거나 같으면 Update 함수가 호출되지 않습니다. 이렇게 하면 Amount 값이 5보다 큰 경우에만 규칙 1규칙 2제외한 모든 규칙이 두 번 평가됩니다.

SideEffects 속성 동작

XmlDocumentFieldBindingClassMemberBinding 클래스에서 SideEffects 속성은 바인딩된 필드, 멤버 또는 열의 값을 캐시할지 여부를 결정합니다.

XmlDocumentFieldBinding 클래스에서 SideEffects 속성의 기본값은 false입니다. 그러나 ClassMemberBinding 클래스에서 SideEffects 속성의 기본값은 true입니다.

따라서 엔진이 규칙 집합 내에서 두 번째 이상 XML 문서의 필드에 액세스하는 경우 엔진은 캐시에서 필드 값을 가져옵니다. 그러나 엔진이 규칙 집합 내에서 두 번째 이상 .NET 개체의 멤버에 액세스하는 경우 엔진은 캐시가 아닌 .NET 개체에서 값을 가져옵니다.

이 동작은 .NET ClassMemberBinding에서 SideEffects 속성을 false설정하는 경우 엔진이 두 번째부터 시작하여 캐시에서 멤버의 값을 가져오므로 성능을 향상시킬 수 있음을 의미합니다. 그러나 Microsoft 규칙 작성기에서 SideEffects 속성을 노출 하지 않으므로 프로그래밍 방식으로만 속성 값을 설정할 수 있습니다 .

인스턴스 및 선택성

XmlDocumentBindingClassBinding 클래스에는 각각 규칙 엔진이 해당 값을 사용하여 조건 평가를 최적화하는 다음과 같은 속성이 있습니다. 이러한 속성 값을 사용하면 엔진이 조건 평가에서 가능한 가장 적은 인스턴스를 먼저 사용한 다음 나머지 인스턴스를 사용할 수 있습니다.

  • 인스턴스: 작업 메모리의 예상 클래스 인스턴스 수입니다.

    개체 인스턴스 수를 미리 알고 있는 경우 Instances 속성을 이 숫자로 설정하여 성능을 향상시킬 수 있습니다.

  • 선택성: 규칙 조건을 성공적으로 통과한 클래스 인스턴스의 백분율입니다.

    조건을 미리 전달하는 개체 인스턴스의 백분율을 알고 있는 경우 성능 향상을 위해 Selectivity 속성을 이 백분율로 설정할 수 있습니다.

이러한 속성 값은 Microsoft 규칙 작성기에서 노출하지 않으므로 프로그래밍 방식으로만 설정할 수 있습니다.

클래스 상속 지원

상속은 OOP(개체 지향 프로그래밍) 언어의 핵심 기능인 원래 클래스를 다시 작성하지 않고 기존 클래스의 모든 기능을 사용하고 해당 기능을 확장하는 기능입니다.

Azure Logic Apps 규칙 엔진은 다음과 같은 종류의 클래스 상속을 지원합니다.

  • 구현 상속: 다른 코딩 없이 기본 클래스의 속성 및 메서드를 사용하는 기능입니다.

  • 인터페이스 상속: 속성 이름 및 메서드 이름만 사용하는 기능이지만 자식 클래스는 구현을 제공해야 합니다.

규칙 엔진을 사용하면 공통 기본 클래스를 기준으로 규칙을 작성할 수 있지만 규칙 엔진에 어설션된 개체는 파생 클래스에서 가져올 수 있습니다.

다음 예제에는 Employee라는 기본 클래스가 있지만 파생 클래스의 이름은 RegularEmployeeContractEmployee입니다.

class Employee
{
    public string Status()
    {
        // member definition
    }
    public string TimeInMonths()
    {
        // member definition
    }
}

class ContractEmployee : Employee
{
   // class definition
}
class RegularEmployee : Employee
{
   // class definition
}

이 예제에서는 다음 규칙이 있다고 가정합니다.

규칙 1

IF Employee.TimeInMonths < 12
THEN Employee.Status = "New"

At run time, if you assert two objects, a **ContractEmployee** instance and a **RegularEmployee** instance, the engine evaluates both objects against the Rule 1.

You can also assert derived class objects in actions by using an **Assert** function. This function causes the engine to reevaluate rules that contain the derived object and the base type in their conditions as shown in the following example, which demonstrates implementation inheritance:

**Rule 2**

```text
IF Employee.Status = "Contract"
THEN Employee.Bonus = false
Assert(new ContractEmployee())

어설션 후에 엔진은 해당 조건에서 Employee 형식 또는 ContractEmployee 형식을 포함하는 모든 규칙을 다시 평가합니다. 파생 클래스만 어설션되더라도 파생 클래스가 아닌 기본 클래스의 메서드를 사용하여 규칙을 작성하는 경우에도 기본 클래스가 어설션됩니다.