Geführt seit Oktober 2019

Die Bereitstellungswarteschlange neu schreiben

Die mittlere Zeit von der Zahlung bis zu den Root-Zugangsdaten sank von drei Minuten und zwanzig Sekunden auf siebenundvierzig Sekunden. Der größte Teil der Verbesserung stammt aus Arbeit, die erledigt wurde, bevor die Bestellung existierte.

Fünf Jahre lang dauerte der Kauf eines Servers hier im Median drei Minuten und zwanzig Sekunden vom Settlement-Webhook bis zu den Zugangsdaten in Ihrem Posteingang. Niemand beschwerte sich. Das war schneller als der Großteil der Branche und erheblich schneller als alles, bei dem ein Mensch Sie genehmigen musste.

Es waren auch vier serielle Schritte, die nichts Serielles zu suchen hatten, und wenn man das erst einmal bemerkt, kann man nicht mehr aufhören, es zu bemerken. Die Neufassung wurde im März ausgerollt und der Median liegt jetzt bei siebenundvierzig Sekunden, mit dem 95. Perzentil knapp unter vier Minuten.

Was die alte Version tat

SchrittMedianWas geschah
Image-Kopie84 sEin Disk-Image aus einem pro-Standort-Speicher auf den Zielknoten ziehen
Volume-Erstellung31 sNVMe-Volume zuweisen und formatieren
Adressvergabe46 sEine Sperre auf dem standortweiten Adresspool nehmen, eine IPv4 wählen, Reverse-DNS schreiben
Erster Start und Cloud-Init39 sSchlüssel generieren, Dateisystem erweitern, E-Mail senden

Vier Schritte, ein globaler Worker-Pool und eine Sperre auf dem Adresspool, hinter der sich jede Bestellung am selben Standort anstellen musste. An einem ruhigen Dienstag war das in Ordnung. Während einer Aktion oder in der Stunde nachdem ein großer Kunde per Skript vierzig Erstellungen ausgelöst hatte, verdoppelte sich der Median und das Ende der Verteilung ging über zwölf Minuten hinaus.

Was wir geändert haben

Images werden vorab angelegt, nicht kopiert. Jeder Knoten hält einen Thin-Clone-Base für jedes Image im Katalog, der nächtlich aktualisiert wird. Das Erstellen eines Volumes ist jetzt ein Copy-on-Write-Klon gegen ein lokales Gen4-NVMe-Spiegelbild und kein Netzwerk-Pull. Dieser Schritt ging von vierundachtzig Sekunden auf unter zwei Sekunden zurück.

Adressen werden im Voraus reserviert. Jeder Standort hält einen warmen Pool an zugewiesenen Adressen mit bereits geschriebenem Reverse-DNS, der auf etwa sechs Stunden Bedarf an diesem Standort ausgelegt ist. Die Zuweisung ist jetzt ein Pop aus einem vorgebauten Pool statt einer Sperre, eines Scans und eines DNS-Scheibens. Sechsundvierzig Sekunden wurden zu etwa vierhundert Millisekunden.

Warteschlangen sind pro Standort. Ein Ansturm in Frankfurt verlangsamt keine Erstellung in São Paulo, was offensichtlich klingt und nicht das ursprüngliche Design war, weil das ursprüngliche Design vier Standorte und einen Ingenieur hatte.

Worker sind idempotent und fortsetzbar. Jeder Schritt ist schlüsselbasiert, sodass ein sterbender Worker einen fortsetzbaren Auftrag hinterlässt, statt einer halb gebauten Instanz und eines Support-Tickets. Manuelle Eingriffe bei fehlgeschlagenen Erstellungen fielen von etwa einem Auftrag von vierhundert auf einen von neuntausend.

Das Ergebnis

MetrikVorherNachher
Median3 min 20 s47 s
95. Perzentil12 min 10 s3 min 56 s
99. Perzentil41 min8 min 20 s
Fehlgeschlagene Erstellungen, die einen Menschen brauchen1 von 4001 von 9.000
Gleichzeitige Erstellungen pro Standort, bevor der Median sich bewegt690

Was unterwegs schiefging

Im März schlug die nächtliche Aktualisierung der Thin-Clone-Bases an vier Standorten elf Stunden lang still fehl und das vorab angelegte Debian-Image lieferte eine Punktversion aus, die neun Tage alt war. Ungefähr neunzig Instanzen wurden daraus erstellt. Keine davon war auf interessante Weise beschädigt, da eine veraltete Punktversion nur ein Paketupdate von einer aktuellen entfernt ist, aber niemand, der einen Server kauft, sollte das überprüfen müssen.

Wir haben die betroffenen Instanzen auf Anfrage neu aufgebaut, allen neunzig per E-Mail geschrieben, ob sie es verlangt hatten oder nicht, und einen Check hinzugefügt, der den Hash des Basis-Images mit dem Katalog vergleicht, bevor ein Knoten Erstellungen bedienen darf. Ein stiller Fehler in einem nächtlichen Job ist die langweiligste mögliche Ursache, und es lohnt sich, ihn genau deshalb aufzuschreiben, weil er langweilig ist.

Was noch langsam ist

  • Benutzerdefinierte ISO-Installationen. Immer noch manuell, immer noch in Dutzenden von Minuten gemessen, normalerweise innerhalb einer Stunde erledigt. Der Engpass ist eine Person, die bestätigt, dass das Image das tut, was sein Hochladen behauptet.
  • Windows. Die Lizenzaktivierung dauert zwei bis drei Minuten und liegt nicht in unserer Kontrolle.
  • Bare Metal. Am selben Tag statt in derselben Minute. Eine physische Maschine hat einen physischen Wiederaufbau, und wir würden Ihnen lieber ehrlich ein Angebot machen, als eine Uhr zu starten, die wir nicht schlagen können.
  • IPv6-/48-Delegierung. An drei Standorten manuell, wo die Fabric-Konfiguration älter ist. Wird langsam behoben.

Warum wir hier aufgehört haben

Wir könnten den Median auf etwa zwanzig Sekunden senken, indem wir Instanzen vorgebootet halten und Ihnen einfach eine bei Zahlung übergeben. Das bedeutet, ungenutzte Kapazität vorzuhalten, also für Kerne zu zahlen, die niemand nutzt, also jeden ein wenig mehr zu belasten, damit neue Bestellungen elf Sekunden schneller wirken.

Siebenundvierzig Sekunden sind kurz genug, dass die Einschränkung jetzt die Kette ist, die Ihre Zahlung bestätigt, und nicht irgendetwas, das wir tun. Über den Punkt hinaus zu optimieren, an dem der Kunde es bemerkt, ist ein Hobby, keine Technik.

Bereit, wenn Sie es sind

Wählen Sie eine Stadt. Wählen Sie eine Größe. Bezahlen Sie in Coins.

Keine Formulare darüber, wer Sie sind, kein Warten auf einen Menschen, der Sie genehmigt, kein Anruf zur Verifizierung. Die Rechnung wird beglichen, und die Zugangsdaten landen in Ihrem Posteingang.