Pilar de eficiencia del rendimiento del enfoque Well-Architected de Amazon ElastiCache - Amazon ElastiCache
PE 1: ¿Cómo se supervisa el rendimiento del clúster de Amazon ElastiCache?PE 2: ¿Cómo se distribuye el trabajo entre los nodos del clúster de ElastiCache?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? PE 4: ¿Cómo optimiza la carga de trabajo el uso de los recursos y las conexiones de red?PE 5: ¿Cómo se gestiona la eliminación o la expulsión de claves?PE 6: ¿Cómo se modelan los datos y se interactúa con ellos en ElastiCache? PE 7: ¿Cómo se registran los comandos de ejecución lenta en el clúster de Amazon ElastiCache?PE8: ¿Cómo ayuda el escalado automático a aumentar el rendimiento del clúster de ElastiCache?

Pilar de eficiencia del rendimiento del enfoque Well-Architected de Amazon ElastiCache

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 se supervisa el rendimiento del clúster de Amazon ElastiCache?

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.

    • Supervise las métricas de CloudWatch mientras ejecuta estas pruebas para comprender las métricas disponibles y establecer una referencia de rendimiento.

  • [Lo mejor] En el caso de las cargas de trabajo de ElastiCache para Valkey y Redis OSS, cambie el nombre de los comandos caros desde el punto de vista computacional, como KEYS, para limitar la capacidad de los usuarios de ejecutar comandos de bloqueo en los clústeres de producción.

    • Las cargas de trabajo de ElastiCache que ejecutan el motor 6.x para Redis OSS pueden aprovechar el control de acceso basado en roles para restringir determinados comandos. El acceso a los comandos se puede controlar con la creación de usuarios y grupos de usuarios con la consola o la CLI de AWS y con la asociación de los grupos de usuarios a un clúster. En Redis OSS 6, cuando RBAC está habilitado, es posible usar -@dangerous, lo que no permitirá comandos costosos, como KEYS, MONITOR, SORT, etc., para ese usuario.

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

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

    • En las cargas de trabajo de ElastiCache para Valkey y Redis OSS, obtendrá más información sobre sus consultas mediante el análisis del registro lento. Por ejemplo, puede utilizar el siguiente comando, valkey-cli slowlog get 10, para mostrar los últimos 10 comandos que han superado los umbrales de latencia (10 milisegundos de forma predeterminada).

    • Algunas consultas se pueden realizar de forma más eficiente con estructuras de datos complejas de ElastiCache para Valkey y Redis OSS. 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 de ElastiCache para Valkey y Redis OSS, redis-benchmark proporciona una interfaz sencilla para probar el rendimiento de diferentes comandos mediante entradas definidas por el usuario, como la cantidad 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 se distribuye el trabajo entre los nodos del clúster de ElastiCache?

Introducción a nivel de pregunta: La forma en que la aplicación se conecta a los nodos de Amazon ElastiCache puede influir en el 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 de conexión de ElastiCache adecuado.

    • ElastiCache para Valkey y Redis OSS implementa diferentes puntos de conexión en función del modo de clúster en uso. Si el modo de clúster está habilitado, ElastiCache proporcionará un punto de conexión de configuración. Para el modo de clúster deshabilitado, ElastiCache proporciona un punto de conexión principal, que normalmente se usa para escritura, y un punto de conexión 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 de conexión 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 habilitado de ElastiCache para Valkey y Redis OSS para mejorar la escalabilidad.

    • Los clústeres de ElastiCache para Valkey y Redis OSS (modo de clúster habilitado) admiten operaciones de escalado en línea (escalar/reducir horizontalmente y verticalmente) para ayudar a distribuir los datos de forma dinámica entre las particiones. 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 al mover las ranuras hash entre las particiones disponibles en su clúster de ElastiCache para Valkey y Redis OSS (modo de clúster habilitado). 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 datos multidimensionales de Valkey o Redis OSS, como listas, flujos, conjuntos, etc. Estas estructuras de datos se almacenan en claves ú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 de ElastiCache para Valkey y Redis OSS, puede detectar las teclas de acceso rápido mediante valkey-cli --hotkeys si existe una política de memoria máxima de LFU.

    • 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 nodo de Valkey o Redis OSS en sí no proporciona esta funcionalidad) y mantenga una lista de nombres de claves de la que leer, además del nombre de la clave original.

    • El motor de ElastiCache 7.2 para Valkey 7.2 y ElastiCache versión 6 para Redis OSS y versiones posteriores admiten el almacenamiento en caché en el cliente asistido por el servidor. Esto permite que las aplicaciones esperen a que se modifique una clave antes de volver a realizar llamadas de red a 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 pregunta: El almacenamiento en caché es una carga de trabajo habitual en ElastiCache y es importante que comprenda cómo administrar 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 uso de la CPU para saber si necesita realizar ajustes en el tiempo de vida o en otros componentes de la aplicación. ElastiCache proporciona un conjunto de métricas de CloudWatch de las latencias agregadas para cada estructura de datos. Estas métricas de latencia se calculan mediante la estadística commandstats del comando INFO y no incluyen el tiempo de red ni el tiempo de E/S. Se trata solo del tiempo que consume ElastiCache para 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 en la pregunta: Muchos clientes de aplicaciones admiten ElastiCache para Valkey, Memcached y Redis OSS. Además, 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] Gestione de forma proactiva las conexiones a su clúster de 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 y NewConnections.

    • 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 pregunta: Las cargas de trabajo tienen diferentes requisitos, y un comportamiento esperado cuando un nodo del clúster se acerca a los límites de consumo de memoria. ElastiCache cuenta con 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 con la maxmemory-policy en el grupo de parámetros del clúster.

    • La política predeterminada volatile-lru libera memoria al expulsar las claves con una fecha de caducidad establecida (valor de TTL). Las políticas menos usadas frecuentemente (LFU) y menos usadas recientemente (LRU) eliminan las claves en función del uso.

    • Para las cargas de trabajo de Memcached, existe una política LRU predeterminada que controla las expulsiones en cada nodo. Es posible supervisar el número de expulsiones de su clúster de Amazon ElastiCache mediante la métrica de expulsiones 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 caso de las cargas de trabajo de ElastiCache para Valkey y Redis OSS, al eliminar claves del clúster de forma explícita, UNLINK es como DEL, pues elimina claves especificadas. 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 versión 6.x para Redis OSS, el comportamiento del comando DEL 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 y se interactúa con ellos en ElastiCache?

