Lors d’une précédente expérience professionnelle en 2007 (AF83) j’avais mis en oeuvre des techniques de répartition de charge via des traitements asynchrones pour le développement d’un microblog/chat web. Je cherchais depuis à réutiliser ces technologies, ce qui m’a poussé au développement de Nodecast.

Or si à l’époque le domaine des serveurs de message queues était encore balbutiant, il a nettement évolué depuis. En effet à l’époque après en avoir testé quelques uns, j’avais fini par me résoudre à utiliser le protocole XMPP via un serveur Jabber. Il faut bien avouer que la mise en œuvre a été plutôt ardu. XMPP est un bon protocole mais il est au final peu adapté pour un simple système de file d’attente, trop verbeux et la librairie Ruby XMPP4R faiblarde, à l’époque en tout cas.

Depuis les serveurs de file d’attente ont poussé comme des champignons, et certains sont même dérivés de serveur type clé/valeur.  J’ai pour ma part choisi Gearman qui me parait une bonne technologie depuis sa réécriture en C, et c’est un bon compromis fonctionnalités / simplicité / performances. Avant d’aller plus loin je préfère présenter le schéma de l’architecture du site, ce qui rendra plus aisé les explications.

Architecture

La partie droite en orange représente le site web. Nginx transmet les requêtes HTTP vers un pool de services Thin qui est un serveur web applicatif, il est en charge d’exécuter l’application en Ruby on Rails. Pour des raisons de performances et efficacité, j’ai choisi d’utiliser une base de données NoSQL, mongoDB.

La partie intéressante est celle à gauche représentée par le nuage gris. En effet il représente les services en charge de l’API.

API asynchrone

L’API est ici une API REST. Le client en Qt effectue donc simplement des requêtes HTTP afin de communiquer avec le service web. Il fait des POST pour l’ajout de données, des PUT pour la modification et des GET pour la consultation.

Plus le client envoi des données sur un court délai, plus les statistiques seront détaillées. Le problème est que cela génère une multitude de connexions et donc de traitement. Et plus il y en a, plus la réponse au client sera longue, ce qui va dégrader la qualité de service. Bien entendu la solution est de rendre asynchrone les traitements afin que la réponse au client soit la plus rapide possible.

Cela est représenté par l’échange 1 et 2 entre le serveur Nginx et le serveur thin.

Client <-> serveur

Lors d’un POST, le client va demander la création d’une donnée au service. Ici il s’agit de la création d’une nouvelle machine (host) à monitorer. Le workflow est le suivant :

1. client Qt POST les datas
2. serveur sinatra authentifie le client
3. serveur sinatra génère un identifiant unique (UUID)
4. serveur sinatra sérialize les datas, et transmet la charge à Gearman dans la file d’attente du dispatcher
5. serveur sinatra renvoi au client un XML contenant l’identifiant unique
6. le client stocke cet identifiant et l’utilisera pour tous les prochains échanges

Le principe ici est que le serveur sinatra ne fasse que le strict minimum, afin de répondre le plus rapidement et d’être disponible pour une prochaine requête. Ainsi même sous une charge importante, les requêtes transmises par les clients Qt, seront empilé et mise en attente au chaud dans le serveur de file Gearman.

Pour une requête PUT le workflow est plus simple puisque l’étape 3 est supprimée. Le serveur sinatra renvoi dans tous les cas un XML contenant le status « proceed » afin de signaler au client que sa requête a été prise en compte.

L’intérêt de Sinatra est qu’il est très simple à mettre en oeuvre ce qui en fait à mon avis un candidat idéal pour servir une API. Le code du serveur tiens d’ailleurs dans un seul fichier :

#!/usr/bin/env ruby
require 'rubygems'

require 'gearman'

require "bundler"
Bundler.setup
Bundler.require(:default)

RAILS_ENV="production"

#Gearman::Util.debug = true
SERVERS = ['localhost:4730']

@@logger = Logger.new('log/server.log', 'daily')
@@logger.debug("Created logger")

File.open(File.join('../config/database.mongo.yml'), 'r') do |f|
 @settings = YAML.load(f)[RAILS_ENV]
end

Mongoid.configure do |config|
 name = @settings["database"]
 host = @settings["host"]
 config.use_object_ids = @settings["use_object_ids"]
 @@logger.info "database : #{name}"
 @@logger.info "host : #{host}"
 config.master = Mongo::Connection.new.db(name)
 # config.slaves = [
 #                Mongo::Connection.new(host, @settings["slave_one"]["port"], :slave_ok => true).db(name)
 #               ]
end

require 'models_mongoid/user.rb'
require 'models_mongoid/profil.rb'
require 'models_mongoid/host.rb' 

set :logging, true

helpers do
 def protected!
 unless authorized?
 response['WWW-Authenticate'] = %(Basic realm="Nodecast HTTP Auth")
 throw(:halt, [401, "Not authorized\n"])
 end
 end

 def authorized?
 @auth ||=  Rack::Auth::Basic::Request.new(request.env)
 @current_user = User.where(:email => @auth.credentials.first, :authentication_token => @auth.credentials.last).first
 @auth.provided? && @auth.basic? && @current_user
 end
end

post '/hosts.xml' do
 protected!
 xml = Crack::XML.parse(request.body.read)
 @@logger.info("#{Time.now} : RECEIVE CREATE")

 uuid = UUIDTools::UUID.timestamp_create.to_s

 host = {
 :user => @current_user.email,
 :uuid => uuid,
 :timestamp => Time.now.utc,
 :datas => xml
 }

 payload('dispatcher_add', host)

 builder do |xml|
 xml.instruct!
 xml.host do
 xml.uuid host[:uuid]
 end
 end
