Distributed Service Scaling via DNS Bucket Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing clustered network systems face challenges in scaling services without disrupting clients, as load balancing and resource re-shuffling can be processor-intensive and disruptive to applications.

Innovation Solution

A system and method that transparently scales services by dividing resources into buckets, using a membership service to propagate scaling changes and ensure consistent order, and employing Kubernetes for container management and DNS processes to maintain transparency and minimal disruption to clients.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If load balancing and resource re-shuffling are performed to scale services, then service capacity increases, but processor overhead and application disruption increase

Engineering Contradiction:
Improveservice capacityVSAvoidprocessor overhead
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The system segments resources into distinct buckets that can be independently managed and assigned to service instances. Each bucket represents a discrete unit of resources (e.g., data, configurations) that can be moved without affecting other resources. This segmentation enables efficient load balancing by allowing the system to redistribute only specific buckets among service instances rather than re-shuffling entire resource sets, thereby reducing processor overhead during scaling operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a membership service as an intermediary that manages the complex logic of resource bucket assignment and service instance registration. This mediator handles the computationally intensive tasks of determining optimal resource distribution, calculating load balances, and coordinating reassignments. By offloading these processor-intensive operations to a dedicated membership service, the system reduces the burden on individual service instances and minimizes application disruption during scaling events.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If load balancing and resource re-shuffling are performed to scale services, then service capacity increases, but application disruption increases

Engineering Contradiction:
Improveservice capacityVSAvoidapplication disruption
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by pre-establishing the membership service and pre-defining resource bucket structures before scaling operations begin. When scaling is needed, the membership service already has the framework in place to rapidly assign new resource buckets to additional service instances without requiring complex real-time calculations. This preliminary setup enables smooth, disruption-free scaling because the infrastructure for resource management is already prepared and can accommodate new instances immediately.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The membership service acts as an intermediary that absorbs and manages the disruption caused by resource re-shuffling. It coordinates the transfer of resource buckets between service instances, ensuring that clients experience minimal interruption. The membership service handles the complexity of reassignment logic, maintaining service continuity by orchestrating transfers in a way that prevents data loss or access failures, thereby preserving application reliability during capacity expansion.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Productivity

If traditional scaling methods are used, then service capacity can be increased, but client transparency and system simplicity deteriorate

Engineering Contradiction:
Improveservice capacityVSAvoidsystem simplicity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The membership service serves multiple functions simultaneously: it acts as a service registry, a load balancer, a resource manager, and a scaling coordinator. This multi-functional approach consolidates what would otherwise require separate complex systems into a single unified service. By making the membership service universal, the system achieves service capacity scaling while maintaining simplicity, as all scaling-related operations are managed through this single interface rather than requiring multiple specialized components.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The membership service as an intermediary abstracts the complexity of resource management and load balancing from both service instances and clients. Service instances simply register with the membership service and receive their assigned resource buckets without needing to implement complex resource management logic. Clients interact with service instances through standard interfaces without needing to understand the underlying resource distribution mechanism. This intermediary layer shields both producers and consumers from system complexity while enabling scalable service capacity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11632423B1Scaling of services in a distributed system
Publication Date: 2023.04.18 DELL PROD LP
  • US11632423B1 patent drawing
  • US11632423B1 patent drawing
  • US11632423B1 patent drawing

AI summary

Embodiments for scaling services in a distributed network by registering bucket names for the services with a Domain Name Service (DNS) server. Buckets hold resources and distribution of buckets to servers is maintained using a Consistent Hashing Ring. Upon determining that services servers need to be added or deleted based on changes load conditions, leave/join events are managed by a Kubernetes event service and updates are propagated to all of the services by the membership service component. A service scaling process updates the mapping of buckets to the host name of the new service server. A resource request from a client is sent to the mapped bucket name, and a DNS resolver process sends it to the changed service server so that the client is completely unaware of this change in bucket ownership.