Planification fiable des tâches sur Google Compute Engine avec Cloud Scheduler

Dans les systèmes distribués, tels qu'un réseau d'instances Compute Engine, il est difficile de planifier des tâches de manière fiable, car toute instance individuelle peut devenir indisponible en raison d'un autoscaling ou d'un partitionnement du réseau.

En utilisant Cloud Scheduler pour la planification et Google Cloud Pub/Sub pour la messagerie distribuée, vous pouvez développer une application permettant de planifier des tâches de manière fiable sur une flotte d'instances Compute Engine. Si vous avez besoin de planifier et d'orchestrer des flux de travail complexes sur d'autres produits ou clouds, envisagez plutôt d'utiliser Cloud Composer.

Cet article en trois parties comprend les éléments suivants :

Planifier des tâches de manière fiable dans Compute Engine

Cron est l'outil standard pour la planification de tâches récurrentes sur les systèmes Unix. À mesure que vos systèmes augmentent en complexité et deviennent distribués, l'exécution de Cron sur une seule machine peut constituer un point de défaillance critique. En effet, toute instance peut s'arrêter en raison d'un autoscaling, ou si son segment de réseau est séparé des systèmes avec lesquels elle doit communiquer.

Cloud Scheduler fournit un service d'entreprise entièrement géré qui vous permet de planifier des événements. Après la planification d'une tâche, Cloud Scheduler appelle les gestionnaires d'événements configurés, qui peuvent être des services App Engine, des points de terminaison HTTP ou des abonnements Cloud Pub/Sub.

Pour exécuter des tâches sur votre instance Compute Engine en réponse à des événements Cloud Scheduler, vous devez relayer ces événements vers ces instances. Pour cela, vous pouvez appeler un point de terminaison HTTP qui s'exécute sur vos instances Compute Engine. Une autre option consiste à transmettre des messages de Cloud Scheduler à vos instances Compute Engine à l'aide de Cloud Pub/Sub. L'exemple présenté ici illustre le deuxième modèle de conception.

Le diagramme suivant fournit une vue d'ensemble de l'architecture de ce modèle de conception.

Schéma simplifié de l'architecture

Dans cette implémentation, vous planifiez des événements dans Cloud Scheduler, puis transmettez ces événements aux instances de Compute Engine à l'aide de Cloud Pub/Sub.

Un utilitaire basé sur vos instances Compute Engine s'abonne à des sujets Cloud Pub/Sub et exécute les tâches Cron en réponse aux événements qu'il extrait de ces sujets. L'utilitaire exécute des scripts standards, vous n'avez donc pas besoin de modifier vos scripts Cron actuels pour les utiliser dans cet exemple.

En utilisant Cloud Pub/Sub pour dissocier la logique de planification des tâches de la logique exécutant les commandes sur Compute Engine, vous pouvez mettre à jour vos scripts Cron dès que vous en avez besoin, sans avoir à mettre à jour l'application Cloud Scheduler. Vous pouvez également modifier votre planification de tâches sans mettre à jour l'utilitaire basé sur vos instances Compute Engine.

Quota

Les tâches Cron étant généralement peu nombreuses et exécutées une fois seulement par heure, jour ou semaine, ce modèle de conception ne devrait pas amener à un dépassement des quotas Cloud Scheduler, conçus pour autoriser des dizaines de requêtes par minute et des milliers par jour. Si c'est malgré tout le cas, envisagez d'autres modèles de mise en œuvre, tels que la gestion du minutage des tâches directement dans le code de l'application.

Coût

Vous pouvez essayer gratuitement l'exemple de mise en œuvre de ce modèle de conception avec la version gratuite de GCP, si vous n'utilisez pas déjà ces ressources pour d'autres applications. Si vos quotas gratuits sont utilisés par d'autres applications de votre projet, les coûts seront déterminés par votre utilisation totale des ressources Compute Engine, Cloud Scheduler et Cloud Pub/Sub.

La tarification de Cloud Scheduler est basée sur le nombre de tâches planifiées. La tarification de Compute Engine est basée sur le type et la durée des instances utilisées. La tarification de Cloud Pub/Sub est basée sur le volume de données envoyé.

Par exemple, si vous exécutez l'exemple de mise en œuvre présenté dans la section suivante pendant une heure, puis supprimez l'ensemble des ressources GCP associées, le coût sera d'environ 1 centime. Pour une ventilation des coûts de cette estimation et le calcul des coûts potentiels de vos propres cas d'utilisation, utilisez le simulateur de coût.

Exemple de mise en œuvre d'un modèle de conception

