Compartilhar via

Confiabilidade no Azure Functions

O Azure Functions é um serviço de computação controlado por eventos que permite executar pequenos blocos de código (funções) sem precisar provisionar ou gerenciar explicitamente a infraestrutura. As funções podem responder a eventos como solicitações HTTP, temporizadores, mensagens de fila e alterações em outros serviços do Azure, tornando-o adequado 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 dar 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 possíveis interrupções e problemas, incluindo falhas transitórias, falhas na zona de disponibilidade e falhas em toda a região. Ele também destaca as principais informações sobre o SLA (contrato de nível de serviço) do 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 entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável do Azure Functions, consulte as práticas recomendadas de arquitetura para o Azure Functions.

Visão geral da arquitetura de confiabilidade

Ao implantar o Azure Functions, é importante estar familiarizado com vários conceitos:

  • Planos de hospedagem: Os planos representam o ambiente de hospedagem para seus aplicativos de funções. O plano determina os recursos de computação disponíveis, o modelo de preços e o comportamento de dimensionamento.

  • Contas de armazenamento: Ao criar um aplicativo de funções, você deve especificar uma conta de armazenamento de host. A conta de armazenamento é usada para gerenciar aspectos das operações internas do aplicativo de funções, incluindo armazenamento de código de função, registro em log e gerenciamento de simultaneidade (como concessões de blob para determinados tipos de gatilho).

    Você também pode usar uma conta de armazenamento para implantação. Essa conta de armazenamento pode ser a mesma que sua conta de armazenamento de host ou uma conta de armazenamento diferente.

    Importante

    As contas de armazenamento são partes críticas da arquitetura de confiabilidade do Azure Functions e você deve configurá-las para atender aos requisitos de resiliência do aplicativo de funções.

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

  • Funções duráveis: Funções duráveis são funções com estado, incluindo orquestrações de longa execução e entidades com estado.

    Ao usar o Durable Functions, você configura um provedor de armazenamento, que armazena o estado. Você precisa avaliar as características de confiabilidade do repositório de estado escolhido e configurá-lo para atender aos seus requisitos de resiliência.

Resiliência a falhas transitórias

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

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

Considere as seguintes recomendações para lidar com falhas transitórias em seus aplicativos de funções:

  • Gatilhos e associações: A plataforma do Azure Functions inclui tratamento de falhas transitórias internas para muitos gatilhos e associações. Quando ocorre uma falha transitória enquanto um gatilho com suporte é disparado ou uma associação com suporte está lendo ou gravando dados, a plataforma pode repetir automaticamente a operação. Esse recurso de repetição interno ajuda a garantir que problemas temporários de conectividade ou instabilidades de serviço não impeçam a execução da função. Para obter mais informações, consulte tratamento de erros e novas tentativas no Azure Functions.

    No entanto, essa proteção abrange apenas falhas transitórias. Falhas persistentes, como uma cadeia de conexão configurada incorretamente ou um recurso excluído, não são repetidas.

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

  • Seu código de função: Dentro do corpo da função, você é responsável por lidar com falhas transitórias ao fazer chamadas para serviços externos. Você deve implementar lógica de repetição, tempos limite e padrões de disjuntor, conforme apropriado para todas as chamadas de serviço externas feitas em seu código de função. Projete suas funções para serem idempotentes sempre que possível, para que tentativas adicionais não causem efeitos colaterais duplicados.

  • Clientes: Todos os aplicativos cliente que se conectam a funções de forma síncrona, como usando uma conexão HTTP, devem ser resilientes a falhas transitórias.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Os planos de consumo não dão suporte a zonas de disponibilidade. Se a redundância de zona for um requisito para sua carga de trabalho, considere usar os tipos de Plano de Consumo Flexível, Plano Premium ou Plano Dedicado (Serviço de Aplicativo).

Os Flex Consumption plans dão suporte a implantações com redundância de zona.

Os planos Premium suportam implantações com redundância de zona.

Quando a redundância de zona está habilitada, a plataforma espalha automaticamente suas instâncias de plano em todas as zonas de disponibilidade na região selecionada. Se qualquer zona de disponibilidade na região tiver um problema, suas funções continuarão a ser executadas usando instâncias em zonas saudáveis.

Você também deve habilitar o ZRS (armazenamento com redundância de zona) na conta de armazenamento do host, o que garante que ele também seja resiliente a interrupções de zona.

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

O plano Dedicado (Serviço de Aplicativo) dá suporte a implantações com redundância zonal. Quando a redundância de zona está habilitada, a plataforma espalha automaticamente suas instâncias em todas as zonas de disponibilidade na região selecionada. Você configura a redundância de zona no plano. Para obter detalhes completos sobre como o Serviço de Aplicativo lida com a redundância de zona, consulte Confiabilidade no Serviço de Aplicativo do Azure.

