Comprendre la fiabilité

BigQuery vous permet d'exécuter des charges de travail d'analyse avec un minimum d'interruption en gérant automatiquement les défaillances de machines et de zones dans une région. Pour une résilience plus étendue, vous pouvez configurer la reprise après sinistre interrégionale, restaurer des données supprimées ou corrompues, et implémenter des nouvelles tentatives d'erreur côté client pour répondre à vos exigences de fiabilité.

Ces fonctionnalités sont compatibles avec les charges de travail qui ingèrent et analysent de grands volumes de données avec des performances constantes, y compris la détection d'anomalies, l'analyse en temps réel avec l'ingestion en flux continu et l'analyse prédictive avec BigQuery ML. Pour obtenir des exemples détaillés de ces solutions, consultez Modèles de référence BigQuery.

Dimensions de fiabilité dans BigQuery

Pour déterminer si BigQuery répond aux exigences de votre charge de travail, vous pouvez évaluer sa fiabilité selon cinq dimensions clés : la disponibilité, la durabilité, la cohérence des données, la cohérence des performances et la récupération des données.

Disponibilité

La disponibilité définit votre capacité à lire des données depuis BigQuery ou à y écrire des données. BigQuery est conçu pour rendre les opérations de lecture et d'écriture disponibilité élevée avec un contrat de niveau de service garantissant une disponibilité de 99,99 %. Deux composants sont impliquées dans les deux opérations :

  • Le service BigQuery
  • Les ressources de calcul nécessaires pour exécuter la requête spécifique

La fiabilité du service est une fonction de l'API BigQuery spécifique que vous utilisez pour récupérer les données. La disponibilité des ressources de calcul dépend de la capacité dont vous disposez lorsque vous exécutez la requête. Pour en savoir plus sur l'unité de calcul fondamentale de BigQuery et sur l'économie des ressources d'emplacements, consultez Comprendre les emplacements.

Durabilité

La durabilité mesure la proportion de données que vous pouvez lire, comme défini dans le chapitre Mettre en œuvre des SLO du Classeur d'ingénierie de la fiabilité des sites. Pour assurer une durabilité élevée, BigQuery stocke automatiquement des copies redondantes de vos données dans deux zones de l'emplacement sélectionné.

Cohérence des données

La cohérence des données définit comment et quand vous pouvez interroger des données après leur écriture ou leur modification. Un aspect de la cohérence des données consiste à garantir une sémantique de type "exactement une fois" pour l'ingestion des données. Pour en savoir plus, consultez Réessayer les insertions de jobs ayant échoué.

Cohérence des performances

En général, les performances peuvent être exprimées en deux dimensions. La latence est une mesure du temps d'exécution des longues opérations de récupération de données, telles que les requêtes. Le débit est une mesure de la quantité de données que BigQuery peut traiter au cours d'une période spécifique. Grâce à la conception mutualisée et évolutive horizontalement de BigQuery, le débit peut s'adapter à des tailles de données arbitraires. Votre cas d'utilisation spécifique détermine l'importance relative de la latence et du débit.

Récupération de données

Vous pouvez mesurer la capacité à récupérer des données après une panne à l'aide des métriques suivantes :

  • Objectif de temps de récupération (RTO) : durée maximale pendant laquelle les données peuvent être indisponibles après un incident.
  • Objectif de point de reprise (RPO) : quantité maximale de données collectées avant l'incident que votre organisation peut tolérer de perdre.

Ces considérations sont particulièrement pertinentes dans le cas peu probable où une zone ou une région subit une panne durant plusieurs jours ou une panne destructive.

Planification de reprise après sinistre

Dans cette section, la planification de la reprise après sinistre couvre les défaillances allant de la perte d'une seule machine à la perte catastrophique d'une région entière. BigQuery gère automatiquement les défaillances de machines uniques et de zones, tandis que les défaillances régionales nécessitent que vous conceviez votre architecture pour la récupération si votre charge de travail l'exige. Il est essentiel de comprendre où s'arrête la récupération automatique et où commence votre responsabilité pour planifier la reprise après sinistre.

BigQuery offre un contrat de niveau de service garantissant une disponibilité de 99,99 %. Cette disponibilité est assurée par l'architecture régionale de BigQuery, qui écrit les données dans deux zones différentes et provisionne une capacité de calcul redondante. Le contrat de niveau de service BigQuery est identique pour les régions (telles que us-central1) et les emplacements multirégionaux (tels que US).

Gestion automatique des échecs

Comme BigQuery est un service régional, il gère automatiquement la perte d'une machine individuelle ou d'une zone entière. BigQuery fait abstraction de l'infrastructure zonale sous-jacente.

Perte d'une machine

Les défaillances des machines sont une occurrence quotidienne à l'échelle de laquelle Google opère. BigQuery est conçu pour gérer automatiquement les défaillances de machine sans aucun impact sur la zone conteneur.

BigQuery divise chaque requête en petites tâches et les distribue en parallèle sur de nombreuses machines. En cas de défaillance ou de dégradation d'une machine, BigQuery redistribue automatiquement les tâches concernées à une autre machine. Une telle approche est essentielle pour réduire la latence de queue.

BigQuery utilise l'encodage Reed-Solomon pour stocker de manière durable une copie zonale de vos données, et stocke au moins une copie zonale supplémentaire dans une autre zone. Si plusieurs défaillances de machine entraînent la perte d'une copie zonale, BigQuery détecte la perte et crée une copie zonale pour restaurer la redondance.

Perte d'une zone

Pour respecter son contrat de niveau de service garantissant une disponibilité de 99,99 %, BigQuery fournit une redondance zonale automatique pour les emplacements de données et de calcul. Étant donné que la disponibilité du calcul dans une seule zone ne peut pas respecter ce SLA à elle seule, BigQuery achemine automatiquement les nouvelles requêtes vers une autre zone dans la minute qui suit une interruption majeure de la zone. L'exécution des requêtes en cours peut prendre plus de temps, tandis que les nouvelles requêtes se terminent normalement dans une autre zone.

Même si une zone reste indisponible pendant une période prolongée, aucune perte de données ne se produit, car BigQuery écrit des données de manière synchrone sur deux zones. Par conséquent, une indisponibilité de zone n'affecte pas votre service.

Types de défaillances

Il existe deux types d'échecs : les échecs légers et les échecs graves.

Les défaillances temporaires sont des anomalies opérationnelles où le matériel n'est pas détruit. Il s'agit par exemple d'une panne de courant, d'une partition réseau ou du plantage d'une machine. BigQuery est conçu pour éviter la perte de données lors d'une défaillance logicielle.

Une défaillance permanente est une défaillance opérationnelle dans laquelle le matériel est détruit, par exemple en raison d'inondations, de tremblements de terre ou d'ouragans. La capacité de BigQuery à empêcher la perte de données lors d'une défaillance matérielle dépend de l'impact de la défaillance sur une seule zone ou sur une région entière.

Redondance des emplacements et comportement en cas de défaillance

Lorsque vous créez un ensemble de données BigQuery, vous sélectionnez l'emplacement de stockage de vos données. Cet emplacement est choisi parmi les éléments suivants :

  • Une région : emplacement géographique spécifique, par exemple l'Iowa (us-central1) ou Montréal (northamerica-northeast1).
  • Un emplacement multirégional : secteur géographique de grande étendue contenant au moins deux lieux géographiques, tel que les États-Unis (US) ou l'Europe (EU).

Dans les deux cas, BigQuery stocke automatiquement des copies de vos données dans deux zones Google CloudGoogle Cloud distinctes au sein d'une même région, dans l'emplacement sélectionné.

En plus de la redondance de stockage, BigQuery conserve également une capacité de calcul redondante sur plusieurs zones. En combinant le stockage redondant et le calcul sur plusieurs zones de disponibilité, BigQuery offre à la fois une disponibilité et une durabilité élevées.

En cas de défaillance au niveau des machines, BigQuery continue de s'exécuter avec un décalage de quelques millisecondes maximum, et toutes les requêtes en cours d'exécution continuent d'être traitées. Lors d'une défaillance zonale logicielle ou matérielle, aucune perte de données ne se produit, même si vous devrez peut-être renvoyer les requêtes en cours d'exécution. BigQuery corrige automatiquement les défaillances zonales légères (pannes de courant, défaillances de transformateurs ou partitions réseau, par exemple) en quelques minutes.

Une défaillance régionale logicielle, telle qu'une perte de connectivité réseau à l'échelle de la région, entraîne une perte de disponibilité jusqu'à ce que la région soit de nouveau en ligne, mais n'entraîne pas de perte de données. Une défaillance régionale majeure, telle qu'un sinistre détruisant une région entière, peut entraîner la perte des données stockées dans cette région. BigQuery ne fournit pas automatiquement de sauvegarde ni d'instance répliquée de vos données dans une autre région géographique. Vous pouvez utiliser la réplication d'ensembles de données interrégionale ou la reprise après sinistre gérée pour améliorer votre résilience aux défaillances régionales graves.

Pour en savoir plus sur les emplacements des ensembles de données BigQuery, consultez Considérations relatives aux emplacements.

Scénario : perte de région

BigQuery n'offre pas de durabilité ni de disponibilité en cas de destruction d'une région physique. Cette limite s'applique aux régions et aux emplacements multirégionaux. Par conséquent, pour maintenir la durabilité et la disponibilité lors d'une panne régionale, vous devez planifier à l'avance. Si le contrat de niveau de service de 99,99 % de BigQuery ne répond pas à vos exigences de disponibilité lors d'une panne régionale temporaire, envisagez de configurer une disponibilité redondante entre les régions.

Pour éviter toute perte de données en cas de destruction d'une région, sauvegardez vos données dans un autre emplacement géographique. Par exemple, vous pouvez utiliser la réplication d'ensemble de données interrégionale pour répliquer en continu vos données dans une région géographiquement distincte.

Si vous utilisez un emplacement multirégional BigQuery, ne sauvegardez pas les données dans une seule région de la zone géographique de cet emplacement multirégional. Par exemple, si vous sauvegardez des données à partir de l'emplacement multirégional US, évitez de choisir une région qui se chevauche, telle que us-central1, en raison du risque de défaillance corrélée lors d'un sinistre. Pour en savoir plus sur la portée géographique des emplacements multirégionaux, consultez Emplacements multirégionaux.

Pour éviter une indisponibilité prolongée, répliquez vos données et provisionnez des emplacements dans deux emplacements BigQuery géographiquement distincts. Vous pouvez utiliser la reprise après sinistre gérée pour provisionner automatiquement des emplacements dans une région secondaire et contrôler le basculement de vos charges de travail d'une région à une autre.

Scénario : suppression accidentelle ou corruption de données

Grâce à l'architecture de contrôle de simultanéité multiversion de BigQuery, BigQuery est compatible avec les fonctionnalités temporelles. Avec la fonctionnalité temporelle, vous pouvez interroger les données à tout moment au cours des sept derniers jours. Cette fonctionnalité vous permet de restaurer les données qui ont été supprimées par erreur, modifiées ou corrompues au cours d'une période de sept jours. Les fonctionnalités temporelles sont disponibles sur les tables supprimées.

BigQuery vous permet également de créer des instantanés de table pour sauvegarder les données dans la même région pendant une période de plus de sept jours. La création d'un instantané est une opération portant uniquement sur les métadonnées, qui n'entraîne pas de frais de stockage supplémentaires. Bien que les instantanés de table aident à protéger contre la suppression accidentelle, ils n'augmentent pas la durabilité des données.

Reprise après sinistre pour l'analyse en temps réel

Pour un pipeline d'analyse en temps réel qui ingère en continu les journaux de points de terminaison en flux continu dans BigQuery, la protection contre l'indisponibilité régionale étendue nécessite de répliquer en continu les données et de provisionner les emplacements dans une région secondaire. Toutefois, étant donné que l'architecture d'ingestion est déjà résiliente à l'indisponibilité temporaire de BigQuery lorsqu'elle utilise Pub/Sub et Dataflow comme l'une de ses méthodes de chargement de données, ce niveau élevé de redondance ne vaut peut-être pas le coût.

Par exemple, supposons que vous configuriez des jobs d'extraction nocturnes pour exporter des données BigQuery de us-east4 vers un stockage Archive Cloud Storage dans us-central1. Cette exportation fournit une sauvegarde durable en cas de perte de données catastrophique dans us-east4. Dans cette configuration, l'objectif de point de récupération (RPO) est de 24 heures, car la sauvegarde la plus récente peut remonter jusqu'à 24 heures. L'objectif de temps de récupération (RTO) peut atteindre plusieurs jours, car vous devez restaurer les données de la sauvegarde Cloud Storage vers BigQuery dans us-central1. Si vous provisionnez BigQuery dans une région différente de celle de vos sauvegardes, vous devez d'abord transférer les données vers cette région. Sauf si vous achetez à l'avance des emplacements redondants dans la région de récupération, le provisionnement de la capacité BigQuery requise peut prendre un certain temps en fonction de la quantité demandée.

Reprise après sinistre pour le traitement des données par lot

Pour une charge de travail de traitement de données par lot dans laquelle vous devez fournir un rapport quotidien essentiel à l'entreprise à un organisme de réglementation dans un délai fixe, la mise en œuvre de la redondance en exécutant deux instances distinctes de l'ensemble du pipeline de traitement en vaut souvent le coût. L'utilisation de deux régions distinctes, telles que us-west1 et us-east4, fournit une séparation géographique et deux domaines de défaillance indépendants en cas d'indisponibilité régionale étendue ou de perte de région permanente.

Si vous devez livrer le rapport une seule fois, vous devez rapprocher le résultat lorsque les deux pipelines se terminent correctement. Une approche consiste à sélectionner le résultat du pipeline qui se termine en premier, par exemple en publiant une notification dans un sujet Pub/Sub une fois l'opération terminée. Vous pouvez également laisser le deuxième pipeline écraser le résultat et utiliser la gestion des versions d'objets dans Cloud Storage. Si le pipeline qui se termine plus tard écrit des données corrompues, vous pouvez restaurer la version écrite par le premier pipeline à partir de Cloud Storage.

Gestion des exceptions

Les sections suivantes décrivent les bonnes pratiques à suivre pour gérer les erreurs qui affectent la fiabilité.

Réessayer les requêtes d'API en échec

Lorsque vos applications clientes, vos bibliothèques clientes ou vos outils partenaires envoient des requêtes API à BigQuery, utilisez une temporisation de retransmission exponentielle tronquée. Avec cette stratégie, si un client reçoit une erreur système ou une erreur de quota, il relance la requête un nombre maximal de fois en utilisant un intervalle d'attente aléatoire et croissant.

L'utilisation d'un intervalle exponentiel entre les tentatives tronqué rend votre application plus résiliente aux erreurs temporaires. Même dans des conditions de fonctionnement normales, vous pouvez vous attendre à un taux d'échec d'environ une requête pour 10 000,conformément au contrat de niveau de service garantissant une disponibilité à 99, 99 % pour BigQuery. Bien que ce taux d'erreur puisse augmenter en cas de conditions anormales, l'intervalle exponentiel entre les tentatives peut mitiger la plupart des échecs tant que les erreurs sont distribuées de manière aléatoire.

Si une requête échoue de manière persistante avec une erreur 5xx, contactez Cloud Customer Care et communiquez clairement l'impact sur l'activité lors de la définition de la priorité de la demande d'assistance afin que l'assistance puisse trier le problème avec précision. En revanche, si une requête échoue de manière permanente avec une erreur 4xx, vous pouvez résoudre le problème en modifiant votre application. Pour en savoir plus, consultez le message d'erreur.

Exemple de logique d'intervalle exponentiel entre les tentatives

La logique d'intervalle exponentiel entre les tentatives relance une demande ou une requête en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de l'intervalle exponentiel soit atteinte. Les étapes suivantes illustrent comment un client met en œuvre une temporisation de retransmission exponentielle tronquée :

  1. Envoyez une requête à BigQuery.

  2. Si la requête échoue, attendez 1 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  3. Si la requête échoue, attendez 2 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  4. Si la requête échoue, attendez 4 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.

  5. Répétez ce schéma en doublant le temps d'attente de base à chaque nouvelle tentative, jusqu'à atteindre le délai maximum_backoff.

  6. Continuez d'attendre et de relancer la requête jusqu'à atteindre le nombre maximal de tentatives, sans augmenter le temps d'attente au-delà de maximum_backoff.

Tenez compte des détails suivants pour ce calcul de l'intervalle d'attente :

  • Le temps d'attente est défini sur min(((2^n)+random_number_milliseconds), maximum_backoff), avec n incrémenté de 1 pour chaque itération (requête).

  • random_number_milliseconds correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cette randomisation permet d'éviter les situations où de nombreux clients se synchronisent par hasard et effectuent tous une nouvelle tentative simultanément, en envoyant des requêtes par vagues synchronisées. Recalculez random_number_milliseconds après chaque nouvelle tentative de la requête.

  • L'intervalle maximal entre les tentatives (maximum_backoff) est généralement de 32 ou 64 secondes. La valeur appropriée pour maximum_backoff dépend de votre cas d'utilisation.

