Es gibt viele Beiträge darüber, wie ein typisches Coding-Interview bei Google aussieht. Obwohl dies nicht so ausführlich beschrieben und diskutiert wird, gibt es auch häufig ein Interview zum Systemdesign. Für eine SRE-Position ist es NALSD: nicht abstraktes großes Systemdesign. Der Hauptunterschied zwischen SWE- und SRE-Interviews besteht in diesen beiden Buchstaben: NA.
Was ist der Unterschied? Wie kann man sich auf dieses Interview vorbereiten? Lassen Sie uns nicht abstrakt sein und ein Beispiel verwenden. Um nicht abstrakter zu sein, nehmen wir etwas aus der materiellen Welt, so dass Sie beim eigentlichen Interview nicht genau das Gleiche gefragt werden (zumindest nicht beim Google-Interview) :)
Entwerfen wir also ein öffentliches Bibliothekssystem. Für die Papierbücher, wie Sie sie überall gesehen haben. Der gesamte folgende Text wurde innerhalb von etwa einer Stunde auf einmal geschrieben, um Ihnen grob die Bereiche zu zeigen, die Sie während des Interviews abdecken / berühren können sollten. Bitte entschuldigen Sie eine Störung, so denke ich (deshalb bin ich).
NALSD-Interview: Entwerfen Sie ein öffentliches Bibliothekssystem.
Zunächst erfassen wir Lastmerkmale, entweder durch Fragen an den Interviewer oder durch eine vernünftige Vermutung (ohne zu vergessen, sie laut auszusprechen). Da es sich bei dem Interview um skalierbare Systeme handelt, erwarten wir eine Stadt mit einer großen Bevölkerung (z. B. 1 Million +). Wir haben einige Optionen: ein riesiges Gebäude oder lokale Bibliotheken plus Speicher. Ich denke, letzteres ist vernünftiger, da es uns auch ermöglicht, das System auf mehrere Städte auszudehnen.
Konzentrieren wir uns nun auf das System für die einzelne Stadt. Wir sollten in der Lage sein, dasselbe Design (mit geringfügigen Korrekturen) erneut anzuwenden, um es auf Länderebene auszudehnen. Wir haben also eine Stadt mit mehr als 1 Million Einwohnern. Um die Berechnungen zu vereinfachen, runden wir 1M mögliche Leser ab. Jeder Leser möchte zu beliebigen Zeitpunkten etwas unabhängig voneinander lesen. So können wir den Leserstrom als Poisson-Prozess modellieren. Während des Interviewzeitraums ist es etwas schwierig, richtig zu rechnen. Vereinfachen wir es also noch einmal und sagen wir einfach, dass ungefähr 1% der möglichen Leser jeden Tag kommen würden, um ein Buch zu nehmen. Nehmen Sie also 10000 Buchanfragen pro Tag an.
Unsere Aufgabe wurde nun: Bereitstellung der Möglichkeit, 10000 Bücher pro Tag in einer Stadt mit mehr als 1 Million Einwohnern zu verteilen (das bedeutet auch, dass wir diese 10000 Bücher eines Tages später zurücknehmen müssen). Diese Schätzung zeigt, dass die Single-Building-Lösung nicht Bestand hat (um die Bücher für mehr als 1 Million Menschen bereitzustellen, sollte unsere Bibliothek innerhalb eines angemessenen Zeitraums erreichbar sein, da sonst der Wille, ein Buch zu nehmen, im Stau abläuft). Versuchen wir also zu erraten, welche Größe für die lokalen Bibliotheken, die wir erstellen müssen, angemessen ist. Eine absolut korrekte Schätzung würde Bevölkerungsdichte, Erreichbarkeitslatenzen usw. beinhalten, aber da dies das Gesamtdesign nicht beeinflusst, können wir es wieder einfacher machen, indem wir eine gleichmäßige Verteilung ähnlicher Einheiten berücksichtigen. Wir wissen immer noch nicht, wie groß die Einheiten sein sollen, zum Beispiel könnten wir 10000 Bibliotheken mit jeweils 1 Buch über die Stadt verteilen, aber es wird offensichtlich nicht funktionieren. Eine Ebene tiefer gehen.
Eine einzelne lokale Bibliothekseinheit. Damit es nützlich ist, sollte die Mehrheit der Besucher in der Lage sein, das gewünschte Buch zu finden. Das bedeutet, dass wir die Nutzung verfolgen und die Nachfrage nach den beliebtesten Anfragen prognostizieren müssen, um bereit zu sein, diese zu bedienen. Darüber hinaus sollten wir eine große Auswahl an weniger beliebten Artikeln haben. Meine grobe Vermutung ist eine Bibliothek mit weniger als 1000 Buchnamen, mit Dutzenden von Exemplaren für die beliebtesten und Einzelstücken für die Schwänze. Die durchschnittliche Zeit zum Lesen eines Buches in unserer Bibliothek liegt zwischen 3 Tagen und 2 Wochen (die Echtzeit hängt natürlich vom Buch selbst ab, was in einem realen Fall eine zusätzliche Analyse erfordern würde). Schätzen wir als 1 Woche pro Buch. Das bedeutet, dass ein Buch, das ausgehändigt wurde, in 1 Woche zurückkommt. Wir sollten also 1 Woche lang Top-Bücher zur Verfügung haben (nach einer Woche werden sie von den Rücksendungen aufgefüllt).
Angenommen, ein durchschnittlicher Explosionsfaktor von 6 würde uns zu einer Speicherkapazität von 6000 Büchern führen. Weniger Speicherplatz würde einen Mangel an den beliebtesten Namen bedeuten (kleinere Einheiten könnten immer noch nützlich sein - wie ein kleiner Mall-Kiosk mit „Twilight“, aber lassen Sie es uns jetzt außerhalb unseres Designs halten).
In einem stabilen Zustand sind die Renditen und Kredite jeden Tag fast gleich (mit einer gewissen Streuung), aber wir sollten auch Spitzenrenditen einplanen (dies können externe Synchronisierungsereignisse sein: Feiertage, Trends usw.). Der richtige Weg ist, ein statistisches Modell zu erstellen und auszuführen. Aber jetzt behalten wir ⅓ einfach als Puffer. Das bedeutet, dass wir 6000 Bücher zur Ausgabe bereithalten sollten, plus Platz für 2000.
Zusammenfassend: Wir brauchen eine Bibliothekseinheit mit 8000 Büchern. Es wird voraussichtlich teuer sein, es jeden Tag wieder aufzufüllen, daher sollten wir damit rechnen, dass dies für ein oder zwei Wochen ausreicht. Zwei Wochen, 6000 Bücher, mit möglicher Renditeverschiebung, es sind ungefähr 300 Bücher pro Tag. Für den Eröffnungstag können wir den gesamten Speicher (8000 Bücher) füllen, um die ersten 2000 Bücher im Umsatz zu setzen. 2000 in 3 Tagen = 600 Bücher pro Tag, mit Schräglaufpuffer = 800 Bücher pro Tag.
Lassen Sie uns den Durchsatz und die Einschränkungen unseres Speichers abschätzen. 1 Buch hat einen Raum von ca. 2 cm, 8000 Bücher = 160 m. Wir können es 4 Mal vertikal falten, also sind es 40 Laufmeter. Wenn wir es in ~ 5-Meter-Racks aufteilen, erhalten wir 8 Racks mit 4 Regalen, die jeweils 5 Meter lang sind. Ein Bibliothekar (oder Robo-Bibliothekar) sollte mit zwei Racks arbeiten können. Das Herausziehen eines einzelnen Buches dauert: 5 Sekunden, um zu den Regalen zu gehen, 5 Sekunden, um das Buch zu greifen / an seinen Platz zu legen, 5 Sekunden, um zurück zu gehen (insgesamt 15 Sekunden). 4 Bibliothekare geben uns einen Spitzendurchsatz von 15 Büchern pro Minute. Somit ist eine Handhabung von höchstens 900 Büchern pro Stunde möglich.
Wenn wir auch die Bearbeitungszeit für Anforderungen (10 Sekunden), die Suchzeit (5 Sekunden) und die Zeit für die Verfolgung des Systems (2 Sekunden) berücksichtigen, erhalten wir einen Spitzenwert von 400 Büchern / Stunde. Wir sollten also in der Lage sein, unsere Schätzung von 800 Büchern pro Tag in 2 Stunden zu verarbeiten.
Lassen Sie uns andere Aspekte berechnen: Um 4 Bücher / Stunde von 4 Bibliothekaren ausgeben zu können, müssen wir genügend Platz für 100 Personen haben, die in der Schlange stehen, und die Eingangstüren sollten 400 Personen / Stunde erlauben, in beide Richtungen zu gehen . Das bedeutet, dass unsere Hauptdrosselung der Wartebereich und die Gebäudetüren sind.
Das bedeutet, dass wir in der Lage sein sollten, bei den richtigen Berechnungen für das tatsächliche Design ein optimales Gleichgewicht zwischen Speicherplatz und Wartebereich zu finden.
Das war's für dieses Level, es ist Zeit weiterzumachen. Wir schätzen den Gesamtbedarf des Bibliotheksnetzwerks auf 10000 Bücher / Tag. Eine Einheit ist 800 Bücher / Tag, also brauchen wir 12,5 Einheiten. Wenn wir eine einheitliche geografische Verteilung durchführen, sollte jeder Leser im Bereich von 1-2 Einheiten (an der Stadtgrenze) und 3-4 (innerhalb der Stadt) liegen. Dies würde die Möglichkeit geben, Spitzen ein wenig auszugleichen und / oder Engpässe bei Top-Büchern zu decken.
Wir wissen auch, dass jede Bibliothek jederzeit geschlossen werden kann (Feuer, Inspektion, Neulackierung der Kühlschranktürgriffe usw.) und dass die Wahrscheinlichkeit eines Zusammentreffens dieser Ereignisse umso höher ist, je mehr Einheiten wir haben. Daher benötigen wir 1 redundante Einheit pro 5-6 Einheiten. Insgesamt benötigen wir also 15 Einheiten, um unsere städtischen Anforderungen zu erfüllen, wenn wir die erforderliche Versorgung innerhalb jeder Einheit aufrechterhalten wollen.
Wie wir bereits früher gedacht haben, müssen wir den Speicher alle ein oder zwei Wochen auffüllen (früher haben wir zwei erraten) - etwa die Hälfte des Speichers sollte ersetzt werden, um den Trends zu folgen usw. Also 4000 Bücher mit neuer Lieferung und 4000 Bücher daraus entfernt. Bei jedem Nachschub müssen wir 4000 Bücher herausziehen und 4000 neue Einträge zurückfügen. Mit unserem Durchsatz von 400 Büchern / Stunde entspricht ein Nachschub 10 sehr intensiven Stunden. Nun, es scheint immer noch in Ordnung zu sein, zumal Massenoperationen normalerweise billiger sind. aber trotzdem - wir sollten bedenken, dass der Wiederauffüllvorgang fünfmal teurer ist als nur das Servieren.
Ein durchschnittliches Buch (2 cm * 20 cm * 30 cm) hat ein Volumen von 1,5 Litern, also 4000 Bücher = 6 Kubikmeter. Dies sollte in ein einzelnes durchschnittliches leichtes Frachtfahrzeug passen. 1 Kubikmeter Papier wiegt 600 kg, 6 m 3 = 3,6 t. Ein durchschnittliches leichtes Frachtfahrzeug kann ~ 1,5 Tonnen umschlagen, wir brauchen also 3 davon. Plus eins für Redundanz. Wir haben 15 Bibliothekseinheiten, die alle 2 Wochen aktualisiert werden, was bedeutet, dass dies eng im Zeitplan liegt, sodass wir ein weiteres Auto benötigen.
Und wir haben immer noch nicht darüber nachgedacht, wie und woher diese Autos die Bücher bewegen würden, daher werden für unser Design auch Lagerhäuser und Müllabfuhrstellen für nicht mehr beliebte Bücher benötigt ...
Die Zeit ist abgelaufen. Was ist das Besondere an der NALSD-Frage? Skalierbarkeit wird von jedem großen Systemdesign erwartet. Aber in einem NALSD-Interview muss man
genau sein .
Sie können oben viele Vermutungen und Annahmen sehen, aber alle Berechnungen basierten auf zuvor gemachten Zahlen. Ich habe auch versucht zu erklären, wie man zur richtigen Nummer kommt, aber es ist leicht, müde / gelangweilt zu werden und dies zu verpassen. Es ist auch einfach, sich an eine Zahl aus Ihrem Speicher zu halten, ohne eine gute Erklärung für die Gründe zu liefern ... Da das Design jedoch sehr spezifisch ist, können Sie die Zahl ändern und den Rest neu berechnen, wenn Sie einen Fehler für eine beliebige Zahl machen.
Ich erinnere mich noch daran, wie ich während meines NALSD-Interviews bei IOPS einer einzelnen Festplatte von 600 geblieben bin, nur weil ich kürzlich an der Optimierung eines RAID-Arrays gearbeitet hatte, bei dem das gesamte Array 600 IOPS hatte ... Der Interviewer war leicht überrascht: 600 IOPS pro fahren? : D.Während des Interviews können alle Ihre Annahmen und Vermutungen vom Interviewer korrigiert werden. Außerdem könnte der Interviewer einige zusätzliche Einschränkungen hinzufügen (die Sie vergessen haben, von denen Sie nichts wussten, die Sie nicht gefragt haben oder die Sie einfach anpassen möchten, weil sie möchten oder denken, dass dies ein besserer Weg ist, um fortzufahren). Da Sie nur mit bestimmten Zahlen arbeiten, wären nur kleine Aktualisierungen der Zahlen gemäß den bereits angegebenen Gleichungen erforderlich.
Wenn die Korrektur einer Annahme eine vollständige Neugestaltung des Systems erfordert, handelt es sich entweder um einen Entwurfsfehler oder um eine falsche Korrektur, oder die neue Annahme führt uns über die Anwendbarkeit des Entwurfs hinaus (und dies ist im wirklichen Leben nicht so selten). Es ist wichtig, diese Tatsache nicht zu verpassen: Sie sollten die erhaltenen Zahlen validieren, um sicherzustellen, dass sie sowohl während des Entwurfs als auch nach jeder Korrektur realistisch sind.
Als SREs müssen wir über die Skalierbarkeit realer Systeme im Rahmen realer Hardwarebeschränkungen nachdenken. Es könnte einen schönen
Algorithmus geben , der eine gigantische Zeitkomplexität gegen eine bestimmte Menge RAM austauscht ... Dennoch können wir heute nicht 1PiB RAM pro 1 CPU erstellen. Wenn wir also 1 PiB RAM haben, haben wir auch ungefähr 10k CPUs. Oder 20k. Oder sogar 30k. Das bedeutet, dass wir uns auf das reale (lokale) Optimum konzentrieren sollten, das heute in der Realität erreichbar ist, und nicht auf das globale Optimum, das unter idealen Bedingungen erreichbar ist.
Sie sollten sich keine genauen Zahlen merken, aber Sie sollten in der Lage sein, Faustregeln anzuwenden, um Größenordnungen zu erhalten. Wie IOPSes: HDD ist ungefähr 100s, SSD ungefähr 100s Tausende. Aber diese Hunderttausenden haben einen Preisunterschied zwischen Festplatte und SSD wie 1: 3 oder 1: 4. Außerdem wird alles ignoriert: Rack-Platz, Blades für die Laufwerke, Netzwerkanschlüsse und andere Dinge, die nicht mehr billig sind, wenn Sie bei Peta- und Exa-Skalen arbeiten.
Machen Sie es sich jetzt auf Ihrem Stuhl bequem, entspannen Sie sich und versuchen Sie, ein System für das Wachstum und die Lieferung von frischen Hühnereiern im Abonnement zu entwickeln.