Prácticas recomendadas para Memorystore for Redis Cluster

En esta página, se proporciona orientación sobre el uso óptimo de Memorystore para Redis Cluster. 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 Redis Cluster funcione de manera eficiente para tu aplicación.

Conceptos de administración de memoria

• Carga de escritura: Es el volumen y la velocidad con los que agregas o actualizas claves en tu clúster de Redis. Tu carga de escritura puede variar de normal a muy alta según tu caso de uso de Redis y los patrones de uso de la aplicación.

• Política de desalojo: Memorystore for Redis Cluster usa la política de desalojo volatile-lru. Puedes usar comandos como EXPIRE para establecer desalojos para las claves.

Supervisa un clúster que tiene una carga de escritura normal

Visualiza la métrica /cluster/memory/maximum_utilization. Si /cluster/memory/maximum_utilization es del 100% o menos, tu clúster de Redis funciona bien cuando usas una carga de escritura normal.

Sin embargo, si el uso de memoria se acerca al 100% y esperas que el uso de datos aumente, debes escalar verticalmente el tamaño del clúster para dejar espacio para los datos nuevos.

Supervisa un clúster que tiene una carga de escritura alta

Visualiza la métrica /cluster/memory/maximum_utilization. Según la gravedad de tu carga de escritura alta, tu clúster puede experimentar problemas de rendimiento en los siguientes umbrales:

• Las cargas de escritura muy altas pueden experimentar problemas si /cluster/memory/maximum_utilization alcanza el 65% o más.

• Las cargas de escritura moderadamente altas pueden experimentar problemas si /cluster/memory/maximum_utilization alcanza el 85% o más.

En estos casos, debes aumentar el tamaño del clúster para mejorar el rendimiento.

Si tienes problemas o te preocupa que tu instancia tenga una carga de escritura alta, comunícate con el Google Cloud equipo de asistencia.

Cómo escalar fragmentos

Cuando escalas la cantidad de fragmentos en una instancia, debes hacerlo durante los períodos de escrituras bajas. El escalamiento durante períodos de carga de escritura alta 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 Redis utiliza expulsiones de claves, escalar a un tamaño de clúster más pequeño puede reducir la proporción 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 Redis en los que no quieras perder claves, solo debes reducir la escala a un clúster más pequeño 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 clúster. Puedes usar la métrica /cluster/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 clúster debido a la pérdida de capacidad de los nodos en la zona no disponible. Te recomendamos que uses clústeres de alta disponibilidad. Usar dos réplicas por fragmento (en lugar de una) proporciona recursos de CPU adicionales durante una interrupción. Además, recomendamos administrar 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 servidores principales y las réplicas con la métrica /cluster/cpu/maximum_utilization.

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

• En el caso de las instancias con una réplica por nodo, establece un valor de /cluster/cpu/maximum_utilization de 0.5 segundos para la instancia principal y de 0.5 segundos para la réplica, cuando la réplica se designe como réplica de lectura.
• Para las instancias con dos réplicas por nodo, establece un valor de /cluster/cpu/maximum_utilization de 0.8 segundos para la instancia principal y de 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 o réplicas en tu instancia.

Comandos de Redis que consumen muchos recursos

Te recomendamos que evites usar comandos de Redis 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 Redis está bloqueado
• Verificaciones de estado, observabilidad y replicación insuficientes

En la siguiente tabla, se enumeran ejemplos de comandos de Redis 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 clientes de Redis

Tu aplicación debe usar un cliente de Redis compatible con clústeres cuando se conecte a una instancia de Memorystore para Redis Cluster. 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 el clúster con el fin de enviar solicitudes a los nodos correctos y evitar la sobrecarga de rendimiento causada por los redireccionamientos del clúster.

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

Por lo general, el descubrimiento del cliente se realiza con un comando CLUSTER SLOT, CLUSTER NODE o CLUSTER SHARDS al servidor de Redis. Te recomendamos que uses el comando CLUSTER SHARDS. CLUSTER SHARDS reemplaza el comando CLUSTER SLOTS (obsoleto) y proporciona una representación más eficiente y extensible del clúster.

El tamaño de la respuesta para los comandos de detección de clientes del clúster puede variar según el tamaño y la topología del clúster. Los clústeres 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 del clúster no crezca sin límites.

Estas actualizaciones de topología son costosas en el servidor de Redis, 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 del clúster, 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 Redis no responda durante un período prolongado, lo que provoca una utilización de CPU muy alta.

Evita la sobrecarga de descubrimiento en Redis

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

• Implementa un grupo de conexiones de cliente con un tamaño finito y pequeño para limitar la cantidad de conexiones entrantes simultáneas desde la aplicación cliente.

• Cuando el cliente se desconecta del servidor debido a un tiempo de espera agotado, vuelve a intentarlo con una retirada exponencial con fluctuaciones. Esto ayuda a evitar que varios clientes sobrecarguen el servidor al mismo tiempo.

• Usa el extremo de descubrimiento de Memorystore for Redis Cluster para realizar el descubrimiento del clúster. El extremo de descubrimiento tiene alta disponibilidad y se balancea la carga en todos los nodos del clúster. Además, el extremo de descubrimiento intenta enrutar las solicitudes de descubrimiento de clústeres a los nodos con la vista de topología más actualizada.

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 de 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, 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. Consulta Supervisa un clúster que tiene una carga de escritura alta para obtener más información.

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.

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.

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.

Prácticas recomendadas para la lechuga

En esta sección, se describen las prácticas recomendadas para usar Lettuce y conectarse a una instancia de Memorystore para Redis Cluster.

Actualiza los valores de los parámetros

Cuando uses Lettuce, cambia el parámetro validateClusterNodeMembership a false. De lo contrario, cuando cambie la topología, es posible que recibas errores de unknownPartition.