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 for 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 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é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:

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

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

Se ajusta la escala de las particiones 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, escalar a un tamaño de instancia más pequeño puede reducir 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. Tu 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 de 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 reducen 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 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 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/instance/cpu/maximum_utilization objetivos de uso de CPU:

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

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

Si tu instancia experimenta un uso elevado de la CPU o si se agotan los recursos de la instancia (por ejemplo, por tener demasiadas conexiones), es posible que la instancia se comporte de forma incorrecta y que falten métricas externas.

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.

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

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

Categoría	Comando que requiere muchos recursos	Alternativa eficiente en el uso de recursos
Ejecutar para todo el espacio de claves	KEYS	SCAN
Ejecuta para 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 los umbrales de escalamiento

Los casos de umbral de escalamiento se dividen en las siguientes categorías:

• Ajuste de escala para el uso de memoria
• Ajuste de escala para el uso de CPU
• Escalamiento para mitigar los hotspots

Si tu carga de trabajo depende de la expulsión de claves, Google no recomienda aumentar la escala verticalmente para el uso de CPU o memoria. En estas cargas de trabajo, el uso de memoria suele alcanzar su capacidad máxima antes de que se produzcan desalojos automáticamente. Los aumentos repentinos de memoria resultantes bloquean las operaciones de reducción.

En las siguientes secciones, se detallan situaciones comunes y umbrales de métricas que podrían justificar el ajuste de escala.

Ajuste del uso de memoria

Para determinar cuándo realizar el ajuste de escala en función del uso de memoria, supervisa las métricas /instance/memory/average_utilization y /instance/memory/maximum_utilization. Para obtener más información sobre estas métricas, consulta Métricas de supervisión admitidas.

Si tu instancia cumple con alguna de las siguientes condiciones, considera activar una operación de expansión:

• El uso promedio de memoria de tu instancia supera el umbral sugerido del 70%.
• El uso máximo de memoria supera el 80% y el uso promedio de memoria supera el 50%.

Si tu instancia cumple con alguna de las siguientes condiciones, considera activar una operación de reducción:

• El uso promedio de memoria de tu instancia cae por debajo del umbral sugerido del 50%.
• El uso máximo de memoria cae por debajo del 60% y el uso promedio de memoria cae por debajo del 40%.

Ajuste de escala según el uso de CPU

Para determinar cuándo realizar el ajuste de escala en función del uso de la CPU, supervisa las métricas /instance/cpu/average_utilization y /instance/cpu/maximum_utilization.

Si tu instancia cumple con alguna de las siguientes condiciones, considera activar una operación de expansión:

• El uso promedio de CPU de tu instancia supera el umbral sugerido del 70%.
• El uso máximo de CPU supera el 80% y el uso promedio de CPU supera el 50%.

Si tu instancia cumple con alguna de las siguientes condiciones, considera activar una operación de reducción:

• El uso promedio de CPU de tu instancia cae por debajo del umbral sugerido del 50%.
• El uso máximo de CPU cae por debajo del 60% y el uso promedio de CPU cae por debajo del 40%.

Escalamiento para mitigar los hotspots

Memorystore for Valkey proporciona variaciones promedio y máximas de la misma métrica, que puedes usar para identificar los puntos críticos de esa familia de métricas. El valor máximo representa el nodo de instancia con mayor carga, mientras que el valor promedio representa la carga de toda la instancia. Si el valor máximo es significativamente mayor que el valor promedio, esto indica que un nodo específico está cargado de forma desproporcionada (un punto de acceso). Para resolver este problema, te recomendamos que escale horizontalmente tu instancia. Para obtener más información, consulta Cómo escalar la capacidad de la instancia.

Cuando observes una divergencia significativa entre las variaciones promedio y máxima, puedes ejecutar los comandos INFO memory y INFO cpu en los nodos de instancia para recopilar datos en tiempo real directamente de la instancia. Para obtener más información sobre cómo usar estos comandos, consulta INFO en la documentación de Valkey.

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 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 agotó el tiempo de espera del servidor, vuelve a intentarlo con una retirada exponencial con fluctuación. Esto ayuda a evitar que varios clientes sobrecarguen el servidor de forma simultánea.

Detecta y controla las conexiones que no responden

