Compartilhar via

Resiliência de descoberta de serviço (versão prévia)

  • Artigo

Com a resiliência dos Aplicativos de Contêiner do Azure, você pode prevenir, detectar e recuperar proativamente de falhas de solicitação de serviço usando políticas de resiliência simples. Neste artigo, você aprenderá a configurar políticas de resiliência dos Aplicativos de Contêiner do Azure ao iniciar solicitações usando a descoberta de serviço dos Aplicativos de Contêiner do Azure.

Observação

Atualmente, as políticas de resiliência não podem ser aplicadas a solicitações feitas usando a API de Invocação de Serviço Dapr.

As políticas estão em vigor para cada solicitação para um aplicativo de contêiner. Você pode personalizar políticas para o aplicativo de contêiner aceitando solicitações com configurações como:

  • O número de repetições
  • Duração do tempo limite de repetições
  • Repetir correspondências
  • Erros consecutivos de disjuntor e outros

A captura de tela a seguir mostra como um aplicativo usa uma política de repetição para tentar se recuperar de solicitações com falha.

Diagram demonstrating container app to container app resiliency using a container app's service name.

Políticas de resiliência com suporte

Configurar políticas de resiliência

Se você configurar políticas de resiliência usando o Bicep, a CLI ou o portal do Azure, você só poderá aplicar uma política por aplicativo de contêiner.

Quando você aplica uma política a um aplicativo de contêiner, as regras são aplicadas a todas as solicitações feitas a esse aplicativo de contêiner, não às solicitações feitas desse aplicativo de contêiner. Por exemplo, uma política de repetição é aplicada a um aplicativo de contêiner chamado App B. Todas as solicitações de entrada feitas ao Aplicativo B são repetidas automaticamente em caso de falha. No entanto, as solicitações de saída enviadas pelo aplicativo B não têm garantia de repetição em caso de falha.

O exemplo de resiliência a seguir demonstra todas as configurações disponíveis.

resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
  name: 'my-app-resiliency-policies'
  parent: '${appName}'
  properties: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
        connectionTimeoutInSeconds: 5
    }
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                        exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-status-codes'
                '5xx'
                'reset'
                'connect-failure'
                'retriable-4xx'
            ]
        }
    } 
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
    tcpConnectionPool: {
        maxConnections: 100
    }
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
  }
}

Especificações da política

Tempos limite

Os tempos limite são usados para encerrar operações de execução longa antecipada. A política de tempo limite inclui as propriedades a seguir.

properties: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadados Obrigatório Descrição Exemplo
responseTimeoutInSeconds Sim Tempo limite aguardando uma resposta do aplicativo de contêiner. 15
connectionTimeoutInSeconds Sim Tempo limite para estabelecer uma conexão com o aplicativo de contêiner. 5

Repetições

Defina tcpRetryPolicy ou uma estratégia de httpRetryPolicy para operações com falha. A política de repetição inclui as configurações a seguir.

httpRetryPolicy

properties: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                       exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-headers'
                'retriable-status-codes'
            ]
        }
    } 
}
Metadados Obrigatório Descrição Exemplo
maxRetries Sim Repetições máximas a serem executadas para uma solicitação http com falha. 5
retryBackOff Sim Monitore as solicitações e desligue todo o tráfego para o serviço afetado quando os critérios de tempo limite e repetição forem atendidos. N/D
retryBackOff.initialDelayInMilliseconds Sim Atraso entre o primeiro erro e a primeira repetição. 1000
retryBackOff.maxIntervalInMilliseconds Sim Atraso máximo entre as repetições. 10000
matches Sim Defina valores de correspondência para limitar quando o aplicativo deve tentar uma repetição. headers, httpStatusCodes, errors
matches.headers Y* Tente novamente quando a resposta de erro incluir um cabeçalho específico. *Os cabeçalhos só serão propriedades obrigatórias se você especificar a propriedade de erro retriable-headers. Saiba mais sobre correspondências de cabeçalho disponíveis. X-Content-Type
matches.httpStatusCodes Y* Tente novamente quando a resposta retornar um código de status específico. *Os códigos de status só serão propriedades obrigatórias se você especificar a propriedade de erro retriable-status-codes. 502, 503
matches.errors Sim Só tenta novamente quando o aplicativo retorna um erro específico. Saiba mais sobre extensões disponíveis. connect-failure, reset
Correspondências de cabeçalho

Se você especificou o erro retriable-headers, poderá usar as propriedades de correspondência de cabeçalho a seguir para tentar novamente quando a resposta incluir um cabeçalho específico.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadados Descrição
prefixMatch As repetições são executadas com base no prefixo do valor do cabeçalho.
exactMatch As repetições são executadas com base em uma correspondência exata do valor do cabeçalho.
suffixMatch As repetições são executadas com base no sufixo do valor do cabeçalho.
regexMatch As repetições são executadas com base em uma regra de expressão regular em que o valor do cabeçalho deve corresponder ao padrão regex.
Errors

Você pode executar repetições em qualquer um dos seguintes erros:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadados Descrição
retriable-headers Cabeçalhos de resposta HTTP que disparam uma repetição. Uma repetição será executada se qualquer uma das correspondências de cabeçalho corresponder aos cabeçalhos de resposta. Obrigatório se você quiser repetir em quaisquer cabeçalhos correspondentes.
retriable-status-codes Códigos de status HTTP que devem disparar repetições. Obrigatório se você quiser repetir em quaisquer código de status correspondentes.
5xx Repita se o servidor responder com quaisquer códigos de resposta 5xx.
reset Repita se o servidor não responder.
connect-failure Repita se uma solicitação falhou devido a uma conexão com falha com o aplicativo de contêiner.
retriable-4xx Repita se o aplicativo contêiner responder com um código de resposta da série 400, como 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadados Obrigatório Descrição Exemplo
maxConnectAttempts Sim Defina as tentativas máximas de conexão (maxConnectionAttempts) para repetir em conexões com falha. 3

Disjuntores

As políticas de disjuntor especificam se uma réplica de aplicativo de contêiner é temporariamente removida do pool de balanceamento de carga, com base em gatilhos como o número de erros consecutivos.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadados Obrigatório Descrição Exemplo
consecutiveErrors Sim Número consecutivo de erros antes que uma réplica de aplicativo de contêiner seja temporariamente removida do balanceamento de carga. 5
intervalInSeconds Sim A quantidade de tempo fornecida para determinar se uma réplica é removida ou restaurada do pool de balanceamento de carga. 10
maxEjectionPercent Sim Percentual máximo de réplicas de aplicativo de contêiner com falha para ejetar do balanceamento de carga. Remove pelo menos um host, independentemente do valor. 50

Pools de conexões

O pool de conexões do Aplicativo de Contêiner do Azure mantém um pool de conexões estabelecidas e reutilizáveis para aplicativos de contêiner. Esse pool de conexões reduz a sobrecarga de criar e derrubar conexões individuais para cada solicitação.

Os pools de conexões permitem especificar o número máximo de solicitações ou conexões permitidas para um serviço. Esses limites controlam o número total de conexões simultâneas para cada serviço. Quando esse limite é atingido, novas conexões não são estabelecidas para esse serviço até que as conexões existentes sejam liberadas ou fechadas. Esse processo de gerenciamento de conexões impede que os recursos sejam sobrecarregados por solicitações e mantém um gerenciamento eficiente de conexões.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadados Obrigatório Descrição Exemplo
http1MaxPendingRequests Sim Usado para solicitações de http1. Número máximo de conexões abertas para um aplicativo de contêiner. 1024
http2MaxRequests Sim Usado para solicitações de http2. Número máximo de solicitações simultâneas. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadados Obrigatório Descrição Exemplo
maxConnections Sim Número máximo de conexões simultâneas com um aplicativo contêiner. 100

Observabilidade de resiliência

Você pode executar a observabilidade de resiliência por meio das métricas e logs do sistema do seu aplicativo de contêiner.

Logs de resiliência

Na seção Monitoramento do aplicativo de contêiner, selecione Logs.

Screenshot demonstrating where to find the logs for your container app.

No painel Logs, grave e execute uma consulta para localizar resiliência por meio dos logs do sistema do aplicativo de contêiner. Por exemplo, execute uma consulta semelhante à seguinte para pesquisar eventos de resiliência e mostrar:

  • Carimbo de data/hora
  • Nome do ambiente
  • Nome do aplicativo de contêiner
  • Tipo de resiliência e motivo
  • Mensagens de Log
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Clique em Executar para executar a consulta e visualizar os resultados.

Screenshot showing resiliency query results based on provided query example.

Métricas de resiliência

Na seção Monitoramento do menu de contêiner, selecione Métricas. No painel Métricas, selecione os seguintes filtros:

  • O escopo do nome do aplicativo de contêiner.
  • O namespace das métricas Métricas padrão.
  • As métricas de resiliência do menu suspenso.
  • Como você gostaria dos dados agregados nos resultados (por média, por máximo, etc.).
  • A duração do tempo (últimos 30 minutos, últimas 24 horas etc.).

Screenshot demonstrating how to access the resiliency metrics filters for your container app.

Por exemplo, se você definir a métrica Repetições de Solicitação de Resiliência no escopo do test-app com agregação Média para pesquisar em um período de 30 minutos, os resultados serão semelhantes aos seguintes:

Screenshot showing the results from example metrics filters for resiliency.

Conteúdo relacionado

Veja como a resiliência funciona para Componentes dapr nos Aplicativos de Contêiner do Azure.