Necesito ayuda para decidir entre EBS vs S3 en Amazon Web Services

Question

Estoy trabajando en un proyecto que incorpora funciones de almacenamiento y uso compartido de archivos y después de meses de investigar el mejor método para aprovechar AWS, todavía estoy un poco preocupado.

Básicamente, mi decisión es utilizar el almacenamiento de EBS para almacenar archivos de usuario o S3. El sistema incorporará el archivo zip sobre la marcha cuando el usuario quiera descargar un puñado de archivos. Además, cuando los usuarios descargan cualquier archivo, no quiero que se exponga la URL de los archivos.

Los dos mejores opciones que he llegado con son:

1. tiene una instancia EC2, que tiene un número de volúmenes de EBS montado en los archivos de usuario de la tienda.

   • pros: Parece mucho más rápido que S3, y comprimir archivos del volumen de EBS es sencillo.
   • contras: Creo que Amazon limita la cantidad de almacenamiento de EBS que puede utilizar y no es tan redundante como S3.

2. Una vez cargados y procesados ​​los archivos, el sistema los envía a un contenedor S3 para su almacenamiento a largo plazo. Cuando se soliciten archivos, recuperaré los archivos de S3 y los devolveré al cliente.

   • pros: la redundancia, no hay límites de almacenamiento de archivos
   • contras: Parece muy lento, no hay manera de montar un depósito de S3 como un volumen en el sistema de ficheros, sirviendo archivos comprimidos significaría transferir cada archivo a la instancia EC2, comprimir, y finalmente enviar la salida (de nuevo, lento!)

¿alguno de mis suposiciones incorrectas? ¿Alguien puede pensar en una mejor manera de administrar cantidades masivas de almacenamiento de archivos?

Answer 1

Si su servicio va a ser utilizado por un número indeterminado de usuarios, es importante tener en cuenta que la escalabilidad siempre será una preocupación, independientemente de la opción adoptada, necesitará escalar el servicio para satisfacer la demanda , por lo que sería conveniente suponer que su servicio se ejecutará en un Grupo de escalamiento automático con un conjunto de instancias EC2 y no una sola instancia.

En cuanto a la protección de la URL para permitir que sólo los usuarios autorizados descargar los archivos, hay muchas maneras de hacer esto sin requerir su servicio para actuar como un intermediario, a continuación, tendrá que lidiar con al menos dos cuestiones:

1. nombre de archivo previsibilidad: para evitar la previsibilidad URL, usted podría nombrar el archivo cargado como un hash y almacenar los nombres de archivos y propiedades originales en una base de datos como SimpleDB, opcionalmente se puede establecer una cabecera HTTP como "Content Disposition: filename = original_file_name.ext "para indicar al navegador de los usuarios que nombre el archivo descargado en consecuencia.

2. autorización: cuando el usuario pide descargar un archivo dado su servicio, emitir una autorización temporal usando Query String Authentication o Temporary Security Credentials para que las donaciones usuario específico acceso de lectura al archivo por un período de tiempo, entonces su servicio redirige a la S3 canasta URL para descarga directa. Esto puede descargar mucho sus instancias de grupo de EC2, por lo que estará disponible para procesar otras solicitudes más rápidamente.

Para reducir el espacio y el tráfico a su depósito de S3 (recordemos que se paga por GB almacenado y transferidos), también recomendaría la compresión de cada archivo individual utilizando un algoritmo estándar como gzip antes de subir a S3 y configurar la cabecera "Content-Encoding: gzip" para hacer que la descompresión automática funcione con el navegador de los usuarios. Si su lenguaje de programación de elección es Java, sugiero echarle un vistazo al código de complemento webcache-s3-maven-plugin que creé para cargar recursos estáticos de proyectos web.

En cuanto al tiempo de procesamiento en la compresión de una carpeta, con frecuencia no podrá asegurarse de que las carpetas se comprimirán en poco tiempo, para permitir que el usuario la descargue inmediatamente, ya que eventualmente podría haber grandes carpetas eso podría tomar minutos o incluso horas para ser comprimido. Para ello sugiero que uses los SQS y servicios del SNS con el fin de permitir que proceso de compresión asíncrona, que funcionaría como sigue:

