Eu preciso poder compartilhar o conteúdo enviado por usuários em vários servidores de aplicativos do EC2. Eu observei o rsync, o NFS montado e o S3 como opções potenciais de poder compartilhar esses dados quase em tempo real. Os arquivos do usuário enviados e baixados estão quase sempre entre 1-10MB. Alguns são acessados muito e alguns apenas uma vez e depois apagados.
Minha nova abordagem envolve o lançamento de uma instância do EC2 estritamente como um servidor de arquivos, separado dos servidores de aplicativos. Com essa opção, para um usuário fazer download de um arquivo, eles são conectados a um dos servidores de aplicativos que consulta o banco de dados com dados sobre o arquivo que deseja baixar. O usuário é então solicitado a fazer o download, que os conecta ao servidor de arquivos para download.
Eu sinto que essa opção será mais rápida do que minhas outras opções. A única desvantagem que vejo é que não consigo fazer o escalonamento automático dos servidores de arquivos. No entanto, posso ampliar e criar uma coluna no banco de dados que diga 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-10MB ou isso é algo melhor determinado a partir do teste de carga?
Também em termos de escalonamento, será um problema se 1 arquivo específico localizado em apenas 1 servidor de arquivos se tornar extremamente popular? Usar um CDN resolveria esse problema?
Um CDN seria a melhor opção para você, usando o S3 com o CloudFront. Minha recomendação seria descentralizar o conteúdo gerado pelo usuário do (s) servidor (es) do aplicativo, mantendo seus servidores voláteis quando a escala for maior ou menor em sua arquitetura é uma boa prática de design.
O S3 e o CloudFront seriam a primeira opção, mas se você achar que a latência não é aceitável, há outros.
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 escalável, como GlusterFS . Isso permite que você armazene arquivos em várias instâncias do EC2 e faça 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 arquivos em si são armazenados em qualquer disco suportado pelo EC2 que inclua EBS com provisionamento de IOPS ou 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 o benefício do SSD IO rápido para seus dados críticos).
Você deseja arquitetar seus EC2s para que eles não tenham dados exclusivos, pense neles simplesmente como máquinas de computação.
Você tem algumas opções.
Serviço escalável e confiável para armazenar e recuperar arquivos. Ele não funciona bem como um sistema de arquivos, por isso, se você está fazendo muitas leituras e gravações, não é uma ótima solução.
Arquivos estáticos (css, js, imagens) podem ser exibidos fora do CloudFront (que podem obter seus dados de S3 ou EC2s). Isso melhora muito o desempenho, portanto, você pode usar o S3 para obter seus arquivos e servi-los no CloudFront.
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.
Você pode hospedar seu próprio memecached ou usar o serviço Elasticache. Essa solução não é armazenamento de arquivos, mas é útil como um sistema de cache de objeto de memória distribuída de alto desempenho.