El pilar de confiabilidad de Amazon ElastiCache Well-Architected Lens

El pilar de la fiabilidad se centra en las cargas de trabajo que realizan las funciones previstas y en cómo recuperarse rápidamente de la incapacidad de satisfacer las demandas. Entre los temas clave, se incluyen el diseño de sistemas distribuidos, la planificación de la recuperación y cómo adaptarse a los cambios de requisitos.

REL 1: ¿Cómo se respaldan las implementaciones de arquitecturas de alta disponibilidad (HA)?

Introducción a nivel de preguntas: comprender la arquitectura de alta disponibilidad de Amazon ElastiCache le permitirá operar en un estado resiliente durante los eventos de disponibilidad.

Ventaja a nivel de pregunta: Diseñar la arquitectura de sus ElastiCache clústeres para que sean resistentes a los fallos garantiza una mayor disponibilidad para sus despliegues. ElastiCache

• [Obligatorio] Determine el nivel de confiabilidad que necesita para su clúster. ElastiCache Las diferentes cargas de trabajo tienen diferentes estándares de resiliencia, desde cargas de trabajo totalmente efímeras hasta cargas de trabajo cruciales para la misión. Defina las necesidades de cada tipo de entorno en el que opere, como desarrollo, pruebas y producción.

  Motor de almacenamiento en caché: ElastiCache para Memcached o ElastiCache para Valkey y Redis OSS

  1. ElastiCache for Memcached no proporciona ningún mecanismo de replicación y se utiliza principalmente para cargas de trabajo efímeras.

  2. ElastiCache para Valkey y Redis, OSS ofrece las funciones de alta disponibilidad que se describen a continuación

• [Lo mejor] Para las cargas de trabajo que requieren alta disponibilidad, ElastiCache utilícelas en modo clúster con un mínimo de dos réplicas por partición, incluso para cargas de trabajo pequeñas que requieren un solo fragmento.

  1. Si el modo de clúster está activado, multi-AZ se habilita automáticamente.

     Multi-AZ minimiza el tiempo de inactividad, ya que realiza conmutaciones por error automáticas desde el nodo principal a las réplicas, en caso de mantenimiento planificado o no planificado, y mitiga los errores de AZ.

  2. En cuanto a las cargas de trabajo particionadas, un mínimo de tres particiones proporciona una recuperación más rápida durante los eventos de conmutación por error, ya que el protocolo de clúster de Valkey o Redis OSS requiere que la mayoría de los nodos principales estén disponibles para alcanzar el quórum.

  3. Configure dos o más réplicas para ofrecer disponibilidad.

     Tener dos réplicas proporciona escalabilidad de lectura mejorada así como disponibilidad de lectura en situaciones en las que una réplica está en mantenimiento.

  4. Utilice tipos de nodos basados en Graviton2 (nodos predeterminados en la mayoría de las regiones).

     ElastiCache ha añadido un rendimiento optimizado en estos nodos. Como resultado, obtiene un mejor rendimiento de replicación y sincronización, lo que se traduce en una mejora general de la disponibilidad.

  5. Supervise y tenga el tamaño adecuado para hacer frente a los picos de tráfico previstos: con una carga pesada, el motor puede dejar de responder, lo que afecta a la disponibilidad. BytesUsedForCachey DatabaseMemoryUsagePercentage son buenos indicadores del uso de memoria, mientras que ReplicationLag son un indicador del estado de la replicación en función de la velocidad de escritura. Puede usar estas métricas para activar el escalado de clústeres.

  6. Para garantizar la resiliencia del cliente realice pruebas con la API de conmutación por error antes de un evento de conmutación por error en producción.

  [Recursos]:

  • Configure ElastiCache para Redis OSS para obtener una mayor disponibilidad

  • Alta disponibilidad a través de grupos de reproducción

REL 2: ¿Cómo cumple sus objetivos de puntos de recuperación (RPOs)? ElastiCache

Introducción a nivel de preguntas: comprenda el RPO de las cargas de trabajo para tomar decisiones informadas sobre las estrategias de ElastiCache respaldo y recuperación.

Ventaja a nivel de pregunta: Tener una estrategia de RPO implementada le permite mejorar la continuidad del negocio en caso de que se produzcan escenarios de recuperación de desastres. Diseñar sus políticas de respaldo y restauración puede ayudarlo a cumplir sus objetivos de punto de recuperación (RPO) para sus datos. ElastiCache ElastiCache ofrece capacidades de instantáneas que se almacenan en Amazon S3, junto con una política de retención configurable. Estas instantáneas se toman durante un período de copia de seguridad definido y el servicio las gestiona automáticamente. Si la carga de trabajo requiere un grado de detalle de respaldo adicional, tiene la opción de crear hasta 20 copias de seguridad manuales por día. Las copias de seguridad creadas manualmente no tienen una política de retención de servicios y se pueden conservar indefinidamente.

