Pilar de eficiencia en el ElastiCache rendimiento de Amazon Well-Architected Lens - Amazon ElastiCache (RedisOSS)

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Pilar de eficiencia en el ElastiCache rendimiento de Amazon Well-Architected Lens

El pilar de eficiencia del rendimiento se centra en el uso eficiente de recursos informáticos y de TI. Los temas clave incluyen la selección de los tipos y tamaños de recursos correctos en función de los requisitos de la carga de trabajo, la supervisión del rendimiento y la toma de decisiones informadas para mantener la eficiencia a medida que evolucionan las necesidades empresariales.

PE 1: ¿Cómo monitoriza el rendimiento de su ElastiCache clúster de Amazon?

Introducción a nivel de pregunta: Al comprender las métricas de supervisión existentes, puede identificar la utilización actual. La supervisión adecuada puede ayudar a identificar posibles obstáculos que afecten al rendimiento de su clúster.

Ventaja a nivel de pregunta: Comprender las métricas asociadas a su clúster puede ayudar a guiar las técnicas de optimización que pueden reducir la latencia y aumentar el rendimiento.

  • [Obligatorio] Pruebas de rendimiento de referencia con un subconjunto de la carga de trabajo.

    • Debe supervisar el rendimiento de la carga de trabajo real mediante mecanismos como las pruebas de carga.

    • Supervisa las CloudWatch métricas mientras realizas estas pruebas para comprender mejor las métricas disponibles y establecer una línea base de rendimiento.

  • [Lo mejor] En el caso de las cargas de trabajo ElastiCache (de RedisOSS), cambie el nombre de los comandos que son costosos desde el punto de vista computacional, por ejemploKEYS, para limitar la capacidad de los usuarios de ejecutar comandos de bloqueo en los clústeres de producción.

    • ElastiCache Las cargas de trabajo (RedisOSS) que ejecutan el motor 6.x pueden aprovechar el control de acceso basado en roles para restringir determinados comandos. El acceso a los comandos se puede controlar creando usuarios y grupos de usuarios con la AWS consola o CLI asociando los grupos de usuarios a un clúster (Redis). ElastiCache OSS En Redis OSS 6, cuando RBAC está activado, podemos usar «- @dangerous" y no permitirá el uso de comandos caros comoKEYS,, MONITORSORT, etc. para ese usuario.

    • Para la versión 5.x del motor, cambie el nombre de los comandos mediante el rename-commands parámetro del grupo de parámetros del clúster ElastiCache (RedisOSS).

  • [Mejor] Analice las consultas lentas y busque técnicas de optimización.

    • En el ElastiCache caso de las cargas de trabajo (de RedisOSS), analiza el registro lento para obtener más información sobre tus consultas. Por ejemplo, puede utilizar el siguiente comando, redis-cli slowlog get 10, para mostrar los últimos 10 comandos que superaron los umbrales de latencia (10 segundos de forma predeterminada).

    • Algunas consultas se pueden realizar de manera más eficiente utilizando estructuras de datos complejas ElastiCache (RedisOSS). Por ejemplo, en el caso de las búsquedas de rangos de estilos numéricos, una aplicación puede implementar índices numéricos simples con conjuntos ordenados. La administración de estos índices puede reducir los escaneos realizados en el conjunto de datos y devolver los datos con una mayor eficiencia de rendimiento.

    • Para las cargas de trabajo ElastiCache (RedisOSS), redis-benchmark proporciona una interfaz sencilla para probar el rendimiento de diferentes comandos mediante entradas definidas por el usuario, como el número de clientes y el tamaño de los datos.

    • Dado que Memcached solo admite comandos simples a nivel de clave, considere la posibilidad de crear claves adicionales como índices para evitar iterar a través del espacio de claves para atender las consultas de los clientes.

  • [Recursos]:

PE 2: ¿Cómo distribuye el trabajo entre los nodos de su ElastiCache clúster?

Introducción a nivel de preguntas: La forma en que su aplicación se conecta a ElastiCache los nodos de Amazon puede afectar al rendimiento y la escalabilidad del clúster.

Ventaja a nivel de pregunta: Al utilizar de forma adecuado los nodos disponibles en el clúster garantizará que el trabajo se distribuya entre los recursos disponibles. Las siguientes técnicas también ayudan a evitar que haya recursos inactivos.

  • [Obligatorio] Haga que los clientes se conecten al punto final adecuado. ElastiCache

    • ElastiCache (RedisOSS) implementa diferentes puntos finales según el modo de clúster que se utilice. Si el modo de clúster está habilitado, ElastiCache proporcionará un punto final de configuración. Para el modo de clúster desactivado, ElastiCache proporciona un punto final principal, que normalmente se utiliza para las escrituras, y un punto final de lectura para equilibrar las lecturas entre las réplicas. La implementación correcta de estos puntos de conexión resultará en un mejor rendimiento y en operaciones de escalado más sencillas. Evite conectarse a puntos de conexión de nodos individuales a menos que haya un requisito específico para hacerlo.

    • Para los clústeres de Memcached de varios nodos, ElastiCache proporciona un punto final de configuración que permite la detección automática. Se recomienda utilizar un algoritmo de hash para distribuir el trabajo de manera uniforme entre los nodos de caché. Muchas bibliotecas cliente de Memcached implementan un hash coherente. Consulte la documentación de la biblioteca que va a utilizar para ver si admite el uso consistente de hash y saber cómo implementarlo. Encontrará más información sobre la implementación de estas funciones aquí.

  • [Mejor] Aproveche el modo de clúster ElastiCache (RedisOSS) habilitado para mejorar la escalabilidad.

    • ElastiCache Los clústeres (RedisOSS) (habilitados para el modo clúster) admiten operaciones de escalado en línea (saliente/entrada y arriba/abajo) para ayudar a distribuir los datos de forma dinámica entre los fragmentos. El uso del punto de conexión de configuración garantizará que los clientes compatibles con clústeres puedan adaptarse a los cambios en la topología del clúster.

    • También puede reequilibrar el clúster moviendo las ranuras hash entre los fragmentos disponibles en su clúster (Redis ElastiCache ) (habilitado para el modo de clúster). OSS Esto ayuda a distribuir el trabajo de manera más eficiente entre las particiones disponibles.

  • [Mejor] Implemente una estrategia para identificar y corregir las teclas de acceso rápido de su carga de trabajo.

    • Tenga en cuenta el impacto de las estructuras de OSS datos multidimensionales de Redis, como listas, flujos, conjuntos, etc. Estas estructuras de datos se almacenan en OSS claves de Redis únicas, que residen en un solo nodo. Una clave multidimensional muy grande tiene el potencial de utilizar más capacidad de red y memoria que otros tipos de datos y puede provocar un uso desproporcionado de ese nodo. Si es posible, diseñe la carga de trabajo de modo que distribuya el acceso a los datos entre varias claves discretas.

    • Las teclas de acceso rápido de la carga de trabajo pueden influir en el rendimiento del nodo en uso. Para las cargas de trabajo ElastiCache (de RedisOSS), puede detectar las teclas de acceso rápido redis-cli --hotkeys si existe una política de LFU memoria máxima.

    • Considere la posibilidad de replicar las teclas de acceso rápido en varios nodos para distribuir el acceso a ellas de manera más uniforme. Este enfoque requiere que el cliente escriba en varios nodos principales (el OSS nodo de Redis en sí no proporcionará esta funcionalidad) y que mantenga una lista de nombres clave para leer, además del nombre de clave original.

    • EElastiCacheLa versión 6 de (RedisOSS) admite el almacenamiento en caché del lado del cliente asistido por el servidor. Esto permite a las aplicaciones esperar a que se modifique una clave antes de volver a realizar llamadas de red a ella. ElastiCache

  • [Recursos]:

