Confiabilidade no Azure Functions
Este artigo descreve o suporte à confiabilidade no Azure Functions e aborda a resiliência intra-regional com zonas de disponibilidade e recuperação entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.
O suporte à zona de disponibilidade para o Azure Functions está disponível nos planos Premium (Elástico Premium) e Dedicado (Serviço de Aplicativo). Este artigo enfatiza o suporte à redundância de zona para planos Premium. Para redundância de zona em Planos dedicados, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.
As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
O Azure Functions dá suporte a uma implantação com redundância de zona.
Quando você configura o Functions para ter redundância de zona, a plataforma espalha automaticamente as instâncias de aplicativo de funções em três zonas na região selecionada.
A distribuição de instâncias com uma implantação com redundância de zona é determinada com base nas seguintes regras, mesmo quando o aplicativo é reduzido ou escalado horizontalmente:
- A contagem mínima de instâncias do aplicativo de funções é três.
- Quando você especifica uma capacidade maior que três, as instâncias são distribuídas uniformemente somente quando a capacidade é um múltiplo de 3.
- Para um valor de capacidade superior a 3*N, instâncias extras são distribuídas por uma ou duas zonas restantes.
Importante
O Azure Functions pode ser executado na plataforma de Serviço de Aplicativo do Azure. Na plataforma do Serviço de Aplicativo, os planos que hospedam Premium aplicativos de função de plano são chamados de planos Premium Elásticos, com nomes de SKU como EP1. Se optar por executar seu aplicativo de funções em um plano Premium, crie um plano com um nome de SKU que comece com "E", como EP1. Os nomes de SKU do plano do Serviço de Aplicativo que começam com "P", como o P1V2 (Plano pequeno Premium V2), são, na verdade, Planos de hospedagem dedicados. Como eles são Dedicados e não Elásticos Premium, os planos com nomes de SKU começando com "P" não serão dimensionados dinamicamente e poderão aumentar os custos.
Disponibilidade regional
Os planos Premium com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Oriente Médio | África | Pacífico Asiático |
|---|---|---|---|---|
| Brazil South | França Central | Israel Central | Norte da África do Sul | Leste da Austrália |
| Canadá Central | Centro-Oeste da Alemanha | Catar Central | Índia Central | |
| Centro dos EUA | Norte da Itália | Norte dos EAU | Norte da China 3 | |
| Leste dos EUA | Norte da Europa | Leste da Ásia | ||
| Leste dos EUA 2 | Leste da Noruega | Leste do Japão | ||
| Centro-Sul dos Estados Unidos | Suécia Central | Sudeste Asiático | ||
| Oeste dos EUA 2 | Norte da Suíça | |||
| Oeste dos EUA 3 | Sul do Reino Unido | |||
| Europa Ocidental |
Pré-requisitos
O suporte a zonas de disponibilidade é uma propriedade do plano Premium. Estes são os requisitos e as limitações atuais para a habilitação das zonas de disponibilidade:
- Você só pode habilitar zonas de disponibilidade ao criar um plano Premium para o aplicativo de funções. Você não pode converter um plano Premium existente para usar zonas de disponibilidade.
- Você deve usar uma conta de armazenamento com redundância de zona para a conta de armazenamento do aplicativo de funções. Se você usar um tipo diferente de conta de armazenamento, o Functions poderá apresentar um comportamento inesperado durante uma interrupção de zona.
- Há suporte para os aplicativos Windows e Linux.
- Deve ser hospedado em um plano de hospedagem Elástico Premium ou Dedicado. Para saber como usar a redundância de zona com um plano Dedicado, confira Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
- No momento, o suporte à zona de disponibilidade não está disponível para aplicativos de funções em planos de Consumo.
- Os aplicativos de funções hospedados em um plano Premium precisam ter uma contagem mínima de três instâncias sempre prontas.
- A plataforma vai impor essa contagem mínima em segundo plano se você especificar uma contagem de instâncias menor que três.
- Se você não estiver usando o plano Premium ou uma unidade de escala que dê suporte a zonas de disponibilidade, se estiver em uma região sem suporte ou se estiver em dúvida, confira as diretrizes sobre migração.
Preços
Não há nenhum custo extra associado à habilitação de zonas de disponibilidade. O preço de um plano do Serviço de Aplicativo Premium com redundância de zona é igual ao preço de um plano Premium de zona única. Para cada plano do Serviço de Aplicativo usado, você será cobrado com base no SKU escolhido, na capacidade especificada e em quaisquer instâncias dimensionadas de acordo com seus critérios de dimensionamento automático. Se você habilitar zonas de disponibilidade, mas especificar uma capacidade inferior a três para um plano do Serviço de Aplicativo, a plataforma vai impor uma contagem mínima de três instâncias para esse plano do Serviço de Aplicativo e vai cobrar você por essas três instâncias.
Criar um plano Premium com redundância de zona e um aplicativo de funções
No momento, há duas maneiras de implantar um plano Premium com redundância de zona e um aplicativo de funções. Você pode usar o portal do Azure ou um modelo do ARM.
Abra o portal do Azure e navegue até a página Criar aplicativo de funções. Informações sobre a criação de um aplicativo de funções no portal podem ser encontradas aqui.
Na página Noções básicas, preencha os campos do aplicativo de funções. Preste atenção aos campos na tabela abaixo (também realçados na captura de tela abaixo), que têm requisitos específicos para redundância de zona.
Configuração Valor sugerido Observações sobre redundância de zona Região Região preferencial A assinatura na qual este novo aplicativo de funções será criado. Você precisa escolher uma região habilitada para zona de disponibilidade na lista acima. 
Na página Hosting, preencha os campos do plano de hospedagem do aplicativo de funções. Preste atenção aos campos na tabela abaixo (também realçados na captura de tela abaixo), que têm requisitos específicos para redundância de zona.
Configuração Valor sugerido Observações sobre redundância de zona Conta de armazenamento Uma conta de armazenamento com redundância de zona Conforme mencionado acima na seção de pré-requisitos, é altamente recomendável usar uma conta de armazenamento com redundância de zona para seu aplicativo de funções com redundância de zona. Tipo de Plano Functions Premium Este artigo detalha como criar um aplicativo com redundância de zona em um plano Premium. No momento, a redundância de zona não está disponível nos planos de Consumo. Informações sobre redundância de zona nos planos do serviço de aplicativo podem ser encontradas neste artigo. Redundância de Zona habilitado Esse campo preenche o sinalizador que determina se o aplicativo possui redundância de zona. Não será possível selecionar Enabled, a menos que você tenha escolhido uma região que dê suporte à redundância de zona, conforme mencionado na etapa 2.
Para o restante do processo de criação do aplicativo de funções, crie seu aplicativo de funções normalmente. Não há campos no restante do processo de criação que afetem a redundância de zona.
Depois que o plano com redundância de zona for criado e implantado, qualquer aplicativo de funções hospedado em seu novo plano será considerado com redundância de zona.
Migração da zona de disponibilidade
Atualmente, os aplicativos de funções do Azure não dão suporte à migração no local de instâncias de aplicativos de funções existentes. Para obter informações de como migrar o plano Premium multilocatário público do suporte sem zona de disponibilidade para suporte com zona de disponibilidade, confira Migrar o Serviço de Aplicativo para o suporte com zona de disponibilidade.
Experiência de zona inoperante
Todas as instâncias de aplicativos de funções disponíveis de aplicativos de funções com redundância de zona estão habilitadas e processando eventos. Quando uma zona falha, o Functions detecta as instâncias perdidas e tenta localizar automaticamente as novas instâncias de substituição, se necessário. O comportamento de escala elástica ainda se aplica. No entanto, em um cenário de zona inoperante, não há garantia de que as solicitações para instâncias adicionais terão sucesso, pois há um esforço de retornar às instâncias perdidas. Os aplicativos implantados em um plano Premium habilitado para uma zona de disponibilidade continuarão sendo executados mesmo que outras zonas na mesma região sofram interrupção. No entanto, é possível que comportamentos que não sejam de tempo de execução ainda sejam afetados por uma interrupção em outras zonas de disponibilidade. Esses comportamentos podem incluir dimensionamento do plano Premium, criação de aplicativos, configuração de aplicativos e publicação de aplicativos. A redundância de zona para os planos Premium garante apenas o tempo de atividade contínuo para aplicativos implantados.
Quando o Functions aloca instâncias para um plano Premium com redundância de zona, ele usa o melhor balanceamento de zona possível oferecido pelos conjuntos de dimensionamento de máquinas virtuais do Azure subjacentes. Um plano Premium é considerado balanceado quando cada zona tem o mesmo número de VMs (± 1 VM) em todas as outras zonas usadas pelo plano Premium.
Recuperação de desastre entre regiões e continuidade dos negócios
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
Esta seção explica algumas das estratégias que você pode usar para implantar o Functions para permitir a recuperação de desastre.
Recuperação de desastre de várias regiões
Como não há nenhuma redundância interna disponível, as funções são executadas em um aplicativo de funções em uma região específica do Azure. Para evitar a perda de execução durante interrupções, você pode implantar de forma redundante as mesmas funções para aplicativos de funções em várias regiões. Para saber mais sobre implantações em várias regiões, confira as diretrizes em Aplicativo Web de várias regiões altamente disponível.
Quando você executa o mesmo código de função em várias regiões, há dois padrões a serem considerados, ativo-ativo e ativo-passivo.
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 em execução ativa e processando eventos, seja de maneira duplicada ou em rotação. É recomendável que você use um padrão ativo-ativo em combinação com Azure Front Door para suas funções críticas disparadas por HTTP, que podem rotear e fazer uma distribuição equilibrada de solicitações HTTP entre funções em execução em várias regiões. O front door também pode verificar periodicamente a integridade de cada ponto de extremidade. Quando uma função em uma região para de responder às verificações de integridade, a Azure Front Door a retira da rotação e só encaminha o tráfego para as funções íntegras restantes.
Importante
Contudo, é altamente recomendável que você use o padrão ativo-passivo para funções de gatilho não HTTPS. Você pode criar implantações ativo-ativo para funções de gatilho não HTTPS. No entanto, você precisa considerar como as duas regiões ativas interagem ou coordenam uma com a outra. Quando você implanta o mesmo aplicativo de funções em duas regiões com cada um disparando na mesma fila do Barramento de Serviço, eles atuariam como consumidores concorrentes na remoção da fila. Cada mensagem seria processada por apenas uma das instâncias, mas também haveria um ponto único de falha no Barramento de Serviço de instância única.
Em vez disso, você poderia implantar duas filas de Barramento de Serviço, com uma em uma região primária, uma em uma região secundária. Nesse caso, você poderia ter dois aplicativos de função, cada um sendo apontado para a fila de Barramento de Serviço ativa em sua região. O desafio com essa topologia é como as mensagens de fila são distribuídas entre as duas regiões. Geralmente, isso significa que cada publicador tenta publicar uma mensagem em ambas as regiões, e cada mensagem é processada por ambos os aplicativos de funções ativos. O resultado é o padrão ativo/ativo desejado, mas também surgem outros desafios quanto à duplicação da computação e quando ou como os dados são consolidados.
Padrão ativo-passivo para funções de gatilho não HTTPS
É recomendável que você use o padrão ativo-passivo para suas funções de gatilho não HTTP acionadas por eventos, como Barramento de Serviço e funções de gatilho dos Hubs de Eventos.
Para criar redundância em funções de gatilho não HTTP, use o padrão ativo-passivo. Com um padrão ativo-passivo, as funções são executadas ativamente na região que está recebendo eventos, enquanto as mesmas funções em uma segunda região permanecem ociosas. O padrão ativo-passivo oferece apenas uma função para processar cada mensagem enquanto fornece um mecanismo de failover para a região secundária em um desastre. Os aplicativos de funções funcionam com os comportamentos de failover dos serviços de parceiros, como o recuperação geográfica do Barramento de Serviço e a recuperação geográfica dos Hubs de Eventos do Azure.
Considere uma topologia de exemplo usando um gatilho de Hubs de Eventos do Azure. Nesse caso, o padrão ativo/passivo requer o envolvimento dos seguintes componentes:
- Hubs de Eventos do Azure implantados nas regiões primária e secundária.
- Desastre geográfico habilitado para emparelhar os hubs de eventos primário e secundário. Isso também cria um alias que você pode usar para se conectar aos Hubs de Eventos e trocar do primário para o secundário sem alterar as informações de conexão.
- Os aplicativos de funções são implantados na região primária e secundária (failover), com o aplicativo na região secundária, essencialmente ocioso, porque as mensagens não estão sendo enviadas lá.
- O aplicativo de funções dispara na cadeia de conexão direta (sem alias) do respectivo Hub de Eventos.
- Os editores do Hub de Eventos devem publicar na cadeia de conexão do alias.
Antes do failover, os publicadores que enviarem ao alias compartilhado encaminham para o Hub de Eventos primário. O aplicativo de funções primário está ouvindo exclusivamente o Hub de Eventos primário. O aplicativo de funções secundário é passivo e ocioso. Assim que o failover for iniciado, os publicadores que enviarem ao alias compartilhado são encaminhados para o Hub de Eventos secundário. O aplicativo de funções secundário agora fica ativo e começa a disparar automaticamente. O failover efetivo para a região secundária pode ser totalmente controlado pelo hub de eventos. As funções são ativadas apenas quando o respectivo hub de eventos é ativado.
Leia mais sobre informações e considerações sobre failover com o Barramento de Serviço e os Hubs de Eventos.