Box: implantação do Elastic Stack para observabilidade, um microsserviço por vez

Nos últimos anos, a equipe de engenharia da Box estava ficando cada vez mais preocupada com o fato de seu backend antigo para geração de relatórios não estar sendo ampliado. E, conforme o roadmap da Box crescia, a equipe de observabilidade tinha interesse em adotar uma solução mais confiável e econômica para logging operacional e de aplicações do que a fornecida pela Splunk.

Esses eram processos de missão crítica que estavam adquirindo importância cada vez maior, especialmente enquanto a Box mantinha seu rumo de transformar uma infraestrutura monolítica em centenas de microsserviços para permitir que a empresa crescesse, inovasse e oferecesse novos recursos voltados para o cliente.

Como a solução de logging antiga era cobrada com base na quantidade de dados ingeridos, ocasionalmente a Box precisava cortar projetos de logging para limitar custos ou os engenheiros da Box decidiam não registrar em log eventos de microsserviços recém-implantados.

Isso era uma realidade na época e estava em desacordo com a missão da Box de se transformar rapidamente em uma plataforma líder de gerenciamento de conteúdo na nuvem. Essa transformação exigiu que a Box dividisse sua infraestrutura monolítica em microsserviços, um direcionamento que implicava mais logging de forma mais abrangente, não menos.

Além disso, o uso do MySQL pela Box para relatórios empresariais tinha seus próprios problemas. Entre eles estava a incapacidade de fornecer dados de logs de uso para grandes empresas, como quando os arquivos eram abertos, movidos para uma pasta diferente ou mesmo compartilhados, devido à enorme quantidade de eventos que estavam sendo gerados.

Então, em 2015, depois de pesquisar preços, capacidade de expansão, suporte e segurança oferecidos por diferentes provedores de soluções, a Box fechou com a Elastic.

Ao usar o Elastic Stack, a Box adotou uma abordagem de observabilidade escalável e preparada para o futuro, com um modelo de preços baseado na quantidade de memória sob gerenciamento, não na ingestão de dados. Essa mudança para a Elastic, ao mesmo tempo em que fortalece os recursos de geração de relatórios da Box e reduz drasticamente os custos, também captura logs dos microssistemas da Box para possibilitar a compreensão do desempenho e do comportamento. Esses logs também estão disponíveis a qualquer momento.

O caso de uso de relatórios foi o ponto de entrada para a Elastic na Box. O sucesso na substituição do MySQL para relatórios gerou confiança na Elastic. Esses foram os principais fatores que levaram a Box a começar a substituir sua solução de logging pela Elastic, um novo microsserviço de cada vez.

Mesmo assim, um novo sistema de relatórios e logging deve ter a adesão dos engenheiros, sob o risco de enfrentar uma possível falha ou adoção lenta. Com a escolha do Elastic Stack pela Box, os engenheiros agora estão mais motivados do que nunca para executar relatórios em escala e programar logs para microsserviços novos ou existentes. Tudo isso posiciona a Box para ter ainda mais sucesso.

Enquanto isso, a jornada inicial da Box começou com alguns terabytes de armazenamento e com alguns desenvolvedores da equipe de armazenamento desenvolvendo e adotando os novos recursos de relatórios da Box, juntamente com a ajuda de consultores da Elastic no local e sessões de treinamento da Elastic. Hoje, cerca de 500 engenheiros em diversas equipes da Box estão adotando o Elastic Stack para relatórios e logging, e visualizando terabytes de dados diariamente em centenas de dashboards do Kibana.

Como sabemos, o primeiro passo da Box com a Elastic foi migrar os logs empresariais para o Elasticsearch para fins de relatório e para servir como backend para analítica de dados. Esse pipeline de dados evoluiria posteriormente para dar suporte ao novo ambiente de logging da Box, com respaldo da Elastic.

Para o projeto de relatórios, a empresa está aproveitando os recursos de segurança obrigatórios, como controle de acesso por função e autenticação do usuário. Esses e outros recursos — como conseguir saber quem acessou qual arquivo da Box, quando e onde — permitiram que a Box cumprisse as obrigações de conformidade que envolvem segurança e privacidade.

A mudança inicial para esse projeto de relatórios do Elasticsearch, conhecido internamente como “Newsroom”, solucionou problemas relacionados a filtragem e inconsistências entre os logs empresariais e a análise de dados empresarial. A Box não estava mais tendo problemas para produzir os relatórios de cumprimento de SLAs, por exemplo. Para grandes empresas, às vezes os relatórios nem eram carregados e, para médias empresas, demoravam muito para retornar.

Outras correções incluídas:

• Ganho de capacidade para filtrar com eficiência os logs de uso com base em usuários/pastas
• Capacidade para obter eventos relacionados a usuários específicos na empresa ou a uma pasta específica
• Os relatórios de estatísticas mostrados no console administrativo se mantêm integrais
• Resolução da inconsistência entre os logs empresariais e a análise de dados empresarial

A antiga solução de logging da Box era cobrada com base na quantidade de dados ingeridos, que, na época, era de cerca de 7 terabytes por dia. Desde então, esse número aumentou para cerca de 20 terabytes por dia e deve aumentar ainda mais. Para não quebrar, a Box tinha de escolher onde implementar os recursos de observabilidade em sua crescente plataforma de microsserviços — um problema insustentável que a mudança para a Elastic resolveu.

O custo não era a única preocupação. Sob sua plataforma de logging anterior, os indexadores às vezes falhavam. A latência também era um problema, e os alertas não eram confiáveis.

Tendo isso em mente e com o crescimento exponencial no volume diário de dados de logging, a empresa reformulou sua infraestrutura de logging em 2017.

A Box está migrando todo o logging operacional e de aplicações de forma contínua e segura para o Elasticsearch com uma abordagem tríplice de separação do logging de retenção, ad-hoc e interativo por meio de um pipeline cujo codinome interno é Almost-Real-Time-Analytics ou “Arta”.

A Box afirma que é essencial produzir e manter sistemas de nível empresarial com desempenho dentro dos SLAs garantidos. Portanto, os engenheiros da Box precisam ter visibilidade de seus sistemas e dos logs que estão gerando. Ahmed diz que a Elastic forneceu à equipe de observabilidade da Box um sistema de logging com recursos sofisticados de consulta e uma sobrecarga mínima de indexação — tudo a um custo razoável frente à ampliação da Box.

Com essa observabilidade controlada pela Elastic, além de centenas de dashboards do Kibana para visualizar esses dados, os engenheiros da Box têm insights na ponta dos dedos. Eles podem ver se há problemas para os clientes abrirem seus arquivos na Box, se colaboradores foram adicionados aos arquivos, se arquivos foram adicionados a uma pasta e assim por diante. O logging também fornece aos engenheiros um caminho rápido para corrigir problemas, como a latência no upload de arquivos do cliente, para manter a Box dentro dos requisitos do SLA para tempo de funcionamento.

“Além disso, para garantir que os clientes da Box continuem com uma ótima experiência do usuário, o logging é fundamental no ato da codificação na Box para garantir que as alterações no código tenham sido confirmadas”, diz Dave Ward, diretor sênior de engenharia da Box.

“Quando uma alteração é feita para adicionar novos recursos ou uma correção, ela produz o resultado desejado?”, Ward pergunta. “Estou vendo erros ao enviar o código? Se o pipeline de observabilidade não estiver funcionando como planejado, não poderemos garantir a integridade dos nossos sistemas. O Arta com o Elasticsearch é de missão crítica para sustentar nossa agilidade e nossa cadência de lançamento em escala.”

Hoje, a Box está trabalhando para executar grande parte de seus fluxos de logging com foco no desenvolvedor em nível de produção no Arta. À medida que a Box continua a adicionar fluxos de logging novos e existentes de seu desenvolvimento contínuo de microsserviços, a equipe da empresa procura criar ainda mais melhorias na estabilidade, na resiliência e na eficiência operacional, além de reduzir ainda mais os custos.

Para o futuro, a Box está considerando a possibilidade de centralizar mais de suas métricas de rastreamento em uma única plataforma sob o guarda-chuva da Elastic. A Box também está trabalhando ativamente em parceria com engenheiros da Elastic e está refinando e compartilhando feedback do produto.

A empresa tem interesse em outros recursos da Elastic, como o Elastic APM para monitoramento de performance de aplicação, machine learning para ajudar a detectar problemas e alertar sobre eles, além dos recursos de mapeamento de geoIP para que a Box possa visualizar no Kibana de que parte do mundo onde vêm as consultas, partindo do endereço IP.

A Box também está explorando o Elastic SIEM para ajudar a controlar as operações de segurança e incrementando seus dashboards do Kibana com o Canvas, além de estar pesquisando muitos outros recursos da Elastic.

Em termos financeiros, a adoção da solução da Elastic ajudou a reduzir o preço pela metade quando se trata de cargas de dados. Além disso, problemas nos relatórios e intermitências no MySQL foram solucionados. E a latência causada, em parte, pela indexação na leitura da solução anterior de logging, em comparação com a indexação na gravação da Elastic, está se tornando uma coisa do passado.

“É como ferver o oceano ou ferver um lago para extrair os dados.” É assim que Wadhwani descreve a diferença na latência. “É muito mais rápido fazer consultas no Kibana com o Elasticsearch”, diz Wadhwani.

Em um nível menos quantificável, quando se trata de ROI, a Box está incentivando ativamente seus engenheiros a produzir a quantidade certa de logs para atingir o nível de observabilidade necessário para a criação de produtos de nível empresarial.

Essas e outras mudanças estão ajudando a Box a cumprir acordos internos e externos de SLA, ao mesmo tempo em que incentivam os desenvolvedores da Box a inovar à medida que a Box vai crescendo.