end

put '/host/update/:id' do
 protected!
 xml = Crack::XML.parse(request.body.read)
 @@logger.info("#{Time.now} : RECEIVE UPDATE")

 host = {
 :user => @current_user.email,
 :uuid => params[:id],
 :timestamp => Time.now.utc,
 :datas => xml
 }

 payload('dispatcher_update', host)

 builder do |xml|
 xml.instruct!
 xml.host do
 xml.status "proceed"
 end
 end
end

private

def payload(worker, data)

 client = Gearman::Client.new(SERVERS)
 taskset = Gearman::TaskSet.new(client)

 #task = Gearman::Task.new('update', Marshal.dump(host), :background => true, :poll_status_interval => 1)
 task = Gearman::Task.new(worker, Marshal.dump(data))
 task.on_complete {|d| @@logger.info "complete : #{d}" }  

 task.on_warning {|w| @@logger.info "[client] warn: #{w}" }
 task.on_fail {|f| @@logger.info "[client] calculation failed : #{f}" }
 taskset.add_task(task)  
end

On voit bien ici que « post ‘/hosts.xml’ do » et ‘put ‘/host/update/:id’ do » permettent de répondre très simplement aux requêtes POST et PUT des clients. Pour le reste on voit bien que le serveur ne fait que préparer un Hash avec l’XML transmis par le client, un timestamp, l’uuid du host et l’id de l’utilisateur. Ce Hast est ensuite sérialisé puis la charge est envoyée dans la file d’attente du dispatcher.

Dispatcher <-> workers

Comme on le voit dans le code les traitements sont envoyés dans la file d’attente sur 2 canaux : « dispatcher_update » et « dispatcher_add ». Il y a donc un processus Ruby qui attend des traitements sur ces canaux afin de les préparer puis les transmettre à chaque worker. J’avais tout d’abord un seul worker, mais il est beaucoup plus intéressant de le découper en plusieurs workers spécifiques à une tâche. En effet des utilisateurs peuvent décider de ne pas envoyer les informations relatives au CPU ou bien au réseau. De fait les worker auront la charge qui correspond au contenu des requêtes transmises.

Le dispatcher ne dépend pas des traitements à effectuer, son rôle est de découper le traitement en de multiples sous-traitement qu’il transmet dans le canal de chaque worker. Si les traitements sont lourds il peut malgré tout continuer à les répartir dans chacun des canaux, quelque soit la charge en cours.

Les traitements se font réellement dans chaque worker. Ils désérialisent les données reçues de leur file d’attente, puis les stocke dans mongodb. Voici un des workers dédié au traitement des load :

#!/usr/bin/env ruby
require 'rubygems'

gem 'mongoid', '1.9.0'

require 'mongoid'
gem 'gearman-ruby', '3.0.1'
require 'gearman'
require 'uuidtools'

require 'logger'
require 'yaml'
require 'optparse'
require "pp"

options = {}

optparse = OptionParser.new do |opts|
 opts.on('-w', '--work WORK', 'path to the work directory') do |work|                                        
 options[:work] = work
 end
 opts.on('-m', '--mongo MONGO', 'path to the mongo file') do |mongo|                                        
 options[:mongo] = mongo
 end
 opts.on('-e', '--env ENV', 'rails environment') do |env|                                        
 options[:env] = env
 end
end

begin
 optparse.parse!
 mandatory = [:work, :mongo, :env]
 missing = mandatory.select{ |param| options[param].nil? }
 if not missing.empty?
 puts "Missing options: #{missing.join(', ')}"
 puts optparse
 exit
 end
rescue OptionParser::InvalidOption, OptionParser::MissingArgument
 puts $!.to_s
 puts optparse
 exit
end

puts "Performing task with options: #{options.inspect}"            

#Gearman::Util.debug = true if options[:env] == "development"

servers = ['localhost:4730']
@@worker = Gearman::Worker.new(servers)

logger = Logger.new("#{options[:work]}/log/worker_stats_load.log", 'daily')
logger.debug("Created logger")

File.open(File.join("#{options[:mongo]}/database.mongo.yml"), 'r') do |f|
 @settings = YAML.load(f)[options[:env]]
end

Mongoid.configure do |config|
 name = @settings["database"]
 host = @settings["host"]
 config.use_object_ids = @settings["use_object_ids"]
 logger.info "database : #{name}"
 logger.info "host : #{host}"
 config.master = Mongo::Connection.new.db(name)
 # config.slaves = [
 #                Mongo::Connection.new(host, @settings["slave_one"]["port"], :slave_ok => true).db(name)
 #               ]
end

require "#{options[:work]}/models_mongoid/user.rb"
require "#{options[:work]}/models_mongoid/profil.rb"
require "#{options[:work]}/models_mongoid/host.rb"
require "#{options[:work]}/models_mongoid/osystem.rb" 

require "#{options[:work]}/models_mongoid/host_ram.rb"
require "#{options[:work]}/models_mongoid/host_cpu.rb"
require "#{options[:work]}/models_mongoid/host_network.rb"
require "#{options[:work]}/models_mongoid/host_last_comment.rb"
require "#{options[:work]}/models_mongoid/host_stats_uptime.rb"
require "#{options[:work]}/models_mongoid/host_stats_load.rb"
require "#{options[:work]}/models_mongoid/host_stats_network.rb"
require "#{options[:work]}/models_mongoid/host_stats_cpu.rb"
require "#{options[:work]}/models_mongoid/host_stats_memory.rb" 

require "#{options[:work]}/models_mongoid/load_statistic.rb" 

