fcbk
Conéctate con TwitterConéctate con Facebook
8

3 consejos para ti, futuro SysAdmin

4392Puntos

hace 2 meses

En este post resumo 3 consejos sobre escalabilidad de una aplicación, que probablemente te ayudarán cuando llegues a tener este desafío en tu aplicación o empresa.

La cruda realidad

Muchas veces cuando uno comienza joven a trabajar, hay muchas cosas que uno no tiene idea así tenga las mejores habilidades técnicas. Específicamente en mi caso me pasó que entré a Platzi como backend y terminé también administrando los servidores de la aplicación. Resulta que no es lo mismo administrar un sitio o aplicación con unos pocos miles de usuarios a administrar los servidores de cientos de miles de usuarios al mes. Parece obvio, pero no lo es. Gracias a esta experiencia aprendí varias cosas a veces por las malas de como se logra escalar una aplicación web en la nube o en cualquier servicio de infraestructura que tengas a tu disposición y que te explicaré a continuación.

Escalar una aplicación horizontalmente

Por lo general en un sitio pequeño si uno necesita más recursos solo contrata un servidor más grande y migra la aplicación, eso es totalmente válido. Sin embargo cuando tu aplicación crece demasiado vienen nuevos retos: ¿Cómo reaccionas ante una subida de tráfico? ¿Cómo obtienes alta disponibilidad? ¿Qué hacer si el servidor muere? Es aquí cuando el escalamiento horizontal entra en juego, agregar más nodos de una aplicación soluciona estos problemas, trae otros obviamente como el problema de la configuración pero al menos ganas terreno y tiempo contra el problema de subida de tráfico y alta disponibilidad.

Algo a tener en cuenta sobre todo si usas proveedores de cloud como AWS, Azure o Google Cloud es que ellos tienen formas de escalar automáticamente -que requieren configuración-. Muchas veces mejor de lo que uno pudiera hacer, así que te recomiendo que uses por ejemplo Auto Scaling Groups, CloudWatch + Load Balancers para tu aplicación, no es algo indispensable pero hará tu vida más fácil.

Sobre costos $$, escalar verticalmente puede traerte más gastos a largo plazo porque debes mantener un servidor encendido todo el día y muy probablemente usando una porción del total de sus recursos.

Escalar bases de datos

Al contrario de una aplicación web, escalar una base de datos puede ser difícil algunas veces o quizás más crítico, porque al final del día es la información de tu aplicación/empresa. Si crees que tu aplicación tendrá millones de registros y que podrías estar ante una gran aplicación, lo que te recomiendo es pensar en configurar tu base de datos con opción de escalamiento desde el primer día. Obviamente muchas veces uno no hace eso y se encuentra con una base de datos de gran tamaño que ya toca escalar, incluso migrar como en nuestro caso, pasando de MySQL a PostgreSQL, pero eso es tema de otro post.

Si ya tienes una base de datos andando y no está configurada correctamente para escalar, lo mejor es atacarlo ahora, porque seguirá creciendo y luego es más delicado hacer cambios que puedan corromper la base de datos. El escalamiento en base de datos SQL por lo general es vertical, si te quedas corto con el servidor actual una acción fácil es instalar más RAM, disco y procesador, eso es rápido y no requiere una configuración especial más allá de las optimizaciones que desees hacer.

Con respecto a las bases de datos NoSQL, en muchos casos es más sencillo porque están pensada para escalar horizontalmente, siempre hay que tener cautela porque es la información de tu aplicación/empresa. HAZ BACKUPS.

Administrar servidores con WebSockets (WS)

Cuando uno está desarrollando un chat que es lo más común que usa WS uno lo ve trivial, monta un servidor, un Nginx o HAProxy y listo, eso andará hasta obtener 5 millones de usuarios con tu servidor de 1GB de RAM y 1 CPU: no hay nada más falso que eso. WebSocket es algo que al principio se ve sencillo pero su administración se complica sobre todo con la forma de escalar, acá el escalamiento vertical es la mejor opción si el crecimiento de tu aplicación es constante pero lento.

Si el caso es el contrario que creces rápido y necesitas aumentar tu disponibilidad en momentos críticos. Como ejemplo: un partido de fútbot, si tu aplicación es un chat de fútbol, los domingo serán días muy movidos, entonces allí debes pensar como configurar HAProxy o Nginx para que mantenga sesiones entre el usuario y el servidor que inició la conexión porque sino tendrás muchos problemas de re-conexión que terminarán aumentando el consumo de tus servidores y haciendo que pierdas dinero e incluso tu aplicación se caiga en medio del momento más importante para tu aplicación.

Ten en mente que los WS podrían consumir bastante recursos de red, es decir tráfico de entrada o salida, así que es importante que tengas ese posible problema en el radar para tomar una buena decisión sobre elegir escalamiento vertical u horizontal.

Resumen

En la mayoría de los casos, en mi humilde opinión, escalar horizontalmente es lo mejor, no lo más fácil pero si lo mejor a largo plazo para tu aplicación. Entiendo también que a veces no hay suficiente presupuesto o tiempo así que no te sientas cohibido de usar el escalamiento vertical si es tu salvación en el momento, lo importante es que tus usuarios puedan acceder a tu aplicación ten en mente eso.

Te recomiendo que veas el siguiente vídeo

Me gustaría que compartieras en los comentarios si ya has trabajado como SysAdmin que es la mayor lección que has aprendido en ese proceso y sino, que te parece más importante a la hora de administrar un servidor.

Espero tu comentario 😃

Yohan
Yohan
@yograterol

4392Puntos

hace 2 meses

Todas sus entradas