BigQuery Autoscaling en Public Preview : le décryptage DoiT

Voici un rappel rapide des termes employés tout au long de cet article. Si vous connaissez déjà BigQuery, la plupart vous seront familiers ; sinon, voici un petit coup de pouce avant de poursuivre.

• Job Un job est une action exécutée sur BigQuery pour réaliser un travail : requête, chargement de données, copie de données, etc. Le type de job le plus courant est la requête, et les deux termes sont souvent utilisés indifféremment.
• Slot L'unité de calcul de base utilisée par BigQuery pour exécuter un job. Voyez-le comme une mini machine virtuelle qui s'associe à de nombreuses autres pour réaliser le travail effectif d'un job.
• Reservation Une construction qui réserve un ensemble de slots destinés à être utilisés par zéro ou plusieurs projets qui y sont rattachés.
• Commitment Un nombre fixe de slots réservés pour une durée d'engagement déterminée — généralement un mois ou un an — en échange d'un tarif réduit.
• Admin Project Un projet désigné comme gestionnaire des reservations et commitments BigQuery. En général, une organisation en possède un seul (ou quelques-uns) afin de disposer d'un point de gestion unique pour ses ressources BigQuery. Pour les projets en flat-rate et en autoscaling, les SKU de facturation des reservations à l'échelle de l'organisation seront associés à ce projet.
• Flex Slots Slots pouvant être ajoutés à une reservation pour une montée en charge ponctuelle. À noter : ils sont facturés à la seconde, avec une période minimale de facturation de 60 secondes.
• Idle Slot Un slot qui n'est pas utilisé par un job à un instant donné.
• Workloads Un workload est un ensemble de jobs exécutés au sein d'un même projet.
• Slot/heure L'unité de facturation de base pour les projets BigQuery Autoscaling. Elle correspond à un slot utilisé par un job pendant une heure.
• Autoscaling Slots Nouvelle construction qui ajuste à la hausse le nombre de slots, depuis une valeur de base (Baseline Slots) jusqu'à un maximum, en fonction des besoins du workload en cours d'exécution.
• Baseline Slots Le nombre minimal de slots maintenus à chaud et actifs dans un projet BigQuery Autoscaling. Ce sont eux qui sont sollicités en premier avant que l'autoscaling ne se déclenche, et ils sont facturés tant que la reservation est active.

Google vient de placer en public preview une fonctionnalité longtemps attendue : l'autoscaling des slots BigQuery, pour les workloads dont les besoins en slots dépassent la capacité achetée.

En résumé, BigQuery peut désormais ajuster automatiquement le nombre de slots nécessaires aux workloads, sans intervention manuelle — par exemple sans Cloud Function chargée de redimensionner une reservation Flex Slots dès que certains seuils d'utilisation sont atteints.

Le modèle de facturation de BigQuery existe depuis plus de dix ans et repose essentiellement sur deux logiques — payer les données analysées et payer la capacité — qui s'accordent mal avec l'autoscaling de la capacité de calcul. Pour répondre à ce besoin, Google a introduit, avec cette nouvelle fonctionnalité, un modèle de facturation plus moderne, fondé sur l'approche payez ce que vous consommez.

Cette fonctionnalité fait exactement ce que son nom indique : l'autoscaling des slots. Autrement dit, lorsqu'un workload a besoin de slots supplémentaires, BigQuery ajuste désormais à la hausse ou à la baisse le nombre de slots au sein de la reservation, en fonction des jobs en cours d'exécution.

S'y ajoute, comme indiqué plus haut, un nouveau modèle de facturation reposant sur une notion appelée slot/heure : le prix d'utilisation d'un slot pendant une heure, facturé à la seconde.

* À noter : ce changement n'affecte que la partie compute/analyse de BigQuery, pas les coûts de stockage. Le stockage n'est en rien concerné par ces évolutions. Gardez-le à l'esprit en lisant la suite de cet article.

C'est extrêmement puissant si vous utilisez actuellement la facturation flat-rate et que vos besoins dépassent les slots réservés. Les Flex Slots permettaient d'obtenir des slots supplémentaires, mais sans automatisation : il fallait un outillage additionnel, généralement une Cloud Function s'exécutant à intervalles réguliers, qui vérifiait la métrique des slots utilisés et ajoutait ou retirait des Flex Slots à une reservation selon les besoins. Vous trouverez un bon exemple ici (sans affiliation avec DoiT). Malheureusement, si vous aviez besoin de slots supplémentaires immédiatement, c'était peine perdue — sauf à construire et financer une infrastructure additionnelle pour le faire.

Avant d'aller plus loin, notez que ce nouveau modèle de facturation peut être appliqué à une seule reservation, qui peut contenir zéro ou plusieurs projets. Vous pouvez donc panacher on-demand, flat-rate et autoscaling à votre guise, à travers reservations et projets, pour optimiser usage ou coûts.

En pratique, lorsqu'un projet a une valeur de baseline définie, tous les jobs commencent par utiliser ses baseline slots, puis le scaling démarre une fois ces slots épuisés. À noter qu'il s'agit d'un pool partagé entre tous les jobs des projets d'une même reservation — exactement comme dans une reservation flat-rate. Une fois qu'ils ne sont plus utilisés, les slots sont relâchés et ne sont donc plus facturés : c'est précisément ce qui les distingue des Flex Slots, lesquels sont facturés tant qu'ils ne sont pas retirés.

Cela dit, il existe une fenêtre de 60 secondes pendant laquelle BigQuery décide comment ajuster la capacité. Cela évite que des requêtes de courte durée ne déclenchent une montée jusqu'au maximum de slots et n'entraînent une surfacturation pour des slots qui n'étaient pas nécessaires.

Comme BIEN trop souvent dans le monde du cloud, la réponse est : ça dépend. Réponse frustrante, alors plongeons dans quelques scénarios où ce nouveau modèle d'autoscaling se révèle idéal :

Imaginons un workload exécuté quelques fois par jour seulement, sur une courte durée, mais qui mobilise un nombre considérable de slots (de l'ordre du millier, voire plus). Les Flex Slots peuvent convenir, mais ce job s'exécute souvent en moins d'une minute : vous payez alors la période minimale de 60 secondes des Flex Slots alors qu'ils ne sont pas utilisés sur l'ensemble de cette durée.

Et si vous avez des workloads qui consomment énormément de slots (au-delà de 2 000, soit le plafond on-demand) et qui sont très orientés lecture — ce qui rend la facturation on-demand peu rentable — alors c'est le candidat parfait pour l'Autoscaling. De plus, ces workloads sont souvent déclenchés par une action client, sans laisser le temps de créer une reservation Flex Slots pour les exécuter.

Enfin, si vos workloads sont très irréguliers, vous pouvez comparer leur consommation de slots à votre configuration actuelle dans notre calculateur BigQuery Autoscaling Slots pour voir si ce modèle est mieux adapté.

Sous ce nouveau modèle d'autoscaling, les reservations restent globalement similaires à celles utilisées en facturation flat-rate, mais elles introduisent quelques nouveaux concepts ainsi que certaines différences.

Elles sont toujours créées dans un projet de gestion, et chaque reservation contient zéro ou plusieurs projets auxquels les slots sont alloués.

Comme la notion de scaling est nouvelle, il existe désormais une valeur minimale, appelée Baseline Slots, et une valeur maximale, appelée maximum reservation size ou max slots.

La valeur max slots correspond à la somme de la valeur Baseline Slots et du nombre de slots autoscalés définis pour l'ensemble de la reservation.

Par défaut, si un job — ou un ensemble de jobs — dépasse le maximum d'autoscaling de sa reservation, il peut emprunter des slots à d'autres reservations rattachées au même projet de gestion. Une case à cocher intitulée Ignore idle slots permet de désactiver cette fonctionnalité dans l'écran Create Reservation :

La tarification est complètement différente des modèles traditionnels que BigQuery propose depuis un certain temps. Le nouveau modèle repose sur une notion appelée slot/heure : un coût par slot pour une heure d'utilisation, facturé à la seconde.

L'Autoscaling facture votre usage en fonction de la durée pendant laquelle vous utilisez un slot. La facturation se fait à la seconde, mais l'heure sert d'unité de référence pour arrondir les chiffres. Ainsi, si vous utilisez un slot pendant 900 secondes (un quart d'heure), vous serez facturé 0,25 slot/heure. Pour 3 600 secondes (une heure), ce sera 1,0 slot/heure. En général, vous utiliserez plus d'un slot pour un job : il suffit donc de multiplier par le nombre de slots utilisés pour connaître le total des slot/heures facturés.

L'élément manquant pour calculer le prix est le coût par slot/heure, fixé à 0,06 USD par slot/heure pour la public preview. À noter que ce tarif peut évoluer puisque la fonctionnalité est en preview.

La formule générale pour déterminer le coût d'un job est donc :

Prix = 0,06 * (<Slots utilisés> * (<Secondes utilisées>/3600))

Pas la formule la plus lisible, mais en substance vous multipliez le nombre de slots utilisés par les heures d'utilisation (secondes utilisées / 3 600 secondes). Cela paraît plus compliqué que ça ne l'est.

C'est pourquoi nous avons créé un calculateur pour vous faciliter l'estimation et la comparaison des tarifs. À noter qu'il est en lecture seule : commencez par en faire une copie dans votre Workspace pour une utilisation optimale.

Comme il s'agit d'une nouvelle fonctionnalité de Google, de nouveaux SKU de tarification l'accompagnent, afin que vous puissiez suivre vos dépenses dans la DoiT Console (anciennement Cloud Management Platform ou CMP).

Les coûts en slot/heure sont couverts par un SKU dont le nom ressemble à :

BigQuery Autoscale Preview for US (multi-region)

L'identifiant de ce SKU est : B8BE-01DC-0ECF

Les commits annuels (détaillés plus bas) sont couverts par un SKU dont le nom ressemble à :

BigQuery Autoscale Preview 1 Year for US (multi-region)

L'identifiant est : C0F6–38AB-6629

La région ou multi-region varie selon le SKU, mais le format reste identique pour toutes les régions.

Comme dans la tarification flat-rate, l'Autoscaling propose une fonctionnalité de commitment : vous vous engagez à utiliser un nombre défini de slots, par tranches de 100, sur une durée déterminée, en échange d'un tarif réduit. Le fonctionnement est identique à un commitment flat-rate, à ceci près que l'Autoscaling n'autorise que les engagements annuels. Ils sont définis par région ou par multi-region, comme pour les commitments flat-rate : vous devez les utiliser dans la région ou multi-region d'achat pour bénéficier des économies.

*À noter : lorsque vous souscrivez un commitment, l'intégralité de sa valeur vous est facturée, comme pour un commitment flat-rate. La logique de facturation est strictement identique.

Le tarif d'un commitment annuel est de 0,05 USD par slot/heure, par tranches de 100 slots. Cela représente environ 3 504 USD par mois pour 100 slots, contre environ 4 380 USD par mois pour 100 slots utilisés sur un mois entier (sur la base de 730 heures par mois) sans commitment.

La méthode la plus simple pour passer de la facturation flat-rate à l'Autoscaling consiste tout bonnement à modifier la reservation de flat-rate vers Autoscaling. Google a rendu cette bascule très simple : aucune suppression ni recréation de reservation n'est nécessaire.

Passer de l'on-demand à l'Autoscaling (ou au flat-rate) demande un peu plus de travail. Je recommande vivement de lire la documentation Google sur le sujet ici avant de basculer, puis de suivre la procédure de création d'une reservation en sélectionnant Autoscaling au lieu de flat-rate dans le menu.

Cette question revient souvent car beaucoup d'utilisateurs de BigQuery n'en ont aucune idée. Pas d'inquiétude : on s'en occupe !

Dans une précédente série d'articles consacrée à l'optimisation des coûts BigQuery, j'ai publié un ensemble de requêtes BigQuery dans un repository GitHub, comprenant plusieurs requêtes pour vous aider sur ce point. Avant d'exécuter quoi que ce soit dans ce repository, surveillez le volume de données analysées : ces requêtes peuvent traiter de très grandes quantités de données (> 2 To sur certains de nos jeux de données internes).

Le sujet est très vaste et dépasse largement le cadre de cet article, mais je recommande d'exécuter les requêtes suivantes :

• Slots by Minute Cette requête crée une série temporelle sur la période donnée et indique le nombre de slots utilisés à chaque minute.
• Top Complex Queries Cette requête retourne les requêtes les plus complexes (au sens du plus grand nombre de slots utilisés) sur la période spécifiée.
• Job Information Cette requête retourne des statistiques pour un Job ID, dont les informations relatives aux slots. Très utile lorsque vous identifiez un job qui rencontre des problèmes de performance et souhaitez vérifier s'il aurait besoin de slots supplémentaires pour s'exécuter plus vite.