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 à développer 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 la réglementation.
  • Améliorer 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 explique 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 leur organisation.

Architecture

Le diagramme suivant illustre l'architecture de sauvegarde automatique:

Architecture de la solution de sauvegarde automatique.

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

  1. Cloud Scheduler déclenche une exécution vers le service de distribution via un message Pub/Sub, qui contient la portée des données BigQuery incluses et exclues. Les exécutions sont planifiées à l'aide d'une expression cron.
  2. Le service de distribution, qui est basé sur Cloud Run, utilise l'API BigQuery pour lister les tables qui relèvent du champ d'application de BigQuery.
  3. Le service de distribution envoie une requête pour chaque table au service de configuration via un message Pub/Sub.
  4. Le service de configuration Cloud Run calcule la stratégie de sauvegarde de la table à partir de l'une des options définies suivantes:

    1. La stratégie au niveau de la table, définie par les propriétaires des données.
    2. La stratégie de remplacement, définie par le responsable de la gouvernance des données, pour les tables qui ne disposent pas de stratégies 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 table au service suivant, en fonction de la stratégie de sauvegarde calculée.

  6. En fonction de 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 des instantanés BigQuery sauvegarde la table en tant qu'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 consiste en une exportation de données de table, un récepteur de journaux Cloud Logging écoute les événements de fin des tâches d'exportation afin d'activer l'exécution asynchrone de l'étape suivante.

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

  9. Pour chaque table, le service de taggage consigne 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 job Cron entièrement géré, spécialement conçu pour les entreprises, qui vous permet de configurer des unités de travail planifiées à exécuter à des heures définies ou à intervalles réguliers.
  • Datastore: base de données NoSQL hautement évolutive 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 de publication, 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 de données due à une logique de pipeline de données erronée.

Ces types d'erreurs humaines peuvent généralement être résolus à l'aide de la fonctionnalité 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 également une période de sécurité, pendant laquelle les données supprimées sont conservées dans un stockage de sécurité pendant sept jours supplémentaires après la période de fonctionnalité temporelle. Ces données sont disponibles pour une récupération d'urgence via le 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 peuvent plus être récupérées à partir de leur dernier état stable.

Pour limiter ce problème, nous vous recommandons d'effectuer des sauvegardes régulières pour toutes les tables BigQuery qui ne peuvent pas être reconstruites à partir de 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 régulièrement sauvegarder des centaines ou des milliers de tables dans l'ensemble de l'organisation, vous avez besoin d'une solution d'automatisation évolutive qui peut effectuer les opérations suivantes:

  • Gérer différentes limites d'API Google Cloud
  • Fournir un framework standardisé pour définir des stratégies 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 de la table appropriées.
  • L'équipe de gouvernance des données, qui s'assure qu'une stratégie de remplacement est en place pour couvrir toutes les tables qui ne disposent pas d'une stratégie au niveau de la table. La stratégie de remplacement garantit que certains ensembles de données, projets et dossiers sont sauvegardés afin de respecter les règles de conservation des données de votre entreprise.

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): stratégie 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 qui est stocké dans un bucket commun.
    • Les stratégies manuelles prévalent sur les stratégies de remplacement lorsque la solution détermine la stratégie de sauvegarde d'une table.
    • Pour en savoir plus sur le déploiement, consultez la section Définir des règles de sauvegarde au niveau des tables.
  • Configuration par défaut de l'organisation (centralisée): règle de remplacement qui ne s'applique qu'aux tables qui ne disposent pas de règles associées 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 remplacement 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 la section Définir des règles de sauvegarde de remplacement.

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 si elles sont perdues ou corrompues. Les sauvegardes peuvent être exécutées de manière ponctuelle ou récurrente (via une requête ou un workflow planifiés). Dans BigQuery, les sauvegardes ponctuelles 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 voyage dans le temps 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 qui entraînent une perte ou une corruption de données, plutôt que pour récupérer après des défaillances régionales. BigQuery propose un objectif de niveau de service (SLO) de 99,9% à 99,99%, en fonction de l'édition.

À l'inverse, la réplication est le processus continu de copie des modifications de la base de données dans une base de données secondaire (ou réplica) située dans un autre emplacement. Dans BigQuery, la réplication interrégionale peut aider à fournir une redondance géographique 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 de BigQuery n'est pas conçue pour être utilisée comme plan de reprise après sinistre pour les scénarios de panne dans une région entière. Pour assurer la résilience face aux sinistres régionaux, envisagez d'utiliser la reprise après sinistre gérée par BigQuery.

La réplication interrégionale de BigQuery fournit une copie synchronisée en lecture seule des données dans une région proche des consommateurs de données. Ces copies de données permettent des jointures colocalisées et évitent le trafic et les coûts interrégionaux. Toutefois, en cas de corruption de données due à une erreur humaine, la réplication seule ne permet pas de les récupérer, car les données corrompues sont automatiquement copiées sur la réplication. Dans ce cas, les sauvegardes ponctuelles (instantanés) sont préférables.

Le tableau suivant présente un récapitulatif des méthodes de sauvegarde et de réplication:

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

(instantanés ou exportation vers Cloud Storage)
Une fois ou de manière récurrente Identiques aux données de la table source Restaurer les données d'origine au-delà de la période de voyage dans le temps Les instantanés génèrent des frais de stockage uniquement pour les modifications de données dans l'instantané

Les exportations peuvent générer des frais de stockage standards

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

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