1. usuario solicita la compresión de carpetas
2. la instancia frontend EC2 crea una solicitud de compresión en una cola SQS
3. una instancia de backend EC2, consume la solicitud de compresión de la cola SQS
4. la instancia de backend descarga los archivos de S3 a una unidad EBS, ya que los archivos generados serán temporales sugeriría a elegir para utilizar a al menos m1.casos pequeños con efímeros discos de tipo, que son locales a la máquina virtual para reducir la latencia de E/S y el tiempo de procesamiento.
5. después de generar el archivo comprimido, el servicio carga el archivo en el depósito S3, configurando opcionalmente las propiedades Object Expiration, que le indicará a S3 que elimine el archivo automáticamente después de un cierto período de tiempo (nuevamente para reducir sus costos de almacenamiento) y publica una notificación de que el archivo está listo para descargarse en un tema SNS.
6. si el usuario todavía está en línea, lea la notificación del tema y notifique al usuario que el archivo zip está listo para descargarse, si después de un tiempo no recibió esta notificación, puede decirle al usuario que la compresión está tomando más de lo esperado y el servicio lo notificará por correo electrónico tan pronto como el archivo esté listo para ser descargado.

En este caso, podría tener dos grupos de escala automática, respectivamente frontend y back-end, que pueden tener diferentes restricciones de escalabilidad.

Answer 2

Usar S3 es una mejor opción para este caso de uso. Se escala mejor y será más simple. ¿Por qué te preocupa que sea lento? Las transferencias entre EC2 y S3 son bastante ágiles.

Answer 3

Si insiste en servir los archivos zip directamente desde su instancia de EC2, usar S3 será más complicado que almacenarlos localmente. Pero S3 es mucho más duradero que cualquier volumen de almacenamiento EC2, por lo que recomiendo usarlo de todos modos si los archivos deben mantenerse durante mucho tiempo.

Dice que no quiere exponer las URL de los archivos directamente.Si eso es solo porque no desea que las personas puedan marcarlos y omitir su autenticación de servicio en el futuro, S3 tiene una gran solución:

1 - Almacene los archivos que desea atender (con cremallera si lo desea de esa manera) en un cubo privado S3.

2 - Cuando un usuario solicita un archivo, autentica la solicitud y luego redirige las solicitudes válidas a S3 URL temporal, firmada, del archivo. Hay muchas bibliotecas en una variedad de idiomas que pueden crear esas URL.

3 - El usuario descarga el archivo directamente desde S3, sin tener que pasar por su instancia de EC2. Eso le ahorra ancho de banda y tiempo, y probablemente le da la descarga más rápida posible al usuario.

Esto expone una URL, pero probablemente esté bien. No hay problema si el usuario guarda la URL, ya que no funcionará después del tiempo de caducidad que establezca. Para mi servicio, establecí ese tiempo en 5 minutos. Dado que está firmado digitalmente, el usuario no puede cambiar el tiempo de caducidad en la URL sin invalidar la firma.

Answer 4

Algunas consideraciones:

1. EBS costos volumen es varias veces mayor que la de S3.
2. Los límites de tamaño de volumen de EBS son de 16 TB, por lo que no debería ser un problema. Sin embargo, los volúmenes de ese tamaño son muy caros.
3. Asegúrese de que su depósito se encuentre en la misma región que sus instancias EC2.
4. Utilice puntos finales VPC para comunicarse con S3. Esto es mucho más rápido.
5. Asegúrese de que su tipo de instancia EC2 tenga el ancho de banda de red que necesita. La CPU y la velocidad de la red aumentan con el tamaño de la instancia.

Mantendría todo en S3, descargue los archivos necesarios para comprimirlos en un paquete. A continuación, cargue el zip en S3 y envíele al usuario una S3 URL firmada para descargar desde S3.

Puede permitir que el usuario descargue desde su instancia EC2, pero muchos usuarios tienen problemas de error, problemas de reintento, ancho de banda lento, etc. Si los archivos zip son pequeños (menos de 100 MB) entregue localmente, de lo contrario cargue a S3 y deja que S3 se ocupe de los problemas de descarga del usuario.

Otra opción sería crear una función Lambda que crea el archivo zip y almacena en S3. Ahora no tiene que preocuparse por el ancho de banda o la escala de la red. La función Lambda podría devolverle la URL S3, que usted entrega al navegador, o bien, podría enviarle un correo electrónico al cliente. Mire en SES para esto. Nota: El sistema de archivos Lambda solo tiene 512 MB de espacio, la memoria puede asignarse hasta 1.5 GB. Si está generando archivos zip más grandes que esto, Lambda no funcionará (en este momento). Sin embargo, puede crear varios archivos zip (part1, part2, ...)