Ce este scalabilitatea software-ului și de ce ar trebui compania dumneavoastră să o ia în serios?

Chiar și companiile cu experiență și succes pot avea probleme cu scalabilitatea. Îți amintești aplicația Disney’s Applause? Le-a permis utilizatorilor să interacționeze cu diferite emisiuni Disney. Când a apărut aplicația pe Google Play, a fost extrem de populară. Nu atât de scalabil, totuși. Nu a putut face față unui număr mare de fani, rezultând o experiență slabă pentru utilizator. Oamenii au fost furioși, lăsând feedback negativ și o stea pe Google Play. Aplicația nu și-a revenit niciodată din această publicitate negativă.

Puteți evita astfel de probleme dacă acordați atenție scalabilității software în primele etape de dezvoltare, indiferent dacă îl implementați singur sau utilizați servicii de inginerie software.

Deci, ce este scalabilitatea în software? Cum să vă asigurați că soluția dvs. este scalabilă? Și când trebuie să începeți să scalați?

Ce este scalabilitatea software?

Gartner definește scalabilitatea ca fiind măsura capacității unui sistem de a scădea sau crește performanța și costul ca răspuns la schimbările în cererile de procesare.

În contextul dezvoltării software, scalabilitatea este capacitatea unei aplicații de a gestiona variația sarcinii de lucru în timp ce adaugă sau elimină utilizatori cu costuri minime. Așadar, este de așteptat ca o soluție scalabilă să rămână stabilă și să își mențină performanța după o creștere abruptă a volumului de lucru, fie că este așteptată sau spontană. Exemple de volum de muncă crescut sunt:

• Mulți utilizatori accesează sistemul simultan
• Extinderea cerințelor privind capacitatea de stocare
• Creșterea numărului de tranzacții în curs de procesare

Tipuri de scalabilitate software

Puteți scala o aplicație orizontal sau vertical. Să vedem care sunt beneficiile și dezavantajele fiecărei abordări.

Scalabilitate orizontală a software-ului (scaling out)

Puteți scala software-ul pe orizontală încorporând noduri suplimentare în sistem pentru a gestiona o sarcină mai mare, deoarece acesta va fi distribuit pe mașini. De exemplu, dacă o aplicație începe să întâmpine întârzieri, puteți scala prin adăugarea unui alt server.

Scalabilitatea orizontală este o alegere mai bună atunci când nu puteți estima cât de multă încărcare va trebui să suporte aplicația dvs. în viitor. Este, de asemenea, o opțiune de bază pentru software-ul care trebuie să se extindă rapid, fără timpi de nefuncționare.

Beneficii:

• Rezistenta la esec. Dacă un nod eșuează, alții vor reuși
• Nu există o perioadă de nefuncționare în timpul scalării, deoarece nu este nevoie să dezactivați nodurile existente în timp ce adăugați altele noi
• Teoretic, posibilitățile de scalare pe orizontală sunt nelimitate

Limitări:

• Complexitate adăugată. Trebuie să determinați cum este distribuită sarcina de lucru între noduri. Puteți utiliza Kubernetes pentru gestionarea încărcării
• Costuri mai mari. Adăugarea de noi noduri costă mai mult decât modernizarea celor existente
• Viteza globală a software-ului poate fi limitată de viteza de comunicare cu nodul

Scalabilitate verticală a software-ului (creștere)

Scalabilitatea verticală înseamnă adăugarea de mai multă putere hardware-ului existent. Dacă cu scalabilitate orizontală ați adăuga un alt server pentru a gestiona încărcarea unei aplicații, aici veți actualiza serverul existent adăugând mai multă putere de procesare, memorie, etc. O altă opțiune este eliminarea vechiului server și conectarea unuia mai avansat și mai capabil.

Acest tip de scalabilitate funcționează bine atunci când cunoașteți cantitatea de încărcare suplimentară pe care trebuie să o încorporați.

Beneficii:

• Nu este nevoie să schimbați configurația sau logica unei aplicații pentru a se adapta la infrastructura actualizată
• Cheltuieli mai mici, deoarece costă mai puțin actualizarea decât adăugarea unei alte mașini

Limitări:

• Există timpi de nefuncționare în timpul procesului de actualizare
• Mașina actualizată prezintă încă un singur punct de defecțiune
• Există o limită la cât de mult puteți upgrade un dispozitiv

Scalabilitate verticală vs. orizontală a software-ului

Iată o comparație de tabel care oferă o imagine de ansamblu asupra diferitelor aspecte ale ambelor tipuri de scalabilitate software.

Când aveți absolut nevoie de scalabilitate?

Multe companii marginalizează scalabilitatea în inginerie software în favoarea costurilor mai mici și a ciclurilor de viață mai scurte de dezvoltare a software-ului. Și chiar dacă există câteva cazuri în care scalabilitatea nu este un atribut esențial al calității sistemului, în majoritatea situațiilor, trebuie să o luați în considerare încă de la primele etape ale ciclului de viață al produsului.

Când scalabilitatea software-ului nu este necesară:

• Dacă software-ul este o dovadă de concept (PoC) sau un prototip
• La dezvoltarea software-ului intern pentru companii mici, folosit doar de angajați
• Aplicație mobilă/desktop fără back-end

În rest, este foarte recomandat să analizați opțiunile de scalabilitate pentru a fi gata când va veni momentul. Și de unde știi că este timpul să treci la scară? Când observați o degradare a performanței. Iată câteva indicații:

• Timpul de răspuns al aplicației crește
• Incapacitatea de a gestiona cererile simultane ale utilizatorilor
• Rate de eroare crescute, cum ar fi erorile de conexiune și timeout-uri
• Se formează frecvent blocaje. Nu puteți accesa baza de date, autentificarea eșuează etc.

Sfaturi pentru construirea de software extrem de scalabil

Scalabilitatea software-ului este mult mai ieftină și mai ușor de implementat dacă este luată în considerare chiar la începutul dezvoltării software. Dacă trebuie să scalați în mod neașteptat fără a face pașii necesari în timpul implementării, procesul va consuma mult mai mult timp și resurse. O astfel de abordare este refactorizarea codului, care este un efort duplicat, deoarece nu adaugă nicio caracteristică nouă. Pur și simplu face ceea ce ar fi trebuit făcut în timpul dezvoltării.

Mai jos puteți găsi opt sfaturi care vă vor ajuta să construiți un software care este mai ușor de scalat în viitor. Tabelul de mai jos împarte sfaturile în diferite etape de dezvoltare a software-ului.

Sfat #1: Optați pentru găzduire în cloud pentru o scalabilitate mai bună a software-ului

Aveți două opțiuni pentru a vă găzdui aplicațiile, fie în cloud, fie în local. Sau puteți folosi o abordare hibridă.

Dacă optați pentru modelul on-premises , vă veți baza pe propria infrastructură pentru a rula aplicații, pentru a vă găzdui stocarea de date etc. Această configurare vă va limita capacitatea de a scala și o va face mai scumpă. Cu toate acestea, dacă operați într-un sector puternic reglementat, este posibil să nu aveți de ales, deoarece găzduirea locală vă oferă mai mult control asupra datelor.

De asemenea, în unele sectoare, precum cel bancar, timpul de tratare a tranzacțiilor este esențial și nu vă puteți permite să așteptați ca cloud-ul să răspundă sau să tolerați orice timp de nefuncționare de la furnizorii de cloud. Companiile care operează în aceste industrii sunt limitate la utilizarea hardware-ului specific și nu se pot baza pe orice oferă furnizorii de cloud. Același lucru este valabil și pentru aplicațiile critice, sensibile la timp, cum ar fi vehiculele automate.

Alegerea serviciilor de cloud computing vă va oferi posibilitatea de a accesa resurse de la terți în loc să vă folosiți infrastructura. Cu cloud-ul, aveți o posibilitate aproape nelimitată de a crește și reduce dimensiunea fără a fi nevoie să investiți în servere și alt hardware. Furnizorii de cloud sunt, de asemenea, responsabili pentru întreținerea și securizarea infrastructurii.

Dacă lucrați în industria sănătății, puteți consulta articolul nostru despre cloud computing în sectorul medical.

Sfat #2: Utilizați echilibrarea sarcinii

Dacă decideți să scalați orizontal, va trebui să implementați un software de echilibrare a încărcăturii pentru a distribui cererile primite între toate dispozitivele capabile să le gestioneze și să vă asigurați că niciun server nu este copleșit. Dacă un server se defectează, un echilibrator de încărcare va redirecționa traficul serverului către alte mașini online care pot gestiona aceste solicitări.

Când un nou nod este conectat, acesta va deveni automat o parte a configurației și va începe să primească și cereri.

Sfatul #3: Memorați în cache cât de mult puteți

Cache-ul este folosit pentru a stoca conținut static și rezultate precalculate pe care utilizatorii le pot accesa fără a fi nevoie să treacă din nou prin calcule.

Memorați în cache cât mai multe date posibile pentru a elimina încărcarea bazei de date. Configurați-vă logica de procesare astfel încât datele care sunt rareori modificate, dar citite destul de des să poată fi preluate dintr-un cache distribuit. Acest lucru va fi mai rapid și mai puțin costisitor decât interogarea bazei de date cu fiecare cerere simplă. De asemenea, atunci când ceva nu este în cache, dar este accesat des, aplicația dvs. îl va prelua și va stoca în cache rezultatele.

Acest lucru aduce probleme, cum ar fi cât de des ar trebui să invalidați memoria cache, de câte ori trebuie accesată o bucată de date pentru a fi copiată în cache etc.

Sfat #4: Activați accesul prin API-uri

Utilizatorii finali vor accesa software-ul dvs. printr-o varietate de clienți și va fi mai convenabil să oferiți o interfață de programare a aplicațiilor (API) pe care toată lumea o poate utiliza pentru a se conecta. Un API este ca un intermediar care permite două aplicații să vorbească. Asigurați-vă că aveți în vedere diferite tipuri de clienți, inclusiv smartphone-uri, aplicații desktop etc.

Rețineți că API-urile vă pot expune la vulnerabilități de securitate. Încercați să rezolvați acest lucru înainte de a fi prea târziu. Puteți utiliza gateway-uri securizate, autentificare puternică, metode de criptare și multe altele.

Sfat #5: Beneficiați de procesarea asincronă

Un proces asincron este un proces care poate executa sarcini în fundal. Clientul nu trebuie să aștepte rezultatele și poate începe să lucreze la altceva. Această tehnică permite scalabilitatea software-ului, deoarece permite aplicațiilor să ruleze mai multe fire, permițând nodurilor să fie mai scalabile și să gestioneze mai multă sarcină. Și dacă apare o sarcină consumatoare de timp, aceasta nu va bloca amenințarea de execuție, iar aplicația va putea în continuare să se ocupe de alte sarcini simultan.

Procesarea asincronă se referă, de asemenea, la împărțirea proceselor în pași atunci când nu este nevoie să așteptați ca un pas să fie finalizat înainte de a începe următorul, dacă acest lucru nu este critic pentru sistem. Această configurare permite distribuirea unui proces pe mai multe fire de execuție, ceea ce facilitează și scalabilitatea.

Procesarea asincronă este realizată la nivel de cod și infrastructură, în timp ce gestionarea asincronă a cererilor este la nivel de cod.

Sfat #6: Optați pentru tipuri de baze de date care sunt mai ușor de scalat, atunci când este posibil

Unele baze de date sunt mai ușor de scalat decât altele. De exemplu, bazele de date NoSQL, cum ar fi MongoDB, sunt mai scalabile decât SQL. MongoDB menționat mai sus este open source și este de obicei folosit pentru analiza datelor mari în timp real. Alte opțiuni NoSQL sunt Amazon DynamoDB și Google Bigtable.