Se você não habilitar a redundância de zona, seu plano será nonzonal ou regional, o que significa que as instâncias de 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 zona de disponibilidade. Seu plano pode enfrentar tempo de inatividade durante uma interrupção em qualquer zona da região.

Requisitos

  • Suporte à região: Planos de Consumo Flex com redundância de zona podem ser implantados em um conjunto específico de regiões. Você pode recuperar a lista atual de regiões com suporte usando a CLI do Azure. Para obter mais informações, consulte Exibir regiões que dão suporte a zonas de disponibilidade.

  • Suporte à região: Planos Premium com redundância de zona podem ser implantados nas seguintes regiões:

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

  • Sistemas operacionais: Há suporte para planos do Windows e do Linux.

  • Contagem mínima de instâncias: Um mínimo de duas instâncias sempre prontas é necessária quando a redundância de zona é habilitada para planos Premium.

  • Conta de armazenamento do host: Você deve configurar a conta de armazenamento de host padrão do aplicativo de funções para usar o ZRS (armazenamento com redundância de zona). Se você usar uma conta de armazenamento de host que não esteja configurada para ZRS, seu aplicativo poderá se comportar inesperadamente durante uma interrupção de zona.
  • Conta de armazenamento de contêiner de implantação: Se você usar uma conta de armazenamento separada para o contêiner de implantação do aplicativo, atualize-a para ser redundante de zona também.

Considerações

A redundância de zona só garante a disponibilidade contínua para aplicativos já implantados. Uma interrupção da zona de disponibilidade pode afetar alguns aspectos do Azure Functions, embora o aplicativo continue a atender ao tráfego. Esses comportamentos incluem dimensionamento de plano, criação de aplicativo, configuração de aplicativo e publicação de aplicativos.

Distribuição de instâncias entre zonas

Quando você configura aplicativos do Plano Flex de Consumo como redundantes entre zonas, a plataforma espalha automaticamente as instâncias do plano entre várias zonas na região selecionada, aplicando regras diferentes para as instâncias sempre prontas em comparação às sob demanda.

  • Instâncias sempre prontas são distribuídas entre pelo menos duas zonas de forma alternada.

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

  • As instâncias sob demanda são criadas como resultado de volumes de eventos à medida que o aplicativo é dimensionado além da contagem de instâncias sempre prontas. Instâncias sob demanda são distribuídas entre zonas de disponibilidade conforme o melhor esforço possível. A expansão de escala mais rápida é priorizada sobre a distribuição mais uniforme entre as zonas. A plataforma tenta equilibrar a distribuição ao longo do tempo.

Quando você configura os planos de aplicativos de funções do Elastic Premium como redundantes de zona, a plataforma automaticamente distribui as instâncias do plano entre várias zonas na região selecionada. A propagação de instância segue estas regras, mesmo quando o aplicativo é escalonado para cima e para baixo:

  • A contagem mínima de instâncias do aplicativo de funções é duas.
  • Quando você especifica uma capacidade maior 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 maior que Número de Zonas * Número de instâncias, instâncias extras são distribuídas entre as zonas restantes.

Quando o Functions aloca instâncias para um plano Premium com redundância de zona, ele usa o balanceamento de zona de melhor esforço, que os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure subjacentes oferecem. 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 à habilitação da redundância de zona. O preço de um plano com redundância de zona é o mesmo que um plano de zona única.

No entanto, quando você habilita zonas de disponibilidade em um aplicativo com uma configuração de instância sempre pronta de menos de duas instâncias para cada função ou grupo de dimensionamento por função, a plataforma cria automaticamente duas instâncias do tipo sempre pronto para cada função ou grupo de dimensionamento por função. Essas novas instâncias também são cobradas como instâncias sempre prontas.

No entanto, se você habilitar zonas de disponibilidade em um plano com menos de duas instâncias, a plataforma imporá uma contagem mínima de duas instâncias para esse plano e você será cobrado por ambas as instâncias.

Para obter detalhes de preços completos, consulte os preços do Azure Functions.

Configurar o suporte à zona de disponibilidade

  • Crie um novo plano de Azure Functions com redundância por zona. Você pode habilitar a redundância de zona ao criar um novo plano. Para obter etapas detalhadas, consulte Criar um aplicativo de funções com redundância de zona.

  • Habilite a redundância de zona em um plano existente: Para planos Premium, você só pode habilitar a redundância de zona durante a criação do plano. Você não pode converter um plano Premium existente para ser com redundância de zona. Em vez disso, você deve migrar seu aplicativo criando uma implantação lado a lado em um novo aplicativo de plano Premium. Para obter mais informações, consulte Habilitar redundância de zona em um plano existente.

