Photo de Rob Wicks sur Unsplash
Préambule
Les éditions BigQuery ont introduit de nouveaux modèles tarifaires et apporté des évolutions notables aux modèles existants.
Chez DoiT, nous accompagnons de nombreux clients dans la conception d'architectures solides, l'exploitation efficace des services cloud et l'optimisation de leurs coûts. À la suite des évolutions de BigQuery, plusieurs clients nous ont sollicités pour réduire leurs coûts de calcul et envisager le passage de l'édition On-Demand vers le nouveau modèle tarifaire Standard Edition.
Cet article vous guide à travers les étapes permettant de déterminer si une telle transition est financièrement intéressante, et la manière de la mettre en œuvre puis de la suivre.
Le code SQL référencé dans cet article requiert l'accès aux vues INFORMATION_SCHEMA suivantes : JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECT.
Prérequis pour l'accès aux tables : roles/bigquery.resourceViewer (au niveau du projet)
L'essentiel de la réservation Standard Edition
La Standard Edition, une offre basée sur le calcul (heures de slots), se distingue des autres options tarifaires basées sur le calcul car elle s'applique au niveau du projet (comme l'édition On-Demand) plutôt qu'au niveau de l'organisation.
Son principal atout : l'accès à l'autoscaling à faible coût et sans engagement. BigQuery ajuste dynamiquement vos slots en fonction de la hausse ou de la baisse de vos workloads. (Introduction to slots autoscaling)
Les principales différences entre On-Demand et Standard Edition sont les suivantes :
1. Unités de tarification : On-Demand facture en fonction du volume de données scannées, tandis que la Standard Edition s'appuie sur un modèle slot/heure.
2. Disponibilité des slots : avec On-Demand, les slots sont considérés comme chauds et instantanément disponibles ; en Standard Edition, l'AutoScaler identifie d'abord la capacité de slots nécessaire avant de les attribuer aux jobs (un délai d'environ 10 secondes), ce qui impacte la latence des requêtes.
3. Slots maximum disponibles : 2 000 slots pour On-Demand, contre 1 600 pour la Standard Edition.
\[1\] Checklist des fonctionnalités et limitations standard
La première étape consiste à vérifier la compatibilité de votre projet avec la Standard Edition. Examinez attentivement la liste des fonctionnalités et assurez-vous d'en bien comprendre les capacités et les restrictions :
Une comparaison détaillée et complète est disponible ici : BigQuery editions features.
\[2\] Analyser l'utilisation des workloads
Une fois les fonctionnalités et les contraintes examinées, l'étape suivante consiste à estimer les dépenses selon que votre projet est orienté I/O ou CPU (slots). Dans la vue INFORMATION_SCHEMA.JOBS, vous pouvez récupérer ces données via total_bytes_billed (I/O) et total_slot_ms (CPU).
L'objectif est de comparer la dépense liée aux données scannées à la dépense estimée liée à l'utilisation des slots. Le calcul des coûts I/O est relativement simple : il s'agit de la somme du coût de toutes les requêtes. En revanche, l'estimation des coûts basés sur les slots est légèrement sous-évaluée car elle ne tient pas compte du comportement de l'autoscaler (taille de bucket de 100 slots et descente après une minute minimum). Nous appliquons un multiplicateur de 1,5 à l'évaluation basée sur les slots pour corriger cet écart.
Le tableau ci-dessous compare les coûts mensuels via le ratio entre le coût des slots et le coût On-Demand, indiquant la variation de coût estimée lors du passage de On-Demand à Standard Edition.
Un ratio inférieur à 100 suggère une réduction potentielle des coûts ; un ratio supérieur à 100 indique une hausse possible.
Par exemple :
Dépense mensuelle du client — On-Demand est plus coûteux
Dépense mensuelle du client — On-Demand est moins coûteux
Code pour générer le tableau ci-dessus : BigQuery OnDemand vs. SE.sql
La Standard Edition proposant moins de fonctionnalités que l'édition On-Demand, il est recommandé de rester sur On-Demand si le ratio dépasse globalement 75 %. Les économies attendues seraient en effet minimes au regard des fonctionnalités sacrifiées.
\[3\] Configuration du nombre maximum de slots
La Standard Edition ne requiert qu'un seul paramètre : le nombre maximum de slots, qui sert de plafond à l'autoscaling.
Comment déterminer la configuration adaptée ?
Il n'existe malheureusement pas de solution universelle : ce paramètre devra probablement être ajusté après la configuration initiale, en fonction de votre profil de workload et de l'arbitrage souhaité entre coût et performance.
Une façon de calculer une valeur initiale consiste à appliquer la formule suivante :
Identifiez l'heure correspondant au 90e percentile durant la période sélectionnée où l'utilisation des slots a dépassé 100 (configuration de base), puis arrondissez-la au multiple de 100 supérieur.
Configuration max basée sur l'heure P90 sur la période sélectionnée
Exemple de code pour déterminer la configuration maximale initiale : BQ SE max configuration.sql
Créer la réservation
La création d'une réservation est documentée pas à pas ici : Get started with reservations.
Sélectionnez Standard Edition, définissez le paramètre max Slots et choisissez la région ou multi-région appropriée, faute de quoi la réservation ne fonctionnera pas correctement.
\[4\] Suivi des performances et évaluation des coûts
Impact sur les performances
Pour suivre les performances de votre application, collectez des métriques telles que les temps de traitement des jobs et les temps de réponse des requêtes ad-hoc avant la migration, puis comparez-les avec les résultats post-migration. Il est judicieux d'informer les utilisateurs de BigQuery des changements à venir et de recueillir leurs retours.
Vous pouvez évaluer les performances d'un point de vue système en consultant les Administrative resource charts abordés dans la section suivante.
Bénéfices financiers
Pour évaluer la rentabilité, examinez vos dépenses via le dashboard de facturation quotidien. Sélectionnez les SKU Analysis et Standard Edition dans la section facturation.
Le tableau ci-dessous agrège, sur un intervalle d'une heure, l'allocation totale de slots ainsi que les coûts estimés. Ces informations permettent de calculer approximativement le coût réel en fonction des actions de l'autoscaler.
Exemple de code : Standard Edition cost estimation.sql
Répartition des coûts estimés par heure
\[5\] Réglages fins
Affiner les paramètres de la Standard Edition revient à ajuster la configuration maximale de slots, soit pour améliorer les performances (en augmentant le nombre de slots), soit pour réduire les dépenses (en le diminuant). L'objectif : un système équilibré, sans sous-utilisation ni sur-provisionnement des ressources.
Surveiller l'efficacité de vos workloads vous indiquera si le système est équilibré, sous-utilisé ou sur-provisionné. Pour cela, observez les Administrative resource charts ou interrogez directement les vues INFORMATION_SCHEMA.
Administrative resource charts :
Les administrateurs BigQuery suivent dans la durée l'utilisation des slots de leur organisation et la performance des jobs BigQuery. Vous trouverez ces graphiques dans la section Monitoring de la barre latérale BigQuery, qui propose plusieurs vues pour répondre à différentes questions. Pour vous familiariser avec ces fonctionnalités, consultez le guide sur les administrative resource charts.
- Analyse de l'utilisation des slots : utilisez la métrique P90 ou P99 pour examiner la relation entre l'utilisation des slots et leur allocation (qui inclut baseline + Autoscaled slots) ainsi que la durée nécessaire à la montée ou à la descente en charge.
Utilisation des slots
Le graphique ci-dessus s'appuie sur les données de la vue RESERVATION_CHANGES_BY_PROJECT, qui contient les informations relatives aux modifications de réservations.
Le tableau ci-dessous présente l'allocation des slots et la durée jusqu'au prochain changement (montée ou descente en charge). La métrique 'allocated_slots' représente le nombre de slots assignés à un instant donné jusqu'au prochain 'UPDATE', tandis qu''Estimated total slots' représente l'allocation globale sur l'ensemble de la période.
Exemple de code : Monitor BQ edition autoscaling.sql
Allocations réelles de slots avec leur durée
- Concurrence des jobs : pour identifier les goulots d'étranglement du système, consultez la métrique pending jobs.
Jobs en attente
- Performance des jobs : surveillez les jobs présentant une latence élevée à l'aide de la mesure du 90e percentile (P90).
Latence des jobs
Synthèse et recommandation
En présence de pics ou de bursts, d'autres approches peuvent s'avérer plus pertinentes et nécessiter une analyse approfondie. Les outils présentés apportent néanmoins des éclairages précieux tout au long de la démarche.
La transition dépend principalement du type d'usage des projets concernés : orientés I/O (rendant On-Demand plus coûteux) ou orientés CPU (rendant la Standard Edition plus coûteuse).
Google recommande principalement la Standard Edition pour les projets de recherche et développement, en précisant : Par exemple, la Standard Edition est idéale pour les workloads ad-hoc, de développement et de test.
La notion de workload de production variant d'un client à l'autre, certains pourront envisager la Standard Edition même pour des workloads ETL/ELT en production. Cela reste acceptable si les limites de l'édition sont respectées (en particulier le SLA de 99,9 %), si la charge demeure stable dans le temps et si aucun utilisateur final ne s'inquiète de la latence des requêtes.
Maintenant que cette démarche vous est familière, testez-la et faites-nous part de vos retours.