Configuración de su aplicación: ¿cómo elegir la mejor configuración de servidor?

Introducción

La tecnología y el internet se han convertido en presencias centrales en nuestra vida cotidiana, académica y profesional. Por eso, la gran cantidad de sitios web y aplicaciones que existen simultáneamente no es una sorpresa. Si usted es una empresa, querrá tener una plataforma web asociada. Una aplicación le permite comercializar y ofrecer sus servicios a sus clientes objetivo con facilidad.

Independientemente del motivo por el que esté creando una aplicación web, debe determinar cómo construirla. Hay muchas opciones a su disposición a la hora de elegir la mejor configuración de servidor. La arquitectura de servidor por la que se decida determinará cómo ejecuta y gestiona todo en su entorno. Por eso, la decisión debe tomarse tras una cuidadosa consideración.

Cómo elegir la configuración de servidor adecuada

¿Cómo decidir entonces qué arquitectura es la 'adecuada' para su aplicación? Para ello, primero debe pensar en cuáles son los requisitos de su aplicación web. Debe haber ciertas características que deba incorporar para que funcione de manera eficiente para su caso de uso específico. Por ejemplo, tal vez busque una aplicación que sea fácil de escalar. O tal vez necesite que su aplicación funcione sin problemas tanto en navegadores como en dispositivos móviles. Al mismo tiempo, su presupuesto también puede ser su principal preocupación.

Independientemente de cuáles sean sus requisitos, debe saber que puede crear una solución personalizada para su aplicación. En este tutorial, exploraremos los diversos tipos de servidores que muchas personas utilizan habitualmente para sus aplicaciones web. Hablaremos de los distintos casos de uso y de cuándo es mejor utilizar una determinada configuración. Para ayudarle a decidir si es adecuada para usted, también le presentaremos algunos pros y contras de cada arquitectura de servidor.

1. Todo en un solo servidor

Como sugiere el nombre, se carga todo el entorno en un único servidor. El entorno incluiría su servidor web, su servidor de aplicaciones y el servidor de bases de datos. Por ejemplo, funciona en la configuración de pila Linux, Apache, MySQL, y PHP (LAMP). Puede seguir nuestros tutoriales sobre cómo instalar la pila LAMP en un servidor Ubuntu y cómo instalar la pila LAMP en CentOS.

Cuándo usarlo:

Este tipo de disposición funciona mejor si dispone de poco tiempo. Es sencilla y rápida de configurar. Por eso funciona para aplicaciones web simplistas.

Beneficios:

• Sencillo y fácil de entender e implementar.
• Requiere poco tiempo para configurarse en su totalidad.

Desventajas:

• No permite la escalabilidad horizontal.
• Ofrece muy poco en términos de aislamiento de componentes.
• La aplicación y la base de datos compiten esencialmente por los mismos recursos, ya que se encuentran en un único servidor.
• Como resultado, es posible que experimente un rendimiento deficiente.

2. Servidor de base de datos independiente

El principal problema de utilizar un único servidor es la competencia por recursos limitados. Esta configuración pretende resolver ese problema. Aquí, el sistema de gestión de bases de datos, o DBMS, se mantiene separado del servidor de aplicaciones. El servidor de bases de datos está en una red privada y tiene sus propios recursos. Esto se traduce en un mejor rendimiento y una mayor seguridad.

Cuándo usarlo:

De nuevo, si desea implementar una configuración rápida, esto es bastante sencillo de configurar. Es la solución ideal si le preocupa que la base de datos y la aplicación compitan por los mismos recursos.

Beneficios:

• Recursos de sistema dedicados y separados para la aplicación y la base de datos, incluyendo CPU, memoria, E/S, etc.
• Mayor potencial de escalabilidad tanto en la capa de aplicación como en la de base de datos.
• Puede añadir y eliminar recursos según lo necesite.
• Si retira la base de datos de la internet pública, también puede aumentar su seguridad.

Desventajas:

• Un poco más complejo que la configuración de un solo servidor.
• Una conexión de red de bajo ancho de banda o alta latencia entre los dos servidores puede producir problemas de rendimiento.

3. Proxy inverso o equilibrador de carga

Aquí es donde los equilibradores de carga entran en escena. Los balanceadores de carga se utilizan normalmente en entornos de servidores para mejorar el rendimiento y la confiabilidad. Lo hacen 'balanceando la carga'; es decir, distribuyendo la carga de trabajo a través de una matriz de servidores.

Cuándo usarlo:

Los balanceadores de carga son extremadamente útiles para cuando necesitas realizar escalado horizontal. El escalado horizontal básicamente significa agregar más servidores al entorno. También puedes usar un proxy inverso de capa de aplicación para servir varias aplicaciones a la vez usando un solo dominio y puerto. HAProxy, Nginx, y Varnish son ejemplos de software que permiten el balanceo de carga de proxy inverso.

Beneficios:

• En caso de que un servidor de la línea falle, los otros servidores compensan su función balanceando la carga de trabajo.
• Te permite realizar un escalado horizontal para aumentar o disminuir la capacidad del entorno.
• También limita las conexiones de los clientes, lo que ofrece protección contra ataques DDOS.

Desventajas:

• En caso de que los recursos del sistema no sean suficientes, el balanceador de carga puede limitar el rendimiento de tu aplicación.
• Se necesita una configuración adecuada para garantizar un rendimiento correcto.
• Significativamente más complejo que las configuraciones de un solo servidor o de servidores separados.
• Debes tener en cuenta factores como la terminación SSL y las aplicaciones que necesitan sesiones persistentes.
• El principal punto de preocupación al usar balanceadores de carga es que representan un único punto de fallo. Esto significa que si el balanceador de carga falla, todo tu servicio se caerá.

4. Acelerador HTTP o proxy inverso de caché

Esta es una configuración que puedes usar para aumentar la velocidad con la que entregas contenido a un usuario de tu aplicación. Emplea varias técnicas para reducir este tiempo. La más importante es mediante el almacenamiento en caché de la respuesta del servidor de aplicaciones. El acelerador guarda el contenido en su memoria cuando un usuario lo solicita por primera vez. Por lo tanto, cuando llegan solicitudes futuras similares, sirve el contenido rápidamente sin interactuar con el servidor de aplicaciones. Tanto Nginx, Varnish como Squid son capaces de realizar aceleración HTTP.

Cuándo usarlo:

Como es de esperar, esta configuración es más adecuada para archivos y contenidos que los usuarios solicitan con mucha frecuencia. También funciona muy bien para aplicaciones web dinámicas con mucho contenido.

Beneficios:

• El almacenamiento en caché y la compresión aumentan significativamente la velocidad de la aplicación y el procesamiento de solicitudes.
• Disminuir la carga en la CPU también mejora el rendimiento del sitio.
• También puedes usar esto como un balanceador de carga de proxy inverso.

Desventajas:

• Tienes que ajustarlo bien para extraer su mejor rendimiento.
• Es posible que experimentes un rendimiento deficiente en caso de que la tasa de aciertos de caché sea baja.

5. Replicación de base de datos Primario-Réplica

Una configuración de replicación de base de datos primario-réplica suele ser muy útil para sistemas que realizan más lecturas que escrituras. Por ejemplo, los sistemas de gestión de contenidos realmente pueden aprovechar dicha arquitectura. Necesitas un nodo primario y uno o más nodos de réplica para la replicación. Distribuye las lecturas entre todos los nodos. Las actualizaciones van solo al nodo primario.

Cuándo usarlo:

Como mencionamos, una configuración de base de datos basada en replicación ayuda a mejorar el rendimiento de lectura de un sistema. Puedes usarla para aplicaciones como CMS.

Beneficios:

• Mejora el rendimiento de lectura de la base de datos ya que la distribuye entre las réplicas.
• Si usas el nodo primario solo para actualizaciones, también puedes mejorar el rendimiento de escritura.

Desventajas:

• Cualquier aplicación que intente acceder a la base de datos debe ser capaz de decidir a qué nodo enviar las actualizaciones y las solicitudes de lectura.
• En caso de que la réplica primaria falle, las actualizaciones se detienen. Debes resolver el problema para permitir que las actualizaciones continúen.
• No existe un mecanismo de conmutación por error para hacer frente a un posible fallo del nodo primario.

Uso combinado de las configuraciones de servidor

Afortunadamente, también es posible combinar varias técnicas para obtener el resultado deseado. Esto significa que puede equilibrar la carga de los servidores de aplicaciones con los servidores de caché en un solo entorno y replicar la base de datos. Hacerlo le permite aprovechar la funcionalidad de ambos servidores. Sin embargo, esto no hace que la configuración sea más complicada o problemática.

Ejemplo:

Intentaremos comprender dicho entorno con un ejemplo:

En un entorno de este tipo, el equilibrador de carga enviará las solicitudes estáticas a los servidores de caché. Contenido estático incluye elementos como CSS, imágenes y Javascript, entre otros. En su lugar, dirigirá cualquier otro tipo de solicitud de contenido a los servidores de aplicaciones.

Supongamos que un usuario solicita contenido estático del entorno. Esto es lo que ocurriría:

• El equilibrador de carga determinará primero si el contenido es un cache-hit o un cache-miss. El contenido cache-hit está presente en la caché, mientras que el contenido cache-miss no está allí. Lo hace consultando al backend de caché.
• En caso de que sea un cache-hit, el equilibrador de carga envía el contenido al usuario.
• En caso de que sea un cache-miss, el servidor de caché reenvía la solicitud al backend de la aplicación.
• El backend de la aplicación buscará y enviará el contenido desde la base de datos.
• El backend de caché recibe el contenido del equilibrador de carga. También almacena en caché este contenido antes de devolverlo al equilibrador de carga.
• Este último luego reenvía la respuesta al usuario.

Por otro lado, esto es lo que sucederá si el usuario solicita contenido dinámico:

• La solicitud llegará del usuario al equilibrador de carga.
• Esta solicitud llega al backend de la aplicación.
• El backend de la aplicación localiza el contenido solicitado y lo devuelve al equilibrador de carga.
• El usuario recibe el contenido.

Uno de los principales beneficios de un entorno combinado de este tipo es que es más confiable. No solo eso, sino que también tiene capacidades de rendimiento superiores. Sin embargo, todavía existen dos puntos únicos de fallo: el equilibrador de carga y el servidor de base de datos principal.

Conclusión

Puede utilizar cada configuración de servidor por sí sola en su entorno. Por otro lado, también podría combinar un par de ellas para crear una solución personalizada. No hay una respuesta 'correcta'. Todo depende de la funcionalidad que desee extraer de la arquitectura.

Tener conocimientos básicos sobre cómo funciona cada configuración de servidor le ayudará a tomar la decisión para su propia aplicación. Lo mejor es empezar con algo pequeño y sencillo. Puede seguir aumentando la complejidad de su configuración a medida que adquiera experiencia.

¡Feliz informática!