0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe...

1

Architecture service haute disponibilitéLe cas du service “Renseignements” du groupe FT

Christophe Roux – [email protected]

Décembre 2007

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)

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

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

Le service sur Orange.fr

Le service sur le 118712.fr

Shortcut Annuaire sur Orange.fr

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

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)

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

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)

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.

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

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 !

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

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,…)

Exemple de fermes de serveurs

Solution mise en œuvre et raisons

Architecture cible

Validation de l’architecture : une étape essentielle

Choix de l’open source

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


Serveurs de recherche KeLight

Export des fichiers annuaire

SNCAHTTP / HTML

VPN

Transfert fichiers données pour les serveurs

Transfert fichiers index Kelight


Requêtes MySql

Ecriture réseau des logs

HTTP / XML

Serveur Back-Office & Logs

synchro MySql

Transfert fichiers logs

Transfert fichiers logs

Zone DMZ

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.

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)

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,…

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

La vie d’une application

Notions de RUN

Notions de monitoring

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 !

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

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.

Conclusion

Critères à prendre en compte et questions à se poser

questions ?

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

Des questions ?

0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe...

Documents

Transcript of 0 Architecture service haute disponibilité Le cas du service Renseignements du groupe FT Christophe...