YouCanBook.me otimiza seus aplicativos graças ao Amazon CodeGuru

Por Sergio Delgado, líder da equipe de engenharia no YouCanBook.me

Na YouCanBook.me gostamos de dizer que somos “uma pequena empresa que faz grandes coisas”. Muitos aspectos de nossa cultura cotidiana são derivados de um lema muito simples, mas especialmente focado na eficiência de nossas operações. Embora os primeiros anos em que nosso CTO programou a primeira versão de nossa plataforma SaaS estejam no passado, quando entrei para a empresa éramos apenas cinco desenvolvedores, dos quais apenas três eram responsáveis pelos serviços de back-end, e nenhum deles foi dedicado a 100% para isto. As tarefas diárias de um programador em uma start-up como a nossa são incrivelmente variadas, desde responder a solicitações de suporte ao cliente até refinar o backlog de tarefas, definir infraestrutura ou ajudar com requisitos. É um trabalho tão exigente quanto recompensador, onde os desafios nunca acabam, mas que nos obriga a buscar eficiência em tudo o que fazemos. Um projeto não muito bem definido, onde não somos muito claros sobre o caminho a seguir e que pode levar meses de pesquisa é um desafio para uma equipe como a nossa, e provavelmente será adiado várias vezes para priorizar desenvolvimentos mais urgentes que trazem valor imediato para nossos clientes. Para nós, é muito importante extrair o máximo de benefício de cada desenvolvimento que fazemos, no menor tempo possível.

O resultado dessa filosofia é nosso envolvimento com a Amazon Web Services e suas diferentes plataformas e serviços. Embora as versões iniciais de nossos serviços de back-end não fossem executadas na AWS, a migração para a nuvem nos permitiu parar de nos preocupar com o gerenciamento de servidores físicos em uma empresa de hospedagem e concentrar nossos esforços em nossa lógica e código de negócios.

Atualmente, nossos servidores back-end são baseados na tecnologia Java e executados no AWS Elastic Beanstalk, enquanto para o front-end temos uma combinação de páginas JSP e webapps em React. Em JVMs, implantamos arquivos WAR, que compilamos a partir do código-fonte que armazenamos nos repositórios do AWS CodeCommit usando scripts do AWS CodeBuild. Além disso, todo o nosso monitoramento é baseado em logs e métricas do Amazon CloudWatch.

Um recurso interessante é que temos os diferentes ambientes (desenvolvimento, pré-produção, produção, análise, etc.) completamente separados, mas gerenciados por meio de um único AWS Organizations. Os usuários do AWS Identity and Access Management (IAM) são criados em uma conta raiz e, em seguida, assumem funções para operar os ambientes necessários com os devidos privilégios.

Com tudo isso, três pessoas gerenciam meia dúzia de serviços, em quatro ambientes diferentes, rodando em dezenas de instâncias e, simplesmente, tudo funciona.

O nosso problema

Embora nossos serviços sejam desenvolvidos com tecnologia Java, a verdade é que nem todos eles compartilham a mesma stack de tecnologia. Ao longo dos anos, eles migraram para estruturas mais modernas e padronizaram seu design, mas nem todos conseguiram se atualizar ainda. Estávamos cientes de que alguns serviços tinham problemas claros de desempenho e causavam gargalos quando haviam altos picos de tráfego, especialmente a parte do código mais antigo baseado em tecnologias legadas. Nossa solução de curto prazo era superdimensionar esses serviços específicos, com o consequente custo extra, e reimplantá-los a longo prazo seguindo a arquitetura de nossos serviços mais modernos. Mas, ao mesmo tempo, tínhamos certeza de que conseguiríamos melhorias muito rápidas se investíssemos em alguma ferramenta de análise de desempenho, ou APM (Application Performance Monitoring). Sabíamos que havia muitos no mercado e alguns de nós tinhamos experiência com alguns deles, e boas referências de outros. Então criamos um projeto de melhoria de desempenho em nosso roteiro, pesquisamos um pouco quais produtos pareciam melhores e… paramos por ai. O dia a dia sempre é priorizado e nunca encontramos tempo para dedicar contatando fornecedores, instalando as ferramentas, analisando nossos serviços durante o período experimental, comparando os resultados, etc. É por isso que as tarefas de desempenho estavam constantemente sendo adiadas, sempre esperando por uma época do ano em que não tínhamos muito mais a fazer. O que nunca ia acontecer.

