Latencia de microsegundos con Amazon DynamoDB Accelerator (DAX) - Diseño de caché en memoria
Explicamos la aceleración de lecturas de DynamoDB con DAX, las estrategias de caché y el diseño de clústeres.
Descripción general de DAX
DAX es una caché en memoria para DynamoDB que reduce la latencia de lectura de milisegundos a microsegundos. A diferencia de ElastiCache (Redis/Memcached), proporciona una API compatible con DynamoDB, por lo que la migración se completa simplemente cambiando el endpoint del SDK al clúster DAX. Un clúster DAX se despliega dentro de una VPC, con cada nodo manteniendo una réplica de los mismos datos en caché. El nodo primario maneja las escrituras mientras los nodos réplica distribuyen las lecturas, y las réplicas se promueven automáticamente en caso de fallo del primario.
Estrategia de caché y diseño de clúster
La caché de ítems almacena los resultados de GetItem y BatchGetItem, con expiración automática por TTL (5 minutos por defecto). La caché de consultas almacena los conjuntos de resultados de Query y Scan. Mediante write-through, cuando se ejecutan PutItem o UpdateItem, la caché también se actualiza, reduciendo el riesgo de devolver datos obsoletos en las lecturas. Se recomienda un clúster de al menos 3 nodos (Multi-AZ), y el tipo de nodo se selecciona según el volumen de datos a cachear. dax.r5.large (13.5 GB de memoria) es adecuado para cargas de trabajo medianas, mientras que dax.r5.xlarge (27 GB de memoria) es apropiado para grandes conjuntos de datos calientes.
Estrategia de caché y consistencia
DAX gestiona la caché en dos capas: caché de ítems y caché de consultas. La caché de ítems retiene los resultados de GetItem y BatchGetItem con un TTL (5 minutos por defecto). La caché de consultas retiene los resultados de Query y Scan. Las operaciones de escritura (PutItem, UpdateItem, DeleteItem) se reflejan tanto en DAX como en DynamoDB mediante write-through. Las lecturas con consistencia eventual se sirven desde la caché, mientras que las lecturas con consistencia fuerte acceden directamente a DynamoDB. Existe un trade-off: configurar un TTL corto reduce la tasa de aciertos de caché, mientras que un TTL largo reduce la frescura de los datos. Para aprender sobre la optimización del rendimiento de la caché de DynamoDB, los libros relacionados (Amazon) son una referencia útil.
Comparación entre DAX y ElastiCache
DAX es una caché dedicada a DynamoDB, y su mayor ventaja es que puede adoptarse simplemente reemplazando el endpoint del SDK de DynamoDB. No es necesario implementar lógica de invalidación de caché ni diseño de claves en la aplicación, ya que write-through mantiene automáticamente la consistencia. ElastiCache (Redis), por otro lado, puede cachear datos de fuentes distintas a DynamoDB (RDS, respuestas de APIs externas) y aprovecha estructuras de datos como Pub/Sub y conjuntos ordenados. La caché de consultas de DAX determina los aciertos por coincidencia exacta de parámetros, por lo que las tasas de aciertos disminuyen para cargas de trabajo donde las condiciones de filtro de Query cambian frecuentemente. En tales casos, diseñar claves de caché del lado de la aplicación con ElastiCache es más eficiente. DAX no cachea APIs transaccionales (TransactGetItems / TransactWriteItems), por lo que su efectividad es limitada para cargas de trabajo centradas en transacciones.
Errores de diseño y consideraciones operativas
Los clústeres DAX deben desplegarse dentro de una VPC. Al conectar desde Lambda, coloque Lambda en la misma VPC o acceda a través de un endpoint de VPC. Colocar Lambda en una VPC aumenta el tiempo de arranque en frío, por lo que considere usar Provisioned Concurrency. Durante fallos de nodos DAX, el SDK del cliente reintenta automáticamente, pero la latencia de lectura vuelve a milisegundos durante el failover (varios segundos). Las aplicaciones deben diseñarse para tolerar este aumento temporal de latencia. Los TTL de caché de ítems y caché de consultas se pueden configurar independientemente. Para tablas con escrituras frecuentes, acorte el TTL de la caché de ítems a 1 minuto o menos y establezca el TTL de la caché de consultas aún más corto para mantener la frescura de los datos. El escalado horizontal del clúster (agregar nodos) puede realizarse en línea, pero la reducción (eliminar nodos) implica redistribución de datos en caché y debe realizarse durante períodos de bajo tráfico.
Precios de DAX
Los precios de DAX se basan en la facturación por hora de los nodos. Un nodo dax.r5.large cuesta aproximadamente 0.269 dólares por hora (unos 194 dólares mensuales). Se recomienda una configuración mínima de 3 nodos (Multi-AZ), con un costo mensual de aproximadamente 582 dólares. Se compara el efecto de reducción de costos de las unidades de capacidad de lectura (RCU) de DynamoDB con el costo de los nodos DAX para determinar si la implementación de DAX es ventajosa en cargas de trabajo con muchas lecturas. Con una tasa de aciertos de caché del 90% o superior, se pueden reducir significativamente las RCU de DynamoDB, esperando un efecto de reducción que supere el costo de DAX.
Resumen
DAX es una caché en memoria para DynamoDB que logra latencias de lectura del orden de microsegundos. Mantiene la consistencia de escritura mediante caché write-through mientras reduce significativamente la carga de lectura con dos capas de caché: caché de ítems y caché de consultas. El efecto de reducción de costos de RCU de DynamoDB se vuelve notable con tasas de aciertos de caché del 90% o superiores, siendo ideal para cargas de trabajo intensivas en lectura.