Wie wir einen plötzlichen Anstieg der Last um das 10-Fache im Homeoffice bewältigt haben und welche Schlussfolgerungen wir daraus gezogen haben.

Hallo, Хабр! In den letzten paar Monaten haben wir eine sehr interessante Situation erlebt, und ich möchte unsere Geschichte zum Thema Skalierung der Infrastruktur teilen. In dieser Zeit hat SberMarket die Bestellungen um das Vierfache gesteigert und den Dienst in 17 neuen Städten gestartet. Der explosive Anstieg der Nachfrage nach Lebensmittellieferungen zwang uns zur Skalierung der Infrastruktur. Lesen Sie mehr über die interessantesten und nützlichsten Erkenntnisse im Folgenden.

Mein Name ist Dima Bobylev, ich bin der technische Direktor von SberMarket. Da dies der erste Beitrag in unserem Blog ist, möchte ich ein paar Worte über mich und das Unternehmen sagen. Letzten Herbst nahm ich am Wettbewerb der jungen Leader des Runet teil. Für den Wettbewerb habe ich eine kleine Geschichte geschrieben darüber, wie wir bei SberMarket die interne Kultur und den Ansatz zur Entwicklung des Dienstes sehen. Obwohl es nicht gelang, den Wettbewerb zu gewinnen, habe ich dennoch die wichtigsten Prinzipien für die Entwicklung eines IT-Ökosystems formuliert.

Bei der Leitung eines Teams ist es wichtig, ein Gleichgewicht zwischen den Anforderungen des Unternehmens und den Bedürfnissen jedes einzelnen Entwicklers zu finden. SberMarket wächst derzeit um das 13-fache im Vergleich zum Vorjahr, was sich auf das Produkt auswirkt und ständige Erhöhungen der Volumen und Tempi der Entwicklung erfordert. Trotz dieser Herausforderung nehmen wir uns jedoch ausreichend Zeit für die vorläufige Analyse und das qualitativ hochwertige Schreiben von Code. Der entwickelte Ansatz hilft nicht nur bei der Erstellung eines funktionierenden Produkts, sondern auch bei dessen weiterer Skalierung und Entwicklung. Infolge dieses Wachstums ist SberMarket bereits zum Marktführer unter den Lebensmittellieferdiensten geworden: Wir liefern täglich etwa 18.000 Bestellungen aus, obwohl es Anfang Februar noch etwa 3.500 waren.

Eines Tages bat ein Kunde den Kurier von SberMarket, die Lebensmittel kontaktlos direkt auf den Balkon zu liefern.

Kommen wir zu den Details. In den letzten Monaten haben wir aktiv an der Skalierung der Infrastruktur unseres Unternehmens gearbeitet. Dieser Bedarf wurde durch externe und interne Faktoren erklärt. Gleichzeitig mit der Erweiterung der Kundenbasis stieg die Anzahl der angeschlossenen Geschäfte von 90 zu Beginn des Jahres auf über 200 bis Mitte Mai. Natürlich haben wir uns vorbereitet, die Hauptinfrastruktur reserviert und geplant, sowohl vertikale als auch horizontale Skalierung aller virtuellen Maschinen, die in der Yandex-Cloud gehostet werden, zu ermöglichen. Doch die Praxis hat gezeigt: „Alles, was schiefgehen kann, wird schiefgehen.“ Heute möchte ich einige der interessantesten Situationen teilen, die in diesen Wochen aufgetreten sind. Ich hoffe, unsere Erfahrungen sind für Sie nützlich.

Slave ist vollständig einsatzbereit

Bereits vor Beginn der Pandemie haben wir einen Anstieg der Anfragen an unsere Backend-Server festgestellt. Der Trend, Produkte mit Lieferung nach Hause zu bestellen, nahm zu, und mit der Einführung der ersten Maßnahmen zur Selbstisolierung aufgrund von COVID-19 stieg die Belastung dramatisch im Laufe des ganzen Tages. Es bestand die Notwendigkeit, die Master-Server der Hauptdatenbank schnell zu entlasten und einen Teil der Leseanfragen auf die Replikationsserver (Slave) zu verlagern.

Wir hatten uns im Voraus auf diesen Schritt vorbereitet, und es wurden bereits zwei Slave-Server für diese Art von Manöver in Betrieb genommen. Diese arbeiteten hauptsächlich an Batch-Aufgaben zur Generierung von Informations-Fids für den Datenaustausch mit Partnern. Diese Prozesse erzeugten zusätzliche Last und wurden zu Recht bereits vor einigen Monaten „ausgegliedert“. 

Da auf dem Slave die Replikation stattfand, hielten wir uns an das Prinzip, dass Anwendungen nur im Read-Only-Modus damit arbeiten können. Der Disaster Recovery Plan sah vor, dass wir im Falle einer Katastrophe einfach den Slave an die Stelle des Masters mounten und alle Lese- und Schreibanfragen auf den Slave umschalten können. Allerdings wollten wir auch die Replikate für die Bedürfnisse der Abteilung für Analytik nutzen, weshalb die Server nicht vollständig in den Read-Only-Status versetzt wurden; jeder Host hatte seine eigene Benutzergruppe, und einige hatten Schreibrechte, um Zwischenresultate von Berechnungen zu speichern.

Bis zu einem bestimmten Belastungsniveau hatten wir sowohl für das Schreiben als auch für das Lesen bei der Verarbeitung von HTTP-Anfragen genug Master. Mitte März, als Sbermarket die Entscheidung traf, vollständig auf Homeoffice umzusteigen, begann unser RPS sprunghaft zu steigen. Immer mehr unserer Kunden gingen in die Selbstisolation oder arbeiteten von zu Hause aus, was sich in den Lastkennzahlen niederschlug.

Die Leistungsfähigkeit des „Masters“ reichte nicht mehr aus, weshalb wir begannen, einen Teil der schwersten Leseanfragen an die Replik zu verlagern. Um die Querlenkung von Leseanfragen auf den Slave und von Schreibanfragen auf den Master transparent zu gestalten, verwendeten wir das Ruby-Gem „Octopus“. Wir erstellten einen speziellen Benutzer mit dem Suffix _readonly ohne Schreibrechte. Aufgrund eines Fehlers in der Konfiguration eines der Hosts gingen jedoch einige Schreibanfragen im Namen eines Benutzers, der entsprechende Rechte hatte, an den Slave-Server.

Das Problem trat nicht sofort auf, da die erhöhte Last das Nachziehen der Slaves verlangsamt hatte. Inkonsistenzen bei den Daten wurden am Morgen festgestellt, als nach nächtlichen Importen die Slaves den Master nicht „eingeholt“ hatten. Wir schoben dies auf die hohe Belastung des Dienstes selbst und den Import, der mit der Eröffnung neuer Geschäfte verbunden war. Aber Daten mit stundenlanger Verzögerung bereitzustellen, war inakzeptabel, und wir wechselten die Prozesse auf den zweiten analytischen Slave, da dieser über höhere Ressourcen verfügte und nicht mit Leseanfragen belastet war (was wir uns ebenfalls als Erklärung für das Fehlen des Replikationslag erklärten).oAls wir die Ursachen für das „Auseinanderlaufen“ des Haupt-Slaves klärte, war der analytische Slave bereits aus demselben Grund ausgefallen. Trotz der Verfügbarkeit von zwei zusätzlichen Servern, zu denen wir die Last im Falle eines Ausfalls des Masters verlagern wollten, stellte sich aufgrund eines bedauerlichen Fehlers heraus, dass im entscheidenden Moment keiner verfügbar war.

Da wir jedoch nicht nur einen Datenbank-Dump gemacht hatten (die Wiederherstellung dauerte zu diesem Zeitpunkt etwa 5 Stunden), sondern auch einen Snapshot des Master-Servers erstellt hatten, konnten wir die Replik in 2 Stunden starten. Allerdings erwartete uns danach ein länger dauerndes Anwachsen des Replikationsprotokolls (da der Prozess im Einzel-Thread-Modus läuft, aber das ist eine ganz andere Geschichte).

