Automatisation évolutive des sauvegardes BigQuery

Last reviewed 2024-09-17 UTC

Cette architecture fournit un framework et un déploiement de référence pour vous aider à élaborer votre stratégie de sauvegarde BigQuery. Ce framework recommandé et son automatisation peuvent aider votre organisation à effectuer les opérations suivantes :

  • Respectez les objectifs de reprise après sinistre de votre organisation.
  • Récupérer les données perdues en raison d'erreurs humaines
  • Respectez les réglementations.
  • Améliorez l'efficacité opérationnelle.

Le champ d'application des données BigQuery peut inclure (ou exclure) des dossiers, des projets, des ensembles de données et des tables. Cette architecture recommandée vous montre comment automatiser les opérations de sauvegarde récurrentes à grande échelle. Vous pouvez utiliser deux méthodes de sauvegarde pour chaque table : les instantanés BigQuery et les exportations BigQuery vers Cloud Storage.

Ce document s'adresse aux architectes cloud, aux ingénieurs et aux responsables de la gouvernance des données qui souhaitent définir et automatiser des règles de données dans leurs organisations.

Architecture

Le schéma suivant illustre l'architecture de la sauvegarde automatisée :

Architecture de la solution de sauvegarde automatisée.

Le workflow illustré dans le schéma précédent comprend les phases suivantes :

  1. Cloud Scheduler déclenche une exécution du service de répartiteur via un message Pub/Sub, qui contient le champ d'application des données BigQuery incluses et exclues. Les exécutions sont planifiées à l'aide d'une expression cron.
  2. Le service de répartiteur, qui est basé sur Cloud Run, utilise l'API BigQuery pour lister les tables qui se trouvent dans le champ d'application BigQuery.
  3. Le service de répartiteur envoie une requête pour chaque table au service de configurateur via un message Pub/Sub.

  4. Le service de configuration Cloud Run calcule la règle de sauvegarde de la table à partir de l'une des options définies suivantes :

    1. La règle au niveau de la table, définie par les propriétaires des données.
    2. Règle de secours, définie par le responsable de la gouvernance des données, pour les tables qui n'ont pas de règles définies.

    Pour en savoir plus sur les règles de sauvegarde, consultez Règles de sauvegarde.

  5. Le service de configuration envoie une requête pour chaque tableau au service suivant, en fonction de la règle de sauvegarde calculée.

  6. Selon la méthode de sauvegarde, l'un des services Cloud Run personnalisés suivants envoie une requête à l'API BigQuery et exécute le processus de sauvegarde :

    1. Le service d'instantanés BigQuery sauvegarde la table sous forme d'instantané.
    2. Le service d'exportation de données sauvegarde la table en tant qu'exportation de données vers Cloud Storage.

  7. Lorsque la méthode de sauvegarde est une exportation de données de table, un collecteur de journaux Cloud Logging écoute les événements de fin des tâches d'exportation afin de permettre l'exécution asynchrone de l'étape suivante.

  8. Une fois que les services de sauvegarde ont terminé leurs opérations, Pub/Sub déclenche le service de taggage.

  9. Pour chaque table, le service de taggage enregistre les résultats des services de sauvegarde et met à jour l'état de la sauvegarde dans la couche de métadonnées Cloud Storage.

Produits utilisés

Cette architecture de référence utilise les produits Google Cloud suivants :

  • BigQuery : entrepôt de données d'entreprise qui vous aide à gérer et analyser vos données grâce à des fonctionnalités intégrées telles que l'analyse géospatiale du machine learning et l'informatique décisionnelle.
  • Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
  • Pub/Sub : service de messagerie asynchrone et évolutif qui dissocie les services qui produisent des messages des services qui traitent ces messages.
  • Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
  • Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.
  • Cloud Scheduler : planificateur de tâches Cron entièrement géré, spécialement conçu pour les entreprises. Il vous permet de configurer des unités de travail planifiées qui seront exécutées à des heures spécifiques ou à intervalles réguliers.
  • Datastore : base de données NoSQL à haute évolutivité pour vos applications Web et mobiles.

