Pilier de fiabilité

Le pilier de fiabilité du AWS Well-Architected Framework englobe la capacité d'une charge de travail à exécuter la fonction prévue correctement et de manière cohérente au moment prévu. Cela inclut la possibilité 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 des charges de travail sur les différents piliers Well-Architected. Pour des raisons de fiabilité, vous devez suivre des modèles spécifiques.

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

Un volume de cluster Neptune peut atteindre une taille maximale de 128 tebioctets (TiB) dans tous les pays pris en charge, Régions AWS sauf en Chine, où le quota est de GovCloud 64 TiB.

Le quota de 128 TiB est suffisant pour stocker environ 200 à 400 milliards d'objets dans le graphique. Dans un graphe de propriétés étiqueté (LPG), un objet est un nœud, une arête ou une propriété sur un nœud ou une arête. Dans un graphe RDF (Resource Description Framework), un objet est un quad.

Pour tout cluster Neptune Serverless, vous définissez le nombre minimum et maximum d'unités de capacité Neptune (). NCUs Chaque NCU comprend 2 Gibioctets (GiB) de mémoire, le vCPU et le réseau associés. Les valeurs NCU minimale et maximale s'appliquent à toutes les instances sans serveur du cluster. La valeur NCU maximale la plus élevée que vous pouvez définir est de 128,0 NCUs et la valeur minimale la plus basse est de 1,0. NCUs Optimisez la plage NCU qui convient le mieux à votre application en observant les CloudWatch métriques ServerlessDatabaseCapacity Amazon, en capturant la plage dans laquelle vous vous trouvez le plus souvent et en corrélant les comportements ou les coûts indésirables dans cette fourchette. NCUUtilization Si vous constatez que votre charge de travail n'évolue pas assez rapidement, augmentez le minimum NCUs afin de fournir suffisamment de traitement pour l'augmentation initiale pendant qu'elle évolue.

Chacune Compte AWS dispose de quotas pour chaque région quant au nombre de ressources de base de données que vous pouvez créer. Ces ressources incluent des instances et des clusters de bases de données. Une fois qu'une limite a été atteinte pour une ressource, les appels supplémentaires pour créer cette ressource échouent avec une exception. Certains quotas sont des quotas souples qui peuvent être augmentés sur demande. Pour obtenir la liste des quotas partagés entre Amazon Neptune et Amazon RDS, Amazon Aurora et Amazon DocumentDB (avec compatibilité avec MongoDB), ainsi que des liens permettant de demander des augmentations de quotas lorsqu'elles sont disponibles, consultez la section Quotas dans Amazon RDS.

Comprendre les modèles de déploiement de Neptune

Dans les clusters de base de données Neptune, il existe une instance de base de données principale et jusqu'à 15 répliques de Neptune. L'instance de base de données principale prend en charge les opérations de lecture et d'écriture et effectue toutes les modifications de données sur le volume du cluster. Les répliques Neptune se connectent au même volume de stockage que l'instance de base de données principale et ne prennent en charge que les opérations de lecture. Les répliques Neptune peuvent décharger les charges de travail de lecture de l'instance de base de données principale.

Pour obtenir une haute disponibilité, utilisez des répliques de lecture. Le fait qu'une ou plusieurs instances de réplication en lecture soient disponibles dans différentes zones de disponibilité peut augmenter la disponibilité, car les répliques en lecture servent de cibles de basculement pour l'instance principale. Si l'instance Writer échoue, Neptune fait en sorte qu'une instance de réplication en lecture devienne l'instance principale. Dans ce cas, il y a une brève interruption (généralement inférieure à 30 secondes) pendant le redémarrage de l'instance promue, au cours de laquelle les demandes de lecture et d'écriture adressées à l'instance principale échouent, sauf exception. Pour une fiabilité maximale, envisagez deux répliques en lecture dans différentes zones de disponibilité. Si l'instance principale de la zone de disponibilité 1 est mise hors ligne, l'instance de la zone de disponibilité 2 est promue en instance principale, mais elle ne peut pas traiter les requêtes pendant ce temps. Une instance de la zone de disponibilité 3 est donc requise pour gérer les requêtes de lecture pendant la transition.

Si vous utilisez Neptune Serverless, les instances de lecture et d'écriture de toutes les zones de disponibilité augmenteront ou diminueront, indépendamment les unes des autres, en fonction de la charge de leur base de données. Vous pouvez définir le niveau de promotion d'une instance de lecteur sur 0 ou 1 afin qu'il augmente ou diminue en fonction de la capacité de l'instance de rédacteur. Cela le rend prêt à prendre en charge la charge de travail actuelle à tout moment.

Gérez et dimensionnez les clusters Neptune

