Celery en production — choix du broker, sémantique de retry, et ce que Flower vous dit vraiment

Celery est l'un de ces outils dont les défauts sont presque corrects. Presque. La policy de retry par défaut va retrier pour toujours. acks_late par défaut est False, donc un crash de worker perd la tâche. Le broker par défaut pour « démarrage rapide » est Redis sans persistance activée, donc un redémarrage Redis perd toutes les tâches en cours.

Voici le setup Celery de production que nous faisons tourner pour les clients Python managés — choix de broker, config worker, policy de retry, et le monitoring qui fait remonter les problèmes.

Une tâche de base avec les défauts sûrs

from celery import Celery, shared_task
 
app = Celery('app', broker='redis://redis:6379/0', backend='redis://redis:6379/1')
app.conf.update(
    task_acks_late=True,
    task_reject_on_worker_lost=True,
    task_track_started=True,
    worker_prefetch_multiplier=1,
    broker_connection_retry_on_startup=True,
)
 
@shared_task(bind=True, autoretry_for=(IOError,), retry_backoff=True,
             retry_jitter=True, retry_kwargs={'max_retries': 5})
def send_email(self, to, subject):
    ...

acks_late=True et prefetch_multiplier=1 ensemble signifient : prendre une tâche à la fois, n'acquitter qu'après succès. Combinés avec retry_backoff et un plafond max_retries, les jobs ne disparaissent pas dans une boucle de retry.

L'article complet couvre :

• Redis vs RabbitMQ : quand chacun est le bon broker
• Idempotence — la propriété que les tâches devraient avoir mais ont rarement
• Routage des tâches vers des queues dédiées pour priorisation et isolation
• Flower : les métriques qui comptent (profondeur de queue, latence de tâche, taux de retry)
• Celery beat pour les tâches planifiées — et l'histoire d'élection de leader que personne ne vous prévient
• Cycle de vie des workers : max-tasks-per-child, fuites mémoire, interaction OOM-killer

Nous livrons ce pattern Celery sur chaque stack Python managée avec du travail en arrière-plan.