0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe Roux – Décembre.

Présentation au sujet: "0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe Roux – Décembre."— Transcription de la présentation:

1 0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe Roux – christophe.roux@orange-ftgroup.com Décembre 2007

2 page 1 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)

3 page 2 Contexte Lactivité 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 à lacte et revenus publicitaires) Nécessité pour le groupe FT de re-prendre position sur le sujet

4 page 3 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

5 page 4 Le service sur Orange.fr

6 page 5 Le service sur le 118712.fr

7 page 6 Shortcut Annuaire sur Orange.fr

8 page 7 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

9 page 8 Données du problème Concevoir un moteur de recherche pour les 25 Millions denregistrements 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 dun SLA) : cest ce quon 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)

10 page 9 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

11 page 10 Pourquoi calculer le pic de requêtes et comment le calculer ? Elément clef de dimensionnement de votre plateforme – Cest 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)

12 page 11 Quest-ce quun 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 quon peut retrouver dans un SLA : –Temps de réponse maximum attendu –Disponibilité de la plateforme –Temps de prise en compte dun incident –Délai de correction de lincident 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.

13 page 12 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 Lobjectif étant de se couvrir contre les risques de pannes (matériel ou logiciel) –Panne sur un disques (systèmes RAID) –Défaillance dune carte réseau (utiliser 2 cartes réseaux) –Crash alimentation (idem) Conclusion : doubler dès que possible les éléments « critiques » dune plateforme (attention au coût cependant !)

14 page 13 Haute dispo et scalabilité 2 notions très souvent liées Scalabilité : capacité dune plateforme à franchir des paliers en terme daudience, despace de stockage,… On dira dune plateforme quelle ne scale pas ou mal si un franchissement de pallier nécessite de re-penser une (au pire toute) larchitecture Technique utilisée pour scaler : découper votre plateforme en unités fonctionnelles, et pour chaque unité fonctionnelle la composer dune « ferme de serveurs ». –Permet dassurer la redondance –Dabsorber « 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 !

15 page 14 Haute dispo : redondance Cluster actif / passif ou failover – Calcul du nombre « dunité » (ou serveur) nécessaires pour rendre le service attendu au niveau de qualité demandé – Rajout dune unité activable rapidement mais nassurant aucun service –Avantages : consomme moins de ressources quune 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 dune défaillance – Par exemple : cluster actif / passif sur des bases de données Cluster actif / actif –Calcul identique que précédemment –Rajout dune unité de prod de plus afin de pallier à la défaillance éventuelle dune autre unité –Avantage : qualité de service accrue puisquon peut se permettre de perdre une unité –Inconvénient : coûte plus cher que la solution précédente

16 page 15 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 nimporte 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,…)

17 page 16 Exemple de fermes de serveurs

18 page 17 Solution mise en œuvre et raisons Architecture cible Validation de larchitecture : une étape essentielle Choix de lopen source

19 page 18 Architecture cible

20 page 19 Focus BD : problèmes de scalabilité Un peu dhistorique, 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. Cest 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 ! Cest donc en général un SPOF de votre architecture. Exemple : avec 2 serveurs BD qui auraient besoin davoir 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 nest pas forcèment une solution car le maître encaisse toute la charge quand les utilsiateurs écrivent des données.

21 page 20

22 page 21 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 daugmenter 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)

23 page 22 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 doù lintérêt des fermes de serveur –Fermes de serveurs php / mysql –Fermes de serveurs « éléments statiques » : html, javascript,images,flash,…

24 page 23 De limportance des tests en charge Ce nest pas tout que davoir conçu votre architecture encore faut-il vérifier quelle 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 savérer complexe et coûteuse Ne surtout pas oublier cette phase dans votre « chiffrage projet » (planning et coûts) !

25 page 24 La vie dune application Notions de RUN Notions de monitoring

26 page 25 RUN Définition : une fois le produit disponible, tout ce qui concerne sa vie au cours de son utilisation. Cest le coût dentretien. Par opposition aux coûts de setup qui sont liés à la mise en œuvre dun projet (achat de serveurs, coûts initiaux de développements,…) Pour ce qui nous concerne : –Coûts récurrents de licence –Coûts dentretiens 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 savérer au final plus avantageuse sur plusieurs années grâce à des coûts de RUN compétitifs !

27 page 26 Monitoring Objectif : surveiller le bon fonctionnement de la plateforme Comment ? –Sondes mesurant lactivité de tel ou tel process –Sondes mesurant le nb de connexions tcp ouvertes –etc… Plusieurs types de sondes : des couches basses (os) jusquaux couches les plus hautes (applicatives) Permet de rendre compte : –dun éventuel incident –du niveau de SLA de la plateforme

28 page 27 Logs Essentiels pour diagnostiquer un incident Leur analyse est une aide très précieuse Sans ça vous êtes aveugle lors du déroulement dun 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 dun utilisateur.

29 page 28 Conclusion Critères à prendre en compte et questions à se poser questions ?

30 page 29 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

31 page 30 Des questions ?