Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Réalisation d'une démonstration de faisabilité avec Amazon Aurora

Vous trouverez ci-après une explication de la manière de configurer et d'exécuter une démonstration de faisabilité pour Aurora. Une démonstration de faisabilité est une investigation que vous faites pour voir si Aurora convient bien à votre application. La démonstration de faisabilité peut vous aider à comprendre les fonctions d'Aurora dans le contexte de vos propres applications de base de données, ainsi qu'à comparer Aurora à votre environnement de base de données actuel. Il peut également indiquer le niveau d'effort dont vous avez besoin pour déplacer les données, le SQL code de port, optimiser les performances et adapter vos procédures de gestion actuelles.

Dans cette rubrique, vous trouverez une vue d'ensemble et un step-by-step aperçu des procédures et décisions de haut niveau nécessaires à l'exécution d'une preuve de concept, répertoriées ci-dessous. Pour obtenir des instructions détaillées, vous pouvez suivre les liens vers la documentation complète pour des sujets spécifiques.

Présentation d'une démonstration de faisabilité Aurora

Lorsque vous réalisez une validation de concept pour Amazon Aurora, vous découvrez ce qu'il faut faire pour transférer vos données et SQL applications existantes vers Aurora. Vous étudiez les aspects importants d'Aurora à grande échelle, en utilisant un volume de données et d'activités représentatif de votre environnement de production. L'objectif est de prendre confiance dans le fait que les points forts d'Aurora concordent bien avec les défis qui vous amènent à dépasser votre infrastructure de base de données précédente. À la fin d'une démonstration de faisabilité, vous disposez d'un plan concret pour effectuer des tests d'application et une comparaison des performances à plus grande échelle. À ce stade, vous comprenez les principaux éléments de travail qui vous attendent sur le chemin d'un déploiement en production.

Les conseils qui vous seront donnés sur les bonnes pratiques peuvent vous éviter des erreurs courantes qui posent problème lors des essais comparatifs. Toutefois, cette rubrique ne couvre pas le step-by-step processus d'exécution des tests de performance et de réglage des performances. Ces procédures varient selon votre charge de travail et les fonctions Aurora que vous utilisez. Pour obtenir des informations détaillées, veuillez consulter la documentation relative aux performances, telle que Gestion des performances et dimensionnement des clusters de bases de données Aurora, Améliorations des performances Amazon Aurora MySQL, Performances et évolutivité pour Amazon Aurora PostgreSQL et Surveillance de la charge de la base de données avec Performance Insights sur .

Les informations contenues dans cette rubrique s'appliquent principalement aux applications dans lesquelles votre organisation écrit le code et conçoit le schéma et qui prennent en charge les moteurs de base de données SQL open source My SQL et Postgre. Si vous testez une application commerciale ou du code généré par une infrastructure d'application, vous n'avez peut-être pas la flexibilité d'appliquer toutes les consignes. Dans ce cas, contactez votre AWS représentant pour savoir s'il existe des meilleures pratiques ou des études de cas Aurora correspondant à votre type d'application.

1. Identifier vos objectifs

Lorsque vous évaluez Aurora dans le cadre d'une démonstration de faisabilité, vous choisissez les mesures à effectuer et la manière d'évaluer la réussite de l'exercice.

Vous devez vous assurez que toutes les fonctionnalités de votre application sont compatibles avec Aurora. Les versions majeures d'Aurora étant câblées avec les versions principales correspondantes de My SQL et PostgreSQL, la plupart des applications développées pour ces moteurs sont également compatibles avec Aurora. Toutefois, vous devez encore valider la compatibilité application par application.

Par exemple, certains choix de configuration que vous faites lorsque vous configurez un cluster Aurora influencent le fait que vous puissiez ou deviez utiliser des fonctions de base de données particulières. Vous pouvez commencer avec le type de cluster Aurora à l'usage le plus général, appelé provisionné. Vous pouvez alors décider si une configuration spécialisée, telle qu'une requête parallèle ou sans serveur, offre des avantages pour votre charge de travail.

Utilisez les questions suivantes pour mieux identifier et quantifier vos objectifs :

Prenez le temps d'acquérir les connaissances nécessaires sur les capacités de plateforme et les moteurs de base de données Aurora, et passez en revue la documentation du service. Prenez bonne note de toutes les fonctionnalités qui peuvent vous aider à atteindre les résultats que vous souhaitez. L'une d'entre elles pourrait être la consolidation des charges de travail, décrite dans le billet AWS de blog sur la base de données How to planning and optimize Amazon Aurora with My SQL compatibility for consolidated workloads. Une autre peut être la mise à l'échelle basée sur la demande, décrite dans Amazon Aurora Auto Scaling avec des répliques Aurora, dans le Guide de l'utilisateur Amazon Aurora. D'autres peuvent être liées aux gains de performances ou à la simplification des opérations de base de données.

2. Comprendre les caractéristiques de votre charge de travail

