Log operacional na Lyft: migração do Splunk Cloud para o Amazon ES e depois para o Elasticsearch autogerenciado
Está procurando uma alternativa para a Splunk? Saiba como a migração da Splunk para a Elastic pode ajudar a unificar seus dados de observabilidade e segurança em uma única plataforma, reduzindo seus custos gerais e as despesas administrativas.
Este post é um resumo de uma palestra do Elastic{ON} 2018. Quer saber sobre outras palestras como esta? Veja o arquivo da conferência ou descubra quando a Elastic{ON} Tour estará numa cidade perto de você.
Quer aprender sobre as diferenças entre o Amazon Elasticsearch Service e nosso Elasticsearch Service oficial? Visite nossa página de comparação do AWS Elasticsearch.
A Lyft precisa de uma poderosa infraestrutura tecnológica para manipular centenas de milhões de viagens globalmente todos os anos (mais de 375 milhões somente em 2017) e garantir que todos os seus clientes cheguem ao seu destino. Em 2017, isso se traduziu em mais de 200 microsserviços em mais de 10.000 instâncias EC2 — números que aumentariam para períodos de pico como a véspera do Ano Novo (mais de 2 milhões de viagens em um único dia) e o Halloween (mais de 2000 viagens por minuto no pico). Para manter todos esses sistemas e viagens em operação, é importante que os engenheiros da Lyft tenham acesso a todos os logs operacionais. Para Michael Goldsby e sua equipe de Observabilidade, isso significa manter seu serviço de pipeline de logs em atividade.
Nos primeiros anos da análise de logs da Lyft, ela usava o Splunk Cloud como provedor de serviços. Só que os limites de retenção de seu contrato, backups de ingestão de até 30 minutos durante os períodos congestionados e os custos associados ao escalonamento fizeram com que a Lyft decidisse migrar para o Elasticsearch.
No final de 2016, uma equipe de dois engenheiros conseguiu migrar a Lyft do Splunk para o Amazon Elasticsearch Service na AWS em cerca de um mês. Usar o Elasticsearch era ótimo, mas havia algumas partes da oferta da AWS que não eram perfeitas. Uma das ressalvas era que a equipe de Goldsby queria atualizar para o Elasticsearch 5.x, mas o AWS só oferecia a versão 2.3 na época. Além disso, novas instâncias estavam limitadas ao Amazon EBS para armazenamento, que tinha desempenho e confiabilidade inferiores à escala da Lyft. E nem todas as APIs do Elasticsearch eram expostas no AWS. Só que essas limitações do AWS não eram maiores do que os benefícios de abandonar o Splunk Cloud.
Com os limites de ingestão eliminados (ou pelo menos aumentados drasticamente), a equipe de Observabilidade decidiu abrir as comportas e adotar uma nova filosofia: “envie-nos todos os seus logs”. Isso rapidamente fez saltar as taxas de ingestão de 100.000 eventos por minuto para 1,5 milhão de eventos por minuto. Com essa nova abordagem, tudo ficou maravilhoso durante cerca de quatro meses. Quando a equipe de Goldsby passou por inatividades de ingestão, encolhimento de retenção ou painéis lentos do Kibana, bastou fazer o escalonamento ascendente. E quando atingiram o limite de nó de 20 do AWS, receberam uma exceção especial permitindo-lhes chegar a até 40 nós.
Mas mesmo com 40 nós, havia problemas. E os problemas estavam nos clusters vermelhos.
Os clusters vermelhos eram um problema que a equipe de Goldsby sabia como corrigir (reiniciar, substituir nós etc.). O problema real era que eles não tinham acesso direto aos clusters. Em vez disso, eles precisariam abrir um tíquete junto à Amazon, às vezes aguardando horas durante horários de pico para obter suporte. E o tíquete teria de ser escalonado, porque a primeira linha de suporte não tinha acesso aos clusters. Por fim, a Lyft aprendeu que, para agilizar o processo de escalonamento, poderia ir diretamente ao gerente de conta técnica (TAM) que providenciaria que os clusters voltassem a ficar verdes.
Entre as inevitáveis intervenções de suporte, o limite da versão 2.3, o requisito de EBS e outras limitações impostas pelo AWS (balanceamento de carga round-robin, inatividades de 60 segundos, ofuscação de API etc.), a equipe de Observabilidade decidiu fazer uma nova migração — desta vez para a implantação do Elasticsearch autogerenciado. “[No AWS] você não conta com todos os recursos. Não pode apertar todos os botões”, comentou Goldsby. “Sentíamos ter experiência operacional suficiente com o Elasticsearch internamente…[e] achamos que daríamos conta do recado.”
Com uma equipe um pouco maior do que a usada para a migração do Splunk, a Lyft conseguiu migrar do Amazon Elasticsearch Service para o Elasticsearch autogerenciado em apenas duas semanas. Agora ela tem a própria implantação, além de todos os recursos que anteriormente estavam travadas no AWS. Isso também significava que ela estava a cargo de todos os aspectos operacionais do Elastic Stack, incluindo manter os clusters verdes e os usuários (colegas de trabalho) satisfeitos.
Saiba como a Lyft fez a implantação de seu Elasticsearch autogerenciado assistindo à palestra Lyft's Wild Ride from Amazon ES to Self-Managed Elasticsearch for Operational Log Analytics no Elastic{ON} 2018. Você vai saber tudo sobre escolhas de hardware, decisões de gerenciamento de ciclo de vida de índices e muito mais, incluindo a diferença entre “log de todas as coisas e log de qualquer coisa” em relação à qualidade de serviço.
