Le développement de pipelines implique différentes étapes et tâches, telles que le développement de code, les tests et la livraison en production. Ce document aborde les questions suivantes :
- Points à prendre en compte concernant l'intégration continue (CI) et la livraison continue (CD) pour automatiser les compilations, les tests et les déploiements de pipelines dans différents environnements
- Fonctionnalités de Dataflow permettant d'optimiser les performances et l'utilisation des ressources en production
- Approches et points d'observation pour la mise à jour des pipelines de streaming en production
- Bonnes pratiques pour améliorer la fiabilité des pipelines en production
Intégration continue
L'intégration continue (CI) exige que les développeurs fusionnent fréquemment le code dans un dépôt partagé, ce qui est utile pour les applications qui subissent beaucoup de modifications, telles que les sites Web fréquemment mis à jour. Bien que les pipelines de données ne changent généralement pas autant que les autres types d'applications, les pratiques de CI offrent de nombreux avantages en ce qui concerne leur développement. Par exemple, l'automatisation des tests fournit des retours rapides en cas de défaillance d'un processeur et réduit le risque d'introduire des régressions dans le code base.
L'automatisation des tests est un élément important de l'intégration continue. Associée à une couverture de test appropriée, l'automatisation des tests permet d'exécuter votre suite de tests sur chaque commit de code. Votre serveur CI peut fonctionner avec un outil de compilation automatique tel que Maven pour exécuter votre suite de tests en une ou plusieurs étapes du pipeline CI. Vous pouvez empaqueter du code qui réussit les tests unitaires et les tests d'intégration dans les artefacts de déploiement à partir desquels les pipelines sont lancés. On appelle cette compilation une compilation réussie.
Le nombre et les types d'artefacts de déploiement créés à partir d'une compilation réussie varient en fonction de la méthode de lancement des pipelines. À l'aide du SDK Java Apache Beam, vous pouvez empaqueter le code de votre pipeline dans un fichier JAR auto-exécutable. Vous pouvez ensuite stocker le fichier JAR dans un bucket hébergé dans le projet pour un environnement de déploiement, tel que le projet Google Cloud de préproduction ou de production. Si vous utilisez des modèles classiques (un type d'exécution modélisée), les artefacts de déploiement incluent un fichier de modèle JSON, le fichier JAR de votre pipeline et un modèle de métadonnées facultatif. Vous pouvez ensuite déployer les artefacts dans différents environnements de déploiement à l'aide de la livraison continue, comme expliqué dans la section suivante.
Livraison et déploiement continus
La livraison continue (CD) copie les artefacts de déploiement dans un ou plusieurs environnements de déploiement prêts à être lancés manuellement. En règle générale, les artefacts créés par le serveur CI sont déployés dans un ou plusieurs environnements de préproduction pour exécuter des tests de bout en bout. L'environnement de production est mis à jour si tous les tests de bout en bout réussissent.
Pour les pipelines de traitement par lot, le déploiement continu peut lancer directement le pipeline en tant que nouveau job Dataflow. D'autres systèmes peuvent également utiliser les artefacts pour lancer des tâches par lot si nécessaire. Par exemple, vous pouvez utiliser Cloud Composer pour exécuter des jobs par lot dans un workflow, ou utiliser Cloud Scheduler pour planifier des jobs par lot.
Les pipelines de streaming peuvent être plus complexes à déployer que les pipelines de traitement par lot et donc plus difficiles à automatiser à l'aide du déploiement continu. Par exemple, vous devrez peut-être déterminer comment remplacer ou mettre à jour un pipeline de streaming existant. Si vous ne souhaitez pas ou ne pouvez pas mettre à jour un pipeline, d'autres méthodes telles que la coordination de plusieurs tâches Dataflow permettent de minimiser ou d'empêcher les interruptions d'activité.
Identités et rôles requis pour les approches CI/CD
Votre pipeline CI/CD interagit avec différents systèmes pour créer, tester et déployer des pipelines. Par exemple, votre pipeline doit accéder au dépôt de votre code source. Pour activer ces interactions, assurez-vous que votre pipeline dispose des identités et des rôles appropriés. Les activités de pipeline suivantes peuvent également nécessiter d'attribuer des identités et des rôles spécifiques à votre pipeline.
Tests d'intégration avec des services externes, y compris Google Cloud
Lorsque vous utilisez l'exécuteur Direct Runner pour exécuter des tests ad hoc ou effectuer des tests d'intégration, votre pipeline utilise les identifiants de Google Cloud CLI pour consommer les sources et les récepteurs de données Google Cloud, ou les identifiants fournis par la variable d'environnement GOOGLE_APPLICATION_CREDENTIALS. Assurez-vous que le compte de service utilisé pour obtenir les identifiants des ressources Google Cloud accessibles par le pipeline dispose de rôles et d'autorisations suffisants.
Déployer des artefacts dans différents environnements de déploiement
Si possible, utilisez des identifiants uniques pour chaque environnement (effectivement pour chaque projet) et limitez l'accès aux ressources en conséquence.
Utilisez des comptes de service uniques pour chaque projet afin de lire et d'écrire des artefacts de déploiement dans des buckets de stockage. Selon que votre pipeline utilise un modèle ou non, votre processus de déploiement peut avoir besoin de préproduire plusieurs artefacts. Par exemple, pour créer et préproduire un modèle Dataflow, vous devez disposer des autorisations pour écrire dans un bucket Cloud Storage les artefacts de déploiement nécessaires au lancement de votre pipeline, tels que le fichier de modèle de pipeline.
Déployer des pipelines dans différents environnements de déploiement
Dans la mesure du possible, utilisez des comptes de service uniques pour chaque projet afin d'accéder aux ressources Google Cloud du projet, de les gérer et d'accéder à Dataflow.
Le compte de service que vous utilisez pour créer et gérer des jobs Dataflow doit disposer d'autorisations IAM suffisantes pour la gestion des jobs. Pour en savoir plus, consultez la section Compte de service Dataflow de la page sur la sécurité et les autorisations dans Dataflow.
Le compte de service de nœud de calcul que vous utilisez pour exécuter des jobs Dataflow doit être autorisé à gérer les ressources Compute Engine pendant l'exécution du job, ainsi que les interactions entre le pipeline Apache Beam et le service Dataflow. Pour en savoir plus, consultez la section Compte de service de nœud de calcul de la page sur la sécurité et les autorisations dans Dataflow.
Pour spécifier un compte de service de nœud de calcul géré par l'utilisateur pour un job, utilisez l'option de pipeline --serviceAccount.
Si vous ne spécifiez pas de compte de service de nœud de calcul lors de la création d'un job, Dataflow tente d'utiliser le compte de service Compute Engine par défaut.
Nous vous recommandons de spécifier à la place un compte de service de nœud de calcul géré par l'utilisateur pour les environnements de production, car le compte de service Compute Engine par défaut dispose généralement d'un ensemble d'autorisations plus étendu que celui requis pour vos jobs Dataflow.
Dans les scénarios de production, nous vous recommandons d'utiliser des comptes de service distincts pour la gestion des jobs Dataflow et pour le compte de service du nœud de calcul, qui offre une sécurité supérieure à celle d'un seul compte de service. Par exemple, le compte de service utilisé pour créer des tâches Dataflow peut ne pas avoir besoin d'accéder à des sources et des récepteurs de données, ni à utiliser d'autres ressources utilisées par le pipeline. Dans ce scénario, le compte de service de nœud de calcul utilisé pour exécuter les jobs Dataflow dispose des autorisations nécessaires pour utiliser des ressources de pipeline. Un compte de service différent pour la création de jobs dispose d'autorisations pour gérer (y compris créer) des jobs Dataflow.
Exemple de pipeline CI/CD
Le diagramme suivant fournit une vue générale et indépendante des outils des approches CI/CD pour les pipelines de données. De plus, le diagramme montre la relation entre les jobs de développement, les environnements de déploiement et les services d'exécution du pipeline.
Le diagramme montre les étapes suivantes :
Développement de code : lors du développement de code, un développeur exécute le code de pipeline localement à l'aide de l'exécuteur Direct Runner. En outre, les développeurs utilisent un environnement de bac à sable pour exécuter des pipelines ad hoc à l'aide de l'exécuteur Dataflow Runner.
Dans les pipelines CI/CD types, le processus d'intégration continue est déclenché lorsqu'un développeur modifie le système de contrôle source, par exemple en transférant du nouveau code vers un dépôt.
Compilation et test : le processus d'intégration continue compile le code du pipeline, puis exécute des tests unitaires et des tests d'intégration des transformations à l'aide de l'exécuteur Direct Runner. Des tests d'intégration système facultatifs, incluant des tests d'intégration avec des sources et des récepteurs externes utilisant de petits ensembles de données de test, peuvent également être exécutés.
Si les tests réussissent, le processus CI stocke les artefacts de déploiement, qui peuvent inclure des fichiers JAR, des images Docker et des métadonnées de modèle, nécessaires au lancement du pipeline dans des emplacements accessibles au processus de livraison continue. Selon les types d'artefacts de déploiement générés, vous pouvez utiliser Cloud Storage et Artifact Registry pour stocker les différents types d'artefacts.
Livraison et déploiement : le processus de livraison continue copie les artefacts de déploiement dans un environnement de préproduction ou les rend disponibles pour être utilisés dans cet environnement. Les développeurs peuvent exécuter manuellement des tests de bout en bout à l'aide de l'exécuteur Dataflow Runner, ou utiliser le déploiement continu pour lancer le test automatiquement. En règle générale, une approche de déploiement continu est plus facile à activer pour les pipelines de traitement par lot que pour les pipelines de traitement par flux. Étant donné que les pipelines de traitement par lot ne s'exécutent pas en continu, il est plus facile de les remplacer par une nouvelle version.
Le processus de mise à jour des pipelines de traitement par flux peut aller du simple au complexe. Il est donc recommandé de tester les mises à jour dans l'environnement de préproduction. Il se peut que les procédures de mise à jour ne soient pas toujours cohérentes entre les versions. Par exemple, un pipeline peut changer de telle sorte qu'il est impossible de le mettre à jour sur place. Pour cette raison, il est parfois difficile d'automatiser les mises à jour de pipeline à l'aide d'un déploiement continu.
Si tous les tests de bout en bout réussissent, vous pouvez copier les artefacts de déploiement ou les mettre à la disposition dans l'environnement de production, dans le cadre du processus de livraison continue. Si le nouveau pipeline met à jour ou remplace un pipeline de streaming existant, suivez les procédures testées dans l'environnement de préproduction pour déployer le nouveau pipeline.
Différences entre l'exécution de tâches modélisées et non modélisées
Vous pouvez créer une tâche Dataflow à l'aide du SDK Apache Beam directement à partir d'un environnement de développement. Ce type de job est appelé job non modélisé. Bien qu'il s'agisse d'une approche pratique, vous préférerez peut-être séparer les jobs de développement et d'exécution de pipelines. Pour effectuer cette séparation, vous pouvez utiliser des modèles Dataflow qui permettent d'organiser et d'exécuter vos pipelines comme des jobs indépendants. Une fois qu'un modèle est déployé, d'autres utilisateurs, y compris des non-développeurs, peuvent exécuter les jobs du modèle à l'aide de Google Cloud CLI, de la console Google Cloud ou de l'API REST Dataflow.
Dataflow propose les types de modèles de tâche suivants :
- Modèles classiques : les développeurs utilisent le SDK Apache Beam pour exécuter le code du pipeline et enregistrer le graphique d'exécution sérialisé en JSON en tant que modèle. Le SDK Apache Beam préproduit le fichier de modèle dans un emplacement Cloud Storage, ainsi que toutes les dépendances requises par le code de pipeline.
- Modèles Flex : les développeurs utilisent Google Cloud CLI pour empaqueter le pipeline en tant qu'image Docker, qui est ensuite stockée dans Artifact Registry. Un fichier de spécification de modèle Flex est également automatiquement généré et stocké dans un emplacement Cloud Storage spécifié par l'utilisateur. Le fichier de spécification de modèle Flex contient des métadonnées décrivant comment exécuter le modèle, telles que des paramètres de pipeline.
En plus des fonctionnalités du modèle Flex décrites dans la documentation associée, les modèles Flex offrent des avantages par rapport aux modèles classiques pour la gestion des modèles.
- Avec les modèles classiques, plusieurs artefacts (tels que les fichiers JAR) peuvent être stockés dans un emplacement de préproduction Cloud Storage, mais sans aucune fonctionnalité permettant de gérer ces multiples artefacts. Par comparaison, un modèle Flex est encapsulé dans une image Docker. L'image regroupe toutes les dépendances (hormis la spécification de modèle Flex) nécessaires à votre pipeline dans un artefact de déploiement géré par Artifact Registry.
- Vous pouvez utiliser les fonctionnalités de gestion des images Docker pour vos modèles Flex. Par exemple, vous pouvez partager en toute sécurité des modèles Flex en accordant des autorisations d'extraction (et éventuellement de transfert) à Artifact Registry, et utiliser des tags d'image Docker pour différentes versions de vos modèles Flex.
Les développeurs peuvent utiliser des modèles classiques et des modèles Flex pour lancer des jobs dans un projet différent du projet propriétaire du registre et du bucket de stockage hébergeant les éléments du modèle, ou uniquement le bucket de stockage si vous utilisez des modèles classiques Ceci est utile si vous devez isoler le traitement des données de plusieurs clients dans différents projets et jobs de pipeline. À l'aide des modèles Flex, vous pouvez spécifier davantage les différentes versions d'une image Docker à utiliser lorsque vous lancez un pipeline. Cette fonctionnalité simplifie le remplacement par étapes de pipelines par lots ou de pipelines de traitement par flux sur plusieurs projets lorsque vous mettez à jour des modèles par la suite.
Fonctionnalités de Dataflow pour optimiser l'utilisation des ressources
Dataflow fournit des fonctionnalités propres à l'exécuteur, telles que les suivantes, pour optimiser l'utilisation des ressources, ce qui peut améliorer les performances et réduire les coûts :
- Streaming Engine : Streaming Engine déplace l'exécution des pipelines de traitement par flux des nœuds de calcul de VM vers un service dédié. Cette fonctionnalité offre plusieurs avantages : elle améliore la réactivité de l'autoscaling, réduit le nombre de ressources de VM de calcul consommées et permet des mises à jour automatiques des services sans redéploiement. Dans certains cas, vous pouvez également réduire l'utilisation des ressources en utilisant le traitement de type "au moins une fois", pour les cas d'utilisation qui peuvent tolérer des doublons. L'activation de Streaming Engine est recommandée pour les pipelines de traitement par flux. Cette fonctionnalité est activée par défaut lorsque vous utilisez les dernières versions du SDK Java Apache Beam ou du SDK Python.
- Dataflow Shuffle : Dataflow Shuffle transfère les opérations de brassage des pipelines de traitement par lot des nœuds de calcul de VM vers un service dédié. Cela présente plusieurs avantages, dont l'exécution accélérée de la plupart des pipelines de traitement par lot, la réduction du nombre de ressources consommées par les VM de nœud de calcul, l'amélioration de la réactivité de l'autoscaling et l'amélioration de la tolérance aux pannes. L'activation de Dataflow Shuffle est recommandée pour les pipelines de traitement par lot. Cette fonctionnalité est activée par défaut à l'aide du SDK Java Apache Beam et de la dernière version du SDK Python.
- Planification flexible des ressources (FlexRS) : FlexRS permet de réduire les coûts de traitement par lot grâce à l'utilisation de techniques de planification avancées, du service Dataflow Shuffle et d'une combinaison d'instances de VM préemptives et de VM standards.
Mettre à jour les pipelines de traitement par flux en production
Consultez la page Mettre à niveau un pipeline de streaming.
Cycle de vie d'une tâche Dataflow
Le cycle de vie d'une tâche Dataflow passe par divers états de tâche.
Pour exécuter un job Dataflow, envoyez-le à une région.
Le job est ensuite acheminé vers un backend Dataflow disponible dans l'une des zones de la région. Avant d'attribuer un backend, Dataflow vérifie que vous disposez d'un quota et d'autorisations suffisants pour exécuter la tâche. Une fois ces vérifications effectuées et le backend attribué, la tâche passe à l'état JOB_STATE_PENDING. Dans le cas de jobs FlexRS, l'attribution du backend peut être reportée et ces jobs passent à l'état JOB_STATE_QUEUED.
Le backend attribué récupère le job à exécuter et tente de démarrer les nœuds de calcul Dataflow dans votre projet Google Cloud. Le choix de la zone des VM de nœud de calcul dépend d'un certain nombre de facteurs. Dans le cas des jobs par lot qui utilisent Dataflow Shuffle, le service tente également de veiller à ce que le backend et les VM de nœud de calcul Dataflow se trouvent dans la même zone afin d'éviter le trafic interzone.
Une fois les nœuds de calcul Dataflow démarrés, ils demandent du travail auprès du backend Dataflow. En effet, ce backend est chargé de diviser le travail en fragments exécutables en parallèle, appelés lots, et de les répartir entre les nœuds de calcul. Si les nœuds de calcul ne peuvent pas gérer le travail existant et si l'autoscaling est activé, le backend démarre des nœuds de calcul supplémentaires. De même, si plus de nœuds de calcul que nécessaire sont démarrés, certains d'entre eux sont arrêtés.
Une fois les nœuds de calcul Dataflow démarrés, le backend Dataflow sert de plan de contrôle pour orchestrer l'exécution des jobs. Lors du traitement, le plan de données du job effectue des opérations de brassage telles que GroupByKey, CoGroupByKey et Combine.
Les tâches utilisent l'une des implémentations de plan de données suivantes pour effectuer les opérations de brassage :
- Le plan de données s'exécute sur les nœuds de calcul Dataflow et les données brassées sont stockées sur des disques persistants.
- Le plan de données s'exécute en tant que service, en dehors des VM de nœud de calcul. Cette mise en œuvre comporte deux variantes que vous spécifiez lors de la création du job : Dataflow Shuffle pour les pipelines de traitement par lot et Streaming Engine pour les pipelines de traitement par flux. Le brassage basé sur les services améliore considérablement les performances et l'évolutivité des opérations de brassage de données par rapport au brassage basé sur les nœuds de calcul.
Les jobs de traitement par flux qui entrent dans JOB_STATE_RUNNING s'exécutent indéfiniment jusqu'à ce qu'ils soient annulés ou drainés, sauf en cas d'échec du job. Les jobs par lot se terminent automatiquement une fois le traitement terminé ou si une erreur irrécupérable se produit. Selon la manière dont le job est arrêté, Dataflow définit l'état du job sur l'un des états terminaux, par exemple JOB_STATE_CANCELLED, JOB_STATE_DRAINED ou JOB_STATE_DONE.
Bonnes pratiques pour assurer la fiabilité du pipeline
Cette section décrit les échecs pouvant survenir lorsque vous travaillez avec Dataflow, ainsi que les bonnes pratiques relatives aux jobs Dataflow.
Appliquer les principes d'isolation
Une recommandation générale pour améliorer la fiabilité globale du pipeline consiste à appliquer les principes d'isolation dans les régions et les zones. Assurez-vous que vos pipelines n'ont pas de dépendances interrégionales critiques. Si un pipeline est fortement dépendant de services déployés dans plusieurs régions, une défaillance dans l'une de ces régions peut affecter votre pipeline. Pour éviter ce problème, effectuez un déploiement multirégional afin d'assurer la redondance et la sauvegarde.
Créer des instantanés Dataflow
Dataflow propose une fonctionnalité d'instantané qui fournit une sauvegarde de l'état d'un pipeline. Vous pouvez restaurer l'instantané de pipeline dans un nouveau pipeline Dataflow de traitement par flux dans une autre zone ou région. Vous pouvez ensuite démarrer le retraitement des messages dans les sujets Pub/Sub ou Kafka à partir de l'horodatage de l'instantané. Si vous configurez des instantanés réguliers de vos pipelines, vous pouvez réduire le RTO (objectif de temps de récupération).
Pour en savoir plus sur les instantanés Dataflow, consultez la page Utiliser les instantanés Dataflow.
Gérer les échecs d'envoi de jobs
Vous envoyez des jobs Dataflow sans modèle à l'aide du SDK Apache Beam. Pour cela, vous exécutez le pipeline à l'aide de l'exécuteur Dataflow Runner spécifié dans les options du pipeline. Le SDK Apache Beam préproduit les fichiers dans Cloud Storage, crée un fichier de requête de tâche et l'envoie à Dataflow.
Les jobs créés à partir de modèles Dataflow utilisent également différentes méthodes d'envoi qui reposent généralement sur l'API des modèles.
Certaines erreurs renvoyées par Dataflow peuvent indiquer des échecs de tâches basées sur des modèles ou non. Cette section décrit les différents types d'échecs d'envoi de job et présente les bonnes pratiques permettant de les gérer ou de les atténuer.
Réessayer d'envoyer des tâches après des échecs temporaires
Si une tâche ne parvient pas à démarrer en raison d'un problème de service Dataflow, relancez la tâche plusieurs fois. La répétition des tentatives atténue les problèmes de service temporaires.
Atténuer les défaillances de zones en spécifiant une région de nœud de calcul
Dataflow offre une disponibilité régionale et une disponibilité multirégionale. Lorsqu'un utilisateur envoie un job vers une région sans spécifier explicitement de zone, Dataflow achemine le job vers une zone de la région spécifiée en fonction de la disponibilité des ressources.
Pour définir l'emplacement d'une tâche, il est recommandé de spécifier une région de nœud de calcul à l'aide de l'option --region au lieu de l'option --zone autant que possible. Cela permet à Dataflow de fournir à vos pipelines un degré supérieur de tolérance aux pannes en choisissant automatiquement la meilleure zone possible pour ce job. Les jobs qui spécifient une zone explicite ne présentent pas cet avantage et échouent si des problèmes surviennent dans la zone. Si l'envoi d'un job échoue en raison d'un problème de zone, vous pouvez souvent résoudre le problème en relançant le job sans spécifier de zone explicitement.
Atténuer les défaillances régionales en stockant des données dans plusieurs régions
Si une région entière n'est pas disponible, relancez la tâche dans une autre région. Il est important de réfléchir à la disponibilité de vos données lorsque les tâches échouent dans plusieurs régions. Pour vous protéger contre les défaillances d'une région sans copier manuellement les données dans plusieurs régions, utilisez les ressources Google Cloud qui stockent automatiquement les données dans plusieurs régions. Par exemple, utilisez des emplacements multirégionaux BigQuery pour stocker des ensembles de données, ou des buckets Cloud Storage birégionaux et multirégionaux. Si une région devient indisponible, vous pouvez relancer l'exécution du pipeline dans une autre région où les données sont disponibles.
Pour obtenir un exemple d'utilisation des services multirégionaux avec Dataflow, consultez la section Haute disponibilité et redondance géographique.
Gérer les échecs dans les pipelines en cours d'exécution
Une fois qu'une tâche est envoyée et acceptée, les seules opérations valides pour cette tâche sont les suivantes :
- Annulation des tâches par lot
- Mise à jour, drainage ou annulation des tâches de streaming
Vous ne pouvez pas modifier l'emplacement des jobs en cours d'exécution après l'avoir envoyé. Si vous n'utilisez pas FlexRS, les tâches commencent généralement à traiter les données dans les minutes qui suivent leur envoi. Les jobs FlexRS peuvent prendre jusqu'à six heures avant de commencer à traiter des données.
Cette section traite des échecs liés à l'exécution des tâches et des bonnes pratiques à appliquer.
Surveiller les tâches pour identifier et résoudre les problèmes liés aux erreurs temporaires
Dans le cas des jobs par lot, les lots comprenant un élément défaillant sont relancés quatre fois. Dataflow met fin au job lorsqu'un lot a échoué quatre fois. Ce processus permet de résoudre de nombreux problèmes temporaires. Toutefois, en cas d'échec prolongé, le nombre maximal de nouvelles tentatives est généralement atteint rapidement, ce qui permet à la tâche d'échouer rapidement.
Pour la surveillance et la gestion des incidents, configurez des règles d'alerte pour détecter les tâches ayant échoué. Si un job échoue, inspectez les journaux des jobs pour identifier les échecs dus à des éléments de travail ayant échoué et pour lesquels le nombre maximal de nouvelles tentatives est dépassé.
Dans le cas des jobs de traitement par flux, Dataflow relance indéfiniment les éléments de travail ayant échoué. Le job n'est pas arrêté. Cependant, le job peut se bloquer jusqu'à ce que le problème soit résolu. Créez des règles de surveillance pour détecter les signes d'un pipeline bloqué, tels qu'une augmentation de la latence du système et une diminution de la fraîcheur des données. Mettez en œuvre la journalisation des erreurs dans le code de votre pipeline pour vous aider à identifier les blocages du pipeline causés par des éléments de travail qui échouent de manière répétée.
Redémarrer des tâches dans une zone différente en cas de panne de zone
Après le démarrage d'une tâche, les nœuds de calcul Dataflow qui exécutent le code utilisateur sont limités à une seule zone. En cas de panne de zone, les jobs Dataflow sont souvent affectés, en fonction de l'étendue de la panne.
En cas d'interruptions n'affectant que les backends Dataflow, ces backends sont automatiquement migrés vers une zone différente par le service géré afin de pouvoir poursuivre le job. Si le job utilise Dataflow Shuffle, le backend ne peut pas être transféré d'une zone à l'autre. Si une migration de backend Dataflow se produit, les tâches peuvent être temporairement bloquées.
Si une panne de zone se produit, les jobs en cours d'exécution sont susceptibles d'échouer ou de se bloquer jusqu'à ce que la disponibilité de la zone soit restaurée. Si une zone devient indisponible pendant une longue période, vous devez arrêter les jobs (les annuler s'il s'agit de jobs par lot et les drainer s'il s'agit de jobs de traitement par flux), puis les redémarrer afin de laisser Dataflow choisir la zone opérationnelle.
Redémarrer des tâches par lot dans une autre région en cas de panne régionale
Si une panne se produit dans une région où vos jobs Dataflow sont en cours d'exécution, ils peuvent échouer ou être bloqués. Dans le cas des tâches par lot, redémarrez-les dans une autre région si possible. Il est important de vous assurer que vos données sont disponibles dans différentes régions.
Atténuer les pannes régionales en utilisant la haute disponibilité ou le basculement
Pour les jobs de traitement par flux, selon la tolérance aux pannes et le budget de votre application, vous disposez de différentes options pour atténuer les défaillances. S'il s'agit d'une panne régionale, l'option la plus simple et la plus rentable consiste à attendre que la panne disparaisse. Toutefois, si votre application est sensible à la latence ou si le traitement des données ne doit pas être interrompu ou doit reprendre dans les meilleurs délais, les sections suivantes présentent les différentes options.
Haute disponibilité : sensible à la latence, aucune perte de données
Si votre application ne peut pas tolérer de perte de données, exécutez des pipelines dupliqués dans deux régions différentes et demandez-leur d'utiliser les mêmes données. Les mêmes sources de données doivent être disponibles dans les deux régions. Les applications en aval qui dépendent des résultats de ces pipelines doivent pouvoir basculer entre les résultats de ces deux régions. En raison de la duplication des ressources, cette option implique le coût le plus élevé par rapport aux autres options. Pour obtenir un exemple de déploiement, consultez la section Haute disponibilité et redondance géographique.
Basculement : sensible à la latence avec risque de perte de données
Si votre application peut tolérer des pertes de données potentielles, rendez la source de données en streaming disponible dans plusieurs régions. Par exemple, si vous utilisez Pub/Sub, gérez deux abonnements indépendants pour le même sujet, un pour chaque région. En cas de panne régionale, démarrez un pipeline de remplacement dans une autre région et faire en sorte qu'il utilise les données de l'abonnement de sauvegarde.
Relancez l'abonnement de sauvegarde à un moment approprié afin de limiter au maximum la perte de données sans compromettre la latence. Les applications en aval doivent savoir comment basculer vers les résultats du pipeline en cours d'exécution, comme c'est le cas avec l'option de haute disponibilité. Cette option utilise moins de ressources que l'exécution de pipelines dupliqués, car seules les données sont dupliquées.
Haute disponibilité et redondance géographique
Vous pouvez exécuter plusieurs pipelines de streaming en parallèle pour traiter des données à haute disponibilité. Par exemple, vous pouvez exécuter deux tâches de streaming en parallèle dans différentes régions, ce qui fournit une redondance géographique et une tolérance aux pannes pendant le traitement des données.
En tenant compte de la disponibilité géographique des sources de données et des récepteurs, vous pouvez exploiter des pipelines de bout en bout dans une configuration multirégionale à disponibilité élevée. Le schéma suivant illustre un exemple de déploiement.
Ce flux est représenté dans le diagramme suivant :
Pub/Sub s'exécute dans la plupart des régions du monde, ce qui lui permet d'offrir un accès rapide et mondial aux données, tout en vous permettant de contrôler l'emplacement de stockage des messages. Pub/Sub peut stocker automatiquement les messages publiés dans la région Google Cloud la plus proche des abonnés, mais vous pouvez aussi le configurer pour utiliser une région spécifique ou un ensemble de régions à l'aide de règles de stockage de messages.
Pub/Sub distribue ensuite les messages aux abonnés dans le monde entier, quel que soit leur emplacement de stockage. Les clients Pub/Sub n'ont pas besoin de connaître l'emplacement des serveurs auxquels ils se connectent, car les mécanismes d'équilibrage de charge mondiaux dirigent le trafic vers le centre de données Google Cloud le plus proche où les messages sont stockés.
Dataflow s'exécute dans des régions Google Cloud spécifiques. En exécutant des pipelines parallèles dans des régions Google Cloud distinctes, vous pouvez protéger vos tâches contre les défaillances qui affectent une seule région. Le diagramme montre deux instances du même pipeline, chacune s'exécutant dans une région Google Cloud distincte.
BigQuery fournit des emplacements d'ensembles de données régionaux et multirégionaux. Lorsque vous choisissez un emplacement multirégional, votre ensemble de données se trouve dans au moins deux régions géographiques. Le diagramme représente deux pipelines distincts, chacun écrivant dans un ensemble de données multirégional distinct.