Patrones de diseño de rendimiento para Amazon S3

Al diseñar aplicaciones para cargar y recuperar objetos de Amazon S3, use los patrones de diseño de nuestras prácticas recomendadas para lograr el mejor rendimiento para su aplicación. También ofrecemos Directrices de rendimiento para Amazon S3 para que las tenga en cuenta al planificar la arquitectura de aplicaciones.

Para optimizar el rendimiento, puede usar los siguientes patrones de diseño.

Uso del almacenamiento en caché para el contenido de acceso frecuente

Muchas aplicaciones que almacenan datos en Amazon S3 ofrecen un "conjunto de trabajo" que los usuarios solicitan continuamente. Si una carga de trabajo envía solicitudes GET repetidas para un conjunto común de objetos, puede utilizar una caché como Amazon CloudFront, Amazon ElastiCache o AWS Elemental MediaStore para optimizar el rendimiento. La adopción correcta de la caché puede dar lugar a una baja latencia y a velocidades de transferencias de datos altas. Las aplicaciones que usan el almacenamiento en caché también envían menos solicitudes directas a Amazon S3, lo que puede contribuir a reducir los costes de las solicitudes.

Amazon CloudFront es una red de entrega de contenido (CDN) rápida que almacena datos en caché de forma transparente desde Amazon S3 en un gran conjunto de puntos de presencia (PoP) distribuidos geográficamente. Cuando se puede tener acceso a los objetos desde multirregiones o a través de Internet, CloudFront permite que los datos se almacenen en caché cerca de los usuarios con acceso a los objetos. Esto puede dar como resultado la entrega de alto rendimiento de contenido popular de Amazon S3. Para obtener más información sobre CloudFront, consulte la guía para desarrolladores de Amazon CloudFront.

Amazon ElastiCache es una caché en memoria administrada. Con ElastiCache, puede aprovisionar instancias Amazon EC2 que almacenan en caché objetos en memoria. Este almacenamiento en caché se traduce en pedidos de reducción de la magnitud en la latencia GET y aumentos sustanciales en el rendimiento de descarga. Para usar ElastiCache, debe modificar la lógica de la aplicación tanto para rellenar la caché con objetos activos como para comprobar la caché en busca de estos objetos antes de solicitarlos en Amazon S3. Para ver ejemplos de uso de ElastiCache para mejorar el rendimiento de GET de Amazon S3, consulte la publicación del blog Turbocharge Amazon S3 with Amazon ElastiCache for Redis.

AWS Elemental MediaStore es un sistema de almacenamiento en caché y distribución de contenido creado específicamente para flujos de trabajo de vídeo y entrega de medios desde Amazon S3. MediaStore proporciona API de almacenamiento integrales específicamente para vídeo, y está recomendado para cargas de trabajo de video sensibles al rendimiento. Para obtener información sobre MediaStore, consulte la Guía del usuario de AWS Elemental MediaStore.

Tiempos de espera y reintentos de aplicaciones sensibles a la latencia

Hay ciertas situaciones en las que una aplicación recibe una respuesta de Amazon S3 que indica que es necesario volver a intentarlo. Amazon S3 asigna nombres de bucket y objeto a los datos de objeto asociados a ellos. Si una aplicación genera velocidades de solicitudes altas (normalmente velocidades sostenidas de más de 5000 solicitudes por segundo a un pequeño número de objetos), podría recibir respuestas de ralentización HTTP 503. Si se producen estos errores, cada SDK de AWS implementa la lógica de reintentos automática mediante el retroceso exponencial. Si no está usando un SDK de AWS, debe implementar la lógica de reintentos al recibir el error HTTP 503. Para obtener más información, consulte Retry behavior en la AWS SDKs and Tools Reference Guide.

Amazon S3 se escala automáticamente en respuesta a las nuevas velocidades de solicitudes sostenidas, optimizando el rendimiento de forma dinámica. Aunque Amazon S3 se está optimizando internamente para una nueva velocidad de solicitudes, recibirá respuestas a las solicitudes HTTP 503 de forma temporal hasta que se complete la optimización. Una vez que Amazon S3 optimice internamente el rendimiento para la nueva velocidad de las solicitudes, todas las solicitudes se atienden de forma general sin reintentos.

