Estoy pensando en configurar un servicio de pub/sub con websockets. Por lo que puedo decir, los cuellos de botella de escalabilidad se producirán principalmente con la memoria, lo que afecta la cantidad de sockets que se pueden abrir a la vez, por lo que creo que sería prudente dividir esto de los otros servidores que ejecutan servicios como API. ¿Es esto correcto? Me imagino que la memoria es más cara que la potencia informática cuando se trata de alojamiento, entonces, ¿existen mejores prácticas cuando se trata de optimizar este tipo de servidor en términos de escalabilidad y costo?
El objetivo es proporcionar al usuario de esta aplicación web actualizaciones en tiempo real a medida que los sistemas en el campo registran nuevos datos, sin tener que sondear el backend periódicamente. Pero no queremos duplicar los costos de nuestro servidor o puede que no valga la pena. Estamos utilizando AWS EC2 con equilibrio de carga y escalado automático para nuestros servidores API actuales.
Respuesta1
El uso real de memoria de un solo socket no es tanto.
Lo que consume memoria es el estado asociado con qué cliente está interesado en qué actualizaciones y qué cliente ya ha recibido una actualización en particular.
En una implementación primitiva (es decir, utilizando la pila de red del sistema operativo), este último estado se mantiene en forma de buffers salientes, de modo que si se envía una actualización a 10.000 clientes, los datos se copian 10.000 veces y cada una de las copias se adjunta a un cola saliente, donde se aumenta con los encabezados necesarios (que contienen el estado por conexión), y luego se crea un descriptor para el hardware que le indica que envíe un paquete que es una concatenación de los encabezados y la carga útil.
La copia por cliente de la carga útil se mantiene en la memoria hasta que el cliente la reconoce, y de ahí provienen los requisitos de memoria. Esta memoria no se puede paginar, por lo que crea presión de memoria y caché en otras aplicaciones.
Hay implementaciones que implementan partes de la pila de red dentro del propio programa del servidor, y estas pueden evitar las copias contando referencias o recreando cargas útiles bajo demanda, lo que le permite salirse con la suya con mucho menos uso de memoria, pero implica una gran cantidad de La codificación complicada para que sea verdaderamente escalable, especialmente los servidores de múltiples sockets, plantea algunos problemas interesantes que la pila de red del sistema operativo ya sabe cómo solucionar.
Las opciones que tienes
- ejecute el servicio pub/sub en el mismo servidor que la aplicación
- ejecute el servicio pub/sub en un servidor dedicado con red de sistema operativo
- ejecute el servicio pub/sub en un servidor dedicado con redes personalizadas
- ejecutar el servicio pub/sub en múltiples servidores dedicados
son su estrategia de escalada a medida que crece el servicio. Pasar de compartido a dedicado no requiere mucha planificación y se puede hacer según sea necesario; Una vez que esto haya sucedido, es hora de preparar las siguientes etapas.
La ampliación a varios servidores introducirá no determinismo en su sistema, ya que los clientes pueden recibir actualizaciones en diferente orden, por lo que para que este paso de ampliación sea exitoso, sus clientes deben ser conscientes de esto y poder presentar una vista consistente. Si eso es trivial o difícil depende de su aplicación real.
tl;dr:no es necesario optimizar prematuramente. Divida el servicio de modo que el primer paso de escalamiento sea un simple cambio de configuración y comience a optimizar tan pronto como eso suceda.