Conception pour optimiser l’utilisation
 Optimisez l’utilisation des ressources et des opérations. Appliquez-les aux exigences fonctionnelles et non fonctionnelles négociées de la solution. |
|---|
Les services et les offres fournissent différentes capacités et niveaux tarifaires. Après avoir acheté un ensemble de fonctionnalités, évitez de les sous-utiliser. Recherchez des moyens d’optimiser votre investissement dans le niveau. De même, évaluez en permanence les modèles de facturation afin d’identifier ceux qui s’alignent le mieux sur votre utilisation, en fonction des charges de travail de production actuelles.
Exemple de scénario
Contoso University héberge actuellement une solution COTS (produit du commerce) qui permet aux enseignants de l’université de créer et de mettre à jour des cours pour l’année académique et constitue le portail d’inscription principal utilisé par les étudiants pour ces cours. La solution a une intégration personnalisée avec un système de gestion de l’enseignement SaaS (Software-as-a-Service), vers lequel l’université espère finalement migrer toutes ses fonctions dans quelques années. En attendant, elle souhaite optimiser les coûts sur les composants d’intégration personnalisée.
La solution technologique de l’offre COTS est généralement traitée comme une boîte noire, à l’exception de sa base de données qui est Azure Database pour MySQL. L’intégration personnalisée est une fonction durable Azure qui s’exécute sur un plan de service Standard dans Azure App Service. Ce service App Service hébergeait auparavant un site web universitaire, mais ce n’est plus le cas. Cette fonction durable est une application Python soutenue par un compte Stockage Azure dédié qui effectue une synchronisation nocturne à partir de la base de données MySQL dans l’API SaaS.
Utiliser la tarification basée sur la consommation dans la mesure du possible
Il peut exister des services qui offrent des tarifs basés sur la consommation, ce qui signifie que vous n’êtes facturé que pour l’utilisation du service et que vous pouvez l’arrêter lorsqu’il n’est pas nécessaire, afin d’éviter d’encourir des coûts. Si vous avez des composants de charge de travail utilisés seulement de manière sporadique, cela peut vous aider à réduire les coûts, par rapport au paiement applicable à l’exécution du composant 24/7/365.
En utilisant la tarification basée sur la consommation, vous payez uniquement et exactement pour ce que vous utilisez. Cette option est un bon choix lorsque vous vous attendez à ce que votre calcul de charge de travail ne soit pas utilisée à temps plein.
Problématique de Contoso
- Le travail de synchronisation s’exécute généralement pendant environ une heure chaque nuit, à un horaire spécifique. Historiquement, les performance ont été satisfaisantes. Les dysfonctionnements sont rares, et les erreurs temporaires sont gérées correctement dans la configuration actuelle.
- Étant donné que le calcul nécessaire pour la tâche de synchronisation n’est utilisé qu’une heure par jour, et que 24 heures sont facturées quelle que soit l’utilisation, l’équipe de charge de travail souhaiterait trouver une alternative à la conception actuelle.
- L’équipe a envisagé d’écrire un script pour arrêter le service chaque nuit après l’exécution de la synchronisation et le redéployer le lendemain, mais cette solution impliquerait un degré élevé de risque et de complexité.
Application de l’approche et résultats
- L’équipe analyse l’historique des travaux et constate que la fonction ne s’exécute jamais plus de deux heures. Elle compare le coût du plan dédié au coût du plan de consommation Azure Functions pour le pire scénario, et conclue que le plan de consommation sera moins coûteux.
- L’équipe exécute un test de performances pour s’assurer que les performances sont suffisantes. Elle remarque une légère augmentation du temps d’exécution, mais celui-ci reste toujours dans des limites acceptables.
- Le coût global de la charge de travail est réduit en adoptant le plan de consommation, car des coûts sont encourus uniquement durant l’exécution du travail.
Optimiser votre conception de haute disponibilité
Accordez la priorité au déploiement de modèles Actif-actif ou Actif uniquement plutôt qu’aux modèles Actif-passif, dans le cadre de votre plan de récupération, si vous avez déjà payé les ressources.
Si votre conception utilise par défaut des modèles Actif-passif, il se pourrait que vous ayez des ressources inactives qui pourraient autrement être utilisées. La conversion en Actif-actif peut vous permettre de répondre à vos exigences de nivellement de charge et d’augmentation subite de mise à l’échelle sans trop de dépenses. Si vous pouvez atteindre vos cibles de récupération avec un modèle Actif uniquement, les coûts de ces ressources peuvent être éliminés entièrement.
Problématique de Contoso
- L’application COTS utilise Serveur flexible Azure Database pour MySQL configuré pour une haute disponibilité de même zone, ce qui fournit un serveur de secours dans la même zone de disponibilité que le serveur principal. Des sauvegardes automatiques sont également activées.
- Le RPO de la charge de travail est relativement long (12 heures), et le RTO est de trois heures pendant une journée de cours.
- D’après les tests de récupération précédents, l’équipe sait qu’elle peut atteindre ses cibles RPO et RTO par le biais d’un basculement automatique vers le serveur de secours. Elle a également testé la récupération de la base de données à partir d’une sauvegarde, et peut atteindre les cibles dans ce scénario.
Application de l’approche et résultats
- L’équipe de charge de travail réévalue l’avantage de la conception de haute disponibilité par rapport au coût du service deux fois plus élevé qu’une instance unique.
- L’équipe teste la création d’une nouvelle instance et la récupération d’une base de données à partir de la sauvegarde, et constate qu’elle sera toujours en conformité avec les cibles de récupération. Elle décide par conséquent d’éliminer l’instance de secours.
- L’équipe met à jour le plan de récupération d’urgence afin qu’il reflète la nouvelle stratégie de récupération d’urgence et afin de réaliser les économies souhaitées grâce à la nouvelle configuration.
Garantir la propreté de votre environnement cloud en éliminant les ressources et données inutilisées
Examinez régulièrement et rigoureusement les déploiements afin d’identifier les ressources et les données inutilisées, et désaffectez-les. Au fil du temps, les ressources et les données qui étaient requises dans le passé mais qui ne sont plus utilisées peuvent demeurer dans vos environnements cloud et engendrer inutilement une accumulation des coûts. Soyez vigilant quant à la propreté de vos environnements, afin d’optimiser l’efficacité en matière de coûts.
Le fait d’arrêter les ressources inutilisées et de supprimer les données lorsque vous n’en avez plus besoin permet de réduire les déchets et de libérer des fonds afin de pouvoir les investir ailleurs.
Problématique de Contoso
- Historiquement, l’université a toujours été réticente à l’idée de mettre des solutions hors service, craignant de devoir revenir un jour à une configuration antérieure. Cette prudence a conduit à la présence et à l’exécution de services abandonnés, et parfois oubliés, depuis des mois dans un ou plusieurs environnements.
- Lorsque des services abandonnés sont découverts, c’est généralement par accident, car il n’existe aucun processus formel visant à détecter la présence de ces services dans l’environnement.
Application de l’approche et résultats
- L’équipe ajoute la mise hors service de l’instance App Service au backlog dans le cadre de la migration d’App Service vers l’hébergement basé sur la consommation pour la fonction durable. Dans le cadre du sprint suivant, elle arrêtera les déploiements App Service dans tous les environnements.
- Pour faciliter la détection proactive des ressources abandonnées, l’équipe configure des alertes dans Azure Advisor afin d’être informée des ressources inutilisées.
- L’équipe implémente une nouvelle stratégie qui l’oblige à effectuer des révisions complètes mensuelles des environnements de préproduction et des révisions complètes trimestrielles de l’environnement de production afin d’identifier les ressources abandonnées. Toutes les ressources abandonnées trouvées sont ajoutées au backlog en vue de leur mise hors service.