Nefunkční požadavky softwarové architektury

Při návrhu systému se IT architekt musí řídit byznys požadavky, které mu byly při návrhu systému předloženy od zákazníka. Systém musí tyto požadavky naplnit, aby podporoval byznys cíle dané společnosti a v ideálním případě tvořil konkurenční výhodu. IT architekt však musí při návrhu systému myslet ještě na jednu skupinu požadavků, pokud chce vybudovat kvalitní a pro společnost konkurenceschopný software. Danou skupinou jsou nefunkční požadavky tzv. Service-level requirements (někdy také nazývány quality of service requirments). I tyto požadavky mají mnohdy kritický vliv na aplikaci, ale jejich samotným úkolem však není podpořit byznys cíle, ale vyvinout kvalitní stabilní aplikaci a její kvalitu měřit podle kritérií, kterých si u dané aplikace zákazník nejvíce cení. Mezi základní požadavky patří výkon, škálovatelnost, spolehlivost, rozšiřitelnost, udržitelnost, spravovatelnost a bezpečnost. Při volbě požadavků, které jsou pro systém nejdůležitější, musejí architekt ve spolupráci se zákazníkem počítat s tím, že se jednotlivé požadavky vylučují navzájem. Chceme-li například navrhnout a realizovat systém, který si bude zakládat na vysokém výkonu, musíme obětovat požadavky, jako jsou udržitelnost a rozšiřitelnost. Musíme tedy počítat s tím, že rychlost naší aplikace bude vykoupena například tím, že v budoucnu budeme muset investovat více prostředků pro rozšíření dané aplikace o novou funkčnost.

Výkon

Výkon jako požadavek na systém, je často měřen jako doba reakce systému na uživatelův požadavek. Dále může být výkon měřen jako počet transakcí provedených za určitý časový úsek, obvykle se měří počet transakcí za 1 sekundu. Bez ohledu na měření musí IT architekt vytvořit takovou architekturu, která poskytuje možnost designérům a vývojářům dokončit systém bez toho, aby se lidé na těchto pozicích příliš nezabývali měřením výkonu.

Propustnost

Práce, kterou musí aplikace vykonat za časovou jednotku. Propustnost může být měřena dvěma způsoby.

Počet transakcí za sekundu (tps)
Počet zpracovaných zpráv za sekundu (mps)

Spolu s propustností musíme řešit otázku toho, jestli řešit průměrnou propustnost nebo propustnost na vrcholu. S tím samozřejmě souvisí poté i náklady spojené s provozem daného systému.

Doba odezvy

Doba odezvy by se dala charakterizovat jako zpoždění při zpracování byznys transakce nebo pokud chceme zařadit dobu odezvy do kontextu internetu, tak by se dalo mluvit o čase, který je spojen s vystavením odpovědi zákazníkovi. Rychlá doba odezvy může zefektivnit práci se systémem, naopak špatná doba odezvy může dokonce odradit samotné uživatele systému. Příklad požadavku na dobu odezvy může znít:

95% žádostí zpracovat do 4 sec a žádná žádost nesmí trvat déle než 15 sec

Blokování

Zpracování požadavku může být zpožděno nebo blokováno kvůli potřebě vyčkat na uvolnění zdrojů nebo na nutnost ukončení procesu, na který další proces navazuje.

Následující techniky jsou používány ke zvýšení výkonu systému

Zvýšení kapacity přidáním dalších jednotek podporující rychlost zpracování.
Zvýšení výpočetního výkonu použitím vhodných algoritmů a technik.

Další techniky podporující redukování výpočetního přetížení systému

Zavedení paralelních výpočtu v případech, kde je to možné.
Zavedení limitu na počet požadavků, které mohou být zpracovávány v jednu dobu.
Zavedení průběžných odpovědí na požadavky uživatele, aby uživatel nabyl dojmu výkonného systému.
Zavedení Timeout na dlouhotrvající transakce. Zejména platí pro ty transakce, které kooperují s externími systémy.

Škálovatelnost

