Télétravail et FinOps At Scale avec AWS AppStream 2.0

Télétravail et FinOps At Scale avec AWS AppStream 2.0

Mar 1, 2021

aws

Un des consultants Agyla.Cloud, a accompagné les équipes de Veolia dans la mise en place d’une solution de scaling dynamique des flottes d’Amazon AppStream 2.0. 

Je suis en mission chez Veolia  depuis octobre 2019 en tant qu’expert AWS. Mon rôle est d’assurer le build et le run, ainsi que d’assister au sein de l’équipe Application Transformation le product manager d’Amazon AppStream 2.0. 

L’utilisation de AppStream chez Veolia s’inscrit dans le cadre du projet phare SATAWAD (Secure AnyTime, AnyWhere, Any Device). L’adoption de SATAWAD a conduit à la migration vers des produits PaaS ou SaaS, comme les applications de Google Workspace, ainsi qu’à l’usage massif des Chromebooks. Certaines applications ont été remédiées ou remplacées pour devenir conformes aux exigences SATAWAD, alors que les autres applications sont maintenant streamées sur AWS, via Amazon AppStream 2.0. Suite à cela, Veolia est actuellement un grand utilisateur d’AppStream dans le monde. 

Dans le cadre du product management, je fais le lien avec les BUs (Business Units) pour les aider à monter leur propre environnement AppStream, et les accompagner afin qu’elles puissent être autonomes dans une partie de leur support.

 

Les challenges et les objectifs de Veolia

 

Les trois grands objectifs de cette mission ont été les suivants :

  1. Améliorer le build afin de minimiser les incidents. Ceci a été réalisé sujet à l’aide de scripts d’automatisation PowerShell.
  1. Faire face à la sollicitation exceptionnelle du service à travers le monde pendant les différents confinements et la crise sanitaire de la COVID-19, en mettant en place des politiques d’autoscaling adaptées. 
  1. Limiter les coûts d’usage résultant de l’utilisation massive en confinement, en adoptant des règles de scaling automatisées et le Serverless au service du FinOps.

Il faut noter qu’AppStream a une logique d’infrastructure différente des ressources AWS classiques, comme, par exemple EC2. Il s’agit d’un outil VDI (Virtual Desktop Infrastructure) où les ressources ne sont pas partagées, contrairement à d’autres outils VDI. Puisque chaque utilisateur est desservi par une instance, le nombre d’utilisateurs potentiels défini par les différents SLAs doit à tout moment correspondre au nombre d’instances disponibles. Si l’on compte 20 utilisateurs à un moment donné, chaque utilisateur doit être servi par une machine. Chaque flotte doit, donc, être dimensionnée aux besoins. 

Les solutions d’Agyla.cloud pour le scaling dynamique

 

Avec le Product Manager, je gère 60 flottes en s’appuyant sur la variable de la capacité disponible. Avant, il n’y avait pas de méthode de scaling dynamique qui pouvait séparer le scaling du matin, de celui du weekend et du soir. C’était problématique, parce qu’il y avait toujours beaucoup de ressources non utilisées, générant des coûts importants. 

La solution automatisée de scaling présentée était en Serverless, avec AWS Lambda. Une fonction Lambda écrite en Python se lance chaque matin et soir pour mettre en place le scaling de chaque flotte. 

La solution se présente comme suit:

  • Les règles de scaling pour chaque flotte et chaque cycle sont stockées dans une table Amazon DynamoDB.
  • La fonction Lambda lit les valeurs de la table DynamoDB et appelle l’API AutoScaling pour appliquer les règles correspondantes.
  • Des cron jobs déclenchent des Event Rules d’Amazon CloudWatch, qui lancent la fonction Lambda.

Un des avantages de cette solution est que Lambda ne tourne que pendant quelques secondes les matins et soirs, ce qui rend l’outil plus rapide, intuitif et économique. La gestion est donc largement simplifiée.

Technologies utilisées 

 

En plus d’AWS Lambda et du Serverless, j’utilise plusieurs technologies : 

  • AWS CloudFormation pour le déploiement automatisé des infrastructures.
  • AWS CloudWatch pour le monitoring des ressources AWS, ainsi que pour la visualisation des logs de la fonction Lambda et des logs internes.
  • Amazon DynamoDB pour le stockage des règles de scaling des flottes.
  • AWS CloudTrail pour investiguer les éventuelles erreurs présente. 
  • PowerShell pour scripter le lancement des applications, le lancement des configurations des flottes au démarrage, ainsi que pousser les logs nécessaires pour assurer le support.
  • BigQuery et DataStudio pour le suivi des paramètres des flottes en dynamique et la création des rapports qui s’envoient dans un bucket S3.

J’utilise également des outils Google, tels que Google Drive, Google Sheets, et AppSheet, ainsi que ServiceNow.

Les résultats de l’implémentation du scaling dynamique

 

Les résultats de notre solution n’ont pas tardé : le scaling est devenu beaucoup plus adapté et aligné avec l’usage quotidien, même intensif.

Avec les premiers confinements suite à l’épidémie, l’usage d’AppStream s’est multiplié par 2.5, et les coûts ont suivi. Avec notre solution de scaling dynamique, Veolia a vu une diminution des coûts de 30% dès le premier mois. On note actuellement des économies de 20 à 30% tous les mois, en comparant avec les coûts engagés sur la même période, l’année dernière. Les coûts par utilisateur ont également diminué. 

Par ailleurs, AppStream a deux types de flottes : 

  • Les flottes Always On, qui coûtent cher
  • Les flottes On-Demand, qui sont très adaptées pour faire du FinOps

Chez Veolia, nous avons également quatre catégories d’applications streamées : 

  • Les applications de bureau classiques, telles que Microsoft Office Excel
  • Les applications SAP
  • Quelques applications métiers développées par Veolia 
  • Quelques applications graphiques du type AutoCad, que j’ai réussi à déployer pour la première fois

Sur les 60 flottes, il y en avait au moins 30 où les utilisateurs avaient besoin du même tableur, et au moins 10 flottes qui avaient exactement les mêmes applications. J’ai donc réussi à fusionner des stacks afin d’utiliser moins de ressources, d’augmenter la performance et de limiter les coûts.  

En début de 2021, avec mon appui dans cette mission, l’équipe a atteint une maturité en matière de gestion du produit ce qui a poussé Veolia à réfléchir à externaliser sa gestion.

Conclusion

A cause de la complexité des challenges, ma mission chez Veolia m’a permis d’apprendre beaucoup de choses et de monter rapidement en compétences. J’ai pu acquérir une expérience importante avec AWS Lambda, ce que je n’avais pas avant. Un de mes objectifs prochains est d’exploiter encore plus le Serverless.

Pendant la phase d’implémentation, j’ai demandé de l’aide à deux consultants Agyla.Cloud afin de corriger et optimiser le script : un grand merci à eux pour leur soutien ! 

Dans le cadre du Product Management, j’ai pu aider plusieurs BUs à implémenter notre solution dans leurs environnements, en leur proposant des workshops et des break-out sessions. 

Sur le plan humain, cette mission m’a permis -dans ses différents aspects- d’interagir avec des collaborateurs de différents métiers avec des besoins variés, différentes cultures ainsi que différents éditeurs. C’est une expérience qui a enrichi mes capacités d’interaction et élargi mon champs de connaissances. 

Poursuivre ma lecture

Les paris s’envolent dans le Cloud

Les paris s’envolent dans le Cloud

Dans le cadre de leur mission, deux consultants Cloud & DevOps chez Agyla.cloud, qui accompagnent notre client PMU, un des plus gros acteurs français de paris hippiques, dans leur projet de migration vers le Cloud AWS, des applications compte, des systèmes de logins clients ainsi que de l’application de prise de paris officielle PMU, nous racontent leur expérience.

Accueil
Expertises
Formations
Contact