Te recomendamos que configures tu aplicación cliente para detectar conexiones que no responden a Memorystore for Valkey. Cuando se detecta una conexión que no responde, el cliente debe restablecerla. Para compilar una aplicación resiliente, recomendamos las siguientes configuraciones del cliente:

• Configura los parámetros de keep-alive de TCP: Establece los parámetros TCP keepalive time, TCP keepalive interval y TCP keepalive probes de modo que los clientes detecten y descarten las conexiones que no responden de forma proactiva, incluso cuando las conexiones estén inactivas. Por ejemplo, si estableces el parámetro TCP keepalive time en 30 segundos, TCP keepalive interval en 10 segundos y TCP keepalive probes en 3, los clientes restablecerán las conexiones inactivas que no responden en un minuto.
• Configura los tiempos de espera del usuario de TCP: Establece este tiempo de espera en tus clientes para restablecer las conexiones que tienen solicitudes pendientes y dejan de responder. Por ejemplo, si estableces el tiempo de espera en 15 segundos, los clientes restablecerán las conexiones que no responden y que tienen solicitudes pendientes después de 15 segundos.

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 for 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 para los nodos correspondientes en la instancia y 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 posiciones 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 segmentos que atendía el nodo principal anterior, o bien cuando se realiza un nuevo fragmentado y los segmentos 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 servidor principal se degrada a réplica.

• Además, los clientes deben actualizar periódicamente la topología para mantenerlos preparados para cualquier cambio y conocer los cambios que no generen redireccionamientos 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 de clientes

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 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 limitada 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 realice varias solicitudes de reconexión y descubrimiento sin agregar una 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 descubrir nodos. El extremo de descubrimiento 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 instancias con el modo de clúster inhabilitado

Cuando te conectes a una instancia con el modo de clúster inhabilitado, tu aplicación deberá 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.

Si usas la estrategia create-before-destroy cuando realizas tareas de 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 para la 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 cuando crees copias de seguridad de tu instancia con instantáneas de RDB o agregues 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 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 se accede con las escrituras. El espacio en memoria puede ser hasta el doble del tamaño de los datos en el nodo.

Para garantizar que los nodos tengan suficiente memoria para completar la instantánea, mantén o establece maxmemory en el 80% de la capacidad del nodo, de modo que el 20% se reserve para la sobrecarga. 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. Además, cuando agregues réplicas, reduce el tráfico de escritura lo más posible. Para obtener más información, consulta Cómo supervisar 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 fallará y recibirás 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.
• Aumenta 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

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 cualquier otro cambio en tu base de datos, como un cambio de esquema. Si te preocupa recuperarte 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 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 instancia bajo si te sientes cómodo con instantáneas menos frecuentes.

Por ejemplo, si tu instancia tiene poco tráfico de la 1 a.m. a las 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.

Cómo agregar una 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 memoria.

Cuándo usar una instancia de zona única

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 tu objetivo principal es minimizar los costos y tener un rendimiento máximo para los clientes que se encuentran en la misma región, te recomendamos que elijas una instancia de una sola zona.

Minimiza el impacto de las interrupciones

Cuando eliges una instancia de una sola zona, 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 tu servidor se reduce 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 los nodos, que se encuentran en la zona no disponible, se vean afectados.

Recuperación rápida

Si se produce una interrupción zonal en una instancia de una sola zona, Memorystore for 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 que las operaciones se interrumpan lo menos posible.

Habilitar la seguridad de la capa de transporte (TLS)

En esta sección, se explican los beneficios de seguridad y las implicaciones en el 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 los ataques de intermediarios.
• Encriptación en tránsito: La encriptación integrada deGoogle Cloudprotege el tráfico dentro de la red de Google a nivel de la infraestructura. Sin embargo, esto implica confiar en las pilas de host y de red de Google. Si bien 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 de TLS pueden reanudarla sin repetir el proceso de uso intensivo de 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, el establecimiento de conexiones requiere 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, ya que 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 requieren un uso intensivo de la CPU y que afectan tanto al cliente como al servidor. Esto puede reducir la capacidad de la instancia y aumentar su latencia.

Recomendaciones

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

• Habilitar la reanudación de TLS mitiga la sobrecarga para establecer conexiones. Solo se requiere una conexión entre el cliente y el servidor para la conexión inicial. Sin embargo, una expansión repentina del tamaño de la instancia del cliente podría provocar una breve interrupción causada por el handshake completo inicial de cada host cliente nuevo.
• Si bien 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.