Im Sommer nehmen traditionell sowohl die Einkaufsaktivität als auch die Intensität der Veränderungen in der Infrastruktur von Webprojekten ab, erzählt uns Captain Obvious. Ganz einfach, weil auch IT-Spezialisten manchmal in den Urlaub fahren. Und auch CTO. Für diejenigen, die im Amt bleiben, ist es umso schwieriger, aber darum geht es jetzt nicht: Vielleicht ist der Sommer deshalb die beste Zeit, um langsam über das bestehende Reservierungssystem nachzudenken und einen Plan zu seiner Verbesserung auszuarbeiten. Und die Erfahrung von Yegor Andreev aus , worüber er auf der Konferenz sprach .
Beim Erstellen von Backup-Sites können mehrere Fallstricke auftreten. Und es ist absolut unmöglich, sich darin zu verfangen. Und was uns dabei, wie auch bei vielen anderen Dingen, ruiniert, ist Perfektionismus und... Faulheit. Wir versuchen, alles, alles, alles perfekt zu machen, aber wir müssen es nicht perfekt machen! Sie müssen nur bestimmte Dinge tun, aber machen Sie sie richtig und vervollständigen Sie sie, damit sie richtig funktionieren.
Failover ist keine lustige Sache; Dies ist eine Sache, die genau eines bewirken soll: Ausfallzeiten reduzieren, damit der Service, das Unternehmen, weniger Geld verliert. Und bei allen Reservierungsmethoden empfehle ich, im folgenden Kontext zu denken: Wo ist das Geld?
Erste Falle: Wenn wir große, zuverlässige Systeme bauen und auf Redundanz setzen, reduzieren wir die Zahl der Unfälle. Das ist ein schreckliches Missverständnis. Wenn wir Entlassungen vornehmen, erhöhen wir wahrscheinlich die Zahl der Unfälle. Und wenn wir alles richtig machen, werden wir gemeinsam Ausfallzeiten reduzieren. Es wird mehr Unfälle geben, aber sie werden zu geringeren Kosten passieren. Was ist eine Reservierung? - Dies ist eine Komplikation des Systems. Jede Komplikation ist schlecht: Wir haben mehr Zahnräder, mehr Gänge, kurz gesagt, mehr Elemente – und damit ein höheres Pannenrisiko. Und sie werden wirklich kaputt gehen. Und sie werden häufiger kaputt gehen. Ein einfaches Beispiel: Nehmen wir an, wir haben eine Website mit PHP und MySQL. Und es muss dringend reserviert werden.
Shtosh (c) Wir nehmen den zweiten Standort und bauen ein identisches System auf ... Die Komplexität wird doppelt so groß – wir haben zwei Einheiten. Wir führen auch eine bestimmte Logik für die Übertragung von Daten von einem Standort zu einem anderen ein – das heißt Datenreplikation, Kopieren statischer Daten usw. Daher ist die Replikationslogik normalerweise sehr komplex, und daher kann die Gesamtkomplexität des Systems nicht zwei-, sondern drei-, fünf- oder zehnmal größer sein.
Zweite Falle: Wenn wir wirklich große komplexe Systeme bauen, fantasieren wir darüber, was wir am Ende bekommen wollen. Voila: Wir wollen ein superzuverlässiges System bekommen, das ohne Ausfallzeiten funktioniert, in einer halben Sekunde (oder besser noch, sofort) umschaltet und wir beginnen, Träume wahr werden zu lassen. Doch auch hier gibt es eine Nuance: Je kürzer die gewünschte Schaltzeit, desto komplexer wird die Systemlogik. Je komplexer wir diese Logik gestalten müssen, desto häufiger wird das System zusammenbrechen. Und Sie können in eine sehr unangenehme Situation geraten: Wir versuchen mit aller Kraft, die Ausfallzeiten zu reduzieren, aber in Wirklichkeit machen wir alles komplizierter, und wenn etwas schief geht, werden die Ausfallzeiten am Ende länger. Hier ertappt man sich oft dabei, dass man denkt: Naja... lieber nicht reservieren. Es wäre besser, wenn es alleine und mit verständlichen Ausfallzeiten funktionieren würde.
Wie kann man dagegen ankämpfen? Wir müssen aufhören, uns selbst zu belügen, aufhören, uns selbst zu schmeicheln, dass wir jetzt hier ein Raumschiff bauen werden, aber wir müssen hinreichend verstehen, wie lange das Projekt dauern kann. Und für diese maximale Zeit werden wir entscheiden, welche Methoden wir tatsächlich nutzen, um die Zuverlässigkeit unseres Systems zu erhöhen.
Es ist Zeit für „Geschichten aus dem Leben“ natürlich.
Beispiel Nummer eins
Stellen Sie sich eine Visitenkarten-Website für das Rohrwalzwerk Nr. 1 in der Stadt N vor. Darauf steht in großen Buchstaben: ROHRWALZWERK Nr. 1. Direkt darunter steht der Slogan: „Unsere Pfeifen sind die rundsten Pfeifen in N.“ Und unten ist die Telefonnummer des CEO und sein Name. Wir verstehen, dass Sie eine Reservierung vornehmen müssen – das ist eine sehr wichtige Sache! Beginnen wir damit, herauszufinden, woraus es besteht. HTML-Statik - das sind ein paar Bilder, auf denen der General Manager tatsächlich mit seinem Partner am Tisch im Badehaus über einen nächsten Deal spricht. Wir fangen an, über Ausfallzeiten nachzudenken. Da fällt mir ein: Du musst fünf Minuten daliegen, nicht länger. Und dann stellt sich die Frage: Wie viele Verkäufe gab es auf unserer Website im Allgemeinen? Wie viel – wie viel? Was bedeutet „Null“? Und das bedeutet: Weil der General letztes Jahr alle vier Geschäfte am selben Tisch getätigt hat, mit denselben Leuten, mit denen er ins Badehaus geht und am Tisch sitzt. Und wir verstehen, dass nichts Schlimmes passieren wird, selbst wenn die Website einen Tag lang nicht verfügbar ist.
Basierend auf den einleitenden Informationen gibt es einen Tag, um diese Geschichte anzusprechen. Beginnen wir mit der Überlegung über ein Redundanzschema. Und wir wählen für dieses Beispiel das idealste Redundanzschema: Wir verwenden keine Redundanz. Das Ganze kann von jedem Admin in einer halben Stunde mit Rauchpausen aufgezogen werden. Webserver installieren, Dateien hinzufügen – fertig. Es wird klappen. Sie müssen nichts im Auge behalten, Sie müssen nichts besonders beachten. Das heißt, die Schlussfolgerung aus Beispiel Nummer eins liegt auf der Hand: Dienste, die nicht reserviert werden müssen, müssen auch nicht reserviert werden.
Beispiel Nummer zwei
Firmenblog: Dort schreiben speziell geschulte Leute Neuigkeiten, wir haben an der und der Ausstellung teilgenommen, aber wir haben ein anderes neues Produkt herausgebracht und so weiter. Nehmen wir an, das ist Standard-PHP mit WordPress, einer kleinen Datenbank und ein wenig Statik. Da fällt mir natürlich wieder ein, dass man sich auf keinen Fall hinlegen sollte – „nicht länger als fünf Minuten!“ Das ist alles. Aber denken wir weiter. Was macht dieser Blog? Die Leute kommen von Yandex, von Google, basierend auf einigen Suchanfragen, organisch dorthin. Großartig. Hat der Verkauf etwas damit zu tun? Epiphany: nicht wirklich. Der Werbeverkehr wird zur Hauptseite geleitet, die sich auf einem anderen Computer befindet. Beginnen wir mit der Überlegung über ein Buchungsschema. Das Gute ist, dass es in ein paar Stunden aufgezogen werden muss, und es wäre schön, sich darauf vorzubereiten. Es wäre sinnvoll, eine Maschine aus einem anderen Rechenzentrum zu nehmen, die Umgebung darauf zu übertragen, also einen Webserver, PHP, WordPress, MySQL, und sie dort zu belassen. In dem Moment, in dem wir verstehen, dass alles kaputt ist, müssen wir zwei Dinge tun: den MySQL-Dump 50 Meter weit ausrollen, er wird in einer Minute dorthin fliegen, und dort eine bestimmte Anzahl von Bildern aus dem Backup ausrollen. Auch das gibt es Gott weiß wie lange nicht mehr. Somit steigt das Ganze in einer halben Stunde. Keine Replikation, oder Gott vergib mir, automatisches Failover. Fazit: Was wir schnell aus einem Backup ausrollen können, muss nicht gesichert werden.
Beispiel Nummer drei, komplizierter
Online-Shop. PHP mit offenem Herzen ist etwas optimiert, MySQL mit einer soliden Basis. Ziemlich viel statische Aufladung (schließlich hat der Online-Shop wunderschöne HD-Bilder und all das Zeug), Redis für die Sitzung und Elasticsearch für die Suche. Wir fangen an, über Ausfallzeiten nachzudenken. Und hier ist es natürlich klar, dass ein Online-Shop nicht einen Tag lang schmerzlos herumliegen kann. Denn je länger es liegt, desto mehr Geld verlieren wir. Es lohnt sich, schneller zu werden. Wie viel? Ich denke, wenn wir uns eine Stunde hinlegen, wird niemand verrückt. Ja, wir werden etwas verlieren, aber wenn wir anfangen, hart zu arbeiten, wird es nur noch schlimmer. Wir definieren ein Schema der zulässigen Ausfallzeiten pro Stunde.
Wie kann das alles reserviert werden? Ein Auto braucht man auf jeden Fall: Eine Stunde Zeit ist ziemlich wenig. Mysql: Hier brauchen wir bereits Replikation, Live-Replikation, denn in einer Stunde werden höchstwahrscheinlich nicht 100 GB zum Dump hinzugefügt. Statik, Bilder: Auch hier kann es sein, dass in einer Stunde keine Zeit mehr ist, 500 GB hinzuzufügen. Daher ist es besser, die Bilder gleich zu kopieren. Redis: Hier wird es interessant. In Redis werden Sitzungen gespeichert – wir können sie nicht einfach wegnehmen und vergraben. Denn das wird nicht sehr gut sein: Alle Benutzer werden abgemeldet, ihre Körbe werden geleert und so weiter. Die Leute werden gezwungen sein, ihren Benutzernamen und ihr Passwort erneut einzugeben, und viele Leute brechen möglicherweise ab und schließen den Kauf nicht ab. Auch hier werden die Conversions sinken. Andererseits ist Redis direkt auf dem neuesten Stand, wobei die zuletzt angemeldeten Benutzer wahrscheinlich auch nicht benötigt werden. Und ein guter Kompromiss besteht darin, Redis zu nehmen und es aus einem Backup von gestern oder, wenn Sie das stündlich machen, von vor einer Stunde wiederherzustellen. Glücklicherweise erfordert die Wiederherstellung aus einem Backup das Kopieren einer Datei. Und die interessanteste Geschichte ist Elasticsearch. Wer hat sich jemals für die MySQL-Replikation entschieden? Wer hat sich jemals für die Elasticsearch-Replikation entschieden? Und bei wem funktionierte es danach normal? Was ich meine ist, dass wir eine bestimmte Entität in unserem System sehen. Es scheint nützlich zu sein – aber es ist komplex.
Komplex in dem Sinne, dass unsere Ingenieurskollegen keine Erfahrung damit haben. Oder es gibt ein negatives Erlebnis. Oder wir verstehen, dass dies noch eine ziemlich neue Technologie mit Nuancen oder Rohheit ist. Wir denken ... Verdammt, Elastic ist auch gesund, es dauert auch lange, es aus einem Backup wiederherzustellen, was soll ich tun? Wir verstehen, dass in unserem Fall elastisch für die Suche verwendet wird. Wie verkauft unser Online-Shop? Wir gehen zu Vermarktern und fragen, woher die Leute kommen. Sie antworten: „90 % von Yandex Market kommen direkt auf die Produktkarte.“ Und entweder kaufen sie es oder nicht. Daher benötigen 10 % der Nutzer eine Suche. Und die Aufrechterhaltung einer elastischen Replikation, insbesondere zwischen verschiedenen Rechenzentren in verschiedenen Zonen, weist wirklich viele Nuancen auf. Welcher Ausgang? Wir nehmen Elastic von einer reservierten Site und machen nichts damit. Wenn sich der Fall in die Länge zieht, werden wir ihn vielleicht eines Tages zur Sprache bringen, aber das ist nicht sicher. Eigentlich ist die Schlussfolgerung dieselbe, mit Plus oder Minus: Auch hier reservieren wir keine Dienstleistungen, die sich nicht auf das Geld auswirken. Um das Diagramm einfacher zu halten.
Beispiel Nummer vier, noch schwieriger
Integrator: Blumen verkaufen, ein Taxi rufen, Waren verkaufen, im Allgemeinen alles. Eine ernste Sache, die für eine große Anzahl von Benutzern rund um die Uhr funktioniert. Mit einem vollwertigen interessanten Stapel, in dem es interessante Grundlagen, Lösungen, hohe Belastung und vor allem Schmerzen gibt, wenn man sich länger als 24 Minuten hinlegt. Nicht nur und nicht so sehr, weil die Leute nicht kaufen, sondern weil die Leute sehen, dass das Ding nicht funktioniert, sie sich aufregen und vielleicht gar nicht mehr zurückkommen.
OK. Fünf Minuten. Was werden wir dagegen tun? In diesem Fall verwenden wir wie Erwachsene das gesamte Geld, um eine echte Backup-Site mit Replikation aller Dinge zu erstellen und vielleicht sogar den Wechsel zu dieser Site so weit wie möglich zu automatisieren. Und darüber hinaus müssen Sie noch eine wichtige Sache bedenken: die Schaltordnung tatsächlich verfassen. Die Vorschriften können sehr einfach sein, auch wenn alles automatisiert ist. Aus der Reihe „Führen Sie das und das Ansible-Skript aus“, „Klicken Sie auf das und das Kontrollkästchen in Route 53“ und so weiter – aber dies muss eine Art genaue Liste von Aktionen sein.
Und alles scheint klar. Das Wechseln der Replikation ist eine triviale Aufgabe, sonst wechselt es von selbst. Das Umschreiben eines Domänennamens in DNS stammt aus derselben Serie. Das Problem ist, dass beim Scheitern eines solchen Projekts Panik ausbricht und selbst die stärksten, bärtigen Administratoren dafür anfällig sein können. Ohne klare Anweisungen „Öffne das Terminal, komm her, die Adresse unseres Servers ist immer noch so“ ist es schwierig, die für die Wiederbelebung vorgesehene Frist von 5 Minuten einzuhalten. Wenn wir diese Vorschriften nutzen, ist es außerdem einfach, einige Änderungen beispielsweise in der Infrastruktur zu erfassen und die Vorschriften entsprechend zu ändern.
Nun, wenn das Reservierungssystem sehr komplex ist und wir irgendwann einen Fehler gemacht haben, können wir unsere Backup-Site zerstören und zusätzlich die Daten auf beiden Sites in einen Kürbis verwandeln – das wäre völlig traurig.
Beispiel Nummer fünf, kompletter Hardcore
Ein internationaler Dienst mit Hunderten Millionen Nutzern auf der ganzen Welt. Alle Zeitzonen, die es gibt, hohe Belastung bei maximaler Geschwindigkeit, man kann sich überhaupt nicht hinlegen. Eine Minute – und es wird traurig sein. Was zu tun ist? Reservieren Sie erneut gemäß dem vollständigen Programm. Wir haben alles getan, worüber ich im vorherigen Beispiel gesprochen habe, und noch ein bisschen mehr. Eine ideale Welt und unsere Infrastruktur entspricht allen Konzepten von IaaC-Entwicklern. Das heißt, alles ist in Git und Sie drücken einfach den Knopf.
Was fehlt? Eins – Übungen. Ohne sie geht es nicht. Es scheint, dass bei uns alles perfekt ist, wir haben im Allgemeinen alles unter Kontrolle. Wir drücken den Knopf, alles passiert. Auch wenn dies der Fall ist – und wir verstehen, dass dies nicht der Fall ist – interagiert unser System mit einigen anderen Systemen. Dies ist beispielsweise DNS von Route 53, S3-Speicher, Integration mit einigen APIs. Wir werden in diesem spekulativen Experiment nicht alles vorhersehen können. Und bis wir tatsächlich den Schalter betätigen, werden wir nicht wissen, ob es funktionieren wird oder nicht.
Das ist wahrscheinlich alles. Seien Sie nicht faul und übertreiben Sie es nicht. Und möge Uptime mit Ihnen sein!
Source: habr.com