El documento analiza las API agregadas y el cómputo masivo. Explica que las API agregadas combinan múltiples solicitudes REST en una sola llamada para reducir la latencia. También describe diferentes modelos de API agregadas como las de automatización, producción creativa y visualización de datos. Finalmente, presenta un caso práctico sobre la implementación de un sistema de cómputo masivo basado en GlusterFS en una universidad.

1. UNIVERSIDAD TÉCNICA DEL NORTE
Instituto de postgrado
Andrea Guevara
Alexandra Juma
Gabriela Valencia

2. COMPUTACIÓN EN LA NUBE Investigación de API´S
agregadas y cómputo masivo

3. API´S
agregadas
Cómputo
masivo

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

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

6. MODELO
Este modelo de interacción se ilustra en el siguiente diagrama:

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

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

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

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

11. RESULTADO
El resultado del experimento son
los siguientes:

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

13. API AGREGADAS PARA AUTOMATIZACIÓN
Extrae datos de API de una
fuente hace el envió a otra.
OBJETIVO
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 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

14. API AGREGADAS PARA PRODUCCIÓN CREATIVA
Extraer datos de
múltiples fuentes,
los combina y
luego
los envía como la
salida
OBJETIVO
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.
CARACTERÍSTICAS
Digital PR firms.
PROVEEDORES

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

16. 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)
OBJETIVO
Estos 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

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

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

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

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

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

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

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

24. DISEÑO E IMPLEMENTACIÓN
ESTUDIO, 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.

25. COMPARACIÓN
Antiguo 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.

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

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

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

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

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