Szolgáltatáskimaradások Európában és Brazíliában

Sziasztok, Brian „Penrif” Bossé vagyok a League of Legends technikai részlegétől, és a február végén az EUW, EUNE és BR szervereket sújtó műszaki problémákról szeretnék beszélni. Akit érdekelnek a szolgáltatáskimaradások és az elhárításuk technikai részletei, most szépséges grafikonokat nézegetve elégítheti ki a kíváncsiságát!

Az előzmények

Felkeltette a szolgáltatás felett éberen őrködő Hálózati Műveleti Központ figyelmét, hogy drasztikusan csökkent az elindított LoL-játékok száma.

Ez nagyon szokatlan

A játékok sikeres elindításában nagyon sok rendszer vesz részt a meccskereséstől a terheléselosztáson át magáig a játékszerverig, és egy ilyen tünetből nem állapítható meg egyből, hogy mi okozza a hibát. Ezért értesítettük az egyes területek szakembereit, de ők azt jelezték vissza, hogy az ő rendszerük flottul működik, de minimális a bejövő adatforgalmuk. A meccskeresés például nem tud hatékonyan működni, ha túl kevés a meccset kereső játékos.

Ez alapján világossá vált, hogy rendszerszintű probléma adódott, amely megakadályozza, hogy a játékosok adatai elérjék a háttérrendszereket. A metrikák ezen a területen jeleztek nagyon komoly gondokat:

Az alul látható vízszintes vörös vonalnál kezdünk aggódni

Itt az egyik általános tároló gazdagépünkre érkező bejövő kapcsolatok láthatók. Ezek hatalmas teljesítményű egyedi számítógépek, amelyek számos kisebb alkalmazást (tárolót) futtatnak; ezek együtt alkotják a LoL-t futtató rendszert. A két gazdagép közül kettő felé jóval több kapcsolat irányul a kelleténél. Az okok megértéséhez szót kell ejtenünk az úgynevezett peremhálózati tárolókról.

A peremen állva

Az ezeken futó folyamatok fogadják az internetes adatforgalmat, megszűrik, majd átirányítják a megfelelő háttérszolgáltatáshoz. Kiszűrik a nyilvános internet feleslegét, és csak a folyamathoz szükséges adatokat engedik tovább. Gondolom, sejtitek, hogy óriási adatmennyiséget kell ily módon kezelni, de közel sem annyit, mint amennyi az incidens során jelent meg hirtelen. Három tényező együttállására volt szükség a helyzet kialakulásához. Megpróbálom egyenként megmagyarázni ezeket.

A kezdet

Kezdjük a lavinát elindító problémával: aránytalanul sok kérelem érkezett egy szolgáltatásba. Néhány hónapja észleltük, hogy megnőtt a szolgáltatásra irányuló hívásgyakoriság volatilitása, de úgy láttuk, hogy ez nem befolyásolja a szolgáltatást, és az utána következő rendszerekben sem okozott problémát. Egy ártalmatlan anomália általában nem igényel azonnali beavatkozást, de rögzítettük a létezését. Mára kiderült, hogy mi volt a gond: hiba történt a kérelem küldésében, és az emiatt bizonyos esetekben azonnal meghiúsult... és a rendszer folyamatosan próbálta megismételni.

Szivárgó tárolók

Létezett egy ismert hiba a tárolórendszerünk és az általunk használt operációs rendszer aktuális verziója közötti együttműködésben. Ez memóriavesztéshez vezetett az operációs rendszer legmélyén, ami ellenőrizetlenül hagyva idővel kulcsfontosságú rendszerfunkciók leállásához vezetett. Az incidenst megelőzően sosem jelentkezett a hiba, de amúgy is frissítettük addigra a Riot tárolóflottájának 60%-át. Sajnos a frissítés még folyamatban volt az európai és latin-amerikai szervereken.

A balszerencse áradása

Végül pedig... pechünk volt. Egy szoftver segítségével csoportosítjuk olyan kötegekbe a tárolókat, amelyeket egy számítógép kezelni képes. Ezeket aztán a gép keretein belül tartja, hogy a jelentős hálózati forgalmat kezelő peremszolgáltatások egymástól függetlenül működjenek az adott szilánk tárolókészletein belül. Azt viszont nem tudtuk szabályozni, hogy más szilánkok peremszolgáltatásai ne ugyanazon a számítógépen kössenek ki, így az EUW és az EUNE peremszolgáltatásai ugyanoda kerültek. A megtöbbszöröződött terhelés egyetlen számítógépre zúdulása volt az, ami az előző két problémát jelentős incidenssé fokozta.

A szolgáltatáskimaradások alkalmával legalább három szilánk peremtárolói egyetlen gazdagépre kerültek. A hibás kérelmek által generált adatforgalom, több szilánk egyetlen gazdagépre zúduló adatforgalma és az operációs rendszer memóriavesztése együttesen működésképtelenné tették a gépet, ami a szilánk leállásához és szolgáltatáskimaradáshoz vezetett.

Hatás és megoldás

Általában nehéz kibogozni az ehhez hasonló gondok forrását és azonosítani a konkrét hibákat. Amikor el kellett dönteni, hogy elindulhat-e a Clash egy ilyen instabil fürtön, már sejtettük, hogy a tárolók lehetnek a probléma okozói, de még nem sikerült egyértelműen azonosítani a megnövekedett adatforgalom okát. Bár a hibának semmi köze nem volt a Clashhez, a legjobb verseny- és játékélmény érdekében az egyhetes halasztás mellett döntöttünk. Szeretnénk elnézést kérni az incidens érintettjeitől, és biztosítani mindenkit, hogy minden ahhoz vezető hibát sikerült kijavítanunk.

A hibás kérelmeket létrehozó kódot kijavítottuk, de arra az esetre, ha véletlenül hasonló probléma adódna a jövőben, átalakítottuk az újrapróbálkozási mechanizmust, hogy ne növelhesse meg ilyen módon az adatforgalmat. Az összes szilánkon befejeződött a tárolók szoftverfrissítése. Konkrét terveink vannak arra, hogy a peremszolgáltatásokat áthelyezzük egy terheléselosztó rendszerbe, amely képes elosztani ezek forgalmát a szilánkok között. Amíg ez nem valósul meg, addig probléma esetén valamelyikünk telefonja egy légiriadó erejével fog szirénázni, amíg nem történik meg a terhelés manuális elosztása.

Ki merjük jelenteni, hogy a kiváltó okok azonosítása után ez a mostani forgatókönyv nem ismétlődhet meg. Ugyanakkor annak ellenére, hogy a játék és a kiszolgálórendszerei folyamatosan fejlődnek, sajnos nem lehet teljesen kizárni a hasonló incidensek előfordulását. Ilyen esetekben a lehető leghamarabb próbáljuk helyreállítani a szolgáltatást. Köszönöm mindenkinek, aki eljutott idáig. Akit érdekelnek az ehhez hasonló részletes technikai bejegyzések, annak ajánlom figyelmébe a LoL technikai blogját. Sziasztok, és találkozunk a Szurdokban!