Amazon DynamoDB Accelerator
Servicio de caché completamente administrado que coloca una caché en memoria delante de DynamoDB, reduciendo la latencia de lectura de milisegundos a microsegundos
Descripción general
Amazon DynamoDB Accelerator (DAX) es un clúster de caché en memoria especializado para DynamoDB. Al ser totalmente compatible con la API de DynamoDB, basta con cambiar el endpoint de la aplicación al clúster DAX para reducir la latencia de lectura de milisegundos a microsegundos. Las escrituras se reflejan de forma transparente en DynamoDB mediante write-through, manteniendo automáticamente la coherencia de la caché.
Criterios de selección frente a ElastiCache y limitaciones de DAX
DAX y ElastiCache for Redis son ambos cachés en memoria, pero sus casos de uso difieren claramente. DAX es exclusivo para DynamoDB y, al poder usar la API de DynamoDB tal cual, los cambios en la aplicación son mínimos. Almacena automáticamente en caché los resultados de GetItem, BatchGetItem, Query y Scan en dos capas (caché de ítems y caché de consultas), devolviendo resultados sin acceder a DynamoDB cuando llega la misma solicitud. ElastiCache es una caché de propósito general que puede almacenar datos de fuentes distintas a DynamoDB (RDS, resultados de APIs externas, datos de sesión, etc.). También permite implementar lógica de caché compleja utilizando las estructuras de datos de Redis (Sorted Set, Hash, List). El caso ideal para DAX es cuando la carga de lectura en DynamoDB es alta y se repiten los mismos patrones de claves o consultas. Las limitaciones de DAX incluyen: solo es accesible desde dentro de una VPC (si se usa con Lambda se requiere conexión VPC), las lecturas de consistencia fuerte omiten la caché y acceden directamente a DynamoDB, y se necesita un clúster separado por tabla. Para cargas de trabajo con muchas escrituras y pocas lecturas, el costo de DAX no se justifica.
Diseño de clúster y estrategia de caché
Para entornos de producción se recomienda una configuración mínima de 3 nodos (multi-AZ) en el clúster DAX. Los tipos de nodo son de la serie dax.r5, seleccionando el tamaño de memoria según el volumen de datos a cachear. El TTL de la caché de ítems (por defecto 5 minutos) y el TTL de la caché de consultas (por defecto 5 minutos) se configuran de forma independiente y se ajustan según la frecuencia de actualización de los datos. Para datos maestros con baja frecuencia de actualización se configura un TTL largo (1 hora o más), mientras que para datos actualizados frecuentemente se configura un TTL corto (decenas de segundos). La tasa de aciertos de caché se calcula con CloudWatch como ItemCacheHits / (ItemCacheHits + ItemCacheMisses), con un objetivo del 80% o superior. Si la tasa de aciertos es baja, es posible que los patrones de acceso no sean adecuados para caché (se accede a claves diferentes cada vez). El costo de DAX se basa en horas de nodo; para dax.r5.large (3 nodos) es aproximadamente 600 USD mensuales. Es importante calcular previamente si la reducción en unidades de capacidad de lectura (RCU) de DynamoDB justifica el costo de DAX.
Uso en tablas de clasificación de juegos y aplicaciones en tiempo real
DAX es más efectivo en cargas de trabajo donde las lecturas se concentran en unas pocas claves calientes. En tablas de clasificación de juegos, las consultas de ranking superior se ejecutan repetidamente por todos los jugadores. Sin DAX, se generan puntos calientes en las particiones de DynamoDB con riesgo de throttling, pero DAX almacena en caché los resultados de las consultas reduciendo drásticamente la carga sobre DynamoDB. Los catálogos de productos de comercio electrónico son similares: las páginas de detalle de productos populares generan grandes cantidades del mismo GetItem, haciendo efectiva la caché de ítems de DAX. En sistemas de subastas en tiempo real, se lee frecuentemente la oferta más alta actual mientras que las actualizaciones solo ocurren al pujar. Configurando el TTL de DAX en unos pocos segundos, se pueden devolver datos casi en tiempo real mientras se reduce la carga de lectura de DynamoDB en más del 90%. Por otro lado, en cargas de trabajo analíticas donde se ejecutan Scans con condiciones diferentes cada vez, la tasa de aciertos de la caché de consultas será baja y la efectividad de DAX será limitada. En estos casos, es más apropiado exportar los datos de DynamoDB a S3 y analizarlos con Athena.