Si es un desarrollador, crear un sitio web y servirlo a los usuarios puede ser lo más placentero para usted. Después de todo, trabajó duro e intentó crear algo valioso para los usuarios. Cuando ve que una gran cantidad de usuarios han comenzado a usar sus servicios y día tras día los números aumentan, realmente se siente increíble y comienza a pensar en llevar sus servicios al siguiente nivel. Se siente bien al ver los números crecientes, pero pronto se da cuenta de que su máquina o servidor ya no puede manejar grandes cantidades de requests y puede dejar de responder en cualquier momento. Ahora necesita encontrar una solución para escalar su aplicación para la enorme cantidad de requests. ¿Cómo resolvería este problema?, ¿Qué enfoque seguirá para escalar su aplicación?
No importa para qué empresa esté trabajando o qué tipo de sitio web esté creando, la mayoría de las veces se enfrentará a este tipo de escenario y, como desarrollador, sería su responsabilidad encontrar la solución a este problema. bien. Tendrá que ampliar la accesibilidad, el poder y la presencia de su aplicación. Puede resolver este problema agregando hardware adicional o actualizando la configuración actual del sistema, lo que se denomina escalabilidad . En este blog, hablaremos sobre cómo escalar una aplicación, que también es un concepto importante de una ronda de entrevistas de diseño de sistemas. Si su objetivo es ingresar a una gran empresa tecnológica gigante, entonces debe conocer muy bien este concepto para esta ronda.
La opción para escalar su base de datos se puede agrupar en dos categorías principales…
- Escala vertical
- Escala horizontal
1. Escala vertical
En términos simples, actualizar la capacidad de una sola máquina o pasar a una nueva máquina con más potencia se denomina escalamiento vertical. Puede agregar más potencia a su máquina agregando mejores procesadores, aumentando la memoria RAM u otros ajustes para aumentar la potencia. El escalado vertical se puede lograr fácilmente cambiando de máquinas pequeñas a más grandes, pero recuerde que esto implica tiempo de inactividad. Puede mejorar la capacidad de su servidor sin manipular su código.
- Este enfoque también se conoce como el enfoque de » ampliación «.
- No requiere ninguna partición de datos y todo el tráfico reside en un solo Node con más capacidad .
- Fácil implementación.
- Menos esfuerzos administrativos ya que necesita administrar un solo sistema.
- Se mantiene la compatibilidad de aplicaciones.
- Se utiliza principalmente en pequeñas y medianas empresas.
- MySQL y Amazon RDS son un buen ejemplo de escalado vertical.
inconvenientes
- Escalado limitado.
- Potencial limitado para mejorar la E/S de red o la E/S de disco.
- Reemplazar el servidor requerirá tiempo de inactividad en este enfoque.
- Mayor riesgo de interrupciones y fallas de hardware.
- Alcance finito de capacidad de actualización en el futuro.
- El costo de implementación es caro.
2. Escala horizontal
Este enfoque es la mejor solución para proyectos que tienen requisitos de alta disponibilidad o conmutación por error. En el escalado horizontal, mejoramos el rendimiento del servidor agregando más máquinas a la red, compartiendo el procesamiento y la carga de trabajo de la memoria entre múltiples dispositivos. Simplemente agregamos más instancias del servidor al grupo de servidores existente y distribuimos la carga entre estos servidores. En este enfoque, no hay necesidad de cambiar la capacidad del servidor o reemplazar el servidor. Además, al igual que la escala vertical, no hay tiempo de inactividad al agregar más servidores a la red. La mayoría de las organizaciones eligen este enfoque porque incluye aumentar la concurrencia de E/S, reducir la carga en los Nodes existentes y aumentar la capacidad del disco.
- Este enfoque también se conoce como el enfoque de ‘ escala horizontal ‘.
- La escalabilidad horizontal se puede lograr con la ayuda de un sistema de archivos distribuido, agrupamiento y equilibrio de carga.
- El tráfico se puede gestionar de forma eficaz.
- Más fácil de ejecutar la tolerancia a fallas.
- Fácil de actualizar
- Disponibilidad instantánea y continua.
- Fácil de dimensionar y cambiar el tamaño correctamente según sus necesidades.
- El costo de implementación es menos costoso en comparación con la ampliación
- Google con su Gmail y YouTube, Yahoo, Facebook, eBay, Amazon, etc. utilizan mucho la escala horizontal.
- Cassandra y MongoDB son un buen ejemplo de escalado horizontal.
inconvenientes
- Diseño arquitectónico complicado
- Altas tarifas de licencia
- Altos costos de servicios públicos (refrigeración y electricidad)
- El requisito de equipos de red adicionales, como enrutadores y conmutadores.
Una breve comparación
Hemos entendido el significado de las dos categorías principales de escalado de una aplicación. También hemos discutido algunos pros y contras de cada uno de ellos. Hagamos una comparación rápida de estos dos enfoques basándonos en estos pros y contras…
Escala horizontal |
Escala vertical |
---|---|
Equilibrio de carga requerido | No se requiere equilibrio de carga |
Resistente a fallas del sistema | Punto único de fallo |
Utiliza llamadas de red | Comunicación entre procesos |
Inconsistencia de datos | Datos consistentes |
escala bien | Límite de hardware |
- Equilibrio de carga: el escalado horizontal requiere equilibrio de carga para distribuir o distribuir el tráfico entre varias máquinas. En la máquina vertical, solo hay una máquina para manejar la carga, por lo que no requiere un balanceador de carga.
- Resistencia a fallas: el escalado horizontal es más resistente a las fallas del sistema. Si una de las máquinas falla, puede redirigir la solicitud a otra máquina y la aplicación no sufrirá tiempos de inactividad. Esto no es en el caso del escalado vertical, tiene una sola máquina por lo que tendrá un único punto de falla. Esto simplemente significa que en el escalado horizontal puede lograr la disponibilidad, pero en el escalado vertical, la base de datos aún se ejecuta en un solo cuadro, por lo que no mejora la disponibilidad.
- Comunicación de máquinas: el escalado horizontal requiere comunicación de red, o llamadas, entre máquinas. Las llamadas de red son lentas y más propensas a fallar. Esto no es en el caso de la escala vertical, la escala vertical funciona en la comunicación entre procesos que es bastante rápida.
- Coherencia de datos: los datos son inconsistentes en la escala horizontal porque diferentes máquinas manejan diferentes requests, lo que puede provocar que sus datos no estén sincronizados, lo que debe abordarse. Por otro lado, las máquinas verticales tienen una sola máquina a la que se redirigirán todas las requests, por lo que no hay problema de inconsistencia de datos en el escalado vertical.
- Limitaciones: según el presupuesto, el espacio o los requisitos, puede agregar tantos servidores como desee en la escala horizontal y escalar su aplicación tanto como desee. Esto no es en el caso de la escala vertical. Hay un límite finito a la capacidad alcanzable con escalado vertical. Escalar más allá de esa capacidad da como resultado tiempo de inactividad y viene con un límite superior. Por lo tanto, una sola máquina solo puede mejorarse hasta que alcance los límites actuales de la informática.
¿Cuál es el adecuado para una aplicación?
Después de una comprensión justa de ambas opciones, podemos ver que ambas tienen algunos pros y contras. Siempre habrá algunas compensaciones, por lo que puede ser un poco más complicado para los desarrolladores decidir cuál es mejor para una aplicación. Necesitas tomar una decisión inteligente aquí. En primer lugar, debe identificar sus requisitos, objetivos comerciales y áreas en las que nos gustaría agregar valor. Luego tome decisiones de diseño importantes cuestionándonos a nosotros mismos, desarrollando prototipos y refinando el diseño. Ciertos factores son importantes a considerar para una mejor comprensión de su objetivo o requisito comercial. Algunos de ellos son…
- Requisitos de rendimiento o características de rendimiento de una aplicación.
- rendimiento del sistema
- Tiempo de respuesta del sistema
- Requisito de disponibilidad del sistema
- ¿El sistema es tolerante a fallas? Si es así, ¿cuál es el grado de la misma?
- ¿Es fiable el diseño?
- ¿Qué nivel de consistencia nos importa?
- ¿Cuál es el objetivo de escalabilidad de la aplicación (es posible que tenga un objetivo a corto plazo o inmediato, pero ¿qué sucederá a largo plazo?)
Todos los factores anteriores lo ayudarán a identificar el objetivo comercial y los requisitos para su aplicación. Cualquiera que sea la opción que elija, idealmente debería poder responder las preguntas anteriores y muchas otras similares. Debe tener una comprensión clara de las diferencias entre estos 2 enfoques de escala. Identifique lo que se adapta a sus requisitos y vea si la aplicación realmente se ajusta al modelo que elija. Si su objetivo es lograr un rendimiento superior, puede utilizar el escalado vertical o el escalado horizontal, o ambos, en un entorno de nube.
Si tiene curiosidad por saber qué usan las grandes empresas tecnológicas reales al escalar sus sistemas, entonces la respuesta es ambas. La mayoría de las veces, en las grandes organizaciones, los ingenieros toman algunas buenas cualidades de escalado vertical y algunas buenas cualidades de escalado horizontal. Siguen el enfoque híbrido de combinar la velocidad y la coherencia del escalado vertical con la resiliencia y la escalabilidad infinita del escalado horizontal.
Simplemente agregar nuevo hardware y agregar más Nodes o máquinas no es la forma de comenzar. Debe observar cuidadosamente los requisitos de su solicitud antes de tomar una decisión. Si los requisitos se pueden cumplir aumentando la capacidad o ajustando las características de una sola máquina, entonces opte por la escala vertical (especialmente para las empresas emergentes), pero una vez que los usuarios comiencen a crecer rápidamente y necesite reemplazar el sistema con bastante frecuencia, opte por la escala horizontal. escalado o la combinación de ambos.
Publicación traducida automáticamente
Artículo escrito por anuupadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA