Web Application Deployment in the Cloud Using Amazon Web Services From Infancy to Maturity

Transcription

1 P3 InfoTech Solutions Pvt. Ltd July 2013 Created by P3 InfoTech Solutions Pvt. Ltd., 1

2 Web Application Deployment in the Cloud Using Amazon Web Services From Infancy to Maturity 1. Introduction This case study describes three scenarios of a web application deployment in the Cloud using Amazon Web Services (AWS) starting from a basic one-server setup to an advanced setup with Auto Scaling and High Availability. These scenarios reflect the lifecycle of an application that starts with few users during its early days, then goes on to having more users, and eventually becomes business-critical. These case studies demonstrate the following key points: Application deployment on AWS is future-proof. Applications can be deployed in AWS starting with a low-cost basic setup and then incrementally add features such as Higher Performance, Scalability, and High Availability as the need arises. This is a result of the great flexibility and extensibility that AWS provides thanks to the large number of features available and the ability to choose these features on an à la carte basis. Few changes (if any) are required to the application. The addition of features to application s deployment architecture requires only few changes to the application, if any. In most cases, changes only need to be made to the application s deployment setup in AWS, without any changes to the application itself. Where there are changes required to the application, they are easy to accomplish thanks to AWS APIs which are available in all the programming languages commonly used for web development. 2. AWS Architectural Components An Amazon Elastic Compute Cloud (EC2) instance is a Virtual Machine (VM) provided by AWS. EC2 instances are the basic unit of computing in AWS and come in various CPU and memory configurations. For more information about EC2, refer Amazon Elastic Block Storage (EBS) is block storage attached to an EC2 instance. EBS has been designed for high reliability and performance. An EBS instance (referred to as an EBS volume) can only be attached to a single EC2 instance at any time. This means that every application server needs to have its own EBS volume to store the application code and data. Moreover, EBS volumes cannot be used as-is to share data among EC2 servers. For more information about EC2, refer Created by P3 InfoTech Solutions Pvt. Ltd., 2

3 Amazon Simple Storage Service (S3) is a highly reliable and durable storage provided by AWS. S3 has been designed for high reliability by maintaining multiple replicas of the data. The design point for S3 is % durability and 99.99% availability of objects over a given year. As opposed to EBS, S3 is not attached to any particular EC2 instance; rather, S3 storage is accessible from any EC2 instance and therefore can be readily used to store data shared by EC2 instances. Another key thing to note about S3 is that browsers can directly connect to files stored in S3 via a unique URL for every file; thus S3 can serve the data itself without the requirement of a separate EC2 server. These attributes make S3 a great choice for serving static content such as CSS and JavaScript files, Images, Videos, etc. For more information about S3, refer Amazon Relational Database Service (RDS) is a hosted database service provided by AWS. RDS provides standard SQL databases such as MySQL, Oracle and Microsoft SQL, but takes care of common database management tasks so that the application administrator is not burdened with them. For more information about RDS, refer Amazon Elastic Load Balancing (ELB) is a hosted load balancing service provided by AWS. ELB automatically distributes incoming load among the EC2 instances attached to the ELB. ELB has in-built detection of unhealthy instances and ensures that load is not distributed to those instances. For more information about ELB, refer Amazon CloudWatch provides monitoring for AWS resources, such as EC2, RDS and ELB. It can be used to collect and track metrics to gain visibility into resource utilization, application performance, and operational health. More importantly, since CloudWatch monitors resources in real-time, it can be used to react immediately to keep the application running smoothly. Some of the metrics that CloudWatch monitors are: CPU utilization, Memory usage, Disk IO statistics, Request latency, Request counts, and Network IO statistics. For more information about CloudWatch, refer Amazon Elastic IP Addresses are static addresses assigned to AWS resources (an EC2 or ELB). Elastic IP addresses are associated with an account and not a particular EC2 instance, allowing them to be remapped to another instance in case of an EC2/ELB failure. For more information on Elastic IP addresses, refer Auto Scaling allows application owners to scale EC2 capacity up or down automatically according to the conditions defined (based on CloudWatch metrics). Auto Scaling is a very powerful feature that can be provided only due to the elastic, on-demand and immediate properties of Cloud Computing. With Auto Scaling, EC2 instances can be increased seamlessly during demand spikes to maintain performance, and decreased Created by P3 InfoTech Solutions Pvt. Ltd., 3

