Modalitati de scalare a aplicatiilor in cloud

Tot mai multe startup-uri in ziua de azi dezvolta aplicatii avand drept target milioane de utilizatori.
Cum ar trebui gandita infrastrucura pentru o astfel de aplicatie, am sa prezint cateva retete pe care le-am folosit.

Scalarea pe partea de back end este de doua tipuri, pe verticala, cand adaugi mai mult resurse la o masina(Core-uri,…), sau pe orizontala cand adaugi mai multe masini pe care sa ruleze back-end-ul, cu un load balancer in fata care sa distribuie request-urile la masini in functie de incarcarea acestora. Amazon are Elastic Computing 2 unde putem sa configuram infratructura cloud-ului in care ruleaza back-end-ul, cate core-uri sa aiba o masina, si cate masini sa avem in spatele load balancer-ul.

Cum implementam scalarea pe verticala si orizontala la nivel de back-end ?

Scalarea pe verticala inseamna ca adaugam mai multe core-uri la o masina, astfel incat ar trebui sa scriem cod care sa ruleze in paralel pe mai multe core-uri, multe tehnologii Java, .NET, Python suporta multithreading, multithreading este solutia pentru multicore programming,.NET mai are o abstractizare peste thread-uri numita Task Parallel Library care vine sa accelereze partea de programare multicore.

Scalarea pe orizontala inseamna sa adaugam mai multe masini in spatele load balancer-ului, solutia pe care am folosit-o eu pentru scalarea pe orizontala a fost sa implementez back end-ul ca si REST API, call-urile de REST API se fac la un load balancer care distribuie aceste call-uri mai departe catre o masina cu REST API deployed in functie de incarcarea acestora.

Cum implementam scalarea pe orizontala la nivel de baza de date ?

Am sa incep prin a spune ca bazele de date denormalizate NoSQL sunt mai potrivite pentru BigData, query-urile sunt mai rapide pe astfel de date si suporta mai multe request-uri simultane decat bazele de date clasice relationale. In continuare am sa va prezint 2 scenarii posibile de sharding(avem mai multe instante de servere de baze de date pe diferite masini). Primul scenariu este cand avem o masina master cu baza de date pe care se fac operatiile de scriere si mai multe masini slave, replici ale masini master, de pe care se fac operatiile de citire, aceasta este o solutie de distribuire a incarcarii la nivelul bazei de date intre masini. Un alt scenariu este sa partionam la nivel de rows baza de date, sa spunem ca primul milion de inregistrari il punem pe prima masina, al doilea pe a doua masina, folosind shard keys.

Cum implementam scalarea la nivel de front end ?

Solutia este sa numai avem continut HTML generat server side, server-ul sa nu faca nici un fel de procesare pentru generare front end, sa returneze plain files, care sa fie partea unui Single Page Application

Si fiindca o imagine zice cat o mie de cuvinte:

5 Likes

Ai uitat sa scalezi partea care chiar conteaza: front-end-ul pt. SPA. In multe cazuri (read: React/Redux etc.) cantitatea de JS este imensa asta fara mai punem in calcul assets (CSS, Imagini, Fonts, etc.)

Din experienta problema se concentreaza chiar aici pentru aplicatii clasice - si se rezolva relativ simplu: CDNs, correct headers, lower JS footprint, request-uri catre API reduse (nu faci per action 20 API calls - you can batch them sau be smart about it and make the API better) etc.

2 Likes

@iamntz imi zice ca nu am drepturi sa editez aceasta resursa, cand incerc sa editez content din tutorial, oricum il gasiti si pe blog-ul meu, refactorizat un pic:

http://code-kata.blogspot.ro/search/label/Scalability

@dakull ai dreptate, sper sa adaug si partea asta pe viitor :slight_smile:

Optimizare prematura!
Daca compania nu are departament si milioanele necesare pt marketing
0% sanse la milioane de utilizatori

2 Likes