Um imenso (e exponencialmente crescente) volume de dados motivou a maior migração de dados já realizada pelo Facebook. A mudança foi concluída em junho, mas só foi divulgada em detalhes um mês depois.
A migração foi necessária uma vez que a capacidade máxima se esgotou e a demanda de processamento do site já estava no limite. Em menos de um ano, o volume de dados de usuários aumentou mais de 50%, passando dos 30 petabytes (30 mil terabytes). Menos de um ano antes, o tamanho era de 20 petabytes.
Os dados do Facebook foram deslocados para um novo data center, com maior capacidade de processamento e armazenamento. O data warehouse do Facebook é desenvolvido com base em um conjunto de tecnologias open source, principalmente em torno do Apache Hadoop.
A experiência oferece lições para situações em que a migração de dados deve ser feita mantendo um sistema no ar, 24x7. Ilustra também tarefas envolvidas em manter e evoluir uma das maiores infraestruturas de TI do mundo.
Foto: Um dos novos data centers do Facebook (fonte: Facebook)
Contexto e Tecnologias
O Facebook é desenvolvido utilizando LAMP; o front-end é criado com PHP, enquanto o MySQL atua como repositório de uma estrutura de dados baseada em chave/valor. Em uma apresentação durante o QCon 2008, em São Francisco, o diretor de engenharia do Facebook descreveu algumas características e obstáculos encontrados com a arquitetura do site naquela época. Passados três anos, os desafios só aumentaram.
O foco da migração foi na camada intermediária, composta por serviços fundamentais, especialmente um data warehouse. Esse data warehouse é responsável por processar os dados dos usuários e seus "amigos" e disponibilizar as informações relevantes para os usuários. O mesmo data warehouse também é utilizado como fonte de informações estratégicas e de monitoramento para os analistas do Facebook.
A tecnologia principal usada pelo data warehouse é o Hadoop, um framework com um modelo de programação que permite processamento distribuído em grandes conjuntos de dados, que são armazenados em clusters de computadores. São usados diversos outros projetos open source, incluindo:
- Apache Hive, sistema para extração de informações em grandes massas de dados com o HDFS (Hadoop Distributed File System);
- Apache HBase, a base de dados do Hadoop, com capacidade de armazenamento de grandes tabelas (bilhões de linhas e milhões de colunas);
- Apache Thrift, composto por um gerador de código, para a construção de serviços a partir de um arquivo texto que estipula uma estrutura de tipo e interfaces de serviços.
Migração 24x7
Replicar os dados do data warehouse foi um dos maiores desafios durante a migração, especialmente pela necessidade de manter o Facebook permanentemente no ar durante o processo:
A escala dessa migração excedeu todas as migrações anteriores, e foi necessário analisar várias estratégias. Uma delas foi mover fisicamente as máquinas para o novo data center. Poderíamos tê-las movido em alguns dias, se colocássemos pessoal suficiente dedicado a isso. Mas isso não seria uma opção viável porque nossos usuários e analistas dependem nos dados 24x7, e o tempo fora do ar seria longo demais.
A estratégia escolhida na migração foi implantar um novo cluster com os dados espelhados do antigo ambiente, além de criar um mecanismo que garantisse a replicação dos dados modificados no cluster antigo para o novo. Dessa forma, no momento da transição, bastaria redirecionar os serviços para o novo data center.
A replicação dos dados ocorreu em duas etapas, a primeira foi a cópia da massa de dados do cluster de origem para o de destino. Esse trabalho foi feito pelo DistCp, uma ferramenta para cópia de arquivos de forma paralela, com MapReduce, o algoritmo fundamental do Hadoop para processamento distribuído. A segunda etapa da replicação foi recuperar os logs de mudanças nos dados, ao mesmo tempo que a cópia dos dados era processada para replicar as mudanças no novo cluster. Isso foi feito através de um plug-in desenvolvido para o Apache Hive. Tanto o software de replicação quanto o plug-in foram criados internamente, pelos engenheiros do Facebook.
Essa estratégia de migração de data center era a mais complexa, já que, enquanto o cluster era criado e o espelho dos dados era processado, os usuários continuavam a disponibilizar e alterar informações no Facebook. Por outro lado, com a estratégia adotada, a equipe de infraestrutura do Facebook reduzia consideravelmente a probabilidade de indisponibilidade do site.
Para a replicação, os desafios foram desenvolver um sistema capaz de lidar com o tamanho do data warehouse, que havia já continha milhões de arquivos, diretórios e objetos do Hive. Apesar de termos antes criado um sistema de replicação para clusters menores, ele não era capaz de dar conta da taxa atual de criação de objetos. O sistema foi então reescrito para adicionar suporte a multithreading, além de um novo serviço de backend para o gerenciamento das operações com HDFS. Com isso, chegamos a uma taxa de cópia alta o suficiente para completar a migração no tempo necessário. Para a troca para o novo cluster, os maiores desafios vieram da necessidade de gerenciar um grande conjunto de sistemas que interagem com o data warehouse e o cluster MapReduce. Temos vários serviços que gerenciam a submissão e o agendamento de tarefas. Foi necessário pará-los e somente reiniciá-los quando todas as mudanças de DNS e de configuração tivessem sido concluídas.
A arquitetura do Facebook e especificamente as técnicas usadas para a migração, são definitivamente casos de sucesso. Por trás do complexo ecossistema do site, existem vários outros desafios além da gestão e processamento de dados. Em dois artigos escritos pela equipe do Facebook, é possível conhecer mais sobre os obstáculos a serem gerenciados para manter a rede social no ar: um descreve a quantidade de módulos no front-end do Facebook e a dependência entre eles; outro detalha técnicas de como manter a aplicação no ar com, na época, meio bilhão de usuários (hoje mais de 750 milhões estão cadastrados).