Devo persistir imagens no EBS ou S3?

Question

Estou migrando meu servidor Java, Tomcat e MySQL para o AWS EC2.

Eu já anexei um volume do EBS para armazenar dados do MySQL. Na minha aplicação web, as pessoas podem fazer upload de imagens, que eu deveria persistir.

Existem duas alternativas na minha mente:

1. Salve as imagens enviadas no volume do EBS.
2. Use o serviço S3.

As seguintes são as minhas notas, por favor, seja cético sobre elas, pois minha experiência não está nos servidores, mas no desenvolvimento de software.

• EBS mais : o armazenamento do S3 é mais caro. (0,15 $ / Gb > 0,1 $ / Gb)

• S3 plus : a exibição de arquivos estáticos do EBS pode influenciar negativamente o desempenho do meu servidor da web. Isso é verdade? A exibição de imagens afeta o desempenho de um servidor notavelmente? Para o S3, meu servidor não será responsável por fornecer arquivos estáticos.

• S3 mais : exibir arquivos estáticos do EBS pode resultar em custo de E / S, embora provavelmente seja menor.

• EBS mais : as pessoas dizem que o EBS é mais rápido.

• S3 mais : as pessoas dizem que o S3 é mais seguro para persistência.

• EBS mais : não há necessidade de aprender uma API: é simples salvar as imagens em um volume do EBS.

Eu não consigo decidir e estou pedindo orientação.

    

Answer 1

No que diz respeito aos custos, não é necessariamente verdade que o S3 irá custar mais do que o EBS. Se você tiver um volume EBS de 15 GB, pagará por todo esse armazenamento, se ele contiver 1 GB de dados ou até mesmo nenhum dado ainda. Com o S3, você paga apenas pelos dados reais armazenados.

Sua estratégia deve ser usar o EBS para o volume montado, mas sempre voltar ao EBS até o S3. No passado, havia uma maneira de usar o S3 mais cache para o volume montado (chamado PersistentFS), mas está extinto agora. Portanto, monte um volume do EBS e faça backup dele em S3.

Aqui estão alguns fatos para respaldar essa recomendação, bem como uma comparação geral entre EBS e S3:

• O EBS só pode ser usado com instâncias do EC2, enquanto o S3 também pode ser usado fora do EC2
• O EBS aparece como um volume montável, enquanto o S3 requer software para ler e gravar dados
• O EBS pode acomodar uma quantidade menor de dados que o S3
• O EBS só pode ser usado por uma instância do EC2 por vez, enquanto o S3 pode ser usado por várias instâncias
• O S3 normalmente experimenta atrasos de gravação enquanto o EBS não

• O S3 é redundante (6 cópias eu acho) enquanto o EBS não é. link

• Em termos de desempenho, o S3 tem a maior latência e também tem maior variação na latência. A latência de gravação do S3 também pode ser maior que a latência de leitura. EBS, por outro lado, tem menor latência com menos variação. Ele também possui cache de write-back para latência de gravação muito baixa. link

• O EBS (com 20 GB de dados modificados) tem uma taxa de falhas anual esperada de 0,1% a 0,5%.

• Com o EBS, você paga US $ 0,10 por GB por mês para o tamanho do volume, independentemente de ter armazenado dados nesse volume ou não.

• Com o S3, você paga US $ 0,15 por GB por mês para instantâneos - APENAS PARA DADOS ARMAZENADOS.

• A confiabilidade do EBS depende da manutenção de instantâneos recentes. Conforme descrito pela Amazon no link , a confiabilidade do EBS depende da quantidade de dados armazenados no volume que não foi feito backup para o S3 usando um instantâneo. Portanto, para obter durabilidade com o EBS, é importante manter os dados no volume de backup para o S3, tirando fotos frequentes.

• Você pagará US $ 0,10 por GB por mês para o tamanho do volume do EBS, mais US $ 0,15 por GB por mês para os snapshots do S3. Mas vários instantâneos são armazenados de forma incremental. Se você tiver um dispositivo com 100 GB de dados, mas somente 5 GB de dados tiverem sido alterados desde o último instantâneo, apenas os 5 GB adicionais de dados de instantâneos serão armazenados novamente no Amazon S3. link

Answer 2

1. Custos: Manter imagens no S3 custará mais caro, especialmente se você usar o CloudFront. A Amazon cobra pelo tráfego e pelas solicitações GET / PUT e pelo custo das solicitações GET / PUT, que pode ser ainda maior do que os custos de tráfego para arquivos pequenos.

2. O que é mais seguro? O S3 é realmente um armazenamento mais seguro do que o EBS, de acordo com a Amazon, mas eu acho que não é um grande problema, pois você pode facilmente fazer backup do EBS no S3 periodicamente.

3. API: A API do S3 é bastante simples e não é um grande problema salvar um arquivo no S3.

4. Segurança. É mais seguro hospedar arquivos enviados por usuários além do aplicativo da Web - é mais difícil enviar conteúdo malicioso para o seu servidor de aplicativos da Web para hackers.

5. Velocidade. Eu não acho que o EBS hospedado arquivos servidos pelo tomcat pode ser mais rápido do que os arquivos hospedados no S3, especialmente ao usar o CloudFrond (CDN).

Outra opção que recomendo é configurar um servidor da Web leve e separado (o nginx funciona perfeitamente para essas tarefas) para fornecer conteúdo estático do EBS. Essa solução será bastante rápida, segura (se for fornecida de uma instância separada) e econômica.

    

Answer 3

Serving statics from EBS may influence my web server's performance negatively

Bem, qual é a quantidade de seus dados estáticos? Se estiver abaixo de 1Gb, é muito provável que ele fique no cache e, portanto, não influencie o desempenho.

    

Answer 4

Qual é o seu volume de tráfego? Vale a pena para você usar o S3 como uma Rede de Entrega de Conteúdo ou você usará o S3 normal?

Quanto mais complicado será para você usar o S3 em vez do armazenamento local na unidade com o EBS? A entrega de dados estáticos pode ser um fator dependendo da sua aplicação.

    

Answer 5

Se você tiver algum tráfego sério & usuários você pode querer ir com S3 porque permite usar como um CDN. Você pode ter que considerar os custos se estiver esperando muitos dados do usuário. Para o S3, você precisa pagar por GET / PUT, portanto, muitos arquivos pequenos custarão caro. Com o EBS na sua imagem EC2, você pagará apenas pela largura de banda.

Eu sugiro que você execute os números. Veja também o que é mais fácil para o seu aplicativo fazer.