PE 3: En el caso del almacenamiento en caché de las cargas de trabajo, ¿cómo se realiza el seguimiento de la eficacia y el rendimiento de la memoria caché y se informa al respecto?

Introducción a nivel de preguntas: El almacenamiento en caché es una carga de trabajo habitual ElastiCache y es importante que comprenda cómo gestionar la eficacia y el rendimiento de la memoria caché.

Ventaja a nivel de pregunta: Es posible que su aplicación muestre signos de un rendimiento lento. La capacidad de utilizar métricas específicas de la memoria caché para tomar una decisión sobre cómo aumentar el rendimiento de la aplicación es fundamental para la carga de trabajo de la memoria caché.

  • [Obligatorio] Mida y realice un seguimiento a lo largo del tiempo de la proporción de aciertos de la caché. La eficiencia de la memoria caché está determinada por su proporción de aciertos de la caché. La proporción de aciertos de la caché es el total de aciertos de caché dividido por el total de aciertos y errores. Cuanto más se acerque a 1 esté la proporción, más eficaz será la memoria caché. Una baja proporción de aciertos de caché se debe al volumen de errores de caché. Los errores de caché se producen cuando la clave solicitada no se encuentra en la memoria caché. Una clave no está en la memoria caché porque ha sido expulsada o eliminada, ha caducado o no ha existido nunca. Comprenda por qué las claves no están en la memoria caché y desarrolle las estrategias adecuadas para tenerlas en la memoria caché.

    [Recursos]:

  • [Obligatorio] Mida y recopile el rendimiento de la caché de su aplicación junto con los valores de latencia y CPU utilización para saber si necesita realizar ajustes en sus componentes time-to-live o en otros componentes de la aplicación. ElastiCache proporciona un conjunto de CloudWatch métricas para las latencias agregadas de cada estructura de datos. Estas métricas de latencia se calculan mediante la estadística commandstats del INFO comando ElastiCache (RedisOSS) y no incluyen la red ni el tiempo de E/S. Este es solo el tiempo que tarda ElastiCache (RedisOSS) en procesar las operaciones.

    [Recursos]:

  • [Lo mejor] Elija la estrategia de almacenamiento en caché adecuada para sus necesidades. Una baja proporción de aciertos de caché se debe al volumen de errores de caché. Si su carga de trabajo está diseñada para tener un bajo volumen de errores de caché (como comunicación en tiempo real), es mejor revisar las estrategias de almacenamiento en caché y aplicar las resoluciones más adecuadas para la carga de trabajo, como la instrumentación de consultas para medir la memoria y el rendimiento. Las estrategias reales que implemente para completar y mantener su caché dependen del tipo de datos que sus clientes necesiten almacenar en la caché, así como de los patrones de acceso a dichos datos. Por ejemplo, es poco probable que utilice la misma estrategia tanto para las recomendaciones personalizadas en una aplicación de streaming como para las noticias más populares.

    [Recursos]:

PE 4: ¿Cómo optimiza la carga de trabajo el uso de los recursos y las conexiones de red?

Introducción a nivel de preguntas: Muchos clientes de aplicaciones admiten ElastiCache (RedisOSS) y ElastiCache (Memcached) y las implementaciones pueden variar. Debe comprender la administración de redes y conexiones implementada para analizar el posible impacto en el rendimiento.

