How We’re Making Roblox’s Infrastructure More Efficient And Resilient - Roblox Blog

Taasavaldanud Platon

järgijaid: 0

Kuna Roblox on viimase 16+ aasta jooksul kasvanud, on kasvanud ka miljoneid ümbritsevaid 3D-kooskogemusi toetava tehnilise infrastruktuuri ulatus ja keerukus. Meie toetatavate masinate arv on viimase kahe aasta jooksul enam kui kolmekordistunud, ligikaudu 36,000 30-lt 2021. juuni 145,000 seisuga ligi 1,000 XNUMX-le tänaseks. Nende pidevate kasutuskogemuste toetamine inimestele üle kogu maailma nõuab enam kui XNUMX siseteenust. Kulude ja võrgu latentsusaega kontrolli all hoidmiseks juurutame ja haldame neid masinaid osana kohandatud ja hübriidsest privaatsest pilveinfrastruktuurist, mis töötab peamiselt ruumides.

Meie infrastruktuur toetab praegu enam kui 70 miljonit igapäevast aktiivset kasutajat üle maailma, sealhulgas loojaid, kes loodavad Robloxi majandus nende ettevõtete jaoks. Kõik need miljonid inimesed ootavad väga kõrget usaldusväärsust. Arvestades meie kogemuste kõikehõlmavat olemust, on viivituste või latentsuse, rääkimata katkestustest, suhtes äärmiselt madal tolerants. Roblox on suhtlemise ja ühenduse loomise platvorm, kus inimesed saavad kokku kaasahaarava 3D-kogemuse saamiseks. Kui inimesed suhtlevad ümbritsevas ruumis avataridena, on isegi väikesed viivitused või tõrked märgatavamad kui tekstilõime või konverentskõne puhul.

2021. aasta oktoobris kogesime kogu süsteemi hõlmavat katkestust. See algas väikeselt, ühes andmekeskuses oli probleem ühes komponendis. Kuid see levis uurimise ajal kiiresti ja lõppes 73-tunnise katkestusega. Sel ajal jagasime mõlemat üksikasju juhtunu kohta ja mõned meie varajased õpingud sellest probleemist. Sellest ajast alates oleme uurinud neid teadmisi ja töötanud selle nimel, et suurendada oma infrastruktuuri vastupidavust sellistele tõrgetele, mis esinevad kõigis suuremahulistes süsteemides selliste tegurite tõttu nagu äärmuslikud liikluse hüpped, ilm, riistvararikked, tarkvaravead või lihtsalt. inimesed teevad vigu. Kui need tõrked ilmnevad, kuidas tagada, et probleem ühes komponendis või komponentide rühmas ei leviks kogu süsteemile? See küsimus on olnud meie tähelepanu keskmes viimased kaks aastat ja kuigi töö käib, tasub seni tehtu end ära. Näiteks hoidsime 2023. aasta esimesel poolel kokku 125 miljonit kaasamistundi kuus võrreldes 2022. aasta esimese poolega. Täna jagame juba tehtud tööd ja oma pikemaajalist visiooni ehitamiseks. vastupidavam infrastruktuurisüsteem.

Backstopi ehitamine

Suuremahulistes infrastruktuurisüsteemides juhtub väikesemahulisi tõrkeid mitu korda päevas. Kui ühel masinal on probleem ja see tuleb kasutusest kõrvaldada, on see hallatav, kuna enamik ettevõtteid haldab oma taustateenuste mitut eksemplari. Nii et kui üks eksemplar ebaõnnestub, võtavad töökoormuse teised. Nende sagedaste tõrgete lahendamiseks seatakse päringud tavaliselt tõrke ilmnemisel automaatselt uuesti proovima.

See muutub keeruliseks, kui süsteem või inimene proovib uuesti liiga agressiivselt, mis võib muutuda viisiks, kuidas väikesed tõrked levivad kogu infrastruktuuri kaudu teistele teenustele ja süsteemidele. Kui võrk või kasutaja proovib piisavalt pidevalt uuesti, koormab see lõpuks selle teenuse kõiki eksemplare ja potentsiaalselt ka teisi süsteeme globaalselt. Meie 2021. aasta katkestus oli tingitud millestki, mis on suuremahulistes süsteemides üsna tavaline: rike algab väikesest, seejärel levib läbi süsteemi, muutudes nii kiiresti suureks, et seda on raske lahendada enne, kui kõik kaob.

