Rally, do benchmarking ao aperfeiçoamento contínuo

Para manter um nível de qualidade elevado e continuar a melhorar os nossos produtos, temos de ser capazes de definir e medir essa qualidade, detetar as suas variações e investigar em caso de degradação.

Com esse objetivo em mente, identificámos no OpenStack (a solução sobre a qual se construiu a nossa oferta de Public Cloud) dois pontos importantes que nos parecem essenciais do ponto de vista do cliente:

  • a utilização da API OpenStack através dos clientes OpenStack, de bibliotecas ou da API v6 da OVH;
  • a garantia do bom desempenho das instâncias (processador, RAM, disco, rede).

Este artigo centra-se no primeiro ponto: a forma como a OVH mede o desempenho das API Public Cloud. Começarei por apresentar a solução que implementámos e a forma como ela se integra no ecossistema da OVH. Vou concluir com um caso concreto, que mostra como pudemos melhorar o tempo de resposta de certas consultas API em até 75%.

 

Rally: a ferramenta de benchmarking do OpenStack orientada para o cliente

O Rally é uma componente do projeto OpenStack e define-se como uma solução de “Benchmarking as a Service”. O seu papel é testar uma plataforma OpenStack do ponto de vista do cliente e extrair dela medições dos tempos de execução.

O projeto, desenvolvido em Python, foi iniciado em 2013. A versão 1.0.0 foi lançada em julho de 2018. A escolha da OVH de utilizar este projeto foi relativamente fácil, na medida em que ele faz parte do ecossistema de OpenStack e fornece funcionalidades que respondiam às nossas necessidades.

O Rally oferece a execução de cenários, os quais são conjuntos de testes sequenciais configuráveis, de maior ou menor complexidade. Assim, é possível, por exemplo, testar simplesmente a criação de um token de autenticação e validar o seu funcionamento. São também realizáveis outras manipulações mais complexas: testar num só cenário a autenticação e a criação de várias instâncias associando-lhes volumes. Esta flexibilidade permite-nos imaginar, de forma fácil e sem limites, testes bastante específicos. O Rally fornece nativamente um lote completo de cenários classificados segundo componentes funcionais (Nova, Neutron, Keystone, Glance, por exemplo).

Além disso, mede os tempos de resposta a cada etapa do cenário e na sua globalidade. Os dados são guardados em bases de dados e podem ser exportados em forma de relatórios HTML ou JSON. A ferramenta é capaz de iterar um mesmo cenário um certo número de vezes e de calcular os valores médios, bem como outras estatísticas (mediana, percentil 90, percentil 95, mínimo, máximo) por cada iteração e para todas elas no seu conjunto.

relatório rally

Relatório de teste de Rally gerado em HTML

O Rally também suporta a noção de Service Level Agreement (SLA), isto é, a possibilidade de definir uma taxa de erro aceitável quanto ao número de iterações de modo a avaliar se o teste geral foi bem-sucedido.

Um outro aspeto que nos seduziu neste projeto foi a possibilidade de executar os testes enquanto cliente final, sem ter o papel de administrador. Assim, podemos pôr-nos perfeitamente no lugar dos nossos clientes Public Cloud.

 

Casos práticos

Medição de desempenho

A nossa necessidade inicial é qualificar a API de uma plataforma existente. Portanto, executamos, várias vezes por hora, um certo número de iterações dos testes Rally para cada componente funcional do OpenStack, para todas as regiões.

Qualificação de software

Impõe-se outra utilização quando somos levados a realizar patches de código ou a efetuar atualizações de segurança ou de software. Em cada caso, sem uma ferramenta, é difícil avaliar os impactos das alterações. Podemos tomar como exemplo as atualizações do kernel relativas às últimas falhas de segurança (Spectre e Meltdown), anunciadas como indutoras de uma deterioração dos desempenhos. O Rally permite-nos agora avaliar facilmente os eventuais impactos.

Qualificação de hardware

Também podemos querer testar uma nova gama de servidores físicos a ser utilizados no “Control Plane” do OpenStack. O Rally permite-nos verificar se há uma variação de desempenho.

 

Medir é bom, mas...

Não podemos esquecer que é preciso visualizar a evolução dos tempos de resposta ao longo do tempo. O Rally pode fornecer um relatório em HTML sobre a execução de um cenário quanto a um período muito curto. No entanto, mostra-se incapaz de agregar os relatórios de todas as suas execuções.

Assim, precisávamos de um meio de extrair os dados dos relatórios de execução e de os resumir sob a forma de um gráfico. É aqui que entra em cena a nossa plataforma de métricas interna, baseada em Warp10 para o armazenamento e em Grafana para os painéis de controlo.

Utilizámos a função de exportação JSON, implementada no Rally, para extrair os valores medidos durante os testes e os introduzir na plataforma de métricas. De seguida, criámos um painel de controlo que nos permite visualizar estes tempos de resposta ao longo do tempo, relativamente a cada teste e a cada região. Assim, podemos visualizar facilmente a sua evolução no tempo e comparar os tempos de resposta por região. Em regiões próximas umas das outras (em França, por exemplo: GRA, RBX e SBG), devemos obter sensivelmente os mesmos tempos de resposta. Se não for o caso, procuramos a origem da diferença para corrigir o problema.

dashboard rally

Painel de controlo interno com a agregação dos resultados dos testes Rally

 

Caso de estudo concreto

Depois de preparar todos os componentes, comparámos a evolução dos tempos de resposta entre as diferentes regiões. Apercebemo-nos de que, ao longo do tempo e em certas regiões, os desempenhos se degradavam quanto a testes específicos do nosso projeto. A título de exemplo, há um teste que consiste em listar o conjunto das instâncias do projeto Rally: o tempo médio verificado é de 600 ms, ao passo que em certas regiões atingimos os 3 segundos.

Começámos por analisar se o problema se referia apenas ao nosso projeto e não a todos os clientes, o que era efetivamente o caso.

Após uma pesquisa mais aprofundada, descobrimos que o ponto de estrangulamento se situava ao nível da base de dados da versão Juno do OpenStack. De facto, o OpenStack pratica o soft delete quando elimina dados. Isto significa que marca os dados como eliminados, sem os apagar realmente da tabela. Neste caso, a tabela “instances” é composta, por exemplo, por uma coluna “project_id” e “deleted. Quando o Rally lista os servidores do projeto, a pesquisa é do tipo:

SELECT * FROM instances WHERE project_id=’xxx’ AND deleted = 0;

Infelizmente, nas versões Juno do OpenStack, não existe um índice (“project_ id”, “deleted”) nesta tabela, contrariamente ao que acontece na versão Newton do OpenStack. Para o projeto Rally, os testes lançam cerca de 3000 novas instâncias todos os dias em cada região. Ao fim de 3 meses, tínhamos 270 000 instâncias em soft delete nas nossas bases de dados. Esta importante quantidade de dados nas nossas bases de dados, associada à falta de índices na tabela, explica as latências que constatámos em certas regiões (apenas aquelas com versão Juno).

Portanto, a nossa ação corretiva foi implementar nos nossos projetos internos um mecanismo de eliminação definitiva dos dados marcados como soft delete. O resultado fez-se sentir imediatamente, dividindo por quatro o tempo de resposta no teste que consiste em listar os servidores do projeto Rally.

caso prático

Melhoramento significativo dos tempos de resposta numa região Juno para o projeto Rally

Neste caso específico, vamos implementar, para os clientes que possam ser afetados pelos mesmos problemas, uma arquivação automática dos dados soft deleted nas tabelas ocultas do OpenStack previstas para este efeito.

Graças a esta ferramenta de benchmarking, estamos agora em condições de evidenciar anomalias entre regiões que acarretam uma diferença de experiência para o utilizador. Assim, podemos aplicar as soluções necessárias para eliminar tais disparidades, de modo a obter a melhor experiência possível para os utilizadores em regiões próximas umas das outras. Com esta ferramenta, entramos naturalmente num processo de aperfeiçoamento contínuo para manter e aumentar a qualidade de utilização das nossas API OpenStack.