Hogyan tesszük hatékonyabbá és ellenállóbbá a Roblox infrastruktúráját - Roblox Blog

Újra kiadta Platón

Követő: 0

Ahogy a Roblox az elmúlt 16 év alatt nőtt, úgy nőtt a több millió magával ragadó 3D-s együttélést támogató műszaki infrastruktúra mérete és összetettsége is. Az általunk támogatott gépek száma több mint háromszorosára nőtt az elmúlt két évben, a 36,000. június 30-i körülbelül 2021 145,000-ről a mai közel 1,000 XNUMX-re. Ezeknek az állandóan elérhető élményeknek a támogatása az emberek számára a világ minden tájáról több mint XNUMX belső szolgáltatást igényel. A költségek és a hálózati késleltetés kézben tartása érdekében ezeket a gépeket egy egyedileg épített és hibrid privát felhőinfrastruktúra részeként telepítjük és kezeljük, amely elsősorban a helyszínen fut.

Infrastruktúránk jelenleg több mint 70 millió napi aktív felhasználót támogat világszerte, beleértve azokat az alkotókat is, akik a Roblox-ra támaszkodnak. gazdaság vállalkozásaik számára. Mindezek az emberek milliói nagyon magas szintű megbízhatóságot várnak el. Tapasztalataink magával ragadó jellegéből adódóan rendkívül alacsony a tolerancia a késések vagy késleltetések tekintetében, nem is beszélve a kimaradásokról. A Roblox a kommunikáció és a kapcsolatteremtés platformja, ahol az emberek magával ragadó 3D-s élményekben találkoznak. Amikor az emberek avatárként kommunikálnak egy magával ragadó térben, még a kisebb késések vagy hibák is jobban észrevehetők, mint egy szöveges szálon vagy egy konferenciahíváson.

2021 októberében rendszerszintű leállást tapasztaltunk. Kicsiben kezdődött, egy adatközpont egyik összetevőjével kapcsolatos probléma. De a nyomozás során gyorsan elterjedt, és végül 73 órás kiesést eredményezett. Abban az időben mindkettőnket megosztottuk részleteket a történtekről és néhány korai tanulságunk a kérdésből. Azóta tanulmányozzuk ezeket a tanulságokat, és azon dolgozunk, hogy növeljük infrastruktúránk ellenálló képességét az olyan típusú hibákkal szemben, amelyek minden nagyméretű rendszerben előfordulnak olyan tényezők miatt, mint a szélsőséges forgalmi kiugrások, időjárás, hardverhiba, szoftverhibák vagy egyszerűen csak. az emberek hibáznak. Amikor ezek a hibák előfordulnak, hogyan biztosíthatjuk, hogy egyetlen összetevő vagy összetevőcsoport probléma ne terjedjen át a teljes rendszerre? Ez a kérdés állt a középpontunkban az elmúlt két évben, és miközben a munka folyik, az eddigi munkánk már kifizetődik. Például 2023 első felében havi 125 millió munkaórát takarítottunk meg 2022 első feléhez képest. Ma megosztjuk a már elvégzett munkát, valamint az építkezésre vonatkozó hosszabb távú elképzelésünket rugalmasabb infrastruktúra-rendszer.

Backstop építése

A nagyszabású infrastrukturális rendszereken belül naponta sokszor előfordulnak kis léptékű meghibásodások. Ha az egyik gépen probléma van, és ki kell kapcsolni, az kezelhető, mert a legtöbb vállalat több példányt is karbantart a háttérszolgáltatásaiból. Így ha egyetlen példány meghibásodik, mások veszik fel a munkaterhelést. E gyakori hibák kiküszöbölése érdekében a kérések általában úgy vannak beállítva, hogy hiba esetén automatikusan újrapróbálják.

