Vanaf 28 oktober en volledig opgelost op 31 oktober, had Roblox een storing van 73 uur.¹ Vijftig miljoen spelers gebruiken Roblox elke dag regelmatig en om de ervaring te creëren die onze spelers verwachten, omvat onze schaal honderden interne online services. Zoals bij elke grootschalige service, hebben we van tijd tot tijd serviceonderbrekingen, maar de langere duur van deze storing maakt het bijzonder opmerkelijk. We bieden onze community onze oprechte excuses aan voor de downtime.

We delen deze technische details om onze gemeenschap inzicht te geven in de oorzaak van het probleem, hoe we het hebben aangepakt en wat we doen om soortgelijke problemen in de toekomst te voorkomen. We willen herhalen dat er tijdens het incident geen gebruikersgegevens verloren zijn gegaan of dat onbevoegde partijen toegang hebben gehad tot informatie.

Roblox Engineering en technisch personeel van HashiCorp hebben hun krachten gebundeld om Roblox weer in gebruik te nemen. We willen het HashiCorp-team erkennen, dat ongelooflijke middelen aan boord heeft gebracht en onvermoeibaar met ons heeft samengewerkt totdat de problemen waren opgelost.

Storingsoverzicht

De storing was uniek in zowel duur als complexiteit. Het team moest achtereenvolgens een aantal uitdagingen aanpakken om de oorzaak te begrijpen en de service weer op de rails te krijgen.

• De storing duurde 73 uur.
• De oorzaak was te wijten aan twee problemen. Het inschakelen van een relatief nieuwe streamingfunctie op Consul onder ongewoon hoge lees- en schrijfbelasting leidde tot buitensporige twist en slechte prestaties. Bovendien veroorzaakten onze specifieke belastingsomstandigheden een pathologisch prestatieprobleem in BoltDB. Het open source BoltDB-systeem wordt binnen Consul gebruikt om vooruitschrijvende logs te beheren voor de verkiezing van leiders en gegevensreplicatie. 
• Een enkele Consul-cluster die meerdere workloads ondersteunt, verergert de impact van deze problemen.
• Uitdagingen bij het diagnosticeren van deze twee voornamelijk niet-gerelateerde problemen die diep in de Consul-implementatie verborgen lagen, waren grotendeels verantwoordelijk voor de langdurige uitvaltijd. 
• Kritische monitoringsystemen die een beter inzicht in de oorzaak van de storing zouden hebben gegeven, waren afhankelijk van getroffen systemen, zoals Consul. Deze combinatie bemoeilijkte het triageproces ernstig.
• We waren attent en voorzichtig in onze aanpak om Roblox uit een uitgebreide, volledig neerwaartse staat te halen, wat ook veel tijd kostte.
• We hebben de technische inspanningen versneld om onze monitoring te verbeteren, circulaire afhankelijkheden in onze observeerbaarheidsstack te verwijderen en ons opstartproces te versnellen. 
• We werken eraan om naar meerdere beschikbaarheidszones en datacenters te verhuizen.
• We zijn bezig met het oplossen van de problemen in Consul die de oorzaak waren van deze gebeurtenis.

Preambule: onze clusteromgeving en HashiStack

De kerninfrastructuur van Roblox draait in Roblox-datacenters. We implementeren en beheren onze eigen hardware, evenals onze eigen computer-, opslag- en netwerksystemen bovenop die hardware. De schaal van onze implementatie is aanzienlijk, met meer dan 18,000 servers en 170,000 containers.

Om duizenden servers op meerdere sites te laten draaien, maken we gebruik van een technologiesuite die algemeen bekend staat als de "HashiStack. ' Nomade, Consul en Gewelf zijn de technologieën die we gebruiken om servers en services over de hele wereld te beheren, en waarmee we containers kunnen orkestreren die Roblox-services ondersteunen.

Nomade wordt gebruikt voor het plannen van werkzaamheden. Het bepaalt welke containers op welke nodes gaan draaien en op welke poorten ze toegankelijk zijn. Het valideert ook de status van de container. Al deze gegevens worden doorgestuurd naar een Service Registry, een database met IP:Poort-combinaties. Roblox-services gebruiken het serviceregister om elkaar te vinden, zodat ze kunnen communiceren. Dit proces wordt 'servicedetectie' genoemd. We gebruiken Consul voor service discovery, gezondheidscontroles, sessievergrendeling (voor HA-systemen die bovenop zijn gebouwd), en als een KV-winkel.