SQL funcționează bine atunci când vine vorba de scalarea operațiunilor de citire, dar blochează operațiunile de scriere datorită conformității sale cu principiile ACID (atomicitate, consistență, izolare și durabilitate). Deci, dacă aceste principii nu sunt principala preocupare, puteți opta pentru NoSQL pentru o scalare mai ușoară. Dacă trebuie să vă bazați pe baze de date relaționale, pentru coerență sau orice altă problemă, este totuși posibil să scalați folosind sharding și alte tehnici.

Sfat #7: alegeți microservicii în locul arhitecturii monolit, dacă este cazul

Arhitectură monolitică

Software-ul monolitic este construit ca o singură unitate, combinând operațiunile de pe partea client și pe partea de server, o bază de date etc. Totul este strâns cuplat și are o singură bază de cod pentru toate funcționalitățile sale. Nu puteți actualiza doar o parte fără a afecta restul aplicației.

Este posibil să scalați software-ul monolit, dar trebuie să fie scalat holistic folosind abordarea de scalare verticală, care este costisitoare și ineficientă. Dacă doriți să actualizați o anumită parte, nu există nicio scăpare de la reconstruirea și redistribuirea întregii aplicații. Deci, optează pentru un monolitic dacă soluția ta nu este complexă și va fi folosită doar de un număr limitat de persoane.

Arhitectura microservicii

Microserviciile sunt mai flexibile decât monoliții. Aplicațiile concepute în acest stil constau din multe componente care funcționează împreună, dar sunt implementate independent. Fiecare componentă oferă o funcționalitate specifică. Serviciile care constituie o singură aplicație pot avea stive tehnice diferite și pot accesa baze de date diferite. De exemplu, o aplicație de comerț electronic construită ca microservicii va avea un serviciu pentru căutarea produselor, altul pentru profilurile de utilizator, altul pentru gestionarea comenzilor și așa mai departe.

Componentele aplicației pentru microservicii pot fi scalate independent, fără a impune impozitarea întregului software. Așadar, dacă sunteți în căutarea unei soluții scalabile, microservicii sunt designul dvs. de preferat. Scalabilitate ridicată a software-ului este doar unul dintre numeroasele avantaje pe care le puteți obține din această arhitectură. Pentru mai multe informații, consultați articolul nostru despre beneficiile microserviciilor.

Sfat #8: Monitorizați performanța pentru a determina când să scalați

După implementare, vă puteți monitoriza software-ul pentru a detecta semne timpurii de degradare a performanței care pot fi rezolvate prin scalare. Acest lucru vă oferă posibilitatea de a reacționa înainte ca problema să escaladeze. De exemplu, când observați că memoria se epuizează sau că mesajele așteaptă să fie procesate mai mult decât limita specificată, acesta este un indiciu că software-ul dumneavoastră rulează la capacitatea sa.

Pentru a putea identifica aceste și alte probleme legate de scalabilitatea software-ului, trebuie să încorporați un sistem de monitorizare a telemetriei în aplicația dvs. în timpul fazei de codare. Acest sistem vă va permite să urmăriți:

• Timp mediu de răspuns
• Debitul, care este numărul de cereri procesate la un moment dat
• Numărul de utilizatori concurenți
• Valori de performanță a bazei de date, cum ar fi timpul de răspuns la interogare
• Utilizarea resurselor, cum ar fi CPU, utilizarea memoriei, GPU
• Rate de eroare
• Cost pe utilizator

Puteți beneficia de soluțiile de monitorizare existente și cadrele de agregare a jurnalelor, cum ar fi Splunk. Dacă software-ul dvs. rulează în cloud, puteți utiliza soluția furnizorului de cloud. De exemplu, Amazon oferă AWS CloudWatch în acest scop.

Exemple de soluții software scalabile din portofoliul ITRex

Oglindă de fitness inteligentă cu un antrenor personal

Descrierea proiectului

Clientul a dorit să construiască o oglindă de fitness de perete de lungime completă, care să-i ajute pe utilizatori cu rutina de antrenament. Ar putea monitoriza forma utilizatorului în timpul exercițiului, ar putea număra repetările și multe altele. Acest sistem trebuia să includă software care permite antrenorilor să creeze și să încarce videoclipuri, iar utilizatorilor să înregistreze și să-și gestioneze antrenamentele.

Ce am făcut pentru a asigura scalabilitatea software-ului

• Am optat pentru arhitectura de microservicii
• Scalabilitate orizontală implementată pentru distribuția sarcinii. Un nou nod a fost adăugat ori de câte ori a existat prea multă sarcină asupra celor existente. Deci, ori de câte ori utilizarea procesorului depășea 90% din capacitatea sa și rămâne acolo pentru o perioadă specificată de timp, se adăuga un nou nod pentru a ușura încărcarea.
• A trebuit să implementăm baze de date relaționale - adică SQL și PostgreSQL - din motive arhitecturale. Chiar dacă bazele de date relaționale sunt mai greu de scalat, există totuși mai multe opțiuni. La început, deoarece baza de utilizatori era încă relativ mică, am optat pentru scalarea verticală. Dacă publicul creștea, plănuiam să implementăm abordarea master-slave - distribuirea datelor în mai multe baze de date.
• A beneficiat foarte mult de stocarea în cache, deoarece acest sistem conține o mulțime de informații statice, cum ar fi numele antrenorilor, titlurile antrenamentului etc.
• A folosit RestAPI pentru procesarea asincronă a cererilor între aplicația de antrenament și server
• Se bazează pe arhitectura fără server, cum ar fi AWS Lambda, pentru alte tipuri de procesare asincronă. Un exemplu este procesarea video asincronă. După ce un antrenor încarcă un nou videoclip de antrenament și îl segmentează în diferite exerciții, ei apasă pe „salvare”, iar serverul începe să proceseze acest videoclip pentru streaming live HTTP pentru a construi patru versiuni ale videoclipului original cu rezoluții diferite. Trainerul poate încărca videoclipuri noi simultan.
• Într-un alt exemplu, sistemul efectuează în mod asincron tăierea inteligentă a videoclipurilor utilizatorilor pentru a elimina orice părți în care utilizatorul a fost inactiv.

Sistem de securitate cibernetică bazat pe biometrie

Descrierea proiectului

Clientul a dorit să construiască o platformă de securitate cibernetică care să permită companiilor să autentifice angajații, contractanții și alți utilizatori pe baza datelor biometrice și să evite parolele și codurile PIN. Această platformă ar conține, de asemenea, un instrument video live pentru a confirma de la distanță identitatea utilizatorului.

Cum ne-am asigurat că acest software este scalabil

• Am folosit o arhitectură de microservicii descentralizată
• Au implementat trei echilibratori de încărcare pentru a distribui sarcina între diferite microservicii
• Unele părți ale acestei platforme au fost autoscalabile prin proiectare. Dacă încărcarea a depășit un anumit prag, a fost creată automat o nouă instanță a unui microserviciu
• Am folosit șase baze de date diferite - patru PostgreSQL și două MongoDB. Bazele de date PostgreSQL au fost scalate vertical atunci când a fost necesar. În timpul proiectării arhitecturii, ne-am dat seama că unele dintre bazele de date ar trebui să fie scalate destul de des, așa că am adoptat MongoDB în acest scop, deoarece sunt mai ușor de scalat pe orizontală.
• Procesare asincronă implementată pentru o experiență mai bună a utilizatorului. De exemplu, post-procesarea video a fost realizată în mod asincron.
• Am optat pentru un algoritm de recunoaștere facială al unui furnizor de servicii terță parte. Deci, ne-am asigurat că selectam o soluție care era deja scalabilă și am încorporat-o în platforma noastră printr-un API.

Provocări pe care le-ați putea întâlni în timpul scalarii

Dacă intenționați să planificați scalabilitatea software-ului în timpul dezvoltării aplicației și doriți să încorporați sfaturile de mai sus, vă puteți confrunta în continuare cu următoarele provocări:

• Datoria tehnică acumulată . Părțile interesate ale proiectului ar putea încerca totuși să marginaleze scalabilitatea în favoarea costurilor, vitezei etc. mai mici. Scalabilitatea nu este o cerință funcțională și poate fi umbrită de caracteristici mai tangibile. Ca urmare, aplicația va acumula caracteristici tehnice care nu vor fi compatibile cu scalabilitatea.
• Scalare cu metodologia de dezvoltare Agile . Metodologia agilă înseamnă îmbrățișarea schimbării. Cu toate acestea, atunci când clientul dorește să implementeze prea multe modificări prea des, scalabilitatea software-ului poate fi lăsată deoparte de dragul de a se adapta cerințelor în schimbare.
• Testare de scalabilitate . Este greu să efectuați teste realiste de încărcare. Să presupunem că doriți să testați cum se va comporta sistemul dacă măriți dimensiunea bazei de date de 10 ori. Va trebui să generați o cantitate mare de date realiste, care se potrivește cu caracteristicile originale ale datelor, apoi să generați o sarcină de lucru realistă atât pentru scrieri, cât și pentru citiri.
• Scalabilitate a serviciilor de la terți . Asigurați-vă că furnizorul de servicii terță parte nu limitează scalabilitatea. Atunci când selectați un furnizor de tehnologie, verificați dacă acesta poate suporta nivelul dorit de scalabilitate a software-ului și să-și integreze soluția corect.
• Înțelegerea modului de utilizare a aplicației dvs. Trebuie să aveți o perspectivă solidă asupra modului în care va funcționa software-ul dvs. și a câte persoane îl vor folosi, ceea ce rareori este posibil să îl estimați cu precizie.
• Restricții arhitecturale . Uneori ești limitat în alegerile tale arhitecturale. De exemplu, ar putea fi necesar să utilizați o bază de date relațională și va trebui să vă ocupați de scalarea acesteia atât pe orizontală, cât și pe verticală.
• A avea talentul potrivit . Pentru a proiecta o soluție scalabilă care să nu vă dea bătăi de cap în viitor, aveți nevoie de un arhitect cu experiență care a lucrat la proiecte similare înainte și care să înțeleagă scalabilitatea software-ului atât din perspectiva codării, cât și a infrastructurii. Aici, la ITRex Group, am lucrat la multe proiecte și avem întotdeauna în vedere scalabilitatea în timpul dezvoltării software.

În concluzie

Dacă nu sunteți absolut sigur că nu va trebui să scalați, luați în considerare scalabilitatea software-ului în stadiile incipiente de dezvoltare și luați măsurile de precauție necesare. Chiar dacă sunteți limitat în alegerile dvs. arhitecturale și nu puteți implementa întotdeauna cea mai scalabilă opțiune, veți ști totuși unde sunt obstacolele și veți avea timp să luați în considerare alternative.

Lăsarea scalabilității de dragul altor cerințe funcționale va fi contrară. În primul rând, compania se va lupta cu degradarea performanței. Procesarea cererilor va dura prea mult. Utilizatorii vor experimenta întârzieri inacceptabile. După toate acestea, compania va mări plățile dublând și triplând suma care ar fi putut fi cheltuită în etapele anterioare.

Vă gândiți la implementarea unui nou software de întreprindere sau la actualizarea unui sistem existent, dar vă faceți griji că nu va ține pasul cu nevoile de afaceri în creștere rapidă? Intrați în legătură! Ne vom asigura că software-ul dumneavoastră nu numai că are toate funcționalitățile necesare, ci și că poate fi scalat cu investiții minime și timpi de nefuncționare.

Publicat inițial la https://itrexgroup.com pe 24 iulie 2023.