Preciso poder compartilhar o conteúdo carregado pelo usuário em vários servidores de aplicativos EC2. Analisei o rsync, o NFS montado e o S3 como opções potenciais para poder compartilhar esses dados quase em tempo real. Os arquivos do usuário carregados e baixados têm quase sempre entre 1 e 10 MB. Alguns são muito acessados e outros apenas uma vez e depois excluídos.
Minha abordagem mais recente envolve iniciar uma instância EC2 estritamente como um servidor de arquivos, separado dos servidores de aplicativos. Com esta opção, para que um usuário baixe um arquivo, ele se conecta a um dos servidores de aplicação que consulta o banco de dados com dados sobre o arquivo que deseja baixar. O usuário é então solicitado a fazer download, o que o conecta ao servidor de arquivos para download.
Sinto que esta opção será mais rápida do que minhas outras opções. A única desvantagem que vejo é que não consigo dimensionar automaticamente os servidores de arquivos. No entanto, posso aumentar a escala e criar uma coluna no banco de dados que indique em qual servidor de arquivos o arquivo está localizado.
Esta é uma boa abordagem ou estou faltando alguma coisa? Além disso, qual é uma boa maneira de determinar quantos uploads/downloads simultâneos podem ocorrer no servidor de arquivos com base nas especificações do servidor e com arquivos entre 1 e 10 MB ou isso é melhor determinado no teste de carga?
Também em termos de escala, será um problema se um arquivo específico localizado em apenas um servidor de arquivos se tornar extremamente popular? Usar um CDN resolveria esse problema?
Responder1
Um CDN seria a melhor opção para você, usar S3 com CloudFront seria. Minha recomendação seria descentralizar o conteúdo gerado pelo usuário do(s) servidor(es) de aplicativos, mantendo seus servidores voláteis quando aumentar ou diminuir sua arquitetura for uma boa prática de design.
Responder2
S3 e CloudFront seriam a primeira opção, mas se você achar que a latência não é aceitável, existem outras.
Se um único servidor de arquivos estiver funcionando bem para você, você poderá fazer a transição para uma plataforma de servidor de arquivos distribuída e escalonável, comoGlusterFS. Isso permite armazenar arquivos em várias instâncias do EC2 e fazer com que eles apareçam como uma única montagem. Você pode usar a opção "réplica 2" para criar 2 cópias de cada arquivo para redundância. Em seguida, use duas instâncias em zonas de disponibilidade diferentes para aumentar a disponibilidade. Os próprios arquivos são armazenados em qualquer disco compatível com EC2 que inclua EBS com IOPS provisionados ou até mesmo SSD efêmero (já fiz isso antes - a redundância do Gluster torna a volatilidade do efêmero menos preocupante para que você possa obter os benefícios do SSD IO rápido para seus dados críticos).
Responder3
Você deseja arquitetar seus EC2s para que eles não tenham dados exclusivos, pense neles simplesmente como máquinas de computação.
Você tem poucas opções.
S3
Serviço escalável e confiável para armazenar e recuperar arquivos. Ele não funciona bem como sistema de arquivos, portanto, se você estiver fazendo muitas leituras e gravações, não será uma ótima solução.
CloudFront (CDN)
Arquivos estáticos (css, js, imagens) podem ser veiculados no CloudFront (que pode obter dados do S3 ou EC2s). Isso melhora muito o desempenho, então você pode usar o S3 para obter seus arquivos e servi-los no CloudFront.
GlusterFS
Você pode usar um cluster de EC2s como armazenamento conectado à rede. É claro que isso adiciona um pouco mais de complexidade à sua configuração e não é a solução mais rápida.
Elasticache/Memecached
Você pode hospedar seu próprio memecached ou usar o serviço Elasticache. Esta solução não é armazenamento de arquivos, mas é útil como um sistema de cache de objetos de memória distribuída de alto desempenho.