Unidad 5.5: Base de datos en memoria (capa de caché)

Introducción

La Unidad 5.3 estableció un límite de plataforma estricto: PostgreSQL y MariaDB administrados en IONOS CLOUD no tienen réplicas de solo lectura, no tienen replicación administrada a un segundo clúster y no tienen replicación entre regiones. Las réplicas síncronas y asíncronas dentro de un clúster existen para la conmutación por error, no para atender tráfico de lectura. Esto deja una pregunta obvia para cualquier carga de trabajo intensiva en lecturas: ¿de dónde proviene la escalabilidad de lectura? La respuesta es esta unidad. La capa de caché de In-Memory DB absorbe la carga de lectura que una réplica de lectura relacional habría soportado, y al hacerlo, cierra la brecha de ausencia de réplicas de lectura con un patrón nativo en lugar de una función ausente.

La misma capa realiza una segunda función que es igual de importante. La Unidad 4.3 mostró que VM Auto Scaling solo puede agregar y eliminar réplicas sin estado de forma segura. Cualquier sesión, bloqueo o estado transitorio que resida en la memoria de un nodo de cómputo se pierde en el momento en que ese nodo se reduce. Externalizar ese estado a una capa de memoria compartida es lo que hace que la capa de aplicación sea genuinamente sin estado, y por lo tanto lo que hace que la escalabilidad automática sea segura. Esta unidad termina construyendo el clúster en Data Center Designer y conectándolo en la red privada frente a la capa relacional.

1. La capa de escalado de lecturas y externalización de estado

In-Memory DB se ofrece a través de IONOS CLOUD DBaaS como un almacén de valores por clave administrado y compatible con Redis OSS, fijado en la versión estable 7.2 de Redis OSS heredada. Es un servidor de estructuras de datos, no solo una caché plana: almacena cadenas, hash, listas, conjuntos, conjuntos ordenados, mapas de bits, hyperloglogs, índices geoespaciales y streams. Esa amplitud permite que una sola capa cumpla dos roles arquitectónicos a la vez.

Por qué sustituye a las réplicas de lectura. Una réplica de lectura relacional escala las lecturas duplicando el conjunto de datos en otro nodo que responde a las consultas SELECT; IONOS CLOUD DBaaS no ofrece esa opción. En su lugar, la aplicación lee a través de una caché: la primera solicitud de un valor no encuentra el dato y consulta PostgreSQL o MariaDB, el resultado se escribe en In-Memory DB, y todas las solicitudes posteriores se sirven desde la memoria con una latencia inferior al milisegundo sin tocar la base de datos. Aprovechar la caché minimiza las consultas a la base de datos, reduciendo significativamente el tráfico y los recursos necesarios, lo que permite una capa de escalado rápida y rentable. La base de datos relacional principal se mantiene pequeña porque solo ve fallos de caché y escrituras, mientras que el rendimiento de lecturas escala con la memoria de la caché y no con los núcleos de la base de datos. Esta es la decisión de diseño señalada en la Unidad 2.4 como escalado horizontal basado en caché: se compra RAM en la capa de caché en lugar de escalar verticalmente la base de datos.

Por qué es el requisito previo para el escalado automático. Cuando la capa de aplicación mantiene el estado de la sesión en la memoria local del proceso, cada evento de reducción de escala destruye las sesiones fijadas al nodo eliminado, y cada evento de aumento de escala inicia un nodo frío que otras solicitudes no pueden ver. Mover el estado de la sesión y el estado transitorio a la capa compartida de In-Memory DB significa que cualquier réplica de cómputo puede atender cualquier solicitud, que es exactamente el requisito previo de ausencia de estado que la Unidad 4.3 exige antes de que un grupo de escalado automático basado en métricas pueda añadir o eliminar nodos Dedicated Core sin interrumpir a los usuarios. Por lo tanto, la capa de caché es la mitad de lecturas del patrón sin réplicas de lectura (5.3) y la mitad de externalización de estado del escalado automático seguro (4.3).

Lo que hace y lo que no hace escalar la caché. Un clúster de In-Memory DB escala de dos maneras, y la distinción es fácil de confundir. El escalado vertical cambia los núcleos y la RAM por nodo y es la forma de aumentar el rendimiento; los nodos se modifican después de haberse apagado, por lo que los clústeres multinodo mantienen la interrupción al mínimo cambiando primero los secundarios y luego el primario. El escalado horizontal cambia el número de nodos, pero la documentación es explícita en que esto solo proporciona alta disponibilidad y no aumentará el rendimiento: el primario acepta todas las lecturas y escrituras, y los secundarios son capacidad en espera para el conmutación automática por fallo, no puntos de acceso de lectura adicionales. Por lo tanto, la caché escala las lecturas a través del tamaño de la memoria, no distribuyendo las lecturas entre réplicas, reflejando la propia realidad de la capa relacional de no tener réplicas de lectura un nivel más arriba.

1.1 FinCorp: cerrando la brecha de escalado de lecturas

La ruta de lectura del portal de clientes de FinCorp era el problema abierto que dejó la Unidad 5.3. Las vistas de resumen de cuenta e historial de transacciones se leen muchas más veces de las que se escriben, y el clúster de PostgreSQL regulado en la capa de datos privada no puede escalarse añadiendo réplicas de lectura. FinCorp coloca un clúster de In-Memory DB en la misma LAN privada, delante del clúster de PostgreSQL, y enruta las lecturas del portal a través de él. Los resúmenes de cuenta frecuentes se sirven desde la memoria; la base de datos se consulta solo en un fallo de caché o en una escritura. El mismo clúster mantiene el estado de la sesión del portal, por lo que la capa web sin estado orientada al público puede someterse al grupo de escalado automático de Dedicated Core diseñado en la Unidad 4.3 sin perder sesiones cuando los nodos reducen su escala. Una sola capa administrada resuelve ambas restricciones, y nunca sale de la red privada.

2. Cache-Aside frente a Write-Through

La caché solo resulta útil si la aplicación la integra mediante una estrategia deliberada de lectura y escritura. Dos patrones predominan, y la elección es una decisión de arquitectura de aplicación que la plataforma no toma por usted.

La siguiente tabla contrasta los dos patrones de integración:

Cache-aside es el valor predeterminado para una capa de escalado de lecturas, ya que solo almacena en caché los datos que se solicitaron efectivamente, manteniendo la memoria de la caché enfocada en el conjunto de trabajo. Su costo es el fallo por acceso frío en la primera consulta y la disciplina de invalidar o actualizar una clave en cada escritura para que la caché no proporcione un valor obsoleto después de que la base de datos cambie. Para el portal de FinCorp, donde un pequeño conjunto de cuentas se lee constantemente y la mayoría se lee rara vez, cache-aside mantiene el conjunto de trabajo activo residente y deja la cola larga a la base de datos.

Write-through mantiene la caché como fuente autoritativa inmediatamente después de una escritura al escribir en ambos almacenes a la vez, lo cual es adecuado para datos que se leen poco después de ser escritos. Paga esa frescura con latencia de escritura, porque cada escritura ahora espera por ambos almacenes, y puede llenar la caché con entradas que nunca se leen posteriormente.

Una regla práctica: elija un tiempo de vida (Time To Live) para las claves en caché que coincida con el nivel de obsolescencia aceptable de un valor, y trate la expulsión como una medida de respaldo, no como el mecanismo principal de expiración. Dado que la caché sustituye al escalado de lecturas y no es un sistema de registro, la aplicación siempre debe poder reconstruir cualquier valor desde la capa relacional en caso de fallo. Las opciones de persistencia a continuación refuerzan la caché frente a reinicios, pero el clúster relacional sigue siendo la fuente de verdad.

3. Colocación, dimensionamiento y expulsión

3.1 Colocación en red privada

