Aws cloud or any other cloud provides feature to autoscale your web application to meet the traffic needs. In this blog post we will explain what are the bottlenecks in Autoscaling web applications and how you can ready your web app for autoscaling. AWS provides a broad range of services which can be utilized to architect your web applications and making them ready for autoscaling. AWS Provides services like autoscale configuration, autoscale groups, elb, alb, route 53 etc to setup load balanced autoscaled environment.

What is autoscaling?

Autoscaling means throwing new instances on runtime on the basis of certain parameters or matrix like cpu consumption, network traffic etc. In a autoscalable environment load balancer receives user request and forwards them to web servers on ec2 instances, then ec2 instances respond back through load balancer to user. We need to set autoscale groups to leverage feature of autoscaling, We can setup rules so that if any particular rule is breached then automatedly new instances will be created and gets attached to load balancer and when consumption on a parameter we set for scaling gets reduced then additional instances can be terminated automatedly.

Bottlenecks in autoscaling or readying your webapp for autoscaling:

Indeed it is a good practice to first assess the application before putting app on autoscaling. Is the application ready for autoscaling or not. But what are the factors through which you can determine the app is ready for scaling or not. We are listing here few factors, knowing them will help you in assessing web app for autoscaling alongwith solutions to overcome those bottlenecks.

1. Sessions

Often sessions gets created on file system or stored in database. If they are stored on file system then they are tied to webserver and may create bottleneck in scaling. These are called sticky session. Lets take an example of ecommerce which is on autoscalable environment and operating on parallel 2 EC2 instances site. Now lets say a user logs in a site and his session is tied up with first EC2 instance and assume this first instance is already operating in its full capacity, now the next request from the same user or any other users whose session is tied to that instance will suffer, it might timeout or increase latency. For leveraging autoscaling to its fullest it is much better to offload session so that it is not tied to a aprticular EC2 instance and can be managed in a central environment where in if a user fires a next request that request can be served from second instance. It is considered a best practice to offload session, you can utilize redis, or memcached clusters or aws elasticache service to offload sessions, aws dynamodb can also be utilized to offload sessions. However you can also store session to database server, but it is generally a bad practice as read and write operations on db are very costly and you should save them for a better usage.

2. Image or document Uploads

If application has any image or document upload functionality, then those images or documents needs to be stored centrally so that they can be available on all instances. If we keep upload functionality tied up to webserver only then upload on one server will not be available on other and incase of instance termination they will be lost as well. As a best practice the uploads should go to a central place. We can utilize aws s3 service to upload image or documents, even we can utilize aws efs service as well.

3. Application logs

If you write logs through application like error logs or any other functionality logs then it needs to be offloaded to a central location so that it can be made available for read/write on all ec2 instances. If we keep log on webserver itself then a new write on log at one server will not be available on other, and incase of scale down instances might be deleted as well resulting in loss of logs. As a best practice logs to be centrally stored on a log server. We can utilize AWS S3 service to store logs, even we can utilize aws efs service as well.

4. Database Server

We cannot keep database along with webserver in a autoscalable environment as the inserts and updates on one c2 instance may not be available on another ec2 instance, database entries or records may be missed or not available at all places. So as a best practice database server should be offloaded on a standalone server of its own. You can utilize aws managed service like rds as well to host databases like mysql, postgres, oracle, mssql.

The post Bottlenecks in Autoscaling Web Applications appeared first on WebNLinux.