Zátěž ve webových informačních systémech

Abstrakt: Jedním z problémů otevřených univerzitních informačních systémů založených na webových technologiích je proces správného rozvržení zdrojů pro obsluhu často proměnlivé uživatelské zátěže související například s charakterem semestrální výuky na univerzitách. Nesprávné stanovení kapacit jednotlivých komponent může během provozu způsobit podstatné zhoršení kvality poskytovaných služeb na jedné straně a případně neúměrné plýtvání prostředků na straně druhé. Příspěvek má za cíl představit některé možné metody řešení těchto problémů, které byly vyvinuty a v praxi nasazeny v rámci provozu Informačního systému Masarykovy univerzity na vysokých školách různých velikostí a způsobů řízení výuky. Diskutovány budou také aktuální výsledky vývoje v oblasti technologií pro řešení takzvaných lokálních přetížení.

1. Úvod

Cílem tohoto příspěvku je diskutovat známé přístupy, které se obvykle uplatňují při rozhodování o vhodných způsobech rozvržení zátěže, a zejména poskytnout praktické zkušenosti z této oblasti, které byly postupně získány na Masarykově univerzitě. Informační systém Masarykovy univerzity (IS MU) slouží jako jediná platforma pro realizaci univerzitní agendy související se studiem, univerzitní komunikaci a integraci nástrojů pro elektronickou podporu výuky napříč všemi devíti fakultami a dalšími univerzitními pracovišti. V současné době využívá jeho služeb přibližně 40.000 aktivních uživatelů, což představuje denní zátěž téměř dvaceti tisíců uživatelů, kteří provedou až 1,5 milionu autentizovaných webových transakcí za den. Zvláštní skupinou uživatelů, která se výrazně podílí na celkovém zatížení systému, jsou pak uchazeči o studium, kteří v rámci nyní již výhradně elektronicky vedeného přijímacího řízení v systému spravují více než 50.000 elektronických přihlášek ke studiu.

V první části příspěvku se zaměříme na zatížení systému při běžném provozu, který musí být systémem obsloužen bez toho, aniž by docházelo k prodlevám a zpomalením. Proto je nutné zvolit dostatečně flexibilní postupy, které jsou schopny přímo reagovat na změny v zátěži během životního cyklu jednotlivých subsystémů. Další část představuje problém a řešení tzv. lokálního přetížení, během kterého dochází k dočasnému navýšení počtu uživatelských požadavků výrazně nad rámec běžného provozu a je proto nutné obsluhu tohoto typu zátěže řešit odděleně.

2. Zatížení normálního provozu

Z hlediska běžné denní zátěže však tato evidence tradičního studia představuje pouze část z celkového množství a náročnosti uživatelských dotazů, která se obvykle ve větší míře projevuje na začátku a konci každého semestru, zatímco během samotné výuky v semestru a uprostřed prázdnin přístup k těmto aplikacím evidenčního charakteru klesá. Se stále rostoucím vlivem studijních informačních systémů na průběh samotného studia formou rozmanitých metod elektronické podpory výuky, jako jsou interaktivní studijní materiály, elektronické testy, diskuse, týmové projekty, multimediální prvky a řada dalších, vzniká při jejich naprosto nezbytné úzké integraci se systémem evidence studia další typ zátěže, se kterou se musí provozovatel systému vyrovnat.

S tímto prakticky soustavně rostoucím rozsahem služeb poskytovaných systémem roste také počet uživatelů, kteří na něj kladou zcela nové požadavky a tím permanentně roste zatížení systému. Daný nárůst byl navíc v posledních letech doprovázen postupným vzestupem celkového počtu studentů na vysokých školách v našem regionu a také stále rostoucím počtem uživatelů schopných využít nové prostředky.

Tento stav, kdy systém musí zajistit dostatečnou odezvu na všechny běžné uživatelské požadavky během semestrů i mezi nimi, budeme v následujícím textu považovat za normální provoz, pro který je nutné všechny výpočetní zdroje uvnitř systému optimalizovat tak, aby nedošlo k jejich přetížení. Další situace, při kterých může docházet k přetížení vlivem dočasného abnormálního nárůstu požadavků budou zmíněny v následující kapitole.

Zaměřme se tedy na provoz webového univerzitního informačního systému, který zajišťuje velké množství služeb pro podporu studia na univerzitě. Základem pro provoz systému jsou na jedné straně koncové klientské stanice tvořené běžným internetovým prohlížečem bez ohledu na to, zda je tímto koncovým zařízením standardní osobní počítač, mobilní telefon nebo jiné komunikační zařízení. Odhlédneme-li od nutnosti zajištění alespoň minimálního počtu volně přístupných koncových stanic případně síťových přípojek pro studenty i zaměstnance, ke kterému musí univerzita pro úspěšné nasazení systému přistoupit, není tato část přímo doménou zajištění provozu systému.

Další součásti v architektuře webových systémů tvoří prezentační (webové servery) a aplikační vrstva. Zde se již obvykle zřetelně projevuje správné rozvržení výpočetních kapacit při rostoucí zátěži. Vzhledem k tomu, že aplikační servery provozují v běžném případě na sobě téměř nezávislé aplikace, je možné pro škálovatelnost výkonu této části systémy nasadit vysoce distribuované prostředí, kdy je aplikační zátěž distribuována na více výpočetních uzlů prezentačního/aplikačního clusteru. Vzájemná nezávislost aplikací pak zajišťuje na této úrovni téměř lineární nárůst výkonu při pouhém navýšení počtu uzlů v clusteru. Výhodou tohoto řešení pak je možnost využití komoditního hardwarového vybavení s nízkými náklady na pořízení a provoz.

Poslední vrstvou webového systému je databázová část, která poskytuje souběžný přístup k většině údajů udržovaných v systému pro všechny uzly aplikačního clusteru. Na rozdíl od aplikační vrstvy dochází v tomto případě velmi často k pevnému svázání více souběžných požadavků navzájem v případě, kdy tyto požadavky přistupují a modifikují stejná data. Výkon a od něj odvozené zatížení systému tak záleží nejen na výkonu zpracování jednoho požadavku, ale i na vzájemné komunikaci mezi jednotlivými požadavky.

Odhlédněme nyní od měření rychlosti zpracování jednoho požadavku, která je dána zejména rychlostí procesoru, na kterém se požadavek zpracovává (případě rychlosti více procesorů u požadavků umožňujících paralelní zpracování databázových dotazů), rychlostí a velikostí vyrovnávacích a operačních pamětí spotřebovávaných procesorem a celkové rychlosti vstupně výstupního rozhraní a předpokládejme, že zpracování samostatných požadavků poskytuje vždy dostatečný výkon, což je dáno zejména správným návrhem a implementací aplikace případně optimalizací jednotlivých komponent. Cílem při zvládání zátěže pro nás nadále bude schopnost zajistit souběžné zpracování velkého a zejména stále rostoucího množství uživatelských požadavků, které spouštěny sériově nebo v malém množství poskytují vždy dostatečnou odezvu.

Problém správné obsluhy uživatelské zátěže v normálním provozu se tak omezuje na problém správného nastavení zmiňovaných výpočetních zdrojů uvnitř databázové vrstvy. Správná architektura systému by měla umožnit více méně rovnoměrné rozložení zátěže během normálního provozu mezi všechny tři vrstvy tak, aby systém nebyl zatížen pouze na jedné části, nebo naopak většina součástí nezůstala během normálního provozu nevytížena.

V případě, že je znám celkový počet uživatelů, kteří do systému přistupují a s tím související předpokládaná zátěž systému tvořená uživatelskými požadavky, je možné stanovit velikost zdrojů všech součástí. V případě prezentační a aplikační vrstvy jsou kapacity optimalizovány přímo počtem uzlů v distribuovaném prostředí, tedy počtem serverů v daném clusteru. V případě databázového subsystému je obvykle nutné přistoupit k nasazení vhodného víceprocesorového výpočetního systému se sdílenou pamětí daného rozsahu.

Skutečný problém nastává ve chvíli, kdy například po delším čase běžného provozu nebo vývoje (nelze však vyloučit ani případné chyby při počátečním určení předpokládaného rozsahu zátěže) normální uživatelská zátěž vzroste tak, že některá z komponent přestane poskytovat dostatek prostředků pro zvládnutí této zátěže a dojde k přetížení. V takovém případě je vždy nejprve nutné přistoupit k ladění aplikací a samotného systému na mnoha úrovních. Může se však stát, že výpočetní výkon, který dosud plně dostačoval, přirozený nárůst požadavků nemůže fyzicky zvládnout. V takovém případě je nutné přistoupit k navýšení prostředků daného subsystému.

