Dank des Elastic Stacks fahren unsere Taxis rund um die Uhr
Der Elastic Technologie Stack unterstützt unser Unternehmen in zwei verschiedenen Bereichen. Er sorgt als Cache dafür, dass unsere App reaktionsschnell ist und bleibt, und bietet ein Backend für eine gewaltige Menge Logs. In diesem Artikel wird die Architektur unseres Logging-Cluster erklärt.
Mytaxi ist aktuell die erfolgreichste Taxi-App in Europa. Jeden Tag verbinden wir tausende Kunden mit professionellen Taxifahrern. Buchung, Vermittlung und Zahlung müssen rund um die Uhr reibungslos ablaufen.
Der Logging-Cluster
Wir fingen 2013 mit einer ziemlich simplen Standardkonfiguration des Elastic Technologie Stacks an. Dieser umfasste zwei Elasticsearch-Nodes und eine Node für Logstash und Kibana. Das hat in der Zeit vor unserem exponenziellen Wachstum ab 2014 gut funktioniert. Dieses Setup lief bis Mitte 2015. Der Cluster wurde während unserer Wachstumsphase nicht berücksichtigt, weshalb es ihm an Leistung mangelte. Bis Mitte 2015 hatten wir etwa 2 TB Daten in Elasticsearch gespeichert.
2013 entschieden wir uns außerdem, den Schritt von einem kolossalen Backend hin zu Micro-Services zu wagen. Inzwischen haben wir unser Backend in etwa 50 Micro-Services aufgeteilt. Wir mussten die Logs von all diesen Services an einem zentralen Ort speichern. Im Juli 2015 entschlossen wir uns, einen neuen Cluster einzurichten, der unsere Bedürfnisse für die kommenden Jahre erfüllen würde. Wir hatten folgende Anforderungen:
- Unsere Logs für 90 Tage speichern (ein Tag entspricht ca. 40 GB Logs)
- Die Leseleistung war ein Flaschenhals, wenn Benutzer große Zeiträume nach Daten abfragten. Wir wollten die Leistung durch mehr Nodes verbessern.
- Die Anzahl der Shards wird während der Cluster-Erstellung konfiguriert. Sie kann nicht geändert werden. Wir wollten eine Zahl, die durch 2, 4, 5 und 10 geteilt werden kann. Das kleinste gemeinsame Vielfache davon ist 20.
- Jeder Elasticsearch Server sollte eine gerade Menge an Shards verwalten.
- Obwohl unser Hauptaugenmerk nicht auf dem Geld liegt, wollten wir das beste Preis-Leistungs-Verhältnis herausholen.
Obwohl unser Hauptaugenmerk nicht auf dem Geld liegt, wollten wir das beste Preis-Leistungs-Verhältnis herausholen.
Mit diesen neuen Anforderungen gingen wir zu AWS und suchten nach einer angemessenen Instanzengröße. Drei Instanzgrößen passten zu unseren Anforderungen (Preise möglicherweise veraltet):
- i2.xlarge – 4 CPUs, 30,5 GB RAM, 800 GB SSD – 686,62 $/Monat
- i2.2xlarge - 8 CPUs, 60,5 GB RAM, 2x800 GB SSD - 1510,57 $/Monat
- m1.xlarge - 4 CPUs, 15 GB RAM, 4x420 GB HDD - 277,43 $/Monat
Der m1.xlarge schien uns hier das beste Angebot zu sein. Die Instanzen sind sicher und verfügen über 4 HDDs im RAID0-Verbund. Zehn m1.xlarge-Instanzen bilden einen Cluster mit 150 GB RAM und 16,8 TB Festspeicher. Mit dieser Menge an Speicherplatz konnten wir den Aufbewahrungszeitraum der Logs sogar noch steigern.
Zur Konfiguration der zehn Nodes und Installation einer einheitlichen Elasticsearch-Konfiguration haben wir Ansible verwendet. Das Spielbuch kombinierte Rollen für:
- Bootstrapping der AWS-Instanz (Host-Namen einrichten, Installation gemeinsamer Kernsysteme etc.)
- Einrichtung eines Software-basierten RAID0
- Installation einer Beobachtungssoftware, die Berichte an einen Beobachtungs-Proxy im selben VPC sendet
- Verbindung der Instanzen mit unserem Verzeichnis-Server, damit sich die Backend-Techniker über SSH anmelden können
- Installation und Konfiguration von Elasticsearch einschließlich mehrerer Plugins
Log-Cluster-Architektur
Bei 10 gleichzeitg laufenden Elasticsearch-Nodes interessiert es Sie vielleicht, wie das Gesamtsystem aussieht. Unsere Micro-Services melden ihre Anwendungs-Logs an einen AWS-Elasticache (Redis). Logstash ruft die Logs von dort ab und verarbeitet sie. Das folgende Bild zeigt eine Architekturübersicht.
Anwendungsbeispiele des Log-Clusters
Anfang November 2015 beschlossen wir, eine große Änderung an unserer Backend-Architektur vorzunehmen. Wir begannen, jeden einzelnen unserer Micro-Services in einem Docker-Container einzurichten, der auf einem AWS ECS-Cluster lief. Diese große Änderung wurde von unserem Log-Cluster unterstützt. Da die Migration unterbrechungsfrei durchgeführt wurde, verfolgten wir aufmerksam die Anzeigen in Kibana. Selbst die kleinste Steigerung der Ausnahmequoten bei einer Anwendung hätte Probleme im laufenden Service bedeuten können. Nachdem wir also Container für einen neuen Service gestartet hatten, blickten alle wie gebannt auf den großen Bildschirm mit den Kibana-Anzeigen und jubelten, wenn keine Ausnahmen ausgelöst wurden. Obwohl wir ein bisschen Angst bekamen, als Batman auftauchte ...
Schlussfolgerung
Es ist unser Ziel, das beste Taxierlebnis in Europa zu liefern und unseren Service in den nächsten Jahren auf immer mehr Städte auszuweiten. Mit etwa 50 Micro-Services brauchen wir ein Informations-Hub, um eine Statusübersicht des Gesamtsystems zu erhalten. Für uns liefert der Elastic Technology Stack diese Übersicht. Außerdem bekommen unsere Entwickler so die Möglichkeit, Bugs tiefgreifend zu untersuchen und die Auswirkungen von Änderungen genau zu verfolgen.
Sebastian Herzberg ist ein System- und Netzwerktechniker bei Intelligent Apps GmbH (mytaxi) in Hamburg, wo er im Mai 2015 anfing. In den vergangenen Monaten hat er an Projekten wie einem neuen Überwachungssystem und der Migration auf Docker mitgearbeitet. Er ist hauptsächlich für die Backend-Systeme verantwortlich, die auf AWS laufen, und wird dabei von einem Team aus 3 Systemadministratoren und 2 Backend-Technikern unterstützt.