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.

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

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

En esta sección, se describen 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 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 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 Google Cloud equipo de asistencia.

Fragmentos de escala

Cuando escalas la cantidad de fragmentos en un clúster, 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 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 utiliza expulsiones de claves, escalar a un tamaño de clúster más pequeño puede reducir tu 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 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. 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 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 la CPU

Si ocurre 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. 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 /cluster/cpu/maximum_utilization.

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

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

Si tu clúster experimenta un uso de CPU alto o si los recursos del clúster se agotan (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 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.

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	DEL	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 /cluster/memory/average_utilization y /cluster/memory/maximum_utilization. Para obtener más información sobre estas métricas, consulta Métricas de supervisión admitidas.

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

• El uso promedio de memoria de tu clúster 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 clúster cumple con alguna de las siguientes condiciones, considera activar una operación de reducción:

• El uso promedio de memoria de tu clúster 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 /cluster/cpu/average_utilization y /cluster/cpu/maximum_utilization.

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

• El uso promedio de CPU de tu clúster 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 clúster cumple con alguna de las siguientes condiciones, considera activar una operación de reducción:

• El uso de CPU promedio de tu clúster disminuye 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 Redis Cluster 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 del clúster con mayor carga, mientras que el valor promedio representa la carga de todo el clúster. 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 realices un escalamiento horizontal de tu clúster. 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 del clúster para recopilar datos en tiempo real directamente del clúster. Para obtener más información sobre el uso de estos comandos, consulta INFO en la documentación de Redis.

Prácticas recomendadas para el cliente de Redis

Tu aplicación debe usar un cliente de Redis compatible con clústeres cuando se conecte a uno. 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 para 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 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

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 descubrimiento 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 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 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 muy alta de la CPU.

Evita la sobrecarga de descubrimientos 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, se reintenta la conexión 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 una 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.

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 Redis Cluster. 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.

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 clúster con instantáneas de RDB o agregues réplicas a tu clúster, sigue 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 se accede con 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, 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.

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 fallará y recibirás 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 de tu clúster a menos del 80% de la memoria máxima permitida del nodo.
• Aumenta la escala del 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

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

Cuándo usar un clúster de zona única

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

Minimiza el impacto de las interrupciones

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 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 clúster 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 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 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 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 de unknownPartition.

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 provocar un efecto de bola de nieve, ya que Memorystore for Redis Cluster intenta restablecer las conexiones agotadas, 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 del clúster 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 del clúster 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 clústeres.