mytaxi_logo

Notre business repose sur l'ensemble technologique d'Elastic de deux manières. D’une part, celui-ci permet à notre app de rester réactive en tant que cache et, d’autre part, fournit un back-end pour un volume colossal de logs. Cet article décrit l'architecture utilisée pour notre cluster de logging. Mytaxi est actuellement l'app de taxis la plus utilisée en Europe: nous connectons chaque jour des milliers de clients avec des chauffeurs de taxis. La réservation, la recherche de taxis et le paiement doivent s'effectuer rapidement et sans problème 24 h/24 et 7 j/7.

Le cluster de logging

Nous avons démarré en 2013 avec une configuration plutôt standard de l'ensemble technologique d'Elastic. Celui-ci était composé de deux nœuds Elasticsearch et un nœud pour Logstash et Kibana. Cela fonctionnait très bien jusqu'à ce que notre croissance augmente rapidement en 2014. Nous avons conservé cette configuration jusqu'à mi-2015. Le cluster a été abandonné pendant la phase de croissance et ses performances étaient donc peu optimales. À la mi-2015, nous avions environ 2 To de données stockées dans Elasticsearch.

En 2013, nous avons également décidé de passer d'une structure de back-end monolithique à une architecture de micro-services. Aujourd'hui, notre back-end est composé d'environ 50 micro-services. Nous avions besoin de rassembler les logs de ces services en un seul et même endroit. En juillet 2015, nous avons donc décidé d'installer un nouveau cluster pour prendre en charge nos besoins pour les années à venir. Nous avions les exigences suivantes :

Enregistrer nos logs pendant 90 jours (un jour de données équivaut environ à 40 Go de logs)
La performance de lecture était un goulet d'étranglement lorsque nous souhaitions obtenir des données sur de longues périodes. Nous souhaitions augmenter nos performances en installant davantage de nœuds.
Le nombre de shards est configuré pendant la création des clusters. Il ne peut être modifié par la suite. Nous souhaitions un chiffre qui soit divisible à la fois par 2, 4, 5 et 10. Le plus petit commun multiple est donc 20.
Chaque serveur Elasticsearch gère un nombre pair de shards.
Bien que l'argent ne soit pas l'objectif principal, nous souhaitions atteindre un optimum entre prix et performance.

Installation du matériel et procédure

Ces exigences en tête nous sommes allés voir AWS et avons étudié les tailles d'instance possibles. Trois tailles différentes correspondaient à nos exigences (les prix ne sont peut-être plus les mêmes à l'heure actuelle) :

i2.xlarge - 4 CPU, 30,5 Go RAM, 800 Go SSD - 686,62 $/mois
i2.2xlarge - 8 CPU, 60,5 Go RAM, 2 x 800 Go SSD - 1510,57 $/mois
m1.xlarge - 4 CPU, 15 Go RAM, 4 x 420 Go HDD - 277,43 $/mois

L'option m1.xlarge nous semblait être la meilleure. Peu onéreuse, elle disposait de 4 HDD qui pouvaient être combinés à un RAID0. Dix instances de ce type pouvaient former un cluster de 150 Go de RAM et 16,8 To d'espace disque. Avec autant d'espace disque, nous aurions pu facilement augmenter la période de conservation des logs.

Pour configurer dix nœuds et installer une configuration semblable d'Elasticsearch, nous avons utilisé Ansible. Le guide combinait les rôles pour :

Le « bootstrap » de l'instance AWS (installation du nom de l'hôte, installation des packs communs, etc.)
Configurer un RAID0 dans le logiciel
Installer un logiciel de surveillance qui envoie ses informations à un proxy de surveillance au sein du même VPC
Connecter les instances à notre serveur d'annuaire, pour que les ingénieurs back-end puissent se connecter via SSH
Installer et configurer Elasticsearch notamment plusieurs plugins

Architecture du logcluster

Avec une installation de 10 nœuds d'Elasticsearch, vous vous demandez sûrement à quoi ressemble le système. Nos micro-services envoient leurs logs d'application dans un Elasticache AWS (Redis). Logstash récupère alors les logs et les traite. L'image ci-dessous illustre l'architecture.

Exemples d'utilisation du logcluster

Début novembre 2015, nous avons décidé de mettre en place un changement radical dans notre architecture back-end. Nous avons configuré chacun de nos micro-services dans un conteneur Docker basé sur un cluster AWS ECS. Ce changement majeur a été accompagné par notre logcluster. La migration devant être faite sans interrompre le service, nous avions les yeux rivés sur les écrans de Kibana. Même les augmentations les plus infimes dans les taux d'exception d'une application peuvent indiquer des problèmes dans le service live. C'est pourquoi à chaque fois qu'on lançait un conteneur pour un nouveau service, on avait tous les yeux rivés sur les grands écrans TV qui présentent les données de Kibana, et on était tous heureux lorsqu'il n'y avait pas d'exception à constater. Même si on a eu un peu peur lorsque Batman a fait son apparition...

Conclusion

Nous avons pour objectif de fournir l'expérience la plus optimale de réservation de taxi en Europe et d'étendre notre service dans davantage de villes dans les années à venir. Avec environ 50 micro-services, nous avons besoin d'un centre d'informations pour avoir une idée du statut général du système. C'est ce que fournit l'ensemble technologique d'Elasticsearch. De plus, il permet également à nos développeurs d'étudier les bugs plus en détail et de surveiller l'impact des changements de plus près.

Sebastian Herzberg est ingénieur réseau et système chez Intelligent Apps GmbH (mytaxi) à Hambourg depuis mai 2015. Depuis quelques mois, il travaille sur un nouveau système de surveillance et la migration vers Docker. Il travaille principalement sur les systèmes back-end basés sur AWS avec une équipe de 3 administrateurs système et 2 ingénieurs back-end.

SaaS

Orchestration

Articles By Sebastian Herzberg

Avec les technologies d'Elastic, tout roule !

Ne manquez aucune actualité Elastic.