Resiliencia en Amazon ElastiCache
La infraestructura global de AWS se compone de regiones y zonas de disponibilidad de AWS. AWS Las regiones proporcionan varias zonas de disponibilidad físicamente independientes y aisladas que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además de baja latencia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
Para obtener más información sobre las regiones y zonas de disponibilidad de AWS, consulte Infraestructura global de AWS
Además de la infraestructura global de AWS, Amazon ElastiCache ofrece varias características que ayudan con las necesidades de resiliencia y copia de seguridad de los datos.
Mitigación de errores
A la hora de planificar la implementación de Amazon ElastiCache, debe realizar la planificación de modo que los errores tengan una repercusión mínima en la aplicación y datos. Los temas de esta sección abordan enfoques que puede aplicar para proteger la aplicación y los datos frente a errores.
Temas
Mitigación de errores al ejecutar Memcached
Al ejecutar el motor de Memcached, dispondrá de las opciones siguientes para minimizar el impacto de los errores. Existen dos tipos de errores que debe abordar en los planes de mitigación: errores de nodos y errores de zonas de disponibilidad.
Mitigación de errores de nodos
Las cachés sin servidor mitigan automáticamente los errores de los nodos con una arquitectura replicada de varias zonas de disponibilidad para que los errores de los nodos sean transparentes para su aplicación. Para mitigar el impacto de un error de nodo en un clúster basado en nodos, reparta los datos almacenados en caché por varios nodos. Como los clústeres basados en nodos no son compatibles con la replicación, los errores en nodos siempre tendrán como consecuencia la pérdida de datos del clúster.
Al crear su clúster de Memcached, puede crearlo con un número de nodos comprendido entre 1 y 60, o más si se solicita de forma especial. Repartir los datos entre un mayor número de nodos implica que perderá menos datos en caso de error en algún nodo. Por ejemplo, si reparte los datos en 10 nodos, un único nodo almacenará aproximadamente un 10 % de los datos almacenados en la caché. En este caso, un error de nodo supondrá una pérdida aproximada del 10 % de la caché, que deberá reemplazarse cuando se cree y aprovisione un nodo de reemplazo. Si los datos se almacenan en caché en 3 nodos de mayor tamaño, un error en un nodo supondría una pérdida aproximada del 33 % de los datos almacenados en la caché.
Para obtener información acerca de la especificación del número de nodos en un clúster de Memcached, consulte Creación de un clúster de Memcached (consola).
Mitigación de errores de zona de disponibilidad
Las cachés sin servidor mitigan automáticamente los errores de las zonas de disponibilidad con una arquitectura replicada de varias zonas de disponibilidad a fin de que los errores de estas zonas sean transparentes para su aplicación.
Para mitigar el impacto de los fallos de una zona de disponibilidad en un clúster basado en nodos, busque los nodos en tantas zonas de disponibilidad como sea posible. En el caso improbable de que se produzca un error en una zona de disponibilidad, se perderán los datos almacenados en la caché de dicha zona, no los datos almacenados en la caché de otras zonas de disponibilidad.
¿Por qué tantos nodos?
Dado que mi región solo tiene tres zonas de disponibilidad, si se produjera un error en una de ellas, perdería aproximadamente un tercio de los datos. En ese caso, ¿por qué son necesarios más de tres nodos?
Esta es una excelente pregunta. Recuerde que estamos intentando mitigar dos tipos distintos de errores: errores de nodos y errores de zonas de disponibilidad. Tiene razón. Si los datos están distribuidos en distintas zonas de disponibilidad y, si se produce un error en una de ellas, solo perderá los datos almacenados en la memoria caché de dicha zona de disponibilidad, independientemente del número de nodos que tenga. Sin embargo, en caso de error en un nodo, disponer de más nodos reducirá la proporción de datos perdidos.
No existe ninguna “fórmula mágica” para determinar la cantidad de nodos que debe tener en un clúster. Debe sopesar el impacto de la pérdida de datos frente a la probabilidad de que se produzca algún error y los costos para llegar a su propia conclusión.
Para obtener información acerca de la especificación del número de nodos en un clúster de Memcached, consulte Creación de un clúster de Memcached (consola).
Para obtener más información acerca de las regiones y zonas de disponibilidad, consulte Elección de regiones y zonas de disponibilidad para ElastiCache.
Mitigación de errores al ejecutar Valkey o Redis OSS
Si ejecuta un motor de Valkey o Redis OSS, dispondrá de las siguientes opciones para minimizar el impacto de los errores que se produzcan en un nodo o zona de disponibilidad.
Mitigación de errores de nodos
Las cachés sin servidor mitigan automáticamente los errores de los nodos con una arquitectura de varias zonas de disponibilidad a fin de que los errores de los nodos sean transparentes para su aplicación. Los clústeres basados en nodos deben configurarse adecuadamente para mitigar el fallo de un nodo individual.
Para mitigar el impacto de los errores de los nodos de Valkey o Redis OSS en los clústeres basados en nodos, dispone de las siguientes opciones:
Mitigación de errores: grupos de replicación de Valkey o Redis OSS
Un grupo de replicación de Valkey o Redis OSS se compone de un solo nodo principal, disponible para operaciones de lectura y escritura para su aplicación, y de 1 a 5 nodos de réplica de solo lectura. Cuando se escriben datos en el nodo principal, también se actualizan de forma asíncrona en los nodos de réplica de lectura.
Qué sucede en caso de error en una réplica de lectura
ElastiCache detecta la réplica de lectura con error.
ElastiCache deja el nodo con error sin conexión.
ElastiCache lanza y aprovisiona un nodo de reemplazo en la misma zona de disponibilidad.
El nuevo nodo se sincroniza con el nodo principal.
Durante este tiempo, la aplicación podrá seguir realizando operaciones de lectura y escritura con los demás nodos.
Multi-AZ de Valkey o Redis OSS
Puede habilitar multi-AZ en sus grupos de replicación de Valkey o Redis OSS. Independientemente de que habilite Multi-AZ o no, se detectará y reemplazará automáticamente un error en el nodo principal. El modo en que esto tiene lugar varía en función de si Multi-AZ está habilitado o no.
Cuando Multi-AZ está habilitado
ElastiCache detecta el error del nodo primario.
ElastiCache promociona el nodo de réplica de lectura con el mínimo retraso de reproducción en el nodo primario.
El resto de réplicas se sincronizarán con el nuevo nodo principal.
ElastiCache pone en marcha una réplica de lectura en la zona de disponibilidad del nodo primario con error.
El nuevo nodo se sincroniza con el nodo principal recién promovido.
La conmutación por error a un nodo de réplica suele ser más rápida que la creación y el aprovisionamiento de un nuevo nodo principal. Esto significa que la aplicación podrá reanudar la escritura en el nodo principal antes que si Multi-AZ no estuviera habilitado.
Para obtener más información, consulte Minimización del tiempo de inactividad en ElastiCache utilizando multi-AZ con Valkey y Redis OSS.
Cuando Multi-AZ está deshabilitado
ElastiCache detecta un error primario.
ElastiCache deja el primario sin conexión.
ElastiCache crea y aprovisiona un nodo primario nuevo para reemplazar el primario con error.
ElastiCache sincroniza el nodo primario nuevo con una de las réplicas existentes.
Cuando finaliza la sincronización, el nuevo nodo funciona como el nodo principal del clúster.
Durante los pasos 1 a 4 de este proceso, la aplicación no puede escribir en el nodo principal. Sin embargo, la aplicación podrá seguir leyendo datos de los nodos de réplica.
Para mejorar la protección, le recomendamos que lance los nodos del grupo de reproducción en distintas zonas de disponibilidad (AZ). De este modo, los errores en zonas de disponibilidad solo afectarán a los nodos de dichas zonas de disponibilidad, no a los demás.
Para obtener más información, consulte Alta disponibilidad a través de grupos de reproducción.
Mitigación de errores de zona de disponibilidad
Las cachés sin servidor mitigan automáticamente los errores de las zonas de disponibilidad con una arquitectura replicada de varias zonas de disponibilidad a fin de que los errores de estas zonas sean transparentes para su aplicación.
Para mitigar el impacto de un fallo de una zona de disponibilidad en un clúster basado en nodos, busque los nodos de cada partición en tantas zonas de disponibilidad como sea posible.
Independientemente de la cantidad de nodos que tenga en una partición, si se encuentran en la misma zona de disponibilidad, un error catastrófico en dicha zona tendría como resultado la pérdida de todos los datos de la partición. Sin embargo, si ubica los nodos en varias zonas de disponibilidad, un error en cualquiera de las zonas de disponibilidad tendría como consecuencia la pérdida solo de los nodos de dicha zona de disponibilidad.
Cada vez que se pierde un nodo, puede experimentar una reducción del rendimiento, ya que las operaciones de lectura son compartidas por menos nodos. Esta reducción del rendimiento continuará hasta que los nodos se reemplacen.
Para obtener más información acerca de la especificación de zonas de disponibilidad en los nodos de Valkey o Redis OSS, consulte Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola).
Para obtener más información acerca de las regiones y zonas de disponibilidad, consulte Elección de regiones y zonas de disponibilidad para ElastiCache.
Recomendaciones
Se recomienda crear cachés sin servidor en clústeres basados en nodos, ya que obtendrá automáticamente una mejor tolerancia a errores sin necesidad de configuración adicional. Sin embargo, al crear un clúster basado en nodos, hay dos tipos de fallos para los que se debe preparar: los fallos de nodos individuales y los fallos generalizados en zonas de disponibilidad. Los mejores planes de mitigación de errores abordarán ambos tipos de errores.
Minimización del impacto de los errores de nodos
Para minimizar el impacto de un error en un nodo al utilizar Valkey o Redis OSS, recomendamos que su implementación utilice varios nodos en cada partición y distribuya los nodos en varias zonas de disponibilidad. Esto se hace automáticamente en las cachés sin servidor.
En los clústeres basados en nodos en Valkey o Redis OSS, se recomienda habilitar multi-AZ en el grupo de replicación para que ElastiCache conmute por error de forma automática a una réplica si falla el nodo principal.
Cuando ejecute Memcached y tenga distribuidos los datos en distintos nodos, cuantos más nodos utilice, menor será la pérdida de datos en caso de error en algún nodo.
Minimización del impacto de los errores en la zona de disponibilidad
Para minimizar el impacto de un error en una zona de disponibilidad, recomendamos lanzar los nodos en tantas zonas de disponibilidad distintas como sea posible. Distribuir los nodos de manera regular en zonas de disponibilidad minimizará el impacto en caso de un improbable evento de error de zona de disponibilidad. Esto se hace automáticamente en las cachés sin servidor.
Otras precauciones
Si ejecuta Valkey o Redis OSS, además de todo lo anterior, recomendamos que programe copias de seguridad periódicas del clúster. Las copias de seguridad (instantáneas) crean un archivo .rdb que podrá utilizar para restablecer la caché en caso de error o daño. Para obtener más información, consulte Instantánea y restauración.
