Fiabilidade no Azure Functions
Este artigo descreve o suporte à confiabilidade no Azure Functions e aborda a resiliência intrarregional com zonas de disponibilidade e a recuperação entre regiões e a continuidade de negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, consulte Confiabilidade do Azure.
O suporte à zona de disponibilidade para o Azure Functions está disponível nos planos Premium (Elastic Premium) e Dedicado (Serviço de Aplicativo). Este artigo se concentra no suporte de 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 fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas 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 é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte 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 como zona redundante, a plataforma distribui automaticamente as instâncias do aplicativo de função por três zonas na região selecionada.
A distribuição de instâncias com uma implantação redundante de zona é determinada dentro das seguintes regras, mesmo quando o aplicativo é dimensionado para dentro e para fora:
- A contagem mínima de instâncias do aplicativo de função é 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, as instâncias extras são distribuídas pelas zonas restantes.
Importante
O Azure Functions pode ser executado na plataforma do Serviço de Aplicativo do Azure. Na plataforma do Serviço de Aplicativo, os planos que hospedam aplicativos de função de plano Premium são chamados de planos Elastic Premium, com nomes de SKU como EP1. Se você optar por executar seu aplicativo de função em um plano Premium, certifique-se de criar 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 P1V2 (plano Premium V2 Pequeno), são, na verdade , planos de hospedagem dedicados. Por serem Dedicados e não Elastic Premium, os planos com nomes de SKU começando com "P" não serão dimensionados dinamicamente e poderão aumentar seus custos.
Disponibilidade regional
Os planos Premium com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Médio Oriente | África | Ásia-Pacífico |
|---|---|---|---|---|
| Sul do Brasil | França Central | 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 da 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 | |||
| EUA Oeste 3 | Sul do Reino Unido | |||
| Europa Ocidental |
Pré-requisitos
O suporte da zona de disponibilidade é uma propriedade do plano Premium. A seguir estão os requisitos/limitações atuais para habilitar zonas de disponibilidade:
- Você só pode habilitar zonas de disponibilidade ao criar um plano Premium para seu aplicativo funcional. Não é possível converter um plano Premium existente para usar zonas de disponibilidade.
- Você deve usar uma conta de armazenamento redundante de zona (ZRS) para a conta de armazenamento do seu aplicativo de função. Se você usar um tipo diferente de conta de armazenamento, o Functions poderá mostrar um comportamento inesperado durante uma interrupção zonal.
- Tanto o Windows como o Linux são suportados.
- Deve ser hospedado em um plano de hospedagem Elastic Premium ou dedicado. Para saber como usar a redundância de zona com um plano Dedicado, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
- O suporte à zona de disponibilidade não está atualmente disponível para aplicações funcionais nos planos de consumo .
- Os aplicativos de função hospedados em um plano Premium devem ter uma contagem mínima de instâncias sempre prontas de três.
- A plataforma impõe essa contagem mínima nos bastidores se você especificar uma contagem de instâncias inferior a três.
- Se você não estiver usando o plano Premium ou uma unidade de escala que ofereça suporte a zonas de disponibilidade, estiver em uma região sem suporte ou não tiver certeza, consulte as diretrizes de migração.
Preços
Não há nenhum custo extra associado à ativação de zonas de disponibilidade. O preço de um plano Premium do Serviço de Aplicativo Premium redundante de zona é o mesmo de um plano Premium de zona única. Para cada plano do Serviço de Aplicativo que você usa, você é cobrado com base na SKU escolhida, na capacidade especificada e em todas as instâncias para as quais você dimensiona com base em 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 imporá uma contagem mínima de instâncias de três para esse plano do Serviço de Aplicativo e cobrará por essas três instâncias.
Criar um plano Premium com redundância de zona e uma aplicação funcional
Atualmente, há duas maneiras de implantar um plano Premium com redundância de zona e um aplicativo funcional. Você pode usar o portal do Azure ou um modelo ARM.
Abra o portal do Azure e navegue até a página Criar Aplicativo de Função. Informações sobre como criar um aplicativo de função no portal podem ser encontradas aqui.
Na página Noções básicas, preencha os campos do seu aplicativo de função. Preste especial atenção aos campos na tabela abaixo (também destacados na imagem abaixo), que têm requisitos específicos para redundância de zona.
Definição Valor sugerido Notas para redundância de zona Região Região preferida A subscrição no âmbito da qual esta nova aplicação de funções é criada. Você deve escolher uma região que esteja na zona de disponibilidade habilitada na lista acima. 
Na página Hospedagem, preencha os campos do seu plano de hospedagem de aplicativo funcional. Preste especial atenção aos campos na tabela abaixo (também destacados na imagem abaixo), que têm requisitos específicos para redundância de zona.
Definição Valor sugerido Notas para redundância de zona Conta de Armazenamento Uma conta de armazenamento com redundância de zona Como 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ção redundante de zona. Tipo de Plano Funções Premium Este artigo detalha como criar um aplicativo redundante de zona em um plano Premium. A redundância de zona não está atualmente disponível nos planos de consumo. Informações sobre redundância de zona em planos de serviço de aplicativo podem ser encontradas neste artigo. Redundância de zona Ativado(a) Este campo preenche o sinalizador que determina se seu aplicativo é redundante de zona ou não. Você não poderá selecionar Enableda menos que tenha escolhido uma região que ofereça suporte à redundância de zona, conforme mencionado na etapa 2.
Para o resto do processo de criação do aplicativo de função, crie seu aplicativo de função 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 é criado e implantado, qualquer aplicativo de função hospedado em seu novo plano é considerado redundante de zona.
Migração da zona de disponibilidade
Atualmente, os Aplicativos de Função do Azure não oferecem suporte à migração in-loco de instâncias de aplicativos de função existentes. Para obter informações sobre como migrar o plano Premium multilocatário público da zona de indisponibilidade para o suporte à zona de disponibilidade, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
Experiência de zoneamento
Todas as instâncias de aplicativos de função disponíveis de aplicativos de função com redundância de zona são habilitadas e processam eventos. Quando uma zona fica inativa, o Functions deteta instâncias perdidas e tenta encontrar automaticamente novas instâncias de substituição, se necessário. O comportamento da escala elástica ainda se aplica. No entanto, em um cenário de zone-down, não há garantia de que as solicitações de instâncias adicionais possam ser bem-sucedidas, uma vez que o preenchimento de instâncias perdidas ocorre com base no melhor esforço. Os aplicativos implantados em uma zona de disponibilidade habilitada para o plano Premium continuam a ser executados mesmo quando outras zonas na mesma região sofrem uma interrupção. No entanto, é possível que comportamentos sem tempo de execução ainda possam ser afetados por uma interrupção em outras zonas de disponibilidade. Esses comportamentos afetados podem incluir o dimensionamento do plano Premium, a criação de aplicativos, a configuração de aplicativos e a publicação de aplicativos. A redundância de zona para planos Premium garante apenas um tempo de atividade contínuo para aplicativos implantados.
Quando o Functions aloca instâncias a um plano Premium redundante de zona, ele usa o melhor balanceamento de zona de esforço oferecido pelos Conjuntos de Escala de Máquina Virtual do Azure subjacentes. Um plano Premium é considerado equilibrado quando cada zona tem o mesmo número de VMs (± 1 VM) em todas as outras zonas usadas pelo plano Premium.
Recuperação de desastres entre regiões e continuidade de negócios
A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para 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 desastres.
Recuperação de desastres em várias regiões
Como não há redundância interna disponível, as funções são executadas em um aplicativo de função em uma região específica do Azure. 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. Para saber mais sobre implantações de várias regiões, consulte as orientações em Aplicativo Web multirregião 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 ativamente executando e processando eventos, seja de forma duplicada ou em rotação. É recomendável que você use um padrão ativo-ativo em combinação com o Azure Front Door para suas funções críticas acionadas por HTTP, que podem rotear e round-robin solicitações HTTP entre funções em execução em várias regiões. A porta da frente também pode verificar periodicamente a integridade de cada ponto final. Quando uma função em uma região para de responder a verificações de integridade, o Azure Front Door a tira da rotação e só encaminha o tráfego para as funções saudáveis restantes.
Importante
No entanto, é altamente recomendável que você use o padrão ativo-passivo para funções de gatilho não-HTTPS. Você pode criar implantações ativas-ativas para funções acionadas não HTTP. No entanto, você precisa considerar como as duas regiões ativas interagem ou se coordenam uma com a outra. Quando você implanta o mesmo aplicativo de função em duas regiões com cada um acionando na mesma fila do Service Bus, eles agem como consumidores concorrentes na eliminação da fila dessa fila. Embora isso signifique que cada mensagem está sendo processada apenas por uma das instâncias, também significa que ainda há um único ponto de falha na única instância do Service Bus.
Em vez disso, você pode implantar duas filas do Service Bus, com uma em uma região primária e outra em uma região secundária. Nesse caso, você pode ter dois aplicativos de função, com cada um apontado para a fila do Service Bus ativa em sua região. O desafio com essa topologia é como as mensagens de fila são distribuídas entre as duas regiões. Muitas vezes, isso significa que cada editor tenta publicar uma mensagem em ambas as regiões, e cada mensagem é processada por ambos os aplicativos de função ativa. Embora isso crie o padrão ativo/ativo desejado, também cria outros desafios em torno da duplicação de 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 usar o padrão ativo-passivo para suas funções acionadas não HTTP orientadas a eventos, como funções acionadas pelo Service Bus e Hubs de Eventos.
Para criar redundância para funções de gatilho não-HTTP, use um 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 fornece uma maneira para apenas uma única função processar cada mensagem, enquanto fornece um mecanismo para failover para a região secundária em um desastre. Os aplicativos de função funcionam com os comportamentos de failover dos serviços de parceiros, como a recuperação geográfica do Barramento de Serviço do Azure e a recuperação geográfica dos Hubs de Eventos do Azure.
Considere um exemplo de topologia usando um gatilho de Hubs de Eventos do Azure. Neste caso, o padrão ativo/passivo requer envolver os seguintes componentes:
- Hubs de Eventos do Azure implantados em uma região primária e secundária.
- Desastre geográfico habilitado para emparelhar os hubs de eventos primários e secundários. Isso também cria um alias que você pode usar para se conectar a hubs de eventos e alternar de primário para secundário sem alterar as informações de conexão.
- Os aplicativos de função 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 para lá.
- O aplicativo de função é acionado na cadeia de conexão direta (sem alias) para seu respetivo hub de eventos.
- Os editores do hub de eventos devem publicar na cadeia de conexão de alias.
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 efetivo para uma região secundária pode ser conduzido inteiramente a partir do hub de eventos, com as funções ficando ativas somente quando o respetivo hub de eventos estiver ativo.
Leia mais sobre informações e considerações para failover com Service Bus e Hubs de Eventos.