Overwatch ⌚

Introduction

The Overwatch architecture is designed for optimized task scheduling, balancing, and real-time monitoring within a high-demand system. By categorizing tasks based on dependencies and instance types, the architecture efficiently manages both independent and interdependent tasks through a dual-queue system enhanced by robust monitoring tools. This setup maximizes task throughput while ensuring system stability.

Elements

• Database: Serves as the central storage for all task data, configurations, and system metrics. It interfaces directly with the Load Balancer to provide critical information needed for efficient task distribution.

• Load Balancer: Plays a pivotal role by:

  • Distributing Tasks: Ensures tasks are evenly allocated across available resources.
  • Rate Limiting: Controls the task flow into the queues, preventing overload.

• Task Queues:

The architecture utilizes two main queues to categorize tasks based on their requirements:

• Dependent Queue: Manages tasks with interdependencies, ensuring that they execute sequentially or according to their dependencies.

• Independent Queue: Handles standalone tasks that can be executed in parallel without waiting for other processes. Both queues are managed using semaphores and wait groups for task synchronization and resource management.

• Scheduling Algorithms: The architecture employs two distinct scheduling algorithms to categorize tasks:

  • Single Instance Agents: Uses First Come First Serve (FCFS) to maintain a straightforward execution order without complex prioritization.
  • Multiple Instance Agents: Utilizes Priority-Based Scheduling to dynamically allocate resources based on task priority and urgency.

Synchronization Mechanisms

• Semaphores: Control resource access, preventing tasks from competing for the same resources.
• Wait Groups: Facilitate synchronization within the Independent and Dependent Queues, ensuring that dependencies are honored before task execution.
• Task Executors (G1, G2, G3, G4): Executors (G1 to G4) are responsible for running tasks assigned from the Independent and Dependent Queues. Task allocation to executors is managed based on CPU availability and task requirements, with executors optimizing resource utilization.

Monitoring System

The Monitoring System tracks key metrics, specifically CPU and Memory Usage, to ensure efficient task allocation based on real-time system load, preventing resource contention and bottlenecks.

• CPU Usage: Monitors processor load continuously, enabling balanced task allocation.
• Memory Usage: Tracks memory usage to avoid memory constraints that could impede processing.

The PID Controller functions as a feedback loop that adjusts system load based on historical and real-time data:

• Proportional (P): Reacts to current error by adjusting task allocation proportionally to CPU and memory usage.
• Integral (I): Compensates for accumulated past errors, adjusting for sustained overloads or underutilization.
• Derivative (D): Anticipates future errors based on the rate of change in system load, allowing proactive adjustments.

The Exponential Decay Growth component fine-tunes the PID Controller's response by scaling adjustments down over time for stability, preventing rapid task allocation fluctuations in response to load changes.

• Initial Value: Represents the initial load or resource level at the start of the decay process, such as the initial task allocation load.
• Decay Constant: Determines the rate at which the influence of past data diminishes, with a higher decay constant reducing the impact of older data and prioritizing recent conditions.

Mathematically, the PID controller can be represented as:

Role in System Stabilization

The Exponential Decay Growth model complements the PID Controller to enhance stability by:

• Smooth Adjustment: Gradually decreasing the weight of past conditions prevents overreactions to previous load changes, creating a smoother adjustment curve.
• Prevention of Oscillations: As load fluctuates, the exponential decay limits sharp increases or decreases in task allocation, avoiding destabilizing oscillations.
• Adaptation to Real-Time Conditions: With less emphasis on past data, the system can focus on current and recent loads, allowing it to respond dynamically to real-time CPU and memory usage changes.

Implementation Details

The provided use case scenarios illustrate how different scheduling approaches affect completion time in the Overwatch architecture. This analysis highlights the flexibility and efficiency of the dual-queue setup under varying conditions.

Define the terms used in the following cases:

• Case 1: Independent Queue Handling Single Instances (FCFS Scheduling) Tasks are processed in arrival order without dependencies.

  

  Result: The completion time scales linearly with the number of tasks, maintaining a predictable order.

• Case 2: Dependent Queue Managing Single Instances with Dependencies Each task depends on the completion of the preceding task, enforcing strict ordering.

  

  Result: Completion time depends on the cumulative sum of dependent tasks, ensuring that dependencies are honored without delay.

• Case 3: Partial Independent Queue Handling Mixed Single Instances Independent and dependent tasks are separated, allowing independent tasks to proceed without waiting.

  

  Result: By allowing independent tasks to proceed freely, the architecture minimizes delays, optimizing completion time.

• Case 4: Partial Dependent Queue Handling Mixed Single Instances Independent tasks do not block other tasks in the queue, optimizing resource allocation.

  

  Result: This approach ensures efficient resource allocation and prevents delays by managing independent and dependent tasks without blockages.

• Case 5: Independent Queue Handling Multiple Instances (FCFS Scheduling) Multiple instances are processed concurrently without dependencies.

  

  Result: The completion time is minimized by handling multiple instances concurrently, optimizing throughput.

• Case 6: Dependent Queue Handling Multiple Instances with Dependencies Multiple instances are processed in sequence within the Dependent Queue.

  

  Result: Completion time accumulates due to sequential dependencies, extending the total processing time.

• Case 7: Partial Independent Queue Handling Mixed Single and Multiple Instances Mixed instances are handled in the Independent Queue, allowing concurrency for multiple instances and sequential processing for single instances.

  

  Result: By handling multiple and single instances concurrently, the architecture minimizes delays and optimizes completion time.

• Case 8: Partial Dependent Queue Handling Mixed Single and Multiple Instances Mixed instances are handled in the Dependent Queue with concurrency and adherence to dependencies.

  

  Result: Completion time is optimized by balancing concurrent multiple instances and sequential single instances, ensuring efficient resource allocation.

In summary, completion time is influenced by whether tasks are in the Dependent or Independent Queue and if they involve single or multiple instances. The maximum time taken in each queue after the start time defines the overall completion time. For this case study, we have assumed that multiple users are handling identical software package sizes and using the same set of tools. If any of these parameters change, the load balancer will manage the standard execution of agents, delivering results to users with varying package sizes or different toolsets.