Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Application Load Balancer

aws.amazon.com

Post reply on HN
Print view View original

111–120 of 140 posts

Re: AWS Application Load Balancer

#111

Post by vacri »

jamiesonbecker wrote: post #101
SideburnsOfDoom wrote: post #94

Earlier quoted context omitted.

250 rps in absolute terms is not enormous; and peaks of 25 times relative to base load is not unheard of. What I think you are indicating is that you have a very unusual thing that ELB is not set up to handle: you go from base to peak load in seconds flat. Or even less? That's interesting and quite unlike the very common model of human visitors to a website ramping up, that ELB is likely designed around.

I'm still addicted to AWS, but Google hit 1M rps with only a seven minute scale time according to their blog way back in 2013. https://cloudplatform.googleblog.com/2013/11/compute-engine-... My biggest issue with ELB is how long it takes for the initial instances to get added to a new ELB.. it takes f-o-r-v-e-r... I've seen it take as long as fifteen minutes, even with no load. I'm hoping ALB fixes that.

Re: adding to ELB, I haven't had that experience - for me it's been pretty reliably in line with the healthcheck config (2 healthchecks x 30 sec apart = 60ish seconds to add). Or are you including instance spin-up time in that number?

Re: AWS Application Load Balancer

#112

Post by imperalix »

pgib wrote: post #55
pat2man wrote: post #23

Earlier quoted context omitted.

Like via SNI? No mention of it and the screenshots make it seem unlikely.

The Amazon Certificate Manager uses SNI, and you can request certificates with multiple hosts and even wildcard domains. I would imagine if you upload your own multi-domain certificate that it would work in the same way, but I have never tested that.

I think you mean SAN instead of SNI. SNI is like host headers for TLS connections, while SAN on certs allow you have to very valid for multiple names.

Re: AWS Application Load Balancer

#113

Post by user5994461 »

encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

Please don't say "huge" when talking about your traffic. That is misleading.

The appropriate word to describe 8 requests/s is "nothing". Health checks and monitoring could do that much by themselves when there are no users. 200 requests/s is a very small site.

To give you some point of comparison: 200 HTTP requests/s could be processed by a software load balancer (usual pick: HAProxy) on a t2.nano and it wouldn't break a sweat, ever. It might need a micro if it's HTTPS :D (that's likely to be generous).

To be fair, I hardly expect any performance issues from the load balancer before 1000 requests/s. The load is too negligible (unless everyone is streaming HD videos).

All the answers about scaling "ELB" are nonsense. There is no scale in this specific case. The "huge" peak being referred to would hardly consume 5% of a single core to be balanced.

I used to criticize ELB a lot and avoid them at all cost. So do many other people on the internet. But at your scale, all our hatred is irrelevant, you should be way too small to encounter any issues.

N.B. Maybe I'm wrong and ELB have gotten so buggy and terrible that they are now unable to process even little traffic without issues... but I don't think that's the case.

Re: AWS Application Load Balancer

#114

Post by [deleted] »

user5994461 wrote: post #113
encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

Please don't say "huge" when talking about your traffic. That is misleading. The appropriate word to describe 8 requests/s is "nothing". Health checks and monitoring could do that much by themselves when there are no users. 200 requests/s is a very small site. To give you some point of comparison: 200 HTTP requests/s could be processed by a software load balancer (usual pick: HAProxy) on a t2.nano and it wouldn't bre…

[deleted]

Re: AWS Application Load Balancer

#115

Post by detaro »

encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

So what was your solution? run your own load balancer in an instance?

Re: AWS Application Load Balancer

#116

Post by encoderer »

detaro wrote: post #115
encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

So what was your solution? run your own load balancer in an instance?

We have a pool of elastic IPs that we rotate with Route53 using latency based routing. The ability to move the IP atomically (by moving the ENI) gives us operational flexibility. We were pretty surprised ourselves that the (huge) hotspots in our traffic distribution alone were enough to "break" the ELB, despite overall traffic being fairly low. We had to see it ourselves to believe it. The current setup has worked out well for us as we've scaled over the last year.

Also I'll add here to another point made below: I don't blame the ELB for not being built to handle our traffic pattern, despite the fact that websites are probably a minority on EC2 vs APIs and other servers. My specific critique is that none of their instrumentation of the performance of your load balancer indicates to you that there is any problem at all. That is... unfortunate.

Re: AWS Application Load Balancer

#117

Post by [deleted] »

detaro wrote: post #115
encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

So what was your solution? run your own load balancer in an instance?

[deleted]

Re: AWS Application Load Balancer

#120

Post by developer2 »

encoderer wrote: post #38

We plan to do a blog post about this at some point, but we had the pleasure of seeing exactly how elastic the elb is when we switched Cronitor from linode to aws in February 2015. Requisite backstory: Our api traffic comes from jobs, daemons, etc, which tend to create huge hot spots at tops of each minute, quarter hour, hour and midnight of popular tz offsets like UTC, us eastern, etc. There is an emergent behavior t…

As someone who is apparently all-in on AWS, can you explain how you justify the cost? I understand the convenience of having all the pre-built services, but that is a finitely limited benefit. The vendor lock-in of the entire infrastructure and deployment processes being extremely AWS-specific means it's financially infeasible to migrate elsewhere once you are launched. Tack on the expensive-beyond-belief S3 server pricing that gets you terrible allocations of shared hardware, the sky-high insane prices they charge for bandwidth, and the penny-and-nickeling of all other services. I continue to be baffled that any small, medium, or large company believes AWS serves them better than any dedicated or colocation alternative.

The vast, vast, vast majority (seriously, probably 95-98%) of companies do not build out the required AWS infrastructure to remain highly available, with failover, with on-demand auto-scaling of all services that would make AWS the go-to choice. I continue to come across the individuals who maintain the fantasy that their business will remain online if a nuclear bomb wipes out their primary data centre. Yet they all deploy to a single availability zone, the same way you'd deploy a cluster of servers anywhere else. I cease to be amazed at businesses that spend $10k+ a month on AWS that would cost them half that with a colocated deployment.

Post reply on HN