apis agregadas computomasivo

13
1 UNIVERSIDAD TÉCNICA DEL NORTE INSTITUTO DE POSTGRADO MAESTRÍA EN INGENIERÍA DE SOFTWARE II PROMOCIÓN COMPUTACIÓN EN LA NUBE Investigación sobre API´S de agregación y cómputo masivo Docente: Fredy Tapia, Ing. Msg. Maestrantes: Andrea Guevara Gabriela Valencia Alexandra Juma 25 de noviembre de 2016 Ibarra Ecuador

Upload: andrea-guevara

Post on 23-Feb-2017

35 views

Category:

Engineering


0 download

TRANSCRIPT

Page 1: Apis Agregadas computomasivo

1

UNIVERSIDAD TÉCNICA DEL NORTE

INSTITUTO DE POSTGRADO

MAESTRÍA EN INGENIERÍA DE SOFTWARE II

PROMOCIÓN

COMPUTACIÓN EN LA NUBE

Investigación sobre API´S de agregación y cómputo masivo

Docente: Fredy Tapia, Ing. Msg.

Maestrantes:

Andrea Guevara

Gabriela Valencia

Alexandra Juma

25 de noviembre de 2016

Ibarra – Ecuador

Page 2: Apis Agregadas computomasivo

2

Indice APIs de Agregación ................................................................................................................. 3

APIs REST ......................................................................................................................... 3

APIs de Agregación ............................................................................................................. 3

Ejemplo .......................................................................................................................... 4

Modelos de APIs Agregadas en el mercado ......................................................................... 5

Cómputo Masivo ..................................................................................................................... 8

Ejemplo de Proyecto ............................................................................................................ 8

Conclusiones ........................................................................................................................ 12

Glosario ............................................................................................................................... 12

Referencias ........................................................................................................................... 12

Page 3: Apis Agregadas computomasivo

3

APIs de Agregación

APIs REST

REST, REpresentational State Transfer, es el tipo de arquitectura más natural y estándar para

crear APIs para servicios orientados a Internet. (SOA). En los APIs REST el número de

solicitudes(llamadas) al servidor son recurrentes debido a su naturaleza genérica y

granularidad; cada llamada devuelve sólo una parte de la funcionalidad para una experiencia

de usuario dado, lo que requiere aplicaciones cliente para hacer múltiples llamadas que

necesitan ser montados con el fin de ser una sola experiencia de usuario. Este modelo de

interacción se ilustra en el siguiente diagrama:

APIs de Agregación

Para reducir las múltiples llamadas inherente a la API REST, las discretas solicitudes deben

realizarse en una sola petición optimizado para un cliente determinado. La ventaja es que el

dispositivo paga el precio de una latencia WAN y aprovecha la baja latencia y el potente del

lado del servidor en el hardware. Como efecto secundario, esto también elimina las

APIs

Agregación Computo

Masivo

Page 4: Apis Agregadas computomasivo

4

redundancias que se producen para cada petición entrante. Este modelo de interacción se ilustra

en el siguiente diagrama:

Una petición optimizada como el modelo anterior debe abarcar el paralelismo del lado del

servidor para al menos el mismo nivel que el alcanzado previamente a través de múltiples

peticiones de red del cliente. Debido a que en el lado del servidor las solicitudes paralelizadas

se están ejecutando en la misma red.

Ejemplo

API Agregación por Lua y Nginx en una aplicación móvil de calificación de palabras

según la carga emocional más positiva.

Con concurrencia de 1 proceso, por solicitud nos referimos a la carga de la página de un click

en enviar para obtener los resultados (esto se traduce en múltiples peticiones a la API REST).

El resultado del experimento son los siguientes:

Page 5: Apis Agregadas computomasivo

5

La aplicación móvil cuando se utilizan las llamadas AJAX asíncronas típicos (rojo), el usuario

final ve un promedio de tiempo de carga de página de 815 ms, se define como una mala

experiencia de usuari. Y cuando se utiliza las APIs agregadas, el tiempo medio de carga de la

página podría bajar a 278 ms (barras verdes).

Modelos de APIs Agregadas en el mercado

Existe una amplia diversidad en cómo se obtienen los resultados de las empresas que ofertan

APIS de agregación. Algunos tienen una relación de tipo uno a uno: extraen datos de una fuente

de API y la envían a otra. Algunos tienen un modelo de varios a uno que extrae servicios y

datos de múltiples fuentes de API y lo entrega en una salida, por ejemplo, una visualización.

Recientemente, ha surgido un servicio de agregación más reciente que ofrece soluciones de

