Ce guide présente l'environnement flexible pour les utilisateurs qui connaissent déjà l'environnement standard. Vous y trouverez une description des similitudes et des principales différences entre les deux environnements, ainsi que des recommandations architecturales générales pour les applications utilisant les deux environnements.
Pour accéder au mappage des services disponibles dans l'environnement standard vers leurs analogues dans un environnement flexible, consultez la page Migrer des services depuis l'environnement standard vers l'environnement flexible.
Similitudes et principales différences
Les deux environnements fournissent l'infrastructure de déploiement, de service et de scaling d'App Engine. Les principales différences concernent l'exécution de votre application par l'environnement, l'accès de l'application aux services externes, l'exécution de l'application en local et le scaling de l'application. Vous pouvez également consulter un résumé de ces différences sur la page Choisir un environnement.
Exécution de l'application
Dans l'environnement standard, l'application s'exécute sur une instance légère à l'intérieur d'un bac à sable, Ce bac à sable limite les capacités de votre application. Par exemple, le bac à sable permet uniquement à votre application d'utiliser un ensemble limité de bibliothèques binaires, et votre application ne peut pas écrire sur le disque. L'environnement standard limite également les options de processeur et de mémoire disponibles pour votre application. En raison de ces restrictions, la plupart des applications standards App Engine sont des applications Web sans état, qui répondent rapidement aux requêtes HTTP.
À l'inverse, l'environnement flexible exécute l'application dans des conteneurs Docker sur des machines virtuelles (VM) Google Compute Engine, lesquelles comportent moins de restrictions. Vous pouvez par exemple utiliser le langage de programmation de votre choix, écrire sur le disque, utiliser la bibliothèque de votre choix et même exécuter plusieurs processus. L'environnement flexible vous permet également de choisir n'importe quel type de machine Compute Engine pour vos instances, afin que votre application ait accès à davantage de mémoire et de processeurs.
Accéder à des services externes
Dans l'environnement standard, votre application accède généralement à des services tels que Datastore via les API google.appengine intégrées. En revanche, ces API ne sont plus disponibles dans l'environnement flexible. Vous devez alors utiliser les bibliothèques clientes Google Cloud. Votre application bénéficiera d'une plus grande portabilité, car ces bibliothèques clientes fonctionnent partout. Si nécessaire, les applications qui s'exécutent dans l'environnement flexible peuvent généralement s'exécuter sur Google Kubernetes Engine ou Compute Engine sans modification importante.
Développement local
Dans l'environnement standard, vous exécutez généralement votre application en local à l'aide du SDK App Engine. Le SDK gère l'exécution de votre application et émule les services App Engine. Dans l'environnement flexible, l'exécution de votre application ne passe pas par le SDK. Les applications conçues pour l'environnement flexible doivent être écrites comme des applications Web standards pouvant être exécutées n'importe où. Comme évoqué précédemment, l'environnement flexible exécute simplement votre application dans un conteneur Docker. En d'autres termes, il vous suffit d'exécuter directement l'application pour la tester en local. Par exemple, pour exécuter une application Python à l'aide de Django, exécutez simplement python manage.py runserver.
Autre différence majeure : les applications de l'environnement flexible exécutées en local utilisent des services Cloud Platform réels, tels que Datastore. Utilisez un projet distinct pour réaliser les tests en local et, le cas échéant, utilisez des émulateurs.
Caractéristiques du scaling
Bien que les deux environnements utilisent l'infrastructure de scaling automatique d'App Engine, ils évoluent différemment. L'environnement standard peut évoluer très rapidement de zéro instance à plusieurs milliers. Au contraire, l'environnement flexible doit comporter au moins une instance en cours d'exécution pour chaque version active de votre application, et son déploiement peut prendre plus de temps en fonction du trafic.
L'environnement standard utilise un algorithme d'autoscaling conçu sur mesure, tandis que l'environnement flexible emploie l'autoscaler Compute Engine. Notez que l'environnement flexible n'est pas compatible avec toutes les options d'autoscaling disponibles avec Compute Engine. App Engine respecte toutes les réservations de VM Compute Engine que vous avez déjà dans une région correspondant à votre configuration. Disposer d'une réservation de VM augmente la probabilité que vous receviez une allocation de ressources lors d'une manque temporaire de ressources.
Il est recommandé aux développeurs de tester le comportement de leur application dans des conditions variées. Par exemple, vous devez vérifier comment l'autoscaling répond lorsqu'une application liée au processeur devient liée aux E/S quand des appels à des services distants entraînent une latence élevée.
Vérifications d'état
L'environnement standard ne réalise pas de vérifications d'état pour déterminer s'il convient ou non d'envoyer du trafic vers une instance. L'environnement flexible, au contraire, permet aux développeurs d'applications d'écrire leurs propres gestionnaires de vérification de l'état, utilisés par l'équilibreur de charge pour déterminer si le trafic peut être envoyé à une instance ou s'il convient d'appliquer une procédure d'autoréparation. Les développeurs doivent faire preuve de vigilance lorsqu'ils ajoutent une logique aux vérifications d'état. Par exemple, si la vérification de l'état effectue un appel à un service externe, une défaillance temporaire de ce service peut rendre inopérationnelles toutes les instances, voire entraîner une défaillance en cascade.
Abandonner des requêtes en cas de surcharge
Dans le cadre d'une stratégie visant à éviter les défaillances en cascade, il est possible d'abandonner des requêtes en cas de surcharge des applications. Dans l'environnement standard, cette fonctionnalité est intégrée à la couche de routage du trafic. Dans l'environnement flexible, pour les applications dont le nombre de requêtes par seconde est très élevé, nous recommandons aux développeurs d'y intégrer cette fonctionnalité d'abandon de trafic en surcharge, en limitant le nombre de requêtes simultanées.
Vous pouvez vérifier que votre application d'environnement flexible n'est pas exposée à ce type de défaillance en créant une version avec une limite du nombre maximal d'instances. Ensuite, augmentez progressivement le trafic jusqu'à ce que des requêtes soient abandonnées. Vous devez vous assurer que votre application n'échoue pas aux vérifications d'état lors d'une surcharge.
Pour Java, les applications Java utilisant l'environnement d'exécution Jetty peuvent configurer le filtre de qualité de service pour mettre en œuvre l'abandon en cas de surcharge. Vous pouvez définir le nombre maximal de requêtes simultanées traitées par les applications, ainsi que la durée pendant laquelle les requêtes seront mises en file d'attente à l'aide de cette fonctionnalité.
Tailles des instances
Les instances de l'environnement flexible peuvent avoir des limites de processeur et de mémoire plus élevées que celles de l'environnement standard. Cela leur permet d'exécuter des applications nécessitant une utilisation intensive de la mémoire et des processeurs. Toutefois, le risque de bugs liés à la simultanéité sera plus important en raison de l'augmentation du nombre de threads au sein d'une seule instance.
Les développeurs peuvent se connecter en SSH sur une instance de l'environnement flexible et obtenir un vidage de thread pour résoudre ce type de problème.
Par exemple, si vous utilisez l'environnement d'exécution Java, vous pouvez exécuter la commande suivante :
$ ps auwwx | grep java $ sudo kill -3$ sudo docker logs gaeapp
Délai maximal avant expiration de la requête
Bien que le délai avant expiration de la requête dans l'environnement standard varie en fonction du type de scaling sélectionné, l'environnement flexible impose toujours un délai avant expiration de 60 minutes. Pour éviter que les requêtes restent en suspens pendant l'ensemble de ce délai de 60 minutes et qu'elles utilisent potentiellement tous les threads du serveur Web :
Lorsque vous appelez des services externes, spécifiez un délai avant expiration.
Mettez en œuvre un filtre servlet pour interrompre les requêtes qui prennent trop de temps (60 secondes, par exemple). Assurez-vous que votre application peut revenir à un état cohérent une fois que le filtre a interrompu une requête.
Gestion des threads
Dans l'environnement standard, les environnements d'exécution Java antérieurs à Java 8 ne pouvaient utiliser que des threads créés à l'aide du SDK de l'environnement standard App Engine. Les développeurs qui transfèrent une application depuis un environnement d'exécution Java de première génération de l'environnement standard vers l'environnement flexible doivent passer à l'utilisation de bibliothèques de threads natives. Les applications nécessitant un très grand nombre de threads peuvent fonctionner plus efficacement à l'aide des pools de threads qu'avec la création explicite de threads.
Migration du trafic
L'environnement standard propose une fonctionnalité de migration du trafic qui transfère progressivement celui-ci vers une nouvelle version, afin de minimiser les pics de latence. Consultez la documentation sur la migration du trafic pour savoir comment éviter un pic de latence lors de la transition vers une nouvelle version.
Échecs de zone unique
Les applications de l'environnement standard disposent d'un seul site d'hébergement. Cela signifie que toutes les instances de l'application résident dans une seule zone de disponibilité. En cas d'échec dans cette zone, l'application démarre de nouvelles instances dans une autre zone de la même région, et l'équilibreur de charge achemine le trafic vers les nouvelles instances. Vous constaterez un pic de latence due aux requêtes de chargement, ainsi qu'une purge de Memcache.
Les applications de l'environnement flexible utilisent des groupes d'instances gérés régionaux. Autrement dit, les instances sont réparties entre plusieurs zones de disponibilité au sein d'une même région. En cas de défaillance d'une zone, l'équilibreur de charge interrompt l'acheminement du trafic vers cette zone. Si vous avez configuré l'autoscaling pour une migration à chaud de vos instances avec le moins de perturbations possible, vous constaterez une brève période de surcharge avant que l'autoscaling ne crée d'autres instances.
Comparaisons des coûts
De nombreux facteurs entrent en compte dans la comparaison des coûts des charges de travail selon l'environnement d'exécution, standard ou flexible, y compris :
- le prix payé par MCycle ;
- la capacité processeur des plates-formes, qui a un impact sur les performances de traitement par MCycle ;
- la mesure dans laquelle les instances peuvent être exécutées à chaud sur chaque plate-forme ;
- le coût des déploiements, qui peut varier en fonction de la plate-forme et peut être conséquent si vous utilisez le déploiement continu pour votre application ;
- le temps d'exécution.
Vous devrez réaliser des tests afin de déterminer le coût de votre charge de travail sur chaque plate-forme. Dans un environnement flexible, vous pouvez appliquer le nombre de requêtes par seconde par cœur en tant que proxy pour évaluer la rentabilité de votre application et déterminer l'incidence d'un changement sur les coûts. L'environnement standard ne fournit pas un tel mécanisme permettant d'obtenir des métriques en temps réel sur la rentabilité de votre application. Vous devez effectuer une modification et attendre la fin du cycle de facturation quotidien.
Microservices
L'environnement standard permet une authentification sécurisée entre les applications à l'aide de l'en-tête de requête X-Appengine-Inbound-Appid. L'environnement flexible ne propose pas une telle fonctionnalité. La méthode conseillée pour sécuriser l'authentification entre les applications est alors d'utiliser OAuth.
Déploiement
Les déploiements dans un environnement standard sont généralement plus rapides que dans un environnement flexible. En effet, il est plus rapide de faire évoluer une version existante dans un environnement flexible que de déployer une nouvelle version, car la programmation réseau de cette version constitue généralement l'étape la plus longue. L'une des stratégies pour accélérer les rollbacks dans un environnement flexible consiste à conserver une version connue de qualité, réduite à une instance unique. Vous pouvez ensuite augmenter la capacité de cette version et lui acheminer tout le trafic à l'aide de la fonction de répartition du trafic.
Quand utiliser l'environnement flexible
L'environnement flexible est conçu pour compléter l'environnement standard. Si une application existante est exécutée dans l'environnement standard, il n'est généralement pas nécessaire de la migrer dans son intégralité vers l'environnement flexible. Identifiez plutôt les parties de votre application qui requièrent davantage de processeurs, plus de RAM, une bibliothèque ou un programme tiers spécialisé, ou qui nécessitent des actions impossibles à réaliser dans l'environnement standard. Une fois ces éléments identifiés, créez des petits services App Engine utilisant un environnement flexible pour ne gérer que ces éléments. Votre service existant qui s'exécute dans l'environnement standard peut appeler les autres services via le protocole HTTP, Cloud Tasks ou Cloud Pub/Sub.
Par exemple, si une application Web existante s'exécute dans l'environnement standard et que vous souhaitez ajouter une nouvelle fonctionnalité pour convertir des fichiers au format PDF, vous pouvez écrire un microservice distinct qui s'exécute dans l'environnement flexible pour ne gérer que la conversion au format PDF. Ce microservice peut être un programme simple composé d'un ou deux gestionnaires de requêtes. Il peut installer et utiliser n'importe quel programme Linux disponible pour faciliter la conversion, comme unoconv.
Votre application principale demeure dans l'environnement standard et peut appeler ce microservice directement via HTTP. Si vous prévoyez que la conversion prendra beaucoup de temps, l'application peut utiliser les services Cloud Tasks ou Pub/Sub pour placer les requêtes en file d'attente.