Entendendo o Cloud Storage: GCS

O propósito do Google Cloud Storage é persistir e recuperar dados binários como entidades inteiras. Se essa entidade estivesse no seu computador, você a chamaria de arquivo; já no GCS, ela é chamada de objeto. Ao contrário dos arquivos no seu computador, os objetos do GCS são imutáveis e nunca podem ser alterados.

Objetos do GCS podem ser excluídos ou substituídos, mas não alterados. Essa característica pode ser explorada em diversos designs de arquitetura em escala de nuvem.

Os objetos do GCS também são opacos. O GCS não enxerga a estrutura interna dos objetos, pois eles são apenas sequências de dados binários. O GCS usa metadados associados para acompanhar aspectos do objeto, como data e hora de criação, tipo MIME e tamanho.

Os objetos do GCS são duráveis. O Google armazena objetos usando uma combinação de técnicas para garantir pelo menos 11 "9s", ou seja, 99,999999999% de durabilidade anual em uma região. (Para se proteger contra perdas decorrentes de desastres locais, naturais ou causados pelo ser humano, o usuário pode optar por armazenar dados em várias regiões ou até em várias nuvens.) Onze 9s significa que um bilhão de objetos armazenados por 100 anos resultaria em, no máximo, uma perda.

Os objetos do GCS são disponíveis. Estar disponível significa que o GCS consegue entregar um objeto sob demanda. O GCS oferece diferentes opções de SLA para disponibilidade mensal: 99,95%, 99,9% ou 99,0%. Em tempo, isso equivale a 22 minutos, 44 minutos ou 7 horas e 18 minutos de indisponibilidade por mês.

Os objetos do GCS ficam armazenados em buckets dentro de um projeto do GCP. Os buckets fornecem o contexto de armazenamento para os objetos, incluindo identidade, o projeto que os hospeda — vinculado a uma conta de cobrança e à segurança —, localização geográfica, diversas políticas e muito mais.

Um bucket do GCS tem um identificador globalmente único expresso como uma URI . O Google usa o esquema de URI gs: para buckets e objetos do GCS.

A sintaxe da URI é: gs:///

Por exemplo, gs://doit-intl-storage/logo.png é uma URI globalmente única.

O GCS tem um papel importante na arquitetura de muitos sistemas em nuvem. De modo geral, o GCS é a opção mais barata para guardar informações. Ainda assim, é preciso ficar de olho em latência, largura de banda e nas restrições tradicionais de arquitetura para manter a eficiência de custos.

Vale lembrar que o GCS é um serviço. O acesso é feito via API REST, que por sua vez é encapsulada por bibliotecas de cliente em diversas linguagens de programação, por uma CLI e por várias ferramentas de terceiros. O GCS não é um sistema de armazenamento em bloco. Ele não pode ser usado diretamente como sistema de arquivos para uma máquina virtual ou contêineres.

Vários fatores influenciam o custo de uso do Google Cloud Storage. Alguns dos principais a observar são:

• Tamanho do objeto
• Tempo de armazenamento
• Características do bucket: localização, redundância e classe de armazenamento
• Atividade, como gravação e leitura de um objeto e dos seus metadados
• Bytes trafegados em uma ou mais redes quando o objeto é transferido

Dá para pensar nos custos de duas formas. A primeira é quanto custa armazenar um objeto se nada for feito com ele — depois de gravado, não é lido nem excluído. Esse é o custo puro de armazenamento. A segunda são os custos por atividade, como leitura, transferência, exclusão, consulta etc.

Vamos aos números para entender melhor. Para o custo puro de armazenamento, vamos usar como exemplo um único objeto de 1 GiB armazenado por um ano. (Lembre-se de que 1 GiB = 1.073.741.824 bytes (= 10243 B = 230 B).)

O armazenamento padrão mais caro fica no Brasil: US$ 0,42, enquanto em muitos lugares o valor cai para US$ 0,24. O armazenamento padrão é a melhor escolha para objetos acessados com frequência. Para objetos inativos, os custos da classe archive são drasticamente menores: US$ 0,036 no Brasil e US$ 0,0144 em outros lugares.

Os custos por atividade podem surpreender quem está começando. Há cobranças para gravar no armazenamento, ler do armazenamento, listar objetos e excluir objetos antes do prazo (quando o objeto está em uma classe de armazenamento de longo prazo). Essas cobranças podem influenciar a engenharia e até a arquitetura de um sistema em escala de nuvem.

Por exemplo, prestei consultoria para uma empresa que administra imagens de satélite. O sistema on-premise deles armazenava muitos blocos pequenos de imagem. Ao migrar tudo para o GCS, perceberam que o design — ler blocos pequenos para montar uma imagem grande — gerava custos altíssimos por causa da atividade de leitura.

Eles refizeram o sistema para guardar menos imagens, porém maiores, e dividi-las em memória depois da leitura. É bem contraintuitivo, mas é a realidade do GCS.

Vou abordar o tema mais amplo de segurança em nuvem em outro artigo. A segurança do GCS é gerenciada pelo IAM. No passado, houve alguns vazamentos sérios porque era fácil demais conceder acesso público a um bucket por engano. O Google mudou isso e hoje existem vários avisos para evitar esse tipo de erro.

Para ficar por dentro, siga-nos no DoiT Engineering Blog , no canal da DoiT no LinkedIn e no canal da DoiT no Twitter . Para conhecer oportunidades de carreira, acesse https://careers.doit-intl.com .