Préparer la croissance

Vous avez probablement entendu dire que la préparation est la clé du succès. Cela dit est particulièrement vrai en ce qui concerne la croissance lisse, réussie et fiable.

L’un des principaux avantages du cloud computing est la possibilité de passer à l’échelle. Cette capacité a conduit à une hypothèse erronée selon laquelle il n’est pas nécessaire de préparer ou de planifier la croissance dans le cloud, car elle a une échelle infinie.

Il est vrai qu’il y a probablement plus de ressources que suffisamment dans le cloud pour répondre aux demandes de votre application. Toutefois, il existe quelques raisons pour lesquelles il est toujours important de comprendre vos besoins en capacité :

• Bien qu’il y ait probablement beaucoup de ressources dans le cloud pour répondre à vos besoins, tous les services que vous consommez ne sont pas automatiquement évolutifs ou sont intrinsèquement évolutifs. Par conséquent, vous devez connaître les limites de service et savoir quand vous devez effectuer un scale-up des services et des ressources.

• Les ressources cloud peuvent être illimitées, mais votre budget n’est probablement pas. Vous devez prendre en compte les coûts, et vos amis du service Financier veulent connaître vos dépenses dans le cloud prévues.

Planifier la croissance organique

La croissance organique dans le monde des affaires fait référence au processus par lequel les organisations étendent leur propre capacité, en s’appuyant sur des ressources intrinsèques et des compétences pour alimenter une croissance plus lente et plus naturelle.

La première chose que vous devez faire lors de la planification de la capacité dans le cloud à mesure que votre entreprise augmente de manière organique consiste à mapper les besoins actuels en ressources pour les composants plus volumineux de votre application.

Scénario : Croissance organique

Revenons à l’architecture que nous avons examinée au début de ce module. Tailwind Traders est sur le point de lancer un nouveau produit innovant et prévoit une croissance spectaculaire en conséquence. Pour vous rappeler, voici à quoi ressemble leur diagramme d’architecture.

Pour commencer la planification de la capacité, vous devez identifier les composants plus volumineux. Dans cet exemple qui inclut :

• Cluster de l'Azure Kubernetes Service
• Application Rewards s’exécutant dans Azure App Service
• Différentes bases de données, telles que Cosmos DB, Azure SQL et les autres.

Pour chacun de ces composants volumineux, vous devez comprendre l’utilisation actuelle des ressources pour vous aider à planifier l’utilisation future. Examinons l’utilisation des ressources pour l’un de ces composants volumineux.

Mesurer la capacité dans Cosmos DB

Dans Cosmos DB, le stockage est mesuré automatiquement en gigaoctets et mis à l’échelle, même si vous devez toujours connaître les mesures pour des raisons de coût.

Le débit est préprovisionné et vous utilisez une métrique appelée Unités de requête pour mesurer ce débit. Les unités de requête (RU) sont un mélange de mémoire, d’UC et d’IOPS, ce qui vous permet de planifier la capacité. Vous provisionnez les unités de requête par incréments de 100 unités de requête par seconde.

Chaque opération de base de données est mesurée en RU/s. Les lectures sont simples : une lecture de 1 Ko correspond à une seule unité de requête. D’autres opérations sont calculées en fonction de plusieurs facteurs, tels que la taille des éléments, la cohérence des données, les modèles de requête, etc.

Quand vous profilez votre application, chaque réponse de Cosmos DB contient l’en-tête des frais de requêtes, qui vous indique exactement le nombre d’unités de requête utilisées par la demande. Vous pouvez comparer le nombre d’unités de requête utilisées au nombre provisionné pour vérifier que vous disposez d’une capacité actuelle suffisante.

Il est judicieux de mettre en corrélation l’utilisation de vos ressources à une métrique métier telle que les utilisateurs actifs mensuels ou les revenus. Cette corrélation vous aide à planifier la capacité en fonction de la façon dont vous attendez que l’entreprise augmente. Vous pouvez récupérer ces métriques de capacité dans Azure Monitor. Comprendre l’utilisation des ressources du système vous aide à savoir quand vous devez effectuer un scale-up et quels seront vos coûts au fil du temps.

Passons à la pratique et observons les données d’utilisation de Cosmos DB chez Tailwind Traders. Voici un graphique de leur utilisation.