Planejamento e gerenciamento de capacidade

Os aplicativos de funções com redundância de zona continuam a ser executados mesmo quando as zonas na região sofrem uma interrupção.

Durante uma interrupção de zona, o Azure Functions detecta instâncias perdidas e tenta localizar ou criar automaticamente instâncias de substituição nas zonas íntegras. Esse processo é feito com o melhor esforço e não é garantido. Se sua carga de trabalho precisar ter um determinado número de instâncias para manter o nível de serviço esperado, considere o superprovisionamento do número de instâncias sempre prontas. Essa abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem desempenho degradado. Para mais informações, consulte Gerenciar capacidade usando superprovisionamento.

Comportamento quando todas as zonas estão saudáveis

** Esta seção descreve o que esperar quando um plano tem redundância de zona, a conta de armazenamento do host usa a ZRS e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: Quando você configura a redundância de zona no Azure Functions, as solicitações são distribuídas automaticamente entre as instâncias em cada zona de disponibilidade. Uma solicitação 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, portanto, não há dados do cliente para replicar entre zonas. A plataforma replica a configuração entre zonas automaticamente.

    Se sua conta de armazenamento de host usar o ZRS, o Armazenamento do Azure replicará de forma síncrona seus dados em várias zonas de disponibilidade.

    Para o Durable Functions, examine seu provedor de armazenamento para entender como ele replica dados entre zonas.

Comportamento durante uma falha de zona

Esta seção descreve as expectativas para quando um plano é redundante entre zonas, a conta de armazenamento do host utiliza ZRS e ocorre uma interrupção na zona de disponibilidade.

  • Detecção e resposta: A plataforma do Azure Functions é responsável por detectar uma falha em uma zona de disponibilidade. Você não precisa fazer nada para iniciar um failover de zona.
  • Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Azure Service Health para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Quando uma zona de disponibilidade não está disponível, todas as solicitações em andamento conectadas a uma instância na zona de disponibilidade com falha são encerradas e precisam ser repetidas. Verifique se os aplicativos estão 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 sua conta de armazenamento de host usar ZRS, o Azure Storage garante que não haja nenhuma perda de dados em caso de falha numa zona.

    Para o Durable Functions, examine seu provedor de armazenamento para entender se a perda de dados é possível durante uma falha de zona.

  • Tempo de inatividade esperado: Durante interrupções de zona, as conexões podem sofrer breves interrupções que normalmente duram alguns segundos à medida que o tráfego é redistribuído. Verifique se os aplicativos estão preparados seguindo as diretrizes de tratamento de falhas transitórias.

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

    Importante

    O Azure não garante que as solicitações por mais instâncias sejam bem-sucedidas em um cenário de queda de zona. A plataforma tenta repor as instâncias perdidas com base no melhor esforço possível. Se você precisar de capacidade garantida durante uma falha na zona de disponibilidade, crie e configure seus planos para considerar a perda de zona, provisionando a capacidade em excesso.

  • Comportamentos fora do tempo de execução: Os aplicativos em um plano de aplicativo de função com redundância por zona continuam a ser executados e atendem ao tráfego mesmo que uma zona de disponibilidade sofra uma parada. No entanto, comportamentos que não são de runtime ainda podem ser afetados durante uma interrupção da zona de disponibilidade. Esses comportamentos incluem dimensionamento de aplicativo de funções, criação de aplicativo, configuração de aplicativo e publicação de aplicativos.

Recuperação de zona

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

Testar falhas em zonas

A plataforma do Azure Functions gerencia o roteamento de tráfego, o failover e a recuperação de zona para recursos com redundância de zona. Você não precisa iniciar nada. Como esse recurso é totalmente gerenciado, você não precisa 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 região única. Se a região ficar indisponível, o recurso do Azure Functions também ficará 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 de forma redundante as mesmas funções para aplicativos de funções em várias regiões.

Você é responsável por:

  • Implantando aplicativos de funções em várias regiões
  • Gerenciando a distribuição de tráfego entre regiões
  • Implementando mecanismos de failover
  • Garantindo a consistência de dados entre regiões (se aplicável)
  • Monitoramento e gerenciamento de implantações entre regiões

Quando você executa o mesmo código de função em várias regiões, há dois padrões comumente usados que você pode considerar: ativo-ativo e ativo-passivo. As seções a seguir fornecem uma breve introdução a esses padrões, mas não fornecem diretrizes detalhadas ou etapas 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 em execução ativa e processando eventos, seja de maneira duplicada ou em rotação. Você deve usar um padrão ativo-ativo em combinação com o Azure Front Door para suas funções críticas disparadas por HTTP, possibilitando o roteamento e o balanceamento de carga das requisições HTTP entre funções em execução em várias regiões. O Azure Front Door também pode monitorar periodicamente a integridade de cada ponto de extremidade. Se uma função em uma região parar de responder a verificações de integridade, o Azure Front Door a tira da rotação e encaminha apenas o tráfego para as funções saudáveis restantes.

Diagrama mostrando um exemplo de arquitetura ativa-ativa, com o roteamento do Azure Front Door entre aplicativos do Azure Functions em regiões diferentes, cada uma com seu próprio banco de dados.

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

Para funções acionadas por eventos, que não são disparadas por HTTP (como funções acionadas por Service Bus e Event Hubs), 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 de apenas uma única função processar cada mensagem, o que é importante para manter a consistência de dados, ao mesmo tempo em que oferece um mecanismo para transferir operação para a região secundária em um desastre, como uma interrupção regional.

O failover do aplicativo de funções precisa ser considerado, levando em consideração os comportamentos de failover de outros serviços, como:

Considere uma topologia de exemplo usando um gatilho do Azure Event Hubs, em que o namespace dos Hubs de Eventos está configurado para recuperação geográfica de desastres. Nesse caso, o padrão ativo-passivo requer os seguintes componentes:

  • Hubs de Eventos do Azure implantados nas regiões primária e secundária.
  • Recuperação de desastre geográfico habilitada para emparelhar os hubs de eventos primários e secundários. Isso também cria um alias que você pode usar para se conectar ao namespace dos Hubs de Eventos e alternar de primário para secundário sem alterar as informações de conexão.
  • Aplicativos de função implantados nas regiões primária e secundária (failover), com o aplicativo na região secundária essencialmente inativo porque as mensagens não estão sendo enviadas para lá.
  • O aplicativo de funções dispara na cadeia de conexão direta (não alias) para o seu respectivo namespace dos Hubs de Eventos.
  • Os editores no namespace dos Hubs de Eventos devem publicar na cadeia de conexão de alias.

Diagrama mostrando um exemplo de arquitetura ativa-passiva, com a recuperação de desastre geográfico dos Hubs de Eventos abrangendo várias regiões e aplicativos de funções e bancos de dados separados em cada região.

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.

Funções duráveis

Para recuperação de desastre de várias regiões para Durable Functions, consulte Recuperação de desastre e distribuição geográfica no Azure Durable Functions.

Resiliência à manutenção do serviço

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

  • Resiliência de falha transitória: Durante a manutenção do serviço, as instâncias que executam seu aplicativo de funções podem ser reiniciadas ou sofrer interrupções temporárias. Verifique se todos os aplicativos cliente que interagem com seu aplicativo de funções são resilientes a falhas transitórias.
  • Habilitar redundância de zona: Ao habilitar a redundância de zona em seu plano, você também melhora a resiliência durante as atualizações da plataforma. Implantar várias instâncias no seu plano e habilitar a redundância de zona aumentam a resiliência se uma instância ou zona se tornar instável durante uma atualização.

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

  • Habilitar redundância de zona: Ao habilitar a redundância de zona em seu plano, você também melhora a resiliência durante as atualizações da plataforma. Domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e que são mapeados para zonas de disponibilidade. Desplegar várias instâncias no seu plano e habilitar a redundância de zona adiciona uma camada extra de resiliência se uma instância ou zona se tornar indisponível durante uma atualização.

  • Ambiente do Serviço de Aplicativo: Se você hospedar seu aplicativo de funções em um Ambiente do Serviço de Aplicativo, poderá personalizar o ciclo de atualização. Se você precisar validar o efeito das atualizações na sua carga de trabalho, habilite as atualizações manuais. Essa abordagem permite realizar validação e testes em uma instância fora de produção antes de aplicá-los à sua instância de produção.

    Para 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 implantações de aplicativos

As implantações de aplicativos introduzem o risco de problemas em um ambiente de produção. Você deve estar preparado para reverter uma atualização se ela causar problemas. Você também deve controlar como as atualizações são distribuídas para minimizar a interrupção das reinicializações do aplicativo.

Os planos de consumo flex dão suporte a estratégias de atualização de site, que fornecem várias maneiras de implantar as atualizações do aplicativo, incluindo atualizações sem interrupção para implantações de tempo de inatividade zero.

Os slots de implantação do Azure Functions permitem implantações sem tempo de inatividade de seus aplicativos 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 seu aplicativo ser reiniciado. Reiniciar o aplicativo causa uma falha transitória.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de 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 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