UNIVERSIDAD TÉCNICA DEL NORTEInstituto de postgrado

Andrea Guevara

Alexandra Juma

Gabriela Valencia

COMPUTACIÓN EN LA NUBE Investigación de API´S

agregadas y cómputo masivo

API´S agregadas

Cómputo masivo

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 recurrentesdebido a su naturaleza genérica y granularidad; cada llamada devuelve sólouna parte de la funcionalidad para una experiencia de usuario dado, lo querequiere aplicaciones cliente para hacer múltiples llamadas que necesitan sermontados con el fin de ser una sola experiencia de usuario.

MODELO

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 solicitudes discretas 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 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).

RESULTADO

El resultado del experimento son

los siguientes:

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.

API AGREGADAS PARA AUTOMATIZACIÓN

Extrae datos de API de una fuente hace el envió a otra.

OBJETIVOCon 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 que se pueden integrar con cualquier otro servicio para crear un flujo de trabajo automatizado.

Las empresas 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

CARACTERISTICAS

Zapier, Temboo

PROVEEDORES

API AGREGADAS PARA PRODUCCIÓN CREATIVA

Extraer datos demúltiples fuentes,los combina yluegolos envía como lasalida

OBJETIVO

Las agencias creativas y lasempresas digitales derelaciones públicas son unsector en crecimiento de losconsumidores de la API, no soloutilizando API para monitorearanálisis de marketing o mediossociales, sino como parte de lacampaña de relacionespúblicas.

CARACTERÍSTICAS

Digital PR firms.

PROVEEDORES

API AGREGADAS PARA LA VISUALIZACIÓN DE BI Y ANÁLISIS

Extrae datos de múltiples fuentes de API y los envía a una salida visual (panel).

OBJETIVOS

Agregadores de automatización, servicios de tablero 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.

CARACTERÍSTICAS

Adigami

PROVEEDOR

API AGREGADAS DE DATOS GRANDES Y PERSONALES

Extrae datos de multiples fuentes API (datos abiertos) y combinan con las API que extraen de las cuentas privadas designadas, analiza y envia los resultados a la salida (dasboards y apps)

OBJETIVOEstos modelos emulan o amplían las ideas principales detrás de los mashupsremezclando datos abiertos con fuentes propietarias, algoritmos y luego agregando los datos privados de los usuarios finales a través de la API para crear informes de inteligencia personal.

Estos pueden ser en forma de aplicaciones, alertas o cuadros de mando que ayudan a los clientes finales a tomar medidas pertinentes.

CARACTERÍSTICAS

API Yodlee interactivo agregada está diseñado para clientes que necesitan acceso y de nivel de reserva de seguridad basado en el permiso para tener acceso a banco de sus clientes, tarjeta de crédito, inversiones y cuentas de crédito.

PROVEEDOR

EJEMPLO

IGG Software desarrolla iBank

El cliente para poder ver una visión holística de sus finanzas en cualquier Apple dispositivo. La ventaja "incorporada" de Envestnet® | Yodlee® Aggregation API permite el cliente para tener sus datos actualizados, todo el tiempo. Diseñado para ayudar al cliente a controlar el gasto, construir ahorros y planificar

Ejemplo: remezclando los datos de tiempo abierto con los datos

propietarios de sus clientes y tal vez otros datos específicos de ubicación

enrutados a través de la API para calcular los riesgos de riesgo climático

para apoyar la toma de decisiones agrícolas locales

CÓMPUTO MASIVO

Trabajar con grandes volúmenes de datos es prácticamente imposible con losrecursos disponibles en las computadoras personales modernas. Para lidiar con esteproblema se divide la tarea en partes que trabajan de forma independiente. Esto esconocido como cómputo en paralelo (cómputo masivo) y puede realizarse sobredistintos núcleos en una misma computadora o sobre diferentes computadorasagrupadas en un clúster. Un clúster es un conjunto de computadoras quecolaboran en la solución de una tarea.

EJEMPLO DE PROYECTO

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

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 Universidad Politécnica de Catalunya.

Las principales actividades del departamento son la docencia y la investigación. Esesta faceta la que requiere de una gran potencia de cálculo dada la complejidad yvariedad de los proyectos que se tratan.

Durante el proyecto se lleva a cabo un análisis de los requisitos para el nuevosistema de clustering, se estudia las distintas opciones para realizar unapropuesta que finalmente se implementará.

ANÁLISIS PRELIMINARSITUACIÓ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 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

OBJETIVOS DEL PROYECTO

La sustitución de los clusters por uno nuevo que se adapte a las nuevas necesidades del Departamento

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

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.

DISEÑO E IMPLEMENTACIÓNESTUDIO, ANÁLISIS Y DISEÑO DE UNA SOLUCIÓN

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.

COMPARACIÓNAntiguo cluster Requerimientos nuevo 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 automática de openMosix no

funciona con aplicaciones que hacen uso de threads o

memoria compartida.

El middleware elegido debe ser personalizable a nivel

de gestión de colas, 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 GlusterFScon 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.

PRUEBASTEST 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.

104,5 206,4 303,9 300 292,5 264,3 215,2

98,2

193,3

267,5

238,2

174,4182,7

120,5

0

50

100

150

200

250

300

350

1-47 2-47,6 3-48,5 6-98 9-152 18-337 36-734

Concurrencia - Tiempo respuesta(s)

Throughput agregado (MB/s)

GlusterFS Lustre

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 Universidad Politécnica de Catalunya elige el modelo de computación masiva GLusterFS.

REFERENCIAS

Nuevo sistema de clustering. Revisado el 25 de noviembre de

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

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

noviembre de 2016, http://www.programmableweb.com/news/api-aggregation-whyit-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

http://solutions.yodlee.com/rs/789-EJH-884/images/CS_IGG-Software-Case-Study.pdf