Le client peut continuer à effectuer des nouvelles tentatives après avoir atteint le délai maximal entre les tentatives. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Par exemple, si le client utilise un intervalle maximal entre les tentatives de 64 secondes, une fois celui-ci atteint, il peut continuer à effectuer des nouvelles tentatives toutes les 64 secondes. Pour éviter les boucles infinies de nouvelles tentatives, configurez un nombre maximal de nouvelles tentatives afin que le client cesse d'essayer après une limite définie.

Le temps d'attente entre les nouvelles tentatives et le nombre de tentatives dépendent de votre cas d'utilisation et des conditions du réseau.

Réessayer les insertions de job en échec

Si votre application nécessite une sémantique d'insertion de type "exactement une fois", réfléchissez à la manière dont la propriété WriteDisposition de votre tâche gère les données existantes dans une table (échec, écrasement ou ajout).

Avec une disposition WRITE_EMPTY ou WRITE_TRUNCATE, vous pouvez obtenir une sémantique "au plus une fois" en retentant l'insertion ou l'exécution des jobs ayant échoué, car BigQuery écrit de manière atomique toutes les lignes qu'un job ingère dans la table.

Avec une disposition WRITE_APPEND, spécifiez un ID de job personnalisé pour qu'une nouvelle tentative n'ajoute pas de données en double. Étant donné que BigQuery rejette toute requête de création de job qui réutilise un ID de job précédent, la spécification d'un ID de job fournit une sémantique "au plus une fois" pour cet ID. Vous pouvez ensuite obtenir une sémantique de type "exactement une fois" en confirmant que toutes les tentatives précédentes ont échoué avant de réessayer avec un nouvel ID de job prévisible.

Si un problème réseau temporaire empêche votre client de recevoir la confirmation d'une insertion de job, une nouvelle tentative avec le même ID de job échoue avec status=ALREADY_EXISTS (code=409 et reason="duplicate"). Appelez jobs.get pour récupérer l'état du job existant et déterminer s'il faut créer un job avec un nouvel ID de job.

Cas d'utilisation et exigences de fiabilité

BigQuery peut être un composant essentiel de diverses architectures. En fonction du cas d'utilisation et de l'architecture que vous déployez, vous devrez peut-être répondre à différentes exigences de disponibilité, de performances et de fiabilité. Les sections suivantes examinent deux architectures courantes et leurs exigences de fiabilité.

Analyse en temps réel

Le premier exemple est un pipeline de traitement de données d'événement. Dans cette architecture, Pub/Sub ingère les événements de journaux provenant des points de terminaison, et un pipeline Dataflow de traitement en flux continu traite et écrit les données dans BigQuery à l'aide de l'API BigQuery Storage Write. Les analystes exécutent ensuite des requêtes ad hoc sur les données pour recréer des séquences d'événements, et des tableaux de bord en temps quasi réel visualisent les données pour détecter les tendances et les modèles.

Cette charge de travail nécessitant une fraîcheur des données de bout en bout élevée, une faible latence d'ingestion est essentielle. Une fois les données écrites dans BigQuery, la fiabilité dépend de deux facteurs : si les utilisateurs peuvent exécuter des requêtes ad hoc avec une latence cohérente et prévisible, et si les tableaux de bord qui utilisent les données reflètent les informations les plus récentes.

Traitement de données par lot

Le deuxième exemple est une architecture de traitement par lots basée sur les exigences de conformité réglementaire du secteur des services financiers. L'une des principales exigences est de soumettre aux autorités de régulation des rapports quotidiens et à heure fixe. Tant que le processus quotidien de traitement par lots génère ses rapports dans le délai imparti, il répond aux exigences de performances.

Le pipeline charge les données dans BigQuery et les associe à d'autres sources de données à des fins de création de tableaux de bord, d'analyse et de génération de rapports au format PDF. Il est essentiel que ces rapports soient fournis dans le délai imparti et sans erreur. Par conséquent, vous devez garantir la fiabilité lors de l'ingestion des données et générer des rapports précis dans un délai cohérent pour respecter les délais réglementaires.