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. En esta página, también se señalan los posibles problemas que se deben evitar.

Nota: Para ver ejemplos de configuración de clientes de clústeres de Redis, consulta Ejemplos de código de la biblioteca cliente.

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

En esta sección, se describen las estrategias para administrar la memoria de los clústeres de modo que Memorystore for Redis Cluster funcione de manera eficiente para tus aplicaciones cliente.

Conceptos de administración de la 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 expulsión : Memorystore para Redis Cluster usa la volatile-lru política de expulsión. Puedes usar comandos como el comando EXPIRE para configurar expulsiones de claves.

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

Consulta la métrica /cluster/memory/maximum_utilization. Si /cluster/memory/maximum_utilization está en 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 crezca, 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

Consulta la métrica /cluster/memory/maximum_utilization. Según la gravedad de la 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 escalar verticalmente el tamaño del clúster para mejorar el rendimiento.

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

Escala fragmentos

Cuando aumentas la cantidad de fragmentos en un clúster, debes hacerlo durante los períodos de escritura bajos. El escalamiento durante períodos de carga de escritura alta puede aumentar la presión de memoria en el clúster debido a la sobrecarga de memoria que causa la replicación o la migración de ranuras.

Si tu caso de uso de Redis usa expulsiones de claves, el escalamiento a un tamaño de clúster 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 Redis en los que no deseas perder claves, solo debes reducir la escala a un clúster más pequeño que aún tenga suficiente espacio para tus datos. La nueva cantidad 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 clúster. Puedes usar la métrica /cluster/memory/total_used_memory para ver cuántos datos se almacenan en tu clúster.

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 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. 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 las instancias principales y las réplicas con la métrica Main Thread CPU Seconds /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:

• Para los clústeres con una réplica por nodo, establece un valor /cluster/cpu/maximum_utilization de 0.5 segundos para la instancia principal y 0.5 segundos para la réplica.
• Para los clústeres con dos réplicas por nodo o más, establece un valor /cluster/cpu/maximum_utilization de 0.9 segundos para la instancia 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 clúster. Si tienes menos de cinco réplicas para tu clúster, también puedes escalar verticalmente la cantidad de réplicas, hasta un máximo de cinco réplicas.

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

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 de memoria causada por comandos que aumentan el uso de memoria
• Pérdida de datos durante la replicación y sincronización de nodos porque se bloquea el subproceso principal de Redis
• 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 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	DEL	UNLINK
Publicar y suscribirse	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Prácticas recomendadas para el cliente de Redis

Tu aplicación debe usar un cliente de Redis compatible con el clúster cuando se conecte a un clúster. Para obtener ejemplos de clientes compatibles con el clúster y configuraciones de muestra, consulta Ejemplos de código de la biblioteca cliente. Tu cliente debe mantener un mapa de ranuras hash en los nodos correspondientes del clúster para enviar solicitudes a los nodos correctos y evitar la sobrecarga de rendimiento causada por los redireccionamientos del clúster.

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 un redireccionamiento MOVED del servidor, como en el caso de una conmutación por error cuando la réplica se hace cargo de todas las ranuras que entrega el nodo principal anterior, 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 experimentan tiempos de espera de forma persistente.

• Cuando se recibe un error READONLY del servidor. Esto puede suceder cuando una instancia principal se degrada a 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 redireccionamientos ni errores del servidor, como cuando se agregan nodos de réplica nuevos. Ten en cuenta que también se deben cerrar las conexiones obsoletas 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 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 descubrimiento del cliente 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. Como resultado, 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 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 se 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 reintento. Esto puede hacer que el servidor de Redis no responda durante un período prolongado, lo que provoca un uso muy elevado de la CPU.

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 de la aplicación cliente.

• Cuando el cliente se desconecta del servidor debido al tiempo de espera, vuelve a intentarlo con una retirada exponencial con fluctuación. 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 está balanceado en todos los nodos del clúster. Además, el extremo de descubrimiento intenta enrutar las solicitudes de descubrimiento del clúster a los nodos con la vista de topología más actualizada.

Detecta y controla las conexiones que no responden

Te recomendamos que configures tu aplicación cliente para detectar conexiones que no responden a Memorystore para Redis Cluster. Cuando se detecta una conexión que no responde, el cliente debe restablecerla. Para compilar una aplicación resistente, te recomendamos las siguientes configuraciones de cliente:

• Configura los parámetros de keep-alive de TCP: establece los parámetros TCP keepalive time, TCP keepalive interval y TCP keepalive probes para que los clientes detecten y descarten de forma proactiva las conexiones que no responden, 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 restablecen 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 restablecen las conexiones que no responden que tienen solicitudes pendientes después de 15 segundos.

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

Administración de la memoria

Las instantáneas de RDB usan una bifurcación de proceso y 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, reduce el tráfico de escritura tanto como sea posible. Consulta Supervisa un clúster que tiene una carga de escritura alta para obtener más información.

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

Para resolver este problema, reduce el uso de memoria del clúster de una de las siguientes maneras:

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

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

Instantáneas obsoletas

La recuperación de nodos 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 cualquier otro cambio 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 del clúster 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 bajo del clúster si te sientes cómodo con instantáneas menos frecuentes.

Por ejemplo, si tu clúster tiene poco tráfico de 1 a.m. a 4 a.m., puedes establecer la hora de inicio en 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.

Agrega 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 la memoria.

Cuándo usar un clúster de una sola zona

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

Costo y rendimiento

Si tu objetivo principal es minimizar el costo y tener un rendimiento máximo para tus clientes que se encuentran en la misma región, te recomendamos que elijas un clúster de una sola zona.

Minimiza el impacto de la interrupción

Cuando eliges un clúster de una sola zona, es menos probable que las interrupciones zonales afecten tu clúster. 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 clúster falle, 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 un clúster de una sola zona, Memorystore for Redis Cluster optimiza la recuperación de tus datos. Puedes aprovisionar un clúster nuevo en una zona en funcionamiento rápidamente y redireccionar tu aplicación para operaciones con interrupciones mínimas.

Prácticas recomendadas para Lettuce

En esta sección, se describen las prácticas recomendadas para usar Lettuce para conectarse a un clúster.

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 unknownPartition.

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

Si usas TLS, obtendrás 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 servidores, 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 de TLS pueden reanudar la sesión sin repetir el proceso de uso intensivo de recursos de 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 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 porque Memorystore for Redis Cluster intenta restablecer las conexiones con tiempo de espera agotado, 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 del clúster 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 del clúster 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 clústeres.