Cas d'utilisation

Cette section fournit des exemples de cas d'utilisation pour lesquels vous pouvez utiliser cette architecture.

Automatisation des sauvegardes

Par exemple, votre entreprise peut opérer dans un secteur réglementé et utiliser BigQuery comme entrepôt de données principal. Même si votre entreprise suit les bonnes pratiques en matière de développement logiciel, d'examen du code et d'ingénierie des versions, il existe toujours un risque de perte ou de corruption de données en raison d'erreurs humaines. Dans un secteur réglementé, vous devez minimiser ce risque autant que possible.

Voici quelques exemples d'erreurs humaines :

  • Suppression accidentelle de tables
  • Corruption des données en raison d'une logique de pipeline de données erronée.

Ces types d'erreurs humaines peuvent généralement être résolus grâce à la fonctionnalité de voyage dans le temps, qui vous permet de récupérer des données datant d'il y a jusqu'à sept jours. De plus, BigQuery propose une période de sécurité pendant laquelle les données supprimées sont conservées dans un stockage sécurisé pendant sept jours supplémentaires après la fenêtre de fonctionnalité temporelle. Ces données sont disponibles pour la récupération d'urgence via Cloud Customer Care. Toutefois, si votre entreprise ne détecte pas et ne corrige pas ces erreurs dans ce délai combiné, les données supprimées ne pourront plus être récupérées à partir de leur dernier état stable.

Pour éviter cela, nous vous recommandons d'effectuer des sauvegardes régulières pour toutes les tables BigQuery qui ne peuvent pas être reconstruites à partir des données sources (par exemple, les enregistrements historiques ou les KPI avec une logique métier évolutive).

Votre entreprise peut utiliser des scripts de base pour sauvegarder des dizaines de tables. Toutefois, si vous devez sauvegarder régulièrement des centaines ou des milliers de tables dans l'ensemble de l'organisation, vous avez besoin d'une solution d'automatisation évolutive capable d'effectuer les opérations suivantes :

  • Gérez les différentes limites de l'API Google Cloud .
  • Fournir un framework standardisé pour définir des règles de sauvegarde.
  • Fournir des fonctionnalités de transparence et de surveillance pour les opérations de sauvegarde.

Règles de sauvegarde

Votre entreprise peut également exiger que les règles de sauvegarde soient définies par les groupes de personnes suivants :

  • Les propriétaires de données, qui connaissent le mieux les tables et peuvent définir les règles de sauvegarde au niveau des tables appropriées.
  • L'équipe chargée de la gouvernance des données, qui s'assure qu'une stratégie de remplacement est en place pour couvrir toutes les tables qui n'ont pas de stratégie au niveau de la table. La règle de secours garantit que certains ensembles de données, projets et dossiers sont sauvegardés pour respecter les réglementations de votre entreprise concernant la conservation des données.

Dans le déploiement de cette architecture de référence, il existe deux façons de définir les règles de sauvegarde pour les tables, et elles peuvent être utilisées ensemble :

  • Configuration du propriétaire des données (décentralisée) : une règle de sauvegarde au niveau de la table, qui est associée manuellement à une table.

    • Le propriétaire des données définit un fichier JSON au niveau de la table, stocké dans un bucket commun.
    • Les règles manuelles prévalent sur les règles de secours lorsque la solution détermine la règle de sauvegarde d'une table.
    • Pour en savoir plus sur le déploiement, consultez Définir des règles de sauvegarde au niveau des tables.

  • Configuration par défaut de l'organisation (centralisée) : règle de secours qui s'applique uniquement aux tables auxquelles aucune règle n'est associée manuellement.

    • Une équipe de gouvernance des données définit un fichier JSON central dans Terraform, dans le cadre de la solution.
    • La stratégie de secours propose des stratégies de sauvegarde par défaut au niveau des dossiers, des projets, des ensembles de données et des tables.
    • Pour en savoir plus sur le déploiement, consultez Définir des règles de sauvegarde de secours.

Sauvegarde et réplication

Un processus de sauvegarde crée une copie des données de la table à un moment donné, afin qu'elles puissent être restaurées en cas de perte ou de corruption. Les sauvegardes peuvent être exécutées ponctuellement ou de manière récurrente (par le biais d'une requête ou d'un workflow planifiés). Dans BigQuery, les sauvegardes à un moment précis peuvent être effectuées à l'aide d'instantanés. Vous pouvez utiliser des instantanés pour conserver des copies des données au-delà de la période de sept jours dans le même emplacement de stockage que les données sources. Les instantanés BigQuery sont particulièrement utiles pour récupérer des données après des erreurs humaines ayant entraîné une perte ou une corruption de données, plutôt que pour récupérer des données après des défaillances régionales. BigQuery propose un objectif de niveau de service (SLO) de 99,9 % à 99,99 %, selon l'édition.

En revanche, la réplication est le processus continu de copie des modifications apportées à la base de données vers une base de données secondaire (ou répliquée) située dans un autre emplacement. Dans BigQuery, la réplication interrégionale peut contribuer à la géo-redondance en créant des copies en lecture seule des données dans des Google Cloud régions secondaires, qui sont différentes de la région des données sources. Toutefois, la réplication interrégionale BigQuery n'est pas conçue pour être utilisée comme plan de reprise après sinistre en cas de panne régionale totale. Pour assurer la résilience en cas de sinistre régional, envisagez d'utiliser la reprise après sinistre gérée par BigQuery.

La réplication interrégionale BigQuery fournit une copie en lecture seule synchronisée des données dans une région proche des consommateurs de données. Ces copies de données permettent d'effectuer des jointures colocalisées et d'éviter le trafic et les coûts interrégionaux. Toutefois, en cas de corruption des données due à une erreur humaine, la réplication seule ne peut pas aider à la récupération, car les données corrompues sont automatiquement copiées dans l'instance répliquée. Dans ce cas, les sauvegardes à un moment précis (instantanés) sont plus adaptées.

Le tableau suivant compare les méthodes de sauvegarde et la réplication :

Méthode Fréquence Emplacement de stockage Cas d'utilisation Coûts
Sauvegarde

(instantanés ou exportation Cloud Storage)		 Ponctuellement ou de manière récurrente Identique aux données de la table source Restaurer les données d'origine au-delà de la période de voyage temporel Les instantanés entraînent des frais de stockage uniquement pour les modifications de données qu'ils contiennent.

Les exportations peuvent entraîner des frais de stockage standards.

Consultez Optimisation des coûts.
Réplication interrégionale En continu Distant Créer une instance répliquée dans une autre région

Migrations ponctuelles entre régions		 Entraîne des frais de stockage des données dans le réplica

Entraîne des coûts de réplication des données

Considérations de conception

Cette section fournit des conseils à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, d'optimisation des coûts, d'efficacité opérationnelle et de performances.

Sécurité, confidentialité et conformité

Le déploiement intègre les mesures de sécurité suivantes dans sa conception et son implémentation :

  • Le paramètre Entrée réseau pour Cloud Run n'accepte que le trafic interne afin de limiter l'accès depuis Internet. Il permet également aux utilisateurs et aux comptes de service authentifiés d'appeler les services.
  • Chaque service Cloud Run et chaque abonnement Pub/Sub utilise un compte de service distinct, auquel seules les autorisations requises sont attribuées. Cela permet d'atténuer les risques associés à l'utilisation d'un seul compte de service pour le système et de respecter le principe du moindre privilège.

Pour des raisons de confidentialité, la solution ne collecte ni ne traite aucune information permettant d'identifier personnellement l'utilisateur. Toutefois, si les tables sources contiennent des informations permettant d'identifier personnellement l'utilisateur, les sauvegardes de ces tables incluent également ces données exposées. Le propriétaire des données sources est responsable de la protection des informations permettant d'identifier personnellement l'utilisateur dans les tables sources (par exemple, en appliquant la sécurité au niveau des colonnes, le masquage des données ou la censure). Les sauvegardes ne sont sécurisées que lorsque les données sources le sont. Une autre approche consiste à s'assurer que les projets, ensembles de données ou buckets contenant des données de sauvegarde avec des informations permettant d'identifier personnellement les utilisateurs exposées disposent des règles Identity and Access Management (IAM) requises qui limitent l'accès aux seuls utilisateurs autorisés.

En tant que solution à usage général, le déploiement de référence ne respecte pas nécessairement les exigences spécifiques d'un secteur particulier.

Fiabilité

Cette section décrit les fonctionnalités et les considérations de conception pour la fiabilité.

Atténuation des échecs avec précision

Pour sauvegarder des milliers de tables, vous risquez d'atteindre les limites de l'API pour les produits Google Cloud sous-jacents (par exemple, les limites d'opérations snapshot et export pour chaque projet). Toutefois, si la sauvegarde d'une table échoue en raison d'une erreur de configuration ou d'autres problèmes temporaires, cela ne devrait pas affecter l'exécution globale ni la possibilité de sauvegarder d'autres tables.

Pour atténuer les éventuelles défaillances, le déploiement de référence découple les étapes de traitement en utilisant des services Cloud Run granulaires et en les connectant via Pub/Sub. Si une demande de sauvegarde de table échoue lors de la dernière étape du service de taggage, Pub/Sub ne relance que cette étape et non l'ensemble du processus.

En divisant le flux en plusieurs services Cloud Run, au lieu de plusieurs points de terminaison hébergés sous un seul service Cloud Run, vous pouvez contrôler précisément la configuration de chaque service. Le niveau de configuration dépend des capacités du service et des API avec lesquelles il communique. Par exemple, le service de répartiteur s'exécute une fois par exécution, mais il nécessite un temps considérable pour lister toutes les tables dans le champ d'application de la sauvegarde BigQuery. Par conséquent, le service de répartiteur nécessite des paramètres de délai d'attente et de mémoire plus élevés. Toutefois, le service Cloud Run pour les instantanés BigQuery s'exécute une fois par table en une seule exécution et se termine plus rapidement que le service de répartiteur. Par conséquent, le service Cloud Run nécessite un ensemble de configurations différent au niveau du service.

Cohérence des données

La cohérence des données entre les tables et les vues est essentielle pour maintenir une stratégie de sauvegarde fiable. Étant donné que les données sont mises à jour et modifiées en permanence, les sauvegardes effectuées à différents moments peuvent capturer différents états de votre ensemble de données. Ces sauvegardes dans différents états peuvent entraîner des incohérences lorsque vous restaurez des données, en particulier pour les tables qui appartiennent au même ensemble de données fonctionnel. Par exemple, si vous restaurez une table des ventes à un moment différent de celui de la table d'inventaire correspondante, cela peut entraîner une incohérence dans les stocks disponibles. De même, les vues de base de données qui agrègent des données provenant de plusieurs tables peuvent être particulièrement sensibles aux incohérences. Restaurer ces vues sans s'assurer que les tables sous-jacentes sont dans un état cohérent peut entraîner des résultats inexacts ou trompeurs. Par conséquent, lorsque vous concevez vos règles et fréquences de sauvegarde BigQuery, il est impératif de tenir compte de cette cohérence et de vous assurer que vos données restaurées reflètent fidèlement l'état réel de votre ensemble de données à un moment donné.

Par exemple, dans le déploiement de cette architecture de référence, la cohérence des données est contrôlée par les deux configurations suivantes dans les stratégies de sauvegarde. Ces configurations calculent l'heure exacte de l'instantané de table à l'aide de la fonctionnalité temporelle, sans nécessairement sauvegarder toutes les tables en même temps.

  • backup_cron : contrôle la fréquence à laquelle une table est sauvegardée. Le code temporel de début d'une exécution sert de point de référence pour le calcul du voyage temporel pour toutes les tables sauvegardées lors de cette exécution.
  • backup_time_travel_offset_days : contrôle le nombre de jours à soustraire au point de référence dans le temps (heure de début de l'exécution) pour calculer la version exacte de la table avec voyage dans le temps.

Restauration automatique des sauvegardes

Bien que cette architecture de référence se concentre sur l'automatisation des sauvegardes à grande échelle, vous pouvez également envisager de restaurer ces sauvegardes de manière automatisée. Cette automatisation supplémentaire peut offrir des avantages similaires à ceux de l'automatisation des sauvegardes, y compris une efficacité et une vitesse de récupération améliorées, avec moins de temps d'arrêt. Étant donné que la solution assure le suivi de tous les paramètres et résultats de sauvegarde via le service de taggage, vous pouvez développer une architecture similaire pour appliquer les opérations de restauration à grande échelle.

Par exemple, vous pouvez créer une solution basée sur un déclencheur à la demande qui envoie un champ de données BigQuery à un service de répartiteur, lequel envoie une requête par table à un service de configurateur. Le service de configuration peut récupérer l'historique des sauvegardes que vous souhaitez pour une table spécifique. Le service de configuration peut ensuite le transmettre à un service de restauration des instantanés BigQuery ou à un service de restauration Cloud Storage pour appliquer l'opération de restauration en conséquence. Enfin, un service de taggage peut stocker les résultats de ces opérations dans un magasin d'état. Ce faisant, le framework de restauration automatisée peut bénéficier des mêmes objectifs de conception que le framework de sauvegarde décrits dans ce document.

Optimisation des coûts

Le framework de cette architecture fournit des règles de sauvegarde qui définissent les paramètres suivants pour l'optimisation globale des coûts :

  • Méthode de sauvegarde : le framework propose les deux méthodes de sauvegarde suivantes :
    • Les instantanés BigQuery, qui entraînent des coûts de stockage basés sur les données mises à jour et supprimées par rapport à la table de base. Par conséquent, les instantanés sont plus rentables pour les tables en mode ajout uniquement ou dont les mises à jour sont limitées.
    • Les exportations BigQuery vers Cloud Storage, qui entraînent des frais de stockage standards. Toutefois, pour les grandes tables qui suivent une approche de troncature et de chargement, il est plus rentable de les sauvegarder en tant qu'exportations dans des classes de stockage moins coûteuses.
  • Expiration des instantanés : la durée de vie (TTL) est définie pour un seul instantané de table, afin d'éviter d'accumuler des coûts de stockage pour l'instantané indéfiniment. Les coûts de stockage peuvent augmenter au fil du temps si les tables n'ont pas de date d'expiration.

Efficacité opérationnelle

Cette section décrit les fonctionnalités et les considérations relatives à l'efficacité opérationnelle.

Règles de sauvegarde précises et évolutives

L'un des objectifs de ce framework est l'efficacité opérationnelle, qui consiste à augmenter la production de l'entreprise tout en maintenant les entrées relativement faibles et gérables. Par exemple, la sortie correspond à un nombre élevé de tables sauvegardées régulièrement, tandis que l'entrée correspond à un petit nombre de configurations et de règles de sauvegarde gérées.

En plus d'autoriser les règles de sauvegarde au niveau des tables, le framework autorise également les règles au niveau des ensembles de données, des projets, des dossiers et au niveau mondial. Cela signifie qu'avec quelques configurations à des niveaux supérieurs (par exemple, au niveau du dossier ou du projet), des centaines ou des milliers de tables peuvent être sauvegardées régulièrement, à grande échelle.

Observabilité

Avec un framework d'automatisation, il est essentiel de comprendre l'état des processus. Par exemple, vous devriez pouvoir trouver les informations pour les requêtes courantes suivantes :

  • Règle de sauvegarde utilisée par le système pour chaque table.
  • L'historique des sauvegardes et les emplacements de sauvegarde de chaque table.
  • État général d'une seule exécution (nombre de tables traitées et de tables ayant échoué).
  • Erreurs fatales survenues lors d'une seule exécution, ainsi que les composants ou les étapes du processus dans lesquels elles se sont produites.

Pour fournir ces informations, le déploiement écrit des journaux structurés dans Cloud Logging à chaque étape d'exécution qui utilise un service Cloud Run. Les journaux incluent les entrées, les sorties et les erreurs, ainsi que d'autres points de contrôle de la progression. Un récepteur de journaux achemine ces journaux vers une table BigQuery. Vous pouvez exécuter un certain nombre de requêtes pour surveiller les exécutions et obtenir des rapports pour les cas d'utilisation courants d'observabilité. Pour en savoir plus sur les journaux et les requêtes dans BigQuery, consultez Afficher les journaux routés vers BigQuery.

Optimisation des performances

Pour gérer des milliers de tables à chaque exécution, la solution traite les demandes de sauvegarde en parallèle. Le service Dispatcher liste toutes les tables incluses dans le champ d'application de la sauvegarde BigQuery et génère une demande de sauvegarde par table à chaque exécution. Cela permet à l'application de traiter des milliers de requêtes et de tables en parallèle, et non de manière séquentielle.

Certaines de ces requêtes peuvent échouer initialement pour des raisons temporaires, par exemple en raison de limites atteintes dans les API Google Cloud sous-jacentes ou de problèmes réseau. Tant que les requêtes ne sont pas traitées, Pub/Sub les relance automatiquement avec la stratégie de nouvelles tentatives à intervalle exponentiel. En cas d'erreurs fatales telles que des destinations de sauvegarde non valides ou des autorisations manquantes, les erreurs sont consignées et l'exécution de cette requête de table spécifique est interrompue sans affecter l'exécution globale.

Limites

Les quotas et limites suivants s'appliquent à cette architecture.

Pour les instantanés de table, les éléments suivants s'appliquent à chaque projet d'opération de sauvegarde que vous spécifiez :

  • Un projet peut exécuter jusqu'à 100 tâches d'instantané de table simultanées.
  • Un projet peut exécuter jusqu'à 50 000 tâches d'instantané de table par jour.
  • Un projet peut exécuter jusqu'à 50 jobs d'instantané de table par table et par jour.

Pour en savoir plus, consultez Instantanés de tables.

Pour les tâches d'exportation (exportations vers Cloud Storage), les règles suivantes s'appliquent :

  • Vous pouvez exporter gratuitement jusqu'à 50 Tio de données par jour à partir d'un projet à l'aide du pool d'emplacements partagé.
  • Un projet peut exécuter jusqu'à 100 000 exportations par jour. Pour étendre cette limite, créez une réservation d'emplacements.

Pour en savoir plus sur l'extension de ces limites, consultez Tâches d'exportation.

En ce qui concerne les limites de simultanéité, cette architecture utilise Pub/Sub pour réessayer automatiquement les requêtes qui échouent en raison de ces limites, jusqu'à ce qu'elles soient traitées par l'API. Toutefois, pour les autres limites concernant le nombre d'opérations par projet et par jour, vous pouvez soit demander à augmenter le quota, soit répartir les opérations de sauvegarde (instantanés ou exportations) sur plusieurs projets. Pour répartir les opérations entre les projets, configurez les règles de sauvegarde comme décrit dans les sections de déploiement suivantes :

Déploiement

Pour déployer cette architecture, consultez Déployer une automatisation évolutive des sauvegardes BigQuery.

Étapes suivantes

Contributeurs

Auteur : Karim Wadie | Ingénieur stratégique Cloud

Autres contributeurs :