Use Socket.IO and Redis in Multiples for ELB

Question

I installed two EC2 instances on AWS working behind a load balancer, but socket.io breaks when the twos instance starts. I assume that when round robins from ELB between instances and Socket.io send requests before updating to Websockets, it causes io socket to break (session id unknown). I thought that using the shared session repository in Redis, Socket.io would work as all instances would have access to the sessions.

I have a small application developed in Node.js (more specifically, Sails.js) for testing purposes only. I was able to configure ELB to support Web sockets in TCP mode by redirecting requests (Phusion Passenger + NGINX) that run the Sails.js application.

In the app, Redis runs on Amazon Elasticache for SESSIONS and SOCKETS. If I test both instances separately without an ELB, I can see that Redis works for Sockets, as messages are sent and received in both instances.

Are general sessions enough for Socket.io to work? Or do I need sticky sessions in ELB to forward clients to the same instances?

I chose ELB because it is easier to add and remove instances dynamically, which is complicated by using NGINX (Free) or HAProxy.

Any ideas?

Answer 1

When starting a server in the cloud with load balancer / reverse proxy, routers, etc. you need to configure it to work properly, especially when you scale the server to use multiple instances.

One of the limitations of Socket.io, SockJS, and similar libraries is that they must constantly talk to the same server instance. They work great when there is only one server instance.

When you scale the application in the cloud, the load balancer (Nginx in the case of Cloud Foundry) will take responsibility, and the requests will be sent to different instances, causing the Socket.io gap.

To help in such situations, load balancers have a feature called “sticky sessions” as well as “session affinity”. The basic idea is that if this property is set, then after the first load-balanced request, all of the following requests will be sent to the same server instance.

Cloud Foundry for jsessionid cookies for jsessionid cookie-enabled apps includes sticky cookie-based sessions.

Note. jsessionid is the cookie name commonly used to track sessions in Java / Spring applications. Cloud Foundry simply accepts this as a sticky cookie for all frameworks.

So, all applications must do this in order to set a cookie called jsessionid in order to make socket.io work.

app.use (cookieParser); app.use (express.session ({store: sessionStore, key: "jsessionid", secret: "your secret is here"}));

So these are the steps:

• Express sets up a session cookie called jsessionid.
• When socket.io connects, it uses the same cookie and enters the load balancer
• The load balancer always directs it to the same server on which the cookie was set.
• If you use Application Load Balancer, then sticky session settings are at the target group level.