SlideShare une entreprise Scribd logo
1  sur  49
ChtiJug(Micro)services, loadbalancing et
gestion des erreurs / comment bien
gérer vos dépendances HTTP
Christophe Furmaniak

Twitter : @cfurmaniak

Github : looztra

Consultant Architecture et Culture DevOps chez Zenika

Ex Atos Multimedia Atos Worldline Worldline

(Très) Intéressé par la Gestion de la Configuration, les métriques,
le cycle de construction, livraison et déploiement des applications

Adepte de la tonte des Yaks
Yak shaving : Any apparently useless activity which, by allowing you to overcome intermediate
difficulties, allows you to solve a larger problem.

Note : j'ai l'air grincheux, mes slides ne sont pas très esthétiques,
je suis au courant
/me
Le contenu de la prez
Contexte
(micro)services
Attention, buzzwords
Martin Fowler http://martinfowler.com/articles/microservices.html
“the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in
its own process and communicating with lightweight
mechanisms, often an HTTP resource API. These services are built
around business capabilities and independently deployable by
fully automated deployment machinery.”
[Chez Pivotal => « Cloud Native Apps »]
(micro)services
Attention, buzzwords
Microservices vs SOA vs Monolith
Même combat !

Vous aurez un jour ou l'autre à gérer des dépendances

Qu'elles soient internes ou externes
− paypal, ident oauth, envoi de mel, ...

Soit vos dépendances sont soft (compatibles asynchrone):
− ESB, messaging (jms ou autre), voire WS

Soit elles sont hard (temps réel) => besoin de réactivité
− WebService http(s), ...
Comment s'y prendre ?

En mode optimiste :
− Mais pourquoi ça planterait ?
− => Mode cowboy !!!

En mode réaliste :
− Ca va planter
− => Bienvenus !
Pourquoi maintenant (1) ?
Le dév logiciel a évolué:
− Avant, la plupart du temps, on ne s'occupait pas de
cette problématique, on avait déjà suffisamment de
mal à utiliser/communiquer avec nos
dépendances :)
− Maintenant on est des grands, on doit s'en occuper,
plus d'excuses!

l'outillage et les libs (par défaut/embeded ou
extra) ont évolué
Pourquoi maintenant (2) ?
Microservices : la théorie

Les petits services sont très simple, se focalisant sur un domaine
précis, en le faisant bien

Chaque service peut être construit en utilisant le meilleur et le plus
approprié des outils pour faire le boutlot

Les systèmes construits de cette façon sont par défaut faiblement
couplés

Plusieurs développeurs et équipes peuvent livrer relativement
indépendamment les uns des autres

Ces services sont de grands facilitateurs du mode « continuous
delivery », autorisant des déploiements fréquents tout en gardant
un système global disponible et stable
(Source: Microservices – Not a free lunch by Benjamin Wooton)
Not a free lunch ?
Vous et vos ops quand vous allez livrer
Microservices : la pratique

Attention à:
− La latence
− La tolérance à la panne
− La configuration du load balancing

La gestion de la configuration
− Sans automatisation, vous allez vous prendre des murs!

Le monitoring
− Sans métriques, vous ne savez pas d'où vous partez ni où
vous allez!
Pour la latence ?

Rxjava : https://github.com/ReactiveX/RxJava/

Reactive Streams http://www.reactive-streams.org

http://techblog.netflix.com/2013/02/rxjava-netflix-api.html
Pour la tolérance à la panne ?

Hystrix https://github.com/Netflix/Hystrix (par Netflix)

cf le TIA de Thomas Recloux à DevoxxFR#2015
− https://www.devoxx.fr/2015/speaker/thomas_recloux.html
− https://github.com/trecloux/devoxx-fr-15-hystrix-demo
Focus
Loadbalancing
Loadbalancing ?
En informatique, la répartition de charge (en anglais :
load balancing) est un ensemble de techniques
permettant de distribuer une charge de travail entre
différents ordinateurs d'un groupe.
Ces techniques permettent à la fois :
- de répondre à une charge trop importante d'un
service en la répartissant sur plusieurs serveurs
- de réduire l'indisponibilité potentielle de ce service
que pourrait provoquer la panne logicielle ou
matérielle d'un unique serveur
L'appli
Guestbook
Le guestbook qui déchire

Un frontend AngularJs (nginx)

Un service API Gateway (springboot)

Un service de filtrage (springboot)

Un service de stockage (springboot)

Un backend de stockage (redis)
Frontend --> API Gateway --> Filter Service
--> Api Service --> Redis Master
--> Redis Slave

Chaque service tourne sur 2 serveurs

Sauf le redis master (parce que !)
LB
OldSchool
Le LB mis en place par ta grand-mère

Configuration d'une VIP (adresse ip virtuelle)

Loadbalancing hardware (F5/A10)

HAProxy

LVS/KeepAlived

Pas trop mauvaise gestion des indisponibilités

Pas scalable facilement

Combien de temps (et de tickets) pour que votre configuration
soit mise à jour ?

Et si on multiplie le nombre de services à loadbalancer ?
LB
Les devs prennent
Le LB mis en place par les devs #1

Chaque service doit connaitre la liste des serveurs (+port)
implémentant chacune de ces dépendances

Idéalement, les requêtes sont distribuées sur tous les 'backends'
disponibles référencés

'Tarzan faire son trou tout seul' => sans moi

Netflix à la rescousse : Ribbon

Software loadbalancers

Fault tolerance incluse

RxJava friendly
Référencement statique des serveurs
Ribbon
CommandBuilder.<String>newBuilder()
.withLoadBalancer(LoadBalancerBuilder.newBuilder().buildFixedServerListLoadBalancer(serverList))
.build(new LoadBalancerExecutable<String>() {
@Override
public String run(Server server) throws Exception {
URL url = new URL("http://" + server.getHost() + ":" + server.getPort() + path);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
return conn.getResponseMessage();
}
}).execute();
LB
Référencement
Le LB mis en place par les devs #2

Quand un des backends n'est plus dispo => ERROR!

Une solution simple (avec Netflix/Ribbon)

Utiliser un RetryHandler!

DefaultLoadBalancerRetryHandler(
int retrySameServer,
int retryNextServer,
boolean retryEnabled)
Référencement statique des serveurs + retry
LB
statique + retry
LB
Service
Le LB mis en place par les devs #3

Chaque service s'enregistre dans une base de manière
dynamique (nom + coordonnées)

Chaque service ayant besoin d'une dépendance interroge la base
et découvre les backends de ses dépéndances dynamiquement

Méta question : mais comment mes services connaissent
l'adresse de la base de registre ? :)
Enregistrement et découverte dynamique
Le LB mis en place par les devs #3

internal registration (du code dans ton app)

external registration (de la config à l'exterieur de ton app)

fichier de conf global au serveur (ex smartstack+nerve)

par application, en mode wrapper

auto-registration (écoute d'un daemon, type docker [ex
registrator])
Patterns pour l'enregistrement
Le LB mis en place par les devs #3

La base de registre est interrogeable en mode DNS

Besoin de configurer votre appli/vos serveurs pour pouvoir
utiliser le bon serveur DNS

Attention aux pb potentiels de cache DNS

!!! nginx et upstream

La base de registre fournit une API http qui permet de retrouver la
liste des backends pour un service
Patterns pour la découverte
Le LB mis en place par les devs #3

Attention à la notion de durée de validité des informations
récupérées (le TTL)

Use case: service s'appuyant sur noeuds A, B et C

ttl de 5secondes

serveur C 'tombe' dans l'intervalle des 5 secondes

le service DNS peut retourner C (il ne sait pas encore qu'il n'est
pas dispo)

le service "liste de serveurs" retournera A, B et C (idem)

si pas de bol, c'est serveur C que tu appelles en faisant
confiance à ton service "registry/dns", => BOOM
=> Le retry handler est ton ami !
Dans tous les cas
Le LB mis en place par les devs #3

Eureka

Consul (HashiCorp)

Etcd (CoreOS)

ZooKeeper (nan, oubliez en fait, ou alors utilisez Curator)

SkyDns

SmartStack (AirBnB)
Les implémentations
Le LB mis en place par les devs #3

S'appuie sur 3 composants :

ZooKeeper :

Centralisation des informations
Focus sur SmartStack
Le LB mis en place par les devs #3

Nerve

Installé sur chaque serveur hébergeant des services

Responsable :

De l'enregistrement

De la validation de l'état de santé de chaque service
(healthchecks)
Focus sur SmartStack
Le LB mis en place par les devs #3

Synapse

Installé sur chaque serveur hébergeant des services

Génération d'une config HA Proxy

Pour parler à une dépendance, chaque service s'adresse à
localhost !
Focus sur SmartStack
Le LB mis en place par les devs #3

Avantages :

utilisation de localhost

non intrusif (pas de code dans ton app!)

Inconvénients :

ZooKeeper

Maintenance du fichier de conf Nerve
Focus sur SmartStack
Le LB mis en place par les devs #3

Un ensemble de serveurs jouent le rôle de cluster central

Chaque service hébergeant des services ou devant communiquer
avec des services héberge un agent consul

Les services communiquent toujours avec 'localhost'

Requêtable en mode DNS et en mode API http
Focus sur Consul (1/3)
Le LB mis en place par les devs #3

Les deux patterns d'enregistrement sont possibles :

Enregistrement intégré dans votre appli (avec du code, cf Spring
Cloud Consul)

Enregistrement par un wrapper (shell par exemple) : pas de
code à modifier dans l'appli...mais un wrapper à configurer
Focus sur Consul (2/3)
Le LB mis en place par les devs #3

Les deux patterns de découverte sont possibles :

Découverte intégrée dans votre appli (avec du code, cf Spring
Cloud Consul + Netflix Ribbon)

Découverte en utilisant le DNS (référencement uniquement
d'une 'vip')
Focus sur Consul (3/3)
LB
Démo Consul
LB
Infrastructure au
Le LB quand c'est l'infra qui gère

Ton appli est hébergée au format container ?

T'as la chance d'utiliser un orchestrateur ?

Ben t'as rien à faire alors

(Bon, vérifier tes params de cache DNS java quand même au cas où)

Exemple d'orchestrateurs qui vont bien:

Kubernetes

Rancher
Rien à faire j'te dis !
LB
Démo Rancher
The
End
Il faut s'adapter à votre infra!

reférencement statique

reférencement vers serveur de configuration (Spring Cloud Config,
Archaius)

DNS statique

load balancer externe (haproxy, lvs+keepalived, F5/A10) (-)

reverse-proxy

consul en mode enregistrement de l'application

consul en mode "sidekick registrator (ça ne marche bien que dans
un contexte docker)"

Consul avec un wrapper-launcher

DNS dyn dans Rancher

Smartstack

les autres solutions auxquelles je n'ai pas pensé en préparant la
prez :)
+ à vos Ops et à la culture de votre entreprise !
Si vous ne deviez retenir qu'une chose
SOA/Microservices/Monolith :
dans tous les cas soyez préparés, ça va planter !
Du code ?
https://github.com/looztra/guestbook-api-server
Merci
Des questions ?

Contenu connexe

Tendances

Kubernetes University, Cap sur l’orchestration Docker
Kubernetes University, Cap sur l’orchestration DockerKubernetes University, Cap sur l’orchestration Docker
Kubernetes University, Cap sur l’orchestration DockerJean-Baptiste Claramonte
 
Journée DevOps : Puppet, un outil pour les installer tous
Journée DevOps : Puppet, un outil pour les installer tousJournée DevOps : Puppet, un outil pour les installer tous
Journée DevOps : Puppet, un outil pour les installer tousPublicis Sapient Engineering
 
Julien Maitrehenry - Docker, ça mange quoi au printemps
Julien Maitrehenry - Docker, ça mange quoi au printempsJulien Maitrehenry - Docker, ça mange quoi au printemps
Julien Maitrehenry - Docker, ça mange quoi au printempsWeb à Québec
 
Introduction à Docker et Gaudi
Introduction à Docker et GaudiIntroduction à Docker et Gaudi
Introduction à Docker et GaudiEmmanuel Quentin
 
Introduction à docker.io
Introduction à docker.ioIntroduction à docker.io
Introduction à docker.ioNicolas Hennion
 
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassinOxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassinLudovic Piot
 
Déploiement et gestion d'un site web avec Rancher
Déploiement et gestion d'un site web avec RancherDéploiement et gestion d'un site web avec Rancher
Déploiement et gestion d'un site web avec RancherAnthony Sigogne
 
NightClazz Docker Découverte
NightClazz Docker Découverte NightClazz Docker Découverte
NightClazz Docker Découverte Zenika
 
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?Membré Guillaume
 
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !Publicis Sapient Engineering
 
Docker nice meetup #1 construire, déployer et exécuter vos applications, ...
Docker nice meetup #1   construire, déployer et exécuter vos applications, ...Docker nice meetup #1   construire, déployer et exécuter vos applications, ...
Docker nice meetup #1 construire, déployer et exécuter vos applications, ...adri1s
 
Déploiements avec Docker
Déploiements avec DockerDéploiements avec Docker
Déploiements avec DockerLuis Lopez
 
Migration d'une base de code subversion vers git
Migration d'une base de code subversion vers gitMigration d'une base de code subversion vers git
Migration d'une base de code subversion vers gitGeoffrey Bachelet
 
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...Cédric Leblond
 

Tendances (20)

Kubernetes University, Cap sur l’orchestration Docker
Kubernetes University, Cap sur l’orchestration DockerKubernetes University, Cap sur l’orchestration Docker
Kubernetes University, Cap sur l’orchestration Docker
 
Journée DevOps : Puppet, un outil pour les installer tous
Journée DevOps : Puppet, un outil pour les installer tousJournée DevOps : Puppet, un outil pour les installer tous
Journée DevOps : Puppet, un outil pour les installer tous
 
Julien Maitrehenry - Docker, ça mange quoi au printemps
Julien Maitrehenry - Docker, ça mange quoi au printempsJulien Maitrehenry - Docker, ça mange quoi au printemps
Julien Maitrehenry - Docker, ça mange quoi au printemps
 
Introduction à Docker et Gaudi
Introduction à Docker et GaudiIntroduction à Docker et Gaudi
Introduction à Docker et Gaudi
 
Introduction à docker.io
Introduction à docker.ioIntroduction à docker.io
Introduction à docker.io
 
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassinOxalide Workshop #4 - Docker, des tours dans le petit bassin
Oxalide Workshop #4 - Docker, des tours dans le petit bassin
 
Déploiement et gestion d'un site web avec Rancher
Déploiement et gestion d'un site web avec RancherDéploiement et gestion d'un site web avec Rancher
Déploiement et gestion d'un site web avec Rancher
 
NightClazz Docker Découverte
NightClazz Docker Découverte NightClazz Docker Découverte
NightClazz Docker Découverte
 
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
CI, CD, pipelines, conteneurs : la cohabitation est elle possible ?
 
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
Devoxx France : Kubernetes University, Cap sur l’orchestration Docker !
 
Devoxx France : GruntJs In Action
Devoxx France : GruntJs In ActionDevoxx France : GruntJs In Action
Devoxx France : GruntJs In Action
 
Docker nice meetup #1 construire, déployer et exécuter vos applications, ...
Docker nice meetup #1   construire, déployer et exécuter vos applications, ...Docker nice meetup #1   construire, déployer et exécuter vos applications, ...
Docker nice meetup #1 construire, déployer et exécuter vos applications, ...
 
Les bases de git
Les bases de gitLes bases de git
Les bases de git
 
Docker - YaJUG
Docker  - YaJUGDocker  - YaJUG
Docker - YaJUG
 
Déploiements avec Docker
Déploiements avec DockerDéploiements avec Docker
Déploiements avec Docker
 
Présentation devops&puppet 04112014
Présentation devops&puppet 04112014 Présentation devops&puppet 04112014
Présentation devops&puppet 04112014
 
Présentation Docker
Présentation DockerPrésentation Docker
Présentation Docker
 
Intro docker
Intro dockerIntro docker
Intro docker
 
Migration d'une base de code subversion vers git
Migration d'une base de code subversion vers gitMigration d'une base de code subversion vers git
Migration d'une base de code subversion vers git
 
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...
Retour d'expérience Docker: Puissance et simplicité de VSTS, déploiement sur ...
 

Similaire à Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs comment bien gérer vos dépendances http

Le Cloud IaaS & PaaS, OpenStack réseau et sécurité
Le Cloud IaaS & PaaS, OpenStack réseau et sécuritéLe Cloud IaaS & PaaS, OpenStack réseau et sécurité
Le Cloud IaaS & PaaS, OpenStack réseau et sécuritéNoureddine BOUYAHIAOUI
 
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016Ori Pekelman
 
Conférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrConférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrOxalide
 
Mdl ocsinventory 20100330
Mdl ocsinventory 20100330Mdl ocsinventory 20100330
Mdl ocsinventory 20100330robertpluss
 
Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2tikok974
 
Road map to DevOps engineering - Elie Sirius
Road map to DevOps engineering -  Elie SiriusRoad map to DevOps engineering -  Elie Sirius
Road map to DevOps engineering - Elie SiriusGDG Bujumbura
 
Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2tikok974
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfFootballLovers9
 
Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSGerard Konan
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsGeorgeot Cédric
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAmazon Web Services
 
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...Jasmine Conseil
 
Atelier hadoop-single-sign-on
Atelier hadoop-single-sign-onAtelier hadoop-single-sign-on
Atelier hadoop-single-sign-onsahar dridi
 
Orchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerOrchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerThe Incredible Automation Day
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !VISEO
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015 ABC Systemes
 
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partieConference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partieZenika
 
Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?codedarmor
 

Similaire à Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs comment bien gérer vos dépendances http (20)

Le Cloud IaaS & PaaS, OpenStack réseau et sécurité
Le Cloud IaaS & PaaS, OpenStack réseau et sécuritéLe Cloud IaaS & PaaS, OpenStack réseau et sécurité
Le Cloud IaaS & PaaS, OpenStack réseau et sécurité
 
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
Construire Des Applications Cloud Natives - SymfonyLive Paris 2016
 
HLayer / DevOps REX
HLayer / DevOps REXHLayer / DevOps REX
HLayer / DevOps REX
 
Conférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrConférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.Fr
 
Mdl ocsinventory 20100330
Mdl ocsinventory 20100330Mdl ocsinventory 20100330
Mdl ocsinventory 20100330
 
Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2
 
Road map to DevOps engineering - Elie Sirius
Road map to DevOps engineering -  Elie SiriusRoad map to DevOps engineering -  Elie Sirius
Road map to DevOps engineering - Elie Sirius
 
Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2Mdl ocsinventory 20100330-2
Mdl ocsinventory 20100330-2
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
 
Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaS
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOps
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
 
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et  ...
Livraison en continue avec l'outillage devops - Jenkins, Ansible, Docker et ...
 
