Szerző: Gálffy Csaba

2014. augusztus 27. 12:39

Ezért állt a Visual Studio Online

Komoly leállást tapasztalt a Microsoft online fejlesztői szolgáltatása, a Visual Studio Online. A rendszer több, mint öt órán keresztül gyakorlatilag elérhetetlen volt augusztus 14-én, a fejlesztőcsapat most publikálta az okokról és tapasztalatokról szóló beszámolót.

Komoly leállást produkált a Microsoft Visual Studio Online, a cég szolgáltatásként nyújtott fejlesztői rendszere. A "felhős Team Foundation Server" augusztus 14-én előbb néhány felhasználó, majd egyre többek számára elérhetetlenné vált, 14:00 UTC és 19:30 UTC között pedig (mintegy öt és fél órára) teljesen leállt, ezzel ez lett a szolgáltatás történetének egyik legsúlyosabb kiesése. A  fejlesztőcsapat most elkészítette a leállást követő jelentését, amely feltárja az okokat és részletezi a jövőben tervezett lépéseket is.

Miért történt?

A vizsgálat feltárta a probléma forrását, eszerint az egyik központi SPS (Shared Platform Services) adatbázis hirtelen rendkívüli terhelést kapott a Team Foundation Server felől, amelyet képtelen volt megfelelő sebességgel kiszolgálni. Mivel az SPS része a hitelesítési és licencellenőrzési folyamatnak is, így kiesésével a rendszer nem tudta megfelelő sebességgel ellenőrizni a felhasználók licenceinek érvényességét és kizárta őket.

Hogy magát a váratlan terhelést mi okozta, arra egyelőre nincs válasza a cégnek, ez a terület továbbra is vizsgálat tárgya. Azt tudni lehet, hogy a fejlesztők röviddel az incidens előtt alakították át némileg a rendszer konfigurációját, és valószínűleg az újdonságok egyike okozott váratlan terhelést. A csapat munkáját nehezíti, hogy az SPS adatbázis-lekérdezések logja hiányos, így nehéz pontosan rekonstruálni a leálláshoz vezető folyamatot. A blogbejegyzés szerint azonban nem is a specifikus hiba megtalálása a legfontosabb, hanem hogy az hogyan ránthatta magával a teljes rendszert és vezethetett leálláshoz.

A felhős rendszerek (köztük a Visual Studio Online) megtervezésében fontos szempont az elosztottság, a hibatűrés és a dominóeffektus kizárása - esetünkben ezek a megfontolások nem érvényesültek, így a hibakeresés elsősorban arra irányult, hogy mi akadályozta ezt meg. A csapat több, egymástól független hibát is talált, amelyek együtt vezettek végül a lavinához. Néhány példa:  a TFS-SPS hívások nem frissítették helyesen a TFS service-hez tartozó tulajdonságot, ez SQL-írási versenyhelyzethez vezetett, ami a Service Bus-on jelentős forgalomnövekedést okozott. A problémát tovább fokozta, hogy a 401-es hibát kezelő kód hibája miatt a gyorsítótár sűrűn ürítésre került, ez tovább csökkentette a teljesítményt. Az Azure Portal egyik kiegészítő szolgáltatása a 401-es hibát adó lekéréseket 5 másodpercenként (hibásan) újrapróbálta (hosszabb lista az eredeti bejegyzésben).

Fellazult fegyelem

Figyelemre méltó, hogy a Team Foundation Server termékmenedzsere, Brian Harry egészen őszintén beszél arról, hogy a leálláshoz végső soron a fejlesztő-üzemeltető csapat kultúrájának módosulása vezetett. Míg a szolgáltatás beindításakor "rendkívüli műszaki szigor köré épültek fel a folyamatok és a minőségi elvárások, ez a szigor a hosszú menetelésben elsorvadt" - mondja Harry, a kezdeti magas standardok az új kódban már nem teljesültek. Míg korábban a csapat szinte minden tagja átlátta a teljes stacket, így megértette, hogy bizonyos döntések hogyan befolyásolhatják a teljesítményt, idővel ez elveszett, helyére pedig egymástól (részben) függetlenül fejlődő, absztrakt szoftverrétegek kerültek.

Ezzel önmagában még nem lett volna probléma, a tesztkörnyezet azonban ezt a változást nem tükrözte le. Unit és szintetikus tesztek természetesen vannak, de bizonyos skálázódási-teljesítménybeli problémák ilyen környezetben nem jönnek elő. Ez esetben is valami ilyesmi történt, a konfiguráció megváltozásával a terhelés valamelyik ponton megugrott, ami bedöntötte a rendszert. Kicsiben, szintetikus tesztekben ez nem jött elő, csak az éles működés során. A fentiek fényében adott a megoldás, a csapat most egy olyan infrastruktúrát épít, amelyen nagyobb rendszeren is tudja mérni a rendszer teljesítményét, és amely helyesen tudja modellezni a különböző változtatások erőforrásköltségét.

Fejlesztő vagy? Segíts! Hack the Crisis. Gyere hétvégén fejleszteni, csatlakozz a hazai fejlesztői közösséghez!

A leállás közvetlen elhárítását követően azonban az architektúra alapos újratervezést és ellenőrzést kap. Az SPS-en belüli lekérdezések, illetve az SQL és az SPS közötti hívások mintázata új telemetriával egészül ki, amely a fenti szituációk beálltát még azelőtt jelezni tudja, mielőtt a helyzet kritikussá válik. Az SPS konfigurációs adatbázis particionálást és skálázódást kap, amivel könnyebb a problémák elszigetelése és javul a teljesítmény is. Hosszabb távú megoldás az automatikus "fékek" implementálása, amely az ilyen túlterheléses leállás ellen hoz majd védelmet. Ezen túl a teljes szolgáltatást magasabb hibatűrésre tervezik, hogy egy komponens kiesése esetén a többi leállás nélkül, valamilyen csökkentett funkciójú módban tovább működhessen (fail gracefully, degrade gracefully).

Fontos tanulságok

A bejegyzést érdemes eredetiben is elolvasni, Harry ugyanis igen fontos gondolatokat fogalmaz meg benne, a fenti incidenstől részben függetlenül. Az egyik, hogy amikor a teljesítményről igyekszünk fogalmat alkotni, akkor egy hibás elképzelés (absztrakció) nagyon félrevezető lehet. A csapat a fejlesztés kezdetén a SQL Servert relációs adatbázisként fogta fel. Ez azonban nem találó, sokkal pontosabb a lemezes I/O-n nyugvó absztrakciós rétegként definiálni, mivel teljesítménye szorosan összefügg az alatta fekvő lemezes alrendszer késleltetésével, adatsűrűségével, lekérdezési mintázataival. A felismerés azt jelenti, hogy a lemezes alrendszer optimalizálásával érhető el a jobb skálázódás - míg csupán adatbázisként tekinteni a szoftvert egészen más, kevesebb megtérüléssel rendelkező irányba vitte volna a csapatot.

a címlapról