• Deplay a web application in a two-tier architecture for scalability
• Use virtual machine images to clone a web application onto additional virtual machine instances
• Use a load balancer that is provided as cloud service
• Performance-test a load-balanced web application

In this lab you will perform a number of tasks and document your progress in a lab report. Each task specifies one or more deliverables to be produced. Collect all the deliverables in your lab report. Give the lab report a structure that mimics the structure of this document.

You should have from the previous lab a micro instance running Ubuntu Server 14.04 LTS with Drupal7 installed. In the following we will refer to it as the Drupal master instance.

You will improve the Drupal site to make it scalable. Your site will be able to absorb traffic increases by adding virtual machines that process requests in parallel. Following a two-tier architecture the business logic and presentation layer will be separated from the database layer so that the former can be replicated in multiple virtual machines. The database moves into Amazon's Relational Database Service (RDS) which provides automatic backup, data replication and failover.

Note: Not all deliverables get you the same number of points. Deliverables that only verify that you performed some instructions get fewer points, deliverables that ask questions that test your understanding and require thinking get more points.

Endpoint Address: david-drupal.ciuq8ad2qsbu.eu-central-1.rds.amazonaws.com

RDS Cost Comparison

With the RDS service: 15.33 $ per month With the EC2 instance: 10.85 $ per month

We can see that it is cheaper to run an EC2 instance than the RDS service. This difference exists because with the RDS service the customer has no need to performe maintenance on its database. Everything is managed by the Amazon team. The customer just have to instantiate it and use it. On the other hand, if the customer choose to use an EC2 instance to exploits its database, he will have to manage it himself.

Why use RDS service ?

By using the RDS service, the IT team of the company won't have to manage the database. All the maintenance will be done by the Amazon team which will spare some work for the company's IT team.

Why use EC2 instance ?

By using an EC2 instance, the IT team will have the full control on the whole database's componants. This could be interesting if the IT team has to create a specific environnement to manage its database. Howewer, the team will have to manage its instance and performe all the maintenance tasks by themselves.

$dbs['mysql'] = array(
  'driver' => 'mysql',
  'database' => 'drupal7',
  'username' => 'drupal7',
  'password' => 'SXFYnsGQXmsr',
  'host' => 'david-drupal.ciuq8ad2qsbu.eu-central-1.rds.amazonaws.com',
  'port' => '3306',
  'prefix' => ''
);
 
// Other driver config ...
 
$databases['default']['default'] = $dbs['mysql'];

Load Balancer DNS: David-Drupal-2050734920.eu-central-1.elb.amazonaws.com

Load Balancer IPs: 52.29.19.144, 35.157.175.254

172.31.24.195 - - [06/Mar/2017:13:28:45 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"
172.31.14.9 - - [06/Mar/2017:13:28:45 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"
172.31.24.195 - - [06/Mar/2017:13:28:55 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"
172.31.14.9 - - [06/Mar/2017:13:28:55 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"
172.31.24.195 - - [06/Mar/2017:13:29:05 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"
172.31.14.9 - - [06/Mar/2017:13:29:05 +0000] "GET /index.html HTTP/1.1" 200 11632 "-" "ELB-HealthChecker/1.0"

System components diagram

System's monthly cost

The test was performed by using jMeter to create a constant load on the server of 50 concurrent threads sending requests as fast as possible during 15-20 minutes. Unfortunately we were unable to collect results from jMeter as it ran out of memory too fast for a test of more than 2-3 minutes. The test ran from around 13:50 to 14:10. Due to AWS account restrictions, the web instances had to be scaled down to t2.micro as higher tier instances are unavailable at the moment.

Observations

From the load balancer's graph (below), we can see that latency is stable at around 100ms during the entirety of the test and that the “Sum Requests” and “Sum HTTP 2xx” graphs match meaning that all requests were answered successfully for the duration of the test.

From the server graph (below), we can see that both instance's CPU and network graph follow similar curves for the duration of the test, indicating that the load balancers balanced charge equally between both instances which is consistent with advertised behaviour.

Furthermore, we can see that the database instance's graph follows a similar pattern to the web instances.

From our current results, we can estimate that the current infrastructure can handle an average peak load of 500 requests per seconds for a short period of time (estimated 30 to 40 minutes) after which the instances will have exhausted their CPU credits and will drastically lower their performances.

Is this test really effective ?

Yes, this test allows to gauge the setup's ability to handle a continuous load on a single page, which is useful to test the site's performance under “peak” load such as an important event.

For a more thourough test, it would be better to monitor load across multiple pages using a “smart” crawler which would maintain sessions and attempt to replicate user behaviours.