Usamos uma variedade de armazenamentos de dados e tecnologias como MySql, Cassandra, Elasticsearch e Vertica, no entanto, nesta pós-trilogia (todas as coisas podem ser divididas em 3…), gostaria de focar em nosso ecossistema Hadoop e em nossa jornada de metal puro em uma solução de nuvem híbrida.
O período bare metal
Em poucas palavras, mantemos dois tipos de clusters do Hadoop:
- Clusters online, usados para atividades de veiculação online. Esses clusters são relativamente pequenos (2 PB de dados por cluster) e são mantidos em nossos datacenters em clusters bare metal, como parte de nossa infraestrutura de atendimento.
- O cluster de pesquisa, surpreendentemente, é usado principalmente para atividades de pesquisa e off-line. Esse cluster mantém grande quantidade de dados (6 PB) e, por natureza, a carga de trabalho nesse cluster é elástica. Na maioria das vezes, não era utilizado, mas havia momentos de picos em que era necessário consultar uma quantidade enorme de dados.
Lição de história
Antes de avançarmos em nossa história, pode valer a pena gastar algumas palavras sobre a história.
Começamos a usar a tecnologia Hadoop na Avance Network há mais de 3 anos - começando como um pequeno experimento técnico. À medida que nossos negócios crescem rapidamente, o mesmo ocorre com os dados e os clusters foram ajustados em tamanho, no entanto, uma dívida tecnológica havia sido criada em torno deles. Continuamos a aumentar os clusters, com base na metodologia de dimensionamento e, após algum tempo, nos encontramos com clusters executando a versão antiga do Hadoop, sem poder suportar novas tecnologias, construídas a partir de centenas de servidores, alguns dos quais muito antigos.
Decidimos que precisamos parar de ser bombeiros e ser super proativos sobre o problema. Primeiro cuidamos dos clusters on-line e os migramos para uma nova solução interna de bare metal
Agora era hora de avançar e lidar com o nosso cluster de Pesquisa.
Ponto de partida do cluster de pesquisa
Nosso ponto de partida para o cluster de Pesquisa foi uma compilação de 500 servidores, contendo cerca de 6 PB de dados, executando a versão da comunidade CDH4.
Como mencionado anteriormente, a carga de trabalho nesse cluster é elástica - às vezes, requer muita energia computacional e, na maioria das vezes, é pouco utilizada (veja o gráfico abaixo).
Este gráfico mostra a utilização da CPU por 2 semanas, visto que o uso não é constante, na maioria das vezes é pouco usado, com alguns picos periódicos
O cluster não pôde oferecer suporte a novas tecnologias (como SPARK e ORC), que já estavam em uso com os clusters Online, reduzindo nossa capacidade de usá-lo para pesquisas reais.
Além disso, alguns dos servidores desse cluster estavam ficando muito antigos e, à medida que aumentamos o cluster em tempo real, sua proporção de armazenamento: CPU: RAM era abaixo do ideal, fazendo com que desperdiçássemos impressões caras em nosso datacenter.
Além de tudo isso, causou muita frustração à equipe!
Mapeamos nossas opções no futuro:
- Faça a atualização no local para o software de cluster de Pesquisa
- Reconstrua o cluster de pesquisa do zero em bare metal em nossos datacenters (semelhante ao projeto que fizemos com os clusters Online)
- Aproveite as tecnologias de nuvem e migre o cluster de pesquisa para a nuvem.
O dilema
A opção 1 foi descartada imediatamente, uma vez que respondeu apenas a uma fração da nossa frustração. Ele não solucionou os problemas antigos de hardware e não preocupou-se com o armazenamento não ideal: taxas de CPU: RAM - que entendemos que só piorariam quando usarmos tecnologias intensivas em RAM, como SPARK.
Tivemos um dilema entre a opção 2 e a opção 3, ambas opções viáveis com prós e contras.
Construir o cluster de Pesquisa internamente era um projeto com o qual estávamos muito familiarizados (acabamos de concluir nossa migração de clusters on-line), nossos usuários estavam muito familiarizados com a tecnologia, portanto, nenhuma curva de aprendizado nessa frente. Por outro lado, exigia um grande investimento financeiro e não conseguimos alavancar a elasticidade na medida que desejávamos.
A migração para a nuvem respondeu às nossas necessidades de elasticidade, no entanto, apresentou um modelo de custo não previsível (algo muito importante para a equipe de finanças) e tinha muitas incógnitas, pois era novo para nós e para os usuários que precisariam trabalhar com o ambiente . Ficou claro que o aprendizado e a educação serão necessários, mas não ficou claro o quão acentuada essa curva de aprendizado seria.
Além disso, sabíamos que era preciso ter total compatibilidade entre o cluster de Pesquisa e o cluster Online, mas era difícil estimar o esforço necessário para chegar lá e o número de processos que exigem a transição de dados entre os clusters.
Então, o que fazemos quando não sabemos qual opção é melhor?
Nós estudamos e experimentamos! E foi assim que entramos no 2º período - o POC.