muchos a uno que dibujan servicios y datos de múltiples APIs y luego lo vuelven a empaquetar

en una API para que los usuarios finales puedan acceder.

Los servicios extraen contenido basado en palabras clave relevantes (o hashtags) y lo muestran

en un formato establecido. Utilizan API para recopilar los datos de fuentes de medios externos

y luego empaquetan los resultados, a menudo actualizando periódicamente los feeds en tiempo

real (refrescando las llamadas a la API con una duración de 10 minutos aproximadamente).

Entre algunos servicios, los planes de suscripción avanzada pueden proporcionar los resultados

a los clientes finales en formato API.

Page 6: Apis Agregadas computomasivo

6

DESCRIPCIÓN 1. API AGREGADAS

PARA

AUTOMATIZACIÓN

2. API AGREGADAS PARA

PRODUCCIÓN CREATIVA

3. AGREGACIÓN DE API

PARA ENTREGA DE

CONTENIDO

4. API AGREGADAS PARA LA

VISUALIZACIÓN DE BI Y

ANÁLISIS

OBJETIVO Extrae datos de API de una

fuente hace el envió a otra.

Extraer datos de múltiples fuentes,

los combina y luego los envía

como la salida

Extrae datos de varias API y envía

a una salida visual

Extrae datos de múltiples fuentes de

API y los envía a una salida visual

(panel o dashboard).

CARACTERISTICAS Con niveles de precios

establecidos por número de

integraciones y / o número de

llamadas de API realizadas

cada mes.

Tienden a tener una biblioteca

de SaaS y (cada vez más)

servicios de IoT que se pueden

integrar con cualquier otro

servicio para crear un flujo de

trabajo automatizado.

La empresa utiliza las API del

servicio externo para crear

integraciones que permiten a

los clientes que no son

programadores integrar

fácilmente las API en un flujo

de trabajo transparente.

Las agencias creativas y las

empresas digitales de relaciones

públicas son un sector en

crecimiento de los consumidores

de la API, no solo utilizando API

para monitorear análisis de

marketing o medios sociales, sino

como parte de la campaña de

relaciones públicas.

Los servicios extraen contenido

basado en palabras clave relevantes

(o hashtags) y lo muestran en un

formato establecido.

Utilizan API para recopilar los

datos de fuentes de medios

externos y luego empaquetan los

resultados, a menudo actualizando

periódicamente los feeds en tiempo

real (refrescando las llamadas a la

API con una duración de 10

minutos aproximadamente).

Entre algunos servicios, los planes

de suscripción avanzada pueden

proporcionar los resultados a los

clientes finales en formato API.

Modelo de suscripción.

Agregadores de automatización,

servicios de tablero de instrumentos

como Ducksboard proporcionar una

biblioteca de los servicios que se

pueden extraer de (detrás de las

escenas, el acceso a la API

correspondiente), junto con los datos

de la compañía privada para crear la

analítica y paneles de inteligencia

empresarial para los usuarios finales.

Page 7: Apis Agregadas computomasivo

7

EJEMPLOS DE

PROVEEDORES

IFTTT, Zapier, Itduzzit,

Temboo.

Zapier es uno de los

proveedores más grandes en

este espacio y acaba de

terminar una revisión de su

interfaz de usuario.

Temboo toma un tacto

ligeramente diferente: su

servicio ayuda a los

programadores a conectar

varias API en un flujo de

trabajo automatizado y luego

crea los fragmentos de código

que un consumidor-

desarrollador puede pegar en

su aplicación.

Fujitsu RunMyProcess utiliza

fuentes API para crear y

automatizar flujos de trabajo

extensos en todo el proceso,

no sólo para tareas

individuales.

Creative agencies (Deportivo)

utiliza las API como parte de su

"paleta creativa" para diseñar

campañas digitales para sus

clientes de marca. Tiene unas API

agregadas de una variedad de

fuentes para crear campañas

atractivas en medios sociales o en

espacios públicos para interactuar

con los públicos objetivo.

Digital PR firms

Swayy, Tagboard. Ducksboard, Adigami, Sush.io, Good

Data.

Ducksboard proporciona una

biblioteca de los servicios que

pueden extraer, junto con datos

privados para crear paneles analíticos

y de inteligencia empresarial para los

usuarios finales, que generan

competencia, rentabilidad y

crecimiento.

sush.io se enfoca en los paneles de

análisis de marketing basados en el

uso de feeds API de proveedores de

SaaS de marketing.

Good Data ofrece un servicio

dirigido a clientes empresariales.

