PERF04-BP02 Évaluer les options disponibles - AWS Well-Architected Framework
Directives d'implémentationNiveau d'effort du plan d'implémentation : Ressources

PERF04-BP02 Évaluer les options disponibles

Identifiez les options de base de données disponibles et déterminez comment elles peuvent optimiser vos performances avant de sélectionner votre solution de gestion des données. À l'aide des tests de charge, identifiez les métriques de base de données qui sont essentiels à votre charge de travail. Pendant que vous explorez les options de base de données, tenez compte de divers aspects tels que les groupes de paramètres, les options de stockage, la mémoire, le calcul, le réplica en lecture, la cohérence éventuelle, le regroupement de connexions et les options de mise en cache. Testez ces différentes options de configuration pour améliorer les métriques.

Résultat souhaité : Une charge de travail peut utiliser une ou plusieurs solutions de base de données en fonction des types de données. La fonctionnalité et les avantages de la base de données correspondent de manière optimale aux caractéristiques des données, aux modèles d'accès et aux exigences de la charge de travail. Pour optimiser les performances et les coûts de votre base de données, vous devez évaluer les modèles d'accès aux données afin d'identifier les options de base de données appropriées. Évaluez les temps de requête acceptables pour vous assurer que les options de base de données sélectionnées répondent aux exigences.

Anti-modèles courants :

  • Ne pas identifier les modèles d'accès aux données.

  • Ne pas connaître les options de configuration de la solution de gestion de données que vous avez choisie.

  • Se concentrer uniquement sur l'augmentation de la taille de l'instance sans examiner les autres options de configuration disponibles.

  • Ne pas tester les caractéristiques de mise à l'échelle de la solution choisie.

Avantages liés au respect de cette bonne pratique : En explorant et en expérimentant les options de base de données, vous pourriez réduire le coût de l'infrastructure, améliorer les performances et l'évolutivité et réduire l'effort requis pour maintenir vos charges de travail.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : Débit

  • Devoir optimiser son infrastructure pour une base de données universelle signifie faire des compromis inutiles.

  • Coûts plus élevés en raison de la non-configuration de la solution de base de données pour qu'elle corresponde aux modèles de trafic.

  • Des problèmes opérationnels peuvent découler des problèmes de mise à l'échelle.

  • Les données peuvent ne pas être sécurisées au niveau requis.

Directives d'implémentation

Comprenez les caractéristiques des données de votre charge de travail afin de pouvoir configurer vos options de base de données. Exécutez des tests de charge pour identifier les métriques clés de performance et les goulots d'étranglement. Utilisez ces caractéristiques et ces métriques pour évaluer les options de base de données et tester différentes configurations.

Services AWS Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Mise à l'échelle du calcul Augmentation de la taille de l'instance, les instances Aurora Serverless se mettent à l'échelle automatiquement en réponse aux changements de charge Mise à l'échelle automatique en lecture/écriture avec mode « capacité à la demande » ou mise à l'échelle automatique de la capacité de lecture/écriture allouée en mode « capacité allouée » Augmentez la taille de l'instance Augmentation de la taille de l'instance, ajout de nœuds au cluster Augmentez la taille de l'instance Mise à l'échelle automatique pour ajuster la capacité Mise à l'échelle automatique en lecture/écriture avec mode « capacité à la demande » ou mise à l'échelle automatique de la capacité de lecture/écriture allouée en mode « capacité allouée » Mise à l'échelle automatique pour ajuster la capacité
Mise à l'échelle verticale des lectures Tous les moteurs prennent en charge les réplicas en lecture. Aurora prend en charge la mise à l'échelle automatique des instances de réplica en lecture Augmentation des unités de capacité de lecture allouées Réplicas en lecture Réplicas en lecture Réplicas en lecture. Prend en charge la mise à l'échelle automatique des instances de réplica en lecture Mise à l'échelle automatique Augmentation des unités de capacité de lecture allouées Augmentation automatique jusqu'aux limites de simultanéité documentées
Mise à l'échelle verticale des écritures Augmentation la taille de l'instance, regroupement des écritures dans l'application ou ajout d'une file d'attente devant la base de données. Mise à l'échelle horizontale via le partitionnement au niveau de l'application sur plusieurs instances Augmentation des unités de capacité d'écriture allouées Assurer une clé de partition optimale pour empêcher la limitation d'écriture au niveau de la partition Augmentation de la taille de l'instance principale Utilisation de Redis en mode cluster pour répartir les écritures sur les partitions Augmentation de la taille de l'instance Les demandes d'écriture peuvent être limitées lors de la mise à l'échelle. Si vous rencontrez des exceptions de limitation, continuez à envoyer des données au même débit (ou supérieur) pour une mise à l'échelle automatique. Écritures par lots pour réduire les demandes d'écriture simultanées Augmentation des unités de capacité d'écriture allouées Assurer une clé de partition optimale pour empêcher la limitation d'écriture au niveau de la partition Augmentation automatique jusqu'aux limites de simultanéité documentées
Configuration du moteur Groupes de paramètres Ne s'applique pas Groupes de paramètres Groupes de paramètres Groupes de paramètres Ne s'applique pas Ne s'applique pas Ne s'applique pas
Mise en cache Mise en cache en mémoire, configurable via des groupes de paramètres. Association à un cache dédié tel qu'ElastiCache pour Redis pour décharger les demandes d'éléments fréquemment consultés Cache entièrement géré DAX (DAX) disponible Mise en cache en mémoire. Association à un cache dédié tel qu'ElastiCache pour Redis pour décharger les demandes d'éléments fréquemment consultés (facultatif) La fonction principale est la mise en cache Utilisation du cache des résultats de requête pour mettre en cache le résultat d'une requête en lecture seule Timestream a deux niveaux de stockage ; l'un d'entre eux est un niveau de stockage en mémoire hautes performances Déploiement d'un cache dédié tel qu'ElastiCache pour Redis pour décharger les demandes d'éléments fréquemment consultés Ne s'applique pas
Haute disponibilité et reprise après sinistre La configuration recommandée pour les charges de travail de production consiste à exécuter une instance de secours dans une deuxième zone de disponibilité pour assurer la résilience au sein d'une région.  Pour la résilience entre les régions, Aurora Global Database peut être utilisé Hautement disponible dans une région. Les tables peuvent être répliquées dans les régions à l'aide des tables globales DynamoDB Créez plusieurs instances dans les zones de disponibilité pour assurer la disponibilité.  Les instantanés peuvent être partagés entre les régions, et les clusters peuvent être répliqués à l'aide de DMS pour fournir une réplication/reprise après sinistre entre régions La configuration recommandée pour les clusters de production consiste à créer au moins un nœud dans une zone de disponibilité secondaire.  ElastiCache Global Datastore peut être utilisé pour répliquer des clusters dans des régions. Les réplicas en lecture dans d'autres zones de disponibilité servent de cibles de basculement.  Les instantanés peuvent être partagés entre les régions, et les clusters peuvent être répliqués à l'aide de flux Neptune pour répliquer les données entre deux clusters dans deux régions différentes. Hautement disponible dans une région. La réplication entre régions nécessite le développement d'applications personnalisées à l'aide du SDK Timestream Hautement disponible dans une région.  La réplication entre régions nécessite une logique d'application personnalisée ou des outils tiers Hautement disponible dans une région.  Pour assurer la réplication entre les régions, exportez le contenu du journal Amazon QLDB vers un compartiment S3 et configurez le compartiment pour la réplication entre régions.

