Aplicacions al Cloud (I): Escalabilitat

Molts cops, quan es parla de “pujar” determinats serveis TI al Cloud ho associem amb el procés de virtualitzar servidors existents on allotgem aplicacions, per finalment executar-los en algun entorn de virtualització del nostre proveïdor de confiança. Això, per sí sol, no fa que la nostra aplicació s’hagi convertit en «cloud»; amb això per sí sol encara no podem gaudir de molts dels avantatges que els evangelistes del Cloud prediquen. Estaríem passant per alt un aspecte molt important: l’arquitectura dels serveis o aplicacions que volem executar.

Per poder utilitzar i aprofitar els avantatges que ofereixen les plataformes Cloud en termes de flexibilitat i escalabilitat, cal en primer lloc, que les nostres aplicacions estiguin preparades. En aquesta sèrie d’articles veurem alguns aspectes importants a tenir en compte per poder preparar les nostres aplicacions pel pas al Cloud.

Escalat vertical vs horitzontal

Quan tenim una aplicació corrent en un servidor i la demanda de peticions puja correm el risc de que el servidor no pugui atendre i servir correctament totes les peticions que arriben. En aquest punt, tenim un problema i dues possibles solucions:

  1. Augmentar les prestacions del servidor: afegir memòria, incloure més cpu, etc. Això és el que coneixem com escalat vertical. Aquest tipus d’escalat és el que es plantejava antigament quan la demanda creixia lentament i es podien fer pressupostos a “x” anys vista i on es comptava sempre amb capacitat sobrant als servidors en previsió del possible creixement. En els temps en què vivim, quan els projectes o serveis nous es volen posar en producció en terminis curts i és difícil fer prediccions a més d’un any vista, quan es vol ajustar els costos i no pagar més del que és estricament necessari, l’escalat vertical deixa de tenir tant de sentit i, fins i tot, es podria considerar una estratègia perillosa. Les ampliacions (o reduccions) de hardware, encara que siguin “virtuals” impliquen tasques de manteniment i talls de servei. Addicionalment, un servidor no pot créixer il·limitadament en memòria, disc o cpu, sempre hi ha un límit, i molts cops ens el trobarem en el moment menys oportú.
    Només cal mirar al nostre voltant: cap dels grans serveis o portals que coneixem i que són exemple de creixement i escalabilitat (google, facebook, twitter, evernote, whatsapp, linkedin, etc.) podrien ser servits des d’un únic “gran” servidor. Dit duna altra manera: cap d’aquest serveis hauria estat possible utilitzant l’escalat vertical.

    escalat_vertical2

  2. Una estratègia diferent seria distribuir l’aplicació en diferents components i augmentar el número de cada un d’ells, segons convingui. Aquesta és la clau, i s’anomena escalat horitzontal sobre arquitectures distribuïdes. En comptes de dissenyar una aplicació de forma monolítica, la des-composem en diferents mòduls, cada un dels quals executa una funció concreta. Això permet que puguem créixer allà on calgui en número de servidors (instàncies o nodes), en comptes d’augmentar cpu o memòria d’un únic gran node. Si utilitzem un escalat horitzontal, al tenir més d’una instància (servidor) per a cada servei, el que fem es balancejar les peticions entre els diferents nodes que donen aquell servei, podent afegir més nodes segons les necessitats i la càrrega global de peticions. El balanceig de peticions ens ofereix una segona avantatge: l’alta disponibilitat del servei. Podem aturar un node, ja sigui perquè té problemes o sigui per realitzar un manteniment com ara actualitzar el sistema operatiu, re-dirigint les peticions cap als nodes restants, de forma que l’usuari final no nota cap interrupció de servei. Addicionalment, una arquitectura distribuïda ens permet afrontar canvis en una part de l’aplicació sense afectar a la resta, facilitant el control de versions i en definitiva la gestió del canvi. Ens permet també que cada part de l’aplicació funcioni amb el sistema operatiu i les versions més adients per a la funció a realitzar, sense haver d’assumir compromisos ni patir problemes de compatibilitat. Ara bé, l’escalat horitzontal també ens planteja un seguit de reptes que hem de superar per poder gaudir de les seves avantatges. No podia ser tot tant fàcil. Per això haurem de seguir un conjunt de bones pràctiques que veurem més endavant.

    escalat_horitzontal2

Exemples

Un exemple d’arquitectura monolítica i que ha de créixer mitjançant escalat vertical podria ser un servidor web amb una aplicació (PHP, Java, ASP, etc.) i una Base de Dades (MySQL, SQL Server, etc.), tot executant-se en un mateix servidor. Quan el número de visitants o el número de peticions simultànies a la base de dades fa que el nostre servidor arribi al màxim de memòria o cpu, aquest deixarà de respondre i l’únic que podrem fer és aturar l’equip, afegir més memòria ram o cpu i tornar-lo a engegar, esperant que els nous recursos addicionals siguin suficients per assumir la càrrega. Si passat un temps baixa l’activitat, veiem que ja no necessitem aquells recursos extra i volem deixar de pagar-los, el que haurem de fer és similar: aturar l’equip (fet que implica un nou tall de servei), treure memòria ram i/o cpu i tornar a engegar, i així anar fent. Tot això amb l’inconvenient afegit que un problema de recursos amb el servei web pot deixar sense memòria el servei de base de dades i viceversa, dificultant encara més les previsions i la gestió de la càrrega en moments crítics. Està clar que això no és un bon exemple d’escalabilitat.

Quan pensem en arquitectures web distribuïdes probablement la primera idea que ens ve al cap és separar la base de dades del servei web. Cada funció és executada en un servidor diferent, cadascun pot tenir els recursos i versions de sistema operatiu que més s’adeqüin a la funció a realitzar i, si cal, podem afegir més nodes de cada tipus per dividir la càrrega i augmentar la capacitat. Caldrà però, que la nostra aplicació tingui en compte l’existència dels nodes addicionals, i aquí apareix uns dels primers reptes. Per aconseguir-ho, ens poden ser d’ajut elements com els balancejadors de peticions web. En altres casos pot ser el propi codi de l’aplicació qui decideixi enviar dades o peticions a diferents nodes, per exemple quan tenim més d’una base de dades on guardem diferents tipus d’informació.

De totes formes, una arquitectura escalable al Cloud va molt més enllà, i per aconseguir sistemes realment auto-escalables i elàstics basats en plataformes Cloud haurem d’incorporar un conjunt de metodologies i tecnologies addicionals que veurem en propers articles d’aquest blog.

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *

*