Artem Denisov ( , )
Badoo ist die weltweit größte Dating-Site. Derzeit haben wir weltweit rund 330 Millionen registrierte Nutzer. Aber was im Kontext unseres heutigen Gesprächs viel wichtiger ist, ist, dass wir etwa 3 Petabyte an Benutzerfotos speichern. Jeden Tag laden unsere Nutzer etwa 3,5 Millionen neue Fotos hoch, und die Leselast beträgt ca 80 Anfragen pro Sekunde. Das ist ziemlich viel für unser Backend und manchmal gibt es dabei Schwierigkeiten.
Ich werde über das Design dieses Systems sprechen, das Fotos im Allgemeinen speichert und versendet, und ich werde es aus der Sicht eines Entwicklers betrachten. Es wird einen kurzen Rückblick auf die Entwicklung geben, in dem ich die wichtigsten Meilensteine skizziere, aber nur detaillierter auf die Lösungen eingehen werde, die wir derzeit verwenden.
Jetzt fangen wir an.
Wie gesagt, dies wird eine Retrospektive sein, und um irgendwo damit anzufangen, nehmen wir das gängigste Beispiel.
Wir haben eine gemeinsame Aufgabe: Wir müssen Benutzerfotos annehmen, speichern und senden. In dieser Form ist die Aufgabe allgemein, wir können alles verwenden:
- moderner Cloud-Speicher,
- eine Box-Lösung, von der es inzwischen auch viele gibt;
- Wir können in unserem Rechenzentrum mehrere Maschinen aufstellen und darauf große Festplatten unterbringen und dort Fotos speichern.
Historisch gesehen lebt Badoo – ab und zu (damals, als es noch in den Kinderschuhen steckte) – auf seinen eigenen Servern in unseren eigenen DCs. Daher war diese Option für uns optimal.
Wir haben einfach mehrere Maschinen genommen, sie „Fotos“ genannt und einen Cluster erhalten, der Fotos speichert. Aber es scheint, als würde etwas fehlen. Damit das alles funktioniert, müssen wir irgendwie bestimmen, auf welchem Rechner wir welche Fotos speichern. Und auch hier besteht keine Notwendigkeit, Amerika zu öffnen.
Wir fügen unserem Speicher ein Feld mit Informationen über Benutzer hinzu. Dies wird der Sharding-Schlüssel sein. In unserem Fall haben wir es place_id genannt, und diese Orts-ID verweist auf den Ort, an dem Benutzerfotos gespeichert sind. Wir erstellen Karten.
Im ersten Schritt kann dies sogar manuell erfolgen – wir sagen, dass ein Foto dieses Benutzers mit einem solchen Ort auf einem solchen Server landet. Dank dieser Karte wissen wir immer, wann ein Benutzer ein Foto hochlädt, wo wir es speichern und woher wir es weitergeben müssen.
Dies ist ein absolut triviales Schema, das jedoch erhebliche Vorteile bietet. Das erste ist, wie gesagt, einfach, und das zweite ist, dass wir mit diesem Ansatz problemlos horizontal skalieren können, indem wir einfach neue Autos liefern und sie der Karte hinzufügen. Sie müssen nichts weiter tun.
So ging es uns eine Zeit lang.
Das war etwa 2009. Sie lieferten Autos, lieferten...
Und irgendwann bemerkten wir, dass dieses Schema gewisse Nachteile hat. Was sind die Nachteile?
Erstens ist die Kapazität begrenzt. Wir können nicht so viele Festplatten auf einen physischen Server packen, wie wir möchten. Und das ist im Laufe der Zeit und mit dem Wachstum des Datensatzes zu einem gewissen Problem geworden.
Und zweitens. Dies ist eine untypische Konfiguration von Maschinen, da solche Maschinen in einigen anderen Clustern nur schwer wiederzuverwenden sind; sie sind ziemlich spezifisch, d. h. Sie sollten leistungsschwach, aber gleichzeitig mit einer großen Festplatte ausgestattet sein.
Das war alles für 2009, aber im Prinzip sind diese Anforderungen auch heute noch relevant. Wir haben eine Retrospektive, also 2009 war damit alles völlig schlecht.
Und der letzte Punkt ist der Preis.
Der Preis war damals sehr hoch und wir mussten uns nach Alternativen umsehen. Diese. Wir mussten sowohl den Platz in den Rechenzentren als auch die physischen Server, auf denen sich all dies befindet, irgendwie besser nutzen. Und unsere Systemingenieure begannen eine große Studie, in der sie eine Reihe verschiedener Optionen prüften. Sie untersuchten auch Cluster-Dateisysteme wie PolyCeph und Lustre. Es gab Leistungsprobleme und eine recht schwierige Bedienung. Sie weigerten sich. Wir haben versucht, den gesamten Datensatz über NFS auf jedem Auto zu mounten, um ihn irgendwie zu skalieren. Auch das Lesen verlief schlecht, wir haben verschiedene Lösungen von verschiedenen Anbietern ausprobiert.
Und am Ende haben wir uns für die Nutzung des sogenannten Storage Area Network entschieden.
Dabei handelt es sich um große SHDs, die speziell für die Speicherung großer Datenmengen konzipiert sind. Dabei handelt es sich um Regale mit Datenträgern, die auf den endgültigen optischen Ausgabegeräten montiert werden. Das. Wir haben eine Art Maschinenpool, ziemlich klein, und diese SHDs, die für unsere Sendelogik transparent sind, d. h. damit unser Nginx oder jemand anderes Anfragen für diese Fotos bearbeiten kann.
Diese Entscheidung hatte offensichtliche Vorteile. Das ist SHD. Es dient der Speicherung von Fotos. Das ist günstiger, als Maschinen einfach mit Festplatten auszustatten.
Zweites Plus.
Das liegt daran, dass die Kapazität deutlich größer geworden ist, d.h. Wir können viel mehr Speicherplatz in einem viel kleineren Volumen unterbringen.
Es gab aber auch Nachteile, die sich recht schnell zeigten. Als die Anzahl der Benutzer und die Auslastung dieses Systems zunahmen, traten Leistungsprobleme auf. Und das Problem liegt hier auf der Hand: Jede SHD, die viele Fotos auf kleinem Raum speichern soll, leidet in der Regel unter intensivem Lesen. Das gilt eigentlich für jeden Cloud-Speicher oder alles andere. Jetzt haben wir keinen idealen Speicher, der unendlich skalierbar wäre, man könnte alles hineinstopfen und er würde die Messwerte sehr gut vertragen. Vor allem Gelegenheitslektüren.
Dies ist auch bei unseren Fotos der Fall, da Fotos inkonsistent angefordert werden und dies ihre Leistung stark beeinträchtigt.
Selbst nach den heutigen Zahlen beginnen bereits Probleme, wenn wir auf einem Computer, an den ein Speicher angeschlossen ist, mehr als 500 RPS für Fotos erreichen. Und für uns war es schon schlimm genug, denn die Zahl der Nutzer wächst, es wird nur noch schlimmer. Das muss irgendwie optimiert werden.
Um zu optimieren, haben wir uns damals natürlich entschieden, uns das Lastprofil anzuschauen – was im Allgemeinen passiert, was optimiert werden muss.
Und hier spielt uns alles in die Hände.
Ich habe bereits in der ersten Folie gesagt: Wir haben 80 Leseanfragen pro Sekunde bei nur 3,5 Millionen Uploads pro Tag. Das heißt, es handelt sich um einen Unterschied von drei Größenordnungen. Es liegt auf der Hand, dass das Lesen optimiert werden muss, und es ist praktisch klar, wie.
Es gibt noch einen kleinen Punkt. Die Besonderheiten des Dienstes bestehen darin, dass sich eine Person registriert, ein Foto hochlädt, dann beginnt, andere Personen aktiv anzuschauen, sie zu liken und anderen Personen aktiv angezeigt zu werden. Dann findet er einen Partner oder findet keinen Partner, je nachdem, wie es ausgeht, und nutzt den Dienst für eine Weile nicht mehr. In diesem Moment, in dem er es nutzt, sind seine Fotos sehr heiß – sie sind gefragt, viele Leute sehen sie sich an. Sobald er damit aufhört, verliert er ziemlich schnell den Kontakt zu anderen Menschen wie zuvor und seine Fotos werden fast nie mehr nachgefragt.
Diese. Wir haben einen sehr kleinen Hot-Datensatz. Aber gleichzeitig gibt es viele Anfragen für ihn. Und eine völlig naheliegende Lösung ist hier das Hinzufügen eines Caches.
Ein Cache mit LRU wird alle unsere Probleme lösen. Was machen wir?
Wir fügen vor unserem großen Cluster mit Speicher einen weiteren relativ kleinen hinzu, der Fotocaches genannt wird. Dies ist im Wesentlichen nur ein Caching-Proxy.
Wie funktioniert es von innen? Hier ist unser Benutzer, hier ist Speicher. Alles ist wie vorher. Was fügen wir dazwischen hinzu?
Es handelt sich lediglich um eine Maschine mit einer physischen lokalen Festplatte, die schnell ist. Das geht zum Beispiel mit einer SSD. Und auf dieser Festplatte ist eine Art lokaler Cache gespeichert.
Wie sieht es aus? Der Benutzer sendet eine Anfrage für ein Foto. NGINX sucht zunächst im lokalen Cache danach. Wenn nicht, dann einfach Proxy_Pass auf unseren Speicher übertragen, das Foto von dort herunterladen und es dem Benutzer geben.
Aber das ist sehr banal und es ist unklar, was im Inneren passiert. Es funktioniert ungefähr so.
Der Cache ist logisch in drei Schichten unterteilt. Wenn ich „drei Schichten“ sage, bedeutet das nicht, dass es sich um ein komplexes System handelt. Nein, das sind bedingt nur drei Verzeichnisse im Dateisystem:
- Dies ist ein Puffer, in dem Fotos abgelegt werden, die gerade von einem Proxy heruntergeladen wurden.
- Dabei handelt es sich um einen Hot-Cache, der aktuell aktiv angeforderte Fotos speichert.
- Und ein Cold-Cache, bei dem Fotos nach und nach aus dem Hot-Cache verschoben werden, wenn weniger Anfragen eingehen.
Damit dies funktioniert, müssen wir diesen Cache irgendwie verwalten, die darin enthaltenen Fotos neu anordnen usw. Auch das ist ein sehr primitiver Prozess.
Nginx schreibt einfach für jede Anfrage in das RAMDisk-Access.log, in dem es den Pfad zu dem Foto angibt, das es aktuell bereitgestellt hat (natürlich relativer Pfad), und welche Partition es bereitgestellt hat. Diese. Es kann „Foto 1“ heißen und dann entweder ein Puffer, ein Hot-Cache, ein Cold-Cache oder ein Proxy.
Abhängig davon müssen wir irgendwie entscheiden, was wir mit dem Foto machen.
Auf jedem Computer läuft ein kleiner Daemon, der dieses Protokoll ständig liest und Statistiken über die Verwendung bestimmter Fotos in seinem Speicher speichert.
Er sammelt dort einfach, behält die Zähler und macht regelmäßig Folgendes. Er verschiebt aktiv angeforderte Fotos, für die es viele Anfragen gibt, in den Hot Cache, wo immer sie sich befinden.
Selten angeforderte und seltener angeforderte Fotos werden nach und nach aus dem heißen Cache in den kalten verschoben.
Und wenn uns der Platz im Cache ausgeht, beginnen wir einfach wahllos damit, alles aus dem kalten Cache zu löschen. Und das funktioniert übrigens auch gut.
Damit das Foto beim Proxy in den Puffer sofort gespeichert wird, verwenden wir die Proxy_store-Direktive und der Puffer ist auch eine RAMDisk, d.h. Für den Benutzer funktioniert es sehr schnell. Dies betrifft die Interna des Caching-Servers selbst.
Die verbleibende Frage ist, wie Anfragen auf diese Server verteilt werden.
Nehmen wir an, es gibt einen Cluster aus zwanzig Speichermaschinen und drei Caching-Servern (so ist es passiert).
Wir müssen irgendwie herausfinden, welche Anfragen für welche Fotos gelten und wo sie landen sollen.
Die gebräuchlichste Option ist Round Robin. Oder aus Versehen?
Dies hat natürlich eine Reihe von Nachteilen, da wir in einer solchen Situation den Cache sehr ineffizient nutzen würden. Anfragen landen auf einigen zufälligen Rechnern: Hier wurde es zwischengespeichert, aber auf dem nächsten ist es nicht mehr da. Und wenn das alles funktioniert, wird es sehr schlimm sein. Auch bei einer kleinen Anzahl von Maschinen im Cluster.
Wir müssen irgendwie eindeutig bestimmen, welcher Server welche Anfrage bearbeiten soll.
Es gibt einen banalen Weg. Wir nehmen den Hash von der URL oder den Hash von unserem Sharding-Schlüssel, der in der URL enthalten ist, und dividieren ihn durch die Anzahl der Server. Wird funktionieren? Wille.
Diese. Wir haben zum Beispiel eine 2%-Anfrage, bei einer „example_url“ landet diese immer auf dem Server mit dem Index „XNUMX“ und der Cache wird ständig bestmöglich entsorgt.
Bei einem solchen Schema gibt es jedoch ein Problem mit dem Resharding. Resharding – ich meine die Änderung der Anzahl der Server.
Nehmen wir an, dass unser Caching-Cluster nicht mehr zurechtkommt und wir beschließen, eine weitere Maschine hinzuzufügen.
Fügen wir hinzu.
Jetzt ist alles nicht durch drei, sondern durch vier teilbar. Daher leben fast alle Schlüssel, die wir früher hatten, und fast alle URLs jetzt auf anderen Servern. Der gesamte Cache wurde kurzzeitig ungültig gemacht. Alle Anfragen fielen auf unseren Speichercluster, es kam zu Unwohlsein, Dienstausfällen und unzufriedenen Benutzern. Das möchte ich nicht tun.
Diese Option passt auch nicht zu uns.
Das. Was sollen wir machen? Wir müssen den Cache irgendwie effizient nutzen, dieselbe Anfrage immer wieder auf demselben Server landen lassen, aber resistent gegen Resharding sein. Und es gibt eine solche Lösung, die ist gar nicht so kompliziert. Man nennt es konsistentes Hashing.
Wie sieht es aus?
Wir übernehmen eine Funktion des Sharding-Schlüssels und verteilen alle seine Werte auf dem Kreis. Diese. am Punkt 0 konvergieren seine Minimal- und Maximalwerte. Als nächstes platzieren wir alle unsere Server ungefähr so auf demselben Kreis:
Jeder Server wird durch einen Punkt definiert, und der Sektor, der im Uhrzeigersinn zu ihm führt, wird dementsprechend von diesem Host bedient. Wenn Anfragen bei uns eingehen, sehen wir sofort, dass zum Beispiel Anfrage A – sie hat dort einen Hash – und von Server 2 bedient wird. Anfrage B – von Server 3. Und so weiter.
Was passiert in dieser Situation beim Resharding?
Wir machen nicht wie zuvor den gesamten Cache ungültig und verschieben nicht alle Schlüssel, sondern wir verschieben jeden Sektor um eine kurze Strecke, sodass relativ gesehen unser sechster Server, den wir hinzufügen möchten, in den freien Speicherplatz passt, und wir fügen es dort hinzu.
Selbstverständlich fahren in einer solchen Situation auch die Tasten heraus. Aber sie ziehen deutlich schwächer aus als zuvor. Und wir sehen, dass unsere ersten beiden Schlüssel auf ihren Servern verblieben sind und sich der Caching-Server nur für den letzten Schlüssel geändert hat. Das funktioniert recht effizient, und wenn Sie neue Hosts schrittweise hinzufügen, gibt es hier kein großes Problem. Man fügt nach und nach etwas hinzu, wartet, bis der Cache wieder voll ist, und alles funktioniert gut.
Bleibt nur noch die Frage bei Absagen. Nehmen wir an, dass irgendein Auto außer Betrieb ist.
Und wir möchten diese Karte in diesem Moment nicht wirklich neu generieren, einen Teil des Caches ungültig machen usw., wenn beispielsweise die Maschine neu gestartet wurde und wir Anfragen irgendwie bedienen müssen. Wir behalten einfach an jedem Standort einen Backup-Fotocache vor, der als Ersatz für jeden Computer dient, der derzeit ausgefallen ist. Und wenn einer unserer Server plötzlich nicht mehr verfügbar ist, wird der Datenverkehr dorthin weitergeleitet. Natürlich haben wir dort keinen Cache, d.h. Es ist kalt, aber zumindest Benutzeranfragen werden bearbeitet. Handelt es sich hierbei um eine kurze Zeitspanne, dann erleben wir sie völlig gelassen. Der Speicher wird einfach stärker belastet. Wenn dieses Intervall lang ist, können wir bereits eine Entscheidung treffen – diesen Server von der Karte entfernen oder nicht oder ihn möglicherweise durch einen anderen ersetzen.
Hier geht es um das Caching-System. Schauen wir uns die Ergebnisse an.
Es scheint, dass es hier nichts Kompliziertes gibt. Aber diese Methode der Cache-Verwaltung ergab eine Trickrate von etwa 98 %. Diese. Von diesen 80 Anfragen pro Sekunde erreichen nur 1600 den Speicher, und das ist eine völlig normale Belastung, sie ertragen sie ruhig, wir haben immer eine Reserve.
Wir haben diese Server in drei unserer DCs platziert und drei Präsenzpunkte erhalten – Prag, Miami und Hongkong.
Das. Sie sind mehr oder weniger lokal in jedem unserer Zielmärkte ansässig.
Und als netten Bonus haben wir diesen Caching-Proxy bekommen, auf dem die CPU tatsächlich im Leerlauf ist, weil sie nicht so sehr für die Bereitstellung von Inhalten benötigt wird. Und dort haben wir mit NGINX+ Lua eine Menge nützlicher Logik implementiert.
Wir können zum Beispiel mit WebP oder Progressive JPEG (dies sind effektive moderne Formate) experimentieren, sehen, wie es sich auf den Datenverkehr auswirkt, einige Entscheidungen treffen, es für bestimmte Länder aktivieren usw.; Nehmen Sie dynamische Größenänderungen vor oder beschneiden Sie Fotos im Handumdrehen.
Dies ist ein guter Anwendungsfall, wenn Sie beispielsweise über eine mobile Anwendung verfügen, die Fotos anzeigt, und die mobile Anwendung die CPU des Clients nicht damit verschwenden möchte, ein großes Foto anzufordern und es dann auf eine bestimmte Größe zu ändern, um es hineinzuschieben die Aussicht. Wir können einfach einige Parameter dynamisch in der bedingten UPort-URL angeben, und der Foto-Cache ändert die Größe des Fotos selbst. In der Regel wird die Größe ausgewählt, die wir physisch auf der Festplatte haben, so nah wie möglich an der angeforderten Größe, und sie in bestimmten Koordinaten weiterverkauft.
Übrigens haben wir Videoaufzeichnungen der letzten fünf Jahre der Konferenz der Entwickler von Hochlastsystemen öffentlich zugänglich gemacht . Anschauen, lernen, teilen und abonnieren .
Wir können dort auch viel Produktlogik hinzufügen. Zum Beispiel können wir mithilfe von URL-Parametern verschiedene Wasserzeichen hinzufügen, wir können Fotos verwischen, verwischen oder verpixeln. Dies ist der Fall, wenn wir ein Foto einer Person zeigen möchten, aber nicht ihr Gesicht. Das funktioniert gut, hier ist alles umgesetzt.
Was haben wir bekommen? Wir haben drei Präsenzpunkte, eine gute Trickrate und gleichzeitig haben wir auf diesen Maschinen keine ungenutzte CPU. Er ist jetzt natürlich wichtiger geworden als zuvor. Wir müssen uns stärkere Autos besorgen, aber es lohnt sich.
Dies betrifft die Rückgabe von Fotos. Hier ist alles ganz klar und offensichtlich. Ich glaube, ich habe Amerika nicht entdeckt, fast jedes CDN funktioniert so.
Und höchstwahrscheinlich könnte ein erfahrener Zuhörer eine Frage haben: Warum nicht einfach alles auf CDN umstellen? Es wäre ungefähr das Gleiche; alle modernen CDNs können dies. Und es gibt eine Reihe von Gründen.
Das erste sind Fotos.
Dies ist einer der Schlüsselpunkte unserer Infrastruktur, und wir müssen so viel Kontrolle wie möglich darüber haben. Wenn es sich um eine Lösung eines Drittanbieters handelt und Sie keine Kontrolle darüber haben, wird es für Sie ziemlich schwierig sein, damit zu leben, wenn Sie über einen großen Datensatz und einen sehr großen Datenfluss verfügen der Benutzeranfragen.
Lassen Sie mich Ihnen ein Beispiel geben. Jetzt können wir mit unserer Infrastruktur zum Beispiel bei Problemen oder Stößen im Untergrund zur Maschine gehen und dort relativ gesehen herumalbern. Wir können die Sammlung einiger Metriken hinzufügen, die wir nur benötigen, wir können irgendwie experimentieren, sehen, wie sich dies auf die Diagramme auswirkt und so weiter. Jetzt werden viele Statistiken zu diesem Caching-Cluster gesammelt. Und wir schauen uns das regelmäßig an und verbringen viel Zeit damit, einige Anomalien zu untersuchen. Wenn es auf der CDN-Seite wäre, wäre es viel schwieriger zu kontrollieren. Oder wenn zum Beispiel ein Unfall passiert, wissen wir, was passiert ist, wir wissen, wie wir damit leben und wie wir ihn überwinden können. Dies ist die erste Schlussfolgerung.
Auch die zweite Schlussfolgerung ist eher historisch, da sich das System über einen langen Zeitraum entwickelt hat und es in verschiedenen Phasen viele verschiedene Geschäftsanforderungen gab, die nicht immer in das CDN-Konzept passen.
Und der Punkt, der sich aus dem vorherigen ergibt, ist
Das liegt daran, dass wir bei Foto-Caches über eine Menge spezifischer Logik verfügen, die nicht immer auf Anfrage hinzugefügt werden kann. Es ist unwahrscheinlich, dass ein CDN Ihnen auf Ihren Wunsch hin einige benutzerdefinierte Dinge hinzufügt. Verschlüsseln Sie beispielsweise URLs, wenn Sie nicht möchten, dass der Client etwas ändern kann. Möchten Sie die URL auf dem Server ändern und verschlüsseln und dann einige dynamische Parameter hierher senden?
Welche Schlussfolgerung lässt sich daraus ziehen? In unserem Fall ist CDN keine sehr gute Alternative.
Und wenn Sie in Ihrem Fall spezielle Geschäftsanforderungen haben, können Sie das, was ich Ihnen gezeigt habe, ganz einfach selbst umsetzen. Und das funktioniert bei einem ähnlichen Lastprofil einwandfrei.
Wenn Sie jedoch eine allgemeine Lösung haben und die Aufgabe nicht sehr spezifisch ist, können Sie absolut sicher ein CDN verwenden. Oder wenn Ihnen Zeit und Ressourcen wichtiger sind als Kontrolle.
Und moderne CDNs haben fast alles, worüber ich Ihnen jetzt erzählt habe. Mit Ausnahme einiger Plus- oder Minusfunktionen.
Hier geht es um das Verschenken von Fotos.
Lassen Sie uns in unserem Rückblick nun ein wenig vorwärts gehen und über die Lagerung sprechen.
Das Jahr 2013 verging.
Caching-Server wurden hinzugefügt, Leistungsprobleme verschwanden. Alles ist gut. Der Datensatz wächst. Im Jahr 2013 hatten wir etwa 80 Server, die mit dem Speicher verbunden waren, und etwa 40 Caching-Server in jedem DC. Das sind 560 Terabyte Daten auf jedem DC, d.h. insgesamt etwa ein Petabyte.
Und mit dem Wachstum des Datensatzes begannen die Betriebskosten deutlich zu steigen. Was bedeutete das?
In diesem Diagramm, das gezeichnet wird – mit einem SAN, mit daran angeschlossenen Maschinen und Caches – gibt es viele Fehlerquellen. Hatten wir uns bereits zuvor mit dem Ausfall von Caching-Servern befasst, war alles mehr oder weniger vorhersehbar und verständlich, aber auf der Speicherseite war alles noch viel schlimmer.
Erstens das Storage Area Network (SAN) selbst, das ausfallen kann.
Zweitens ist es über eine Optik mit den Endmaschinen verbunden. Möglicherweise liegen Probleme mit optischen Karten und Zündkerzen vor.
Natürlich gibt es davon nicht so viele wie beim SAN selbst, aber dennoch sind dies auch Fehlerquellen.
Als nächstes kommt die Maschine selbst, die mit dem Speicher verbunden ist. Es kann auch scheitern.
Insgesamt haben wir drei Fehlerquellen.
Zusätzlich zu den Fehlerquellen gibt es außerdem einen hohen Wartungsaufwand für den Speicher selbst.
Dabei handelt es sich um ein komplexes Mehrkomponentensystem, und Systemingenieure können Schwierigkeiten damit haben, damit zu arbeiten.
Und der letzte, wichtigste Punkt. Wenn an einem dieser drei Punkte ein Fehler auftritt, besteht eine Wahrscheinlichkeit ungleich Null, dass Benutzerdaten verloren gehen, da das Dateisystem abstürzen könnte.
Nehmen wir an, unser Dateisystem ist kaputt. Erstens dauert die Wiederherstellung lange – bei einer großen Datenmenge kann es eine Woche dauern. Und zweitens werden wir am Ende höchstwahrscheinlich einen Haufen unverständlicher Dateien haben, die irgendwie zu Benutzerfotos zusammengefasst werden müssen. Und wir riskieren, Daten zu verlieren. Das Risiko ist recht hoch. Und je häufiger solche Situationen auftreten und je mehr Probleme in der gesamten Kette auftreten, desto höher ist dieses Risiko.
Dagegen musste etwas getan werden. Und wir haben beschlossen, dass wir nur die Daten sichern müssen. Das ist eigentlich eine naheliegende und gute Lösung. Was haben wir getan?
So sah unser Server aus, als er zuvor mit dem Speicher verbunden war. Dies ist ein Hauptabschnitt, es handelt sich lediglich um ein Blockgerät, das eigentlich eine Halterung für die Fernspeicherung über Optiken darstellt.
Wir haben gerade einen zweiten Abschnitt hinzugefügt.
Wir haben einen zweiten Speicher daneben platziert (zum Glück ist er finanziell nicht so teuer) und ihn als Backup-Partition bezeichnet. Es ist ebenfalls über eine Optik angeschlossen und befindet sich auf derselben Maschine. Aber wir müssen die Daten zwischen ihnen irgendwie synchronisieren.
Hier erstellen wir einfach eine asynchrone Warteschlange in der Nähe.
Sie ist nicht sehr beschäftigt. Wir wissen, dass wir nicht genügend Aufzeichnungen haben. Eine Warteschlange ist einfach eine Tabelle in MySQL, in die Zeilen wie „Sie müssen dieses Foto sichern“ geschrieben werden. Bei jeder Änderung oder jedem Upload kopieren wir mit einem asynchronen oder einfach einem Hintergrund-Worker von der Hauptpartition zur Sicherung.
Und so haben wir immer zwei konsistente Abschnitte. Selbst wenn ein Teil dieses Systems ausfällt, können wir die Hauptpartition jederzeit mit einem Backup ändern und alles wird weiterhin funktionieren.
Aber dadurch erhöht sich die Lesebelastung enorm, denn... zusätzlich zu Kunden, die aus dem Hauptteil lesen, weil sie sich dort zuerst das Foto ansehen (es ist dort aktueller) und dann im Backup danach suchen, wenn sie es nicht gefunden haben (aber NGINX macht das einfach), Unser System ist auch ein Plus-Backup, das jetzt von der Hauptpartition liest. Es ist nicht so, dass dies ein Engpass war, aber ich wollte die Last im Grunde nicht einfach so erhöhen.
Und wir haben eine dritte Festplatte hinzugefügt, eine kleine SSD, und sie Puffer genannt.
Wie es jetzt funktioniert.
Der Benutzer lädt ein Foto in den Puffer hoch, dann wird ein Ereignis in die Warteschlange geworfen, das angibt, dass es in zwei Abschnitte kopiert werden muss. Es wird kopiert und das Foto verbleibt einige Zeit (z. B. einen Tag) im Puffer und wird erst dann von dort gelöscht. Dies verbessert das Benutzererlebnis erheblich, da der Benutzer in der Regel ein Foto hochlädt, Anfragen sofort folgen oder er selbst die Seite aktualisiert und aktualisiert hat. Aber es hängt alles von der Anwendung ab, die den Upload durchführt.
Oder zum Beispiel senden andere Personen, denen er sich zu zeigen begann, sofort nach diesem Foto Anfragen. Es ist noch nicht im Cache, die erste Anfrage erfolgt sehr schnell. Im Wesentlichen dasselbe wie aus einem Foto-Cache. Die langsame Speicherung spielt hier überhaupt keine Rolle. Und wenn es einen Tag später gelöscht wird, ist es entweder bereits auf unserer Caching-Ebene zwischengespeichert oder höchstwahrscheinlich wird es von niemandem mehr benötigt. Diese. Das Benutzererlebnis ist hier aufgrund solch einfacher Manipulationen sehr gut gewachsen.
Nun, und das Wichtigste: Wir haben aufgehört, Daten zu verlieren.
Sagen wir einfach, wir haben aufgehört möglicherweise Daten verlieren, weil wir sie nicht wirklich verloren haben. Aber es bestand Gefahr. Wir sehen, dass diese Lösung natürlich gut ist, aber es ist ein bisschen so, als würde man die Symptome des Problems glätten, anstatt es vollständig zu lösen. Und hier bleiben einige Probleme bestehen.
Erstens handelt es sich hierbei um einen Fehlerpunkt in Form des physischen Hosts selbst, auf dem all diese Maschinerie läuft; er ist nicht verschwunden.
Zweitens gibt es immer noch Probleme mit SANs, deren hoher Wartungsaufwand usw. bleibt bestehen. Es war kein entscheidender Faktor, aber ich wollte versuchen, irgendwie ohne ihn zu leben.
Und wir haben die dritte Version gemacht (eigentlich die zweite) – die Reservierungsversion. Wie sah es aus?
Das war es -
Unser Hauptproblem besteht darin, dass es sich um einen physischen Host handelt.
Erstens entfernen wir SANs, weil wir experimentieren wollen, wir wollen nur lokale Festplatten ausprobieren.
Dies ist bereits 2014-2015, und zu dieser Zeit hat sich die Situation mit Festplatten und deren Kapazität in einem Host viel verbessert. Wir beschlossen, warum wir es nicht versuchen sollten.
Und dann nehmen wir einfach unsere Backup-Partition und übertragen sie physisch auf eine separate Maschine.
Somit erhalten wir dieses Diagramm. Wir haben zwei Autos, die die gleichen Datensätze speichern. Sie sichern sich gegenseitig vollständig und synchronisieren Daten über das Netzwerk über eine asynchrone Warteschlange im selben MySQL.
Das funktioniert deshalb so gut, weil wir nur wenige Datensätze haben. Diese. Wenn Schreiben mit Lesen vergleichbar wäre, hätten wir möglicherweise eine Art Netzwerkaufwand und Probleme. Es wird wenig geschrieben, viel gelesen – diese Methode funktioniert gut, d.h. Wir kopieren selten Fotos zwischen diesen beiden Servern.
Wie funktioniert das, wenn man etwas genauer hinschaut?
Hochladen. Der Balancer wählt einfach zufällige Hosts mit einem Paar aus und lädt darauf hoch. Gleichzeitig führt er selbstverständlich Gesundheitschecks durch und sorgt dafür, dass das Auto nicht herausfällt. Diese. Er lädt Fotos nur auf einen Live-Server hoch, und dann wird alles über eine asynchrone Warteschlange auf seinen Nachbarn kopiert. Mit dem Upload ist alles denkbar einfach.
Die Aufgabe ist etwas schwieriger.
Lua hat uns hier geholfen, da es schwierig sein kann, eine solche Logik auf Vanilla NGINX zu erstellen. Wir stellen zunächst eine Anfrage an den ersten Server, um zu sehen, ob das Foto dort ist, da es möglicherweise zum Beispiel bei einem Nachbarn hochgeladen werden könnte, aber noch nicht hier angekommen ist. Wenn das Foto da ist, ist das gut. Wir geben es sofort an den Kunden weiter und speichern es möglicherweise zwischen.
Sollte es nicht da sein, stellen wir einfach eine Anfrage an unseren Nachbarn und erhalten es garantiert von dort.
Das. Auch hier können wir sagen: Es kann zu Performance-Problemen kommen, da es ständig zu Roundtrips kommt – das Foto wurde hochgeladen, es ist nicht hier, wir stellen zwei Anfragen statt einer, das sollte langsam funktionieren.
In unserer Situation funktioniert das nicht langsam.
Wir sammeln eine Reihe von Metriken auf diesem System, und die bedingte Smart-Rate eines solchen Mechanismus liegt bei etwa 95 %. Diese. Die Verzögerung dieses Backups ist gering, und deshalb können wir fast garantieren, dass wir das Foto nach dem Hochladen beim ersten Mal aufnehmen und nicht zweimal irgendwohin gehen müssen.
Was haben wir sonst noch, das wirklich cool ist?
Zuvor hatten wir die Hauptsicherungspartition und haben nacheinander von ihnen gelesen. Diese. Wir haben immer zuerst im Hauptverzeichnis und dann im Backup gesucht. Es war ein einziger Schritt.
Jetzt nutzen wir das Lesen von zwei Maschinen gleichzeitig. Wir verteilen Anfragen per Round Robin. In einem kleinen Prozentsatz der Fälle stellen wir zwei Anfragen. Aber insgesamt haben wir jetzt doppelt so viel Lesebestand wie zuvor. Und die Belastung wurde sowohl auf den Versandmaschinen als auch direkt auf den Lagermaschinen, die wir damals auch hatten, stark reduziert.
Was die Fehlertoleranz betrifft. Eigentlich ist es das, wofür wir hauptsächlich gekämpft haben. Mit Fehlertoleranz hat hier alles super geklappt.
Ein Auto hat eine Panne.
Kein Problem! Ein Systemingenieur wacht möglicherweise nicht einmal nachts auf, er wartet bis zum Morgen, dann wird nichts Schlimmes passieren.
Auch wenn diese Maschine ausfällt und die Warteschlange außer Betrieb ist, gibt es auch keine Probleme. Das Protokoll wird einfach zuerst auf der lebenden Maschine gesammelt und dann zur Warteschlange und dann zum Auto hinzugefügt nach einiger Zeit in Betrieb gehen.
Das Gleiche gilt für die Wartung. Wir schalten einfach eine der Maschinen aus, ziehen sie manuell aus allen Pools, sie empfängt keinen Datenverkehr mehr, wir führen Wartungsarbeiten durch, wir bearbeiten etwas, dann nehmen wir sie wieder in Betrieb, und dieses Backup wird ziemlich schnell aufgeholt. Diese. pro Tag gleicht sich die Ausfallzeit eines Autos innerhalb weniger Minuten aus. Das ist wirklich sehr wenig. Mit Fehlertoleranz sage ich noch einmal, hier ist alles cool.
Welche Schlussfolgerungen lassen sich aus diesem Sozialplan ziehen?
Wir haben Fehlertoleranz.
Einfach zu verwenden. Da die Maschinen über lokale Festplatten verfügen, ist dies für die damit arbeitenden Ingenieure aus betrieblicher Sicht wesentlich komfortabler.
Wir erhielten eine doppelte Lesevergütung.
Dies ist zusätzlich zur Fehlertoleranz ein sehr guter Bonus.
Aber es gibt auch Probleme. Jetzt haben wir eine viel komplexere Entwicklung einiger damit zusammenhängender Funktionen, da das System schließlich zu 100 % konsistent ist.
Wir müssen uns beispielsweise in irgendeinem Hintergrundjob ständig fragen: „Auf welchem Server laufen wir gerade?“, „Gibt es hier wirklich ein aktuelles Foto?“ usw. Das ist natürlich alles zusammengefasst und für den Programmierer, der Geschäftslogik schreibt, transparent. Aber dennoch ist diese große komplexe Schicht entstanden. Aber wir sind bereit, dies im Austausch für die Vorteile, die wir dadurch erhalten haben, in Kauf zu nehmen.
Und auch hier kommt es wieder zu Konflikten.
Ich habe am Anfang gesagt, dass es schlecht ist, alles auf lokalen Festplatten zu speichern. Und jetzt sage ich, dass es uns gefallen hat.
Ja, tatsächlich hat sich die Situation im Laufe der Zeit stark verändert, und jetzt hat dieser Ansatz viele Vorteile. Erstens erhalten wir eine viel einfachere Bedienung.
Zweitens ist es produktiver, weil wir keine automatischen Controller oder Verbindungen zu Festplatten-Shelfs haben.
Es gibt dort eine riesige Menge an Maschinen, und das sind nur ein paar Scheiben, die hier auf der Maschine zu einem Raid zusammengefügt werden.
Aber es gibt Nachteile.
Dies ist selbst bei heutigen Preisen etwa 1,5-mal teurer als die Verwendung von SANs. Daher haben wir uns entschieden, nicht mutig unser gesamtes großes Cluster in Autos mit lokalen Festplatten umzuwandeln und uns für eine Hybridlösung zu entscheiden.
Die Hälfte unserer Maschinen arbeitet mit Festplatten (naja, nicht die Hälfte – wahrscheinlich 30 Prozent). Und der Rest sind alte Autos, die früher das erste Reservierungssystem hatten. Wir haben sie einfach neu gemountet, da wir keine neuen Daten oder irgendetwas anderes benötigten, sondern haben die Mounts einfach von einem physischen Host auf zwei verschoben.
Und wir haben mittlerweile einen großen Bestand an Lektüre, den wir erweitert haben. Wenn wir früher einen Speicher auf einer Maschine montiert haben, montieren wir jetzt beispielsweise vier auf einem Paar. Und es funktioniert gut.
Lassen Sie uns kurz zusammenfassen, was wir erreicht haben, wofür wir gekämpft haben und ob es uns gelungen ist.
Ergebnisse
Wir haben Benutzer – bis zu 33 Millionen.
Wir haben drei Präsenzpunkte: Prag, Miami, Hongkong.
Sie enthalten eine Caching-Schicht, die aus Autos mit schnellen lokalen Festplatten (SSDs) besteht, auf denen einfache Maschinen von NGINX, dessen access.log und Python-Daemons laufen, die all dies verarbeiten und den Cache verwalten.
Wenn Sie möchten, sind Sie in Ihrem Projekt, wenn Fotos für Sie nicht so wichtig sind wie für uns, oder wenn der Kompromiss zwischen Kontrolle, Entwicklungsgeschwindigkeit und Ressourcenkosten für Sie in die andere Richtung geht, dann können Sie es getrost ersetzen Mit einem CDN kommen moderne CDNs gut zurecht.
Als nächstes kommt die Speicherschicht, auf der wir Cluster aus Maschinenpaaren haben, die sich gegenseitig sichern. Dateien werden bei jeder Änderung asynchron von einer zur anderen kopiert.
Darüber hinaus arbeiten einige dieser Maschinen mit lokalen Festplatten.
Einige dieser Maschinen sind mit SANs verbunden.
Und einerseits ist es bequemer zu bedienen und etwas produktiver, andererseits ist es praktisch in Bezug auf Platzierungsdichte und Preis pro Gigabyte.
Dies ist ein so kurzer Überblick über die Architektur dessen, was wir haben, und wie sich alles entwickelt hat.
Noch ein paar Tipps vom Kapitän, ganz einfache.
Erstens: Wenn Sie plötzlich zu dem Schluss kommen, dass Sie dringend alles in Ihrer Fotoinfrastruktur verbessern müssen, messen Sie zuerst, denn vielleicht muss nichts verbessert werden.
Lassen Sie mich Ihnen ein Beispiel geben. Wir haben eine Reihe von Maschinen, die Fotos aus Anhängen in Chats versenden, und das Schema funktioniert dort seit 2009, und niemand leidet darunter. Allen geht es gut, jedem gefällt alles.
Um zu messen, hängen Sie zunächst eine Reihe von Kennzahlen auf, schauen Sie sich diese an und entscheiden Sie dann, womit Sie unzufrieden sind und was verbessert werden muss. Um dies zu messen, haben wir ein cooles Tool namens Pinba.
Es ermöglicht Ihnen, sehr detaillierte Statistiken von NGINX für jeden Anforderungs- und Antwortcode sowie die Zeitverteilung zu sammeln – ganz wie Sie möchten. Es verfügt über Anbindungen an alle möglichen Analysesysteme, und dann können Sie sich alles wunderbar ansehen.
Zuerst haben wir es gemessen, dann haben wir es verbessert.
Weiter. Wir optimieren das Lesen mit Cache und das Schreiben mit Sharding, aber das ist ein offensichtlicher Punkt.
Weiter. Wenn Sie gerade erst mit dem Aufbau Ihres Systems beginnen, ist es viel besser, Fotos als unveränderliche Dateien zu erstellen. Weil Sie sofort eine ganze Reihe von Problemen mit der Cache-Ungültigmachung verlieren, wie die Logik die richtige Version des Fotos finden soll usw.
Nehmen wir an, Sie haben hundert hochgeladen und diese dann gedreht, so dass es sich um eine physisch andere Datei handelt. Diese. Kein Grund zum Nachdenken: Jetzt spare ich etwas Platz, schreibe es in dieselbe Datei und ändere die Version. Das funktioniert immer nicht gut und verursacht später viel Kopfzerbrechen.
Nächster Punkt. Informationen zur spontanen Größenänderung.
Früher haben wir, wenn Benutzer ein Foto hochgeladen haben, sofort eine ganze Reihe von Größen für alle Gelegenheiten und für verschiedene Kunden zugeschnitten, und sie waren alle auf der Festplatte. Jetzt haben wir darauf verzichtet.
Wir haben nur drei Hauptgrößen übrig: klein, mittel und groß. Wir verkleinern einfach alles andere von der Größe, die hinter der liegt, die uns bei Uport gestellt wurde, wir führen einfach die Verkleinerung durch und geben es dem Benutzer.
Die CPU der Caching-Schicht erweist sich hier als deutlich günstiger, als wenn wir diese Größen auf jedem Speicher ständig neu generieren würden. Nehmen wir an, wir möchten einen neuen hinzufügen. Das wird einen Monat dauern. Führen Sie überall ein Skript aus, das dies alles sauber erledigt, ohne den Cluster zu zerstören. Diese. Wenn Sie jetzt die Möglichkeit haben zu wählen, ist es besser, so wenige physische Größen wie möglich zu erstellen, aber zumindest eine gewisse Verteilung, sagen wir, drei. Und alles andere kann mit vorgefertigten Modulen einfach im Handumdrehen angepasst werden. Es ist jetzt alles sehr einfach und zugänglich.
Und inkrementelles asynchrones Backup ist gut.
Wie unsere Praxis gezeigt hat, funktioniert dieses Schema hervorragend beim verzögerten Kopieren geänderter Dateien.
Auch der letzte Punkt ist offensichtlich. Wenn Ihre Infrastruktur jetzt keine derartigen Probleme hat, es aber etwas gibt, das kaputt gehen kann, wird es definitiv kaputt gehen, wenn es etwas mehr wird. Daher ist es besser, im Voraus darüber nachzudenken und keine Probleme damit zu bekommen. Das ist alles, was ich sagen wollte.
Kontakte
»
»
Dieser Bericht ist eine Abschrift einer der besten Reden auf der Konferenz der Entwickler von Hochlastsystemen . Bis zur HighLoad++ 2017-Konferenz ist es noch weniger als ein Monat.
Wir haben es bereits fertig , der Zeitplan wird derzeit aktiv gestaltet.
In diesem Jahr beschäftigen wir uns weiterhin mit dem Thema Architekturen und Skalierung:
- / Igor Wassiljew
- / Dmitri Jegorow
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Einige dieser Materialien nutzen wir auch in unserer Online-Schulung zur Entwicklung von Hochlastsystemen ist eine Kette speziell ausgewählter Briefe, Artikel, Materialien, Videos. Unser Lehrbuch enthält bereits mehr als 30 einzigartige Materialien. Verbinden!
Source: habr.com