########## JOB UPDATE STAT ############
@@worker.add_ability('update_load') do |data,job|

 dump = Marshal.load(data)

 xml = dump[:push]
 host = Host.where(:uuid => dump[:uuid]).first

 host_load = {
 :created_at => dump[:timestamp],
 :updated_at => dump[:timestamp],
 :loadavg0 => xml[:loadavg0],
 :loadavg1 => xml[:loadavg1],
 :loadavg2 => xml[:loadavg2]
 }    

 begin

 ls = host.load_statistics.create(host_load)
 logger.info "LOAD stats created"

 loadavg0 = 0.0
 loadavg1 = 0.0
 loadavg2 = 0.0

 host.load_statistics.each do |stat|
 loadavg0 += stat.loadavg0
 loadavg1 += stat.loadavg1
 loadavg2 += stat.loadavg2
 end

 if !host.stats_load
 host.create_stats_load(
 :created_at => dump[:timestamp],
 :updated_at => dump[:timestamp],
 :number => 1,
 :loadavg0 => ls.loadavg0,
 :loadavg1 => ls.loadavg1,
 :loadavg2 => ls.loadavg2,
 :max0 => ls.loadavg0,
 :max1 => ls.loadavg1,
 :max2 => ls.loadavg2
 )
 else      
 host.stats_load.updated_at = dump[:timestamp]
 host.stats_load.number += 1

 host.stats_load.max0 = ls.loadavg0 if ls.loadavg0 > host.stats_load.max0
 host.stats_load.max1 = ls.loadavg1 if ls.loadavg1 > host.stats_load.max1
 host.stats_load.max2 = ls.loadavg2 if ls.loadavg2 > host.stats_load.max2

 host.stats_load.average0 = loadavg0 / host.stats_load.number
 host.stats_load.average1 = loadavg1 / host.stats_load.number
 host.stats_load.average2 = loadavg2 / host.stats_load.number

 host.stats_load.loadavg0 = ls.loadavg0
 host.stats_load.loadavg1 = ls.loadavg1
 host.stats_load.loadavg2 = ls.loadavg2

 host.save
 end

 logger.info "Embedded host load stats updated"

 rescue => e
 logger.info "failed on update : #{e}"
 raise Exception.new("failed on update : #{e}")
 end

end

loop do
 @@worker.work
end

Avantages

En cas de soucis sur les workers, ceux-ci pourront être stoppé sans problème même en production. Grâce au découplage mis en place, les traitements sont tous simplement en attente dans leur file d’attente. Il y a intérêt à avoir un serveur d’API très basique (ici le code dans Sinatra) afin d’éviter au maximum les éventuels plantages ou corruption des données, et de plus cela le rend, comme je l’ai déjà dis, plus rapide.

Evolution

Cette architecture est encore basique car ne tourne que sur une seule machine. Cependant les technologies employées permettront de la répartir sur plusieurs machines très simplement. Tout d’abord au niveau de mongoDB via des slaves. Puis en démarrant plusieurs démons Gearman. Les workers pourront ainsi dépiler leurs jobs sur l’un des serveurs Gearman du cluster.

Ensuite il pourra être intéressant que chaque worker log dans mongoDB ses tâches et ses temps de traitement afin de détecter les éventuels bottleneck. Gearman possède également une multitude d’options comme pouvoir rendre prioritaire un job.

Enfin il est bien entendu approprié que le front web puisse utiliser l’API afin d’effectuer des traitements lourds demandés par l’utilisateur.

Sinatra est un framework web léger non MVC qui permet via son DSL de répondre à toutes les méthodes HTTP (DELETE, PUT,POST,GET) simplement et en utilisant un seul fichier Ruby. L’introduction démontre la plupart de ses capacités. C’est à mon avis idéal pour servir une API plutôt que de sortir l’artillerie lourde Rails.

MongoID est un driver Ruby pour la base NoSQL mongoDB. Il est en concurrence avec MongoMapper.

Gearman est un serveur qui fait parti des innombrables serveur de job. En effet depuis ces dernières années un nouveau serveur sort tous les 6 mois ou presque avec plus ou moins de succès. Parmi ceux-ci on peut citer Beanstalkd ou RabbitMQ, il existe un « vieux » (1 an) comparatif non exhaustif de quelques serveurs de job Choosing a message queue for Python on Ubuntu on a VPS. Pour ajouter au trouble on peut trouver parmi eux des serveurs NoSQL type clé/valeur comme redis avec le plugin Resque.

Je travaille depuis quelques mois sur mon projet Nodecast et je souhaitais rendre l’API asynchrone. Le principe du projet est qu’un client desktop extrait régulièrement des informations systèmes et les transmet au site web. Un serveur Sinatra expose l’API et enregistre les données dans MongoDB. Le problème est que si de plus en plus clients viennent pusher leurs données sur le serveur Sinatra, celui-ci aura forcément de plus en plus de mal à encaisser la charge. Avec une architecture de ce type entre la requête HTTP POST du client et la réponse du serveur, tout fonctionne de manière synchrone, de fait si le serveur Sinatra atteins son pallier il ne sera plus en mesure de répondre à de nouvelles requêtes. Il est nécessaire que l’échange entre le client et le serveur Sinatra soit le plus rapide possible.

Pour cela il est essentiel de découpler l’interaction entre le serveur et le travail effectué. Pour comprendre cela imaginons que le client ne transmette pas d’informations systèmes mais carrément une vidéo que le serveur devra par exemple ré-encoder. Il n’est pas concevable que lorsque le client (desktop ou browser) a fini de poster la vidéo, l’utilisateur doive encore attendre la fin du réencodage du film avant d’avoir la main. Ce travail de ré-encodage doit s’effectuer dans un 2ème temps.

