Re: [keycloak-dev] Clustering and user sessions

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Marek Posolda" <mposolda(a)redhat.com&gt; Cc: keycloak-dev(a)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.

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