Funções do Azure opções de alojamento
Quando cria uma aplicação de funções no Azure, tem de escolher um plano de alojamento para a sua aplicação. Existem três planos básicos de alojamento disponíveis para Funções do Azure: plano de consumo, plano Premium e plano Dedicado (Serviço de Aplicações). Todos os planos de alojamento estão geralmente disponíveis (GA) em máquinas virtuais do Linux e do Windows.
O plano de alojamento que escolher dita os seguintes comportamentos:
- Como a sua aplicação de funções é dimensionada.
- Os recursos disponíveis para cada instância da aplicação de funções.
- Suporte para funcionalidades avançadas, como o Azure Rede Virtual conectividade.
Este artigo fornece uma comparação detalhada entre os vários planos de alojamento, juntamente com o alojamento baseado no Kubernetes.
Nota
Se optar por alojar as suas funções num cluster do Kubernetes, considere utilizar um cluster do Kubernetes compatível com o Azure Arc. O alojamento num cluster do Kubernetes compatível com o Azure Arc está atualmente em pré-visualização. Para saber mais, veja Serviço de Aplicações, Funções e Logic Apps no Azure Arc.
Descrição geral dos planos
Segue-se um resumo das vantagens dos três principais planos de alojamento para Funções:
| Planear | Benefícios |
|---|---|
| Plano de consumo | Dimensione automaticamente e pague apenas os recursos de computação quando as suas funções estiverem em execução. No plano Consumo, as instâncias do anfitrião de Funções são adicionadas e removidas dinamicamente com base no número de eventos recebidos. ✔ Plano de alojamento predefinido. ✔ Pague apenas quando as suas funções estiverem em execução. ✔ Dimensiona automaticamente, mesmo durante períodos de carga elevada. |
| Plano Premium | Dimensiona automaticamente com base na procura através de trabalhadores pré-aquecidos, que executam aplicações sem atraso após estarem inativas, são executadas em instâncias mais poderosas e ligam-se a redes virtuais. Considere o plano Funções do Azure Premium nas seguintes situações: ✔ As aplicações de funções são executadas continuamente ou quase continuamente. ✔ Tem um número elevado de pequenas execuções e uma fatura de execução elevada, mas poucos segundos GB no plano Consumo. ✔ Precisa de mais opções de CPU ou memória do que as fornecidas pelo Plano de consumo. ✔ O código tem de ser executado durante mais tempo do que o tempo máximo de execução permitido no Plano de consumo. ✔ Precisa de funcionalidades que não estejam disponíveis no plano consumo, como a conectividade de rede virtual. ✔ Quer fornecer uma imagem personalizada do Linux para executar as suas funções. |
| Plano dedicado | Execute as suas funções num plano de Serviço de Aplicações com taxas regulares de planos de Serviço de Aplicações. Melhor para cenários de execução prolongada em que não é possível utilizar Durable Functions. Considere um plano de Serviço de Aplicações nas seguintes situações: ✔ Tem VMs subutilizadas existentes que já estão a executar outras instâncias Serviço de Aplicações. ✔ O dimensionamento preditivo e os custos são necessários. |
As tabelas de comparação neste artigo também incluem as seguintes opções de alojamento, que fornecem a maior quantidade de controlo e isolamento para executar as suas aplicações de funções.
| Opção de alojamento | Detalhes |
|---|---|
| ASE | Ambiente do Serviço de Aplicações (ASE) é uma funcionalidade Serviço de Aplicações que fornece um ambiente totalmente isolado e dedicado para executar aplicações Serviço de Aplicações em alta escala de forma segura. Os ASEs são adequados para cargas de trabalho de aplicações que requerem: ✔ Escala muito alta. ✔ Isolamento total da computação e acesso seguro à rede. ✔ Utilização elevada da memória. |
| Kubernetes (Direto ou Azure Arc) |
O Kubernetes fornece um ambiente totalmente isolado e dedicado em execução na plataforma kubernetes. O Kubernetes é adequado para cargas de trabalho de aplicações que requerem: ✔ Requisitos de hardware personalizados. ✔ Isolamento e acesso seguro à rede. ✔ Capacidade de execução em ambiente híbrido ou multi cloud. ✔ Execute juntamente com aplicações e serviços do Kubernetes existentes. |
As restantes tabelas neste artigo comparam os planos em várias funcionalidades e comportamentos. Para obter uma comparação de custos entre planos de alojamento dinâmicos (Consumo e Premium), veja a página de preços do Funções do Azure. Para obter os preços das várias opções de plano dedicado, consulte a página de preços do Serviço de Aplicações.
Sistema operativo/runtime
A tabela seguinte mostra o sistema operativo e o suporte de idiomas para os planos de alojamento.
| Linux1,2 apenas código |
Apenas código do Windows | Linux1,2,3 Contentor do Docker |
|
|---|---|---|---|
| Plano de consumo | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Sem suporte |
| Plano Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Plano dedicado | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (direto) | n/a | n/a | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (Pré-visualização) | C# JavaScript Java Python TypeScript |
n/a | C# JavaScript Java PowerShell Core Python TypeScript |
1 O Linux é o único sistema operativo suportado para a pilha de runtime do Python.
2 O suporte do PowerShell no Linux está atualmente em pré-visualização.
3 O Linux é o único sistema operativo suportado para contentores do Docker.
Duração do tempo limite da aplicação de funções
A duração do tempo limite das funções numa aplicação de funções é definida pela functionTimeout propriedade no ficheiro de projeto host.json . Esta propriedade aplica-se especificamente a execuções de funções. Depois de o acionador iniciar a execução da função, a função tem de devolver/responder dentro da duração do tempo limite. Para obter mais informações, veja Melhorar o desempenho e a fiabilidade do Funções do Azure.
A tabela seguinte mostra os valores predefinidos e máximos (em minutos) para planos específicos:
| Planear | Predefinição | Máximo1 |
|---|---|---|
| Plano de consumo | 5 | 10 |
| Plano Premium | 302 | Ilimitado |
| Plano dedicado | 302 | Ilimitado |
1 Independentemente da definição de tempo limite da aplicação de funções, 230 segundos é a quantidade máxima de tempo que uma função acionada por HTTP pode demorar a responder a um pedido. Isto deve-se ao tempo limite de inatividade predefinido de Balanceador de Carga do Azure. Para tempos de processamento mais longos, considere utilizar o padrão assíncrono Durable Functions ou diferir o trabalho real e devolver uma resposta imediata.
2 O tempo limite predefinido para a versão 1.x do runtime das Funções é ilimitado.
Escala
A tabela seguinte compara os comportamentos de dimensionamento dos vários planos de alojamento.
As instâncias máximas são fornecidas numa base por aplicação por função (Consumo) ou por plano (Premium/Dedicado), salvo indicação em contrário.
| Planear | Aumentar horizontalmente | Número máximo de instâncias |
|---|---|---|
| Plano de consumo | Condicionada por eventos. Aumentar horizontalmente automaticamente, mesmo durante períodos de carga elevada. Funções do Azure infraestrutura dimensiona a CPU e os recursos de memória ao adicionar instâncias adicionais do anfitrião das Funções, com base no número de eventos de acionador recebidos. | Windows: 200 Linux: 1001 |
| Plano Premium | Condicionada por eventos. Aumentar horizontalmente automaticamente, mesmo durante períodos de carga elevada. Funções do Azure infraestrutura dimensiona a CPU e os recursos de memória ao adicionar instâncias adicionais do anfitrião das Funções, com base no número de eventos em que as suas funções são acionadas. | Windows: 100 Linux: 20-1002 |
| Plano dedicado3 | Dimensionamento manual/automático | 10-30 |
| ASE3 | Dimensionamento manual/automático | 100 |
| Utilizar o Kubernetes | Dimensionamento automático condicionado por eventos para clusters do Kubernetes com KEDA. | Varia de acordo com o cluster |
1 Durante o aumento horizontal, existe atualmente um limite de 500 instâncias por subscrição por hora para aplicações Linux num plano de Consumo.
2 Em algumas regiões, as aplicações Linux num plano Premium podem ser dimensionadas para 100 instâncias. Para obter mais informações, veja o artigo Plano Premium.
3 Para obter limites específicos para as várias opções do plano de Serviço de Aplicações, veja os limites do plano de Serviço de Aplicações.
Comportamento de arranque a frio
| Planear | Detalhes |
|---|---|
| Plano de consumo | As aplicações podem ser dimensionadas para zero quando estão inativas, o que significa que alguns pedidos podem ter latência adicional no arranque. O plano de consumo tem algumas otimizações para ajudar a diminuir a hora de início a frio, incluindo a extração de funções de marcador de posição pré-aqueadas que já têm o anfitrião de funções e os processos de linguagem em execução. |
| Plano Premium | Instâncias perpétuamente quentes para evitar qualquer arranque a frio. |
| Plano dedicado | Ao executar num plano Dedicado, o anfitrião de Funções pode ser executado continuamente, o que significa que o arranque a frio não é realmente um problema. |
| ASE | Ao executar num plano Dedicado, o anfitrião de Funções pode ser executado continuamente, o que significa que o arranque a frio não é realmente um problema. |
| Utilizar o Kubernetes | Dependendo da configuração keda, as aplicações podem ser configuradas para evitar um arranque a frio. Se configurado para dimensionar para zero, é registado um início a frio para novos eventos. |
Limites do serviço
| Recurso | Plano de consumo | Plano Premium | Plano dedicado | ASE | Kubernetes |
|---|---|---|---|---|---|
| Duração do tempo limite predefinida (min) | 5 | 30 | 301 | 30 | 30 |
| Duração máxima do tempo limite (min) | 10 | não vinculado7 | não vinculado2 | não vinculado | não vinculado |
| Máximo de ligações de saída (por instância) | 600 ativos (1200 no total) | não vinculado | não vinculado | não vinculado | não vinculado |
| Tamanho máximo do pedido (MB)3 | 100 | 100 | 100 | 100 | Depende do cluster |
| Comprimento máximo da cadeia de consulta3 | 4096 | 4096 | 4096 | 4096 | Depende do cluster |
| Comprimento máximo do URL do pedido3 | 8192 | 8192 | 8192 | 8192 | Depende do cluster |
| ACU por instância | 100 | 210-840 | 100-840 | 210-2508 | Preços do AKS |
| Memória máxima (GB por instância) | 1.5 | 3.5-14 | 1.75-14 | 3.5 - 14 | Qualquer nó é suportado |
| Contagem máxima de instâncias (Windows/Linux) | 200/100 | 100/20 | varia por SKU9 | 1009 | Depende do cluster |
| Aplicações de funções por plano | 100 | 100 | não vinculado4 | não vinculado | não vinculado |
| Planos do Serviço de Aplicações | 100 por região | 100 por grupo de recursos | 100 por grupo de recursos | - | - |
| Blocos de implementação por aplicação10 | 2 | 3 | 1-209 | 20 | n/a |
| Armazenamento5 | 5 TB | 250 GB | 50-1000 GB | 1 TB | n/a |
| Domínios personalizados por aplicação | 5006 | 500 | 500 | 500 | n/a |
| Suporte SSL de domínio personalizado | ligação SNI SSL não vinculada incluída | SSL SNI não vinculado e 1 ligações SSL IP incluídas | SSL SNI não vinculado e 1 ligações SSL IP incluídas | SSL SNI não vinculado e 1 ligações SSL IP incluídas | n/a |
1 Por predefinição, o tempo limite para o runtime das Funções 1.x num plano de Serviço de Aplicações não está vinculado.
2 Requer que o plano de Serviço de Aplicações esteja definido como AlwaysOn. Pagar a tarifas padrão.
3 Estes limites são definidos no anfitrião.
4 O número real de aplicações de funções que pode alojar depende da atividade das aplicações, do tamanho das instâncias da máquina e da utilização de recursos correspondente.
5 O limite de armazenamento é o tamanho total do conteúdo no armazenamento temporário em todas as aplicações no mesmo plano de Serviço de Aplicações. O plano de consumo utiliza Ficheiros do Azure para armazenamento temporário.
6 Quando a aplicação de funções está alojada num plano de Consumo, só é suportada a opção CNAME. Para aplicações de funções num plano Premium ou num plano de Serviço de Aplicações, pode mapear um domínio personalizado com um CNAME ou um registo A.
7 Garantido até 60 minutos.
8 Os trabalhadores são funções que alojam aplicações de clientes. As funções de trabalho estão disponíveis em três tamanhos fixos: uma vCPU/3,5 GB de RAM; Duas vCPUs/7 GB de RAM; Quatro RAM vCPU/14 GB.
9 Veja Serviço de Aplicações limites para obter detalhes.
10 Incluindo o bloco de produção.
Limitações para criar novas aplicações de funções num grupo de recursos existente
Em alguns casos, ao tentar criar um novo plano de alojamento para a sua aplicação de funções num grupo de recursos existente, poderá receber um dos seguintes erros:
- O escalão de preço não é permitido neste grupo de recursos
- <> SKU_name trabalhadores não estão disponíveis no grupo <de recursos resource_group_name>
Isto pode acontecer quando são cumpridas as seguintes condições:
- Pode criar uma aplicação de funções num grupo de recursos existente que já tenha contido outra aplicação de funções ou aplicação Web.
- A nova aplicação de funções é criada na mesma região que a aplicação anterior.
- A aplicação anterior é de alguma forma incompatível com a sua nova aplicação. Isto pode acontecer entre SKUs, sistemas operativos ou devido a outras funcionalidades ao nível da plataforma, como o suporte da zona de disponibilidade.
Esta situação deve-se à forma como a aplicação de funções e os planos de aplicações Web são mapeados para diferentes conjuntos de recursos quando são criados. SkUs diferentes requerem um conjunto diferente de capacidades de infraestrutura. Quando cria uma aplicação num grupo de recursos, esse grupo de recursos é mapeado e atribuído a um conjunto específico de recursos. Se tentar criar outro plano nesse grupo de recursos e o conjunto mapeado não tiver os recursos necessários, este erro ocorrerá.
Quando este erro ocorrer, crie a aplicação de funções e o plano de alojamento num novo grupo de recursos.
Funcionalidades de rede
| Funcionalidade | Plano de consumo | Plano Premium | Plano dedicado | ASE |
|---|---|---|---|---|
| Restrições de IP de entrada | ✅Sim | ✅Yes | ✅Yes | ✅Yes |
| Pontos Finais Privados de Entrada | ❌Não | ✅Sim | ✅Yes | ✅Yes |
| Integração da rede virtual | ❌Não | ✅Sim (Regional) | ✅Sim (Regional e Gateway) | ✅Sim |
| Acionadores de rede virtual (não HTTP) | ❌Não | ✅Sim | ✅Yes | ✅Sim |
| Ligações híbridas (apenas Windows) | ❌Não | ✅Yes | ✅Yes | ✅Yes |
| Restrições de IP de saída | ❌Não | ✅Yes | ✅Yes | ✅Yes |
Faturação
| Planear | Detalhes |
|---|---|
| Plano de consumo | Pague apenas pelo tempo de execução das suas funções. A faturação baseia-se no número de execuções, no tempo de execução e na memória utilizada. |
| Plano Premium | O plano Premium baseia-se no número de segundos principais e na memória utilizada em instâncias necessárias e pré-aqueciadas. Pelo menos uma instância por plano tem de ser sempre mantida quente. Este plano fornece os preços mais previsíveis. |
| Plano dedicado | Paga o mesmo pelas aplicações de funções num Plano de Serviço de Aplicações, tal como faria com outros recursos Serviço de Aplicações, como aplicações Web. |
| Ambiente do Serviço de Aplicações (ASE) | Existe uma taxa mensal fixa para um ASE que paga a infraestrutura e não muda com o tamanho do ASE. Também existe um custo por Serviço de Aplicações vCPU do plano. Todas as aplicações alojadas num ASE estão na SKU de preços Isolada. |
| Utilizar o Kubernetes | Paga apenas os custos do cluster do Kubernetes; sem faturação adicional para Funções. A sua aplicação de funções é executada como uma carga de trabalho de aplicação sobre o cluster, tal como uma aplicação normal. |