UNIVERSIDAD TÉCNICA DEL NORTE

Instituto de postgrado

Andrea GuevaraAlexandra JumaGabriela Valencia

COMPUTACIÓN EN LA NUBE

Investigación de API´S agregadas y cómputo masivo

API´S agregad

as

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

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 de múltiples fuentes, los combina y luego los envía como la salida

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

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

OBJETIVOSAgregadores 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

AdigamiPROVEEDOR

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 mashups remezclando 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 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.

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

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.

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

50

100

150

200

250

300

350

104.5 206.4 303.9 300 292.5 264.3 215.2

98.2

193.3

267.5

238.2

174.4 182.7

120.5

Throughput agregado (MB/s)

GlusterFS Lustre

Concurrencia - Tiempo respuesta(s)

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

Gracias