🎬 ✉️ 🛌🏻 Wie wir den Schulen geholfen haben, auf Fernunterricht umzusteigen und mit der Belastung fertig zu werden 🥚 🅱️ 🌝

Hallo Habr! Mein Name ist Alexey Vakhov, ich bin der technische Direktor von Uchi.ru. Mitte März, als die Schulen auf Fernunterricht umstellten, stellten wir Lehrern und Schülern verschiedene Dienste für Online-Klassen zur Verfügung. Nach unseren Berechnungen hatten wir einen Sicherheitsspielraum, um dem 1,5- bis 2-fachen der Last standzuhalten. Mitte April wuchs unser Verkehr um das Achtfache. Ich musste viel tun, um über Wasser zu bleiben. Vielleicht braucht jemand unsere Erfahrung, um diese oder eine zukünftige Krise zu überleben.

Wir haben solche Überraschungen nicht erwartet und waren nicht bereit dafür, wahrscheinlich war kein einziges Unternehmen in Russland oder auf der Welt dazu bereit. Normalerweise ist die Aktivität auf Uchi.ru im März im Vergleich zum Herbst aufgrund des Frühlings und der bevorstehenden Sommerferien geringer. Zu diesem Zeitpunkt bereiten wir uns bereits auf den September vor: Wir sägen Merkmale, führen Umgestaltungen durch, führen umfangreiche architektonische Änderungen durch und führen eine weitere angenehme Routine durch. Diesmal war es jedoch anders.

Die maximale Anzahl von Unique Usern auf der Website erreichte gleichzeitig 240.000, wir haben das vorherige Maximum des aktuellen Schuljahres bei 30.000 Personen aufgezeichnet. Zu diesem Zeitpunkt wuchs die Last jeden Tag und wir arbeiteten rund um die Uhr, um den Standort zu stabilisieren.

Wenn eine solche Last auf die Site fällt, werden in der Regel Anwendungen, Dienste, Balancer, Basen, Web und Kanäle gebildet. Alle "Engpässe" der Infrastruktur werden aufgedeckt. Unter solchen Bedingungen ist es schwierig, Probleme zu diagnostizieren - symptomatisch ist alles fehlerhaft. Es ist leicht zu reparieren, wenn der Verkehr reibungslos wächst und eines ausfällt. Wenn die Last in Aufregung gerät, besteht eines der großen Probleme darin, die Ursachen von Fehlern zu verstehen.

Die Strategie für das Arbeiten unter solchen Bedingungen besteht darin, zu beseitigen, was die Site am meisten trifft, dann den nächst schmerzhaftesten Punkt zu finden, gleichzeitig nach potenziellen Problemen zu suchen und diese zu beheben und so weiter. Hier sind einige der bemerkenswertesten Dinge, die wir getan haben, um die Plattform zu stabilisieren.

Verlassen Sie sich auf sich

Während einer Krise vor dem Verkehr werden Sie als Team eins. Es hängt von Ihren Mitarbeitern ab, ob Sie Lösungen finden, mit der Krise fertig werden oder nicht.

Es gibt keine Leute in der Branche, die kommen, in Ihr komplexes System schauen, sofort etwas tun und alles wäre in Ordnung. Natürlich gibt es auf der Welt genügend Spezialisten, die die Aufgabe bewältigen, wenn Zeit bleibt. Wenn jedoch gerade eine grundlegende Lösung benötigt wird, können Sie sich nur auf Ihr Team verlassen, das das System und seine Besonderheiten kennt. Das Ergebnis und die Verantwortung für das Geschäft liegt beim Team. Eine externe Untersuchung ist ratsam, um punktweise zu verbinden.

Die operative Koordination des Anti-Krisen-Teams in einem speziellen Chat in Slack half uns, schnell zu navigieren und unsere Arbeit aufzubauen, die alle hier und jetzt gelöst wurden. Wir haben die Verantwortungsbereiche zwischen den Mitarbeitern aufgeteilt, sodass es keine Kreuzungen gab und die Jungs keine Doppelarbeit geleistet haben. An den schwierigsten Tagen musste ich buchstäblich rund um die Uhr in Kontakt bleiben.

Erweiterte Cloud

Sie können sich nicht gegen alle Krisen versichern, aber es ist wichtig, flexibel zu sein. Der Wolkenstapel gab uns eine solche Plastizität und die Möglichkeit, auch bei einem derart dramatischen Lastanstieg über Wasser zu bleiben.

Anfangs haben wir die Ressourcen unter der erhöhten Last erhöht, aber irgendwann sind wir auf die Quoten der Region unseres Cloud-Anbieters gestoßen. Auf seiner Ebene traten Probleme auf: Unsere virtuellen Server waren von Nachbarn betroffen, auf denen auch der Datenverkehr zunahm, was zu Fehlern beim Betrieb unserer Anwendungen führte. Dies wurde erwartet: Wir sind auf den Anbieter und seine Infrastruktur angewiesen, die wiederum eine hohe Belastung erfahren haben. Wir haben einige Ressourcen von virtuellen Maschinen ohne Priorität für den Hauptstandort freigegeben. Mit dem Anbieter haben wir eine dedizierte Ressource vereinbart.

Verbesserte Überwachungstools

Während der Krise hat der Alarm seine Funktion nicht erfüllt. Alle Teammitglieder überwachten bereits alle Systeme rund um die Uhr, und das Incident Management wurde auf ständige Arbeit an allen Fronten reduziert. Um die aufgetretenen Probleme vollständig zu diagnostizieren, hatten wir zu wenig Daten. Zum Überwachen virtueller Maschinen verwenden wir beispielsweise den Standardknotenexporter für Prometheus. Er ist gut darin, das große Ganze zu sehen, denn bei näherer Betrachtung begann eine einzelne virtuelle Maschine, NetData zu verwenden.

Optimierter Cache-Speicher

Ein Problem trat auch bei Schlüsselwertspeichern auf. In einer der Anwendungen konnte Redis nicht damit umgehen - in einer einzigen Kopie kann es nur auf einem Kern arbeiten. Daher verwendeten sie eine Redis-Gabel namens KeyDB, die in mehreren Threads arbeiten kann.

Um die Bandbreite in einer anderen Anwendung zu erhöhen, haben wir 10 unabhängige Redis'ov erhöht. Sie werden von unserem Service Mesh vertreten, das auch Schlüssel abschüttelt. Selbst wenn ein oder zwei Redis abstürzen, verursacht dies keine Probleme aufgrund von konsistentem Hashing. Außerdem müssen sie praktisch nicht verabreicht werden.

Das Netzwerk wurde erweitert

Wie Sie wissen, reichen 640 Kb für alle. Wir haben immer private / 24-Subnetze verwendet, aber vor dem Hintergrund der Quarantäne mussten wir dringend auf / 22 erweitern. Jetzt bietet das Netzwerk viermal so viele Server, wir hoffen, dass es mit Sicherheit ausreicht.

PgBouncer separat durchgeführt

Als relationale Datenbank verwenden wir PostgreSQL überall, einige kleine virtuelle Instanzen und irgendwo - die Installation mehrerer großer dedizierter Server für den Master und die Replikate. Der offensichtliche Engpass dieser Architektur ist der Master, der im Idealfall nur für die Aufnahme verwendet wird und nicht horizontal skaliert. Mit dem Anstieg des Datenverkehrs begannen wir, uns auf der CPU auszuruhen.

Gleichzeitig verwenden wir PgBouncer, der auf dem Assistenten und auf jedem Replikat installiert wurde, um die Verbindungen zu verwalten. An einem Port kann nicht mehr als ein Prozessorkern verwendet werden. Auf jedem Server gab es also mehrere Bouncer. Irgendwann wurde klar, dass PgBouncer selbst den materiellen Teil der CPU von der Basis entfernte, und bei maximaler Last war ein rascher Anstieg des Lastdurchschnitts und ein Rückgang der Systemleistung zu verzeichnen.

Wir haben die Türsteher auf einen separaten Server verschoben, wodurch wir 20-25% der CPU auf jedem Datenbankserver einsparen konnten.

Mit Überraschungen konfrontiert

Insbesondere in Krisenzeiten kann nur einem Tool nicht vertraut werden. Im Gegenteil, die Redundanz der Werkzeuge hilft, weil sie ein objektiveres Bild ermöglicht. Bekannte Tools versagen aus verschiedenen Gründen. Um beispielsweise die Anzahl der Personen auf einer Website zu schätzen, verwenden wir normalerweise einen Echtzeit-Google Analytics-Bericht, bei dem es sich um eine vertrauliche und genaue Metrik handelt. Aber manchmal ist es fehlerhaft und dieses Mal mussten wir uns interne Metriken wie die Anzahl der Seitenaufrufereignisse und die Anzahl der Anforderungen pro Sekunde ansehen.

Für die zentralisierte Protokollierung verwenden wir ELK. Unsere Protokolllieferungspipeline basiert auf Apache Kafka und Elastic Filebeat. Unter hoher Last wurde die Verwaltung des Holzförderers eingestellt, die Protokolle gingen verloren oder blieben zurück. Wir haben die Geschwindigkeit der Protokollübertragung und der Speicherindizierung erhöht, indem wir die Elasticsearch-Indizes bearbeitet, die Anzahl der Partitionen in Kafka und Filebeat erhöht und die Komprimierung in allen Phasen optimiert haben. Aufgrund der Tatsache, dass die Pipeline zum Sammeln von Protokollen von der Produktion getrennt ist, hatten Probleme mit dem erhöhten Datenverkehr der Protokolle keine Auswirkungen auf die Funktionsweise des Standorts.

Akzeptierte die Spielregeln

Es ist unmöglich, sich im Voraus auf jede Krise vorzubereiten, aber Sie können zunächst versuchen, ein flexibles System aufzubauen. Startups oder Unternehmen, die nach und nach aufhören, Startups zu sein, ist es in einer ruhigen Zeit nicht immer vernünftig, sich auf ein abnormales Verkehrswachstum vorzubereiten: Die Ressourcen des Teams sind begrenzt. Wenn wir ihre Vorbereitung auf etwas aufgeben, das niemals passieren kann, bleibt keine Kraft mehr für das Hauptprodukt. Es ist viel wichtiger, im Moment richtig zu reagieren und keine Angst vor mutigen Entscheidungen zu haben. Das Ergebnis ihrer Krise ist in der Regel ein Ausstieg auf ein qualitativ neues Niveau.

Hier ist so ein lustiger Frühling in diesem Jahr. Wenn es den Anschein hat, dass alles Mögliche getan wurde, stellt sich manchmal heraus, dass dies nur der Anfang ist.

Wie wir den Schulen geholfen haben, auf Fernunterricht umzusteigen und mit der Belastung fertig zu werden