Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
No Azure Functions, uma única instância de aplicativo de funções permite que vários eventos sejam processados simultaneamente. Como eles são executados na mesma instância de computação, eles compartilham recursos de memória, CPU e conexão. Em determinados planos de hospedagem, a alta demanda em uma instância específica faz com que o host do Functions crie automaticamente novas instâncias para lidar com o aumento da carga. Nesses planos de escala dinâmica , há uma compensação entre comportamentos de simultaneidade e dimensionamento. Para fornecer mais controle sobre como seu aplicativo é executado, o Functions fornece uma maneira de gerenciar o número de execuções simultâneas.
O Functions fornece duas maneiras principais de gerenciar a simultaneidade:
- Simultaneidade fixa por instância: você pode configurar limites de simultaneidade no nível do host que são específicos para gatilhos individuais. Esse modelo é o comportamento de simultaneidade padrão para o Functions.
- Simultaneidade dinâmica: para determinados tipos de gatilho, o host do Functions pode determinar automaticamente o melhor nível de simultaneidade para esse gatilho em seu aplicativo de funções. Você deve aceitar esse modelo de simultaneidade.
Este artigo descreve os comportamentos de simultaneidade de gatilhos controlados por eventos em funções e como esses comportamentos afetam o dimensionamento em planos dinâmicos. Ele também compara os modelos de concorrência fixos por instância e dinâmica.
Escalabilidade versus concorrência
Para funções que usam gatilhos baseados em evento ou respondem a solicitações HTTP, você pode atingir rapidamente os limites de execuções simultâneas durante períodos de alta demanda. Durante esses períodos, você deve ser capaz de dimensionar seu aplicativo de funções adicionando instâncias para evitar uma lista de pendências no processamento de solicitações de entrada. A maneira como dimensionamos seu aplicativo depende do seu plano de hospedagem:
| Tipo de escala | Planos de hospedagem | Descrição |
|---|---|---|
| Dimensionamento dinâmico (controlado por eventos) |
Consumo Consumo flexível Prêmio |
Em um plano de escala dinâmica, o host dimensiona o número de instâncias do aplicativo de funções para cima ou para baixo com base no número de eventos de entrada. Para obter mais informações, consulte o dimensionamento controlado por eventos no Azure Functions. |
| Dimensionamento manual | Planos dedicados (Serviço de Aplicativo) | Ao hospedar seu aplicativo de funções em um plano dedicado, você deve configurar manualmente suas instâncias durante períodos de maior carga ou configurar um esquema de dimensionamento automático. |
Antes que qualquer dimensionamento possa ocorrer, seu aplicativo de funções tenta lidar com aumentos de carga manipulando várias invocações do mesmo tipo em uma única instância. Como resultado, essas execuções simultâneas em uma determinada instância afetam diretamente as decisões de escala. Por exemplo, quando um aplicativo em um plano de escala dinâmica atinge um limite de simultaneidade, talvez seja necessário dimensionar para acompanhar a demanda futura.
O equilíbrio de escala versus simultaneidade que você tenta alcançar em seu aplicativo depende de onde podem ocorrer gargalos: no processamento (limitações de processo com uso intensivo de CPU) ou em um serviço downstream (limitações baseadas em E/S).
Simultaneidade fixa por instância
Por padrão, a maioria dos gatilhos dá suporte a um modelo de configuração de simultaneidade fixa por instância por meio de escalabilidade baseada em destino. Nesse modelo, cada tipo de gatilho tem um limite de simultaneidade por instância.
Você pode substituir os valores padrão de simultaneidade para a maioria dos gatilhos definindo uma simultaneidade específica por instância para esse tipo de gatilho. Para muitos gatilhos, você define as configurações de simultaneidade no arquivo host.json. Por exemplo, o gatilho do Barramento de Serviço do Azure fornece uma configuração de MaxConcurrentCalls e MaxConcurrentSessions em host.json. Essas configurações funcionam em conjunto para controlar o número máximo de mensagens que cada aplicativo de funções processa simultaneamente em cada instância.
Em determinados cenários de dimensionamento baseados em destino, como quando você usa um gatilho Apache Kafka ou Azure Cosmos DB, a configuração de simultaneidade está na declaração de função e não no arquivo host.json. Outros tipos de gatilho têm mecanismos internos para balancear a carga entre as instâncias. Por exemplo, os Hubs de Eventos do Azure e o Azure Cosmos DB usam um esquema baseado em partição.
Para tipos de gatilho que dão suporte à configuração de simultaneidade, as configurações de simultaneidade são aplicadas a todas as instâncias em execução. Dessa forma, você pode controlar a simultaneidade máxima para suas funções em cada instância. Por exemplo, quando sua função é intensiva em CPU ou recursos, você pode optar por limitar a simultaneidade para manter as instâncias saudáveis. Nesse caso, você pode contar com a escala para lidar com cargas maiores. Da mesma forma, quando sua função faz solicitações a um serviço downstream que está sendo limitado, você também deve considerar limitar a simultaneidade para evitar sobrecarregar o serviço downstream.
Simultaneidade do gatilho HTTP
Aplica-se somente ao Plano de Consumo Flex
A simultaneidade do gatilho HTTP é um tipo especial de simultaneidade fixa por instância. Na simultaneidade de gatilhos HTTP, a simultaneidade padrão também depende do tamanho da instância.
O plano Consumo Flex dimensiona todas as funções de gatilho HTTP juntas como um grupo. Para obter mais informações, confira Escala por função.
A tabela a seguir indica a configuração de simultaneidade padrão para gatilhos HTTP em uma determinada instância, com base no tamanho da memória da instância configurada:
| Tamanho da instância (MB) | * simultaneidade padrão |
|---|---|
| 512 | 4 |
| 2.048 | 16 |
| 4.096 | 32 |
*Em aplicativos Python, todos os tamanhos de instância usam um nível de simultaneidade de gatilho HTTP de um por padrão.
Esses valores padrão devem funcionar bem para a maioria dos casos e você pode começar com eles. Considere que, em um determinado número de solicitações HTTP, aumentar o valor de simultaneidade HTTP reduz o número de instâncias necessárias para lidar com solicitações HTTP. Da mesma forma, diminuir o valor de simultaneidade HTTP requer mais instâncias para lidar com a mesma carga.
Se você precisar ajustar a simultaneidade HTTP, poderá fazer isso usando a CLI do Azure. Para obter mais informações, consulte Definir limites de simultaneidade HTTP.
Os valores de simultaneidade padrão na tabela anterior se aplicam somente quando você não define sua própria configuração de simultaneidade HTTP. Quando você não define explicitamente uma configuração de simultaneidade HTTP, a simultaneidade padrão aumenta conforme mostrado na tabela quando você altera o tamanho da instância. Depois de definir especificamente um valor de simultaneidade HTTP, esse valor será mantido apesar das alterações no tamanho da instância.
Determinar a concorrência fixa ideal por instância
Configurações de simultaneidade fixa por instância oferecem controle sobre certos comportamentos de gatilho, como a limitação de suas funções. Mas pode ser difícil determinar os valores ideais para essas configurações. Em geral, você precisa chegar a valores aceitáveis por um processo iterativo de teste de carga. Mesmo depois de determinar um conjunto de valores que funcionam para um perfil de carga específico, o número de eventos que chegam de seus serviços conectados pode mudar de dia para dia. Essa variabilidade pode fazer com que seu aplicativo seja executado com valores abaixo do ideal. Por exemplo, seu aplicativo de funções pode processar cargas de mensagens exigentes no último dia da semana, o que exige que você limite a concorrência. No entanto, durante o restante da semana, os payloads de mensagem podem ser mais leves, o que significa que você pode usar um nível de simultaneidade maior no restante da semana.
Idealmente, o sistema deve permitir que as instâncias processem o máximo de trabalho possível, mantendo cada instância íntegra e latências baixas. A concorrência dinâmica foi projetada para essa finalidade.
Simultaneidade dinâmica
O Functions fornece um modelo de simultaneidade dinâmica que simplifica a configuração da simultaneidade para todos os aplicativos de funções executados no mesmo plano.
Observação
A simultaneidade dinâmica é atualmente com suporte apenas para os gatilhos de Armazenamento de Blobs do Azure, Armazenamento de Filas do Azure e Barramento de Serviço. Além disso, você deve usar as versões de extensão listadas no suporte à extensão, posteriormente neste artigo.
Benefícios
A simultaneidade dinâmica fornece os seguintes benefícios:
- Configuração simplificada: você não precisa mais determinar manualmente as configurações de simultaneidade por gatilho. O sistema aprende os valores ideais para a carga de trabalho ao longo do tempo.
- Ajustes dinâmicos: a simultaneidade é ajustada dinamicamente em tempo real, o que permite que o sistema se adapte a padrões de carga alterados ao longo do tempo.
- Proteção de integridade da instância: o runtime limita a simultaneidade a níveis que uma instância de aplicativo de funções pode lidar confortavelmente. Esses limites protegem o aplicativo do risco de sobrecarga ao assumir mais tarefas do que consegue gerenciar.
- Taxa de transferência aprimorada: a taxa de transferência geral é melhorada, pois as instâncias individuais não puxam mais trabalho do que podem processar rapidamente. Como resultado, a carga de trabalho é balanceada de forma mais eficaz entre instâncias. Para funções que podem lidar com cargas mais altas, uma taxa de transferência mais alta pode ser obtida aumentando a simultaneidade para valores acima da configuração padrão.
Configuração de simultaneidade dinâmica
Você pode ativar a simultaneidade dinâmica no nível do host no arquivo host.json . Quando ele é ativado, os níveis de simultaneidade de quaisquer extensões de associação que dão suporte a esse recurso são ajustados automaticamente conforme necessário. Nesses casos, as configurações de simultaneidade dinâmica substituem as configurações de simultaneidade configuradas manualmente.
Por padrão, a simultaneidade dinâmica está desativada. Quando você ativa a simultaneidade dinâmica, a simultaneidade começa em um nível de um para cada função. O nível de simultaneidade é ajustado até um valor ideal, que o host determina.
Você pode ativar a simultaneidade dinâmica em seu aplicativo de funções adicionando as seguintes configurações ao arquivo host.json :
{
"version": "2.0",
"concurrency": {
"dynamicConcurrencyEnabled": true,
"snapshotPersistenceEnabled": true
}
}
Quando snapshotPersistenceEnabled é true, que é o valor padrão, os valores de simultaneidade aprendidos são periodicamente mantidos no armazenamento. Novas instâncias começam a partir desses valores em vez de começar a partir de um nível e ter que refazer o aprendizado.
Gerenciador de simultaneidade
Nos bastidores, quando a simultaneidade dinâmica é ativada, um processo do gerenciador de simultaneidade é executado em segundo plano. Esse gerente monitora constantemente as métricas de integridade da instância, como a utilização da CPU e de threads, e altera as limitações conforme necessário. Quando uma ou mais limitações são ativadas, a simultaneidade da função é reduzida até que o host esteja íntegro novamente. Quando os aceleradores são desativados, a concorrência pode aumentar. Várias heurísticas são usadas para aumentar ou reduzir a simultaneidade, de maneira inteligente, com base nessas limitações. Ao longo do tempo, a simultaneidade de cada função se estabiliza em um nível específico. Como pode levar tempo para determinar o valor ideal de simultaneidade, use simultaneidade dinâmica somente se, inicialmente ou após um período de inatividade, um valor subótimo for aceitável para sua solução.
Os níveis de simultaneidade são gerenciados para cada função individual. Especificamente, o sistema equilibra entre funções com uso intensivo de recursos que exigem um baixo nível de simultaneidade e funções mais leves que podem lidar com maior simultaneidade. O equilíbrio de simultaneidade para cada função ajuda a manter a integridade geral da instância do aplicativo de funções.
Quando a simultaneidade dinâmica é ativada, você encontra decisões de simultaneidade dinâmica em seus logs. Por exemplo, entradas de log são adicionadas quando várias limitações são ativadas e sempre que a simultaneidade é ajustada para cima ou para baixo para cada função. Esses logs são gravados na categoria de log Host.Concurrency na tabela traces.
Suporte à extensão
A simultaneidade dinâmica é habilitada para um aplicativo de funções no nível do host, e todas as extensões que dão suporte para a simultaneidade dinâmica são executadas nesse modo. A simultaneidade dinâmica requer colaboração entre o host e as extensões de gatilho individuais. Apenas as versões listadas das extensões a seguir dão suporte para a simultaneidade dinâmica.
| Extensão | Versão | Descrição |
|---|---|---|
| Armazenamento de Filas | Versão 5.x (extensão de armazenamento) | O gatilho de Armazenamento de Filas tem seu próprio loop de sondagem de mensagens. Quando você usa uma configuração fixa por instância, as opções de configuração BatchSize e NewBatchThreshold regem a simultaneidade. Quando você usa simultaneidade dinâmica, esses valores de configuração são ignorados. A simultaneidade dinâmica é integrada ao loop de mensagens, portanto, o número de mensagens recuperadas por iteração é ajustado dinamicamente. Quando as limitações são ativadas, o host está sobrecarregado. O processamento de mensagens é pausado até que as limitações sejam desativadas. Quando os controladores de velocidade são desativados, a concorrência aumenta. |
| Armazenamento de Blobs | Versão 5.x (extensão de armazenamento) | Internamente, o gatilho de Armazenamento de Blobs utiliza a mesma infraestrutura que o gatilho de Armazenamento de Filas. Quando blobs novos ou atualizados precisam ser processados, as mensagens são gravadas em uma fila de controle gerenciada pela plataforma. Essa fila é processada usando a mesma lógica usada para o gatilho de Armazenamento de Filas. Quando a simultaneidade dinâmica é ativada, a simultaneidade para o processamento dessa fila de controle é gerenciada dinamicamente. |
| Barramento de Serviço | Versão 5.x | O gatilho do Barramento de Serviço atualmente dá suporte para três modelos de execução. A simultaneidade dinâmica afeta esses modelos de execução das seguintes maneiras:MaxConcurrentCalls de configuração rege a simultaneidade. Quando você usa simultaneidade dinâmica, esse valor de configuração é ignorado e a simultaneidade é ajustada dinamicamente.MaxConcurrentSessions configuração rege a simultaneidade. Quando a simultaneidade dinâmica é ativada, o MaxConcurrentSessions valor é ignorado e o número de sessões que cada instância processa é ajustado dinamicamente.MaxMessageCount . Como as invocações em lote são sequenciais, a simultaneidade da sua função disparada em lote é sempre uma, e a simultaneidade dinâmica não se aplica. |
Próximas etapas
Para saber mais, consulte os recursos a seguir: