Escalabilidad Infinita y tablas Memory-Optimized

 

 

En este post voy a analizar algunos escenarios de escalabilidad de aplicaciones, en particular, aquellos escenarios que pueden verse beneficiados con el uso de tablas memory-optimized.

Los puntos principales del post son los siguientes:

• Rangos de escalabilidad de aplicaciones
• Algunas restricciones a la escalabilidad infinita impuestas por la arquitectura tradicional de base de datos relacionales
• Ventajas de las tablas memory-optimized para sistemas con escalabilidad infinita

Rangos de escalabilidad de aplicaciones

Cuando hablamos de escalabilidad de aplicaciones, nos referimos a la capacidad que tiene una aplicación dada de mantener el mismo nivel de performance ante cantidades crecientes de usuarios concurrentes que la utilizan.

La escalabilidad de aplicaciones puede agruparse en diversos rangos, según el punto de vista del análisis, pero una forma típica es la siguiente:

• Escalabilidad básica
• Escalabilidad intermedia
• Escalabilidad ilimitada o infinita

Escalabilidad básica es el rango mínimo de escalabilidad, que abarca entre uno y unos pocos miles de usuarios concurrentes.

En este rango se ubican aplicaciones de PyMEs y aplicaciones departamentales de grandes empresas.

La edición Express de SQL Server puede atender este rango de escalabilidad.

Este rango no es el foco de este post.

Escalabilidad Intermedia es un rango que abarca entre unos pocos miles y varias decenas de miles a varios cientos de miles (para muchos escenarios) de usuarios concurrentes. Este es el rango de escalabilidad que las ediciones de SQL Server a partir de la Standard pueden proveer (con los recursos apropiados de hardware del server).

En este rango se ubican aplicaciones corporativas del estilo de ERP, portales corporativos, aplicaciones de Helpdesk y otras similares.

En este rango de escalabilidad, las ediciones de SQL Server mencionadas (con los recursos de hardware apropiados), son capaces de atender con alta performance a todo tipo de escenarios. También es importante destacar que a partir de este rango de escalabilidad, es imprescindible usar versiones 64 bits de SQL Server con múltiples procesadores de múltiples núcleos, y con un dimensionamiento adecuado de memoria.

Escalabilidad ilimitada o infinita es el rango que se corresponde con aplicaciones web de uso masivo, a partir de varias decenas de miles de usuarios concurrentes en adelante, sin cota superior definida.

Este rango puede ser atendido por las mismas ediciones ya mencionadas de SQL Server, con los adecuados recursos de hardware en el server, sin embargo, es importante destacar que con cantidades muy grandes de usuarios concurrentes, existen diversos escenarios donde puede aumentar la latencia en las transacciones hasta niveles no deseables: este es el tipo de escenarios que se puede beneficiar con las ventajas de las tablas memory-optimized.

Para poder analizar las ventajas que las tablas memory-optimized ofrecen para este tipo de requerimiento (escalabilidad infinita), es necesario analizar con más detalle algunas de las restricciones a la escalabilidad infinita que imponen algunos elementos de la arquitectura tradicional de los engines de bases de datos relacionales.

Algunas restricciones a la escalabilidad infinita impuestas por la arquitectura tradicional de base de datos relacionales

Vamos a repasar brevemente la secuencia de pasos que ocurren en un server de base de datos SQL Server desde que recibe una solicitud de ejecutar un proceso hasta que el resultado del proceso es retornado al proceso cliente en un contexto de escalabilidad infinita.

Para realizar este breve análisis, me focalizaré en un concepto que es útil para este propósito: el concepto de recurso limitante.

En un contexto de alta escalabilidad, el server de base de datos ha de recibir una cantidad muy alta de Remote Procedure Calls concurrentes, provenientes de procesos cliente.

Para poder atender a todos estas invocaciones concurrentes sin tener que encolarlas, es necesario que el server tenga multiples procesadores con múltiples núcleos.

Desde este punto de vista, el procesamiento paralelo es favorable para cubrir el requerimiento de escalabilidad infinita.

Para poder ejecutar el proceso solicitado, el server ha de verificar si los datos necesarios para dicho proceso están disponibles en el Data Caché.

Este es el primer recurso limitante relevante que se presenta en los diversos pasos a seguir para ejecutar el proceso solicitado.

Si en el Buffer Pool no están todos los datos necesarios, el server debe leer los datos faltantes en los files que los contienen y ubicarlos en el Data Caché para poder ejecutar el proceso solicitado.

Al querer leer los datos faltantes en los files que los contienen, aparece el segundo recurso limitante relevante: que el disco que contiene los files donde se alojan los datos requeridos esté ocupado realizando otra tarea previa.

Esto hace que se debe encolar la tarea de lectura y esperar su turno hasta que pueda ser realizada: esta espera es la causante de los wait types “infames” del tipo PageIOLatch*.

Es importante destacar que tener múltiples procesadores no ayuda para reducir ambos recursos limitantes: es más, cuantos más procesadores tenga el server, es más probable que múltiples invocaciones concurrentes estén “peleando” entre sí por los recursos limitantes mencionados.

También es importante destacar que el aumento de memoria permite tener un Data Caché más grande, y por lo tanto, bajar un poco la probabilidad que el server no encuentre los datos necesarios para ejecutar el proceso solicitado y por lo tanto, tenga que leer dichos datos de los files que los contienen.

En cuanto al recurso limitante que el disco esté ocupado con otra tarea previa, el elemento crucial es la velocidad del disco, y tener más procesadores o más memoria en el server no resuelve  en forma significativa este problema (toda vez que es necesario ir a leer los datos faltantes).

En resumen, las restricciones a la escalabilidad infinita surgen por el tiempo total necesario para ejecutar el proceso solicitado, y dicho tiempo se ve afectado por la espera para leer los datos faltantes, y esto ocurre porque dichos datos no están disponibles en el Data Caché al momento de ejecutar el proceso solicitado.

Por lo tanto, si se puede garantizar que los datos necesarios para un proceso en particular estén “siempre” en memoria, se eliminan las restricciones mencionadas a la escalabilidad infinita.

Justamente, esto es lo que aporta el uso de tablas memory-optimized a los escenarios de escalabilidad infinita.

Ventajas de las tablas memory-optimized para sistemas con escalabilidad infinita

Al eliminar la necesidad de tener que ir a leer al disco los datos faltantes para ejecutar un proceso en particular, el uso de tablas memory-optimized puede mejorar en forma significativa la performance de los procesos que operan con dichas tablas, donde el factor de mejora típicamente es por lo menos un orden de magnitud, y en muchos casos, dos órdenes de magnitud: justamente esto justificó que el codename de esta tecnología sea Hekaton, que literalmente es “cien” en griego.

Este nivel de mejora de performance es crucial para aplicaciones tanto Internet Facing como Cloud.

Para aplicaciones Web Internet Facing, se tiene disponible las tablas memory-optimized en SQL Server 2014 Enterprise (On Premises), mientras que para Cloud-based web applications, se tiene disponible tablas memory-optimized en SQL Azure.

Saludos, GEN

 

Cómo integrar los requerimientos de DBAs y Admins a las decisiones de diseño de una solución

En este post voy a tratar brevemente sobre qué podemos hacer para asegurarnos que los requerimientos de DBAs y Admins están adecuadamente cubiertos por las decisiones de diseño de una solución, en equilibrio con una adecuada cobertura de los requerimientos de los demás stakeholders de dicha solución.

Los puntos principales de este post son los siguientes:

• Los DBAs y Admins también son stakeholders de primer nivel de una solución
• Los requerimientos de DBAs y Admins suelen “asomar” a través de los requerimientos no funcionales de la solución
• Pensar en cómo automatizar el deployment de la solución desde el comienzo
• Incorporar metodologías como DevOps para mejorar la integración con DBAs y Admins en los deployments

Los DBAs y Admins también son stakeholders de primer nivel de una solución

Un problema frecuente que se presenta en la documentación de requerimientos es que resulta poco probable que los usuarios clave entrevistados por los analistas funcionales tengan presentes los requerimientos de los DBAs y de los Admins y los describan con suficiente detalle.

En suma, los requerimientos de los DBAs y Admins pasan a engrosar la lista de los requerimientos “invisibles” de la solución en cuestión: son todos aquellos requerimientos que no tienen un “vocero” que los saque del anonimato, a tiempo.

Lamentablemente, este es un hecho muy frecuente, y un abrumador porcentaje de las soluciones existentes tiene su lista de requerimientos “invisibles”, que típicamente incluye a los requerimientos de los DBAs y Admins.

Un elemento que contribuye a que los requerimientos de los DBAs y Admins sean “invisibles” es que la gran mayoría de los usuarios no comprende de qué forma puede comprometer seriamente la correcta operación de la solución si los requerimientos de los DBAs y Admins no están adecuadamente cubiertos.

Qué podríamos hacer para mejorar esto ?

Existe una alternativa de resolución muy simple: que el arquitecto sea el que “saque del anonimato” a los requerimientos de DBAs y Admins, junto con otros requerimientos “invisibles” importantes.

Una forma apropiada para hacer esto es que el arquitecto le sugiera a los analistas funcionales como orientar las preguntas de requerimientos en general, y en particular, sobre los no funcionales.