Évaluez Aurora dans le contexte du cas d'utilisation que vous envisagez. Aurora est un bon choix pour les charges de travail liées au traitement des transactions en ligne (OLTP). Vous pouvez également exécuter des rapports sur le cluster qui contient les OLTP données en temps réel sans provisionner un cluster d'entrepôts de données distinct. Vous pouvez déterminer si votre cas d'utilisation appartient à l'une de ces catégories en recherchant les caractéristiques suivantes :

L'un des facteurs clés affectant vos choix de base de données est la vitesse des données. Une grande vitesse implique des insertions et des mises à jour très fréquentes des données. Un tel système peut compter des milliers de connexions et des centaines de milliers de requêtes simultanées de lecture et d'écriture dans une base de données. Dans les systèmes à grande vitesse, les requêtes affectent habituellement un nombre relativement faible de lignes et accèdent généralement à plusieurs colonnes d'une même ligne.

Aurora est conçu pour traiter les données à grande vitesse. Selon la charge de travail, un cluster Aurora doté d'une instance de base de données r4.16xlarge individuelle peut traiter plus de 600 000 instructions SELECT par seconde. Toujours en fonction de la charge de travail, un tel cluster peut traiter 200 000 instructions INSERT, UPDATE et DELETE par seconde. Aurora est une base de données en ligne parfaitement adaptée aux charges de travail à haut volume, à haut débit et hautement parallélisées. OLTP

Aurora peut également exécuter des requêtes de reporting sur le même cluster qui gère la OLTP charge de travail. Aurora prend en charge jusqu'à 15 réplicas, chacun intervenant en moyenne à 10–20 millisecondes de l'instance principale. Les analystes peuvent interroger OLTP les données en temps réel sans les copier vers un cluster d'entrepôts de données distinct. Avec les clusters Aurora qui utilisent la fonction de requête parallèle, vous pouvez décharger une grande partie du travail de traitement, de filtrage et d'agrégation dans le sous-système de stockage Aurora distribué massivement.

Utilisez cette phase de planification pour vous familiariser avec les fonctionnalités d'Aurora, AWS des autres services AWS Management Console, du et du AWS CLI. De plus, vérifiez comment ces éléments fonctionnent avec les autres outils que vous envisagez d'utiliser dans la démonstration de faisabilité.

3. Entraînez-vous avec le AWS Management Console ou AWS CLI

À l'étape suivante, entraînez-vous avec le AWS Management Console ou le AWS CLI, pour vous familiariser avec ces outils et avec Aurora.

Entraînez-vous avec AWS Management Console

Les activités initiales suivantes avec les clusters de bases de données Aurora visent principalement à vous familiariser avec l' AWS Management Console environnement et à vous entraîner à configurer et à modifier des clusters Aurora. Si vous utilisez les moteurs de base de données SQL compatibles My et Postgre SQL avec AmazonRDS, vous pouvez tirer parti de ces connaissances lorsque vous utilisez Aurora.

En tirant profit du modèle de stockage partagé Aurora et de fonctions telles que la réplication et les instantanés, vous pouvez traiter des clusters de base de données complets comme un autre type d'objet que vous pouvez manipuler librement. Vous pouvez configurer, supprimer et modifier fréquemment la capacité des clusters Aurora au cours de la démonstration de faisabilité. Vous n'êtes pas tenu de conserver vos choix précoces en matière de capacité, de paramètres de base de données et de disposition de données physiques.

Pour commencer, configurez un cluster Aurora vide. Choisissez le type de capacité provisionné et un emplacement régional pour vos expériences initiales.

Connectez-vous à ce cluster à l'aide d'un programme client tel qu'une application en SQL ligne de commande. Au départ, vous vous connectez à l'aide du point de terminaison de cluster. Vous vous connectez à ce point de terminaison pour effectuer toutes les opérations d'écriture, telles que les instructions du langage de définition des données (DDL) et les processus d'extraction, de transformation et de chargement (ETL). Ultérieurement dans la démonstration de faisabilité, vous connectez des sessions impliquant beaucoup de requêtes à l'aide du point de terminaison de lecteur, lequel distribue la charge de travail des requêtes entre plusieurs instances de base de données dans le cluster.

Effectuez une montée en charge du cluster en ajoutant d'autres réplicas Aurora. Pour ces procédures, veuillez consulter Réplication avec Amazon Aurora. Augmentez ou diminuez les instances de base de données en modifiant la classe d' AWS instance. Découvrez comment Aurora simplifie ces types d'opérations, de sorte que si vos estimations initiales de capacité système sont inexactes, vous pouvez effectuer des ajustements ultérieurs sans tout recommencer.

Créez un instantané et restaurez-le dans un cluster différent.

Examinez les métriques du cluster pour voir ses activités au fil du temps et la manière dont ces métriques s'appliquent aux instances de base de données dans le cluster.

Il est utile de se familiariser avec la façon de faire ces choses dès AWS Management Console le début. Une fois que vous comprenez ce que vous pouvez faire avec Aurora, vous pouvez progresser et automatiser ces opérations à l'aide de AWS CLI. Dans les sections suivantes, vous trouverez plus de détails sur les procédures et les meilleures pratiques relatives à ces activités au cours de proof-of-concept cette période.

