views:

3866

answers:

6

Hi

Its been on the cards for a while, but now that Amazon have released Elastic Load balancing what are your thoughts on deploying this solution for a high-traffic web app.

Should we replace HAProxy or consider ELB as a complimentary service in front of HAProxy

Appreciate any comments or suggestions

Thanks

Dom

+5  A: 

I've been running an ELB instead of HAProxy for about a month now on a site that gets about 100,000 visits per day and I've been pretty pleased with the results.

A couple of gotchas though:

  1. You can't load balance the root of a domain as you have to create a CNAME alias to your load balancer. Once solution is to redirect all traffic from http://mysite.com to http://www.mysite.com

  2. ELBs don't have SSL termination capability so if you need SSL to your application you'll need to run your load-balanced webserver on an alternative port (I use 8443).

Apart from that I really can't speak highly enough of the AWS ELB offerings. I'm also using the Cloudwatch monitoring and autoscaling. Oh and don't forget it's cheaper than running a small EC2 instance ($0.025 per hour instead of $0.10)

Cheers Arfon

arfon
+3  A: 

There are complaints in the Amazon forum about ELB's reliability. I suggest you head over there and search on ELB to form your own opinion on that front.

We wanted to use ELB to load balance web service requests, but we have many external callers, some of which send a 100-Continue HTTP message. Unfortunately ELB does not understand that part of the HTTP protocol, so we're unable to go beyond proof-of-concept until that's addressed.

Eric J.
+7  A: 

ELB's dependence on DNS CNAME record indirection is pretty crippling for web services that need to be very fast. In our case we need to have very good response time. In a quick performance test, the use of an ELB increased the average latency for HTTP requests by a factor of almost 2. This is mainly because the TTL on the CNAME lookup is zero. Thus, all lookups involve hitting name servers for two different domains, so the name resolution is way slower. (I worry that defeating caching in DNS is simply an abuse of the system.) The only hope for ELB in our case would be to get away from CNAME records by having Amazon support an Elastic IP as the address of a load balancer instance.

Burt
A: 

Hi there,

this answer is a bit late but hasn't been mentioned in the previous answers:

One main problem for many users with ELB is that it does not support stickyness, which is a killer for many webapps.

According to AWS devs it should come however in the next release.

Cheers

Hi JeffWhat do you mean by stickyness. ?
Dom
Sticky sessions (so that a request from a client always routes to the same server, most commonly implemented with cookies)
if you are not able to store your session data in a common storage, you should probably should be using an LB. you won't really be balancing any loads :-P how about instead, doing the old www1,www2,www3,etc subdomain game if you need that functionality.
Zac Bowling
Sticky sessions are a terrible idea and should never be used
Peter Sankauskas
Sticky sessions are supported in ELB as of today! http://aws.amazon.com/about-aws/whats-new/2010/04/08/support-for-session-stickiness-in-elastic-load-balancing/
Kaitsu
+8  A: 

Another issue is getting the client IP address. For regular HTTP this works fine, as ELB sets the X-FORWARDED-FOR header. But for HTTPS this isn't possible because it is forwarding at the TCP layer. Hopefully some day ELB will have SSL termination.

And now it does!
crb