Most of the applications on Internet require high availability and scaling due to dynamic business needs. All of us want to make sure our customers or users don’t get impacted, our systems can easily handle spike in load and recover from or isolate a failure to run our service/application smoothly without significant business risk.
Amazon ELB is very useful solution for applications that requires high availability and scalability; it provides out of the box load balancing solutions if you are using Amazon EC2 as computing infrastructure. I will outline the pros of Amazon ELB and why it makes sense to use it instead of creating a HAProxy or nginx or home-grown load-balancer solution.
A good load balancer design should consider scaling at network level and application level. While we can horizontally partition the load to multiple machines so our application can scale and handle more users/requests/load, our load balancer also should be able to do that at network level as a single load balancer will have limited network bandwidth so essentially you need a pool of load balancers for your applications for a true elastic scaling, this is one of the significant benefits of using Amazon ELB.
Here is the step-by-step flow of what happens when a client requests a URL served by your application while using Amazon ELB.
- When user hits your web server’s name like http://www.sample.com from browser, the client looks in DNS for the resolution of domain name. Because we have set up DNS to have a CNAME alias pointing http://www.sample.com to the ELB name myelb1234.us-east-1.elb.amazonaws.com, your DNS responds with the name myelb1234.us-east-1.elb.amazonaws.com.
- The client then looks in DNS for the resolution of myelb1234.us-east-1.elb.amazonaws.com. This DNS entry is controlled by Amazon and their DNS server will return an IP address like 113.22.43.68 based on the ELB IP pool.
- Now the client opens a connection with the machine at the provided IP address 113.22.43.68. The machine at this address is the actual ELB service.
- The ELB service at address 113.22.43.68 passes through the communications from the client to one of our application EC2 instances in the load balancing pool. At this point the client is communicating with one of our EC2 application instances.
So we have ELB level load balancing in step 2 and application level load balancing at step 4 for the true elasticity.
Fig 1: Amazon ELB Architecture (image credit)
The primary reason why ELB doesn’t use fixed IP address and how it scales?
1. Amazon ELB doesn’t use (elastic) fixed ip address instead uses a pool of ip address because ELB is also auto load balanced by Amazon for true elasticity – this is the reason why we use CNAME while mapping the domain name to ELB instead of single IP address.
2. Even though ELB uses pool of ip address, initially it might have only one IP address or rather use one IP address if all EC2 instances attached to the ELB are in the same availability zone unless there is a very heavy network traffic for your application (because the load balance & scaling needs to happen at network level also as a single network connection will have limited bandwidth capacity). If you launch your EC2 instances in multiple availability zones then it will use different IP addresses for each zone and increase it based on the load. Also Amazon need not use the same IP addresses for the ELB in long term as per their documentation it might change from time to time.
Some of the important items related to ELB behavior
1. If an ELB can’t process a request (e.g. no healthy instances behind it) it will return 50x’s (503 in the case of no healthy instances). You need to have a good monitoring that will alert in case of failures by your application servers.
2. Adding new instances to the ELB will take couple of minutes and it’s not yet JIT.
3. You need to manage the security groups at ELB level and EC2 instance level. Also if your application needs to find the original ip address of the client requests then you need to use x-forwarded-for header and use HTTP as a protocol between ELB and your EC2 machines port forwarding. If you use TCP as protocol then your application will see ELB private ip address as client address.
4. Have a good DNS solution (Route 53?, UltraDNS, DNSMadeEasy or DynDNS) if you are using ELB as it resolves to multiple IP address so set your TTL to 60 seconds or so and you don’t want your users to be impacted when a new IP address gets added to your ELB pool.
It’s easy to get started with ELB setup for scaling your apps in AWS.
Let us know your experience.
[This guest post is written by Vijay Rayapati. Vijay works as CTO at Kuliza – a Bangalore based social technology firm. You can read more of his posts on the Kuliza blog]
