Running RabbitMQ+Celery in the same server as production environment

Question

I'm running a Django app in an EC2 instance, which uses RabbitMQ + Celery for task queuing. Are there any drawbacks to running my RabbitMQ node from the same EC2 instance as my production app?

Answer 1

The answer to this questions really depends on the context of your application.

When you're faced with scenarios you should always consider a few things.

Seperation of concerns Here, we want to make sure that if one of the systems are not responsible for the running of other systems. This includes things like

• If the ec2 instance running all the stuff goes down, will the remaining tasks in queue continue running

• if my RAM is full, will all systems remain functioning

• Can I scale just one segment of my app without having to redesign infrastructure.

By having rabbit and django (with some kind of service, wsgi, gunicorn, waitress etc) all on one box, you loose a lot of resource contingency.

Although RAM and CPU may be abundant, there is a limit to IO, disk writes, network writes etc. This means that if for some reason you have a heavy write function, all other systems may suffer as a result. If you have a heavy write to RAM funciton, the same applies.

So really the downfalls from keeping things in one system that I can see from your question and my own experience are as follows.

• Multiple points of failure. If your one instance of rabbit fails, your queues and tasks stop working.

• If your app starts generating big traffic, other systems start to contend for recourses.

• If any component goes down, that could mean other downtime of other services.

• System downtime means complete downtime of all components.

• Lots of headaches when your application demands more resources with minimal downtime.

• Lots of web traffic will slow down task running

• Lots of task running will slow down web requests

• Lots of IO will slow down all the things

The rule of thumb that I usually follow is keep single points of failures far from each other - that way you only need to manage those components. A good use case for this would be to use an EC2 instance for your app, another for your workers and another for your rabbit. That way you can apply smaller/bigger instances for just those components if you need to. You can even create AMIs and create autoscaling groups - if it is your use case.

Here are some articles for reference

• Seperation of concern
• Modern design architectures
• Single points of failure

Answer 2

If we take EC2 instance out of this question it becomes:

Are there any drawbacks in running RabbitMQ Node on the same server as my productions app?

I would say it depends on various things like, kind of workloads and its composition, complexity of the workload, do you expect growth in usage etc.

If your workload is well behaved and the server is big enough for both (app + task q) then why not as there will be only one server to manage. Make sure to protect these 2 process from each other by limiting their system resource usage.

If your traffic is not well behaved then you might want more the one server. In this case having dedicated servers is better (separation of concerns) as you will have to manage more than one server.

Now back to EC2, all the above still apply. EC2 makes horizontal scaling of applications easier so if you have them on separate instance then you can scale them individually and cost effectively. If not when you scale there will be wastage of resources.