Partilhar via


Dimensione aplicações Dapr com escaladores KEDA

Os Aplicativos de Contêiner do Azure dimensionam automaticamente o tráfego HTTP para zero. No entanto, para dimensionar o tráfego não-HTTP (como pub/sub Dapr e associações), você pode usar escaladores KEDA para dimensionar seu aplicativo e seu sidecar Dapr para cima e para baixo, com base no número de eventos e mensagens de entrada pendentes.

Este guia demonstra como configurar as regras de escala de um aplicativo pub/sub Dapr com um escalador de mensagens KEDA. Para contextualizar, consulte os exemplos de aplicativos pub/sub correspondentes:

Nos exemplos acima, o aplicativo usa os seguintes elementos:

  1. O checkout editor é um aplicativo que deve ser executado indefinidamente e nunca reduzir para zero, apesar de nunca receber nenhum tráfego HTTP de entrada.
  2. O componente pub/sub do Dapr Azure Service Bus.
  3. Um order-processor aplicativo de contêiner de assinante pega mensagens recebidas por meio do orders tópico e processadas à medida que chegam.
  4. A regra de escala para o Barramento de Serviço do Azure, que é responsável por dimensionar o order-processor serviço e seu sidecar Dapr quando as orders mensagens começam a chegar ao tópico.

Diagrama mostrando a arquitetura de dimensionamento do aplicativo de processamento de pedidos.

Vamos dar uma olhada em como aplicar as regras de dimensionamento em um aplicativo Dapr.

Aplicativo de contêiner do Publisher

O checkout editor é um serviço sem cabeça que funciona indefinidamente e nunca é reduzido a zero.

Por padrão, o tempo de execução de Aplicativos de Contêiner atribui uma regra de escala baseada em HTTP a aplicativos, que direciona o dimensionamento com base no número de solicitações HTTP de entrada. No exemplo a seguir, minReplicas é definido como 1. Essa configuração garante que o aplicativo contêiner não siga o comportamento padrão de dimensionamento para zero sem tráfego HTTP de entrada.

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
      }
    }
  }
}

Aplicativo de contêiner de assinante

O aplicativo de assinante a seguir order-processor inclui uma regra de escala personalizada que monitora um recurso do tipo azure-servicebus. Com essa regra, o aplicativo (e seu sidecar) aumenta e diminui conforme necessário com base no número de mensagens pendentes no ônibus.

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'
              }
            }
          }
        ]
      }
    }
  }
}

Como funciona o scaler

Observe a messageCount propriedade na configuração do escalador no aplicativo do assinante:

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

Essa propriedade informa ao escalador quantas mensagens cada instância do aplicativo pode processar ao mesmo tempo. Neste exemplo, o valor é definido como 30, indicando que deve haver uma instância do aplicativo criada para cada grupo de 30 mensagens aguardando no tópico.

Por exemplo, se 150 mensagens estiverem aguardando, o KEDA dimensionará o aplicativo para cinco instâncias. A propriedade maxReplicas está definida como 10. Mesmo com um grande número de mensagens no tópico, o scaler nunca cria mais do que 10 instâncias deste aplicativo. Essa configuração garante que você não aumente muito a escala e acumule muitos custos.

Próximos passos

Saiba mais sobre como usar componentes do Dapr com os Aplicativos de Contêiner do Azure.