Préparer la croissance
Vous avez probablement déjà entendu dire que la préparation est la clé du succès. C’est particulièrement vrai dans le cas d’une croissance fluide, réussie et fiable.
L’un des principaux avantages du cloud computing est la possibilité de mettre à l’échelle. Cette capacité a donné naissance à une idée fausse selon laquelle il n’est pas nécessaire de préparer ou de planifier la croissance dans le cloud, car son échelle est infinie.
Il est vrai qu’il y a probablement suffisamment de ressources dans le cloud pour répondre aux besoins de votre application. Toutefois, il existe deux raisons pour lesquelles vous devez toujours comprendre vos besoins de capacité :
Même s’il y a assez de ressources dans le cloud pour répondre à vos besoins, tous les services que vous consommez sont mis à l’échelle automatiquement ou sont intrinsèquement scalables. Par conséquent, vous devez être conscient des limites de service et savoir quand vous avez besoin d’effectuer un scale-up des services et des ressources.
Les ressources cloud sont peut-être illimitées, mais votre budget ne l’est probablement pas. Vous devez prendre en compte le coût, et vos collègues du service financier ont besoin de connaître les dépenses cloud prévues.
Planifier une croissance organique
Dans le monde de l’entreprise, la croissance organique fait référence au processus par lequel les organisations étendent leur propre capacité, en se basant sur leurs ressources et compétences intrinsèques, pour stimuler une croissance lente et naturelle.
La première chose à faire pour planifier la capacité dans le cloud, lorsque votre activité croît de manière organique, consiste à recenser les besoins actuels en ressources pour les principaux composants 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 considérable en conséquence. Rappel du schéma de leur architecture.
Pour commencer la planification de la capacité, vous devez identifier les principaux composants. Dans cet exemple, il s’agit des éléments suivants :
- Cluster Azure Kubernetes Service
- Application Rewards en cours d’exécution dans Azure App Service
- Diverses bases de données, telles que Cosmos DB, Azure SQL et autres.
Pour chacun de ces composants volumineux, vous devez comprendre l’utilisation actuelle des ressources pour mieux planifier leur utilisation future. Passons en revue l’utilisation des ressources pour un de ces grands composants.
Mesurer la capacité dans Cosmos DB
Dans Cosmos DB, le stockage est mesuré en gigaoctets et mis à l’échelle automatiquement, même si vous devez toujours être conscient des mesures pour des raisons de coût.
Le débit est préconfiguré et vous utilisez une métrique appelée Unités de requête pour le mesurer. Les unités de requête (RU) sont un mélange de mémoire, de processeur et d’IOPS, qui vous donne une seule métrique à partir de laquelle vous planifiez 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 : 1 Ko lu correspond à une seule unité de requête. Les autres opérations sont calculées en fonction d’autres facteurs, comme 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 votre utilisation de ressources avec une métrique d’entreprise, telle que les utilisateurs actifs mensuels ou le chiffre d’affaires mensuel. Cette corrélation vous permet de planifier la capacité en fonction de vos prévisions de croissance d’activité. Vous pouvez récupérer ces métriques de capacité dans Azure Monitor. En comprenant l’utilisation des ressources du système, vous pouvez savoir quand vous avez besoin d’effectuer un scale-up et anticiper les coûts dans le temps.
Passons à la pratique et observons les données d’utilisation de Cosmos DB chez Tailwind Traders. Voici un graphe de l’utilisation.
Dans cet exemple, Tailwind Traders croît en moyenne de 2 500 utilisateurs actifs mensuels (MAU) avec une base d’utilisateurs actuelle de 10 000.
Si on regarde le stockage, nous pouvons voir que la 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 les métriques de ressources de notre système, nous savons quand nous avons besoin de mettre à l’échelle notre débit et quels vont être nos coûts au fil du temps.
Nous pouvons maintenant produire un graphe pour nous aider à 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. Une autre information intéressante est qu’ils peuvent même peut-être effectuer un scale-down dès maintenant de leur base de données Cosmos DB, car ils utilisent beaucoup moins que la capacité préprovisionnée.
Planifier une croissance inorganique
Dans l’exemple précédent, vous planifiiez une croissance organique. Une croissance inorganique provient de facteurs externes et non pas d’une augmentation des activités propres de l’entreprise. Au lieu d’être une évolution naturelle, elle a tendance à impliquer une augmentation plus soudaine et plus importante de l’utilisation.
Parfois, vous n’êtes pas au courant à l’avance d’une augmentation du trafic, des utilisateurs, etc. Pour anticiper de tels cas, vous devez créer votre système pour qu’il soit aussi scalable que possible, automatiquement, et pour qu’il échoue correctement quand cela n’est pas possible. Nous voyons ça plus loin dans ce module.
Dans d’autres circonstances, comme quand vous avez un grand lancement de produit à venir, vous pouvez avoir une croissance inorganique que vous pouvez planifier et préparer. Si vos équipes collaborent sur 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 de ressources et implémenter les changements en conséquence.
Une bonne préparation dépend de votre organisation et de l’événement concerné. Vous pouvez ne pas y arriver, mais plus vous êtes préparé, plus vous avez d’atouts en main dès le début.
Scénario : Croissance inorganique
Examinons une autre situation hypothétique comme exemple de planification d’une croissance inorganique. Un événement marketing est planifié pour le lancement d’un nouveau produit Tailwind Traders innovant de grande envergure. Cet événement doit attirer 5000 utilisateurs supplémentaires sur le site commercial de l’entreprise.
En utilisant les données de l’exemple précédent de croissance organique et en les mettant en corrélation, avec un peu de chance par un lien de causalité, avec une métrique métier que vous avez obtenue de vos équipes produit/marketing (par exemple, nombre d’utilisateurs), vous pouvez commencer à planifier une croissance inorganique.
Grâce au scénario précédent, vous savez que pour 2500 utilisateurs vous avez besoin d’environ 50 Go de stockage et 100 unités de requête. Vous pouvez maintenant utiliser ces données et déterminer si vous êtes prêt pour l’événement. Si 5000 utilisateurs sont prévus, il faut 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 dans le cadre de l’événement. Ces capacités sont mises à l’échelle automatiquement et vous avez seulement besoin de comprendre les nouveaux coûts, ce qui est abordé plus loin.
Vous pouvez aussi prédire que les RU atteindront seulement 50 % de la capacité après l’événement. La capacité de Cosmos DB pour cet événement n’est donc pas un problème.
Toutefois, il y aura un impact sur le coût.
Vous pouvez voir que 100 Go de stockage supplémentaires coûtent 25 USD supplémentaires/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. Résultat : cet événement marketing est susceptible d’augmenter la facture de Cosmos DB de 25 USD.