Dec 8, 10:00 GMT-02:00

A AWS nos retornou com a métrica que indicou problema no servidor de cache de memória no episódio (a métrica é EVICTIONS). Colocamos um alarme para que uma degradação desta métrica possa executar um lambda que retomará o serviço ao seu estado normal, sem precisar da intervenção do nosso time.

Além disto, identificamos que alguns elementos do sistema usavam erroneamente o mesmo servidor da session para cacheamento. Ao separar o cacheamento e session, garantimos que o serviço mais crítico, que é o de session, consiga trabalhar com um número muito maior de requisições. Desta forma dimensionaremos o serviços para que o servidor suporte 100 vezes mais requisições que a nossa média em horário comercial. O maior pico de acesso até hoje medido foi 10x a nossa média.

Lembrando que assim como servidores de banco de dados SQL, não conseguimos criar um ambiente 100% escalável para session, por causa própria natureza de como a session funciona.

Dec 7, 16:29 GMT-02:00

O Superlógica armazena as sessões do servidor web (session) em um servidor de cache em memória chamado Memcached, que é gerenciado pela AWS.

No dia 4 de dezembro houve muito tráfego, mais de 5 vezes o fluxo normal, provocando neste servidor uma performance degradada.

Por se tratar de um componente central da nossa infraestrutura, todo sistema ficou lento. O diagnóstico pelo nosso time técnico ficou comprometido, atrasando sua resolução, já que, nas métricas e alarmes fornecidos pela AWS, o serviço de cache aparentava estar operando normalmente e sem sobrecarga.

O problema foi potencializado por conta de um volume de sessions abertas em excesso - uma session é aberta a cada solicitação de boletos ou acesso ao site do cliente, aluno ou condômino.

Se eliminarmos a abertura de session nesta parte do sistema, sem perder nenhuma funcionalidade, vamos ter uma redução drástica estimada em pelo menos 50% do número de leitura e escritas ao referido servidor. Estamos desenvolvendo estas melhorias no momento, com prazo de 15 dias.

Além de reduzir o número de sessions, estamos investigando com a AWS os motivos pelos quais o servidor de cache de memória apresentou problema mesmo com todas as métricas demonstrando o contrário. Os recursos de memória e processamento estavam em 40% e 10%, respectivamente, o que claramente indica que o servidor estava com uma carga inferior ao seu potencial.

Assim, entendendo qual foi o limite atingido e por que o Memcached apresentou degradação de performance, conseguiremos nos antecipar ao aumento de demanda e, em último caso, na hipótese deste serviço apresentar problema futuramente, substitui-lo em aproximadamente 3 min.

Também estamos testando a performance entre as duas opções disponíveis de servidor de session - Memcached e Redis - para descobrirmos qual das duas é mais adequada para o nosso ambiente e escala.