Robusnost u složenim sustavima: sažetak akademskog članka

Fotografija Vladimira Kudinova na Unsplash-u

Danas ćemo gledati članak pod naslovom „Robusnost u složenim sustavima“ koji je 2001. objavio Steven D. Gribble. Svi citati i brojke povuku se s papira.

Ovaj rad tvrdi da je zajednička dizajnerska paradigma za sustave u osnovi pogrešaka, što rezultira nestabilnim, nepredvidivim ponašanjem kako kompleksnost sustava raste.

„Zajednička dizajnerska paradigma“ odnosi se na praksu predviđanja okruženja u kojemu će sustav raditi i njegovih modusa neuspjeha. U radu se navodi da će se sustav baviti uvjetima koji nisu bili predviđeni jer postaje složeniji, tako da bi trebao biti osmišljen tako da se pristojno suoči s neuspjehom. U radu se istražuju ove ideje uz pomoć „distribuiranih podataka (DDD), skalabilnog poslužitelja za pohranu temeljenog na klasterima“.

Veliki sustavi po svojoj prirodi djeluju kroz složenu interakciju mnogih komponenti. Ta interakcija dovodi do prožetog povezivanja elemenata sustava; ovo povezivanje može biti snažno (npr. paketi poslani između susjednih usmjerivača u mreži) ili suptilni (npr. sinkronizacija usmjeravanja reklama širom mreže).

Zajednička karakteristika koju izlažu ovako veliki sustavi je nešto što se naziva efekt leptira. To se odnosi na mali neočekivani poremećaj u sustavu koji je posljedica zamršene interakcije različitih komponenti koja uzrokuje široku promjenu.

Zajednički cilj dizajna sustava je robusnost: sposobnost sustava da ispravno radi u različitim uvjetima i graciozno ne uspije u neočekivanoj situaciji. Rad se protivi uobičajenom obrascu pokušaja predviđanja određenog skupa operativnih uvjeta za sustav i arhitektonskog projektiranja da dobro funkcionira samo u tim uvjetima.

Također je učinkovito nemoguće predvidjeti sve poremećaje koje će sustav doživjeti kao rezultat promjena u okruženju, poput kvarova hardvera, pucanja opterećenja ili uvođenja softvera koji se loše ponaša. S obzirom na to, vjerujemo da je svaki sustav koji pokušava steći robusnost isključivo putem predznanja, sklon krhkosti.

DDS: studija slučaja

Gore spomenuta hipoteza istražuje se pomoću skalabilnog sustava pohrane temeljenog na klasterima, distribuiranih struktura podataka (DDD) - „virtualne hash tablice visokog propusnog kapaciteta koja je podijeljena i replicirana kroz mnoge pojedinačne čvorove za pohranu koji se nazivaju cigla“.

Ovaj je sustav izgrađen koristeći prediktivnu filozofiju dizajna kao gore opisanu.

Na temelju velikog iskustva s takvim sustavima, pokušali smo razmotriti ponašanje softverskih komponenti, algoritama, protokola i hardverskih elemenata sustava, kao i radno opterećenje koje bi ono dobivalo.

Kad je sustav funkcionirao u okviru pretpostavki dizajnera, dobro je funkcionirao. Oni su bili u mogućnosti to skalirati i poboljšati performanse. Međutim, u slučaju kada je prekršena jedna ili više pretpostavki o radnim uvjetima, sustav se ponašao neočekivano, što je rezultiralo gubitkom podataka ili nedosljednošću.

Dalje, govorimo o nekoliko takvih anomalija.

Skladište za smeće i sinhronizacija granica

Dizajneri sustava koristili su vremenske ograničenja kako bi otkrili kvar kvarova u sustavu. Ako određena komponenta nije reagirala u određenom roku, smatrat će se mrtvom. Pretpostavili su ograničenu sinkronost u sustavu.

DDS je implementiran u Javi, pa je iskoristio skupljanje smeća. Skupljač smeća u našem JVM-u bio je sakupljač otpadaka i pometnja; Kao rezultat toga, kako su aktivniji predmeti boravili u hrpi JVM-a, povećava se trajanje koje bi skupljao smeće kako bi skupio fiksnu količinu memorije.

Kad je sustav bio na zasićenju, čak i male razlike u opterećenju cigle povećale bi vrijeme koje oduzima sakupljač smeća zauzvrat, smanjujući propusnost opeke. To se naziva GC thrashing. Pogođene opeke zaostale bi za svojim kolegama što bi dovelo do daljnje degradacije performansi sustava.

Dakle, sakupljanje smeća narušilo je pretpostavku o ograničenoj sinkroniji kada se bliži ili iznad točke zasićenja.

Usporavanje istjecanja i propusti povezani

Druga pretpostavka napravljena prilikom dizajniranja sustava bila je da su kvarovi neovisni. DDS je upotrijebio replikaciju kako bi napravio sustav neispravan. Vjerojatnost neuspjeha višestrukih replika bila je vrlo mala.

Međutim, ova je pretpostavka prekršena kada su u svom kodu naišli na stanje utrke, što je prouzročilo curenje memorije bez utjecaja na ispravnost.

Kad god smo lansirali naš sustav, skloni smo istodobno lansirati sve opeke. S obzirom na približno izbalansirano opterećenje u cijelom sustavu, sve bi cigle gotovo istodobno isticale iz hrpe, nekoliko dana nakon što su lansirane. Također smo nagađali da su naši mehanizmi za automatsko zaustavljanje pogoršali ovu situaciju povećavajući opterećenje replike nakon što kolega nije uspio, povećavajući brzinu kojom je replika procurila u memoriju.

Budući da su sve replike podvrgnute jednoličnom opterećenju bez uzimanja u obzir smanjenja performansi i drugih problema, to je stvorilo vezu između replika i ...

