Robusztus a komplex rendszerekben: egy tudományos cikk összefoglalása

Fotó: Vladimir Kudinov az Unsplash-en

Ma megvizsgáljuk a „Robusztus a komplex rendszerekben” című, 2001-ben Steven D. Gribble által kiadott papírt. Az összes idézőjel és ábra a papírból származik.

Ez a cikk azt állítja, hogy a rendszerek közös tervezési paradigmája alapvetően hibás, és instabil, kiszámíthatatlan viselkedést eredményez a rendszer komplexitásának növekedésével.

A „közös tervezési paradigma” arra a gyakorlatra vonatkozik, hogy megjósolják a rendszer működési környezetét és annak meghibásodási módjait. A tanulmány kijelenti, hogy egy rendszer olyan körülményekkel fog foglalkozni, amelyeket nem számítottak előre, amint összetettebbé válik, ezért úgy kell megtervezni, hogy kevésbé bonyolult módon kezelje a kudarcot. A cikk ezeket az ötleteket „elosztott adatstruktúrák (DDD), skálázható, fürt alapú tároló szerver” segítségével vizsgálja meg.

Természetüknél fogva a nagy rendszerek sok alkatrész komplex kölcsönhatásán keresztül működnek. Ez az interakció a rendszer elemeinek átható csatolásához vezet; ez a kapcsolás erős lehet (például a hálózat szomszédos útválasztói között elküldött csomagok) vagy finom (például a hirdetési útvonalak szinkronizálása egy széles hálózaton keresztül).

Az ilyen nagy rendszerek megjelenésének közös jellemzője, hogy Butterfly Effect néven ismert. Ez arra utal, hogy a rendszer egy kicsi váratlan zavart okoz, amelyet a különféle alkatrészek bonyolult kölcsönhatása okoz, és ez széles körű változást idéz elő.

A rendszer tervezésének közös célja a robusztusság: a rendszer azon képessége, hogy különféle körülmények között helyesen működjön, és váratlan helyzetekben kecsesen kudarcot valósítson meg. A cikk azzal a közös mintával szembesül, hogy megpróbálják megjósolni a rendszer bizonyos működési feltételeit, és megtervezni, hogy csak ezekben a körülmények között működjön jól.

Ezenkívül gyakorlatilag lehetetlen megjósolni az összes zavart, amelyet egy rendszer tapasztal a környezeti feltételek megváltozása, például hardverhibák, terheléscsillapítás vagy rosszul viselkedő szoftver bevezetése eredményeként. Mindezek alapján úgy gondoljuk, hogy minden olyan rendszer, amely kizárólag az előzetes megismerés révén próbálja megszerezni a robusztust, hajlamos a törékenységre.

DDS: Esettanulmány

A fenti hipotézist egy skálázható, klaszter-alapú tárolórendszer, DDD (DDD) segítségével vizsgáljuk - „egy nagy kapacitású, nagy teljesítményű virtuális kivonat-tábla, amely fel van osztva és replikálva van számos különálló tároló csomóponton, úgynevezett tégla”.

Ezt a rendszert a fentiekben ismertetett prediktív tervezési filozófiával építették fel.

Az ilyen rendszerekkel kapcsolatos széles körű tapasztalatok alapján megpróbáltuk megfontolni a rendszer szoftver alkotóelemeinek, algoritmusainak, protokolljainak és hardver elemeinek viselkedését, valamint a kapott munkaterheléseket.

Amikor a rendszer a tervezők által tett feltételezések keretein belül működött, jól működött. Tudták méretezni és javítani a teljesítményt. Abban az esetben azonban, ha a működési feltételekre vonatkozó egy vagy több feltételezést megsértették, a rendszer váratlan módon viselkedett, adatvesztést vagy következetlenségeket eredményezve.

Ezután számos ilyen rendellenességről beszélünk.

Szemétgyűjtés dobogó és behatárolt szinkronizálás

A rendszer tervezői időtúllépéseket használtak a rendszer komponenseinek meghibásodásainak észlelésére. Ha egy adott elem nem válaszolt a megadott időn belül, akkor azt halottnak tekintik. Feltételezték, hogy a rendszerben szinkronizmus van.