La première règle à définir est que l’échange entre le client et le serveur doit s’effectuer le plus vite possible, c’est un échange du type « fire and forget ». Pour cela lorsque le client desktop poste les informations, le serveur ne doit renvoyer qu’un acknowledge et aucune autre information permettant au client de savoir si le travail s’est bien effectué. Car si c’était le cas on reviendrait à un fonctionnement synchrone … Cependant rien empêche le serveur de renvoyer au client un identifiant unique afin de lui permettre par la suite de connaitre via une autre requête l’état de du travail envoyé.

Pour rendre cela possible il est nécessaire de séparer le code qui réceptionne la requête du code qui va traiter la demande. Il manque un tampon entre les deux, car le code qui va traiter la demande, le worker, peut être justement occupé à en traiter une. L’intérêt d’un serveur de job (appelé aussi serveur de file de message) est de stocker le job et le transmettre au worker lorsque celui-ci en fait la demande. Dans l’industrie il existe le protocole AMQP que RabbitMQ implémente. Je n’ai malheureusement pas réussi à faire lancer ce dernier sur mon serveur Ubuntu 10.04. J’ai découvert Gearman qui est presque aussi simple d’usage sur Beanstalkd tout en proposant des capacités de montée en charge, un worker pouvant s’abonner à plusieurs serveurs Gearman. De plus cet outil est développé par Danga pour LiveJournal, voir leur présentation sur le backend de LiveJournal : Behind the Scenes at LiveJournal: Scaling Storytime.

Sinatra expose l’API, réceptionne les demandes des clients, les transmet aussitôt à Gearman dans une file nommée en fonction du job (update,insert,…) puis renvoie aussitôt un ack au client desktop pour lui confirmer que sa requête est prise en compte. Sinatra est donc rapidement disponible à réceptionner une nouvelle requête. Le worker est abonné aux files d’attente dont il a la charge, il supprime le job du serveur afin de le traiter. Enfin Gearman offre la possibilité au worker de retourner au client l’état du travail effectué. Le client, ici Sinatra, dispose de ces 3 méthodes :

Il peut ainsi stocker dans un fichier de log le statut du worker.

Voici le code du client Sinatra lancé par Thin :

#!/usr/bin/env ruby
require 'rubygems'

require 'gearman'

require "bundler"

Bundler.setup

Bundler.require(:default)

RAILS_ENV="development"

Gearman::Util.debug = true

SERVERS = ['localhost:4730']

logger = Logger.new('log/server.log', 'daily')

logger.debug("Created logger")

File.open(File.join('../config/database.mongo.yml'), 'r') do |f|

@settings = YAML.load(f)[RAILS_ENV]

end

Mongoid.configure do |config|

name = @settings["database"]

host = @settings["host"]

config.use_object_ids = @settings["use_object_ids"]

logger.info "database : #{name}"

logger.info "host : #{host}"

config.master = Mongo::Connection.new.db(name)

end

require 'models_mongoid/user.rb'

require 'models_mongoid/profil.rb'

require 'models_mongoid/host.rb'

set :logging, true

helpers do

def protected!

unless authorized?

response['WWW-Authenticate'] = %(Basic realm="Nodecast HTTP Auth")

throw(:halt, [401, "Not authorized\n"])

end

end

def authorized?

@auth ||=  Rack::Auth::Basic::Request.new(request.env)

# logger.info "AUTH = #{@auth.inspect}"

@current_user = User.where(:email => @auth.credentials.first, :authentication_token => @auth.credentials.last).first

@auth.provided? && @auth.basic? && @current_user

end

end

post '/hosts.xml' do

protected!

xml = Crack::XML.parse(request.body.read)

logger.info("POST")

uuid = UUIDTools::UUID.timestamp_create.to_s

host = {

:user => @current_user.email,

:uuid => uuid,

:datas => xml

}

client = Gearman::Client.new(SERVERS)

taskset = Gearman::Taskset.new

# task = Gearman::Task.new('add', Marshal.dump(xml), :background => true, :poll_status_interval => 1)

task = Gearman::Task.new('add', Marshal.dump(host))

task.on_complete {|d| logger.info "complete : #{d}" }

task.on_warning {|w| logger.info "[client] warn: #{w}" }

task.on_fail {|f| logger.info "[client] calculation failed : #{f}" }

taskset << task

client.run(taskset)

builder do |xml|

xml.instruct!

xml.host do

xml.uuid host[:uuid]

end

end

end

put '/host/update/:id' do

protected!

xml = Crack::XML.parse(request.body.read)

host = {

:user => @current_user.email,

:uuid => params[:id],

:datas => xml

}

logger.info("UPDATE")

client = Gearman::Client.new(SERVERS)

taskset = Gearman::Taskset.new

#task = Gearman::Task.new('update', Marshal.dump(host), :background => true, :poll_status_interval => 1)

task = Gearman::Task.new('update', Marshal.dump(host))

task.on_complete {|d| logger.info "complete : #{d}" }

task.on_warning {|w| logger.info "[client] warn: #{w}" }

task.on_fail {|f| logger.info "[client] calculation failed : #{f}" }

taskset << task

client.run(taskset)

builder do |xml|

xml.instruct!

xml.host do

xml.status "proceed"

end

end

end

et le code du worker lancé par un script daemons

#!/usr/bin/env ruby
require 'rubygems'

gem 'mongoid', '1.9.0'
require 'mongoid'
gem 'gearman-ruby', '2.0.0'
require 'gearman'
require 'uuidtools'
require 'logger'
require 'yaml'
require 'optparse'
require "pp"

options = {}

optparse = OptionParser.new do |opts|
  opts.on('-w', '--work WORK', 'path to the work directory') do |work|
    options[:work] = work
  end
  opts.on('-m', '--mongo MONGO', 'path to the mongo file') do |mongo|
    options[:mongo] = mongo
  end
  opts.on('-e', '--env ENV', 'rails environment') do |env|
    options[:env] = env
  end
end

begin
  optparse.parse!
  mandatory = [:work, :mongo, :env]
  missing = mandatory.select{ |param| options[param].nil? }
  if not missing.empty?
    puts "Missing options: #{missing.join(', ')}"
    puts optparse
    exit
  end
rescue OptionParser::InvalidOption, OptionParser::MissingArgument
  puts $!.to_s
  puts optparse
  exit
end

puts "Performing task with options: #{options.inspect}"            

Gearman::Util.debug = true if options[:env] == "development"

servers = ['localhost:4730']
@@worker = Gearman::Worker.new(servers)

logger = Logger.new("#{options[:work]}/log/worker.log", 'daily')
logger.debug("Created logger")

File.open(File.join("#{options[:mongo]}/database.mongo.yml"), 'r') do |f|
  @settings = YAML.load(f)[options[:env]]
end

Mongoid.configure do |config|
  name = @settings["database"]
  host = @settings["host"]
  config.use_object_ids = @settings["use_object_ids"]
  logger.info "database : #{name}"
  logger.info "host : #{host}"
  config.master = Mongo::Connection.new.db(name)
end

require "#{options[:work]}/models_mongoid/user.rb"
require "#{options[:work]}/models_mongoid/profil.rb"
require "#{options[:work]}/models_mongoid/host.rb"
require "#{options[:work]}/models_mongoid/osystem.rb"
require "#{options[:work]}/models_mongoid/load_statistic.rb"
require "#{options[:work]}/models_mongoid/memory_statistic.rb"
require "#{options[:work]}/models_mongoid/uptime_statistic.rb"
require "#{options[:work]}/models_mongoid/network_statistic.rb"
require "#{options[:work]}/models_mongoid/cpu_statistic.rb" 

########## JOB ADD HOST ############
@@worker.add_ability('add') do |data,job|

  dump = Marshal.load(data)
  xml = dump[:datas]

  @current_user = User.where(:email => dump[:user]).first

  p "user = #{@current_user.inspect}"

  push_host = {
    :uuid => dump[:uuid],
    :public => xml['host']['public'],
     s_version => xml['host']['version'],
    :patch_level => xml['host']['patch_level'].nil? ? "" : xml['host']['patch_level'].downcase,
    :cpu_vendor => xml['host']['cpu_vendor'],
    :architecture => xml['host']['architecture'],
    :cpu_model => xml['host']['cpu_model'],
    :cpu_mhz => xml['host']['cpu_mhz'],
    :cpu_cache_size => xml['host']['cpu_cache_size'],
    :cpu_number => xml['host']['cpu_number'],
    :cpu_total_cores => xml['host']['cpu_total_cores'],
    :cpu_total_sockets => xml['host']['cpu_total_sockets'],
    :cpu_cores_per_socket => xml['host']['cpu_cores_per_socket'],
    :mem_ram => xml['host']['mem_ram'],
    :mem_total => xml['host']['mem_total'],
    :hostname => xml['host']['hostname'],
    :domain_name => xml['host']['domain_name'],
    :default_gateway => xml['host']['default_gateway'],
    :primary_dns => xml['host']['primary_dns'],
    :secondary_dns => xml['host']['secondary_dns'],
    :primary_interface => xml['host']['primary_interface'],
    :primary_addr => xml['host']['primary_addr'],
    :user_id => @current_user.id
  }

  host_uptime = {
    :time => xml['host']['uptime_time'],
    :days => xml['host']['uptime_days']
  }

  host_load = {
    :loadavg0 => xml['host']['loadavg0'],
    :loadavg1 => xml['host']['loadavg1'],
    :loadavg2 => xml['host']['loadavg2']
  }

  host_mem = {
    :mem_used => xml['host']['mem_used'],
    :mem_free => xml['host']['mem_free'],
    :mem_actual_free => xml['host']['mem_actual_free'],
    :mem_actual_used => xml['host']['mem_actual_used'],
    :mem_actual_free_percent => xml['host']['mem_actual_free_percent'],
    :mem_actual_used_percent => xml['host']['mem_actual_used_percent'],
    :swap_total => xml['host']['swap_total'],
    :swap_used => xml['host']['swap_used'],
    :swap_free => xml['host']['swap_free'],
    :swap_page_in => xml['host']['swap_page_in'],
    :swap_page_out => xml['host']['swap_page_out']
    }

  host_network = {
    :rx_rate => xml['host']['rx_rate'],
    :tx_rate => xml['host']['tx_rate']
  }

  host_cpu = {
    :user => xml['host']['cpu_user'],
    :sys => xml['host']['cpu_sys'],
    :nice => xml['host']['cpu_nice'],
    :idle => xml['host']['cpu_idle'],
    :wait => xml['host']['cpu_wait'],
    :irq => xml['host']['cpu_irq'],
    :soft_irq => xml['host']['cpu_soft_irq'],
    :stolen => xml['host']['cpu_stolen'],
    :combined => xml['host']['cpu_combined'],
    :total => xml['host']['cpu_total']
  }

  begin
    profil = @current_user.profils.where(:context => xml['host']['profil']).first

    if !profil
      profil = @current_user.profils.create(:context  => xml['host']['profil'])
    end

    @host = profil.hosts.create(push_host)

    osystem = Osystem.where(:vendor => xml['host']['vendor'].downcase, :vendor_version => xml['host']['vendor_version'].downcase).first

    if !osystem
      osystem = Osystem.create(
                               :name => xml['host']['name'].downcase,
                               :vendor => xml['host']['vendor'].downcase,
                               :vendor_version => xml['host']['vendor_version'].downcase,
                               :vendor_code_name => xml['host']['vendor_code_name'].nil? ? "" : xml['host']['vendor_code_name'].downcase,
                               :description => xml['host']['description'],
                                s_base => xml['host']['os_base'],
                                s_type => xml['host']['os_type']
                               )
    end

    @host.osystem_id = osystem.id
    osystem.hosts_number += 1
    osystem.save
    @host.save

    if xml['host']['activated_memory'] == "true"
      @host.memory_statistics.create(host_mem)
    end

    if xml['host']['activated_load'] == "true"
      @host.load_statistics.create(host_load)
    end

    if xml['host']['activated_uptime'] == "true"
      @host.uptime_statistics.create(host_uptime)
    end

    if xml['host']['activated_network'] == "true"
      @host.network_statistics.create(host_network)
    end

    if xml['host']['activated_cpu'] == "true"
      @host.cpu_statistics.create(host_cpu)
    end

  rescue => e
    logger.info "error on create host : #{e}"
  end

  @current_user.hosts_number += 1
  @current_user.save