4 automatically during demand lulls to minimize costs. Auto Scaling is particularly well suited for applications that experience significant variability in usage. For more information on Auto Scaling, refer Availability Zones are distinct datacenters that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. Amazon CloudFront is a content distribution network (CDN) provided by AWS. It enables fast access to static data such as photos and streaming videos by storing the data at edge locations close to users. For more information about CloudFront, refer 3. Case Study #1 Starter Plan for Small Application This scenario applies to a non-business-critical small application. The application s availability requirement ranges between 99% and 99.9% this translates to a downtime of 438 minutes to 44 minutes per month. The application itself consists of web server and possibly a separate app server, a relational database, and a bunch of static files (CSS, JavaScript, Images, etc.). The application could be hosted on either a Windows or Linux operating system Key points regarding the deployment architecture Figure 1: Architecture Diagram for Starter Setup The application is hosted on a single EC2 instance. The EC2 instance hosts both the Web server and the database server. Created by P3 InfoTech Solutions Pvt. Ltd., 4

5 The size of the EC2 instance can vary between a micro instance to large instance, depending on the performance and usage requirements. The root volume of the EC2 instance is an Elastic Block Store (EBS) volume. This is a best practice and safeguards against data loss in case of failure of the EC2 instance. The application code as well as the database files are stored on the EBS volume. Amazon S3 is used for storing and serving static content such as CSS, JavaScript, images, audio files, video files, documents, etc. The benefit of serving static files from S3 is that it offloads this work from the EC2 instance, thus reducing the load on it Changes Required to Application Compared to a non-aws deployment, the application needs to be modified in the following ways for this deployment. Awareness of S3: The application will need to be modified a little bit to be aware of S3, but only if it has any user-generated content. The user-generated files should be temporarily uploaded to the local EBS volume attached to the EC2 instance and then transferred to S3. This can be easily done with a little working knowledge of the S3 APIs. If the application does not have any user-generated content, then the move to S3 should only involve a change to URL used to server static data in the application s settings Deployment Tips 1. The AWS region used for deployment should be carefully selected. The AWS region that is closest to most of the application s users should be selected. 2. Amazon CloudWatch should be used to monitor the EC2 instance and be configured to send out notifications if something goes wrong. Notifications can be sent via or SMS (only supported in US). 3. If the application will keep running for a long duration (more than 6 months) and for several hours of a day (more than 12 hours), use a Reserved EC2 instance instead of OnDemand instance; this can greatly reduce your EC2 costs. 4. Auto Scaling can be used to further reduce downtime in case the EC2 instance fails. To achieve this, Auto Scaling should be setup with a minimum size and maximum size set to 1. With this setup, if the EC2 instance fails, the Auto Scaling feature will start a new instance from the same image. Created by P3 InfoTech Solutions Pvt. Ltd., 5

6 5. Hourly or daily backups of the EBS volume should be taken to reduce the extent of data loss if something bad happens to the EBS volume. For an even higher degree of data protection, a remote copy of this backup should be maintained on a different AWS region Benefits of using Starter plan Following are the key benefits of this deployment compared to a non-aws deployment. 1. Can be notified via CloudWatch in case something goes wrong. 2. Serving of static files is offloaded to S3, thus freeing up resources on the EC2 instance for running the application and database. 3. Flexibility: this deployment provides flexibility as a result of the many options offered by AWS. For example: As the application s performance requirement increases, it can be easily moved to a bigger EC2 instance at any time. The size of the EBS volume can be easily increased at any time. The application can be migrated to a different AWS region. 4. Future-proof: this deployment architecture can be easily extended to a more reliable deployment (e.g. the next 2 deployment scenarios) when the need arises. 4. Case Study #2 Intermediate Plan with Auto Scaling This scenario is applicable to a non-business-critical medium sized application that gets traffic load throughout the day. The traffic has highs and lows during certain periods of the day that reflect peak and low usage times for the application. The application is not business critical, and doesn t require investing in a high availability or disaster recovery solution. The application can tolerate downtime of up to a few hours per month, translating to availability requirement in the range 99% and 99.9% (438 minutes to 44 minutes per month). As in the previous scenario, the application itself consists of web server, a relational database, and a bunch of static files (CSS, JavaScript, Images, etc.). The application could be hosted on either a Windows or Linux operating system. Created by P3 InfoTech Solutions Pvt. Ltd., 6

