Hoe we de infrastructuur van Roblox efficiënter en veerkrachtiger maken
Naarmate Roblox de afgelopen 16 jaar is gegroeid, zijn ook de omvang en complexiteit van de technische infrastructuur die miljoenen meeslepende 3D-ervaringen ondersteunt, toegenomen. Het aantal machines dat we ondersteunen is de afgelopen twee jaar meer dan verdrievoudigd, van ongeveer 36.000 op 30 juni 2021 tot bijna 145.000 vandaag. Om deze altijd beschikbare ervaringen voor mensen over de hele wereld te ondersteunen, zijn meer dan 1.000 interne diensten nodig. Om de kosten en netwerklatentie te beheersen, implementeren en beheren we deze machines als onderdeel van een op maat gemaakte en hybride private cloudinfrastructuur die voornamelijk on-premises draait.
Onze infrastructuur ondersteunt momenteel meer dan 70 miljoen dagelijkse actieve gebruikers over de hele wereld, inclusief de makers die voor hun bedrijf afhankelijk zijn van de Roblox-economie. Al deze miljoenen mensen verwachten een zeer hoge mate van betrouwbaarheid. Gezien het meeslepende karakter van onze ervaringen is er een extreem lage tolerantie voor vertragingen of latentie, laat staan voor uitval. Roblox is een platform voor communicatie en verbinding, waar mensen samenkomen in meeslepende 3D-ervaringen. Wanneer mensen als hun avatars communiceren in een meeslepende ruimte, vallen zelfs kleine vertragingen of storingen meer op dan in een tekstchat of een conferentiegesprek.
In oktober 2021 hadden we te maken met een systeemstoring. Het begon klein, met een probleem in één onderdeel van één datacenter. Maar het verspreidde zich snel terwijl we het aan het onderzoeken waren en resulteerde uiteindelijk in een storing van 73 uur. Destijds deelden we zowel details over wat er was gebeurd als enkele van onze eerste lessen die we uit het incident hadden geleerd. Sindsdien hebben we die lessen bestudeerd en gewerkt aan het vergroten van de veerkracht van onze infrastructuur tegen het soort storingen dat in alle grootschalige systemen voorkomt als gevolg van factoren zoals extreme pieken in het verkeer, het weer, hardwarefouten, softwarebugs of gewoon menselijke fouten. Hoe zorgen we ervoor dat, wanneer deze storingen zich voordoen, een probleem in één onderdeel of een groep onderdelen zich niet verspreidt naar het hele systeem? Deze vraag is de afgelopen twee jaar onze focus geweest en hoewel het werk nog gaande is, werpt wat we tot nu toe hebben gedaan al vruchten af. In de eerste helft van 2023 hebben we bijvoorbeeld 125 miljoen engagementuren per maand bespaard in vergelijking met de eerste helft van 2022. Vandaag delen we het werk dat we al hebben gedaan, evenals onze langetermijnvisie voor het bouwen van een veerkrachtiger infrastructuursysteem.
Een vangnet opbouwen
Binnen grootschalige infrastructuursystemen doen zich vele malen per dag kleinschalige storingen voor. Als één machine een probleem heeft en buiten gebruik moet worden gesteld, is dat beheersbaar omdat de meeste bedrijven meerdere instanties van hun back-enddiensten onderhouden. Dus wanneer één instantie uitvalt, nemen andere de werklast over. Om deze frequente storingen aan te pakken, worden verzoeken over het algemeen zo ingesteld dat ze automatisch opnieuw worden geprobeerd als ze een foutmelding krijgen.
Dit wordt een uitdaging wanneer een systeem of persoon te agressief opnieuw probeert, wat ertoe kan leiden dat die kleinschalige storingen zich via de infrastructuur verspreiden naar andere diensten en systemen. Als het netwerk of een gebruiker hardnekkig genoeg blijft proberen, zal dit uiteindelijk elke instantie van die dienst, en mogelijk ook andere systemen, wereldwijd overbelasten. Onze storing in 2021 was het gevolg van iets wat vrij gebruikelijk is in grootschalige systemen: een storing begint klein en verspreidt zich vervolgens door het systeem, waarbij deze zo snel groot wordt dat het moeilijk is om deze op te lossen voordat alles uitvalt.
Ten tijde van onze storing hadden we één actief datacenter (met componenten die als back-up fungeerden). We moesten handmatig kunnen overschakelen naar een nieuw datacenter wanneer een probleem het bestaande datacenter platlegde. Onze eerste prioriteit was ervoor te zorgen dat we een back-upimplementatie van Roblox hadden, dus hebben we die back-up gebouwd in een nieuw datacenter, gelegen in een andere geografische regio. Dat bood extra bescherming voor het ergste scenario: een storing die zich uitbreidt naar genoeg componenten binnen een datacenter, waardoor het volledig onbruikbaar wordt. We hebben nu één datacenter dat de werklast verwerkt (actief) en één dat stand-by staat en als back-up fungeert (passief). Ons doel op lange termijn is om van deze actieve-passieve configuratie over te stappen naar een actieve-actieve configuratie, waarbij beide datacenters de werklast verwerken, met een load balancer die verzoeken tussen beide verdeelt op basis van latentie, capaciteit en status. Zodra dit is geïmplementeerd, verwachten we een nog hogere betrouwbaarheid voor heel Roblox en de mogelijkheid om vrijwel onmiddellijk over te schakelen in plaats van binnen enkele uren.
Overstap naar een cellulaire infrastructuur
Onze volgende prioriteit was het creëren van sterke beschermingsmuren binnen elk datacenter om de kans op een totale uitval van een datacenter te verkleinen. Cellen (sommige bedrijven noemen ze clusters) zijn in wezen een set machines en vormen de manier waarop we deze muren creëren. We repliceren diensten zowel binnen als tussen cellen voor extra redundantie. Uiteindelijk willen we dat alle diensten bij Roblox in cellen draaien, zodat ze kunnen profiteren van zowel sterke beschermingsmuren als redundantie. Als een cel niet langer functioneert, kan deze veilig worden gedeactiveerd. Door replicatie tussen cellen kan de dienst blijven draaien terwijl de cel wordt gerepareerd. In sommige gevallen kan het repareren van een cel betekenen dat de cel volledig opnieuw moet worden ingericht. In de branche is het vrij gebruikelijk om een individuele machine of een kleine groep machines te wissen en opnieuw in te richten, maar dit is niet gebruikelijk voor een hele cel, die ongeveer 1.400 machines bevat.
Om dit te laten werken, moeten deze cellen grotendeels uniform zijn, zodat we workloads snel en efficiënt van de ene cel naar de andere kunnen verplaatsen. We hebben bepaalde vereisten vastgesteld waaraan services moeten voldoen voordat ze in een cel draaien. Services moeten bijvoorbeeld gecontaineriseerd zijn, wat ze veel draagbaarder maakt en voorkomt dat iemand configuratiewijzigingen op OS-niveau aanbrengt. We hanteren een 'infrastructure-as-code'-filosofie voor cellen: in onze broncoderepository nemen we de definitie op van alles wat zich in een cel bevindt, zodat we deze snel vanaf nul kunnen herbouwen met behulp van geautomatiseerde tools.
Niet alle services voldoen momenteel aan deze vereisten, dus hebben we ernaar gestreefd om service-eigenaren te helpen hieraan te voldoen waar mogelijk, en hebben we nieuwe tools gebouwd om het eenvoudig te maken services naar cellen te migreren wanneer ze er klaar voor zijn. Onze nieuwe implementatietool verdeelt bijvoorbeeld automatisch de implementatie van een service over cellen, zodat service-eigenaren niet hoeven na te denken over de replicatiestrategie. Dit strenge niveau maakt het migratieproces veel uitdagender en tijdrovender, maar het voordeel op de lange termijn is een systeem waarin:
- Het veel gemakkelijker is om een storing in te dammen en te voorkomen dat deze zich naar andere cellen verspreidt;
- Onze infrastructuuringenieurs efficiënter kunnen werken en sneller kunnen handelen; en
- De engineers die de diensten op productniveau bouwen die uiteindelijk in cellen worden geïmplementeerd, hoeven niet te weten of zich zorgen te maken over in welke cellen hun diensten draaien.
Grotere uitdagingen oplossen
Net zoals branddeuren worden gebruikt om vlammen in te dammen, fungeren cellen als sterke explosiewanden binnen onze infrastructuur om te helpen bij het indammen van elk probleem dat een storing binnen een enkele cel veroorzaakt. Uiteindelijk zullen alle diensten waaruit Roblox bestaat redundant worden ingezet binnen en tussen cellen. Zodra dit werk is voltooid, kunnen problemen zich nog steeds zo ver verspreiden dat een hele cel onbruikbaar wordt, maar het zou uiterst moeilijk zijn voor een probleem om zich buiten die cel te verspreiden. En als we erin slagen cellen onderling uitwisselbaar te maken, zal het herstel aanzienlijk sneller verlopen omdat we kunnen overschakelen naar een andere cel en zo kunnen voorkomen dat het probleem gevolgen heeft voor eindgebruikers.
Waar dit lastig wordt, is het voldoende scheiden van deze cellen om de kans op verspreiding van fouten te verminderen, terwijl we de prestaties en functionaliteit behouden. In een complex infrastructuursysteem moeten services met elkaar communiceren om query's, informatie, workloads, enz. te delen. Terwijl we deze services naar cellen repliceren, moeten we goed nadenken over hoe we de onderlinge communicatie beheren. In een ideale wereld leiden we het verkeer van één ongezonde cel om naar andere gezonde cellen. Maar hoe gaan we om met een 'query of death' – een query die ervoor zorgt dat een cel ongezond wordt? Als we die query omleiden naar een andere cel, kan dat ertoe leiden dat die cel ongezond wordt, precies wat we proberen te voorkomen. We moeten mechanismen vinden om 'goed' verkeer weg te leiden van ongezonde cellen, terwijl we het verkeer dat ervoor zorgt dat cellen ongezond worden, detecteren en onderdrukken.
Op korte termijn hebben we kopieën van computerdiensten in elke rekencel geïmplementeerd, zodat de meeste verzoeken aan het datacenter door één enkele cel kunnen worden afgehandeld. We zorgen ook voor load balancing van het verkeer over de cellen heen. Op langere termijn zijn we begonnen met het bouwen van een service discovery-proces van de volgende generatie dat zal worden ingezet door een service mesh, dat we hopen te voltooien in 2024. Dit stelt ons in staat om geavanceerde beleidsregels te implementeren die communicatie tussen cellen alleen toestaan wanneer dit geen negatieve invloed heeft op de failover-cellen. Ook komt er in 2024 een methode om afhankelijke verzoeken naar een serviceversie in dezelfde cel te leiden, wat het verkeer tussen cellen minimaliseert en daarmee het risico op het verspreiden van storingen tussen cellen vermindert.
Op piekmomenten wordt meer dan 70 procent van ons back-end-servicetrffic buiten de cellen verwerkt en we hebben veel geleerd over het aanmaken van cellen, maar we verwachten dat er nog meer onderzoek en testen nodig zullen zijn naarmate we onze services blijven migreren tot 2024 en daarna. Naarmate we vorderen, zullen deze beschermingsmuren steeds sterker worden.
Migreren van een altijd-aan-infrastructuur
Roblox is een wereldwijd platform dat gebruikers over de hele wereld ondersteunt, dus we kunnen diensten niet verplaatsen tijdens daluren of 'downtime', wat het proces van het migreren van al onze machines naar cellen en onze diensten die in die cellen draaien nog ingewikkelder maakt. We hebben miljoenen 'always-on'-ervaringen die ondersteund moeten blijven worden, zelfs terwijl we de machines waarop ze draaien en de diensten die ze ondersteunen verplaatsen. Toen we met dit proces begonnen, hadden we geen tienduizenden machines die ongebruikt stonden en beschikbaar waren om deze workloads naar te migreren.
We hadden echter wel een klein aantal extra machines die waren aangeschaft in afwachting van toekomstige groei. Om te beginnen bouwden we nieuwe cellen met behulp van die machines en migreerden we vervolgens workloads daarheen. We hechten zowel waarde aan efficiëntie als aan betrouwbaarheid, dus in plaats van nieuwe machines aan te schaffen toen onze 'reserve'-machines opraakten, bouwden we meer cellen door de machines waar we de workloads vanaf hadden gemigreerd te wissen en opnieuw in te richten. Vervolgens migreerden we workloads naar die opnieuw ingerichte machines en begonnen we het proces helemaal opnieuw. Dit proces is complex: wanneer machines worden vervangen en vrijkomen om in cellen te worden ingebouwd, komen ze niet op een ideale, ordelijke manier vrij. Ze zijn fysiek verspreid over datahallen, waardoor we ze stukje bij beetje moeten inrichten. Dit vereist een defragmentatieproces op hardwareniveau om de hardwarelocaties afgestemd te houden op grootschalige fysieke faaldomeinen.
Een deel van ons infrastructuurteam richt zich op het migreren van bestaande workloads vanuit onze legacy-omgeving, of 'pre-cell'-omgeving, naar cellen. Dit werk gaat door totdat we duizenden verschillende infrastructuurdiensten en duizenden backend-diensten hebben gemigreerd naar nieuw gebouwde cellen. We verwachten dat dit het hele komende jaar in beslag zal nemen en mogelijk tot in 2025, vanwege enkele complicerende factoren. Ten eerste vereist dit werk de ontwikkeling van robuuste tools. We hebben bijvoorbeeld tools nodig om automatisch grote aantallen services opnieuw te balanceren wanneer we een nieuwe cel implementeren – zonder dat dit gevolgen heeft voor onze gebruikers. We hebben ook services gezien die zijn gebouwd op basis van aannames over onze infrastructuur. We moeten deze services herzien, zodat ze niet afhankelijk zijn van zaken die in de toekomst kunnen veranderen naarmate we overgaan op cellen. We hebben ook een manier geïmplementeerd om te zoeken naar bekende ontwerppatronen die niet goed werken met cellulaire architectuur, evenals een methodisch testproces voor elke gemigreerde service. Deze processen helpen ons om eventuele gebruikersproblemen te voorkomen die worden veroorzaakt doordat een service niet compatibel is met cellen.
Op dit moment worden bijna 30.000 machines beheerd door cellen. Dat is slechts een fractie van ons totale machinepark, maar de overgang is tot nu toe zeer soepel verlopen, zonder negatieve gevolgen voor de spelers. Ons uiteindelijke doel is dat onze systemen elke maand een uptime van 99,99 procent voor gebruikers bereiken, wat betekent dat we niet meer dan 0,01 procent van de engagementuren zouden verstoren. In de hele sector kan downtime niet volledig worden geëlimineerd, maar ons doel is om elke downtime van Roblox te verminderen tot een niveau dat bijna onmerkbaar is.
Toekomstbestendig blijven terwijl we opschalen
Hoewel onze eerste inspanningen succesvol blijken te zijn, is ons werk aan cellen nog lang niet afgerond. Naarmate Roblox blijft opschalen, zullen we blijven werken aan het verbeteren van de efficiëntie en veerkracht van onze systemen door middel van deze en andere technologieën. Gaandeweg zal het platform steeds beter bestand zijn tegen problemen, en eventuele problemen die zich voordoen, zouden steeds minder zichtbaar en verstorend moeten worden voor de mensen op ons platform.
Samenvattend hebben we tot nu toe:
- Een tweede datacenter gebouwd en met succes de actieve/passieve status bereikt.
- Cellen gecreëerd in onze actieve en passieve datacenters en met succes meer dan 70 procent van ons back-end-servicetrffic naar deze cellen gemigreerd.
- De vereisten en best practices vastgesteld die we moeten volgen om alle cellen uniform te houden terwijl we doorgaan met het migreren van de rest van onze infrastructuur.
- Een continu proces in gang gezet om sterkere "blast walls" tussen cellen te bouwen.
Naarmate deze cellen meer uitwisselbaar worden, zal er minder crosstalk tussen de cellen zijn. Dit biedt ons een aantal zeer interessante mogelijkheden op het gebied van het vergroten van de automatisering rond monitoring, troubleshooting en zelfs het automatisch verschuiven van workloads.
In september zijn we ook begonnen met het uitvoeren van active/active-experimenten in onze datacenters. Dit is een ander mechanisme dat we testen om de betrouwbaarheid te verbeteren en failover-tijden te minimaliseren. Deze experimenten hielpen bij het identificeren van een aantal systeemontwerppatronen, voornamelijk rond gegevenstoegang, die we moeten herzien terwijl we toewerken naar volledig active-active. Over het algemeen was het experiment succesvol genoeg om het te laten draaien voor het verkeer van een beperkt aantal van onze gebruikers.
