Post on 03-Apr-2015
1
Architecture service haute disponibilitéLe cas du service “Renseignements” du groupe FT
Christophe Roux – christophe.roux@orange-ftgroup.com
Décembre 2007
page 2
Orange.fr en quelques chiffres
Plus de 100 M de pages / vues jour c.a.d 3000 req / s en pic
No 2 en visiteurs uniques en France derrière Google
2ème webmail français derrière MSN Hotmail
> 1 M de documents (pages)
page 3
Contexte
L’activité “Annuaire” historique dans le groupe FT (le 12)
Vente du service “Pages Jaunes” récemment (Q4 2006)
Activité “annuaire” stratégique pour le groupe FT
Valeur de marché supérieure à 1Md e (paiement à l’acte et revenus publicitaires)
Nécessité pour le groupe FT de re-prendre position sur le sujet
page 4
Le service Renseignements
Service de recherche de type annuaire ou locale– Particulier / Professionnelle et Inversée– Localisation géographique des recherches via mappy– Fonctionnalités de suggestion / aide à recherche sur les champs des formulaires de saisie– Système de saisie rapide depuis le cartouche de recherche orange
Disponible depuis le portails orange.fr / voilà.fr et 118712.fr. Des déclinaisons mobile sont prévues pour S1 2008
Evolutions prévues pour 2008– Recherche « A proximité »– Recherche 2 champs / un champ– Déclinaisons sur le mobile
No 2 derrière Pages Jaunes en terme de trafic
page 5
Le service sur Orange.fr
page 6
Le service sur le 118712.fr
page 7
Shortcut Annuaire sur Orange.fr
page 8
Cahier des charges et notions de services hautes dispo
Données du problème
Notions diverses de service haute dispo– Pic de charge– Service Level Agreement– Redondance– Scalabilité– Répartition de charge
page 9
Données du problème
Concevoir un moteur de recherche pour les 25 Millions d’enregistrements que comprend la base “annuaire’ (Plusieurs Go de données)
Audience attendue (projections marketing) > 1 M requêtes / jour, soit des pics à 30 req / s
Disponibilité 99.9 % (une des données d’un SLA) : c’est ce qu’on appelle la haute disponibilité
Pouvant “grossir” rapidement, facilement
Tout cela évidemment avec un prix de setup / run le plus bas possible !
En assurant le niveau de performance attendu (SLA)
page 10
Reliability is one of the most important requirements because even the slightest outage has significant financial consequences and impacts customer trust.
In addition, to support continuous growth, the platform needs to be highly scalable.
For example, customers should be able to view and add items to their shopping cart even if disks are failing, network routes
are flapping, or data centers are being destroyed by tornados.
ight control over the tradeoffs between availability, consistency, cost-effectiveness and performance
page 11
Pourquoi calculer le pic de requêtes et comment le calculer ?
Elément clef de dimensionnement de votre plateforme– C’est lui qui permet de “sizer” correctement le nb de machines nécessaires
Bien différencier : – Pic journalier– Pic exceptionnel (lié à une opération de comm par exemple)
Calcul : (nb de requêtes attendues par jour / 100 000) * facteur– facteur compris entre 2 et 3 (constaté par expérience)
page 12
Qu’est-ce qu’un SLA
Définition : convention de service entre 2 parties qui engage une des 2 parties (le fournisseur / hébergeur) à un certain nombre de contraintes afin de garantir une certaine qualité de service
Un exemple simple de SLA : garantie de réponse en moins de 300 ms pendant 99.9% du temps avec un pic de requêtes de 500 / s
.
Quelques éléments qu’on peut retrouver dans un SLA :– Temps de réponse maximum attendu– Disponibilité de la plateforme– Temps de prise en compte d’un incident– Délai de correction de l’incident en fonction de sa gravité– etc…
Cadre de travail essentiel dans le domaine des plateformes haute dispo et à fortes audiences où justement le CA est lié aux nombres de requêtes servies ! Exemple type, les liens sponsorisés et les moteurs de recherche.
page 13
Comment répondre à la contrainte haute dispo ?
Utiliser une architecture redondante et présentant si possible le moins de SPOF
Redondance Vs SPOF– SPOF = Single Point Of Failure– Redondance = doubler un élément physique ou logiciel
L’objectif étant de se couvrir contre les risques de pannes (matériel ou logiciel)– Panne sur un disques (systèmes RAID)– Défaillance d’une carte réseau (utiliser 2 cartes réseaux)– Crash alimentation (idem)
Conclusion : doubler dès que possible les éléments « critiques » d’une plateforme (attention au coût cependant !)
page 14
Haute dispo et scalabilité
2 notions très souvent liées
Scalabilité : capacité d’une plateforme à franchir des paliers en terme d’audience, d’espace de stockage,…
On dira d’une plateforme qu’elle ne scale pas ou mal si un franchissement de pallier nécessite de re-penser une (au pire toute) l’architecture
Technique utilisée pour scaler : découper votre plateforme en unités fonctionnelles, et pour chaque unité fonctionnelle la composer d’une « ferme de serveurs ».
– Permet d’assurer la redondance– D’absorber « rapidement et facilement » un pic de charge exceptionnel et à moindre coût– De franchir des paliers (audience, stockage,…) jusqu’à une certaine limite quand même !
page 15
Haute dispo : redondance
Cluster actif / passif ou failover– Calcul du nombre « d’unité » (ou serveur) nécessaires pour rendre le service attendu au
niveau de qualité demandé– Rajout d’une unité activable rapidement mais n’assurant aucun service– Avantages : consomme moins de ressources qu’une unité de prod car pas sollicitée et moins
cher– Inconvénient : dégradation de la qualité de service le temps d ’effectuer la bascule en
production lors d’une défaillance– Par exemple : cluster actif / passif sur des bases de données
Cluster actif / actif– Calcul identique que précédemment– Rajout d’une unité de prod de plus afin de pallier à la défaillance éventuelle d’une autre unité– Avantage : qualité de service accrue puisqu’on peut se permettre de perdre une unité– Inconvénient : coûte plus cher que la solution précédente
page 16
Haute dispo : la répartition de charge
Ferme de serveurs : n serveurs identiques fonctionnellement parlant
c.a.d stateless : quel que soit le serveur sur lequel un utilisateur/client a fait sa requête précédente, sa prochaine requête peut-être traitée par n’importe lequel des autres serveurs.
Aiguillage des requêtes assuré par des équipements réseaux (eux-même redondés) de type webswitch. Ces équipements sont soit de type boitiers : arrowpoint, alteon,… ou logiciel Linux Virtual System.
Attention aux architectures avec Sticky ! Celles ci se prêtent très mal aux fortes montées en charge car difficilement scalable.
– Eviter le plus possible les sessions PHP, Java,…)
page 17
Exemple de fermes de serveurs
page 18
Solution mise en œuvre et raisons
Architecture cible
Validation de l’architecture : une étape essentielle
Choix de l’open source
page 19
Architecture cible
Frontaux (Web + Moteur)
Internet
Répartiteur de charges
Analyseur de requêtes – serveur auto-complétion
HTTP / XML
Traitement des données brutes
Export des fiches KeLight
Indexation KeLight + Master MySql
Répartiteur de charges
Serveurs de recherche KeLight
Export des fichiers annuaire
SNCAHTTP / HTML
VPN
Transfert fichiers données pour les serveurs
Transfert fichiers index Kelight
Répartiteur de charges
Requêtes MySql
Ecriture réseau des logs
HTTP / XML
Serveur Back-Office & Logs
synchro MySql
Transfert fichiers logs
Transfert fichiers logs
Zone DMZ
page 20
Focus BD : problèmes de scalabilité
Un peu d’historique, la base de données relationnelle est présente depuis les premières heures du web ou presque et sert de base à des sites servant plusieurs millions de requêtes. C’est donc une technologie éprouvée !
Mais pour des raisons intrinsèques, il est difficile de paralléliser et de créer de la redondance avec une base de donnée ! C’est donc en général un SPOF de votre architecture.
Exemple : avec 2 serveurs BD qui auraient besoin d’avoir les mêmes données, dans une situation où Il faut à la fois écrire et lire ces données, il devient très difficile de synchroniser les changements. Fonctionner avec une architecture Maître / esclave n’est pas forcèment une solution car le maître encaisse toute la charge quand les utilsiateurs écrivent des données.
page 21
page 22
Les architectures Maître / Esclave
Terme très souvent employé dans la cadre des Bases de données
Principe (version la plus simple) : un serveur sql maître sur lequel on peut écrire (et lire), n serveurs esclaves (sur lequel on ne peut que lire) qui répliquent à chaque instant les données du serveur maître
Intérêt : l’écriture est pénalisante mais cela permet surtout d’augmenter la surface de lecture « facilement et rapidement » (ferme de serveurs SQL en read-only)
La plus simple car maintenant on peut avoir plusieurs serveurs maîtres (Oracle, Mysql)
page 23
Moindre coût
Utilisation de technologies open source ou LAMP– Linux Apache Php Mysql– Pas de coûts de licences récurrents à payer (MS, Oracle ont un système de facturation
annuel à la CPU)
Serveurs équivalent à de « gros » PCs donc faible coût (par opposition à du matériel SUN par exemple bien que les prix baissent fortement)
Mutualisation dès que possible de plusieurs services sur une même plateforme d’où l’intérêt des fermes de serveur
– Fermes de serveurs php / mysql– Fermes de serveurs « éléments statiques » : html, javascript,images,flash,…
page 24
De l’importance des tests en charge
Ce n’est pas tout que d’avoir conçu votre architecture encore faut-il vérifier qu’elle va tenir la charge le jour J !
Importance des campagnes de tests en charge ou benchs– De connaître les limites de fonctionnement de la plateforme– De connaître unitairement quelles sont les perfs de chacun des éléments– Nécessité de refaire une campagne à chaque évolution « majeure » fonctionnelle de la
plateforme– Peut s’avérer complexe et coûteuse
Ne surtout pas oublier cette phase dans votre « chiffrage projet » (planning et coûts) !
page 25
La vie d’une application
Notions de RUN
Notions de monitoring
page 26
RUN
Définition : une fois le produit disponible, tout ce qui concerne sa vie au cours de son utilisation. C’est le coût d’entretien.
Par opposition aux coûts de setup qui sont liés à la mise en œuvre d’un projet (achat de serveurs, coûts initiaux de développements,…)
Pour ce qui nous concerne :– Coûts récurrents de licence– Coûts d’entretiens des serveurs (disque,…)– Coûts d’électricité (alimentation, climatisation,…)– Coûts humains liés aux activités précédentes– Corrections de bugs– Maintenance évolutive
A prendre en compte dans le chiffrage de votre solution et fera partie du business plan
A optimiser évidemment. Une solution plus coûteuse en terme de développement initial (setup) peut s’avérer au final plus avantageuse sur plusieurs années grâce à des coûts de RUN compétitifs !
page 27
Monitoring
Objectif : surveiller le bon fonctionnement de la plateforme
Comment ?– Sondes mesurant l’activité de tel ou tel process– Sondes mesurant le nb de connexions tcp ouvertes– etc…
Plusieurs types de sondes : des couches basses (os) jusqu’aux couches les plus hautes (applicatives)
Permet de rendre compte : – d’un éventuel incident– du niveau de SLA de la plateforme
page 28
Logs
Essentiels pour diagnostiquer un incident
Leur analyse est une aide très précieuse
Sans ça vous êtes aveugle lors du déroulement d’un incident !
Vous devez savoir tout ce qui se passe au niveau de votre application
Attention quand même à ne pas être trop verbeux ! Ne racontez pas votre vie mais logguez les infos / données essentielles qui vous permettront de re-tracer le parcours et les actions d’un utilisateur.
page 29
Conclusion
Critères à prendre en compte et questions à se poser
questions ?
page 30
Quelques éléments à prendre en compte ou questions à se poser
Charge et/ou volumétries attendues sur chacun des composants (notamment les pics !)
Vitesse d’évolutions attendues de ce mêmes charge ou volumétries
SLA : temps de réponse, taux de disponibilité,…
Base de données : accès lecture ou écriture ? Fréquence ?
Hardware : idem
Budget dont je dispose
Balance entre qualité et coût à optimiser sans cesse
page 31
Des questions ?