In-Memory DB se adjunta a exactamente una conexión de red: una única conexión de LAN privada por clúster, definida por un centro de datos, un identificador de LAN y una IP dentro de la subred de esa LAN. No existe un punto de acceso público ni gestión de direcciones IP para el clúster, por lo que usted elige una IP dentro de su subred (o utiliza la IP de la subred que la plataforma asigna mediante DHCP) y el clúster se vuelve accesible en esa dirección después del aprovisionamiento. Esta es la misma colocación en la capa de datos privada utilizada para las bases de datos relacionales y de documentos en este módulo: la caché se ubica en la LAN privada, delante del clúster relacional, y es accesible únicamente desde la capa de aplicaciones y la capa de bases de datos, nunca desde internet. Los clientes se conectan mediante TLS solo si el clúster ha sido configurado explícitamente para utilizarlo (TLS no está activado de forma predeterminada), con el certificado del servidor emitido por Let's Encrypt cuando está habilitado, por lo que el arquitecto debe decidir habilitar TLS y luego el cliente debe conectarse con la opción TLS y el certificado de autoridad de certificación correspondiente.

Los siguientes rangos de IP están reservados por la plataforma y no pueden utilizarse para conexiones de In-Memory DB:

3.2 Dimensionamiento según RAM y persistencia

Usted no aprovisiona directamente el disco de la caché. Usted elige el número de núcleos de CPU y la RAM por nodo, y la plataforma deriva el Block Storage aprovisionado a partir de la RAM configurada y el modo de persistencia elegido, aplicando un mínimo de 10 GB por nodo para cada modo. La relación es fija:

El modo de persistencia es el parámetro de dimensionamiento más importante. El valor predeterminado es Ninguna, lo que significa que el conjunto de datos reside solo en memoria y se pierde en caso de reinicio; para una caché de lectura a través pura que siempre puede reconstruirse desde la capa relacional, Ninguna suele ser la opción correcta y más económica. RDB realiza instantáneas puntuales periódicas; AOF registra cada operación de escritura y puede reconstruir el conjunto de datos al reiniciar; RDB_AOF combina ambos para la configuración más duradera y, a la vez, la que más almacenamiento consume. La compensación es directa: mayor durabilidad multiplica el almacenamiento aprovisionado en relación con la RAM, por lo que un nodo de 32 GB dimensionado al máximo consume 32 GB de disco con Ninguna, pero 256 GB con RDB y AOF. Dimensione la RAM según su conjunto de trabajo activo más un margen para la expulsión, y luego elija el modo de persistencia más bajo que permita el conjunto de requisitos de recuperación de la carga de trabajo.

Los límites máximos, frente a la cuota de su contrato, son de 16 núcleos de CPU, 32 GB de RAM y 2 TB de almacenamiento por clúster, con un máximo de 5 nodos por clúster. El motor Valkey subyacente tiene un valor predeterminado de 10.000 conexiones de cliente (maxclients), lo cual es un valor predeterminado de la tecnología y no un límite publicado de IONOS CLOUD.

3.3 Expulsión

Cuando un nodo de caché alcanza su límite de memoria con los datos entrantes, la política de expulsión determina qué se elimina. La política predeterminada es allkeys-lru, que expulsa la clave menos utilizada recientemente entre todas las claves, el comportamiento adecuado para una caché de lectura a través general donde cualquier clave es candidata a la expulsión. El conjunto completo de políticas admitidas es noeviction, allkeys-lru, allkeys-lfu, allkeys-random, volatile-lru, volatile-lfu, volatile-random y volatile-ttl. Las políticas volatile-* solo expulsan claves que tienen una fecha de expiración, lo cual es apropiado cuando algunas claves nunca deben ser expulsadas; noeviction rechaza nuevas escrituras una vez que la memoria está llena, lo que convierte a la caché en un punto de fallo duro y rara vez es correcto para una capa de escalado. Para una capa de lectura con caché a un lado, mantenga la política predeterminada allkeys-lru (o allkeys-lfu si la frecuencia de acceso es una señal mejor que la recencia) para que la caché siempre deje espacio para el conjunto de trabajo activo actual.

Recorrido de implementación de DCD

Este recorrido aprovisiona un único clúster de In-Memory DB y lo coloca en la capa de datos privada de FinCorp para que la aplicación pueda utilizarlo como caché de lectura a través (read-through) frente al clúster de PostgreSQL de la Unidad 5.3. El requisito previo es un VDC existente con al menos un servidor en una LAN privada: el clúster debe unirse a una LAN privada existente, y debe disponer de una IP en la subred de esa LAN para asignarla. Reutilice el VDC de FinCorp y la LAN de la capa de datos privada creados en el Módulo 3.

