RSS
 

Simple, Secure and Speedy – Part Two

05 Jul

Amazon’s EC2 (Elastic Compute Cloud) enables an user to deploy a fully customized Linux or Windows server in the Amazon cloud. Beyond the security provided by the built-in (Windows or Linux) firewall, EC2 provides another layer of firewall called a security group.

A security group may be configured to filter IP traffic – to allow access to only certain ports from certain Internet address ranges. IP traffic that does not pass the filter rules will never even touch the server. All servers running in a security group assume the same filter rules.

Furthermore, a security group may be configured to allow access only from another security group. Thus enabling very secure multi-tier deployments in Amazon’s EC2.

private tier in Amazon's EC2

Above circles represent the various security groups. One security group is configured as a DMZ and allows HTTP traffic from the Internet to come to the proxy server. The private security group only allows traffic from the DMZ security group, thus no Internet traffic can directly contact the private servers.

simple three tier in Amazon's EC2

Security group access can be chained. The example above shows how a three tier deployment can be achieved with security groups. In such a setup the middle tier is effectively your application server – even though this could be a simple PHP application. That is to say that any claimed security benefits of three tier deployments have been achieved.

Consider again the same configuration suggested in the previous post: Nginx for the reverse proxy and lighthttpd with PHP for the web server.

OK, so this is certainly simpler than a complex multi-tier solution say from Java. And it has the same effective security. But what about speed and scalability? Well ultimately the determining factor will be the database tier, which is why you’ll see mention of Cassandra and other cloud databases throughout this blog. But keeping the MySQL theme for simplicity sake, the other most performance vulnerable tier is the middle one.

Even with FPM, APC, and memcache (caching accelerators, etc.) it is entirely possible that the middle tier will overload before either the DMZ tier or the database tier. One reason is the threading model used – a topic I will devote a couple of posts to in the near future.

To achieve higher throughput, and higher availability, from the middle tier we need to add more servers to that tier. Each sever in that tier should be an exact clone – the same lighttpd with PHP configuration and the same application files/scripts.

The Nginx configuration will need to change by adding an upstream configuration.

    upstream backend  {
         server http://[private server 1 address]:8000;
         server http://[private server 2 address]:8000;
         server http://[private server 3 address]:8000;
     }

     server {
       listen   80;
       server_name  localhost;

        location / {
             proxy_pass        http://backend;
        }
     }

That’s all it takes, you now have a load balanced application tier. Naturally the same concepts above can be applied to an on-premises deployment as well, this is nothing unique to cloud computing.

The DMZ tier may be load balanced also, although this is far less likely to be a performance bottle neck because of the extremely efficient design of Nginx. However, for the sake of high availability – and for the long term goal of expanding this architecture – let’s consider the load balanced DMZ tier also.

To achieve this clone the Nginx settings – pointing to the same backend as the first. Then set the load balancer “hardware” to point to these two Nginx servers. Amazon’s EC2 provides a virtual load balancer which appears to be hardware to the network. On premises you’ll probably be using a true hardware load balancer.

So we have achieved the security and scalability of an advanced web application framework. However, we did it using simply PHP application code – indeed with very few exceptions the PHP coder does not have to do anything special to scale to these levels.

The remaining thorn is what to do about the database tier. There are ways to scale that tier but there are problems too. More to come on that subject.

About Andy White

Author of 32 articles on this blog.

For nearly twenty years I have enjoyed and studied post relational (aka nosql) databases. I also study application framework architectures and do a fair bit of web development. For more information view my profile on LinkedIn.

Published on Monday July 05, 2010 at 10:49am

 

Tags:

Comments are closed.