A chegada do Amazon CodeGuru Profiler

Um dos bons hábitos que temos é estar muito atentos a todas as notícias da Amazon Web Services e geralmente somos muito rápidos em testá-las, especialmente quando eles não envolvem alterações no código de nossos serviços.

Além disso, confiar nos produtos da AWS nos dá uma vantagem extra. Como política da empresa, adoramos poder definir nosso modelo de segurança sobre usuários, funções e permissões do IAM, em vez de ter que criar contas e usuários separados em outras plataformas. Essa abordagem rigorosa para gerenciar o acesso e as permissões para usuários de nossa infraestrutura nos permita passar regularmente por auditorias de segurança e superá-las com sucesso sem investir muito esforço para uma empresa de nossa dimensão. Na verdade, nossas certificações de segurança são um dos nossos diferenciais contra nossos concorrentes.

É por isso que imediatamente reconhecemos a oportunidade que o CodeGuru Profiler nos ofereceia quando foi anunciado no re:Invent no final de 2019. No papel, outras ferramentas APM que queríamos avaliar pareciam oferecer mais informações ou um conjunto maior de métricas, mas a grande questão era se elas seriam úteis para nós. Que benefícios teríamos com telas e mais telas de relatórios se não tivéssemos certeza do que significavam ou se não entregassem recomendações que poderíamos implementar imediatamente? O CodeGuru parecia simples, mas em vez de vê-lo como uma desvantagem, tivemos a intuição de que poderia ser um grande benefício para nós. Ao testá-lo, poderíamos analisar os resultados em horas, não semanas, e descobrir se ele realmente nos traria valor quando se tratava de descobrir as partes do código que precisávamos otimizar.

A melhor coisa sobre o CodeGuru Profiler é que levaria mais tempo para discutirmos se deveríamos ou não utilizá-lo do que apenas configurá-lo e ver como ele é. Um único desenvolvedor, o gerente de infraestrutura, conseguiu instalar o agente CodeGuru em todos os nossos JVMs em uma tarde. Executamos o CodeGuru Profiler diretamente no ambiente de produção, permitindo analisar latências e identificar gargalos usando dados reais de produção, especialmente após um pico de tráfego. Percebemos que é muito mais fácil e mais realista para nós do que simular carga de trabalho sintética, e não há possibilidade de defini-la incorretamente ou sob falsas premissas. Tudo o que encontramos no CodeGuru é o comportamento autêntico de nossos sistemas.

Pré-otimização

Pós-otimização

Análise

Os gráficos de chamada do CodeGuru Profiler foram muito fáceis de entender. Simplesmente selecionamos o intervalo de tempo no qual detectamos um problema de dimensionamento ou carga de trabalho de pico e, para cada aplicação , vemos as classes e métodos Java que mais contribuíram para as latências das solicitações de nossos usuários. Como nosso negócio é baseado na integração com diferentes sistemas de calendário externos (Google, Outlook, CalDAV…) grande parte dessa latência é inevitável, mas rapidamente encontramos duas estratégias claras quando se trata de otimizar nosso código:

• Identificar métodos que não fazem solicitações a sistemas de terceiros, mas, no entanto, adicionam tempo significativo às latências. Nesses casos, o CodeGuru Profiler também ofereceu recomendações para otimizar o código e melhorar seu desempenho.
• Veja exatamente o percentual de tempos de resposta devido ao tipo de solicitações para os calendários subjacentes. Algumas solicitações (como criar um evento) não têm muito espaço para melhorias, mas encontramos consultas que foram feitas com muito mais frequência do que estimávamos, e que poderiam ser evitadas em grande parte por um algoritmo de pesquisa mais otimizado.

Nós começamos a trabalhar e em algumas semanas nós geramos cerca de quinze tickets em nosso backlog, a maioria dos quais foi implantada em produção durante o primeiro mês. Normalmente, cada ticket exigiu horas de desenvolvimento, em vez de dias, e não tivemos que desfazer nenhum deles ou identificar falsos positivos nas recomendações do CodeGuru.

Resultado

Conseguimos otimizar nosso serviço mais antigo e de pior desempenho para que sua latência fosse reduzida em 15% pelo percentil 95 (p95) em um dia de trabalho típico. Além disso, nossos gráficos de tempo de resposta são muito mais achatados do que antes, pois eliminamos picos de latência que ocorriam quase que regularmente.

