Nesta página, apresentamos as práticas recomendadas para teste de carga do serviço do Cloud Run para determinar se ele é escalonado durante o uso em produção e encontrar gargalos que impeçam o escalonamento.
Testes anteriores ao teste de carga
Identifique e resolva problemas de simultaneidade em um pequeno ambiente de teste ou desenvolvimento antes de continuar o teste de carga. Meça a simultaneidade de contêineres antes de realizar um teste de carga e verifique se o serviço do Cloud Run inicia de maneira confiável.
Concentre os testes de contêiner em pequenas contagens incrementais em execuções escalonadas manualmente. É possível aproximar o escalonamento manual no Cloud Run ao definir o máximo de instâncias como o valor até o qual você quer escalonar.
Se você criou ou alterou a imagem do contêiner recentemente, teste isso de maneira independente antes de executar um teste de carga.
Você também precisa verificar outros tipos de problemas de desempenho, como latência excessiva e uso da CPU, antes de executar um teste de carga em grande escala.
Usar max instances de forma adequada
O Cloud Run aplica o máximo de instâncias para limitar o escalonamento de um serviço. O número máximo padrão de instâncias é 100. Se você acha que o teste de carga pode exceder esse padrão, trabalhe com a equipe de conta do Google e defina um novo valor máximo. Se você ainda não tiver um relacionamento com uma equipe de conta, entre em contato com a equipe de vendas do Google Cloud.
O número máximo de instâncias que pode ser selecionado depende dos limites de CPU e limites de memória, bem como da região de implantação.
Esses limites são gerenciados por um limite de cota e podem aumentar mediante uma solicitação de aumento de limite de cota.
Teste de carga na região us-central1
A região us-central1 do Google Cloud oferece um limite de cota alto, portanto, o Google
recomenda o teste de carga em us-central1. Trabalhe com sua equipe de conta
e envie um caso de suporte com detalhes sobre o horário e a escala do teste,
se você espera se aproximar dos limites de cota.
Testar o uso apropriado da CPU e o perfil de inicialização do serviço
Em um cenário ideal, você implanta uma versão de teste do serviço no Cloud Run e a carrega de forma direta. No entanto, em alguns casos, talvez você não consiga implantar uma versão de teste do seu serviço. Por exemplo, seu serviço do Cloud Run pode fazer parte de um ecossistema complexo que é difícil de replicar em um ambiente de teste.
Nesses casos, é possível aproximar o desempenho do serviço simulando-o
com um serviço mais simples que tem uso de CPU e tempos de inicialização comparáveis.
O tempo de inicialização é especialmente importante para o escalonamento rápido. Tenha em mente que
testar com algo muito simples também é problemático. Por exemplo, evite testar com um
serviço hello world simples que retorna solicitações recebidas sem nenhum processamento.
Usar um arcabouço de testes para gerar cargas
É possível gerar cargas de teste através de um pico de tráfego controlado usando um arcabouço de testes, como o JMeter. É possível usar os grupos de linhas de execução do JMeter e o atraso entre as solicitações de teste do JMeter para aumentar a carga.
Também é possível enviar solicitações HTTP simples ou gravar uma sessão do navegador com o JMeter. O Cloud Run permite testar o serviço sem acesso à internet, pela autenticação do desenvolvedor. Isso permite o acesso por um arcabouço de testes, como o JMeter, em execução em uma máquina virtual do Compute Engine conectada a uma nuvem privada virtual associada ao projeto.
Não gere carga de ferramentas em que a taxa e a simultaneidade não podem ser controladas. O Pub/Sub é uma opção ruim de ferramenta para gerar carga, porque não é possível controlar a taxa de tráfego e o número de clientes. Se você não souber a taxa e a simultaneidade, não saberá o que está testando.
Usar a análise de registro detalhada através de registros exportados
Você precisa de uma análise segundo-a-segundo dos eventos para entender a resposta do serviço do Cloud Run aos picos de tráfego rápidos. A análise de registro é necessária para isso, porque a granularidade dos dados de monitoramento não é detalhada de forma suficiente. A análise de registros também permite investigar os motivos das solicitações com alto latência.
Ao gravar registros, é possível melhorar o desempenho de geração de registros pela gravação direta
em stdout em vez de usar uma biblioteca de cliente do Cloud Logging.
Para configurar uma exportação de registro antes de iniciar o teste, crie um coletor de registros com o BigQuery de destino e um filtro de inclusão, como:
resource.type="cloud_run_revision"
resource.labels.service_name="[your app]"
Evitar inicializações a frio falsas
Para minimizar as inicializações a frio vivenciadas pelos usuários, defina o número mínimo de instâncias como pelo menos 1.
Garantir que o serviço seja escalonado de maneira linear
Repita o teste em diferentes cargas para garantir que o serviço do Cloud Run seja escalonado de maneira linear com a carga e não atinja um gargalo limitante com uma carga menor do que a esperada na produção.
Analisar e visualizar os resultados no Colab
Use os gráficos de monitoramento de resumo para entender melhor os resultados e complementar a análise de registro detalhada usando os registros exportados.
Os gráficos de monitoramento podem ajudar você a descobrir:
- Com que rapidez, no segundo mais próximo, as novas instâncias são criadas e inicializadas?
- As solicitações são distribuídas de maneira uniforme entre diferentes instâncias?
- Com que rapidez a latência em percentis diferentes pode ser reduzida para um valor de estado estável?
Use a interface do usuário do console do Google Cloud para que o BigQuery faça uma introspecção do esquema de registro exportado e visualize os resultados. Execute as consultas e indique os resultados usando o Colab, que tem integração pronta com o BigQuery, o Pandas e o Matplotlab. O Colab também se integra facilmente a ferramentas de visualização de dados avançados, como o Seaborn.
Encontrar gargalos
Os testes de carga podem ajudar você a descobrir um código ineficiente e gargalos de escalonamento. Códigos ineficientes geram custos mais altos porque precisam lidar com mais o tráfego, mas não necessariamente impedem o escalonamento. Por exemplo, uma dependência de uma conversão de banco de dados com bloqueio no nível da tabela pode ser um gargalo que impedirá o escalonamento do serviço do Cloud Run, porque apenas uma transação pode ser executada por vez.
Verificar o desempenho conforme a experiência do cliente
Consulte os registros de consulta capturados pelo JMeter, que incluem latências medidas no cliente. No entanto, como as ferramentas de teste de servidor, como JMeter, não são iguais a navegadores ou cliente móvel, é possível executar um teste com um framework baseado em navegador, como o Selenium Webdriver, ou um framework de teste de cliente móvel. Cuidado com o excesso de latências máximas causadas pela inicialização da conexão TLS que podem distorcer os resultados com outliers.
Resumo das práticas recomendadas
Execute um teste de carga para determinar se a migração para o Cloud Run é a escolha certa e se o serviço pode ser escalonado para o tráfego máximo esperado. Execute o teste com um arcabouço como o JMeter. Exporte os registros para o BigQuery para análise detalhada.