Ventaja a nivel de pregunta: El uso eficiente de los recursos de red puede mejorar la eficiencia del rendimiento de su clúster. Las siguientes recomendaciones pueden reducir las demandas de red y mejorar la latencia y el rendimiento del clúster.

  • [Obligatorio] Administre de forma proactiva las conexiones a su clúster. ElastiCache

    • La agrupación de conexiones en la aplicación reduce la sobrecarga del clúster que se crea al abrir y cerrar conexiones. Supervise el comportamiento de la conexión en Amazon CloudWatch mediante CurrConnections yNewConnections.

    • Cierre correctamente las conexiones del cliente cuando corresponda para evitar fugas de conexiones. Las estrategias de administración de conexiones incluyen cerrar correctamente las conexiones que no están en uso y establecer tiempos de espera de conexión.

    • Para las cargas de trabajo de Memcached, hay una cantidad configurable de memoria reservada para gestionar las conexiones denominada memcached_connections_overhead.

  • [Mejor] Comprima objetos grandes para reducir la memoria y mejorar el rendimiento de la red.

    • La compresión de datos puede reducir la cantidad de rendimiento de red requerida (Gbps), pero aumenta la cantidad de trabajo de la aplicación para comprimir y descomprimir datos.

    • La compresión también reduce la cantidad de memoria que consumen las claves

    • En función de las necesidades de su aplicación, considere las ventajas y desventajas entre la relación y la velocidad de compresión.

  • [Recursos]:

PE 5: ¿Cómo se gestiona la eliminación o la expulsión de claves?

Introducción a nivel de preguntas: las cargas de trabajo tienen requisitos y comportamientos esperados diferentes cuando un nodo del clúster se acerca a los límites de consumo de memoria. ElastiCache (RedisOSS) tiene diferentes políticas para gestionar estas situaciones.

Ventaja a nivel de pregunta: La gestión adecuada de la memoria disponible y la comprensión de las políticas de expulsión ayudarán a garantizar el conocimiento del comportamiento del clúster cuando se superen los límites de memoria de las instancias.

  • [Obligatorio] Analice el acceso a los datos para evaluar qué política aplicar. Identifique una política de memoria máxima adecuada para controlar si se realizan expulsiones en el clúster y cómo se hacen.

    • La expulsión tiene lugar cuando se consume la cantidad máxima de memoria del clúster y existe una política que permite la expulsión. El comportamiento del clúster en esta situación depende de la política de expulsión especificada. Esta política se puede administrar mediante el grupo maxmemory-policy de parámetros del clúster ElastiCache (RedisOSS).

    • La política predeterminada volatile-lru libera memoria al desalojar las claves con un tiempo de caducidad (valor) establecido. TTL Las políticas utilizadas con menos frecuencia (LFU) y las utilizadas con menos frecuencia (LRU) eliminan las claves en función del uso.

    • Para las cargas de trabajo de Memcached, existe una LRU política predeterminada que controla los desalojos en cada nodo. El número de desalojos de tu ElastiCache clúster de Amazon se puede monitorizar mediante la métrica de desalojos de Amazon. CloudWatch

  • [Mejor] Estandarice el comportamiento de eliminación para controlar el impacto en el rendimiento de su clúster y evitar atascos inesperados en el rendimiento.

    • En el ElastiCache caso de las cargas de trabajo (RedisOSS), cuando se eliminan las claves del clúster de forma explícita, UNLINK se eliminan las claves especificadas. DEL Sin embargo, el comando realiza la recuperación de memoria real en un subproceso diferente, por lo que no es de bloqueo, mientras que DEL sí. La eliminación real se realizará más adelante de forma asincrónica.

    • Para las cargas de trabajo de ElastiCache (RedisOSS) 6.x, el comportamiento del DEL comando se puede modificar en el grupo de parámetros mediante el parámetro. lazyfree-lazy-user-del

  • [Recursos]:

PE 6: ¿Cómo se modelan los datos e interactúa con ellos ElastiCache?

Introducción a nivel de preguntas: ElastiCache la aplicación depende en gran medida de las estructuras de datos y del modelo de datos utilizado, pero también debe tener en cuenta el banco de datos subyacente (si está presente). Comprenda las estructuras de datos ElastiCache (RedisOSS) disponibles y asegúrese de utilizar las estructuras de datos más adecuadas para sus necesidades.

Ventaja a nivel de pregunta: el modelado de datos ElastiCache tiene varios niveles, que incluyen el caso de uso de la aplicación, los tipos de datos y las relaciones entre los elementos de datos. Además, cada comando y tipo de datos ElastiCache (RedisOSS) tiene sus propias características de rendimiento bien documentadas.

  • [Lo mejor] Una práctica recomendada es reducir la sobrescritura involuntaria de datos. Utilice una convención de nomenclatura que minimice la superposición de nombres de clave. La nomenclatura convencional de las estructuras de datos utiliza un método jerárquico como: APPNAME:CONTEXT:ID, por ejemplo ORDER-APP:CUSTOMER:123.

    [Recursos]:

  • Los [mejores] comandos ElastiCache (RedisOSS) tienen una complejidad temporal definida por la notación Big O. Esta complejidad temporal de un comando es una representación algorítmica/matemática de su impacto. Al introducir un nuevo tipo de datos en su aplicación, debe revisar detenidamente la complejidad temporal de los comandos relacionados. Los comandos con una complejidad temporal de O(1) son constantes y no dependen de la cantidad de datos de entrada.; sin embargo, los comandos con una complejidad temporal de O(N) son lineales y están sujetos a la cantidad de datos de entrada. Debido al diseño de un solo subproceso de ElastiCache (RedisOSS), un gran volumen de operaciones de alta complejidad temporal se traducirá en un menor rendimiento y posibles tiempos de espera de operación.

    [Recursos]:

  • [Ideal] Úselo APIs para obtener GUI visibilidad del modelo de datos de su clúster.

    [Recursos]:

PE 7: ¿Cómo se registran los comandos de ejecución lenta en el ElastiCache clúster de Amazon?

Introducción a nivel de pregunta: Ventajas del ajuste del rendimiento mediante la captura, la agregación y la notificación de comandos de ejecución prolongada. Si comprende cuánto tiempo tardan en ejecutarse los comandos, puede determinar qué comandos tienen un rendimiento deficiente y qué comandos impiden que el motor funcione de manera óptima. ElastiCache (RedisOSS) también tiene la capacidad de reenviar esta información a Amazon CloudWatch o Amazon Kinesis Data Firehose.

Ventaja a nivel de pregunta: El registro en una ubicación permanente dedicada y la provisión de eventos de notificación para los comandos lentos puede ayudar a realizar un análisis detallado del rendimiento y se puede utilizar para activar eventos automatizados.

  • [Obligatorio] Amazon ElastiCache (RedisOSS) ejecuta el motor versión 6.0 o posterior, el grupo de parámetros correctamente configurado y el SLOWLOG registro está habilitado en el clúster.

    • Los parámetros necesarios solo están disponibles cuando la compatibilidad de las versiones del motor está configurada en la OSS versión 6.0 o superior de Redis.

    • SLOWLOGel registro se produce cuando el tiempo de ejecución de un comando en el servidor supera un valor especificado. El comportamiento del clúster depende de los parámetros del grupo de parámetros asociado, que son slowlog-log-slower-than y slowlog-max-len.

    • Los cambios surten efecto inmediatamente.

  • [Lo mejor] Aproveche nuestras capacidades de CloudWatch Kinesis Data Firehose.

    • Utilice las capacidades de filtrado y alarma de CloudWatch CloudWatch Logs Insights y Amazon Simple Notification Services para lograr la supervisión del rendimiento y la notificación de eventos.

    • Utilice las funciones de streaming de Kinesis Data Firehose SLOWLOG para archivar los registros en un almacenamiento permanente o para activar el ajuste automatizado de los parámetros del clúster.

    • Determine si JSON el TEXT formato simple se adapta mejor a sus necesidades.

    • Proporcione IAM permisos para publicar en CloudWatch o en Kinesis Data Firehose.

  • [Mejor] Configure slowlog-log-slower-than con un valor distinto al predeterminado.

    • Este parámetro determina cuánto tiempo puede ejecutarse un comando en el OSS motor de Redis antes de que se registre como un comando de ejecución lenta. El valor predeterminado es 10 000 microsegundos (10 milisegundos). El valor predeterminado puede ser demasiado alto para algunas cargas de trabajo.

    • Determine un valor que sea más adecuado para su carga de trabajo en función de las necesidades de la aplicación y los resultados de las pruebas; sin embargo, un valor demasiado bajo puede generar un exceso de datos.

  • [Mejor] Deje slowlog-max-len como valor predeterminado.

    • Este parámetro determina el límite máximo del número de comandos de ejecución lenta que se capturan en la OSS memoria de Redis en un momento dado. Un valor de 0 desactiva de manera efectiva la captura. Cuanto más alto sea el valor, más entradas se almacenarán en la memoria, lo que reducirá la posibilidad de que se expulse información importante antes de poder revisarla. El valor predeterminado es 128.

    • El valor predeterminado es adecuado para la mayoría de las cargas de trabajo. Si es necesario analizar los datos en una ventana de tiempo ampliada desde redis-cli mediante el SLOWLOG comando, considere la posibilidad de aumentar este valor. Esto permite que queden más comandos en la memoria de Redis. OSS

      Si envía los SLOWLOG datos a CloudWatch Logs o a Kinesis Data Firehose, los datos se conservarán y se podrán analizar fuera del sistema, lo que reducirá ElastiCache la necesidad de almacenar grandes cantidades de comandos de ejecución lenta en la memoria de Redis. OSS

  • [Recursos]:

PE8: ¿Cómo ayuda Auto Scaling a aumentar el rendimiento del ElastiCache clúster?

Introducción a nivel de preguntas: al implementar la función de escalado OSS automático de Redis, ElastiCache sus componentes pueden ajustarse con el tiempo para aumentar o disminuir automáticamente los fragmentos o réplicas deseados. Esto se puede hacer mediante la implementación de políticas de escalado programado o de seguimiento de objetivos.

Ventaja a nivel de pregunta: comprender y planificar los picos de carga de trabajo puede garantizar un mejor rendimiento del almacenamiento en caché y la continuidad empresarial. ElastiCache (RedisOSS) Auto Scaling monitorea continuamente su utilización de CPU /Memory para asegurarse de que su clúster funcione a los niveles de rendimiento deseados.

  • [Obligatorio] Al lanzar un clúster para ElastiCache (OSSRedis):

    1. Asegúrese de que el modo Clúster esté habilitado.

    2. Asegúrese de que la instancia pertenezca a una familia de un cierto tipo y tamaño que admita el escalado automático.

    3. Asegúrese de que el clúster no se ejecute en almacenes de datos globales, Outposts o zonas locales.

    [Recursos]:

  • [Lo mejor] Identifique si su carga de trabajo requiere mucha lectura o escritura para definir la política de escalado. Para obtener el mejor rendimiento, utilice solo una métrica de seguimiento. Se recomienda evitar tener varias políticas para cada dimensión, ya que las políticas de escalado automático se escalan horizontalmente de forma gradual cuando se alcanza el objetivo, pero solo se reducen horizontalmente cuando todas las políticas de seguimiento de objetivos están listas para reducirse horizontalmente.

    [Recursos]:

  • [Lo mejor] Supervisar el rendimiento a lo largo del tiempo puede ayudar a detectar cambios en la carga de trabajo que pasarían desapercibidos si se hiciera en un momento determinado. Puede analizar CloudWatch las métricas correspondientes a la utilización del clúster durante un período de cuatro semanas para determinar el umbral de valor objetivo. Si aún no está seguro de qué valor elegir, se recomienda comenzar con el valor mínimo admitido de métrica predefinida.

    [Recursos]:

  • [Mejor] Se recomienda probar la aplicación con las cargas de trabajo mínimas y máximas esperadas para identificar la cantidad exacta de particiones o réplicas que necesita el clúster a fin de desarrollar políticas de escalado y mitigar los problemas de disponibilidad.

    [Recursos]: