La teoría

El paradigma Maestro-Esclavo se basa en que, para acceder a un recurso que está disponible solo desde un punto o solo para un servicio, ya sea por que su acceso es crítico en concurrencia o porque solo se pueda acceder desde un único punto cada vez, se hace necesaria una estructura en la que un único punto sea el responsable de ese acceso, quedando todos los demás supeditados a este.

Esto genera igualmente un problema de cuello de botella, pero la misión no es distribuir, en este caso, para ganar más potencia de procesamiento, sino conseguir: una mayor alta disponibilidad para un recurso accesible solo desde un punto cada vez.

En la terminología de Erlang, la nomenclatura empleada es líder (leader) para referirse al maestro elegido cada vez, y trabajador (worker) para referirse a los esclavos. Esto es así por dos sutiles diferencias que existen entre el modelo clásico de maestro-esclavo frente a este de lider-trabajador:

• El maestro es siempre uno y se carga con las tareas de replicación y de escritura, el líder, sin embargo, se carga con todas las tareas y no replica nada entre sus trabajadores.
• El esclavo se encarga de las tareas más frecuentes, en su caso, las lecturas, sin pedir nada al maestro. Si le llega una escritura puede remitirla a su maestro o ignorarla, depende de la implementación. El trabajador, sin embargo, delega todos los trabajos al líder.
• Cuando un maestro muere, los esclavos quedan atendiendo lecturas, pero el sistema de escritura queda sin servicio, a menos que haya algún mecanismo que permita, por alta disponibilidad, levantar a otro maestro, pero no es la base del paradigma. Cuando un líder muere, en cambio, de entre los trabajadores se elige a un nuevo líder, que se encarga de las peticiones. El esquema está pensado en sí para tener una alta disponibilidad.

Aunque es un comportamiento bastante básico, aún no se ha introducido en la base de Erlang, ya que sus algoritmos de elección han sufrido cambios, incluso hasta hace pocos meses. Supongo que incluso aún habrá algún que otro cambio más, por lo que conviene mantenerse al día. El repositorio oficial (de momento) es este de github, gen_leader_revival de abecciu.

Los autores de la base son Andrew Thompson, Dave Fayram, Hans Svensson y Ulf Wiger.

La implementación

El código podemos descargarlo del repositorio indicado anteriormente, solo necesitaremos el código de gen_leader.erl y el código de skeleton.erl.

La plantilla nos da lo básico para que el gen_leader funcione. Si compilamos ambas y lanzamos desde una consola el skeleton, podemos ver que funciona correctamente. Es más, vamos a modificarlo muy poquito agregando solo impresiones por pantalla para saber en qué momento se ejecuta cada uno:

elected(State, Election, undefined) ->
    Synch = [],
    io:format("no one elected? ~p~n", [Election]),
    {ok, Synch, State};
 
elected(State, Election, Node) ->
    io:format("elected node [~p]: ~p~n", [Node, Election]),
    {reply, [], State}.
 
surrendered(State, Synch, Election) ->
    io:format("surrendered (~p): ~p~n", [Synch, Election]),
    {ok, State}.
 
handle_leader_call(Request, _From, State, Election) ->
    io:format("leader_call (~p): ~p~n", [gen_leader:leader_node(Election), Request]),
    {reply, ok, State}.
 
from_leader(Synch, State, Election) ->
    io:format("from_leader (~p): ~p~n", [gen_leader:leader_node(Election), Synch]),
    {ok, State}.
 
handle_DOWN(Node, State, Election) ->
    io:format("DOWN (~p): ~p~n", [Node, gen_leader:leader_node(Election)]),
    {ok, State}.

El código modificado es llamado como callback cuando se suceden las siguientes situaciones:

• elected (con nodo undefined), es llamada cuando el nodo es elegido para ser líder, si la variable de Nodo no es undefined, entonces es llamado cuando un nuevo trabajador se ha unido al líder.
• surrendered, llamada en trabajadores cuando un líder ha sido elegido, o cuando un nuevo nodo entra en el clúster, y se decide de nuevo quién es el líder, siendo llamado elected en el líder elegido y surrendered en el nuevo trabajador.
• handle_leader_call, esta llamada la realiza quien necesita algo del cluster, o cualquiera de los trabajadores al líder, pero en esencia, solo se proces en el líder.
• from_leader, mensajes que se emiten desde el líder hacia los trabajadores. Si la devolución de handle_leader_call es {reply, Reply, Broadcast, State}, se envía el mensaje de Broadcast a todos los trabajadores, con lo que pueden hacer alguna sincronización con su estado interno o realizar la acción que se requiera.
• handle_DOWN, mensaje de caída recibida por el líder de los nodos que han caído. Cuando cae el líder, un nuevo líder es elegido y se le envía la señal de caída del nodo del antiguo líder.

Teniendo estas características en cuenta, podemos ejecutar el código y ver cómo se comporta:

En lider1@bosqueviejo:

(lider1@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']).
no one elected? {election,<0.55.0>,none,datos,lider1@bosqueviejo,
                          [lider1@bosqueviejo,lider2@bosqueviejo],
                          [],
                          [lider2@bosqueviejo],
                          [],[],none,norm,
                          {1,6,0},
                          [],[],5000,
                          {interval,#Ref<0.0.0.49>},
                          lider2@bosqueviejo,6,1,sender}
{ok,<0.55.0>}

Ahora levantamos en lider2@bosqueviejo:

(lider2@bosqueviejo)1> {ok, Pid} = datos:start_link(['lider1@bosqueviejo', 'lider2@bosqueviejo']).
{ok,<0.55.0>}
surrendered ([]): {election,<6327.55.0>,none,datos,lider1@bosqueviejo,
                            [lider1@bosqueviejo,lider2@bosqueviejo],
                            [],[],
                            [{lider1@bosqueviejo,lider1@bosqueviejo},
                             {#Ref<0.0.0.59>,lider1@bosqueviejo},
                             {#Ref<0.0.0.57>,lider1@bosqueviejo}],
                            [],none,norm,
                            {1,6,0},
                            [],[],5000,undefined,undefined,5,1,sender}

En lider1@bosqueviejo se sucede el siguiente mensaje al levantar al lider2@bosqueviejo:

elected node [lider2@bosqueviejo]: {election,<0.55.0>,none,datos,
                                       lider1@bosqueviejo,
                                       [lider1@bosqueviejo,lider2@bosqueviejo],
                                       [],[],
                                       [{#Ref<0.0.0.74>,lider2@bosqueviejo}],
                                       [],none,norm,
                                       {1,6,0},
                                       [],[],5000,
                                       {interval,#Ref<0.0.0.49>},
                                       lider2@bosqueviejo,6,1,sender}

Ahora en lider1@bosqueviejo enviamos un mensaje:

(lider1@bosqueviejo)2> gen_leader:leader_call(Pid, "hola").
leader_call (lider1@bosqueviejo): "hola"
ok

Y lo que pasaba al mismo tiempo en lider2@bosqueviejo:

from_leader (lider1@bosqueviejo): [118,117,101,115,116,114,111,32,108,105,100,
                                   101,114,32,100,105,99,101,58,32,"hola",
                                   "\n"]

En caso de que salgamos de la consola del lider1@bosqueviejo vemos lo siguiente en lider2@bosqueviejo:

no one elected? {election,<0.55.0>,<6327.55.0>,datos,lider2@bosqueviejo,
                          [lider1@bosqueviejo,lider2@bosqueviejo],
                          [],
                          [lider1@bosqueviejo],
                          [{#Ref<0.0.0.59>,lider1@bosqueviejo},
                           {#Ref<0.0.0.57>,lider1@bosqueviejo}],
                          [],none,norm,
                          {2,5,1},
                          [],[],5000,
                          {interval,#Ref<0.0.0.75>},
                          lider2@bosqueviejo,5,2,sender}
DOWN (lider1@bosqueviejo): lider2@bosqueviejo

Es decir, se elige a un nuevo líder y se envía el mensaje de caída del líder.

Conclusiones

Este esquema es bastante útil ya que simplifica el problema de tener varios servidores, por ejemplo, y recursos que solo pueden estar disponibles en un solo servidor cada vez. Por ejemplo, el acceso a un recurso propietario que solo nos da una licencia de uso, el acceso con control de concurrencia a un recurso.

Su interfaz de broadcast, permite que el sistema pueda recibir peticiones de lectura y escritura, haciendo que su broadcast deje la información en cada worker para, en caso de que cayese el líder, puedan seguir funcionando sin problema alguno.

Realmente, otro elemento más para facilitar la creación de sistemas servidores de alta disponibilidad en Erlang.

En principio, como revisé solo los conceptos en los que se basa y no el funcionamiento a nivel de usuario, de programador, no sabía si era una interfaz amigable para realizar consultas o búsquedas, y la forma de realizar las cargas, inserciones y demás. Tengo que decir que, al menos el acceso y la comunicación con el servidor resulta muy cómoda y sencilla, ya que se basa en REST.

A través de peticiones HTTP muy sencillas y que se pueden generar incluso desde la línea de comandos con herramientas como curl, podemos realizar peticiones a la base de datos.

Mensajes hacia Riak

En principio, Riak se basa en REST, esto quiere decir que cada URI especifica un recurso dentro de la base de datos, y sobre ese recurso podemos realizar las acciones HTTP que se relacionan a cualquiera de las acciones básicas de una petición:

• GET equivale a tomar datos, sería la R del CRUD (retrieve) o el SELECT del SQL.
• PUT equivale a insertar datos nuevos, sería la C del CRUD (create) o el INSERT del SQL.
• POST equivale a una modificación o actualización de datos, sería la U del CRUD (update) o el UPDATE de SQL.
• DELETE equivale a una eliminación del dato, sería la D (delete) o el DELETE de SQL.

Esto permite muchas ventajas, como el uso, en el GET, de la cabecera If-Modified-Since, que nos dará la posibilidad de comprobar si un elemento pesado (imagen, vídeo o similar) es nuevo o no, para volver a descargarlo. Riak nos retornará el objeto con el mensaje 200 para indicar que hay uno nuevo, o solo la cabecera 304 (Not Modified) para indicarnos de que es el mismo que ya tenemos, por lo que no hace falta volver a transmitirlo.

Ante una petición de POST, o una de PUT en el que no exista el registro, se retornará el mensaje 201 (Created), y ante una operación de DELETE, si ha salido bien recibiremos un 204 (No Content) o 404 (Not Found).

Composición de la URI

La URI para localizar recursos dentro de Riak se puede establecer como sigue:

/riak/BUCKET/RESOURCE

NOTA: la palabra clave riak ha sido modificada en nuevas versiones por buckets, pero se mantiene riak por compatibilidad hacia atrás. Por lo que, si estás instalando una versión nueva tomada de la parte de descargas de Riak, puedes usar en lugar de riak la palabra buckets.

Riak configura su URI de modo que la primera palabra clave es precisamente riak, seguida por el bucket donde se almacenarán los recursos que se indique a continuación en la URI. El bucket es un bolsillo en el que se puede almacenar lo que se desee. Además, el bucket se puede configurar a través del paso de algunos parámetros de configuración específicos. Esto se sale un poco del objetivo del artículo, por lo que si tienes curiosidad de lo que se puede configurar puedes echarle un vistazo a este enlace.

Volviendo al tema, tenemos recursos. Estos recursos son un espacio en el que podemos guardar la información que necesitemos. Puede ser un texto normal, codificado como YAML, como JSON, como XML, o incluso una imagen o un vídeo… o incluso una imagen ISO (comprobado con una ISO de Sabayon de 700 MB aproximadamente).

Por lo que, podemos probar a hacer algunas prácticas. Lanzamos Riak. Si lo tenemos en ejecución en el puerto 8098 (es el de por defecto cuando se instala el paquete deb), podemos hacer lo siguiente:

curl -v -X PUT -H "Content-type: image/jpeg" --data-binary @imagen.jpg http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Nota: asegúrate de que la localización de la imagen es correcta, a una imagen de tu disco válida, y no olvidas poner la arroba (@) justo antes de esa ruta (sin espacios).

La comprobación más simple es a través del cualquier navegador que tengas instalado en esa misma máquina:

http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Con esto ya tendríamos la primera pureba satisfactoria de nuestro sistema de clave-valor para el almacenamiento de datos. Ahora, si lo que queremos es eliminarla, podemos hacerlo así:

curl -v -X DELETE http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Si recargamos el navegador con la URL anterior, veremos que nos responde not found.

Búsquedas en Riak

En caso de que tengamos información formateada en JSON dentro de cada clave y queramos hacer una búsqueda de esta información para extraer únicamente las claves que nos sean útiles, tendremos que emplear el sistema conocido como map-reduce, para realizar una búsqueda a través de todas las claves de un bucket.

Voy a basarme en lo explicado en la documentación oficial de Riak, para no tener que inventar datos. En principio, si descargamos los dos siguientes ficheros y los ejecutamos:

• goog.csv, datos a insertar en Riak (en formato CSV).
• load_data, script en Erlang que insertará los datos, convirtiéndolos en un formato JSON. Hay que editar el scirpt y cambiar la URL para que tenga el puerto correcto, en mi caso puse 8098.

Esto nos da un bucket bastante grande en el que poder practicar.

Como decíamos antes, vamos a dar un repaso al sistema de MapReduce, el cual fue popularizado por Google. Este se basa en el algoritmo de divide y vencerás, realmente, ya que realiza un lanzamiento sobre cada elemento individual (map) tomando un resultado y, después, la parte de reduce, se encarga de analizar y unificarlo todo en un solo resultado.

Por lo tanto, tenemos que enviar mediante POST, a una URI concreta, un formato JSON de dato que será el siguiente:

{"inputs": "goog", "query": [
    {"map": {
        "language":"javascript",
        "source": "function(value, keyData, arg) { var data = Riak.mapValuesJson(value)[0]; if(data.High && parseFloat(data.High) > 600.00) return [value.key]; else return []; }",
        "keep": true
    }}
]}

Si guardamos esto en un fichero, podemos lanzarlo con el siguiente comando:

curl -X POST http://127.0.0.1:8098/mapred -H "Content-type: application/json" -d @mapred.json

En este caso, la función de map es la siguiente:

function(value, keyData, arg) {
  var data = Riak.mapValuesJson(value)[0];
  if(data.High && data.High > 600.00)
    return [value.key];
  else
    return [];
}

Esto quiere decir que se toma el contenido de cada clave, se parsea con una función especial de Riak para convertir de JSON y retornar la primera línea para que sea almacenada en data. Se comprueba que tenga campo High y que High sea mayor de 600.

Es un filtro como se puede hacer con cualquier función map en cualquier lenguaje (que disponga de ella, claro).

Ahora, para emplear tanto map, como reduce, imagina que lo que queremos, de esta información, es econtrar la máxima varianza diaria del precio por mes. Para eso, en el map sacaríamos la varianza diaria, y en el reduce tomaríamos solo la máxima varianza por mes, las funciones serían así:

/* Map calcula la varianza diaria y asigna la clave por mes */
function(value, keyData, arg){
  var data = Riak.mapValuesJson(value)[0];
  var month = value.key.split('-').slice(0,2).join('-');
  var obj = {};
  obj[month] = data.High - data.Low;
  return [ obj ];
}
 
/* Reduce encuentra la varianza máxima por mes */
function(values, arg){
  return [ values.reduce(function(acc, item){
             for(var month in item){
                 if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; }
                 else { acc[month] = item[month]; }
             }
             return acc;
            })
         ];
}

Codificado para enviarlo en el fichero mapred.json, lo anterior quedaría así:

{"inputs":"goog",
 "query":[{"map":{"language":"javascript",
                  "source":"function(value, keyData, arg){ var data = Riak.mapValuesJson(value)[0]; var month = value.key.split('-').slice(0,2).join('-'); var obj = {}; obj[month] = data.High - data.Low; return [ obj ];}"}},
         {"reduce":{"language":"javascript",
                    "source":"function(values, arg){ return [ values.reduce(function(acc, item){ for(var month in item){ if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; } else { acc[month] = item[month]; } } return acc;  }) ];}",
                    "keep":true}}
         ]
}

NOTA: el parámetro keep es el que nos dice qué es lo que se retorna. Si agregamos este mismo parámetro en las dos secciones (map y reduce), nos encontramos que el retorno de la búsqueda es tanto de uno como de otro.

Otras cosas

Otra de las cosas que han agregado es la posibilidad de enlazar recursos, de modo que, asignando un enlace y una etiqueta (con el nombre del tipo de enlace), podamos tener relacionado un recurso con otro. Esto da un abanico de posibilidades tan grande como el que se consigue con las bases de datos relacionales, ya que es posible tener en un bucket contactos, en otro datos específicos de un servicio y relacionar el contacto con esos datos agregando una etiqueta al mismo, e incluso que el enlace sea bidireccional agregando las etiquetas en los dos sentidos, cambiando la etiqueta para que sea semántica.

Una imagen de lo que se puede conseguir:

Las partes de administración (para ajustar las variables del teorema CAP) y configuración de otros nodos es algo que dejamos a revisar de la documentación oficial.

Conclusiones

Como puede verse, Riak solventa con su paradigma de NoSQL, basado en el almacenamiento por clave-valor y búsquedas por MapReduce, la mayoría de necesidades que se pueden encontrar a la hora de emplear este tipo de sistemas. Lo único que queda un poco en el aire, o hay que realizar con llamadas sucesivas, son las actualizaciones y eliminaciones masivas, pero realmente, puede ser un mal menor, si estas no son empleadas en el esquema que se vaya a implementar Riak.

Hay que tener presente que Riak es una muy buena base de datos, que fundamenta sus potencias en la posibilidad de contar con un cluster, lecturas rápidas con caché, y búsquedas artificiosas con MapReduce, pero puede haber otros usos en los que las consultas de modificación y eliminación masivas sean lo más importante y esto ya sería mejor abarcarlo con otra base de datos de otro tipo.

Si pensamos lo que Alan Kay decía sobre la orientación a objetos, no se refería a tener un espacio en la memoria en la que albergar datos que pudiesen ser modificados a través de llamadas a funciones. Él definía de manera conceptual la instancia de un objeto, vivo, al que se le pasan mensajes para trabajar con esa información y retornar una respuesta. ¿No es más parecido a lo que se puede hacer con un gen_server, por ejemplo?

También hay gente que intenta hacer que los procesos de Erlang sean más eficientes que los de otros lenguajes y, sino lo son, Erlang no sirve… cuando, creo que está claro o sino es mejor repasarlo… que Erlang no destaca por la velocidad de sus procesos, sino por la versatilidad de poder crear millones de ellos e incluso a través de un cluster, de modo que se facilita la computación distribuida, no solo la concurrente.

Entonces, ¿cuál es realmente el fallo de que la gente piense en cosas como orientación a objetos o rendimiento de los procesos? … que no han entendido el cambio de paradigma.

Programación Orientada a la Concurrencia

El paradigma que ofrece Erlang, y que está ofreciendo Go, y que se ofrece a través de Celluloid en Ruby, y otros muchos frameworks en otros diversos lenguajes, es lo que se conoce como Modelo Actor, o a mi me gusta llamar Programación orientada a la Concurrencia.

La programación orientada a la concurrencia se basa en los procesos, que son la unidad mínima de computación para concurrencia en este paradigma. Un proceso se define a través de un módulo y puede ser lanzado una o varias veces, dependiendo de la cantidad de procesos que puedan existir en ejecución para un programa específico.

El proceso es en este paradigma lo que el objeto en el paradigma de la orientación a objetos, teniendo un espacio de memoria (heap) en el que almacena datos privados y que él solo puede manipular, y la posibilidad de recibir mensajes para realizar acciones concretas retornando, o no, un valor. En este sentido, agregamos la posibilidad, porque de concurrencia hablamos, de llamadas síncronas o asíncronas.

Como cada proceso, es una entidad de memoria que almacena datos y que responde a la ejecución de código, se puede especificar con un diagrama de clases UML este diseño, teniendo presente la cardinalidad para la existencia de 1 a N posibles instancias de procesos.

Además, a través de los comportamientos, Erlang nos permite crear entidades avanzadas como supervisores, máquinas de estados y generadores de eventos. Estas entidades facilitan enormemente el trabajo de programación de entidades que antes, en el paradigma de objetos, eran impensables.

Diseñar una web en la que se emplea un controlador a través de una máquina de estados para hacer un sistema statefull que mantiene la sesión en memoria sin necesidad de serializar/deserializar información. Además de, en caso de necesitar enviar información a un log o una inserción demorada (sea cual sea la base de datos), es algo que tan solo se puede hacer a través de programación paralela.

Por otro lado, la optimización. El cómputo del coste algorítmico queda totalmente desfasado, realmente. En un servidor de cuádruple núcleo con dos procesadores (16 en total), un algoritmo que se ejecuta de forma distribuida, además, en dos instancias una en cada servidor como el mencionado, tiene la posibilidad de ejecutarse 32 veces más rápido que un programa escrito de forma secuencial o empleando hilos (que normalmente no emplean varias CPUs).

¿Ahora sí?

En esencia. Esto es como cuando salió GTK para PHP, si PHP no está diseñado para estar más de 15 minutos en ejecución (porque se suele bloquear y tiene siempre algún que otro leak de memoria), ¿por qué intentamos introducir orientación a objetos en un lenguaje funcional cuando la metodología más idónea es la orientación a la concurrencia (o el modelo actor)? Acepto comentarios que lo aclaren (si es que esto es posible ).

Para comenzar, vamos a poner de nuevo de manifiesto la plantilla del gen_server, si se quieren tener más referencias sobre el gen_server se puede consultar este otro artículo, o de forma más extensa en este artículo del Blog Aprendiendo Erlang.

Por lo tanto, la estructura de un código con gen_server es la siguiente:

-module(server).
-author('bombadil@bosqueviejo.net').
 
-behaviour(gen_server).
 
-define(SERVER, ?MODULE).
 
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).
 
-record(state, {}).
 
start_link() ->
    gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).
 
init([]) ->
    {ok, #state{}}.
 
handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.
 
handle_cast(_Msg, State) ->
    {noreply, State}.
 
handle_info(_Info, State) ->
    {noreply, State}.
 
terminate(_Reason, _State) ->
    ok.
 
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Agregando conexiones TCP

TCP, a diferencia de UDP, necesita formalizar que está escuchando en un nodo, y aceptar cada petición entrante para mantener una comunicación bilateral. En este caso, el init se complica. Debemos de establecer la escucha del puerto y esto requiere de que pasemos algunos parámetro y opciones:

-record(state, {lsocket, socket}).
 
init([]) ->
    Opts = [binary, {packet, 0}, {active, true}],
    case gen_tcp:listen(5000, Opts) of
        {ok, LSocket} ->
            {ok, #state{lsocket = LSocket}, 0};
        {error, Reason} ->
            {stop, Reason}
    end.

Para esto, tendremos que agregar el parámetro lsocket y socket al registro de estado.

La función init se encarga de establecer la escucha en el puerto 5000, de forma activa. Para más opciones se puede revisar tanto la documentación de gen_tcp, como las opciones específicas disponibles en el paquete inet a través de setops.

Como se puede ver, en caso de que la escucha se establezca de forma apropiada, hay un timeout configurado a cero, por lo que, se llamará al callback de handle_info, con el parámetro timeout. En ese punto, es donde tenemos que agregar la parte del servidor TCP en la que se espera por una conexión entrante para poder atenderla. La función, por tanto, sería:

handle_info(timeout, State=#state{lsocket=LSocket}) ->
    {ok, Socket} = gen_tcp:accept(LSocket),
    {noreply, State#state{socket=Socket}};
 
handle_info(Info, State=#state{socket=Socket}) ->
    io:format("~p~n", [Info]),
    gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])),
    gen_tcp:close(Socket),
    {noreply, State, 0}.

El programa es algo simple, ya que acepta la conexión, espera una transmisión y responde enviando la fecha y hora y cierra la conexión. Podemos probarlo de la siguiente forma:

$ nc localhost 5000
hola
{{2012,4,4},{20,5,49}}

Y ahora… la concurrencia

Como puedes observar, mientras tienes abierta la primera conexión, la segunda no se establece porque el sistema está ocupado con la primera petición. Esto conlleva un cuello de botella, ya que la concurrencia es nula.

Para conseguir ampliar la concurrencia, desde el primer servidor, el proceso que tiene en escucha el puerto, debe de lanzar un proceso, un nuevo servidor para atender cada petición de forma independiente.

Para esto necesitamos crear otro nuevo gen_server, pero con unas características diferentes, ya que no se mantendrá a la espera de conexiones entrantes, sino que será para manejar una conexión activa.

El módulo gen_tcp nos ayuda en esta tarea, ya que cada mensaje entrante lo recibimos a través de handle_info en el proceso padre, como habíamos visto antes, y esto debemos de redireccionarlo hacia el proceso hijo que creemos. En principio, copiando la estructura de gen_server de nuevo y llamándola request, agregamos un par de cambios como el siguiente:

start_link(Socket) ->
    {ok, Pid} = gen_server:start_link(?MODULE, [Socket], []),
    gen_tcp:controlling_process(Socket,Pid),
    inet:setopts(Socket, [{active, once}]),
    {ok, Pid}.

Esta forma de lanzar el gen_server, hace que el proceso no tenga un nombre asociado, por lo que se pueden lanzar tantos como queramos o necesitemos. Para el gen_tcp, indicamos que el proceso que atenderá las peticiones de ese socket será el que se acaba de crear, y se le indica que puede enviar una petición.

La función de inicialización tendrá esta forma:

-record(state, {socket}).
 
init([Socket]) ->
    {ok, #state{socket=Socket}}.

En el módulo server podemos eliminar la parte de gestión de la petición (la parte de handle_info que se refiere estrictamente a la gestión de la petición) y dejar solo la parte de la aceptación de la petición de esta forma:

handle_info(timeout, State=#state{lsocket=LSocket}) ->
    {ok, Socket} = gen_tcp:accept(LSocket),
    request:start_link(Socket),
    {noreply, State, 0}.

En el nuevo módulo request, agregamos la parte de código que se encarga de realizar la contestación:

handle_info(Info, State=#state{socket=Socket}) ->
    io:format("~p~n", [Info]),
    gen_tcp:send(Socket, io_lib:format("~p~n", [{date(),time()}])),
    gen_tcp:close(Socket),
    {stop, normal, State}.

En este caso, cuando gen_tcp envía un mensaje desde el cliente al servidor, este mensaje disparará la ejecución de esta función, imprimirá por pantalla el mensaje recibido, contestará de forma fija con la fecha y hora actual, cerrará la conexión con el cliente y detendrá la ejecución del proceso.

Algunas pruebas

Si ejecutamos en una máquina virtual de Erlang el servidor, y abrimos dos consolas o tres o más con el siguiente comando:

$ nc localhost 5000

Veremos que todas y cada una de las consolas obtienen conexión y quedan en el proceso hijo a la espera de un mensaje que envíes. Puedes poner el texto que quieras y presionar el retorno de carro. Volviendo a la consola de Erlang, se verá el mensaje escrito en cada una de las consolas.

Si modificamos el código para que acepte paquetes de tipo http y procesamos una respuesta válida, podemos probar la carga a través de programas como wrk o ab. En mis pruebas, he conseguido:

$ ab -n 10000 -c 50 http://127.0.0.1:5000/
[...]
Concurrency Level:      50
Time taken for tests:   0.885 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      760000 bytes
HTML transferred:       110000 bytes
Requests per second:    11303.38 [#/sec] (mean)
Time per request:       4.423 [ms] (mean)
Time per request:       0.088 [ms] (mean, across all concurrent requests)
Transfer rate:          838.92 [Kbytes/sec] received

Una tasa de unas 11 mil peticiones por segundo. Nada mal.

En este caso vamos a montar un servidor UDP. Esto lo revisé en su día porque estuve realizando un pequeño servidor para el protocolo syslog, de lo que resultó este servidor, que permite pasar a través de un manejador de eventos (gen_event) los mensajes de syslog recibidos a través del puerto 514 en formato UDP.

En principio, comentaré un poco la estructura del comportamiento (behaviour) de Erlang/OTP que emplearemos: gen_server.

Empleando los gen_server

El gen_server es el comportamiento más básico que se encuentra disponible en OTP, ya que sobre él se construyen otros como gen_fsm. Este comportamiento específico se fundamenta en la recepción de mensajes y su manejo a través de unos callbacks, de modo que tenemos tres tipos de mensajes que podemos procesar:

• call: referidos a llamadas en las que se envía una petición y se espera por una respuesta del servidor. Siendo realizadas desde otros procesos de Erlang.
• cast: estas son llamadas que se envían y no se espera por una respuesta. También son realizadas desde otros procesos de Erlang.
• info: este podría considerarse un comodín, ya que en esta categoría entran todos los mensajes que no entran en las anteriores. Normalmente, aquí es donde recibiremos la información UDP y TCP de los servidores que creemos de cara a la red.

La estructura de un código con gen_server es la siguiente:

-module(server).
-author('bombadil@bosqueviejo.net').
 
-behaviour(gen_server).
 
-define(SERVER, ?MODULE).
 
-export([start_link/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
         terminate/2, code_change/3]).
 
-record(state, {}).
 
start_link() ->
    gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).
 
init([]) ->
    {ok, #state{}}.
 
handle_call(_Request, _From, State) ->
    Reply = ok,
    {reply, Reply, State}.
 
handle_cast(_Msg, State) ->
    {noreply, State}.
 
handle_info(_Info, State) ->
    {noreply, State}.
 
terminate(_Reason, _State) ->
    ok.
 
code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Si guardamos esta estructura como server.erl (que es el nombre del módulo, tal y como se indica en la primera línea), el sistema compilará y lo podremos incluso lanzar con el comando:

server:start_link().

Convirtiendo nuestro gen_server en servidor UDP

Para convertir nuestro gen_server en un servidor UDP solo necesitamos abrir en escucha el puerto que queramos en modo UDP a través de gen_udp y el resto lo hará la estructura gen_server. Sería tan simple como modificar la función init para que albergase el siguiente código:

init([]) ->
    Port = 5000,
    {ok, Socket} = gen_udp:open(Port),
    error_logger:info_msg("Listen in port ~p~n", [Port]),
    {ok, #state{socket=Socket}}.

Y también la estructura del registro de estado, para albergar la información que necesitamos almacenar en el proceso, que será el recurso del puerto abierto:

-record(state, {socket}).

Es bueno que, además, agregemos en el terminate la cláusula que nos permita cerrar el servidor UDP, esto lo podemos agregar modificando la función termiante de la siguiente forma:

terminate(_Reason, State) ->
    gen_udp:close(State#state.socket),
    ok.

Por último, vamos a hacer que cada mensaje que nos llegue desde el servidor UDP se presente a modo de log en la consola. Esto lo haremos modificando la función handle_info, que como habíamos visto antes, es la que recibe los mensajes UDP:

handle_info(Info, State) ->
    error_logger:info_msg("Received via INFO: ~p~n", [Info]),
    {noreply, State}.

Probando el servidor

Para probarlo, solo tenemos que ejecutar en una consola:

$ erl 
Erlang R15B (erts-5.9) [source] [64-bit] [smp:4:4] [async-threads:0] [kernel-poll:false]
 
Eshell V5.9  (abort with ^G)
1> server:start_link().
 
=INFO REPORT==== 21-Mar-2012::10:52:44 ===
Listen in port 5000
{ok,<0.34.0>}

Abrimos otra consola, y ejecutamos el siguiente comando para generar un paquete UDP:

$ nc -u localhost 5000
hola

NOTA: tras escribir hola hay que presionar el retorno de carro (enter o intro) para que el paquete sea enviado.

Esto generará en la consola de Erlang el siguiente mensaje:

=INFO REPORT==== 21-Mar-2012::10:54:01 ===
Received via INFO: {udp,#Port<0.506>,{127,0,0,1},36772,"hola\n"}

Empleando el match en la función handle_info e incluso con expresiones regulares o lo que queramos, podremos tratar de forma más adecuada el mensaje.

Un ejemplo de aplicación de este servidor, como comenté al principio, se puede ver en este proyecto que comencé hace tiempo, un servidor de syslog, que se basa en la recepción de mensajes por el puerto UDP 514, y el envío, a través de gen_event de los mensajes recibidos.

Conclusiones

Con este ejemplo, Erlang demuestra que es muy fácil construir servidores de red, con muy pocas líneas de código. En este ejemplo, el hecho de ser un servidor UDP permite eliminar el payload de la escucha, aceptación y mantenimiento de conexión con el destinatario, simplemente se acepta el mensaje, se lee y procesa, muy simple y con un buen rendimiento del sistema.

Después de la conferencia, como hice con la charla de Metodologías Ágiles en la Práctica, colgaré la presentación para que pueda ser visionada por todo aquél que lo desee.

A todos los que vayáis… nos vemos allí… a los que no, pues nos seguimos viendo por el blog… ¡a ver si dejáis comentarios!

Actualización 09/03/2012: aquí dejo las transparencias de la charla:

Actualizado 11/03/2012: después de 5 horas de procesamiento del vídeo de 8 GB con corrección de color, brillo, agregación de información y conversión a FLV para el visor en web (324MB), ya está disponible el vídeo de la charla. Agradecer sobretodo a Guillermo el podérmelo facilitar (y haberlo grabado).

Si alguien quiere tener acceso al vídeo en mejor calidad, puede solicitármelo y le envío el enlace. No lo dejo en abierto porque hay limitación de ancho de banda y el vídeo con mayor calidad es mucho más pesado.

Los comentarios siguen abiertos para lo que queráis preguntar o comentar.

Con este título nos encontramos un libro bastante curioso sobre esta tecnología, y digo tecnología, porque no solo cubre el lenguaje de programación funcional Erlang, sino también el framework de desarrollo OTP. El libro se estructura de forma que la introducción al lenguaje es efímera pero clara, y nos plantean, casi desde el principio, la creación de un proyecto de caché, al que van agregando los elementos de OTP, hasta culminar en un proyecto completo, funcional, y que contiene, desde la práctica, todos y cada uno de los elementos que podemos encontrar en el framework OTP.

Da un recorrido por las herramientas de Erlang, de monitorización, de depuración y los profilers, así como Mnesia (la base de datos que trae consigo Erlang) y los mecanismos para crear, publicar y actualizar en caliente aplicaciones en Erlang.

Sus autores, entusiastas de Erlang, trabajan en el proyecto Erlware, además de mantener el libro. Estos son Martin Logan, Eric Merritt y Richard Carlsson. El prólogo está escrito por Ulf Wiger, CTO de Erlang Solutions.

Comentar, simplemente, que el libro me ha gustado mucho por su carácter directo. Muestra un proyecto en proceso de creación con código completo y explicando, no solo la historia de cada uno de los elementos y el porqué funcionan y se comportan como se comportan, sino también mostrando la utilidad práctica y para el proyecto de cada elemento, siendo como ejemplo de uso de los elementos de que dispone Erlang/OTP.

Su redacción es amena y para nada pesada y, aún siendo una temática muy densa, se desarrolla con ejemplos, código y gráficos a lo largo de unas 370 páginas, aproximadamente, quedando explicado todo de forma muy concisa y clara. El autor se centra sobretodo en OTP y el desarrollo de soluciones reales más que en la sintaxis y propiedades del lenguaje, con lo que consigue que el texto sea más pragmático y menos académico que el propio libro de Joe Armstrong.

Recomiendo su lectura para todo aquél que desee aprender Erlang/OTP con una curva de aprendizaje más suavizada.

¿Qué es un CMS exactamente?

Un CMS es un sistema de administración de contenido (Content Management System), básicamente. Zotonic se centra en esto mismo, administrar el contenido de la web que está sirviendo. A diferencia de otros CMS realizados en otros lenguajes, Zotonic tiene la ventaja de ejecutarse en una máquina que permite la ejecución de software fuera de la petición.

Por ejemplo, en otros lenguajes como Ruby, Python, Perl o PHP, cuando una petición HTTP llega al sistema establece el contexto de ejecución (sesión, cookies, datos de la solicitud, etc.) y tras su respuesta, el contexto es liberado (o volcado a la memoria secundaria), con lo que, es imposible mantener una ejecución paralela que dispare el sistema.

Es más, hay herramientas como delayed::job (en Ruby) o DJJob (en PHP), precisamente para paliar un poco esto.

Sin embargo, Zotonic, tiene como ventaja el hecho de que puede disparar la ejecución de un proceso no dependiente de la solicitud que almacene su resultado en una cola de mensajes que sea descargada por el sistema AJAX de la vista para mostrarlos en el momento que sea necesario. Esto le da a Zotonic una sensación de rapidez y paralelismo que pocos entornos web tienen hoy en día.

¿Qué ofrece Zotonic?

En principio, Zotonic se puede instalar en una máquina o en varias (en clúster) manteniendo una única interfaz de administración y pudiendo balancear entre todas el acceso, de forma fácil y transparente. Además, cada clúster puede administrar varios dominios:

Su interfaz es muy parecida a WordPress, y permite igualmente escribir páginas y entradas de modo que se puedan emplear como páginas del propio sitio web. Su editor se ve así:

Como base de datos emplea PostgreSQL, y la forma de programar las plantillas es mediante el estándar de Django Template Library (DTL), lo cual facilita la creación de las vistas enormemente. Se puede revisar la documentación que, aunque el tema de las plantillas las trata poco (realmente es porque su simpleza no requiere de mayor información) es una sección de la web bastante extensa conteniendo temas como: SSL, Modelo de Datos, información sobre Erlang, PostgreSQL, conexión Ajax con Zotonic, mensajes Growl, etc.

Una lista bastante extensa y detallada de las características puede verse aquí (en inglés).

Instalando Zotonic

Se puede descargar en cualquier ruta de nuestro equipo, realmente, con el comando:

git clone git://github.com/zotonic/zotonic.git

Esto nos deja un entorno limpio con el que podemos hacer nuestra primera instalación. Por ejemplo, si ponemos en nuestro fichero /etc/hosts al lado de localhost la palabra miblog, podremos escribir lo siguiente:

make
bin/zotonic -s blog miblog
./start.sh

Ahora, solo tendremos que ir a un navegador, si ponemos la URL http://localhost:8000, veremos la interfaz de los dominios que tenemos en ejecución. Solo dispondremos, en estos momentos de miblog, por lo que, como lo hemos puesto en nuestro fichero de hosts, podemos seguir ese enlace y ver la web de nuestro sitio.

Si accedemos por la URL http://miblog:8000/admin/, nos preguntará por el login de acceso y contraseña. Este será, en principio (deberemos de cambiarlo): admin / admin; tras esto, se nos presentan todas las opciones disponibles de Zotonic… ¡y en castellano!

Todo queda bastante claro y muy fácil de manejar, a excepción de las plantillas, las cuales solo se pueden modificar a través de la edición de los ficheros en el directorio donde se haya creado el dominio. En este caso, como hemos creado el dominio miblog, la ruta será: priv/sites/miblog/templates.

Conclusiones

Zotonic se ha convertido en poco tiempo en un CMS con amplias características y muy usado en el mundo del web, aunque no tanto como otros que llevan más tiempo como por ejemplo Zope, Drupal o Joomla, pero poco a poco, gracias a sus características propias de alta disponibilidad, redundancia y escalabilidad, de seguro comenzará a ser cada vez más popular.

En su presentación en la Erlang Factory de Londres de 2011, Demonware preparó una presentación de Erlang and First-Person Shooters.

En resumen, ya que el documento es bastante gráfico e interesante de ver, Demonware es una empresa que se dedica a dar soporte de servidor a videojuegos multi-jugador de Activision y Blizzard. No solo la parte en sí del juego, sino también el chat y audio/vídeo que se puede activar en algunos juegos, así como sistemas anti-trampas, etc.

Los juegos que mantienen en sus servidores van desde Call of Duty (todas las entregas), pasando por Guitar Hero (y derivados), hasta otros como Blur y Marvel Ultimate Alliance 2.

Para hacernos una idea de su crecimiento y tecnologías:

Según la empresa, si el cambio no se hubiese realizado, la crisis podría haber sido un desastre, ya que el paso de mil a 20 mil usuarios se realizó con una sola salida al mercado, la de Call Of Duty 4: Modern Warfare.

Terminan la presentación, comentando algunas cosas que han aprendido con la práctica, que son bastante interesante, a la par que útiles. Nada, lo dicho, recomiendo su visualización.

Actualización 16/09/2011: se me olvidó comentar que SPOF significa, según sus siglas, Single Point Of Failure, algo así como el punto único de fallo. Se refiere a cuando un sistema, aún teniendo bastante redundancia, tiene un punto único, en la red, en el software o en alguna parte del sistema que, fallando, deja sin servicio a todo.

Como la mayoría de software realizado por empresas y que se adentran en el software libre, Riak tiene dos versiones, una Open Source (que es completa y funcional) y otra Enterprise (que agrega commodities -o facilidades- tales como una interfaz de administración).

La base de datos Riak está basada en el documento escrito por Amazon sobre el sistema de almacenamiento Dynamo, el cual se basa en un sistema de alta disponibilidad, con estructura de almacenamiento del par clave-valor y distribuido. Este documento ha sido seguido, además, por Cassandra (la base de datos de Facebook, liberada y acogida en el seno de la Fundación Apache, y que ha sido implementada desde entonces por Digg, Twitter, Reddit, Rackspace, etc.) y por Voldemort (la base de datos de LinkedIn).

Características principales

Riak, además de seguir las bases de Dynamo, ha agregado otras características propias a la lista, quedando (visto en su página web oficial) la siguiente lista de características a destacar:

• Escalabilidad: la escalabilidad con Riak es lineal, predecible y de coste efectivo. Agregar nuevas máquinas no significa tener una avalancha de de peticiones que ponga en peligro la efectividad del sistema. Se pueden ir agregando o eliminando máquinas sin mayor problema, y sin que suponga una carga excesiva para el sistema base.
• Tolerancia a fallos: el cluster soporta o admite fallos en nodos aislados, o incluso en partes del cluster, está preparado para no perder datos ante este tipo de fallos. El sistema ha sido diseñado con fallos de máquinas e interrupciones de servicio de red como norma, no como excepción.
• Alta disponibilidad: para alta disponibilidad el sistema debe de estar disponible, no solo para lecturas, sino también para escrituras. La arquitectura de share-nothing (nada compartido) hace que cada nodo en el cluster esté habilitado para realizar lecturas y escrituras, por lo que, la alta disponibilidad está garantizada.
• Replicación: dependiendo de las necesidades, Riak se puede configurar para replicar entre múltiples clusters iguales o diseñar uno o más clusters como solo-lectura o backup. Cada nodo en el cluster puede responder a las peticiones de lecutra/escritura, y el evento de replicación asegura que todos los clusters sean actualizados. Los algoritmos se ejecutan en cada nodo asegurando la consistencia de datos.

En base al teorema CAP del Dr. Eric Brewer, las tres propiedades deseadas de un sistema distribuido son: consistencia, disponibilidad y partición (tolerancia a fallos). El teorema establece que puedes solo puedes tener dos de las tres propiedades en cada momento. Riak se enfoca en Disponibilidad y Partición. Esta elección pone a Riak en el campo de la consistencia eventual. Sin embargo, la ventana para consistencia eventual es en términos de milisegundos, lo que es suficiente para la mayoría de aplicaciones.

¿Cómo funciona?

No me quiero extender mucho, ya que esta información está disponible (aunque en inglés) en la propia web de Riak, en Concepts, así que resumiré un poco.

El almacén de datos se realiza en base a el par clave-valor, es lo que podríamos llamar una base de datos hash. No obstante, la clave se compone de bucket y key, que son como en Erlang el módulo y la función, o en Java el paquete y la clase. El conjunto bucket/key es la unidad de organización única que puede emplearse.

El sistema admite también el uso de enlaces (links). Esto quiere decir que el contenido de un bucket/key, puede ser un contenido o un enlace a otro bucket/key que tenga su propio contenido. Algo así como el enlace simbólico en los sistemas de ficheros de Unix/Linux/BSD/…

Además, el contenido, puede ir estructurado en forma de metadatos, es decir, como las cabeceras de los mensajes HTTP, para disponer de arrays asociativos (hash) dentro del contenido.

Uso de diferentes backends. En la versión 0.12, Bitcask se estableció como backend para Riak, pero hay más, aquí ponemos un listado de los disponibles:

• Bitcask: simple pero potente almacenaje de pares clave-valor. Es de baja latencia y alto rendimiento.
• DETS / ETS: tablas incorporadas en Erlang para el almacenamiento de información.
• Erlang Balanced Trees (gb_trees): sistema de árbol balanceado. Rápido para leer, pero algo lento para escribir.
• Innostore: basado en el engine InnoDB de MySQL. Debido a restricciones de licencia, se proporciona por separado.

Cada cluster que se configura de Riak, consta de los siguientes elementos:

• Nodos: nodos físicos, o máquinas, de las que se compone el cluster.
• Nodos Virtuales: nodos virtuales (o vnodes) que corren en cada máquina. Cada máquina física puede contener uno o varios nodos virtuales.
• Particiones: cada cluster Riak tiene un entero de 160-bits dividido en particiones ecuánimes. Cada vnode reclamará una partición del anillo.

Cada nodo en el cluster es responsable del 1/(número total de nodos físicos) del anillo. Puedes determinar el número de vnodes en cada nodo calculando el (número de particiones)/(número de nodos). Por ejemplo, un anillo con 32 particiones, compuesto por cuatro nodos físicos, tendrá aproximadamente ocho vnodos por nodo. Esta configuración es representada por el siguiente diagrama:

Riak está diseñado para ser un sistema distribuido, cuantos más nodos haya en el sistema, más rápido funcionará.

No hay nodo maestro, todos los nodos en Riak son iguales. Cada nodo es completamente capaz de servir cualquier petición de cliente. Esto es posible debido a la forma en la que Riak usa la consistencia de hash para distribuir datos a través del cluster, que se realiza a través de un gossip protocol.

Sobre la replicación

Riak controla tantas réplicas como datos son mantenidos a través de una configuración llamada n-valor. Este valor tiene una configuración por defecto en cada nodo pero puede ser sobreescrito por cada bucket. Los objetos de Riak heredan el n-valor de su bucket padre. Todos los nodos en el mismo cluster deben de acordar y usar el mismo n-valor.

Por ejemplo, aquí hay una representación de que sucede cuando n-valor es 3 (esta es la configuración por defecto). Cuando almacenas el dato en el bucket con un n-valor de tres, el dato se replicará a tres particiones separadas del anillo.

Y cuando un nodo falla o se agrega otro nodo, ¿qué sucede?

Riak usa una técnica llamada hinted handoff, para compensar el cluster en el momento que un nodo falla. Los vecinos del nodo fallido tomarán relevo y realizarán el trabajo de ese nodo permitiendo al cluster trabajar de forma normal. Esto puede considerarse una forma de auto-curación.

Si se agrega un nodo nuevo, en cambio, se rebalancean los datos.

Algunas pegas… siempre las hay

Primero, los buckets que usan un conjunto de propiedades no estandar forzarán a Riak a enviar vía gossip más datos a través del cluster. Los datos adicionales pueden ralentizar el proceso. Segundo, algunos backends, como Innostore, almacenan cada bucket como una entidad separada. Esto puede causar que nos quedemos sin recursos tales como manejadores de ficheros. Estas restricciones de recursos pueden no impactar al rendimiento, pero representarán otro límite en el máximo número de buckets a gestionar.

Conclusiones

A nivel teórico, todo bien, parece. Habrá que realizar un banco de pruebas y ver qué tal va el sistema. De momento, me he quedado sin tiempo (del que había planificado) para escribir este artículo, por lo que, dejo las pruebas para la siguiente parte… que entraremos de lleno en la práctica.