• [Obligatorio] Comprenda y documente el RPO de sus ElastiCache implementaciones.

  • Tenga en cuenta que Memcached no ofrece ningún proceso de copia de seguridad.

  • Revise las capacidades de las funciones de ElastiCache Backup and Restore.

• [Lo mejor]Disponga de un proceso que se haya comunicado bien para hacer copias de seguridad de su clúster.

  • Inicie copias de seguridad manuales según sea necesario.

  • Revise las políticas de retención de las copias de seguridad automáticas.

  • Tenga en cuenta que las copias de seguridad manuales se conservarán indefinidamente.

  • Programe las copias de seguridad automáticas durante los períodos de bajo uso.

  • Realice operaciones de respaldo contra réplicas de lectura para asegurarse de minimizar el impacto en el rendimiento del clúster.

• [Bueno] Aproveche la función de copia de seguridad programada ElastiCache para realizar copias de seguridad periódicas de sus datos durante un período definido.

  • Haga pruebas periódicas de las restauraciones a partir de las copias de seguridad.

• [Recursos]:

  • Redis OSS

  • Backup y restauración para ElastiCache

  • Realización de copias de seguridad manuales

  • Programación de copias de seguridad automáticas

  • ElastiCache Clústeres de Backup y Restauración

REL 3: ¿Cómo se cumplen los requisitos de recuperación de desastres (DR)?

Introducción a nivel de preguntas: La recuperación ante desastres es un aspecto importante de cualquier planificación de la carga de trabajo. ElastiCache ofrece varias opciones para implementar la recuperación ante desastres en función de los requisitos de resiliencia de la carga de trabajo. Con Amazon ElastiCache Global Datastore, puede escribir en su clúster de una región y tener los datos disponibles para su lectura desde otros dos clústeres de réplicas entre regiones, lo que permite lecturas de baja latencia y recuperación ante desastres en todas las regiones.

Ventaja a nivel de pregunta: Comprender y planificar una variedad de escenarios de desastres contribuye a garantizar la continuidad del negocio. Las estrategias de DR deben equilibrarse en relación al costo, el impacto en el rendimiento y la posible pérdida de datos.

• [Obligatorio] Desarrolle y documente estrategias de recuperación ante desastres para todos sus ElastiCache componentes en función de los requisitos de carga de trabajo. ElastiCache tiene la particularidad de que algunos casos de uso son totalmente efímeros y no requieren ninguna estrategia de DR, mientras que otros se encuentran en el extremo opuesto del espectro y requieren una estrategia de DR extremadamente sólida. Todas las opciones deben soparse teniendo en cuenta la optimización de costos: una mayor resiliencia requiere más infraestructura.

  Conozca las opciones de DR disponibles a nivel regional y multirregional.

  • Se recomiendan implementaciones multi-AZ para evitar errores de AZ. Asegúrese de realizar la implementación con el modo clúster habilitado en arquitecturas Multi-AZ, con un mínimo de 3 disponibles. AZs

  • Se recomienda utilizar Global Datastore para protegerse contra los errores regionales.

• [Lo mejor] Habilite Global Datastore para cargas de trabajo que requieran resiliencia a nivel de región.

  • Tenga un plan para realizar una conmutación por error a la región secundaria en caso de degradación de la primaria.

  • Pruebe el proceso de conmutación por error multirregional antes de llevar a cabo una conmutación por error en producción.

  • Supervise la métrica ReplicationLag para conocer el posible impacto de la pérdida de datos durante los eventos de conmutación por error.

• [Recursos]:

  • Mitigación de errores

  • Replicación entre regiones mediante almacenes de datos globales AWS

  • Restauración desde una copia de seguridad con redimensionamiento opcional del clúster

  • Minimizar el tiempo de inactividad en ElastiCache Valkey y Redis OSS con Multi-AZ

REL 4: ¿Cómo se planifican eficazmente las conmutaciones por error?

