Netty et Cassandra en finale du challenge USI 2011

Le challenge USI 2011 est une compétition organisée par Octo Technologies, qui vise à réaliser une application Web qui survit à des conditions extrêmes:

  • 1 000 000 d’utilisateurs connectés en même temps
  • Avec des connexions HTTP longues
  • Et des serveurs qui plantent de manière aléatoire

Vous trouverez plus d’informations sur le site du challenge.

Sur les 20 équipes qui ont participé au challenge, une dizaine a pu rendre une application testable, et 3 ont été sélectionnées pour la finale, dont l’équipe n°10.

L’équipe n°10 c’est:

Vous pouvez suivre l’équipe sur twitter @usi2011_jaxio

L’application réalisée est entièrement développée en Java, suite à une étude de différentes technologies concurrentes, en particulier node.js, nginx et zeromq.

En effet, le challenge pose deux problèmes bien particuliers:

  • Tenir un grand nombre de connexions HTTP en parallèle
  • Avoir un back-end qui supporte une montée en charge linéaire et des crashs aléatoires

Pour ce qui est des connexions HTTP, nos tests nous ont montré que l’on pouvait faire aussi bien que nginx ou node.js avec du Java. C’est pour cette raison que nous avons choisi JBoss Netty pour notre frontal. Pour information, une autre équipe finaliste (Xebia) a choisi Deft, qui est une solution Java assez proche, il semble donc que ce soit le meilleur choix à faire pour tenir la charge. Voilà qui devrait surprendre pas mal de monde…
Cependant, il faut noter qu’il s’agit de solutions développées spécifiquement pour ce challenge, et qu’un serveur d’application Java classique est totalement incapable de tenir ce genre de charge. Concernant le back-end, nous avons choisi Apache Cassandra, qui est une solution NoSQL permettant d’excellentes performances en écriture (ce qui est l’un des gros problèmes du challenge), ainsi qu’une très bonne bonne montée en charge.

Notre retour sur Cassandra est positif: l’outil est impressionnant en terme d’architecture technique et propose des fonctionnalités tout simplement révolutionnaires pour qui est habitué aux technologies SQL “standard”. De plus, la documentation est particulièrement bien soignée, en particulier lorsque l’on recherche des informations sur la performance:

Ce choix de Cassandra nous a renforcé dans l’utilisation d’un front-end Java, car nous n’avons pas trouvé de solution satisfaisante pour nous connecter à Cassandra depuis les autres technologies étudiées (avec node.js par exemple).

Le jeu n’étant pas encore fini, nous donnerons plus tard dans ce blog les détails de différentes stratégies et tunings que nous avons utilisées sur notre système, en particulier au niveau de la configuration de Cassandra, des JVMs et de l’OS (un Ubuntu server).

En attendant, nous souhaitons bonne chance à nos concurrents!