Optimisation et gestion des applications dans SAP BTP, exécution Cloud Foundry

Implémentation des fonctionnalités de mise à l'échelle dans SAP BTP, exécution Cloud Foundry

Objective

After completing this lesson, you will be able to implémentez efficacement les fonctionnalités de mise à l'échelle dans SAP BTP, exécution Cloud Foundry.

Mise à l'échelle des fonctionnalités dans SAP BTP, exécution Cloud Foundry de manière efficace

Introduction

Votre entreprise a récemment déployé des applications sur SAP BTP, exécution Cloud Foundry et doit comprendre les fonctionnalités de mise à l'échelle pour gérer efficacement les fluctuations du trafic et de la demande des applications.

Mise à l'échelle horizontale et verticale

SAP BTP, exécution Cloud Foundry offre de puissantes fonctionnalités de mise à l'échelle, y compris la mise à l'échelle horizontale et verticale. Le choix entre la mise à l'échelle horizontale et verticale dépend des exigences spécifiques de votre application. Voici quelques détails clés sur les fonctionnalités de mise à l'échelle dans SAP BTP, exécution Cloud Foundry :

Mise à l'échelle horizontale

Également appelé scaling out, il s'agit du processus d'ajout d'instances supplémentaires pour prendre en charge votre application afin de gérer une charge accrue. Dans le contexte de SAP BTP et de Cloud Foundry, cela signifie augmenter le nombre d'instances d'application, ce qui garantit que l'application reste réactive et performante, même si la charge de l'application augmente.

Dans SAP BTP Cloud Foundry, vous pouvez facilement faire évoluer vos applications horizontalement à l'aide de SAP BTP, de l'interface de ligne de commande d'exécution Cloud Foundry (CLI), du cockpit SAP BTP ou du service Application Autoscaler. La plateforme distribuera automatiquement les instances sur différentes machines virtuelles et zones de disponibilité pour garantir une haute disponibilité et une tolérance aux pannes.

Mise à l'échelle verticale

Également appelé mise à l'échelle, il s'agit du processus d'ajout de plus de ressources, telles que la mémoire, le disque et le processeur, à votre application pour gérer une charge accrue. Dans le contexte de SAP BTP Cloud Foundry, il s'agit d'augmenter le quota de mémoire et de disque pour vos instances d'application. La quantité de CPU est automatiquement fournie par la plate-forme de telle sorte que les applications obtiennent une part CPU garantie de θ cœur par Go de mémoire d'instance. La mémoire d'instance maximale par application est de 16 Go, ce qui permet une mise à l'échelle verticale jusqu'à 4 UC. Pour plus d'informations sur la limite de mémoire à jour, voir la section Limites.

Dans SAP BTP Cloud Foundry, vous pouvez faire évoluer efficacement vos applications verticalement à l'aide de SAP BTP, de l'interface de ligne de commande d'exécution Cloud Foundry (CLI) et du cockpit SAP BTP. Vous pouvez définir la mémoire et l'espace disque pour chaque instance d'application lors du push ou de la mise à l'échelle de votre application. La mise à l'échelle verticale ajuste automatiquement les ressources affectées à votre application, ce qui améliore ses performances. Cependant, il est important de noter que cela peut entraîner une augmentation des coûts à mesure que des ressources supplémentaires sont utilisées.

Dans le contexte des applications multi-locataires, chaque locataire ou consommateur accède à l'application via une URL dédiée. L'environnement d'application les identifie par leur ID de locataire unique, garantissant ainsi l'isolation des données en distinguant les demandes des différents locataires consommateur en fonction de l'ID du locataire.

Les ressources de chaque module, telles que le quota de mémoire et de disque, peuvent être définies dans le fichier mta.yaml. Lorsque vous déployez le MTA, la plateforme alloue automatiquement les ressources spécifiées à chaque instance d'application.

Limites

L'exécution de SAP BTP, Cloud Foundry impose certaines limites à l'utilisation et à la mise à l'échelle des ressources pour garantir une affectation efficace des ressources et une utilisation équitable entre les applications. Ces limites peuvent être personnalisées grâce à l'utilisation de quotas d'organisation et d'espace, ce qui permet aux administrateurs de définir des allocations de ressources maximales pour la mémoire, l'unité centrale, l'espace disque et le nombre d'instances par application. Dans SAP BTP, environnement d'exécution Cloud Foundry, certaines limites s'appliquent aux applications de mise à l'échelle :

  • Mémoire : la mémoire maximale que vous pouvez allouer à une instance d'application est de 16 Go.
  • Quota de disque : le quota maximal de disque que vous pouvez allouer à une instance d'application est de 10 Go.
  • Taille du package d'application : la taille maximale du package d'application est de 1,5 Go. Si votre application est plus volumineuse que cela, le déploiement échoue.
  • Taille d'archive MTA : la taille maximale d'une archive d'applications multicibles (MTA) est limitée à 500 Mo. Le déploiement est refusé pour les archives de plus grande taille.
  • Nombre d'instances : le nombre d'instances que vous pouvez ajuster à dépendra du quota affecté à votre organisation et à votre espace dans SAP BTP, environnement d'exécution Cloud Foundry.

Reportez-vous à la documentation SAP BTP - Configuration spécifique pour obtenir les informations les plus récentes sur les configurations de limites pour SAP BTP, exécution Cloud Foundry.

Ces limites sont conçues pour garantir une utilisation équitable et maintenir les performances et la stabilité de la plateforme. Si votre application requiert des ressources supplémentaires, envisagez d'optimiser votre application ou de répartir la charge de travail entre plusieurs applications ou services.

Mise à l'échelle automatique

La mise à l'échelle automatique est un aspect essentiel du développement d'applications, en particulier dans un environnement cloud. SAP BTP, exécution Cloud Foundry prend en charge la mise à l'échelle automatique via le service Application Autoscaler, ce qui permet aux applications d'ajuster dynamiquement le nombre d'instances en cours d'exécution en fonction de critères prédéfinis tels que l'utilisation de l'UC, l'utilisation de la mémoire ou les métriques personnalisées. Cela permet aux applications d'effectuer automatiquement une mise à l'échelle en réponse à l'évolution des conditions de charge, garantissant ainsi des performances optimales et l'utilisation des ressources. Le service ajuste automatiquement le nombre d'instances d'application en fonction de la stratégie que vous avez définie, qui peut être configurée à l'aide de planifications ou de métriques spécifiques telles que l'utilisation de l'UC, le débit HTTP ou la latence HTTP. Ce faisant, les applications peuvent évoluer dynamiquement, en maintenant les performances et l'efficacité des ressources dans des conditions de charge variables.

Le service Application Autoscaler fournit les fonctionnalités suivantes :

  • Mise à l'échelle dynamique : elle ajuste automatiquement le nombre d'instances d'application en fonction des métriques de performance de l'application en temps réel.
  • Mise à l'échelle planifiée : elle ajuste automatiquement le nombre d'instances d'application en fonction de planifications prédéfinies. Cela est utile pour les scénarios dans lesquels des modifications de charge prévisibles surviennent.
  • API RESTful : fournit des API pour gérer les stratégies d'échelle automatique et récupérer l'historique de mise à l'échelle automatique.
  • Tableau de bord de mise à l'échelle automatique : il fournit une interface utilisateur pour vous permettre de gérer les stratégies de mise à l'échelle automatique et d'afficher l'historique de mise à l'échelle automatique.

Pour utiliser le service Application Autoscaler, vous devez le lier à votre application et définir une stratégie d'autoscaling. Les politiques de mise à l'échelle avec plusieurs règles sont évaluées de haut en bas. La première règle qui correspond déterminera le résultat de l'évaluation de la politique.

Il est généralement acceptable si la mise à l'échelle est basée sur une seule métrique (en fonction de l'hystérésis). Assurez-vous que les règles les plus critiques sont classées par ordre de priorité en haut de la directive. Notez que cette approche ne prend pas en charge la combinaison de plusieurs paramètres à l'aide d'opérations logiques telles que AND ou OR. Gardez ces considérations à l'esprit lors de la configuration des stratégies de mise à l'échelle.

Configuration de service rationalisée

  1. Créez une instance de service.
  2. Définissez la stratégie de mise à l'échelle.
  3. Liez l'application à l'instance de service à l'aide de la stratégie.

La figure explique la configuration rationalisée du service : un didacticiel basé sur un scénario.

Les paramètres personnalisés doivent être soumis si les paramètres standard sont insuffisants. Ces métriques doivent être soumises toutes les 40 secondes par instance d'application pour être cohérentes avec les autres métriques. Notez qu'il existe une limite de 30 demandes par seconde par rapport à l'API de paramètres personnalisés. Tous les paramètres, y compris les paramètres personnalisés, sont moyennés au fil du temps et dans les instances d'application. Il est donc important de soumettre des mesures périodiquement à partir de chaque instance d'application.

Équilibrage de la charge

SAP BTP, exécution Cloud Foundry inclut des fonctionnalités intégrées d'équilibrage de la charge pour répartir équitablement le trafic entrant entre toutes les instances en cours d'exécution d'une application. Cela permet d'améliorer la performance globale, la disponibilité et la fiabilité des applications en utilisant efficacement les ressources disponibles et en gérant les pics de trafic.

Si l'équilibrage automatique de la charge fourni par la plate-forme n'est pas suffisant, SAP BTP Cloud Foundry fournit également différentes stratégies pour répartir la charge. Ces stratégies incluent le tourniquet et le moindre lien. Par défaut, la plateforme utilise une approche tourniquet pour répartir uniformément les requêtes entrantes entre toutes les instances d'une application. Cependant, si votre application a des besoins ou des caractéristiques spécifiques, vous pouvez choisir une stratégie d'équilibrage de la charge différente qui répond mieux à vos besoins.

Par exemple, la stratégie de connexion la moins élevée dirige les requêtes entrantes vers l'instance ayant le moins de connexions actives, ce qui peut être bénéfique pour les applications avec des connexions à longue durée de vie ou des charges de travail inégales. L'algorithme de connexion la moins élevée peut produire de meilleurs résultats lors de l'utilisation du service Application Autoscaler. Cet algorithme dirige le trafic vers les nouvelles instances créées lors de la mise à l'échelle, car elles n'ont initialement aucune connexion active. En revanche, l'algorithme tourniquet distribuerait le trafic de manière plus uniforme, mais peut prendre plus de temps pour équilibrer la charge, car les connexions établies avant que les nouvelles instances deviennent disponibles doivent être terminées.

Synthèse

SAP BTP, exécution Cloud Foundry offre de puissantes fonctionnalités de mise à l'échelle, y compris la mise à l'échelle horizontale (augmentation du nombre d'instances) et la mise à l'échelle verticale (augmentation de la mémoire et de l'espace disque). Il existe également des limites sur l'utilisation des ressources, personnalisables via des quotas d'organisation et d'espace, et des fonctionnalités d'auto-mise à l'échelle pour ajuster dynamiquement le nombre d'instances en cours d'exécution en fonction de critères prédéfinis. La plate-forme fournit également un équilibrage de charge intégré pour répartir uniformément le trafic entrant. Ces fonctionnalités sont essentielles pour maintenir des performances optimales, l'utilisation des ressources et la disponibilité des applications.