Planification pour Code Engine
IBM Cloud® Code Engine prend en charge les types de charges de travail suivants : applications, tâches, fonctions et flottes.
Une application exécute votre code pour servir les demandes HTTP. Outre les demandes HTTP traditionnelles, IBM Cloud® Code Engine prend en charge les applications qui utilisent WebSockets comme protocole de communication. Le nombre d'instances d'une application en cours d'exécution est automatiquement augmenté ou réduit (jusqu'à zéro) en fonction des requêtes entrantes et de vos paramètres de configuration. Une application contient une ou plusieurs révisions. Une révision représente une version non modifiable des propriétés de configuration de l'application. Chaque mise à jour d'une propriété de configuration d'application crée une nouvelle révision de l'application.
Une tâche exécute en parallèle une ou plusieurs instances de votre code exécutable. Contrairement aux applications qui gèrent les demandes HTTP, les travaux sont conçus pour s'exécuter une seule fois et prendre fin. Lorsque vous créez un travail, vous pouvez spécifier les informations de configuration de charge de travail qui sont utilisées à chaque fois que le travail est exécuté.
Une fonction est un extrait de code sans état qui exécute des tâches lorsqu'il est invoqué par des requêtes HTTP. Avec les fonctions IBM Code Engine, vous pouvez exécuter votre logique métier de manière évolutive et sans serveur. Les fonctions d' IBM Code Engine fournissent un environnement d'exécution optimisé pour prendre en charge les scénarios de faible latence et d'extension rapide. Votre code de fonction peut être écrit dans un runtime géré qui inclut des versions spécifiques de Node.js ou de Python.
Une flotte, également appelée flotte sans serveur, exécute une ou plusieurs instances de code utilisateur pour réaliser un ensemble de tâches spécifiées. Les flottes peuvent traiter de grandes charges de travail à forte intensité de calcul, permettre de contrôler les profils des machines et fonctionner avec des ressources GPU. Les flottes sont à locataire unique, mettent en œuvre une file d'attente dynamique pour les tâches et offrent un contrôle total sur la configuration du profil de la machine. En outre, les flottes peuvent se connecter à des nuages privés virtuels (VPC) pour accéder en toute sécurité aux données et aux services des utilisateurs.
| Caractéristique | Application | Travail | Fonction | Flotte |
|---|---|---|---|---|
| Temps d'exécution (durée) | A exécution longue (10 minutes par demande) | Longue durée (jusqu'à 24 heures) | Courte durée (2 minutes ou moins) | Longue durée (de quelques minutes à quelques semaines) |
| Temps d'attente de démarrage | Moyen | Début planifié | Faible | Faible |
| Résiliation | Exécution en continu | Exécution jusqu'à la fin | Exécution jusqu'à la fin | Exécution jusqu'à la fin |
| Appel | A la demande ou en cours d'exécution permanente | Planifiée | Sur demande, instantané | Planifiée |
| Modèle de programmation | Génération et exécution basées sur un conteneur | Génération et exécution basées sur un conteneur | Fichiers de code source spécifiques au langage et métadonnées de dépendance | Génération et exécution basées sur un conteneur |
| Parallélisme | Exécution parallèle, flexible | Exécution parallèle faible à moyenne | Exécution parallèle élevée | Exécution en parallèle et mise en file d'attente |
| Extension | En fonction du nombre de demandes | En fonction de la définition de charge de travail du travail | Basé sur des événements ou des appels directs | En fonction du nombre de tâches et d'instances simultanées |
| Isolement | Multi-locataire | Multi-locataire | Multi-locataire | Service exclusif |
| Prise en charge de GPU | Non | Non | Non | Oui |
| Contrôle de la configuration des machines | Aucun contrôle | Aucun contrôle | Aucun contrôle | contrôle total |
| Connectivité VPC | Via Private Path | Via Private Path | Via Private Path | Natif (via un pool de sous-réseaux) |
| Optimisé pour | Charge de travail longue durée et très complexe et ajout à la demande | Charges de travail planifiées ou planifiées avec des demandes de ressources élevées | Temps de démarrage et ajout rapide | Charges de travail à grande échelle et à forte intensité de calcul |
Cas d'utilisation Code Engine
Il existe une grande variété de cas d'utilisation pour Code Engine, dont voici quelques exemples vous permettant de vous lancer.
- Avoir une certaine expérience des conteneurs, mais aucune compétence ou aucun budget en matière de gestion de clusters
- Vous êtes un développeur qui a une bonne connaissance des conteneurs. Vous souhaitez toutefois vous affranchir de la complexité ou de la consommation de temps inhérentes à la gestion d'un cluster. Avec Code Engine, vous n'avez plus besoin de vous soucier des compétences requises ou du temps nécessaire pour gérer un cluster. En effet, Code Engine élimine ces complexités et c'est l'équipe IBM qui gère l'infrastructure de Maria dans le cadre du service IBM Cloud.
- Charges de travail avec des pics par intermittence
- Votre site Web est très sollicité pendant le week-end et moins durant la semaine. Dans la mesure où ce site Web connaît des pics d'activité suivis de périodes d'inactivité, Code Engine est une solution adaptée. Avec Code Engine, l'application de site Web procède automatiquement à la mise à l'échelle par augmentation des instances d'application lors de l'accroissement du trafic, puis à la mise à l'échelle par réduction (et même jusqu'à zéro) lors des périodes d'inactivité.
- Charges de travail par lots intégrées au stockage
- Votre travail par lots traite le salaire des employés à la fin de chaque mois. Comme cette tâche s'exécute une fois par mois, elle reste inactive la plupart du temps, mais consomme beaucoup de ressources CPU et de mémoire lorsqu'elle s'exécute. Le travail par lots doit s'intégrer au stockage afin de stocker les résultats. En utilisant Code Engine, vous pouvez intégrer le travail par lots à IBM Cloud Object Storage et n'êtes facturé que pour les ressources utilisées par le travail lors de son exécution. Lorsque le travail est inactif, il ne consomme aucune ressource et, par conséquent, il n'engendre aucun frais. Toutefois, le travail peut entraîner des coûts avec l'instance IBM Cloud Object Storage.
- Apport de sa propre charge de travail
- Une partie de votre travail consiste à créer des images et à les déployer. Vous possédez une certaine expérience en matière de création et de déploiement d'images de conteneur, mais vous souhaitez simplifier ce processus de manière à pouvoir vous concentrer sur d'autres tâches. Avec Code Engine, vous pouvez générer des images et les déployer directement à partir de la même interface, ce qui simplifie les tâches quotidiennes et libère du temps pour développer davantage de code.
- Tests, validations de principe ou mises à l'épreuve
- Vous souhaitez en apprendre davantage sur l'architecture reposant sur un conteneur. Votre équipe a développé une application, mais elle souhaite la tester avant de la présenter aux parties prenantes. Cette application étant de taille réduite, elles ne souhaitent pas avoir à payer un cluster dédié, aussi petit soit-il. Dans ce cas, vous pouvez tester l'application puis fournir une démonstration de faisabilité de la conception aux parties prenantes sans qu'elles aient à supporter les coûts inhérents à un cluster dédié.
Quand utiliser une application, un travail ou une fonction
Les applications et les travaux sont très similaires ; en fin de compte, ils exécutent du code. Cependant, certains aspects clés doivent être pris en compte lorsque vous décidez de structurer votre code sous forme d'application ou de tâche.
- Votre code a-t-il besoin de répondre à un évènement ?
-
Dans le contexte de Code Engine, toute demande HTTP entrante (même la demande de chargement d'une page Web) ou appel API REST est considéré comme un événement. Le concept d'être basé sur un évènement est souvent le critère clé lorsque vous choisissez entre une application ou un travail car, par définition, les applications sont exécutées en raison d'une requête HTTP alors que des travaux sont exécutés à la suite d'un appel.
-
Si vous savez que votre charge de travail répond à des demandes HTTP entrantes, il est judicieux de choisir l'application. Cependant, si votre charge de travail est exécutée puis terminée, un travail sera plus adapté.
- Comment votre code est-il mis à l'échelle ?
-
Les applications et les travaux sont évolutifs. Les applications sont mises à l'échelle en réponse à des critères mesurables en temps réel, tels que le nombre de demandes entrantes actives, car chaque instance de votre application doit pouvoir traiter uniquement un certain nombre de demandes simultanées à la fois. Les travaux sont mis à l'échelle en fonction du nombre d'instances spécifié à la création du travail.
-
Si vous savez qu'un nombre spécifique d'instances de votre code doit être exécuté et que chaque instance peut être exécutée sans demande HTTP entrante, un travail est idéal. Cependant, si le nombre d'instances doit être mis à l'échelle dynamiquement en fonction de la charge HTTP entrante, les applications sont mieux adaptées.
Scénarios courants pour Code Engine
Lisez certains de ces scénarios courants pour mieux comprendre quand choisir un type de charge de travail spécifique.
- Votre charge de travail nécessite-t-elle un temps d'attente faible ou est-elle interactive ?
- Si votre charge de travail requiert qu'un client ou qu'un utilisateur attende de façon synchrone la réponse à la demande et que la réponse doit être disponible en quelques millisecondes, utilisez une application. Les applications fournissent un nœud final accessible en externe et répondent de manière synchronisée à la demande. Les sites Web, les agents conversationnels et les applications mobiles sont des exemples de ce type de charge de travail. Utilisez des applications.
- Votre calcul est-il simple et nécessite-t-il une quantité faible d'unité centrale, de mémoire et d'entrées-sorties ?
- Si votre charge de travail est légère et nécessite une quantité faible d'unité centrale, de mémoire et d'E-S, l'option simultanée, disponible pour les applications, peut être utile. Un serveur d'API qui fournit des opérations de base et qui est sauvegardé avec une base de données NoSQL est un exemple classique de ce type de charge de travail. En général, ces types de demande présentent une faible quantité de données et requièrent peu de mémoire ou moins de cycles d'unité centrale. Avec un accès concurrent plus élevé, l'application peut traiter les données d'une première demande alors que la seconde demande est en attente d'entrée-sortie. Etant donné que les exigences relatives à l'unité centrale et à la mémoire sont faibles, de nombreuses demandes peuvent être exécutées simultanément. Utilisez des applications.
- Votre calcul est-il lié à l'unité centrale, à la mémoire ou aux entrées-sorties ?
- Pour traiter une quantité spécifique de données, où chaque bloc de données est volumineux et nécessite une quantité importante d'unité centrale et de mémoire, les travaux constituent généralement le meilleur choix. Cependant, si la charge de travail requiert un modèle demande-réponse, il est également possible d'utiliser des applications. Dans les deux cas, la tâche de calcul s'exécute avec un accès concurrent unique. Chaque instance d'application ou tâche de travail ne traite qu'une seule demande ou un bloc de données simultanément pour tirer pleinement parti des ressources configurées pour l'instance. Le parallélisme est obtenu par le nombre d'instances ou de tâches, où le coût de création d'une tâche supplémentaire est négligeable en raison des contraintes de ressources élevées. Le traitement des données d'image dans un compartiment Object Storage ou dans des modèles d'apprentissage automatique de service en est un exemple classique. Utilisez des applications ou des travaux.
- L'exécution de votre calcul est-elle longue ?
- Si l'exécution du calcul est longue, les travaux constituent le meilleur choix en raison de leur nature asynchrone. La durée maximale des applications est toujours limitée car le maintien d'une connexion ouverte à l'échelle est coûteux. Les modèles d'apprentissage automatique ou l'optimisation des hyperparamètres sont des charges de travail classiques. Utilisez des travaux.
- Pouvez-vous spécifier l'accès concurrent de votre calcul dès le départ ?
- Si vous savez combien de calculs vous devez effectuer, vous pouvez exécuter un travail avec le nombre exact d'instances jusqu'à ce qu'il se termine. Le réglage des hyperparamètres ou l'apprentissage d'un réseau de neurones constituent des exemples classiques. Utilisez des travaux.
- Votre charge de travail réagit-elle à un événement spécifique ?
- Si votre charge de travail doit réagir à un événement, par exemple une validation Git qui est envoyée dans votre référentiel, un objet qui est envoyé par téléchargement dans un compartiment Object Storage ou un document qui est modifié dans votre base de données, utilisez des applications. Celles-ci fournissent un noeud final qui peut être configuré pour recevoir des événements depuis la source d'événement. Utilisez des applications.
- Devez-vous traiter une grande quantité de données en peu de temps en réponse à des événements ou des demandes ?
- Si votre charge de travail requiert une réponse rapide à des demandes ou des événements non prévus, les applications sont généralement mieux adaptées car elles sont mises à l'échelle dynamiquement, même à partir de zéro. Utilisez des applications.
- Combinaison d'applications et de travaux
- Vous pouvez même combiner des applications et des travaux. Par exemple, une application peut démarrer un travail pour externaliser des calculs spécifiques. Les travaux peuvent également interroger une application. L'entraînement et la mise à disposition de modèles d'apprentissage automatique est un exemple classique de combinaison de travaux et d'applications. En général, des travaux sont utilisés pour entraîner les modèles et des applications sont utilisées pour les servir. Utilisez des applications et des travaux.