Merci aux sponsors Freelance Academy, L.Systems, Keymetrics, Node.JS Paris, pour cette conférence NodeJS et ce transcript pige . Victor le directeur des opérations nous présente Keymetrics est le chef d'orchestre de l'infrastructure Node.JS, un manager de process, process manager. Keymetrics développe et maintient PM2 avec un dashboard web qui surveille le process de notre application Node.JS et en cas de crash il peut la relancer. L'application est toujours disponible. Voir PM2 ici et avec keymetrics, on a un tableau de bord de nos applications ent temps réel. Analyse de logs, si une excpeption tombe, on est averti, transaction tracing, consommation CPU, avec 14 jours de rétention de données, profiling mémoire et CPU...
Sommaire de cette conférence Keymetrics RabbitMQ avec Node.js Paris
Les speakers Nicolas, Stanislas, Quentin, Etienne
Description:
RabbitMQ est une technologie qui présente de nombreux avantages pour faire scaler une application Node.js. On l'utilise pas mal en Java, mais elle reste assez peu connue des développeurs Javascript. L'objectif de ce talk est donc de vous présenter RabbitMQ, ses concurrents, ses avantages et tous les scénarios d'utilisation en Node.js.
~~
Plongée au coeur de V8
par Sebastien Cottinet
Description:
On adore la puissance, l'expressivité et la flexibilité de Javascript. Mais on a parfois besoin que ça mouline vite. Très vite. Surtout lorsqu'on travaille avec des applications temps-réel. Dans ce talk, armés du profiler Javascript de Chrome et du surpuissant et méconnu profiler de V8, on répondra aux questions suivantes : comment trouver les bouts de code qui nous ralentissent ? Comment les optimiser, et à quel prix ? Va-t-il la peine de le faire ?
Une introduction rapide aux outils et aux pratiques d'optimisation. Étonnant et parfois même un peu effrayant...
Comment migrer de Heroku vers Google Kubernetes Engine
Description:
Cet été, on a migré une application Node.js distribuée, de Heroku vers Google Kubernetes Engine. Je pensais que ça allait être facile. Hé bien j'avais tort ! Je vais vous raconter les ratés les plus tragiques auxquels j'ai dû faire face pendant cette migration. Et si vous êtes sympas, je vous expliquerai les astuces que j'ai appliquées pour corriger le tir !
RabbitMQ avec Node.JS
Yoann Gotthilf , Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser. chez Everoad est uen marketplace qui met en relation les transporteurs avec les vendeurs. Stack NodeJS,
RabbitMQ est un broker bus: l'objectif est d'envoyer un message à des systemes qui vont cosommer
Les 3 utilisations de RabbitMQ:
-Délégation: appel REST via une API par exemple dans intercom, au lieu de tout faire dans une requete http, on met la requete en queue si on en a beaucoup pour ne pas créer de goulets d'etranglements.
-Inscription: communication entre micro services
-Bufferisation: empiler, temporiser les messages sur un stockage pas cher et pouvoir les consommer au fur et à mesure
RabbitMQ est mur, créé en 2006, basé sur un protocole standard, AMQP, open source, développé en irlande. C'est un projet maintenu par pivotal software et il y a une bonne communauté derriere, une releause par mois.
Une question? Posez-la ici
Aide au développement d'applications NodeJS
Comment utilise-t-on RabbitMQ?
Un exemple concret: quand un serveur d'email reçoit plein d'emails d'utilisateurs différents, il doit les mettre dans une file d'attente, une queue, le temps de les distribuer.
Worker queue: l'idée c'est qu'on a un producer, un service qui va publier un message dans une queue. Les messages sont empilés jusqu'à ce que les consumers consemment les messages en les dépilant.
...Voir code...
consumer.js pousse le message dans la queue. On fait une connection TCP sur un socket. On crée un channel. On crée une connection, une channel. On implémente le pattern: on fait un insert assertQueue . Notion importante: quand on déclare des queues, un contrat est étable.
Le prefetch: très important, permet de dire au service combien de message il peut consommer en même temps. Ensuite on fait un sendToQueue d'un message. On consomme le message: on recupère le message, on fait un console.log dessus, puis on fait un channel.ack(msg) pour consommer le message, c'est pour mieux gérer la consistance de la donnée quand elle passe dans le bus. Et enfin, on ferme la channel.
node consumer.js
node publisher.js
RabbitMQ est fourni avec une console par defaut qui permet de voir un peu tout ce qui se passe
Plus on envoie d'evenements, plus la queue se remplit.
On peut démarrer 2 consommateurs pour se servir des messages dans la queue. Chaque process récupère maintenant un message sur 2.
Pub/Sub : nouveau composant, qui est un échangeur qui dispatche le message au besoin entre les queues, en fonction du taux de remplissage des queus.
On va dire à la queue de se binder à l'échanger. Le consommateur se connecte à la queue pour recevoir les messages.
Dernier pattern: Routing et topics.
On va pouvoir faire du routing: on peut adresser tel message dans telle queue. On veut que par exemple le message orange passe dans la queue 1 et que le message lazy passe dans la queue 2. Chaque micro service envoie un message dans la queue. On s'abonne à l'échangeur pour écouter les évenements qui sont intéréssants.
Concrètement, on peut remplir des logs, les parser et les trier en fonction des evenements. On veut dispatcher les messages en fonction des mots qui apparaissent. 1 consommateur qui s'abonne aux messages "warning" grace au topic. On binde la queue à l'echangeur et on l'abonne au routing "warning". Idem pour les 2 autres avec les mots "error" et "info". Et voilà, en fonction des mots lus dans le log, les lignes sont envoyées sur les 3 routes en fonction des mots lus sur chaque ligne. Un peu comme si on avait 3 web-services, micro-services.
RabbitMQ est une techno très facile à mettre en place avec très peux de lignes de codes; Il y a quelques subtilités comme le prefetch.
Les solutions similaires, concurrents, challengers: Kafka (utilisé par Linkedin), Redis, Amazon SQS, Google Pub/Sub
Une question? Posez-la ici
Aide au développement d'applications NodeJS
Plongée au coeur de V8 optimisation d'un programme NodeJS
On a un code, beau propre, maintenable, mais il est lent, on aimerait bien qu'il aille plus vite. On utilise generalement un profiler: c'est un outil qui va regarder comment s'execute un code, et emet des rapports sur le fonctionnement: il analyse combien de fois les fonctions sont appelée, combien elles prennent de mémoire, de CPU, on l'utilise en général en revue de code.
2 profilers disponibles sous node.JS
Soit la commande unix que tout le monde connait: du -sh
cette commande, écrite en c, scanne le repertoire en profondeur et ca donne sa taille et son nombre de fichiers.
il s'execute en 1,25 seconde.
On va faire la même chose en Node.JS
Avec le fs de node. On prend un fichier, on prend sa taille. Si c'est un repertoire, on fait du recusif, on fait du getStat, on agrege tout ça, et ça donne la taille totale.
il s'execute en 7 secondes.
Il y a donc 6 secondes d'écart. Que se passe-t-il? On va profil pour savoir que faire pour améliorer les perfs.
La commande:
node --inspect
permet de brancher le debugger de chrome sur le code. On va pouvoir watcher, mettre des breakpoints
node --inspect-brk essai1 $home
Sur notre chromium, on a le debugguer : on va sur le profiler et on enregistre le profiling CPU du code. On fait start, on lance le code, et on fait stop quand le programme s'arrête.
On a 2 colonnes: total time, le temps total pris par 1 fonction et toutes les fonctions qu'elle appelle.
exemple, une promise appelle d'autres fonctions. Tout ce qui est () c'est du code internet Node.JS
colonne self time: code interne à la fonction.
On s'apperçoit que le garbage collector fonctionen beaucoup. On a du lstat, appels systèmes pour récuperer les tailles des fichiers. In a aussi (program). On rencontre resolve, qui est la méthode de promise resolve, promise.all, ... On s'apperçoit que les promises prennent du temps. On va tout récrire en callback, y compris promise.all
différence entre promise et callback : la callback est plus léger qu'une promise
node essai2 $home, résultat: 5 secondes. On a gagné 50% de performances dans ce cas particulier!
Idem, on lance le profiler. On remarque toujours lstat, program et garbage collector.
Utilisons le profiler de Chrome V8, avec la commande "-prof"
node --prof essai2 $home
ce "--prof" de V8 va nous générer un log
node --prof essai2 $home perflog.log
On voit le temps passé dans 7% javascript et le temps passé dans le V8 en C++ 91%. On peut donc optimiser 7% de notre code javascript.
On passe 22% du temps à réveiller des threads qui dorment!
8% de temps supplémentaire sur le thread qui se réveille.
On touche au fonctionnement de Node.JS avec son event loop. Il reveille 750000 Threads un par un.
Et si j'écrivais tout en synchrone, avec des try-catch? Qu'est-ce que ça donne?
node essai3 $home
scanned 728201 files in 2,578 seconds
On a gagné encore 50%
Conclusion: architecture/Algorithme: connaissance intime d'un langage
L'outil de profiling apporte les mesures: ça nous force à réfléchir à changer l'architecture du programme. En changeant un algorithme, on peut optimiser des fois jsuqu'à 40%
Optimiser, ça coute très cher, et ça mène des fois à des choses sales, mais nécéssaires. Identifier et se limiter aux sections critiques de code. Ca ne sert à rien d'optimiser une fonction qui s'execute 1 fois toutes les 30 secondes...
Pour des performances plus rapides, mieux vaut écrire en C, mais ça coute plus cher. Des modules NoJS utilisent des bouts de codes en C, ou en C++ pour aller plus vite...
Sebastien Cottinet
Code de la demo disponible ici sur Git:
https://github.com/scottinet/node-js-profiling-showcase
Une question? Posez-la ici
Aide au développement d'applications Node.JS
Comment migrer de Heroku vers Google Kubernetes Engine
Adrien Joly, Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.
Pourquoi migrer? Quoi migrer? Kubernites?
Algolia c'est une base de donnée en ligne, avec un moteur de recherche, sauf qu'on heberge des index de recherches. Ces index sont préoptimisés pour faire des recherches très rapide. Un crawler web chez Algolia utilise Node.JS On rajoute un manager, une base de donnée, et un RabbitMQ pour controler les managers et une UI pour manager tout ça. Quelques proxys pour scanner les contenus des SPA et les PDF.
Sur Heroku, on a un dyno professionnel avec des anndons
Pour deployer sur Heroku c'est simple, on fait juste un git push heroku
en local pour le tester, on utilise docker-compose.yml + shared .env file
docker-compose up -d
ca download les service, ca les met dans des containers, on fait enfin
yarn dev
et ca tourne...
Google Cloud Platform
3 façons de faire tourner les applicatins
On utilise container engine avec Kubernetes dessus, et en terme de stockage, on va utiliser Cloud SQL, comme MongoLab
Kubernetes c'est K8S, un moyen de deployer et d'orchester des applications qui tournent dans des containers. C'est juste une manière d'orchestrer.
K8S, deploiement, comment se connecter à une DB...
Dans kubernetes, on se retrouve avec 8 fichiers .yml avec des scripts .sh pour deployer nos services.
cubectl sert à lancer des containers, changer la configuration des containers
exemple: 02.rabbitmq.yml explique à Kubernetes de comment lancer RabbitMQ... Avec des kind: deployment et kind: service
Des variables d'environnement sont lancees par Kubernetes
deploy script:
-se connecter au Google cloud
-build
-on upload cette image pour la deployer
-on envoie les fichiers YAML pour brieffer sur comment l'app fonctionne
-on scale down
-on met à jour la DB
-on relance le service avec un sale up
Comment on se connecte à la base de donnée?
Sur Heroku c'est simple
Sur Kubernetes, c'est plus compliqué:
créer base de donnée
creer le compte de service avec sa clé JSON
creer le username db et le mot de passe
enregistrer le mot de passe en tant que secret
ecrire un cloudsql-proxy.yml qui est un proxy qui donne un port pour faire du SQL
passer des variables d'environnement...
Faire la meme chose en local pour monitorer
Variables d'environnement :
dans Heroku c'est simple, on a une UI avec clé-valeurs
dans K8S, 5 façons de gérer les variables: génerer les fichiers YAML, creer des environnements variables en secrets. Injection: on peut merger plusieurs variables d'environnement en une seule.
SSL: on veut utiliser un certificat pour acceder aux apps. Heroku avec une case permet d'utiliser un let's encrypt.
Sous K8, il faut bricoler...
Conclusion: migrer d'Heroku vers Kubernetes c'est compliqué. On est obligé de créer ses scripts, d'apprendre tous les concepts de Kubernetes
MAIS bonnes nouvelles: on a réduit le cout, et on a davantage de controle sur notre infrastructure, on maitrise davantage notre système
Ce transcript reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit
Voilà, j'espère que ça vous a plu: n'hésitez pas à noter 5/5 ;-)