Objetivo de la construcción: Aprovisionar la caché y configurarla como una capa de lectura a través (read-through).

Pasos (en Data Center Designer):

1. En DCD, vaya a Menú > Bases de datos > In-Memory DB. Se abre la vista general del clúster de In-Memory DB y muestra los recursos asignados a su contrato.
2. Haga clic en Crear clúster.
3. Defina las propiedades del clúster. Introduzca un Nombre para el clúster; deje Versión en el valor predeterminado 7.2. Establezca Instancias en el número de nodos: elija 1 para una caché de un solo nodo o hasta 5 para alta disponibilidad. Recuerde que los nodos adicionales proporcionan conmutación por error, no capacidad de lectura. Si configura más de un nodo, aparece la opción Tipo de replicación; es asíncrona por defecto para In-Memory DB.
4. Seleccione el número de recursos necesarios. Use los controles deslizantes para establecer el Número de CPUs y el Tamaño de RAM por instancia. La RAM es la decisión real de dimensionamiento: dimensione la RAM según el conjunto de trabajo, porque el multiplicador de persistencia y el disco por nodo se derivan de ella. Manténgase dentro de los límites de 16 núcleos y 32 GB por clúster.
5. Conecte el clúster con un VDC. Seleccione el centro de datos, la LAN privada y una dirección IP (con CIDR) dentro de la subred de esa LAN. Solo se permite una conexión por clúster, y debe ser privada. Elija una dirección que no colisione con hosts existentes y que no se encuentre dentro de un rango reservado.
6. Programe el mantenimiento del clúster. Establezca el día de la semana y la hora de inicio para la ventana de mantenimiento semanal. Elija una ventana de bajo tráfico real en lugar de dejarla sin programar, porque las actualizaciones de versión y los reinicios ocurren aquí y pueden interrumpir brevemente las conexiones.
7. Defina los usuarios. Introduzca un Nombre de usuario y una Contraseña para el clúster. Estas credenciales solo se pueden establecer en la creación y no se pueden cambiar después, así que regístrelas inmediatamente en su almacén de secretos.
8. Revise el costo estimado mostrado para la configuración y luego haga clic en Guardar. El ESTADO del clúster muestra Ocupado durante la creación y Disponible cuando está listo; la plataforma no le notifica, así que consulte el estado hasta que sea Disponible.

Una vez que el clúster esté Disponible, dirija el cliente de caché de la aplicación a la IP privada asignada en el puerto predeterminado 6379 (sobre TLS si lo habilitó en la configuración de la instancia) e implemente la ruta de lectura a través (cache-aside) de la Sección 2: verifique la caché, recurra a PostgreSQL en caso de fallo de caché y rellene la caché en el camino de regreso.

Errores comunes:

• Tratar los nodos adicionales como escalado de lectura. Agregar nodos solo proporciona alta disponibilidad y no aumenta el rendimiento; escale las lecturas con más RAM y un redimensionamiento vertical, no con más réplicas.
• Olvidar que las credenciales se establecen solo en la creación. El nombre de usuario y la contraseña no se pueden actualizar después, así que guárdelos en el momento de la creación; recuperar una contraseña perdida significa reconstruir el clúster.
• Dejar la persistencia en la capa incorrecta para el costo. None pierde todos los datos al reiniciar pero aprovisiona el menor disco; RDB y AOF juntos aprovisionan 8 veces la RAM como disco. Para una caché de lectura a través pura que se reconstruye desde la base de datos, None suele ser lo correcto.
• Elegir noeviction para una caché de escalado. Cuando la memoria se llena, noeviction rechaza nuevas escrituras y convierte la caché en un punto de fallo; mantenga el valor predeterminado de allkeys-lru a menos que una clave específica nunca deba ser expulsada.
• Asignar una IP en un rango reservado, o esperar una segunda conexión. Un clúster toma exactamente una conexión de LAN privada, y los rangos reservados por la plataforma (por ejemplo 10.233.0.0/18) no se pueden utilizar.
• No programar una ventana de mantenimiento real. Las actualizaciones y los reinicios se ejecutan en la ventana semanal y pueden interrumpir brevemente las conexiones, así que colóquela deliberadamente en un período tranquilo y asegúrese de que los clientes se reconecten.

