Prácticas recomendadas para Memorystore for Valkey

En esta página se ofrecen directrices para usar Memorystore for Valkey de forma óptima. En esta página también se indican los posibles problemas que debe evitar.

Prácticas recomendadas para gestionar la memoria

En esta sección se describen estrategias para gestionar la memoria de las instancias de forma que Memorystore for Valkey funcione de forma eficiente en tu aplicación.

Conceptos de gestión de la memoria

  • Uso de memoria: la cantidad de memoria que usa tu instancia. Tienes una capacidad de memoria fija. Puedes usar métricas para monitorizar la cantidad de memoria que estás usando.

  • Política de desalojo: Memorystore for Valkey usa la volatile-lru política de desalojo. Puedes usar comandos de Valkey, como el comando EXPIRE, para definir desalojos de claves.

Monitorizar el uso de memoria de una instancia

Para monitorizar el uso de memoria de una instancia de Memorystore for Valkey, te recomendamos que consultes la métrica /instance/memory/maximum_utilization. Si el uso de memoria de la instancia se acerca al 80% y prevé que el uso de datos aumentará, aumente el tamaño de la instancia para dejar espacio para los nuevos datos.

Si la instancia tiene un uso elevado de memoria, haz lo siguiente para mejorar el rendimiento:

Si tienes algún problema, ponte en contacto con el Google Cloud equipo de Asistencia.

Escalar particiones en el modo de clúster habilitado

Cuando aumentes el número de fragmentos de una instancia, te recomendamos que lo hagas durante los periodos de baja actividad de escritura. El escalado durante periodos de uso elevado puede ejercer presión sobre la memoria de tu instancia debido a la sobrecarga de memoria que provoca la replicación o la migración de ranuras.

Si tu caso práctico de Valkey usa desalojos de claves, escalar a un tamaño de instancia más pequeño puede reducir tu ratio de aciertos de caché. Sin embargo, en este caso no tienes que preocuparte por perder datos, ya que la expulsión de claves es algo esperado.

En los casos prácticos de Valkey en los que no quieras perder claves, solo debes reducir la escala a una instancia más pequeña que siga teniendo espacio suficiente para tus datos. El nuevo número de particiones de destino debe ser al menos 1,5 veces la memoria utilizada por los datos. Es decir, debes aprovisionar suficientes particiones para que quepan 1,5 veces la cantidad de datos que hay en tu instancia. Puede usar la métrica /instance/memory/total_used_memory para ver la cantidad de datos almacenados en su instancia.

Prácticas recomendadas para el uso de la CPU

Si se produce una interrupción zonal inesperada, se reducirán los recursos de CPU de tu instancia debido a la pérdida de capacidad de los nodos de la zona no disponible. Te recomendamos que uses instancias de alta disponibilidad. Si se usan dos réplicas por fragmento (en lugar de una réplica por fragmento), se proporcionan recursos de CPU adicionales durante una interrupción. Además, te recomendamos que gestiones el uso de la CPU de los nodos para que tengan suficiente margen de CPU para gestionar el tráfico adicional de la capacidad perdida si se produce una interrupción zonal inesperada. Debes monitorizar el uso de la CPU de los elementos principales y las réplicas con la métrica Segundos de CPU del hilo principal/instance/cpu/maximum_utilization.

En función del número de réplicas que aprovisiones por nodo, te recomendamos los siguientes /instance/cpu/maximum_utilizationobjetivos de uso de CPU:

  • En las instancias con 1 réplica por nodo, debes definir un valor de /instance/cpu/maximum_utilization de 0,5 segundos para la réplica y el nodo principal.
  • En el caso de las instancias con 2 réplicas por nodo, debes definir un valor /instance/cpu/maximum_utilization de 0,9 segundos para la réplica principal y de 0,5 segundos para las réplicas.

Si los valores de la métrica superan estas recomendaciones, le recomendamos que aumente el número de particiones o réplicas de su instancia.

Comandos de Valkey que consumen muchos recursos

Te recomendamos que no uses comandos de Valkey que consuman muchos recursos. Si usas estos comandos, pueden producirse los siguientes problemas de rendimiento:

  • Latencia alta y tiempos de espera del cliente
  • Presión de memoria causada por comandos que aumentan el uso de memoria
  • Pérdida de datos durante la replicación y la sincronización de nodos porque el hilo principal de Valkey está bloqueado
  • Comprobaciones del estado, observabilidad y replicación

En la siguiente tabla se muestran ejemplos de comandos de Valkey que consumen muchos recursos y se ofrecen alternativas que consumen menos.

