Ich habe vorhin ein typisches
Coding-Interview beschrieben . Neben der Codierung gibt es fast immer eine Frage zum Systemdesign. (Großes) Systemdesign. Bei Interviews auf SRE ist dies ein (für mich) noch interessanteres Tier - NALSD. Nicht abstraktes großes Systemdesign. Der Hauptunterschied zwischen SWE und SRE liegt genau in diesen Buchstaben „NA“.
Was ist der Unterschied und wie kann man sich darauf vorbereiten? Schauen wir uns ein Beispiel an. Als Beispiel nehmen wir etwas sehr Materielles, etwas, das niemand jemals um ein echtes Interview bitten wird (in Google) :)
Zum Beispiel - lassen Sie uns eine Bibliothek entwerfen. Für Papierbücher das übliche. Der gesamte folgende Text wurde in einer Sitzung in ungefähr einer Stunde geschrieben, um grob zu zeigen, was Sie tun können und was wichtig ist. Also vergib mir die Verwirrung, aber ich denke schon (und existiere deshalb).
NALSD-Frage: Entwerfen Sie eine öffentliche Bibliothek.
Erstens interessieren uns die Eigenschaften der Last, oder wir gehen selbst von einer vernünftigen Annahme aus. Da es sich um ein skalierbares System handelt, handelt es sich um eine Stadt mit mindestens einer Million Einwohnern. Es lohnt sich, Optionen in Betracht zu ziehen - ein großes Gebäude oder Bezirksbibliotheken plus Speicher. Letzteres scheint mir vernünftiger zu sein. Besonders wenn nicht eine Stadt, sondern eine Stadt.
Daher werden wir uns im Moment auf das System einer Stadt konzentrieren (mit einigen Vorbehalten können wir einen ähnlichen Mechanismus auf einer höheren Ebene für die Skalierung auf viele Städte anwenden). Die Stadt hat also eine Million Einwohner. Wir runden die Zahlen ab, um Schätzungen zu vereinfachen - es sollen 1 Million wahrscheinliche Leser sein. Die Leser werden jederzeit unabhängig voneinander lesen. Wir können es also als einfachen Poisson-Prozess herausfinden. Normalerweise ist das Zählen auf der Flucht jedoch schwierig. Machen Sie also einen weiteren Vereinfachungsschritt und gehen Sie davon aus, dass 1% der Leser täglich ein Buch nehmen möchten. Insgesamt nehmen wir für weitere Berechnungen 10.000 Bücher pro Tag.
Unsere Aufgabe ist es, die Möglichkeit zu bieten, 10.000 Bücher pro Tag (und übrigens die gleichen 10.000 an jedem anderen Tag in der Zukunft) in der Stadt von mehr als einer Million herauszugeben. In diesem Moment fällt die Frage nach der Monobibliothek oder dem Distrikt bereits weg (damit die ganze Million potenzielle Leser sein kann, müssen sie in angemessener Zeit in die Bibliothek gelangen können, da sonst der Wunsch, das Buch zu nehmen, mit der Zeit definitiv nachlässt). Wir müssen also die Kapazität jeder lokalen Bibliothek bewerten. Es ist richtig, dies unter Berücksichtigung der Bevölkerungsdichte und der Erreichbarkeit zu tun. Da dies jedoch das System selbst nicht wesentlich beeinflusst, stellen wir uns zur Vereinfachung der Berechnungen vor, dass wir sie gleichmäßig platzieren. Dies bedeutet jedoch immer noch nicht, wie wir sie teilen können. Es macht natürlich keinen Sinn, 10.000 Bibliotheken mit einem Buch gleichmäßig in der Stadt zu platzieren. Sie müssen also verstehen, was Sinn macht. Wir gehen zum unteren Level.
Also eine Bibliothek. Damit es Sinn macht, müssen die meisten, die kommen, das Buch finden, das sie brauchen. Dies bedeutet, dass wir die beliebtesten Anfragen aufzeichnen und prognostizieren und diese Bücher bereithalten müssen. Dann müssen wir das Sortiment grundsätzlich behalten. Auf Anhieb würde ich sagen, dass eine lokale Bibliothek mindestens 1000 Objekte haben sollte, die ganz oben in einer Vielzahl von Kopien stehen, mehr Top-Objekte, weniger Tail-Objekte. Das durchschnittliche Buch in unserer Bibliothek wird von 3 Tagen bis 2 Wochen gelesen (tatsächlich hängt das Merkmal vom Buch ab, hier ist eine separate Analyse erforderlich). Wir nehmen es gleich der durchschnittlichen Woche und fahren fort. Das heißt, das genommene Buch fehlt ungefähr eine Woche lang, daher müssen die Top-Bücher eine Woche lang auf Lager sein (dann erholen sie sich von den Rückgaben).
Nehmen wir einen durchschnittlichen Inflationsfaktor von 6. Die Speicherkapazität beginnt also bei 6.000 Büchern. Weniger bedeutet, dass dies nur ein kleines Oberteil ist, was in einigen Fällen noch hilfreich sein kann (z. B. eine Insel mit „Dämmerung“ in einem Supermarkt in der Nähe des Kinderspielzimmers), aber wir werden es vorerst draußen lassen.
Im Gleichgewichtszustand kehren sie zurück und dauern ungefähr gleich einen Tag plus oder minus der Streuung. Wir müssen jedoch weiterhin in der Lage sein, eine erhöhte Anzahl von Spitzenrückgaben zu akzeptieren (z. B. aufgrund externer Synchronisation wie Feiertage oder eines Modewechsels). Das ist richtig - zu simulieren. Aber hier und jetzt nehmen wir ein Drittel als Puffer. Insgesamt unterstützen wir 6.000 Bücher, die zur Ausgabe verfügbar sind, sowie einen Platz für weitere 2.000 in Reserve.
Wir brauchen also eine Einheit, die 8000 Bücher speichern kann. Das tägliche Nachfüllen ist sehr teuer, was bedeutet, dass es ein oder zwei Wochen dauert. Zwei Wochen, 6.000 Bücher, mit einer Tendenz zur Rendite, das sind ungefähr 300 pro Tag. Zum Zeitpunkt der Eröffnung können wir alle 8000 Bücher bewerten, um die ersten 2000 im Umlauf befindlichen Bücher vor der ersten Rückkehr zu erstellen. 2000 für 3 Tage = ungefähr 600 Bücher pro Tag plus Puffer = 800 Bücher pro Tag.
Lassen Sie uns die Bandbreiten- und Speichergrenzen schätzen. Ein Buch benötigt durchschnittlich 2 Zentimeter linearen Raum, 8000 Bücher - 160 Meter. 4 mal vertikal drehen, 40 Meter. Wir brechen in gleichmäßige 5-Meter-Racks auf, wir bekommen 8 Racks mit 4 Regalen, die 5 Meter lang sind. Ein Bibliothekar (oder ein Robo-Bibliothekar) kann mit zwei Racks arbeiten. Das Herausziehen eines Buches dauert bis zu 5 Sekunden, um es zu erreichen, 5 Sekunden, um das Buch herauszuholen oder zu legen, 5 Sekunden in umgekehrter Reihenfolge, insgesamt 15 Sekunden. 4 Bibliothekare stellen uns maximal ungefähr 15 Bücher pro Minute zur Verfügung, d. H. 900 Bücher pro Stunde ab Lager.
Wir addieren Zeit für die Bearbeitung der Anfrage (10s), Suche (5s), Eingabe in das Empfangs- und Ausgabesystem (2s) => 400 Bücher pro Stunde. So kann der Speicher auf seinem Höhepunkt 400 Bücher pro Stunde ausgeben, sodass 800 Bücher pro Tag in 2 Arbeitsstunden erreichbar sind.
Jetzt betrachten wir andere Merkmale: Um 400 Bücher pro Stunde von 4 Personen zu verteilen, müssen 100 Personen im Wartezimmer in einer Warteschlange vor dem Verarbeitungsfenster untergebracht werden, damit diese Personen am Ein- und Ausgang keine Menschenmassen erzeugen. Das heißt, die Eingangsgruppe muss 400 Personen pro Stunde in beide Richtungen passieren. Es stellt sich heraus, dass der Hauptbegrenzer nicht einmal die Lagerung sein wird, sondern die Kapazität der Halle und der Eingangsgruppe.
Dies bedeutet, dass mit genaueren Berechnungen das optimale Verhältnis von Lager und Halle ermittelt werden kann.
Nachdem die Einheit aussortiert ist, kehren wir zum obigen Level zurück. Wir haben die Gesamtbelastung der Bibliothek auf etwa 10.000 Bücher pro Tag geschätzt, wir haben eine Einheit mit 800 Büchern pro Tag gezählt, dh wir benötigen 12,5 Einheiten. Mit der Geoverteilung in der Stadt sind ein oder zwei alternative Einheiten (an den Stadtgrenzen) oder sogar 3-4 (innerhalb) für jeden Leser erreichbar, wodurch Sie Verkehrsspitzen und / oder eine erhöhte Nachfrage nach bestimmten Positionen leicht ausgleichen können.
Wir wissen auch, dass jede Bibliothek jederzeit geschlossen werden kann (Feuer, Hygienekontrolle, Streichen der Griffe von Kühlschränken oder etwas anderem), wobei die Anzahl der Bibliotheken zunimmt und die Wahrscheinlichkeit, dass zwei aus dem Leben fallen, zusammenfällt. Daher benötigen wir ein Ersatzgerät für alle 5-6 Einheiten. Insgesamt müssen 15 Einheiten die erforderliche Leistung sicherstellen, sofern sie den geschätzten Bestand in ihren Lagern halten.
Um den geschätzten Bestand aufrechtzuerhalten, müssen wir ein oder zwei Mal pro Woche (wir dachten über zwei) etwa die Hälfte des Sortiments aktualisieren, um Trends zu folgen und so weiter. Dies bedeutet, dass jede Einheit alle zwei Wochen 4.000 Bücher transportieren und exportieren muss. Bei jedem Import und Export müssen dieselben 4.000 Bücher aus dem Repository entfernt und andere dort abgelegt werden. Bei 400 Büchern pro Stunde dauert die Aktualisierung des Sortiments bei maximaler Auslastung 10 Stunden. Was, wie es scheint, immer noch nicht so schlimm ist, mit der Massenbeladung werden viele Dinge schneller gehen, aber die Aufrechterhaltung des Sortiments dauert fünfmal länger als die Arbeit mit der Bevölkerung.
Das durchschnittliche Buch (2 cm × 20 cm × 30 cm) beträgt ungefähr 1,5 l, d. H. 4000 Bücher = 6 Kubikmeter. Es passt leicht in eine Gazelle. Das Gewicht eines Kubikmeters Papier beträgt 600 kg, das sind 6 Kubikmeter 3,6 Tonnen. Die Tragfähigkeit der Gazelle beträgt eineinhalb Tonnen, daher werden drei Gazellen benötigt. Plus ein Backup. Wir haben 15 Einheiten, die alle 2 Wochen aktualisiert werden. Bei einer gleichmäßigen Verteilung sind wir am Limit. Wir müssen eine weitere Gazelle hinzufügen.
Und wir hatten keine Zeit darüber nachzudenken, woher und wo diese Gazellen transportiert wurden, sodass die Lager der Lieferanten und die Punkte des Entladens von Büchern, die an Relevanz verloren haben, auf dem Diagramm erscheinen ...
Die Zeit ist also abgelaufen. Was ist in der NALSD-Frage so abnormal? Skalierbarkeit muss in jedem großen Systemdesign vorhanden sein. Die Hauptsache ist die
Konkretheit .
Ich habe oben viele Annahmen getroffen, aber alle nachfolgenden Schätzungen basierten auf früheren. Bei Zahlen habe ich auch versucht zu geben, wie man richtig bewertet. Es ist jedoch sehr leicht, das zu vergessen. Man wird müde und vergisst es. Es ist immer noch sehr einfach, sich ohne Erklärung an eine Zahl aus dem Speicher zu halten ... Da das Design jedoch konkret ist und eine der Annahmen sich als falsch herausstellt, kann sie behoben und erst später wiedergegeben werden.
Wie ich mich jetzt erinnere, habe ich in meinem Interview mit den Schätzungen einen IOPS von einer Festplatte von 600 genommen, einfach weil ich ihn kürzlich optimiert und mit einem Array gearbeitet habe, wobei _array_ 600 IOPS ausgegeben hat ... Der Befragte hat mich dann ein wenig überrascht gefragt - 600 IOPS auf Festplatte? : D.Während des Interviews kann der Interviewer jede Ihrer Annahmen korrigieren. Oder fügen Sie eine Art Einschränkung hinzu (von der Sie nichts wussten, nicht nachdachten, nicht fragten oder nur die übliche Änderung von TK im laufenden Betrieb). Da Sie ausschließlich mit bestimmten Nummern arbeiten, ist dies nur eine triviale Aktualisierung der Nummern.
Wenn die Anpassung der Annahme zu einer Neugestaltung des Systems führt, handelt es sich entweder um einen Konstruktionsfehler oder um eine falsche Anpassung oder um eine Überschreitung der Anwendbarkeit des Systems, was auch im wirklichen Leben keine seltene Situation ist. Es ist wichtig, solche Momente nicht zu verpassen und die erhaltenen Zahlen sowohl während der Entwurfsphase als auch bei Anpassungen auf ihre Realität hin zu bewerten.
Als SRE sind wir verpflichtet, in Bezug auf die Skalierung realer Systeme unter den realen Einschränkungen realer Hardware zu denken. Möglicherweise gibt es einen hervorragenden
Algorithmus , der enorme Zeitkosten gegen eine kleine Menge Speicher austauscht. Trotzdem können Sie unter realen Bedingungen kein Petabyte RAM auf einen Prozessorkern legen. Wenn wir also ein Petabyte RAM haben, haben wir mindestens zehntausend Prozessoren. Oder zwanzig. Oder dreißig. Und wir müssen nach dem Optimum suchen, nicht global, sondern hier und jetzt unter den gegebenen Bedingungen.
Sie müssen sich nicht die genauen Zahlen merken, aber Sie müssen eine Vorstellung von der Reihenfolge haben: das gleiche IOPS, das die Festplatte ungefähr hundert und die SSD Hunderttausende hat. Diese Hunderttausende gehen jedoch mit dem Verhältnis der Kosten für ein Terabyte Festplatte zu den Kosten für ein Terabyte SSD als eins zu drei zu vier einher. Und das zählt nicht das Geschirr - ein Platz im Rack, Klingen für sie, Anschlüsse an Schaltern und andere Dinge, die keinen Cent mehr sind, wenn die Rechnung in Petabyte geht.
Lehnen Sie sich jetzt ein wenig in Ihrem Stuhl zurück, entspannen Sie sich und versuchen Sie, ein System für die Lieferung von frischen Hühnereiern im Abonnement zu entwickeln.
Wenn Sie mit englischsprachigen Kollegen teilen möchten, gibt es eine
Option auf Englisch (sowie auf
Englisch ).