Tester les Editions BigQuery sans engagement

Souscrire des engagements basés sur des estimations sans période de test est l’erreur la plus fréquente lors de l’évaluation des Editions BigQuery. Les engagements bloquent les nombres de slots pour un ou trois ans — une erreur de 30 % est coûteuse et ne peut pas être annulée. Tester les Editions avant de s’engager n’entraîne aucune contrainte financière au-delà des slot-heures consommées pendant le test, et le retour en arrière prend environ 60 secondes.

Chemin de test sans engagement

Standard Edition offre un environnement de test adapté : base à zéro, un maximum d’autoscaling modeste, et aucun engagement financier au-delà du tarif Standard PAYG de 0,04 $/slot-heure pour les slots consommés pendant le test.

Créez une réservation de test et affectez-lui un projet de test :

-- Create autoscaling-only reservation for testing
CREATE RESERVATION `my-project.region-us.test-reservation`
OPTIONS (
  edition = 'STANDARD',
  slot_capacity = 0,
  autoscale_max_slots = 200
);

-- Create assignment linking test project to reservation
CREATE ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`
OPTIONS (
  assignee = 'projects/my-test-project',
  job_type = 'QUERY'
);

Une fois l’affectation activée — généralement en moins de 5 minutes — les requêtes de my-test-project passent par la réservation plutôt que par la tarification à la demande. Attendez la propagation avant d’exécuter des tests ; les requêtes soumises pendant la fenêtre d’activation peuvent revenir à la facturation à la demande et ne reflèteront pas fidèlement le comportement des Editions.

Exécutez des charges représentatives pendant 2 à 4 semaines. La période de test doit couvrir vos patterns de charge réels, pas seulement un échantillon. Si votre ETL tourne chaque nuit et que vos rapports de fin de mois génèrent un pic à 3×, votre test doit capturer les deux.

Le retour en arrière est instantané

Supprimez l’affectation et le projet revient immédiatement à la tarification à la demande :

DROP ASSIGNMENT `my-project.region-us.test-reservation.test-assignment`;

Le changement prend effet en quelques minutes. Il n’y a aucune pénalité, aucune période de refroidissement, aucune démarche administrative. Le seul coût est celui des slot-heures consommées pendant le test, facturées aux tarifs Standard Edition paiement à l’usage.

Forcer la tarification à la demande pour des projets spécifiques

Si une organisation parente dispose de réservations Editions mais qu’un projet spécifique nécessite la tarification à la demande — pour l’allocation des coûts, l’isolation des charges ou des besoins de test — affectez-le à la réservation spéciale none :

CREATE ASSIGNMENT `my-project.region-us.reservations/none.explicit-ondemand`
OPTIONS (
  assignee = 'projects/exempt-project',
  job_type = 'QUERY'
);

Cela exclut explicitement le projet de toute réservation organisationnelle, garantissant la facturation à la demande quelle que soit la configuration au niveau parent. C’est le mécanisme de l’approche hybride : certains projets sur Editions, d’autres sur la tarification à la demande, avec un contrôle explicite sur lequel est lequel.

Le pattern de réservation none est également utile lors des migrations — vous pouvez affecter la plupart des projets aux Editions tout en maintenant des charges spécifiques en mode à la demande jusqu’à être certain qu’elles sont correctement configurées. Pas besoin de tout migrer d’un coup.

Que surveiller pendant le test

Deux requêtes à exécuter tout au long de la période de test :

Comparer les coûts par rapport à l’équivalent à la demande :

WITH cost_analysis AS (
  SELECT
    DATE_TRUNC(creation_time, MONTH) AS month,
    SUM(total_bytes_billed) / POW(1024, 4) * 6.25 AS on_demand_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.04 * 1.5 AS standard_edition_cost,
    SUM(total_slot_ms) / 1000 / 3600 * 0.06 * 1.5 AS enterprise_edition_cost
  FROM `region-us`.INFORMATION_SCHEMA.JOBS
  WHERE
    creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
  GROUP BY month
)
SELECT
  month,
  ROUND(on_demand_cost, 2) AS on_demand_usd,
  ROUND(standard_edition_cost, 2) AS standard_usd,
  ROUND(enterprise_edition_cost, 2) AS enterprise_usd,
  ROUND(enterprise_edition_cost / NULLIF(on_demand_cost, 0) * 100, 1) AS editions_pct_of_ondemand
FROM cost_analysis
ORDER BY month DESC;

Interprétez editions_pct_of_ondemand : au-dessus de 75 %, la tarification à la demande est plus rentable. En dessous de 50 %, les Editions méritent sérieusement un engagement. Entre 50 et 75 %, tenez compte des besoins en concurrence, de la prévisibilité des coûts et des exigences fonctionnelles.

Surveiller la contention de slots (requêtes en attente de capacité) :

SELECT
  job_id,
  user_email,
  ROUND(COUNTIF(period_estimated_runnable_units > 0) / COUNT(*) * 100, 1) AS contention_pct,
  MAX(period_estimated_runnable_units) AS max_queued_units,
  ROUND(SUM(period_slot_ms) / 1000 / 3600, 3) AS slot_hours
FROM `region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
WHERE job_creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
GROUP BY job_id, user_email
HAVING contention_pct > 50
ORDER BY contention_pct DESC
LIMIT 20;

Un contention_pct élevé indique que les requêtes passent un temps significatif à attendre des slots — signal que votre maximum est sous-dimensionné. Si la contention dépasse constamment 30 %, augmentez le maximum d’autoscaling avant de tirer des conclusions sur le fonctionnement de la configuration.

Utiliser le BigQuery Slot Estimator

La console BigQuery inclut un Slot Estimator (Capacity Management → Slot Estimator) qui modélise l’impact de différentes configurations de slots maximum sur les performances des charges historiques. Il affiche les coûts estimés et l’impact sur les performances en se basant sur l’historique réel de vos requêtes, sans nécessiter d’essais et erreurs.

Saisissez votre nombre maximum de slots souhaité et le niveau d’engagement. L’estimateur indique :

• La fréquence à laquelle votre charge aurait atteint le plafond
• Les percentiles de latence projetés (P50, P90, P99) sous cette configuration
• Le coût à différents niveaux d’engagement

L’estimateur utilise 30 jours d’historique de jobs. Utilisez-le pour valider les besoins en slots avant de configurer une réservation de test, puis à nouveau après le test pour croiser les résultats observés.

Décider de s’engager

Après 30 jours ou plus de test, vous disposez de trois sources de données :

1. La requête de comparaison des coûts montrant le coût réel des Editions par rapport à l’équivalent à la demande
2. La requête d’histogramme de slots montrant votre distribution P50/P75/P90/P99 (voir Surveillance de l’utilisation des slots BigQuery)
3. La requête de contention montrant si votre max_slots de test était suffisant

Si les trois signalent que les Editions permettent des économies et que votre max_slots a géré la demande sans contention excessive, vous êtes prêt à vous engager. Dimensionnez votre engagement à 60 à 80 % du P50 pour la base (l’état stable sur lequel vous pouvez compter), réglez votre maximum au P90, et laissez l’autoscaling gérer le reste. La remise d’engagement sur les slots de base prévisibles plus le paiement à l’usage pour les pics bat souvent un engagement sur la pleine capacité de pointe.

Dimensionnez l’engagement sur la base, pas sur le maximum. L’autoscaling gère les pics au-delà de la base engagée.