Problemas e limitações

O Cloud Tasks permite criar sistemas assíncronos resilientes ao projetar para comportamentos específicos de execução de fila e limites de serviço. É possível evitar gargalos de processamento e atrasos inesperados considerando a entrega pelo menos uma vez, a limitação do sistema e a capacidade do recurso de destino.

Ordem de execução

Com exceção das tarefas programadas para serem executadas no futuro, as filas de tarefas são completamente independentes da plataforma em relação à ordem de execução. Não há garantias nem tentativas de executar tarefas em uma ordem específica. Especificamente: não há garantias de que as tarefas antigas serão executadas, a menos que uma fila seja completamente esvaziada. Há vários casos comuns em que tarefas mais recentes são executadas antes das mais antigas, e os padrões relacionados a isso podem mudar sem aviso prévio.

Atraso na execução

As execuções do Cloud Tasks podem, ocasionalmente, sofrer pequenos atrasos, geralmente de alguns minutos, devido a reinicializações internas do sistema. As tarefas são atrasadas, mas nenhuma é perdida. Esses são eventos no nível do sistema sem solução alternativa. Esses eventos não são registrados, e a ocorrência deles não tem uma linha do tempo definida.

Execução duplicada

O Cloud Tasks visa uma semântica estrita de "executar exatamente uma vez". No entanto, em situações em que é preciso fazer uma compensação de design entre a execução garantida e a execução duplicada, o serviço prioriza a execução garantida. Assim, o número de execuções duplicadas não é zero. Verifique se o app lida com execuções duplicadas de maneira adequada para que elas não causem falhas inesperadas. Na produção, mais de 99,999% das tarefas são executadas apenas uma vez.

Limitações de recursos

A causa mais comum de atrasos em filas de processamento imediato é o esgotamento de recursos nas instâncias de destino. Se você tentar executar 100 tarefas por segundo em instâncias de front-end que só podem processar 10 solicitações por segundo, um backlog será criado. Isso geralmente se manifesta de duas maneiras, que podem ser resolvidas aumentando o número de instâncias que processam solicitações.

Erros de retirada e taxas impostas

Servidores sobrecarregados podem começar a retornar erros de espera: HTTP 503 (para destinos do App Engine) ou HTTP 429 ou 5xx (para destinos externos). O Cloud Tasks reage a esses erros diminuindo a velocidade da execução até que os erros parem. Essa limitação do sistema impede que o worker seja sobrecarregado. Suas configurações não são alteradas.

A limitação do sistema acontece nas seguintes circunstâncias:

• O Cloud Tasks faz o back-off em todos os erros. Normalmente, o Cloud Tasks usa a espera especificada em retry_config. No entanto, se o worker retornar respostas de erro HTTP 429 Too Many Requests, 503 Service Unavailable ou 5xx, ou se a taxa de erros for alta, o Cloud Tasks vai aplicar uma taxa de envio menor e considerar o atraso de nova tentativa especificado no cabeçalho de resposta HTTP Retry-After. Depois que os erros param e os gerenciadores de destino retornam respostas HTTP 2xx, a fila aumenta gradualmente a taxa de envio aplicada.

• Para evitar picos de tráfego e suavizar aumentos repentinos de carga, o Cloud Tasks aumenta gradualmente os envios quando uma fila é criada, retomada após ser pausada ou fica inativa após alguns minutos sem envios ativos. Esse aumento também ocorre quando um grande número de tarefas fica disponível para envio, como durante picos de criação de tarefas ou quando muitas tarefas são programadas para o mesmo horário. A partir de um estado frio ou ocioso, o Cloud Tasks começa a enviar a uma taxa de referência baixa e aumenta progressivamente a taxa de envio aplicada em intervalos de avaliação periódicos. A taxa continua aumentando em direção à taxa max_dispatches_per_second configurada, desde que a demanda da fila permaneça saturada e os gerenciadores de destino retornem respostas HTTP 2xx. Para mais informações sobre o aumento gradual frio ou inativo e o gerenciamento de filas retomadas, consulte Aumento gradual inicial da fila e Sobrecarga de destino.

Picos de latência e número máximo de tarefas concorrentes

