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

AWS Network Load Balancer

aws.amazon.com

Post reply on HN
Print view View original

51–60 of 122 posts

Re: AWS Network Load Balancer

#51

Post by takeda »

takeda wrote: post #21
Cieplak wrote: post #9

I wonder what they wrote it in. I'd guess C++, Java or Erlang, or a combination of those.

Chances are it's IPVS[1], maybe with some patching. Why would one reinvent the wheel when Linux already lets you do that. In that case it would be C since it's implemented in the Linux kernel. [1] https://en.wikipedia.org/wiki/IP_Virtual_Server

I should have read the blog instead of skimming before responding.

This appears as Layer 4 load balancing, IPVS is more of Layer 3.

So the person who was voted down by mentioning HAProxy might not be too far off. It could be implemented through HAProxy + TPROXY enabled in the kernel[1]. Then just make sure that default gateway configured on targets routes back to the load balancer or it is the load balancer.

[1] https://www.loadbalancer.org/blog/configure-haproxy-with-tpr...

Re: AWS Network Load Balancer

#53

Post by colmmacc »

inertial wrote: post #52

Feature request : Please allow weighted load balancing i.e. ability to distribute traffic in a user specified ratio (weights) to different sized instances.

For now here's a work-around that I use: create multiple listeners/ports on the larger instances and add them as targets. Containers is a great approach here too; load up the bigger instances with more containers and register each container as the targets.

Re: AWS Network Load Balancer

#54

Post by friendzis »

colmmacc wrote: post #2

If you're curious to see NLB in action, here's a live demo: http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/ , it took about 5 minutes in the console to set it up and no changes on the targets/backends. Massive disclaimer: I work on NLB.

Demo page states "Your browser may keep a connection open for a few seconds and re-use it for a reloaded request. If it does, you'll get the same target", but when I attempted to abuse the power of F5, I was alternated between ice cream and bumblebee.

If you are going to look at it, attempt time - ~04:50 UTC, remote address from 88.119.128.0/20 network

Re: AWS Network Load Balancer

#55

Post by zob_cloud »

hexsprite wrote: post #44

so would a websocket-based application be better off using NLB?

Better off depends on what your workload goals are. If you want path or host name based routing, Application load balancer may be a better fit as it natively supports WebSockets. If your goal is long lived sessions (weeks and months, not minutes and hours), Network load balancer is probably a better fit.

Re: AWS Network Load Balancer

#56

Post by vacri »

colmmacc wrote: post #47
vacri wrote: post #37

Earlier quoted context omitted.

> [upgrading ELB], in those situations we work directly with customers via AWS Support. This is painful, though. I don't know about Sep 2017, but in 2016 upscaling your ELB involved answering a block of 21 or so questions in a list only given to you after you engage with support, which had some pretty esoteric items on it. It was decidedly un-AWS-ey.

It was definitely un-AWS-ey, and there's an almost visceral pain response on our faces when we don't have a self-service API for something. This is improving all of the time and I think is already much better, with some big specific improvements ... I'll do my best to share what I can here. First things first, with NLB our experience is that pre-warming is never necessary. Each NLB starts out with a huge volume of ca…

That's all great news to hear. Thanks for the informative response :)

Re: AWS Network Load Balancer

#57

Post by syncerr »

Seems to remarkably decrease latency (380ms -> 109ms). Running some tests:

    # ab -n 400 http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/
    Time per request: 108.779 [ms] (mean, across all concurrent requests)

    # ab -n 400 
    381.933

    # ab -n 400 
    380.632

    # (for reference) ab -n 400 https://www.google.com/
    190.536

    # (for reference) ab -n 400 https://sandbox-api.uber.com/health/
    107.680
If you're wiling to terminate SSL, this looks like it could be a solid improvement.

Re: AWS Network Load Balancer

#59

Post by seanp2k2 »

mdouglass wrote: post #45
nonane wrote: post #35

Earlier quoted context omitted.

I don't think they can add TLS termination because of the way it's implemented. NLB runs on Layer 4 - the transport layer where TCP/UDP run on. TLS technically runs on top of the transport layer.

That’s kind of the answer I was expecting, just hoping it wasn’t the case. From the marketing material they really want you to move, but not having a solution to offload tls makes it impossible for us. And it worries me to see the CLB getting effectively deprecated with it an alternative

ALB can term TLS for h2 and wss: https://aws.amazon.com/elasticloadbalancing/ sounds like that's what you might want?

Re: AWS Network Load Balancer

#60

Post by cperciva »

knite wrote: post #26
colmmacc wrote: post #2

If you're curious to see NLB in action, here's a live demo: http://nlb-34dc3b430638dc3e.elb.us-west-2.amazonaws.com/ , it took about 5 minutes in the console to set it up and no changes on the targets/backends. Massive disclaimer: I work on NLB.

It sounds like NLB passes through source IP - does that mean outbound flows are through the IGW?

There must be some magic happening somewhere, because otherwise outgoing packets would have the wrong source address.
Post reply on HN