Cloud

PostgreSQL dans le cloud : l’investigation des requêtes lentes peut s’avérer complexe

Par La rédaction, publié le 23 juillet 2024

Dans un environnement cloud public, lorsqu’une requête SQL sous PostgreSQL manque de performance, il s’avère souvent difficile d’identifier la cause du problème. Et pour cause, les fournisseurs cloud limitent l’accès aux métriques système. Il peut être tentant de souscrire une offre supérieure, à moins que les traces qui peuvent être récupérées ne donnent des indices suffisants à la résolution du problème…

Par Nicolas Gollet, Directeur Technique chez Dalibo

Les motivations pour héberger une base de données vers le cloud sont nombreuses : rapidité de mise en place, nouveau projet, choix stratégique, automatisation, montée en charge, mise en place relativement propre même en cas de manque de compétences, effet collatéral de la signature d’un contrat groupe…

Par ailleurs, la manière dont les projets sont initiés désormais diffère beaucoup de celle qui prévalait par le passé : les développeurs — pour des raisons de simplicité, de rapidité de mise en œuvre et parce qu’ils peuvent le faire en toute autonomie, sans recours aux administrateurs systèmes ou aux administrateurs de bases de données — mettent volontiers en place des bases de données chez des fournisseurs Cloud.

Dans le cadre de l’écriture d’une application, la démarche est simple, les actions de mise en place vont être réalisées de manière automatique par l’opérateur Cloud. Il s’agit le plus souvent d’actions liées à de l’administration des systèmes ou à de la configuration de base telles que la mise en place des serveurs, de la réplication, d’un nouveau serveur secondaire.

Les effets pervers de l’absence de métriques systèmes avancées

Dans ce contexte, le choix d’une instance s’effectue au regard de considérations de prix ou parce que le développeur a eu connaissance d’un retour d’expérience positif dans la presse ou sur les réseaux sociaux. Il n’a pas forcément la vision de ce que cela signifie en matière d’utilisation et de gestion des systèmes.

Et effectivement, malgré tous les avantages de l’orchestration automatisée par le Cloud, la performance de la base de données peut ne pas être au rendez-vous.

Or, en fonction du fournisseur cloud choisi, plus ou moins d’informations, de métriques sont accessibles, récupérables, pour comprendre la performance de la base de données. Les métriques système sont en effet réduites à celles auxquelles le fournisseur veut bien donner accès. Et souvent, ces informations sont assez limitées. En ce sens, l’infrastructure s’apparente un peu à une boîte noire.

Pour le fournisseur, il s’agit probablement de simplifier au maximum les infos et que la prise en main soit la plus simple pour les utilisateurs finaux.

En uniformisant le niveau d’information fournie aux clients, en limitant l’accès aux informations au strict nécessaire, au strictement utile, en simplifiant la visualisation et la compréhension, le fournisseur améliore l’expérience client, ce qui, accessoirement, peut aussi contribuer à limiter le nombre des recours au support technique. Cette transparence limitée peut également se traduire par une plus grande dépendance vis-à-vis du fournisseur cloud.

Par exemple, voir la quantité de mémoire libre, la quantité de mémoire utilisée, sans entrer dans le détail, sans en comprendre le comportement, ne suffit pas.

Une autre conséquence est que lorsqu’un problème se présente, que le système ne fonctionne pas comme il le devrait, l’utilisateur novice, incapable d’utiliser l’outil aussi finement que nécessaire, en déduit que la formule qu’il a choisie n’est pas adaptée et qu’il lui faut monter en gamme, opter pour une offre plus performante, et souvent plus chère.

De plus, dans certains cas, cela peut amener le développeur à conclure que PostgreSQL, le système de gestion de base de données choisi, n’est pas adapté, le poussant ainsi à explorer d’autres solutions techniques. Cette décision pourrait entraîner une refonte du projet et, par conséquent, des coûts supplémentaires.

À la recherche des indices de performance

Pour le moment, il n’existe aucun bouton « magique » qui indiquerait la marche à suivre pour résoudre le problème de performance.

Les administrateurs de bases de données en sont donc réduits à chercher, au sein des systèmes cloud, les « traces », les indices susceptibles de les orienter vers une solution.

Cela nécessite de prendre le temps de se renseigner sur ce que propose le fournisseur cloud, d’adapter l’offre de services et les procédures de travail par rapport à un projet spécifique.

Souvent, il est nécessaire de trouver des solutions de contournement pour pouvoir accéder à l’information requise. Par exemple sur Amazon RDS, il arrive que les traces de l’instance PostgreSQL soient tronquées lors du téléchargement avec l’outil officiel ; si l’on désire obtenir les traces complètes, il faut passer par une API moins documentée exploitée par des scripts disponibles sur Github par exemple.

Gérer les traces de manière adéquate signifie aussi parfois de souscrire à des services supplémentaires, ce qui se traduit inévitablement en coûts supplémentaires. C’est ici que rentre en jeu un nouveau type de métier : le « FinOps », pour maitriser et optimiser les dépenses.

Une fois les indices analysés, dans le cas de requêtes mal optimisées, il est possible de procéder à des réécritures, à de la création d’index, au changement de certaines configurations de l’instance (lorsque le fournisseur le permet). Ces aménagements permettent souvent à l’instance d’encaisser une charge supplémentaire sans passer sur la gamme supérieure.

Solution de facilité, les bases de données proposées par les fournisseurs cloud n’offrent pas une solution parfaite pour tous les environnements de production, tous les applicatifs.

La source des problèmes de performance de certaines requêtes peut être difficile à identifier et à solutionner. Se renseigner en amont du choix d’un fournisseur cloud est un prérequis essentiel, et il est toujours possible de se faire accompagner dans l’analyse avancée de l’instance quand les problèmes de performance ont un impact trop important sur l’expérience utilisateur, mais aussi en avance de phases dans une optique d’investigation et optimisation continue.

À LIRE AUSSI :