Prácticas recomendadas para Memorystore para Valkey

En esta página, se proporciona orientación para usar Memorystore para Valkey de manera óptima. En esta página, también se señalan los posibles problemas que debes evitar.

Prácticas recomendadas para la administración de la memoria

En esta sección, se describen estrategias para administrar la memoria de la instancia de modo que Memorystore para Valkey funcione de manera eficiente para tu aplicación.

Conceptos de administración de memoria

  • Uso de memoria: Es la cantidad de memoria que usa tu instancia. Tienes una capacidad de memoria fija. Puedes usar métricas para supervisar la cantidad de memoria que usas.

  • Política de expulsión: Memorystore para Valkey usa la política de expulsión volatile-lru. Puedes usar comandos de Valkey, como el comando EXPIRE, para establecer desalojos de claves.

Supervisa el uso de memoria de una instancia

Para supervisar el uso de memoria de una instancia de Memorystore para 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és que el uso de datos aumentará, aumenta el tamaño de la instancia para dejar espacio para los datos nuevos.

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

Si tienes problemas, comunícate con Google Cloud Atención al cliente.

Fragmentos de escala en el modo de clúster habilitado

Cuando escalas la cantidad de fragmentos en una instancia, te recomendamos que lo hagas durante períodos de escrituras bajas. El escalamiento durante períodos de uso elevado puede aumentar la presión de memoria en la instancia debido a la sobrecarga de memoria que causa la replicación o la migración de ranuras.

Si tu caso de uso de Valkey utiliza expulsiones de claves, reducir el tamaño de la instancia puede disminuir la tasa de aciertos de caché. Sin embargo, en este caso, no debes preocuparte por perder datos, ya que se espera el desalojo de claves.

Para los casos de uso de Valkey en los que no quieras perder claves, solo debes reducir la escala a una instancia más pequeña que aún tenga suficiente espacio para tus datos. El nuevo recuento de fragmentos objetivo debe permitir, al menos, 1.5 veces la memoria que usan los datos. En otras palabras, debes aprovisionar suficientes fragmentos para 1.5 veces la cantidad de datos que hay actualmente en tu instancia. Puedes usar la métrica /instance/memory/total_used_memory para ver cuántos datos se almacenan en tu instancia.

Prácticas recomendadas para el uso de la CPU

Si ocurre 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 en la zona no disponible. Te recomendamos que uses instancias altamente disponibles. Usar dos réplicas por fragmento (en lugar de una) proporciona recursos de CPU adicionales durante una interrupción. Además, te recomendamos que administres el uso de CPU de los nodos para que tengan suficiente sobrecarga de CPU para controlar el tráfico adicional de la capacidad perdida si se produce una interrupción zonal inesperada. Debes supervisar el uso de CPU para los elementos principales y las réplicas con la métrica Main Thread CPU Seconds /instance/cpu/maximum_utilization.

Según la cantidad de réplicas que aprovisiones por nodo, te recomendamos los siguientes objetivos de uso de CPU /instance/cpu/maximum_utilization:

  • En el caso de las instancias con 1 réplica por nodo, debes establecer un valor de /instance/cpu/maximum_utilization de 0.5 segundos para la instancia principal y la réplica.
  • En el caso de las instancias con 2 réplicas por nodo, debes establecer un valor de /instance/cpu/maximum_utilization de 0.9 segundos para la instancia principal y de 0.5 segundos para las réplicas.

Si los valores de la métrica superan estas recomendaciones, te recomendamos que aumentes la cantidad de fragmentos o réplicas en tu instancia.

Comandos de Valkey que consumen muchos recursos

Te recomendamos que evites usar comandos de Valkey que consuman muchos recursos. El uso de estos comandos puede generar los siguientes problemas de rendimiento:

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

En la siguiente tabla, se enumeran ejemplos de comandos de Valkey que consumen muchos recursos y se proporcionan alternativas que son eficientes en el uso de recursos.

Categoría Comando que requiere muchos recursos Alternativa eficiente en el uso de recursos
Ejecutar para todo el espacio de claves KEYS SCAN
Ejecuta un conjunto de claves de longitud variable LRANGE Limita el tamaño del rango que usas para una búsqueda.
ZRANGE Limita el tamaño del rango que usas para una búsqueda.
HGETALL HSCAN
SMEMBERS SSCAN
Bloquea la ejecución de una secuencia de comandos EVAL Asegúrate de que tu secuencia de comandos no se ejecute de forma indefinida.
EVALSHA Asegúrate de que tu secuencia de comandos no se ejecute de forma indefinida.
Cómo quitar archivos y vínculos DELETE UNLINK
Publicar y suscribirse PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Prácticas recomendadas para el cliente de Valkey

Evita 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. Luego, puedes realizar una prueba comparativa para ver si más conexiones ayudan sin saturar el recuento 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 una retirada exponencial con fluctuaciones. Esto ayuda a evitar que varios clientes sobrecarguen el servidor de forma simultánea.

Para instancias con el modo de clúster habilitado

Tu aplicación debe usar un cliente de Valkey compatible con clústeres cuando se conecte a una instancia de Memorystore para Valkey con el modo de clúster habilitado. Para ver ejemplos de clientes compatibles con clústeres y muestras de configuración, consulta Muestras de código de la biblioteca cliente. Tu cliente debe mantener un mapa de las ranuras de hash a los nodos correspondientes en la instancia para enviar solicitudes a los nodos correctos. Esto evita la sobrecarga de rendimiento causada por los redireccionamientos.

Asignación de clientes

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

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

  • Cuando se recibe un redireccionamiento MOVED del servidor, como en el caso de una conmutación por error cuando la réplica se hace cargo de todos los espacios que atendía el nodo principal anterior, o bien cuando se realiza un nuevo fragmentado y 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 en particular agotan el tiempo de espera de forma persistente.

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

  • Además, los clientes deben actualizar periódicamente la topología para mantenerlos activos ante cualquier cambio y conocer los cambios que no generen redireccionamientos o errores del servidor, como cuando se agregan nodos de réplica nuevos. Ten en cuenta que las conexiones obsoletas también se deben cerrar como parte de la actualización de la topología para reducir la necesidad de controlar las conexiones fallidas durante el tiempo de ejecución del comando.

Descubrimiento del cliente

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

El tamaño de la respuesta para los comandos de detección de clientes puede variar según el tamaño y la topología de la instancia. Las instancias más grandes con más nodos producen una respuesta más grande. Por lo tanto, es importante asegurarse de que la cantidad 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 la aplicación. Por lo tanto, es importante asegurarse de que cada cliente realice una sola solicitud de detección en un momento determinado (y almacene en caché el resultado en la memoria) y que la cantidad de clientes que realizan las solicitudes se mantenga dentro de un límite 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 común es que la aplicación cliente realiza varias solicitudes de reconexión y descubrimiento sin agregar retirada exponencial al reintentar. Esto puede hacer que el servidor de Valkey no responda durante un período prolongado, lo que provoca un uso de CPU muy alto.

Usa un extremo de detección para el descubrimiento de nodos

Usa el extremo de descubrimiento de Memorystore para Valkey para realizar el descubrimiento de nodos. El extremo de detección tiene alta disponibilidad y se balancea la carga en todos los nodos de la instancia. Además, el extremo de detección intenta enrutar las solicitudes de detección de nodos a los nodos con la vista de topología más actualizada.

Para las instancias con el modo de clúster inhabilitado

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

Prácticas recomendadas para la persistencia

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

Persistencia de RDB

Para obtener los mejores resultados cuando crees copias de seguridad de tu instancia con instantáneas de RDB, debes seguir estas prácticas recomendadas:

Administración de la memoria

Las instantáneas de RDB usan una bifurcación de procesos y un mecanismo de "copia al escribir" para tomar una instantánea de los datos del nodo. Según el patrón de escrituras en los nodos, la memoria utilizada de los nodos aumenta a medida que se copian las páginas a las que afectan las escrituras. En el peor de los casos, la huella de memoria puede duplicar el tamaño de los datos en el nodo.

Para garantizar que los nodos tengan suficiente memoria para completar la instantánea, debes mantener o establecer maxmemory en el 80% de la capacidad del nodo, de modo que el 20% se reserve para la sobrecarga. Para obtener más información, consulta Cómo supervisar el uso de memoria de una instancia. Esta sobrecarga de memoria, además de las instantáneas de supervisión, te ayuda a administrar tu carga de trabajo para que las instantáneas se realicen correctamente.

Instantáneas obsoletas

Recuperar nodos a partir de una instantánea obsoleta puede causar problemas de rendimiento en tu aplicación, ya que intenta conciliar una cantidad significativa de claves obsoletas o realizar otros cambios en tu base de datos, como un cambio de esquema. Si te preocupa la recuperación a partir de una instantánea obsoleta, puedes inhabilitar la función de persistencia de RDB. Una vez que vuelvas a habilitar la persistencia, se tomará una instantánea en el siguiente intervalo programado.

Impacto en el rendimiento de las instantáneas de RDB

Según tu patrón de carga de trabajo, las instantáneas de la RDB pueden afectar el rendimiento de la instancia y aumentar la latencia de tus aplicaciones. Puedes minimizar el impacto en el rendimiento de las instantáneas de RDB programándolas para que se ejecuten durante períodos de tráfico de instancias bajo si te sientes cómodo con instantáneas menos frecuentes.

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

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

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

Cuando configures una instancia sin réplicas, te recomendamos una arquitectura de una sola zona para mejorar la confiabilidad. Esto se debe a los siguientes motivos:

Minimiza el impacto de las interrupciones

Es menos probable que las interrupciones zonales afecten 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, en comparación con el 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, se agiliza la recuperación. Puedes responder aprovisionando rápidamente una instancia nueva en una zona en funcionamiento y redireccionando tu aplicación para que las operaciones se interrumpan lo menos posible.