Get best of the week

Nahrungsmittelinfrastruktur: Wie wir Tanuki unterstützen



Um eine berühmte historische Figur zu paraphrasieren: Die Lieferung ist für uns die wichtigste aller Dienstleistungen. Was würden wir in der aktuellen Situation ohne Brötchen oder Pizza zu Hause tun? Das möchte ich mir nicht vorstellen. So kam es, dass wir vor 2 Jahren die Unterstützung eines der größten Netzwerke übernommen haben - Tanuki . Das monatliche Publikum der Website beträgt etwa eine Million Menschen. Es ist jetzt im Jahr 2020. Als die Tanuki 2018 mit uns zusammenarbeiteten, war sie zweimal kleiner. Wir haben einen reibungslosen Umzug in ein neues Rechenzentrum sichergestellt und die Infrastruktur komplett überarbeitet - dank dessen können Standort und Anwendungen der erhöhten Belastung problemlos standhalten.

Manchmal bedauern wir sehr, dass wir geografisch weit vom nächsten Tanuki-Restaurant entfernt sind. Andernfalls würden alle unsere Erfolge (und kleinen Unglücksfälle) mit köstlichen Brötchen überfüllt sein.

Generell möchten wir Ihnen heute die Geschichte der Unterstützung eines der größten Webprojekte der heimischen „Hotellerie“ erzählen.

Wir haben uns Ende März 2018 getroffen.

Der Internationale Frauentag ist längst vorbei, aber die Jungs haben gerade die Konsequenzen bewältigt. Alles ist ziemlich banal: Am Vorabend des 8. März nahm der Verkehr stark zu und die Website war lange Zeit nicht verfügbar. Wirklich lang, nicht ein paar Stunden. Denn der Verkehr flog nicht nur über die Hauptwebsite, sondern kam auch von der Anwendung (verfügbar für Android und iOS) sowie von Aggregatoren (Yandex. Food, Delivery Club, Zaka-Zaka).

Was wir gesehen haben


Technisch erwies sich das Projekt als ziemlich kompliziert:

  • Die Site ist eine Reaktionsanwendung mit SSR (Server Side Rendering).
  • Mobile Anwendungen - für iOS / Android.
  • API - alle Anwendungen arbeiten damit.
  • Externe Systeme, einschließlich Auftragsabwicklung.


Das System war ein Reverse-Proxy-Server: Der Datenverkehr zu ihnen wurde durch das Schutzsystem vor DDoS-Angriffen geleitet und von dort bereits auf die Back-End-Server verteilt. Zum Zeitpunkt der Annahme gab es eine alte Site und API für mobile Versionen, und die Entwicklung einer neuen Site begann. Die Entwicklung der neuen API wurde auf separaten Servern durchgeführt.

Der Datenbankcluster bestand aus zwei Servern mit Master / Master-Replikation, bei denen das Umschalten im Falle eines Fehlers auf Netzwerkebene aufgrund von Floating IP durchgeführt wurde. Alle Schreibanwendungen arbeiteten mit dieser IP, während sich auf jedem Backend-Server MySQL-Slaves zum Lesen befanden - wobei die Anwendung dementsprechend mit localhost arbeitete.

An der Rezeption sahen wir folgende Probleme:

  • Ein unzureichend zuverlässiger Ausgleichsmechanismus in der Datenbankkonfiguration. Master-Replikationsmaster führte zu häufigen Fehlern.
  • Slaves auf jedem Backend - benötigten viel Speicherplatz. Manipulationen oder das Hinzufügen neuer Backend-Server waren teuer.
  • Es gab kein gemeinsames Bereitstellungssystem für Anwendungen - es gab ein eigenständiges Bereitstellungssystem über das Web.
  • Es gab kein System zum Sammeln von Protokollen - daher ist es ziemlich schwierig, Vorfälle zu untersuchen, vor allem bei der Arbeit mit dem Bestellsystem, da es keine Möglichkeit gibt, festzustellen, wie eine Bestellung eingegangen ist.
  • Es gab keine Überwachung der Geschäftsindikatoren - es war nicht möglich, einen Rückgang oder ein vollständiges Fehlen von Aufträgen rechtzeitig zu erfassen.

Nach dem ersten Audit der zur Überwachung akzeptierten Server haben wir mit der Erstellung einer operativen Roadmap begonnen. Zunächst wurden zwei Hauptarbeitsbereiche identifiziert:
  1. Stabilisierung von Anwendungen.
  2. Organisation einer komfortablen Entwicklungsumgebung für die neue API und Site.

Die Entscheidungen in die erste Richtung bezogen sich hauptsächlich auf die Stabilisierung des MySQL-Clusters. Ich wollte den Master-Replikationsmaster nicht ablehnen, aber es war unmöglich, mit einer schwebenden IP weiterzuarbeiten. In regelmäßigen Abständen wurden Unterbrechungen der Netzwerkkonnektivität beobachtet, die zu Betriebsstörungen des Clusters führten.

Zunächst haben wir beschlossen, die Floating-IP zugunsten eines Proxyservers aufzugeben, bei dem der Upstream zwischen den Mastern gesteuert wird, da wir nginx als Proxy für MySQL verwendet haben. Der zweite Schritt ist die Zuweisung von zwei separaten Servern für Slaves. Die Arbeit mit ihnen wurde auch über einen Proxyserver organisiert. Und seit der Umstrukturierung haben wir die Probleme vergessen, die mit der Arbeit mit der Datenbank verbunden sind.

Als Nächstes haben wir Bestellungen auf Abfrageebene in der Datenbank überwacht. Jede mehr oder weniger weitgehende Abweichung von der Norm führte sofort zu einer Untersuchung. Anschließend haben wir auf Protokollebene Metriken zur Überwachung externer Interaktionen, insbesondere mit dem Auftragsverwaltungssystem, erstellt.

Auf Wunsch haben wir gemeinsam mit Kollegen eine zusätzliche Anpassung aller Systeme an einen stabilen und schnellen Betrieb vorgenommen. Es wurde sowohl MySQL optimiert als auch PHP-Versionen aktualisiert. Darüber hinaus führten Kollegen ein auf Redis basierendes Caching-System ein, das auch dazu beitrug, die Datenbank zu entlasten.

All dies war wichtig ... Aber die Hauptsache für das Geschäft war eine Umsatzsteigerung. In diesem Zusammenhang hatten die Unternehmensleiter große Hoffnungen auf den neuen Standort. Für Entwickler war es notwendig, ein stabiles und praktisches System für die Bereitstellung und Anwendungssteuerung zu erhalten.

Zunächst haben wir uns Gedanken über die Montage- und Lieferpipelines der CI / CD-Anwendung sowie über die Systeme zum Sammeln und Arbeiten mit Protokollen gemacht.

Alle Client-Repositorys wurden auf einer selbst gehosteten Bitbucket-Lösung gehostet . Für die Organisation der Pipelines wurde Jenkins ausgewählt.

Zunächst war es üblich, Pipelines in Entwicklungsumgebungen zu implementieren - dies ermöglichte es uns, die Entwicklungsgeschwindigkeit erheblich zu erhöhen. Dann wurde es in Produktionsschaltungen eingeführt, wo die automatische Bereitstellung es uns ermöglichte, häufige Fehler zu vermeiden, die normalerweise durch den menschlichen Faktor verursacht werden.

Nach der Implementierung begann CI / CD, die Sammlung von Protokollen zu organisieren und mit ihnen zu arbeiten. Als Hauptstapel wurde der ELK-Stapel ausgewählt, der es dem Kunden ermöglichte, bei Vorfällen schnell und besser Untersuchungen durchzuführen. Infolgedessen ging die Anwendungsentwicklung schneller voran.

"Schrecklicher als zwei Feuer ..."


Nachdem die Tanuki recht komplexe, aber dennoch Standardaufgaben gelöst hatten, sagten sie uns, was sie schon lange sagen wollten: „Lass uns umziehen!“

Die Veränderung der DC wurde durch wirtschaftliche Faktoren verursacht. Darüber hinaus erweiterte der Kunde seine Infrastruktur um zusätzliche Services, die sich bereits im neuen DC befanden, was auch die Entscheidung für einen Umzug beeinflusste.

Die Migration eines Systems, geschweige denn eines komplexen Systems, erfordert umfangreiche Planung und große Ressourcen.

Der Umzug erfolgte iterativ: In der ersten Phase wurden Reverse-Proxy-Server im neuen DC erstellt. Und da nur sie über eine öffentliche IP-Adresse verfügen, fungierten sie auch als Zugriffspunkte für Administratoren auf das System.

Dann haben wir alle Infrastrukturdienste gestartet - Protokollierung und CI / CD. Ein Konsulerlaubt, einen bequemen, überschaubaren und ziemlich zuverlässigen Dienst der Interaktion zwischen Clientanwendungen zu organisieren.

Die folgenden Datenbanken wurden migriert, Redis und der Warteschlangenbroker - RabbitMQ. Es war wichtig, alles so zu organisieren, dass es korrekt im Service Discovery-Protokoll registriert war, das wiederum den Betrieb des DNS kontrollierte. Beachten Sie, dass die Anwendungen nicht direkt mit der Datenbank, sondern über Haproxy funktionierten, wodurch Sie bequem und ausgewogen zwischen Datenbanken und Switches im Fehlerfall wechseln können.

In der Vorbereitungsphase stieg die Datenbankreplikation zwischen Rechenzentren nicht an. Ich musste nur die Backups übertragen. Als nächstes haben wir begonnen, die Anwendungen direkt zu konfigurieren. Dies ist die Organisation aller Interaktionen über das interne DNS - die Interaktion zwischen der Anwendung und der Datenbank / Redis / RabbitMQ / externen Diensten (z. B. Bestelldienste). Im gleichen Stadium wurden natürlich alle CI / CD-Mechanismen sofort miteinander verbunden - und dann kam es zu einer zweiten Änderung der Architektur. Bisher war das Ändern der Anwendungseinstellungen über die Benutzeroberfläche nicht möglich - nur durch Bearbeiten von Dateien direkt in der Konsole. Sofort haben wir eine Lösung eingeführt, mit der Sie Einstellungen bequem verwalten können - über die Weboberfläche. Es basierte auf dem Hashicorp-Tresor (Consul fungierte als Backend dafür), mit dem wir bequeme Mechanismen für die Verwaltung von Umgebungsvariablen erstellen konnten.

Der nächste Schritt besteht darin, die Dienste auf den neuen DC umzustellen. Da die Arbeit aller Systeme mithilfe des http-Protokolls organisiert wurde und alle Domänen ein System zum Schutz vor DDoS-Angriffen durchliefen, wurde auf die Manipulation des Upstreams direkt in der Schnittstelle dieses Systems umgeschaltet.

Zuvor wurden die erforderlichen Replikate vom alten zum neuen DC organisiert. Und es wurde auf das vereinbarte Arbeitsfenster umgestellt.

Wie sieht die Infrastruktur jetzt aus?





  • Der gesamte Verkehr geht an die Balancer. Der Datenverkehr zur API erfolgt über die Tanuki-Anwendung (unter Android / iOS) nicht direkt, sondern über Qrator.
  • Auf einem statischen Server befindet sich die Hauptseite des tanuki.ru-Projekts, ein Server mit Zielseiten.
  • Der Backend-Cluster besteht jetzt aus Servern: Frontend, statisch, Server für Anwendungen.

Schema der Auftragsübergabe Die
empfangene Bestellung durchläuft Qrator (sofort filtern wir Angriffe heraus) und gelangt zur API. Dann geht er zu Raiden, um die Bestellung zu liefern, geht zu Redis und geht zu Nginx, wonach er zur Datenbank geht.

Was hat sich für den Kunden geändert?


  • Zuverlässigkeit des Systems: Im Juli 2019 wurden Probleme festgestellt - Bestellungen wurden nicht innerhalb einer Stunde erteilt. Aber das war vor dem globalen Umzug. In der Folge wurden keine größeren Zwischenfälle beobachtet.
  • Das Leben der Entwickler: Sie haben eine praktische Entwicklungsumgebung, CI / CD.
  • Fehlertoleranz: Die Infrastruktur hält jetzt viel Verkehr aus. In den Ferien erreichte der RPS beispielsweise einen Höchstwert von 550 Einheiten.

Was weiter


Unter modernen Bedingungen tritt der Online-Verkauf in den Vordergrund. Das Projekt sollte Servicekunden Zuverlässigkeit und Zugänglichkeit bieten. Die Entwicklung ist aber auch eine sehr wichtige Komponente: Produktversionen sollten für Endbenutzer so schnell und unsichtbar wie möglich sein.

Ein weiteres wichtiges Thema ist die Nutzung von Ressourcen und die Reduzierung der Kosten für die Wartung des Systems.

All dies führt dazu, dass das gesamte System überprüft werden muss. Der erste Schritt besteht darin, die Containerisierung von Anwendungen zu organisieren. Dann ist geplant, einen Kubernetes-Cluster zu organisieren. Aber darüber werden wir im nächsten Artikel sprechen. In der Zwischenzeit - guten Appetit :-)

More articles:


All Articles