Škálovatelnost je schopnost podpořit kvalitu služeb tím, že zvýšíme kapacity systému bez toho, aby došlo ke změnám v software. Systém může být považován za škálovatelný poté, kdy poskytuje požadovaný výkon i v době, kdy jsou na něj kladeny vyšší nároky od uživatelů. Například akceptovatelný limit pro odpověď na uživatelův požadavek může být od 2-5 sekund. K tomu, abychom pochopili škálovatelnost systémů, tak si musíme definovat kapacitu systémů. Kapacita systémů může být definována například jako počet simultánně běžících procesů nebo počet online uživatelů. Pokud systém umí navyšovat kapacity podle toho, jaké jsou zrovna na software vyvíjeny nároky, a neustále drží požadovaný výkon na akceptovatelném limitu, tak se jedná o dobře škálovatelný systém.

Zatížení žádostmi (Request Load)

Proto, abychom dobře škálovali systém, tak je zapotřebí přidat nový hardware. Hardware může být přidán buď vertikálně (Scale up), nebo horizontálně (Scale out). Vertikální škálování znamená přidání procesorů, paměti nebo disků k současnému hardware. Na druhou stranu horizontální škálování znamená přidání rovnou dalších nových serverů do současného systému a tím celkově zvýšit kapacitu. Naše architektura musí být taková, aby bylo možné využít oba dva typy škálování. Obecně s vertikálním škálováním nebývá problém, protože přidání nových procesorů nebo paměti nemá vliv na architekturu, ale s tím, aby systém běžel na více serverech a přitom se tvářil, jako by běžel na jednom, může být problém. Vertikální škálování je vhodné v případě pokud se jedná o vícevláknové aplikace, zatímco horizontální škálování se používá, pokud jsou minimální nároky na distribuci žádostní a komunikace mezi jednotlivými zařízeními.

Paralelní připojení

Každý systém by měl vědět na kolik paralelní uživatelů/žádostí je škálovaný. Dále by každý systém měl mít vypracované řešení na otázku, jak bude reagovat v případě zvýšení počtu paralelně připojených uživatelů. S touto problematikou souvisí to, jaké zdroje uživatelé využívají. Používají-li nějaké externí aplikace, tak i ty musí být škálované na potřebné množství uživatelů, aby nedošlo k tomu, že uživatelé budou čekat na uvolnění těchto zdrojů.

Udržitelnost

Udržitelnost definuje schopnost opravení nedostatků systému bez toho, aby se ovlivnila některá další část. Tudíž pokud je systém vhodně rozdělen do komponent, tak je možné opravit pouze tu komponentu, ve které se problém vyskytl a nemusí být brán v úvahu celý systém. K tomu, abychom toho docílili, potřebujeme systém, která má velice nízké provázání jednotlivých komponent, tudíž můžeme mluvit o vysoké modularitě systému. Dále pro vysokou udržitelnost systému je zapotřebí vést kvalitní dokumentaci jako samotného kódu, tak architektury systému.

Spolehlivost

Spolehlivost zajišťuje integritu a konzistenci aplikací a všech jejích transakcí. I při zvýšené zátěži musí systém pokračovat ve zpracování žádostí od uživatele a zpracovávat transakce tak, jak by je systém zpracovával v době, kdy je náročnost menší. Spolehlivost jde ruku v ruce se škálovatelností. Pokud totiž systém nemůže při zvýšených nárocích být spolehlivý, tak určitě nemůže být ani škálovatelný. Naopak pokud je systém opravdu škálovatelný, tak je zároveň i spolehlivý ohledně integrity a konzistence transakcí.

Dostupnost

Dostupnost znamená, že v každém momentu jsou přístupné všechny služby nebo zdroje daného systému. Spolehlivost může přispívat k dostupnosti, ale dobré dostupnosti může být dosaženo i v případě, že daná komponenta selže. Pokud v daném prostředí nastavíme redundantní počet komponent a jedna komponenta selže, tak to bude mít negativní vliv na spolehlivost, ale služba může být i nadále dostupná díky dané redundanci.

Faktory ovlivňující dostupnost systému

Pád systému – Systém může padnout například vinou selhání hardware, software, sítě nebo aplikační komponenty.
Dlouhotrvající odpověď na požadavek klienta – Pokud klient nedostane od systému vygenerovanou odpověď na svůj požadavek v dostatečně rychlé době, může být systém považován za nedostupný.

Zvýšení dostupnosti systému může být dosaženo jedním ze dvou typů replikace přebytečného hardware nebo softwarových komponent:

Aktivní replikace – Požadavek je odeslán na všechny paralelně pracující komponenty, které zpracovávají požadavek, následně ho synchronizují a odpověď však vrátí pouze jedna komponenta.
Pasivní replikace – Pouze jedna z replikovaných komponent obdrží odpověď (primární komponenta) a ta má za úkol vygenerovat odpověď. Stav ostatních komponent (sekundární komponenty) je synchronizován s primární komponentou. V případě selhání primární komponenty může být stav nahrán ze sekundárních komponent.

Rozšiřitelnost a modifikovatelnost

Rozšiřitelnost je schopnost přidat novou funkcionalitu nebo modifikovat stávající funkcionalitu bez toho, aby se ovlivnil existující systém. Rozšiřitelnost se nedá měřit v případě, když je systém nahrán na produkci, ale ukáže se až v době, kdy potřebujeme rozšířit funkcionalitu systému. Abychom dostáli dobré rozšiřitelnosti, měli bychom zvážit následující možnosti:

Snížit provázání komponent
Využívat rozhraní
Zvyšovat zapouzdření komponent
Kvalitní objektový model

K vytvoření architektury, která bude vhodná k dalšímu rozšiřování, je dobré se držet následujících praktik:

Jasně definovaný rozsah SLA (Service-level agreement) – Tím, že budeme mít jasně definovaný rozsah systému v SLA, se můžeme vyvarovat neočekávaných změn na funkcionalitu systému.
Předvídejte očekávané změny – Při návrhu architektury můžeme předvídat běžné změny systému, jako například změna uživatelského prostředí. Proto bychom měli mít komponenty, ve kterých je možnost vytvoření změn, držet promyšlené a připravit ho na případné změny. Udržitelnost (Maintainability)

Udržitelnost je schopnost opravení nedostatků bez toho, aby byla ovlivněna některá další část systému. Jedná se o další kritérium kvality systému, které nemůže být měřeno v době nasazení aplikace do provozu, ale až v době, kdy se opravdu musí něco v daném systému změnit. Pro zvýšení udržitelnosti máme tyto možnosti:

Snížit provázání komponent
Vysoká modularita systému
Řádně vedená dokumentace

S tvorbou architektury mohou být i problémy související s přílišnou modularitou systému (Over Engineering). Do systému by nemělo být vloženo více úsilí než by bylo doopravdy potřeba. Architekt v tomto případě myslí i na budoucí požadavky, u kterých je malá pravděpodobnost, že bude potřeba jejich realizace.

Spravovatelnost

Spravovatelnost je schopnost řídit systém a zajistit tak jeho bezproblémový běh a přitom respektovat škálovatelnost, spolehlivost, dostupnost, výkon a bezpečnost. Spravovatelnost se také zabývá monitorováním systému, jestli všechny nefunkční požadavky na systém jsou splňovány. V případě nutnosti může být pomocí konfigurace chování systému upraveno tak, aby byl současný stav nefunkčních požadavků zlepšen, nesmí však dojít ke změně samotného systému. Architektura musí zajistit monitorování systému a dynamickou systémovou konfiguraci.

Bezpečnost

Bezpečnost systému musí zajistit, aby systém nemohl být kompromitován. Jedná se o nejsložitější kritérium, podle kterého můžeme měřit kvalitu systému. Nejen, že systém musí zajistit důvěrnost a integritu, ale musí být zajištěn i proti hackerským úrokům, například proti DoS (Denial-of-Service). Vytvořením architektury, která odděluje komponenty podle funkčnosti, zajistíme jednodušší vytvoření bezpečného systému, protože můžeme vybudovat bezpečnostní zóny kolem komponent. Pokud poté dojde ke kompromitování systému, tak je jednodušší určit, v jaké části systému se tak stalo.

Nejběžnější požadavky na bezpečnost

Autentizace
Autorizace
Šifrování
Integrita – obsah zprávy není změněn při přenosu
Neodvolatelnost – odesílatel měl důkaz o doručení a příjemce si je jist odesílatelovou identitou

Literatura

GORTON, Ian. Essential Software Architecture. Anglie: Springer, 2011. ISBN 3642191754.
CADE, Mark. Sun Certified Enterprise Architect for Java EE Study Guide (2nd Edition). Anglie: Prentice Hall, 2010. ISBN 0131482033.
MICROSOFT PATTERNS & PRACTICES TEAM. Microsoft® Application Architecture Guide. USA: Microsoft Press, 2009. ISBN 978-0-7356-2710-9. Dostupné z: http://msdn.microsoft.com/en-us/library/ff650706.aspx