Consulting, services, computer engineering. Implementation of technology solutions and support for businesses.

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active
 

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 , This email address is being protected from spambots. You need JavaScript enabled to view it. 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, This email address is being protected from spambots. You need JavaScript enabled to view it. 

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 ;-)

on Google+
email this page