A DDS-t Java-ban vezetik be, ezért a szemétgyűjtést használják. A JVM-ben a hulladékgyűjtő egy mark-and-sweep gyűjtő volt; Ennek eredményeként, mivel az aktívabb objektumok a JVM-halomban laknak, meghosszabbodik az az időtartam, amely alatt a hulladékgyűjtő egy meghatározott memóriamennyiség visszanyerése érdekében fut.

Amikor a rendszer telített volt, a téglák terhelésének enyhe változásai meghosszabbítják a hulladékgyűjtő által igénybe vett időt, és ezzel csökkentik a tégla átmenő teljesítményét. Ezt nevezzük GC thrashing-nak. Az érintett tégla elmaradna a többi társától, ami a rendszer teljesítményének további romlásához vezetne.

Ezért a hulladékgyűjtés megsértette a korlátozott szinkronizmus feltételezését, amikor a telítési ponthoz közeledett, vagy túl.

Lassú szivárgások és kapcsolódó hibák

A rendszer tervezése során egy másik feltételezés az volt, hogy a hibák függetlenek. A DDS a replikációt használta a rendszer hibatűrővé tételéhez. A többszörös replikák egyidejű kudarcának valószínűsége nagyon kicsi.

Ezt a feltételezést azonban megsértették, amikor kódjukban versenyfeltételekkel találkoztak, amelyek memóriaszivárgást okoztak anélkül, hogy befolyásolták volna a helyességüket.

Amikor elindítottuk rendszerünket, hajlandóak minden téglát egyszerre elindítani. A rendszer egészében nagyjából kiegyensúlyozott terhelés miatt minden tégla majdnem ugyanabban az időben, több nappal az indításuk után kifogyna a halomterületről. Azt is feltételeztük, hogy az automatikus feladatátvételi mechanizmusok tovább súlyosbítják ezt a helyzetet azáltal, hogy a másolat meghiúsulása után növeli a replika terhelését, és növeli a replika memóriaszivárgásának sebességét.

Mivel az összes másolatot egyenletesen terhelték, anélkül, hogy a teljesítmény romlását és más kérdéseket vették figyelembe, ez összekapcsolódást hozott létre a másolatok és a…

… Lassú memóriaszivárgás esetén a független hibák feltételezésének megsértéséhez vezet, ami viszont rendszerünk számára elérhetetlenséget és részleges adatvesztést okozott

Nem ellenőrzött függőségek és meghibásodás-leállítás

Annak a feltevésnek a alapján, hogy ha egy alkatrész lejárt, akkor meghibásodott, akkor a tervezők azt is feltételezték, hogy „megáll-megáll” meghibásodások, vagyis az a komponens, amely meghibásodott, egy idő után nem folytatja működését. A rendszerben lévő téglák aszinkron módon végezték az összes hosszú késleltetésű munkát (lemez I / O).

Nem tudták azonban észrevenni, hogy kódjuk egyes részei blokkoló funkcióhívásokat használtak. Ennek eredményeként a fő eseménykezelő szálat véletlenszerűen vették kölcsön, ami téglákat magyarázhatatlanul néhány percre ragadt el és folytatta a postát.

Noha ez a hiba annak az oka, hogy a saját általunk nem sikerült ellenőrizni a használt kód viselkedését, ez azt mutatja, hogy az egymástól függetlenül épített komponensek közötti alacsony szintű interakciónak súlyos következményei lehetnek a rendszer általános viselkedésére. A magatartás nagyon finom változása a teljes klaszter során megsértette a hibás működés feltételezését, ami végül a rendszerünkben szereplő adatok sérüléséhez vezet.

A robusztus rendszerek felé

..a komplex, kapcsolt rendszer kismértékű változásai a viselkedésben nagy, váratlan változásokat eredményezhetnek, amelyek valószínűleg a tervező által elvárt működési módon kívül esnek a rendszeren.

Néhány megoldás, amely segíthet nekünk robusztusabb rendszerek létrehozásában:

Szisztematikus túlképzés

A telítési ponthoz közeledve a rendszerek törékenyek lesznek, amikor megpróbálják alkalmazni a váratlan viselkedést. Ennek leküzdésének egyik módja a rendszer szándékos túlzott ellátása.

