Exécution de RabbitMQ+Celery sur le même serveur que l'environnement de production

Question

J'exécute une application Django dans une instance EC2, qui utilise RabbitMQ + Celery pour la mise en file d'attente des tâches. Y a-t-il des inconvénients à exécuter mon nœud RabbitMQ à partir de la même instance EC2 que mon application de production ?

Answer 1

La réponse à cette question dépend vraiment du contexte de votre application.

Lorsque vous êtes confronté à des scénarios, vous devez toujours tenir compte de quelques éléments.

Séparation des préoccupations Ici, nous voulons nous assurer que si l'un des systèmes n'est pas responsable du fonctionnement des autres systèmes. Cela inclut des choses comme

• Si l'instance ec2 qui exécute toutes les tâches tombe en panne, les tâches restantes dans la file d'attente continueront-elles à fonctionner ?

• si ma mémoire vive est pleine, tous les systèmes continueront-ils à fonctionner ?

• Puis-je faire évoluer un seul segment de mon application sans avoir à repenser l'infrastructure ?

En ayant rabbit et django (avec une sorte de service, wsgi, gunicorn, waitress, etc.) sur une seule boîte, vous perdez beaucoup de contingence de ressources.

Bien que la RAM et le CPU puissent être abondants, il y a une limite aux entrées-sorties, aux écritures sur disque, aux écritures sur le réseau, etc. Cela signifie que si, pour une raison quelconque, vous avez une fonction d'écriture lourde, tous les autres systèmes peuvent en souffrir. Cela signifie que si, pour une raison ou une autre, vous avez une fonction d'écriture importante, tous les autres systèmes peuvent en souffrir.

D'après votre question et ma propre expérience, les inconvénients de garder les choses dans un seul système sont les suivants.

• Points de défaillance multiples. Si votre seule instance de rabbit tombe en panne, vos files d'attente et vos tâches cessent de fonctionner.

• Si votre application commence à générer un trafic important, d'autres systèmes commencent à se disputer les ressources.

• Si un composant tombe en panne, cela peut entraîner l'arrêt d'autres services.

• L'arrêt du système signifie l'arrêt complet de tous les composants.

• Beaucoup de maux de tête lorsque votre application demande plus de ressources avec un temps d'arrêt minimal.

• Un trafic web important ralentira l'exécution des tâches.

• L'exécution d'un grand nombre de tâches ralentit les requêtes web.

• Beaucoup d'entrées-sorties vont ralentir toutes les choses.

La règle empirique que je suis habituellement est de garder les points de défaillance uniques éloignés les uns des autres - de cette façon, vous ne devez gérer que ces composants. Un bon cas d'utilisation pour cela serait d'utiliser une instance EC2 pour votre application, une autre pour vos travailleurs et une autre pour votre lapin. De cette façon, vous pouvez appliquer des instances plus petites ou plus grandes pour ces composants si vous en avez besoin. Vous pouvez même créer des AMI et des groupes d'autoscaling, si tel est votre cas.

Voici quelques articles de référence

• Séparation des préoccupations
• Architectures de conception modernes
• Points de défaillance uniques

Answer 2

Si nous retirons l'instance EC2 de cette question, cela devient :

Y a-t-il des inconvénients à exécuter RabbitMQ Node sur le même serveur que mon application de production ?

Je dirais que cela dépend de plusieurs choses, comme le type de charge de travail et sa composition, la complexité de la charge de travail, si vous prévoyez une croissance de l'utilisation, etc.

Si votre charge de travail se comporte bien et que le serveur est assez grand pour les deux (application + tâche q) alors pourquoi pas puisqu'il n'y aura qu'un seul serveur à gérer. Veillez à protéger ces deux processus l'un de l'autre en limitant leur utilisation des ressources système.

Si votre trafic n'est pas homogène, vous pouvez avoir besoin de plus d'un serveur. Dans ce cas, il est préférable d'avoir des serveurs dédiés (séparation des préoccupations) car vous devrez gérer plus d'un serveur.

Pour en revenir à EC2, tout ce qui précède reste valable. EC2 facilite la mise à l'échelle horizontale des applications. Si vous les placez sur des instances distinctes, vous pouvez les faire évoluer individuellement et à moindre coût. Sinon, lors de la mise à l'échelle, il y aura un gaspillage de ressources.

Answer 3

TLDR : Si vous pouvez fonctionner avec un seul EC2, vous devriez le faire, mais faites en sorte qu'il soit facile d'évoluer dès aujourd'hui.

Joshnidhin et Giannis ont tous deux couvert les aspects RAM, IO et CPU.

J'ai exécuté des applications de production dans des instances uniques avec la conteneurisation et j'ai dormi l'esprit tranquille en sachant que si, demain, beaucoup de gens veulent ce que j'ai construit, je peux évoluer assez rapidement en déployant ces conteneurs sur différentes instances au lieu d'une instance unique.

Docker vous permet de limiter la consommation de l'unité centrale et de la mémoire de chaque conteneur, ce qui vous permet d'être sûr qu'ils ne se gêneront pas les uns les autres.