Escenarios de alto rendimiento y optimización de costes

Escenario: La base de datos RDS MySQL de un sitio de noticias gestiona un 90 % de tráfico de lectura de contenido de artículos que cambia como máximo una vez por hora. La CPU de la base de datos alcanza una media del 80 %, los costes están aumentando y la latencia es de 200 ms por consulta. Solución: Añada un clúster de ElastiCache Redis delante de RDS mediante el patrón de carga diferida (cache-aside). La aplicación comprueba primero la caché; si encuentra el artículo en ella, lo devuelve en <1 ms. Si no lo encuentra, consulta RDS, devuelve el resultado y lo escribe en la caché con un TTL de 1 hora. Resultado esperado: una tasa de aciertos de caché del 90 %, una CPU de RDS inferior al 20 % y una latencia inferior a 5 ms para las respuestas almacenadas en caché.

Escenario: Los usuarios de Asia-Pacífico experimentan tiempos de carga de 2 a 4 segundos para una aplicación web alojada en EC2 en us-east-1. La aplicación sirve recursos estáticos grandes (imágenes, JS y CSS). Solución: Coloque una distribución de CloudFront delante del ALB. Configure un comportamiento de caché para la ruta /static/* con un TTL largo (por ejemplo, 1 semana), de modo que los archivos estáticos se almacenen en caché en las ubicaciones perimetrales de CloudFront cercanas a los usuarios de Asia. Las solicitudes de API dinámicas omiten la caché con TTL=0. Los usuarios asiáticos cargan los recursos estáticos desde una ubicación perimetral de Singapur o Tokio en menos de 100 ms, en lugar de esperar los viajes de ida y vuelta a us-east-1.

Escenario: Una empresa tiene 500 instancias EC2, muchas de ellas aprovisionadas hace 3 años con tipos de instancia grandes. Su factura de AWS es elevada, pero no sabe qué instancias están sobredimensionadas. Solución: Habilite AWS Compute Optimizer (es gratuito y utiliza 14 días de métricas de CloudWatch). Compute Optimizer analiza la utilización real de CPU, memoria, red y disco de cada instancia, y proporciona recomendaciones para ajustar su tamaño. Se recomendaría reducir una instancia t3.xlarge con una media de CPU del 8 % a t3.small. Aplicar las recomendaciones en las 500 instancias normalmente reduce los costes de EC2 entre un 20 % y un 40 %.

Escenario: Una empresa de genómica ejecuta trabajos por lotes nocturnos que tardan 8 horas y se pueden reintentar si se interrumpen. EC2 On-Demand cuesta 10 000 $ al mes para estos trabajos. Solución: Utilice EC2 Spot Instances para la flota de procesamiento por lotes. Spot Instances es capacidad de EC2 no utilizada disponible con descuentos de hasta el 90 %. Para trabajos por lotes tolerantes a interrupciones, utilice AWS Batch, que vuelve a poner automáticamente en cola los trabajos de Spot fallidos y utiliza una flota mixta (Spot + una capacidad mínima de reserva On-Demand). Ahorro esperado: una reducción del 70 % al 90 % en los costes de computación, de 10 000 $ a entre 1 000 $ y 3 000 $ al mes.

Escenario: Una clasificación de jugadores utiliza DynamoDB con capacidad aprovisionada. Durante los lanzamientos de juegos, el tráfico aumenta 50 veces y la tabla limita las solicitudes. Fuera de los lanzamientos, el rendimiento es casi nulo y se desperdicia la capacidad aprovisionada. Solución: Cambie DynamoDB al modo de capacidad On-Demand. On-Demand escala instantáneamente a cualquier nivel de rendimiento sin planificación manual de capacidad y cobra por solicitud en lugar de hacerlo por unidad aprovisionada. Solo paga por las solicitudes que realiza, sin costes de capacidad inactiva entre lanzamientos. On-Demand intercambia un coste ligeramente superior por solicitud por la garantía de no aplicar throttling y no tener que gestionar la capacidad.

Escenario: Una empresa almacena millones de imágenes generadas por usuarios en S3 Standard. Los patrones de acceso varían de forma impredecible: se accede a algunas imágenes a diario y a otras no se accede durante meses. Quieren reducir los costes de almacenamiento sin gestionar manualmente las políticas de ciclo de vida. Solución: Usar S3 Intelligent-Tiering. Mueve automáticamente los objetos entre niveles según los patrones de acceso: Frequent Access (Standard), Infrequent Access (30 días o más sin acceso), Archive Instant Access (90 días o más) y Archive Access (90 días o más, opcional). No se cobran tarifas de recuperación dentro de Intelligent-Tiering. El cargo de monitorización es de 0,0025 $ por cada 1.000 objetos al mes, una cantidad insignificante para grandes conjuntos de datos.

Escenario: Una startup quiere consultar tablas de un lago de datos en S3. Ejecuta unas 10 consultas ad hoc por semana. Un proveedor propone Amazon Redshift con un clúster dc2.large. Solución para una startup: Empezar con Amazon Athena: coste de infraestructura cero y pago únicamente por los datos escaneados (unos 5 $/TB). 10 consultas semanales sobre datos Parquet bien particionados podrían costar menos de 5 $ al mes. Redshift dc2.large cuesta aproximadamente 180 $ al mes de forma continua. Redshift resulta rentable únicamente cuando la concurrencia de consultas es alta (más de 50 consultas al día) o se necesita una respuesta inferior a un segundo. La palabra clave «ad hoc, infrecuente» apunta claramente a Athena.

Escenario: Un servidor de base de datos relacional requiere 64.000 IOPS con una latencia baja y constante. El volumen gp3 de EBS actual está alcanzando su límite de IOPS. Solución: Actualizar a io2 Block Express (un tipo de volumen de EBS diseñado para bases de datos con un uso intensivo de E/S). io2 Block Express admite hasta 256.000 IOPS por volumen y una latencia inferior a un milisegundo. Es más caro que gp3 (0,125 $/GB + 0,065 $/IOPS aprovisionada al mes), pero es la única opción de EBS que cumple los requisitos de 64.000 IOPS o más. Para cargas de trabajo de bases de datos críticas para la latencia en las que el límite de 16.000 IOPS de gp3 no es suficiente, io2 es la única opción viable de EBS.

Escenario: Una empresa ejecuta continuamente 20 instancias EC2 r6i.4xlarge para una aplicación de producción y no prevé cambios en sus requisitos durante 3 años. Actualmente, el gasto bajo demanda de estas instancias es de 80.000 $ al año. Solución: Comprar Reserved Instances estándar de 3 años (o Compute Savings Plans) con pago total por adelantado para obtener el descuento máximo. Las Reserved Instances estándar ofrecen un descuento de hasta el 72 % frente al modelo bajo demanda. Las instancias se ejecutan las 24 horas, todos los días, con una carga de trabajo predecible: el perfil clásico para usar Reserved Instances. Reducción de costes prevista: 80.000 $ × 0,72 = 22.400 $ al año frente a 80.000 $ al año bajo demanda, lo que supone un ahorro de 57.600 $ al año.

Escenario: Una empresa ejecuta una API REST en una instancia EC2 t3.micro que cuesta 8 $ al mes. La API recibe 1 millón de solicitudes al mes y cada una tarda 100 ms en procesarse. El equipo quiere saber si Lambda sería más barato. Análisis: Precio de Lambda: 1.000.000 de solicitudes × 0,0000002 $ = 0,20 $ (coste de las solicitudes) + 1.000.000 × 0,1 s × 128 MB de memoria × tarifa = aproximadamente 1,67 $ (coste de cómputo) = aproximadamente 1,87 $ al mes. Lambda es más barato que EC2 para esta API con poco tráfico. Cuando el tráfico supera aproximadamente los 40 millones de solicitudes al mes, EC2 resulta más barato. Use la Lambda Cost Calculator para encontrar el punto de equilibrio de cada carga de trabajo.

Escenario: Una API global que presta servicio a usuarios de Europa, Estados Unidos y Asia experimenta una latencia irregular porque el tráfico atraviesa rutas impredecibles de Internet. Se consideró CloudFront, pero las respuestas de la API son dinámicas y no se pueden almacenar en caché. Solución: Usar AWS Global Accelerator. Proporciona dos direcciones IP anycast estáticas a nivel global. El tráfico de los usuarios entra en la red troncal global de AWS a través de la ubicación de edge de AWS más cercana y viaja por la red privada de AWS hasta el origen en la región de destino, evitando el tramo congestionado de la Internet pública entre redes. Global Accelerator mejora entre un 20 % y un 60 % el tiempo de respuesta de las API dinámicas y proporciona una conmutación por error inmediata cuando un endpoint regional deja de estar saludable.

En esta lección ha trabajado con escenarios sobre: lazy loading de ElastiCache para reducir el uso de CPU de RDS del 80 % al 20 %, Spot Instances y AWS Batch para ahorrar entre un 70 % y un 90 % en el coste de trabajos por lotes, Athena para consultas ad hoc poco frecuentes frente a Redshift para análisis con alta concurrencia y S3 Intelligent-Tiering para patrones de acceso impredecibles sin tarifas de recuperación. A continuación se presenta el proyecto final: un mini examen cronometrado de dominios combinados para medir su preparación.