Ez akkor válik kihívássá, ha egy rendszer vagy személy túl agresszíven próbálkozik újra, ami egy módot jelenthet arra, hogy ezek a kis léptékű hibák átterjedjenek az infrastruktúrán más szolgáltatásokra és rendszerekre. Ha a hálózat vagy a felhasználó elég kitartóan próbálkozik újra, akkor a szolgáltatás minden példányát túlterheli, és potenciálisan más rendszereket is globálisan. A 2021-es kiesésünk valaminek a következménye, ami meglehetősen gyakori a nagyméretű rendszerekben: a hiba kicsiben kezdődik, majd átterjed a rendszeren, és olyan gyorsan terjed, hogy nehéz megoldani, mielőtt minden leállna.

Kimaradásunk idején egyetlen aktív adatközpontunk volt (a benne lévő alkatrészekkel tartalékként működtek). Szükségünk volt arra, hogy manuálisan tudjunk átadni egy új adatközpontot, amikor egy probléma megzavarta a meglévőt. Elsődleges feladatunk az volt, hogy biztosítsuk a Roblox biztonsági mentését, ezért a biztonsági mentést egy új adatközpontban építettük meg, amely egy másik földrajzi régióban található. Ez további védelmet jelent a legrosszabb forgatókönyv esetén: az adatközponton belüli elég komponensre terjedő kimaradás, amely teljesen működésképtelenné válik. Mostantól van egy adatközpontunk, amely a munkaterheléseket kezeli (aktív), egy pedig készenléti állapotban van, amely tartalékként (passzív) szolgál. Hosszú távú célunk, hogy erről az aktív-passzív konfigurációról egy aktív-aktív konfigurációra térjünk át, amelyben mindkét adatközpont kezeli a munkaterheléseket, és a terheléselosztó elosztja közöttük a kéréseket a várakozási idő, a kapacitás és az állapot alapján. Amint ez a helyére került, azt várjuk, hogy az egész Roblox esetében még nagyobb megbízhatóságot érjünk el, és szinte azonnal meghibásodjunk, nem pedig több órán keresztül.

Mobil infrastruktúrára költözés

Következő prioritásunk az volt, hogy erős robbanófalakat hozzunk létre minden egyes adatközponton belül, hogy csökkentsük az egész adatközpont meghibásodásának lehetőségét. A cellák (egyes cégek fürtöknek hívják őket) lényegében gépek halmazát alkotják, és így hozzuk létre ezeket a falakat. A szolgáltatásokat a cellán belül és a cellák között is replikáljuk a redundancia növelése érdekében. Végső soron azt akarjuk, hogy a Roblox összes szolgáltatása cellákban működjön, így mind az erős robbanófalak, mind a redundancia előnyeit élvezhetik. Ha egy cella már nem működik, biztonságosan deaktiválható. A cellák közötti replikáció lehetővé teszi, hogy a szolgáltatás továbbra is fusson a cella javítása közben. Egyes esetekben a sejtjavítás a sejt teljes újraelosztását jelentheti. Az egész iparágban meglehetősen elterjedt egy egyedi gép vagy egy kis gépkészlet törlése és újratelepítése, de ez egy teljes cellára, amely ~1,400 gépet tartalmaz, nem az.

Ahhoz, hogy ez működjön, ezeknek a celláknak nagyjából egységesnek kell lenniük, így gyorsan és hatékonyan tudjuk mozgatni a munkaterheléseket egyik celláról a másikra. Meghatároztunk bizonyos követelményeket, amelyeknek a szolgáltatásoknak meg kell felelniük, mielőtt egy cellában futnának. Például a szolgáltatásokat konténerbe kell helyezni, ami sokkal hordozhatóbbá teszi őket, és megakadályozza, hogy bárki is módosítsa a konfigurációt az operációs rendszer szintjén. Elfogadtuk az infrastruktúra kódként filozófiát a cellák számára: Forráskód-tárhelyünkben minden cellában lévő definíciót tartalmaznak, így automatizált eszközök segítségével gyorsan újjáépíthetjük a semmiből.

Jelenleg nem minden szolgáltatás felel meg ezeknek a követelményeknek, ezért azon dolgoztunk, hogy lehetőség szerint segítsünk a szolgáltatástulajdonosoknak megfelelni ezeknek, és új eszközöket építettünk, amelyek megkönnyítik a szolgáltatások cellákba való migrálását, amikor készen állnak. Például az új üzembe helyezési eszközünk automatikusan „csíkozza” a szolgáltatás központi telepítését a cellák között, így a szolgáltatástulajdonosoknak nem kell a replikációs stratégiára gondolniuk. Ez a szigor a migrációs folyamatot sokkal nagyobb kihívást és időigényessé teszi, de a hosszú távú megtérülés egy olyan rendszer lesz, ahol:

Sokkal könnyebb megfékezni a hibát, és megakadályozni, hogy átterjedjen más sejtekre;
Infrastrukturális mérnökeink hatékonyabbak és gyorsabban mozoghatnak; és
A mérnököknek, akik a termékszintű szolgáltatásokat építik ki, amelyek végül a cellákba kerülnek, nem kell tudniuk, és nem kell aggódniuk, hogy szolgáltatásaik mely cellákban futnak.

Nagyobb kihívások megoldása

A tűzgátló ajtókhoz hasonlóan a lángok megfékezésére, a cellák erős robbanófalként működnek infrastruktúránkon belül, hogy segítsenek megvédeni minden olyan problémát, amely egyetlen cellán belül meghibásodást vált ki. Végül a Robloxot alkotó összes szolgáltatás redundánsan telepítve lesz a cellákon belül és a cellák között. Ha ez a munka befejeződött, a problémák továbbra is elég széles körben terjedhetnek ahhoz, hogy egy egész sejt működésképtelenné váljon, de rendkívül nehéz lenne, ha egy probléma túlterjedne azon a sejten. És ha sikerül a sejteket felcserélhetővé tennünk, a helyreállítás lényegesen gyorsabb lesz mert át tudunk lépni egy másik cellába, és megakadályozzuk, hogy a probléma hatással legyen a végfelhasználókra.

Ez bonyolulttá válik, ha ezeket a cellákat kellőképpen el kell választani, hogy csökkentse a hibák terjesztésének lehetőségét, miközben a dolgok teljesítőképesek és működőképesek maradnak. Egy összetett infrastruktúra-rendszerben a szolgáltatásoknak kommunikálniuk kell egymással a lekérdezések, információk, munkaterhelések stb. megosztása érdekében. Miközben ezeket a szolgáltatásokat cellákba replikáljuk, át kell gondolnunk, hogyan kezeljük a keresztkommunikációt. Egy ideális világban átirányítjuk a forgalmat az egyik egészségtelen sejtről a többi egészséges sejtre. De hogyan kezeljük a „halálkérdést” – ez az okozó egy sejt egészségtelennek lenni? Ha átirányítjuk a lekérdezést egy másik cellára, az a cella egészségtelenné válását okozhatja, éppen úgy, ahogyan megpróbáljuk elkerülni. Meg kell találnunk azokat a mechanizmusokat, amelyek segítségével a „jó” forgalmat elterelhetjük az egészségtelen sejtekről, miközben észleljük és elnyomjuk a forgalmat, amely a sejtek egészségtelenné válását okozza.

Rövid távon minden számítási cellába telepítettük a számítási szolgáltatások másolatait, így az adatközponthoz intézett kérések többségét egyetlen cella tudja kiszolgálni. A cellák közötti terheléselosztást is végezzük. Tovább tekintve, megkezdtük egy új generációs szolgáltatásfelderítési folyamat felépítését, amelyet egy szolgáltatásháló fog kiaknázni, és amelyet remélünk, hogy 2024-ben befejezünk. Ez lehetővé teszi számunkra, hogy olyan kifinomult irányelveket hajtsunk végre, amelyek csak akkor teszik lehetővé a cellák közötti kommunikációt. nem befolyásolja negatívan a feladatátvételi cellákat. Szintén 2024-ben érkezik egy olyan módszer, amely a függő kéréseket ugyanabban a cellában lévő szolgáltatásverzióhoz irányítja, ami minimalizálja a cellák közötti forgalmat, és ezáltal csökkenti a hibák cellák közötti terjedésének kockázatát.

Csúcsidőben háttérszolgáltatásunk forgalmának több mint 70 százalékát cellákon kívül szolgálják ki, és sokat tanultunk a cellák létrehozásáról, de további kutatásokra és tesztelésre számítunk, ahogy folytatjuk szolgáltatásaink migrációját 2024-ig, és túl. Ahogy haladunk előre, ezek a robbanásfalak egyre erősebbek lesznek.

Állandóan működő infrastruktúra áttelepítése

A Roblox egy globális platform, amely a világ minden tájáról támogatja a felhasználókat, így nem tudjuk áthelyezni a szolgáltatásokat csúcsidőn kívüli vagy „leállási időben”, ami tovább bonyolítja az összes gépünk cellákba való migrálásának folyamatát, és szolgáltatásainkat, hogy ezekben a cellákban fussanak. . Milliónyi mindig működő élményünk van, amelyeket továbbra is támogatni kell, még akkor is, ha mozgatjuk a rajtuk futó gépeket és az őket támogató szolgáltatásokat. Amikor elindítottuk ezt a folyamatot, nem állt gépek tízezrei, akik csak ültek használaton kívül és álltak rendelkezésre, hogy áttelepítsük ezeket a munkaterheléseket.

Volt azonban néhány további gépünk, amelyeket a jövőbeni növekedés reményében vásároltunk. Kezdésként új cellákat építettünk fel ezekkel a gépekkel, majd a munkaterheléseket migráltuk rájuk. Fontosnak tartjuk a hatékonyságot és a megbízhatóságot is, ezért ahelyett, hogy több gépet vásárolnánk, miután elfogytak a „tartalék” gépeink, több cellát építettünk azáltal, hogy töröltük és újratelepítettük azokat a gépeket, amelyekről költöztünk. Ezután áttelepítettük a munkaterheléseket ezekre az újraprovivalizált gépekre, és újrakezdtük a folyamatot. Ez a folyamat összetett – ahogy a gépek kicserélődnek és felszabadulnak, hogy a cellákba beépüljenek, nem szabadulnak fel ideális, rendezett módon. Fizikailag töredezettek az adatcsarnokok között, így részenként kell kiosztani őket, ami hardverszintű töredezettségmentesítési folyamatot igényel, hogy a hardverhelyek összhangban legyenek a nagyszabású fizikai hibatartományokkal.

Infrastruktúra-mérnöki csapatunk egy része arra összpontosít, hogy a meglévő munkaterheléseket áttelepítse örökölt vagy „cella előtti” környezetünkből cellákba. Ez a munka addig folytatódik, amíg több ezer különféle infrastrukturális szolgáltatást és több ezer háttérszolgáltatást át nem telepítünk az újonnan épített cellákba. Várakozásaink szerint ez néhány bonyolító tényező miatt az egész jövő évet és esetleg 2025-ig is eltart. Először is ehhez a munkához robusztus szerszámok megépítése szükséges. Például szükségünk van olyan eszközökre, amelyek automatikusan újraegyensúlyozzák a nagyszámú szolgáltatást, amikor új cellát telepítünk – anélkül, hogy ez hatással lenne a felhasználókra. Láttunk olyan szolgáltatásokat is, amelyek az infrastruktúránkra vonatkozó feltételezések alapján készültek. Felül kell vizsgálnunk ezeket a szolgáltatásokat, hogy ne függjenek olyan dolgoktól, amelyek a jövőben megváltozhatnak, ahogy a cellákba költözünk. Bevezettünk egy módszert az ismert tervezési minták keresésére, amelyek nem működnek jól a cellás architektúrával, valamint egy módszeres tesztelési folyamatot minden egyes áttelepített szolgáltatáshoz. Ezek a folyamatok segítenek elhárítani a felhasználókkal kapcsolatos problémákat, amelyeket egy szolgáltatás cellákkal való összeférhetetlensége okoz.

