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

Introducción

La Unidad 5.3 estableció un límite de plataforma rígido: Managed PostgreSQL y MariaDB en IONOS no tienen réplicas de lectura, no tienen replicación gestionada en una segunda Cluster, y no tienen replicación entre regiones. Las réplicas síncronas y asíncronas dentro de una Cluster existen para conmutación por error, no para servir tráfico de lectura. Esto deja una pregunta obvia para cualquier Workload con una carga pesada de lectura: ¿de dónde proviene la escalabilidad de lectura? La respuesta es esta unidad. La capa de caché In-Memory DB absorbe la carga de lectura que una réplica de lectura relacional habría llevado, y al hacerlo, cierra la brecha de no-réplica-de-lectura con un patrón nativo en lugar de una característica que falta.

La misma capa hace un segundo trabajo que es igual de importante. La Unidad 4.3 mostró que VM Auto Scaling solo puede agregar y eliminar réplicas sin estado de manera segura. Cualquier sesión, bloqueo o estado transitorio que viva en la memoria de un Node de cómputo se pierde en el momento en que Node se escala. Externalizar ese estado en 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 el escalado automático sea seguro. Esta unidad termina construyendo la Cluster en la Data Center Designer y conectándola en la red privada frente a la capa relacional.

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

In-Memory DB se ofrece a través de IONOS DBaaS como una tienda de clave-valor compatible con OSS administrada, fijada a la versión estable legada de OSS Redis 7.2. Es un servidor de estructuras de datos, no solo una caché plana: almacena cadenas, hashes, listas, conjuntos, conjuntos ordenados, mapas de bits, hiperlogs, índices geoespaciales y flujos. Esa amplitud permite que una capa sirva 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 Node que responde a las consultas SELECT; IONOS DBaaS no ofrece eso. En su lugar, la aplicación lee a través de una caché: la primera solicitud de un valor falla y golpea PostgreSQL o MariaDB, el resultado se escribe en In-Memory DB, y cada solicitud posterior se sirve desde la memoria a una latencia de submilisegundo 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 principal permanece pequeña porque solo ve los fallos y las escrituras, mientras que el rendimiento de lectura se escala con la memoria de la caché en lugar de los núcleos de la base de datos. Esta es la elección de diseño indicada en la Unidad 2.4 como escalado basado en caché: usted compra RAM en la capa de caché en lugar de escalar verticalmente la base de datos.

Por qué es la condición previa para el escalado automático. Cuando la capa de la aplicación mantiene el estado de la sesión en la memoria del proceso local, cada evento de escalado hacia abajo destruye las sesiones ancladas al Node eliminado, y cada evento de escalado hacia arriba comienza un Node frío que otras solicitudes no pueden ver. Mover el estado de la sesión y el estado transitorio a la capa compartida In-Memory DB significa que cualquier réplica de cómputo puede servir cualquier solicitud, lo que es exactamente la condición previa sin estado que requiere la Unidad 4.3 antes de que un grupo de escalado automático basado en métricas pueda agregar o eliminar nodos Dedicated Core sin romper a los usuarios. La capa de caché es, por lo tanto, la mitad de lectura 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).

Qué hace y qué no hace el escalado de la caché. Un In-Memory DB Cluster se escala de dos maneras, y la distinción es fácil de confundir. El escalado vertical cambia los núcleos y RAM por Node y es la forma en que se aumenta el rendimiento; los nodos se modifican después de apagarse, por lo que los clusters de varios Node mantienen la interrupción mínima cambiando primero los secundarios y luego el principal. El escalado horizontal cambia el número de nodos, pero la documentación es explícita en que esto proporciona alta disponibilidad solo y no aumentará el rendimiento: el principal acepta todas las lecturas y escrituras y los secundarios son capacidad de respaldo para el failover automático, no puntos de lectura adicionales. Entonces, la caché escala las lecturas a través del tamaño de la memoria, no extendiendo las lecturas a través de réplicas, reflejando la propia realidad sin réplicas de lectura de la capa relacional un nivel hacia arriba.

1.1 FinCorp: cerrando la brecha de escalado de lectura

