A méretezhetőség a vállalati szoftverek alapvető eleme. Ha kezdettől fogva prioritásként kezeljük, az alacsonyabb karbantartási költségekhez, jobb felhasználói élményhez és nagyobb agilitáshoz vezet.

A szoftvertervezés egyensúlyozás, ahol a fejlesztők azon dolgoznak, hogy a legjobb terméket hozzák létre az ügyfél idő- és költségvetési korlátain belül.

A kompromisszumok szükségességét nem lehet elkerülni. Kompromisszumokat kell kötni a projekt követelményeinek teljesítése érdekében, legyenek azok technikai vagy pénzügyi jellegűek.

Túl gyakran azonban a vállalatok a költségeket helyezik előtérbe a skálázhatósággal szemben, vagy akár teljesen figyelmen kívül hagyják annak fontosságát. Ez sajnos gyakori a nagyadat-kezdeményezéseknél, ahol a skálázhatósági problémák egy ígéretes projektet is elsüllyeszthetnek.

A skálázhatóság nem egy “bónusz funkció”. Ez a minőség határozza meg a szoftverek élettartam-értékét, és a skálázhatóság szem előtt tartásával történő építés hosszú távon időt és pénzt takarít meg.

Mi a skálázhatóság?

A rendszer akkor tekinthető skálázhatónak, ha nem kell újratervezni ahhoz, hogy a munkaterhelés meredek növekedése közben vagy után megőrizze a hatékony teljesítményt.

A “munkaterhelés” utalhat egyidejű felhasználókra, tárolókapacitásra, a kezelt tranzakciók maximális számára, vagy bármi másra, ami a rendszer eredeti kapacitását meghaladja.

A skálázhatóság nem alapvető követelmény egy programmal szemben, mivel a nem skálázható szoftverek korlátozott kapacitással is jól működhetnek.

A skálázhatóság azonban tükrözi a szoftver azon képességét, hogy a felhasználó igényeivel együtt növekedjen vagy változzon.

Minden olyan szoftvert, amely az alapfunkcióin túl bővülhet – különösen, ha az üzleti modell a növekedéstől függ -, skálázhatóságra kell konfigurálni.

A skálázható szoftverek előnyei

A skálázhatóságnak hosszú és rövid távú előnyei egyaránt vannak.

A kezdetekben lehetővé teszi, hogy a vállalat csak azt vásárolja meg, amire azonnal szüksége van, nem pedig minden olyan funkciót, amely később hasznos lehet.

Egy adatintelligencia-kísérleti programot indító vállalat például választhat egy hatalmas vállalati analitikai csomagot, vagy kezdhet egy olyan megoldással, amely csak az első időszakban szükséges funkciókat kezeli.

Egy népszerű választás a műszerfal, amely az elsődleges adatforrásokból és a meglévő vállalati szoftverekből vonja be az eredményeket.

Amikor elég nagyra nőnek ahhoz, hogy több analitikai programot használjanak, ezeket az adatfolyamokat hozzáadhatják a műszerfalhoz, ahelyett, hogy arra kényszerítenék a vállalatot, hogy több vizualizációs programmal zsonglőrködjön vagy egy teljesen új rendszert építsen.

Az ilyen módon történő építés felkészül a jövőbeli növekedésre, miközben egy karcsúbb terméket hoz létre, amely extra komplexitás nélkül felel meg a jelenlegi igényeknek.

Ez alacsonyabb előzetes pénzügyi ráfordítást is igényel, ami fontos szempont a nagy adatberuházások mérete miatt aggódó vezetők számára.

A skálázhatóság teret enged a változó prioritásoknak is. A készen kapható analitikai csomag elveszítheti jelentőségét, ha a vállalat a változó piaci igényeknek való megfelelés érdekében változik.

A skálázható megoldások választása megvédi a kezdeti technológiai beruházást. A vállalkozások hosszabb ideig használhatják ugyanazt a szoftvert, mivel azt úgy tervezték, hogy együtt növekedjen velük.

Amikor eljön a változás ideje, a szilárd, skálázható szoftverre való építés lényegesen olcsóbb, mint a kevésbé agilis programok adaptálása.

Az új funkciók bevezetéséhez rövidebb idő áll rendelkezésre, mint egy teljesen új szoftver bevezetéséhez.

Mindenesetre a személyzetet nem kell sokat képezni vagy meggyőzni a frissített rendszer elfogadásához. Már ismerik a kezelőfelületet, így a további funkciókkal való munkát inkább bónusznak tekintik, mint fáradságnak.

A skálázási hibák következményei

Szóval, mi történik, ha a szoftver nem skálázható?

Kezdetben a gyengeséget nehéz észrevenni. Az alkalmazás korai szakaszában könnyű a munkaterhelés. Viszonylag kevés egyidejű felhasználóval nincs nagy igény az architektúrára.

Amikor a munkaterhelés növekszik, problémák merülnek fel. Minél több tárolt adatot vagy egyidejű felhasználót gyűjt a szoftver, annál nagyobb igénybevételnek van kitéve a szoftver architektúrája.

A kezdetben nem tűnt fontosnak tűnő korlátozások a termelékenység akadályává válnak. A javítások enyhíthetik a korai problémák egy részét, de a javítások bonyolultabbá teszik a rendszert.

A bonyolultság miatt a problémák folyamatos diagnosztizálása fáradságosabbá válik (fordítás: drágább és kevésbé hatékony).

Amint a munkaterhelés nő, és meghaladja a szoftver skálázhatóságát, a teljesítmény csökken.

A felhasználók lassú betöltési időket tapasztalnak, mert a szervernek túl sokáig tart válaszolni a kérésekre. További lehetséges problémák közé tartozik a csökkent rendelkezésre állás vagy akár az adatok elvesztése is.

Mindez elriasztja a jövőbeli használatot. Az alkalmazottak a saját munkájuk elvégzése érdekében megoldásokat találnak a megbízhatatlan szoftverekre.

Ezzel a vállalatot az adatok megsértésének vagy még rosszabbnak teszi ki.

Ha a szoftver az ügyfelek felé fordul, a megbízhatatlanság növeli az elvándorlás lehetőségét.

A Google szerint a felhasználók 61%-a nem ad második esélyt egy alkalmazásnak, ha az első tapasztalat rossz volt. 40%-uk egyenesen egy versenytárs termékét választja helyette.

A skálázhatósági problémák nem csak a kis cégek kezdő hibái. Még a Disney is bajba került az Applause alkalmazásuk eredeti indításakor, amely a nézők számára egy extra lehetőséget kívánt biztosítani a kedvenc Disney-műsorokkal való interakcióra. Az alkalmazás nem tudta kezelni az egyidejűleg streaming videót használók áradatát.

A feldúlt rajongók negatív értékeléseket hagytak, amíg az alkalmazás egyetlen csillagot nem kapott a Google Play áruházban. A Disney illetékesei kénytelenek voltak levenni az alkalmazást, hogy helyrehozzák a károkat, és a negatív hírverés miatt az alkalmazás soha többé nem került újra online.

Prioritások felállítása

Egyes vállalkozások nem helyezik előtérbe a skálázhatóságot, mert nem látják annak közvetlen hasznát.

A skálázhatóságot háttérbe szorítják a sebesség, a rövidebb fejlesztési ciklusok vagy az alacsonyabb költségek javára.

Van néhány eset, amikor a skálázhatóság nem elsődleges fontosságú.

A prototípusnak vagy kis volumenű koncepció bizonyításának szánt szoftverek nem lesznek elég nagyok ahhoz, hogy problémákat okozzanak.

Hasonlóképpen, a kis cégek belső szoftverei, amelyeknél a potenciális felhasználók száma fixen alacsony, más prioritásokat határozhatnak meg.

Végül, amikor az ACID-megfelelés feltétlenül kötelező, a skálázhatóság háttérbe szorul a megbízhatósággal szemben.

Általánosságban azonban a skálázhatóság könnyebb és kevésbé erőforrás-igényes, ha már a kezdetektől fogva figyelembe vesszük.

Egyrészt az adatbázis kiválasztása nagy hatással van a skálázhatóságra. Egy új adatbázisra való áttérés drága és időigényes. Ez nem olyasmi, amit később könnyen meg lehet csinálni.

A skálázhatóság alapelvei

