Necesito poder compartir contenido cargado por el usuario en múltiples servidores de aplicaciones EC2. He analizado rsync, NFS montado y S3 como opciones potenciales para poder compartir estos datos casi en tiempo real. Los archivos de usuario cargados y descargados casi siempre tienen entre 1 y 10 MB. A algunos se accede mucho y a otros sólo una vez y luego se eliminan.
Mi enfoque más nuevo implica lanzar una instancia EC2 estrictamente como un servidor de archivos, separado de los servidores de aplicaciones. Con esta opción, para que un usuario descargue un archivo, se conecta a uno de los servidores de aplicaciones que consulta la base de datos con datos sobre el archivo que desea descargar. Luego se le solicita al usuario que descargue, lo que lo conecta con el servidor de archivos para su descarga.
Siento que esta opción será más rápida que mis otras opciones. El único inconveniente que veo es que no puedo escalar automáticamente los servidores de archivos. Sin embargo, puedo ampliar y crear una columna en la base de datos que indique en qué servidor de archivos se encuentra el archivo.
¿Es este un buen enfoque o me falta algo? Además, ¿cuál es una buena manera de determinar cuántas cargas/descargas simultáneas pueden ocurrir en el servidor de archivos según las especificaciones del servidor y con archivos de entre 1 y 10 MB o es algo que se determina mejor a partir de pruebas de carga?
También en términos de escala, ¿será un problema si un archivo en particular ubicado en solo un servidor de archivos se vuelve extremadamente popular? ¿El uso de una CDN resolvería este problema?
Respuesta1
Una CDN sería la mejor opción para usted; usar S3 con CloudFront lo sería. Mi recomendación sería descentralizar el contenido generado por el usuario desde los servidores de aplicaciones; mantener los servidores volátiles cuando se escala hacia arriba o hacia abajo dentro de su arquitectura es una buena práctica de diseño.
Respuesta2
S3 y CloudFront serían la primera opción, pero si considera que la latencia no es aceptable, existen otras.
Si un único servidor de archivos funciona bien para usted, puede realizar la transición a una plataforma de servidor de archivos distribuido y escalable comoGlusterFS. Esto le permite almacenar archivos en varias instancias EC2 y hacer que aparezcan como un único montaje. Puede utilizar la opción "réplica 2" para crear 2 copias de cada archivo por motivos de redundancia. Luego use dos instancias en diferentes zonas de disponibilidad para aumentar la disponibilidad. Los archivos en sí se almacenan en cualquier disco compatible con EC2 que incluya EBS con IOPS aprovisionadas o incluso SSD efímero (he hecho esto antes; la redundancia de Gluster hace que la volatilidad de lo efímero sea una preocupación menor para que pueda obtener el beneficio de SSD). E/S rápida para sus datos críticos).
Respuesta3
Quiere diseñar sus EC2 para que no tengan datos únicos; considérelos simplemente como máquinas informáticas.
Tienes pocas opciones.
T3
Servicio escalable y confiable para almacenar y recuperar archivos. No funciona bien como sistema de archivos, por lo que si realiza muchas lecturas y escrituras, no es una gran solución.
Nube frontal (CDN)
Los archivos estáticos (css, js, imágenes) se pueden servir desde CloudFront (que puede obtener sus datos de S3 o EC2). Esto mejora enormemente el rendimiento, por lo que puede utilizar S3 para obtener sus archivos y servirlos desde CloudFront.
GlusterFS
Puede utilizar un grupo de EC2 como almacenamiento conectado a la red. Por supuesto, esto añade un poco más de complejidad a su configuración y no es la solución más rápida.
Elasticache / Memecached
Puedes alojar tu propio memecached o utilizar el servicio Elasticache. Esta solución no es almacenamiento de archivos, pero es útil como sistema de almacenamiento en caché de objetos de memoria distribuida de alto rendimiento.