La nouvelle architecture technique Vodeclic

Depuis de nombreux mois, nous travaillons à la restructuration complète de l’infrastructure des serveurs Vodeclic. Dans la nuit du 21 au 22 Février dernier nous avons basculé cette architecture en production, voici pourquoi et comment nous avons travaillé sur ce sujet.

La Théorie

L’architecture que nous avons construit repose sur le principe du load balancing permettant de bénéficier d’une infrastructure dites HA, haute disponibilité (High Availability). Le load balancing permet de répartir la charge du site internet sur plusieurs serveurs, dirigeant en priorité le trafic sur les moins occupés. En cas de défaillance de l’un des serveurs celui-ci n’est plus alimenté par le loadbalancer et notre service reste accessible normalement.

En Pratique

La configuration que nous avons construite est basée sur trois serveurs. Ils sont répartis dans deux Data Centers géographiquement distants et donc séparés tant pour le réseau que le courant électrique. Chacun de ces serveurs disposent strictement de la même configuration logiciel et peuvent fonctionner de façon 100% autonome. Ils sont aussi et surtout capables de fonctionner en parallèle. Cette ambivalence est l’une des difficultés majeures pour ce type d’architecture.

Ces trois serveurs sont répartis en deux ensembles : le principal est nommé « Maitre » et les autres « Esclaves ». Le serveur « Maitre » collecte l’ensemble des requêtes du site et se charge de les répartir entre tous les serveurs, il va agir comme load balancer ainsi que garant principal de la base de donnée.

En cas de défaillance ou de dégradation des performances constatées sur l’un des serveurs « Esclaves », celui-ci est immédiatement retiré par le load balancer et le service continue à fonctionner de façon transparente. Si le serveur « Maitre » est défaillant, un serveur « Esclave » va prendre sa place et donc se voir déclarer « Maitre ». Cette opération est particulièrement complexe. Notre infrastructure permet d’opérer ce changement en seulement 50 secondes, automatiquement, ce qui permet un impact très marginal voir inexistant sur le service Vodeclic.

Architecture technique (version simplifié)


Techniquement

Chaque serveur dispose de la même installation logiciels, à savoir : FreeBSD, Nginx, Unicorn, MySQL, Sphinx, Memcached, Ruby, Rails

Loadbalancer

Plutôt que de devoir gérer un load balancer matériel séparé nous avons choisi d’utiliser le serveur « Maitre » comme load balancer.
Ceci permet d’éviter la gestion et la redondance d’un serveur supplémentaire en s’appuyant sur un existant. Nous utilisons une combinaison de Nginx et de scripts « maison » pour gérer la répartition de charge entre les serveurs. Cette répartition est intelligente, c’est-à-dire qu’elle privilégie les serveurs ayant les meilleurs taux de réponse à chaque instant.

MySQL

La partie SQL est une configuration basée sur de la replication.
Du côté de notre applicatif, nous tirons parti de la configuration Master/Slave de MySQL en allant effectuer automatiquement les requêtes de type lectures directement sur les Slaves et uniquement les écritures sur le Master. Ce fonctionnement permet de décharger le Master. Pour cela nous utilisons la gem « multidb » (lien), celle-ci a comme principal intérêt de gérer de façon transparente la perte d’un serveur MySQL Slave en le black listant.

Failover

En cas de défaillance du serveur « Maitre », que nous détectons après 10 pings en échec (via un monitoring constant), un script se charge d’appeler une API de failover qui transférera son IP vers un serveur « Esclave ». Il se charge ensemble de re-configurer ce dernier comme « Maitre » et finalement de modifier les configurations applicatives de la base de donnée des autres serveurs. L’ensemble de ce processus prend au total 50 secondes. Pendant cette période, le site internet met simplement en attente les requêtes.

Déploiement

Le déploiement de notre application Ruby On Rails se fait via Capistrano (lien). Il est configuré avec un ensemble de règles spécifiques.
Nous avons opté pour gérer les crons via la gem ‘Whenever » (lien), idéal pour cette configuration multi serveurs, ou les crons sont différencié entre le « Maitre » et les « Esclaves ». La partie Ruby est géré par RVM (lien), qui permet de changer de version à la volée.

Assets

Pour nous l’un des points clé fut la réplication des assets (vidéos et images) entre chacun des serveurs. Pour cela nous avons opté pour l’utilisation d’une technologie très éprouvée : rsync. Nous avons d’ailleurs développé un plugin de stockage rsync pour la gem Paperclip.
Ainsi à chaque ajout/modification/suppression d’un asset via l’applicatif, nous appelons notre module rsync. Il se charge derrière de répliquer en temps réel les modifications sur l’ensemble des serveurs.

Scaling

Pour palier à un besoin éventuel de capacité supplémentaire, nous disposons d’un système permettant de répliquer entièrement un serveur pour créer un nouvel « Esclave ». Cette mise en œuvre est réalisable en quelques heures.

Quelques chiffres

Ces trois serveurs en production permettent aujourd’hui de vous proposer un applicatif reposant sur l’équivalent de :
- 20 processeurs à 2,26Ghz, soit un total de plus de 45Ghz
- 56 Go de Ram
- 9,5 To de disque dur

Aujourd’hui cette capacité, très largement supérieure à nos besoins, nous permet de prévenir toute augmentation de charge faisant suite par exemple au lancement d’un partenariat majeur ou l’intégration de grand volume d’utilisateurs (plusieurs dizaines de milliers).

De plus, depuis la migration sur cette architecture nous avons baissé le temps de réponse moyen des requêtes du site sous la barre des 100ms. Nous obtenons ainsi un score Apdex (lien) de 0.99/1.0, proche du maximum théorique de ce standard.

Vous pouvez suivre en direct le temps de réponse de nos serveurs : http://www.vodeclic.com/status

Conclusion

Avec cette nouvelle architecture nous remplissons deux objectifs essentiels :

  • Sécuriser la plate-forme et son accès au travers d’une solution hautement disponible permettant la tolérance à une panne matériel ou logiciel.
  • Garantir des performances et une capacité de diffusion de notre contenu maximal avec la possibilité d’augmenter en quelques heures celle-ci par l’ajout automatisé de nouveaux serveurs.

Pour finir nous souhaitons particulièrement remercier la société No-Sec, spécialiste dans les solutions de sécurités et de hautes disponibilités, sans qui l’ensemble de ce travail n’aurait pu avoir lieu.

Laisser un commentaire