Erlang (V) HTTP reverse proxy

[Repaso]
Repasemos la infraestrctura: Ahora mismo tenemos un servidor web hecho en Erlang, MochiWeb, que accepta mucha mucha carga.

Este servidor en si mismo no hace el trabajo, sino que deja que un Actor de Erlang (llamado Usuario) se encargue de gestionar la petición. Así conseguimos una concurrencia brutal y soportamos un montonazo de carga[1]. El actor usuario, en caso de recibir un mensaje de otro usuario, devolverá este mensaje al servidor web, que a su vez se lo mandará al usuario final y este lo recibirá en su navegador. Bien. También tenemos en un almacén de datos en memória la gestión de las sesiones (en mnesia): allí se asocia un ID de sessión HTTP con el ID de usuario.

Ahora mismo la arquitectura de la aplicación está pensada para ser ejecutada en una misma máquina, lo que supone algunos problemas: cuando toca reiniciar el equipo debido a actualizaciones de kernel y demás el chat debe permanecer "cerrado". No solo esto, si no que el usuario no recibiría un bonito mensaje de error que diga "We are under maintenance", sinó mas bien un "server not found" o algo así. Algo feo feo. Pero arreglarlo tampoco es algo fácil.

También hay otros pequeños problemas como por ejemplo el logueo de las peticiones HTTP (típico fichero access.log) y ofrecer HTTPS (SSL/TLS).

Veamos una imágen actual de la arquitectura de Gaab Web Chat:

Bien. Tenemos un único punto de entrada directamente al servidor de chat de Erlang. En si mismo esto no está mal, ya que el servidor accepta una concurrencia "que te cagas", pero tenemos los problemas comentados anteriormente. Parece que la solución más simple es (como casi siempre) añadir una capa mas de complejidad y añadir un: http reverse proxy.


[Cherokee]
No explicaré lo que es un reverse proxy (consúltese en la wikipedia, o léase este[2] artículo), pero sí explicaré por qué he elegido Cherokee. Aparte de por que en todos los bencharks tiene unos muy buenos resultados, tiene unos ficheros de configuración con una gestión muy clara, es relativamente nuevo pero tiene un gran comunidad y está publicado bajo GPL es porque el creador del servidor web es español. Si señor. Me ha salido la vena patriótica y me apetece apoyar (ummm... vale, con "apoyar" quizás me he pasado, digamos "usar") un proyecto hecho en casa. Y punto.

Y las primeras impresiones no pueden ser mejores: gestión vía web, creado un virtual host en menos de 1 minuto, creado el http proxy en 5 minutos. Amén. Así da gusto.

La idea es usar Cherokee como balanceador de carga entre diferentes aplicaciones GaabWebChat(Erlang+Mnesia+Aplicacion) que se estarían ejecutando en máquinas distintas. La carga de tráfico sería balanceada entre todas las máquina que pudiese tener la aplicación. En caso de que se tuviese que actualizar la plataforma, sería tan simple como decirle a Cherokee que no mandara más tráfico en aquella máquina, actualizarla tranquilamente, y después volver a dirigir tráfico a la misma.

La arquitectura quedaría algo así:

Mucho mas chula que antes, no? Así Cherokee se puede encargar de gestionar las conexiones HTTP/HTTPS, loguear todos los requests en un fichero "access.log", balancear la carga entre varias aplicaciones y servir contenido estático.


[Mejoras]
Esta plataforma todavía se puede mejorar ya que todavía hay un único punto de fallo, el servidor de Cherokee. Esto se podría remediar poniendo varios Cherokees en diferentes máquinas y balanceando la carga por DNS, por ejemplo. Pero esto ya queda (de momento) fuera del alacance de este post.

Esta solución aquí propuesta es un algo que puede que en un futuro pueda necesitar, pero des de luego no lo incluiré en la primera versión que ponga online, ya que MochiWeb puede soportar muucha carga (estoy seguro que ahora mismo por cada 500MiB de RAM que pueda conseguir en un hosting puede soportar a 5K usuarios).

Pues nada, señores. Un saludo.

P.D: Mierda de Blogger. Las imágenes quedan como el culo, pero tienen que tener este tamaño para que se vean claras. So sorry. Prometo cambiar pronto el blog de sitio :/

[1] Me faltan hacer un par de benchmarks para demostrar que esto es así, pero la pereza puede a uno.
[2] http://www.cherokee-project.com/doc/modules_handlers_proxy.html