Ce jeudi 5 Décembre, les équipes Alterway Cloud Consulting participent à la Keynote présentée par Werner Vogels. C’est l’occasion d’être au courant des dernières nouveautés du cloud d’AWS. La keynote commence par une session sur la virtualisation, Werner Vogels nous parle du système de virtualisation Nitro et de ses améliorations.

AWS a révolutionné sa virtualisation en créant un sysème maison, AWS Nitro. Ce hardware développé par AWS a permis d’améliorer les performances des ressources AWS dans des domaines comme le calcul et le stockage. Historiquement, Nitro a été introduit en 2013, où les I/O ont été déportées de l’hyperviseur. Ensuite, c’est la gestion des EBS qui est sortie de l’hyperviseur, lors de la sortie des instances de type c4. Puis cela a été au tour du stockage local, et pour finir ce fut la gestion de la sécurité et du monitoring, avec l’introduction des premières instances bare metal x1.

Nitro est sécurisé et basé sur un système de communication passif, l’accès SSH à l’hyperviseur n’étant pas possible.

La première nouveauté de la Keynote est Nitro Enclaves, une fonctionalité d’EC2 permettant de traiter des données sensibles en partitionnant du cpu et de la mémoire au sein d’une instance pour créer un environnement isolé.

La Keynote s’oriente ensuite sur Fargate, ici il est question d’autoscaling. Clare liguori, principal software engineer chez AWS met en opposition l’autoscaling classique avec celui de Fargate. L’autoscaling de Fargate serait plus réactif que celui d’un autoscaling classique, dans le cadre d’un cluster Kubernetes.

Cela est dû entre autre, à l’architecture de Fargate, basée sur Firecracker et composée d’une microVM ayant une faible emprunte mémoire, de l’ordre de 5Mo par microVM.

Les présentations techniques ont été entrecoupées de présentations business, en l’occurrence après Fargate il a été question d’un retour client de Vanguard.

Retour client : Vanguard

Vanguard, une des plus grosses société de gestion de fonds d’investissement américaine est intervenue pour expliquer sa méthodologie de migration vers le cloud.

Initialement, ils avaient entamé une migration vers un cloud privé… Mais en 2015 ils se sont rendus compte que AWS avait un rythme d’innovation qu’ils ne pourraient pas suivre en ayant un cloud privé. Pour adopter AWS, Vanguard s’est doté d’une équipe de construction du cloud d’une trentaine de personnes. Cette équipe s’est attelée à adopter AWS :

• en migrant des applications orientée Web, initialement déployées dans un PaaS interne
• en adoptant Route53, CloudFront
• en migrant des applications d’analytics, en remplaçant un hadoop interne par AWS EMR
• en utilisant des services plus avancés de AWS, tels que Secrets Manager, AWS Shield et AWS Macie
• en mettant en place des réplications des bases de données on-premises vers AWS afin de rapprocher les données des applications migrées
• en adoptant des services “cloud native” tels que DynamoDB, Kinesis, Lambda
• en migrant le PaaS déployé chez AWS vers ECS+Fargate

En lisant entre les lignes, on peut aussi deviner que Vanguard n’a fait aucun lift&shift de leurs anciennes infrastructures.

Evolution de l’architecture

L’architecture évolue et doit pouvoir évoluer rapidement. Werner prend l’exemple de s3. Le service est aujourd’hui composé de 262 microservices, alors qu’il n’en comptait que 8 au départ. Pour AWS et particulièrement pour le service EBS, la fiabilité n’est pas une option. C’est pourquoi EBS est conçu selon un système particulier de cellules. L’objectif est de limiter le “blast radius”, c’est à dire l’ampleur d’un incident.

EBS n’est pas juste un simple disque. il est composé de multiples fragments de données, eux même regroupés en actif passif, le tout orchestré par un master.

Par l’isolation des ressources AWS est capable de limiter cet effet de bord.

Amazon Builder Library

Enfin, de nombreux clients d’AWS demandent à savoir comment AWS fait pour gérer ses opérations, maintenir sa vitesse d’innovation… c’est pour cela que Amazon a sorti Amazon Builder Library : il s’agit d’une collection de documents sur les méthodes de travail de AWS. Vous pourrez y trouver notamment le sujet du shuffle-sharding qui reprend certains exemples abordés durant la Keynote au sujet de l’isolation.

Session: Design, migration, et optimisation de SQL Server sur AWS

Présenté par : Tom Staab - Partner Solutions Architect, Amazon Web Services, Pallavi Sharma, Sr. Prod Manager - Technical External Services, Amazon Web Services, Stephen Wright - Sr. Director, VP, Liberty Mutual Insurance et Sean Creagan - Director Analytics & Emerging Technology, Liberty Mutual Inc.

Dans cette session, les orateurs nous parlent des considérations à prendre en compte pour faire tourner Microsoft SQL Server sur AWS EC2 et comment optimiser les performances d’un tel déploiement.

Tout part d’un constat : de nombreuses entreprises, lorsqu’elles décident de migrer sur le cloud ont besoin de pouvoir déployer rapidement leurs bases de données (en particulier MS SQL Server) et doivent choisir entre Amazon EC2 et Amazon RDS. Pour conserver leurs licences, avoir un meilleur contrôle sur les vCPUs (lié au licences) et pour des raisons de simplicité, les entreprises se tournent souvent vers EC2 en premier.

Pour leur simplifier la migration, AWS a grandement amélioré le déploiement en annonçant il y a quelques semaines AWS Launch Wizard for SQL Server. Il s’agit d’un assistant dans la console qui permet de paramétrer pas à pas le déploiement d’une base de données SQL Server sur des instances EC2 avec les disques EBS. D’autres services vont ensuite entrer en jeu pour gérer la disponibilité et la continuité des bases de données.

Pour ne citer que ceux là, Amazon FSx permet d’avoir un stockage partagé pour les données en multi-AZ et SIOS DataKeeper (développé par la société SIOS partenaire d’AWS) va créer un cluster des bases de données SQL et répliquer les données de façon synchrone entre plusieurs AZs et de façon asynchrone entre régions.

Stephen Wright et Sean Creagan sont ensuite revenus sur la migration de toute l’infrastructure data de Liberty Mutual Insurance sur AWS EC2 grâce à Amazon DMS (Database Migration Service).

Une migration réussie sans avoir besoin de refactorer les applications. Ils se sont félicités de la collaboration avec les équipes d’AWS et ont déjà le projet en 2020 de migrer leur datalake sur AWS.