Partilhar via

Fiabilidade no Azure Functions

O Azure Functions é um serviço de computação orientado a eventos que permite executar pequenos blocos de código (funções) sem ter de provisionar ou gerir a infraestrutura explicitamente. As funções podem responder a eventos como pedidos HTTP, temporizadores, mensagens de fila e alterações noutros serviços Azure, tornando-as bem adequadas para processar dados, integrar sistemas e executar tarefas em segundo plano.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer suporte à resiliência e à recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Azure Functions resiliente a várias potenciais interrupções e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. Também destaca informações essenciais sobre o acordo de nível de serviço (SLA) da Azure Functions.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, desempenho, segurança, custo e operações. Para compreender como estas áreas se influenciam mutuamente e contribuem para uma solução fiável do Azure Functions, consulte as melhores práticas de arquitetura para Azure Functions.

Visão geral da arquitetura de confiabilidade

Quando implementas Azure Functions, é importante estar familiarizado com vários conceitos:

  • Planos de alojamento: Os planos representam o ambiente de alojamento das suas aplicações de funções. O plano determina os recursos de computação disponíveis, o modelo de preços e o comportamento de escalabilidade.

  • Contas de armazenamento: Ao criar uma aplicação funcional, deve especificar uma conta de armazenamento anfitrião. A conta de armazenamento é usada para gerir aspetos das operações internas da aplicação funcional, incluindo armazenamento de códigos de função, registo e gestão de concorrência (como arrendamentos de blob para certos tipos de triggers).

    Também pode usar uma conta de armazenamento para a implementação. Esta conta de armazenamento pode ser igual à conta de armazenamento do seu anfitrião ou uma conta de armazenamento diferente.

    Importante

    As contas de armazenamento são partes críticas da sua arquitetura de fiabilidade Azure Functions, e deve configurá-las para satisfazer os requisitos de resiliência da sua aplicação de funções.

  • Triggers e ligações: Estes permitem que a sua função responda a eventos, receba e escreva dados de outros serviços.

  • Funções Duradouras: Funções duradouras são funções com estado, incluindo orquestrações de longa duração e entidades com estado.

    Quando usas Funções Duradouras, configuras um fornecedor de armazenamento, que armazena o estado. Precisa de avaliar as características de fiabilidade da loja de estado que escolher e configurá-la para satisfazer os seus requisitos de resiliência.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Considere as seguintes recomendações para lidar com falhas transitórias nas suas aplicações de funções:

  • Disparadores e associações: A plataforma Azure Functions inclui o tratamento integrado de falhas transitórias para muitos disparadores e associações. Quando ocorre uma falha transitória enquanto um gatilho suportado está a disparar ou uma ligação suportada está a ler ou gravar dados, a plataforma pode tentar automaticamente a operação. Este comportamento de nova tentativa incorporado ajuda a garantir que problemas temporários de conectividade ou interrupções de serviço não impeçam a sua função de ser executada. Para mais informações, consulte o tratamento de erros e tentativas de erro do Azure Functions.

    No entanto, esta proteção só cobre falhas transitórias. Falhas persistentes, como uma cadeia de ligação mal configurada ou um recurso eliminado, não são tentadas novamente.

    Falhas persistentes e falhas transitórias repetidas são tratadas como erros, e pode configurar o registo para captar informações sobre erros de execução de funções. Para obter mais informações, consulte Como configurar o monitoramento para o Azure Functions.

  • O seu código de função: No âmbito da sua função, é responsável por tratar falhas transitórias quando faz chamadas para serviços externos. Deve implementar lógica de retentativa, timeouts e padrões de disjuntores conforme apropriado para quaisquer chamadas de serviço externas feitas no seu código de função. Projeta as tuas funções para serem idempotentes sempre que possível, para que as repetições não ocasionem efeitos secundários duplicados.

  • Clientes: Qualquer aplicação cliente que se ligue a funções de forma síncrona, como usando uma ligação HTTP, deve ser resiliente a falhas transitórias.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Os planos de consumo não suportam zonas de disponibilidade. Se a redundância de zonas for um requisito para a sua carga de trabalho, considere usar os planos Flex Consumption, Premium ou Dedicated (App Service).

Os planos Flex Consumption suportam implantações redundantes em zonas.

Os planos premium suportam implantações redundantes por zonas.

Quando a redundância de zonas está ativada, a plataforma distribui automaticamente as instâncias do seu plano por todas as zonas de disponibilidade na região selecionada. Se alguma zona de disponibilidade na região tiver um problema, as suas funções continuam a funcionar usando instâncias em zonas saudáveis.

Também deve ativar o armazenamento redundante por zona (ZRS) na conta de armazenamento do anfitrião, o que garante que seja resiliente a interrupções de zona.

Diagrama mostrando o plano Azure Functions redundante por zonas com três instâncias distribuídas por três zonas e uma conta de armazenamento redundante por zona.

O plano Dedicado (App Service) suporta implementações redundantes por zona. Quando a redundância de zonas está ativada, a plataforma distribui automaticamente as suas instâncias por todas as zonas de disponibilidade na região selecionada. Configuras redundância de zonas no plano. Para detalhes completos sobre como o App Service lida com a redundância de zonas, veja Fiabilidade no Azure App Service.

Se não ativares a redundância de zonas, o teu plano é não zonal ou regional, o que significa que as instâncias do plano podem ser colocadas em qualquer zona de disponibilidade dentro da região ou dentro da mesma zona, e não são resilientes a falhas de zonas de disponibilidade. O seu plano pode sofrer indisponibilidade durante uma interrupção em qualquer zona da região.

Requisitos

  • Apoio regional: Planos Flex Consumption redundantes por zonas podem ser implementados num conjunto específico de regiões. Pode obter a lista atual de regiões suportadas usando a CLI do Azure. Para mais informações, consulte Ver regiões que suportam zonas de disponibilidade.

  • Apoio regional: Os planos Premium redundantes por zona podem ser implementados nas seguintes regiões:

    Américas Europa Médio Oriente Africa Ásia-Pacífico
    Sul do Brasil Centro de França Israel Central Norte da África do Sul Leste da Austrália
    Canadá Central Alemanha Centro-Oeste Catar Central Índia Central
    E.U.A. Central Norte de Itália Norte dos E.A.U. Norte da China 3
    E.U.A. Leste Europa do Norte Ásia Leste
    E.U.A. Leste 2 Leste da Noruega Leste do Japão
    E.U.A. Centro-Sul Suécia Central Sudeste Asiático
    E.U.A. Oeste 2 Norte da Suíça
    E.U.A. Oeste 3 Sul do Reino Unido
    Europa Ocidental

  • Sistemas operativos: São suportados planos tanto para Windows como para Linux.

  • Número mínimo de instâncias: É necessário um mínimo de duas instâncias sempre prontas quando a redundância de zonas está ativada para planos Premium.

  • Conta de armazenamento do hospedeiro: Deve configurar a conta de armazenamento padrão da sua aplicação de funções para usar armazenamento redundante por zona (ZRS). Se usar uma conta de armazenamento de host que não está configurada para ZRS, a sua aplicação pode comportar-se de forma inesperada durante uma falha de zona.
  • Conta de armazenamento de contentores de implantação: Se usares uma conta de armazenamento separada para o contentor de implementação da aplicação, deves atualizá-la para ser redundante por zonas também.

Considerações

A redundância de zonas apenas garante o tempo de funcionamento contínuo para aplicações implementadas. Uma falha na zona de disponibilidade pode afetar alguns aspetos do Azure Functions, mesmo que a aplicação continue a servir o tráfego. Estes comportamentos incluem escalabilidade de planos, criação de aplicações, configuração de aplicações e publicação de aplicações.

Distribuição de instâncias entre zonas

Quando configura as aplicações do plano Flex Consumption como redundantes por zona, a plataforma distribui automaticamente as instâncias do plano por várias zonas na região selecionada, com regras diferentes para instâncias sempre prontas versus on-demand:

  • As instâncias sempre prontas são distribuídas por pelo menos duas zonas em formato de round-robin.

    Para garantir a resiliência das zonas, a plataforma mantém automaticamente pelo menos duas instâncias sempre prontas para cada função ou grupo de escalabilidade por função, independentemente da configuração sempre pronta para a aplicação. Todas as instâncias criadas pela plataforma são gerenciadas pela plataforma, cobradas como instâncias sempre prontas e não alteram as definições de configuração sempre prontas.

  • As instâncias on-demand são criadas como resultado do volume de fontes de eventos à medida que a aplicação escala para além do número de instâncias sempre prontas. As instâncias sob demanda são distribuídas entre zonas de disponibilidade com base no princípio do melhor esforço. A escalabilidade mais rápida é priorizada em detrimento da distribuição uniforme entre as zonas. A plataforma tenta equilibrar a distribuição ao longo do tempo.

