Tenant Isolation in Multi-Tenant API Gateway Using Dynamic Container Loading
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-tenant API gateways, existing solutions fail to efficiently isolate tenants and manage container resources, leading to potential data interference and inefficient resource allocation.
Innovation Solution
The method involves using containers to service requests, where an empty container is selected, loaded with the necessary configuration, and then reused or reassigned as needed, with runtime state information saved to ensure tenant isolation and efficient resource management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If containers are reused to service requests from multiple tenants, then resource allocation efficiency is improved, but tenant isolation may be compromised leading to data interference
Solution Approach 1:
The patent segments tenant configurations and runtime states into isolated units that are loaded into containers on-demand. Each tenant's configuration is stored separately in a data store, and containers are populated with specific tenant configurations only when needed to service requests, ensuring that tenant data remains segmented and isolated even when containers are reused.
Solution Approach 2:
The patent performs preliminary actions by pre-storing tenant configurations and runtime states in a data store before container reuse. When a container needs to service requests for a different tenant, the system first flushes the current configuration and then loads the new tenant's configuration from the data store, ensuring proper isolation is established before the container is reused.
2Reliability
If containers are flushed and reassigned frequently to service different tenant requests, then tenant isolation is improved, but resource allocation efficiency deteriorates
Solution Approach 1:
The patent implements dynamic container management where the decision to flush and reassign containers is based on real-time request patterns and tenant identification. The system dynamically determines whether to flush container configurations based on whether the incoming request is for the same tenant or a different tenant, optimizing the balance between isolation and efficiency.
Solution Approach 2:
The patent changes the state parameters of containers dynamically - switching between having tenant configurations loaded and having containers flushed based on the current request. This parameter change allows the same container to serve multiple tenants efficiently while maintaining isolation when required.
3Adaptability or versatility
If tenant-specific configurations are stored in containers, then service functionality is improved, but data interference between tenants increases
Solution Approach 1:
The patent extracts tenant-specific configurations and runtime states from shared container memory and stores them in a centralized data store. This extraction ensures that each tenant's data is separated and can only be loaded into containers when specifically needed, preventing data interference while maintaining the ability to provide customized service functionality.
Solution Approach 2:
The patent introduces a data store as an intermediary between tenant configurations and containers. This intermediary layer manages the loading and flushing of configurations, ensuring that tenant data is properly isolated while still allowing containers to be populated with the necessary service functionality for each tenant.
4Speed
If containers maintain runtime state information, then service performance is improved, but tenant isolation complexity increases
Solution Approach 1:
The patent uses copying by creating isolated copies of tenant runtime states that are stored in the data store rather than permanently resident in containers. When a tenant's service is needed, the system copies the relevant runtime state into the container, maintains it during service operations, and then flushes it afterward, simplifying the isolation mechanism.
Solution Approach 2:
The patent implements discarding and recovering of runtime state information - flushing tenant-specific runtime states from containers after service completion and recovering them from the data store when needed again. This approach maintains performance by having runtime state available when needed while reducing isolation complexity by using a centralized storage mechanism.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A system can host APIs for a plurality of different tenants and receive requests from many different client devices. As requests are received, an associated tenant can be identified, and a router can determine if a container instance is available to service the request. A container instance may be an empty container instance including an internal endpoint, a Web server, and a runtime environment. An empty container instance can be unassociated with a particular tenant. To associate a container instance with a tenant, a data store, such as a key-value data store can retrieve configuration files that turn the agnostic container instance into a container instance that is associated with particular tenant and includes configuration code to perform the requisite API functions. The pool of empty and populated containers can be managed efficiently.