Introducción a nivel de preguntas: La mejor práctica es habilitar Multi-AZ con conmutaciones por error automáticas. ElastiCache En algunos casos, ElastiCache en el caso de Valkey y Redis, el OSS sustituye a los nodos principales como parte de las operaciones de servicio. Algunos ejemplos son eventos de mantenimiento planificado y el improbable caso de que haya un problema en el nodo o en la zona de disponibilidad. El éxito de las conmutaciones por error depende tanto de la configuración de la biblioteca cliente como de ElastiCache la configuración de la biblioteca.

Ventaja a nivel de pregunta: seguir las prácticas recomendadas para las ElastiCache conmutaciones por error junto con su biblioteca ElastiCache cliente específica le ayuda a minimizar el posible tiempo de inactividad durante las conmutaciones por error.

• [Obligatorio] Si el modo de clúster está deshabilitado, utilice los tiempos de espera para que sus clientes detecten si es necesario desconectarse del nodo principal anterior y volver a conectarse al nuevo nodo principal, mediante la dirección IP del punto de conexión principal actualizada. Si el modo de clúster está habilitado, la biblioteca cliente es responsable de detectar los cambios en la topología del clúster subyacente. En la mayoría de los casos, esto se consigue mediante los ajustes de configuración de la biblioteca ElastiCache cliente, que también permiten configurar la frecuencia y el método de actualización. Cada biblioteca cliente ofrece su propia configuración. Encontrará más información en la documentación correspondiente.

  [Recursos]:

  • Minimiza el tiempo ElastiCache de inactividad en Valkey y Redis OSS con Multi-AZ

  • Revise las mejores prácticas de la biblioteca de su cliente. ElastiCache

• [Obligatorio] Las conmutaciones por error correctas dependen de un entorno de replicación en buen estado entre los nodos principal y de réplica. Revise y comprenda la naturaleza asíncrona de la replicación de OSS de Valkey y Redis, así como CloudWatch las métricas disponibles para informar sobre el retraso en la replicación entre los nodos principal y de réplica. Para los casos de uso que requieran una mayor seguridad de los datos, utilice el comando WAIT para obligar a las réplicas a confirmar las escrituras antes de responder a los clientes conectados.

  [Recursos]:

  • Métricas de Valkey y Redis OSS

  • Supervisión de las mejores prácticas ElastiCache con Amazon CloudWatch

• [Lo mejor] Valide periódicamente la capacidad de respuesta de su aplicación durante la conmutación por error mediante la API ElastiCache Test Failover.

  [Recursos]:

  • Prueba de la conmutación por error automática a una réplica de lectura en ElastiCache

  • Prueba de la conmutación por error automática

REL 5: ¿Sus ElastiCache componentes están diseñados para escalarse?

Introducción a nivel de preguntas: Al comprender las capacidades de escalado y las topologías de implementación disponibles, sus ElastiCache componentes se pueden ajustar con el tiempo para adaptarse a los cambiantes requisitos de carga de trabajo. ElastiCacheofrece un escalado en 4 direcciones: in/out (horizontal) as well as up/down (vertical).

Ventaja a nivel de pregunta: seguir las mejores prácticas para las ElastiCache implementaciones proporciona la mayor flexibilidad de escalado, además de cumplir con el principio bien diseñado de escalar horizontalmente para minimizar el impacto de los fallos.

• [Obligatorio] Comprenda la diferencia entre las topologías de modo clúster habilitado y modo clúster deshabilitado. En casi todos los casos, se recomienda realizar la implementación con el modo de clúster habilitado, ya que permite una mayor escalabilidad a lo largo del tiempo. Los componentes en modo clúster deshabilitado tienen una capacidad limitada para escalar horizontalmente mediante la adición de réplicas de lectura.

• [Obligatorio] Comprenda cuándo y cómo escalar.

  • Para más READIOPS: añada réplicas

  • Para más WRITEOPS: añada particiones (escale horizontamente)

  • Para más E/S de red: utilice instancias optimizadas para la red y escale verticalmente

• [Lo mejor] Implemente sus ElastiCache componentes con el modo clúster activado, optando por más nodos más pequeños en lugar de tener menos nodos más grandes. Esto limita de manera efectiva el radio de acción de un error de nodo.

• [Lo mejor] Incluya réplicas en los clústeres para mejorar la capacidad de respuesta durante los eventos de escalado.

• [Bueno] Si el modo de clúster está desactivado, aproveche las réplicas de lectura para aumentar la capacidad de lectura general. ElastiCache tiene deshabilitada la compatibilidad con hasta 5 réplicas de lectura en el modo de clúster, así como el escalado vertical.

• [Recursos]:

  • Escalado de clústeres ElastiCache

  • Escalado vertical en línea