Consul wordt ingezet als een cluster van machines in twee rollen. "Kiezers" (5 machines) hebben gezaghebbend de status van het cluster; "Niet-stemmers" (5 extra machines) zijn alleen-lezen replica's die helpen bij het schalen van leesverzoeken. Op elk willekeurig moment wordt een van de kiezers door het cluster tot leider gekozen. De leider is verantwoordelijk voor het repliceren van gegevens naar de andere kiezers en het bepalen of geschreven gegevens volledig zijn vastgelegd. Consul gebruikt een algoritme genaamd Vlot voor leider verkiezing en om de status over het cluster te verdelen op een manier die ervoor zorgt dat elk knooppunt in het cluster akkoord gaat met de updates. Het is niet ongewoon dat de leider meerdere keren per dag door middel van leidersverkiezingen verandert.

Het volgende is een recente screenshot van een Consul-dashboard bij Roblox na het incident. Veel van de belangrijkste operationele statistieken waarnaar in deze blogpost wordt verwezen, worden op normale niveaus weergegeven. KV Apply-tijd wordt bijvoorbeeld als normaal beschouwd bij minder dan 300 ms en is op dit moment 30.6 ms. De consul-leider heeft in de afgelopen 32 ms contact gehad met andere servers in het cluster, wat zeer recent is.

1. Normale werkzaamheden van de consul in Roblox

In de maanden voorafgaand aan het incident in oktober is Roblox geüpgraded van Consul 1.9 naar Consulaat 1.10 profiteren van een nieuwe streamingfunctie. Deze streamingfunctie is ontworpen om de CPU- en netwerkbandbreedte die nodig is om updates over grootschalige clusters zoals die bij Roblox te distribueren, aanzienlijk te verminderen.

Initiële detectie (10/28 13:37)

Op de middag van 28 oktober, Vault-prestaties waren verslechterd en een enkele Consul-server had een hoge CPU-belastingD. Roblox-ingenieurs begonnen te onderzoeken. Op dit punt werden spelers niet beïnvloed.

Vroege triage (10/28 13:37 – 10/29 02:00)

Het eerste onderzoek suggereerde dat het consul-cluster waarvan Vault en vele andere services afhankelijk zijn, niet goed was. Specifiek toonden de Consul-clusterstatistieken verhoogde schrijflatentie voor de onderliggende KV-store waarin Consul gegevens opslaat. De latentie van het 50e percentiel bij deze bewerkingen was doorgaans minder dan 300 ms, maar was nu 2 seconden. Hardwareproblemen zijn niet ongebruikelijk op de schaal van Roblox en Consul kan hardwarestoringen overleven. Als hardware echter alleen maar traag is in plaats van defect, kan dit van invloed zijn op de algehele prestaties van Consul. In dit geval vermoedde het team de verslechterde hardwareprestaties als de hoofdoorzaak en begon het proces om een ​​van de Consul-clusterknooppunten te vervangen. Dit was onze eerste poging om het incident te diagnosticeren. Rond deze tijd voegden medewerkers van HashiCorp zich bij Roblox-ingenieurs om te helpen met diagnose en herstel. Alle verwijzingen naar "het team" en "het technische team" vanaf dit punt verwijzen naar zowel het personeel van Roblox als HashiCorp.

Zelfs met nieuwe hardware bleven de prestaties van het Consul-cluster eronder lijden. Om 16:35 daalde het aantal online spelers tot 50% van normaal.

2. CCU tijdens de 16:35 PST Player Drop

Deze daling viel samen met een aanzienlijke verslechtering van de systeemgezondheid, wat uiteindelijk resulteerde in een volledige systeemstoring. Waarom? Wanneer een Roblox-service met een andere service wil praten, vertrouwt deze op Consul om up-to-date kennis te hebben van de locatie van de service waarmee hij wil praten. Als Consul echter ongezond is, hebben servers moeite om verbinding te maken. Bovendien vertrouwen Nomad en Vault op Consul, dus als Consul niet in orde is, kan het systeem geen nieuwe containers plannen of productiegeheimen ophalen die voor authenticatie worden gebruikt. Kortom, het systeem faalde omdat Consul een single point of failure was en Consul niet gezond was.

Op dit punt ontwikkelde het team een ​​nieuwe theorie over wat er mis ging: meer verkeer. Misschien was Consul traag omdat ons systeem een ​​kantelpunt bereikte en de servers waarop Consul draaide de belasting niet meer aankonden? Dit was onze tweede poging om de oorzaak van het incident te diagnosticeren.

Gezien de ernst van het incident besloot het team alle nodes in het Consul-cluster te vervangen door nieuwe, krachtigere machines. Deze nieuwe machines hadden 128 cores (2x meer) en nieuwere, snellere NVME SSD-schijven. Tegen 19:00 uur migreerde het team het grootste deel van het cluster naar de nieuwe machines, maar het cluster was nog steeds niet in orde. Het cluster meldde dat een meerderheid van de knooppunten de schrijfbewerkingen niet bij kon houden, en de latentie van het 50e percentiel op KV-schrijfbewerkingen was nog steeds ongeveer 2 seconden in plaats van de typische 300 ms of minder.

Terug naar servicepoging nr. 1 (10/29 02:00 – 04:00)

De eerste twee pogingen om het consul-cluster in een gezonde staat terug te brengen, waren niet succesvol. We konden nog steeds een verhoogde KV-schrijflatentie zien, evenals een nieuw onverklaarbaar symptoom dat we niet konden verklaren: de consul-leider liep regelmatig niet synchroon met de andere kiezers. 

Het team besloot het hele Consul-cluster af te sluiten en de status opnieuw in te stellen met behulp van een momentopname van een paar uur eerder - het begin van de storing. We begrepen dat dit mogelijk zou leiden tot een kleine hoeveelheid verlies van systeemconfiguratiegegevens (niet verlies van gebruikersgegevens). Gezien de ernst van de storing en ons vertrouwen dat we deze systeemconfiguratiegegevens indien nodig handmatig zouden kunnen herstellen, vonden we dit acceptabel. 

We hadden verwacht dat het herstellen van een momentopname die is gemaakt toen het systeem in orde was, het cluster in een gezonde staat zou brengen, maar we hadden nog een extra zorg. Hoewel Roblox op dit moment geen door gebruikers gegenereerd verkeer door het systeem liet stromen, waren de interne Roblox-services nog steeds actief en plichtsgetrouw contact met Consul om de locatie van hun afhankelijkheden te leren en om hun gezondheidsinformatie bij te werken. Deze lees- en schrijfbewerkingen zorgden voor een aanzienlijke belasting van het cluster. We waren bang dat deze belasting het cluster onmiddellijk terug in een slechte staat zou brengen, zelfs als het opnieuw instellen van het cluster succesvol was. Om dit probleem aan te pakken, hebben we geconfigureerd: iptables op het cluster om de toegang te blokkeren. Dit zou ons in staat stellen om het cluster op een gecontroleerde manier terug te brengen en ons te helpen begrijpen of de belasting die we op Consul leggen, onafhankelijk van het gebruikersverkeer, een deel van het probleem was.

De reset verliep soepel en aanvankelijk zagen de statistieken er goed uit. Toen we de . verwijderden iptables block, de service discovery en health check load van de interne services geretourneerd zoals verwacht. De prestaties van de Consul begonnen echter weer te verslechteren en uiteindelijk waren we terug bij waar we begonnen: 50e percentiel op KV-schrijfbewerkingen was terug op 2 seconden. Diensten die afhankelijk waren van Consul begonnen zichzelf als 'ongezond' te bestempelen en uiteindelijk viel het systeem terug in de nu bekende problematische toestand. Het was nu 04 uur. Er was duidelijk iets met onze lading aan Consul dat problemen veroorzaakte, en meer dan 00 uur na het incident wisten we nog steeds niet wat het was.

Terug naar servicepoging #2 (10/29 04:00 – 10/30 02:00)

We hadden hardwarestoringen uitgesloten. Snellere hardware had niet geholpen en, zoals we later leerden, mogelijk de stabiliteit schaden. Het resetten van de interne toestand van Consul had ook niet geholpen. Er kwam geen gebruikersverkeer binnen, maar Consul was nog steeds traag. We hadden een hefboomwerking iptables om het verkeer langzaam terug het cluster in te laten. Werd het cluster eenvoudigweg teruggeduwd in een ongezonde toestand door het enorme volume van duizenden containers die opnieuw verbinding probeerden te maken? Dit was onze derde poging om de oorzaak van het incident te diagnosticeren.

Het engineeringteam besloot het gebruik van Consul te verminderen en het vervolgens zorgvuldig en systematisch opnieuw in te voeren. Om ervoor te zorgen dat we een schoon vertrekpunt hadden, blokkeerden we ook het resterende externe verkeer. We hebben een uitgebreide lijst samengesteld met services die Consul gebruiken en hebben configuratiewijzigingen doorgevoerd om al het niet-essentiële gebruik uit te schakelen. Dit proces nam enkele uren in beslag vanwege de grote verscheidenheid aan systemen en de beoogde configuratiewijzigingen. Roblox-services die doorgaans honderden instanties hadden, werden verkleind tot enkele cijfers. De frequentie van de gezondheidscontrole werd verlaagd van 60 seconden naar 10 minuten om het cluster extra ademruimte te geven. Op 16 oktober om 00:29 uur, meer dan 24 uur na het begin van de storing, begon het team aan zijn tweede poging om Roblox weer online te krijgen. Nogmaals, de beginfase van deze herstartpoging zag er goed uit, maar om 02:00 uur op 30 oktober was Consul opnieuw in een ongezonde toestand, dit keer met aanzienlijk minder belasting van de Roblox-services die ervan afhankelijk zijn.

Op dit punt was het duidelijk dat het algemene gebruik van Consul niet de enige factor was die bijdroeg aan de prestatievermindering die we op de 28e voor het eerst opmerkten. Met dit besef draaide het team opnieuw. In plaats van naar Consul te kijken vanuit het perspectief van de Roblox-services die ervan afhankelijk zijn, begon het team naar de interne medewerkers van Consul te kijken voor aanwijzingen.

Onderzoek naar twist (10/30 02:00 – 10/30 12:00)

In de komende 10 uur heeft het technische team dieper gegraven in foutopsporingslogboeken en meetgegevens op besturingssysteemniveau. Uit deze gegevens bleek dat de schrijfopdrachten van Consul KV gedurende lange tijd werden geblokkeerd. Met andere woorden, 'conflict'. De oorzaak van de onenigheid was niet meteen duidelijk, maar een theorie was dat de verschuiving van 64 naar 128 CPU Core-servers in het begin van de storing het probleem misschien erger had gemaakt. Na het bekijken van de htop-gegevens en prestatiefoutopsporingsgegevens die in de onderstaande schermafbeeldingen worden getoond, concludeerde het team dat het de moeite waard was om terug te gaan naar 64 Core-servers die vergelijkbaar waren met die van vóór de storing. Het team begon de hardware voor te bereiden: Consul werd geïnstalleerd, de configuraties van het besturingssysteem werden driemaal gecontroleerd en de machines werden zo gedetailleerd mogelijk klaargemaakt voor gebruik. Het team heeft vervolgens het Consul-cluster teruggezet naar 64 CPU Core-servers, maar deze wijziging heeft niet geholpen. Dit was onze vierde poging om de oorzaak van het incident te diagnosticeren.

3. We hebben dit vervolgens weergegeven met een prestatierapport zoals hierboven weergegeven. Het grootste deel van de tijd werd doorgebracht in kernel-spin-locks via het Streaming-abonnementscodepad.

4. HTOP toont CPU-gebruik over 128 cores.

Hoofdoorzaken gevonden (10/30 12:00 – 10/30 20:00)

Enkele maanden geleden hebben we een nieuwe Consul-streamingfunctie ingeschakeld voor een subset van onze services. Deze functie, ontworpen om het CPU-gebruik en de netwerkbandbreedte van het Consul-cluster te verlagen, werkte zoals verwacht, dus in de komende maanden hebben we de functie stapsgewijs ingeschakeld voor meer van onze backend-services. Op 27 oktober om 14 uur, een dag voor de storing, hebben we deze functie ingeschakeld op een backend-service die verantwoordelijk is voor verkeersroutering. Als onderdeel van deze uitrol hebben we, om ons voor te bereiden op het toegenomen verkeer dat we normaal gesproken aan het eind van het jaar zien, ook het aantal knooppunten dat verkeersroutering ondersteunt met 00% verhoogd. Het systeem werkte een dag voordat het incident begon goed met streaming op dit niveau, dus het was aanvankelijk niet duidelijk waarom de prestaties waren veranderd. Door analyse van prestatierapporten en vlamgrafieken van Consul-servers, zagen we echter aanwijzingen dat streamingcodepaden verantwoordelijk waren voor de controverse die een hoog CPU-gebruik veroorzaakte. We hebben de streamingfunctie uitgeschakeld voor alle Consul-systemen, inclusief de verkeersrouteringsknooppunten. De configuratiewijziging werd om 50:15 voltooid, waarna het 51e percentiel voor Consul KV-schrijfacties werd verlaagd naar 50 ms. Eindelijk hadden we een doorbraak.

Waarom was streamen een probleem? HashiCorp legde uit dat, hoewel streaming over het algemeen efficiënter was, het minder gelijktijdigheidscontrole-elementen (Go-kanalen) gebruikte bij de implementatie dan lange polling. Onder zeer hoge belasting - met name zowel een zeer hoge leesbelasting als een zeer hoge schrijfbelasting - verergert het ontwerp van streaming de hoeveelheid contentie op een enkel Go-kanaal, wat blokkering veroorzaakt tijdens het schrijven, waardoor het aanzienlijk minder efficiënt wordt. Dit gedrag verklaarde ook het effect van servers met een hoger aantal cores: die servers waren dual-socket-architecturen met een NUMA-geheugenmodel. De extra twist over gedeelde bronnen werd dus erger onder deze architectuur. Door streaming uit te schakelen, hebben we de gezondheid van het Consul-cluster drastisch verbeterd.

Ondanks de doorbraak waren we nog niet uit het bos. We zagen Consul met tussenpozen nieuwe clusterleiders kiezen, wat normaal was, maar we zagen ook dat sommige leiders dezelfde latentieproblemen vertoonden die we zagen voordat we streaming uitschakelden, wat niet normaal was. Zonder duidelijke aanwijzingen die wijzen op de oorzaak van het probleem met trage leiders, en met bewijs dat het cluster gezond was zolang bepaalde servers niet als leiders werden gekozen, nam het team de pragmatische beslissing om het probleem te omzeilen door het probleem te voorkomen leiders om verkozen te blijven. Hierdoor kon het team zich concentreren op het weer gezond maken van de Roblox-diensten die afhankelijk zijn van Consul.

Maar wat was er aan de hand met de trage leiders? We kwamen hier tijdens het incident niet achter, maar de technici van HashiCorp hebben de oorzaak in de dagen na de storing vastgesteld. Consul gebruikt een populaire open-source persistentiebibliotheek genaamd BoltDB om Raft-logboeken op te slaan. Het is niet gebruikt om de huidige status binnen Consul op te slaan, maar eerder een voortschrijdend logboek van de bewerkingen die worden toegepast. Om te voorkomen dat BoltDB oneindig blijft groeien, maakt Consul regelmatig snapshots. De snapshot-bewerking schrijft de huidige status van Consul naar schijf en verwijdert vervolgens de oudste logboekvermeldingen uit BoltDB. 

Vanwege het ontwerp van BoltDB, zelfs wanneer de oudste logboekvermeldingen worden verwijderd, wordt de ruimte die BoltDB op schijf gebruikt nooit kleiner. In plaats daarvan worden alle pagina's (segmenten van 4 kb in het bestand) die werden gebruikt om verwijderde gegevens op te slaan, gemarkeerd als "vrij" en opnieuw gebruikt voor volgende schrijfbewerkingen. BoltDB volgt deze gratis pagina's in een structuur die de "freelist" wordt genoemd. Meestal wordt de schrijflatentie niet significant beïnvloed door de tijd die nodig is om de freelist bij te werken, maar de werklast van Roblox bracht een pathologisch prestatieprobleem in BoltDB aan het licht dat freelist-onderhoud extreem duur maakte. 

Caching-service herstellen (10/30 20:00 – 10/31 05:00)

Het was 54 uur geleden sinds het begin van de storing. Met streaming uitgeschakeld en een proces om te voorkomen dat trage leiders verkozen blijven, was Consul nu consistent stabiel. Het team was klaar om zich te concentreren op een terugkeer naar service.

Roblox gebruikt een typisch microservices-patroon voor zijn backend. Onderaan de "stack" van microservices bevinden zich databases en caches. Deze databases werden niet beïnvloed door de storing, maar het cachingsysteem, dat tijdens de normale systeemwerking regelmatig 1 miljard verzoeken per seconde verwerkt over zijn meerdere lagen, was ongezond. Aangezien onze caches tijdelijke gegevens opslaan die gemakkelijk opnieuw kunnen worden ingevuld vanuit de onderliggende databases, was de eenvoudigste manier om het cachingsysteem weer in een gezonde staat te brengen, het opnieuw te implementeren.

Het herplaatsingsproces van de cache liep tegen een aantal problemen aan: 

1. Waarschijnlijk als gevolg van het resetten van de Consul-clustermomentopname die eerder was uitgevoerd, waren de interne planningsgegevens die het cachesysteem opslaat in de Consul KV onjuist. 
2. Implementaties van kleine caches duurden langer dan verwacht en implementaties van grote caches werden niet voltooid. Het bleek dat er een ongezond knooppunt was dat de taakplanner als volledig open in plaats van ongezond beschouwde. Dit resulteerde in een poging van de taakplanner om cachetaken op dit knooppunt agressief te plannen, wat mislukte omdat het knooppunt niet in orde was. 
3. De geautomatiseerde implementatietool van het cachingsysteem is gebouwd om incrementele aanpassingen te ondersteunen aan grootschalige implementaties die al op grote schaal verkeer afhandelden, niet om iteratieve pogingen om een ​​groot cluster helemaal opnieuw op te starten. 

Het team werkte de hele nacht door om deze problemen te identificeren en aan te pakken, ervoor te zorgen dat cachesystemen correct werden geïmplementeerd en om de juistheid te verifiëren. Om 05:00 op 31 oktober, 61 uur sinds het begin van de storing, hadden we een gezond Consul-cluster en een gezond caching-systeem. We waren klaar om de rest van Roblox ter sprake te brengen.

De terugkeer van spelers (10/31 05:00 – 10/31 16:00)

De laatste fase van terugkeer naar service begon officieel om 05:00 uur op de 31e. Net als bij het caching-systeem was een aanzienlijk deel van de actieve services afgesloten tijdens de eerste storing of de fasen voor probleemoplossing. Het team moest deze services opnieuw opstarten op de juiste capaciteitsniveaus en controleren of ze correct functioneerden. Dit verliep soepel en om 10 uur waren we klaar om ons open te stellen voor spelers.

Met koude caches en een systeem waar we nog steeds onzeker over waren, wilden we geen stroom verkeer die het systeem mogelijk weer in een onstabiele toestand zou kunnen brengen. Om een ​​overstroming te voorkomen, hebben we DNS-besturing gebruikt om het aantal spelers te beheren dat toegang had tot Roblox. Hierdoor konden we een bepaald percentage willekeurig geselecteerde spelers binnenlaten, terwijl anderen doorgestuurd werden naar onze statische onderhoudspagina. Elke keer dat we het percentage verhoogden, controleerden we de databasebelasting, de cacheprestaties en de algehele systeemstabiliteit. Het werk ging de hele dag door, waarbij de toegang in stappen van ongeveer 10% werd verhoogd. We hebben genoten van het zien van enkele van onze meest toegewijde spelers die ons DNS-stuurschema uitvonden en deze informatie op Twitter begonnen uit te wisselen, zodat ze 'vroege' toegang konden krijgen toen we de service weer beschikbaar maakten. Zondag om 16:45 uur, 73 uur na het begin van de storing, kreeg 100% van de spelers toegang en was Roblox volledig operationeel.

Verdere analyse en wijzigingen als gevolg van de storing

Terwijl spelers op 31 oktober mochten terugkeren naar Roblox, bleven Roblox en HashiCorp hun begrip van de storing gedurende de volgende week verfijnen. Specifieke geschillen in het nieuwe streamingprotocol werden geïdentificeerd en geïsoleerd. Terwijl HashiCorp had gebenchmarkte streaming op vergelijkbare schaal als het gebruik van Roblox, hadden ze dit specifieke gedrag niet eerder waargenomen omdat het zich manifesteerde door een combinatie van zowel een groot aantal streams als een hoge churn-snelheid. Het technische team van HashiCorp maakt nieuwe laboratoriumbenchmarks om het specifieke conflictprobleem te reproduceren en voert aanvullende schaaltests uit. HashiCorp werkt ook aan het verbeteren van het ontwerp van het streamingsysteem om twist onder extreme belasting te voorkomen en stabiele prestaties in dergelijke omstandigheden te garanderen. 

Nadere analyse van het probleem met trage leiders bracht ook de belangrijkste oorzaak aan het licht van de twee seconden durende Raft-gegevensschrijven en problemen met clusterconsistentie. Ingenieurs keken naar vlamgrafieken zoals hieronder om een ​​beter begrip te krijgen van de interne werking van BoltDB.

5. Analyse van Freelist-operaties van BoltDB.

Zoals eerder vermeld, gebruikt Consul een persistentiebibliotheek genaamd BoltDB om Raft-loggegevens op te slaan. Vanwege een specifiek gebruikspatroon dat tijdens het incident werd gecreëerd, werden schrijfbewerkingen van 16 kB in plaats daarvan veel groter. U kunt het probleem geïllustreerd zien in deze schermafbeeldingen:

6. Gedetailleerde BoldDB-statistieken gebruikt in analyse.

De voorgaande opdrachtuitvoer vertelt ons een aantal dingen:

• Deze logopslag van 4.2 GB slaat slechts 489 MB aan werkelijke gegevens op (inclusief alle interne indexen). 3.8 GB is "lege" ruimte.
• De vrije lijst is 7.8 MB omdat het bijna een miljoen gratis pagina-ID's bevat.

Dat betekent dat voor elke log-toevoeging (elke Raft-schrijfactie na wat batchverwerking), er ook een nieuwe 7.8 MB vrije lijst naar schijf werd geschreven, hoewel de feitelijke onbewerkte gegevens die werden toegevoegd 16 kB of minder waren. 

Tegendruk op deze bewerkingen zorgde ook voor volledige TCP-buffers en droeg bij tot 2-3s schrijftijden op ongezonde leiders. Onderstaande afbeelding toont onderzoek naar TCP Zero Windows tijdens het incident.

7. Onderzoek naar TCP zero windows. Wanneer de buffer van een TCP-ontvanger vol begint te raken, kan deze het ontvangstvenster verkleinen. Als het vol is, kan het het venster tot nul herleiden, wat de TCP-afzender vertelt om te stoppen met verzenden.

HashiCorp en Roblox hebben een proces ontwikkeld en geïmplementeerd met behulp van bestaande BoltDB-tooling om de database te "compacteren", waardoor de prestatieproblemen zijn opgelost.

Recente verbeteringen en toekomstige stappen

De storing is nu 2.5 maand geleden. Wat hebben we uitgespookt? We hebben deze tijd gebruikt om zoveel mogelijk te leren van de storing, om technische prioriteiten aan te passen op basis van wat we hebben geleerd, en om onze systemen agressief te versterken. Een van onze Roblox-waarden is Respect The Community, en hoewel we eerder een bericht hadden kunnen plaatsen om uit te leggen wat er is gebeurd, vonden we dat we het aan jou, onze community, verplicht waren om aanzienlijke vooruitgang te boeken bij het verbeteren van de betrouwbaarheid van onze systemen voordat we het publiceren. 

De volledige lijst met voltooide verbeteringen en verbeteringen aan de betrouwbaarheid tijdens de vlucht is te lang en te gedetailleerd voor dit artikel, maar hier zijn de belangrijkste punten:

Telemetrie verbeteringen

Er was een cirkelvormige afhankelijkheid tussen onze telemetriesystemen en Consul, wat betekende dat toen Consul ongezond was, we de telemetriegegevens misten die het voor ons gemakkelijker zouden hebben gemaakt om erachter te komen wat er mis was. We hebben deze circulaire afhankelijkheid verwijderd. Onze telemetriesystemen zijn niet langer afhankelijk van de systemen waarvoor ze zijn geconfigureerd om te bewaken.

We hebben onze telemetriesystemen uitgebreid om beter inzicht te krijgen in de prestaties van Consul en BoltDB. We ontvangen nu zeer gerichte waarschuwingen als er tekenen zijn dat het systeem de status nadert die deze storing heeft veroorzaakt. We hebben ook onze telemetriesystemen uitgebreid om meer inzicht te krijgen in de verkeerspatronen tussen Roblox-services en Consul. Dit extra inzicht in het gedrag en de prestaties van ons systeem op meerdere niveaus heeft ons al geholpen tijdens systeemupgrades en foutopsporingssessies.

Uitbreiding naar meerdere beschikbaarheidszones en datacenters

Door alle Roblox-backend-services op één Consul-cluster te draaien, werden we blootgesteld aan een dergelijke storing. We hebben de servers en netwerken al uitgebouwd voor een extra, geografisch onderscheiden datacenter dat onze backend-services zal hosten. We zijn bezig met het verplaatsen naar meerdere beschikbaarheidszones binnen deze datacenters; we hebben belangrijke wijzigingen aangebracht in onze technische roadmap en onze personeelsplannen om deze inspanningen te versnellen.

Consul-upgrades en sharding

Roblox groeit nog steeds snel, dus zelfs met meerdere Consul-clusters willen we de belasting die we op Consul leggen verminderen. We hebben bekeken hoe onze diensten de KV-winkel en gezondheidscontroles van Consul gebruiken, en hebben een aantal kritieke diensten opgesplitst in hun eigen specifieke clusters, waardoor de belasting van ons centrale consul-cluster naar een veiliger niveau is teruggebracht.

Sommige kernservices van Roblox gebruiken de KV-winkel van Consul rechtstreeks als een handige plek om gegevens op te slaan, ook al hebben we andere opslagsystemen die waarschijnlijk meer geschikt zijn. We zijn bezig met het migreren van deze gegevens naar een geschikter opslagsysteem. Eenmaal voltooid, zal dit ook de belasting van Consul verminderen.

We ontdekten een grote hoeveelheid verouderde KV-gegevens. Het verwijderen van deze verouderde gegevens verbeterde de prestaties van Consul.

We werken nauw samen met HashiCorp om een ​​nieuwe versie van Consul te implementeren die BoltDB vervangt door een opvolger genaamd bbolt dat heeft niet hetzelfde probleem met onbegrensde freelist-groei. We hebben deze inspanning met opzet uitgesteld naar het nieuwe jaar om een ​​complexe upgrade tijdens ons drukke eindejaarsverkeer te voorkomen. De upgrade wordt nu getest en zal in Q1 worden voltooid.

Verbeteringen aan opstartprocedures en configuratiebeheer

De terugkeer naar service-inspanningen werd vertraagd door een aantal factoren, waaronder de inzet en opwarming van caches die nodig zijn voor Roblox-services. We ontwikkelen nieuwe tools en processen om dit proces meer geautomatiseerd en minder foutgevoelig te maken. We hebben met name onze cache-implementatiemechanismen opnieuw ontworpen om ervoor te zorgen dat we ons cachesysteem snel kunnen opstarten vanuit een staande start. De uitvoering hiervan is aan de gang.

We hebben met HashiCorp samengewerkt om verschillende Nomad-verbeteringen te identificeren die het voor ons gemakkelijker zullen maken om grote opdrachten te vinden na een lange periode van onbeschikbaarheid. Deze verbeteringen zullen worden geïmplementeerd als onderdeel van onze volgende Nomad-upgrade, die later deze maand gepland staat.

We hebben mechanismen ontwikkeld en geïmplementeerd voor snellere wijzigingen in de machineconfiguratie.

Herintroductie van streaming

Oorspronkelijk hebben we streaming geïmplementeerd om het CPU-gebruik en de netwerkbandbreedte van het Consul-cluster te verlagen. Zodra een nieuwe implementatie op onze schaal met onze werklast is getest, verwachten we deze zorgvuldig opnieuw in onze systemen te introduceren.

Een opmerking over de openbare cloud

In de nasleep van een storing als deze, is het normaal om te vragen of Roblox zou overwegen om naar de openbare cloud te verhuizen en een derde partij onze fundamentele reken-, opslag- en netwerkdiensten te laten beheren.

