Continuando nossa série de posts sobre Amazon Web Services, hoje temos informações sobre o S3.
Se você não estava acompanhando a série, recomendo começar do
início.
Amazon S3 (Simple Storage Service) é o serviço padrão de armazenamento em nuvem da AWS, oferecendo armazenamento de arquivos de números arbitrários de arquivos de quase todos os tamanhos, de 0 a 5 TB (antes de
2011 O tamanho máximo era de 5 GB; tamanhos maiores agora são bem suportados via
multipart support).
Itens ou objetos são colocados em recipientes nomeados armazenados com nomes normalmente chamados de chaves. O conteúdo principal é o valor.
Os objetos (arquivos) podem ser criados, excluídos ou atualizados. Os objetos grandes podem ser transmitidos, mas você não pode acessar ou modificar partes de um valor; você precisa atualizar todo o objeto.
Todo objeto também tem
metadados, que incluem pares de valores-chave arbitrários, usados de forma semelhante aos cabeçalhos HTTP. Alguns metadados são definidos pelo sistema, alguns são significativos ao fornecer conteúdo HTTP a partir de
buckets ou CloudFront, e você também pode definir metadados arbitrários para seu próprio uso.
URIs S3: embora muitas vezes os nomes de bucket e chave sejam fornecidos nas APIs individualmente, também é prática comum escrever uma localização S3 no formato ‘s3://bucket-name/path/to/key’ (onde a chave aqui é ‘path/to/key’). Você também encontra os prefixos ‘s3n://’ e ‘s3a://’ em sistemas Hadoop .
S3 vs Glacier, EBS e EFS: a AWS oferece muitos serviços de armazenamento, e vários além do S3 oferecem abstrações de tipo de arquivo.
Glacier é para armazenamento de arquivos mais baratos e menos acessados.
EBS, ao contrário do S3, permite o acesso aleatório ao conteúdo do arquivo através de um sistema de arquivos tradicional, mas só pode ser anexado a uma instância EC2 por vez.
EFS É um sistema de arquivos de rede em que muitas instâncias podem se conectar, mas a um custo maior. Veja a tabela de comparação mais abaixo.
Dicas para usar melhor o S3
-
Para fins mais práticos, você pode considerar a capacidade S3 ilimitada, tanto no tamanho total dos arquivos quanto no número de objetos. O número de objetos em um bucket é essencialmente ilimitado. Os clientes rotineiramente têm milhões de objetos.
-
Nomeação do
bucket: há um espaço de nomes global (em todas as regiões, mesmo que o próprio S3 armazene dados em
qualquer região S3 que você escolha), então você verá que muitos nomes de
bucket já foram escolhidos. Criar um
bucket significa adotar o nome até que você o exclua. Os nomes têm
algumas restrições.
-
Os nomes podem ser usados como parte do nome do host ao acessar o
bucket ou seus conteúdos, como .s3-us-east-1.amazonaws.com, contanto que o nome seja
compatível com o DNS.
-
Uma prática comum é usar o acrônimo ou abreviatura do nome da empresa para o prefixo (ou sufixo, se você preferir a hierarquia do estilo DNS) todos os nomes do bucket (mas, por favor, não use isso como uma medida de segurança – isso não é muito seguro e facilmente burlado!).
-
Versão: S3 tem
suporte de versão opcional, de modo que todas as versões de objetos sejam preservadas em um
bucket. Isto é útil se você quiser um controle de mudanças (mas cuidado: não se trata de um sistema de controle de versão completo como o Git).
-
Durabilidade: a durabilidade do S3 é extremamente alta, pois internamente ele mantém várias réplicas. Se você não o exclui por acidente, você pode contar que o S3 não vai perder seus dados (AWS oferece a taxa de durabilidade aparentemente improvável de
99.999999999%, mas este é um cálculo matemático baseado em taxas de falha independentes e níveis de replicação – não uma estimativa de probabilidade verdadeira. De qualquer forma, a S3 teve
um recorde muito bom de durabilidade.) Observe que esta é uma durabilidade muito maior do que o EBS! Se a durabilidade for menos importante para sua aplicação, você pode usar o
S3 Reduced Redundancy Storage, O que diminui o custo por GB, bem como a redundância.
-
Para transferência, colocar dados na AWS é gratuito. Transfira de S3 para EC2 na mesma região gratuitamente também. Transferir para outras regiões ou pela Internet em geral não é gratuito.
-
As exclusões são gratuitas.
-
S3 com redundância reduzida e acesso pouco frequente: a maioria das pessoas usa a classe de armazenamento padrão no S3, mas existem outras classes de armazenamento com menor custo:
-
Reduced Redundancy Storage (RRS) vem sendo efetivamente obsoleto, E tem menor durabilidade (99,99%) do que o padrão S3. Observe que já não participa nas reduções de preços S3, por isso oferece uma pior redundância por mais dinheiro do que o padrão S3. Como resultado, não há motivo para usá-lo.
-
Infrequent Access (IA) permite que você obtenha um armazenamento mais barato em troca de um acesso mais caro. Isso é ótimo para arquivos como logs que você já processou, mas pode querer ver mais tarde. Para ter uma idéia da economia de custos ao usar o Infrequent Access (IA), você pode usar a
Calculadora S3 Infrequent Access.
-
Glacier é uma terceira alternativa que vai ser abordada em outro texto.
-
Desempenho: maximizar o desempenho do S3 significa melhorar o rendimento global em termos de largura de banda e número de operações por segundo.
-
S3 é altamente escalável, então, em princípio, você pode obter arbitrariamente alta taxa de transferência. (Um bom exemplo disso é o
S3DistCp.)
-
Mas geralmente você é limitado pelo canal entre a fonte e S3 e/ou o nível de concorrência das operações.
-
O throughput é, naturalmente, o mais alto entre AWS e S3, e entre instâncias EC2 e buckets S3 que estão na mesma região.
-
A largura de banda da EC2 depende do tipo de instância. Veja a coluna “Desempenho de rede” no
ec2instances.info.
-
A transferência de muitos objetos é extremamente alta quando os dados são acessados de forma distribuída, de muitas instâncias EC2. É possível ler ou escrever objetos de S3 de centenas ou milhares de instâncias ao mesmo tempo.
-
No entanto, o throughput é muito limitado quando os objetos acessados sequencialmente de uma única instância. As operações individuais levam muitos milissegundos e a largura de banda para e de instâncias é limitada.
-
Portanto, para executar um grande número de operações, é necessário usar vários segmentos e conexões de trabalho em instâncias individuais, e para trabalhos maiores, várias instâncias EC2 também.
-
Uploads de várias partes: para objetos grandes, você deseja aproveitar as capacidades de upload de múltiplas partes (começando com tamanhos mínimos de 5 MB).
-
Grandes downloads: também você pode fazer o download de pedaços de um único objeto grande em paralelo, explorando a capacidade de cabeçalho de intervalo HTTP GET.
-
Nós listamos isso como uma recomendação, pois muitas vezes é trabalhoso renomear em larga escala.
-
Observe que, infelizmente, o conselho sobre nomes de chaves aleatórias vai contra ter um layout consistente com prefixos comuns para gerenciar ciclos de vida de dados de forma automatizada.
-
Para dados fora da AWS,
DirectConnect e
S3 Transfer Acceleration podem ajudar. Para
S3 Transfer Acceleration, você paga o equivalente a 1-2 meses de armazenamento para a transferência em qualquer direção para usar pontos de mais próximos.
-
Aplicativos de linha de comando: existem algumas maneiras de usar S3 a partir da linha de comando:
-
Originalmente,
s3cmd foi a melhor ferramenta para o trabalho. Ainda é muito usado por muitos.
-
A interface de linha de comando da
AWS agora oferece suporte ao S3 bem, e é útil para a maioria das situações.
-
s4cmd é uma substituição, com maior ênfase no desempenho através de multi-threading, o que é útil para arquivos grandes e grandes conjuntos de arquivos, e também oferece compatibilidade com o Unix.
-
Aplicações GUI: você pode preferir uma GUI, ou deseja suportar acesso GUI para usuários menos técnicos. Algumas opções:
-
A
AWS Console oferece uma maneira gráfica de usar o S3. Tenha cuidado para dizer às pessoas não-técnicas que o utilizem, pois, uma vez que sem permissões rígidas, oferece acesso a muitos outros recursos AWS.
-
Transmit é uma boa opção no MacOS para a maioria dos casos de uso.
-
Cyberduck É uma boa opção no MacOS e no Windows com suporte para carregamentos de várias partes, ACLs, versões, configuração do ciclo de vida, classes de armazenamento e criptografia do lado do servidor (SSE-S3 e SSE-KMS).
-
S3 e CloudFront: S3 está bem integrado com o CloudFront CDN.
-
Hospedagem estática de sites:
-
Considere usar o CloudFront antes da maioria ou de todos os recursos:
-
Como qualquer CDN, o CloudFront melhora significativamente o desempenho.
-
Se você estiver incluindo recursos em domínios, como fontes dentro de arquivos CSS, talvez seja necessário
configurar o CORS para o
bucket que serve esses recursos.
-
Uma vez que praticamente tudo está se movendo para o SSL atualmente, e você provavelmente deseja controlar o domínio, você provavelmente deseja configurar o CloudFront com seu próprio certificado antes do S3 (e ignorar o
exemplo do AWS sobre isso como não é SSL apenas).
-
É importante gerenciar as permissões com cuidado no S3 se você tiver sensibilidade de dados, pois corrigir isso mais tarde pode ser uma tarefa difícil, se você tiver muitos ativos e usuários internos.
-
Descreva novos buckets se você tiver diferentes sensibilidades de dados, pois isso é muito menos propenso a erros do que regras de permissões complexas.
-
Se os dados são apenas para administradores, como dados de log, coloque-o em um bucket em que só os administradores podem acessar.
-
Limite o acesso individual do usuário (ou IAM) ao S3 ao mínimo exigido e catalogue os locais “aprovados”. Caso contrário, o S3 tende a se tornar o campo de despejo onde as pessoas colocam dados em locais aleatórios que não são limpos há anos, custando-lhe muito dinheiro.
-
Ciclos de vida dos dados:
-
Ao gerenciar dados, a compreensão do ciclo de vida dos dados é tão importante quanto a compreensão dos dados em si. Ao colocar os dados em um bucket, pense em seu ciclo de vida – o fim da vida, e não apenas o seu início.
-
Em geral, os dados com diferentes políticas de expiração devem ser armazenados sob prefixos separados no nível superior. Por exemplo, alguns registros volumosos podem precisar ser excluídos automaticamente mensalmente, enquanto outros dados são críticos e nunca devem ser excluídos. Ter o primeiro em um bucket separado ou pelo menos uma pasta separada é sábio.
-
Pense sobre isso na frente, você vai poupar dor. É muito difícil limpar grandes coleções de arquivos criados por muitos engenheiros com diferentes ciclos de vida e nenhuma organização coerente.
-
Alternativamente, você pode definir uma política de ciclo de vida para arquivar dados antigos para o Glacier. Tenha cuidado com o arquivamento de grandes quantidades de objetos pequenos para o Glacier, pois pode custar mais caro.
-
Há também uma classe de armazenamento chamada
Infrequent Access Que tem a mesma durabilidade que o padrão S3, mas é descontado por GB. É adequado para objetos que são acessados com pouca frequência.
-
Consistência dos dados: entender
consistência de dados é importante para qualquer uso de S3, onde existem vários produtores e consumidores de dados.
-
A criação de objetos individuais em S3 é atômica. Você nunca enviará um arquivo e terá outro cliente para ver apenas metade do arquivo.
-
Além disso, se você criar um novo objeto, você poderá lê-lo instantaneamente, o que é chamado consistência de leitura e gravação.
-
Bem, com a advertência adicional de que, se você fizer uma leitura em um objeto antes de existir, e então criá-lo,
você obtém consistência (not read-after-write).
-
Se você sobrescrever ou excluir um objeto, você só terá garantia de consistência.
-
Note que
até 2015, a região ‘us-standard’ Teve um modelo de consistência eventual mais fraco, e as outras regiões (mais novas) foram read-after-write. Isso foi finalmente corrigido – mas observe vários blogs antigos que mencionam isso!
-
Na prática, a “eventual consistência” geralmente significa em segundos, mas casos raros de esperas de minutos ou
horas.
-
S3 como um sistema de arquivos:
-
Em geral, as APIs do S3 têm limitações inerentes que tornam o S3 difícil de usar diretamente como um sistema de arquivos de estilo POSIX enquanto ainda preserva o próprio formato de objeto do S3. Por exemplo, anexar a um arquivo requer reescrever, o que afeta o desempenho e a renomeação atômica de diretórios, a exclusão mútua na abertura de arquivos e os links rígidos são impossíveis.
-
s3fs É um sistema de arquivos FUSE que vai adiante e tenta de qualquer maneira, mas tem limitações de desempenho e surpresas por essas razões.
-
Riofs (C) e
Goofys (Go) são mais recentes e tentam adotar um formato de armazenamento de dados diferente para resolver esses problemas e, portanto, são prováveis melhorias em s3fs.
-
S3QL (
discussão) é uma implementação Python que oferece deduplicação de dados, snapshots e criptografia, mas apenas um cliente por vez.
-
ObjectiveFS (
discussion) é uma solução comercial que suporta funcionalidades do sistema de arquivos e clientes concorrentes.
-
Se você estiver usando um VPC (conexões privadas não acessíveis via Internet), considere configurar um
VPC Endpoint para o S3, a fim de permitir que seus recursos hospedados pelo VPC acessem facilmente sem a necessidade de configuração de rede adicional ou de saltos.
-
Replicação entre regiões: S3 tem
um recurso para replicar um
bucket entre uma região e outra. Note-se que o S3 já é altamente replicado dentro de uma região, por isso geralmente isso não é necessário para durabilidade, mas pode ser útil para conformidade (armazenamento de dados distribuído geograficamente), menor latência ou como estratégia para reduzir os custos da largura de banda região-a-região refletindo dados altamente usados em uma segunda região.
-
IPv4 vs IPv6: por muito tempo, S3 apenas suportou IPv4 no ponto final padrão https://BUCKET.s3.amazonaws.com. Entretanto,
a partir de 11 de agosto de 2016 Agora oferece suporte tanto IPv4 quanto IPv6! Para usar ambos, você tem que
ativar dualstack no seu cliente de API preferido ou usando diretamente esse esquema de URL https://BUCKET.s3.dualstack.REGION.amazonaws.com. Isso se estende até a aceleração de transferência S3 também.
Problemas e Limitações
-
Durante muitos anos, houve um notório
limite de 100 buckets por conta, que não poderia ser aumentado e causou muita dor de cabeça significativa nas empresas. Desde 2015, você pode solicitar aumentos. Você pode pedir para aumentar o limite, mas ainda será limitado (geralmente abaixo de ~ 1000 por conta).
-
Tenha cuidado para não fazer suposições implícitas sobre transacionalidade ou sequenciação de atualizações de objetos. Nunca assuma que, se você modificar uma sequência de objetos, os clientes verão as mesmas modificações na mesma sequência, ou se você carregar um monte de arquivos, todos aparecerão de uma só vez em todos os clientes.
-
S3 tem um
SLA Com 99,9% de tempo de atividade. Se você usa o S3 pesadamente, você verá inevitavelmente erros ocasionais de acesso ou armazenamento de dados à medida que os discos ou outras infra-estruturas falharem. A disponibilidade geralmente é restaurada em segundos ou minutos. Embora a disponibilidade não seja extremamente alta, como mencionado acima, a durabilidade é excelente.
-
Depois de fazer o upload, qualquer alteração que você faz no objeto causa uma reescrita completa do objeto, de modo que evite o comportamento de anexação com arquivos regulares.
-
A consistência dos dados externos, como discutido acima, pode ser surpreendente às vezes. Se S3 sofre de problemas internos de replicação, um objeto pode ser visível a partir de um subconjunto das máquinas, dependendo do ponto final do S3 que eles atingiram. Esses geralmente resolvem em segundos; No entanto, há casos isolados quando a questão permaneceu por 20 a 30 horas.
-
MD5s e carregamentos de várias partes: no S3, o
cabeçalho ETag da S3 é um hash no objeto. E em muitos casos, é o hash MD5. No entanto, isso
não é geral quando você usa uploads de várias partes. Uma solução alternativa é calcular MD5s você mesmo e colocá-los em um cabeçalho personalizado (como é feito pelo
s4cmd).
-
Custos incompletos de upload de várias partes: os carregamentos incompletos de várias partes causam
taxas de armazenamentos mesmo se o upload falhar e nenhum objeto S3 for criado.
Amazon (
e outros) recomendam usar uma política de ciclo de vida para limpar carregamentos incompletos e economizar em custos de armazenamento.
-
Região padrão dos EUA: anteriormente, a região us-east-1 (também conhecida como a região padrão dos EUA) foi replicada em todas as costas, o que levou a uma maior variabilidade de latência. Em vigor desde 19 de junho de 2015, isso
não é mais válido. Todas as regiões do Amazon S3 agora oferecem suporte à consistência de leitura e gravação. O Amazon S3 também renomeou a região padrão dos EUA para a região dos EUA (N. Virgínia) para ser consistente com as convenções de nomeação regional da AWS.
-
Quando configurar ACLs sobre quem pode acessar o
bucket e conteúdo, existe um grupo predefinido chamado
Usuários Autenticados. Esse grupo geralmente é usado, de forma incorreta, para restringir o acesso de recursos S3 a usuários autenticados da conta proprietária. Se concedido, o grupo AuthenticatedUsers permitirá o acesso de recursos S3 a todos os usuários autenticados, em todas as contas AWS. Um caso de uso típico desta ACL é usado em conjunto com
o solicitador que paga a funcionalidade do S3.
Durabilidade, Disponibilidade e Preço de Armazenamento
Como ilustração de características e preços comparativos, a tabela abaixo fornece S3 Standard, RRS, IA, em comparação com Glacier, EBS, e EFS, usando a região da Virgínia a partir de agosto de 2016.
|
Durabilidade (por ano)
|
Disponibilidade “projetada”
|
Disponibilidade SLA
|
Armazenamento (por TB por mês)
|
GET or retrieve (por milhão)
|
Escrever ou arquivar (por milhão)
|
|
Glacier
|
Onze 9s
|
Lento
|
–
|
$4
|
$50
|
$50
|
|
S3 IA
|
Onze 9s
|
99.9%
|
99%
|
$12.50
|
$1
|
$10
|
|
S3 RRS
|
99.99%
|
99.99%
|
99.9%
|
$24 (first TB)
|
$0.40
|
$5
|
|
S3 Standard
|
Onze 9s
|
99.99%
|
99.9%
|
$23
|
$0.40
|
$5
|
|
EBS
|
99.8%
|
Não informada
|
99.95%
|
|
|
|
|
EFS
|
“Alta”
|
“Alta”
|
–
|
$300
|
|
|
