Multi-Tenancy in Redis Enterprise
Multi-Tenancy in Redis Enterprise
Redis Enterprise allows you to create a multi-tenant environment on-premises or in any infrastructure you control. Why would you want, you ask? Read on to find out.
Join the DZone community and get the full member experience.Join For Free
Running out of memory? Learn how Redis Enterprise enables large dataset analysis with the highest throughput and lowest latency while reducing costs over 75%!
Multi-tenant software is architected to host multiple tenants sharing the same infrastructure. Amazon Web Services, Microsoft Azure, SalesForce, etc. are popular examples of multi-tenancy. Redis Enterprise Cloud, offered by Redis Labs, is also a multi-tenant service with over 500,000 Redis databases sharing the Redis Cloud platform.
Redis Enterprise software allows you to create such a multi-tenant environment on-premises or in any infrastructure you control. But why would you need such an environment?
If your organization develops a series of in-house applications and microservices, then a multi-tenant environment can save you time and money. Application lifecycles typically include development, testing, and staging before production deployment. For fast time-to-market, you need a solution that will take your application through development, testing, staging, and production rapidly. A multi-tenant architecture eliminates the setting up of new physical infrastructure for your software, and installing new supporting software (a database for example) in your development, testing, and production environment. It enables you to execute multiple development efforts and testing cycles in parallel with little effort.
Multi-Tenancy for Your Redis Database
1. Redis in a multi-instance deployment
A multi-tenant architecture is different from a multi-instance architecture. In the latter, you install a new instance of the software for each tenant. The picture below illustrates an example of multi-instance architecture for Redis. In this type of scenario, you spawn a new Redis instance for every tenant. As the number of your tenants grow, the complexity of deploying, monitoring, maintaining, and upgrading multiple software instances grow exponentially.
2. Multi-tenancy achieved through virtualization/containerization
In this case, you deploy Redis as a container or a virtual appliance and allow the underlying management solution to spawn a new Redis instance. Multi-tenancy is achieved at the server/infrastructure layer. In many ways, this technique of achieving multi-tenancy is not very different from the multi-instance setup. While the management layer reduces the complexity of provisioning and starting a new Redis service, you still have the same number of Redis services to monitor and manage. Typically, third party Redis-as-a-Service vendors such as Elasticache, Azure Redis, Google Redis and Heroku Redis follow this method. These solutions are priced per Redis instance. The effects of scale and scope economies benefit these service providers more than you.
3. Multi-tenancy in Redis Enterprise
Redis Enterprise offers software multi-tenancy in which a single deployment of Redis Enterprise Software (often deployed as a cluster of nodes) serves hundreds of tenants. Each tenant has its own Redis database endpoint which is completely isolated from the other Redis databases.
When you deploy Redis Enterprise in your data center, private cloud or a virtual private cloud, you benefit from the scope economies of the multi-tenant architecture. With a single Redis Enterprise cluster of a few nodes, you can support your development and testing efforts and then take it to production.
How Redis Enterprise's Multi-Tenant Architecture Works
Redis Enterprise architecture implements multiple layers of abstraction to deliver multi-tenancy, high availability, linear scaling, high throughput, etc. Redis Enterprise architecture is comprised of the following components:
- Shard: A shard is an open source Redis instance. Redis, being a single-threaded process, runs on one CPU core. You could maximize your throughput by running a shard on each CPU core.
- Database: A database is the logical endpoint that holds the data for a tenant. You can assign multiple shards to a database to meet any data set size or throughput requirements. You may enable persistence, replication, eviction policy, and flash as a RAM extension at the database level. You can also configure your database for high-availability (as shown in the picture below). Redis Enterprise will attach your primary and secondary databases to different nodes. A database can be one of the following types:
- A simple database, i.e. a single master shard
- A highly available (HA) database, i.e. a pair of primary (master) and secondary (slave) shards
- A clustered database, which contains multiple master shards, each managing a subset of the dataset (or in Redis terms, a different range of "hash-slots")
- An HA clustered database, i.e. multiple pairs of master/slave shards
- Node: A node is a physical server, virtual machine, container or cloud instance on which the Redis Enterprise software is installed. At any given time, a node can include between zero and a few hundred Redis databases.
- Zero Latency Proxy: Each node in the cluster includes a zero-latency, multi-threaded proxy that forwards Redis operations to the database shards on behalf of a Redis client. In a multi-tenant environment, the proxy ensures that the client requests go to the right shard of a database.
You may deploy multiple databases in a Redis Enterprise cluster; you are only limited by the total memory size. Every database endpoint has an FQDN. The zero-latency proxies on all of the nodes in a cluster can redirect client requests to the appropriate primary (master) database.
Advantages of Redis Enterprise's Multi-Tenancy
Redis Enterprise's multi-tenancy solves many problems:
- Reduces infrastructure cost: Redis Enterprise maximizes the infrastructure utilization by allowing you to run multiple Redis database endpoints in a single cluster. For instance, you could run hundreds of database endpoints on a simple three-node cluster. The number of database instances you can run, can be many more than the available cores because of built-in time-slicing. Redis Enterprise utilizes all available physical resources before signalling the need to add more resources. In contrast, other multi-tenant solutions provide only one database endpoint per node or cluster. If you need more database endpoints, you are required to invest in more physical infrastructure.
- Makes scaling seamless: You can scale a Redis Enterprise database by adding more shards and even expanding it over multiple nodes if needed. The Redis Enterprise architecture ensures other tenants-databases in this case-are not affected during this process.
- Offers tenant-level tunability for high availability, persistence, eviction and data size: Not all applications have the same requirements for data durability and high availability. In Redis Enterprise, you can tune your database to meet your application requirements, independent of the other databases running on the same node.
- Brings agility to development, testing and production environments: Once Redis Enterprise cluster is set up, application developers can provision Redis database endpoints on demand without worrying about the underlying physical or cloud infrastructure.
Redis Enterprise is a market-proven, multi-tenant solution. Redis Cloud is indeed Redis Enterprise's multi-tenant service. Built-in controls within Redis Cloud ensure that all databases' throughput and latency requirements are being met, while being shielded from "noisy neighbors" and while staying highly available in scaled out, distributed environments.
Redis Labs runs more than 500,000 database endpoints on all the popular public cloud platforms: AWS, Azure, GCP and SoftLayer. Redis Enterprise Software is deployed as a multi-tenant software in over 300 enterprises. Read our documentation to learn how to create and maintain databases in a multi-tenant environment.
Published at DZone with permission of Roshan Kumar , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.