[26/07/2021] Las nuevas empresas emergentes de SaaS rara vez piensan en cómo incrementar el tamaño de sus aplicaciones. Claro, imaginan el día en que necesitarán expandirse e incorporan crecimiento en sus planes financieros, pero rara vez diseñan sus aplicaciones para la escalabilidad desde el principio. Por el contrario, se centran más a menudo en completar funciones que pueden vender.
Pero el momento de pensar en la ampliación es desde el principio, antes de que su primer cliente se registre en su servicio. A medida que la empresa implementa función tras función, y los clientes continúan registrándose, el negocio crece. A medida que el negocio crece, el incremento de escala se convierte en un motivo de preocupación.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Con frecuencia, la necesidad de incrementar en escala se hace evidente cuando un nuevo servicio SaaS alcanza un límite de capacidad de recursos, específicamente la capacidad de recursos de acceso a datos. A menudo, la base de datos, cualquiera que sea la tecnología, es demasiado pequeña para satisfacer las crecientes demandas, y no se puede expandir más allá de cierto punto.
Este problema puede ocurrir independientemente de la tecnología de base de datos que utilice y del tamaño del servidor, u otra infraestructura que instale para tener espacio para crecer. Tarde o temprano, encontrará problemas de escala.
Una vez que el muro de recursos de crecimiento se hace evidente, y es necesario tomar decisiones de incremento de escala serias, la fragmentación de los datos -dividir sus datos en múltiples bases de datos paralelas donde cada base de datos contiene un segmento de su negocio- es a menudo una de las primeras soluciones que se introducen para expandir la capacidad de incrementar la escala de su aplicación. Existen muchas razones para esto:
1. Dividir sus datos en múltiples segmentos es, aparentemente, una solución simple para resolver problemas con los recursos de los datos. Si una base de datos es demasiado pequeña para manejar su tráfico, ¡intentemos con dos, tres o cuatro!
2. Una vez que haya fragmentado los datos de su aplicación, aparentemente, es muy simple continuar incrementando en escala usando el mismo enfoque: a medida que su tráfico crece, simplemente agregue más bases de datos paralelas a su aplicación.
Echemos un vistazo más de cerca a la fragmentación, y cómo se usa para resolver problemas iniciales de escala de la base de datos.
Un ejemplo simple de fragmentación
¿Qué es exactamente la fragmentación? Un caso de uso típico de SaaS implica que los clientes se comuniquen con alguna aplicación, que luego hace uso de los datos almacenados en una base de datos. A medida que aumenta el número de clientes, aumenta la carga de la aplicación. Por lo general, es relativamente fácil aumentar la capacidad de la aplicación agregando más servidores para manejar la carga. (Esto, por supuesto, tiene límites y vale la pena discutirlo por separado en otro momento).
Sin embargo, una vez que llega a un cierto número de clientes, su limitación de escala de repente se convierte en su base de datos. Su base de datos no puede manejar con eficacia a los clientes adicionales y su aplicación terminará con problemas de disponibilidad, problemas de rendimiento y otros problemas. Esto se ilustra en la Figura 1.
Figura 1. Aplicación SaaS alcanzando un límite.Una vez que su base de datos alcanza un cierto tamaño y capacidad, es difícil (si no imposible) hacerla más grande. En su lugar, puede optar por dividir la base de datos en varias bases de datos paralelas y dividir la base de clientes entre las diferentes bases de datos.
En la Figura 2, dividimos a los clientes en dos bases de datos separadas y, de repente, podemos manejar a los clientes adicionales sin problemas. Cada base de datos contiene todos los datos necesarios para soportar a un cliente determinado, pero los clientes individuales se dividen en diferentes bases de datos.
Figura 2. Una aplicación SaaS que usa fragmentación simple.
¿Cómo se dividen los datos en varias bases de datos y se sabe, dentro de la aplicación, qué base de datos tiene los datos de qué cliente? Normalmente, se utiliza una clave de fragmentación para determinar qué base de datos contiene un conjunto particular de datos. A menudo, esta clave de fragmentación es algo como un ID de cliente. Al asignar algunos ID de cliente a una base de datos, y otros ID de cliente a otra base de datos, puede colocar todos los datos de un cliente determinado en una sola base de datos. Por lo tanto, para cada cliente se utilizará una única base de datos para todas las solicitudes de clientes, y se pueden agregar nuevos clientes a nuevas bases de datos a cualquier escala razonable.
Donde la fragmentación sale mal
Entonces, ¿qué tiene de malo este enfoque? Los problemas comienzan cuando sus clientes comienzan a crecer. A medida que los clientes comienzan a usar más la aplicación, comienzan a usar más almacenamiento y a consumir más recursos. De repente, la capacidad de uno de sus fragmentos se sobrecarga y necesita descargar a algunos de sus clientes de un fragmento a otro fragmento (menos cargado). Debe tomar todos los datos de estos clientes, copiarlos en un nuevo fragmento y luego apuntar sus ID de cliente al nuevo fragmento.
Esta no es una operación trivial. Especialmente, no es trivial si desea lograrlo sin causar ningún tiempo de inactividad notable para los clientes. ¿Cómo se mueven muchos datos para un determinado cliente sin afectar la capacidad del cliente para acceder a la aplicación, mientras que el movimiento está ocurriendo? La respuesta generalmente implica escribir herramientas personalizadas. Esta herramienta generalmente no es sencilla de escribir y su ejecución es arriesgada. La Figura 3 ilustra este proceso cuando un "Cliente demasiado grande” sobrecarga una base de datos y usted tiene que moverlos a otra base de datos más nueva.
Figura 3. Descarga de un cliente a un nuevo fragmento.
El siguiente problema que ocurre es cuando un cliente se vuelve tan grande que requiere un fragmento de base de datos completo, por sí solo. Cuando se encuentra en esta situación, ¿qué sucede cuando ese cliente crece un poco más?
Figura 4. Un solo cliente más grande que la partición.
De repente, no hay lugar para mover a este cliente y ha alcanzado otro límite de escala, un límite que su estrategia de fragmentación actual simplemente no puede manejar.
Repartición, reequilibrio, uso sesgado, informes entre fragmentos y analítica particionada son otros problemas que deben tratarse. Sin embargo, la necesidad de manejar tamaños de conjuntos de datos que cambian rápidamente, así como la necesidad de mover datos entre fragmentos, son los mayores desafíos con un mecanismo de fragmentación de calidad.
¿Fragmentar o no fragmentar?
Si no necesita fragmentar, ¡no lo haga! Puede utilizar otras estrategias, incluida la partición de datos por servicio y función en lugar de dividirlos en fragmentos, para manejar el incremento en la escala de datos.
Sin embargo, a veces la fragmentación es inevitable. Entonces, si debe fragmentar, tenga en cuenta lo siguiente:
- Configure sus fragmentos mucho antes de que los necesite. Anticipe su necesidad de fragmentación en función de una escala optimista y fragmente mucho antes de que el uso real lo exija.
- Seleccione su clave de fragmentación con cuidado. Desea que sus fragmentos sean independientes, pero también bien equilibrados. El uso del ID de cliente puede parecer una buena idea -le permite crear conjuntos de datos independientes fácilmente- pero los clientes varían mucho en tamaño y equilibrar fragmentos en función de la identificación de cliente puede ser problemático. Es posible fragmentar en función de otro recurso común, pero la respuesta específica depende, en gran medida, de la lógica del negocio y las necesidades de su aplicación.
- Cree herramientas para administrar sus fragmentos antes de implementarlos en producción. Necesitará las herramientas mucho antes de lo esperado. Las herramientas deben poder mover de forma rápida y eficiente elementos fragmentados individuales (clientes, etc.) de un fragmento a otro de forma transparente. Rápidamente, las herramientas deben poder reequilibrar varios recursos durante un incidente de escala incrementada, y necesita de analítica para alertar cuando el tamaño de los fragmentos se desvíe.
- Piense seriamente en dividir sus datos mediante otros métodos. Considere almacenar sus datos en servicios y microservicios individuales, en lugar de hacerlo en un almacén de datos centralizado. Cuanto más pequeño sea el conjunto de datos, menor será la necesidad de fragmentación y más simple y eficiente será administrar la fragmentación cuando sea necesario.
La mayoría de las aplicaciones modernas experimentan crecimiento -crecimiento en su uso, crecimiento en el tamaño y complejidad de sus datos, crecimiento en la complejidad de la aplicación y crecimiento en la cantidad de personas y el tamaño de la organización necesarios para administrar la aplicación. Es fácil ignorar estos desafíos de crecimiento hasta que sea demasiado tarde, luego usar una solución rápida y fácil para resolver la necesidad inmediata. Pero cuando se trata de fragmentación de datos, la planificación y la ejecución minuciosa son fundamentales para garantizar que esta elección de arquitectura sea una ayuda para el aumento de escala, en lugar de un riesgo.
Basado en el artículo de Lee Atchison (InfoWorld) y editado por CIO Perú
Lee Atchison es un reconocido líder intelectual en computación en la nube y modernización de aplicaciones. Con más de tres décadas de experiencia en el desarrollo de productos, arquitectura, escalado y modernización, Lee ha trabajado en Amazon, Amazon Web Services (AWS), New Relic y otras organizaciones de aplicaciones modernas. Se le cita ampliamente en muchas publicaciones y ha sido un orador destacado en todo el mundo. El libro más reciente de Lee es Architecting for Scale (O'Reilly Media).
Puede ver también: