[keycloak-dev] Clustering and user sessions

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:57:49 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> 
> 
> On 9/17/2014 7:03 AM, Stian Thorgersen wrote:
> > By far the most common request to Keycloak is going to be refreshing the
> > token and if we're sending a message to the cluster for every token
> > refresh it's just not going to scale very well.
> >
> > Will it even scale past 1 node?! Think about it, every refresh causes a
> > request one node to handle one request from the client and send a message
> > to the cluster, while all other nodes have to deal with a message from the
> > cluster. It's going to increase availability, but not scalability.
> >
> > So we're going to have to do something smarter than simply sending
> > lastSessionRefresh every time.
> >
> > Following your example I don't think it's a big deal that there's a window
> > where the session is expired on one node, while not on another. We can
> > always come up with a schema to improve that. Two alternatives we could do
> > if a node detects a session as expired:
> >
> > 1. Ask the cluster if the session is expired, if at least one node says
> > it's not expired it's not
> > 2. Tell the cluster that the session is expired
> >
> > Another solution we could consider is sharding. We have one or more front
> > servers to the cluster which just delegate to a shard to process a
> > request. Each shared handles one set of users and can consist of one or
> > more nodes for increased availability. The front servers only need to know
> > about the shards and members of a shard. This is probably the only
> > solution that's going to scale to really big numbers, so might eventually
> > be required.
> >
> 
> For sharding, you'd also have to change our architecture.  When the
> client needs to change the code to a token, it is going to have to know
> which shard to communicate to.

Nopes, it talks to the a front-end server not the back-end shards. The front-end then delegates the request to one of the back-end servers.

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>