logger.info "created"
end

########## JOB UPDATE HOST ############
@@worker.add_ability('update') do |data,job|

  dump = Marshal.load(data)
  xml = dump[:datas]

  @current_user = User.where(:email => dump[:user]).first
  @host = Host.where(:uuid => dump[:uuid], :blocked => false).first

  if !@host
logger.info "host unknown"

  elsif @current_user.hosts.include?(@host)
    # os = Osystem.find(:all, :conditions => "lower(name) = '#{xml['host'][:os_name].downcase}' AND lower(codename) LIKE '%#{xml['host'][:os_codename].downcase}%' AND version = '#{xml['host'][:os_release]}' AND computer_architecture = '#{xml['host'][:architecture]}'")

    host_uptime = {
      :time => xml['host']['uptime_time'],
      :days => xml['host']['uptime_days']
    }

    host_load = {
      :loadavg0 => xml['host']['loadavg0'],
      :loadavg1 => xml['host']['loadavg1'],
      :loadavg2 => xml['host']['loadavg2']
    }

    host_mem = {
      :mem_used => xml['host']['mem_used'],
      :mem_free => xml['host']['mem_free'],
      :mem_actual_free => xml['host']['mem_actual_free'],
      :mem_actual_used => xml['host']['mem_actual_used'],
      :mem_actual_free_percent => xml['host']['mem_actual_free_percent'],
      :mem_actual_used_percent => xml['host']['mem_actual_used_percent'],
      :swap_total => xml['host']['swap_total'],
      :swap_used => xml['host']['swap_used'],
      :swap_free => xml['host']['swap_free'],
      :swap_page_in => xml['host']['swap_page_in'],
      :swap_page_out => xml['host']['swap_page_out']
    }

    host_network = {
      :rx_rate => xml['host']['rx_rate'],
      :tx_rate => xml['host']['tx_rate']
    }

    host_cpu = {
      :user => xml['host']['cpu_user'],
      :sys => xml['host']['cpu_sys'],
      :nice => xml['host']['cpu_nice'],
      :idle => xml['host']['cpu_idle'],
      :wait => xml['host']['cpu_wait'],
      :irq => xml['host']['cpu_irq'],
      :soft_irq => xml['host']['cpu_soft_irq'],
      :stolen => xml['host']['cpu_stolen'],
      :combined => xml['host']['cpu_combined'],
      :total => xml['host']['cpu_total']
    }

    begin

      if xml['host']['profil'] != @host.profil.context
        profil = @current_user.profils.where(:context => xml['host']['profil']).first
        if !profil
          profil = @current_user.profils.create(:context  => xml['host']['profil'])
        end
        @host.profil = profil
        @host.save
      end

         if xml['host']['activated_memory'] == "true"
           mem = @host.memory_statistics.create(host_mem)
         end

         if xml['host']['activated_load'] == "true"
           @host.load_statistics.create(host_load)
         end

         if xml['host']['activated_uptime'] == "true"
           @host.uptime_statistics.create(host_uptime)
         end

         if xml['host']['activated_network'] == "true"
           @host.network_statistics.create(host_network)
         end

         if xml['host']['activated_cpu'] == "true"
           @host.cpu_statistics.create(host_cpu)
         end

         logger.info "updated"

    rescue => e
      logger.info "failed on update : #{e}"
      raise Exception.new("failed on update : #{e}")
    end

  else
    logger.info "unauthorized update"
    raise Exception.new("unauthorized update")
  end
end

@@worker.work

Si vous suivez l’actualité RubyonRails, vous savez sans doute que l’édition 2008 de Paris on Rails a lieu le 1er décembre à la Cité des sciences. Par contre vous ne savez peut être pas qu’une Rails party est organisé la vieille ce dimanche 30 novembre. Toutes les infos ici : rails party 2008 et inscription ici. Ils ont bien de la chance ces parisiens ! Quand est-ce que Lyon sera à la hauteur de sa dimension … ?

Pour enchainer sur le thème Ruby, j’ai réalisé une nouvelle et sans doute dernière version de Geekast 0.1.3 afin de fixer ce bug. Peercast n’étant plus maintenu par son développeur la motivation n’y est plus et je suis de plus en apprentissage du C++ sur iMotion un autre projet perso. Quoi qu’il en soit je ne compte pas abandonner Ruby qui est un vrai plaisir à utiliser et complémentaire à un langage compilé.

