Smartym Pro  /  Blog  /  Technology  / 
web
04
October

Software project development: how to scale your application with Amazon Web Services

 
During software project development, engineers have to solve various challenges: what tools and technologies should they choose, how to ensure application security, what functionality the app must have to perform certain features, and a lot more.

Having worked with a plenty of customers, we can say that one of the most common and important requirements is making the system scalable. In this post, we’ll see how to scale the project up to millions of users with Amazon Web Services (AWS). So, let’s start.

 

Amazon Web Services

 

AWS is a secure cloud services platform that provides a wide range of infrastructure services like cloud computing, access to database and data storages, content delivery, and other functional capabilities, that help app development teams to successfully scale their applications.

When using cloud computing you receive a lower cost comparing to in-house calculations. Since thousands of customers consume resources in the cloud together, Amazon Web Services can achieve high economies of scale. This helps companies save costs for using resources.

Here at Smartym, we use AWS platform as it provides a set of great tools for developing complex, reliable, and high-load systems.

 

Scaling the project: Scenarios

 

1 User

 
The simplest scenario for a website, where you need only one user (you). To build the architecture you should run on a single database, for example, a type t2.micro.

The types of instances include various combinations of CPU, storage, memory, and networking capacity, providing app development teams with the flexibility to choose the optimal resources’ combination.

With a single instance, you will be able to run the entire web stack, including (for instance) a web application, database, management, and so on.

Then, for the Domain Name System (DNS) it’s better to use Amazon Route 53, a highly available and scalable cloud-based web service for the DNS.

The Amazon Route 53 service is used to connect only to “healthy” addresses  (using DNS checks) and to independently monitor the status of the application and its endpoints.

 

>10 Users; >100 Users

 
Use one host for the future website. Separate out a single host into multiple ones as the use of the separate hosts will enable both website and database to be scaled and failed independently of each other.

Also, use one host for the database. Start with a SQL database and move to NoSQL only if necessary. You should start with NoSQL in the following cases:
 

  • You have a super intensive data workload.
  • You don’t have any relational data.
  • The project requires a high throughput.
  • The requirements for your future application are very low-latency.
  • The system requires storing > 5 TB of data in the first year.

 
It’s pretty simple to scale the system to over 100 users during software project development. Use a separate host for the web tier and store the database on the Amazon Relational Database Service (Amazon RDS).

Amazon AWS represents a web service that facilities the processes of setting up, operating, and scaling a relational database in the cloud. Also, Amazon RDS allows managing common database administration tasks.

Then, by using AWS you can instantly receive a multi-AZ database setup. There won’t be any anxiety related to the replication. Your database will have a high-availability level.

 

>1000 Users; >10,000 Users

 
If the host for the web service fails, the website also goes down. Thus, you need another web instance in another AZ, where the latency between the availability zones is in the low single-digit milliseconds.

An important thing you should make is to slave database to Relational Database Service (RDS) running in another availability zone. If there are some issues with the master, the app will automatically switch over to the slave. Since the app applies the same endpoint, there won’t be changes necessary on the failover.

Apply Elastic Load Balancing (ELB), a highly available managed load balancer, provided by AWS and existing in all availability zones.

ELB is used for the distribution of incoming traffic across several targeted objects, including EC2 instances, containers, and IP-addresses in multiple AZs.

ELB scales your load balancer as incoming traffic changes over time and automatically scales to the large majority of workloads. What’s important, Elastic Load Balancing has health checks ensuring that traffic won’t flow to failed hosts and health monitoring of the registered instances.

Also, Elastic Load Balancing offers three types of load balancers – Application Load Balancer, Network Load Balancer, and Classic Load Balancer – that provide high availability, auto scaling and reliable protection required to ensure application resiliency.

To scale the project to >10,000 users, add more read replicas to the database. Move all static content that may include JavaScript, CSS, images, files, and videos, to Amazon S3, an object base store. It should be noted that this type of content doesn’t require to sit on an Amazon EC2 instance.

Amazon CloudFront is the Amazon’s CDN that allows storing and caching data in the 53 edge locations across the world to provide app users with the lowest latency access to the content.

Use Amazon DynamoDB as it supports quick performance, exists in multiple AZs, and with it you get the ability to dynamically adjust the dedicated bandwidth according to the actual amount of traffic.

For scaling the project app development teams also use Auto Scaling, since it enables to match compute power with demand, manage loads, and work of services (we’ll consider Auto Scaling in details a bit later).

 

> 500,000 Users; > 1,000,000 Users

 
Use Auto Scaling to effectively manage instances and dynamically scale Amazon EC2 resources. Keep in mind that the auto scaling group involves two availability zones, but can extend to three AZs if needed.

Then, to offload session data app development teams use Amazon DynamoDB, and to apply ElastiCache in order to offload popular reads from the database.

Also, aggregate level metrics and make log analysis. To complete the first task look at the metrics on the Elastic Load Balancer to get feel for performance of the entire set of instances. Use CloudTrail enabling to analyze and manage logs.

To understand what should be changed/improved use a New Relic service (or something like that) that will help find out what customers see as end users.

Don’t try to invent something new and complex as Amazon Web Services provide a plenty of services that inherently fault tolerant as they cover a lot of availability zones. They include queuing, email, databases, monitoring, metrics, logging, transcoding, search, and more.

For example, queuing allows passing messages between various app infrastructure components. Use an SQS queueing service: it performs this task well and enables to cover multiple AZs. Also, it’s scalable, reliable, and easy-to-use.

To decouple applications, app development team generally apply AWS Lambda, which also runs code without servers’ provisioning or management.

For managing all instances make some automation, it will help you scale the system to thousands of instances. To automatically manage the app infrastructure use AWS Elastic Beanstalk. Apply AWS CodeDeploy for deployment of the application code to a fleet of EC2 instances.

To scale the system to >1,000,000 users, ensure multi-AZ, use Auto Scaling, and build Service Oriented Architecture. Then, put caching in front of the database, move the state off the web tier, and use Amazon SES for email sending.

 

Auto Scaling

 
Auto Scaling enables developers to provide application high availability level and dynamically scale Amazon EC2 resources depending on your needs and defined conditions.

With their dynamic scaling, you also get the ability to automatically increase the number of Amazon EC2 instances during peak loads. It allows to maintain performance, handle traffic increases, reduce the amount of resources, and thus cut expenses.

Software engineers also use Auto Scaling for managing Amazon EC2 group of instances as it helps maintain group access and ensure that only the required number of instances is used.

It doesn’t matter how many Amazon EC2 instances you use. By using the Auto Scaling you can identify both Amazon EC2 unstable instances and malfunctioning applications. This feature will enable you to replace instances without any intervention and applications – to constantly receive the necessary computing resources.
 

Auto Scaling advantages and opportunities:
 

  • Auto Scaling allows matching compute power with demand.
  • During the times of low loads, Auto Scaling helps companies reduce electricity costs by making some servers sleep.
  • Auto Scaling suits well for either applications with stable load schemes or applications, which level of use is constantly changing.
  • Auto Scaling enables efficient instance management: when a damaged instance doesn’t pass performance tests, Auto Scaling automatically replaces it with a new one, removing the necessity of manual intervention.
  • By using Auto Scaling you ensure that the application can successfully process traffic and that the instances themselves work correctly.

 
Hope, the article has been useful to you. Keep in mind these steps and tips and follow them during software project development, and scale your application to millions of users.

Post Tags: