Prácticas recomendadas para Memorystore para Valkey

En esta página, se proporciona orientación sobre el uso óptimo de Memorystore para Valkey. También se muestran 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 cuánta memoria 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 expulsiones 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 veas la /instance/memory/maximum_utilization métrica. Si el uso de memoria de la instancia se acerca al 80% y esperas que el uso de datos aumente, entonces escala verticalmente 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:

• Escala verticalmente el tamaño de la instancia.
• Disminuye el maxmemory parámetro de configuración.

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

Escala fragmentos 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 alto 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 usa expulsiones de claves, el escalamiento a un tamaño de instancia más pequeño puede reducir la tasa de aciertos de caché. Sin embargo, en esta circunstancia, no debes preocuparte por perder datos, ya que se espera la expulsión de claves.

Para los casos de uso de Valkey en los que no deseas perder claves, solo debes reducir la escala a una instancia más pequeña que aún tenga suficiente espacio para tus datos. Tu nuevo recuento de fragmentos de destino 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 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 CPU

Si se produce una interrupción zonal inesperada, esto genera una reducción de los recursos de CPU para tu instancia debido a la pérdida de capacidad de los nodos en la zona no disponible. Te recomendamos que uses instancias con alta disponibilidad. El uso de varias réplicas por fragmento (en lugar de una réplica por fragmento) proporciona recursos de CPU adicionales durante una interrupción. Puedes tener hasta cinco réplicas por fragmento.

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 nodos 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:

• Para las instancias con una réplica por nodo, establece un valor /instance/cpu/maximum_utilization de 0.5 segundos para el nodo principal y 0.5 segundos para la réplica.
• Para las instancias con dos réplicas por nodo o más, establece un valor /instance/cpu/maximum_utilization de 0.9 segundos para el nodo principal y 0.5 segundos para cada réplica.

Si los valores de la métrica superan estas recomendaciones, te recomendamos que aumentes la cantidad de fragmentos en tu instancia. Si tienes menos de cinco réplicas para tu instancia, también puedes escalar verticalmente la cantidad de réplicas, hasta un máximo de cinco réplicas.

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 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 se bloquea el subproceso principal de Valkey
• 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 cuanto a los recursos.

Nota: Además de consumir muchos recursos, a medida que aumenta el tamaño total de los datos, también aumenta el costo de usar estos comandos.

Para encontrar los comandos de larga duración que usas, usa SLOWLOG. Esta herramienta te proporciona una lista de los comandos que tardan más en ejecutarse. Como resultado, conoces los comandos que causan problemas de latencia. Para determinar alternativas eficientes en cuanto a los recursos para estos comandos, consulta la siguiente tabla.

Categoría	Comando que consume muchos recursos	Alternativa eficiente en cuanto a los recursos
Ejecutar para todo el espacio de claves	KEYS	SCAN
Ejecutar para un conjunto de claves de longitud variable	LRANGE	Limita el tamaño del rango que usas para una consulta.
	ZRANGE	Limita el tamaño del rango que usas para 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 de forma indefinida.
	EVALSHA	Asegúrate de que tu secuencia de comandos no se ejecute de forma indefinida.
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 conexión en Valkey

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

• Determina el tamaño del grupo de conexiones del cliente que sea mejor para ti. Un buen tamaño inicial para cada cliente es una conexión por nodo de Valkey. Luego, puedes realizar pruebas comparativas para ver si más conexiones ayudan sin saturar el recuento máximo de conexiones permitidas.

• Cuando el cliente se desconecta del servidor porque este agota el tiempo de espera, vuelve a intentarlo con una retirada exponencial con fluctuación. 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 el clúster cuando se conecte a una instancia de Memorystore para Valkey con el modo de clúster habilitado. Para obtener ejemplos de clientes compatibles con el clúster y configuraciones de muestra, consulta Muestras de código de la biblioteca cliente. Tu cliente debe mantener un mapa de ranuras hash en los nodos correspondientes de la instancia para enviar solicitudes a los nodos correctos. Esto evita la sobrecarga de rendimiento que causan las redirecciones.

Encuadre del cliente

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

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

• Cuando se recibe una redirección MOVED del servidor, como en el caso de una conmutación por error cuando todas las ranuras que entrega el nodo principal anterior son tomadas por la réplica o cuando se vuelve a fragmentar cuando las ranuras 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 un nodo principal se degrada a una réplica.

• Además, los clientes deben actualizar la topología de forma periódica para mantenerlos preparados para cualquier cambio y obtener información sobre los cambios que no generen redirecciones ni errores del servidor, como cuando se agregan nodos de réplica nuevos. 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 controlar las conexiones fallidas durante el tiempo de ejecución del comando.

Descubrimiento del cliente

Por lo general, el descubrimiento del cliente se realiza mediante la emisión de 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 descubrimiento del cliente 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. Como resultado, 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 descubrimiento 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 los límites para evitar sobrecargar el servidor.

Por ejemplo, cuando se inicia la aplicación cliente o se pierde la conexión del 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 una retirada exponencial cuando se vuelve a intentar. Esto puede hacer que el servidor de Valkey no responda durante un período prolongado, lo que provoca un uso muy alto de la CPU.

Usa un extremo de descubrimiento para el descubrimiento de nodos

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

Para instancias con el modo de clúster inhabilitado

Cuando te conectas 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 de lector para leer desde las réplicas y aislar el tráfico del nodo principal.

Si usas la estrategia de crear antes de destruir cuando realizas el mantenimiento en tu instancia, es posible que recibas el siguiente mensaje de error:

READONLY You can't write against a read only replica.

Para resolver este problema, detén la conexión a tu instancia. Luego, vuelve a crear la conexión.

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 de la copia de seguridad de tu instancia con instantáneas de RDB o agregar réplicas a tu instancia, usa las siguientes prácticas recomendadas:

Administración de la memoria

Las instantáneas de RDB usan una bifurcación de proceso y un mecanismo de "copia en escritura" para tomar una instantánea de los datos del nodo. Según el patrón de escrituras en los nodos, la memoria usada de los nodos crece a medida que se copian las páginas que tocan las escrituras. El espacio en memoria puede ser hasta el doble del tamaño de los datos en el nodo.

Para asegurarte de que los nodos tengan suficiente memoria para completar la instantánea, mantén o establece 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 supervisar las instantáneas, te ayuda a administrar tu carga de trabajo para tener instantáneas exitosas. Además, cuando agregues réplicas, disminuye el tráfico de escritura tanto como sea posible. Para obtener más información, consulta Supervisa el uso de memoria de una instancia.

Nota: Si agregas una réplica a una instancia que usa más del 80% de la memoria máxima de la instancia, la operación falla y recibes un mensaje de error.

Para resolver este problema, reduce el uso de memoria de tu instancia de una de las siguientes maneras:

• Reduce el espacio en memoria de tu instancia a menos del 80% de la memoria máxima permitida del nodo.
• Escala el tipo de nodo de tu instancia para que tenga más memoria.

Una vez que el uso de memoria de tu instancia esté por debajo del umbral del 80%, vuelve a agregar la réplica.

Instantáneas obsoletas

La recuperación de nodos a partir de una instantánea obsoleta puede causar problemas de rendimiento para tu aplicación, ya que intenta conciliar una cantidad significativa de claves obsoletas o de otros cambios en tu base de datos, como un cambio de esquema. Si te preocupa la recuperación 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 de instantáneas programado.

Impacto en el rendimiento de las instantáneas de RDB

Según el patrón de tu carga de trabajo, las instantáneas de 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, te recomendamos que evalúes cuidadosamente el impacto en el rendimiento y sopeses los beneficios de usar instantáneas de RDB para la carga de trabajo.

Agregar réplica

Para agregar una réplica, se requiere una instantánea de RDB. Para obtener más información sobre las instantáneas de RDB, consulta Administración de la memoria.

Cuándo usar una instancia de una sola zona

Si configuras una instancia para que no use réplicas, te recomendamos que uses una instancia de una sola zona. Esto se debe a los siguientes motivos:

Costo y rendimiento

Si tus principales motivaciones son minimizar el costo y tener un rendimiento máximo para tus clientes que se encuentran en la misma región, te recomendamos que elijas una instancia de una sola zona.

Minimiza el impacto de la interrupción

Cuando eliges una instancia de una sola zona, es menos probable que las interrupciones zonales afecten tu instancia. Si colocas todos los nodos dentro de una sola zona, la probabilidad de que una interrupción zonal afecte tu servidor disminuye del 100% al 33%. Hay un 33% de probabilidades de que la zona en la que se encuentra tu instancia deje de funcionar, en comparación con un 100% de probabilidades de que se vean afectados los nodos, que se encuentran en la zona no disponible.

Recuperación rápida

Si se produce una interrupción zonal para una instancia de una sola zona, Memorystore para Valkey optimiza la recuperación de tus datos. Puedes aprovisionar una instancia nueva en una zona en funcionamiento rápidamente y redireccionar tu aplicación para operaciones con interrupciones mínimas.

Habilita la seguridad de la capa de transporte (TLS)

En esta sección, se explican los beneficios de seguridad y las implicaciones de rendimiento del uso de la seguridad de la capa de transporte (TLS), junto con recomendaciones para su habilitación.

Beneficios de seguridad

Cuando usas TLS, obtienes los siguientes beneficios de seguridad:

• Autenticación de Identity and Access Management (IAM): TLS usa este tipo de autenticación para protegerse contra ataques de suplantación de identidad del servidor, como ataques de intermediarios.
• Encriptación en tránsito: Google CloudLa encriptación integrada de protege el tráfico dentro de la red de Google a nivel de la infraestructura. Sin embargo, esto implica confiar en el host de Google y en las pilas de red. Aunque esta encriptación es transparente y está habilitada de forma predeterminada, no es de extremo a extremo. Por otro lado, TLS usa la encriptación en tránsito en la capa de aplicación. Esta encriptación de extremo a extremo te brinda más control sobre tus claves y procesos de encriptación.
• Protección de tokens de autenticación: Si usas la autenticación de IAM, habilitar TLS minimiza el riesgo de exponer y filtrar tus tokens de autenticación.

Implicaciones de rendimiento

TLS afecta el rendimiento de las siguientes maneras:

• Establecer conexiones: Un cliente y un servidor que establecieron una sesión TLS pueden reanudarla sin repetir el proceso que consume muchos recursos para establecer la conexión entre el cliente y el servidor. Si habilitas la reanudación de TLS, reduces la sobrecarga de establecer una conexión entre el cliente y el servidor.

  Si no estableces la reanudación de TLS, establecer conexiones consume muchos recursos. Tanto para las conexiones nuevas como para las existentes, muchas conexiones entre el cliente y el servidor pueden provocar tiempos de espera de conexión. Esto puede causar un efecto de bola de nieve porque Memorystore para Valkey intenta restablecer las conexiones que agotaron el tiempo de espera, lo que aumenta los recursos que usa para establecer conexiones.

• Encriptar y desencriptar datos: La encriptación y desencriptación de datos implican operaciones que consumen mucha CPU y que afectan tanto al cliente como al servidor. Esto puede reducir la capacidad de tu instancia y aumentar su latencia.

Recomendaciones

Cuando consideres habilitar TLS, te recomendamos que evalúes tus políticas de seguridad mientras consideras los beneficios y las desventajas de TLS. Si eliges habilitar TLS, ten en cuenta las siguientes consideraciones:

• Habilitar la reanudación de TLS mitiga la sobrecarga para establecer conexiones. Se requiere una conexión entre el cliente y el servidor solo para la conexión inicial. Sin embargo, una expansión repentina del tamaño de la instancia del cliente puede generar una breve interrupción causada por el protocolo de enlace completo inicial de cada host cliente nuevo.
• Aunque es posible que algunas bibliotecas cliente no ofrezcan controles integrados para habilitar TLS, puedes usar código personalizado para integrar esta funcionalidad en tus instancias.