Jak již bylo zmíněno, navýšení výpočetních zdrojů prezentační a aplikační vrstvy je možné provést pouhým přidáním nových uzlů příslušného clusteru, což je obvykle nejjednodušší metoda, která nevyžaduje podstatnou zátěž na instalaci a optimalizaci stávajících součástí. V případě využití komoditních komponent je případně možné po ukončení faktické životnosti danou hardwarovou součást povýšit za rychlejší nebo propustnější součást, která je na trhu téměř vždy dostupná.

Naproti tomu navýšení zdrojů databázového subsystému nemusí být vždy tak jednoduché. Pouhé přidání fyzicky nezávislého uzlu clusteru zde není možné. Některé systémy se sdílenou pamětí umožňují povýšení zdrojů i v rámci jednoho systému. Tento přístup má však několik nevýhod. Zejména je nutné při počáteční investici počítat s tím, že může dojít k tomuto navýšení a tím vlastně dopředu vynaložit nemalé investice za něco, co nemusí být v budoucnu využito. Další praktickou nevýhodou je celková náročnost tohoto řešení. Zatímco aplikační vrstva může být povýšena pouhým duplikováním stávajících uzlů na nové servery bez zásahu do nich samotných, povýšení víceprocesorového systému se sdílenou pamětí vyžaduje obvykle složité hardwarové i softwarové operace na stávajícím řešení. Rozhodně tak není jednoduše možné navýšit výkon podle potřeby například pouze dočasně.

Následující odstavce představí obecně známé metody řešení tohoto problému a unikátní přístup, který byl velmi úspěšně nasazen při provozu IS MU v minulých dvou letech.

2.1. Obecné způsoby obsluhy normálního provozu

Přestože toto moderní řešení přináší řadu výhod a je zřejmě vhodným kandidátem pro zaměření pozornosti při dalším vývoji rozsáhlých otevřených systémů, v praxi se ukazuje, že komunikační nároky při opravdu masivním současném přístupu tisíců uživatelů ke stejným datům není efektivní zajišťovat distribuovaným zpracováním. Celkový nárůst výkonu tak velmi závisí na použité aplikaci a vhodnosti konkrétních aplikací adaptovat se do distribuovaného prostředí.

Přestože existují databázové produkty, které zajišťují transparentní přístup aplikací k databázové vrstvě bez ohledu na to, zda je interně implementovaná jako systém se sdílenou pamětí nebo databázový cluster, při vysoké zátěži, o kterou nám však v tuto chvíli jde nejvíce, dochází k velmi vysokému poklesu výkony ve srovnání se systémy se sdílenou pamětí. V některých případech je tak nutné sdílet zdroje pouze mezi dvěma databázovými uzly, existují však praktické příklady, které ukazují, že efektivního využití při zátěži je možné docílit pouze v případě systémů se sdílenou pamětí.

2.2. Víceúrovňové databázové clustery a řešení MU

Alternativní řešení tzv. víceúrovňových databázových clusterů, které bylo při vývoji a provozu IS MU nasazeno, vychází rovněž z myšlenky clusterování. V tomto případě jsou však vytvářeny clustery na více úrovních (jakoby clustery clusterů). První úroveň tvoří klasický databázový cluster se sdíleným diskovým přístupem, který slouží výhradně pro zajištění dostupnosti (uzly této úrovně se dokáži vzájemně nahradit v případě výpadku některého z nich). Hlavní provoz během běžné zátěže je však směrován pouze na jeden uzel. Tento uzel clusteru první úrovně je pak implemetnován opět jako cluster nezávislých uzlů druhé úrovně, které však dohromady tvoří jednu sdílenou pamět. V dalších úrovních je dále možné vytvářet clustery diskového uložiště v případě, že je nutné navýšit výkon na této součásti.

Výhodou tohoto řešení je možnost relativně snadného navýšení databázového výkonu pouhým přidáním nového fyzicky nezávislého uzlu do clusteru druhého úrovně, ovšem za současného zachování vysoké propustnosti, která je dána přímým přístupem do paměti napříč jednolivými uzly a tedy i procesy databázového serveru pomocí prostředků operačního systému. Tím lze technicky dosáhnout velmi jednoduchého a tedy i dočasného navýšení výkonu databázové vrstvy kdykoliv v případě navýšení objemu běžných požadavků kladených na systém.

3. Lokální přetížení

Je zřejmé, že metody zmíněné v předchozí kapitole pro optimalizaci výkonu jednotlivých komponent není možné v tomto případě využít, neboť systém by byl optimalizován na velmi krátkou dobu časových špiček a ve většině případů zbytečně předimenzován. Přirozeným řešením tohoto problému je zřejmě odstranění příčiny časové soutěže, tedy například stanovení jiných vhodných kritérií, na základě kterých by se daná komodita rozdělila bez ohledu na konkrétní dobu, kdy daný soutěžící projevil o komoditu zájem. Navíc v případě velkých rozdílů mezi poptávkou a nabídkou (kapacitou) je technická realizace on-line časové soutěže závislá na řadě náhodných faktorů, které mohou v konečném důsledku vést k fakticky náhodnému pořadí vítězů.

Přesto se v praxi nejednou setkáváme s případy, kdy dochází k lokálnímu přetížení i v případě, které není možné ovlivnit změnou pravidel nebo přirozeným omezením současně pracujících uživatelů. V takovém případě je nutné využít sofistikované technické metody, které umožní alespoň omezit negativní vlivy lokálního přetížení na běžný provoz systému. Jednou z možností je metoda tzv. adaptivního zpracování požadavků. Cílem tohoto přístupu je v rozsahu možností daných omezenou kapacitou systému během lokálního přetížení pokud možno ponechat běžný provoz bez jakéhokoliv omezení a naopak automaticky detekovat ty požadavky na systém, které mohou mít na lokální přetížení vliv. V takovém případě systém sám detekuje hrozící přetížení a adaptuje zpracování požadavků tak, že běžné požadavky provádí v rámci svého provozu bezprostředně po jejich přijetí (jako obvykle), zatímco automaticky detekované přetěžující požadavky pozastaví a zpracovává zcela odděleně.

Důležitou součástí tohoto systému pak je bezprostřední (pouze v rámci relativně malé režie) reakce systému nejen formou legitimní odpovědi (u běžných požadavků), ale také jako informace o tom, že v rámci zpracování přetěžujícího požadavku došlo k odložení. Výsledkem tohoto přístupu pak je stav, kdy systém transparentně zpracovává požadavky běžných uživatelů ve stejné kvalitě jako při normálním provozu (fakticky on-line bez jakéhokoliv zdržení), zatímco požadavky soutěžících jsou pozdrženy, což však pouze zvyšuje zmiňované náklady na straně soutěžícího. Systémové zdroje jsou využívány omezeně v rámci dostupné kapacity s možností přesné regulace bez ohledu na celkový počet soutěžících.

4. Technické řešení

Jako základ pro webový přístup slouží libovolný webový prohlížeč, který komunikuje se systémem pomocí zabezpečeného protokolu HTTPS. Na straně serveru je poté zátěž distribuována na síťové vrstvě mezi uzly prezentačního clusteru, který je realizován pomocí HTTP serverů projektu Apache. Prezentační vrstva je pak úzce spjata s vlastním aplikačním prostředím založeném na programovacím prostředí jazyka Perl, které realizuje celou řadu aplikačních služeb včetně správy většiny tzv. read-mostly údajů. Datová vrstva pro hlavní údaje spravované systémem je poté realizována jako víceúrovňový databázový cluster, který využívá pro realizaci druhé úrovně systému sdílené paměti NUMAFlex společnosti SGI. Samotný databázový cluster první úrovně pak zajišťují dvě instance databázového serveru Oracle Databáze Enterprise Edition spolu s technologií Real Application Clusters. Jako jednotící operační platforma všech součástí slouží operační systém Linux. Zvláštní technickou realizaci pro manipulaci s velkým objemem dat zajišťuje vlastní distribuované úložiště, které je mimo jiné optimalizováno pro obsluhu zátěže související s přístupem k objemným údajům (studijní materiály, videa, obrazy CD a pod).