7 4.1. Key points regarding the deployment architecture Figure 2: Architecture Diagram for Scalable Setup Dynamic scaling is achieved via AWS Auto Scaling feature. With Auto Scaling the application can be scaled automatically when demand increases or decreases. For instance, consider the following EC2 uptime data we got from one of our clients. o The application is deployed with up to 4 EC2 instances o EC2 instances #1 and #2 are always running, i.e. 100% of the time Created by P3 InfoTech Solutions Pvt. Ltd., 7

8 o EC2 instances #3 and #4 handle the additional load during peak hours or traffic burst periods. o EC2 instance #3 runs for 40% of the time o EC2 instance #4 runs for 20% of the time Elastic Load Balancer (ELB) is used to distribute incoming application traffic across the EC2 instance. A separate EC2 instance is used for the DB server which is a best practice for any but the most simplest of applications. Note: Although we have shown the database on a separate EC2 instance, this could be replaced with RDS also which is essentially an EC2 instance + database software that is managed by AWS. 5 EBS-storage volumes are used, one for each EC2 instance. Note: there are 4 EC2 instances for the application and 1 EC2 instance for the database. As with the previous case study, Amazon S3 is used for storing static content such as images, audio files etc Changes Required to Application This setup requires no further changes in the application compared to the starter plan Deployment Tips Following are some deployment tips for this plan, in addition to the deployment tips for the starter plan. 1. Auto Scaling Rules should be carefully specified taking into account the application s traffic profile and performance characteristics as well as the hosting budget. 2. The utilization of the EC2 instances that are part of the Auto Scaling Group should be reviewed. For instances that will be running most of the time, using Reserved EC2 instances instead of OnDemand instances can result in significant cost savings Benefits of Intermediate plan The intermediate plan has the following benefits over the starter plan. Created by P3 InfoTech Solutions Pvt. Ltd., 8

9 1. Higher capacity due to multiple application instances: This deployment architecture uses multiple EC2 instance to host the application, enabling the application to handle much more load than with a single instance. 2. Auto Scaling: This scenario demonstrates how the application can scale seamlessly in AWS by using the Auto Scaling feature. Dynamic scaling helps provision resources for the application to closely match the actual demand. This ensures a great experience for the users of the application, while keeping costs low. With Auto Scaling, it is possible to configure rules for when and how to scale up or scale down the number of EC2 instances used by the application. 3. Separate DB: The deployment uses a separate EC2 instance for the database. This is a deployment best practice. By having the database served out of a separate EC2 instance, the application and the database do not contend for the same resources. This provides more reliable application performance and makes it easier to any diagnose performance problems. 4. Non-disruptive software upgrades: Software upgrades can be performed in a rolling fashion, one EC2 instance at a time. While the EC2 instance is being upgraded, the other EC2 instances of the Auto Scaling group will continue to serve requests. 5. Case Study #3 Advanced Plan with High Availability for Business Critical Applications The major difference between this scenario and the previous ones is that the application is business critical and therefore cannot tolerate any downtime. The availability requirement of the application is 99.99% uptime (less than 5 minutes of downtime per month). As in the previous scenario, the application itself consists of web server, a relational database, and a bunch of static files (CSS, JavaScript, Images, etc.). The application could be hosted on either a Windows or Linux operating system. Created by P3 InfoTech Solutions Pvt. Ltd., 9