Een andere van onze Roblox-waarden is Take The Long View, en deze waarde bepaalt in hoge mate onze besluitvorming. We bouwen en beheren onze eigen fundamentele infrastructuur op locatie, omdat we geloven dat dit op onze huidige schaal, en nog belangrijker, de schaal waarvan we weten dat we ze zullen bereiken naarmate ons platform groeit, de beste manier is om ons bedrijf en onze gemeenschap te ondersteunen. Door onze eigen datacenters voor backend- en netwerkedgeservices te bouwen en te beheren, hebben we de kosten aanzienlijk kunnen beheersen in vergelijking met de openbare cloud. Deze besparingen hebben direct invloed op het bedrag dat we kunnen betalen aan makers op het platform. Bovendien stelt het bezit van onze eigen hardware en het bouwen van onze eigen edge-infrastructuur ons in staat om prestatievariaties te minimaliseren en de latentie van onze spelers over de hele wereld zorgvuldig te beheren. Consistente prestaties en lage latentie zijn van cruciaal belang voor de ervaring van onze spelers, die zich niet noodzakelijkerwijs in de buurt van de datacenters van openbare cloudproviders bevinden.

Merk op dat we niet ideologisch gebonden zijn aan een bepaalde benadering: we gebruiken de openbare cloud voor gebruikssituaties waar dit het meest logisch is voor onze spelers en ontwikkelaars. Als voorbeelden gebruiken we de openbare cloud voor burst-capaciteit, grote delen van onze DevOps-workflows en de meeste van onze interne analyses. Over het algemeen vinden we public cloud een goede tool voor applicaties die niet prestatie- en latency-kritisch zijn en die op beperkte schaal draaien. Voor onze meest prestatie- en latentiekritieke workloads hebben we er echter voor gekozen om onze eigen infrastructuur on-prem te bouwen en te beheren. We hebben deze keuze gemaakt in de wetenschap dat het tijd, geld en talent kost, maar ook in de wetenschap dat we hiermee een beter platform kunnen bouwen. Dit komt overeen met onze Take The Long View-waarde.

Systeemstabiliteit sinds de storing

Roblox krijgt eind december meestal een golf van verkeer. We hebben nog veel meer betrouwbaarheidswerk te doen, maar we zijn verheugd te kunnen melden dat Roblox tijdens de piek in december geen enkel significant productie-incident heeft gehad en dat de prestaties en stabiliteit van zowel Consul als Nomad tijdens deze piek waren uitstekend. Het lijkt erop dat onze onmiddellijke betrouwbaarheidsverbeteringen al vruchten afwerpen, en naarmate onze langetermijnprojecten zijn afgerond, verwachten we nog betere resultaten.

Sluiting Gedachten

We willen onze wereldwijde Roblox-gemeenschap bedanken voor hun begrip en steun. Een andere van onze Roblox-waarden is Verantwoordelijkheid nemen, en we nemen de volledige verantwoordelijkheid voor wat hier is gebeurd. We willen nogmaals onze oprechte dank betuigen aan het team van HashiCorp. Hun ingenieurs sprongen in om ons te helpen bij het begin van deze ongekende storing en week niet van onze zijde. Zelfs nu, met de storing enkele weken achter ons, blijven de technici van Roblox en HashiCorp nauw samenwerken om ervoor te zorgen dat we er gezamenlijk alles aan doen om te voorkomen dat een soortgelijke storing ooit nog eens voorkomt.

Ten slotte willen we onze Roblox-collega's bedanken voor het valideren waarom dit een geweldige plek is om te werken. Bij Roblox geloven we in beleefdheid en respect. Het is gemakkelijk om beleefd en respectvol te zijn als het goed gaat, maar de echte test is hoe we elkaar behandelen als het moeilijk wordt. Op een bepaald moment tijdens een storing van 73 uur, terwijl de klok tikt en de stress toeneemt, zou het niet verwonderlijk zijn om iemand zijn kalmte te zien verliezen, iets respectloos te zeggen of zich hardop af te vragen wiens schuld dit allemaal was. Maar dat is niet wat er is gebeurd. We steunden elkaar en we werkten de klok rond als één team samen tot de dienst gezond was. We zijn natuurlijk niet trots op deze storing en de impact die het had op onze gemeenschap, maar we zijn trots op hoe we als een team zijn samengekomen om Roblox weer tot leven te brengen, en hoe we elkaar bij elke stap met beleefdheid en respect hebben behandeld.

We hebben enorm veel geleerd van deze ervaring en we zijn meer dan ooit toegewijd om van Roblox in de toekomst een sterker en betrouwbaarder platform te maken.

Nogmaals bedankt. 

¹ Merk op dat alle datums en tijd in deze blogpost in Pacific Standard Time (PST) zijn.

Source: https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/