Étapes d'implémentation

  1. Quelles sont les options de configuration disponibles pour les bases de données sélectionnées ?

    1. Les groupes de paramètres pour Amazon RDS et Aurora vous permettent d'ajuster les paramètres communs au niveau du moteur de base de données tels que la mémoire allouée pour le cache ou l'ajustement du fuseau horaire de la base de données

    2. Pour les services de base de données alloués comme Amazon RDS, Aurora, Neptune, Amazon DocumentDB et ceux déployés sur Amazon EC2, vous pouvez modifier le type d'instance, le stockage alloué et ajouter des réplicas en lecture.

    3. DynamoDB vous permet de spécifier deux modes de capacité : à la demande et alloué. Pour tenir compte des différentes charges de travail, vous pouvez basculer entre ces modes et augmenter la capacité allouée en mode alloué à tout moment.

  2. La charge de travail en lecture ou en écriture est-elle importante ? 

    1. Quelles sont les solutions disponibles pour décharger les lectures (réplicas en lecture, mise en cache, etc.) ? 

      1. Pour les tables DynamoDB, vous pouvez décharger les lectures à l'aide de DAX pour la mise en cache.

      2. Pour les bases de données relationnelles, vous pouvez créer un cluster ElastiCache pour Redis et configurer votre application pour qu'elle lise d'abord les données à partir du cache, en revenant à la base de données si l'élément demandé n'est pas présent.

      3. Les bases de données relationnelles comme Amazon RDS et Aurora, et les bases de données NoSQL allouées telles que Neptune et Amazon DocumentDB prennent toutes en charge l'ajout de réplicas en lecture pour décharger les parties lues de la charge de travail.

      4. Les bases de données sans serveur comme DynamoDB se mettent à l'échelle automatiquement. Assurez-vous que vous disposez de suffisamment d'unités de capacité de lecture (RCU) allouées pour gérer la charge de travail.

    2. Quelles sont les solutions disponibles pour la mise à l'échelle des écritures (sharding des clés de partition, introduction d'une file d'attente, etc.) ?

      1. Pour les bases de données relationnelles, vous pouvez augmenter la taille de l'instance pour qu'elle s'adapte à une charge de travail accrue ou augmenter les IOPS provisionnés pour permettre un débit accru vers le stockage sous-jacent.

        • Vous pouvez également ajouter une file d'attente devant votre base de données plutôt que d'écrire directement dans la base de données. Ce modèle vous permet de dissocier l'ingestion de la base de données et de contrôler le débit afin que la base de données ne soit pas submergée. 

        • Regrouper vos demandes d'écriture plutôt que de créer de nombreuses transactions de courte durée contribue à améliorer le débit dans les bases de données relationnelles à volume d'écriture élevé.

      2. Les bases de données sans serveur comme DynamoDB peuvent mettre à l'échelle le débit d'écriture automatiquement ou en ajustant les unités de capacité d'écriture allouées (WCU) en fonction du mode de capacité. 

        • Cependant, vous pouvez toujours rencontrer des problèmes avec les partitions actives lorsque vous atteignez les limites de débit pour une clé de partition donnée. Pour pallier à ce problème, choisissez une clé de partition distribuée plus uniformément ou partitionnez en écriture la clé de partition. 

  3. Quels sont les pics de transactions par seconde (TPS) actuels ou attendus ? Testez l'utilisation de ce volume de trafic et de ce +X % de volume pour comprendre les caractéristiques de mise à l'échelle.

    1. Des outils natifs tels que pg_bench pour PostgreSQL peuvent être utilisés pour tester la base de données et identifier les goulots d'étranglement et les caractéristiques de mise à l'échelle.

    2. Le trafic de type production doit être capturé afin de pouvoir être réexécuté pour simuler des conditions réelles en plus des charges de travail synthétiques.

  4. Si vous utilisez un calcul sans serveur ou élastiquement évolutif, testez l'impact de cette mise à l'échelle sur la base de données. Le cas échéant, ajoutez la gestion ou le regroupement des connexions pour réduire l'impact sur la base de données. 

    1. RDS Proxy peut être utilisé avec Amazon RDS et Aurora pour gérer les connexions à la base de données. 

    2. Les bases de données sans serveur comme DynamoDB n'ont pas de connexions associées, mais tenez compte de la capacité allouée et des politiques de mise à l'échelle automatique pour faire face aux pics de charge.

  5. La charge est-elle prévisible, y a-t-il des pics de charge et des périodes d'inactivité ?

    1. En cas de périodes d'inactivité, envisagez de réduire la capacité allouée ou la taille de l'instance pendant ces périodes. Aurora Serverless V2 augmente et diminue automatiquement la capacité en fonction de la charge.

    2. Pour les instances hors production, envisagez de les suspendre ou de les arrêter en dehors des heures de travail.

  6. Avez-vous besoin de segmenter et de décomposer vos modèles de données en fonction des modèles d'accès et des caractéristiques des données ?

    1. Envisagez d'utiliser AWS DMS ou AWS SCT pour déplacer vos données vers d'autres services.

Niveau d'effort du plan d'implémentation : 

Pour respecter cette bonne pratique, vous devez connaître vos caractéristiques et métriques de données actuelles. La collecte de ces métriques, l'établissement d'un point de référence, puis l'utilisation de ces métriques pour identifier l'option de configuration de base de données idéale indique un niveau d'effort faible to modéré . La validation par des tests de charge et des expérimentations est conseillée.

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :