mardi 28 juillet 2015

System Architecture to deploy a Django Application with PostgreSQL, nginx and gunicorn on Amazon AWS

I gratefully appreciate if someone could help us with the following problem.

We are in the final stages of development and about to deploy our web application on Amazon AWS. The software stack that we are using is very similar to the one Instagram is using (http://ift.tt/1yhd0nS). That includes Django, PostgreSQL, nginx, gunicorn, etc.

My question is about the system architecture. We have done an extensive amount of research over the last few weeks and short-listed the following three system architectures. But we are not sure which of the following is the best one to use, as it seems different companies are using different approaches (http://ift.tt/1HYp3cg). I will briefly describe our findings here as it might be useful for others to refer to in future:

  1. One school of thought is to separate the “Web Tier” (Web Servers) from the “App Tier” (App Servers) and use a “Load Balancer” (eg. Amazon Elastic Load Balancer (ELB), HAProxy, etc) before each layer as it is shown in the following figure:

    enter image description here

This architecture seems to be the mainstream architecture proposed by Amazon AWS support team. The following pictures are taken from this white paper “Web Application Hosting: Best Practices” ( http://ift.tt/1QZrN0r ) and this system architecture ( http://ift.tt/1sAAfUg ). They all show the same system architecture as described above.

enter image description here enter image description here enter image description here

As described in the aforementioned “white paper”, access to the “App Layer” is only permitted to the “Web Layer” and access to the “DB Layer” is only permitted to the “App Layer” in this system architecture which is probably better from the security point of view.

  1. Another approach is to separate the “Web Tier” from the “App Tier” but use the “Web Servers” (in our case, nginx) as load balancer as illustrated in the following figure. Based on the explanation that Instagram provided (3 nginx servers behind ELB and 20+ app servers in front of nginx servers), it seems like they are using this architecture. This way there is no need for an additional “load balancer” before the “App Tier”.

enter image description here

Also in this white paper “NGINX Plus on Amazon AWS” (http://ift.tt/1Qm6tyw), the author is proposing this architecture.

enter image description here

As described in the aforementioned white paper, one of the benefits of this system architecture is to split “App Servers” into different “availability zones” and allocate a web server for each zone (Shown in the following figure).

enter image description here 3. The last and probably the simplest approach is to combine “Web Tier” and “App Tier” into one, and run “web servers” (nginx) and “app servers” (gunicorn) on the same machine, and put a “load balancer” (eg. ELB, HAProxy) behind them. Appknox seems to be using this architecture based on the information provided in this link: http://ift.tt/1Hsk7cS . Also it is not clear whether Pinterest is using this approach or not (http://ift.tt/JKSlAz).

enter image description here

Here are my questions:

a. Which of the aforementioned system architectures are better in terms of “Scalability”, “security”, “maintainability”, etc and why? In other words, while the third approach (running nginx and gunicorn on the same machines behind a load balancer) seems to be simpler to implement and easier to maintain, why would one choose the first or second approach? What are the benefits offered by the first and second approaches?

b. If one chooses to use the first or second architecture and have “web servers” and “app servers” on different machines, does that make tasks such as “session management”, “cookies”, etc more complicated or that is not as issue?

There was also a similar question about this topic (http://ift.tt/1Sc1nJo) but the responses are not sufficient enough.

Your help is gratefully appreciated. Thanks in advance




Aucun commentaire:

Enregistrer un commentaire