10 5.1. Key points regarding the deployment architecture Figure 3: Architecture Diagram for Scalable + Highly Available Setup This deployment adds high availability to the application. High availability means that there is no single point of failure. If any single component in the setup fails, the application will continue to be operational (though, with a slightly reduced performance). This setup uses two AWS availability zones. The setup of the advanced plan replicates the intermediate plan setup in 2 availability zones. By launching instances in two availability zones, the application is protected from failures within a single availability zone. Even if one entire availability zone fails, the application will still be able to operate from the other availability zone. High-availability for database using a replicated master-slave setup. Data is synchronously replicated from the master to the slave to ensure there is no loss of data when the master fails. When the master database fails, the slave will be Created by P3 InfoTech Solutions Pvt. Ltd., 10

11 promoted as the master and will start serving both read and write requests. The master-slave setup provides 2 benefits: 1. High-availability for the database 2. Better read performance for the database since reads can be served from both the master and the slave ELB is a highly available service by design; hence only one ELB is required. Amazon CloudFront is used to cache static data on edge locations near to the users. User requests for static content are automatically served from the CloudFront edge location nearest to the user. This helps improve the application experience for the users as the data gets downloaded faster on the users computers Changes Required in Application Design Awareness about Database Master-Slave Architecture (optional): To make best use of this architecture, the application needs to be aware of the Master-Slave setup of the database. This is an optional enhancement for the application that results in better database performance; however, this configuration can also be used without this enhancement. One of the DB instances acts as the master and the other as a slave. All application servers must write data only to the master. The application servers in availability zone 2 (the one with the slave DB server) should send read requests to the slave DB server. This reduces the load on the Master DB Server by distributing the reads between the Master and the Slave servers, resulting in better database performance and greater scalability Deployment Tips Following are some deployment tips for this plan, in addition to the deployment tips for the intermediate plan. 1. We recommend using RDS for the database, as it provides a simple way to use a replicated multi-availability zone setup. 2. For a predictable, balanced, and reliable setup, the Auto Scaling configurations should be identical in the two availability zones. This configuration includes things such as: size of the EC2 instances, size of EBS volumes, and Auto Scaling rules. Created by P3 InfoTech Solutions Pvt. Ltd., 11

12 5.4. Benefits over Intermediate Plan High Availability: In this configuration, there is no single point of failure enabling the application can withstand the failure of any single component. This significantly increases the availability of the application. Increased Database Capacity and Performance: Distributing database reads among two instances doubles the database read capacity. Faster load times for static files: Use of Amazon CloudFront for serving static files results in faster load times as the data is served from a server closer to the user. This leads to a better user experience for the users. 6. Summary In this case study, we have described 3 architectures for deploying applications in AWS: starter plan, intermediate plan, and advanced plan. We started with the starter plan which consists of a single EC2 instance and is suitable for small applications non business-critical for business. Then, we moved to the intermediate plan which is suitable for medium or large sized applications non business-critical for business. The intermediate plan introduced the use of Auto Scaling group for elastically scaling the application capacity. Finally, we discussed the advanced plan that is meant for business-critical applications that need to be highly available. While discussing these case studies, we made use of several AWS features: EC2, EBS, RDS, Elastic IP, S3, CloudFront, CloudWatch, EBS Snapshots, Auto Scaling, and Availability Zones. One of the best things about using AWS is that it provides a large set of services, which can be used à la carte. This allows an application to start with a basic deployment such as the starter plan with only a basic set of services. As the application s use grows and its deployment requirements become more demanding for performance and availability, the deployment architecture can be easily scaled up and other AWS services can be incorporated to provide enterprise grade performance and availability. All this without any up-front investments and paying only for the resources you use. About P3 InfoTech Solutions Pvt. Ltd. P3 InfoTech Solutions Pvt. Ltd. helps organizations achieve business breakthroughs by adopting Cloud Computing through our Outsourced Product Development and Cloud Consulting service offerings. Discover our passion for Cloud Computing and Web Applications at Created by P3 InfoTech Solutions Pvt. Ltd., 12