Ma közel 30,000 99.99 gépet kezelnek a cellák. Ez csak egy töredéke a teljes flottánknak, de ez idáig nagyon zökkenőmentes átmenet volt, negatív játékosok hatása nélkül. Végső célunk az, hogy rendszereink minden hónapban elérjék a 0.01 százalékos felhasználói üzemidőt, ami azt jelenti, hogy az elköteleződési órák legfeljebb XNUMX százalékát zavarnánk meg. Az egész iparágra kiterjedően az állásidőt nem lehet teljesen kiküszöbölni, de célunk az, hogy a Roblox leállásait olyan mértékben csökkentsük, hogy az szinte észrevehetetlen legyen.

Jövőbiztosság, ahogy méretezzük

Bár korai erőfeszítéseink sikeresnek bizonyulnak, a sejtekkel kapcsolatos munkánk még korántsem fejeződött be. Ahogy a Roblox folyamatosan skálázódik, továbbra is azon fogunk dolgozni, hogy ezzel és más technológiákkal javítsuk rendszereink hatékonyságát és rugalmasságát. Ahogy haladunk, a platform egyre ellenállóbbá válik a problémákkal szemben, és minden felmerülő probléma fokozatosan kevésbé lesz látható és zavaró lesz a platformunkon dolgozók számára.

Összefoglalva, a mai napig a következők állnak rendelkezésünkre:

Felépített egy második adatközpontot, és sikeresen elérte az aktív/passzív állapotot.
Cellákat hozott létre aktív és passzív adatközpontjainkban, és sikeresen migrálta a háttérszolgáltatási forgalom több mint 70 százalékát ezekre a cellákra.
Állítsa be azokat a követelményeket és bevált gyakorlatokat, amelyeket követnünk kell ahhoz, hogy az összes cella egységes maradjon, miközben folytatjuk az infrastruktúra többi részének áttelepítését.
Beindította a sejtek közötti erősebb „robbanásfalak” felépítésének folyamatos folyamatát.

Ahogy ezek a sejtek egyre jobban felcserélhetők, kevesebb lesz az áthallás a sejtek között. Ez nagyon érdekes lehetőségeket nyit meg számunkra a megfigyelés, a hibaelhárítás, sőt a munkaterhelések automatikus eltolása körüli automatizálás fokozása terén.

Szeptemberben megkezdtük az aktív/aktív kísérletek futtatását adatközpontjainkban. Ez egy másik mechanizmus, amelyet tesztelünk a megbízhatóság javítása és a feladatátvételi idők minimalizálása érdekében. Ezek a kísérletek segítettek azonosítani számos rendszertervezési mintát, nagyrészt az adatokhoz való hozzáféréssel kapcsolatban, amelyeket át kell dolgoznunk, miközben törekszünk a teljesen aktívvá válás felé. Összességében elmondható, hogy a kísérlet elég sikeres volt ahhoz, hogy futni hagyjon korlátozott számú felhasználónk forgalmára.

Izgatottan várjuk, hogy tovább mozdítsuk ezt a munkát a platform hatékonyságának és rugalmasságának növelése érdekében. Ez a cellákon és az aktív-aktív infrastruktúrán végzett munka, valamint egyéb erőfeszítéseink lehetővé teszik számunkra, hogy megbízható, nagy teljesítményű közművé váljunk emberek milliói számára, és folyamatosan bővüljünk, miközben egymilliárd ember valódi összekapcsolásán dolgozunk. idő.