Escalabilitat de Sistemes Distribuïts: Tècniques i Models Serverless

Tècniques per Escalar Sistemes Distribuïts

Un sistema distribuït és escalable si, tot i un augment sobtat de tràfic o connexions d'usuari, es manté eficaç i eficient. Això s'aconsegueix amb les següents tècniques:

• Ús de dades replicades (replicated data): Consisteix a mantenir còpies de dades en diversos servidors. És essencial per a aplicatius com DNS o bases de dades. Aquesta tècnica permet escalar afegint nodes, evitant la centralització de dades i diversificant la demanda entre servidors.
• Ús de l'emmagatzematge en cau (caching): Consisteix a emmagatzemar respostes a peticions recents. Si es torna a sol·licitar el mateix recurs, s'evita consultar el servidor original. S'utilitza tant en el client (memòria cau del navegador) com en el servidor (amb un servidor proxy).
• Desplegament de diversos servidors: Implementar serveis mitjançant molts processos de servidor separats en màquines diferents. Aquests servidors poden tenir particions d'objectes o còpies replicades. Un exemple comú és l'arquitectura en cluster.

Escalat Vertical vs. Escalat Horitzontal

Escalat vertical significa augmentar paràmetres (memòria, disc, processament) sobre el mateix node (servidor).

Escalat horitzontal significa créixer en nombre de nodes que proporcionen el mateix servei.

L'inconvenient de l'escalat vertical és que el creixement està limitat pels recursos físics del servidor. Per tant, l'escalat horitzontal és més útil, ja que aborda tres escenaris típics:

• Continuous growth: Permet afegir nodes de computació i emmagatzematge de manera lineal.
• Event based: Permet ampliar temporalment el nombre de nodes per donar servei en esdeveniments concrets (festivitats) i després tornar a la situació normal.
• Slashdot effect: Produït per un creixement desmesurat i no previst del tràfic sobre un recurs, sovint quan un lloc web important enllaça un lloc no escalable.

Models Client-Servidor: Thin vs. Fat

En els models client-servidor, la funcionalitat es reparteix entre clients i servidor. Si es tria un fat client, s'utilitza un thin server, i viceversa.

Thin Client / Fat Server

Es basa en l'ús de maquinari i programari simple i limitat al client. El dispositiu client té un sistema operatiu mínim, no emmagatzema dades i només proporciona una interfície d'usuari per accedir als serveis del servidor. La càrrega de treball del client és mínima.

Fat Client / Thin Server

Es basa en l'ús de maquinari i programari més complet i potent al client, ja que processa la majoria de tasques. El servidor s'utilitza bàsicament com a punt d'emmagatzematge de dades. La càrrega de treball recau principalment en el client.

Comunicació Instantània: Models Push i Pull

Els models push i pull són dues formes de comunicació a través d'Internet.

Model Push

La informació és posada directament a l'usuari final (broadcasting). El client estableix una connexió activa constant, de manera que el servidor envia tots els nous esdeveniments. És típic de missatgeria instantània (Google Chat, MSM, IRC, Jabber...). Protocols pull com POP3 o IMAP4 han afegit extensions (IMAP IDLE) per permetre notificacions push.

Model Pull

El client va a buscar el recurs o esdeveniment periòdicament. El client es connecta al servidor per comprovar i obtenir els nous esdeveniments i després es desconnecta. Aquest procediment es repeteix. És típic de pàgines web, blogs, wikis i Podcasts.

La diferència clau és que amb push, el client obté els nous esdeveniments (missatges, chats) de forma instantània, mentre que amb pull s'ha de sol·licitar l'estat periòdicament.

Tècniques HTTP per a Xats Interactius

S'utilitzen diverses tècniques per simular o implementar comunicació en temps real via HTTP:

• Webpush: Utilitza HTTP/2 per distribuir esdeveniments en temps real, consolidant-los en un únic servei per a un ús més eficient dels recursos de xarxa.
• HTTP Server Push (o HTTP Streaming): El servidor web manté oberta la connexió de resposta al client. Quan hi ha un nou esdeveniment, s'envia immediatament. S'ofereix normalment amb CGI o el tipus MIME multipart/x-mixed-replace.
• Pushlet (o Java pushlet): Tècnica similar a l'anterior, però utilitza rutines de javascript per actualitzar el contingut de la pàgina, aconseguint un resultat similar al push sense necessitat de plug-ins Java.
• Long Polling: És una tècnica de polling (pull) que simula push. Quan el client fa un pull, el servidor reté la petició fins que té nova informació. En rebre-la, el client realitza immediatament una altra petició.

Serverless Computation amb OpenLambda

Relació Serverless, FaaS, PaaS i IaaS

Aquests conceptes representen l'evolució del paradigma del Cloud Computing, basat en diferents nivells d'abstracció dels servidors:

1. IaaS (Infrastructure as a Service): S'abstreu la capa de maquinari. Es passen servidors físics a màquines virtuals externalitzades, on el client ha de desplegar el sistema operatiu i les aplicacions.
2. PaaS (Platform as a Service): El proveïdor ja proporciona el servidor amb el sistema operatiu adequat.
3. FaaS (Function as a Service): Conegut com serverless programming, s'abstreu fins a la capa de llenguatge d'execució. Els clients només subministren codi (funcions). Per cada funció, es crea un objecte que executa el codi i després es destrueix. Els proveïdors gestionen on s'executen, reaprofitant el mateix hardware i SO.

A cada nivell d'abstracció (de IaaS a PaaS i a FaaS), el proveïdor del núvol ofereix una major granularitat.

Escalabilitat, Heterogeneïtat i Tolerància a Fallades (OpenLambda)

• Escalabilitat: Els handlers (que gestionen el codi) comparteixen un pool de servidors del proveïdor. Els clients no es preocupen per la gestió ni la ubicació del codi. El model és autoescalable per gestionar la demanda sobtada.
• Heterogeneïtat: OpenLambda abstraeix maquinari, SO i entorn d'execució, permetent desenvolupar codi sense considerar l'heterogeneïtat dels clients futurs. Es genera codi més petit i sense control d'estat.
• Tolerància a fallades: La implementació es basa en arquitectures de servidors clusters amb redundància entre centres de dades i servidors del pool. Si un servidor falla, el balancejador de càrrega redirigeix les peticions. Els proveïdors distribueixen la capacitat en múltiples zones de disponibilitat per eliminar punts de fallada.

Occupy the Cloud: Arquitectura PyWren

Arquitectura Proposada i Contribució Major

L'article aborda la dificultat d'implementar arquitectures clúster per a aplicacions big data (anàlisi de dades i computació científica) de manera paral·lela, ja que els models inicials estaven orientats a servidor.

Proposa eliminar l'enfocament cap al servidor (serverless) i utilitzar el model del núvol (cloud computing) amb funcions sense estat (stateless functions). Això simplifica i fa més elàstics els sistemes de processament de grans volums de dades.

La major contribució de l'autor amb l'arquitectura PyWren és evitar que els usuaris hagin de desenvolupar i gestionar la infraestructura on-premise, abstraient-los de la complexitat d'instal·lació i configuració.

PyWren permet utilitzar infraestructura serverless mitjançant una API simple que converteix el codi monolític de l'usuari en codi paral·lel executable sobre el model Lambda (cloud). Aquesta API ha d'estar integrada amb les biblioteques existents.

Escalabilitat, Heterogeneïtat i Tolerància a Fallades (PyWren)

Aquesta arquitectura presenta escalabilitat i tolerància a fallades de manera similar al model Lambda original.

• Escalabilitat: L'emmagatzematge d'objectes a S3 es pot recuperar com un SSD local (amb velocitats mitjanes de 30-40 MB/s, escalant fins a 60-80 GB/s amb 2800 funcions simultànies). Això demostra que el magatzem remot S3 no és un coll d'ampolla (bottleneck). El càlcul escala de 18 GFLOPS a 40 TFLOPS amb 2800 funcions simultànies.
• Heterogeneïtat: L'ús del model Lambda permet l'abstracció de capes inferiors. No obstant això, l'API de PyWren permet l'ús de maquinari especialitzat com GPUs o FPGAs, que no són compatibles amb AWS Lambda. Per tant, el nivell d'heterogeneïtat és inferior al model Lambda original (OpenLambda). A més, les aplicacions que requereixen interrelació entre funcions (no-stateless) no són compatibles.
• Tolerància a fallades: El fet que les funcions siguin stateless permet la seva reexecució en cas de fallada (al mateix entorn o a un altre) amb les mateixes dades d'entrada. Per fer el seguiment de les execucions reeixides, només calen escriptures atòmiques al magatzem remot.