Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
•Download as PPTX, PDF•
2 likes•510 views
Les slides que j'ai utilisés comme support de ma présentation « Le Cloud, une réponse à nos besoins », lors de l'Apéro Digital le 3 avril 2019 à Lyon.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
Similar to Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin (20)
Le Cloud, une réponse à nos besoins - Apéro Digital avril 2019 - Pascal Martin
- 1. Le Cloud, une réponse à nos besoins. Pascal MARTIN, DevOps @ M6 @pascal_martin
- 3. Le Cloud Pourquoi ? Comment ? AWS, Kubernetes, Terraform, CI/CD…
- 4. Historiquement – « on-prem » • Salle dans un datacentre parisien • Serveurs, achetés • Matériel réseau • Coûts supplémentaires • Electricité • Climatisation • Personnel
- 5. Les limites de « on-prem »
- 6. Les limites de « on-prem »
- 8. Migrer vers Le Cloud ? • Montée en charge • + de clients • + de trafic • Événements spéciaux • Émission à succès • Match de football • Dans plusieurs pays le même soir ! • Souplesse et élasticité
- 9. Services managés • Services fournis par AWS • S3, RDS, DynamoDB, Elasticache/Redis, Elasticsearch, ECR, SNS, Route 53, SQS… • Pilotage via Terraform • Chaque projet gère son infrastructure
- 10. Des applications, des conteneurs • Packaging et déploiement • Isolation • Reproductibilité • Microservices • Concepts familiers
- 11. « Comment toujours avoir nginx et php-fpm qui tournent ? » « Comment les faire communiquer ? »
- 12. « Comment scaler le nombre de conteneurs php-fpm (automatiquement) en fonction de la charge ? »
- 13. Kubernetes • Orchestrateur de référence • Fin 2017 : prenait la tête • 2018 : a gagné la guerre • EKS ? • À Paris après le début de notre migration • À Ré-essayer • Kops
- 14. Résilience
- 15. Et « serverless » alors ? • Exécution de code : Lambda • Adapté en réaction à des événements • Pas toujours adapté au temps réel • Gestion des coûts ? • Déploiement, mise à jour, maintenance ? • Mais pas que ! • Stockage de fichiers, de données • File de messages • …
- 16. Un projet global • Volonté / besoin de l’entreprise • Centaines de jours de travail • Implique tout le monde • Impacts sur le produit et les roadmaps • Soutien et volonté du management • Migrer dans Le Cloud n’est pas un « projet technique »
- 17. Organisation des équipes • Ops : infrastructure de base • Dev : adaptation des projets • Ops + devs : tests de performance • DevOps : accompagnement
- 18. AWS, Paris On-prem Paris – PA3 AWS eu-west-3 1,4 ms
- 21. L’enfer des coûts • Tout se paye • Instances, réseau, volume de trafic, nombre de requêtes (lectures/écritures) logs, volume de données… • Avec des facteurs supplémentaires : taille de messages, cohérence, fréquence de récupération… • Plusieurs tarifications • On-demand • Reserved – 1 an, 3 ans, paiement en avance ou non • Spot • Et autres, selon les services !
- 22. Tout tagger : les projets
- 23. Tout tagger : les services d’un projet
- 25. Piste 1 : instances spot
- 27. Piste 2 : instances réservées (c5.4xlarge, Paris) Engage- ment upfront Chaque mois Total annuel Gain % standard On demand - 0 582 6981 - No upfront Partial upfront All upfront
- 28. Piste 2 : instances réservées (c5.4xlarge, Paris) Engage- ment upfront Chaque mois Total annuel Gain % standard On demand - 0 582 6981 - No upfront 1 an 0 404 4848 31% Partial upfront 1 an 2310 193 4626 35% All upfront 1 an 4528 0 4528 36%
- 29. Piste 2 : instances réservées (c5.4xlarge, Paris) Engage- ment upfront Chaque mois Total annuel Gain % standard On demand - 0 582 6981 - No upfront 1 an 0 404 4848 31% 3 ans 0 285 3420 52% Partial upfront 1 an 2310 193 4626 35% 3 ans 4750 132 3167 55% All upfront 1 an 4528 0 4528 36% 3 an 8929 0 2976 58%
- 30. Piste 2 : instances réservées (c5.4xlarge, Paris) Engage- ment upfront Chaque mois Total annuel Gain % standard Gain % convertible On demand - 0 582 6981 - - No upfront 1 an 0 404 4848 31% 21% 3 ans 0 285 3420 52% 45% Partial upfront 1 an 2310 193 4626 35% 25% 3 ans 4750 132 3167 55% 49% All upfront 1 an 4528 0 4528 36% 26% 3 an 8929 0 2976 58% 50%
- 31. Piste 3 : Intelligent Tiering S3
- 32. Piste 4 : ne pas faire n’importe quoi
- 33. Développer (le business) en fonction du coût • Facturation par projet • Aide à la décision • Stopper un projet ? • Optimiser des développements ? • Influence sur les choix techniques
- 34. Notre approche : pragmatisme • Admettre qu’on ne saura pas prédire précisément • Estimer les coûts (ordre de grandeur) • Développer, déployer • Suivre la consommation régulièrement • Améliorer, optimiser, itérer
- 35. Moins cher ?
- 36. Notre planning de migration Ça prend du temps !
- 37. Une phase de R&D • Tests, validation • services managés • outils • Découverte de Kubernetes
- 38. Faisons un truc parfait
- 39. YOLO !
- 40. Moui, bon, en fait…
- 41. Une approche raisonnée • Setup • AWS • Cluster Kubernetes • Montée en compétence des équipes • Migration d’un projet – sans risque • Fiabilisation • Apprenons ! • Migration des autres projets • Améliorons au quotidien
- 42. Ça prend du temps • Former et accompagner les équipes • Ré-apprendre un métier • Intégration au travail quotidien
- 43. Itérer • a
- 44. Le résultat ? Hey, on a fait des trucs qui marchent o/
- 45. Autonomie pour les développeurs
- 46. Elasticité – Pods Kubernetes
- 47. Elasticité – Nodes – Instances EC2
- 48. Conclusion
- 49. Élasticité ++ x47En 16 minutes…
- 50. Élasticité ++ Le « pic de 21h » quotidien
- 51. Le Plan Copenhague • Retour d’expérience • 9 chapitre (~190 pages) déjà publiés leanpub.com/6cloud
Editor's Notes
- Illustration : https://unsplash.com/photos/LVmyjS0hxYU
- Illustration : https://unsplash.com/photos/lspHbhJkQ30 l’histoire des 5 semaines pour avoir un nouveau serveur opérationnel ? Oui, un peu exagéré. Mais pas tant.
- Illustration : https://unsplash.com/photos/9BJRGlqoIUk
- Illustration : https://unsplash.com/photos/FO7JIlwjOtU Historiquement : nous louons une salle dans un datacentre parisien, nous y avons placé des serveurs (que nous avons acheté au préalable), des matériels réseau. Nous payons l’électricité, la clim, des personnes qui vont racker les serveurs, … ) -> “on-prem” pour la suite de cette conf ;-)
- Charge CPU montait à 90% ou plus le soir, en soirée normale – nos serveurs commençaient à montrer leur age et à atteindre leurs limites. Note : on avait fait le choix, depuis quelques temps, de ne plus investir dans cet hébergement, puisque nous savions que nous allions le quitter.
- Exemple de limite réellement atteinte : un fois de fort trafic, une de nos applications a plafonné à 100% de CPU. Pas un incident à proprement parler, le service a continué de fonctionner… Mais pas une expérience utilisateur parfaite, puisque certaines fonctionnalités ont été ralenties pendant une heure.
- Screenshot charge sur un mois, pour montrer la saisonnalité du trafic… alors qu’on paye pour 100% du temps de machines, on-prem => Le Cloud, si on sait tirer profit de son élasticité, aiderait bien, ici ;-)
- Dès 2017 : volonté de migrer notre hébergement vers Le Cloud (Déjà dit : explique qu’on n’avait pas investi dans notre hébergement on-prem ces derniers temps)
- Quoi ? Bases de données, CDN, stockage, caches, … Pourquoi ? Ne pas les gérer nous-même. Le métier de notre entreprise, c’est plus la vidéo que gérer des serveurs. Oui, on se lie avec un fournisseur -- c’est un choix qu’on a fait : exploiter pleinement les fonctionnalités offertes par notre fournisseur de cloud. Notre approche : si un service managé répond à notre besoin, alors on prend le service managé plutôt que de gérer quelque chose nous-même. Exemple : on ne fait pas tourner PostgreSQL ou MySQL dans notre cluster Kubernetes. On passe par RDS. Et donc, aucune problématique de type “stockage persistant” dans le cluster \o/
- Nous voulions déployer nos applications principalement sous forme de conteneurs => Rester sur nginx / php (et autres) qu’on connaissait bien et qui sont très bien adaptés au Cloud et à la scalabilité, mais gagner en souplesse
- Illustration : https://unsplash.com/photos/4Ennrbj1svk
- Illustration : https://unsplash.com/photos/jvBXiynINGE
- Orchestrateur. Pour le déploiement d’applications sous forme de conteneurs Docker. Elasticité -> réponse à la question de la tenue à la charge
- Source du tweet : https://twitter.com/allspaw/status/950476356625862657 Le but de tout ça = éviter des pannes ; possiblement, en essayant de les causer en journée quand on est là et ainsi éviter des surprises le soir.
- Illustration : https://unsplash.com/photos/uEFXEqp44ws Lambda C’est quoi C’est bien pour quoi ? C’est pas adapté pour quoi ? Services managés serverless SQS -> c’est magiquement merveilleux S3 -> idem
- Illustration : https://unsplash.com/photos/U2BI3GMnSSE Volonté business Volonté politique / financière “La technique” = beaucoup de travail, mais migrer dans le cloud n’est pas un “projet technique”, ça implique “tout le monde” Potentiellement des centaines de J/H => impact sur le produit, les roadmaps ; une migration comme ça, ça se fait avec le soutien (ou la volonté) du management !
- Illustration : https://unsplash.com/photos/lbLgFFlADrY Dans un monde qui n’existe pas -- c’est un peu plus flou ; mais c’est l’idée Ops : infra “de base” Devs : adaptation des projets DevOps : accompagnement des équipes de dev
- AWS -> le plus “gros” ; pas un mauvais choix ; y compris pour trouver de l’aide / sous-traiter / recruter Région Paris -> schéma ou tableau des latences ; facilitera nos migrations (on peut déployer une appli dans le cloud qui dépende d’une DB on-prem)
- Illustration : https://unsplash.com/photos/-8a5eJ1-mmQ
- En gros, reprendre ce que je dis dans LPC ^^. Plus une histoire “drole” que des détails pour l’instant
- Illustration : https://unsplash.com/photos/L2AHkgrpYv8
- Illustration : https://unsplash.com/photos/dD46Zl-mfWQ Quelques pistes, quelques façons dont nous avons fait des économies. Liste pas du tout exhaustive, on est loin d’être allé aussi loin qu’il est possible d’aller ^^
- Principe instance spot Instances reclaimées n’importe quand => force à être résilient, permet d’anticiper des problèmes qui se poseraient sinon en prod (où, forcément, on a des serveurs qui tombent des fois) Note : on ne le fait pas (encore) en prod mais on le fait pour tous les nœuds de notre cluster Kubernetes de staging
- Illustration : https://unsplash.com/photos/Ahs_MHU8y1s
- Pour ce tableau, je prends une instance EC2 c5.4xlarge (16 CPU, 32 GB RAM), qui coute 0.808 USD/heure
- Pour ce tableau, je prends une instance EC2 c5.4xlarge (16 CPU, 32 GB RAM), qui coute 0.808 USD/heure
- Pour ce tableau, je prends une instance EC2 c5.4xlarge (16 CPU, 32 GB RAM), qui coute 0.808 USD/heure
- Pour ce tableau, je prends une instance EC2 c5.4xlarge (16 CPU, 32 GB RAM), qui coute 0.808 USD/heure
- S3 et Intelligent Tiering
- Exemple de cloudwatch logs et logstash Exemple de l’appli qui loggait “je suis vivante” 42 fois par seconde :-/ Et de celle qui faisait des stacktraces de 42 km de long en boucle :-/
- Illustration : https://unsplash.com/photos/pElSkGRA2NU Ouvre des possibilités de facturation par projet Mais aussi potentiellement “ce projet coûte X (et rapporte Y) => il faut le tuer” ; et “=> il faut l’optimiser pour réduire le coût” Nouvelle approche “pilotage par les coûts” (je reprends l’expression d’un collègue développeur au moment du choix des solutions techniques pour un projet) Développer en pensant aux services et leur pricing DynamoDB SQS -> long polling, empty receives, batcher les actions
- Illustration : https://unsplash.com/photos/OApHds2yEGQ Faire des trucs et voir, suivre la consommation régulièrement Impossible de savoir exactement à l’avance :-/ Rappel : combien coûte un développeur par jour actuellement à Lyon ? Passer des heures pour grapiller 10 € ne vaut pas toujours le coût (pun intended).
- Illustration : https://unsplash.com/photos/dQkXoqQLn40
- Illustration : https://unsplash.com/photos/YMfY-XaZA0M
- Illustration : https://unsplash.com/photos/3GZi6OpSDcY R&D : décembre -> avril
- Illustration : https://unsplash.com/photos/Yc409-8V2pU Deux mois à essayer des outils super magiques pour déployer des applis -> mais en fait bof…
- Illustration : https://unsplash.com/photos/US06QF_sxu8 YOLO, le plan copenhague Allons-y sinon on n’ira jamais !
- Illusration : https://unsplash.com/photos/loeqHoa1uWY Pas trop envie que ça finisse comme ça, quand même…
- Illustration : https://unsplash.com/photos/vJICk89hFbU Une approche qui va de l’avant, prudemment Setup AWS, création cluster (incluant montée en compétence des équipes, découverte AWS et Terraform) : avril -> juin Migrons un projet Apprenons ! Fiabilisons Migrons les autres projets
- Illustration : https://unsplash.com/photos/xBeid9r1paU Ca prend du temps, il y a du boulot ! Former et accompagner les équipes (ops, devs) Ré-apprendre un métier -> un gros effort y compris “humain” Intégration au travail du quotidien, y compris stories “business”
- Illustration : https://unsplash.com/photos/l9GSjgjE_rs Améliorer des choses tout le long ; et “après” (genre l’optimisation des couts)
- Illustration : https://unsplash.com/photos/uj3hvdfQujI
- Source du tweet : https://twitter.com/omansour/status/1090590297288069120 Deputy CTO @ M6 Distribution
- Screenshot élasticité des pods une semaine normale, pour une de nos applications « classique »
- Screenshot élasticité des nodes (instances EC2) une semaine normale Nodes == ce qu’on paye, chez AWS ;-)
- Illustration : https://unsplash.com/photos/P8b0bg-w_YA Hey, on a fait une bonne partie du chemin \o/ Des fois, on a des surprises -- genre ces jours-ci, on est sur des problèmes de résolution DNS… Une des dernières pistes en WIP, c’est un bug dans le kernel linux, dans un fichier pas modifié depuis 23 ans… En vrai, ça se passe vraiment plutôt pas mal. Il ne faut juste pas complètement paniquer. Ni avoir peur de sauter dans le vide. Bien sûr, il reste du boulot ^^
- Screenshot de 6 à 282 CPUs consommés, en 16 minutes Histoire : changement de CDN devant notre service de génération de miniatures d’images. Générer des miniatures d’images = consommateur en CPU. “Test” qu’on voulait faire depuis des mois, pour valider “pour de vrai” que vraiment ça tenait. Ça a tenu \o/ Coût ? 40 serveurs pendant 1h => 40 USD. C’est “rien” par rapport à “tomber la prod”
- Screenshot, la même chose, mais sur une plage horaire plus large ; plus de recul. Si on regarde sur 24h, on voit le pic journalier de 21h la veille… Enfin, on le « voit ». À peine, comparé aux 282 pods ^^