Session affinity / stickiness / persistence

[pesho]

Is support for sticky sessions on the roadmap?

[emilevauge]

Hi, this is not my top priority for now, but why not in the futur!
But to be honnest, I'm not promoting this kind of feature because it's not in line with microservices architecture and more precisely 12 factor apps.

[pesho]

But to be honnest, I'm not promoting this kind of feature because it's not in line with microservices architecture and more precisely 12 factor apps.

I do follow most of the 12-factor app principles myself, but this particular one (unconditionally banning sticky sessions) is flat out misguided and wrong. The ideologic creators of these principles, Heroku, do support sticky sessions themselves.

There are some scenarios for which sticky sessions are the best possible solution. Namely, bi-directional connection layers such as Socket.io which use Websockets if available, but may fall back to long polling. If one wants to scale such a system horizontally, there are (broadly) two available options:

1. Use a centralized session data storage (the 12-factor recommendation), like Redis or Memcached.
2. Store the session data in-process for a short time, and use session affinity in the load balancers.

Of these two options, the 2nd one is clearly the smarter one. The first one adds unnecessary complexity, latency, performance penalty, and is harder to scale. The second one is simple (it's easy to accomplish in HTTP load balancers without increasing the computational complexity) and linearly scalable horizontally.

[dverbeek84]

@pesho, I totally agree with you. In a enterprise (my situation) you don't want to have to much complexity. Becouse it is complex already. Maintaining multiple redis clusters or just add sticky sessions, that's not a hard choice. I am already looking how to add it but I am not a go expert :d

[faddat]

While the doc outlining 12 factor apps is a masterpiece, did anyone else feel reminded of the late 90's when they read it?

[emilevauge]

I understand that sessions stickiness can be simpler than deploying a Redis backend. BUT, the simplest solution is not always the best. Everytime I encontered stickiness in production, everytime it lead to deployement / scalability / poor user experience / bad load balancing problems. As I said, It is not a priority for now, and if it's a needed feature for you, my advice is to do it with Nginx for now :)

[pesho]

@emilevauge, if you are only concerned about microservices, then what you say is undoubtedly true - sticky sessions stink. There are other valid use cases though, my example above was one (long polling).

if it's a needed feature for you, my advice is to do it with Nginx for now :)

Nginx only does IP-based sticky sessions, which are not perfect. HAproxy would be my recommendation (I've been running many-node, many-loadbalancer Engine.IO and SockJS clusters in production for the past couple of years).

[emilevauge]

@pesho why do you consider long polling as a valid use case for stickiness? If session data are stored in Redis?

[pesho]

@emilevauge for the reasons mentioned above:

unnecessary complexity, latency, performance penalty, and is harder to scale

[emilevauge]

@pesho I don't see any difference between a long polling app and a REST microservice on this, sorry :'( If you want to discuss further on this, can we go on https://gitter.im/EmileVauge/traefik ?

[pesho]

@emilevauge can you point a single benefit a long polling app gains from a centralized session storage, compared to using sticky sessions? I can point several drawbacks.

A long polling layer does not require reliable session storage for example (which has its costs). It shouldn't need to deal with the complexities of sharding Redis either.

[emilevauge]

To be continued here: https://gitter.im/EmileVauge/traefik

[olvesh]

Server-affinity might be a good thing even if not using sticky sessions because of cache regionality.

Micro-services might have caches in them that would be warm for a specific subset of requests. If all requests are served round-robin all services would need to cache everything in order to be effective. By using server-affinity the caches won't need to hold as much to serve the same purpose.

[samber]

@emilevauge As said previously by @pesho, Socket.io offer HTTP long polling in replacement of Websocket for backward compatibility. Websockets were not supported before IE10.

From the developer POV, when using socket.io, both client and server are able to fall back to long polling automatically without any change in the source code. In that case, socket.io simulates a session.

I agree with you, session affinity does not respect 12-factor app methodology, but I think managing it at the LB level avoids a lot of work and complexity/debt for developers !

Did anybody start working on this ? ;-)

[muradm]

Issue #404 mentions "traefik.backend.sticky" but there is nothing in docs. Is this working now? Does it work with Consul service catalog / kv backends?

[errm]

@muradm the PR is currently in play over in #446