Katkestuse ajal oli meil üks aktiivne andmekeskus (selles olevad komponendid toimisid varukoopiana). Vajasime võimalust käsitsi uude andmekeskusesse üle minna, kui probleem olemasoleva andmekeskuse alla tõmbas. Meie esimene prioriteet oli tagada, et meil oleks Robloxi varukoopia, nii et ehitasime selle varukoopia uude andmekeskusesse, mis asub teises geograafilises piirkonnas. See lisas kaitset halvima stsenaariumi korral: katkestus levib andmekeskuses piisavalt paljudele komponentidele, nii et see muutub täielikult töövõimetuks. Meil on nüüd üks andmekeskus, mis käsitleb töökoormust (aktiivne) ja üks ooterežiimis, mis toimib varukoopiana (passiivne). Meie pikaajaline eesmärk on liikuda sellelt aktiivselt-passiivselt konfiguratsioonilt aktiivsele-aktiivsele konfiguratsioonile, kus mõlemad andmekeskused tegelevad töökoormusega, kusjuures koormuse tasakaalustaja jaotab päringud nende vahel latentsuse, võimsuse ja seisukorra alusel. Kui see on paigas, ootame kogu Robloxi veelgi suuremat töökindlust ja suutma ebaõnnestuda peaaegu hetkega, mitte mitme tunni jooksul.

Mobiilside infrastruktuurile üleminek

Meie järgmiseks prioriteediks oli luua igas andmekeskuses tugevad plahvatusseinad, et vähendada terve andmekeskuse ülesütlemise võimalust. Rakud (mõned ettevõtted nimetavad neid klastriteks) on sisuliselt masinate kogum ja nende abil me neid seinu loome. Kopeerime teenuseid nii rakkude sees kui ka nende vahel, et suurendada koondamist. Lõppkokkuvõttes tahame, et kõik Robloxi teenused töötaksid lahtrites, et nad saaksid kasu nii tugevatest plahvatusseintest kui ka koondamisest. Kui lahter enam ei tööta, saab selle ohutult deaktiveerida. Rakkudevaheline replikatsioon võimaldab teenusel lahtri parandamise ajal töötada. Mõnel juhul võib rakkude parandamine tähendada raku täielikku ümberpaigutamist. Kogu tööstusharu puhul on üksiku masina või väikese masinakomplekti pühkimine ja ümberkorraldamine üsna tavaline, kuid seda ei tehta terve raku jaoks, mis sisaldab ~1,400 masinat.

Selle toimimiseks peavad need lahtrid olema suures osas ühtsed, et saaksime töökoormust kiiresti ja tõhusalt ühest lahtrist teise teisaldada. Oleme seadnud teatud nõuded, millele teenused peavad vastama, enne kui need lahtris töötavad. Näiteks peavad teenused olema konteineris, mis muudab need palju kaasaskantavamaks ja takistab kellelgi OS-i tasemel konfiguratsioonimuudatusi tegemast. Oleme rakkude jaoks kasutusele võtnud taristu koodina filosoofia: oma lähtekoodihoidlasse lisame lahtris leiduva määratluse, et saaksime selle automaatsete tööriistade abil kiiresti nullist üles ehitada.

Kõik teenused ei vasta praegu nendele nõuetele, seega oleme töötanud selle nimel, et aidata teenuste omanikel neid võimaluse korral täita, ning oleme loonud uusi tööriistu, et hõlbustada teenuste üleminekut lahtritesse, kui need on valmis. Näiteks meie uus juurutustööriist "triibutab" teenuse juurutamise automaatselt üle rakkude, nii et teenuse omanikud ei pea mõtlema replikatsioonistrateegiale. Selline ranguse tase muudab migratsiooniprotsessi palju keerulisemaks ja aeganõudvamaks, kuid pikaajaline tasuvus on süsteem, kus:

Palju lihtsam on rikkeid ohjeldada ja vältida selle levikut teistesse rakkudesse;
Meie taristuinsenerid võivad olla tõhusamad ja liikuda kiiremini; ja
Insenerid, kes loovad tootetaseme teenuseid, mis lõpuks rakkudesse juurutatakse, ei pea teadma ega muretsema selle pärast, millistes rakkudes nende teenused töötavad.

Suuremate väljakutsete lahendamine

Sarnaselt sellele, kuidas tuletõkkeuksi kasutatakse leekide ohjeldamiseks, toimivad rakud meie infrastruktuuris tugevate plahvatusseintena, mis aitavad ohjeldada mis tahes probleemi, mis põhjustab tõrke ühes rakus. Lõpuks juurutatakse kõik Robloxist koosnevad teenused üleliigselt rakkude sees ja nende vahel. Kui see töö on lõpetatud, võivad probleemid levida piisavalt laialt, et muuta terve rakk kasutuskõlbmatuks, kuid probleemil oleks äärmiselt raske levida sellest rakust kaugemale. Ja kui meil õnnestub muuta rakud vahetatavateks, on taastumine oluliselt kiirem sest suudame tõrjuda teise lahtrisse ja hoida probleem lõppkasutajaid mõjutamast.

See muutub keeruliseks, on nende rakkude eraldamine piisavalt, et vähendada võimalust vigade levitamiseks, säilitades samal ajal asjad jõudluse ja funktsionaalsuse. Keerulises infrastruktuurisüsteemis peavad teenused üksteisega suhtlema, et jagada päringuid, teavet, töökoormust jne. Neid teenuseid rakkudesse kopeerides peame olema läbimõeldud selle üle, kuidas me ristkommunikatsiooni haldame. Ideaalses maailmas suuname liikluse ühest ebatervislikust rakust teistele tervetele rakkudele. Kuid kuidas me saame hakkama "surmapäringuga" - see on see põhjustades rakk olla ebatervislik? Kui suuname päringu teise lahtrisse, võib see lahter muutuda ebatervislikuks just nii, nagu me üritame vältida. Peame leidma mehhanismid "hea" liikluse suunamiseks ebatervislikelt rakkudelt, tuvastades ja summutades samal ajal liiklust, mis põhjustab rakkude ebatervislikkust.

Lühiajalises perspektiivis oleme igasse arvutuslahtrisse juurutanud arvutusteenuste koopiad, nii et enamikku andmekeskuse päringuid saab teenindada üks rakk. Samuti tasakaalustame liiklust rakkude vahel. Kaugemale vaadates oleme alustanud järgmise põlvkonna teenuste avastamise protsessi loomist, mida võimendab teenusevõrk, mille loodame lõpule viia 2024. aastal. See võimaldab meil rakendada keerukaid eeskirju, mis võimaldavad rakkudevahelist suhtlust ainult siis, kui see ei mõjuta tõrkesiirde lahtreid negatiivselt. 2024. aastal on tulemas ka meetod sõltuvate päringute suunamiseks samas lahtris olevale teenuseversioonile, mis minimeerib rakkudevahelist liiklust ja vähendab seeläbi tõrgete rakkudevahelise leviku ohtu.

Tipphetkel teenindatakse enam kui 70 protsenti meie taustateenuste liiklusest rakkudest väljas ja oleme rakkude loomise kohta palju õppinud, kuid ootame rohkem uuringuid ja katsetusi, kui jätkame oma teenuste üleviimist 2024. aastani ja kaugemale. Edenedes muutuvad need lõhkeseinad üha tugevamaks.

Pidevalt töötava infrastruktuuri üleviimine

Roblox on ülemaailmne platvorm, mis toetab kasutajaid üle kogu maailma, nii et me ei saa teenuseid teisaldada haripunktivälisel ajal või "seisakuajal", mis raskendab veelgi kõigi meie masinate rakkudesse migreerimise protsessi ja meie teenuste nendes rakkudes töötamist. . Meil on miljoneid pidevalt töötavaid kogemusi, mida tuleb jätkuvalt toetada, isegi kui liigutame masinaid, millel need töötavad, ja neid toetavaid teenuseid. Kui me seda protsessi alustasime, ei olnud meil kümneid tuhandeid masinaid, mis seisid lihtsalt kasutamata ja nende töökoormuste üleviimiseks.

Meil oli aga väike hulk lisamasinaid, mis osteti tulevase kasvu ootuses. Alustuseks ehitasime neid masinaid kasutades uusi rakke ja seejärel migreerisime töökoormused neile. Hindame nii tõhusust kui ka töökindlust, nii et selle asemel, et minna välja ja osta rohkem masinaid, kui meil „varumasinad” otsa said, ehitasime rohkem rakke, pühkides ja ümber paigutades masinaid, millest olime välja rännanud. Seejärel viisime töökoormused nendele ümberehitatud masinatele üle ja alustasime protsessi uuesti. See protsess on keeruline – kuna masinad asendatakse ja vabanevad rakkudesse sisseehitamiseks, ei vabane need ideaalsel ja korrapärasel viisil. Need on andmesaalide vahel füüsiliselt killustatud, jättes meile võimaluse neid varustada osade kaupa, mis nõuab riistvarataseme defragmentimisprotsessi, et hoida riistvara asukohad joondatud suuremahuliste füüsiliste rikete domeenidega.