Categoría Comando que requiere muchos recursos Alternativa eficiente en cuanto a recursos
Se ejecuta en todo el espacio de claves KEYS SCAN
Ejecutar para un conjunto de claves de longitud variable LRANGE Limita el tamaño del intervalo que usas en una consulta.
ZRANGE Limita el tamaño del intervalo que usas en una consulta.
HGETALL HSCAN
SMEMBERS SSCAN
Bloquear la ejecución de una secuencia de comandos EVAL Asegúrate de que tu secuencia de comandos no se ejecute indefinidamente.
EVALSHA Asegúrate de que tu secuencia de comandos no se ejecute indefinidamente.
Eliminar archivos y enlaces DELETE UNLINK
Publicar y suscribirse PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Prácticas recomendadas para clientes de Valkey

Evitar la sobrecarga de conexiones en Valkey

Para mitigar el impacto causado por una afluencia repentina de conexiones, te recomendamos lo siguiente:

  • Determina el tamaño del grupo de conexiones de cliente que mejor se adapte a tus necesidades. Un buen tamaño inicial para cada cliente es una conexión por nodo de Valkey. Después, puedes hacer una prueba comparativa para ver si más conexiones ayudan sin saturar el número máximo de conexiones permitidas.

  • Cuando el cliente se desconecta del servidor porque se agota el tiempo de espera del servidor, vuelve a intentarlo con retroceso exponencial con fluctuación. De esta forma, se evita que varios clientes sobrecarguen el servidor simultáneamente.

Para instancias con el modo de clúster habilitado

Tu aplicación debe usar un cliente de Valkey compatible con clústeres al conectarse a una instancia de Memorystore for Valkey con el modo Clúster habilitado. Para ver ejemplos de clientes compatibles con clústeres y configuraciones de muestra, consulta Ejemplos de código de bibliotecas de cliente. Tu cliente debe mantener un mapa de ranuras de hash a los nodos correspondientes de la instancia para enviar solicitudes a los nodos correctos. De esta forma, se evita la sobrecarga del rendimiento causada por las redirecciones.

Asignación de clientes

Los clientes deben obtener una lista completa de los espacios y los nodos asignados en las siguientes situaciones:

  • Cuando se inicializa el cliente, debe rellenar la asignación inicial de ranuras a nodos.

  • Cuando se recibe una redirección MOVED del servidor, como en el caso de una conmutación por error en la que la réplica se hace cargo de todos los espacios que servía el nodo principal anterior, o en el caso de un refragmentación en el que los espacios se mueven del nodo principal de origen al nodo principal de destino.

  • Cuando se recibe un error CLUSTERDOWN del servidor o las conexiones a un servidor concreto superan el tiempo de espera de forma persistente.

  • Cuando se recibe un error READONLY del servidor. Esto puede ocurrir cuando un elemento principal se degrada a réplica.

  • Además, los clientes deben actualizar periódicamente la topología para que estén preparados para cualquier cambio y para conocer los cambios que no provoquen redirecciones o errores del servidor, como cuando se añaden nuevos nodos de réplica. Ten en cuenta que las conexiones obsoletas también deben cerrarse como parte de la actualización de la topología para reducir la necesidad de gestionar las conexiones fallidas durante el tiempo de ejecución del comando.

Descubrimiento de clientes

El descubrimiento de clientes suele hacerse enviando un comando SLOTS, NODES o CLUSTER SHARDS al servidor de Valkey. Te recomendamos que uses el comando CLUSTER SHARDS. CLUSTER SHARDS sustituye al comando SLOTS (obsoleto) y proporciona una representación más eficiente y extensible de la instancia.

El tamaño de la respuesta de los comandos de detección de clientes puede variar en función del tamaño y la topología de la instancia. Las instancias más grandes con más nodos producen una respuesta mayor. Por lo tanto, es importante asegurarse de que el número de clientes que realizan el descubrimiento de la topología de nodos no crezca sin límites.

Estas actualizaciones de la topología de nodos son costosas en el servidor de Valkey, pero también son importantes para la disponibilidad de las aplicaciones. Por lo tanto, es importante asegurarse de que cada cliente haga una sola solicitud de descubrimiento en un momento dado (y almacene en caché el resultado en la memoria) y de que el número de clientes que hagan las solicitudes se mantenga limitado para evitar sobrecargar el servidor.

Por ejemplo, cuando la aplicación cliente se inicia o pierde la conexión con el servidor y debe realizar el descubrimiento de nodos, un error habitual es que la aplicación cliente haga varias solicitudes de reconexión y descubrimiento sin añadir retroceso exponencial al reintentar. Esto puede hacer que el servidor de Valkey no responda durante un periodo prolongado, lo que provoca un uso muy elevado de la CPU.

