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.

Optimisation de la charge de travail des requêtes

Une charge de travail bien ajustée vous permettra de trouver une solution stable à l'hypercroissance. Si votre charge de travail n'est pas bien ajustée, quelle que soit la puissance du cluster Amazon Aurora que vous utilisez, vous rencontrerez des goulots d'étranglement qui dégraderont les performances et qui auront un impact sur l'expérience utilisateur de votre application. Il est recommandé de mettre en place dès le départ un processus qui vous aide à identifier et à régler les requêtes problématiques dans votre système.

Suivi et réglage des requêtes problématiques liées à votre charge de travail

En cas d'hypercroissance, il suffit d'avoir une charge de travail bien réglée pour faire la moitié du chemin. Pour comprendre la nature des charges de travail en temps réel et des problèmes de performances auxquels votre cluster Aurora est confronté, assurez-vous que votre équipe recueille les requêtes problématiques provenant à la fois de votre instance d'enregistreur et de votre instance de lecteur. Ces requêtes problématiques doivent être réglées pour que votre charge de travail s'exécute de manière optimale. Amazon Aurora Édition compatible avec MySQL vous permet d'y parvenir de deux manières :

Utilisation de l'Analyse des performances

L'Analyse des performances suit la charge sur l'instance d'enregistreur ou de lecteur Aurora en fonction de la moyenne des sessions actives (AAS). La valeur AAS est calculée à l'aide de l'échantillonnage et du nombre de sessions actives qui attendent qu'un processeur prenne en charge la charge de travail de ses requêtes et la traite. L'Analyse des performances propose une interface graphique dans laquelle vous pouvez vérifier les instructions SQL qui sont à l'origine de la charge la plus élevée en termes d'attente pour les sessions actives.

Dans la capture d'écran précédente, l'appel à la procédure stockée my_sqrt fait attendre le traitement de la charge de 13,03 sessions en moyenne. La prochaine étape logique consiste à ajuster cette procédure. Vous devez identifier les instructions SQL de vos lecteurs et enregistreurs qui sont à l'origine d'une charge sur leur instance respective et les régler pour améliorer les performances jusqu'à ce que les valeurs AAS chutent et restent en dessous de la ligne pointillée Max vCPU dans Analyse des performances. Si vos tentatives de réglage ont atteint un plafond et que vous constatez toujours que l'AAS est au-dessus de la ligne Max vCPU, vous pouvez opter pour une classe d'instance plus importante pour gérer votre charge de travail. N'optez pas pour une instance plus importante sans avoir d'abord essayé d'ajuster la charge de travail de vos requêtes, car l'augmentation du trafic commencera à révéler les lignes erronées créées par de mauvaises requêtes dans votre charge de travail.

Utiliser des journaux de requêtes lents et les publier sur CloudWatch

Le journal des requêtes lentes est une fonctionnalité native de MySQL qui vient compléter l'Analyse des performances. Il est recommandé d'utiliser ces deux méthodes pour garder une longueur d'avance sur les requêtes problématiques susceptibles de perturber vos instances. Le journal des requêtes lentes journalise toutes les requêtes plus lentes que la variable dynamique long_query_time. Cette variable peut être configurée sans aucun redémarrage de vos instances de cluster.

Pour garantir flexibilité et isolation lors de l'exercice de réglage, utilisez des groupes de paramètres distincts pour vos instances d'enregistreur et de lecteur. Ceci est particulièrement important si vous utilisez la répartition lecture-écriture. Définissez une limite confortable pour long_query_time dans vos instances de cluster en fonction de vos besoins. À mesure que vous réglez votre charge, vous pouvez viser des valeurs agressives dans la variable long_query_time, car vous pouvez définir le seuil à la milliseconde près. Avec une simultanéité élevée et une charge de travail bien ajustée, presque toutes vos requêtes devraient s'exécuter en quelques millisecondes.

Lorsque vous configurez Amazon Aurora Édition compatible avec MySQL pour enregistrer les requêtes lentes dans un fichier, Aurora Édition compatible avec MySQL écrit les journaux des requêtes lentes dans le système de fichiers Aurora compatible avec MySQL et les conserve pendant 24 heures. Pour conserver les journaux de requêtes lents pendant une période plus longue à des fins d'analyse, publiez-les sur Amazon CloudWatch. Vous pouvez également créer un CloudWatch tableau de bord pour surveiller la lenteur de vos requêtes. Pour plus d'informations, consultez le billet de blog Creating an Amazon CloudWatch Dashboard to monitor Amazon RDS et Amazon Aurora MySQL. En plus d'analyser vos requêtes lentes sur Amazon CloudWatch, vous pouvez profiler les journaux de requêtes lentes à l'aide pt-query-digest d'un outil du Percona Toolkit.

Vous pouvez également choisir d'automatiser ce processus de téléchargement et de profilage des requêtes pour améliorer l'efficacité au sein de votre équipe. Votre équipe doit rechercher les requêtes qui s'exécutent fréquemment et à des intervalles plus longs, et les régler en priorité. Visez un état dans lequel très peu de requêtes sont journalisées dans votre journal des requêtes lentes. Aussi, vous pouvez réduire le long_query_time pour devenir plus agressif en comprenant et en ajustant votre charge de travail.