Odezva v IT řešeních
Onehdá jsem byl přizván ke konzultaci na téma dostupnosti IT, abych po hodině diskuse (kdy jsme si pořád nějak nerozuměli) zjistil, že klienta trápí QoS a jde jen o zmatení pojmů. Tj. že jeho aplikace dává správné výsledky (jsou platné), dává je správně i opakovaně (jsou tedy spolehlivé), dokonce je dává kdykoliv (vše je tedy dostupné) ale "jen" trpí tím, že pro uživatele je odezva nekomfortní, zejména v určité (bohužel pracovní) části dne. Proto se v tomto příspěvku podívejme na otázku QoS, tedy Quality of Service.
QoS => latence Pokud odhlédneme od aplikací, které např. něco řídí a musí udržovat často velice precizní i milisekundové sekvence operací, klíčovým QoS parametrem aplikací v business prostředí je latence na straně uživatelského rozhraní, tj. dosažení a udržení akceptovatelné maximální odezvy z pohledu uživatele. A to jak obecně (kdykoliv), tak speciálně zhoršení latence v určité exponované časy nebo při provádění určitých operací či jejich souběhu. Stejně jako v případě dostupnosti (o tom předchozí článek), i zde je potřeba definovat ze strany managementu (zodpovědného za danou aplikaci):
a) maximální akceptovatelné latence pro vybranou (reprezentativní) sadu operací v rámci konkrétní aplikace – z pohledu latence se jedná typicky o 5 kategorií činností:
bezprostřední odezva na vstup uživatele klávesnicí/myší/dotykovou obrazovkou jako je např. vyplňování formuláře – odezva <100 ms je OK, hodnota 100 - 250 ms je problematická, hodnota nad 400 - 500 ms je zcela nevyhovující;
odezva na rutinní, často prováděné operace, jako je např. výběr položky a zobrazení detailu záznamu, ev. tisk pokladního dokladu/faktury u čekajícího zákazníka, zde se akceptovatelná doba pohybuje vesměs v jednotkách sekund;
přehledové operace, historické vývoje a trendy, tisk běžných dokumentů – vesměs vyhovují hodnoty 5-10 sekund;
sestavy, práce s archivem, generování BI pohledů atp., kde mohou být akceptovány i latence v desítkách sekund či dokonce jednotek minut;
uzávěrky, generování datových kostek, hromadný tisk faktur, rozesílání massmailingů atp., kde se můžeme bavit i o hodinách, výjimečně jednotkách dnů (pokud se jedná o objemy dokumentů ve stovkách tisíc až milionech stran či BigData); a
b) odhadnout náklady, spojené v nevyhovující latencí (QoS), zpravidla se jedná o vícenáklady: - interní – prostoje uživatelů a s tím související ekonomické ztráty i frustrace atp.; - externí – rizika nespokojenosti externích uživatelů ev. jejich ztráty.
Co si navymýšlíte, na to si počkáte! Je potřeba mít na paměti, že požadavky na funkčnost (přidávání operací, zákaznických úprav a integrace na další systémy) vždy povedou ke zhoršení latence a je potřeba dobře zvážit priority. Bohužel, v cílových konceptech se většinou uvádí popis požadované funkčnosti (a čím víc, tím lépe), aniž by byly současně zvažovány a definovány QoS parametry. A při řízení projektů se používá jednoduchý trojimperativ Náklady/Termín/Funkčnost místo modernějšího čtyřimperativu, zahrnujícího i kvalitu - v tomto případě QoS v podobě latence. A výsledek podle toho vypadá ...
Samozřejmě - a to zdůrazňuji - požadavky na určitou garantovanou latenci mohou vést k citelnému prodloužení vývoje, doby a komplikovanosti implementace a samozřejmě navýšení nákladů! Nelze očekávat (ostatně jako u žádného n-imperativu), že jen tak btw zdarma někdo investuje zásadní kapacity navíc .... Proto je tak důležité stanovit nejen max. přípustné latence, ale i vícenáklady při jejich nedodržení, aby bylo jasné, kolik má smysl investovat do zlepšení QoS. Poté se může problémem IT cíleně zabývat =>
Co s tím fantem? Příčin nevyhovující QoS aplikace může být celá řada, zpravidla se jedná o kombinaci těchto hlavních vlivů, které by mělo řešit IT typicky v tomto pořadí:
1) nevhodná koncepce řešení v dané implementaci
Toto je kruciální bod - chybu v koncepci a topologii jen těžko napravíte dalšími "optimalizačními" kroky, zpravidla "jen do času" - a bude třeba se vrátit na začátek ... to je jak s vlhkostí v domě, kdy dodatečné flikování problém nevyřeší. Zde může jít např. o nevhodné sdružení jednotlivých rolí aplikace na jednom serveru - řešením může být pak separace rolí do více serverů a tím lepší škálování výkonu. Někdy může být problém s podporou paralelismu operací se základními (levnými) verzemi databázového prostředí či omezení velikosti paměti RAM, které si pak vynutí přechod na Enterprise verzi. Ale není to samospasitelné, je potřeba mít dobrý důvod jít do citelně dražší platformy!!
2) nevhodná struktura databáze a jejího indexování
V tomto případě se postupuje tak, že se databáze rozdělí na více částí (tzv. partitioning), některé části se přednostně umístí na rychlé disky SSD (TierO/Tier1) ev. do paměti RAM – týká se např. TempDB nebo indexových souborů. V praxi jsme se rovněž setkali s tím, že konkrétní aplikace má problém s latencí při použití více než N indexů. Po jejich redukci (vypuštění těch víceméně duplicitních nebo ne nezbytných) došlo k dramatickému zlepšení.
3) nedostatečně optimalizovaný kód, jak základní aplikace, tak ev. zákaznických programových úprav
U základní aplikace je řešením přechod na novější verzi anebo v nouzi i přepsání některých částí s ohledem na specifické potřeby zákazníka. Zde ovšem s rizikem nutnosti opětovného zásahu při nasazení updatů nebo nové verze. Častější je ale vliv dodatečných zákaznických úprav – ať co do množství, tak do provedení. Zde implementátor (nejsa svázán jasným omezením maximální latence) může volit cestu pohodlnější realizace, naplnit tak požadavky na funkčnost a výsledek je problematický. Cestou je pak revize, respektive optimalizace již napsaného funkčního řešení, kde ale náklady nezřídka dosahují hodnot např. ½ původních nákladů na zákaznické úpravy, proto je lepší tyto požadavky dávat rovnou do CK než se k problému vracet.
4) časový souběh prováděných operací
Např. provádění náročných operací (generování reportů, uzávěrkové operace atp.) v hlavní provozní době – zde přitom nemusí být problém v celkovém zatížení prostředí, ale často v zamykání databáze. Podobný problém může způsobit i zálohování v pracovní době pro dosažení nízkého RPO – lze řešit zálohami pouze transakčních logů, které nejsou tak objemné anebo využití zálohování přes hardwarově (diskovým polem) generované snímky (snapshoty). Relativně často jsou problémem požadavky na on-line generování pohledů do dat, které ale (zvláště nad většími objemy) prostě vyžadují nemalý čas. Řešením pak může být předzpracování (prefetch) těchto pohledů v mimoprovozních časech i za cenu toho, že dále prezentovaná data nebudou až tak 100% aktuální.
5) chybná konfigurace a komponenty prostředí
Sem spadají např. chybné ovladače zařízení, nastavení front, cache, ev. vliv terminálového serveru (je-li použit). Lze prověřit a případně urychlit použitím Tier0 cache na serverech pro potřeby terminálových služeb. Tyto vlivy vesměs mohou být v rozměru desítek %, jistě to není řádové urychlení ... to by musela být v konfiguraci zásadní chyba. V případě, že aplikace využívá webové rozhraní, může být podstatný vliv použitého prohlížeče na klientovi, ev. použitého protokolu. Stejně tak jsou tradičně pomalejší aplikace psané v prostředí Java nebo dalších „makro“ jazycích a je potřeba upřednostnit např. C# kód.
6) Problémy v komunikaci
Zde primárně nedostatečná kapacita při výměně dat po datové síti LAN&WAN, ev. mezi diskovým úložištěm a servery na SAN síti. Zásadní může být vliv (především synchronní) replikace mezi datovými centry v případě řešení s vysokou dostupností. V případě mezinárodních či celosvětových řešení je zde samozřejmě fyzikální omezení dané vzdáleností a omezenou rychlostí elektromagnetického vlnění. Po Evropě zpravidla nebývá problém, ale jakmile uživatelé z Asie či USA pracují proti datovému centru v Evropě, tato vzdálenost zanáší do aplikace latence ve stovkách ms pouze z titulu vzdálenosti. A pokud máte tu smůlu a klienty v kontinentální Číně, přihodí si nemalý časový bonus "Velký bratr" v podobě státního firewallu. Použití urychlovačů přenosů (tzv. shaping), které eliminují duplicity, komprimují data a řídí pořadí přenášených paketů s ohledem na potřebné QoS může být občas řešením, ale ne vždy má až takový efekt, jak výrobce slibuje. A přitom nestojí zrovna málo.
7) latence primárního diskového pole
Pro moderní aplikace je minimální latence zpravidla doporučena na úrovni jednotek ms, což je ale problém dosáhnout s relativně malým počtem (do desítek ks) rotačních pevných disků. Proto se v těchto případech používá kombinace s disky SSD (SSD cache, automatický tiering), ev. kompletní diskové pole SSD, tzv. all-flash, kde není problém dosahovat latencí <1 ms i při milionech IOPS (vstupně-výstupních transakcí za sekundu). Možné problémy mohou být i v nevhodném typu a provedení diskových kontrolérů a komunikační (SAN) infrastruktury mezi servery a diskovým polem; a rovněž v konfiguraci diskového pole (nevhodné RAID, chybné nastavení velikostí bloků). Dopady úprav primárního diskového pole na celkové QoS aplikace pak mohou být až v desítkách %, výjimečně více.
Samozřejmě, vlivů může být ještě více a jejich nejrůznější kombinace představují pokročilé intelektuální cvičení a pracovní nasazení interdisciplinárního týmu složeného ze specialistů na aplikace, databáze, systémáky, síťaře a referenční uživatele. Ale když se chce (a někdo to zaplatí), lze dosáhnout pozoruhodných zlepšení uživatelského komfortu.