Entraînez-vous avec AWS CLI

Nous recommandons d'automatiser les procédures de déploiement et de gestion, même dans un proof-of-concept environnement donné. Pour ce faire, familiarisez-vous avec le AWS CLI si ce n'est pas déjà fait. Si vous utilisez les moteurs de base de données SQL compatibles My et Postgre SQL avec AmazonRDS, vous pouvez tirer parti de ces connaissances lorsque vous utilisez Aurora.

Aurora implique généralement des groupes d'instances de base de données organisés en clusters. Ainsi, de nombreuses opérations impliquent de déterminer quelles instances de base de données sont associées à un cluster, puis d'effectuer les opérations administratives dans une boucle pour toutes ces instances.

Par exemple, vous pouvez automatiser des étapes telles que la création de clusters Aurora, puis leur mise à l'échelle ascendante avec des classes d'instance plus grandes ou leur montée en charge avec des instances de base de données supplémentaires. Cela vous aidera à répéter des phases quelconques de votre démonstration de faisabilité et à explorer des scénarios hypothétiques avec différents types de configuration de clusters Aurora.

Découvrez les capacités et les limites d'outils de déploiement d'infrastructure tels qu AWS CloudFormation. Vous constaterez peut-être que les activités que vous effectuez dans un proof-of-concept contexte ne sont pas adaptées à une utilisation en production. Par exemple, le AWS CloudFormation comportement de modification consiste à créer une nouvelle instance et à supprimer l'instance actuelle, y compris ses données. Pour plus de détails sur ce comportement, veuillez consulter Comportements de mise à jour des ressources d'une pile dans le Guide de l'utilisateur AWS CloudFormation .

4. Créer votre cluster Aurora

Avec Aurora, vous pouvez explorer des scénarios hypothétiques en ajoutant des instances de base de données au cluster et en effectuant une mise à l'échelle ascendante des instances de base de données vers des classes d'instance plus puissantes. Vous pouvez également créer des clusters avec différents paramètres de configuration pour exécuter côte à côte la même charge de travail. Avec Aurora, vous disposez d'une grande flexibilité pour configurer, supprimer et reconfigurer des clusters de base de données. Dans ces conditions, il est utile de pratiquer ces techniques dès les premières étapes du proof-of-concept processus. Pour découvrir les procédures générales permettant de créer des clusters Aurora, veuillez consulter Création d'un cluster de base de données Amazon Aurora.

Là où cela est possible, commencez avec un cluster en utilisant les paramètres suivants. Ignorez cette étape seulement si vous avez certains cas d'utilisation spécifiques en tête. Par exemple, vous pouvez ignorer cette étape si votre cas d'utilisation requiert un type de cluster Aurora spécialisé. Vous pouvez également l'ignorer si vous avez besoin d'une combinaison particulière de version et de moteur de base de données.

5. Configurer votre schéma

Sur le cluster Aurora, configurez des bases de données, des tables, des index, des clés étrangères et d'autres objets de schéma pour votre application. Si vous passez d'un autre système de base de données SQL compatible My ou PostgreSQL, attendez-vous à ce que cette étape soit simple et directe. Vous utilisez la même SQL syntaxe et la même ligne de commande ou d'autres applications clientes que celles que vous connaissez pour votre moteur de base de données.

Pour émettre SQL des instructions sur votre cluster, recherchez son point de terminaison et fournissez cette valeur comme paramètre de connexion à votre application cliente. Vous trouverez le point de terminaison de cluster dans l'onglet Connectivity (Connectivité) de la page de détails de votre cluster. Le point de terminaison de cluster est celui intitulé Writer (Rédacteur). L'autre point de terminaison, intitulé Reader (Lecteur), représente une connexion en lecture seule que vous pouvez fournir aux utilisateurs finaux qui exécutent des rapports ou d'autres requêtes en lecture seule. Pour obtenir de l'aide face à des problèmes de connexion à votre cluster, veuillez consulter Connexion à un cluster de bases de données Amazon Aurora.

Si vous déplacez votre schéma et vos données à partir d'un système de base de données différent, préparez-vous à apporter à ce stade certaines modifications à votre schéma. Ces modifications de schéma doivent correspondre à la SQL syntaxe et aux fonctionnalités disponibles dans Aurora. Vous pouvez exclure certains déclencheurs, colonnes, contraintes ou autres objets de schéma à ce stade. Cela peut s'avérer utile, notamment si ces objets nécessitent des adaptations pour la compatibilité d'Aurora et ne sont pas significatifs pour vos objectifs en matière de démonstration de faisabilité.

Si vous migrez depuis un système de base de données doté d'un moteur sous-jacent différent de celui d'Aurora, pensez à utiliser le AWS Schema Conversion Tool (AWS SCT) pour simplifier le processus. Pour plus de détails, consultez le Guide de l'utilisateur AWS Schema Conversion Tool. Pour obtenir des informations générales sur les activités de migration et de portage, consultez le AWS livre blanc sur la migration de vos bases de données vers Amazon Aurora.