En las aplicaciones sensibles a la latencia, Amazon S3 aconseja un seguimiento y realizar un reintento agresivo de operaciones más lentas. Siempre que reintente una solicitud, recomendamos que se use una nueva conexión a Amazon S3 y que se vuelva a realizar una búsqueda de DNS.

Si realiza solicitudes de tamaño grande y variable (por ejemplo: más de 128 MB), aconsejamos que se realice un seguimiento del rendimiento logrado y que se reintente el 5 % más lento de las solicitudes. Al realizar solicitudes más pequeñas (por ejemplo: menos de 512 KB), donde las latencias medias suelen situarse en el rango de las decenas de milisegundos, una buena directriz es reintentar una operación GET o PUT transcurridos 2 segundos. Si son necesarios reintentos adicionales, la práctica recomendada es el retardo. Por ejemplo, recomendamos que se emita un reintento transcurridos 2 segundos y un segundo reintento después de 4 segundos adicionales.

Si su aplicación realiza solicitudes de tamaño fijo a Amazon S3, debe esperar unos tiempos de respuesta más uniformes para cada una de estas solicitudes. En este caso, una estrategia sencilla consiste en identificar el 1 % más lento de las solicitudes y reintentarlas. Incluso un único reintento suele ser eficaz reduciendo la latencia.

Si está utilizando AWS Key Management Service (AWS KMS) para el cifrado del servidor, consulte Quotas en la AWS Key Management Service Developer Guide con el fin de obtener información acerca de las tasas de solicitudes admitidas para su caso de uso.

Escalado horizontal y uso en paralelo de solicitudes para lograr un alto rendimiento

Amazon S3 es un sistema distribuido muy grande. Para ayudarle a aprovechar su escala, le animamos a escalar horizontalmente solicitudes paralelas a los puntos de enlace de servicio de Amazon S3. Además de distribuir las solicitudes en Amazon S3, este tipo de enfoque de escalado ayuda a distribuir la carga mediante varias rutas a través de la red.

Para las transferencias de alto rendimiento, Amazon S3 aconseja que se usen aplicaciones que a su vez usen varias conexiones a los datos de GET o PUT en paralelo. Por ejemplo, esto cuenta con el respaldo del gestor de transferencias de Amazon S3 en el SDK de AWS para Java. Además, la mayoría de los otros SDK de AWS proporcionan construcciones similares. Para algunas aplicaciones, puede lograr conexiones paralelas lanzando varias solicitudes simultáneamente en diferentes subprocesos de aplicación, o bien en diferentes instancias de aplicación. El mejor enfoque que adoptar depende de su aplicación y la estructura de los objetos a los que tiene acceso.

Puede utilizar los SDK de AWS para emitir las solicitudes GET y PUT directamente en lugar de emplear la administración de las transferencias en el SDK de AWS. Este enfoque le permite ajustar su carga de trabajo de forma más directa, mientras sigue beneficiándose de la compatibilidad del SDK con los reintentos y su control de cualquier respuesta HTTP 503 que pueda surgir. Como regla general, al descargar objetos grandes dentro de una región desde Amazon S3 a Amazon EC2, recomendamos que se realicen solicitudes simultáneas de rangos de byte de un objeto en la granularidad de 8-16 MB. Realice una solicitud simultánea de cada valor comprendido en un intervalo de 85-90 MB/s del rendimiento de red deseado. Para saturar una tarjeta de interfaz de red (NIC), puede usar unas 15 solicitudes simultáneas a través de conexiones independientes. Puede escalar de forma ascendente las solicitudes simultáneas a través de más conexiones para saturar las NIC con mayor rapidez, como NIC de 25 GB/s y de 100 GB/s.

