Optimiser l’allocation des ressources de calcul pour atteindre des objectifs de performance tout en contrôlant les coûts peut être un équilibre difficile à trouver, en particulier pour les charges de travail de base de données avec des modèles d’utilisation complexes. Pour aider à relever ces défis, nous sommes heureux d’annoncer la préversion d’Azure SQL Database serverless. SQL Database serverless (préversion) est un nouveau niveau de calcul qui optimise les performances et les coûts et simplifie la gestion des performances des bases de données à utilisation intermittente et imprévisible. Les applications métiers, les bases de données de développement/test, la gestion de contenu et les systèmes de e-commerce ne sont que quelques exemples parmi une gamme d’applications qui correspondent souvent au modèle d’utilisation idéal pour SQL Database serverless. L’offre SQL Database serverless convient également aux nouvelles applications avec une incertitude liée au dimensionnement ou aux charges de travail nécessitant un mise à l’échelle fréquente afin de réduire les coûts. Le niveau de calcul serverless bénéficie de tous les avantages de l’offre SQL Database complètement managée et intégrant des fonctionnalités d’intelligence intégrées. De plus, il contribue à accélérer le développement d’applications, à réduire au minimum la complexité opérationnelle et à baisser les coûts totaux.

Mise à l’échelle automatique du calcul

L’offre SQL Database serverless met automatiquement à l’échelle le calcul pour les bases de données uniques en fonction de la demande de charge de travail et facture le calcul utilisé par seconde. Le niveau Serverless contraste avec le niveau de calcul provisionné dans SQL Database, qui alloue un montant fixe de ressources de calcul à un prix fixe et qui est facturé à l’heure. Sur une courte période, les bases de données de calcul provisionnées doivent soit surprovisionner les ressources à un certain coût afin de prendre en charge les pics d’utilisation, soit sous-provisionner les ressources et risquer des performances médiocres. Sur des périodes plus longues, les bases de données de calcul provisionnées peuvent être remise à l’échelle, mais cette solution peut nécessiter la prédiction de modèles d’utilisation ou l’écriture d’une logique personnalisée pour déclencher des opérations de remise à l’échelle en fonction d’un calendrier ou des métriques de performance. Cela ajoute à la complexité opérationnelle et de développement. Dans le niveau serverless, la mise à l’échelle du calcul dans des limites configurables est gérée par le service afin de dimensionner correctement et en continu les ressources. Le niveau serverless offre également une option permettant de mettre automatiquement la base de données en pause pendant les périodes d’utilisation inactives et de reprendre son fonctionnement quand l’activité reprend.

Payez uniquement le calcul utilisé

Dans SQL Database serverless, le calcul est facturé uniquement en fonction de la quantité de CPU et de mémoire utilisée par seconde.  Tant que la base de données est en pause, seul le stockage est facturé, ce qui offre un avantage supplémentaire en termes d’optimisation des coûts.

Prenons l’exemple d’une application métier ou d’une base de données de développement/test qui est en veille la nuit, mais qui nécessite une marge de sécurité en termes de bursting multi-cœurs tout au long de la journée. Supposons que l’application utilise une base de données serverless configurée pour permettre la mise en pause et la mise à l’échelle automatiques jusqu’à 4 vCores et présente le modèle d’utilisation suivant sur une période de 24 heures :

Comme vous pouvez le constater, l’utilisation de la base de données correspond à la quantité de calcul facturée qui est mesurée en unités de secondes vCore et s’élève à environ 46 000 secondes vCore sur une période de 24 heures. Supposons que le prix unitaire du calcul pour la base de données serverless est d’environ 0,000073 $/vCore/seconde. Par conséquent, la facture de calcul pour cette période d’un jour a un montant d’un peu moins de 3,40 $. Ce montant s’obtient en multipliant le prix unitaire du calcul par le nombre total de secondes vCore accumulées. Au cours de cette période, la base de données a été mise en pause automatiquement lorsqu’elle était inactive et a bénéficié d’épisodes de bursting jusqu’à 80 % sur 4 vCores sans intervention du client. Dans cet exemple, les économies réalisées en mode serverless sont significatives par rapport à une base de données de calcul provisionnée configurée avec la même limite de 4 vCores.  

Notez que les prix font l’objet d’une remise pendant la préversion. Dans cet exemple, les prix sont basés sur la région USA Est en mai 2019 et sont susceptibles de changer. Pour connaître les tarifs les plus récents, consultez la page de tarification Azure SQL Database..

Compromis coûts/performances

Lorsque vous utilisez SQL Database serverless, vous devez prendre en compte des compromis coûts/performances. Ces compromis sont liés au prix unitaire de calcul et à l’impact sur les performances de l’application du fait du préchauffage du calcul après des périodes à faible utilisation ou inactives.

Prix de l’unité de calcul

Le prix de l’unité de calcul est plus élevé pour une base de données serverless que pour une base de calcul provisionnée, car le serverless est optimisé pour les charges de travail avec des modèles d’utilisation intermittente. Si l’utilisation du processeur ou de la mémoire est suffisamment élevée et maintenue suffisamment longtemps, le niveau de calcul provisionné peut être moins onéreux.

Préchauffement du calcul après une faible utilisation

Lorsqu’une base de données serverless est en ligne, la mémoire est progressivement récupérée si l’utilisation du processeur ou de la mémoire est suffisamment basse pendant une durée suffisante. Lorsque l’activité de la charge de travail est rétablie, il peut que des E/S de disque soient nécessaires pour réhydrater les pages de données dans le pool de mémoires tampons SQL ou qu’une recompilation des plans de requête soit requise. Cette stratégie de gestion de la mémoire permettant de récupérer le cache en fonction d’une utilisation faible est propre à SQL Database serverless. Elle est par ailleurs conçue pour contrôler les coûts des clients, mais peut avoir un impact sur les performances. La récupération de mémoire basée sur une utilisation faible ne se produit pas dans le niveau de calcul provisionné pour des bases de données uniques ou les pools élastiques où ce type d’impact peut être évité.

Préchauffement du calcul après une pause

La latence nécessaire pour mettre en pause et reprendre une base de données serverless est généralement d’environ une minute ou moins, durée pendant laquelle la base de données est hors ligne. Après la reprise de la base de données, les caches de mémoire doivent être réhydratés, ce qui ajoute une latence supplémentaire avant le retour des conditions de performances optimales. La période d’inactivité qui doit s’écouler avant la mise en pause automatique peut être configurée pour compenser cet impact sur les performances. La mise en pause automatique peut également être désactivée pour les charges de travail sensibles à cet impact tout en tirant des avantages de la mise à l’échelle automatique. Les minimums de calcul sont facturés pendant que la base de données est en ligne, quelle que soit l’utilisation. Une désactivation de la pause automatique peut donc augmenter les coûts.

En savoir plus

Azure SQL Database serverless est pris en charge dans le niveau Usage général pour des bases de données uniques.

• En savoir plus sur l’option Azure SQL Database serverless (préversion)
• En savoir plus sur la tarification Azure SQL Database pour le niveau de calcul serverless (préversion).