Au cours de cette phase, vous pouvez évaluer la présence ou l'absence d'inefficacités dans votre configuration de schéma, par exemple dans votre stratégie d'indexation ou dans d'autres structures de table, telles que les tables partitionnées. De telles inefficacités peuvent être amplifiées lorsque vous déployez votre application sur un cluster doté de plusieurs instances de base de données et d'une charge de travail importante. Déterminez si vous pouvez affiner actuellement de tels aspects de performances, ou durant des activités ultérieures, telles qu'un test complet d'évaluation.

6. Importer vos données

Durant la démonstration de faisabilité, vous étudiez les données, ou un échantillon représentatif, provenant de votre système de base de données antérieur. Si possible, configurez au moins certaines données dans chacune de vos tables. Cela vous aide à tester la compatibilité de tous les types de données et fonctions de schéma. Après vous être exercé à l'utilisation des fonctions Aurora de base, effectuez une mise à l'échelle ascendante de la quantité de données. Lorsque vous aurez terminé la validation du concept, vous devriez tester vos ETL outils, vos requêtes et votre charge de travail globale avec un ensemble de données suffisamment volumineux pour tirer des conclusions précises.

Vous pouvez utiliser plusieurs techniques pour apporter des données de sauvegarde physique ou logique dans Aurora. Pour obtenir des détails, veuillez consulter Migration de données vers un cluster Amazon Aurora My SQL DB ou Migration de données vers Amazon Aurora avec compatibilité avec Postgre SQL selon le moteur de base de données que vous utilisez dans la démonstration de faisabilité.

Testez les ETL outils et les technologies que vous envisagez. Déterminez ce qui répond le mieux à vos besoins. Prenez en compte à la fois le débit et la flexibilité. Par exemple, certains ETL outils effectuent un transfert ponctuel, tandis que d'autres impliquent une réplication continue de l'ancien système vers Aurora.

Si vous migrez d'un système SQL compatible My vers Aurora MySQL, vous pouvez utiliser les outils de transfert de données natifs. Il en va de même si vous migrez d'un système SQL compatible avec Postgre vers Aurora Postgre. SQL Si vous migrez depuis un système de base de données qui utilise un moteur sous-jacent différent de celui d'Aurora, vous pouvez tester le AWS Database Migration Service (AWS DMS). Pour plus de détails AWS DMS, consultez le guide de AWS Database Migration Service l'utilisateur.

Pour plus de détails sur les activités de migration et de portage, consultez le AWS livre blanc sur le manuel de migration Aurora.

7. Transférez votre SQL code

L'essai des applications SQL et des applications associées nécessite différents niveaux d'effort selon les cas. En particulier, le niveau d'effort dépend du fait que vous passez d'un système SQL SQL compatible My ou Postgre ou d'un autre type.

Au cours de cette phase, vous pouvez évaluer la présence ou l'absence d'inefficacités dans votre configuration de schéma, par exemple dans votre stratégie d'indexation ou dans d'autres structures de table, telles que les tables partitionnées. Déterminez si vous pouvez affiner actuellement de tels aspects de performances, ou durant des activités ultérieures, telles qu'un test complet d'évaluation.

Vous pouvez vérifier la logique de connexion de base de données dans votre application. Pour tirer profit du traitement distribué d'Aurora, vous pouvez avoir besoin d'utiliser des connexions distinctes pour les opérations de lecture et d'écriture, et d'utiliser des sessions relativement courtes pour les opérations de requête. Pour obtenir des informations sur les connexions, veuillez consulter 9. Se connecter à Aurora.

Réfléchissez aux concessions et compromis éventuels que vous avez dû faire pour contourner les problèmes dans votre base de données de production. Prévoyez du temps dans le proof-of-concept planning pour apporter des améliorations à la conception de votre schéma et à vos requêtes. Pour juger si vous pouvez obtenir des victoires faciles en matière de performances, de coût d'exploitation et d'évolutivité, essayez les applications d'origine et modifiées côte à côte sur différents clusters Aurora.

Pour plus de détails sur les activités de migration et de portage, consultez le AWS livre blanc sur le manuel de migration Aurora.

8. Spécifier les paramètres de configuration

Vous pouvez également passer en revue les paramètres de configuration de votre base de données dans le cadre de l' proof-of-concept exercice Aurora. Vous avez peut-être déjà réglé les paramètres de SQL configuration My SQL ou Postgre en fonction des performances et de l'évolutivité de votre environnement actuel. Le sous-système de stockage d'Aurora est adapté et réglé pour un environnement distribué basé sur le cloud avec un sous-système de stockage à grande vitesse. Par conséquent, de nombreux anciens paramètres de moteur de base de données ne s'appliquent pas. Nous vous recommandons de conduire vos expériences initiales avec les paramètres de configuration Aurora par défaut. Réappliquez les paramètres de votre environnement actuel seulement si vous rencontrez des goulots d'étranglement de performances et d'évolutivité. Si cela vous intéresse, vous pouvez approfondir ce sujet dans la section Présentation du moteur de stockage Aurora sur le blog AWS de base de données.

Aurora favorise la réutilisation des paramètres de configuration optimaux pour une application particulière ou un cas d'utilisation particulier. Au lieu de modifier un fichier de configuration distinct pour chaque instance de base de données, vous gérez des ensembles de paramètres que vous assignez à des clusters entiers ou à des instances de base de données spécifiques. Par exemple, le paramètre de fuseau horaire s'applique à toutes les instances de base de données du cluster, et vous pouvez ajuster le paramètre de taille du cache de page pour chaque instance de base de données.

Vous commencez avec l'un des ensembles de paramètres par défaut et appliquez les modifications aux seuls paramètres dont vous devez affiner le réglage. Pour obtenir des détails sur l'utilisation des groupes de paramètres, veuillez consulter Paramètres de cluster de base de données et d'instance de base de données Amazon Aurora. Pour découvrir les paramètres de configuration qui sont applicables ou non aux clusters Aurora, veuillez consulter Paramètres de configuration d'Aurora MySQL ou Paramètres Amazon Aurora PostgreSQL. selon votre moteur de base de données.

9. Se connecter à Aurora

Comme vous pouvez le constater en effectuant votre configuration initiale de schéma et de données et en exécutant des exemples de requête, vous pouvez vous connecter à différents points de terminaison dans un cluster Aurora. Le point de terminaison à utiliser varie selon que l'opération correspond à une lecture, telle qu'une instruction SELECT, ou à une écriture, telle qu'une instruction CREATE ou INSERT. Lorsque vous augmentez la charge de travail sur un cluster Aurora et essayez les fonctions Aurora, il est important pour votre application d'affecter chaque opération au point de terminaison approprié.

En utilisant le point de terminaison de cluster pour les opérations d'écriture, vous vous connectez toujours à une instance de base de données dans le cluster qui possède des capacités de lecture/écriture. Par défaut, seule une instance de base de données d'un cluster Aurora possède des capacités de lecture/écriture. Cette instance de base de données est appelée instance principale. Si l'instance principale d'origine devient non disponible, Aurora active un mécanisme de basculement et une autre instance de base de données prend la relève comme instance principale.

De même, en dirigeant les instructions SELECT vers le point de terminaison de lecteur, vous répartissez le travail de traitement des requêtes entre les instances de base de données du cluster. Chaque connexion de lecteur est attribuée à une instance de base de données différente à l'aide d'une résolution circulaire. DNS L'exécution de la majeure partie du travail de requête sur les réplicas de base de données Aurora en lecture seule réduit la charge sur l'instance principale, ce qui lui permet de se consacrer à la gestion et aux instructions. DDL DML

L'utilisation de ces points de terminaison réduit la dépendance sur les noms d'hôte codés en dur et aide votre application à récupérer plus rapidement après des échecs d'instance de base de données.

Les réplicas Aurora sont sujets à un retard de réplication, généralement compris entre 10 et 20 millisecondes. Vous pouvez surveiller ce retard de réplication et décider s'il figure dans la plage de vos exigences de cohérence des données. Dans certains cas, vos requêtes de lecture peuvent nécessiter une forte cohérence de lecture (read-after-writecohérence). Dans ces cas, vous pouvez continuer à utiliser le point de terminaison de cluster et non pas le point de terminaison de lecteur.

Pour tirer pleinement parti des capacités d'Aurora pour l'exécution parallèle distribuée, vous pouvez être amené à modifier la logique de connexion. Votre objectif est d'éviter d'envoyer toutes les demandes de lecture à l'instance principale. Les réplicas Aurora en lecture seule sont en attente, tous avec les mêmes données, prêts à traiter les instructions SELECT. Codez votre logique d'application pour utiliser le point de terminaison approprié pour chaque type d'opération. Suivez ces instructions générales :

Pour obtenir des informations générales sur la gestion des connexions et les points de terminaison pour Aurora, veuillez consulter Connexion à un cluster de bases de données Amazon Aurora. Pour en savoir plus sur ce sujet, consultez le manuel de l'administrateur SQL de base de données Aurora My — Gestion des connexions.

10. Exécuter votre charge de travail

Une fois que les paramètres de schéma, de données et de configuration sont en place, vous pouvez commencer à vous exercer à utiliser le cluster en exécutant votre charge de travail. Dans la démonstration de faisabilité, utilisez une charge de travail qui reflète les aspects principaux de votre charge de travail de production. Nous recommandons de toujours prendre des décisions concernant les performances en utilisant des tests et des charges de travail réels plutôt que des benchmarks synthétiques tels que sysbench ou -C. TPC Dans la mesure du possible, collectez des mesures en fonction de votre propre schéma, de vos modèles de requêtes et de votre volume d'utilisation.