Ennek azonban megvan a maga kérdése: az erőforrások kihasználatlanságához vezet. Ez azt is megköveteli, hogy megjósolják a várható működési környezetet és ezáltal a rendszer telítési pontját. A legtöbb esetben ezt nem lehet pontosan megtenni.

Használja a belépési ellenőrzést

Másik módszer a terhelés visszautasításának megkezdése, miután a rendszer megközelíti a telítési pontot. Ehhez azonban meg kell előre jelezni a telítettségi pontot - ami nem mindig lehetséges, különösen nagy rendszereknél, amelyek sok hozzájáruló változóval rendelkeznek.

A kérelmek elutasítása szintén erőforrásokat igényel a rendszerből. A belépés-szabályozást szem előtt tartva tervezett szolgáltatásoknak általában két működési módjuk van: normál, ahol a kérelmeket feldolgozzák, és rendkívül könnyű üzemmódban, ahol azokat elutasítják.

Beépíteni az önellenőrzést a rendszerbe

egy introspektív rendszer az, amelyben a rendszer figyelésének képességét a kezdetektől kezdve megtervezik.

Ha egy rendszert meg lehet figyelni, és a tervezők és az üzemeltetők értelmes méréseket végezhetnek a működéséről, akkor sokkal robusztusabb, mint egy fekete dobozos rendszer. Könnyebb adaptálni egy ilyen rendszert a környezetének változására, valamint kezelni és karbantartani.

Vezesse be az alkalmazkodóképességet a vezérlőhurok bezárásával

A vezérlőhurok példája az emberi tervezők és üzemeltetők, akik a mérést a működési környezet változásaival jelzett változás hatására adaptálják. Az ilyen vezérlőhurok ütemterve azonban nem túl kiszámítható. A szerzők szerint a rendszereket belső vezérlőhurkokkal kell építeni.

Ezek a rendszerek magukba foglalják az önvizsgálat eredményeit, és megkísérelik a vezérlő változókat dinamikusan adaptálni annak érdekében, hogy a rendszer stabil vagy jól teljesítő üzemmódban működjön.
Valamennyi ilyen rendszernek megvan a tulajdonsága, hogy az adaptációt végző komponens képes valamilyen pontosan feltételezni az adaptáció hatásait; ennek hiányában a rendszer „sötétben működik”, és valószínűleg kiszámíthatatlanná válik. Az adaptáció hatásainak feltételezéséhez egy új, érdekes megközelítés a statisztikai gépi tanulás használata; ezt figyelembe véve egy rendszer kipróbálhatja a változásokat annak érdekében, hogy felépítsék a hatások modelljét.

A kudarc terve

A komplex rendszereknek meg kell várniuk a kudarcot, és ennek megfelelően meg kell tervezniük.

Néhány módszer erre:

  1. az összetevők leválasztása a hibák helyben történő leküzdésére
  2. minimalizálja a károkat robusztus absztrakciók, például tranzakciók felhasználásával
  3. minimalizálja az időt hibaállapotban (az ellenőrző pont segítségével gyorsan helyreálljon)

Ebben a cikkben a szerzők azzal érvelnek, hogy a rendszerek tervezése a működés korlátozásainak és természetének, a hibáknak és a viselkedésnek a figyelembevételével gyakran törékeny és kiszámíthatatlan rendszerekhez vezet. Gyökeresen eltérő megközelítésre van szükség az olyan rendszerek felépítéséhez, amelyek robusztusabbak a hiba esetén.

Ez a különböző tervezési paradigma az, amelyben a rendszereknek a lehető legjobb esélye van a stabil viselkedésnek (olyan technikák révén, mint a túlképzés, a belépés ellenőrzése és az önellenőrzés), valamint a váratlan helyzetekhez való alkalmazkodás képességének (az önellenőrzést visszajelzésként kezelve) egy zárt vezérlőhurokhoz). Végül a rendszereket úgy kell megtervezni, hogy kevésbé kezeljék a hibákat, mivel a bonyolultság elkerülhetetlen kiszámíthatatlansághoz vezet.