Transcription

1

2 Sébastien DUBOIS Co fondateur Evolix Responsable Grégory COLPART Co fondateur Evolix Gérant / Responsable Jean Pierre FANNI Fondateur Cybercartes

3 Monter une infrastructure pour 1M VU pour qui?

4 Créé en 1997, cybercartes.com propose environ cartes virtuelles et une technologie propriétaire unique permettant l animation de photos et l enregistrement de voix pour créer de toutes pièces des cartes originales et personnalisées (LOLcartes). La société CyberCartes (créée en 2000) édite le site du même nom Visites : 1,2 millions le 1er janvier 6,7 millions (janvier) Visiteurs Uniques : le 1er janvier 4 millions (janvier) Pages vues : 40 millions (janvier) Newsletter hebdo : 3,5 millions d abonnés Base ing : 2,7 millions d abonnés optin

5 Avatar parlant LOLCartes Cartes vidéos personnalisées

6 Monter une infrastructure pour 1M VU pour quand? Fête des Mères Noël Halloween Fête des Pères Saint Valent in Muguet 1er Mai Pâques Pâques Les Voeux Fête Journée des de la Femme Grands Mères 1er Avril

7 1 Million de VU tous les jours = SIMPLE 1 Million de VU une seule fois par an = COMPLEXE Le 1er janvier le pic horaire est à 11h00 et comptabilise visites.

8 Monter une infrastructure pour 1M VU les soucis majeurs... : o Problèmes NFS / Accès disque o Montée en charge violente des frontaux web o Problèmes firewall (trop de connexions simultanées) o Saturation des bases de données o etc.

9 Monter une infrastructure pour 1M VU les changements apportés : Interactions SysAdmin / Dev Réflexions menées SysAdmin / Dev ensemble Formations techniques (cache applicatifs / HTTP, performance) Refonte de l'environnement de dév (déploiements, tests) Communication accentuée / réunions régulières Publication de best pratices

10 Définir les principes de base Parce qu'il faut toujours avoir des principes... N'importe quel équipement peut tomber (...ou presque), cela n'impacte pas la production. Une panne sur un seul équipement n'est jamais urgente. Utiliser le maximum des ressources existantes en évitant le matériel inactif, c'est à dire essayer d'être en actif/actif partout. Un équipement inactif, c'est cher. Très cher. Avoir une indépendance vis à vis des hébergeurs/opérateurs : même en cas d'attaque nucléaire sur un datacenter, la page d'accueil, le catalogue et les nouvelles commandes restent en ligne. On a déjà eu une attaque nucléaire...

11 1ère étape : séparation du full-static Le full-static coûte 100x cher en ressources Contenu concerné : JPG, JS, CSS, TXT, SWF, MP3, etc. (95%!) Sur un nom de domaine dédié : static.cybercartes.com Mise en cache générale (ajout? aux URLs) Reste «juste» la problématique bande passante / temps de réponse Solution low cost : déploiement multi serveurs Nginx sur OVH/Online (testé && approuvé avec plusieurs Gb/s de trafic) + répartition via Round Robin DNS (avec faible TTL) Solution CDN : Cloudfront, Cloudfare, Akamei, etc.

12 2ème étape : séparation en nœuds quasi-indépendants Pour une scalabilité infinie... Partitionnement de l'application en nœuds distincts (sharding) comportant cache + www + sql + filer Pas toujours possible : ( Souvent un nœud principal/critique avec des applis non partitionnables Nœuds répartis chez différents hébergeurs, notamment Amazon EC2 / Gandi pour gérer les fortes montées en charge (principe du «Cloud Hybride») Répartition via Round Robin DNS (avec faible TTL) Process asynchrones de consolidation/centralisation des datas

13 3ème étape : séparation du «cachable» / «non-cachable» Le contenu cachable est 10x cher en ressources Séparation en modules : homepage + catalogue (cachable) : envoi (non cachable) : envoi.cybercartes.com retrait (cachable) : retrait.cybercartes.com Politique différente pour chaque module (VirtualHost, droits SQL) Minimiser les sessions (car non cachable) ou alors utilisation d'un cache partiel des page (cache ESI)

14 4ème étape : séparation du «synchrone» / «asynchrone» Pour un maximum de performance! Un maximum d'actions à passer en «asynchrone» (non bloquante) Exemples : envoi d' , requêtes complexes en bases, etc. Utilisation de cron ou système dédié : Gearman, RabbitMQ Serveurs dédiés au travail de process : workers En cas de montée en charge, utilisation de serveurs temporaires sur Amazon EC2 (principe du «Cloud Hybride»)

15 L'infrastructure globale

16 Détails d'un nœud

17 Focus sur le cache/load-balancing HAProxy en frontal + après le cache Migration de Squid à Varnish en 2013 Tout ce qui est caché n'atteint pas les frontaux. C'est une grosse économie. Le cache c'est bon, mangez-en! Pour aplatir un peu les pics de charge, on précache les pages les plus visitées via un script quotidien. (merci Awstats) Passage en 2013 sur plateforme Evolix de cache (BOOST)

18 HAProxy

19 Focus sur le filer Difficile d'être en actif/actif... HTTP (via Nginx) pour les accès en lecture NFS pour les accès en écriture (à minimiser) Migration d'un SAN SCSI+serveurs vers ZFS (FreeBSD) Serveurs optimisés en RAM et disques SSD/SAS/SATA On s'appuie sur des snapshots ZFS très réguliers pour minimiser l'impact d'une éventuelle panne

20 Focus sur les bases de données Choix historique de MySQL (à l'origine un seul serveur) Réplication master/master avec load balancing Contraintes de dév (gestion du «lag», autoincrement, ALTER TABLE) Réplication master/slave pour serveur en read only (tâches annexes : calcul de stats, requêtes complexes, sauvegardes)

21 Focus sur les tests de montée en charge Avec Tsung Indispensable pour anticiper les surprises (même si on n'émule jamais parfaitement la prod) Conséquence : certaines pages redeveloppées en dehors du framework (Zend) pour des raisons de performance!!

22 Mais aussi... Memcached (cache applicatif) (Must-have) Sharedance (partage sessions PHP) (deprecated) Optimisation HA des systèmes (sysctl, etc.) Firewalls redondants OpenBSD/PF/CARP Pour les mails : serveurs Postfix virtualisés Utilisation de matériel de marques différentes (DELL/IBM/HP) et système différents (Debian/FreeBSD/OpenBSD) : «ne pas mettre tous ses œufs dans le même panier... et utiliser le meilleur à chaque poste!»

23 Monter une infrastructure pour 1M VU que retenir?

24 Défi CyberCartes relevé par Evolix avec succès! - Interactions SysAdmin / Dev Séparer full-static, cachable, non bloquant Architecture répartie sur plusieurs hébergeurs Faire des tests de montées en charge Optimisations HA (SQL, filer, LB) Utiliser la virtualisation à bon escient (Cloud Hybride) - Trouver le juste milieu entre adaptation du développement et achat de ressources

25 Warning : ne pas appliquer tous ces principes à la lettre : il faut voir au cas par cas (chaque dév a des contraintes différentes)!

26 @Evolix + Question? Evolix est un MSP (Managed Services Provider), avec une forte expertise en réseau et infogérance d'infrastructures critiques sous environnement Linux ou BSD. Evolix est composée en 2014 de 8 personnes (dont 6 administrateurs systèmes) avec un responsable technique qui est développeur officiel de la distribution Debian. Nos clients : Pure player / Agence Web / Entreprises Chiffres clés : Créée en personnes + de 400 serveurs infogérés RCP couvrant son métier d'infogérance