Medir el rendimiento es importante cuando ajusta el número de solicitudes que se van a emitir simultáneamente. Recomendamos comenzar con una sola solicitud cada vez. Mida el ancho de banda de red logrado y el uso de otros recursos utilizados por su aplicación durante el procesamiento de los datos. A partir de ese momento, podrá identificar el recurso de cuello de botella (es decir, el recurso más usado) y, por tanto, el número de solicitudes con probabilidades de resultar de utilidad. Por ejemplo, si el procesamiento de una solicitud cada vez se traduce a un uso del 25 % de la CPU, sugiere que se pueden atender hasta cuatro solicitudes simultáneas. La medición es fundamental y merece la pena confirmar el uso de recursos a medida que aumenta la velocidad de solicitudes.

Si su aplicación emite solicitudes directamente a Amazon S3 mediante la API de REST, recomendamos usar un grupo de conexiones HTTP y volver a utilizar cada conexión para una serie de solicitudes. Al evitarse la configuración de la conexión por solicitud, desaparece la necesidad de llevar a cabo protocolos de enlace de Capa de conexión segura (SSL) y TCP de inicio lento. Para obtener información sobre el uso de la API de REST, consulte la referencia de la API de Amazon Simple Storage Service.

Por último, merece la pena prestar atención a DNS y volver a comprobar si las solicitudes se distribuyen mediante un amplio grupo de direcciones IP de Amazon S3. Consultas de DNS para el ciclo de Amazon S3 a través de una gran lista de puntos de enlace de IP. Sin embargo, el almacenamiento en caché de los solucionadores o el código de aplicación que vuelve a usar una sola dirección IP no se beneficia de la diversidad de direcciones y el balanceo de carga que se produce a continuación. Las herramientas de utilidades de red, como, por ejemplo, la herramienta de línea de comandos netstat, pueden mostrar las direcciones IP que se están utilizando para la comunicación con Amazon S3. Además, proporcionamos directrices acerca de las configuraciones de DNS que se deben emplear. Para obtener más información sobre estas directrices, consulte Making requests en la Amazon S3 API Reference.

Uso de Amazon S3 Transfer Acceleration para acelerar las transferencias de datos en lugares geográficos dispares

Configuración de transferencias de archivos rápidas y seguras con Amazon S3 Transfer Acceleration resulta eficaz a la hora de minimizar o eliminar la latencia generada por la distancia geográfica existente entre clientes repartidos por todo el mundo y una aplicación regional mediante Amazon S3. Transfer Acceleration usa las ubicaciones de borde distribuidas globalmente en CloudFront para el transporte de los datos. La red de borde de AWS tiene puntos de presencia en más de 50 ubicaciones. Actualmente, se usa para distribuir el contenido a través de CloudFront y proporcionar respuestas rápidas a las consultas DNS realizadas a Amazon Route 53.

La red de borde también ayuda a acelerar las transferencias de datos tanto dentro como fuera de Amazon S3. Resulta ideal para las aplicaciones que transfieren datos en o entre continentes, tienen una conexión a Internet rápida, usan objetos grandes o tienen mucho contenido que cargar. A medida que los datos llegan a una ubicación de borde, se redirigen a Amazon S3 a través de una ruta de red optimizada. En general, cuanto más lejos esté de una región de Amazon S3, mayor será la mejora de la velocidad que puede esperar del uso de Transfer Acceleration.

Puede configurar Transfer Acceleration en buckets nuevos o ya existentes. Puede usar un punto de enlace independiente de Amazon S3 Transfer Acceleration para utilizar las ubicaciones de borde de AWS. La mejor forma de probar si Transfer Acceleration contribuye al rendimiento de las solicitudes de los clientes es usar la herramienta de comparación de velocidad de Amazon S3 Transfer Acceleration. Las condiciones y configuraciones de red varían de cuando en cuando y de ubicación a ubicación. Así pues, solo se le cobrarán las transferencias en las que Amazon S3 Transfer Acceleration pueda mejorar de forma potencial su rendimiento de carga. Para obtener información acerca del uso de Transfer Acceleration con diferentes SDK de AWS, consulte Habilitación y uso de S3 Transfer Acceleration.