Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
No Azure Functions, uma única instância de aplicativo de função permite que vários eventos sejam processados simultaneamente. Como eles são executados na mesma instância de computação, eles compartilham memória, CPU e recursos de conexão. Em certos planos de hospedagem, a alta demanda em uma instância específica faz com que o host Functions crie automaticamente novas instâncias para lidar com o aumento da carga. Nesses planos de escala dinâmica , há uma compensação entre simultaneidade e comportamentos de escala. 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: Pode-se configurar limites de simultaneidade ao nível do host que são específicos para gatilhos individuais. Este modelo é o comportamento de simultaneidade padrão para Funções.
- Simultaneidade dinâmica: para determinados tipos de gatilho, o host Functions pode determinar automaticamente o melhor nível de simultaneidade para esse gatilho em seu aplicativo de função. Você deve optar por este 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. A análise também compara os modelos de concorrência fixa por instâncias e dinâmica.
Dimensionamento versus concorrência
Para funções que usam gatilhos baseados em eventos 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, deve ser capaz de escalar a sua aplicação de função adicionando instâncias para evitar um atraso no processamento de pedidos recebidos. A forma como dimensionamos a sua aplicação depende do seu plano de alojamento:
| Tipo de escala | Planos de hospedagem | Description |
|---|---|---|
| Dimensionamento dinâmico (orientado a eventos) |
Consumo Consumo Flexível Prémio |
Em um plano de escala dinâmica, o host dimensiona o número de instâncias de aplicativo de função para cima ou para baixo com base no número de eventos de entrada. Para obter mais informações, consulte Dimensionamento controlado por eventos no Azure Functions. |
| Dimensionamento manual | Planos dedicados (Serviço de Aplicativo) | Ao hospedar seu aplicativo de função 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ção 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 impactam diretamente as decisões de escala. Por exemplo, quando um aplicativo em um plano de escala dinâmica atinge um limite de simultaneidade, ele pode precisar ser dimensionado para acompanhar a demanda de entrada.
O equilíbrio de escala versus simultaneidade que você tenta alcançar em seu aplicativo depende de onde os gargalos podem ocorrer: 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 oferece suporte a um modelo de configuração de simultaneidade fixo por instância através de dimensionamento orientado a alvo. Neste 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, configura as definições de simultaneidade no arquivo host.json. Por exemplo, o Azure Service Bus Trigger fornece tanto uma configuração de MaxConcurrentCalls quanto de MaxConcurrentSessions no host.json. Essas configurações funcionam juntas para controlar o número máximo de mensagens que cada aplicativo de função processa simultaneamente em cada instância.
Em determinados cenários de dimensionamento baseado 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, não no arquivo host.json . Outros tipos de gatilho têm mecanismos internos para invocações de balanceamento de carga entre 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 suportam 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 a sua função consome muitas CPUs ou recursos, pode optar por limitar a simultaneidade para manter as instâncias saudáveis. Nesse caso, você pode confiar no dimensionamento para lidar com cargas maiores. Da mesma forma, quando a sua função faz solicitações para um serviço a jusante que está a ser limitado, deve-se considerar também limitar a concorrência para evitar sobrecarregar o serviço a jusante.
Simultaneidade de gatilho HTTP
Aplica-se apenas ao plano Flex Consumption
A concorrência do disparador HTTP é um tipo especial de concorrência fixa por instância. Na simultaneidade de gatilho HTTP, a simultaneidade padrão também depende do tamanho da instância.
O plano Flex Consumption dimensiona todas as funções de gatilho HTTP juntas como um grupo. Para obter mais informações, consulte Dimensionamento 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 da simultaneidade HTTP reduz o número de instâncias necessárias para lidar com solicitações HTTP. Da mesma forma, diminuir o valor da simultaneidade HTTP requer mais instâncias para lidar com a mesma carga.
Se você precisar ajustar a simultaneidade HTTP, poderá fazê-lo 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 é mantido apesar das alterações no tamanho da instância.
Determinar a concorrência fixa ótima por instância
As configurações de simultaneidade fixas por instância oferecem controle de 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. Geralmente, você tem que 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 dos 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ção pode processar cargas de mensagens exigentes no último dia da semana, o que exige que você diminua a simultaneidade. No entanto, durante o resto da semana, as cargas úteis das mensagens podem ser mais leves, o que significa que pode usar um nível de simultaneidade mais alto durante esse período.
Idealmente, o sistema deve permitir que as instâncias processem o máximo de trabalho possível, mantendo cada instância íntegra e as latências baixas. A simultaneidade dinâmica é concebida para esse objetivo.
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ção executados no mesmo plano.
Nota
Atualmente, a simultaneidade dinâmica só tem suporte para os gatilhos Armazenamento de Blob 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 em Suporte de extensão, mais adiante neste artigo.
Benefícios
A simultaneidade dinâmica oferece os seguintes benefícios:
- Configuração simplificada: não é mais necessário determinar manualmente as configurações de simultaneidade por gatilho. O sistema aprende os valores ideais para a sua carga de trabalho ao longo do tempo.
- Ajustes dinâmicos: A simultaneidade é ajustada dinamicamente para cima ou para baixo em tempo real, o que permite que o sistema se adapte às mudanças nos padrões de carga ao longo do tempo.
- Proteção de integridade da instância: o tempo de execução limita a simultaneidade a níveis que uma instância de aplicativo de função pode lidar confortavelmente. Esses limites protegem a aplicação de se sobrecarregar, ao assumir mais trabalho do que deveria.
- Taxa de transferência aprimorada: a taxa de transferência geral é melhorada, porque as instâncias individuais não recebem mais trabalho do que podem processar rapidamente. Como resultado, o trabalho é balanceado de forma mais eficaz entre as 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 vinculação que suportam esse recurso são ajustados automaticamente conforme necessário. Nesses casos, as configurações de simultaneidade dinâmica substituem quaisquer configurações de simultaneidade configuradas manualmente.
Por padrão, a simultaneidade dinâmica está desativada. Quando ativa a simultaneidade dinâmica, esta começa ao nível de um por 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ção adicionando as seguintes configurações ao seu 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 armazenados. Novas instâncias começam a partir desses valores, em vez de partir de um nível inicial e ter que reiniciar o processo de aprendizagem.
Gestor de simultaneidade
Nos bastidores, quando a simultaneidade dinâmica é ativada, um processo de gerenciamento de simultaneidade é executado em segundo plano. Esse gerenciador monitora constantemente as métricas de integridade da instância, como a utilização da CPU e do thread, e altera as limitações conforme necessário. Quando um ou mais aceleradores são ligados, a simultaneidade da função é ajustada para baixo até que o host esteja íntegro novamente. Quando os aceleradores estão desligados, a simultaneidade pode aumentar. Várias heurísticas são usadas para ajustar inteligentemente a simultaneidade para cima ou para baixo, conforme necessário, com base nesses aceleradores. Com o tempo, a simultaneidade para cada função estabiliza a um nível específico. Como pode levar tempo para determinar o valor de simultaneidade ideal, use a simultaneidade dinâmica somente se um valor subótimo for aceitável para sua solução inicialmente ou após um período de inatividade.
Os níveis de simultaneidade são gerenciados para cada função individual. Especificamente, o sistema se equilibra entre funções que consomem muitos recursos que exigem um baixo nível de simultaneidade e funções mais leves que podem lidar com simultaneidade mais alta. O equilíbrio de concorrência para cada função ajuda a manter a integridade geral da instância do aplicativo de função.
Quando a simultaneidade dinâmica está ativada, você encontra decisões de simultaneidade dinâmica em seus logs. Por exemplo, as entradas de log são adicionadas quando vários aceleradores são ativados 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 de extensão
A simultaneidade dinâmica está habilitada para um aplicativo de função no nível do host e todas as extensões que suportam 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 seguintes extensões suportam simultaneidade dinâmica.
| Extensão | Versão | Description |
|---|---|---|
| Armazenamento em Fila | Versão 5.x (extensão de armazenamento) | O gatilho de armazenamento de fila tem o seu próprio ciclo de consulta de mensagens. Quando utiliza 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, de modo que o número de mensagens recuperadas por iteração é ajustado dinamicamente. Quando os reguladores estão ativados, o host fica sobrecarregado. O processamento de mensagens é pausado até que os aceleradores sejam desligados. Quando os controlos de velocidade são desligados, a concorrência aumenta. |
| Armazenamento de Blobs | Versão 5.x (extensão de armazenamento) | Internamente, o disparador de Armazenamento de Blobs utiliza a mesma infraestrutura que o disparador 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 em Fila. Quando a simultaneidade dinâmica está ativada, a simultaneidade para o processamento dessa fila de controle é gerenciada dinamicamente. |
| Barramento de Serviço | Versão 5.x | Atualmente, o gatilho do Service Bus oferece suporte a três modelos de execução. A simultaneidade dinâmica afeta esses modelos de execução das seguintes maneiras:MaxConcurrentCalls gere a simultaneidade. Quando você usa simultaneidade dinâmica, esse valor de configuração é ignorado e a simultaneidade é ajustada dinamicamente.MaxConcurrentSessions concorrência. 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 configuração. Como as invocações em lote são seriais, a simultaneidade para sua função acionada em lote é sempre uma só, e a simultaneidade dinâmica não se aplica. |
Próximos passos
Para obter mais informações, consulte os seguintes recursos: