Um dos problemas que percebi com o Kong no docker é que em alguns momentos, principalmente na primeira requisição a ele, encontrei um delay de pontuais 20s. Como estava também usando-o para cache, suspeitei do plugin e estava errado.
A intenção do post é evitar que você também passe por isso.
Aqui no eShop Cloud Native, projeto que, aliás, apresentei ontem no Canal .NET, eu estava com uma pendência há meses.
Se você reparar vai ver que sempre que eu iniciava o kong novamente ele dava umas engasgadas de eternos 20 segundos.
Isso acontecia na primeira requisição e em requisições após X minutos. Não medi com clareza quantos minutos eram necessários até perceber novamente o problema. Mas algo entre 3 e 5 minutos.
Então, independente da inatividade, se eu continuasse usando por 5 minutos, hora ou outra percebia novamente o maldito delay.
Estava claro que era o Kong porque o fluxo é:
Web App MVC -> Kong -> API
Assim, em outro momento, já havia reconfigurado a stack para não passar por ele, fazendo a aplicação MVC chegar diretamente na API e o problema nunca aparecia.
A questão é:
Não há log que sinalize problema algum. O Kong não deixa de completar a requisição, portanto não há um erro, embora encontremos um comportamento indesejado.
O sintoma é que esses requests mais lentos, que ocorrem ocasionalmente, levam exatos 20s, nunca ultrapassando 20.5s.
Com base nas métricas que produzo aqui com o Enterprise Application Log, o tempo médio estava em 114ms, enquanto a mediana estava em 066ms.
Nenhuma requisição interna ultrapassava 557ms.
Com base nessa informações, tudo sugeriu que esses 20.XXX segundos, se tratassem de:
20 segundos de delay
Mais a execução normal de algo depois desse delay.
Não precisei buscar muito recorrer ao pai dos burros e encontrar a resposta em discussões no github.
Issues relacionadas
Upstream targets go unhealthy every few seconds #3641 https://github.com/Kong/kong/issues/3641
Large DNS delay for APIs on internal docker networks #3058 https://github.com/Kong/kong/issues/3058
O problema consiste na configuração de DNS, mais especificamente na sequência de tipos de registros a serem avaliados. Entre os vários tipos de registros disponíveis nos DNS’s, o kong adotava a seguinte ordem: LAST,SRV,A,CNAME, como mostra a imagem abaixo.
E era exatamente a entrada SRV (de serviço) que gerava esse delay, 20s é o timeout da estratégia.
A solução foi remover o SRV, como recomendado nas issues.
Para o Kong, eu criei um dockerfile, coisa que não existia para ele aqui até então.
FROM kong:3.0.0-alpine COPY ./kong.yml / USER root RUN cp /etc/kong/kong.conf.default /etc/kong/kong.conf && echo 'dns_order=LAST,A,CNAME' >> /etc/kong/kong.conf USER kong
E por fim atualizei nosso diagrama de Ação/Reação para apresentar, finalmente, a solução para o dilema.
0 comentários