Aplicações de escala Dapr com escaladores KEDA

O Aplicativos de Contêiner do Azure dimensiona automaticamente o tráfego HTTP para zero. No entanto, para dimensionar tráfego não HTTP (como Dapr pub/sub e vinculações), você pode usar KEDA scalers 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.

Esse guia demonstra como configurar as regras de escala de um aplicativo Dapr pub/sub com um escalonador de mensagens KEDA. Para contexto, consulte os aplicativos pub/sub de exemplo correspondentes:

• Comunicação de microsserviços usando pub/sub em C#
• Comunicação de microsserviços usando pub/sub em JavaScript
• Comunicação de microsserviços usando pub/sub em Python

Nos exemplos acima, o aplicativo usa os seguintes elementos:

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

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

Aplicativo de contêiner do Editor

O checkout Editor é um serviço headless que roda indefinidamente e nunca chega a zero.

Por padrão, o tempo de execução dos Aplicativos de Contêiner do Azure atribui uma regra de escala baseada em HTTP aos aplicativos, que direciona o dimensionamento com base no número de solicitações HTTP recebidas. No exemplo a seguir, minReplicas é definido como 1. Essa configuração garante que o aplicativo de contêiner não siga o comportamento padrão de escala 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 seguinte order-processor aplicativo de assinante inclui uma regra de escala personalizada que monitora um recurso do tipo azure-servicebus. Com essa regra, o aplicativo (e seu sidecar) aumenta ou diminui conforme necessário com base no número de mensagens pendentes no Bus.

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 propriedade messageCount na configuração do scaler no aplicativo do assinante:

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

Essa propriedade informa ao scaler quantas mensagens cada instância do aplicativo pode processar ao mesmo tempo. Nesse 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 houver 150 mensagens aguardando, o KEDA dimensiona 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 de 10 instâncias desse aplicativo. Essa configuração garante que você não aumente muito e acumule muitos custos.

Próximas etapas

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