amazon s3 - prices - Necesita ayuda para decidir entre EBS vs S3 en Amazon Web Services

price amazon s3

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 usar 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.

Las dos mejores opciones que he encontrado son:

1. Tener una instancia EC2 que tenga montados una cantidad de volúmenes EBS para almacenar archivos de usuario.

   • pros: parece mucho más rápido que S3, y comprimir archivos desde el volumen de EBS es sencillo.
   • Contras: Creo que Amazon limita la cantidad de almacenamiento EBS que puede usar y no es tan redundante como S3.

2. Una vez que los archivos se cargan y procesan, 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: Redundancia, sin límites de almacenamiento de archivos
   • Contras: Parece muy lento, no hay manera de montar un cubo S3 como un volumen en el sistema de archivos, el servicio de archivos comprimidos significaría transferir cada archivo a la instancia EC2, comprimir y finalmente enviar el resultado (¡de nuevo, lento!)

¿Alguna de mis suposiciones es errónea? ¿Alguien puede pensar en una mejor manera de administrar cantidades masivas de almacenamiento de archivos?

Answer 1

Algunas consideraciones:

1. El costo del volumen de EBS es varias veces mayor que el 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 contenedor esté ubicado en la misma región que sus instancias EC2.
4. Use 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 en S3 y deje S3 tratar con 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, puedes crear múltiples archivos zip (part1, part2, ...)

Answer 2

Si insiste en servir los archivos comprimidos 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.

Usted 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 servir (con la cremallera si así lo desea) en un depósito S3 privado.

2 - Cuando un usuario solicita un archivo, autentica la solicitud y luego redirige las solicitudes válidas a una URL S3 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 que tenga 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 eso 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 3

Si su servicio va a ser utilizado por un número indeterminado de usuarios, es importante tener en cuenta que la capacidad de escalado siempre será una preocupación, independientemente de la opción adoptada, necesitará escalar el servicio para satisfacer la demanda, por lo que sea ​​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 solo los usuarios autorizados descarguen los archivos, hay muchas maneras de hacerlo sin que su servicio tenga que actuar como intermediario, y luego tendrá que lidiar con al menos dos problemas:

1. Predictibilidad del nombre de archivo : para evitar la predictibilidad URL, puede nombrar el archivo cargado como un hash y almacenar los nombres de archivo originales y las propiedades en una base de datos como SimpleDB, opcionalmente puede establecer un encabezado http como "Content-Disposition: filename = original_file_name.ext "Aconsejar al navegador de los usuarios que nombre el archivo descargado en consecuencia.

2. autorización : cuando el usuario solicite descargar un archivo determinado de su servicio, emita una autorización temporal usando la autenticación de cadena de consulta o credenciales temporales de seguridad para ese usuario específico que le da acceso de lectura al archivo por un período de tiempo luego su servicio redirecciona a la URL del segmento S3 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 segmento S3 (recuerde que paga por GB almacenado y transferido), también recomendaría comprimir cada archivo individual utilizando un algoritmo estándar como gzip antes de cargarlo a S3 y configurar el encabezado "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 para comprimir una carpeta, con frecuencia no podrá asegurarse de que las carpetas se comprimirán en poco tiempo, para permitir que el usuario la descargue de inmediato, ya que eventualmente podría haber grandes carpetas que podrían demorar unos minutos. o incluso horas para ser comprimido. Para esto, le sugiero que use los servicios SQS y SNS para permitir el procesamiento de compresión asíncrono , que funcionaría de la siguiente manera:

1. solicitud de usuario, compresión de carpetas
2. la instancia frontend EC2 crea una solicitud de compresión en una cola SQS
3. una instancia de back-end 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, le sugiero que elija usar al menos instancias m1.small con discos de tipo efímero , que son locales a la máquina virtual para reducir I / O latencia y el tiempo de procesamiento.
5. después de que se genera el archivo comprimido, el servicio carga el archivo en el depósito S3, configurando opcionalmente las propiedades de caducidad del objeto , que le indicará a S3 que elimine el archivo automáticamente después de un cierto período de tiempo (nuevamente para reducir los costos de almacenamiento) y publica una notificación de que el archivo está listo para descargarse en un tema SNS.
6. si el usuario aún está en línea, lea la notificación del tema y notifique al usuario que el archivo comprimido está listo para ser descargado; si después de un tiempo no llegó esta notificación, puede decirle al usuario que la compresión demora 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 escenario, puede tener dos Grupos de escala automáticos, respectivamente frontend y backend, que pueden tener diferentes restricciones de escalabilidad.

Answer 4

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.