AWS Application Load Balancer WebSocket metadata based stickiness?

Question

We have a cluster of some service. The clients connect to the cluster via Websocket. The clients are targeted to nodes based on the group they belong to (lets call it a "conference").

In other words, a whole group of clients (conference) is served by one particular node. So, the target node should be selected based on some metadata sent when initiating the WebSocket connection.

Client Tom Hanks connects to Actors     conference -> LB routes to node EU Server
Client Tom Hanks connects to Tesla fans conference -> LB routes to node USA Server

Client Ada Zizkova connects to Actors     conference -> LB routes to node EU Server
Client Ada Zizkova connects to Tesla fans conference -> LB routes to node USA Server
...

Notice that this is NOT a HTTP session based stickiness. The HTTP session is the same one for the same user.

All this is what we would like to have. But currently we are at the simple AWS Elastic Load Balancer and we are about to implement this stickiness in-house and bypass the ELB.

Before doing that, I am looking into whether the ALB could do what I described above. Can't find anything, just this: Does an Application Load Balancer support WebSockets? Which looks like a general connection stickiness. See AWS docs here.

How can I do a metadata-based WebSocket stickiness with ALB? (Or with something else in AWS).

Answer 1

For most of the applications, you can use AWS ELB(Classic Load Balancers) by "Sticky Sessions" feature.

By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user's session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.

The key to managing sticky sessions is to determine how long your load balancer should consistently route the user's request to the same instance.

Also, the WebSockets connections are inherently sticky. If the client requests a connection upgrade to WebSockets, the target that returns an HTTP 101 status code to accept the connection upgrade is the target used in the WebSockets connection. After the WebSockets upgrade is complete, cookie-based stickiness is not used.

For more information, read the following doc on the AWS website: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Eventually, you can use AWS ALB (Application Load Balancer), ALB supports Web Sockets.

Just replace the ELB with the ALB and enable sticky sessions.

The Application Load Balancer is designed to handle streaming, real-time, and WebSocket workloads in an optimized fashion. Instead of buffering requests and responses, it handles them in streaming fashion. This reduces latency and increases the perceived performance of your application.

For more information about AWS ALB, read the following doc on the AWS website:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html