Da wir jedoch nicht nur den Dump der Datenbank erstellt haben (die Wiederherstellung dauerte zu diesem Zeitpunkt etwa 5 Stunden), sondern auch einen Snapshot des Master-Servers angefertigt haben, konnte die Replikation innerhalb von 2 Stunden gestartet werden. Allerdings wartete danach das Einspielen des Replikationsprotokolls auf uns, was eine lange Zeit in Anspruch nahm (da der Prozess im Einzelthread-Modus läuft, aber das ist eine ganz andere Geschichte).

Ausgabe: Nach solch einem Vorfall wurde klar, dass wir von der Praxis absehen müssen, die Aufzeichnung für Benutzer einzuschränken, und den gesamten Server als readonly erklären sollten. Bei diesem Ansatz kann man sich sicher sein, dass die Replikate in kritischen Momenten verfügbar sind.

Die Optimierung auch nur einer schweren Abfrage kann die Datenbank «wiederbeleben».

Obwohl wir den Katalog auf der Website ständig aktualisieren, wiesen die Abfragen, die wir auf die Slave-Server ausgelagert hatten, eine kleine Verzögerung zum Master auf. Die Zeit, die wir benötigten, um das Problem der plötzlich ausgefallenen Slaves zu entdecken und zu beheben, überschritt die «psychologische Grenze» (in dieser Zeit konnten Preisaktualisierungen stattfinden, während die Kunden veraltete Daten sahen), und wir mussten alle Abfragen auf den Haupt-Datenbankserver umschalten. Infolgedessen funktionierte die Website langsam... aber sie funktionierte wenigstens. Während die Slave-Server wiederhergestellt wurden, blieb uns nichts anderes übrig, als Optimierungen vorzunehmen. 

Während die Slave-Server sich erholten, zogen sich die Minuten langsam hin, der Master war überlastet, und wir konzentrierten alle unsere Kräfte auf die Optimierung aktiver Aufgaben gemäß dem «Pareto-Prinzip»: Wir wählten die TOP-Abfragen aus, die den Großteil der Last erzeugten, und begannen mit dem Tuning. Dies geschah direkt «im laufenden Betrieb».

Ein interessantes Phänomen war, dass ein bis zum Rand ausgelasteter MySQL-Server selbst auf geringfügige Verbesserungen der Prozesse reagiert. Die Optimierung einiger Abfragen, die nur 5% der Gesamtlast ausmachten, zeigte bereits eine spürbare Entlastung der CPU. Infolgedessen gelang es uns, einen akzeptablen Ressourcenvorrat für die Arbeit des Masters mit der Datenbank sicherzustellen und die notwendige Zeit für die Wiederherstellung der Replikate zu gewinnen. 

Ausgabe: Selbst eine kleine Optimierung ermöglicht es, während mehrerer Stunden bei Überlastung «zu überleben». Das war genau die Zeit, die wir zur Wiederherstellung der Server mit den Replikaten benötigten. Übrigens werden wir die technische Seite der Optimierung von Abfragen in einem der nächsten Beiträge besprechen. Also abonniert unseren Blog, wenn euch das nützlich erscheinen könnte.

Organisieren Sie die Überwachung der Funktionsfähigkeit der Partnerdienste.

Wir bearbeiten Kundenbestellungen, weshalb unsere Dienste ständig mit externen APIs interagieren – das sind Schnittstellen zum Versenden von SMS, Zahlungsplattformen, Routing-Systemen, Geocodern, dem FNS-Dienst und vielen anderen Systemen. Und als die Last schnell zunahm, stießen wir auf die Begrenzungen der APIs unserer Partnerdienste, an die wir zuvor nicht einmal gedacht hatten.

Ein unerwartetes Überschreiten der Quoten von Partnerdiensten kann zu Ausfallzeiten bei Ihrem eigenen Service führen. Viele APIs blockieren Kunden, die die Grenzwerte überschreiten, und in einigen Fällen kann eine Überzahl an Anfragen die Produktion beim Partner überlasten. 

Beispielsweise hatten die begleitenden Dienste im Moment des Anstiegs der Lieferungen Schwierigkeiten mit der Verteilung und der Bestimmung der Routen. Infolgedessen stellte sich heraus, dass die Bestellungen aufgegeben wurden, der Dienst zur Routenplanung jedoch nicht funktionierte. Unsere Logistiker haben unter diesen Bedingungen das Praktisch Unmögliche geleistet, und die enge Zusammenarbeit des Teams half, zeitweilige Ausfälle der Dienste auszugleichen. Aber so viele Anträge manuell zu bearbeiten, ist auf Dauer unhaltbar, und nach einiger Zeit wären wir mit einer unzulässigen Lücke zwischen den Bestellungen und deren Ausführung konfrontiert worden. 

Es wurden eine Reihe organisatorischer Maßnahmen ergriffen, und die koordinierte Arbeit des Teams half, Zeit zu gewinnen, während wir über neue Bedingungen verhandelten und auf die Modernisierung der Dienste einiger Partner warteten. Es gibt auch andere APIs, die durch hohe Ausdauer und wettbewerbsfähige Preise bei hohem Verkehr erfreuen. Zu Beginn nutzten wir eine bekannte Kartographie-API zur Bestimmung der Adresse des Lieferpunkts. Am Ende des Monats erhielten wir eine Rechnung von fast 2 Millionen Rubel. Danach entschieden wir uns, es schnell zu ersetzen. Ich werde keine Werbung machen, aber ich kann sagen, dass unsere Ausgaben deutlich gesenkt wurden.

Ausgabe: Es ist unbedingt erforderlich, die Betriebsbedingungen aller Partnerdienste zu überwachen und sie im Hinterkopf zu behalten. Selbst wenn es heute so aussieht, als ob sie "übermäßig großzügig" sind, bedeutet das nicht, dass sie morgen nicht zum Hindernis für das Wachstum werden. Und natürlich ist es besser, im Voraus über die finanziellen Bedingungen der gestiegenen Anforderungen an den Dienst zu verhandeln. 

Manchmal stellt sich heraus, dass "man mehr Gold braucht" (c) nicht hilft

Wir sind es gewohnt, in der Hauptdatenbank oder auf Anwendungsservern auf „Engpässe“ zu stoßen, aber bei der Skalierung können Probleme dort auftreten, wo man sie nicht erwartet. Für die Volltextsuche auf der Website verwenden wir die Engine Apache Solr. Mit zunehmender Last haben wir eine Verringerung der Antwortzeit festgestellt, und die CPU-Auslastung des Servers erreichte bereits 100 %. Was könnte einfacher sein — wir geben dem Solr-Container mehr Ressourcen.

Anstelle des erwarteten Leistungszuwachses ist der Server einfach „gestorben“. Er war sofort zu 100 % ausgelastet und reagierte noch langsamer. Ursprünglich hatten wir 2 Kerne und 2 GB RAM. Wir beschlossen, das zu tun, was normalerweise hilft — wir gaben dem Server 8 Kerne und 32 GB. Alles wurde viel schlimmer (wie genau und warum — dazu werden wir in einem separaten Beitrag berichten). 

Innerhalb weniger Tage haben wir die Feinheiten dieses Problems durchschaut und eine optimale Leistung bei 8 Kernen und 32 GB erreicht. Diese Konfiguration ermöglicht es uns auch heute, die Last weiterhin zu steigern, was sehr wichtig ist, da das Wachstum nicht nur bei den Kunden, sondern auch bei der Anzahl der angeschlossenen Geschäfte — in den letzten 2 Monaten hat sich deren Anzahl verdoppelt. 