Una breve conexión de cliente ilustra la restricción de TLS y punto final privado que el texto establece:

redis-cli -h 192.168.1.100 -p 6379 --tls --cacert ca.crt -a "$PASSWORD" ping

El host es la IP privada de la LAN asignada en el paso 5, el puerto es el 6379 por defecto, y el par --tls --cacert solo es necesario si se habilitó TLS en la configuración de la instancia (el punto de conexión administrado termina TLS con un certificado de Let's Encrypt cuando está habilitado, pero TLS no está activado de forma predeterminada). No existe una dirección pública a la que conectarse, y ese es el objetivo: la caché es accesible únicamente desde dentro del VDC.

Resumen

La capa de caché de In-Memory DB es el único componente que resuelve dos limitaciones de la plataforma a la vez. Es el sustituto nativo de las réplicas de lectura que las instancias administradas de PostgreSQL y MariaDB no ofrecen, absorbiendo la carga de lectura a través de la memoria para que la base de datos relacional primaria solo reciba escrituras y fallos de caché, y es el almacén de estado compartido que hace que la capa de aplicación sea verdaderamente sin estado y, por lo tanto, segura para someterla a VM Auto Scaling. Construida sobre la capa de datos privada con una ruta de lectura cache-aside, dimensionada a partir de la RAM y el modo de persistencia, y configurada con su predeterminado de expulsión razonable, permite a FinCorp escalar las lecturas y el cómputo sin introducir nunca una réplica de lectura de base de datos ni un punto de acceso público.

Puntos clave:

• No hay réplicas de lectura relacionales en IONOS CLOUD; la caché de In-Memory DB es la forma de escalar las lecturas, sirviendo el conjunto de trabajo caliente desde la memoria y accediendo a la base de datos solo en fallos y escrituras.
• La caché también es la capa de externalización de estado que hace real la precondición sin estado para el escalado automático (Unidad 4.3).
• Agregar nodos al clúster proporciona alta disponibilidad, no ancho de banda de lectura; aumente la capacidad agregando RAM y redimensionando verticalmente.
• El disco aprovisionado se deriva de la RAM multiplicada por el multiplicador de persistencia (None 1x, RDB 2x, AOF 4x, RDB+AOF 8x), con un mínimo de 10 GB por nodo; elija el nivel de persistencia más bajo que permita el requisito de recuperación.
• El clúster admite exactamente una conexión de LAN privada, con TLS disponible si lo habilita en la configuración de la instancia, no tiene punto de acceso público, y sus credenciales se fijan en la creación; la expulsión predeterminada allkeys-lru es correcta para una caché de lectura a través.

Terminología importante:

• Cache-aside: Un patrón de lectura a través en el que la aplicación lee la caché, recurre a la base de datos en caso de fallo y rellena la caché con el resultado; las escrituras van a la base de datos e invalidan o actualizan la clave en caché.
• Write-through: Un patrón en el que la aplicación escribe simultáneamente en la caché y en la base de datos, manteniendo la caché como fuente de autoridad inmediatamente después de una escritura a costa de la latencia de escritura.
• Modo de persistencia: La configuración de In-Memory DB (None, RDB, AOF o RDB_AOF) que controla si los datos sobreviven a un reinicio y, a través de un multiplicador fijo sobre la RAM, cuánto Block Storage aprovisiona el clúster.
• Política de expulsión: La regla (predeterminada allkeys-lru) que decide qué claves se eliminan cuando un nodo alcanza su límite de memoria.

Lectura adicional

• Unidad 5.3: Bases de datos relacionales, para el límite de réplica de solo lectura que este nivel cierra
• Unidad 4.3: Elasticidad y VM Auto Scaling, para la precondición sin estado que este nivel satisface
• Unidad 2.4: Arquitectura de costos y FinOps, para la economía de escalado horizontal basado en caché frente al escalado vertical de la base de datos