Uma correção das falhas de seguranças Meltdown(1) e Spectre, que afeta processadores de computadores produzidos nos últimos 20 anos, deixou nossos servidores mais lentos.
A correção foi compulsoriamente aplicada pelo nosso fornecedor de serviços computacionais em nuvem, Amazon AWS, no final do dia 3 de Janeiro de 2018, causando degradação de performance em 30% dos nossos clientes no dia 5; 20% dos clientes nos dias 8, 9; e 15% no dia 10.
A correção foi necessária para mitigar os riscos decorrente desta falha grave de segurança. Na nossa visão, a aplicação imediata desta correção pela AWS, foi acertada já que a segurança deve sempre ter prioridade em relação a performance.
No entanto, teve consequências muito severas para nós.
Por algum motivo ainda não explicado pela AWS, instâncias com o tipo de virtualização chamada de "paravirtual" sofreram bem mais com a degradação de performance, que a outra, chamada de "HVM". Estas são as 2 opções de virtualização disponíveis na AWS.
Mais de 95% dos nossos servidores estavam com a virtualização "paravirtual" e por isto a degradação de performance nos impactou bastante.
Como parte da nossa estrutura é elástica, mais máquinas subiram para compensar a perda de performance e, por isto, para 70% dos clientes o problema não foi sentido.
No entanto, cerca de 20% dos servidores não são dimensionados automaticamente em processos de "autoscaling"(2). Desta forma, a única opção apresentada pela AWS era migrar estas máquinas para "HVM".
Foi o que fizemos até descobrir que uma boa parte delas não eram compatíveis com HVM. O motivo era que o sistema legado chamado Condor Desktop, ainda usado por 30%(3) dos nossos clientes, dependiam de uma determinada versão do banco de dados Firebird e esta versão do Firebird, por sua vez, dependia de uma certa versão do S.O., que por sua vez era incompatível com HVM.
Infelizmente com o passar dos anos o Firebird, que era um ótimo banco de dados, esta deixando de ser atualizado, e, aos poucos deixou de funcionar adequadamente com o restante da nossa tecnologia.
Para você entender, o Firebird em versões mais recentes apresenta instabilidade quando colocado em estresse de carga junto com as UDFs que utilizamos no Condor Desktop.
Trabalhamos duramente por meses neste problema mas não encontramos uma forma de resolve-lo sem abandonar o Firebird. Este é um problema que foi identificado há 3 anos e por isto, resolvemos, naquela época, fazer a única coisa que estava em nossas mãos: abandonar o Firebird e realizar um grande esforço de migração para um novo banco de dados. O escolhido foi o MySQL (3).
E assim o fizemos! Mas, apesar das nossas campanhas, não limitamos o tempo que nossos clientes tinham para migrar o Condor Desktop para seu sucessor, o Superlógica Condomínios.
Apesar de todos os clientes estarem usando alguns recursos do Superlógica Condomínios, 30% (3) deles ainda usavam o Condor Desktop para fazer algum tipo de atividade e, por isto, permaneceram na estrutura antiga, com o Firebird.
O atraso em matar este legado nos colocou na péssima situação dos primeiros dias do início deste ano (2018) após a aplicação, pela AWS, da correção dos bugs nos processadores. O fato do legado nos impedir de mudar para versões mais recentes, era um risco que conhecíamos, mas subestimamos.
Foi esta decisão, de postergar ao máximo o fim do sistema legado, o maior responsável pela maioria das indisponibilidades e questões de performance que passamos até hoje. É responsável também por nossa estrutura custar 40% mais caro do que poderia custar. Além disto, deixamos de aproveitar a estrutura nova que é mais segura e tem um desempenho pelo menos 200% superior.
Ocorrido o problema de performance, sabíamos que a solução definitiva era migrar os clientes para a nova estrutura. No entanto, trabalhamos em paralelo em uma solução paliativa para aqueles clientes que não estavam preparados para abandonar repentinamente o Condor Desktop. No dia 10/1, quarta-feira, conseguimos sucesso em testar a solução paliativa que era rodar o Firebird no HVM.
Fomos migrando os servidores mais críticos para HVM, gradativamente para não causar mais impactos negativos. Desde sexta-feira, 12/JAN, todos nossos clientes estavam operando sem degradação de performance, mas o processo de migração para HVM só terminou segunda-feita, 15/JAN.
Ainda há muitos clientes resistentes em parar de usar o Condor Desktop, nos impedindo de matar nosso legado definitivamente. Mas, ao contrário do que aconteceu antes, definimos um prazo para que todas estejam na nova estrutura. Este prazo é dia 9/ABR/18.
A migração para a nova plataforma é fundamental para mantermos os níveis de serviço com a crescente expansão da nossa base de clientes, melhorar a disponibilidade e a segurança dos nossos serviços.
Algumas outras ações que estamos implementando:
(1) https://www.theregister.co.uk/2018/01/04/amazon_ec2_intel_meltdown_performance_hit/ (2) O motivo é que a natureza de como funcionam não é compatível com autoscaling. (3) 20% dos clientes usam Condor Desktop e os outros 10% não foram migrados para nova estrutura por outros motivos. (4) A vantagem do Mysql é que ele é extensivamente utilizado. Empresas como Google e Facebook, o utilizam em missão crítica. Ele suporta replicação, backups incrementais, snapshots, tem diversos consultores especializados e está em franco desenvolvimento.
Atencionsamente,
Leandro Garcia, Luis Cêra e André Baldini.