Un exemple de mise en œuvre de ce modèle de conception, nommé Exemple : Planification fiable des tâches sur Google Compute Engine, est disponible sur GitHub.

L'exemple comprend deux parties :

  • Des instructions de configuration pour Cloud Scheduler et Cloud Pub/Sub.

  • Un utilitaire qui s'exécute sur Compute Engine. Cet utilitaire surveille un sujet Cloud Pub/Sub. Lorsqu'il détecte un nouveau message, il exécute, en local, la commande correspondante sur le serveur.

Le fichier README inclus décrit l'exemple plus en détail, ainsi que la procédure de son exécution sur GCP.

Pour le cas spécifique de démarrage et d'arrêt d'instances sur une planification, consultez la section Planifier des instances de calcul avec Cloud Scheduler.

Mettre en œuvre un modèle de conception et un exemple

L'exemple illustre un moyen de mettre en œuvre une solution de planification fiable pour Compute Engine, à l'aide de Cloud Scheduler. Il s'agit d'un modèle de conception utile, car il sépare sur l'instance Compute Engine la logique de planification de la logique d'exécution des commandes, ce qui permet de modifier l'emplacement et l'exécution de vos tâches sans avoir à mettre à jour la logique de planification.

Le schéma suivant montre le flux de messages associé à cet exemple. En spécifiant les instances abonnées à un sujet donné, vous pouvez contrôler si une tâche Cron s'exécute sur une ou plusieurs instances.

Schéma détaillé de l'architecture

Un autre avantage de cette architecture, c'est le contrôle qu'elle vous donne sur la manière dont les tâches Cron sont routées vers vos instances.

Vous pouvez envoyer différents messages Cron à différents ensembles de serveurs, comme l'illustrent les sujets A et C de Cloud Pub/Sub. Les tâches du sujet A sont envoyées à un seul serveur abonné, alors que celles du sujet C sont envoyées à plusieurs serveurs abonnés. Utilisez cette stratégie pour exécuter un ensemble de commandes sur votre serveur Web et un autre sur vos autres serveurs.

Une autre option consiste à exécuter une commande sur l'un des serveurs. Ceci est illustré par la rubrique B. Dans ce cas, plusieurs serveurs partagent un seul abonnement. Les messages publiés dans la rubrique B sont gérés par le premier serveur à revendiquer ce message et la commande correspondante ne s'exécute que sur ce serveur. Vous pouvez l'utiliser pour effectuer des analyses de données nocturnes ne devant être exécutées que sur un seul serveur.

Étapes suivantes

Vous pouvez modifier l'exemple et l'utiliser comme modèle pour votre propre application. Voici quelques conseils pour commencer :

  • Mettez à jour la configuration de Cloud Scheduler pour spécifier vos propres messages Cron. Vous pouvez mettre à jour la tâche Cron directement, comme décrit dans la section Créer et configurer des tâches Cron.

  • Mettez à jour test_executor.py pour exécuter un script au lieu de logger_sample_task.py, ou bien écrivez votre propre utilitaire Executor.

  • Au lieu de lancer manuellement l'utilitaire sur Compute Engine et de l'exécuter en tant que processus de premier plan, vous pouvez le lancer automatiquement en tant que daemon via un outil système ou tiers, tel que systemd ou Supervisor.

  • Ni Cloud Scheduler, ni Cloud Pub/Sub n'offrent de garanties strictes de livraison "exactement une fois". Bien que peu probable, il est possible qu'un message soit livré en double. Si l'exécution répétée d'une tâche spécifique crée un résultat indésirable, utilisez un outil de verrouillage distribué cohérent, tel que Zookeeper, pour vous assurer que la tâche n'est effectivement exécutée qu'une seule fois et par une seule instance.

  • Lorsque vous planifiez des tâches, suivez les meilleures pratiques Cron et assurez-vous que les tâches sont suffisamment éloignées pour pouvoir être traitées avant leur prochaine exécution.

  • Déterminez si l'exécution d'instances Compute Engine est nécessaire pour toutes les tâches. Une autre solution consiste à déclencher Cloud Functions en réponse aux messages Cloud Pub/Sub. Cloud Functions peut appeler des API Cloud, mais elles ne peuvent pas exécuter directement de scripts shell. Si vous devez exécuter des scripts shell, vous pouvez appeler l'API Compute Engine pour créer des instances temporaires Compute Engine afin d'exécuter des scripts. Ces instances peuvent simplement se fermer lorsque les tâches sont terminées. Cela vous donne la possibilité de terminer les tâches peu de temps après l'événement, avec un coût minimal.

Testez d'autres fonctionnalités de Google Cloud Platform. Découvrez nos tutoriels.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…