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.
Recomendaciones para la administración de 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 en 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 instancia de Valkey. La carga de escritura puede variar de normal a muy alta según tu caso de uso de Valkey y los patrones de uso de la aplicación.
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 una instancia que tiene una carga de escritura normal
Consulta la métrica /instance/cpu/maximum_utilization. Si /instance/cpu/maximum_utilization está al 100% o menos, tu instancia de Valkey tiene un buen rendimiento 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 el tamaño de la instancia para dejar espacio para los datos nuevos.
Supervisa una instancia que tiene una carga de escritura alta
Consulta la métrica /instance/memory/maximum_utilization. Según la gravedad de la carga de escritura alta, tu instancia puede experimentar problemas de rendimiento en los siguientes umbrales:
Las cargas de escritura muy altas pueden tener problemas si
/instance/memory/maximum_utilizationalcanza el 65% o más.Las cargas de escritura moderadamente altas pueden tener problemas si
/instance/memory/maximum_utilizationalcanza el 85% o más.
En estas situaciones, debes aumentar el tamaño de la instancia para mejorar el rendimiento.
Si tienes problemas o te preocupa que tu instancia tenga una carga de escritura alta, comunícate con la Asistencia de Google Cloud.
Escalamiento de fragmentos
Cuando escalas la cantidad de fragmentos en una instancia, debes realizar la escala durante 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 Valkey usa expulsiones de claves, el escalamiento a un tamaño de instancia más pequeño puede reducir tu porcentaje de aciertos de la caché. Sin embargo, en esta circunstancia, no debes preocuparte por perder datos, ya que se espera la expulsión de claves.
En el caso de los casos de uso de Valkey en los que no quieres perder claves, solo debes reducir la escala a una instancia más pequeña 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 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 se produce una interrupción zonal inesperada, se reducirán los recursos de la CPU de tu instancia debido a la pérdida de capacidad de los nodos en la zona no disponible. Te recomendamos que uses instancias de alta disponibilidad. El uso de dos réplicas por fragmento (en lugar de una) proporciona recursos de CPU adicionales durante una interrupción. 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 la CPU de 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 objetivos de uso de CPU de /instance/cpu/maximum_utilization:
- Para instancias con 1 réplica por nodo, debes establecer un valor de
/instance/cpu/maximum_utilizationde 0.5 segundos para la instancia principal y la réplica. - Para instancias con 2 réplicas por nodo, debes establecer un valor de
/instance/cpu/maximum_utilizationde 0.9 segundos para el principal y de 0.5 segundos para las réplicas.
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 Valkey costosos para la CPU
Debes evitar los comandos de Valkey que son costosos de ejecutar por varios motivos. En esta sección, se proporcionan ejemplos de los motivos por los que algunos comandos son costosos, pero esta lista no es exhaustiva.
Comandos que operan en todo el espacio de claves
- KEYS
Comandos que operan en un conjunto de claves de longitud variable
- LRANGE
- ZRANGE
- HGETALL
Comandos que bloquean la ejecución de una secuencia de comandos
- EVAL
- EVALSHA
Riesgos de usar comandos costosos
- Latencia alta y tiempos de espera del cliente
- Presión de la memoria causada por comandos que aumentan el uso de memoria.
- Pérdida de datos durante la replicación y sincronización de nodos debido al bloqueo del subproceso principal de Valkey
- Verificaciones de estado, observabilidad y replicación agotadas.
Prácticas recomendadas para clientes de Valkey
Tu aplicación debe usar un cliente de Valkey que reconozca el clúster cuando se conecte a una instancia de Memorystore para Valkey. Para ver ejemplos de clientes conscientes de clústeres y configuraciones de muestra, consulta Muestras de código de bibliotecas cliente. Tu cliente debe mantener un mapa de ranuras de hash para los nodos correspondientes en la instancia para enviar solicitudes a los nodos correctos y evitar la sobrecarga de rendimiento causada por los redireccionamientos.
Asignación de clientes
Los clientes deben obtener una lista completa de los intervalos y los nodos asignados en las siguientes situaciones:
Cuando se inicializa el cliente, debe propagar la asignación inicial de ranuras a nodos.
Cuando se recibe una redirección
MOVEDdel servidor, como en la situación de una conmutación por error cuando la réplica toma el control de todos los espacios que entregaba el nodo principal anterior, o cuando se vuelve a particionar cuando los espacios se mueven del nodo principal de origen al nodo principal de destino.Cuando se recibe un error
CLUSTERDOWNdel servidor o las conexiones a un servidor en particular se agotan de forma persistente.Cuando se recibe un error
READONLYdel servidor. Esto puede ocurrir cuando se cambia el estado de una instancia principal a réplica.Además, los clientes deben actualizar periódicamente la topología para mantener los clientes preparados para cualquier cambio y obtener información sobre los cambios que pueden no generar redireccionamientos o errores del servidor, como cuando se agregan nuevos nodos de réplica. Ten en cuenta que las conexiones inactivas 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 de clientes 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 de los comandos de descubrimiento 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. Como resultado, es importante garantizar que la cantidad de clientes que realizan el descubrimiento de la topología del nodo no crezca sin límites.
Estas actualizaciones de 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 almacenen 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 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 causa un uso muy alto de la CPU.
Evita la sobrecarga de descubrimiento en Valkey
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 del cliente.
Cuando el cliente se desconecta del servidor debido al tiempo de espera, vuelve a intentarlo con una retirada exponencial con jitter. Esto ayuda a evitar que varios clientes abrumen al servidor al mismo tiempo.
Usa el extremo de descubrimiento de Memorystore para Valkey para realizar el descubrimiento de 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 descubrimiento intenta enrutar las solicitudes de descubrimiento de nodos a los nodos con la vista de topología más actualizada.
Prácticas recomendadas de persistencia
En esta sección, se explican las prácticas recomendadas para la persistencia.
Persistencia de RDB
Para obtener los mejores resultados cuando crees una copia de seguridad de tu instancia con instantáneas de RDB, debes seguir las siguientes prácticas recomendadas:
Administración de la memoria
Las instantáneas de la RDB usan un proceso de bifurcación 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 utilizada de los nodos crece a medida que se copian las páginas que tocan las escrituras. En el peor de los casos, la huella de memoria puede ser el doble del tamaño de los datos en el nodo.
Para garantizar que los nodos tengan suficiente memoria para completar la instantánea, debes mantener o establecer maxmemory en el 80% de la capacidad del nodo para que el 20% se reserve para la sobrecarga. Consulta Cómo supervisar una instancia que tiene una carga de escritura alta para obtener más información. Esta sobrecarga de memoria, además de supervisar las instantáneas, te ayuda a administrar tu carga de trabajo para tener instantáneas exitosas.
Instantáneas inactivas
La recuperación de nodos de una instantánea inactiva puede causar problemas de rendimiento en tu aplicación, ya que intenta conciliar una cantidad significativa de claves inactivas o de otros cambios en tu base de datos, como un cambio de esquema. Si te preocupa recuperarte de una instantánea inactiva, 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 de las instantáneas de RDB en el rendimiento
Según el 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. Si no te molesta tener instantáneas menos frecuentes, puedes programar las instantáneas de RDB para que se ejecuten durante períodos de tráfico de instancias bajo y, así, minimizar el impacto en el rendimiento.
Por ejemplo, si tu instancia 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.
Elige una instancia de una sola zona si no usa réplicas
Cuando configures una instancia sin réplicas, te recomendamos una arquitectura de zona única 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 dentro de una sola zona, la probabilidad de que una interrupción zonal afecte a tu servidor disminuye del 100% al 33%. Esto se debe a que existe una probabilidad del 33% de que la zona en la que se encuentra tu instancia deje de estar disponible, en comparación con el 100% de probabilidad de que los nodos ubicados en la zona no disponible se vean afectados.
Recuperación rápida
Si se produce una interrupción zonal, la recuperación se optimiza. Para responder, puedes aprovisionar rápidamente una instancia nueva en una zona en funcionamiento y redireccionar tu aplicación para que las operaciones se interrumpan lo menos posible.