Usar un endpoint de descubrimiento para el descubrimiento de nodos

Usa el endpoint de descubrimiento de Memorystore for Valkey para descubrir nodos. El endpoint de descubrimiento tiene una alta disponibilidad y la carga se balancea entre todos los nodos de la instancia. Además, el endpoint de descubrimiento intenta enrutar las solicitudes de descubrimiento de nodos a los nodos con la vista de topología más actualizada.

En el caso de las instancias con el modo de clúster inhabilitado

Cuando se conecta a una instancia con el modo clúster inhabilitado, su aplicación debe conectarse al endpoint principal para escribir en la instancia y recuperar las escrituras más recientes. Tu aplicación también puede conectarse al endpoint de lectura para leer de las réplicas y aislar el tráfico del nodo principal.

Prácticas recomendadas de persistencia

En esta sección se explican las prácticas recomendadas para la persistencia.

Persistencia de RDB y adición de réplicas

Para obtener los mejores resultados al crear copias de seguridad de tu instancia con copias de seguridad de RDB o al añadir réplicas a tu instancia, sigue estas prácticas recomendadas:

Gestión de la memoria

Las copias de seguridad de RDB usan una bifurcación de procesos y un mecanismo de copia al escribir para crear una copia de seguridad de los datos de los nodos. En función del patrón de escritura en los nodos, la memoria utilizada de los nodos aumenta a medida que se copian las páginas afectadas por las escrituras. La huella de memoria puede ser hasta el doble del tamaño de los datos del nodo.

Para asegurarte de que los nodos tengan suficiente memoria para completar la instantánea, mantén o define maxmemory en el 80% de la capacidad del nodo para que el 20% se reserve para la sobrecarga. Esta sobrecarga de memoria, además de las monitorizaciones de las instantáneas, te ayuda a gestionar tu carga de trabajo para que las instantáneas se creen correctamente. Además, cuando añadas réplicas, reduce el tráfico de escritura tanto como sea posible. Para obtener más información, consulta Monitorizar el uso de memoria de una instancia.

Capturas obsoletas

Recuperar nodos a partir de una copia de seguridad obsoleta puede provocar problemas de rendimiento en tu aplicación, ya que intentará conciliar una cantidad significativa de claves obsoletas u otros cambios en tu base de datos, como un cambio de esquema. Si te preocupa recuperarte de una copia obsoleta, puedes inhabilitar la función de persistencia de RDB. Una vez que vuelvas a habilitar la persistencia, se hará una captura en el siguiente intervalo de capturas programado.

Impacto en el rendimiento de las copias de seguridad de RDB

En función del patrón de carga de trabajo, las copias de seguridad de RDB pueden afectar al rendimiento de la instancia y aumentar la latencia de las aplicaciones. Puedes minimizar el impacto en el rendimiento de las copias de seguridad de RDB programándolas para que se ejecuten durante periodos de poco tráfico de instancias si no te importa que las copias de seguridad se creen con menos frecuencia.

Por ejemplo, si tu instancia tiene poco tráfico de 1:00 a 4:00, puedes definir la hora de inicio a las 3:00 y el intervalo en 24 horas.

Si tu sistema tiene una carga constante y requiere instantáneas frecuentes, debes evaluar detenidamente el impacto en el rendimiento y sopesar las ventajas de usar instantáneas RDB para la carga de trabajo.

Añadir una réplica

Para añadir una réplica, se necesita una instantánea de RDB. Para obtener más información sobre las instantáneas de RDB, consulta Gestión de memoria.

Elige una instancia de una sola zona si tu instancia no usa réplicas

Cuando configures una instancia sin réplicas, te recomendamos que uses una arquitectura de una sola zona para mejorar la fiabilidad. Estos son los motivos:

Minimizar el impacto de las interrupciones

Es menos probable que las interrupciones zonales afecten a tu instancia. Si colocas todos los nodos en una sola zona, la probabilidad de que una interrupción zonal afecte a tu servidor se reduce del 100% al 33%. Esto se debe a que hay un 33% de probabilidades de que la zona en la que se encuentra tu instancia deje de funcionar, frente al 100% de probabilidades de que los nodos ubicados en la zona no disponible se vean afectados.

Recuperación rápida

Si se produce una interrupción zonal, la recuperación se simplifica. Puedes responder aprovisionando rápidamente una nueva instancia en una zona que funcione y redirigiendo tu aplicación para que las operaciones se interrumpan lo mínimo posible.