SAP Concur: Elastic Logging como estratégia DevOps

Este artigo é o resumo de uma palestra da comunidade apresentada na Elastic{ON} 2018. Quer ver mais palestras como essa? Confira o arquivo da conferência ou saiba quando a Elastic{ON} Tour estará em uma cidade perto de você.

Se você já preencheu um relatório de despesas, é bem provável que tenha usado o SAP Concur. Com mais de 45 milhões de usuários em mais de 150 países (incluindo 70% das empresas da Fortune 500), o Concur é uma das principais soluções em viagens e despesas. Só em 2016, a plataforma SaaS processou mais de US$ 87 bilhões em despesas, o que significa mais de 2,4 milhões de recibos e US$ 187 milhões em faturas por dia. Pode parecer um enorme volume de itens para a contabilidade, mas gera ainda mais linhas de log para uma solução em logging gerenciar diariamente.

A Concur existe há mais de 20 anos e, à medida que seus serviços cresceram e evoluíram, sua solução em registro também se desenvolveu. Não apenas na tecnologia que utilizam, mas também no escopo e na intenção de seu uso. Inicialmente uma solução baseada em SQL usada para armazenamento simples de registros, a solução atual — construída sobre o Elastic Stack — ajuda a promover a propriedade de aplicações de ponta a ponta e alinha desenvolvimento, testes e operações. No futuro, a equipe LAMA (Logging, Alerta, Monitoramento e Análise) da Concur planeja usar o Machine Learning da Elastic em análises operacionais e insights, além de automatizar implantações e reversões. Eles deram grandes avanços no registro, mas não passaram do armazenamento de registros para análises da noite para o dia.

Originalmente construída sobre um banco de dados relacional, a solução em logging ingeria dados de log em formato XML via RabbitMQ, e os usuários adoravam a facilidade com que podiam consultar os logs usando SQL. Mas, à medida que a popularidade do serviço crescia, o mesmo acontecia com o uso. Com o pico de ingestão chegando a 200 GB/dia — e taxas superiores a 1.500 documentos/seg — o serviço atingiu o limite, e atrasos relacionados ao desempenho podiam obrigar os usuários a esperar até 20 minutos para que um log estivesse disponível no sistema. Como resposta, a única solução encontrada pela equipe de logging foi migrar o banco de dados para um hardware mais potente, o que se mostrou insustentável. O que eles precisavam era de escalabilidade horizontal; então, partiram em busca de uma solução melhor.

Após pesquisar o Elasticsearch e ouvir diferentes histórias de sucesso de empresas em situações semelhantes, a Concur escolheu o Elastic Stack como solução em registro de logs. Era rápido, poderoso e escalável — e (possivelmente ainda mais) importante para os usuários internos, tinha um componente de visualização que eles adoravam. Antes, diferentes equipes criavam a própria interface e dashboards, muitas vezes incorrendo em custos de licenciamento para as ferramentas necessárias. Com o Kibana, a Concur passou a ter uma solução em visualização unificada, eliminando a necessidade de soluções próprias ou de terceiros.

A primeira implementação do Elastic foi com Elasticsearch 1.1 e Kibana 3, com a ingestão vindo do Logstash, RabbitMQ (igual ao que usaram na solução SQL) e Fluentd. A equipe de logging também conseguiu criar o próprio plugin de alertas (um benefício da natureza open source do Elastic), já que um ainda não existia dentro do Elastic Stack. Entre a velocidade aumentada do Elasticsearch, as visualizações do Kibana e os recursos de alerta do plugin Watcher próprio, a adoção de serviços aumentou em toda a Concur, e a ingestão disparou para 5.000 doc/seg. Isso é algo que a solução SQL deles não conseguiria nem de perto.

Da solução à estratégia com a Elastic

Desde a implementação inicial, a solução em logging da Concur cresceu junto com o Elastic Stack. Em 2015, eles migraram para o Elasticsearch 2.3 e o Kibana 4.5, adquiriram uma assinatura Gold e começaram a usar Beats (como substituto do Fluentd), Watcher (para substituir a solução interna) e Shield (para segurança). Eles também desenvolveram outro plugin personalizado, dessa vez uma interface de agregação personalizada. À medida que sua solução de logging melhorava, a adoção também aumentava e, em 2017, a taxa de ingestão chegou a 60 mil documentos por segundo (4 TB por dia).

Depois de participar do Elastic{ON} 2017, a Concur fez o upgrade novamente, dessa vez para aproveitar a busca entre clusters, a segurança aprimorada (necessária para a conformidade com o GDPR) e outros novos recursos do Elastic Stack que eles aprenderam durante a conferência. Usando a busca entre clusters, eles conseguiram dividir o cluster monolítico em vários clusters menores espalhados por várias regiões. Essa versão melhorada — bem como a mudança para uma assinatura Planitum — os ajudou a estabelecer o ambiente que usam atualmente, com uma variedade de fontes de ingestão, clusters do Elasticsearch em várias regiões (5TB/dia nos EUA) e dashboards do Kibana usados por operações, SREs, suporte, liderança executiva e muito mais. E tudo é gerenciado por uma equipe LAMA composta por seis engenheiros e dois gerentes.

Saiba como a Concur passou do armazenamento de log para a capacitação da propriedade assistindo a Elastic @ SAP Concur: Driving the Journey to DevOps and End-to-End Ownership, do Elastic{ON} 2018. Você também vai saber como eles possibilitaram a implantação do serviço de registro em um clique, como configuraram mapeamentos (não dinâmicos) e campos para mais de 200 equipes e quais são os planos deles para usar o machine learning da Elastic.