Trend s názvem „horizontální škálování“: kdy má smysl a o co vlastně jde?

Podívejme se blíže na to, co požadavek na horizontální škálování vlastně představuje a odkud pramení.

Hned na úvod je nutné říct, že horizontální škálování je dnes často vyžadováno primárně obchodně, technická stránka požadavků pro možnosti horizontálního škálování často pokulhává. V nejednom případě jde o požadavek, který by neměl být prioriotu pro provozovatele aplikace.

Horizontální vs. vertikální škálování

Škálování je buď vertikální nebo horizontální. Vertikální škálování tu s námi je mnoho let a zjednodušeně řečeno jde o navyšování výkonu daného serveru (ať už fyzického nebo virtuálního) nebo kontejneru. Je to nejsnazší způsob zajištění více výpočetních prostředků pro danou aplikaci.

Nevýhodou této metody je primárně její omezenost (výkon serveru nelze přidávat donekonečna). Tuto limitaci, alespoň v teoretické rovině, řeší horizontální škálování. To umožňuje paralelní přidávání nezávislých výpočetních kapacit a rozkládání zátěže mezi tyto kapacity – v ideálním případě donekonečna. Z pohledu škálování byznysu to zní skvěle. Ale…

U rozsáhlých aplikací s vizí obrovského růstu je horizontální škálování skutečně jediná možnost, jak zajistit maximální možnou škálovatelnost online aplikace. Nicméně některé služby je stále výhodnější škálovat vertikálně (například load balancery apod.). Bohužel dodnes stále některé platformy (typu AWS) nutí uživatele vybírat z předdefinovaných balíčků kombinací procesorů a pamětí. To považujeme ve vshosting~ za přežitek.

Cloudová platforma a hosting by měly být schopny se dynamicky přizpůsobit reálné potřebě konkrétních výpočetních prostředků každého klienta. Jinými slovy, pokaždé když klient potřebuje navýšit výkon pro svou aplikaci, měl mít možnost si jednoduše přidat x paměti a y procesorů bez nutnosti vždy znovu složitě zkoumat, který z nabízených „balíčků“ je pro něj ten nejvýhodnější.

Nástrahy horizontálního škálování: zkušenosti z praxe

Jak už jsme zmínili, v některých případech ani dynamická možnost vertikálního škálování nestačí a horizontální škálování se stává nezbytným. Ale vyplatí se opravdu důkladně zvážit, zda tomu tak právě ve Vašem případě skutečně je. Jakkoli je horizontálního škálování teoreticky atraktivní, v realitě naráží na řadu koncepčních nevýhod.

V první řadě horizontální škálování klade obrovské nároky na vývojáře, aby vytvářeli aplikace, které budou pro paralelní provoz a zpracovávání úloh připravené. Z praxe víme, že psaní takových aplikací je výrazně náročnější na znalosti, čas, testování (a tedy i o dost nákladnější).

Je také nutné vzít v potaz limity externích služeb, na které často narážíme. Typicky největší komplikace nastane například v případě, kdy aplikace pro provoz v paralelním režimu používá sdílený filesystem. Škálovatelnost je potom omezena pro celou aplikaci už z principu této několik desítek let staré technologie (vhodnou náhradou je například object storage). I cloudové platformy nebo infrastruktura postavená na distribuovaném řešení (například GlusterFS) dříve či později narazí na limity použité technologie, které se budou za provozu velmi špatně řešit.

Dalším problematickým aspektem bývají relační databáze, které také svým koncepčním pojetím nepočítají s tím, že je bude někdo clusterovat. Technologie v této oblasti výrazně pokročily, například skvělé zkušenosti máme s Galera Clusterem nad MariaDB, na kterém úspěšně provozujeme platformu Shoptet pro desítky tisíc e-shopů. Z tohoto pohledu jde o pokročilejší řešení, než které nabízí například Amazon s AWS Aurora.

AWS Aurora umožňuje horizontální škálování pouze pomocí tzv. „replicas“, což jsou read-only repliky jedné instance databáze. Jde tedy o velmi velmi osekané horizontální škálování, které navíc ztrácí v dnešní době smysl, neboť omezováním provozu z relační databáze (abychom udělali aplikaci více horizontálně škálovatelnou) se omezují zejména read operace na jejichž offloading se používají nástroje typu ElasticSearch. Tyto nástroje jsou naopak velmi dobře horizontálně škálovatelné, ale nejsou ze svého principu (princip ACID) určené k ukládání klíčových dat.

Read-only repliky jsou opět mechanismem starým desítky let, který nepovažujeme za technologii vhodnou pro horizontální škálování. Je tomu tak primárně z důvodu, že tato metoda nezajistí škálování 1:1 pro všechny druhy operací. Jiné možnosti AWS v případě SQL databází nenabízí.

Bezproblémové horizontální škálování díky vshosting~

Největší problém u moderních aplikací stavěných pro horizontální škálování vidíme v tom, že je pro jejich komplexnost velmi špatně predikovatelné, kde která část aplikace či komponenta narazí na jaký limit.

Ve vshosting~ asistujeme vývojářům našich klientů tak, aby jejich aplikace byla lépe a rychleji škálovatelná. Poradíme, jaké prvky v jejich aplikaci jsou či budou limitující pro další růst a připravíme individuální, robustní a plně škálovatelnou infrastrukturu bez kompromisů.

Nemá smysl prošlapávat tisickrát prošlapanou cestu, ve vshosting~ Vám díky našemu unikátnímu know-how poradíme na co se zaměřit při návrhu aplikací. Váš projekt připravíme pro globální expanzi i díky naší vlastní CDN, kterou již brzy budeme spouštět na třetím kontinentu (Asie).

Damir Špoljarič

CEO & Co-Founder