El camino de lectura del portal del cliente de FinCorp fue el problema abierto que quedó en la Unidad 5.3. Las vistas de resumen de cuenta y de historial de transacciones se leen muchas más veces de las que se escriben, y el PostgreSQL Cluster regulado en la capa de datos privada no se puede escalar agregando réplicas de lectura. FinCorp coloca un In-Memory DB Cluster en la misma red privada LAN, frente al PostgreSQL Cluster, y enruta las lecturas del portal a través de él. Los resúmenes de cuenta calientes se sirven desde la memoria; la base de datos se toca solo en caso de fallo de caché o escritura. El mismo Cluster mantiene el estado de la sesión del portal, por lo que la capa web estatal sin estado que enfrenta al público puede estar bajo el grupo de escalado automático Dedicated Core diseñado en la Unidad 4.3 sin perder sesiones cuando los nodos se escalan hacia abajo. Una capa administrada resuelve ambas restricciones, y nunca sale de la red privada.

2. Cache-Aside vs Write-Through

La caché solo ayuda si la aplicación la integra con una estrategia de lectura y escritura deliberada. Dos patrones dominan, 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 un nivel de escalado de lectura porque solo almacena en caché los datos que realmente se solicitan, manteniendo la memoria de la caché enfocada en el conjunto de trabajo. Su costo es el error de lectura en el primer acceso y la disciplina de invalidar o refrescar una clave en cada escritura para que la caché no sirva 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 raramente, cache-aside mantiene el conjunto de trabajo caliente residente y deja la cola larga para la base de datos.

Write-through mantiene la caché autoritativa inmediatamente después de una escritura al escribir ambas tiendas juntas, lo que se adapta a los datos leídos muy pronto después de ser escritos. Paga por esa frescura con la latencia de escritura, porque cada escritura ahora espera en ambas tiendas, y puede llenar la caché con entradas que nunca se leen posteriormente.

Una regla práctica: elija un Tiempo de Vida en las claves en caché que coincida con cuánto puede estar obsoleto un valor, y trate la expulsión como una última línea de defensa, no como el mecanismo de expiración principal. Como la caché sustituye el escalado de lectura y no es un sistema de registro, la aplicación siempre debe poder reconstruir cualquier valor desde el nivel relacional en caso de fallo. Las opciones de persistencia a continuación endurecen la caché contra los reinicios, pero el nivel relacional Cluster sigue siendo la fuente de verdad.

3. Colocación, dimensionamiento y expulsión

3.1 Colocación en red privada

In-Memory DB se conecta a exactamente una conexión de red: una conexión privada LAN por Cluster, definida por un centro de datos, un id de LAN y un IP en la subred de ese LAN. No hay un punto de conexión público y no hay administración de direcciones IP para el Cluster, así que usted elige un IP dentro de su subred (o utiliza la dirección IP de la subred que la plataforma asigna bajo DHCP) y el Cluster se vuelve accesible en esa dirección después de la provisión. Esto es la misma colocación de nivel de datos privados utilizada para las bases de datos relacionales y de documentos en este módulo: la caché se sitúa en la red privada LAN frente a la base de datos relacional Cluster, accesible solo desde el nivel de aplicación y el nivel de base de datos, nunca desde internet. Los clientes se conectan a través de TLS solo si el Cluster 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á activado, así que el arquitecto debe decidir activar TLS y luego tener al cliente conectarse con la opción TLS y el certificado CA correspondiente.

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

3.2 Dimensionamiento desde RAM y persistencia

Usted no provisiona el disco de la caché directamente. Usted elige el número de núcleos CPU y el RAM por Node, y la plataforma deriva el almacenamiento provisionado Block Storage a partir del RAM configurado y el modo de persistencia elegido, con un mínimo de 10 GB por Node aplicado para cada modo. La relación es fija:

El modo de persistencia es el elemento de dimensionamiento que más importa. El valor predeterminado es Ninguno, lo que significa que el conjunto de datos solo vive en memoria y se pierde en un reinicio; para una caché de lectura que siempre puede reconstruirse a partir del nivel relacional, Ninguno es a menudo la opción correcta y más barata. RDB escribe instantáneas periódicas de un momento dado; AOF registra cada operación de escritura y puede reconstruir el conjunto de datos en el reinicio; RDB_AOF combina ambos para la configuración más duradera y que más almacenamiento requiere. El intercambio es directo: más durabilidad multiplica el almacenamiento provisionado en relación con RAM, así que un Node de 32 GB dimensionado al máximo cuesta 32 GB de disco bajo Ninguno pero 256 GB bajo RDB y AOF. Dimensione el RAM para su conjunto de trabajo más el espacio de cabeza para la expulsión, luego elija el modo de persistencia más bajo que los requisitos de recuperación del Workload permitan.

