Dropbox Magic Pocket: saindo do S3 para exabytes próprios

01 · CONTEXTO

Por que construir o próprio armazenamento

O Dropbox guarda dois tipos de dado: o conteúdo dos arquivos e os metadados sobre arquivos e usuários. Segundo o post de anúncio, a empresa sempre teve uma arquitetura híbrida, com metadados e servidores web em data centers próprios e o conteúdo dos arquivos na Amazon. Foi um dos primeiros a adotar o Amazon S3, que permitiu escalar rápido e com confiabilidade.

A escala explica a conversa: cerca de 40 PB de dados de usuários quando o autor do post entrou, em 2012, e mais de 12 vezes de crescimento nos quatro anos seguintes, passando de 500 PB na época do anúncio. Os números são da época do anúncio.

O Dropbox deu duas razões para internalizar o armazenamento. A primeira é desempenho, um dos diferenciais do produto: controlar a pilha de ponta a ponta permite otimizá-la para o caso de uso. A segunda é a economia por unidade: com a escala e um caso de uso particular, dá para customizar hardware e software. O time também concluiu que teria de construir tudo do zero, porque nada em código aberto era comprovado nessa escala.

02 · A MIGRAÇÃO

Do dark launch aos noventa por cento

Em agosto de 2014 veio o chamado dark launch: o Dropbox espelhava dados entre duas localidades regionais e considerava o sistema pronto para guardar dados de usuários. Além disso, manteve backups extras por mais seis meses.

Em 27 de fevereiro de 2015, pela primeira vez, passou a guardar e servir arquivos de usuários exclusivamente em casa. Validada a infraestrutura, fixou a meta agressiva de escalar para mais de 500 PB em seis meses.

A meta declarada era servir 90% dos dados da infraestrutura própria até 30 de outubro de 2015. O Dropbox diz ter chegado em 7 de outubro, quase um mês antes, sem grandes interrupções de serviço nem perda de dados.

1. Antes: metadados e servidores web em data centers próprios, e o conteúdo dos arquivos na Amazon, em uma arquitetura híbrida.

2. O Magic Pocket entra como o sistema próprio que guarda o conteúdo dos arquivos.

3. A meta era servir 90% dos dados da infraestrutura própria; o Dropbox diz ter atingido a marca antes do prazo.

O Dropbox não deixou a Amazon de lado: disse que continuaria a investir em infraestrutura própria e a se associar à Amazon onde fizesse sentido, em especial globalmente, e citou a expansão da relação com a AWS para guardar dados na Alemanha para clientes empresariais europeus que pedissem.

03 · REQUISITOS E MODELO DE DADOS

Blocos imutáveis e um acesso que esfria rápido

O Magic Pocket é um armazenamento de blocos imutáveis: guarda pedaços criptografados de arquivos de até 4 MB e, uma vez gravado, um bloco nunca muda. As alterações de um arquivo ficam em um sistema separado, o FileJournal, o que mantém a simplicidade dos blocos imutáveis e leva a lógica de mutabilidade para camadas acima.

A carga tem forte localidade temporal: boa parte dos dados é acessada com muita frequência na primeira hora após o upload e cada vez menos depois. Mesmo assim, todo bloco exige leitura de baixa latência. O sistema é baseado em discos rígidos, que têm a vantagem de ser duráveis, baratos e densos, e reserva os SSDs para bancos e caches. Há muita replicação inicial e cache para uploads recentes e uma codificação mais eficiente para o resto.

A durabilidade é requisito inegociável: o texto diz que ela tem de ser efetivamente infinita em teoria. Os dados usam erasure coding e ficam em várias regiões geográficas. As metas de projeto do anúncio eram durabilidade anual acima de 99,9999999999% e disponibilidade acima de 99,99%.

A escala exigiu crescer de protótipos de dezenas de petabytes para vários exabytes em cerca de seis meses. Houve surpresas: em um caso o tráfego cresceu de repente e passou a saturar os roteadores entre clusters de rede, o que levou a mudar posicionamento de dados e roteamento e, por fim, a arquitetura de rede entre clusters.

O princípio de simplicidade aparece nas escolhas. O sistema evita consenso por quórum e coordenação distribuída o quanto possível e usa pontos centralizados quando isso é tolerante a falhas e escalável. Para o índice de blocos, em vez de uma tabela hash distribuída, o time escolheu um grande cluster MySQL fragmentado, decisão que descreve como ótima para simplificar o desenvolvimento e reduzir incógnitas.

Como o bloco de 4 MB é granular demais para mover ao trocar um disco ou aplicar erasure coding, ele é agregado em unidades maiores. A tabela resume a hierarquia.

Cada bloco tem uma chave, na maioria dos casos o hash SHA-256 do bloco. Blocos recentes são replicados direto em várias máquinas; depois os buckets são agregados e codificados com erasure coding para ganhar eficiência.

04 · ARQUITETURA E PROTOCOLOS

Zonas, células e o caminho de uma escrita

O Magic Pocket é uma arquitetura multi-zona, com clusters no oeste, no centro e no leste dos Estados Unidos. Cada bloco fica em pelo menos duas zonas, de forma independente, e é replicado dentro delas. A redundância protege contra desastres naturais e quedas em grande escala e cria domínios administrativos claros, para que um erro de configuração ou um colapso por congestionamento não se propague entre zonas.

Dentro de uma zona, os Frontends determinam onde um bloco deve ficar e emitem os comandos de leitura ou escrita. O Block Index mapeia cada bloco ao bucket onde ele está e é um grande cluster MySQL fragmentado. O plano original era um armazenamento chave-valor dedicado, mas o MySQL se mostrou mais que capaz, e o Dropbox já operava milhares de nós de banco de dados.

Um daemon replica de forma assíncrona as escritas de blocos de uma zona para a outra, e cada bloco chega à zona remota em até um segundo depois do upload local.

As células são clusters lógicos de armazenamento autocontidos, de cerca de 50 PB brutos cada; para ganhar espaço, normalmente sobe-se uma nova célula. Dentro dela, os OSDs são, para o resto do sistema, nós simples: guardam blocos sem entender a topologia da célula nem participar de protocolos distribuídos. A Replication Table mapeia cada bucket ao volume e aos OSDs que o guardam. Um volume aberto aceita escrita de dados novos e nada além; um volume fechado é imutável e pode ser movido com segurança.

O Master é o coordenador da célula e monitora a saúde dos OSDs. Roda-se um único Master por célula, o que dá um ponto central de coordenação para decisões de posicionamento sem a complexidade de um protocolo distribuído. O custo é um teto: a célula comporta cerca de cem petabytes antes de CPU e memória do Master virarem gargalo, e ter várias células ajuda na implantação e no isolamento contra falhas em cascata. A célula continua servindo leituras se o Master cair. Ele é soft-state, porque a Replication Table guarda o estado autoritativo dos volumes.

Os Volume Managers atendem a pedidos do Master para mover volumes e rodam no mesmo hardware dos OSDs para diluir sua demanda de rede em hardware ocioso.

1. No Put, o Frontend checa no Block Index se o bloco já existe e escolhe um volume de destino.

2. Em seguida o Frontend consulta a Replication Table para saber quais OSDs guardam o volume escolhido.

3. O Frontend manda comandos de gravação aos OSDs, que fazem fsync dos blocos antes de responder.

4. Com a gravação confirmada, o Frontend adiciona a entrada no Block Index e pode responder com sucesso ao cliente.

5. Nas falhas, se um OSD falha o Frontend tenta outro volume, talvez em outra célula; se o Block Index falha, encaminha o pedido à outra zona.

6. Em segundo plano, o replicador copia os blocos novos para a outra zona.

O Get é o caminho inverso: o Frontend busca célula e bucket no Block Index, volume e OSDs na Replication Table e lê de um dos OSDs, tentando de novo se algum estiver indisponível. Nos volumes com erasure coding, a codificação permite ler cada bloco inteiro de um único OSD, então a maioria das leituras toca um só disco.

05 · REPARO E VERIFICAÇÃO

Quando um disco falha e como saber que está tudo certo

O Master dispara o reparo quando um OSD fica offline por 15 minutos. Cada OSD guarda vários milhares de volumes, então perder um OSD permite reconstruir seus volumes a partir de centenas de outros OSDs ao mesmo tempo, o que distribui o tráfego de reconstrução por centenas de placas de rede e milhares de discos para minimizar o tempo de recuperação.

1. O Master vigia os OSDs e dispara o reparo quando um deles fica offline por 15 minutos.

2. A primeira ação do Master é fechar todos os volumes que estavam no OSD que falhou.

3. O Master monta um plano de reconstrução que escolhe origens e destinos de modo a espalhar a carga pelo maior número possível de OSDs.

4. Os Volume Managers copiam os dados das origens para os destinos, aplicando erasure coding quando necessário, e devolvem o controle ao Master.

5. No commit, o Master incrementa o número de geração nos volumes dos novos OSDs e então atualiza a Replication Table.

6. Se o Master falha antes do commit, o volume fica no local antigo e o novo Master repara de novo.

O modelo de volume aberto e fechado é a peça central: evita que o tráfego vivo interfira nas operações de fundo e permite protocolos de consistência mais simples do que se não houvesse essa divisão.

Quanto à durabilidade, um modelo de Markov com as taxas de falha de disco e os tempos de reparo esperados no pior caso leva o Dropbox a 27 noves. A própria empresa ressalva que replicação é necessária mas de modo algum suficiente, e cita outros modos de falha: desastres naturais, bugs de software, erro de operador e mudanças de configuração ruins.

O Dropbox investe pesado em verificação: mais de 50% da carga de discos e bancos é tráfego interno de verificação. Com mais de meio milhão de discos em produção, eles falham de formas variadas. Ao detectar um disco ruim, o sistema re-replica os dados, em geral em menos de uma hora, mas uma falha não detectada ampliaria a janela de vulnerabilidade de horas para potencialmente meses. O disk scrubber, por exemplo, lê continuamente cada bit do disco e valida contra checksums, com uma varredura completa aproximadamente a cada uma a duas semanas.

Há também a proteção chamada trash. Ao receber a ordem de apagar um extent, o nó apenas o move para uma área temporária (trash). O Trash Inspector percorre os blocos dessas áreas e confere no Block Index, e, passada a inspeção, o extent ainda fica um dia no disco antes de ser removido.

06 · CAMADA FRIA

Pagando menos pela replicação entre regiões

O acesso a arquivos esfria depressa: mais de 40% das leituras são de dados enviados no último dia, mais de 70% no último mês e mais de 90% no último ano. O Dropbox chama de quente o dado acessado com frequência e de frio o pouco acessado, e a diferença abre espaço para otimizar custo por classe de dado.

No envio de um arquivo usa-se replicação n-way em muitos nós e, depois, em segundo plano, codifica-se o dado mais antigo com erasure coding. Já a replicação entre data centers a milhares de milhas de distância equivale, na prática, a armazenar o dobro do dado para sobreviver melhor a desastres de grande escala.

Os requisitos da camada fria eram claros: não abrir mão de durabilidade nem de disponibilidade de leitura, enquanto a disponibilidade de escrita não importa. Como as escritas dos usuários vão para a camada quente, a fria pode pausar escritas a qualquer momento sem afetar usuários, e o dado é migrado de forma assíncrona quando esfria.

A primeira tentativa foi um único erasure code abrangendo todas as regiões, com uma só instância de software. O maior problema apontado foi não conseguir mitigar de fato o risco de durabilidade: com uma única região lógica rodando uma única versão de software, um bug poderia apagar tudo, não importa quantas cópias existissem. O projeto foi encerrado depois de mais de nove meses de trabalho ativo.

Outra ideia, vinda do sistema de blobs mornos do Facebook, era parear cada bloco com um parceiro em outra região geográfica e guardar o XOR dos dois em uma terceira. O Dropbox desistiu logo depois de explorá-la de novo: manter a estrutura global de pares trazia desafios próprios, e os padrões de exclusão imprevisíveis exigiam um processo para recuperar espaço quando um dos blocos fosse apagado.

A nova solução manteve a arquitetura interna de cada região e dividiu o bloco em fragmentos distribuídos entre as regiões. No exemplo de três regiões, o primeiro fragmento vai à região 1, o segundo à região 2 e o XOR deles, como fragmento de paridade, à região 3.

1. Conforme o dado esfria, a migração assíncrona o move em segundo plano da camada quente para a fria.

2. No exemplo de três regiões, o bloco vira dois fragmentos de dados e um fragmento de paridade, o XOR dos dois, cada um em uma região.

3. No Get, o leitor pede às três regiões, espera as duas respostas mais rápidas e cancela a restante.

4. Se uma região está fora, a migração simplesmente pausa até as três voltarem.

5. Para apagar, cada região remove seus fragmentos de forma independente, com versões diferentes do deleter e em horários diferentes.

Na latência, nos percentis 25, 50, 75 e 95 a diferença entre a camada fria e a quente ficou constante em cerca de um round-trip de rede. No percentil 99, porém, a fria teve latência de cauda menor. A explicação do Dropbox é que a camada fria obtinha as duas respostas mais rápidas de três, enquanto a quente tinha uma lógica de retry mais ingênua, que buscava na região mais próxima e só pedia à outra se a primeira tentativa falhasse ou expirasse. Depois, o Dropbox ajustou a quente para disparar otimisticamente um retry na segunda região se a primeira tentativa não chegasse dentro de um orçamento de tempo.

Há uma propriedade elegante: a camada fria sempre exercita o pior caso, porque toda leitura reconstrói a partir de vários fragmentos. Uma queda de região não causa grandes mudanças de tráfego nem aumento de I/O de disco nas regiões sobreviventes.

Na durabilidade, cada região segue independente e com versões de software diferentes, o que ajuda a detectar problemas antes de afetarem todas as cópias. Antes de purgar da camada quente, o Dropbox faz várias rodadas de validação.

A conta de custo: a camada quente é um esquema 1+1 e a fria, no exemplo de três regiões, é 2+1. O fator total de replicação é 2 vezes o fator interno da região na quente e 1,5 vez na fria, o que reduz o uso de disco em 25%. Com quatro regiões tolerando a perda de qualquer uma, o modelo seria 3+1, com 33% de economia.

07 · LIÇÕES

O que levar para uma entrevista

O próprio Dropbox resume o princípio central como manter simples, e a maior parte do Magic Pocket foi construída por um time de menos de meia dúzia de pessoas. A empresa também lembra que a decisão técnica deve ser a solução certa para o problema certo, e não escolhida por ser nova e legal.

Três padrões se repetem no caso: isolar domínios de falha (zonas, células, regiões independentes), separar dado imutável de lógica de mutação e mover o dado para um esquema mais barato conforme ele esfria. Esta síntese é leitura de estudo, não afirmação do Dropbox.