I am a Sr. Software Developer at Oracle Cloud. The opinions expressed here are my own and not necessarily those of my employer.
Rails session storage
When we build applications on a singleton server things are very simple. But then we need to start scaling out (usually better approach than scaling up) and we need to worry about session state management. Here is a great article by Justin Weiss and video of his talk on Rails sessions.
Sticky sessions
The simplest thing on AWS Elastic Load Balancer is to enable sticky sessions. ELB will create a cookie and the next time the request comes back it will be sent to the same EC2 instance as before.
The downside is that if we need to take server out of the load balancer to do maintenance / deploy code there could still be users on it. To help with that we need to use dedicated state server or DB to store session info.
Redis
In Ruby on Rails applications we can enable Redis session storage using redis-rails.
Redis will purge the data after one day with TTL.
Mongo
We have been using this approach for a couple of years with mongo_session_store-rails4 gem.
Documents in Mongo will have ID (zzv-ATGWb5lG-w7AwwI438pXHtk
) and DATA (#<BSON::Binary:0x00000008468ce8>
). We can also modify the default model class to add TTL indexes which will purge old records.
ActiveRecord / SQL
We need to follow instructions on activerecord-session_store to install the gem and created SQL table where data will be stored.
Sessions table will have ID (primary key), session_id (ea2c0d7d8b5799c0f48966c9312f95e8
), data, created_at and updated_at. Since MySQL / Postgres do not have TTL process we will need to create a background job to clean out these records.
Which approach should we use depends on our needs. If we are already using Redis for other tasks such as caching or background jobs then it may make sense to store our session data. On the other hand if we do not yet have Redis and our primary DB is not under strain then it’s probably simpler to store sessions there.