Los techos duros, en relación con su cuota de contrato, son un máximo de 16 núcleos CPU, 32 GB RAM y 2 TB de almacenamiento por Cluster, hasta 5 nodos por Cluster. El motor Valkey subyacente tiene un valor predeterminado de un máximo de 10,000 conexiones de cliente (maxclients), que es un valor predeterminado de tecnología en lugar de un límite publicado de IONOS.

3.3 Expulsión

Cuando una caché Node alcanza su límite de memoria en datos entrantes, la política de expulsión decide qué se elimina. La política predeterminada es allkeys-lru, que expulsa la clave menos recientemente utilizada en todas las claves, el comportamiento correcto para una caché de lectura general donde cualquier clave es un candidato para la eliminació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 llevan una fecha de caducidad, lo que es adecuado cuando algunas claves nunca deben ser expulsadas; noeviction rechaza nuevas escrituras una vez que la memoria está llena, lo que convierte una caché en un punto de fallo duro y rara vez es correcto para un nivel de escalado. Para una caché de lectura, mantenga la política predeterminada allkeys-lru (o allkeys-lfu si la frecuencia de acceso es una señal de recencia mejor que la recencia) para que la caché siempre haga espacio para el conjunto de trabajo actual.

DCD Implementación paso a paso

Esta implementación proporciona una sola In-Memory DB Cluster y la coloca en el nivel de datos privado de FinCorp para que la aplicación pueda utilizarla como una caché de lectura en frente de la PostgreSQL Cluster de la Unidad 5.3. El requisito previo es un VDC existente con al menos un servidor en una LAN privada: la Cluster debe unirse a una LAN privada existente, y usted debe tener una IP en la subred de esa LAN para asignarla. Reutilice el VDC y la LAN de nivel de datos privado de FinCorp construidos en el Módulo 3.

Objetivo de la implementación: Proporcionar la caché y conectarla como una capa de lectura.

Pasos (en la Data Center Designer):

1. En la DCD, vaya a Menú > Bases de datos > In-Memory DB. La vista general de la In-Memory DB Cluster se abre y muestra los recursos asignados a su contrato.
2. Haga clic en Crear Cluster.
3. Defina las propiedades de la Cluster. Introduzca un Nombre para la Cluster; deje la Versión en el valor predeterminado 7.2. Establezca Instancias en el número de nodos: elija 1 para una caché de un solo Node o hasta 5 para alta disponibilidad. Recuerde que los nodos adicionales proporcionan conmutación por error, no aumento de rendimiento. Si establece más de un Node, aparece una opción de Tipo de replicación; es asíncrona por defecto para In-Memory DB.
4. Seleccione el número de recursos requeridos. Utilice los controles deslizantes para establecer el Número de CPUs y el Tamaño de RAM por instancia. RAM es la decisión de tamaño real: tamaño según el conjunto de trabajo, porque el multiplicador de persistencia y el disco por Node se derivan de él. Manténgase dentro de los límites de 16 núcleos y 32 GB por Cluster.
5. Conecte la Cluster 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 Cluster, y debe ser privada. Elija una dirección que no colisione con hosts existentes y no esté dentro de un rango reservado.
6. Programar el mantenimiento de la Cluster. 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 Contraseña para la Cluster . Estas credenciales solo se pueden establecer durante la creación y no se pueden cambiar después, así que regístrelas en su tienda de secretos de inmediato.
8. Revise el costo estimado que se muestra para la configuración, luego haga clic en Guardar. El estado de la Cluster muestra Ocupado durante la creación y Disponible cuando esté listo; la plataforma no lo notifica, así que poll hasta que el estado sea Disponible.

Una vez que la Cluster esté Disponible, apunte el cliente de caché de la aplicación al IP privado asignado en el puerto predeterminado 6379 (sobre TLS si lo habilitó en la configuración de la instancia), e implemente el camino de lectura de la caché desde la Sección 2: verifique la caché, caiga en la PostgreSQL en caso de error y poblé la caché en el camino de regreso.

Errores comunes:

