Pilar de fiabilidad

El pilar de confiabilidad del Marco de AWS Trabajo de Buena Arquitectura abarca la capacidad de una carga de trabajo para realizar su función prevista de manera correcta y consistente cuando se espera que lo haga. Esto incluye la capacidad de utilizar y probar la carga de trabajo a lo largo de todo su ciclo de vida.

Una carga de trabajo fiable comienza por tomar decisiones de diseño anticipadas tanto para el software como para la infraestructura. Sus elecciones respecto a la arquitectura afectarán al comportamiento de su carga de trabajo en todos los pilares de Well-Architected. Para la fiabilidad, debe seguir patrones específicos.

El pilar de confiabilidad se centra en las siguientes áreas clave:

• Arquitectura de carga de trabajo, incluidas las cuotas de servicio y los patrones de implementación

• Administración de cambios

• Administración de errores

Comprenda las cuotas de servicio de Neptune

El volumen de un clúster de Neptune puede crecer hasta un tamaño máximo de 128 tebibytes (TiB) en todos los Regiones de AWS casos admitidos, excepto en China GovCloud y, donde la cuota es de 64 TiB.

La cuota de 128 TiB es suficiente para almacenar aproximadamente entre 200 y 400 000 millones de objetos en el gráfico. En un gráfico de propiedades etiquetadas (LPG), un objeto es un nodo, una arista o una propiedad de un nodo o arista. En un gráfico del marco de descripción de recursos (RDF), un objeto es un cuadrilátero.

Para cualquier clúster Neptune Serverless, debe establecer el número mínimo y máximo de unidades de capacidad de Neptune (). NCUs Cada NCU consta de 2 gibibytes (GiB) de memoria y la vCPU y la red asociadas. Los valores mínimo y máximo de la NCU se aplican a todas las instancias sin servidor del clúster. El valor máximo de NCU más alto que puede establecer es 128,0 NCUs y el mínimo más bajo es 1,0. NCUs Optimice el rango de NCU que mejor se adapte NCUUtilization a su aplicación observando las CloudWatch métricas de Amazon ServerlessDatabaseCapacity y capturando el rango en el que se encuentra habitualmente y correlacionando el comportamiento no deseado o los costos dentro de ese rango. Si descubre que su carga de trabajo no se amplía lo suficientemente rápido, aumente el mínimo NCUs para proporcionar suficiente procesamiento para el aumento inicial mientras se amplía.

Cada una de ellas Cuenta de AWS tiene cuotas para cada región en cuanto a la cantidad de recursos de base de datos que puede crear. Estos recursos incluyen las instancias y clústeres de base de datos. Después de que alcance el límite de un recurso, las llamadas adicionales para crear ese recurso dejan de funcionar con una excepción. Algunas cuotas son cuotas flexibles que se pueden aumentar si se solicita. Para obtener una lista de las cuotas compartidas entre Amazon Neptune y Amazon RDS, Amazon Aurora y Amazon DocumentDB (con compatibilidad con MongoDB), junto con enlaces para solicitar aumentos de cuota cuando estén disponibles, consulte Cuotas en Amazon RDS.

Comprenda los patrones de despliegue de Neptune

En los clústeres de base de datos de Neptune, hay una instancia de base de datos principal y hasta 15 réplicas de Neptune. La instancia de base de datos principal admite operaciones de lectura y escritura y realiza todas las modificaciones de datos en el volumen del clúster. Las réplicas de Neptune se conectan al mismo volumen de almacenamiento que la instancia de base de datos principal y solo admiten operaciones de lectura. Las réplicas de Neptune pueden descargar las cargas de trabajo de lectura de la instancia de base de datos principal.

Para lograr una alta disponibilidad, utilice réplicas de lectura. Tener una o más instancias de réplica de lectura disponibles en diferentes zonas de disponibilidad puede aumentar la disponibilidad, ya que las réplicas de lectura sirven como destinos de conmutación por error para la instancia principal. Si la instancia de escritura falla, Neptune convierte una instancia de réplica de lectura en la instancia principal. Cuando esto ocurre, se produce una breve interrupción (generalmente de menos de 30 segundos) mientras se reinicia la instancia promocionada, durante la cual las solicitudes de lectura y escritura realizadas a la instancia principal fallan con una excepción. Para obtener la máxima fiabilidad, considere la posibilidad de utilizar dos réplicas de lectura en distintas zonas de disponibilidad. Si la instancia principal de la zona de disponibilidad 1 se desconecta, la instancia de la zona de disponibilidad 2 pasa a ser principal, pero no podrá gestionar las consultas mientras eso suceda. Por lo tanto, se necesita una instancia en la zona de disponibilidad 3 para gestionar las consultas de lectura durante la transición.

Si utiliza Neptune Serverless, las instancias de lectura y escritura de todas las zonas de disponibilidad se ampliarán y reducirán, independientemente unas de otras, en función de la carga de la base de datos. Puede establecer el nivel de promoción de una instancia de lectura en 0 o 1 para que se amplíe o disminuya según la capacidad de la instancia de escritura. Esto la prepara para asumir la carga de trabajo actual en cualquier momento.

Gestione y escale los clústeres de Neptune

Puede usar el autoscalamiento de Neptune para ajustar automáticamente el número de réplicas de Neptuno en un clúster de base de datos para cumplir sus requisitos de conectividad y carga de trabajo en función de los umbrales de uso de la CPU. Con el autoscalamiento, su clúster de base de datos Neptune puede gestionar los aumentos repentinos de la carga de trabajo. Cuando la carga de trabajo disminuye, el autoscaling elimina las réplicas innecesarias para no tener que pagar por la capacidad no utilizada. Tenga en cuenta que el inicio de una nueva instancia puede tardar hasta 15 minutos, por lo que el autoscalamiento por sí solo no es una solución suficiente para los cambios rápidos de la demanda.

Puede usar el autoscalamiento solo con un clúster de base de datos de Neptune que ya tenga una instancia de escritura principal y al menos una instancia de réplica de lectura (consulte Instancias y clústeres de bases de datos de Amazon Neptune). Además, todas las instancias de réplica de lectura del clúster deben estar en un estado disponible. Si alguna réplica de lectura está en un estado diferente al disponible, el autoscalamiento de Neptune no hace nada hasta que todas las réplicas de lectura del clúster estén disponibles.

Si experimenta cambios rápidos en la demanda, considere la posibilidad de utilizar instancias sin servidor. Las instancias sin servidor se pueden escalar verticalmente durante períodos cortos, mientras que el autoescalado se escala horizontalmente durante períodos más largos. Esta configuración proporciona una escalabilidad óptima porque las instancias sin servidor se escalan verticalmente, mientras que el autoscalamiento crea instancias de nuevas réplicas de lectura para gestionar la carga de trabajo más allá de la capacidad máxima de una sola instancia sin servidor. Para obtener más información sobre el escalado de capacidad de Amazon Neptune Serverless, consulte Escalado de capacidad en un clúster de base de datos de Neptune Serverless.

Si sus necesidades de escalado cambian en momentos predecibles, puede programar cambios en las instancias mínimas, máximas y umbrales para gestionar mejor esas necesidades cambiantes. Recuerde programar los eventos de escalamiento horizontal con al menos 15 minutos de antelación para permitir que esas instancias se conecten cuando sea necesario.

Use los parámetros de un grupo de parámetros para administrar la configuración de la base de datos en Amazon Neptune. Los grupos de parámetros sirven de contenedor para los valores de configuración del motor que se aplican a una o varias instancias de bases de datos. Al modificar los parámetros del clúster en grupos de parámetros, comprenda la diferencia entre los parámetros estáticos y dinámicos, y cómo y cuándo se aplican. Utilice el punto final de estado para ver la configuración aplicada actualmente.

Gestione las copias de seguridad y los eventos de conmutación por error

Neptune realiza automáticamente una copia de seguridad del volumen del clúster y conserva los datos de la copia de seguridad durante el período de retención de la copia de seguridad. Las copias de seguridad de Neptune son continuas y progresivas para que se puedan restaurar con rapidez a cualquier punto durante el periodo de retención de copia de seguridad. Puede especificar un período de retención de la copia de seguridad de 1 a 35 días al crear o modificar un clúster de base de datos.

Para conservar una copia de seguridad más allá del período de retención de la copia de seguridad, también puede tomar una instantánea de los datos del volumen de su clúster. Al almacenar instantáneas, se generan los cargos de almacenamiento estándar para Neptune.

Cuando crea una instantánea de Amazon Neptune de un clúster de base de datos, Neptune crea una instantánea del volumen de almacenamiento del clúster y hace copias de seguridad de todos sus datos, no solo de instancias individuales. Para crear posteriormente un clúster de base de datos nuevo, restaure esa instantánea de clúster de base de datos. Al restaurar el clúster de base de datos, proporciona el nombre de la instantánea del clúster de base de datos desde la que desea realizar la restauración y, a continuación, proporciona un nombre para el nuevo clúster de base de datos que se crea mediante la restauración.

Compruebe cómo responde el sistema a los eventos de conmutación por error. Usa la API de Neptune para forzar un evento de conmutación por error. Reiniciar con conmutación por error resulta útil cuando se quiere simular el fallo de una instancia de base de datos para realizar pruebas o restaurar operaciones en la zona de disponibilidad original tras producirse una conmutación por error. Para obtener más información, consulte Configuración y administración de una implementación Multi-AZ. Al reiniciar una instancia de escritura de bases de datos, se conmuta por error a la réplica en espera. El reinicio de una réplica de Neptune no inicia una conmutación por error.

Diseñe sus clientes para que sean fiables. Pruebe su comportamiento durante los eventos de conmutación por error. Implemente la lógica de reintento en su cliente con una lógica de retroceso exponencial. Los ejemplos de código que implementan esta lógica se encuentran en los ejemplos de AWS Lambda funciones de Amazon Neptune.

Considere la posibilidad de utilizarla AWS Backupsi tiene un conjunto común de requisitos de respaldo que se aplican a varios motores de bases de datos.