Autant que possible, reproduisez les conditions réelles dans lesquelles l'application s'exécutera. Par exemple, vous exécutez généralement le code de votre application sur des EC2 instances Amazon situées dans la même AWS région et dans le même cloud privé virtuel (VPC) que le cluster Aurora. Si votre application de production s'exécute sur plusieurs EC2 instances réparties dans plusieurs zones de disponibilité, configurez votre proof-of-concept environnement de la même manière. Pour plus d'informations sur AWS les régions, consultez Régions et zones de disponibilité dans le guide de RDS l'utilisateur Amazon. Pour en savoir plus sur le VPC service Amazon, consultez Qu'est-ce qu'Amazon VPC ? dans le guide de VPC l'utilisateur Amazon.

Une fois que vous avez vérifié que les fonctions de base de votre application fonctionnent et que vous pouvez accéder aux données via Aurora, vous pouvez étudier les aspects du cluster Aurora. Certaines fonctions que vous pouvez essayer mettent en jeu des connexions simultanées à l'équilibrage de la charge, à des transactions simultanées et à la réplication automatique.

À ce stade, les mécanismes de transfert de données doivent être familiers et tels que vous puissiez exécuter des tests avec une plus grande proportion d'échantillons de données.

Cette phase permet de voir les effets du changement des paramètres de configuration, tels que les limites de mémoire et les limites de connexion. Réexaminez les procédures que vous avez explorées dans 8. Spécifier les paramètres de configuration.

Vous pouvez également effectuer des essais avec des mécanismes tels que la création et la restauration d'instantanés. Par exemple, vous pouvez créer des clusters avec différentes classes d' AWS instances, différents nombres de AWS répliques, etc. Ensuite, dans chaque cluster, vous pouvez restaurer le même instantané contenant votre schéma et toutes vos données. Pour découvrir les détails de ce cycle, veuillez consulter Création d'un instantané de cluster de base de données et Restauration à partir d'un instantané de cluster de base de données.

11. Mesurer les performances

Dans ce domaine, les bonnes pratiques sont conçues pour garantir que tous les processus et outils appropriés soient configurés de manière à isoler rapidement les comportements anormaux au cours des opérations mettant en jeu les charges de travail. Elles sont également élaborées pour vous assurer de pouvoir identifier de façon fiable toutes les causes applicables.

Vous pouvez toujours voir l'état actuel de votre cluster ou examiner les tendances au fil du temps en affichant l'onglet Surveillance. Cet onglet est disponible à partir de la page de détails de la console pour chaque cluster ou instance de base de données Aurora. Il affiche les statistiques du service CloudWatch de surveillance Amazon sous forme de graphiques. Vous pouvez filtrer les métriques par leur nom, par l'instance de base de données et par période.

Pour disposer de plus de choix dans l'onglet Surveillance, activez les options de surveillance améliorée et Performance Insights dans les paramètres du cluster. Vous pouvez également activer ultérieurement ces choix si vous ne l'avez pas fait lors de la configuration du cluster.

Pour mesurer les performances, vous pouvez principalement vous appuyer sur les graphiques qui montrent les activités pour le cluster Aurora tout entier. Vous pouvez vérifier si les réplicas Aurora ont une charge et des temps de réponse similaires. Vous pouvez également voir comment le travail est divisé entre l'instance principale de lecture/écriture et les réplicas Aurora en lecture seule. Dans le cas d'un déséquilibre entre les instances de base de données ou d'un problème affectant seulement une instance de base de données, vous pouvez examiner l'onglet Surveillance pour cette instance spécifique.

Une fois que l'environnement et la charge de travail réelle ont été configurés pour émuler votre application de production, vous pouvez mesurer la façon dont Aurora fonctionne. Les questions les plus importantes auxquelles il convient de répondre sont les suivantes :

Pour consulter les métriques de débit et de latence, consultez l'onglet Monitoring d'un cluster Aurora donné dans la RDSconsole Amazon. La capture d'écran suivante montre un exemple des métriques de sélection de la DMLlatence, de la latence, du débit sélectionné et du DMLdébit dans l'onglet Surveillance.

Si vous le pouvez, établissez des valeurs de référence pour ces métriques dans votre environnement actuel. Si ce n'est pas possible, établissez une référence sur le cluster Aurora en exécutant une charge de travail équivalente à votre application de production. Par exemple, exécutez votre charge de travail Aurora avec un nombre similaire d'utilisateurs et de requêtes simultanés. Ensuite, observez la manière dont les valeurs changent lorsque vous essayez différents paramètres de configuration, classes d'instance, tailles de cluster, etc.

Si les chiffres de débit sont inférieurs à ce que vous attendiez, poursuivez vos investigations pour déterminer les facteurs affectant les performances de base de données pour votre charge de travail. De même, si les chiffres de latence sont supérieurs à ce que vous attendiez, poursuivez vos investigations. Pour ce faire, surveillez les métriques secondaires du serveur de base de données (mémoireCPU, etc.). Vous pouvez voir si les instances de base de données sont proches de leurs limites. Vous pouvez également voir les capacités supplémentaires dont vos instances de base de données disposent pour traiter plus de requêtes simultanées, des requêtes portant sur des tables plus grandes, etc.

