Introduce Gitlab::Redis::FeatureFlag singleton ahead of redis-cache Redis Cluster migration
This is an alternative to sharding out feature flag operations into its own Redis. Originally discussed in #1994 (comment 1294520454). Currently, feature flags are handled by Rails.cache
which could lead to tricky recursive dependencies as described in #1992 (comment 1163520195). Separating it into its own logical component simplifies it.
In simple terms, instead of (option A) sharding feature-flag workload from the redis-cache
instance into a redis-feature-flag
instance and migrating redis-cache
to redis-cluster-cache
, we perform (option B) an application-level change and migrating redis-cache workload (excluding feature flag) to redis-cluster-cache
. This issue executes option B's step 1.
The advantage of option B is we perform 1 migration and spin up 1 set of Redis Cluster. The disadvantage is that we have to resize and rename (not sure how feasible is this) the redis-cache
instance as it will still exist to handle feature flag workloads.
The end-state is:
- feature-flag workload resides in
redis-cache
instance - all cache workload resides in
redis-cluster-cache
instances
/cc @alejandro @stejacks-gitlab moving the discussions into a new issue as part of &878 (closed)