J'ai eu l'occasion de faire une présentation de Celery et rq au meetup django organisé par @revolunet et hébergé par @cyberdelia de 20 minutes. Merci à eux pour l'organisation et le cadre avec une vue imprenable !

Celery et rq sont deux gestionnaires de files d'attentes pour des tâches conçu en Python.

Le principe : dès qu'un traitement requiert trop de temps ou de ressources pour être traité par django durant une requête HTTP, on délègue ce traitement à un daemon qui va pouvoir les traiter de façon asynchrone.

Il faudra donc pouvoir alerter l'utilisateur (envoi d'un mail, pooling…)

Présentation de Celery

Initialement conçu comme une application django, il a évolué vers un projet autonome (mais qui peut bien évidemment toujours fonctionner de concert avec django.)

Celery est un gestionnaire distribué. Un broker va recevoir les ordres de tâches de la part du serveur sur lequel tourne django. Ce broker va distribuer les tâches.
Plusieurs backends sont supportés, RabbitMQ étant mis en avant comme celui offrant le meilleur support.

C'est un projet dynamique, qui a connu de nombreuses évolutions et dont l'API bouge encore pas mal (ex: suppression des décorateurs magiques dans la version 2.5.) Cependant, la politique de stabilité de l'API est très claire et les commandes sont dépréciées longtemps avant d'être retirées.

C'est un projet mature (les premiers commits remontent à 2007) et donc très (trop ?) riche.

De là est né rq.

Présentation de rq

rq se veut une alternative light à Celery, lorsqu'on a pas besoin toutes les fonctionnalités :

• différents types de tâches — Abortable, Repeatable;
• différents backends supportés;
• webhooks pour les autres langages…

Utilisation de Celery

La documentation de Celery est complète, et la prise en main assez rapide.

Malgré tout, de nombreux points ne sont pas abordés (ou alors cachés dans des sections parfois peu explicites).

Par exemple, toutes les fonctionnalités ne sont pas disponibles avec tous les backends.

Il est facile de partir dans une configuration pour se rendre compte au bout de quelque temps que toutes les options dont on a besoin ne sont pas autorisées.

Le tuning du daemon pour de bonnes performances requiert du temps. Selon la doc elle-même, il n'y a pas de recette miracle et chaque projet requiert un peu de tâtonnement (par exemple, avec le même hardware, 3 workers pouvant gérer chacun 10 tâches apparaît plus stable qu'un seul worker avec 30 tâches en parallèles.)

Malgré tout, certaines fonctionnalités pourtant importantes telles que la priorisation des tâches ne sont pas disponibles. La solution : avoir plusieurs workers (un pour les tâches urgentes, un pour les autres) et envoyer les tâches à l'un ou l'autre.

Si vous utilisez celery avec django, vous avez une application, dj_celery qui vous permet de surveiller le status de vos tâches.
Pour fonctionner, cette application requiert d'activer deux autres outils de celery :

• celerymon, qui va retourner l'état des files d'attentes,
• celerycam, qui va prendre des instantannés à intervalles réguliers pour les enregistrer dans la base de données de votre projet django.

Comme on travaille en asynchrone, il est absolument indispensable de surveiller celery, car le suivi des erreurs encore plus problématiques que pour un site classique.

Il faut également surveiller le broker. Le broker le plus utilisé est RabbitMQ, pour lequel il existe un plugin d'administration.

Utilisation de rq

Beaucoup plus simple, la doc est beaucoup plus concise (mais il y a beaucoup moins à dire aussi.)

Le backend du broker est redis uniquement (aussi disponible avec Celery).

On ne peut pas de tester l'état d'une tâche, à part vérifier si on a un résultat ou non. Celery possède différents états (PENDING, STARTED, SUCCESS, FAILED) et on peut définir des états personnalisés au besoin.

rq ne permet pas de distribuer vers un channel un exchange spécifique pour router les tâches entre différents workers selon le type de tâches.

Plusieurs workers peuvent être lancés mais une tâche est exécutée à la fois (idem pour Celery.)

Python only : pas de webhooks.

Il existe une interface d'administration, mais pour Flask.

Ne fonctionne que sous Unix.

rq me semble avoir été conçu avec des idées très arrêtées sur l'environnement d'exécution, je pense notamment à des environnements de production du type Heroku où l'on ne pourra pas nécessairement avoir RabbitMQ qui est dépendant de erlang, tandis que redis fait désormais partie de l'offre standard.

Conclusion

La discussion qui a suivi a mis en avant les nombreux problèmes rencontrés avec Celery lorsqu'il est utilisé conjointement avec RabbitMQ, tandis que redis semble plus facile à vivre. C'est sans doute l'info à retenir.