Dans la continuité de ma migration vers Fedora sur mes desktops, je viens de migrer mon serveur dedibox sous Centos la version gratuite de Red Hat Enterprise Linux. Même si cet OS est très robuste et maintenu 7 ans, on y trouve moins de paquet qu’ailleurs, aussi j’ai ajouté le dépôt Fedora dédié à Centos, EPEL. J’ai pu ainsi installer Nginx et ejabberd 2.0.2. J’ai été surpris de trouver dans les dépôts des gems tel que Rails, mais malheureusement celui-ci ne fonctionne pas car il a été lié à une version gem de rake trop ancienne (0.7). C’est bien gentil de vouloir packager les gems mais encore faut-il le faire correctement Donc téléchargement de rubygems 1.3 et installation classique des gems, cela fonctionne très bien, je ne vois pas l’intérêt de faire un double travail côté distribution…

C’est pour moi l’occasion de quitter le bon vieux couple apache/mongrel et tester le fameux nginx / thin. Grâce à cette doc thin-nginx-with-rails, j’ai pu rapidement faire tourner mon blog avec thin et nginx. A voir ce que cela donnera sur de futurs projets perso plus gourmant qu’un blog. Pour info, pour pouvoir utiliser le fichier rake par thin il suffit de le copier dans lib/tasks/thin.rake du projet Rails.Et pour la conf nginx dans /etc/nginx/conf.d/upstream-fair.conf

Je viens de publier un article en 2 parties sur le blog d’AF83 :

De la répartition de charge en Ruby on Rails 1/2

De la répartition de charge en Ruby on Rails 2/2

C’est plutôt technique, et présente une solution parmi tant d’autres dans ce domaine très particulier.

L’architecture.

Les bots

Il ne reste qu’à exploiter les capacités de Rails et de XMPP afin de développer les bots qui vont effectuer les traitements.

Exemple :

Ces lignes permettent à un script Ruby de charger l’environnement Rails du projet. Le bot est alors capable d’attaquer notre modèle de données via ActiveRecord.

Ce gem nous permet de communiquer vers le compte Jabber du bot. Il peut donc dépiler les objets qui lui sont destiné et les désérialiser pour les traiter.

Ce gem permet de gérer le bot en tant que service (stop/start/restart).

Pour sérialiser/désérialiser vos objets Ruby / Rails.

Ce gem sert à intercepter une coupure de la connexion vers MySQL. Il surcharge ActiveRecord afin de renégocier une connexion.

Avec ces outils nous avons la capacité de créer des services exploitant une file d’attente Jabber et fonctionnant en parallèle. Ainsi, si la charge vient à augmenter, les messages en attente de traitement ne seront pas perdus, puisqu’en attente dans les comptes Jabber stockés par ejabberd. De plus il est possible de multiplier un même bot en exploitant les ressources du protocole Jabber, chaque bot écoutant sur sa propre ressource (bot@monserveurjabber.com/1, bot@monserveurjabber.com/2, …).

Résumé

Pour Noumba, nous avons développé un projet en Rails, le Hub, qui gère la file d’attente Jabber, et communique en REST avec le frontal Noumba. Si cette architecture est sur-dimensionnée pour votre projet, nul besoin d’un backend. Votre site et des bots suffisent amplement. De même quelques comptes Gmail suffisent si vos ne souhaitez pas déployer votre propre serveur Jabber.

Si un backend en Rails s’avère nécessaire il n’est pas conseillé de dupliquer les modèles de votre site principal vers celui-ci. Cela fonctionne mais le principe DRY est de fait supprimé. Cependant un outil tel que Piston permet de temporiser cette affirmation.

Les autres

Après divers essais Twitter a fini par développer son propre serveur de file qui exploite memcached, starling

Un développeur de Seesmic indique utiliser ActiveMQ et RabbitMQ mais semble vouloir migrer vers une solution XMPP : scaling-questions-and-issues

Il existe un grand nombre d’alternatives, on peut citer :

• Beanstalkd , about-this-blog-beanstalk-messaging-queue

• Sparrow

• AP4R

Les deux premiers utilisent le twisted like eventmachine

Bémol

Une telle architecture implique la gestion d’un serveur Jabber, ce qui peut s’avérer une tâche plus complexe et lourde qu’un réel MoM dédié. De plus la stabilité de la bibliothèque xmpp4r ainsi que le plugin ActionMessenger est à surveiller de près. Pour ce dernier, il a été nécessaire de le patcher afin qu’il puisse supporter plusieurs instances Rails.

Avenir

XMPP est un protocole standard et ouvert très répandu ce qui en fait un candidat idéal si l’on souhaite une architecture pérenne et évolutive. L’architecture décentralisée de Jabber et ses capacités à se connecter à des services externes tel que OpenID (xmppid.net) ouvre la porte à une multitude de possibilités.

Ses nombreuses fonctionnalités dédiés au chat (room, pub/sub, voIP, …) sont toutes indiquées pour des sites communautaires et sociaux à tel point que le projet DiSo souhaite l’utiliser en son coeur, mais ceci est un autre sujet.

Cet article a pour but de décrire l’architecture employée derrière le site de micro-blogging Noumba. Il n’a pas pour objectif d’être exhaustif ni de prétendre proposer la solution idéale, mais seulement présenter un moyen de résoudre certaines contraintes selon notre contexte.

Micro-blogging

Le micro-blogging est un concept, lancé par Twitter, qui permet de s’exprimer en de courtes phrases, tenant en une centaine de caractères de manière à pouvoir être lu depuis un téléphone portable, par SMS ou WAP.
En une phrase on ne communique le même type d’information que sur son blog. Cela va donc de son humeur, un lien, ou une rapide information qui ne nécessite pas un long exposé. Ce type d’information sont plus courante que celle que l’on écrirait sur son blog, et à ce titre le micro-blogging est un complément au blog plus qu’une alternative.

Le corollaire est la possibilité de s’exprimer depuis son téléphone portable vers le site.

Au final un site de micro-blogging est souvent utilisé en tant que passerelle entre 2 outils de communication (Phone2Phone, Desktop2API, Phone2Jabber, Web2…).

Contexte

Noumba est un site web de micro-blogging en Ruby on Rails. Il est ouvert à tous, mais son orientation commerciale le prédispose à une certaine tranche d’âge d’utilisateurs, entre 13 et 25 ans. De fait il est pour l’instant plus utilisé pour du chat que du micro-blogging, ce qui génère un fort nombre de messages par utilisateur.

En outre de part le profil des utilisateurs, des filtres sont indispensable afin de garantir une certaine qualité de contenu et de confidentialité.

Pour le reste, les contraintes sont les mêmes que des sites tels que Twitter ou Jaiku, cependant Noumba a ceci de particulier qu’il propose un certain nombre de satellites utilisés par des partenaires, tel que SFR (sfr.noumba.net), NRJ, (mikl.noumba.net, 6-9.noumba.net) MyMajorCompany (mymajorcompany.noumba.net), MCM (mcm.noumba.net), …

Contraintes

Des traitements asynchrones

Lorsqu’un message est posté, des traitements sont appliqués (filtrage, routage, emails, logs,…). Ces traitements ne doivent pas augmenter la latence entre l’utilisateur et le site web. Il n’est donc pas possible de les effectuer de manière synchrone, c’est à dire imposer à l’utilisateur d’attendre leur fin avant de lui rendre la main.
Si un fonctionnement synchrone est envisageable avec quelques utilisateurs en simultané, il est tout bonnement impossible pour un site à vocation grand public si l’on veut respecter une certaine qualité de service.

La solution est d’effectuer ces traitements de manière asynchrone, c’est à dire en parallèle, sans imposer à l’utilisateur leur fin pour lui rendre la main.

Les solutions

background

La première solution utilisée sur Noumba fut backgroundrb. Cet outil fournit un serveur de tâche permettant de les paralléliser dans un processus.
Si cette solution est intéressante pour quelques tâches simples, elle n’est plus possible dans le contexte lourd d’un micro-blogging, d’autant plus que backgroundrb utilisait les threads.
Les threads en Ruby sont peu efficaces (green thread) et une telle architecture consomme trop de ressources et est l’origine de bugs difficilement décelables.
Ces threads permettent d’exécuter les traitements, workers, cependant la communication entre eux n’est pas aisée ce qui complique l’enchainement des traitements.

Backgroundrb a depuis été repris et n’utilise plus à priori les threads. Malgré tout, une architecture robuste à base de file d’attente est préférable.

Hey MoM ! ou le monde des messages brokers

Les Message oriented Middleware sont des architectures qui permettent de faire communiquer des applicatifs de manière asynchrone par le biais d’une file d’attente. JMS est le MoM le plus connu et un certain nombre d’implémentations libres existent (ActiveMQ, RabbitMQ)

Parmis ceux-ci, certains implémentent le protocole texte stomp, plus simple et adapté à un site de micro-blogging. StompServer en Ruby en fait parti.

Plus de détails sur les MoM

ActiveMessaging.

Ce plugin Rails permet de communiquer vers un serveur MoM. Il lance un poller qui interroge le serveur MoM afin de lui transmettre ou lui retirer les messages.
Ce plugin est MoM agnostique, on peut interroger aussi bien un serveur ActiveMQ, StompServer et même AmazonSQS.

Noumba a utilisé un certain temps un backend StompServer / ActiveMessaging. C’est une architecture intéressante cependant l’évolution et la qualité du code de ActiveMessaging sont à surveiller de prêt.

Noumba en tant que micro-blog génère une forte charge. Or cette charge devient vite un handicap pour le bon fonctionnement du poller.
La conclusion qui s’impose est que Noumba se doit d’être le plus léger possible en effectuant le moins d’opération même par le biais d’un plugin.

Que REST il ?

REST est en effet la solution la plus simple, la plus standard (HTTP) et la moins lourde.
Dans sa dernière architecture, Noumba communique en REST avec un backend, le Hub, également en Rails. Les messages sous forme de Hash sont sérialisés puis transmis au backend.
Cependant il est toujours nécessaire d’implémenter une architecture MoM cà´té Hub afin d’obtenir un fonctionnement asynchrones.

XMPP bien sûr !

Quel serveur robuste fonctionne de fait sous forme de file d’attente, tout en étant robuste et utilisant un protocole standard, connu et ouvert ? XMPP bien sûr !
Ejabberd est un des serveurs Jabber le plus robuste. Etant en erlang, il peut facilement être réparti sous forme de cluster si le besoin se fait sentir.

Entre REST et XMPP il nous manque le lien Ruby on Rails. ActionMessenger vient le combler. Ce plugin Rails permet de transmettre des messages XMPP en utilisant un compte Jabber. Il fonctionne simplement à la manière d’ActionMailer.

Le Hub implémente ce plugin. Il reçoit les objets sérialisés et les transmet à divers comptes Jabber puis répond aussità´t à Noumba au travers de son API REST.