Nós sabemos que oferecemos um serviço essencial para quem vende pela internet, e que qualquer indisponibilidade da nossa plataforma impacta diretamente não só os nossos clientes, mas os clientes dos nossos clientes – os usuários finais. Se ficamos 30 minutinhos fora do ar, por exemplo, mais de mil pessoas deixam de comprar o seu jogo on-line ou são impedidas de adquirir a passagem de ônibus de volta para sua cidade natal. Hoje, processamos quase 45 milhões de compras e mais de 4 bilhões de eventos de navegação por ano. É uma baita responsabilidade.
A Black Friday é “O” dia para o e-commerce. Os descontos trazem um volume gigante de curiosos e pessoas que esperam o ano todo (ou o 13º!) para comprar. Há lojas que vendem 10 vezes mais na sexta-feira e de 3 a 4 vezes mais no final de semana que a segue. A data “pegou” no Brasil, mas parece que muita gente ainda não está pronto para lidar com o pulo no movimento.
Sabendo do aumento violento de acessos e compras, e também da importância da data para os nossos clientes, quando faltavam 3 meses para a Black Friday o nosso time de TI se perguntou: se o volume aumentasse em 5 vezes, que parte do sistema soluçaria? E se aumentasse em 10 vezes? O que podemos fazer para nos prepararmos?
Mapeando os potenciais gargalos na aplicação
Fazer um profiling verdadeiro de uma aplicação distribuída é uma empreitada e tanto, e não era isso que queríamos. O nosso tempo de resposta já é bem decente e diminuir isso 10 milissegundos não era o propósito. O que queríamos era identificar pontos de congestionamento, em que um fluxo anormal de dados geraria timeouts e outros potenciais erros. Tipo assim:
Para isso, nada mais justo do que percorrer o caminho que o pedido faz ao chegar no sistema. Resumindo bem, uma transação passa pelos seguintes módulos:
- API pública
- API privada
- Motor
- Calculador de features
- Oráculo
O trabalho da API pública é validar a mensageria, garantir que estamos recebendo os dados no formato certo, e que aquela loja está habilitada para processar pedidos. O pedido desce para a API privada, responsável pela persistência do pedido no banco de dados. O motor de risco é o orquestrador da análise que despacha a transação para os workers distribuídos fazerem seus cálculos. O motor em si não calcula nada, ele é apenas um juiz: pesa todos os argumentos para decidir o resultado.
Por fim, temos os módulos do oráculo e do calculador de features. O primeiro, como o nome diz, faz as previsões do modelo de inteligência artificial. É puro poder computacional. Já o segundo faz o trabalho de calcular os trocentos fatores de análise do pedido, ou seja, de fazer as perguntas: “já vi fraude com este e-mail antes?”, “quão cara é esta venda, se comparada com o padrão da loja?” ou “este e-mail está na blacklist?”.
Quando você quer otimizar a performance de um sistema, é sempre bom começar olhando para o banco de dados. Eles são bichos bem complexos, têm muito espaço para “tunagem” e são um ponto de falha central: se o banco cair, não importa como a sua aplicação está montada.
E foi batata!
No nosso calculador de features vimos um potencial gargalo na forma como utilizávamos o banco de dados! Basicamente, quanto mais pesquisas simultâneas, mais ele demoraria.
O nosso time, então, começou um trabalho de refatoração na forma como este calculador faz as perguntas e migramos esta parte para o DynamoDB, da Amazon Web Services (AWS) – um banco de dados não-relacional que acaba fazendo um trabalho bem melhor neste tipo de consulta. O resultado você pode ver abaixo:
Notou a diferença? É sutil, mas antes o tempo de resposta tinha uma variação maior; era mais volátil. E esta volatilidade aumentaria com o volume de pedidos. Na segunda parte do gráfico você pode ver que o tempo de resposta ficou mais estável – e ainda fico um tiquinho mais rápido!
Preparando a infra para o impacto
Em paralelo ao trabalho de investigação no código nós também olhamos para a nossa infraestrutura – servidores, balanceadores de carga e afins – entender como poderíamos aumentar a capacidade computacional. Nós temos basicamente dois tipos de entradas de dados, os pedidos e as navegações, e ambos seguem um padrão clássico que acompanha o horário comercial:
Navegações
Pedidos
Mas, apesar de a “dança” ser similar, o volume é bem diferente. Estamos falando de 11 milhões de navegações/dia para mais de 120 mil pedidos/dia. E na Black Friday o pessoal navega muuuuito antes de comprar, para garantir que o preço está legal. Então sabíamos que a carga nos servidores que processam a navegação seria maior.
Hospedamos tudo na nuvem da Amazon e usamos a funcionalidade de AutoScaling para aumentar e diminuir automagicamente o parque de servidores que processam as navegações. Ao longo do dia o sistema liga e desliga os servidores virtuais, conforme o volume. Em preparação para a Black Friday, o que fizemos foi subir de antemão vários servidores extras de navegação, praticamente triplicando a capacidade instalada. Isso garantiu que, quando o pico veio, já estávamos prontos:
Múltiplos Name Servers para DNS
OK, então isso aqui a gente não fez especificamente para a Black Friday. Já está no ar há pouco mais de um ano, mas é algo que vemos poucas empresas fazendo e que pode salvar alguém de um downtime no futuro!
O DNS é uma lista telefônica para os computadores. É um serviço que transforma o domínio google.com no endereço IP 172.217.30.110, para onde o seu computador vai enviar as mensagens de busca. (O Google não fica debaixo de um IP só, mas vamos deixar assim para fins ilustrativos!). Todos os domínios na internet têm um DNS e um Name Server (NS) por trás, e em geral é um serviço externo.
Exemplos:
O R7 usa a Akamai
$ dig ns r7.com +noall +answer
r7.com. 21599 IN NS use5.akam.net.
r7.com. 21599 IN NS ns1-228.akam.net.
r7.com. 21599 IN NS usc3.akam.net.
r7.com. 21599 IN NS asia1.akam.net.
O Reddit usa o Route53 da Amazon
$ dig ns reddit.com +noall +answer
reddit.com. 21599 IN NS ns-1029.awsdns-00.org.
reddit.com. 21599 IN NS ns-1887.awsdns-43.co.uk.
reddit.com. 21599 IN NS ns-378.awsdns-47.com.
reddit.com. 21599 IN NS ns-557.awsdns-05.net.
Já o WhastApp usa a Dyn
$ dig ns whatsapp.com +noall +answer
whatsapp.com. 21599 IN NS ns1.p13.dynect.net.
whatsapp.com. 21599 IN NS ns4.p13.dynect.net.
whatsapp.com. 21599 IN NS ns2.p13.dynect.net.
whatsapp.com. 21599 IN NS ns3.p13.dynect.net.
Legal, até aqui bacana! Akamai, Amazon e Dyn são empresas mega consolidadas e com um histórico excelente de prestação de serviço. Mas, e se na eventualidade alguma delas tiver algum problema? Neste caso a casa cai – e o site também! Se a Dyn tiver algum problema sério, nenhum celular do mundo vai conseguir encontrar os servidores do WhatsApp, e o serviço inteiro cai. Já aconteceu!
Agora vamos dar uma olhada nestes NS aqui:
$ dig ns walmart.com.br +noall +answer
walmart.com.br. 54 IN NS pdns1.ultradns.net.
walmart.com.br. 54 IN NS ns2.p36.dynect.net.
walmart.com.br. 54 IN NS pdns6.ultradns.co.uk.
walmart.com.br. 54 IN NS pdns5.ultradns.info.
walmart.com.br. 54 IN NS pdns4.ultradns.org.
walmart.com.br. 54 IN NS pdns3.ultradns.org.
walmart.com.br. 54 IN NS pdns2.ultradns.net.
walmart.com.br. 54 IN NS ns1.p36.dynect.net.
$ dig ns konduto.com +noall +answer
konduto.com. 19128 IN NS ns2.dnsmadeeasy.com.
konduto.com. 19128 IN NS ns0.dnsmadeeasy.com.
konduto.com. 19128 IN NS ns1.dnsmadeeasy.com.
konduto.com. 19128 IN NS ns-1868.awsdns-41.co.uk.
konduto.com. 19128 IN NS ns-927.awsdns-51.net.
konduto.com. 19128 IN NS ns-241.awsdns-30.com.
konduto.com. 19128 IN NS ns-1053.awsdns-03.org.
konduto.com. 19128 IN NS ns3.dnsmadeeasy.com.
Você vai notar é que tanto o Walmart como nós temos 2 empresas de DNS diferentes!
O que isso quer dizer? Que, na eventualidade de uma destas empresas cair, temos uma segunda opção já pronta, que pode assumir sozinha a tarefa de resolver o domínio.
E qual o lado ruim? Bom, você precisa pagar por dois serviços e ter a disciplina de manter ambos sincronizados entre si. A mudança que você faz em um DNS precisa ser feita no outro – se houver algum descompasso entre as duas configurações os erros serão bi-zar-ros! 🙂
Conclusão
É fundamental planejar-se para a principal data do comércio eletrônico. Foi isso o que fizemos na Konduto: muitos meses antes da última sexta-feira de novembro já estávamos pensando em diversos cenários que poderíamos viver na Black Friday de 2017 e organizamos a nossa casa para este momento.
Provisionamos nosso sistema para suportar um tranco fortíssimo, uma chuva de pedidos e de navegações de clientes, e tivemos a capacidade de atender nossos clientes com um sistema 100% confiável, que não sofreu um soluço sequer durante a Black Friday. Na verdade, a Konduto vem se provando como um sistema antifraude que não deixa seus clientes na mão. Basta acompanhar a nossa status page: durante todo o ano de 2017, nosso sistema teve APENAS 21 minutos de instabilidade. Isso significa um uptime de 99,996%!
A Konduto, além de pioneira na utilização de inteligência artificial (machine learning) e do monitoramento do comportamento de navegação para calcular o risco em compras on-line, possui uma infraestrutura altamente segura e totalmente escalável para garantir a performance de quem utiliza o nosso antifraude.
Ficou alguma dúvida?
Fale com a gente no e-mail oi@konduto.com