A melhoria é tal que estamos muito satisfeitos por ter descoberto que, em um dos últimos picos de carga que tivemos na plataforma, este serviço não era mais o gargalo do sistema, suportando todas as solicitações sem problemas e bloqueando o resto de nossas APIs.

Isso provavelmente nos poupou não apenas o dinheiro que custou as instâncias extras que não precisamos mais, e que tínhamos em execução apenas para poder servir nesses cenários, mas dezenas de horas de pessoa em refatoração mais profunda sobre código legado, exatamente o que estávamos tentando evitar.

Outro dos nossos serviços de back-end, que normalmente mantém uma carga de trabalho muito alta durante o horário comercial, melhorou ainda mais, reduzindo sua latência em até 40%. Na verdade, em uma ocasião, introduzimos um erro na configuração do seu autoscaling e reduzimos o número de instâncias de execução para apenas uma máquina. Levamos algumas horas para perceber nosso fracasso porque essa única instância foi capaz de lidar com todas as solicitações de nossos usuários sem qualquer problema!

O Futuro

Nosso uso do CodeGuru Profiler é muito simples, mas tem sido extremamente valioso para nós. A médio prazo, estamos pensando em realizar a amostragem de parte de nossos servidores ou solicitações de usuários em vez de analisar todo o tráfego de produção, para obter eficiência. No entanto, não é muito urgente para nós, pois nossos serviços estão funcionando perfeitamente bem com a análise de desempenho habilitada, e o impacto sobre os tempos de resposta para nossos usuários é imperceptível.

Por quanto tempo planejamos ter o CodeGuru Profiler ativado? A resposta é clara: indefinidamente. Ter melhorado partes problemáticas de nossos serviços que mais ou menos já conhecíamos é um resultado muito bom, mas a visibilidade que nos oferecerá em futuras cargas de pico é extraordinariamente valiosa. Porque, não vamos nos enganar, removemos vários gargalos, mas teremos outros escondidos, ou vamos apresentá-los com novos desenvolvimentos. Com as métricas e os alarmes do AWS CloudWatch, detectaremos quando isso acontece e saberemos o que aconteceu, mas a partir de agora, o AWS CodeGuru nos ajudará a saber por quê.

Se você tiver um problema semelhante ao nosso, ou quiser evitá-lo, convidamos você a se familiarizar com o Amazon CodeGuru.

Sobre YouCanBook.me

YouCanBook.me permite agendar reuniões online para o seu negócio ou equipe, de qualquer tamanho. Elimina a necessidade de procurar espaços livres enviando e respondendo e-mails, permitindo que seu cliente crie o compromisso diretamente em seu calendário.

Desde a sua criação em 2011, nossa empresa permanece pequena, eficiente, auto-financiada, 100% remota e dedicada a resolver questões de agenda para usuários em todo o mundo. Com apenas 15 funcionários do Reino Unido, Espanha e Estados Unidos, conseguimos atender dezenas de milhares de clientes, gerenciando mais de um milhão de reuniões por mês.

Sobre os autores

Sergio Delgado define-se como programador de vocação. Em 25 anos desenvolvendo software, ele passou por fazer jogos de vídeo C++, máquinas caça-níqueis em Java, plataformas de e-learning em PHP, lutando com o Dreamweaver, automatizando chamadas em um call-center ou executando um departamento de P&D. Um dia ele começou a trabalhar na nuvem, e ele não quer mais voltar para a Terra. Atualmente é o líder da equipe de engenharia e arquiteto de back-end da YouCanBook.me.

Ele colabora com a comunidade dando palestras em encontros ou entrevistas em vários podcasts, e pode ser encontrado em https://www.linkedin.com/in/sergio-antonio-delgado-wantero/.

Rodney Bozo é um arquiteto de soluções da AWS que tem mais de 20 anos de experiência no suporte a clientes com gerenciamento de recursos on-premises, bem como soluções baseadas em nuvem.

Enrico Bergamo é arquiteto de soluções na AWS focado no segmento Enterprise e especialista em tecnologias Serverless, e atua auxiliando clientes de diversos segmentos em suas jornadas para a nuvem. Com mais de 10 anos de experiência em Arquitetura e Desenvolvimento de Sistemas, e DevOps, Enrico atuou diretamente com diversas empresas na definição, implementação e implantação de diversas soluções corporativas.