Entraîne des coûts de réplication de 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 de Cloud Run n'accepte que le trafic interne afin de limiter l'accès depuis Internet. Elle n'autorise également que les utilisateurs authentifiés et les comptes de service à 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 atténue les risques associés à l'utilisation d'un seul compte de service pour le système et respecte 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 personnelles exposées, les sauvegardes de ces tables incluent également ces données exposées. Le propriétaire des données sources est responsable de la protection de toute information personnelle dans les tables sources (par exemple, en appliquant une sécurité au niveau des colonnes, un masquage des données ou une masquation). Les sauvegardes ne sont sécurisées que lorsque les données sources le sont. Une autre approche consiste à vous assurer que les projets, les ensembles de données ou les buckets contenant des données de sauvegarde avec des informations permettant d'identifier personnellement l'utilisateur sont dotés des règles IAM (Identity and Access Management) 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 effectuer des sauvegardes de milliers de tables, vous risquez de dépasser les limites de l'API pour les produits Google Cloud sous-jacents (par exemple, les limites d'opérations d'instantané et d'exportation pour chaque projet). Toutefois, si la sauvegarde d'une table échoue en raison d'une mauvaise 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 défaillances potentielles, le déploiement de référence dissocie les étapes de traitement à l'aide de services Cloud Run précis et les connecte via Pub/Sub. Si une requête de sauvegarde de table échoue à l'étape finale du service de taggage, Pub/Sub ne réessaie que cette étape et ne réessaie pas l'ensemble du processus.

En décomposant le flux en plusieurs services Cloud Run au lieu de plusieurs points de terminaison hébergés dans un seul service Cloud Run, vous pouvez contrôler de manière précise chaque configuration de service. Le niveau de configuration dépend des fonctionnalités du service et des API avec lesquelles il communique. Par exemple, le service de distribution s'exécute une fois par exécution, mais il faut un temps considérable pour lister toutes les tables dans le champ d'application de la sauvegarde BigQuery. Par conséquent, le service de distribution nécessite des paramètres de délai avant expiration 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 en moins de temps que le service de distribution. 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 continuellement mises à jour et modifiées, 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 appartenant au même ensemble de données fonctionnel. Par exemple, restaurer une table de ventes à un moment différent de sa table d'inventaire correspondante peut entraîner une incohérence dans le stock disponible. De même, les vues de base de données qui agrégent les données de plusieurs tables peuvent être particulièrement sensibles aux incohérences. Restaurer ces vues sans vous 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, vous devez absolument tenir compte de cette cohérence et vous assurer que vos données restaurées reflètent précisément 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 via les deux configurations suivantes dans les règles de sauvegarde. Ces configurations calculent l'heure exacte de l'instantané de table via la fonctionnalité temporelle, sans nécessairement sauvegarder toutes les tables en même temps.

  • backup_cron: contrôle la fréquence de sauvegarde d'une table. Le code temporel de début d'une exécution est utilisé comme point de référence pour le calcul du voyage dans le temps pour toutes les tables sauvegardées dans cette exécution.
  • backup_time_travel_offset_days: contrôle le nombre de jours passés à soustraire du point de référence temporel (heure de début de l'exécution) pour calculer la version exacte du tableau de 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 de la sauvegarde, y compris une meilleure efficacité et rapidité de récupération, avec moins de temps d'arrêt. Étant donné que la solution suit 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 d'application de données BigQuery à un service de distribution, qui distribue une requête par table à un service de configuration. 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. Ainsi, le framework de restauration automatisée peut bénéficier des mêmes objectifs de conception que le framework de sauvegarde détaillé dans ce document.

Optimisation des coûts

Le framework de cette architecture fournit des stratégies 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 :
    • Instantanés BigQuery, qui entraînent des coûts de stockage en fonction des 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 troncation et de chargement, il est plus économique de les sauvegarder en tant qu'exportations dans des classes de stockage moins chères.
  • Expiration de l'instantané: la valeur TTL (Time To Live) est définie pour un seul instantané de table afin d'éviter d'engager 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'expirent pas.

Efficacité opérationnelle

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

Règles de sauvegarde précises et évolutives

L'un des objectifs de ce framework est l'efficacité opérationnelle en étendant les résultats commerciaux tout en limitant et en gérant les entrées. Par exemple, la sortie correspond à un grand nombre de tables régulièrement sauvegardées, tandis que l'entrée correspond à un petit nombre de configurations et de stratégies de sauvegarde gérées.

En plus d'autoriser les règles de sauvegarde au niveau de la table, le framework autorise également les règles au niveau de l'ensemble de données, du projet, du dossier et au niveau global. 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 que vous compreniez les états 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 exécution unique (nombre de tables traitées et de tables ayant échoué).
  • Les erreurs fatales qui se sont produites 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 l'entrée, la sortie et les erreurs, ainsi que d'autres points de contrôle de 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 de l'observabilité. Pour en savoir plus sur les journaux et les requêtes dans BigQuery, consultez la page Afficher les journaux acheminés vers BigQuery.

Optimisation des performances

Pour gérer des milliers de tables à chaque exécution, la solution traite les requêtes de sauvegarde en parallèle. Le service de distribution 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 initialement échouer pour des raisons temporaires, telles que l'atteinte des limites des API Google Cloud sous-jacentes ou des problèmes de réseau. Tant que les requêtes ne sont pas terminées, Pub/Sub les relance automatiquement avec la stratégie de nouvelle tentative avec 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 particulière est arrêtée 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 tâches d'instantané de table par table et par jour.

Pour en savoir plus, consultez la section Instantanés de table.

Pour les tâches d'exportation (exportations vers Cloud Storage), les éléments suivants 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 augmenter cette limite, créez une réservation d'emplacement.

Pour en savoir plus sur l'extension de ces limites, consultez la section 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 du nombre d'opérations par projet et par jour, vous pouvez les atténuer en demandant une augmentation du quota ou en répartissant 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 la section Déployer une automatisation de sauvegarde BigQuery évolutive.

Étape suivante

Contributeurs

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

Autres contributeurs :