Fundamentos da computação em nuvem
Serviços de armazenamento
Armazenamento de objetos, blocos e arquivos: como cada um organiza os dados de um jeito diferente, qual carga de trabalho cada um encaixa de verdade, e o erro clássico de prova de tratá-los como intercambiáveis.
- Diferenciar armazenamento de objetos, blocos e arquivos pela forma como cada um organiza e concede acesso aos dados
- Combinar um tipo de armazenamento com uma carga de trabalho a partir do seu padrão de acesso
- Explicar por que durabilidade e disponibilidade são 2 garantias separadas, não uma só
- Identificar os produtos de armazenamento de objetos, blocos e arquivos da AWS, da Azure e do Google Cloud
A mesma palavra, 3 trabalhos bem diferentes
"Armazenamento" parece uma coisa só até você precisar dele de verdade. Um aplicativo de fotos guardando 50 milhões de imagens de usuários, um banco de dados escrevendo milhares de pequenas atualizações por segundo, e 5 servidores web que precisam ler a mesma pasta compartilhada de configuração são 3 problemas completamente diferentes, e nenhum design único de armazenamento resolve os 3 bem. Os provedores de nuvem oferecem 3 tipos distintos de armazenamento exatamente por isso: objeto, bloco e arquivo. Diferenciá-los pelo que cada um foi feito para fazer, não só pelo nome, é a habilidade que esta lição ensina.
Armazenamento de objetos: buckets cheios de arquivos marcados
Comece pelo aplicativo de fotos. Cada imagem é enviada uma vez, lida muitas vezes depois, e nunca editada no lugar: você substitui uma foto, não modifica 4KB dela. O Amazon S3, o modelo do armazenamento de objetos, organiza os dados exatamente nesse padrão: um bucket é um contêiner, e cada arquivo dentro dele é um objeto, endereçado por uma chave única em vez de um caminho de pasta. Não existe uma hierarquia real de pastas por baixo, só um namespace plano onde a chave "fotos/ferias/praia.jpg" parece um caminho, mas é só uma string.
Armazenamento de objetos troca a edição no lugar por escala massiva, custo baixo e durabilidade forte: o S3 é projetado para 99,999999999% (11 noves) de durabilidade, obtida ao guardar dados de forma redundante entre várias zonas de disponibilidade. Essa combinação é por isso que armazenamento de objetos é a escolha padrão para data lakes, backups, ativos de sites estáticos e arquivos de mídia: cargas definidas por escrever uma vez e ler com frequência, não por edições pequenas e constantes.
Armazenamento de blocos: pedaços numerados para uma máquina
Agora pense em um banco de dados relacional escrevendo e reescrevendo linhas o tempo todo. Essa carga precisa de baixa latência e da capacidade de mudar pequenos pedaços de dado no lugar, exatamente o que armazenamento de objetos não oferece. Armazenamento de blocos, modelado no Amazon EBS, divide um volume em pedaços de tamanho fixo, endereçados por número, e conecta esse volume a uma única instância, do mesmo jeito que um disco rígido se conecta a um único computador. O sistema operacional rodando naquela instância pode formatar o volume, montá-lo e tratá-lo como disco local, porque, na prática, é exatamente isso que ele é.
Armazenamento de blocos é zonal: um volume EBS vive em 1 zona de disponibilidade específica e só se conecta a instâncias naquela mesma zona, exatamente por isso um banco de dados sentado sobre um único volume EBS ainda precisa da própria estratégia de replicação ou backup para sobreviver a uma falha de zona. Em troca dessa restrição, armazenamento de blocos entrega o desempenho de baixa latência e alto IOPS que um banco de dados em execução, ou o próprio disco de boot de uma máquina virtual, realmente precisa.
Armazenamento de arquivos: uma árvore de pastas, várias máquinas ao mesmo tempo
O terceiro cenário, 5 servidores web compartilhando o mesmo diretório de configuração, precisa de algo que nenhum dos outros 2 oferece diretamente: acesso simultâneo de várias máquinas à mesma estrutura hierárquica de pastas. Armazenamento de arquivos, modelado no Amazon EFS, resolve isso usando um protocolo de sistema de arquivos em rede (NFS), de forma que todo servidor monta o mesmo sistema de arquivos e vê as mesmas pastas e arquivos, com mudanças de um visíveis para os outros de imediato. Diferente de um volume EBS de conexão única, um sistema de arquivos como o EFS escala automaticamente conforme dados são adicionados e pode ser montado por várias instâncias EC2, contêineres e até servidores locais ao mesmo tempo.
A fronteira, lado a lado
| Propriedade | Objeto | Bloco | Arquivo |
|---|---|---|---|
| Dados organizados como | Namespace plano de objetos endereçados por chave | Blocos numerados de tamanho fixo | Pastas e arquivos hierárquicos |
| Conecta-se a | Acessado pela rede por qualquer cliente autorizado | Uma instância por vez (tipicamente) | Várias instâncias ao mesmo tempo |
| Melhor padrão de acesso | Escrever uma vez, ler com frequência, sem edição no lugar | Leituras e escritas frequentes e pequenas, baixa latência | Leituras e escritas compartilhadas entre máquinas |
| Uso típico | Backups, mídia, data lakes, ativos estáticos | Bancos de dados, volumes de boot, cargas transacionais | Conteúdo compartilhado, diretórios home, configuração compartilhada entre uma frota |
| Produto AWS | S3 | EBS | EFS |
| Produto Azure | Blob Storage | Managed Disks | Azure Files |
| Produto Google Cloud | Cloud Storage | Persistent Disk | Filestore |
Exemplo prático: 1 site de e-commerce, 3 decisões de armazenamento
Uma plataforma de e-commerce precisa guardar 3 tipos diferentes de dado, e a resposta certa muda a cada vez. Fotos de produto, milhões delas, enviadas uma vez e servidas a compradores o tempo todo: armazenamento de objetos, porque nada em uma foto de produto precisa de edição no lugar, e o volume favorece a escala e o custo do armazenamento de objetos. O banco transacional que rastreia pedidos e estoque: armazenamento de blocos, porque cada checkout escreve e reescreve linhas e precisa da baixa latência que só um volume conectado diretamente entrega. Um diretório compartilhado de arquivos de cache de sessão que 6 servidores web idênticos atrás de um load balancer precisam ler e escrever juntos: armazenamento de arquivos, porque é o único dos 3 feito para acesso simultâneo de várias instâncias à mesma árvore de pastas.
Troque 2 dessas escolhas de lugar e o sistema ou quebra de vez, um banco não roda de forma aceitável sobre armazenamento de objetos, ou funciona mas desperdiça dinheiro e desempenho em um descompasso que não precisava existir.
A armadilha: mais barato não significa intercambiável
É tentador olhar para o preço baixo por gigabyte do armazenamento de objetos e concluir que ele é simplesmente a "opção econômica" que dá para trocar em qualquer lugar. Não é. Armazenamento de objetos é barato exatamente porque abre mão do acesso aleatório de baixa latência no lugar que um banco de dados em execução ou um volume de boot dependem. Mover os arquivos de dados de um banco para armazenamento de objetos não economiza dinheiro em um sistema funcionando, produz um sistema que não funciona, porque o tipo de armazenamento e o padrão de acesso precisam combinar. Preço é consequência da troca, não substituto para entendê-la.
Onde isso deixa você
3 perguntas resolvem quase qualquer decisão de armazenamento: o dado é editado no lugar ou só escrito uma vez e lido, ele precisa ser compartilhado por várias máquinas ao mesmo tempo, e ele precisa dar boot ou rodar um sistema operacional diretamente. Armazenamento de objetos responde "escrito uma vez, lido com frequência, sem exigência de compartilhamento". Armazenamento de blocos responde "conectado a uma máquina, editado o tempo todo, precisa de velocidade". Armazenamento de arquivos responde "pasta compartilhada, várias máquinas". A próxima lição sai do armazenamento bruto para a camada com a qual a maioria das aplicações realmente conversa direto: bancos de dados.