Atelier hadoop-single-sign-on
Atelier hadoop-single-sign-onAtelier hadoop-single-sign-on
Atelier hadoop-single-sign-on
 
Orchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp DockerOrchestrating Docker in production - TIAD Camp Docker
Orchestrating Docker in production - TIAD Camp Docker
 
Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !Javascript as a first programming language : votre IC prête pour la révolution !
Javascript as a first programming language : votre IC prête pour la révolution !
 
Présentation evénement AWS - 13 oct 2015
Présentation evénement AWS  - 13 oct 2015 Présentation evénement AWS  - 13 oct 2015
Présentation evénement AWS - 13 oct 2015
 
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partieConference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
 
Openstack framework Iaas
Openstack framework IaasOpenstack framework Iaas
Openstack framework Iaas
 
Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?
 

Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs comment bien gérer vos dépendances http

  • 1. ChtiJug(Micro)services, loadbalancing et gestion des erreurs / comment bien gérer vos dépendances HTTP
  • 2. Christophe Furmaniak  Twitter : @cfurmaniak  Github : looztra  Consultant Architecture et Culture DevOps chez Zenika  Ex Atos Multimedia Atos Worldline Worldline  (Très) Intéressé par la Gestion de la Configuration, les métriques, le cycle de construction, livraison et déploiement des applications  Adepte de la tonte des Yaks Yak shaving : Any apparently useless activity which, by allowing you to overcome intermediate difficulties, allows you to solve a larger problem.  Note : j'ai l'air grincheux, mes slides ne sont pas très esthétiques, je suis au courant /me
  • 3. Le contenu de la prez
  • 5. (micro)services Attention, buzzwords Martin Fowler http://martinfowler.com/articles/microservices.html “the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.” [Chez Pivotal => « Cloud Native Apps »]
  • 7. Microservices vs SOA vs Monolith Même combat !  Vous aurez un jour ou l'autre à gérer des dépendances  Qu'elles soient internes ou externes − paypal, ident oauth, envoi de mel, ...  Soit vos dépendances sont soft (compatibles asynchrone): − ESB, messaging (jms ou autre), voire WS  Soit elles sont hard (temps réel) => besoin de réactivité − WebService http(s), ...
  • 8. Comment s'y prendre ?  En mode optimiste : − Mais pourquoi ça planterait ? − => Mode cowboy !!!  En mode réaliste : − Ca va planter − => Bienvenus !
  • 9. Pourquoi maintenant (1) ? Le dév logiciel a évolué: − Avant, la plupart du temps, on ne s'occupait pas de cette problématique, on avait déjà suffisamment de mal à utiliser/communiquer avec nos dépendances :) − Maintenant on est des grands, on doit s'en occuper, plus d'excuses!  l'outillage et les libs (par défaut/embeded ou extra) ont évolué
  • 11. Microservices : la théorie  Les petits services sont très simple, se focalisant sur un domaine précis, en le faisant bien  Chaque service peut être construit en utilisant le meilleur et le plus approprié des outils pour faire le boutlot  Les systèmes construits de cette façon sont par défaut faiblement couplés  Plusieurs développeurs et équipes peuvent livrer relativement indépendamment les uns des autres  Ces services sont de grands facilitateurs du mode « continuous delivery », autorisant des déploiements fréquents tout en gardant un système global disponible et stable (Source: Microservices – Not a free lunch by Benjamin Wooton)
  • 12. Not a free lunch ? Vous et vos ops quand vous allez livrer
  • 13. Microservices : la pratique  Attention à: − La latence − La tolérance à la panne − La configuration du load balancing  La gestion de la configuration − Sans automatisation, vous allez vous prendre des murs!  Le monitoring − Sans métriques, vous ne savez pas d'où vous partez ni où vous allez!
  • 14. Pour la latence ?  Rxjava : https://github.com/ReactiveX/RxJava/  Reactive Streams http://www.reactive-streams.org  http://techblog.netflix.com/2013/02/rxjava-netflix-api.html
  • 15. Pour la tolérance à la panne ?  Hystrix https://github.com/Netflix/Hystrix (par Netflix)  cf le TIA de Thomas Recloux à DevoxxFR#2015 − https://www.devoxx.fr/2015/speaker/thomas_recloux.html − https://github.com/trecloux/devoxx-fr-15-hystrix-demo
  • 17. Loadbalancing ? En informatique, la répartition de charge (en anglais : load balancing) est un ensemble de techniques permettant de distribuer une charge de travail entre différents ordinateurs d'un groupe. Ces techniques permettent à la fois : - de répondre à une charge trop importante d'un service en la répartissant sur plusieurs serveurs - de réduire l'indisponibilité potentielle de ce service que pourrait provoquer la panne logicielle ou matérielle d'un unique serveur
  • 19. Le guestbook qui déchire  Un frontend AngularJs (nginx)  Un service API Gateway (springboot)  Un service de filtrage (springboot)  Un service de stockage (springboot)  Un backend de stockage (redis) Frontend --> API Gateway --> Filter Service --> Api Service --> Redis Master --> Redis Slave  Chaque service tourne sur 2 serveurs  Sauf le redis master (parce que !)
  • 21. Le LB mis en place par ta grand-mère  Configuration d'une VIP (adresse ip virtuelle)  Loadbalancing hardware (F5/A10)  HAProxy  LVS/KeepAlived  Pas trop mauvaise gestion des indisponibilités  Pas scalable facilement  Combien de temps (et de tickets) pour que votre configuration soit mise à jour ?  Et si on multiplie le nombre de services à loadbalancer ?
  • 23. Le LB mis en place par les devs #1  Chaque service doit connaitre la liste des serveurs (+port) implémentant chacune de ces dépendances  Idéalement, les requêtes sont distribuées sur tous les 'backends' disponibles référencés  'Tarzan faire son trou tout seul' => sans moi  Netflix à la rescousse : Ribbon  Software loadbalancers  Fault tolerance incluse  RxJava friendly Référencement statique des serveurs
  • 24. Ribbon CommandBuilder.<String>newBuilder() .withLoadBalancer(LoadBalancerBuilder.newBuilder().buildFixedServerListLoadBalancer(serverList)) .build(new LoadBalancerExecutable<String>() { @Override public String run(Server server) throws Exception { URL url = new URL("http://" + server.getHost() + ":" + server.getPort() + path); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); return conn.getResponseMessage(); } }).execute();
  • 26. Le LB mis en place par les devs #2  Quand un des backends n'est plus dispo => ERROR!  Une solution simple (avec Netflix/Ribbon)  Utiliser un RetryHandler!  DefaultLoadBalancerRetryHandler( int retrySameServer, int retryNextServer, boolean retryEnabled) Référencement statique des serveurs + retry
  • 29. Le LB mis en place par les devs #3  Chaque service s'enregistre dans une base de manière dynamique (nom + coordonnées)  Chaque service ayant besoin d'une dépendance interroge la base et découvre les backends de ses dépéndances dynamiquement  Méta question : mais comment mes services connaissent l'adresse de la base de registre ? :) Enregistrement et découverte dynamique
  • 30. Le LB mis en place par les devs #3  internal registration (du code dans ton app)  external registration (de la config à l'exterieur de ton app)  fichier de conf global au serveur (ex smartstack+nerve)  par application, en mode wrapper  auto-registration (écoute d'un daemon, type docker [ex registrator]) Patterns pour l'enregistrement
  • 31. Le LB mis en place par les devs #3  La base de registre est interrogeable en mode DNS  Besoin de configurer votre appli/vos serveurs pour pouvoir utiliser le bon serveur DNS  Attention aux pb potentiels de cache DNS  !!! nginx et upstream  La base de registre fournit une API http qui permet de retrouver la liste des backends pour un service Patterns pour la découverte
  • 32. Le LB mis en place par les devs #3  Attention à la notion de durée de validité des informations récupérées (le TTL)  Use case: service s'appuyant sur noeuds A, B et C  ttl de 5secondes  serveur C 'tombe' dans l'intervalle des 5 secondes  le service DNS peut retourner C (il ne sait pas encore qu'il n'est pas dispo)  le service "liste de serveurs" retournera A, B et C (idem)  si pas de bol, c'est serveur C que tu appelles en faisant confiance à ton service "registry/dns", => BOOM => Le retry handler est ton ami ! Dans tous les cas
  • 33. Le LB mis en place par les devs #3  Eureka  Consul (HashiCorp)  Etcd (CoreOS)  ZooKeeper (nan, oubliez en fait, ou alors utilisez Curator)  SkyDns  SmartStack (AirBnB) Les implémentations
  • 34. Le LB mis en place par les devs #3  S'appuie sur 3 composants :  ZooKeeper :  Centralisation des informations Focus sur SmartStack
  • 35. Le LB mis en place par les devs #3  Nerve  Installé sur chaque serveur hébergeant des services  Responsable :  De l'enregistrement  De la validation de l'état de santé de chaque service (healthchecks) Focus sur SmartStack
  • 36. Le LB mis en place par les devs #3  Synapse  Installé sur chaque serveur hébergeant des services  Génération d'une config HA Proxy  Pour parler à une dépendance, chaque service s'adresse à localhost ! Focus sur SmartStack
  • 37. Le LB mis en place par les devs #3  Avantages :  utilisation de localhost  non intrusif (pas de code dans ton app!)  Inconvénients :  ZooKeeper  Maintenance du fichier de conf Nerve Focus sur SmartStack
  • 38. Le LB mis en place par les devs #3  Un ensemble de serveurs jouent le rôle de cluster central  Chaque service hébergeant des services ou devant communiquer avec des services héberge un agent consul  Les services communiquent toujours avec 'localhost'  Requêtable en mode DNS et en mode API http Focus sur Consul (1/3)
  • 39. Le LB mis en place par les devs #3  Les deux patterns d'enregistrement sont possibles :  Enregistrement intégré dans votre appli (avec du code, cf Spring Cloud Consul)  Enregistrement par un wrapper (shell par exemple) : pas de code à modifier dans l'appli...mais un wrapper à configurer Focus sur Consul (2/3)
  • 40. Le LB mis en place par les devs #3  Les deux patterns de découverte sont possibles :  Découverte intégrée dans votre appli (avec du code, cf Spring Cloud Consul + Netflix Ribbon)  Découverte en utilisant le DNS (référencement uniquement d'une 'vip') Focus sur Consul (3/3)
  • 43. Le LB quand c'est l'infra qui gère  Ton appli est hébergée au format container ?  T'as la chance d'utiliser un orchestrateur ?  Ben t'as rien à faire alors  (Bon, vérifier tes params de cache DNS java quand même au cas où)  Exemple d'orchestrateurs qui vont bien:  Kubernetes  Rancher Rien à faire j'te dis !
  • 46. Il faut s'adapter à votre infra!  reférencement statique  reférencement vers serveur de configuration (Spring Cloud Config, Archaius)  DNS statique  load balancer externe (haproxy, lvs+keepalived, F5/A10) (-)  reverse-proxy  consul en mode enregistrement de l'application  consul en mode "sidekick registrator (ça ne marche bien que dans un contexte docker)"  Consul avec un wrapper-launcher  DNS dyn dans Rancher  Smartstack  les autres solutions auxquelles je n'ai pas pensé en préparant la prez :) + à vos Ops et à la culture de votre entreprise !
  • 47. Si vous ne deviez retenir qu'une chose SOA/Microservices/Monolith : dans tous les cas soyez préparés, ça va planter !

Notes de l'éditeur

  1. Expliquer le trait