Pilar de fiabilidad

El AWS pilar de confiabilidad de Well-Architected Framework abarca la capacidad de una carga de trabajo para realizar la función prevista de manera correcta y coherente cuando se espera que lo haga. Esto incluye la capacidad de operar y probar la carga de trabajo durante 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 de arquitectura afectan al comportamiento de la carga de trabajo en todos los pilares de Well-Architected. Para garantizar la confiabilidad, hay patrones específicos que debe seguir, como se explica en esta sección.

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

Su AWS cuenta tiene cuotas predeterminadas (antes denominadas límites) para cada una Servicio de AWS de ellas. A menos que se indique lo contrario, cada cuota es específica de la región. Puedes solicitar aumentos para algunas cuotas, pero no para todas.

Para buscar las cuotas de Neptune Analytics, abra la consola Service Quotas. En el panel de navegación, elija y Servicios de AWS, a continuación, seleccione Amazon Neptune Analytics. Preste atención a las cuotas en cuanto al número de gráficos e instantáneas, a la memoria máxima aprovisionada para un gráfico y a las tasas de solicitudes de API.

Si la memoria máxima aprovisionada no es suficiente para su conjunto de datos, evalúe qué tipos de nodos y bordes son esenciales para el uso analítico previsto. Cargue un subconjunto de los datos para que los análisis sean posibles dentro de la capacidad aprovisionada permitida. Muchas cargas de trabajo de análisis, especialmente las que ejecutan algoritmos de gráficos, solo necesitan la topología con un conjunto limitado de propiedades en lugar del gráfico transaccional completo. (Para ver un análisis de las diferencias entre las cargas de trabajo transaccionales y analíticas, consulte la sección sobre el pilar de la eficiencia del rendimiento).

Si el número máximo de gráficos no es suficiente para el uso previsto:

• Considere la posibilidad de combinar gráficos que tengan usos similares.

• Evalúe cuántos gráficos deben ejecutarse en un momento dado. Si tiene un caso práctico de análisis efímero, capture un gráfico y elimínelo cuando ya no lo necesite. Esto reduce el número de gráficos en comparación con la cuota.

• Considere la posibilidad de aprovisionar los gráficos de forma diferente. Cuentas de AWS

Comprenda los patrones de despliegue de Neptune

Comprenda los siguientes puntos de decisión cuando planee implementar un gráfico de Neptune Analytics:

• Siembra: decida si desea crear un gráfico vacío o cargar datos en él en el momento de la creación con datos de Amazon S3, un clúster de base de datos de Neptune existente o una instantánea de base de datos de Neptune existente.

  Recomendación: Si la fuente es un cúmulo o una instantánea de Neptuno, debe cargar sus datos en el momento de la creación del gráfico. Si la fuente es Amazon S3, cargue los datos en el momento de la creación si el esfuerzo de carga es significativo y se realiza mejor como actividad de aprovisionamiento de infraestructura. Si prefiere cargar datos como una actividad de ingeniería de datos o de aplicación, cree un gráfico vacío y cargue los datos desde Amazon S3 más adelante.

• Capacidad: calcule la capacidad aprovisionada necesaria para un gráfico, teniendo en cuenta el tamaño de los datos y el uso esperado de la aplicación.

  Recomendación: En el momento de la creación, especifique la cantidad máxima de memoria aprovisionada para limitar el tamaño del gráfico. Esta configuración es obligatoria. Si es necesario, puede cambiar la capacidad más adelante.

• Disponibilidad y tolerancia a errores: decida si se requieren réplicas para garantizar la disponibilidad. Una réplica actúa como un dispositivo de reserva para la recuperación en caso de que se produzca un error en el gráfico. Un gráfico con réplicas se recupera más rápido que un gráfico sin réplicas. También considere cuánto tiempo se necesita el gráfico, si es solo para análisis efímeros y, de ser así, cuándo se eliminará.

  Recomendación: Determine los requisitos de disponibilidad (por ejemplo, cuánto tiempo puede no estar disponible el gráfico y cuándo puede eliminarse) antes de crearlo.

• Redes y seguridad: determine si necesita conectividad pública, privada o ambas, y si desea cifrar sus datos.

  Recomendación: Antes de crear un gráfico, comprenda los requisitos organizativos (por ejemplo, si se permite la conectividad pública y dónde se implementarán las aplicaciones cliente de gráficos).

• Copias de seguridad y recuperación: determine si se deben crear instantáneas y, de ser así, cuándo y en qué condiciones. Considere si su organización tiene requisitos de recuperación ante desastres (DR).

  Recomendación: La creación de instantáneas es una actividad manual. Decida cuándo crear las instantáneas y tenga en cuenta sus requisitos de recuperación ante desastres antes de crear un gráfico.

Gestione y escale los clústeres de Neptune

Un gráfico de Neptune Analytics consta de una única instancia optimizada para la memoria. La capacidad (m-NCU) de la instancia se establece en el momento de la creación. La instancia se puede escalar verticalmente aumentando la capacidad aprovisionada mediante una acción administrativa; también se puede reducir la capacidad aprovisionada. Las réplicas son objetivos de conmutación por error pasiva, por lo que no aumentan la escala de un gráfico. En este sentido, una réplica de un gráfico difiere de una réplica de lectura de una base de datos de Neptuno, que es una instancia activa en un clúster de Neptuno que puede procesar las operaciones de lectura de las aplicaciones.

Las réplicas conllevan costes. El precio de la réplica se basa en la tasa m-NCU del gráfico. Por ejemplo, si un gráfico está aprovisionado para 128 millones de NCU y tiene una sola réplica, el costo es el doble que el de un gráfico equivalente sin réplicas.

En el ámbito del análisis, hay dos motivos principales para ampliar la escala:

• Para proporcionar más memoria y CPU para las consultas y los algoritmos analíticos, dado que la consulta individual es cara, el algoritmo gráfico que se ejecuta es intrínsecamente complejo y requiere más recursos debido a su entrada, o bien la tasa de solicitudes simultáneas es alta. Si estas consultas presentan out-of-memory errores, la ampliación es una solución razonable.

• Para admitir un tamaño de gráfico mayor del previsto. Por ejemplo, si la capacidad aprovisionada actualmente es de 128 M-NCU para admitir 60 GB de datos de origen y necesita 40 GB de datos de origen adicionales, está justificado aumentarla a 256 M-NCU.

Supervise CloudWatch las métricas de Neptune Analytics, comoNumQueuedRequestsPerSec,NumOpenCypherRequestsPerSec,GraphStorageUsagePercent, y GraphSizeBytesCPUUtilization, para determinar si es necesario escalar. Puede actualizar la configuración de un gráfico a través de la consola AWS CLI, o SDKs. (Para ver ejemplos y prácticas recomendadas, consulte la sección sobre el pilar de la excelencia operativa).

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

Utilice réplicas para garantizar que haya un gráfico disponible en caso de fallo. Un gráfico utiliza la persistencia basada en registros para confirmar los cambios en todas las zonas de disponibilidad de un. Región de AWS La réplica actúa como un dispositivo de reserva y tiene acceso a estos datos. Si se produce un error, el gráfico reanuda las operaciones en la réplica. La aplicación sigue utilizando el mismo punto final para conectarse al gráfico. Las solicitudes en curso durante el fallo generan errores, con la excepción de que el servicio no esté disponible. Considere la posibilidad de utilizar un patrón de reintento con retroceso en el código de la aplicación para detectar el error e inténtelo de nuevo tras un breve intervalo. Las nuevas solicitudes realizadas durante la conmutación por error se ponen en cola y es posible que experimenten una latencia más prolongada.

Si no se configura ninguna réplica y el gráfico falla, Neptune Analytics se recupera del almacenamiento duradero, pero la recuperación tarda más porque Neptune tiene que reinicializar los recursos.

Cree instantáneas del gráfico. (Neptune Analytics no toma instantáneas automáticas). Si el gráfico se modifica periódicamente después de crearlo, tome instantáneas frecuentes para capturar su estado actual. Elimine las instantáneas antiguas si no es necesario restaurarlas a un momento anterior.

Puedes compartir las instantáneas con otras cuentas y entre ellas. Regiones de AWS Si tiene requisitos de recuperación ante desastres, considere si restaurar el gráfico en una región diferente a partir de una instantánea cumple con sus requisitos de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO).