Lors d’un événement important pour une banque Française, Ippon Hosting a déployé l’outil Tatami. Il s’agit du RSE opensource utilisé et développé en interne par Ippon Technologies. Un article du blog lui est d’ailleurs dédié.
Avant de le déployer, nous avons dû définir un ensemble de paramètres :
- Quelles seront la volumétrie d’utilisateurs et la période ?
- Où héberger l’infrastructure ?
Volumétrie
Cet évènement comprenait une affluence estimée à 160 000 utilisateurs. Nous devions donc réfléchir aux différentes solutions qui s’offraient à nous pour absorber ce trafic non négligeable. Il était inconcevable d’avoir le moindre dysfonctionnement. Nous avons donc choisi l’architecture suivante pour un maximum de résilience :
- Redirection de l’adresse IP publique vers 1 à N serveurs Nginx
- Serveur Nginx qui renvoie vers N serveurs Jetty
- Serveur Jetty qui interroge 3 à N serveurs Cassandra
Voici la représentation avec un schéma d’architecture :
Où héberger l’architecture
Nous nous sommes orientés vers un hébergement de type Cloud nous permettant une plus grande flexibilité pour assurer la montée en charge de l’architecture en fonction de l’utilisation de la plate-forme. Après avoir fait des recherches entre les différents acteurs du marché, notre choix s’est porté vers OutScale pour plusieurs raisons :
- Proximité de la société (présente à St Cloud, 92)
- Hébergement en France (soumis aux lois Française, une valeur ajoutée quand on suit l’actualité)
- Outscale effectue actuellement une démarche de certification ISO 27001.
Application
Un load-balancer est en charge de récupérer les flux provenant d’Internet et de les rediriger vers les serveurs Jetty. Ce load-balancer, Nginx assure les fonctions de :
- reverse proxy
- terminaison SSL
- cache de session SSL
- maintien des connexions clientes : keep-alive
- cache de fichiers JS/CSS/Images
Deux serveurs Jetty sont présents. L’application Tatami est installée sur ces deux serveurs Jetty. Tatami est configuré en cluster pour permettre la scalabilité. Pour cela :
- les sessions sont répliquées via l’utilisation d’Hazelcast
- la réplication de cache au niveau Ehcache est activée
- un cluster ElasticSearch est mis en place pour les index
- un cluster Cassandra est chargé de la persistance
Trois instances Cassandra sont installées en cluster, la configuration des serveurs est d’origine. Nous l’avons configuré pour que les données soient réparties sur les 3 serveurs. ElasticSearch est également installé en cluster sur les serveurs Cassandra.
Bilan
Grâce aux performances élevées de la plate-forme, nous avons parfaitement été en mesure d’assumer le trafic de tous les visiteurs le jour de la mise à disposition du site. Nos outils de supervision en temps réel nous ont permis de suivre en direct l’évolution de la charge sur l’ensemble de l’infrastructure (Riemann). Grâce à cela, nous pouvions réagir rapidement pour ajouter des ressources supplémentaires à tous les niveaux de notre plate-forme en fonction de la charge. Le niveau de résilience a permis de maintenir tous les services de la plate-forme actifs avec une excellente qualité de service.