Adigami agrupan las API agregadas

para que se repita en una sola API.

Page 8: Apis Agregadas computomasivo

8

Cómputo Masivo

Trabajar con grandes volúmenes de datos es prácticamente imposible con los recursos

disponibles en las computadoras personales modernas. Para lidiar con este problema se divide

la tarea en partes que trabajan de forma independiente. Esto es conocido como cómputo en

paralelo (cómputo masivo) y puede realizarse sobre distintos núcleos en una misma

computadora o sobre diferentes computadoras agrupadas en un clúster. Un clúster es un

conjunto de computadoras que colaboran en la solución de una tarea.

El presente documento analiza la implementación de proyecto utilizando computación masiva.

Ejemplo de Proyecto

Consiste en la implantación de un nuevo sistema de clustering o computación masiva para el

Departamento de Lenguajes y Sistemas Informáticos de la Universitat Politècnica de

Catalunya.

Las principales actividades del departamento son la docencia y la investigación. Es esta faceta

la que requiere de una gran potencia de cálculo dada la complejidad y variedad de los proyectos

que se tratan.

Durante el proyecto se lleva a cabo un análisis de los requisitos para el nuevo sistema de

clustering, se estudia las distintas opciones para realizar una propuesta que finalmente se

implementará.

Análisis preliminar

Situación actual

En el momento de comenzar el proyecto, el Departamento de Lenguajes y Sistemas

Informáticos contaba con tres clusters de computación. Cada uno ellos propiedad de un grupo

de investigación distinto.

El modelo HPC(High performance Computing o cómputo de alto rendimiento) basado en

openMosix[1] que proporcionaba un entorno confortable y productivo para la cantidad inicial

de usuarios, ha quedado obsoleto ante el continuo crecimiento tanto en número de usuarios

como en necesidades de cálculo y espacio de disco.

Page 9: Apis Agregadas computomasivo

9

Igualmente, el esquema lógico de la infraestructura hardware, así como el sistema que sustenta

los datos de usuario, no cuentan con ningún mecanismo que proporcione tolerancia a fallos

(caída de un nodo, fallo de un disco) ni alta disponibilidad.

Objetivos del proyecto

La finalidad de este proyecto es doble. Por una parte, la sustitución de los clusters por uno

nuevo que se adapte a las nuevas necesidades del Departamento y por otra, la creación de una

documentación que sirva como referencia técnica al Laboratorio de Cálculo.

El sistema debe proveer a los usuarios un entorno de trabajo sencillo, amigable y proporcionar

una escalabilidad que permita afrontar el futuro sentando unas bases sólidas.

Sistemas de Clustering

Cluster

Conjunto de hardware y software que reúne a grupos de ordenadores que, unidos mediante

redes de alta velocidad, trabajan de forma conjunta en la resolución de problemas.

Cualquier cluster ofrece uno o varios de los siguientes servicios:

Alto rendimiento

Alta disponibilidad

Balanceo de carga

Escalabilidad

Software de Clustering

Es necesario un software o middleware que se encargue de distribuir los trabajos de los usuarios

entre los nodos disponibles de forma óptima.

openMosix

Middleware de los tres clusters en producción.

Funcionamiento de openMosix:

Migración de procesos: Cada proceso tiene su nodo raíz (UHN, Unique Home Node)

que se corresponde con el nodo que lo ha creado.

Memory ushering: Este subsistema se encarga de migrar las tareas que superan la

memoria disponible en el nodo en el que se ejecutan.

Mosix File System (MFS): MFS permite que sistemas de ficheros de nodos remotos

sea accesibles localmente.

Page 10: Apis Agregadas computomasivo

10

Direct File System Access (DFSA): esta opción permite a los procesos hacer

operaciones de E/S de forma local en nodos remotos.

Diseño e implementación

Estudio, análisis y diseño de una solución

Una vez explicados los distintos componentes que forman un cluster, se dispone a revisar las

especificaciones y concretar los requisitos del proyecto.

El análisis de los requisitos llevará a lo largo del proyecto a plantear varios diseños y

arquitecturas posibles para el nuevo cluster, que tras implementarlos y llevar a cabo las

pertinentes pruebas de integración, estabilidad y rendimiento conducirán a la propuesta final.

Análisis del sistema inicial

El Departamento de LSI (Lenguajes y Sistemas Informáticos) tiene tres clusters de

computación. Cada uno de ellos era independiente de los otros, tanto a nivel físico como lógico.

Se trata de tres clusters del mismo tipo, diferenciándose sólo en el número de nodos que lo

conforman.

A nivel hardware, cada cluster está compuesto de una serie de máquinas (PCs enracables)

conectados a una red privada mediante un switch gigabit ethernet. Una de las máquinas está

conectada a la red de LSI y a la red privada del cluster, sirviendo de puerta de acceso al mismo.

A nivel software todas las máquinas que pertenecen a un mismo cluster cuentan con el mismo

sistema operativo y la misma imagen de kernel, requisito imprescindible al tratarse de máquinas

con un sistema de clustering tipo SSI[2] (Single System Image).

Los motivos que llevan a abandonar el modelo openMosix de cluster son los siguientes:

Antiguo cluster Requerimientos nuevos cluster

No tiene ningún mecanismo de limitación de

recursos: cualquier usuario puede, en un

momento dado, lanzar tantos procesos como

quiera y saturar un nodo o el cluster

completo.

El nuevo cluster debe ofrecer un servicio

igual al que ofrece el sistema actual, es decir,

debe ser capaz de procesar los trabajos de los

usuarios y debe disponer de un espacio de

disco para albergar sus datos y programas en

un sistema de disco centralizado

Presenta problemas con varios tipos de

aplicaciones: el mecanismo de migración

El middleware elegido debe ser

personalizable a nivel de gestión de colas,

Page 11: Apis Agregadas computomasivo

11

automática de openMosix no funciona con

aplicaciones que hacen uso de threads o

memoria compartida.

proyectos, grupos de usuarios, etc. Además,

debe contar con un software de gestión de

imágenes de sistema que permita instalar y

modificar fácilmente el sistema en los nodos

que la componen, de forma que la instalación

y posterior mantenimiento de los nodos (más

de 50) sea asumible.

Estrechamente ligado al kernel: openMosix

impone el kernel de los nodos, siendo el más

reciente de la rama 2.4, sin soporte para el

hardware de los nuevos nodos.

El cluster debe ser monitorizable, es decir,

el administrador debe tener las herramientas

necesarias para controlar el estado de sus

componentes y percatarse de cualquier fallo.

Arquitectura propuesta (GlusterFS)

Cada uno de los seis nodos servidores de disco cuenta con dos discos de 750 GB, que tras

instalar sistema y swap deja una partición exportable de unos 700GB. Lo habitual en los

servidores es utilizar una configuración RAID1 que permita el fallo de un disco sin pérdida de

datos. En el caso del sistema GlusterFS con AFR (Automatic File Replication) los datos de

cada nodo ya están replicados en su peer, por lo que optamos por una configuración RAID0.

De esta manera no se pierde espacio y el acceso al volumen resultante es más rápido.

Pruebas

Test ad-hoc

El siguiente test consiste en la ejecución concurrente de procesos con un alto uso de E/S.

A continuación, se muestra los resultados de la comparación de las pruebas obtenidos

correspondientes a ejecutar un determinado número de procesos de lectura entre las

arquitecturas: Lustre y GlusterFS.

Page 12: Apis Agregadas computomasivo

12

Conclusiones

El tiempo de respuesta de APIs agregadas tiene una considerable disminución

comparado con la API de Ajax

A partir de los resultados obtenidos de las pruebas del nuevo sistema de clustering o

computación masiva para el Departamento de Lenguajes y Sistemas Informáticos de la

Universitat Politècnica de Catalunya elige el modelo de computación masiva

GLusterFS.

Glosario

[1] Sistema de cluster para Linux que permite a varias máquinas actuar como un único

sistema multiprocesador

[2] Todas las computadoras vinculadas dependen de un sistema operativo común

[3] Volumen de trabajo o de información neto que fluye a través de un sistema

[4] Software de replicación de dispositivos de bloque (discos duros, particiones, volúmenes,

etc.)

Referencias

Nuevo sistema de clustering. Revisado el 25 de noviembre de

2016. https://rdlab.cs.upc.edu/docu/html/cluster/#_Toc219597953

Page 13: Apis Agregadas computomasivo

13

API Aggregation: Why It Matters and Eight Different Models. Revisado 25 de

noviembre de 2016, http://www.programmableweb.com/news/api-aggregation-why-

it-matters-and-eight-different-models/2013/12/13

Optimizing the Netflix API. Revisado el 25 de noviembre de 2016.

http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

API AGGREGATOR. Revisado el 25 de noviembre de 2016.

https://github.com/solso/api-aggregator#architecture

Extending REST APIs with API Aggregator. Revisado el 25 de noviembre de 2016.

http://tech.3scale.net/2013/04/18/accelerate-your-mobile-api-with-nginx-and-lua/