Pilier de fiabilité

Le AWS pilier de fiabilité du Well-Architected Framework englobe la capacité d'une charge de travail à exécuter correctement et de manière cohérente la fonction prévue, au moment prévu. Cela inclut la capacité d'exploiter et de tester la charge de travail tout au long de son cycle de vie.

Pour garantir la fiabilité d’une charge de travail, il faut commencer par choisir le bon logiciel et la bonne infrastructure. Vos choix d'architecture ont un impact sur le comportement de votre charge de travail dans tous les piliers de Well-Architected. Pour des raisons de fiabilité, il existe des modèles spécifiques que vous devez suivre, comme indiqué dans cette section.

Le pilier de fiabilité se concentre sur les domaines clés suivants :

• Architecture de charge de travail, y compris les quotas de service et les modèles de déploiement

• Gestion des modifications

• Gestion des défaillances

Comprendre les quotas de service Neptune

Votre AWS compte dispose de quotas par défaut (anciennement appelés limites) pour chacun d'entre eux Service AWS. Sauf indication contraire, chaque quota est spécifique à la région. Vous pouvez demander des augmentations pour certains quotas, mais pas pour tous.

Pour trouver des quotas pour Neptune Analytics, ouvrez la console Service Quotas. Dans le volet de navigation, choisissez Services AWS, puis sélectionnez Amazon Neptune Analytics. Faites attention aux quotas relatifs au nombre de graphiques et d'instantanés, à la mémoire maximale allouée à un graphique et aux taux de demandes d'API.

Si la mémoire maximale allouée n'est pas suffisante pour votre ensemble de données, déterminez quels types de nœuds et de bords sont essentiels pour l'utilisation analytique que vous souhaitez en faire. Chargez un sous-ensemble de données afin que les analyses soient possibles dans les limites de la capacité allouée autorisée. De nombreuses charges de travail d'analyse, en particulier celles qui exécutent des algorithmes de graphes, nécessitent uniquement la topologie avec un ensemble limité de propriétés au lieu du graphe transactionnel complet. (Pour une discussion sur les différences entre les charges de travail transactionnelles et analytiques, voir la section sur le pilier de l'efficacité des performances.)

Si le nombre maximum de graphiques n'est pas suffisant pour l'usage que vous souhaitez en faire :

• Envisagez de combiner des graphiques ayant des utilisations similaires.

• Évaluez le nombre de graphiques qui doivent être exécutés à un moment donné. Si vous avez un cas d'utilisation éphémère de l'analytique, capturez un graphique et supprimez-le lorsqu'il n'est plus nécessaire. Cela réduit le nombre de graphiques par rapport au quota.

• Envisagez de créer des graphiques de provisionnement sous différentes formes. Comptes AWS

Comprendre les modèles de déploiement de Neptune

Prenez en compte les points de décision suivants lorsque vous envisagez de déployer un graphe Neptune Analytics :

• Ensemencement : décidez si vous souhaitez créer un graphique vide ou y charger des données au moment de sa création avec des données provenant d'Amazon S3, d'un cluster de base de données Neptune existant ou d'un instantané de base de données Neptune existant.

  Recommandation : Si la source est un cluster ou un instantané Neptune, vous devez charger ses données au moment de la création du graphe. Si la source est Amazon S3, chargez les données au moment de leur création si l'effort de chargement est important et qu'il est préférable de les exécuter dans le cadre d'une activité de provisionnement d'infrastructure. Si vous préférez charger des données dans le cadre d'une activité d'ingénierie des données ou d'application, créez un graphique vide et chargez les données depuis Amazon S3 ultérieurement.

• Capacité : estimez la capacité provisionnée requise pour un graphique, en fonction de la taille des données et de l'utilisation prévue des applications.

  Recommandation : Au moment de la création, spécifiez la mémoire maximale allouée afin de limiter la taille du graphique. Ce paramètre est obligatoire. Vous pouvez modifier la capacité ultérieurement si nécessaire.

• Disponibilité et tolérance aux pannes : déterminez si des répliques sont nécessaires pour garantir la disponibilité. Une réplique fait office de réserve pour la restauration en cas de défaillance du graphe. Un graphe contenant des répliques se rétablit plus rapidement qu'un graphe dépourvu de répliques. Déterminez également combien de temps le graphique est nécessaire, s'il est destiné à des analyses éphémères uniquement et, dans l'affirmative, à quel moment il sera supprimé.

  Recommandation : déterminez les exigences de disponibilité, telles que la durée pendant laquelle le graphique peut être indisponible et le moment où il peut être supprimé, avant de créer un graphique.

• Mise en réseau et sécurité : déterminez si vous avez besoin d'une connectivité publique, d'une connectivité privée ou des deux, et si vous souhaitez chiffrer vos données.

  Recommandation : Avant de créer un graphique, déterminez les exigences de l'organisation, par exemple si la connectivité publique est autorisée et où les applications clientes seront déployées.

• Sauvegardes et restauration : déterminez si des instantanés doivent être créés et, dans l'affirmative, à quel moment et dans quelles conditions. Déterminez si votre organisation a des exigences en matière de reprise après sinistre (DR).

  Recommandation : La création d'instantanés est une activité manuelle. Décidez à quel moment créer des instantanés et prenez en compte vos exigences en matière de reprise après sinistre avant de créer un graphique.

Gérez et dimensionnez les clusters Neptune

Un graphe Neptune Analytics se compose d'une seule instance optimisée pour la mémoire. La capacité (m-NCU) de l'instance est définie au moment de sa création. L'instance peut être mise à l'échelle verticale en augmentant la capacité allouée par le biais d'une action administrative ; la capacité allouée peut également être réduite. Les répliques étant des cibles de basculement passives, elles n'augmentent pas l'échelle d'un graphique. À cet égard, une réplique de graphe est différente d'une réplique de lecture de base de données Neptune, qui est une instance active dans un cluster Neptune capable de traiter les opérations de lecture à partir d'applications.

Les répliques ont un coût. Le prix de la réplique est calculé au taux de m-ncu indiqué sur le graphique. Par exemple, si un graphe est provisionné pour 128 m-NCU et possède une seule réplique, le coût est deux fois supérieur à celui d'un graphe équivalent sans répliques.

Dans le domaine de l'analytique, il existe deux raisons principales de passer à l'échelle supérieure :

• Afin de fournir davantage de mémoire et de processeur pour les requêtes analytiques et les algorithmes, étant donné que chaque requête individuelle est coûteuse, l'algorithme graphique à exécuter est intrinsèquement complexe et nécessite davantage de ressources compte tenu de ses entrées, ou le taux de demandes simultanées est élevé. Si de telles requêtes rencontrent des out-of-memory erreurs, la mise à l'échelle est une solution raisonnable.

• Pour prendre en charge une taille de graphique supérieure à celle prévue. Par exemple, si la capacité actuellement allouée est de 128 M-NCU pour prendre en charge 60 Go de données source et que vous avez besoin de 40 Go supplémentaires de données sources, une augmentation à 256 M-NCU est justifiée.

Surveillez CloudWatch les métriques pour Neptune Analytics, telles que,NumQueuedRequestsPerSec,, et NumOpenCypherRequestsPerSec GraphStorageUsagePercent GraphSizeBytesCPUUtilization, afin de déterminer si une mise à l'échelle est nécessaire. Vous pouvez mettre à jour la configuration d'un graphique via la console AWS CLI, ou SDKs. (Pour des exemples et des meilleures pratiques, voir la section sur le pilier de l'excellence opérationnelle.)

Gestion des sauvegardes et des événements de basculement

Utilisez des répliques pour garantir la disponibilité d'un graphe en cas de panne. Un graphique utilise la persistance basée sur les journaux pour valider les modifications dans les zones de disponibilité d'un Région AWS. La réplique agit en mode veille et a accès à ces données. En cas de défaillance, le graphe reprend les opérations sur le réplica. L'application continue d'utiliser le même point de terminaison pour se connecter au graphe. Les demandes en vol pendant la panne génèrent des erreurs avec une exception d'indisponibilité du service. Envisagez d'utiliser un schéma de nouvelle tentative avec interruption dans le code de l'application pour détecter l'erreur, puis réessayez après un bref intervalle. Les nouvelles demandes effectuées pendant le basculement sont mises en file d'attente et peuvent connaître une latence plus longue.

Si aucune réplique n'est configurée et que le graphe échoue, Neptune Analytics se rétablit à partir d'un stockage durable, mais la restauration prend plus de temps car Neptune doit réinitialiser les ressources.

Créez des instantanés du graphique. (Neptune Analytics ne prend pas de clichés automatiques.) Si le graphique est régulièrement modifié après sa création, prenez fréquemment des instantanés pour capturer son état actuel. Supprimez les anciens instantanés s'il n'est pas nécessaire de les restaurer à une date antérieure.

Vous pouvez partager des instantanés avec d'autres comptes et entre eux. Régions AWS Si vous avez des exigences en matière de reprise après sinistre, déterminez si la restauration du graphe dans une autre région à partir d'un instantané répond à vos exigences en matière de temps de restauration (RTO) et d'objectif de point de restauration (RPO).