Nesta página, você verá um índice de práticas recomendadas do Cloud Storage. É possível usar as informações coletadas aqui como uma referência rápida do que precisa ser lembrado ao criar um aplicativo que usa o Cloud Storage.
Se você é iniciante no Cloud Storage, esta página pode não ser o melhor lugar para começar, já que não ensina o básico sobre a utilização dele. Se você é um novo usuário, sugerimos que comece com Descobrir o armazenamento de objetos com o console do Google Cloud ou Descobrir o armazenamento de objetos com a ferramenta gcloud.
Nomenclatura
Consulte Nomeação de buckets e Nomeação de objetos para ver os requisitos e considerações de nomenclatura.
Tráfego
Faça uma estimativa do valor do tráfego que será enviado para o Cloud Storage. Pense especificamente em:
Operações por segundo. Quantas operações por segundo você espera, tanto para buckets e objetos, quanto para operações de criação, atualização e exclusão.
Largura de banda. Quantos dados serão enviados, em que período de tempo? Considere usar uma ferramenta como a Wolfram Alpha para evitar erros nos seus cálculos.
Controle de cache. Especificar os metadados
Cache-Controlem objetos acessíveis publicamente beneficiará a latência de leitura em objetos quentes ou acessados com frequência. Consulte a Como visualizar e editar metadados para instruções sobre como configurar metadados de objeto, comoCache-Control.
Projete seu aplicativo para minimizar picos no tráfego. Se houver clientes do seu aplicativo fazendo atualizações, distribua-os ao longo do dia.
Ao projetar aplicativos para altas taxas de solicitação, lembre-se dos limites de taxa para determinadas operações. Conheça os limites de largura de banda para determinados tipos de saída e siga as Diretrizes de taxa de solicitação e distribuição de acesso. Esteja ciente principalmente do escalonamento automático e da necessidade de aumentar gradualmente as taxas de solicitações para ter o melhor desempenho.
Ao lidar com erros:
Verifique se o aplicativo usa uma estratégia de repetição para evitar problemas devido a grandes bursts de tráfego.
Tente novamente usando uma nova conexão e, se possível, resolva novamente o nome do domínio. Isso ajuda a evitar a "aderência do servidor", em que uma nova tentativa tenta passar pelo mesmo caminho e atinge o mesmo componente não íntegro que a solicitação inicial atingiu.
Se seu aplicativo for sensível à latência, use solicitações protegidas. As solicitações protegidas permitem que você repita mais rapidamente e reduza a latência de cauda. Elas fazem isso sem reduzir o prazo da solicitação, o que pode fazer com que as solicitações expirem prematuramente. Para mais informações, consulte The Tail at Scale (em inglês).
Entenda o nível de desempenho que os clientes esperam do seu aplicativo. Essas informações ajudarão você a escolher uma opção de armazenamento e região ao criar novos buckets. Por exemplo, considere a possibilidade de colocar seus recursos de computação nos buckets do Cloud Storage para aplicativos de análise.
Opções de locais e armazenamento de dados
Consulte os tópicos Classe de armazenamento e Local do bucket para uma orientação sobre como armazenar melhor seus dados.
ACLs e controle de acesso
As solicitações do Cloud Storage se referem a buckets e objetos pelos nomes deles. Como resultado, mesmo que as ACLs impeçam a operação não autorizada de terceiros em buckets ou objetos, um terceiro pode tentar solicitações com nomes de bucket ou de objeto e determinar a existência deles observando as respostas de erro. Dessa forma, é possível que as informações em nomes de bucket ou de objeto vazem. Se você estiver preocupado com a privacidade de seus nomes de bucket ou de objeto, tome as precauções adequadas, como:
Escolher nomes de bucket e de objeto difíceis de adivinhar. Por exemplo, um bucket chamado
mybucket-gtbytul3é aleatório o suficiente, de modo que terceiros não autorizados não possam adivinhá-lo ou enumerar outros nomes de bucket a partir dele.Evitar usar informações confidenciais como parte de nomes de intervalos ou objetos. Por exemplo, em vez de nomear seu bucket como
mysecretproject-prodbucket, uso o nomesomemeaninglesscodename-prod. Em alguns aplicativos, convém manter metadados confidenciais em cabeçalhos personalizados do Cloud Storage, comox-goog-meta, em vez de codificá-los nos nomes de objetos.
É preferível usar grupos para listar explicitamente um grande número de usuários. Isso não só torna o escalonamento melhor, mas também fornece uma maneira muito eficiente de atualizar o controle de acesso para um número grande de objetos de uma só vez. Por fim, é mais barato porque você não precisa fazer uma solicitação por objeto para alterar as ACLs.
Leia e siga as práticas recomendadas de controle de acesso.
O sistema de controle de acesso do Cloud Storage inclui a capacidade de especificar se os objetos serão legíveis publicamente. Confirme se você pretende conceder acesso público a todos os objetos gravados. Uma vez "publicados", os dados na Internet podem ser copiados para muitos lugares, por isso é efetivamente impossível recuperar o controle de leitura sobre um objeto gravado com essa permissão.
O sistema de controle de acesso do Cloud Storage inclui a capacidade de especificar se os buckets serão graváveis publicamente. Mesmo que configurar um bucket público seja conveniente para vários fins, recomendamos não usar essa permissão. Ela pode propagar conteúdo ilegal, vírus e outros malwares, e o proprietário do bucket é legal e financeiramente responsável pelo conteúdo armazenado nos seus buckets.
Se você precisar disponibilizar o conteúdo com segurança para usuários que não têm contas de usuário, recomendamos que você use URLs assinados. Por exemplo, com URLs assinados, você pode fornecer um link para um objeto e os clientes do seu aplicativo não precisam se autenticar com o Cloud Storage para acessá-lo. Quando você cria um URL assinado, controla o tipo (leitura, gravação, exclusão) e a duração do acesso.
Uploads de dados
Se você usa callbacks XMLHttpRequest (XHR) para receber atualizações de progresso, não feche e reabra a conexão se detectar que o progresso parou. Isso cria um loop de feedback positivo inválido durante os períodos de congestionamento da rede. Quando a rede está congestionada, os callbacks XHR podem ficar atrasados em relação à atividade de confirmação (ACK/NACK) do fluxo de upload, e fechar e reabrir a conexão quando isso acontece usa mais capacidade de rede exatamente no momento em que você menos pode arcar com isso.
Para o tráfego de upload, recomendamos a configuração de tempos limite razoavelmente longos. Para uma boa experiência do usuário final, é possível definir um timer do lado do cliente que atualiza a janela de status do cliente com uma mensagem (por exemplo, "congestionamento de rede") quando seu aplicativo não recebe um callback XHR por muito tempo. Não feche a conexão e tente novamente quando isso acontecer.
Uma maneira fácil e conveniente de reduzir a largura de banda necessária para cada solicitação é ativar a compactação no formato gzip. Embora isso exija mais Tempo de CPU para descompactar os resultados, a redução dos custos de rede normalmente faz com que esse método valha muito a pena.
Um objeto que foi enviado em gzip geralmente também pode ser exibido nesse formato. No entanto, evite fazer upload de conteúdo que tenha
content-encoding: gzipe umcontent-typecompactado, porque isso pode levar a um comportamento inesperado.Recomendamos o uso de uploads retomáveis, que permitem retomar a transferência de dados, mesmo quando uma falha de comunicação interrompe o fluxo de dados. Você também pode usar uploads de várias partes da API XML para fazer upload de partes de um arquivo em paralelo, o que pode reduzir o tempo para concluir o upload geral.
Exclusão de dados
Consulte Excluir objetos para ver diretrizes e considerações sobre a exclusão de dados. Também é possível usar recursos para controlar os ciclos de vida dos dados a fim de evitar que eles sejam excluídos por engano pelo software ou pelos usuários do seu aplicativo.