Vous pouvez utiliser l'auto-scaling Neptune pour ajuster automatiquement le nombre de répliques Neptune dans un cluster de base de données afin de répondre à vos exigences en matière de connectivité et de charge de travail en fonction des seuils d'utilisation du processeur. Grâce à l'auto-scaling, votre cluster de base de données Neptune peut gérer des augmentations soudaines de la charge de travail. Lorsque la charge de travail diminue, l'auto-scaling supprime les répliques inutiles afin que vous ne payiez pas pour la capacité inutilisée. Sachez que le démarrage d'une nouvelle instance peut prendre jusqu'à 15 minutes. L'auto-scaling ne suffit donc pas à lui seul à faire face à l'évolution rapide de la demande.

Vous ne pouvez utiliser l'auto-scaling qu'avec un cluster de base de données Neptune qui possède déjà une instance d'écriture principale et au moins une instance de reproduction en lecture (voir Clusters et instances de base de données Amazon Neptune). En outre, toutes les instances de réplica en lecture du cluster doivent être dans un état disponible. Si une réplique en lecture est dans un état autre que disponible, l'auto-scaling de Neptune ne fait rien tant que toutes les répliques en lecture du cluster ne sont pas disponibles.

Si la demande évolue rapidement, pensez à utiliser des instances sans serveur. Les instances sans serveur peuvent évoluer verticalement sur de courtes périodes tandis que l'auto-scaling s'adapte horizontalement sur de longues périodes. Cette configuration offre une évolutivité optimale car les instances sans serveur évoluent verticalement tandis que l'auto-scaling instancie de nouvelles répliques de lecture afin de gérer la charge de travail au-delà de la capacité maximale d'une seule instance sans serveur. Pour plus d'informations sur le dimensionnement de la capacité d'Amazon Neptune Serverless, consultez la section Dimensionnement de capacité dans un cluster de base de données Neptune Serverless.

Si vos besoins en matière de dimensionnement évoluent à des moments prévisibles, vous pouvez planifier des modifications des instances minimales, maximales et seuils afin de mieux répondre à ces besoins changeants. N'oubliez pas de planifier les événements à grande échelle au moins 15 minutes à l'avance pour permettre à ces instances d'être mises en ligne en cas de besoin.

Vous gérez votre configuration de base de données dans Amazon Neptune à l'aide de paramètres dans un groupe de paramètres. Les groupes de paramètres servent de conteneurs pour les valeurs de configuration de moteur qui sont appliquées à une ou plusieurs instances de base de données. Lorsque vous modifiez des paramètres de cluster dans des groupes de paramètres, comprenez la différence entre les paramètres statiques et dynamiques, et apprenez comment et quand ils sont appliqués. Utilisez le point de terminaison d'état pour voir la configuration actuellement appliquée.

Gestion des sauvegardes et des événements de basculement

Neptune sauvegarde automatiquement le volume de votre cluster et conserve les données sauvegardées pendant toute la durée de la période de conservation des sauvegardes. Les sauvegardes Neptune étant continues et incrémentielles, vous pouvez rapidement opérer une restauration à un point quelconque de la période de rétention des sauvegardes. Vous pouvez spécifier une période de rétention des sauvegardes de 1 à 35 jours lorsque vous créez ou modifiez un cluster de bases de données.

Pour conserver une sauvegarde au-delà de la période de conservation des sauvegardes, vous pouvez également prendre un instantané des données de votre volume de cluster. Le stockage des instantanés est soumis aux frais standard de stockage pour Neptune.

Lorsque vous créez un instantané Amazon Neptune d'un cluster de bases de données, Neptune crée un instantané du volume de stockage du cluster, en sauvegardant toutes ses données, et pas seulement des instances individuelles. Vous pourrez ultérieurement créer un cluster de bases de données en effectuant une restauration à partir de cet instantané. Lorsque vous restaurez le cluster de base de données, vous fournissez le nom du snapshot du cluster de base de données à partir duquel effectuer la restauration, puis vous fournissez un nom pour le nouveau cluster de base de données créé par la restauration.

Testez la façon dont votre système réagit aux événements de basculement. Utilisez l'API Neptune pour forcer un événement de basculement. Le redémarrage avec basculement est utile lorsque vous souhaitez simuler la défaillance d'une instance de base de données à des fins de test ou pour des opérations de restauration dans la zone de disponibilité d'origine après un basculement. Pour plus d'informations, consultez Configuration et gestion d'un déploiement multi-AZ. Lorsque vous redémarrez une instance de rédacteur de base de données, elle bascule vers la réplique de secours. Le redémarrage d'un réplica Neptune ne déclenche pas de basculement.

Concevez vos clients dans une optique de fiabilité. Testez leur comportement lors d'événements de basculement. Implémentez une logique de nouvelle tentative dans votre client avec une logique d'interruption exponentielle. Vous trouverez des exemples de code implémentant cette logique dans les exemples de AWS Lambda fonctions pour Amazon Neptune.

Envisagez de l'utiliser AWS Backupsi vous avez des exigences communes en matière de sauvegarde que vous appliquez à plusieurs moteurs de base de données.