Lições aprendidas – Executando o Presto em grande escala na Meta

O Presto é um mecanismo de consulta SQL gratuito e de código aberto. Usamos essa ferramenta na Meta há 10 anos e aprendemos muito com isso. Para executar qualquer coisa em grande escala, sejam ferramentas, processos ou serviços, precisamos ter práticas de resolução de problemas para superar os desafios inesperados. Confira quatro lições que aprendemos ao usar o Presto na Meta, além de algumas dicas, caso você tenha interesse em executar as suas próprias consultas em grande escala.

Dimensionando o Presto rapidamente para atender às demandas crescentes: quais foram os desafios?

Implantando novas versões do Presto

Figura 1: fluxo de trabalho do processo para enviar novas versões do Presto (diagrama de Philip S. Bell)

A Meta executa um grande número de clusters do Presto, com data centers no mundo todo. Em média, uma nova versão do Presto é desenvolvida e lançada para implantação entre uma e duas vezes por mês. Um dos primeiros desafios que enfrentamos com o avanço veloz da presença do Presto na Meta foi implantar o mecanismo de consulta em alto volume de clusters mantendo a consistência em relação à disponibilidade e à confiabilidade. Ainda lidamos com essa questão, especialmente em casos de uso interativo do Presto, ou seja, quando um usuário inicia uma consulta e fica esperando por um resultado. Esse tipo de falha é menos preocupante em casos de uso de "lote" automatizados, já que as novas tentativas automáticas garantem o sucesso da consulta.

Foi fácil resolver esse problema. Todos os clusters do Presto ficam atrás de um balanceador de carga chamado Gateway, que é responsável (junto com outros sistemas da Meta) por rotear as consultas do mecanismo para o cluster apropriado. Quando precisamos atualizar um cluster do Presto, primeiro ele é marcado como "drenado" no Gateway, ou seja, o balanceador de carga interrompe o envio de novas consultas para ele. Depois, a automação espera por um tempo predeterminado para que as consultas que já estão em execução no cluster sejam concluídas. O cluster é então atualizado e, uma vez online, torna-se visível para o Gateway, que pode começar a encaminhar novas consultas para ele.

O outro aspecto da implantação de novas versões do Presto é a disponibilidade. Precisamos assegurar que os usuários possam continuar usando o Presto enquanto os clusters estão sendo atualizados. Novamente, a automação garante que os data centers em cada região física tenham sempre o número necessário de clusters disponíveis. O ideal é encontrar um equilíbrio entre desligar de uma vez só um número muito grande ou pequeno demais de clusters, o que pode gerar problemas de disponibilidade e atrasos no processo de implantação.

Automatizando os processos de ativação e desativação de clusters do Presto

Figura 2: fluxo de trabalho automatizado para adicionar hardware a clusters (diagrama de Philip S. Bell)

A distribuição do data warehouse da Meta em diferentes regiões está em constante evolução. Isso significa que novos clusters do Presto precisam ser mantidos enquanto os atuais são desativados. Anteriormente, quando havia apenas um pequeno número de clusters do Presto, esse processo era realizado de forma manual. Com a expansão da Meta, rastrear todas as alterações manualmente virou um grande desafio. Para resolver esse problema, implementamos automações para lidar com os processos de ativação e desativação dos clusters.

Primeiro, tivemos que padronizar as definições de cluster, ou seja, criamos configurações de base para os diferentes casos de uso do Presto na Meta. Cada cluster teria um número mínimo de especificações adicionais ou substituições na configuração de base. Uma vez concluído esse processo, qualquer novo cluster poderia ser ativado gerando configurações de forma automática a partir do modelo de base. A ativação do cluster também exigia ganchos de automação para fazer a integração com os vários serviços de infraestrutura em toda a empresa, como Tupperware e serviços específicos de data warehouse. Quando um cluster fica online, algumas consultas de teste são enviadas ao sistema, e a automação verifica se elas são executadas. Depois, o cluster é registrado no Gateway e começa a atender às consultas.

A desativação de um cluster segue basicamente o processo inverso. O registro do cluster é cancelado no Gateway, e todas as consultas em execução podem ser concluídas. Os processos do Presto são encerrados, e as configurações do cluster são excluídas.

Essa automação é integrada ao fluxo de trabalho de ativação e desativação do hardware para o data warehouse. Como resultado final, temos um processo totalmente automatizado, desde o novo hardware que aparece em um data center, até os clusters do Presto que ficam online e começam a atender às consultas, encerrando com a desativação do hardware. A implementação desse processo poupou muitas horas de trabalho, reduziu o tempo ocioso do hardware e minimizou as ocorrências de erro humano.

Depuração e correções automatizadas

Figura 3: detecção de host inválido (diagrama de Philip S. Bell)

Dada a implantação em grande escala do mecanismo de consulta na Meta, precisamos ter ferramentas e automação que simplifiquem a vida do ponto de contato do Presto.

Ao longo dos anos, desenvolvemos vários "analisadores" que ajudam o ponto de contato a depurar e avaliar com eficiência a causa raiz dos problemas. Os sistemas de monitoramento disparam alertas quando há violações de SLAs que afetam o cliente. Depois disso, os analisadores são acionados. Eles obtêm informações de diversos sistemas de monitoramento (Operational Data Store ou ODS), eventos publicados no Scuba e até mesmo registros no nível do host. A lógica personalizada no analisador une todas essas informações para inferir a causa raiz provável. Isso é extremamente útil para o ponto de contato porque apresenta uma análise de causa raiz e permite ir direto para opções de mitigação. Em alguns casos, automatizamos completamente a depuração e a correção para que esse profissional nem precise se envolver. Veja alguns exemplos descritos abaixo:

Detecção de host inválido

Ao executar o Presto em um grande número de máquinas, notamos que certos hosts inválidos podiam gerar falhas excessivas nas consultas. Após uma investigação, identificamos algumas causas principais que resultaram em hosts "inválidos", incluindo as seguintes:

• Problemas no nível do hardware que ainda não haviam sido detectados por sistemas de monitoramento em toda a frota devido à falta de cobertura
• Bugs desconhecidos da JVM que às vezes resultavam em falhas constantes nas consultas

Para evitar esse problema, agora monitoramos falhas nas consultas em clusters do Presto. Especificamente, atribuímos cada erro de consulta ao host que o causou, sempre que possível. Também configuramos alertas que são disparados quando um número alto e fora do normal de falhas nas consultas é atribuído a hosts específicos. Depois, a automação entra em ação para drenar o host da frota do Presto e, assim, conter as falhas.

Depurando problemas de enfileiramento

Cada cluster do Presto oferece suporte para o enfileiramento quando atinge a simultaneidade máxima para execução de consultas com base no caso de uso, na configuração de hardware e no tamanho da consulta. Na Meta, existe um sofisticado mecanismo de roteamento para que uma consulta do Presto seja despachada para o cluster "certo", que é capaz de executá-la fazendo o melhor uso dos recursos. Vários sistemas além do Presto estão envolvidos na tomada de decisão sobre o roteamento e levam em consideração diferentes fatores:

• Estado atual do enfileiramento em clusters do Presto
• Distribuição de hardware em diferentes data centers
• Localidade de dados das tabelas usadas pela consulta

Devido a essa complexidade, pode ser difícil para o ponto de contato descobrir a causa raiz de um problema de enfileiramento encontrado na produção. Esse é outro exemplo em que os analisadores se destacam por extraírem informações de várias fontes e apresentarem conclusões.

Robustez do balanceador de carga

Figura 4: robustez do balanceador de carga (diagrama de Philip S. Bell)

Como já mencionamos, os nossos clusters ficam atrás de balanceadores de carga que encaminham cada consulta do Presto na Meta. No começo, quando o Presto ainda não tinha sido expandido ao nível de uso interno que tem hoje, o Gateway era muito simples. No entanto, como houve um aumento no uso do Presto na Meta, enfrentamos problemas de escalabilidade em algumas ocasiões. Um deles era uma falha quando o Gateway estava sob carga pesada, o que podia tornar o Presto indisponível para todos os usuários. A causa raiz de alguns problemas de estabilidade era um serviço que bombardeava involuntariamente o Gateway com milhões de consultas em um curto espaço de tempo. Isso resultava na falha dos processos do Gateway e na incapacidade de rotear consultas.

Para evitar esse cenário, decidimos tornar o Gateway mais robusto e tolerante a esse tipo de tráfego indesejado de DDoS. Implementamos um recurso de limitação, que rejeita consultas em caso de carga pesada. A limitação pode ser ativada com base na contagem de consultas por segundo em várias dimensões, como por usuário, origem, IP, e também de forma ampla para todas as consultas. Outra melhoria implementada por nós foi o dimensionamento automático. Ao contar com um serviço em toda a Meta que apoia o dimensionamento e a redução de jobs, o número de instâncias do Gateway agora é dinâmico. Ou seja, sob carga pesada, o Gateway pode ser dimensionado para administrar o tráfego adicional e não esgotar a CPU/memória, evitando o cenário de falhas descrito acima. Aliado ao recurso de limitação, isso garante a robustez e a capacidade do Gateway de resistir a padrões de tráfego adversos e imprevisíveis.

Que conselho daríamos a uma equipe que está expandindo um data lakehouse próprio usando o Presto?

Figura 5: dimensionamento da arquitetura do Presto (diagrama de Philip S. Bell)

Confira alguns dos aspectos importantes a serem considerados ao dimensionar o uso do Presto:

1. SLAs fáceis de entender e bem-definidos voltados ao cliente. Definir SLAs em relação a métricas importantes (como tempo de enfileiramento e taxa de falhas nas consultas) para rastrear pontos fracos do cliente se tornou algo fundamental ao dimensionar o uso do Presto. Quando há um grande número de usuários, a falta de SLAs adequados pode prejudicar as iniciativas para mitigar problemas de produção devido à confusão na determinação do impacto de um incidente.
2. Monitoramento e depuração automatizada. Com a expansão do uso do Presto e o aumento no número de clusters, as práticas de monitoramento e a depuração automatizada são essenciais.
   • Executar um monitoramento completo pode ajudar a identificar e conter problemas de produção. Detectar problemas antecipadamente permite minimizar o impacto sobre o usuário.
   • As investigações manuais diante de problemas de produção que afetam o cliente não são dimensionáveis. Precisamos ter um processo de depuração automatizado em vigor para que a causa raiz possa ser rapidamente determinada.
3. Balanceamento de carga adequado. À medida que a frota do Presto cresce, é importante ter uma solução de balanceamento de carga adequada para os clusters do mecanismo. Em grande escala, pequenas ineficiências no balanceamento de carga podem ter um enorme impacto negativo devido ao alto volume da carga de trabalho.
4. Gerenciamento da configuração. Se não for planejado, o gerenciamento da configuração de uma grande frota de clusters do Presto pode se tornar uma dor de cabeça. Sempre que possível, as configurações devem poder ser recarregadas a quente para que as instâncias do Presto não precisem ser reiniciadas nem atualizadas de maneira inoportuna, o que resultará em falhas nas consultas e na insatisfação do cliente.

Este artigo foi escrito em colaboração com Neerad Somanchi, engenheiro de produção da Meta, e Philip Bell, representante de desenvolvedores da Meta.

Para saber mais sobre o Presto, acesse prestodb.io, assista à explicação rápida apresentada por Philip Bell no YouTube ou siga o perfil do Presto no Twitter, no Facebook e no LinkedIn.

Para saber mais sobre o Meta Open Source, acesse o nosso site, inscreva-se no canal do YouTube ou siga o nosso perfil no Twitter, no Facebook e no LinkedIn.