alter way Cloud Consulting à l'AWS RE:invent 2018 : Jour 1

Publié le
par Aurélien Joga, Alexandre Kervadec, Jérémy Mouton, Kevin Messy, Lionel Daubichon, Igor Aiestaran
dans Amazon Web Services
⭠ Retour à la liste des articles
thumbernail Amazon Web Services


Retrouvez l'ensemble du dossier :

Depuis 2015, première année de présence de l'équipe alter way Cloud Consulting, l'AWS Re:Invent n'a cessé de prendre de l'ampleur. La plus grande conférence au monde dans l'univers du Cloud Computing avait réuni 40 000 personnes pour l'édition 2017. Cette année, ce sont un peu plus de 55 000 personnes qui se sont réunies à Las Vegas autour des nouveautés d'Amazon Web Services.

En tant qu'Advanced Partner AWS et experts en pointe sur les technologies de Cloud, cet événement est stratégique : c'est l'occasion pour les équipes Amazon Web Services de nous présenter les dernières nouveautés, sorties ou à venir durant les 12 prochains mois.


L'édition 2018 de l'AWS Re:Invent

C'est désormais la tradition : le lundi soir, place au Monday Night Live ! Présentée cette année par Peter De Santis, Vice président de l'infrastructure globale d'AWS, elle est l'occasion de voir ce qui se passe dans les entrailles du cloud d'Amazon.




La Keynote commence par un état des lieux de l'infrastructure AWS, Peter de Santis, avec quelques chiffres niveau infrastructure :

  • la plus grosse zone de disponibilité d'AWS comporte pas moins de 14 datacenters.
  • Cloudfront et direct connect ont respectivement 150 et 89 endpoints dans le monde.

Il fait également un rappel des toutes dernières régions AWS :

  • Milan (Italie)
  • Cap Town (Afrique du Sud)
  • Stockholm (Suède)
  • Hong Kong (Chine)
  • Barhain

C'est ensuite la partie réseau qui est à l'honneur. AWS continue de travailler sur les performances de ses connexions transcontinentales, afin de les rendre plus performantes et moins chères. Il fait notamment référence au "Jupiter Cable" qui relie les USA au Japon, câble sous marin apportant des performances de 60 Tbps.

Avec ces interconnexions, AWS commence à avoir son propre réseau internet mondial, ce qui permet de contrôler tous les nœuds qui transmettent l'information, et comprendre les différentes latences.

Cette année, de nombreuses annonces ont été faites lors de cette Keynote :


Nouveau service : AWS Global Accelerator





Nouveau service : AWS Transit Gateway




Voici une fonctionnalité qui va ravir plus d'une entreprise. AWS Transit Gateway va permettre de résoudre bon nombre de problèmes d'inter-connexion VPC, Direct Connect et VPN. AWS Transit Gateway est comme son nom l'indique une gateway qui va permettre d'inter-connecter bon nombre (jusqu'à 5000) de VPC entre eux, ainsi que les Customer Gateway pour les VPN (2019 pour Direct Connect). Chaque inter-connexion pourra avoir un débit de 50Gbps en burst. Nous allons pouvoir gérer le routing entre les VPC mais également la sécurité, et le domain routing.

AWS Transit Gateway est déjà disponible pour les régions US East (N. Virginia),US East (Ohio), US West (Oregon), US West (N. California), Europe (Ireland), et Asia Pacific (Mumbai). https://aws.amazon.com/fr/blogs/aws/new-use-an-aws-transit-gateway-to-simplify-your-network-architecture/


Nouveau choix côté processeurs : côté hardware c'est la fin du monopole pour Intel avec l'arrivée des processeurs AMD.




Pour les processeurs AMD, un changement de type d'instance permettra de les utiliser (m5.large à m5a.large par exemple) avec une réduction de prix de 10% pour un équivalent Intel. Deux familles d'instances sont déjà disponible, m5a et r5a. Pour des t3a, il faudra encore attendre un peu.

L'autre grosse annonce, c'est l'arrivée d'un processeurs ARM Graviton, oui oui ARM. Ces nouveaux processeurs nous viennent de Annapurna Labs, entreprise achetée en 2015 par AWS et vont équiper les instances A1.

Nouvelles familles d'instances :




Peter nous fait aussi une annonce par rapport au réseau. Il fait un retour en arrière sur les évolutions des capacités réseau, 1Gbps au départ, puis rapidement 10Gbps et une courbe constante d'évolution. On s'attend alors à une continuité de cette courbe. La surprise est que AWS a réussi à atteindre une performance réseau de 100Gbps pour leurs nouvelles instances grâce à leur nouvel hyperviseur "Nitro", disponible avec les nouvelles instances c5n.


Nouveau service : l'Elastic Fabric Adapter




Nouvelle annonce concernant un sujet relativement exigeant : le HPC. AWS a présenté l'Elastic Fabric Adapter qui est une carte réseau spécifique pour les besoins spécifiques de low-latency et de MPI (Message Passing Interface). Cette nouveauté est pour le moment en preview (https://pages.awscloud.com/elastic-fabric-adapter-preview.html) et sera dans un premier temps disponible que les types d'instances p3dn et c5n. D'autres types d'instances seront ajoutés courant 2019.

Enfin, on y parle Machine Learning avec Amazon Sage Maker NEO. Sage Maker est une plateforme autogérée qui permet de compiler et jouer des modèles de machine learning. Cela permet de passer outre le processus complexe de mise en place du machine learning (préparation des datas etc...) en jouant directement les modèles de machine learning via Sage Maker. Avec l'ajout de Neo, lorsqu'un modèle est compilé, celui-ci est optimisé selon l'architecture souhaitée (Intel Xeon, Atom ou ARM). Enfin, Neo est open source.


Retours sur les conférences marquantes :


Mastering Kubernetes on AWS

Difficultés rencontrées

Les problématiques de haute disponibilité du control plane sont toujours les plus difficiles à gérer, notamment avec les besoin de quorum pour un service comme Etcd :

  • Pour avoir une résilience de perte de 1 nœud, il faut 3 instances
  • Pour avoir une résilience de perte de 2 nœuds, il faut 5 instances
  • ...

Interviennent donc assez rapidement les problématiques de coûts, en plus du besoin de ressources humaines pour gérer ces ressources de calcul et stockage.

La demande s'est donc de plus en plus faite ressentir sur le besoin d'un service managé par AWS.

EKS

Control plane managé

La réponse à la demande d'un control plane managé, hautement disponible et abstrait (invisible pour nous). La seule chose visible du côté utilisateur est le endpoint de ce control plane managé auquel vont accéder nos workers Kubernetes. EKS est construit pour être utilisable entre plusieurs comptes AWS (voir Security Strategies) grâce à des ENI sur les sous-réseaux où tournent les workers. Les tags sur ces sous-réseaux permettent par la suite d'être découverts par le control plane.

Networking: pod to pod

Un DaemonSet CNI est déployé sur le cluster, qui va permettre de faire des appels API pour récupérer des IP directement dans un pool d'adresses défini et de l'attribuer aux pods.

AWS met à disposition une liste de blocks CIDR pour :

  • Les pods
  • Les ENI pour le cross-account
  • Les services Kubernetes : un choix entre 10.100/16 et 172.29/16 selon le VPC que vous avez défini pour éviter l'overlap de plages IP

Des CIDR blocks secondaires non RFC1918 sont disponibles (100.64.0.0/10 et 198.19.0.0/16) sont mis à disposition pour les pods uniquement.

Lorsqu'un pod doit accéder à Internet, son IP est SNAT-ée avec l'IP de l'host (worker EC2).

Networking: pod to service

Dans Kubernetes, les objets qu'on appelle Services peuvent prendre différents types pour exposer une application :

  • ClusterIP : en général via iptables
  • NodePort : via un port dédié sur l'hôte alloué dans un pool spécifique, généralement dynamiquement
  • HostPort : via un port fixe dédié sur l'hôte
  • LoadBalancer : ALB ou ELB, mais aussi en alpha les NLB
  • ExternalName

Dans la plupart des cas, on préfère avoir utiliser des ClusterIP (donc une VIP interne au cluster) puis exposer ce service via un Ingress. Les Ingress travaillent sur la couche 7 du modèle OSI. Différents types d'ingress controllers sont disponibles, AWS est contributeur de l'un d'eux : ALB ingress-controller. Cet ingress-controller vient de sortir en version 1.0 et AWS vous offre maintenant la possibilité d'ouvrir un ticket au support pour tout problème concernant cet ingress-controller.

Security: runtime

Un dernier point abordé est la question des accès aux services AWS par les pods Kubernetes. On ne souhaite pas que plusieurs pods différents aient accès au même rôle attribué à l'hôte, le cloisonnement serait inexistant. Il existe donc plusieurs solutions/services :

  • kube2iam : largement utilisé
  • kiam : très utilisé
  • iam4kube : moins utilisé
  • kube-aws-iam-controller : moins utilisé aussi

Un comparatif des solutions disponibles est proposé par Mikhail Mazurskiy (Atlassian).

AWS ne contribue donc pas pour le moment à un service pour gérer les rôles mais reste ouvert à le faire le jour où il sera possible de faire de l'authentification avec de l'OpenID Connect pour les pods. Un standard sûrement pas près d'arriver.


Elastic Load Balacing : Deep dive & best practices (NET404)

Dans cette session, Pratibha Survyadevara de AWS a passé en revue les différences entre les types de load-balancer en rappelant pour quels cas d'utilisation il fallait privilégier un type plutôt qu'un autre. Elle a notamment indiqué que le NLB (Network Load Balancer) était une fonctionnalité implémentée par le SDN de Amazon, et non par un équipement en particulier. Cela rend ce type de load-balancer très distribué et scalable ; il coûte par ailleurs moins cher que les autres load-balancers.

Will Rose a ensuite fait un aparté sur l'utilisation par Netflix de l'authentification de leurs employés et partenaires par les load-balancers AWS. En effet, il est possible depuis quelques mois de laisser un load-balancer AWS gérer l'authentification des utilisateurs.

Traditionnellement, chaque application métier devait implémenter le SSO dans son propre langage : historiquement Netflix utilisait SAML. Ces implémentations sont souvent longues, coûteuses, et demandent une certaine expertise du développeur.

Netflix a réfléchi à implémenter un reverse-proxy authentifiant, mais là encore la tâche était compliquée et cela rajoutait une brique d'infrastructure à maintenir.

L'intégration ALB+Cognito permet de créer une règle obligeant l'authentification de l'utilisateur pour accéder au contenu. AWS gère le parcours utilisateur pour l'authentifier auprès des providers configurés dans Cognito : une base locale, des providers d'identités sociales (Facebook ou Google), ou encore des solutions SSO d'entreprise utilisant SAML.

Une fois authentifié, le contenu de l'utilisateur est reverse-proxifié de façon classique ; le load-balancer inclut néanmoins trois headers additionnels afin que l'application puisse l'identifier.


Operational excellence with Containerized Workloads Using AWS Fargate

Cette session, qui a démarré avec un résumé plutôt fade de Fargate et ses caractéristiques, est devenue plus intéressante dès que Shimon Tolts de chez Datree a pris la parole. Il a notamment expliqué l'intérêt d'une infrastructure complètement serverless dans une équipe composée essentiellement de développeurs, avec le gain de temps et les économies liées à la quasi-absence de responsabilités côté Ops.

Les atouts Fargate les plus mentionnés, entre autres :

  • L’amélioration de la sécurité grâce à l’isolation au niveau des Tasks et à l’impossibilité de se connecter sur les conteneurs
  • La possibilité d’attribuer des Security Groups de la même manière que sur des instances EC2, avec la possibilité d’avoir des VPC Flow logs
  • La très attendue et récente possibilité d’attribuer des Tags aux ressources ECS

Entre les inconvénients, l’absence d’un équivalent des instances Spot et des réservations a été évoquées, ainsi que les volumes EBS, toujours pas compatibles. Tolts n’a pas manqué de nous montrer avec fierté sa console EC2 avec zéro instance !

Datree propose une solution SaaS qui permet d’assurer un niveau de compliance du code au moment des déploiements. Il s’intègre entre autres avec les Pull Requests GitHub pour valider la conformité du nouveau code par rapport aux normes établies.


Aurora Serverless: Scalable, Cost-Effective Application Deployment

Joshua Eichorn nous présente les principaux atouts d’Aurora Serverless, désormais disponible sur de nombreuses régions, avec l’accent sur la capacité provisionnée et le fait que l'on ait tendance à provisionner lors des périodes de pointe, et à payer la capacité non utilisée lors des périodes creuses.

La session nous a surpris avec l’annonce de deux nouveautés :

  • Une API HTTPS pour effectuer des requêtes SQL sur nos bases de données Aurora, ce qui permet de faire le pont entre Lambda et Aurora Serverless de façon plus simple
  • Un éditeur de requêtes dans la console RDS, pratique pour faire des tests et des vérifications sur ses données !

Nous avons appris quelques détails sur le fonctionnement interne d’Aurora Serverless, ainsi que sur les meilleures pratiques de développement pour réussir les connexions sur les bases de données “en veille”.

Reinventing Amazon EC2 Instance Launches With Launch Templates

Les launch templates, relativement récentes, couvrent une fonctionnalité similaire aux Launch Configurations historiques. Cette nouvelle méthode veut unifier et simplifier la façon de lancer des instances EC2 : auto scaling, EC2 fleet, instances, CloudFormation. Un seul Template suffit à lancer des instances, quelle que soit le chemin choisi.

Avantages des Launch Templates :

  • Un template suffit pour plusieurs lancements consécutifs : pas besoin de renseigner tous les paramètres à chaque fois
  • Unification de l’expérience de lancement d’instances
  • Versionner des templates sans être obligé d’en créer des nouveaux comme auparavant
  • On peut les utiliser pour passer uniquement certains paramètres (tags ou user data par exemple) et compléter le reste avec des paramètres spécifiques à chaque lancement
  • Simplification des droits IAM : si on veut que seuls certains subnets ou certaines AMI soient autorisés, on peut désormais le faire avec une condition qui oblige à utiliser le bon Launch Template (ou un Launch Template avec un certain Tag), ce qui facilite considérablement la policy à appliquer

Toutes les nouvelles fonctionnalités EC2 passeront par les Launch Templates, alors pensez à migrer vos Launch Configurations pour en profiter !


Deploy Serverless Apps with Python: AWS Chalice Deep Dive

Chalice est un “microframework” pour le déploiement d’applications serverless Python sur AWS. Kyle Knapp et James Sarywinnie nous montrent en direct comment déployer et tester une fonction très rapidement avec une dizaine de lignes de code. Chalice s’occupe de créer la bonne policy IAM, de façon assez impressionnante : notre code est scanné et les actions nécessaires sont ajoutées à la policy. Chalice télécharge enfin notre fonction, le tout sans avoir à s’occuper directement des questions d’infrastructure AWS.

Un problème courant quand on développe des fonctions Lambda, ce sont les bibliothèques binaires qui doivent être compilées pour Amazon Linux et inclues dans le zip à déployer. Chalice se charge de faire le nécessaire pour que cette étape, souvent pénible, devienne presque transparente.

Les Event Sources, un des principaux atouts de Lambda, sont également gérés par Chalice. On peut très facilement déclarer une fonction qui s’exécute en réponse à un événement comme, par exemple, la création d’un objet dans S3, sans aucune interaction directe avec CloudWatch Events.

Pour les architectures plus complexes, Chalice offre la possibilité de s’intégrer dans des templates CloudFormation. Terraform a également été évoqué, bien qu’il ne soit pas supporté. Ce projet est Open Source et les contributions sont les bienvenues !


Architecture Pattern for Multi-region Active-Active Applications

Speakers :

  • Amy Che (AWS)
  • Darin Briskman (AWS)
  • Christopher Lane (Chick-fil-A)

Introduction

Avez-vous déjà eu le besoin d'étendre votre application sur plusieurs régions ? Que ce soit pour des plans de reprise d'activité(PRA), de l’extrême haute disponibilité, des réglementations sur les données (RGPD par exemple), beaucoup d'utilisateurs d'AWS choisissent de déployer leurs applications sur plusieurs régions de manière active-active.

Darin Briskman : "Pour réussir, ne le faites pas, c'est le plus simple."

Qu'est-ce qu'une application multi-région active-active ?

2 active full stack AWS regions

C'est donc 2 stacks complètes et actives de votre application dans plusieurs régions.

Les problématiques induites sont :

  • Le replica lag : on compte en moyenne 200ms de latence réseau entre Singapour et l'Est des Etats-Unis d'Amérique
  • Le testing : il devient difficile de tester les applications car elles sont très complexes
  • Une architecture complexe et chère !

Plusieurs raisons pour faire du multi-région actif-actif :

  • Business continuity (on passe à plus de 6 ou 7 "9" de disponibilité)
  • Disaster recovery
  • Distribution géographique des clients/utilisateurs :
  • Limiter les latences
  • Respecter des contraintes légales

Comment faire ceci ?

Pour un besoin de business continuity, il faut commencer par établir un RPO (Recovery Point Objective) et RTO (Recovery Time Objective).

Il y a donc plusieurs stratégies pour réaliser ceci :

  • Backup and restore : on réalise des backups dans S3 ou Glacier. Ça permet de garder des données fraiches et redémarrer assez vite grâce à... une "pilot light". Une pilote light est un minimum de services qui tournent pour pouvoir redémarrer rapidement le service.
  • Warm Standby : on fait tourner une copie de la production dans une autre région, en plus petit pour limiter les coûts. Pour recouvrir il suffit de faire du resize et c'est très rapide, on parle en minute.

Comment re-architecturer une application mono-région en multi-région

Le plus important est d'éviter les race-conditions pour ne pas finir avec des données incohérentes.

  • Pattern 1 : lecture en local, écriture en global, c'est très bien pour des actions d'écriture ne nécessitant pas de très faibles latences. On peut par exemple utiliser ceci pour la gestion des utilisateurs et des mots de passe.
  • Pattern 2 : read local, write en partitionné. Utile et pratique pour des utilisateurs qui voyagent, mais à une faible fréquence.
  • Pattern 3 : read local, write local. Attention, il faut absolument éviter ceci, il y a un gros risque de collision de données. Si l'on met à jour une donnée dans une région et immédiatement après (plus court que la latence réseau) on écrit dans une autre région la même donnée, on se retrouve avec ce que l'on appelle un "split brain" et les données ne sont plus cohérentes

AWS intervient à ce moment grâce à ses services :

  • AWS S3 offre une disponibilité de 99.99% pour le stockage objet
  • AWS DynamoDB offre une réplication sur plusieurs régions (de manière asynchrone)
  • AWS RDS Aurora permet de faire des replica multi-region master/slave (seulement pour Aurora Mysql)

Voir au delà des données

D'un point de vu opérationnel, il faut aussi penser à la communication, notamment au niveau des VPC. Il est aujourd'hui possible de faire un VPC peering inter-région. Le trafic passe donc par le backbone AWS, les données sont chiffrées de bout en bout. Il est donc possible de partager des ressources en toute sécurité entre des régions.

Le nouveau problème, c'est que l'on a pas un unique VPC par région. Le VPC peering n'est pas transitif, il faut donc faire une toile énorme et qui devient rapidement incompréhensible et ingérable. C'est ici qu'intervient VPC Transit Gateway.

Pensons aussi au DNS, et donc Route 53. Ce service très connu et utilisé permet énormément de choses, notamment le routing "latency-based", le routing géographique et un failover à mettre en place avec des healthchecks Route 53. Avec Route 53, il est intéressant d'utiliser des NLB, qui permet de faire du load balancing entre plusieurs régions (oui région, et pas seulement AZ !).

Enfin Global Accelerator annoncé pendant le Monday Night Live va aussi aider par l'utilisation d'IP anycast statique, d'une gestion intelligente du trafic, d'un réseau global et un failover instantané inter-région.

Commet manager les stacks

CloudFormation permet de faire de l'infrastructure As Code (IAC). Les Stack sets permettent de travailler avec des templates à déployer sur plusieurs régions. AWS Config permet de faire une agrégation des données globalement et des mettre des alertes pour découvrir les configuration qui ne sont pas dans les clous. AWS System Manager permet de faire des actions de manière globale sur les ressources, par exemple pour appliquer des patchs. CloudWatch Logs est régional, il faut donc réaliser un workflow d'agrégation des logs par exemple via une Lambda, Kinesis Firehose, Athena et S3.

Conclusion

On peut donc conclure que pour réaliser une application multi-région active-active repose sur un design pas seulement de l'infrastructure, mais sur un design complet de l'applicatif et de l'infrastructure, en utilisant la puissance des service managés AWS. Mais la vraie question est : avez-vous vraiment besoin de réaliser ceci ?

⭠ Retour à la liste des articles

Découvrez les derniers articles d'alter way

Découvrez les technologies d'alter way