Überraschende Skalierbarkeit der Mandantenfähigkeit – Marc's Blog

Wenn die meisten Leute über die Wirtschaftlichkeit von Cloud-Systemen sprechen, konzentrieren sie sich auf die automatische Anpassung an langfristige Saisonalität: Änderungen in der Tagesordnung (weniger Leute kaufen Dinge nachts), Wochen (an Wochentagen besuchen weniger Menschen das Resort), Jahreszeiten und Feiertage. Die Skalierung dieser Art von Saisonabhängigkeit ist nützlich und wichtig, aber es gibt einen anderen Faktor, der noch wichtiger sein kann und oft übersehen wird: der kurzfristige Spitzen-zu-Durchschnitt. Grundsätzlich skalieren die Kosten eines Systems mit seinem (kurzfristigen1) Spitzenverkehr, aber für die meisten Anwendungen skaliert der vom System generierte Wert mit dem durchschnittlichen (langfristigen) Verkehr.

Die Kluft zwischen "Zahlung für Spitzenzeiten" und "Durchschnittsverdienst" ist der Schlüssel zum Verständnis, wie sich die Wirtschaftlichkeit großer Cloud-Systeme von herkömmlichen Single-Tenant-Systemen unterscheidet.

Warum ist das wichtig?

Dies ist wichtig, da die Mandantenfähigkeit (d. h. das Ausführen vieler verschiedener Workloads auf demselben System) das Spitzen-Durchschnitts-Verhältnis des gesamten Systems sehr effektiv reduziert. Dies ist aus zwei Gründen sehr vorteilhaft. Der Hauptgrund ist, dass es die Wirtschaftlichkeit des zugrunde liegenden Systems verbessert, indem es die Kosten (proportional zum Spitzenwert) näher an den Wert (proportional zum Durchschnitt) bringt. Der Vorteil zweiter Ordnung und derjenige, von dem Cloud-Kunden am unmittelbarsten profitieren, besteht darin, dass einzelne Workloads höhere Spitzen haben können, ohne die Systemökonomie zu beeinträchtigen.

Die meisten Leute würden das Skalierbarkeit nennen.

Beispiel 1: S3

Anfang dieses Monats hielt Andy Warfield vom S3-Team auf der OSDI'23 eine sehr unterhaltsame Präsentation über seine Erfahrungen bei der Arbeit an S3. Es gibt viel Gold in seinem Vortrag, aber es gibt einen Punkt, den er angesprochen hat, den ich für sehr wichtig halte und den es wert ist, erkundet zu werden: Wärmemanagement und Mandantenfähigkeit. Hier ist der Beginn des relevanten Teils zum Heat2-Management:

Andy spricht hier einen interessanten Punkt an, aber der wichtigste ist der Unterschied zwischen Objekt-Wärmeverteilung, aggregierter Wärmeverteilung und systemweiter em> Hitze.

Skalierung ermöglicht es uns, Kunden eine Leistung zu liefern, die sonst nicht skalierbar wäre.

Hier spricht Andy über diesen Nebeneffekt. Durch die Verteilung von Client-Workloads auf eine große Anzahl von Speichergeräten ist S3 in der Lage, einzelne Workloads mit Peak-to-Average-Verhältnissen zu unterstützen, die in jeder anderen Architektur unerschwinglich teuer wären. Wichtig ist, dass dies ohne Erhöhung des Peak-to-Average des Gesamtsystems und daher ohne zusätzliche Kosten für Kunden oder den Betreiber erfolgt.

Beispiel 2: Lambda

Wie bei S3 ist die Skalierbarkeit von Lambda direkt an die Mandantenfähigkeit gebunden. In unserem Firecracker-Artikel erklären wir warum:

Jeder Steckplatz kann in einem von drei Zuständen existieren: Initialisierung, Belegt und Leerlauf... Steckplätze verbrauchen in jedem Zustand unterschiedliche Mengen an Ressourcen. Im Leerlauf verbrauchen sie Speicher und halten den Funktionsstatus verfügbar. Wenn sie initialisieren und beschäftigt sind, verwenden sie Speicher, aber auch Ressourcen wie CPU-Zeit, Caches, Netzwerk- und Speicherbandbreite und alle anderen Systemressourcen. Arbeitsspeicher macht etwa 40 % der Kapitalkosten typischer moderner Serverdesigns aus, daher sollten ungenutzte Steckplätze 40 % der Kosten belegter Steckplätze kosten. Um dies zu erreichen, müssen Ressourcen (wie CPU) sowohl lose zugeteilt als auch überbelegt werden, damit sie an andere Standorte verkauft werden können, während einer inaktiv ist.

Dieser letzte Punkt ist der wichtigste: Wir können die Speicher- oder CPU-Menge in einer EC2-Metal-Instance nicht dynamisch skalieren, aber wir können planen, den Speicher oder die CPU an einen anderen Kunden zu verkaufen. wird derzeit von keinem Kunden verwendet. Es ist im Grunde eine statistische Wette. Es besteht immer eine Wahrscheinlichkeit ungleich Null, dass die Nachfrage das Angebot in einem bestimmten Fall übersteigt, also handhaben wir dies sehr sorgfältig.

Wir haben ein Compliance-Ziel von X festgelegt (z. B. 99,99 %), damit Funktionen alle benötigten Ressourcen ohne Konflikte in X % der Zeit abrufen können. Die Effizienz ist dann direkt proportional zum Verhältnis des X. Perzentils der Ressourcenauslastung zur durchschnittlichen Ressourcenauslastung. Intuitiv repräsentiert der Durchschnitt die Einnahmen und das X. Perzentil die Kosten. Mandantenfähigkeit ist ein leistungsstarkes Tool, um dieses Verhältnis zu reduzieren, das sich natürlich um etwa $\sqrt{N}$ verringert, wenn $N$ unkorrelierte Workloads auf einem Rechenknoten ausgeführt werden.

Und damit das funktioniert, müssen wir natürlich sicherstellen, dass die unterschiedlichen Workloads nicht alle gleichzeitig zunehmen...