Los requerimientos de DBAs y Admins suelen “asomar” a través de los requerimientos no funcionales de la solución

Ciertamente, los requerimientos de los DBAs y los Admins no son “completamente invisibles”, más bien, son altamente “transparentes”, ya que estos requerimientos suelen “asomar” en forma velada o indirecta a través de los requerimientos no funcionales que los usuarios normalmente describen.

Por diversas razones, tanto prácticas como técnicas, los arquitectos preferimos agrupar los requerimientos de una solución en categorías que se denominan Quality Attributes.

Consideremos brevemente algunos Quality Attributes (QAs) relevantes que suelen “hacer visibles” a algunos de los requerimientos de DBAs y Admins:

• Performance
• Escalabilidad
• Seguridad
• Alta Disponibilidad/Disaster Recovery (HA/DR)
• Mantenibilidad
• Administrabilidad

Veamos un ejemplo sobre como algunos requerimientos de seguridad pueden “hacer visibles” a requerimientos importantes de DBAs, Admins y otras áreas.

Supongamos que un documento de requerimientos de una solución dice algo similar a lo siguiente:

“Esta solución Web debe ser Internet Facing, dado que debe soportar tanto a usuarios de Intranet como a usuarios de Extranet”

Esta sola frase remite a requerimientos de los DBAs, de los Admins y de Seguridad Informática.

Repasemos brevemente las implicancias que esta frase tiene en las decisiones de diseño para que la solución cubra adecuadamente los requerimientos de DBAs, Admins y Seguridad Informática que “asoman”.

Los Web Front End servers de esta Web Application deben estar en la DMZ o red perimetral, dado que la Web Application en cuestión es Internet Facing.

Dado que la DMZ es una “zona no segura”, la DMZ no puede alojar ni a la capa de lógica de negocios ni a la capa de acceso a datos: solamente debería estar la capa de presentación de la Web Application en la DMZ.

Los requests y responses de los RPCs desde el código de la capa de presentación de la Web Application a la capa de lógica de negocios deben pasar a través de un firewall, por lo tanto, dichas invocaciones deberían estar “montadas” sobre el protocolo HTTP/HTTPS para ser viables.

Queda claro que la arquitectura típica presente en una cantidad importante de Web Applications existentes no es capaz de cumplir con las condiciones y requerimientos mencionados.

Por lo tanto, tal vez sea necesario revisar algunas de las decisiones de diseño que comúnmente se toman en Web Applications para que puedan cubrir estos requerimientos importantes de seguridad en forma adecuada.

En cuanto a los QAs de Mantenibilidad y Administrabilidad, podemos repasar brevemente como la forma en que registramos las excepciones arrojadas por la solución tienen implicancias cruzadas en ambos QAs.

Para los DBAs y Admins, sería conveniente que la solución registre las excepciones en el event log de cada server donde las mismas emergen, mientras que para el equipo de production support que ha de dar soporte (bug fixing e implementación de cambios de requerimientos) a la solución en producción, sería conveniente que la solución registre las excepciones en archivos de log en directorios de red a los que ellos tengan acceso.

Es importante destacar que el equipo de production support tal vez necesite que estos archivos de log registren detalles adicionales de las excepciones que serían un “exceso de información” para los DBAs y Admins, por lo tanto, las decisiones de diseño deberían cubrir en forma adecuada y equilibrada las diferencias en los detalles de información de excepciones a registrar para estos dos grupos.

En relación con el QA de Alta Disponibilidad/Disaster Recovery (HA/DR), debemos contemplar que si bien como primera aproximación es aceptable decir que las implementaciones de alta disponibilidad que soportan medidas de failover automático (como Failover Clustering y Database Mirroring, o las diversas configuraciones de AlwaysOn, en SQL Server) son transparentes a la lógica de los sistemas de información que las usan, lo correcto sería verificar con pruebas de carga con volúmenes y picos de transacciones comparables a los reales el grado de aumento de la latencia en las transacciones, debido a los procesos adicionales necesarios para el soporte de Alta Disponibilidad.

En suma, podemos encontrar que los requerimientos de todos los QAs mencionados tienen diversas y serias implicancias a nivel de las decisiones de diseño que permitan dar una cobertura apropiada a las requerimientos de DBAs y Admins que se desprenden (se “hacen visibles” a través) de dichos QAs.

Tarde o temprano, las decisiones de diseño que debemos tomar para dar adecuada y balanceada cobertura a todos los requerimientos derivan en una arquitectura distribuida, como una diversa cantidad de componentes a instalar en diversos servers.

No hay nada de malo en una arquitectura distribuida con diversos componentes a ser instalados en una serie de servers: es cierto, en sí mismo, no tiene nada de malo, pero debemos contemplar algunas de sus consecuencias.

Por ejemplo, un proceso manual de instalación y configuración de estos diversos componentes en diversos servers no es lo más recomendable, dado que podría ser propenso a diversos errores de instalación y/o configuración no evidentes (errores de instalación y/o configuración que no arrojan mensajes de error durante el proceso manual de instalación, configuración y prueba).

Para eliminar o mitigar la ocurrencia de este tipo de errores, es conveniente que contemos con procesos automáticos de deployment de los diversos componentes de la solución.

Pensar en cómo automatizar el deployment de la solución desde el comienzo

Ya hemos visto muy brevemente que debemos considerar con mucho detenimiento las decisiones de diseño que tomamos para asegurar una adecuada y equilibrada cobertura de todos los requerimientos de una solución, y además, hemos visto que las decisiones de diseño que tomamos tienen implicancias que afectan a estos requerimientos (por ejemplo, ya vimos como una arquitectura distribuida tiene implicancias en el deployment de la misma).

Por lo tanto, es necesario que empecemos a pensar en los procesos automáticos de deployment de la solución desde las etapas tempranas del diseño y del desarrollo, dado que si dejamos esto para el final, corremos el riesgo de descubrir (tarde) que algunas decisiones de diseño no “suman” a la automatización del deployment.

Es importante destacar que esto no implica trabajo adicional, sino que tan solo cambiar la decisión de que tan temprano se empieza a diseñar y desarrollar el proceso de deployment automático de la solución.

Para un equipo de desarrollo que utiliza Agile, debería ser algo bastante natural usar métodos automáticos de deployment.

Una de las prácticas de Agile es tener builds frecuentes durante la ejecución de una iteración o Sprint, como mínimo, en la medida de lo posible, un build diario, aunque sería mucho mejor si el equipo pudiese implementar un proceso de continuous delivery: poder realizar un build a pedido en cualquier momento, y si el mismo es exitoso, a continuación hacer un deployment automático a un entorno en particular de todos los componentes actualizados, recién generados en el build.

En sí mismo, para poder realizar un build a pedido, es necesario automatizar una serie compleja y larga de tareas, que incluyen procesos automáticos de copia coordinada de archivos a determinados directorios de red, junto con la invocación automática (y también coordinada) de determinados procesos (ejecución de procesos de verificación de estilos y standards de programación, ejecución de procesos automáticos de unit testing, ejecución de procesos automáticos de compilación y linking, etc.)

Los equipos de desarrollo Agile suelen usar determinadas tools open source para automatizar builds e integrations, tales como Ant o NAnt.

Por su parte, los DBAs y los Admins suelen usar tools como Perl, Python o PowerShell para automatizar procesos de administración.

Es altamente recomendable que los procesos automáticos de deployment, que han de ser ejecutados por los DBAs y Admins, estén desarrollados con las tools que los DBAs y Admins acostumbrar usar.

Por lo tanto, es altamente recomendable que el equipo de desarrollo adquiera la experiencia necesaria para desarrollar con fluidez en Perl, Python, PowerShell u otra tool, según corresponda.

Queda claro que tanto para el equipo de desarrollo como para el equipo de DBAs y Admins será de mucho valor agregado buscar formas de integrar el trabajo en conjunto que deben realizar.

Incorporar metodologías como DevOps para mejorar la integración con DBAs y Admins en los deployments

Qué podemos hacer para mejorar la integración del equipo de desarrollo con el equipo de DBAs y Admins?

A priori, esto parecería ser algo complicado de lograr, dado que, típicamente, el equipo de desarrollo usa procesos como Agile, por ejemplo, mientras de los DBAs y los Admins usan procesos como ITIL, por ejemplo.

A pesar que estos dos tipos de procesos parecerían presentar dificultades de reconciliación para poder pensar que sería posible tener procesos integrados, en realidad, es una tarea menos complicada de lo que parece, e inclusive, existen metodologías exitosas que permiten integrar los procesos de ambos equipos para aquellas tareas que deben diseñar e implementar en forma conjunta y coordinada.

Una de tales metodologías es DevOps

(para más detalles, ver definiciones y tools)

Como cierre, les dejo dos ideas para reflexionar:

“Los arquitectos debemos entablar un diálogo fluido, cordial y frecuente con los DBAs y Admins, de tal forma que seamos ‘todos juntos contra el problema’, en vez de ‘estar enfrentados por el problema’”.

“Si hemos de desarrollar soluciones que tengan a SQL Server como repositorio de persistencia, los arquitectos debemos ampliar tanto el alcance como la profundidad de los conocimientos que tenemos sobre las diversas capacidades que soporta esta herramienta”

Saludos, GEN