Quando configura os planos da aplicação de função Elastic Premium como redundantes de zona, a plataforma distribui automaticamente as instâncias do plano por várias zonas na região selecionada. A propagação de instâncias segue estas regras, mesmo enquanto o aplicativo aumenta e diminui:

  • A contagem mínima de instâncias da aplicação de função é duas.
  • Quando você especifica uma capacidade maior do que o número de zonas, as instâncias são distribuídas uniformemente somente quando a capacidade é um múltiplo do número de zonas.
  • Para um valor de capacidade superior ao Número de Zonas * Número de instâncias, as instâncias extra são distribuídas entre as restantes zonas.

Quando o Functions aloca instâncias a um plano Premium redundante de zona, utiliza o balanceamento de zonas de melhor esforço, que o Azure Virtual Machine Scale Sets subjacente oferece. Um plano Premium é considerado equilibrado quando cada zona tem o mesmo número de máquinas virtuais em todas as outras zonas usadas pelo plano Premium, mais ou menos uma máquina virtual.

Custo

Não há custo adicional associado a ativar a redundância de zonas. A tarifação de um plano redundante por zona é a mesma que para um plano de zona única.

No entanto, quando ativa zonas de disponibilidade numa aplicação com uma configuração de instâncias sempre prontas com menos de duas instâncias para cada função ou grupo de escalonamento, a plataforma cria automaticamente duas instâncias do tipo sempre pronto para cada função ou grupo de escalabilidade por função. Estas novas instâncias também são faturadas como instâncias sempre disponíveis.

No entanto, se ativares zonas de disponibilidade num plano com menos de duas instâncias, a plataforma impõe um número mínimo de duas instâncias para esse plano, e és cobrado por ambas as instâncias.

Para detalhes completos sobre preços, consulte preços Azure Functions.

Configurar o suporte à zona de disponibilidade

  • Crie um novo plano Azure Functions redundante por zona. Podes ativar a redundância de zonas quando criares um novo plano. Para passos detalhados, consulte Criar uma Aplicação de Função redundante por zona.

  • Ative a redundância de zonas num plano existente: Nos planos Premium, só pode ativar a redundância de zonas durante a criação do plano. Não podes converter um plano Premium existente para ser redundante em zona. Em vez disso, deve migrar a sua aplicação criando uma implantação paralela numa nova aplicação com um plano Premium. Para mais informações, consulte Permitir redundância de zona num plano existente.

Planejamento e gerenciamento de capacidade

As aplicações de função com redundância de zona continuam a funcionar mesmo quando ocorrem falhas nas zonas da região.

Durante uma interrupção de zona, o Azure Functions deteta instâncias perdidas e tenta automaticamente localizar ou criar instâncias de substituição nas zonas saudáveis. Este processo é feito com base no melhor esforço e não é garantido. Se a sua carga de trabalho tiver de ter um certo número de instâncias para manter o nível de serviço esperado, considere sobreprovisionar o número de instâncias constantemente prontas. Esta abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem um desempenho degradado. Para obter mais informações, consulte Gerenciar a capacidade usando o provisionamento excessivo.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um plano é redundante em zonas, a conta de armazenamento do host utiliza ZRS, e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: Quando configura redundância de zonas no Azure Functions, os pedidos são automaticamente distribuídos pelas instâncias em cada zona de disponibilidade. Um pedido pode ir para qualquer instância em qualquer zona de disponibilidade.

  • Replicação de dados entre zonas: O Azure Functions é um serviço de computação sem estado, por isso não há dados de clientes para replicar entre zonas. A plataforma replica automaticamente a configuração entre zonas.

    Se a sua conta de armazenamento anfitrião usar ZRS, o Azure Storage replica sincronizadamente os seus dados em várias zonas de disponibilidade.

    Para Funções Duradouras, reveja o seu fornecedor de armazenamento para perceber como replica dados entre zonas.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um plano tem redundância de zona, a conta de armazenamento do host usa ZRS (Redundância de Zona de Armazenamento) e ocorre uma falha na zona de disponibilidade.

  • Deteção e resposta: A plataforma Azure Functions é responsável por detetar uma falha numa zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.

  • Pedidos ativos: Quando uma zona de disponibilidade não está disponível, quaisquer pedidos em curso que estejam ligados a uma instância na zona de disponibilidade defeituosa são terminados e precisam de ser tentados novamente. Certifique-se de que seus aplicativos estejam preparados seguindo as diretrizes de tratamento de falhas transitórias.

  • Perda de dados esperada: Não se espera que falhas de zona causem perda de dados porque o Azure Functions é um serviço sem estado.

    Se a sua conta de armazenamento anfitrião usar ZRS, o Azure Storage garante que não há perda de dados devido a falhas de zona.

    Para Funções Duradouras, analise o seu fornecedor de armazenamento para compreender se a perda de dados é possível durante uma falha numa zona.

  • Tempo de inatividade previsto: Durante as interrupções de zona, as ligações podem sofrer interrupções breves que normalmente duram alguns segundos enquanto o tráfego é redistribuído. Certifique-se de que seus aplicativos estejam preparados seguindo as diretrizes de tratamento de falhas transitórias.

  • Redirecionamento de tráfego: O Azure Functions deteta as instâncias perdidas dessa zona e tenta encontrar novas instâncias de substituição. Depois de o Azure Functions encontrar substitutos, distribui o tráfego entre as novas instâncias conforme necessário.

    Importante

    O Azure não garante que as solicitações para mais instâncias sejam bem-sucedidas em um cenário de zone-down. A plataforma tenta preencher instâncias perdidas com base no melhor esforço. Se precisar de capacidade garantida durante uma falha de zona de disponibilidade, crie e configure os seus planos para ter em conta a perda de zona, sobre-provisionando a capacidade.

  • Comportamentos fora do tempo de execução: As aplicações num plano de aplicação de função redundante por zona continuam a funcionar e a servir o tráfego mesmo que uma zona de disponibilidade sofra uma falha. No entanto, comportamentos não de execução podem ser afetados durante uma interrupção numa zona de disponibilidade. Estes comportamentos incluem escalabilidade de aplicações funcionais, criação de aplicações, configuração de aplicações e publicação de aplicações.