Introducción a nivel de pregunta: ElastiCache depende en gran medida de las aplicaciones en las estructuras de datos y modelo de datos utilizados, pero también debe tener en cuenta el almacén de datos subyacente (si está presente). Conozca las estructuras de datos 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 en ElastiCache tiene varias capas, que incluyen los casos 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 tiene sus propias firmas 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]:

  • [Lo mejor] Los comandos de ElastiCache para Valkey y Redis OSS 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 a que ElastiCache para Valkey y Redis OSS se ha diseñado con un único subproceso, un gran volumen de operaciones de alta complejidad temporal se traducirá en un menor rendimiento y en posibles tiempos de espera de las operaciones.

    [Recursos]:

  • [Lo mejor] Utilice las API para obtener visibilidad de la GUI en el modelo de datos de su clúster.

    [Recursos]:

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

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 también tiene la capacidad de enviar 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] ElastiCache con una versión del motor Valkey 7.2 o posterior, o un motor de Redis OSS versión 6.0 o posterior, un grupo de parámetros configurado correctamente y el registro SLOWLOG habilitado en el clúster.

    • Los parámetros requeridos solo están disponibles cuando la compatibilidad de la versión del motor está configurada para Valkey 7.2 y versiones posteriores o Redis OSS versión 6.0 o posteriores.

    • El registro SLOWLOG 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 las capacidades de CloudWatch o Kinesis Data Firehose.

    • Utilice las capacidades de filtrado y alarma de CloudWatch, CloudWatch Logs Insights y Amazon Simple Notification Services para supervisar el rendimiento y notificar eventos.

    • Utilice las capacidades de transmisión de Kinesis Data Firehose para archivar los registros SLOWLOG en un almacenamiento permanente o para activar el ajuste automático de los parámetros del clúster.

    • Determine si el formato JSON o TEXTO sin formato se adapta mejor a sus necesidades.

    • Proporcione permisos de IAM para publicar en CloudWatch o 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 motor de Valkey o Redis OSS 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 superior del número de comandos de ejecución lenta que se capturan en la memoria de Valkey o Redis OSS 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 un período de tiempo ampliado desde valkey-cli mediante el comando SLOWLOG, considere aumentar este valor. Esto permite que queden más comandos en la memoria de Valkey o Redis OSS.

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

  • [Recursos]:

PE8: ¿Cómo ayuda el escalado automático a aumentar el rendimiento del clúster de ElastiCache?

Introducción de pregunta: al implementar la característica de escalado automático de Valkey o Redis OSS, los componentes de ElastiCache pueden ajustarse con el tiempo para que aumenten o disminuyan automáticamente las particiones o réplicas deseadas. 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. El escalado automático de ElastiCache supervisa continuamente el uso de la CPU/memoria a fin de garantizar que el clúster funcione a los niveles de rendimiento deseados.

  • [Obligatorio] Al lanzar un clúster para ElastiCache para Valkey o Redis OSS:

    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 las métricas correspondientes de CloudWatch para la utilización del clúster durante un período de cuatro semanas a fin de determinar el umbral del 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]: