다음을 통해 공유

KEDA 스칼라를 사용하여 Dapr 애플리케이션 스케일링

  • 아티클

Azure Container Apps는 HTTP 트래픽을 0으로 자동 스케일링합니다. 그러나 비 HTTP 트래픽(예: Dapr pub/sub 및 바인딩)을 스케일링하려면 KEDA 스칼라를 사용하여 보류 중인 인바운드 이벤트 및 메시지 수에 따라 애플리케이션 및 Dapr 사이드카를 스케일링할 수 있습니다.

이 가이드에서는 KEDA 메시징 스케일러를 사용하여 Dapr pub/sub 애플리케이션의 스케일링 규칙을 구성하는 방법을 보여 줍니다. 컨텍스트를 보려면 해당 pub/sub 애플리케이션 샘플을 참조하세요.

위의 샘플에서 애플리케이션은 다음 요소를 사용합니다.

  1. checkout 게시자는 들어오는 HTTP 트래픽을 수신하지 않았음에도 불구하고 무기한 실행되고 0으로 스케일 다운되지 않는 애플리케이션입니다.
  2. Dapr Azure Service Bus pub/sub 구성 요소입니다.
  3. order-processor 구독자 컨테이너 앱은 orders 토픽을 통해 수신되고 도착 시 처리되는 메시지를 선택합니다.
  4. 메시지가 orders 토픽에 도착하기 시작할 때 order-processor 서비스 및 해당 Dapr 사이드카의 스케일 업을 담당하는 Azure Service Bus의 스케일링 규칙입니다.

주문 처리 애플리케이션의 크기 조정 아키텍처를 보여 주는 다이어그램.

Dapr 애플리케이션에서 스케일링 규칙을 적용하는 방법을 살펴보겠습니다.

게시자 컨테이너 앱

checkout 게시자는 무한정 실행되고 0으로 스케일 다운되지 않는 헤드리스 서비스입니다.

기본적으로 Container Apps 런타임은 들어오는 HTTP 요청 수에 따라 스케일링을 구동하는 HTTP 기반 스케일링 규칙을 애플리케이션에 할당합니다. 다음 예제에서 minReplicas가 1로 설정됩니다. 이 구성은 컨테이너 앱이 들어오는 HTTP 트래픽 없이 0으로 스케일링하는 기본 동작을 따르지 않도록 합니다.

resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-checkout-${resourceToken}'
  location: location
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    //...
    template: {
      //...
      // Scale the minReplicas to 1
      scale: {
        minReplicas: 1
        maxReplicas: 1
      }
    }
  }
}

구독자 컨테이너 앱

다음 order-processor 구독자 앱에는 azure-servicebus 형식의 리소스를 모니터링하는 사용자 지정 스케일링 규칙이 포함되어 있습니다. 이 규칙을 사용하면 앱(및 사이드카)이 버스에서 보류 중인 메시지 수를 토대로 필요에 따라 스케일 업 및 다운됩니다.

resource orders 'Microsoft.App/containerApps@2022-03-01' = {
  name: 'ca-orders-${resourceToken}'
  location: location
  tags: union(tags, {
      'azd-service-name': 'orders'
    })
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    managedEnvironmentId: containerAppsEnvironment.id
    configuration: {
      //...
      // Enable Dapr on the container app
      dapr: {
        enabled: true
        appId: 'orders'
        appProtocol: 'http'
        appPort: 5001
      }
      //...
    }
    template: {
      //...
      // Set the scale property on the order-processor resource
      scale: {
        minReplicas: 0
        maxReplicas: 10
        rules: [
          {
            name: 'topic-based-scaling'
            custom: {
              type: 'azure-servicebus'
              identity: 'system'
              metadata: {
                topicName: 'orders'
                subscriptionName: 'membership-orders'
                messageCount: '30'
              }
            }
          }
        ]
      }
    }
  }
}

스케일러의 작동 방식

구독자 앱에서 스케일러 구성의 messageCount 속성을 확인합니다.

{
  //...
  properties: {
    //...
    template: {
      //...
      scale: {
        //...
        rules: [
          //...
          custom: {
            //...
            metadata: {
              //...
              messageCount: '30'
            }
          }
        ]
      }
    }
  }
}

이 속성은 애플리케이션의 각 인스턴스가 동시에 처리할 수 있는 메시지 수를 스케일러에 알려줍니다. 이 예제에서 값은 30으로 설정되며, 이는 토픽에서 대기 중인 30개 메시지의 각 그룹에 대해 만들어진 애플리케이션의 인스턴스가 하나 있어야 함을 나타냅니다.

예를 들어 150개의 메시지가 대기 중인 경우 KEDA는 앱을 5개의 인스턴스로 스케일 아웃합니다. maxReplicas 속성은 10로 설정됩니다. 항목에 많은 수의 메시지가 있더라도 배율 조정기는 이 애플리케이션의 인스턴스를 10개 이상 만들지 않습니다. 이 설정을 사용하면 너무 많이 스케일 업되어 너무 많은 비용이 발생하지 않도록 할 수 있습니다.

다음 단계

Dapr 구성 요소와 Azure Container Apps를 함께 사용하는 방법에 대해 자세히 알아봅니다.