Dans cet exemple, les traders Tailwind augmentent en moyenne à 2 500 utilisateurs actifs mensuels avec une base d’utilisateurs actuelle de 10 000.

Si nous examinons le stockage, nous pouvons voir que leur base de données utilise 300 Go des 5 To disponibles (6%). Elle augmente de 1 % (ou 50 Go)/mois,.

Du point de vue du débit, il est de 300/1 000 et croît de 10 %/mois :

Maintenant que nous comprenons nos métriques des ressources système, nous savons quand nous aurons probablement besoin d'augmenter notre débit, et quels seront nos coûts au fil du temps.

Nous pouvons maintenant produire un graphique qui nous aide à planifier la capacité.

Nous savons maintenant qu’en mai nous allons atteindre la capacité des unités de requête sur notre base de données. Nous devons donc faire une mise à l’échelle avant. Un autre aperçu intéressant est qu'ils pourraient peut-être même réduire leur base de données Cosmos DB dès maintenant, car ils n'utilisent même pas la capacité préprovisionnée.

Planifier une croissance inorganique

Dans l’exemple précédent, vous prévoyiez une croissance organique. La croissance anormale provient de facteurs externes plutôt que d’une augmentation des activités commerciales de l’entreprise. Au lieu d’être une progression naturelle, il tend à impliquer une augmentation plus soudaine et plus grande de l’utilisation.

Parfois, vous ne savez vraiment pas à l’avance sur une augmentation du trafic, des utilisateurs, et ainsi de suite. En prévision de ces cas, vous devez créer votre système pour qu’il soit automatiquement aussi évolutif que possible, et qu’il échoue sans compromettre le système quand cela n’est pas possible. Nous aborderons cela plus tard dans ce module.

Dans d'autres cas, comme avec un lancement de produit à venir, vous pouvez rencontrer une croissance externe pour laquelle vous pouvez planifier et vous préparer. Si vos équipes travaillent ensemble dans l’ingénierie, le produit, le marketing et la finance, et que vous savez comment obtenir vos modèles d’utilisation et de croissance des ressources. Vous pouvez faire un effort raisonnable pour prédire l’impact de ces événements sur vos besoins en ressources et implémenter les modifications en conséquence.

Réussir cela est spécifique à votre organisation et à l'événement en question. Vous n’avez peut-être pas toujours raison, mais être aussi préparé que possible vous donne une longueur d'avance.

Scénario : Croissance inorganique

Examinons une autre situation hypothétique comme exemple de planification de la croissance inorganique. Il y a un prochain événement marketing pour le lancement d’un nouveau produit innovant de haut niveau chez Tailwind Traders. Ils s’attendent à ce que 5 000 utilisateurs supplémentaires accèdent à leur site de vente.

En utilisant les données de l’exemple précédent de croissance organique, et en la mettant en corrélation, nous espérons que la cause est liée à une métrique métier que vous avez obtenue auprès de vos équipes produit/marketing (par exemple, nombre d’utilisateurs). Vous pouvez commencer à planifier la croissance inorganique.

Vous savez à partir du scénario précédent que pour 2500 utilisateurs, vous avez besoin d’environ 50 Go de stockage et de 100 RU. Vous pouvez maintenant utiliser ces données et déterminer si vous êtes prêt pour cet événement. Si nous pouvons attendre 5 000 utilisateurs, cela nécessite 100 Go de stockage et 200 RU/s.

Nous pouvons voir que les capacités de stockage sont plus que suffisantes pour la croissance attendue de l’événement. Ces capacités sont mises à l’échelle automatiquement pour vous, donc il n’y a aucune inquiétude ici, à l’exception de la compréhension des nouveaux coûts, qui sont traités ultérieurement.

Vous pouvez aussi prédire que les RU atteindront seulement 50 % de la capacité après l’événement. Par conséquent, ils n’ont aucun souci en termes de capacité Cosmos DB pour cet événement.

Toutefois, il y aura un impact sur les coûts.

Vous pouvez voir que les 100 Go de stockage supplémentaire vont coûter un supplément de 25 $ par mois. Le prix du débit reste le même, car les clients paient les unités de requête provisionnées et ils en ont déjà plus que suffisamment. La ligne de fond est que cet événement marketing est susceptible d’augmenter leur facture CosmosDB de 25 USD.