It's been on the cards for a while, but now that Amazon have released Elastic Load balancing (ELB), what are your thoughts on deploying this solution for a high-traffic web application?
Should we replace HAProxy or consider ELB as a complimentary service in front of HAProxy?
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 gotcha though (UPDATE, this issue has been fixed by Amazon AWS, see comments below):
http://mysite.com
to http://www.mysite.com
.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).
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With