search

pedrofgd / api-rest-broker

Projeto TCC Mack para avaliação de uma proposta de Broker para garantir alta disponibilidade no consumo de recursos externos via API REST
1 stars 0 forks source link

Definição da metodologia de testes #8

Closed pedrofgd closed 1 year ago

pedrofgd commented 1 year ago

Existe um pacote no npm chamado "cep-promise", que serve para fazer consultas a diferentes provedores de CEP e é Open Source: https://github.com/BrasilAPI/cep-promise. O pacote tem, em média, mais de 10k downloads por semana no NPM.

Esse pacote é utilizado pela BrasilAPI (aqui um exemplo de como eles usam).

O que o pacote faz é bem parecido com a nossa proposta:

Nós nos diferenciamos pelo monitoramento ativo que queremos fazer. Ao invés de chamar sempre na mesma ordem, nós atualizando a informação de provedor mais disponível quando for necessário.

Podemos rodar esse pacote chamando provedores fake e comparar os resultados com os nossos:

  1. Criar 4 provedores fake para retornar dados de um CEP (gerar dados aleatórios e aguardar uma quantidade aleatória de milissegundos, tentando simular a latência real da chamada a API) e configurados para falhar periodicamente (a cada 100 requisições feitas, retorna 2 erros, por exemplo)
  2. Fazer o clone do pacote "cep-promise" e modificá-lo para utilizar os provedores fake ao invés dos reais
  3. Cadastrar os provedores fake no nosso Broker
  4. Rodar uma bateria de testes utilizado o "cep-promise" e o nosso Broker e comparar os resultados, como: latência adicionada, quantidade de erros retornados ao cliente comparado ao número de falhas nos provedores...

No relatório final, podemos colocar, além dos resultados individuais do Broker (como já havíamos imaginado), os gráficos comparando as duas ferramentas. Os gráficos podem ser utilizando Prometheus + Grafana (semelhante ao que esse cara faz)

Para seguir com essa estratégia:

pedrofgd commented 1 year ago

Além de testar a comparação com o "cep-promise", devemos fazer testes para determinar a velocidade com que o sistema proposto reage a uma falha no provedor: "quando um provedor se apresenta indisponível (ultrapassou os limites de critérios definidos pelo Cliente), quantas requisições são enviadas para ele até que seja feita a troca?"

Podemos configurar o Broker para tolerar um error budget de 1 falha e configurar os provedores fake para retornarem erro a cada X requisições. No Broker validamos a partir de quantas requisições o próximo provedor passou a ser acionado. Por exemplo, a cada 1000 requisições o provedor A retorna erro. No Broker, o ideal é que a requisição de número 1001 já seja direcionada ao provedor B.

pedrofgd commented 1 year ago

Task: https://github.com/users/pedrofgd/projects/4?pane=issue&itemId=25239540

@ClaudioSiqueira @lucas-ye @An-225 podem ajudar?

pedrofgd commented 1 year ago

Vou fechar e discutimos os cenários de teste em detalhes em outra issue