… U kombinaciji s sporim curenjem memorije dovode do kršenja naše pretpostavke neovisnih kvarova, što je zauzvrat uzrokovalo da naš sustav doživi nedostupnost i djelomični gubitak podataka

Neprovjerene ovisnosti i zaustavljanje neuspjehom

Na temelju pretpostavke da ako neka komponenta istekne, nije uspjela, dizajneri su također pretpostavili kvarove „fail-stop“, tj. Komponenta koja nije uspjela ponovno će početi funkcionirati nakon nekog vremena. Cigle u sustavu izvodile su sve dugotrajne radnje (disk I / O) na asinhroni način.

Međutim, nisu primijetili da su neki dijelovi koda koristili blokirne pozive. To je uzrokovalo da nasumično posuđuje glavni konac za rukovanje događajima, što je dovelo do toga da se cigle neprimjetno uhvate nekoliko minuta i nastave s postom.

Iako je do ove pogreške došlo zbog vlastitog neuspjeha u provjeri ponašanja koda koji smo koristili, ona nam pokazuje da interakcija na niskoj razini između neovisno izgrađenih komponenti može imati duboke posljedice na cjelokupno ponašanje sustava. Vrlo suptilna promjena u ponašanju rezultirala je kršenjem naše pretpostavke za zaustavljanje u cijelom klasteru, što na kraju dovodi do korupcije podataka u našem sustavu.

Prema robusnim sustavima

.. male promjene u složenom, spojenom sustavu mogu rezultirati velikim, neočekivanim promjenama u ponašanju, moguće izvođenjem sustava izvan očekivanog radnog režima njegovih dizajnera.

Nekoliko rješenja koja nam mogu pomoći u stvaranju snažnijih sustava:

Sustavno prekomjerno osiguravanje

Kada se približavaju točki zasićenja, sustavi postaju krhki kada pokušavaju prilagoditi neočekivanom ponašanju. Jedan od načina borbe protiv toga je namjerna prekomjerna opskrba sustava.

Međutim, to ima svoj skup problema: to vodi do nedovoljne upotrebe resursa. Također zahtijeva predviđanje očekivanog radnog okruženja, a samim tim i točke zasićenja sustava. U većini slučajeva to se ne može obavljati na precizan način.

Koristite kontrolu prijema

Druga tehnika je započeti odbacivanje opterećenja nakon što se sustav počne približavati točki zasićenja. No, ovo zahtijeva predviđanje točke zasićenja - nešto što nije uvijek moguće, posebno s velikim sustavima koji imaju puno varijabli koje pridonose.

Odbijanjem zahtjeva također se troše određeni resursi iz sustava. Usluge dizajnirane s obzirom na kontrolu prijema obično imaju dva načina rada: uobičajeni gdje se zahtjevi obrađuju i izuzetno lagan način gdje su odbijeni.

Ugradite Introspection u sustav

introspektivni sustav je onaj u kojem je sposobnost praćenja sustava osmišljena od početka.

Kad se sustav može nadgledati, a dizajneri i operatori mogu izvesti smislena mjerenja o svom radu, to je mnogo robusniji od sustava s crnom kutijom. Lakše je prilagoditi takav sustav promjeni svog okruženja, kao i njime upravljati i održavati ga.

Uvedite prilagodljivost zatvaranjem upravljačke petlje

Primjer upravljačke petlje su ljudski dizajneri i operatori koji prilagođavaju dizajn kao odgovor na promjenu u radnom okruženju naznačenu različitim mjerenjima. Međutim, vremenska crta za takvu kontrolnu petlju nije baš predvidljiva. Autori tvrde da bi se sustavi trebali graditi s unutarnjim upravljačkim petljama.

Ovi sustavi uključuju rezultate introspekcije i pokušavaju dinamički prilagoditi upravljačke varijable kako bi sustav funkcionirao u stabilnom ili dobro izvedenom režimu.
Svi takvi sustavi imaju svojstvo da je komponenta koja izvodi adaptaciju u stanju donekle precizno pretpostaviti o učincima prilagodbe; bez ove sposobnosti sustav bi „radio u mraku“ i vjerojatno bi postao nepredvidiv. Novi, zanimljiv pristup hipoteziranju o učincima prilagodbe je korištenje statističkog strojnog učenja; S obzirom na to, sustav može eksperimentirati s promjenama kako bi izgradio model njihovih učinaka.

Planirajte neuspjeh

Složeni sustavi moraju očekivati ​​neuspjeh i planirati ga u skladu s tim.

Par tehnika za to:

  1. rastavljanje komponenata da lokalno sadrže kvarove
  2. minimiziranje štete korištenjem robusnih apstrakcija kao što su transakcije
  3. minimalizirati vrijeme u stanju neuspjeha (pomoću kontrolne točke za brzo oporavak)

U ovom radu, autori tvrde da oblikovanje sustava pretpostavljajući ograničenja i prirodu njegovog rada, kvarova i ponašanja često dovodi do krhkih i nepredvidivih sustava. Potreban nam je radikalno drugačiji pristup kako bismo izgradili sustave koji su snažniji u slučaju kvara.

Ova drugačija dizajnerska paradigma je ona u kojoj se sustavima pruža najbolja moguća šansa za stabilno ponašanje (tehnikama poput prekomjerne odredbe, kontrole prijema i introspekcije), kao i sposobnost prilagođavanja neočekivanim situacijama (tretiranjem introspekcije kao povratne informacije u zatvorenu upravljačku petlju). Konačno, sustavi moraju biti dizajnirani za graciozno rješavanje problema, jer složenost izgleda vodi do neizbježne nepredvidivosti.