Servidores sobrecarregados também podem responder com grandes aumentos de latência. Nessa situação, as solicitações permanecem abertas por mais tempo. As tarefas podem não ser executadas na taxa esperada porque as filas têm um número máximo de tarefas simultâneas. Aumentar o valor de max_concurrent_dispatches para as filas afetadas pode ajudar em situações em que o valor foi definido como muito baixo, introduzindo uma limitação de taxa artificial. No entanto, aumentar max_concurrent_dispatches provavelmente não vai aliviar a pressão de recursos subjacente.

Problemas de aumento gradual com tarefas de longa duração

As filas de tarefas do Cloud Tasks aumentam a saída em parte com base no número de tarefas enviadas anteriormente com sucesso. Se o gerenciador de tarefas levar um período considerável (na ordem de minutos) para concluir uma tarefa e retornar uma resposta de sucesso, poderá haver um atraso na taxa de aumento da fila.

Visualizar mais de 5.000 tarefas

Se você tiver mais de 5.000 tarefas, algumas não vão aparecer no console doGoogle Cloud . Use a CLI gcloud para ver todas as tarefas.

Métrica de profundidade máxima da fila informada

A métrica de profundidade máxima da fila informada pelo Cloud Tasks é limitada a 1.000.000 de tarefas. Isso melhora o desempenho dos workers de tarefas subjacentes, e não há impacto no número de tarefas que podem ser enviadas ou processadas pela fila. As tarefas enviadas para a fila acima do limite de profundidade continuam sendo executadas normalmente.

Para buscar a profundidade atual da fila além de 1.000.000 de tarefas, use o método queues.tasks.list. Esse método retorna todas as tarefas com paginação, permitindo agregar os dados e realizar uma operação de contagem. No entanto, dependendo do tamanho da profundidade da fila, o método pode encontrar restrições de cota.

Como recriar uma fila com o mesmo nome

Excluir uma fila remove de forma permanente e irreversível todas as tarefas dela, incluindo as programadas e as que estão aguardando execução ou nova tentativa. Nem você nem o Cloud Customer Care podem recuperar filas ou tarefas excluídas.

Depois de excluir uma fila, aguarde três dias antes de recriá-la com o mesmo nome. Esse período de espera evita comportamentos inesperados em tarefas que estão sendo executadas no momento da exclusão e evita falhas de processo interno durante o ciclo de exclusão e recriação. O período de espera se aplica a filas excluídas por qualquer interface, incluindo o Google Cloud console, a CLI gcloud, a API REST ou RPC ou o Terraform.

Durante essa janela de tombstone de até três dias, uma solicitação de criação de fila pode parecer bem-sucedida sem recriar a fila, e o upload de um arquivo queue.yaml que inclui o nome da fila excluída pode falhar. Para confirmar que uma fila com o mesmo nome foi recriada, recupere-a usando o comando gcloud tasks queues describe ou o método projects.locations.queues.get. Uma resposta bem-sucedida (200 OK) confirma que a fila foi recriada.

Para limpar tarefas ou modificar uma fila sem perder a fila ou acionar o período de espera de três dias, limpe todas as tarefas da fila, atualize a fila no local ou pause a fila em vez de excluí-la e recriá-la. Se você gerencia filas com o Terraform, defina prevent_destroy = true no bloco lifecycle para evitar a exclusão acidental de filas.

Destino não compatível ao usar um perímetro seguro

Se você tiver configurado um perímetro seguro usando o VPC Service Controls, as solicitações HTTP de uma execução do Cloud Tasks serão bloqueadas para destinos não compatíveis e falharão com um código de erro TARGET_TYPE_NOT_PERMITTED_FOR_VPC. Para mais informações, consulte Configurar um perímetro de serviço usando o VPC Service Controls.

Restrições de locais de recursos

O Cloud Tasks é compatível com a restrição de locais de recursos. No entanto, há limitações nas seguintes regiões:

• us-central1
• us-central2 (região Google Cloud particular)

Se você especificar uma região na política da organização, inclua us-central1 e us-central2, mesmo que não esteja criando recursos do Cloud Tasks nas duas regiões. É possível incluir a região us-central2 na política da organização, mesmo que ela não use regiões particulares.