• Tratar los nodos adicionales como escalado de lectura. Agregar nodos proporciona alta disponibilidad solo y no aumenta el rendimiento; escala las lecturas con más RAM y un redimensionamiento vertical, no más réplicas.
• Olvidar que las credenciales se establecen solo durante la creación. El nombre de usuario y la contraseña no se pueden actualizar más tarde, así que almacénelos en el momento de la creación; recuperar una contraseña perdida significa reconstruir la Cluster.
• Dejar la persistencia en el nivel incorrecto para el costo. Ninguno pierde todos los datos en el reinicio pero proporciona el menor disco; RDB y AOF juntos proporcionan 8 veces el RAM como disco. Para una caché de lectura pura que se reconstruye desde la base de datos, Ninguno suele ser 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 allkeys-lru a menos que una clave específica nunca deba ser expulsada.
• Asignar un IP en un rango reservado, o esperar una segunda conexión. Una Cluster 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 tenga los clientes reconectarse.

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

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

El host es el LAN IP privado asignado en el paso 5, el puerto es el predeterminado 6379, y el par --tls --cacert solo es necesario si TLS estaba habilitado en la configuración de la instancia (el punto de terminación administrado termina TLS con un certificado Let's Encrypt cuando está habilitado, pero TLS no está habilitado de forma predeterminada). No hay una dirección pública para conectarse, lo que es el objetivo: la caché solo es accesible desde dentro del centro de datos virtual. Usted puede encontrar más información sobre la configuración de TLS en la documentación del producto, pero tenga en cuenta que TLS es uno de los tres TLS que se pueden configurar.

Resumen

El nivel de caché In-Memory DB es el único componente que resuelve dos límites de plataforma a la vez. Es el sustituto nativo de las réplicas de lectura que Managed PostgreSQL y MariaDB no ofrecen, absorbiendo la carga de lectura a través de la memoria para que el primario relacional solo vea escrituras y fallos de caché, y es el almacén de estado compartido que hace que el nivel de aplicación sea verdaderamente sin estado y, por lo tanto, seguro para poner bajo VM Auto Scaling. Construido en el nivel de datos privado con un camino de lectura de caché, dimensionado desde RAM y modo de persistencia, y dejado en su valor de expulsión predeterminado sensato, permite a FinCorp escalar lecturas y escalar cómputo sin introducir nunca una réplica de lectura de base de datos o un punto de conexión público.

Puntos clave:

• No hay réplicas de lectura relacionales en IONOS; la caché In-Memory DB es la forma de escalar lecturas, sirviendo el conjunto de trabajo activo desde la memoria y tocando la base de datos solo en caso de fallos y escrituras.
• La caché también es el nivel de externalización de estado que hace que la precondición de estado sin estado para el auto-escalado (Unidad 4.3) sea real.
• Agregar nodos al Cluster proporciona alta disponibilidad, no rendimiento de lectura; aumente la capacidad agregando RAM y redimensionando verticalmente.
• El disco aprovisionado se deriva de RAM multiplicado por el multiplicador de persistencia (Ninguno 1x, RDB 2x, AOF 4x, RDB+AOF 8x), con un piso de 10 GB por Node; elija la persistencia más baja que permita el requisito de recuperación.
• El Cluster toma exactamente una conexión privada LAN, con TLS disponible si lo activa en la configuración de instancia, no tiene punto de conexión público y sus credenciales están fijas en la creación; el valor de expulsión predeterminado allkeys-lru es correcto para una caché de lectura.

Terminología importante:

• Cache-aside: Un patrón de lectura donde la aplicación lee la caché, vuelve a la base de datos en caso de fallo y población de la caché con el resultado; las escrituras van a la base de datos y invalidan o actualizan la clave en caché.
• Write-through: Un patrón donde la aplicación escribe en la caché y la base de datos juntas, manteniendo la caché autoritativa inmediatamente después de una escritura al costo de la latencia de escritura.
• Modo de persistencia: La configuración In-Memory DB (Ninguno, RDB, AOF o RDB_AOF) que controla si los datos sobreviven a un reinicio y, a través de un multiplicador fijo en RAM, cuánto Block Storage el Cluster aprovisiona.
• Política de expulsión: La regla (predeterminada allkeys-lru) que decide qué claves se eliminan cuando un Node alcanza su límite de memoria.

Lectura adicional

• Unidad 5.3: Bases de datos relacionales, para el límite de no-replica de lectura esta capa cierra
• Unidad 4.3: Elasticidad y VM Auto Scaling, para la precondición sin estado esta capa satisface
• Unidad 2.4: Arquitectura de costes y FinOps, para la economía de escalado basada en caché versus escalado vertical de base de datos