Ausgabe: Standardmethoden wie „mehr Hardware hinzufügen“ funktionieren nicht immer. Daher ist es bei der Skalierung eines Dienstes wichtig, gut zu verstehen, wie er Ressourcen nutzt, und seine Leistung unter neuen Bedingungen im Voraus zu testen. 

Stateless — der Schlüssel zu einfachem horizontalem Scaling

Insgesamt hält sich unser Team an den bekannten Ansatz: Dienste sollten keinen internen Zustand (stateless) haben und unabhängig von der Laufzeitumgebung sein. Dies hat es uns ermöglicht, das Wachstum der Last durch einfaches horizontales Scaling zu bewältigen. Aber wir hatten einen Ausnahme-Service — den Verarbeiter von langwierigen Hintergrundaufgaben. Er war für den Versand von E-Mails und SMS, die Verarbeitung von Events, die Generierung von Feeds, den Import von Preisen und Beständen sowie die Verarbeitung von Bildern zuständig. Es stellte sich heraus, dass er von einem lokalen Dateispeicher abhängte und nur einmal vorhanden war. 

Als die Anzahl der Aufgaben in der Warteschlange des Prozessors wuchs (was mit der Anzahl der Bestellungen natürlich einherging), wurde die Leistung des Hosts, auf dem der Prozessor und der Datei-Speicher untergebracht waren, zum limitierenden Faktor. In der Folge blieben das Aktualisieren des Sortiments und der Preise, das Versenden von Benachrichtigungen an die Nutzer und viele andere kritische Funktionen, die in der Warteschlange feststeckten, stehen. Das Ops-Team migrierte umgehend den Datei-Speicher in einen S3-ähnlichen Cloud-Speicher, was es uns ermöglichte, mehrere leistungsstarke Maschinen hochzufahren, um den Hintergrund-Prozessor zu skalieren.

Ausgabe: Das Stateless-Prinzip muss für alle Komponenten ohne Ausnahme eingehalten werden, auch wenn es scheint, dass es "hier sicher nicht problematisch wird." Es ist besser, etwas Zeit in die ordnungsgemäße Organisation der Arbeit aller Systeme zu investieren, als später in Eile den Code umzuschreiben und einen überlasteten Service zu reparieren.

7 Prinzipien für intensives Wachstum

Trotz der Verfügbarkeit zusätzlicher Ressourcen sind wir während des Wachstums auf einige Schwierigkeiten gestoßen. In dieser Zeit hat sich die Anzahl der Bestellungen um mehr als das Vierfache erhöht. Jetzt liefern wir bereits über 17.000 Bestellungen pro Tag in 62 Städten und planen, die geografische Reichweite noch weiter auszubauen — im ersten Halbjahr 2020 wird der Start des Service in ganz Russland erwartet. Um mit der wachsenden Belastung zurechtzukommen, unter Berücksichtigung der bereits gemachten Erfahrungen, haben wir 7 grundlegende Arbeitsprinzipien unter Bedingungen ständigen Wachstums aufgestellt:

1. Incident Management. Wir haben ein Board in Jira erstellt, auf dem jeder Vorfall als Ticket erfasst wird. Dies wird helfen, die mit dem Vorfall verbundenen Aufgaben tatsächlich zu priorisieren und auszuführen. Denn im Grunde ist es nicht schlimm, Fehler zu machen — schlimm ist es, zweimal denselben Fehler zu machen. Für die Fälle, in denen Vorfälle wiederholt auftreten, bevor die Ursache behoben werden kann, sollte eine Handlungsanweisung bereitstehen, denn in Zeiten hoher Belastung ist es wichtig, blitzschnell zu reagieren.
2. Überwachung Es ist für alle Infrastruktur-Elemente ohne Ausnahme erforderlich. Dank ihm konnten wir das Wachstum der Belastung prognostizieren und die „Flaschenhälse“ für die Priorisierung der Behebung richtig auswählen. Wahrscheinlich wird bei hoher Belastung alles kaputtgehen oder anfangen zu stocken, an das Sie nicht einmal gedacht haben. Daher ist es am besten, neue Alarme sofort nach dem Auftreten der ersten Vorfälle zu erstellen, um deren Überwachung und Vorwegnahme zu ermöglichen.
3. Die richtigen Alarme sind bei einem plötzlichen Anstieg der Last einfach unverzichtbar. Erstens müssen sie genau berichten, was kaputtgegangen ist. Zweitens sollten es nicht zu viele Alarme geben, denn eine Fülle von nicht kritischen Alarmen führt dazu, dass alle Benachrichtigungen völlig ignoriert werden.
4. Anwendungen sollten zustandslos sein. Wir haben festgestellt, dass es für diese Regel keine Ausnahmen geben darf. Es ist eine vollständige Unabhängigkeit von der Laufzeitumgebung erforderlich. Dazu können Sie gemeinsam genutzte Daten in einer Datenbank oder zum Beispiel direkt in S3 speichern. Noch besser ist es, die Regeln zu befolgen https://12factor.net. Während eines plötzlichen Anstiegs bleibt keine Zeit, um den Code zu optimieren, und man muss mit direkter Erhöhung der Rechenressourcen und horizontaler Skalierung umgehen.
5. Quoten und die Leistung externer Dienste. Bei schnellem Wachstum kann das Problem nicht nur in Ihrer Infrastruktur, sondern auch im externen Dienst auftreten. Das Frustrierendste ist, wenn dies nicht aufgrund eines Ausfalls geschieht, sondern weil Quoten oder Limits erreicht werden. Daher müssen externe Dienste genauso gut skalieren wie Sie selbst. 
6. Trennen Sie Prozesse und Warteschlangen. Das hilft sehr, wenn es an einem der Gateways zu einem Engpass kommt. Wir hätten keine Verzögerungen beim Datentransfer erlebt, wenn volle Warteschlangen für das Versenden von SMS nicht den Austausch von Benachrichtigungen zwischen Informationssystemen behindert hätten. Außerdem wäre es einfacher gewesen, die Anzahl der Worker zu erhöhen, wenn sie separat gearbeitet hätten.
7. Finanzielle Realitäten. Wenn die Datenströme explosionsartig wachsen, bleibt keine Zeit, über Tarife und Abonnements nachzudenken. Aber man sollte daran denken, besonders wenn man ein kleines Unternehmen ist. Eine hohe Rechnung kann jeder API-Besitzer und auch Ihr Hosting-Anbieter ausstellen. Daher ist es wichtig, die Verträge sorgfältig zu lesen.

Fazit

Nicht ohne Verluste, aber wir haben diese Phase überstanden und versuchen heute, alle gefundenen Prinzipien einzuhalten. Jede Maschine hat die Möglichkeit, die Leistung um das Vierfache zu steigern, um mit unvorhergesehenen Ereignissen umzugehen. 

In den nächsten Beiträgen teilen wir unsere Erfahrungen bei der Untersuchung von Leistungseinbrüchen in Apache Solr und erklären, wie die Interaktion mit der FNS dem Unternehmen hilft, Geld zu sparen. Abonnieren Sie unseren Blog, um nichts zu verpassen, und erzählen Sie in den Kommentaren, ob Ihnen ähnliche Probleme beim Anstieg des Traffics passiert sind.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.

Hatten Sie langsame Reaktionen oder einen Ausfall des Dienstes bei plötzlichem Anstieg der Last aufgrund von:

• 55,6%Unmöglichkeit, schnell Rechenressourcen hinzuzufügen10

• 16,7%Limitationen der Infrastruktur des Hosting-Anbieters3

• 33,3%Limitationen von Drittanbieter-APIs6

• 27,8%Verletzung der stateless Prinzipien Ihrer Anwendungen5

• 88,9%Suboptimale Programmierung eigener Dienste16

18 Benutzer haben abgestimmt. 6 Benutzer haben sich enthalten.

Quelle: habr.com