Istio — Parte 6 — Engenharia do caos

Published in

codigorefinado

4 min readSep 23, 2018

Testar a corretude de do software é um desafio importante, mas testar o mesmo software sob a estabilidade da rede é outro desafio. Um desafio é injetar ou imitar falhas de sistema em condições ruins de rede sem alterar o código da aplicação.

Esta é uma tradução livre, do original disponível no developers.redhat.com, com alguns acréscimos e adações, em que vamos ver como Istio torna os princípios da engenharia do caos mais fácil.

Quebrando requisições

Imagine que temos dois pods executando o microserviço de recomendação, rotulados com v1 e v2, abaixo uma imagem demonstra eles executando bem:

O número a direita é apenas um contador, no código da aplicação

Vamos quebrar as coisas, abaixo, o conteúdo do arquivo yaml cria uma regra de roteamento que quebra metade das requisições (50%) com um erro 503 (Server error).

Agora veja, abaixo, o retorno de uma série de chamadas ao mesmo microserviço:

Para restaurar normalidade, é possível apagar a regra de roteamento com o comando abaixo (tutorial é o nome do projeto):

istioctl delete routerule recommendation-503 -n tutorial

Delay (Atrasos)

Testar como nossa aplicação lida com erros do servidor (503) torna nossa aplicação mais rousta, mas é ainda mais impressionante testar como ela lida com lentidão, ou atrasos na rede, problema que é provávelmente mais comum.

Note que depois de testar sua aplicação, contra situações em que há latencia na rede, provávelmente será necessário alteração no código, provávelmente aderindo a programação reativa.

Observe no exemplo abaixo que, estamos acrescentando um atraso de 7 segundos em 50% das requisições, sem alterar o código fonte da aplicação.

Desde o momento em que o Jaeger Tracing tornou-se suportado, nós podemos ver o efeito deste atraso de forma vizual.

Nunca desista

Outro ponto relacionado a engenharia do caos é a habilidade de retentar. A idéia por de trás, é que ao obter um erro, se retentar talvez funcione. Para ver isto funcionando, vamos utilizar a configuração que retorna 503 em 50% das requisições.

Agora podemos introduzir a configuração para retentar, o exemplo irá esperar dois segundos para rententar, e fará isto por até 3 vezes na esperança e eliminar o erro 503:

Nunca deixe cair

Istio nos permite configurar tempo e timeout, um 504 (Gateway timeout). Para este teste, iremos adicionar um tempo de espera no código, afim de forçar uma situação em que a aplicação é lenta. Após isto, podemos configurar o Istio com a seguinte regra de roteamento:

Na regra acima, podemos ver que após 1 segundo, será retornado um erro 504. Então, podemos ver:

Qual o valor destes recursos?

Com ele você pode testar sua aplicação mais apropriadamente, simulando situações reais do ambiente de produção, inclusive simulando o acesso a internet do seu cliente.

Isto ajudará a tornar a aplicação mais robusta, resiliente a falhas ocilações que são difíceis, se não impossíveis de prever.