A szoftver általános skálázhatóságát több tényező is befolyásolja:

Kihasználtság

A kihasználtság a lehetséges egyidejű felhasználók vagy kapcsolatok számát méri. A használatnak nem szabad mesterséges korlátokat szabni.

Növelésének olyan egyszerűnek kell lennie, mintha több erőforrás állna a szoftver rendelkezésére.

Maximális tárolt adatok

Ez különösen fontos a sok strukturálatlan adatot tartalmazó webhelyek esetében: a felhasználók által feltöltött tartalmak, webhelyjelentések és bizonyos típusú marketingadatok.

Az adattudományi projektek is ebbe a kategóriába tartoznak. Az ilyen típusú tartalmak által tárolt adatok mennyisége drámaian és váratlanul megnőhet.

Az, hogy a maximálisan tárolt adatok gyorsan skálázhatók-e, nagyban függ az adatbázis stílusától (SQL vs. NoSQL szerverek), de az is kritikus, hogy figyelmet fordítsunk a megfelelő indexelésre.

Kód

A tapasztalatlan fejlesztők hajlamosak figyelmen kívül hagyni a kóddal kapcsolatos megfontolásokat, amikor a skálázhatóságot tervezik.

A kódot úgy kell megírni, hogy a régi kód refaktorálása nélkül lehessen hozzáadni vagy módosítani. A jó fejlesztők arra törekszenek, hogy elkerüljék az erőfeszítések megkettőzését, csökkentve a kódbázis teljes méretét és összetettségét.

Az alkalmazások mérete a fejlődésük során valóban növekszik, de a kód tisztán tartása minimalizálja ezt a hatást, és megakadályozza a “spagettikód” kialakulását.

A méretnövelés és a méretnövelés

A méretnövelés (vagy “vertikális méretnövelés”) a fejlettebb vagy erősebb hardver használatával történő növekedést jelenti. A megnövekedett munkaterhelés kezeléséhez lemezterületet vagy gyorsabb központi feldolgozó egységet (CPU) használnak.

A skálázás felfelé jobb teljesítményt nyújt, mint a skálázás kifelé. Minden egy helyen van, ami gyorsabb megtérülést és kisebb sebezhetőséget tesz lehetővé.

A felskálázással az a probléma, hogy csak ennyi hely áll rendelkezésre a növekedéshez. A hardver egyre drágább lesz, ahogy egyre fejlettebbé válik. Egy bizonyos ponton a vállalkozások a fejlett rendszerek vásárlásakor a csökkenő megtérülés törvényébe ütköznek.

Az új hardver bevezetése is időbe telik.

Ezek a korlátok miatt a vertikális skálázás nem a legjobb megoldás olyan szoftverek esetében, amelyeknek gyorsan és kis idő alatt kell növekedniük.

A skálázás kifelé (vagy “horizontális skálázás”) sokkal elterjedtebb vállalati célokra.

A skálázás során a szoftver úgy növekszik, hogy több – nem fejlettebb – hardvert használ, és a megnövekedett munkaterhelést szétosztja az új infrastruktúrán.

A költségek alacsonyabbak, mivel az extra szerverek vagy CPU-k lehetnek a jelenleg használt típusok (vagy bármilyen kompatibilis típus).

A skálázás is gyorsabban történik, mivel semmit sem kell importálni vagy újraépíteni.

A sebességnek azonban van egy kis kompromisszuma. A vízszintesen skálázott szoftvereket korlátozza az a sebesség, amellyel a szerverek kommunikálni tudnak.

A különbség azonban nem elég nagy ahhoz, hogy a legtöbb felhasználó észrevegye, és vannak olyan eszközök, amelyekkel a fejlesztők minimalizálhatják a hatást. Ennek eredményeképpen a skálázható alkalmazások építésénél a skálázást jobb megoldásnak tartják.

Útmutató a nagymértékben skálázható rendszerek építéséhez

A skálázhatóságot a tervezési fázisban figyelembe venni olcsóbb és egyszerűbb is. Íme néhány legjobb gyakorlat a skálázhatóság kezdettől fogva történő beépítéséhez:

Leterheléselosztó szoftverek használata

A terhelést elosztott infrastruktúrával rendelkező rendszerek (például horizontálisan skálázott alkalmazások) esetében a terheléselosztó szoftver kritikus fontosságú.

Ez a szoftver egy algoritmust használ a munkaterhelés szerverek közötti elosztására, hogy egyetlen szerver se legyen túlterhelt. A teljesítményproblémák elkerülése érdekében elengedhetetlenül szükséges.

A hely számít

A skálázható szoftver a lehető legtöbbet teszi az ügyfél közelében (az alkalmazásrétegben). Ha az alkalmazásoknak kevesebbszer kell a magerőforrások közelében navigálniuk a nagyobb forgalmat, az gyorsabb sebességet eredményez, és kevésbé terheli a szervereket.

A peremszámítás még valami, amit figyelembe kell venni. Mivel több alkalmazás igényel erőforrás-igényes alkalmazásokat, a lehető legtöbb munkát az eszközön tartva csökkenti az alacsony jelű területek és a hálózati késések hatását.

Cache, ahol lehetséges

Tudatában kell lennie a biztonsági aggályoknak, de a gyorsítótárazás jó módja annak, hogy ne kelljen ugyanazt a feladatot újra és újra elvégezni.

Lead with API

A felhasználók többféle kliensen keresztül csatlakoznak, így a nem egy adott klienstípust feltételező API-val való vezetés mindannyiukat ki tudja szolgálni.

Aszinkron feldolgozás

Azokra a folyamatokra utal, amelyek különálló lépésekre vannak bontva, amelyeknek a feldolgozás előtt nem kell megvárniuk az előző lépés befejezését.

Egy felhasználónak például egy “elküldve!” értesítést, miközben az e-mail technikailag még mindig feldolgozás alatt áll.

Az aszinkron feldolgozás megszünteti a nagyméretű szoftverek teljesítményét befolyásoló szűk keresztmetszetek egy részét.

Limitálja a korlátozott erőforrásokhoz való egyidejű hozzáférést

Ne duplikálja az erőfeszítéseket. Ha több kérés ugyanazt a számítást kéri ugyanattól az erőforrástól, hagyja, hogy az első befejezze, és csak azt az eredményt használja fel. Ez növeli a sebességet, miközben csökkenti a rendszer terhelését.

Skálázható adatbázist használjon

A NoSQL adatbázisok általában skálázhatóbbak, mint az SQL. Az SQL elég jól skálázza az olvasási műveleteket, de az írási műveleteknél ütközik az ACID-elvek betartását célzó korlátozásokkal.

A NoSQL skálázása kevésbé szigorúan követi ezeket az elveket, így ha az ACID-megfelelés nem szempont, a NoSQL adatbázis lehet a megfelelő választás.

Figyeljen a PaaS-megoldásokra

A platform mint szolgáltatás sok skálázhatósági problémát enyhít, mivel a PaaS szolgáltató kezeli a skálázást. A skálázás olyan egyszerű lehet, mint az előfizetési szint frissítése.

Nézzen utána a FaaS-nek

A funkcionalitás mint szolgáltatás a PaaS-ból fejlődött ki, és nagyon szorosan kapcsolódik hozzá. A szerver nélküli számítástechnika módot nyújt arra, hogy csak azokat a funkciókat használjuk, amelyekre az adott pillanatban szükség van, csökkentve ezzel a back-end infrastruktúrával szembeni felesleges igényeket.

A FaaS még érlelődik, de érdemes lehet megvizsgálni, mint a működési költségek csökkentésének és a skálázhatóság javításának egyik módját.

Ne feledkezzen meg a karbantartásról

Állítsa be a szoftvert automatizált tesztelésre és karbantartásra, hogy amikor növekszik, a karbantartással járó munka ne menjen túlzásba.

Építsen a jövőt szem előtt tartva

A skálázhatóság előtérbe helyezése felkészíti vállalkozását a sikerre. Gondoljon rá idejekorán, és akkor fogja élvezni az agilitás előnyeit, amikor a legnagyobb szükség van rá.

Szoftvert keres, amely együtt tud nőni a vállalatával? Kérjen egy ingyenes találkozót fejlesztőink egyikével, hogy megbeszéljük, hová kell eljutnia, és hogyan tudjuk elérni ezt a célt!