Tutorial

5 Configuraciones Comunes para tus Aplicaciones Web

Published on December 3, 2014
Español
5 Configuraciones Comunes para tus Aplicaciones Web

Introducción

Cuando decidimos que arquitectura de servidor utilizar para nuestro enterno, hay muchos factores a considerar, como el rendimiento, escalabilidad, disponibilidad, costo y facilidad de administración.

Aquí hay una lista de las configuraciones comunes de servidor, con una corta descripción en cada una, incluyendo pros y contras. Recuerda que todos los conceptos cubiertos aquí pueden ser utilizados en distintas combinaciones con otras, y que cada ambiente tiene diferentes requerimientos, así que no hay una sola, correcta configuración.

1. Todo en un Servidor

Todo el entorno reside en un solo servidor. Para aplicaciones web típicas, que incluyen el servidor web, servidor aplicación y servidor de bases de datos. Una una variación común de esta configuración es un LAMP, que comprende Linux, Apache, MySQL y PHP en un mismo servidor.

Caso de Uso: Bueno para configurar aplicaciones rápido, con las configuraciones más simples posibles, pero ofrece poco camino para escalar.

Todo en un servidor

Pros:

  • Simple

Contras:

  • La aplicación y base de datos compiten por los mismos recursos del servidor (CPU, Memoria, Entradas/Salidas, etc), lo que provoca bajo rendimiento y puede determinar un pobre rendimiento en la fuente (aplicación o base de datos) -No es escalable horizontalmente

Artículos Relacionados:

2. Servidor de Base de Datos Independiente

El manejador de base de datos (DBMS) puede ser separado del resto del entorno para eliminar la compentencia por recursos entre la aplicación y la base de datos, e incrementar la seguridad eliminando la base de datos del DMZ, o Internet público.

Caso de Uso: Bueno para configurar tu aplicación rápidamente, pero previene a la aplicación y base datos de pelear por recursos en el mismo sistema.

Base de datos independiente

Pros:

  • La aplicación y base de datos no compiten por los mismos recursos del servidor (CPU, Memory, I/O, etc.)
  • Tienes posibilidad de escalar verticalmente cada espacio independiente, agregando más recursos o lo que sea que el servidor necesite para incrementar su capacidad
  • Dependiendo de la configuración, se puede incrementar la seguridad eliminando la base de datos del DMZ

Contras:

  • Configuración más compleja que la de un solo servidor
  • Los problemas de rendimiento pueden aumentar si la conexión entre los dos servidores tiene latencia alta (por ejemplo, si los servidores están geográficamente distantes entre sí), o si el ancho de banda es demaciado bajo para la cantidad de datos transferidos

Guías Relacionadas:

3. Estabilizador de Cargas (Proxy Inverso)

Los estabilizadores de carga pueden ser agregados al entorno del servidor para mejorar el rendimiento y la Load balancers can be added to a server environment to improve performance and fiabilidad distribuyendo el flujo de carga entre varios servidores. Si uno de esos servidores falla al cargar su balance, el resto de los servidores atenderán el tráfico entrante hasta que el servidor que presenta falla se recupere. Esto también puede aplicarse para servir varias aplicaciones a través de un mismo dominio y puerto, utilizando la capa 7 (capa de aplicación) proxy inverso.

Ejemplos de software para trabajar con proxy inverso y balance de cargas: HAProxy, Nginx, and Varnish.

Caso de Uso: Útil en un entorno que requiere escalar agregando más servidores, también conocido como escalabilidad horizontal.

Estabilizador de cargas

Pros:

  • Habilita escalabilidad horizontal, por ejemplo la capacidad del entorno puede ser aumentada agregando más servidores
  • Puede proteger ataques DDOS limitando las conexiones del cliente mediante un peso y frecuencia

Contras:

  • El estabilizador de cargas puede tener un rendimiento de cuello de botella si no cuenta con los recursos necesarios, o si está configurado pobremente
  • Puede introducir complejidades que requieren consideraciones adicionaes, como cuando se ejecuta una terminación SSL y como responder cuando una aplicación requiere sesiones fijas

Guís Relacionadas:

4. Acelerador HTTP (Caché en Proxy Inverso)

Un acelerador HTTP, o or Caché en Proxy Inverso, puede utilizarse para reducir el tiempo que toma en servir contenido a un usuario através de diversas técnicas. La técnica principal empleada en un acelerador HTTP es almacenando el caché de las respuestas en memoria, así que las peticiones futuras para el mismo contenido serán servidas rápidamente a menos que sea necesaria una interacción con la web o servidores de aplicaciónes.

Ejemplos de software útil para un acelerador HTTP: Varnish, Squid, Nginx.

Caso de Uso: Útil en un entorno donde el contenido pesado es dinámico en aplicaciones web, o cuando muchos archivos comúnes son visitados constantemente.

Acelerador HTTP

Pros:

  • Incrementa el rendimiento del sitio reduciendo la carga de CPU en el servidor web, a través del caché y la compresión
  • Puede ser atendido como un proxy inverso con balance de carga
  • Algunos softwares de caché pueden protegerte ante ataques DDOS

Contras:

  • Requiere afinación para tener un mejor rendimiento
  • Si el rango o capacidad de caché es bajo, puede reducir el rendimiento

Guías Relacionadas:

5. Réplica de Base de Datos Maestro-Esclavo

Un camino para mejorar el rendimiento del sistema de base de datos es realizando muchas lecturas comparadas con las escritas, como en los CMS, es utilizar una réplica de la base de datos maestro-esclavo. La réplica Maestro-Esclavo requiere un principal (maestro) y uno o más nodos esclavos. En esta configuración, todas las actualizaciones del nodo maestro serán distribuidas a través de todos los nodos.

Caso de Uso: Bueno para incrementar el rendimiento en la lectura de la base de datos al nivel de una aplicación.

Aquí un ejemplo de la configuración Réplica Maestro-Esclavo con un solo nodo esclavo:

Replica de base de datos maestro-esclavo

Pros:

  • Mejora la lecuta de la base de datos distribuyéndola entre los esclavos
  • Puede mejorar la escritura utilizando el nodo maestro únicamente para actualizaciones (dependiendo si no hay solicitudes de lectura en procesamiento)

Contras:

  • La aplicación que accesa a la base de datos debe tener un mecanismo para determinar cual de los nodos de base de datos debe ser utilizada para enviar peticiones de actualización y lectura
  • Las actualizaciones a los esclabos son asíncronas, así que hay posibilidades de que el contenido pueda ser diferido
  • Si el maestro falla, no se podrán realizar actalizaciones en la base de datos hasta que el problema sea sulucionado
  • No hay un corrector de errores integrado en caso de alguna falla en el nodo maestro

Guías Relacionadas:

Ejemplo: Combinando los Conceptos

Es posible estabilizar cargas con servidores de caché, además del servidor aplicación y utilizar una réplica de base de datos en un mismo entorno. El propósito es aprovechar los beneficios de cada uno sin introducir muchos problemas y complejidad. Aquí hay un diagrama ejemplo de como debe lucir el entorno del servidor:

Estabilizador de cargas, acelerador http, y replica de base de datos combinados

Asumámos que el estabilizador de cargas está configurado y reconoce peticiones estáticas (como imágenes, css, javascript, etc.) y enviamos todas estas peticiones directamente al servidor de caché, y el resto de las peticiones al servidor de aplicacion.

Aquí hay una descripción de lo que pasaría cuando un usuario realiza una petición al contenido dinámico:

  1. El usuario solicita contenido dinámico de _http://ejemplo.com/_ (estabilizador de cargas)
  2. El estabilizador de cargas envía la peticion al backend de la aplicación
  3. El backend de la aplicación lee de la base de datos y regresa la peticion al estabilizador de cargas
  4. El estabilizador de cargas regresa los datos solicitados al usuario

Si el usuario solicita contenido estático:

  1. El estabilizador de carga revisa el backend de caché para ver si la petición está en caché o no
  2. Si está en caché: regresa el contenido al estabilizador de carga y salta al paso 7, de otro modo. si no hay contenido en caché: el servidor de caché re-envía la petición al backend de la aplicación, a través del estabilizador de carga
  3. El estabilizador de carga re-envía la petición a través del backend de la aplicación
  4. El backend de la aplicación lee de la base de datos y regresa el contenido al estabilizador de carga
  5. El estabilizador de carga re-envía la petición al backend de caché
  6. El backend de caché almacena el contenido y lo regresa el estabilizador de carga
  7. El estabilizador de cargas regresa los datos solicitados al usuario

Este ambiente aún tiene dos puntos por analizar (el estabilizador de carga y el servidor maestro de base de datos), pero provee todos los beneficios de fiabilidad y rendimiento que fueron descritos en la sección de arriba.

Conclusión

Ahora que estas familiarizado con algunas configuraciones básicas de servidor, puedes tener una buena idea de que tipo de servidor requieres para tu aplicación. Si estás trabajando en tu propio entorno, recuerda que el proceso iterativo es el mejor camino para evitar introducirse en complejidades rápidamente.

Comentanos acerca de tus recomendaciones o lo que te gustaría aprender en los comentarios de abajo!

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products

About the authors

Default avatar
TonnyORG

translator


Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
2 Comments


This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Gracias por la traducción al español, sin embargo es notable la falta de ortografía y el descuido en partes que incluso aparecen en inglés o errores cono palabras repetidas. No están bien vistos errores como esos

Hola!, muchas gracias por el artículo, respecto a lo que proponen en el caso 3. Estabilizador de Cargas (Proxy Inverso)

Ustedes dicen que se puede producir un cuello de botella en el balanceador de cargas, según esto, que especificaciones mínimas recomiendan en el caso de tener un trafico medio de acceso a la aplicación.

O de ser mejor que recomendación darían sobre como distribuir los recursos (ram) de cada uno de los droplets balanceador de cargas - droplets con la aplicación droplets de cache - droplets base de datos, no se si se entiende. Por ejemplo:

Balanceador de carga 2 gb ram

Cache 1 gb ram

Base de datos 2 gb

Saludos!!

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Featured on Community

Get our biweekly newsletter

Sign up for Infrastructure as a Newsletter.

Hollie's Hub for Good

Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.

Become a contributor

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

Welcome to the developer cloud

DigitalOcean makes it simple to launch in the cloud and scale up as you grow — whether you're running one virtual machine or ten thousand.

Learn more