Qu’est-ce que l’extensibilité ?

Dans le monde des affaires, la croissance peut être bénéfique. Toutefois, lorsque la croissance se produit trop rapidement et que vous n’avez pas suffisamment préparé pour elle, la croissance peut créer des problèmes. L’un de ces problèmes est l’effet de la croissance de la fiabilité des applications et des services qui n’ont pas été conçus pour gérer une augmentation importante du trafic.

Pour vos clients et utilisateurs, une panne est une panne. Ils ne savent ni ne se soucient de savoir si l'accès à votre site leur est impossible à cause d'un code bogué ou parce que trop de monde essaie d'utiliser simultanément votre site parfaitement codé.

L’extensibilité est la capacité à s’adapter à des demandes accrues ou à des besoins changeants. Vos applications et services doivent être en mesure de gérer une plus grande quantité de charge de travail pour prendre en charge la croissance. Les applications évolutives peuvent gérer un nombre croissant de requêtes au fil du temps sans effet négatif sur la disponibilité ou les performances.

Dans cette unité, vous allez découvrir la relation entre l’extensibilité et la fiabilité, l’importance de la planification de la capacité dans l’obtention de l’extensibilité, et passer brièvement en revue certains concepts de base et termes liés à la mise à l’échelle.

Relation d’extensibilité/fiabilité

La bonne nouvelle est que rendre votre application plus évolutive peut également la rendre plus fiable. Par exemple, si votre système est automatiquement mis à l’échelle, dans le cas d’une défaillance d’un composant sur une machine virtuelle individuelle, le service de mise à l’échelle automatique approvisionne une autre instance pour maintenir votre nombre minimal requis de machines virtuelles. Votre système devient plus fiable. Dans un autre exemple, vous utilisez un service de niveau supérieur comme Stockage Azure qui est intrinsèquement évolutif. Si vous rencontrez un problème de stockage, le service est conçu pour être fiable, de sorte que vos données sont répliquées.

Voici une analogie : pensez aux rampes d’accessibilité que vous voyez souvent à l’extérieur des bâtiments qui ont été initialement conçus pour accueillir des personnes en fauteuil roulant. Ils servent ce but. Mais ils sont également utilisés par les parents avec des bébés dans des poussettes ou des chariots, ou par de petits enfants pour lesquels les marches d’escalier sont trop profondes ou élevées. Cette utilisation est un avantage secondaire.

La fiabilité est souvent un avantage secondaire de l’extensibilité. Si vous concevez vos systèmes pour être évolutifs, ils sont susceptibles d’être plus fiables, aussi.

Planification de la scalabilité et de la capacité

La planification de la capacité implique de déterminer les ressources dont vous avez besoin pour répondre aux exigences actuelles et futures. Vous effectuez cette planification en analysant votre utilisation actuelle des ressources, puis en projetant une croissance future.

Pour estimer les besoins de capacité à l’avenir, vous devez prendre en compte des facteurs tels que :

• Croissance attendue de l’entreprise
• Fluctuations périodiques (saisonnières, et ainsi de suite)
• Contraintes d’application
• Identification des goulots d’étranglement et facteurs de limitation

Vous devez également définir des objectifs de niveau de service afin de pouvoir créer un plan de gestion de capacité qui répond ou dépasse de manière fiable ces objectifs à mesure que la charge de travail et l’environnement changent.

La planification de la capacité est un processus itératif. À mesure que nous parcourons ce module, vous allez apprendre à mapper les besoins en ressources pour les composants d’application.

Concepts et terminologie

Avant de pouvoir comprendre pleinement les concepts et les stratégies que vous rencontrez dans ce module, vous avez besoin d’une connaissance préalable de quelques concepts de base et des termes fondamentaux liés à la mise à l’échelle.

• Montée en puissance : augmenter la taille d’un composant afin de gérer une charge de travail accrue. Également appelé mise à l’échelle verticale.
• Scale-out : ajout de plusieurs composants ou ressources pour répartir la charge sur une architecture distribuée. Par exemple, à l’aide d’une architecture simple qui comporte plusieurs backends derrière un ensemble de frontends. À mesure que la charge augmente, nous ajoutons d’autres serveurs principaux (et frontaux) pour le gérer. Également appelé mise à l’échelle horizontale.
• Mise à l’échelle manuelle : l’action humaine est nécessaire pour augmenter la quantité de ressources.
• Mise à l’échelle automatique : le système ajuste automatiquement la quantité de ressources en fonction de la charge. Pour être clair, le montant est ajusté à la fois vers le haut et vers le bas en fonction d’une charge accrue ou réduite.
• Mise à l’échelle DIY : mise à l’échelle manuelle où vous devez configurer cette dernière vous-même.
• Échelle inhérente : les services qui ont été conçus pour être évolutifs et gérer cette mise à l’échelle en arrière-plan sans intervention de votre part. De votre point de vue, ils semblent presque infiniment évolutifs, car vous pouvez simplement consommer plus de ressources sans avoir à les provisionner manuellement.

L'architecture de Tailwind Traders

Dans ce module, nous allons utiliser un exemple d’architecture d’une société matérielle fictive appelée Tailwind Traders. Leur plateforme de commerce électronique ressemble à ceci :

Ce diagramme est assez complexe à première vue. Nous allons donc le parcourir. Le site web a un front-end. C’est l’élément avec lequel vous échangez lorsque vous allez sur tailwindtraders.com.

Le serveur frontal communique avec un ensemble de services back-end. Ces services principaux incluent les articles courants tels qu’un service de coupons, un service de panier d’achat, un service d’inventaire, etc. Ils s’exécutent tous dans Azure Kubernetes Service. Il existe d'autres éléments et technologies impliqués dans cette application. Tout ce dont vous avez besoin pour vous concentrer est le serveur frontal et les services principaux s’exécutant sur Kubernetes.

Points de défaillance uniques

Maintenant que vous avez vu l’architecture entière, prenons un moment pour examiner les points uniques de défaillance et les endroits que nous pourrions attirer notre attention lors de la réflexion sur la mise à l’échelle.

Tous ces services sont un point de défaillance unique : ils ne sont pas créés pour la résilience ou pour la mise à l’échelle. Si l’un d’entre eux est surchargé, il est probable qu’il se bloque, et il n’y a aucun moyen facile de résoudre cela dans le moment.

Plus loin dans ce module, nous examinons d’autres façons de concevoir ces services afin qu’ils soient plus évolutifs et plus fiables.

Capacité préprovisionnée

Examinons un autre problème qui pourrait s’avérer gênant. Voici les services/composants qui nous obligent à préprovisionner la capacité :

Par exemple, avec Cosmos DB, nous préprovisionnons du débit. Si nous dépassons ces limites, nous allons commencer à envoyer des messages d’erreur à nos clients. Avec les services Azure AI, nous sélectionnons le niveau et ce niveau a un nombre maximal de requêtes par seconde. Une fois que nous atteignons l’une de ces deux limites, l’accès des clients est ralenti.

Un pic important de trafic, comme le lancement d’un nouveau produit, nous permettra-t-il d’atteindre ces limites ? À l’heure actuelle, on ne sait pas. Cette question est une autre que nous examinons plus loin dans ce module.

Coûts

Même quand nous faisons les choses correctement, nous devons encore planifier la croissance. Voici les services de paiement par utilisation :

Ici, nous utilisons Azure Logic Apps et Azure Functions, qui sont tous deux des exemples de technologie serverless. Ces services sont évolutifs automatiquement et nous payons à la demande. Votre facture augmente à mesure que votre base de clients le fait. Nous devrions au moins être conscients de l’impact des événements à venir, comme le lancement d’un produit, sur nos dépenses cloud. Nous travaillons également à la compréhension et à la prédiction de nos dépenses cloud plus loin dans ce module.