Rendre les applications évolutives

Maintenant que vous comprenez les principes fondamentaux de la préparation à la croissance et que vous connaissez les facteurs à prendre en compte dans la planification de la capacité, vous pouvez relever le défi de rendre vos applications aussi évolutives que possible.

Révisions architecturales

Un point clé à retenir est que vous devez effectuer des révisions architecturales régulières de vos systèmes.

Vous savez que vous pouvez appliquer des pratiques telles que l’infrastructure en tant que code pour améliorer la façon dont vous déployez vos ressources cloud. Vous mettez à jour et améliorez régulièrement le code de votre application, et vous devez faire de même avec vos ressources de plateforme sous-jacentes.

L’exécution d’une révision architecturale vous aide à identifier les domaines qui ont besoin d’amélioration.

Le Centre d’architecture Azure dispose d’une multitude de ressources pour vous aider à concevoir vos applications dans le cloud, et il existe de nombreuses recommandations d’extensibilité que vous trouverez dans le guide d’architecture d’application au lien suivant :

Centre d’architecture Azure

Scénario : l'architecture de Tailwind Traders

Une première étape consiste à effectuer une évaluation de l’architecture et de l’application , non seulement pour déterminer où se trouvent ses faiblesses, mais aussi pour reconnaître ses forces. Qu’est-ce qui est bon à ce sujet ?

Jetez un autre coup d’œil au scénario que vous avez vu dans l’unité précédente. Voici un diagramme de l’architecture de l’organisation à nouveau.

Ils ont décomposé l’application en microservices plus petits, et certains de ces services sont assis en tant que conteneurs sur Azure Kubernetes Service ou ils peuvent s’exécuter sur des machines virtuelles ou App Service. Vous utilisez des services intrinsèquement évolutifs tels que Functions et Logic Apps.

Cette modification est bonne, mais il existe des améliorations qui rendent l’application plus évolutive. Par exemple, concentrez-vous maintenant sur le service Produits. Dans le diagramme, le service produit s’exécute dans Kubernetes, mais nous supposons que cette explication s’exécute sur une machine virtuelle dans Azure. Les concepts de mise à l’échelle, éventuellement avec une implémentation légèrement différente, peuvent être appliqués aux applications, qu’elles s’exécutent sur des serveurs, App Service ou dans des conteneurs.

Le produit s’exécute actuellement sur une seule machine virtuelle, connecté à une base de données Azure SQL unique. Vous devez autoriser cette machine virtuelle à effectuer une mise à l'échelle. Pour ce faire, vous pouvez utiliser des groupes de machines virtuelles équilibrées en charge, qui vous permettent de créer et de gérer un groupe de machines virtuelles identiques. Étant donné que vous avez maintenant plusieurs machines virtuelles, vous devez introduire un équilibreur de charge pour distribuer le trafic entre les machines virtuelles.

Groupes identiques de machines virtuelles

En appliquant des ensembles à échelle de machines virtuelles plutôt que des machines virtuelles uniques, vous obtenez plusieurs avantages :

• Vous pouvez mettre à l’échelle automatiquement en fonction des métriques de l’hôte, des métriques de l’invité, des insights de l’application ou d’une planification.
• Vous pouvez utiliser des zones de disponibilité (AZ), qui sont des centres de données autonomes indépendants au sein d’une région Azure. Avec la prise en charge d’AZ, vous pouvez répartir vos machines virtuelles sur plusieurs AZ, ce qui rend votre application plus fiable et la protéger contre les défaillances du centre de données. Les nouvelles instances dans un groupe identique sont automatiquement réparties uniformément entre les zones de disponibilité.
• L’ajout d’un équilibreur de charge devient plus facile. Les groupes de machines virtuelles identiques prennent en charge Azure Load Balancer pour la distribution du trafic de couche 4 (L4) de base. Ils prennent également en charge Azure Application Gateway pour une distribution de trafic L7 plus avancée et une terminaison SSL.

Vous devez prendre en compte certains facteurs importants avant de mettre en œuvre des jeux d'échelle. Spécifiquement:

• Évitez la stickiness de l’instance, afin qu’aucun client ne soit bloqué à un back-end spécifique.
• Supprimez les données persistantes de la machine virtuelle et stockez-les ailleurs, par exemple dans stockage Azure ou dans une base de données.
• Concevez en vue d’un scale-in. Il est également important que votre application puisse facilement effectuer un scale-down. Il doit gérer correctement non seulement avoir plus d’instances ajoutées au pool de serveurs qui gèrent le trafic, mais également l’arrêt brusque des instances à mesure que la charge tombe. L’aspect du scale-down de la mise à l’échelle est souvent négligé.

Découplage

Vous avez ajouté des machines virtuelles supplémentaires avec des groupes identiques. Le scale-out est la réponse classique à « nous devons effectuer une mise à l’échelle ». Toutefois, vous ne pouvez mettre à l’échelle qu’une seule métrique, et cette réponse peut ne pas être pertinente pour toutes les tâches effectuées par votre service produit.

Dans notre scénario, le service de produits a un travail. Il prend une image du produit, puis cette image est téléchargée. Il transcode cette image et la stocke dans plusieurs tailles différentes pour les miniatures, les images du catalogue, etc. Le traitement de l’image est gourmand en processeur, mais l’utilisation générale est intensive en mémoire.

Le traitement d’images est une tâche asynchrone qui peut être divisée en un travail en arrière-plan. Vous pouvez le faire en découplant votre service de traitement d’images à l’aide d’une file d’attente. Le découplage vous permet de mettre à l’échelle les deux services indépendamment : l’un sur la mémoire (le service produit) et l’autre (le service de traitement d’images) sur le processeur ou même la longueur de la file d’attente. Un autre ensemble de mise à l'échelle va consommer ces messages et traiter les images.

Mettre à l’échelle avec les files d’attente

Azure propose deux types d’offres de file d’attente :

• Files d’attente Azure Service Bus Offre de mise en file d’attente plus avancée, qui fait partie du produit Azure Service Bus plus large, offrant des modèles d’intégration pub/sub et plus avancés.
• Files d’attente Azure Storage Une interface de file d'attente REST simple construite sur Azure Storage. Il offre une messagerie fiable et persistante.

Vos besoins dans ce scénario sont simples. Vous pouvez donc utiliser des files d’attente de stockage Azure. Votre niveau de produit n’a pas besoin d’être mis à l’échelle, car vous avez découplé cette tâche en arrière-plan.

Mise en cache en mémoire

Une autre façon d’améliorer les performances de votre application consiste à implémenter un cache en mémoire.

Maintenant, vous savez que les performances ne sont pas égales à la scalabilité exactement, mais en améliorant les performances de votre application, vous pouvez réduire la charge sur d’autres ressources. Cette amélioration signifie que vous n’aurez peut-être pas besoin de mettre à l’échelle aussi tôt.

Azure Cache pour Redis est une offre Redis gérée. Redis peut être utilisé pour de nombreux modèles et cas d’usage. Pour votre service de produit dans ce scénario, vous implémenteriez probablement le modèle cache-aside. Dans ce modèle, vous chargez des éléments de la base de données dans le cache en fonction des besoins, ce qui rend votre application plus performante et réduit la charge sur la base de données.

Redis peut également être utilisé comme file d’attente de messagerie pour mettre en cache du contenu web ou pour la mise en cache de session utilisateur. Ce type de mise en cache peut être plus adapté à d’autres services du système, tels que le service de panier d’achat, où vous pouvez stocker les données du panier d’achat par session dans Redis au lieu d’utiliser un cookie.

Mettre à l’échelle la base de données

Maintenant que vous avez rendu vos ressources de calcul plus évolutives, examinez votre base de données. Dans ce scénario, vous utilisez azure SQL Database, qui est une offre sql server managée d’Azure.

Les bases de données relationnelles sont plus difficiles à effectuer un scale-out que les bases de données non relationnelles. La première chose que vous pouvez faire pour mettre à l’échelle votre base de données consiste à augmenter la taille de la base de données. Ce redimensionnement peut être effectué facilement avec un temps d’arrêt moyen de moins de quatre secondes. Soit à l’aide d’un appel d’API simple dans Azure SQL, soit à l’aide d’un curseur dans le portail.

Si ce dimensionnement ne répond pas à vos besoins, en fonction des caractéristiques du trafic, il peut être approprié de répartir les lectures dans la base de données. Cela vous permet de router le trafic de lecture vers votre réplica en lecture.

Cette modification doit être implémentée dans le code. Voici comment procéder.

#Azure SQL Connection String

#Master Connection String
ApplicationIntent=ReadWrite

#Read Replica Connection String
ApplicationIntent=ReadOnly

#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Mettez à jour l’attribut ApplicationIntent dans votre chaîne de connexion de base de données pour spécifier le serveur auquel vous souhaitez vous connecter. Utilisez ReadOnly pour vous connecter au réplica ou ReadWrite pour vous connecter au serveur maître.

Étant donné que cette commande doit être implémentée dans le code, il peut ne pas s’agir d’une solution adaptée à votre situation. Que se passe-t-il si chaque service de produit unique a besoin de la possibilité de lire et d’écrire ?

Dans ce cas, vous pouvez envisager un scale-out de la base de données SQL avec un partitionnement.

Partitionnement de base de données

Si, après le scale-up ou l’implémentation de réplicas en lecture, vos ressources de base de données ne répondent toujours pas aux besoins de votre système, l’option suivante consiste à effectuer un partitionnement.

Le partitionnement est une technique permettant de distribuer de grandes quantités de données structurées de manière identique sur de nombreuses bases de données indépendantes. Le partitionnement peut être nécessaire pour de nombreuses raisons. Par exemple:

• La quantité totale de données est trop grande pour s’adapter aux contraintes d’une base de données individuelle.
• Le débit de transaction de la charge de travail globale dépasse les fonctionnalités d’une base de données individuelle.
• Les locataires distincts doivent résider sur différentes bases de données physiques pour des raisons de conformité (cette exigence est moins relative à la mise à l’échelle, mais il s’agit d’une autre situation dans laquelle le partitionnement est utilisé).

Votre application ajoute les données pertinentes à la partition appropriée, ce qui rend votre système évolutif au-delà des contraintes de la base de données individuelle.

Azure SQL offre les outils Azure Elastic Database. Ces outils vous aident à créer, gérer et interroger des bases de données SQL partitionnées dans Azure à partir de votre logique d’application.