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 :

Azure Centre d’architecture

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. Ils utilisent également 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 un scale-out. Pour ce faire, vous pouvez utiliser Azure groupes de machines virtuelles identiques, ce qui vous permet de créer et de gérer un groupe de machines virtuelles identiques à charge équilibrée. É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 Zones de disponibilité (AZ), qui sont des emplacements physiquement distincts au sein d’une région Azure, chacune composée d’un ou plusieurs centres de données. 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ège 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 la distribution de trafic L7 plus avancée et l’arrêt 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-la ailleurs, comme 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 : lorsqu’une image de produit est chargée, elle 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 :

• Azure Service Bus files d’attente Solution de gestion de files d’attente avancée, qui fait partie du produit plus large Azure Service Bus, proposant des modèles d’intégration pub/sub et d'autres modèles plus avancés.
• stockage Azure Queues Une interface de file d'attente simple basée sur REST construite sur stockage Azure. Il offre une messagerie fiable et persistante.

Vos besoins dans ce scénario sont simples. Vous pouvez donc utiliser des files d’attente 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 Managed Redis (anciennement 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 de SQL Server managée de 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 bref instant de perte de connectivité, soit à l’aide d’un appel d’API simple dans Azure SQL, soit à l’aide d’un curseur dans le portail.

Si ce redimensionnement ne répond pas à vos besoins, en fonction des caractéristiques du trafic, il peut être approprié d'étendre les lectures vers la base de données, ce qui vous permet d’acheminer le trafic de lecture vers votre réplica de lecture.

Cette modification doit être implémentée dans le code. Vous spécifiez l’intention de routage en définissant l’attribut ApplicationIntent dans votre base de données chaîne de connexion. Utilisez ReadOnly pour vous connecter au réplica, ou ReadWrite pour vous connecter au primaire.

L’approche recommandée consiste à utiliser des identités managées pour l’authentification, en stockant toute configuration nécessaire dans Azure Key Vault :

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Étant donné que cette modification doit être implémentée dans le code, il peut ne pas s’agir d’une solution appropriée pour 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 de faire évoluer horizontalement Azure SQL Database en utilisant le partitionnement (sharding).

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 de base de données élastique Azure. 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.