Recuperação de zona

Quando a zona de disponibilidade recupera, o Azure Functions restaura automaticamente as instâncias na zona de disponibilidade, remove quaisquer instâncias temporárias criadas nas outras zonas de disponibilidade e redireciona o tráfego entre as suas instâncias normalmente.

Teste de falhas de zona

A plataforma Azure Functions gere o encaminhamento de tráfego, failover e recuperação de zonas para recursos redundantes de zona. Você não precisa iniciar nada. Como esse recurso é totalmente gerenciado, não é necessário validar os processos de falha da zona de disponibilidade.

Resiliência a falhas em toda a região

O Azure Functions é um serviço de uma única região. Se a região ficar indisponível, o seu recurso Azure Functions também fica indisponível.

Soluções personalizadas de várias regiões para resiliência

Para evitar a perda de execução durante interrupções, você pode implantar redundantemente as mesmas funções para aplicativos funcionais em várias regiões.

És responsável por:

  • Implementação de aplicações funcionais para múltiplas regiões
  • Gerir a distribuição do tráfego entre regiões
  • Implementação de mecanismos de recuperação automática
  • Garantir a consistência dos dados entre regiões (se aplicável)
  • Monitorização e gestão de implementações interregionais

Quando executa o mesmo código de função em várias regiões, existem dois padrões comuns a considerar: ativo-ativo e ativo-passivo. As secções seguintes fornecem uma breve introdução a estes padrões, mas não fornecem orientações detalhadas ou passos de configuração.

Padrão ativo-ativo para funções de gatilho HTTP

Com um padrão ativo-ativo, as funções em ambas as regiões estão ativamente executando e processando eventos, seja de forma duplicada ou em rotação. Deve usar um padrão ativo-ativo em combinação com o Azure Front Door para as suas funções críticas ativadas por HTTP, que podem encaminhar e repartir de forma circular pedidos HTTP entre funções em execução em múltiplas regiões. O Azure Front Door também pode verificar periodicamente a saúde de cada endpoint. Se uma função numa região deixar de responder a verificações de saúde, o Azure Front Door retira-a da rotação e apenas encaminha o tráfego para as funções saudáveis restantes.

Diagrama mostrando um exemplo de arquitetura ativo-ativo, com o encaminhamento do Azure Front Door entre aplicações do Azure Functions em diferentes regiões, cada uma com a sua própria base de dados.

Padrão ativo-passivo para funções de disparo não HTTP

Para funções orientadas por eventos, não ativadas por HTTP (como funções desencadeadas por Service Bus e Event Hubs), utilize um padrão ativo-passivo. Com um padrão ativo-passivo, as funções executam-se ativamente na região que está a receber eventos, enquanto as mesmas funções numa segunda região permanecem inativas. O padrão ativo-passivo fornece uma forma de apenas uma única função processar cada mensagem, o que é importante para manter a consistência dos dados, ao mesmo tempo que fornece um mecanismo para fazer failover para a região secundária em caso de desastre, como uma interrupção regional.

O failover de aplicações funcionais deve ser considerado juntamente com os comportamentos de failover de outros serviços, tais como:

Considere uma topologia de exemplo usando um trigger do Azure Event Hubs, onde o seu namespace Event Hubs está configurado para recuperação de desastres geográficos. Neste caso, o padrão ativo-passivo requer os seguintes componentes:

  • Hubs de Eventos do Azure implantados em uma região primária e secundária.
  • Recuperação de Geo-desastres ativada para emparelhar os hubs primários e secundários de eventos. Isto também cria um alias que podes usar para te ligares ao namespace do Event Hubs e mudar de primário para secundário sem alterar a informação da ligação.
  • As aplicações de funções são implementadas tanto na região primária como na secundária (failover), com a aplicação na região secundária essencialmente inativa porque as mensagens não são enviadas para lá.
  • A aplicação de funções é ativada na cadeia de ligação direta (não alias) para o respetivo espaço de nomes Event Hubs.
  • Os editores no namespace Event Hubs devem publicar na cadeia de ligação alias.

Diagrama mostrando um exemplo de arquitetura ativo-passiva, com Event Hubs geo-recuperação de desastres a abranger várias regiões e aplicações de função e bases de dados separadas em cada região.

Antes do failover, os editores enviam para a rota de alias compartilhada para o hub de eventos principal. O aplicativo de função principal está ouvindo exclusivamente o hub de eventos principal. O aplicativo de função secundária é passivo e ocioso.

Assim que o failover é iniciado, os editores que enviam para o alias compartilhado são roteados para o hub de eventos secundário. O aplicativo de função secundária agora fica ativo e começa a ser acionado automaticamente. O failover eficaz para uma região secundária pode ser gerido completamente a partir do hub de eventos, com as funções tornando-se ativas somente quando o respetivo hub de eventos estiver ativo.

Funções duráveis

Para recuperação de desastres multirregional para Azure Durable Functions, consulte Recuperação de desastres e geo-distribuição em Azure Durable Functions.

Resiliência à manutenção de serviços

O Azure Functions realiza atualizações regulares de serviços e outras tarefas de manutenção.

  • Resiliência a falhas transitórias: Durante a manutenção do serviço, as instâncias que executam a sua aplicação de funções podem ser reiniciadas ou sofrer interrupções temporárias. Assegure que quaisquer aplicações cliente que interajam com a sua aplicação de funções sejam resilientes a falhas transitórias.
  • Ativar redundância de zona: Ao ativar a redundância de zonas no seu plano, também melhora a resiliência durante as atualizações da plataforma. Implementar múltiplas instâncias no seu plano e ativar a redundância de zonas adiciona uma camada extra de resiliência se uma instância ou zona se tornar insalubre durante uma atualização.

Para manter a sua capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extra do plano durante o processo de atualização.

  • Ativar redundância de zona: Ao ativar a redundância de zonas no seu plano, também melhora a resiliência durante as atualizações da plataforma. Os domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e são mapeadas para zonas de disponibilidade. Implementar múltiplas instâncias no seu plano e ativar a redundância de zonas adiciona uma camada extra de resiliência se uma instância ou zona se tornar insalubre durante uma atualização.

  • Ambiente de Serviços de Aplicação: Se hospedar a sua aplicação de funções num Ambiente de Serviços de Aplicações, pode personalizar o ciclo de atualização. Se você precisar validar o efeito das atualizações em sua carga de trabalho, habilite as atualizações manuais. Essa abordagem permite que você execute validação e teste em uma instância que não seja de produção antes de aplicá-los à sua instância de produção.

    Para obter mais informações sobre preferências de manutenção, consulte Preferências de atualização para manutenção planejada do Ambiente do Serviço de Aplicativo.

Resiliência às implementações de aplicações

As implementações de aplicações introduzem o risco de problemas num ambiente de produção. Deves estar preparado para reverter uma atualização se causar problemas. Deves também controlar como as atualizações são implementadas para minimizar as perturbações causadas pelos reinícios das aplicações.

Os planos Flex Consumption suportam estratégias de atualização do site, que oferecem múltiplas formas de implementar as atualizações da sua aplicação, incluindo atualizações contínuas para implementações sem tempo de inatividade.

Os deployment slots do Azure Functions permitem implementações sem tempo de inatividade das suas apps de funções. Use slots de implantação para minimizar o efeito de implantações e alterações de configuração para seus usuários. Os slots de implantação também reduzem a probabilidade de reinicialização do aplicativo. Reiniciar o aplicativo causa uma falha transitória.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (SLAs) para serviços online.

O Azure Functions fornece SLAs de disponibilidade distintas para o plano de Consumo e para outros tipos de plano.

Conteúdo relacionado

  • Last updated on