¿Puede PHP escalar verticalmente? ¿Hasta dónde debo exprimir un servidor antes de pensar en un equilibrador de carga?

tl; dr : absolutamente debe implementar un equilibrador de carga No hay razón para no tener un equilibrador de carga sentado frente a sus servidores web; no sé cómo alguien podría aconsejar que no lo haga.

Siempre lucho con la visión monolítica de la arquitectura de aplicaciones web. Sí, podría escalar hasta cierto punto, pero eso solo responde a una pregunta arquitectónica hipotética estrecha. ¿Qué va a pasar después de la implementación?

Con cualquier servidor, físico o virtual, tiene muchas piezas en movimiento. El sistema operativo y el componente del servidor web pueden fallar por varias razones. ¿Qué sucede si hay un error en alguna de estas partes: HDD R / W, almacenamiento en caché, memoria, puntero, código php, procesador php o el software de la base de datos?

La cantidad de usuarios que puede manejar es un límite de más que solo el procesador: ¿qué pasa con sus tarjetas de red, RAM, disco, etc.

¿Qué sucede si necesita reiniciar o si necesita implementar una actualización? ¿Qué pasa si un hilo se pierde y mastica tu carnero? Claro, podría manejar mil usuarios simultáneos en páginas estáticas. Pero, ¿qué sucede cuando golpeas un cuello de botella como iniciar sesión?

¿Qué pasa si eres pirateado?

Los equilibradores de carga (o controladores de entrega de aplicaciones) de hoy en día son mucho más sofisticados que los proxies inversos round robin de antaño.

Guías

Esta es la guía de Dell para el dimensionamiento del servidor web y esta es una guía de dimensionamiento gratuita para un equilibrador de carga del servidor web.

Un equilibrador de carga con> 1 servidores web es LA ÚNICA manera de crear una alta disponibilidad real. Aquí está la lista de razones por las que diría que debería considerar cuidadosamente un equilibrador de carga antes de implementar:

  • Velocidad
    • Los ADC son aceleradores SSL expertos: mantienen a sus usuarios seguros y reducen la carga en el servidor al descifrar el tráfico y entregar texto claro a los servidores antes de cifrarlo y enviarlo de vuelta
    • Almacenamiento en caché y compresión: los usuarios solo necesitan acceder al servidor si la memoria caché necesita actualizarse o si se entrega algún contenido dinámico
      • Configuramos un servidor y lo golpeamos con “Abejas con ametralladoras”, una forma de prueba de carga
      • Gracias al almacenamiento en caché, la utilización en los servidores web se redujo al 1%
    • HTTP / 2
      • Gracias a HTTP / 2, el tráfico entre el ADC y el cliente puede manejarse como HTTP / 2, lo que le da a su sitio un buen impulso
    • Al compartir la carga de trabajo, los servidores proporcionan una mejor experiencia en el sitio durante los tiempos de carga pico
  • Despliegue
    • Los ADC son mucho mejores en el manejo de DNS
    • Puede conducir implementaciones de desarrollo de productos rojo / azul en una fracción de segundo
    • También puede realizar una prueba beta al permitir un pequeño conjunto de usuarios de muestra a un servidor específico
    • Puede drenar a los usuarios de un servidor para realizar tareas de mantenimiento sin interrumpirlos.
    • GEO: también puede enrutar a los usuarios a diferentes servidores según su ubicación, o a diferentes centros de datos
  • Seguridad y defensa
    • Los equilibradores de carga son un proxy inverso que protege a los servidores del acceso directo
    • DDoS puede ser limitado o mitigado especialmente con un WAF y una lista negra

Y esta es una publicación de blog que escribí desde un punto de vista de SEO de por qué debería implementar un equilibrador de carga frente a su / cualquier / cada sitio web.

Depende de cuáles sean sus necesidades. Entonces, hablemos sobre algunas de las razones por las que puede querer, o no querer, escalar horizontalmente. Escalar horizontalmente puede brindarle una mejor redundancia. Digo mayo porque si no tiene la capacidad suficiente, tener un servidor abandonado puede causar fallas en cascada cuando ese tráfico se asigna a los servidores de aplicaciones restantes. Sin embargo, esta redundancia puede ser fantasma ya que, a menos que otras partes del sistema, por ejemplo, la base de datos, el almacenamiento en caché, el sistema de archivos, la búsqueda sean redundantes, aún tiene puntos únicos de falla. Es probable que varios servidores de aplicaciones aumenten la complejidad del sistema porque es probable que necesites algún tipo de sistema de archivos de red, y eso siempre es un fastidio para comenzar a funcionar de manera eficiente. Ahora, hasta cierto punto, el aumento de la capacidad va a la misma velocidad que los costos de algunos componentes, por ejemplo, con las instancias de AWS EC2, básicamente se mantiene al mismo nivel que las instancias de T2:

  • 2 CPU, memoria de 8GB: $ 0.094 / hora
  • 4 CPU, memoria de 16 GB: $ 0.188 / hora
  • 8 CPU, 32 GB de memoria: $ 0.376 / hora

Pero para llegar más alto que eso, comienza a no ir igual, ya que debe ir para instancias C4:

  • 16 CPU, 62GB de memoria: $ 0.796 / hora
  • 32 CPU, 132 GB de memoria: $ 1.591 / hora

Después de eso, comienza a ser mucho más caro.

Otra ventaja de varios servidores más pequeños es que puede ajustar el número que está utilizando para satisfacer su demanda actual. Para la mayoría de los sitios web hay horas pico y horas no pico. A costa de la complejidad, puede hacer que el sistema active más servidores para las horas pico y luego reducirlos, lo que podría generar un importante ahorro de costos. Es mucho más difícil hacerlo con un solo servidor.

Sí, PHP puede escalar verticalmente hasta un punto. Es decir, PHP es ejecutado por un servidor http que ejecuta solicitudes PHP en procesos o subprocesos separados.

Cada solicitud utiliza algunos recursos de CPU y algunos recursos de RAM, por lo que cuanto más grande sea el sistema, más solicitudes concurrentes puede atender.

Pero cuantos? Eso depende de lo que haga cada solicitud. Cuánto tiempo se ejecuta, cuánto código tiene que ejecutar, cuántos datos tiene que almacenar en la RAM, etc.

En general, ejecutar un servidor escalable requiere mucha supervisión .

Cuando empiezas a quedarte sin recursos o creas puntos de contención, es hora de escalar a varios servidores. Cuando esto sucede depende de su aplicación, su carga de trabajo, su tráfico. Esto no es algo que la gente en Internet pueda responder por usted.

PHP definitivamente puede escalar verticalmente. Hasta qué punto puede escalar depende de su integración.

No debe preocuparse por un “equilibrador de carga” hasta que pueda mostrar que su backend se beneficiaría de uno. Por lo general, no es ideal pensar en un equilibrador de carga si aún no ha evaluado completamente su rendimiento. Debe verificar todo lo que causa una disminución del rendimiento. Diseño de base de datos, estructura de código y método de integración. Es posible que pueda obtener más rendimiento ajustando su código fuente.

Solo debe considerar un equilibrador de carga cuando esté completamente seguro. Y sabe que su backend PHP puede beneficiarse de él.