Lorsque vous évaluez la capacité et la taille idéales d'un cluster Aurora, vous pouvez trouver la configuration qui permet d'atteindre des performances d'application de pointe sans sur-approvisionnement de ressources. Un facteur important est de trouver la taille appropriée pour les instances de base de données du cluster Aurora. Commencez par sélectionner une taille d'instance dont la capacité de mémoire CPU et la capacité de mémoire sont similaires à celles de votre environnement de production actuel. Collectez les chiffres de débit et de latence pour la charge de travail à cette taille d'instance. Ensuite, mettez à l'échelle l'instance jusqu'à la taille supérieure suivante. Observez si les chiffres de débit et de latence s'améliorent. Réduisez également la taille de l'instance et observez si les chiffres de latence et de débit restent les mêmes. Votre objectif est d'obtenir le plus haut débit avec la plus basse latence sur la plus petite instance possible.

Exécuter des tests de performances suffisamment longs pour mesurer les performances de base de données dans un état stable et à chaud. Vous pouvez avoir besoin d'exécuter la charge de travail pendant de nombreuses minutes ou même quelques heures avant d'atteindre cet état stable. Il est normal d'avoir une certaine variation en début d'exécution. Cette variation se produit car chaque réplica Aurora fait chauffer ses caches sur la base des requêtes SELECT qu'il traite.

Aurora fonctionne le mieux avec des charges de travail transactionnelles impliquant plusieurs requêtes et utilisateurs simultanés. Pour vérifier que vous utilisez une charge suffisante pour obtenir des performances optimales, effectuez des évaluations qui utilisent le multithreading ou exécutez simultanément plusieurs instances des tests de performances. Mesurez les performances avec des centaines ou même des milliers de threads client simultanés. Simulez le nombre de threads simultanés que vous prévoyez dans votre environnement de production. Vous pouvez également effectuer des tests de contrainte supplémentaires avec plus de threads pour mesurer l'évolutivité d'Aurora.

12. Étudier la haute disponibilité d'Aurora

Un grand nombre des fonctions Aurora principales impliquent la haute disponibilité. Ces fonctionnalités incluent la réplication automatique, le basculement automatique, les sauvegardes automatiques avec point-in-time restauration et la possibilité d'ajouter des instances de base de données au cluster. La sécurité et la fiabilité qui émanent de fonctions telles que celles-ci sont importantes pour les applications d'importance capitale.

L'évaluation de ces fonctions requiert un certain état d'esprit. Dans les activités précédentes, telles que le mesurage des performances, vous observez les performances du système quand tout fonctionne correctement. Les tests de haute disponibilité exigent que vous pensiez dans le détail le comportement pour le pire scénario. Vous devez prendre en compte différents types d'échecs, même si de telles conditions sont rares. Vous pouvez introduire intentionnellement des problèmes pour vérifier la capacité du système à récupérer rapidement et correctement.

Nous vous recommandons d'utiliser au moins deux instances dans chaque cluster Aurora. Les instances de base de données d'un cluster Aurora peuvent couvrir jusqu'à trois zones de disponibilité (AZs). Localisez chacune des deux ou trois premières instances de base de données dans une zone de disponibilité différente. Lorsque vous commencez à utiliser des clusters plus importants, répartissez vos instances de base de données sur AZs l'ensemble de votre AWS région. Cela augmente la capacité de tolérance aux pannes. Même si un problème affecte une zone de disponibilité complète, Aurora peut basculer vers une instance de base de données située dans une autre zone de disponibilité. Si vous exécutez un cluster avec plus de trois instances, répartissez les instances de base de données aussi uniformément que possible sur les troisAZs.

Pour découvrir comment simuler des conditions de défaillance pour tester des fonctions à haute disponibilité, veuillez consulter Test d'Amazon Aurora My à SQL l'aide de requêtes d'injection d'erreurs.

Dans le cadre de votre proof-of-concept exercice, l'un des objectifs est de trouver le nombre idéal d'instances de base de données et la classe d'instance optimale pour ces instances de base de données. Cela requiert d'équilibrer les exigences de performances et de haute disponibilité.

Pour Aurora, plus vous avez d'instances de base de données dans un cluster, plus cela profite à la haute disponibilité. L'augmentation du nombre d'instances de base de données améliore également la capacité de mise à l'échelle des applications nécessitant beaucoup d'opérations de lecture. Aurora peut distribuer plusieurs connexions pour les requêtes SELECT entre les réplicas Aurora en lecture seule.

D'un autre côté, la limitation du nombre d'instances de base de données réduit le trafic de réplication à partir du nœud principal. Le trafic de réplication consomme de la bande passante réseau, ce qui constitue un autre aspect des performances et de l'évolutivité globales. Ainsi, pour les OLTP applications nécessitant beaucoup d'écriture, préférez avoir un plus petit nombre d'instances de base de données de grande taille plutôt que de nombreuses petites instances de base de données.

Dans un cluster Aurora classique, une instance de base de données (l'instance principale) gère toutes les DML instructions DDL and. Les autres instances de base de données (les réplicas Aurora) traitent uniquement les instructions SELECT. Bien que les instances de base de données n'exécutent pas exactement la même quantité de travail, nous vous recommandons d'utiliser la même classe d'instance pour toutes les instances de base de données du cluster. De cette manière, si une défaillance survient et qu'Aurora promeut l'une des instances de base de données en lecture seule comme nouvelle instance principale, cette instance principale a la même capacité qu'avant.

Si vous avez besoin d'utiliser des instances de base de données de différentes capacités dans un même cluster, configurez des niveaux de basculement pour les instances de base de données. Ces niveaux déterminent l'ordre dans lequel les réplicas Aurora sont promus par le mécanisme de basculement. Placez les instances de base de données beaucoup plus grandes ou plus petites que les autres à un niveau de basculement inférieur. Cela garantit qu'ils seront choisis en dernier pour une promotion.

Testez les fonctionnalités de restauration des données d'Aurora, telles que la point-in-time restauration automatique, les instantanés et la restauration manuels, ainsi que le retour en arrière des clusters. Le cas échéant, copiez les instantanés dans d'autres AWS régions et restaurez-les dans d'autres AWS régions pour imiter les scénarios de reprise après sinistre.

Étudiez les exigences de votre organisation en matière d'objectif de temps de restauration (RTO), d'objectif de point de restauration (RPO) et de redondance géographique. La plupart des organisations groupent ces éléments dans la catégorie élargie de reprise après sinistre. Évaluez les fonctionnalités de haute disponibilité d'Aurora décrites dans cette section dans le contexte de votre processus de reprise après sinistre afin de vous assurer que vos RPO exigences RTO et exigences sont satisfaites.

13. Suite des opérations

À la fin d'un proof-of-concept processus réussi, vous confirmez qu'Aurora est une solution adaptée à vos besoins en fonction de la charge de travail prévue. Tout au long du processus précédent, vous avez vérifié comment Aurora fonctionne dans un environnement opérationnel réaliste et avez mesuré cela sur la base de vos critères de réussite.

Une fois que votre environnement de base de données est opérationnel avec Aurora, vous pouvez passer à des étapes d'évaluation plus détaillées, qui mènent à votre migration finale et au déploiement en production. Selon votre situation, ces autres étapes peuvent ou non être incluses dans le proof-of-concept processus. Pour plus de détails sur les activités de migration et de portage, consultez le AWS livre blanc sur le manuel de migration Aurora.

Dans une autre étape ultérieure, prenez en considération les configurations de sécurité pertinentes pour votre charge de travail et conçues pour satisfaire vos exigences de sécurité dans un environnement de production. Planifiez les contrôles à mettre en place pour protéger l'accès aux informations d'identification des utilisateurs principaux du cluster Aurora. Définissez les rôles et responsabilités des utilisateurs de base de données pour contrôler l'accès aux données stockées dans le cluster Aurora. Prenez en compte les exigences d'accès aux bases de données pour les applications, les scripts et les outils ou services tiers. Explorez les AWS services et fonctionnalités tels que AWS Secrets Manager l'authentification and AWS Identity and Access Management (IAM).

À ce stade, vous devez comprendre les procédures et les bonnes pratiques à utiliser pour effectuer des tests d'évaluation avec Aurora. Vous pouvez constater qu'il vous faut effectuer un réglage supplémentaire des performances. Pour en savoir plus, veuillez consulter Gestion des performances et dimensionnement des clusters de bases de données Aurora, Améliorations des performances Amazon Aurora MySQL, Performances et évolutivité pour Amazon Aurora PostgreSQL et Surveillance de la charge de la base de données avec Performance Insights sur . Si vous effectuez un réglage supplémentaire, veillez à bien connaître les métriques que vous avez rassemblées au cours de la démonstration de faisabilité. Dans une étape ultérieure, vous pouvez créer des clusters en faisant des choix différents de paramètres de configuration, de moteur de base de données et de version de base de données. Vous pouvez également créer des types spécialisés de clusters Aurora pour répondre aux besoins de cas d'utilisation spécifiques.

Par exemple, vous pouvez explorer les clusters de requêtes parallèles Aurora pour les applications hybrides de traitement transactionnel/analytique (HTAP). Si une large distribution géographique est essentielle pour la reprise après sinistre ou pour réduire au maximum la latence, vous pouvez explorer les bases de données globales Aurora. Si votre charge de travail est intermittente ou que vous utilisez Aurora dans un scénario de développement/test, vous pouvez explorer les clusters Aurora Serverless.

Vos clusters de production peuvent également avoir besoin de traiter des volumes élevés de connexions entrantes. Pour découvrir ces techniques, consultez le AWS livre blanc intitulé Manuel de l'administrateur de SQL base de données Aurora My : Gestion des connexions.

Si, après la preuve de concept, vous décidez que votre cas d'utilisation n'est pas adapté pour Aurora, envisagez d'utiliser les autres services AWS suivants :