Osa meie infrastruktuuri insenerimeeskonnast on keskendunud olemasolevate töökoormuste migreerimisele meie pärandkeskkonnast ehk rakueelsest keskkonnast rakkudesse. See töö jätkub seni, kuni oleme äsja ehitatud rakkudesse üle viinud tuhanded erinevad infrastruktuuriteenused ja tuhanded taustateenused. Eeldame, et see kestab kogu järgmise aasta ja võib-olla ka 2025. aastani, kuna mõned keerulised tegurid. Esiteks nõuab see töö tugevate tööriistade ehitamist. Näiteks vajame tööriistu suure hulga teenuste automaatseks tasakaalustamiseks, kui juurutame uue lahtri – ilma kasutajaid mõjutamata. Oleme näinud ka teenuseid, mille loomisel lähtuti eeldustest meie infrastruktuuri kohta. Peame need teenused üle vaatama, et need ei sõltuks asjadest, mis võivad tulevikus rakkudesse kolides muutuda. Samuti oleme rakendanud nii teadaolevate kujundusmustrite otsimise viisi, mis mobiilsidearhitektuuriga hästi ei tööta, kui ka metoodilise testimisprotsessi iga migreeritud teenuse jaoks. Need protsessid aitavad meil ära hoida kõik kasutajaga seotud probleemid, mis on põhjustatud teenuse rakkudega ühildumatusest.

Praegu haldavad rakud ligi 30,000 99.99 masinat. See on vaid murdosa meie kogu laevastikust, kuid see on seni olnud väga sujuv üleminek, ilma mängijatele negatiivset mõju avaldamata. Meie lõppeesmärk on, et meie süsteemid saavutaksid iga kuu 0.01 protsenti kasutaja tööajast, mis tähendab, et me ei häiriks rohkem kui XNUMX protsenti töötundidest. Kogu tööstusharu hõlmavaid seisakuid ei saa täielikult kõrvaldada, kuid meie eesmärk on vähendada Robloxi seisakuid nii palju, et see on peaaegu märkamatu.

Tulevikukindel meie mastaabis

Kuigi meie varased jõupingutused on osutunud edukaks, pole meie töö rakkudega veel kaugeltki tehtud. Kuna Roblox jätkab skaleerimist, jätkame tööd selle ja teiste tehnoloogiate abil oma süsteemide tõhususe ja vastupidavuse parandamiseks. Kuna me läheme, muutub platvorm probleemidele üha vastupidavamaks ja kõik ilmnevad probleemid peaksid meie platvormil olevaid inimesi järk-järgult vähem nähtavaks ja häirivaks muutuma.

Kokkuvõttes on meil tänaseks:

Ehitati teine andmekeskus ja saavutati edukalt aktiivne/passiivne olek.
Lõime rakud meie aktiivsetes ja passiivsetes andmekeskustes ning siirdasime edukalt üle 70 protsendi meie taustateenuse liiklusest nendesse rakkudesse.
Seadke paika nõuded ja parimad tavad, mida peame järgima, et kõik rakud oleksid ühtsed, kui jätkame ülejäänud infrastruktuuri üleviimist.
Käivitas pideva protsessi, mille käigus ehitati rakkude vahele tugevamaid lõhkemüüre.

Kuna need rakud muutuvad paremini vahetatavateks, on rakkude vahel vähem läbirääkimisi. See avab meile mõned väga huvitavad võimalused jälgimise, tõrkeotsingu ja isegi töökoormuse automaatse nihutamise automatiseerimise suurendamiseks.

Septembris alustasime ka oma andmekeskustes aktiivsete/aktiivsete katsete käitamist. See on veel üks mehhanism, mida testime, et parandada töökindlust ja minimeerida tõrkevahetusaegu. Need katsed aitasid tuvastada mitmeid süsteemi kujundamise mustreid, mis on suuresti seotud andmete juurdepääsuga, mida peame täielikult aktiivseks muutumise suunas ümber töötama. Üldiselt oli katse piisavalt edukas, et jätta see käima piiratud arvu meie kasutajate liikluse jaoks.

Meil on hea meel seda tööd jätkata, et tuua platvormile suurem tõhusus ja vastupidavus. See töö rakkude ja aktiivse-aktiivse infrastruktuuri kallal koos meie muude jõupingutustega võimaldab meil kasvada usaldusväärseks ja suure jõudlusega utiliidiks miljonite inimeste jaoks ning jätkata mastaapimist, kui töötame selle nimel, et miljard inimest reaalselt ühendada. aega.