Serie de charlas tecnológicas: Diseño para la escalabilidad en su nube multiusuario

En Jitterbit, nuestra misión es simplificar incluso los retos de conectividad más complejos y permitir que cualquier persona pueda conectarse en el mundo digital de hoy. Si bien hacemos hincapié en que no es necesario ser desarrollador para usar los productos de Jitterbit, detrás de toda gran solución de software hay un equipo de desarrolladores fantásticos.   En la serie Jitterbit Tech Talk blog, los miembros del equipo de desarrollo de Jitterbit nos ofrecen una visión sobre la creación de una plataforma en la nube de clase empresarial y los retos que tuvieron que resolver en materia de multitenencia, escalabilidad y seguridad.

Esta semana, Pankaj Arora, nuestro director sénior de Tecnología, analiza cómo diseñar y estructurar una plataforma en la nube de clase empresarial altamente escalable.

La nube ofrece a las empresas una manera potente de ofrecer sus productos y servicios con un fácil acceso desde cualquier lugar y en cualquier dispositivo. También proporciona enormes beneficios al proveedor, incluida la visibilidad sobre cómo se utiliza su oferta, un rápido desarrollo e implementación, y reducciones generales en los costos de TI y mantenimiento. Como resultado, casi todas las empresas hoy en día buscan poner sus soluciones disponibles en la nube.

Pero convertirse en una verdadera empresa en la nube va mucho más allá de instalar software en un servidor alojado y ponerle la etiqueta “Nube” a tus materiales de marketing.

Hace poco estuve platicando con un estratega de tecnología y me comentó que alrededor de 75% de empresas desearían migrar sus soluciones empresariales heredadas a la nube. Sorprendentemente, el 90% de ellas elabora un plan inicial basado en una arquitectura en la que sus aplicaciones heredadas simplemente se implementarían en un servidor en la nube de acceso público. Este enfoque anula todos los beneficios que ofrece la nube.

Construir una verdadera plataforma en la nube multiinquilino requiere resolver una serie de diferentes tipos de desafíos, tales como seguridad, confiabilidad, escalabilidad, alta disponibilidad, tolerancia a fallos, registro de eventos (logging), monitoreo, sistema de notificaciones, capacidad de despliegue continuo y más.

En la publicación de hoy, analizaremos más a fondo cómo manejamos el desafío de la ‘escalabilidad’ al desarrollar nuestra plataforma de integración en la nube multiusuario.

El grado de escalabilidad de una aplicación está ligado a su capacidad de escalar vertical y horizontalmente. En un entorno de nube, esto significa diseñar servicios que atiendan solicitudes externas y escalen para poder aprovechar los sistemas de backend internos, como bases de datos, cachés, capas mediadoras, procesos por lotes (motor analítico, motor de recomendaciones), etc., con el fin de manejar solicitudes prácticamente infinitas en un tiempo razonablemente corto. No siempre es posible predecir la cantidad de usuarios que accederán a su plataforma. Diseñar una arquitectura que tenga esto en cuenta en el modelo de multinquilinato ayuda a convertir esta incertidumbre en un problema genérico de escalabilidad.

Escalamiento vertical

La escalabilidad vertical implica agregar recursos como CPU o memoria adicionales a un solo nodo en un sistema, y esto debería ser lo primero en lo que piense al escalar sus servicios. Es muy importante diseñar sus aplicaciones para que utilicen estos recursos de manera óptima. Tome el caso de uso común para nuestra plataforma en la nube de integración híbrida, donde las operaciones de integración son atendidas por un nodo de servidor local o en la nube. Aquí, los servicios deben tomar una solicitud para ejecutar integraciones, pasar la solicitud a los nodos del servidor y continuar atendiendo más solicitudes. La capa de servicios no debe depender ni verse bloqueada por los procesos que ocurren en varias capas del sistema. Como tal, es muy importante contar con una arquitectura asincrónica y orientada a eventos.

Una forma sencilla de entender la arquitectura asincrónica es pensar en tu arquitectura como un restaurante. Un mesero toma los pedidos de una mesa y se los entrega al chef. Mientras el chef, el repartidor de comida y el asistente de limpieza se encargan de actividades como cocinar, servir y limpiar, el mesero continúa atendiendo a nuevos clientes y cobra las cuentas al final del servicio.

Mantener la asincronía mientras el sistema trabaja con todos los componentes como la base de datos, la caché y la capa de mediación es muy importante. Pasar la carga a nodos de servidores agrupados y de alta disponibilidad que ejecutan integraciones libera recursos para que la capa de servicio acepte más solicitudes y responda cuando los procesos se completen.

Escalado horizontal

La siguiente consideración clave debe ser que los servicios estén escritos de tal manera que no importe cuántas instancias de esos servicios se estén ejecutando y qué sistema compartido esté realizando transacciones en un momento dado. Esto le otorga a nuestra plataforma en la nube flexibilidad para escalar automáticamente la capa de servicios. Cada parte del backend está altamente disponible y es autoescalable para mantenerse al día con la demanda de contenedores de servicio en crecimiento.

Sin embargo, no podemos tener contenedores infinitos ejecutando capas de servicio que utilicen componentes compartidos. Ese no es el diseño óptimo. Volvamos a nuestro ejemplo del restaurante. Con el escalamiento vertical, un solo restaurante podría volverse altamente escalable añadiendo más personal, pero en cierto punto, la cantidad de recursos (cocineros, corredores, ayudantes de camarero) llegará a un punto de saturación. Para escalar aún más, este negocio necesitaría abrir ubicaciones adicionales que ayudarían a distribuir a los clientes y equilibrar la carga.

Es mejor dividir toda la plataforma en múltiples zonas, y cada zona se comporta como una réplica de la zona inicial. Esto nos permite usar múltiples zonas para equilibrar la carga de necesidades futuras.

Este modelo tiene múltiples ventajas:

1. Posible escalamiento horizontal infinito, ya que podemos incorporar cualquier cantidad de zonas

2. Tolerancia a fallas, en caso de que toda la zona falle debido a un desastre natural

3. Separación de datos, en el caso de una plataforma SaaS que requiere incluso segregación de metadatos basada en la ubicación, como para las zonas de EE. UU., EMEA, etc.

El resultado deseado aquí es que la experiencia del usuario sea la misma sin importar dónde se encuentre y a qué zona acceda. No se debe requerir ninguna intervención manual por parte del usuario para realizar el trabajo.

En nuestro nube de integración híbrida blog, discutimos cómo nos topamos con el desafío de usar una capa mediadora de tal manera que admitiera una escala vertical limitada. Al escribir nuestra propia capa de conexión personalizada y no bloqueante basada en transporte HTTPS seguro, pudimos ampliar la arquitectura para lograr una escala vertical 50 veces mayor. Por supuesto, también es escalable horizontalmente. Esta combinación de escalado vertical y horizontal nos proporcionó una capa más económica y fácilmente extensible para satisfacer nuestras crecientes necesidades.

Optimización del uso de componentes compartidos:

Los componentes compartidos deben ser, a su vez, escalables y de alta disponibilidad para respaldar la plataforma en la nube. Sin embargo, al ser compartidos, no son tan escalables como la capa de servicios. Es muy importante prestar especial atención a algunos componentes que pueden ser sensibles a una carga elevada, como las bases de datos. Un modelo posible consiste en priorizar y poner en fila los componentes compartidos (usage) cuando una carga simultánea de gran volumen pueda causar problemas. La priorización puede reducir la carga y mitigar los errores en cualquier solicitud de importancia crítica.   Volviendo a nuestro restaurante, la cocina es un componente compartido y, si bien el mesero puede tomar el pedido de un comensal para un aperitivo, un plato principal y un postre, la cocina priorizará la preparación de estos platillos y equilibrará su carga.

Otra forma de manejar la carga puede ser almacenar en caché los datos que rara vez cambian, para evitar un usage elevado de esos componentes. Si las papas fritas son un platillo popular en el menú, el restaurante podría decidir “almacenar en caché” un lote continuo en lugar de freírlas al momento.

Monitoreo de componentes:

Finalmente, es muy importante monitorear cada componente y conocer sus limitaciones. El sistema debe ser capaz de aumentar el ancho de banda automáticamente y en el momento adecuado para mantener los sistemas en funcionamiento según las necesidades de la plataforma en la nube. El monitoreo puede ser externo o iniciado por la aplicación, pero en cualquier caso el objetivo final es permitir que el sistema se autoescale según la carga.

En la próxima publicación sobre blog, hablaremos sobre el monitoreo, el registro y otros elementos de la arquitectura.