CloudyGUI: A Novel Python-based Framework for Auto-Scaling and Cloud Workload Analysis Jyoti Bawa* Guru Nanak Dev University, Department of Computer Science, Amritsar, 143005, Punjab, India
Mohit Kaushik Guru Nanak Dev University, Department of Computer Science, Amritsar, 143005, Punjab, India
Kuljit Kaur Chahal Guru Nanak Dev University, Department of Computer Science, Amritsar, 143005, Punjab, India
arXiv:2607.00455v1 [cs.DC] 1 Jul 2026
Kamaljit Kaur Guru Nanak Dev University, Department of Engineering and Technology, Amritsar, 143005, Punjab, India
Abstract Purpose: Cloud computing environments are highly dynamic, creating major challenges for resource management. Accurate workload prediction is therefore essential for effective auto-scaling. To address this, we present CloudyGUI, a Python simulation framework with an easy-to-use GUI that allows researchers to test and validate resource management strategies. Methods: This framework employs a three-stage pipeline: workload generation, prediction (utilizing XGBoost and LSTM), and an auto-scaling system based on the MAPE loop. Validation includes internal, intermediate, and external methods to ensure system reliability. Results: CloudyGUI’s generated workloads closely match real-world datasets. A two-sample K-S test confirms this alignment, showing strong p-values of 0.19 for CPU and 0.14 for memory. When compared to a command-line tool, the GUI adds only a minimal overhead of 1.4×-4.67×. Furthermore, expert review validates the tool’s realism and practical usefulness. Conclusion: CloudyGUI fills a critical gap by providing an accessible and efficient platform for simulating auto-scaling in cloud applications, helping researchers develop advanced cloud management solutions. Keywords: cloud computing, simulator, workload analysis, auto-scaling, resource management
1. Introduction Cloud environments are highly complex due to virtualization, multi-tenancy, and auto-scaling [1, 2, 3, 4]. This makes it difficult for researchers to test their policies in a real cloud environment [1]. Researchers often use simulation tools to analyze cloud performance and resource behavior without needing actual cloud systems [2, 5]. However, traditional simulators often fail to accurately replicate the dynamic behavior of the cloud environment [1, 6, 7, 8, 9, 10]. To overcome this, we need a specialized simulation tool that can accurately capture these complexities. Such tools are essential for evaluating strategies for resource provisioning, load balancing, and energy efficiency [11, 12]. Thus, researchers can run repeated experiments without the expense of real-world cloud deployment [13, 1, 14]. Existing tools are mostly built in Java and C++, with CloudSim serving as a key resource [15, 16]. However, these
Published in Simulation Modelling Practice and Theory. Cite the published version: https://doi.org/10.1016/j.simpat.2026.103308 Preprint submitted to Elsevier
Java-based simulators often face difficulties related to adaptability and flexibility, which are necessary to accurately simulate the complexities of modern cloud environments [17, 9]. Nowadays, a major challenge involves implementing and evaluating various auto-scaling techniques [17, 18, 19]. To address these limitations, more flexible and modern simulation tools are needed [13, 15, 16]. Tools like Cloudy [9] recently started a trend toward Python-based solutions. Python is preferred for its simplicity, readability, and easy integration with various libraries for GPU computing. However, This transition has been slow, and several challenges remain. While Python offers features like simplicity and integration with AI/ML libraries, existing efforts often resulted in minimal innovation, such as projects that primarily translated older Java frameworks (e.g., geoCloudSim) or became inactive for extended periods (e.g., pyCloudSim). These issues underscore the existing gap for a comprehensive, natively designed, and functionally advanced Python simulation framework capable of
https://github.com/AUT-Cloud-Lab/geoCloudSim https://github.com/vonpupp/pyCloudSim July 2, 2026
handling auto-scaling and providing enhanced usability. To address this gap, this paper introduces a novel Pythonbased cloud simulation framework. The key contributions of this work are as follows:
Techniques utilizing AI automation [31], dynamic load balancing models [3], and deep learning-based proactive scaling [32] are increasingly adopted to handle workload volatility. These advanced control strategies require robust simulation environments to validate their stability and performance before deployment. The evaluation of such complex cloud systems often relies on simulation tools. CloudSim [33] is a widely used tool for cloud simulations that supports the modeling of large-scale infrastructures. However, it lacks native support for auto-scaling mechanisms and a graphical user interface. Many extensions like CloudSim Plus [22], ContainerCloudSim [34], and GPUCloudSim [35] enhance its capabilities for modern cloud features but do not fundamentally alter its core limitations regarding auto-scaling. Other simulators like DCSim [36] focus on Virtual Machine (VM) management and dynamic resource allocation, modeling multi-tier applications and supporting features like VM migration and overcommitted resource provisioning. Meanwhile, MDCSim [37] targets multi-tier data centers, featuring a pluggable three-layer architecture to model communication protocols, kernel-level scheduling, and user-tier interactions, with validation against real prototypes. Several simulators have incorporated auto-scaling, primarily for web applications, though each has unique focuses and limitations. AutoScaleSim [22], an extension of CloudSim, offers a comprehensive toolkit for evaluating auto-scaling in web applications, supporting the full MAPE-K loop, customizable simulations, and various performance metrics, even allowing real web traffic testing and OpenStack validation. However, it largely focuses on generic web server workloads rather than the bursty patterns of interactive GUI applications. PEAS [23] evaluates auto-scaling using scenario theory with probabilistic guarantees and real-platform validation, precisely measuring low-level metrics but overlooking high-level aspects like failed requests, SLA compliance, and cost for generality. PICS [24] provides an auto-scaling framework for public clouds, considering cost and SLA from an end-user perspective, but it primarily simulates workflow rather than transactional workloads and is restricted to short-term simulations (minutes), insufficient for long-term interactive user experiences. Addressing static scheduling limitations, ElasticSim [2], a CloudSim-based toolkit, simulates resource auto-scaling with variable task execution times, using probability distributions and interval-based VM pricing to show that stochastic execution times can significantly increase costs and lead to deadline violations, emphasizing the need for dynamic, uncertainty-aware scheduling. Beyond the aforementioned tools, several specialized simulation toolkits extend cloud modeling capabilities for diverse scenarios, though often without specific focus on the unique demands of interactive GUI auto-scaling. SPECI [38] focuses on the scalable design, performance, and failure/recovery of cloud data centers, allowing users to explore these aspects by defining data center size and middleware policies. For scientific applications, GroudSim [39], a Java-based toolkit enabling simulation on Grid and cloud infrastructures, providing performance statistics and modeling computational and network aspects, including job and file transfers. MDCSim [37], a commercial and
• A Python-Based Simulation Framework: We present a Python-based cloud simulator that directly addresses the limited evolution and provides ease of use. • Graphical User Interface for Enhanced Usability: The framework includes a user-friendly GUI, significantly lowering the barrier to entry for setting up, running, and analyzing complex cloud simulations. • Predictive Auto-Scaling: We implement a predictive threshold-based auto-scaling mechanism, a critical feature for modern cloud environments that is underdeveloped in existing Python-based simulators. While simulators with graphical interfaces and auto-scaling exist [20, 21, 22, 23, 24, 2], they remain largely Java-based. In contrast, modern resource management research is driven by Python-based ML frameworks, creating a disconnect between the two environments. This architectural mismatch forces researchers to bridge or rewrite ML models for simulation, introducing latency and complexity [9]. CloudyGUI’s key innovation is not merely its Python implementation, but its ability to execute native ML models (e.g., XGBoost, PyTorch) directly within the auto-scaling loop. The rest of the paper is organized as follows: Section 2 reviews the existing literature to identify the gaps. Section 3 details the methodology employed in our proposed simulator. In Section 4, we present our results and analysis, demonstrating the simulation data using visualizations. Section 5 interprets these results by discussing their implications for existing practices. Section 6 concludes this study by summarizing the contributions. Finally, Section 7 outlines potential future directions and addresses the limitations of our study. 2. Literature Review Cloud computing offers features such as elasticity, costefficiency, and scalability [25]. However, this complex environment presents challenges in dynamic resource management, energy efficiency, and load balancing [26, 27]. Because of high costs, risks, and time consumption, it is impractical to perform experimentation in live cloud systems [28]. Therefore, robust simulation tools are essential for understanding the complex cloud environment [9, 29]. These tools let users perform experiments cost-effectively [17]. Auto-Scaling is a strategy for dynamically managing cloud resources, which can be effectively studied using simulation. Auto-scaling helps to manage resources and adjust them according to user demand. It ensures high resource availability, maintains cloud performance, controls costs, and prevents both over-provisioning and under-provisioning in the system [30]. While traditional approaches often rely on static thresholds, recent advances on control methods have shifted towards intelligent automation. 2
scalable toolbox, offers in-depth analysis of multi-tier data centers by modeling hardware for power consumption estimates and optimizing web application performance through various resource configurations and network topology. Furthermore, NetworkCloudSim [40] extends CloudSim with a scalable network and a generalized application model for cloud data centers, supporting inter-communicating elements like Message Passing Interface (MPI) and workflows, featuring a network flow model for bandwidth sharing, and allowing easy topology modification via a configuration file. While valuable for their respective domains, these tools typically lack the finegrained control and workload modeling necessary for simulating responsive auto-scaling tailored to individual user interactions within a GUI. Furthermore, various toolkits offer advanced modeling capabilities for modern cloud aspects, yet frequently lack the specific integration of auto-scaling with interactive GUI workload characteristics. DCSim [36] provides an extensible framework for investigating dynamic resource management in IaaS, featuring multi-tier application models and VM interaction/replication. Extending CloudSim, ContainerCloudSim [34] models and evaluates containerized cloud environments, supporting CaaS, container lifecycle, and energy-aware provisioning. Similarly, ICARO [41] Cloud Simulator (ICLOS) focuses on long-term prediction of complex cloud workloads and business configurations by integrating a semantic Knowledge Base and Smart Cloud Engine for realistic, SLA-driven simulations. GPUCloudSim [35] is designed to evaluate GPU virtualization schemes and resource provisioning. It makes use of the First Fit Increasing (FFI) VM placement algorithm, which further improves performance and energy efficiency. Although it addresses the limitation of previous tools that are heavily focused on non-GPU resources, it fails to provide a simulator with autoscaling capabilities built into the GUI. Several simulators offer a graphical user interface to simplify the complex cloud environment. Among these, iCanCloud [20] provides a GUI to configure virtual machines, data centers, and other resources. Other tools, such as DARTCSim [21], extend CloudSim by introducing a GUI to simplify tasks like dynamic resource allocation and task scheduling. For Software-Defined Cloud Data Centers (SDN), CloudSimSDN [42] allows users to efficiently manage the network and traffic. These visual interfaces help to reduce the learning curve and also improve the user’s experience in simulation. Tools like CloudAnalyst [43] and CloudReports [44] also offer GUIs for experimental setup but lack robust auto-scaling. While there are numerous simulation tools, there is a lack of integration of Cloud Simulators built into Python, which comes with GUI and auto-scaling capabilities. There are many simulators, such as ICLOS [41] and ElasticSim [2], which offer auto-scaling capabilities but are built in Java. This gap limits researchers and developers who prefer Python due to its flexibility and simplicity. Existing tools and research primarily address these domains in isolation or for generic workloads, often failing to fully capture the real-time, user-centric demands and complex resource patterns of interactive cloud GUIs. Although tools like AutoScaleSim [22] and CloudSim [45]
Plus support auto-scaling, they are restricted to static or predefined policies within a Java ecosystem, preventing the direct integration of modern Python-based AI workflows. CloudyGUI differentiates itself by treating the simulation engine as a native extension of the data science stack, rather than a standalone engineering tool. Our proposed CloudyGUI tool aims to fill this gap. CloudyGUI provides a GUI-based tool in a Python environment that handles both workload generation and auto-scaling analysis. This approach enhances accessibility and adaptability in cloud development. This integrated framework offers improved performance and user experience while optimizing resource utilization. Table 1 summarizes the relevant literature. 3. Methodology There is a need for a robust and realistic simulation environment to validate various cloud management strategies. To address this, this research develops a novel simulation framework using a three-stage pipeline, which is illustrated in Figure 2. This pipeline shows the complete workflow, starting with workload generation and ending with the execution of predictive resource management. The methodology begins with the workload generation process, which is designed to create datasets that accurately mimic real-world cloud environments. Next, a resource prediction framework uses machine learning to forecast future resource demands from this data. Finally, a predictive auto-scaling system integrates these forecasts into a proactive MAPE control loop for optimal resource allocation. Together, these components form a complete pipeline for rigorously testing and validating advanced auto-scaling algorithms. 3.1. Architecture Overview To effectively simulate auto-scaling behavior in cloud environments, it is required to model the underlying infrastructure with detailed modularity. Our tool adopts a hierarchical architecture that reflects the layered structure of modern cloud data centers. This allows users to control the resource allocation, virtualization and application deployment. This section presents the conceptual model used in CloudyGUI. The model shows the roles and interactions of various components within the framework. Figure 1 illustrates the hierarchical structure and key components of the conceptual model. DataCenter (Outermost Container). The data center serves as the top-level container that holds all the elements. It includes Physical Machines (PMs), a centralized Resource Pool, and the VM Placement Policy module responsible for orchestrating virtual machine deployment. Physical Machine (PM). Each PM represents a physical server within the data center. It hosts multiple Virtual Machine Monitors (VMMs), which allocate physical resources such as CPU, RAM, and GPU to virtual machines. PMs are centrally managed by the DataCenter and serve as the execution substrate for virtualized workloads. 3
Table 1: Literature Overview
Simulator
Year
Language
GUI
Resource Types
GreenCloud [46]
2009
C++
✗
Physical Servers, VMs and traffic pattern
✗
SPECI [38]
2009
Java, C++
✗
Nodes, Data, Topologies, Network Links
✓
MDCSim [37]
2009
Java, C++
✗
✓
CloudSim [45]
2010
Java
✗
CPU, Disk, Servers, Power and network modules Hosts, VM, Cloudlets
CloudAnalyst [43]
2010
Java
✓
✗
GroudSim [39]
2011
Java
✗
CPU cores. RAM. Bandwidth, VCpu, VRAM Grid Sites, CPU’s per Site, Job Queues, Instances, Instance Type
Network-CloudSim [40]
2011
Java
✗
VMs, Physical Hosts, Network Links
✓
Workflow-Sim [47]
2012
Java
✗
✗
EMUSIM [48]
2012
Java
✗
Physical Hosts, VMs, tasks, overhead modules and clustering engine VMs, Cloudlets, Data centers, User requests
CDOSim [49]
2012
Java
✗
VMs, CPU, Memory, Bandwidth, Workloads
✗
DARTCSim [21]
2012
Java
✓
Data Centers, Cloudlets
VMs,
✗
iCanCloud [20]
2012
C++
✓
CPU, Memory, Disk and network
✗
FTCloudSim [50]
2013
Java
✗
Physical hosts, VMs, Cloudlets, Network layers
✗
DCSim [36]
2014
Java
✗
Hosts, VMs, CPU, Memory, Bandwidth, Applications
✓
Cloud-Reports [44]
2014
Java
✓
Physical Hosts, VMs, tasks, overhead modules and clustering engine
✗
4
Scaling
✗
✓
✗
Limitations Complex to configure and Limited application level abstraction Focus is limited to failure Communication and Lacks community support and general purpose extensibility No container or VM abstraction and No Fault Tolerance Limited support for containerization and Static workload modeling Single language support Outdated technology stack and No real-time simulation Failure modeling requires manual setup and Limited community and documentation Network Simulation is flow based, not packet accurate and Workload relies on user defined synthetic application models Single threaded architecture and Overhead modeling Workflow application emulation not natively supported, Limited cloud API integration Workload accuracy depends on KDM and trace quality and Limited SLA modeling Limited network simulation, No container support and No real-time simulation No Built-in Power consumption modeling and Steep learning curve for customization Cloudsim core limitations and No public cloud provider template No detailed networking layer simulation and No direct public cloud provider templates No container support and Energy models require manual creation
Table 1 Continued from previous page Simulator
Year
Language
GUI
Resource Types
CloudSim-SDN [42]
2015
Java
✓
VMs, Data centers, QOS, traffic flows
✗
ICARO [41]
2015
Java
✓
VMs, Hosts, Networks, Storage systems, SLA
✓
PICS [24]
2015
Java
✗
VMs, Storage services, Network services, Job workloads
✓
PEAS [23]
2016
Java
✗
✓
Container-CloudSim [34]
2017
Java
✓
CloudSim Plus [33]
2017
Java
✗
VMs, Servers, CPU, Memory, Requests, Load balancers VMs, Hosts, Networks, Software services, SLA Physical resources, VMs, cloudlets, power models
ElasticSim [2]
2017
Java
✓
Workflow tasks, VMs, runtime distributions
✓
CloudGen [51]
2019
MATLAB
✗
CPU cores, Memory, Usage duration
✗
GPUCloud-Sim [35]
2019
Java
✗
✓
AutoScale-Sim [22]
2021
Java
✗
Data centers,GPU Memory, Bandwidth, power models, VMs VMs, Cloudlets,web applications, end-user sessions
CloudSim-Express [52]
2023
Java
✗
✗
CloudFactory [53]
2023
Java
✗
Data centers, VMs, cloudlets, power models VMs, workflows tasks,
Cloudy [9]
2024
Python
✗
CPU cores, RAM, GPU, V.RAM, V.CPU
✗
CloudyGUI
2025
Python
✓
CPU cores, RAM, GPU, Disk, V.RAM, V.CPU
✓
5
Scaling
✗ ✗
✓
✗
Limitations Accuracy limited by simplifications in bandwidth sharing and latency estimation and Limitations of cloudsim Limited Network Protocol Simulation and High Complexity for Setup Manual Policy Configuration, Limited to IaaS Layer and No Network-Level Simulation Assumes Known Workload Distributions and Limited to Predefined Auto-Scalers Static resource definitions and Semantic overhead Network Simulation Limitations and No container support Limited failure modeling, and Single threaded simulation limitations No public cloud API integration Limited to VM-based workloads and No integration with simulators No explicit SLA modeling and Cloud native workloads Networking is abstracted and Static modeling limited to static thresholds and response time/delay metrics No packet level network simulation and Scalability bound by cloudsim core Limited to workflow-based applications and Stochastic modeling is predefined No Graphical interface and Lack of networking simulation Lack of networking simulation
• Resource usage is continuously monitored and managed by the VMM. This hierarchical structure is well-suited for auto-scaling and often found in real-world cloud environments. This structure supports modular experimentation across various abstraction levels like hardware, virtualization and application. It is ideal for evaluation of auto scaling strategies. 3.2. Workload Generation CloudyGUI uses a multi-stage pipeline to create cloud workloads. Initializing simulation parameters is the first step in the process, after which jobs and tasks are created and their interdependencies are modeled using a directed acyclic graph (DAG). 3.2.1. Initialization Phase The initialization phase establishes the fundamental parameters, resource constraints, and temporal scope for the entire simulation. It is a critical step that ensures the generated workloads are both realistic and feasible.
Figure 1: Conceptual Model for CloudyGUI
Virtual Machine Monitor (VMM). The VMM is responsible for managing virtual machines on a given physical host. Its core functions include resource allocation, VM lifecycle management, and isolation between VMs. In the illustrated architecture, two VMMs (VMM1 and VMM2) are shown, each managing its own set of VMs.
1. Parameter Validation: This step ensures the integrity of the user-defined inputs. The system validates three key parameters: Number of Jobs, Tasks per Job, and Instances per Task. It performs range checking to limit the values to a reasonable scale (e.g., 1-50,000 jobs, 1-20 tasks per job, 1-10 instances per task). This prevents the generation of an unmanageably large or computationally impossible workload. The system also performs type checking to ensure all inputs are valid, non-negative integers. This validation process is crucial for preventing errors and maintaining system stability. 2. Resource Pool Setup: CloudyGUI initializes a default pool of system resources that represents the total available capacity for the simulation. This pool includes a fixed number of CPU cores (512), Memory (2TB), GPU units (32), and Disk space (10TB). The system monitors the consumption of these resources in real-time. Resource granularity is also defined, with memory tracked in MB and disk in GB which enables precise allocation and monitoring throughout the simulation. 3. Time Window: A defined time window provides a temporal horizon for job scheduling, preventing all jobs from being submitted at the same time. CloudyGUI establishes a 7-day scheduling window starting from the current system time. This window serves as a reference for all job-related timestamps, such as submission and start times, and enables the simulation of realistic workload patterns over an extended period.
Virtual Machine (VM). A VM provides a virtualized computing environment. Each VM includes its own operating system kernel and hosts one or more containers. Containers are lightweight, isolated environments that run specific applications. In the diagram, VM1 runs Container A with App 1, while VM2 runs Container B with App 2. Resource Pool. Located at the bottom of the DataCenter, the Resource Pool maintains a global view of available physical resources across all PMs. It keeps track of CPU, memory, and GPU usage. It also supports dynamic resource provisioning. This pool is queried by the VM placement policy to inform allocation decisions. VM Placement Policy. VM Placement Policy is located adjacent to the resource pool. It determines optimal VM placement based on current resource availability. The workflow is as follows: • The DataCenter receives a request to deploy a new VM. • The VM Placement Policy consults the Resource Pool. • Based on available resources, a suitable PM is selected. • The corresponding VMM instantiates and manages the new VM.
3.2.2. Job Generation Phase The job generation phase in CloudyGUI is a multi-step process that systematically builds a diverse and realistic workload from high-level job definitions to individual running instances.
• The VM runs its OS and hosts containers with applications.
1. Job Type Selection: CloudyGUI uses a weighted random selection process to choose job types, which ensures the 6
Figure 2: Architecture Diagram of CloudyGUI
generated workload reflects a realistic distribution of tasks in a cloud environment. For example, the system might assign a 30% probability to a ‘data_processing’ job and a 25% probability to a ‘machine_learning’ job. Each of these job types has predefined characteristics, including a specific duration range, a failure rate, and a set of typical tasks. The ‘web_service’ job type, for instance, has a shorter duration (15-120 minutes) and a low failure rate of 3%, while the ‘machine_learning’ job type has a much longer duration (120-720 minutes) and a higher failure rate of 10%. 2. Job Configuration: Each generated job is assigned several key properties to define its behavior and place it within the simulation’s time window. A unique ID is assigned, along with an initial status of ‘waiting’. The system sets a priority level from 1 (highest) to 5 (lowest). The job’s duration is calculated randomly within the type-specific range, and a submission time is generated to distribute jobs realistically across the 7-day simulation window. 3. Task Creation: For each job, CloudyGUI creates a number of tasks based on the user-defined tasks_per_job parameter. Each task is a smaller unit of work with its own unique ID, type, and resource requirements. These tasks inherit the priority from their parent job and have a duration proportional to the job’s duration. The resource requirements, such as CPU, memory, GPU, and disk space, are determined based on the specific task type. For ex-
ample, a ‘data_preparation’ task might require a specific range of CPU cores and a larger amount of memory compared to a lighter task. 4. Instance Generation: Within each task, a number of instances are created, as defined by the instances_per_task parameter. Each instance is an individual execution unit with its own unique ID. The resources required for the task are scaled down and divided among its instances. For example, if a task needs 8 CPU cores and has 2 instances, each instance will be allocated 4 cores. The instance is assigned an initial status of ‘waiting’, and its start and end times are determined during the simulation. 5. Status Management: The system manages the status of each job, task, and instance as it progresses through the simulation, with statuses transitioning from ‘waiting’ to ‘running’ and finally to ‘completed’, ‘failed’, or ‘interrupted’. 3.2.3. Dependency Management CloudyGUI’s dependency management system is a comprehensive component of the workload generation process that ensures jobs are executed in the correct order. It reflects realworld interdependencies while preventing deadlocks. This process is crucial for generating realistic workload patterns that can be used to test and evaluate a scheduler’s performance. 1. Dependency Analysis: The system establishes job dependencies based on predefined relationships between job 7
types. For example, ‘machine_learning’ jobs may be defined to depend on ‘data_processing’ jobs. The system uses a weighted probability to determine actual job dependency, making the workload more dynamic. For instance, a ‘machine_learning’ job might have a 70% chance of being dependent on a ‘data_processing’ job. The system also has the capability to handle complex relationships like circular dependencies. 2. Dependency Creation: For each job that can have a dependency, the system identifies suitable parent jobs from the existing pool of jobs, ensuring that the parent job’s submission time is earlier than the dependent job’s. The system then constructs a directed acyclic graph (DAG) to represent the job dependencies. This graph is a crucial data structure for maintaining the order of operations and ensuring that jobs are not executed in an incorrect sequence. 3. Schedule Enforcement: The system enforces dependencies by calculating the earliest possible start time for a job, which is determined by the completion time of all its parent jobs, including a small buffer time. CloudyGUI’s scheduler is dependency-aware and only assigns resources to jobs once all their dependencies are satisfied. This mechanism ensures that the workload simulates a realistic workflow where tasks must be completed in a specific order. When a parent job completes, the scheduler checks if any dependent jobs can now be moved to the ready queue for execution. 4. Cycle Detection and Resolution: To prevent deadlocks and logical errors, the system includes a safeguard to detect and resolve circular dependencies. It uses an algorithm (such as Depth-First Search) to check for cycles in the dependency graph. If a cycle is detected, the system automatically resolves it by removing a dependency to create a valid, acyclic graph, thus ensuring that a valid execution order for all jobs can be found. 5. Visualization and Monitoring: CloudyGUI provides visualization tools to help users understand the complex relationships within the generated workload. The system can create visual representations of the dependency graph, which can be rendered as a PNG file. Additionally, the system tracks metrics related to dependencies, such as the average wait time of jobs due to dependencies, to provide a deeper analysis of the generated workload’s characteristics.
atomically. This process checks if the required resources are available and, if so, deducts them from the available pool and adds them to the allocated pool. 2. Scheduling Techniques: CloudyGUI supports a range of scheduling techniques to manage job queues. A PriorityBased Scheduler organizes jobs into queues based on a 1-5 priority level, ensuring that higher-priority jobs are executed before lower-priority ones. To prevent potential issues like starvation where low-priority jobs could be indefinitely delayed by a continuous stream of high-priority tasks, the system implements an aging mechanism. This is achieved by having the scheduler periodically recalculate the effective priority of all jobs in the waiting queue at regular intervals (e.g., every 300 seconds). For every five minutes a job waits, its priority is boosted by one level (by subtracting from its numerical priority value). The priority queue is then rebuilt with these updated values, a process that guarantees fairness by ensuring that even low-priority jobs will eventually rise to the top of the queue and be executed. A Resource-Aware Scheduler adds another layer of intelligence by considering both a job’s resource requirements and the current availability of those resources before making a scheduling decision. The system can also incorporate advanced techniques like preemption, where lowerpriority jobs are temporarily suspended to make way for critical, high-priority jobs. 3. Resource Allocation Process: The system employs an Admission Controller to manage the flow of jobs into the resource pool. When a job is submitted, the controller first checks if the necessary resources are available. If they are available, the resources are reserved, and the job’s status is set to ‘running’. If not, the job is placed in a waiting queue. 4. Contention Handling: The system employs a multifaceted, proactive strategy to manage resource contention and optimize utilization. It uses a Resource Reservation System and Priority-Based Scheduling to guarantee that high-priority workloads have dedicated access to resources, even allowing preemption of lower-priority jobs. To prevent conflicts between different types of tasks, the system utilizes Resource Pooling and Workload Affinity, which map specific workloads to suitable hardware pools. 5. Resource Monitoring and Adjustment: CloudyGUI includes a real-time monitoring system that continuously tracks resource utilization. This system can be configured to automatically scale up or down resources based on predefined thresholds. For example, if CPU utilization exceeds 80%, the system can simulate scaling up by adding more CPU cores to the resource pool. Conversely, if utilization drops below 20%, it can scale down. The system can also address resource fragmentation, a state where a lack of contiguous resources prevents larger jobs from running, even if the total available resources are sufficient. This is handled by a defragmentation algorithm that might involve preempting and rescheduling jobs to consolidate resources. 6. Integration with Cloud Providers: Finally,
3.2.4. Resource Allocation and Scheduling CloudyGUI’s resource allocation and scheduling system is designed to efficiently manage and distribute resources to jobs, mirroring the behavior of real-world cloud schedulers. This phase is crucial for simulating resource contention and evaluating the performance of different scheduling policies. 1. Resource Tracking System: The core of this system is the Resource Pool, which maintains a real-time view of available, total, and allocated resources. It uses thread-safe mechanisms to ensure accurate, concurrent updates. When a job needs resources, the system attempts to reserve them 8
CloudyGUI’s framework is designed to simulate the interaction with a real-world cloud provider. A dedicated Cloud Resource Manager can simulate scaling actions by requesting or releasing cloud resources. This module translates scaling decisions into API calls, simulating the provisioning of new virtual machine instances or the termination of existing ones, which is essential for evaluating auto-scaling strategies.
the gap between workload generation and actionable insights. 3.2.6. Post-Generation Processing Post-generation processing in CloudyGUI is a critical phase for ensuring the validity and integrity of the simulated workload before it is used for analysis or testing. This phase performs a series of checks to confirm that the generated workload is within the defined system constraints.
3.2.5. CSV Generation and Output Structure CloudyGUI’s CSV generation process is a robust data management system designed to capture a simulated workload in a structured format. This process ensures that the complex hierarchical data of jobs, tasks, and instances is flattened into a single file suitable for in-depth analysis.
1. Workload Validation: The system conducts a thorough validation of the generated workload to ensure it follows all predefined constraints. It performs System Constraints Verification to check if any job’s resource requirements (e.g., CPU, memory) exceed the system’s maximum limits. It also performs Temporal Validation to ensure that all time-based events, such as job start and end times, are logically sound and that no task starts before its parent job. 2. Resource Allocation Verification: A key validation check is to prevent resource overallocation. The system processes a timeline of all job start and end events to calculate the total resource usage at every moment during the simulation. It then compares this peak usage against the system’s total capacity for each resource (CPU, memory, GPU, etc.). This verification ensures that the generated workload does not demand more resources than the simulated system can physically provide at any given time, thus confirming the feasibility of the generated workload. 3. Dependency Management: The system enforces job dependencies through a straightforward dependency tracking mechanism. Each job maintains a list of job IDs it depends on, which is validated during workload generation. The verifier ensures that no job starts before its dependencies complete by checking that all dependent jobs are in the ’terminated’ state. The workload generator creates realistic dependency chains between jobs of different types while ensuring no circular dependencies are formed by only allowing dependencies on jobs created earlier in the sequence. 4. System Metrics Collection: The system tracks and analyzes various metrics to evaluate prediction performance and system behavior. Key metrics include Mean Squared Error (MSE), Root Mean Squared Error (RMSE), Mean Absolute Error (MAE), R-squared (R2 ), and Mean Absolute Percentage Error (MAPE). These metrics are calculated by comparing actual resource usage against predicted values, with special handling for edge cases like zero actual values to prevent division errors. The system also tracks explained variance to assess prediction quality. 5. Summary Report and Visualization Generation: CloudyGUI generates a detailed summary report that consolidates all validation results and key statistics into a single file. The system also automatically generates utilization plots using libraries like Matplotlib. For interactive analysis, key summaries and visualizations are rendered on the GUI’s workload page using Chart.js. These visualizations show resource usage over time, with
1. File Generation Process: The process begins with an initialization step where the CSV file is created and a comprehensive set of headers is written. These headers cover information at the job, task, and instance levels, as well as additional details like dependencies. Following initialization, the system collects data from each component of the workload hierarchy. Job-level data, including ID, type, status, and resource requirements, is gathered first. This information is then integrated with data from its tasks and, subsequently, from each individual instance. 2. Hierarchical Data Flattening: To translate the multilevel job structure into a flat CSV format, CloudyGUI employs a data flattening technique. It first collects a job’s core data, then systematically adds task-level information to that data, and finally integrates instance-specific details. This results in each row of the CSV file representing a single instance, but containing all the contextual information from its parent task and job. This approach ensures that the relationships and properties of the entire workload are preserved in a single, accessible record. 3. CSV Writing Strategy: The system implements a reliable CSV writing strategy that ensures data integrity and handles concurrent access. It writes forecast data to a CSV file in the project’s results directory using atomic writes with a temporary file that’s renamed upon successful completion, preventing partial writes. The implementation automatically creates necessary output directories, verifies write permissions, and includes comprehensive error handling and logging. Timestamps are preserved as the index in the output CSV for time-series analysis. 4. Data Validation and Analysis Integration: The system ensures data integrity through post-processing steps that validate the generated CSV. This includes data type conversion, where fields are cast to their correct types, and data sanitization to handle missing or improperly formatted fields. The structured output is designed for seamless integration with data analysis tools. For example, the CSV file can be easily loaded into a Pandas DataFrame for advanced statistical analysis, allowing researchers to quickly calculate key metrics like total jobs, average job duration, and overall resource utilization. This integration bridges 9
(a) Isolated Transformation: Feature scaling is performed using a fit_transform operation exclusively on the training partition. The test partition is subsequently processed using transform with the training set’s statistics, ensuring that global distribution metrics (mean, variance) from the future do not leak into the training process. (b) Safe Feature Generation: Rolling statistics (e.g., 3hour mean) are calculated using a fixed window on shifted data (Lagt−1 ) within each fold. This guarantees that the feature vector at any time t is derived solely from historical data (t − k to t − 1). (c) Strict Chronological Validation: We employ TimeSeriesSplit for cross-validation, which respects temporal ordering by ensuring that each training fold only accesses data preceding the validation index. This strictly avoids the use of future information during interpolation or resampling. 4. Model Architecture and Training: The framework uses various predictive models, including gradient boosting regressors such as XGBoost, and deep learning models such as Long Short-Term Memory (LSTM) networks. Since XGBoost has shown strong performance in our preliminary comparative analysis and is well-suited for timeseries forecasting [55], we chose to focus on it for our primary predictions. Specifically, our own previous work demonstrated the efficacy of XGBoost in workload prediction, where it achieved superior results (e.g., an R2 value of 0.97967 for CPU utilization) compared to baseline models. The training pipeline uses a chronological data split to simulate a realistic scenario where models are trained on past data and evaluated on entirely unseen future data. Specifically, for a given 7-day workload, the initial 80% of the data (approximately 5.6 days) is allocated for training, while the final 20% (approximately 1.4 days) is reserved for testing. The training process incorporates callbacks like early stopping to prevent overfitting and ensure the models generalize well. 5. Resource Prediction: Formally, the resource prediction is modeled as a supervised regression task where the objective is to map an input feature vector Xt at time t to a predicted resource utilization ŷt+1 (e.g., CPU, Memory). Based on our feature engineering pipeline, the input vector Xt is defined as:
horizontal lines indicating the system’s total capacity, which helps researchers visually identify periods of high and low utilization and spot potential bottlenecks. The generated report and plots provide the necessary insights to understand the workload and to inform the development of predictive and auto-scaling algorithms. 3.3. Resource Prediction This section details the predictive modeling framework used in CloudyGUI to forecast resource demands. The system’s ability to accurately predict future workload allows for proactive resource management, a key component of efficient auto-scaling. 1. Data Collection and Preprocessing: The system loads resource metrics from CSV files, focusing on numeric data columns and timestamps. The preprocessing pipeline includes several key steps: First, it identifies and parses timestamp columns, converting them to datetime objects. For data cleaning, it employs an IQR-based outlier detection method to identify and remove statistical outliers, replacing them with NaN values. While this statistical approach is robust for general noise, recent studies highlight the effectiveness of error distribution smoothing (EDS) for imbalanced regression in low-dimensional time series [54]. This method offers a pathway to enhance prediction fidelity in volatile environments. Missing values are then handled through a three-step process: (1) linear interpolation between existing values, (2) forward-filling of any remaining NaNs, and (3) backward-filling of any remaining NaNs at the beginning of the dataset. The data is resampled to hourly intervals using mean aggregation, and the system includes comprehensive logging at each preprocessing step to track data quality issues and processing outcomes. 2. Feature Engineering: To enhance prediction accuracy, a comprehensive set of features is engineered from the preprocessed time-series data. This includes: • Time-based Features: Extraction of temporal attributes such as the hour of the day, day of the week, and weekend flags to capture cyclical patterns in workload behavior. • Statistical Features: Calculation of rolling statistics (mean, standard deviation, and maximum) over various time windows (e.g., 5, 15, and 60 minutes) to capture short-term trends and volatility.
Xt = [Tt , Lag1h (y), Lag24h (y), µ3h (y)]
3. Data Leakage Prevention: To strictly prevent lookahead bias and to ensure that our R2 values reflect genuine predictive power, we implemented a robust pipeline that enforces temporal causality. We utilize a time_series_train_test_split strategy where the data split occurs before any feature engineering. Specifically, we adhere to the following protocols:
(1)
where: • Tt represents the temporal features: {hour, day_of_week, day_of_year, month}. • Lagk (y) denotes the historical utilization values at time t − k. • µ3h (y) is the 3-hour rolling mean used to capture short-term trends.
Look-ahead bias occurs when future information is inadvertently used in model training or validation, leading to overly optimistic performance estimates.
For the primary XGBoost model, the learning objective is to minimize the regularized squared error loss: 10
L(ϕ) =
X X (yi − ŷi )2 + Ω( fk ) i
The system continuously evaluates its own performance through model monitoring and can retrain models if their prediction accuracy degrades, ensuring the Analyze phase remains reliable. The framework is also designed to be extensible, with support for different cloud providers for the Execute phase.
(2)
k
Here, the first term represents the Mean Squared Error (MSE) between the actual (yi ) and predicted (ŷi ) usage, and Ω( fk ) serves as the regularization term to penalize tree complexity and prevent overfitting. The model was trained with n_estimators = 100 and a learning rate of 0.1. 6. Model Evaluation and Monitoring: The performance of the predictive models is evaluated using standard regression metrics, including Mean Absolute Error (MAE), Root Mean Squared Error (RMSE), and the coefficient of determination (R2 ).
Overall, the system provides an efficient and reliable way to manage cloud resources by using predictive intelligence within a self-managing MAPE loop to maintain performance and control costs. 3.5. Simulated Auto-scaling The predictive threshold-based system demonstrated the feasibility of proactive resource management using real-time metrics and forecasting models. However, its reliance on actual cloud providers introduced constraints in terms of cost, repeatability, and experimental control. To overcome these limitations and enable rigorous evaluation of scaling policies under diverse workload scenarios, we transitioned to a fully simulated environment. This simulation framework abstracts the behavior of cloud infrastructure and allows deterministic experimentation with auto-scaling logic. It preserves the core principles of the MAPE loop by monitoring synthetic workloads, analyzing resource metrics, and planning scaling actions. These actions are then executed within a controlled virtual setup, offering fine-grained control over timing, state transitions, and feedback loops. The following components collectively form the backbone of this simulated auto-scaling system.
3.4. Predictive Threshold-Based Auto-scaling This system has an automated control mechanism that uses predicted future resource usage to proactively adjust cloud resources. Instead of reacting to a problem that has already occurred, it anticipates future needs. The entire process is structured around a MAPE control loop, a fundamental framework for autonomous systems. 1. Core Components: The system’s architecture consists of several integrated services that correspond directly to the MAPE loop phases: • Monitor Service: This component handles the Monitor phase, continuously gathering real-time resource metrics like CPU, memory, and network I/O. • Prediction Engine: This is the core of the Analyze phase, using forecasting models (e.g., XGBoost, LSTM) to predict future resource needs based on the data collected by the monitor.
1. SimulationRunner: The SimulationRunner is the central controller that governs the entire simulation process. Its primary role is to manage the simulation’s lifecycle, timing, and data aggregation.
• Decision Engine: This component executes the Plan phase. It applies scaling rules and thresholds to the predictions to determine if an action is needed. This logic uses a decision matrix to handle various scenarios, such as making an aggressive scale-up if a critical threshold is predicted to be breached.
• Lifecycle and Execution Flow Management: The runner initiates the simulation based on a given configuration file. It is responsible for the setup (initializing the mock cloud provider and scaling engine), execution (running the main simulation loop for a predetermined duration), and termination. It controls the simulation’s clock, advancing time in discrete steps. At each time step (e.g., every 30 seconds), it directs the sequence of events: triggering the workload generator, instructing the mock cloud provider to update its instance metrics, and invoking the scaling engine to evaluate the current state. This precise control over the execution flow ensures that experiments are deterministic and reproducible, which is critical for academic research.
• Executor Service: This service performs the Execute phase, carrying out the planned scaling actions by communicating with the underlying cloud provider to provision or de-provision resources. 2. Scaling Logic: The system uses a predictive thresholdbased approach to make decisions. Thresholds have predefined upper and lower utilization limits, while the Prediction Engine forecasts resource usage for future time windows. The Decision Engine then analyzes these predictions against the thresholds to determine the necessary action. This scaling approach aligns with recent deep learning-based auto-scaling frameworks for Service Function Chains in cloud environments [32]. 3. Implementation and Advanced Features: The implementation includes features like adaptive thresholds, which automatically adjust based on historical patterns, and cost optimization to balance performance with cost.
• Data Collection and Logging: Throughout the simulation, the SimulationRunner serves as the primary data logger. It systematically records every event and state change, including the generated workload intensity, the resource metrics reported by the cloud provider (CPU, memory usage), the decisions made 11
by the scaling engine, and the number of active instances. This comprehensive data collection is foundational for the post-simulation analysis, as it provides the raw material for generating plots, calculating performance statistics, and validating the effectiveness of the tested scaling policy.
state before being removed. This state tracking is crucial because it accurately models the real-world lag between a scaling decision and its effect on the system’s capacity. • Dynamic Resource Metrics Provision: The most critical function of the MockCloudProvider is to supply the scaling engine with realistic resource metrics. These metrics are not static; they are dynamically calculated at each time step based on the current synthetic workload and the number of instances in a running state. For example, if the workload increases while the instance count remains the same, the provider will report a higher average CPU utilization. This creates the essential feedback loop for the auto-scaling logic: the environment’s state changes in response to the workload, and the scaling engine reacts to those changes.
• Resource Usage Mapping: To ensure high-fidelity simulation, CloudyGUI maps abstract workload tasks to concrete resource utilization metrics (CPU, Memory, Disk, GPU) using a profile-based dynamic model. As defined in the TASK_TYPES configuration in Section 3.2.2, distinct workload categories exhibit unique resource footprints. For example, Model Training tasks are CPU/GPU intensive (utilizing 70– 100% CPU and 80–100% GPU), whereas Data Ingestion tasks are I/O bound (utilizing 70–90% Disk). The real-time utilization Ur (t) for a specific resource r during a task’s execution is calculated dynamically based on its progress and a stochastic noise factor. The mapping function is defined as: telapsed +δ Ur (t) = Creq × αmin + (αmax − αmin ) × T duration
3. EnhancedScalingEngine: The EnhancedScalingEngine is the brain of the auto-scaling system. It encapsulates the logic and policies that are the subject of the research. Its sole responsibility is to analyze the state of the system and make intelligent scaling decisions.
!
• Implementation of Scaling Policies: This is where the core scaling algorithm is implemented. In its basic form, the policy is based on thresholds: if the average resource usage exceeds a scale_up_threshold (e.g., 70%), the engine decides to add instances. If usage falls below a scale_down_threshold (e.g., 40%), it decides to remove instances. However, this engine is designed to be "enhanced," meaning researchers can implement more sophisticated policies, such as predictive algorithms that analyze trends in resource usage to scale proactively, or multi-metric policies that consider CPU, memory, and network latency simultaneously.
where: – Creq is the allocated resource capacity (e.g., 4 vCPUs). – [αmin , αmax ] is the resource pattern range defined for the specific task type (e.g., [0.4, 0.8] for data ingestion). t represents the task completion progress – Telapsed duration (0.0 to 1.0). – δ ∼ Uniform(−0.05, 0.05) introduces stochastic fluctuation to mimic real-world volatility. This mapping ensures that resource metrics accurately reflect the lifecycle of the underlying tasks, including ramp-up phases and varying intensity, rather than static allocation.
• Constraint Handling: Beyond simple decisionmaking, the engine is responsible for enforcing realworld operational constraints. The most important of these is the cooldown period. After a scaling action is initiated, the engine enters a cooldown phase during which it will not make further scaling decisions. This prevents system instability known as "thrashing", where the system rapidly scales up and down in response to short-term metric fluctuations. By handling these constraints, the engine ensures that its decisions are not just logically sound but also practical and safe for a production environment.
2. MockCloudProvider: The MockCloudProvider is a highfidelity abstraction of a real-world cloud infrastructure provider (like AWS EC2 or Google Compute Engine). Its purpose is to create a realistic, yet fully controlled and cost-free, environment for the scaling engine to operate within. • Infrastructure and State Simulation: This component simulates the core behaviors of a cloud environment. When the scaling engine requests a new instance, the MockCloudProvider does not provision a physical server. Instead, it simulates the process by creating a virtual instance object and transitioning it through realistic states: from pending to running. This includes modeling the inherent delays associated with instance boot-up times. Similarly, when an instance is terminated, it moves to a terminating
In summary, CloudyGUI provides a modular and controllable environment for simulating auto-scaling strategies under varied conditions. Its integration of realistic workload generation, predictive modeling, and a structured simulation loop supports reproducible experimentation and policy evaluation. 12
4. Results and Analysis Job Type Distribution
This section presents a detailed analysis of the simulation results generated by CloudyGUI, demonstrating the framework’s effectiveness in modeling and managing dynamic cloud workloads. The findings are organized into three subsections that directly correspond to our core methodology: an evaluation of the Workload Generation component, an analysis of the Resource Prediction model’s accuracy, and a demonstration of the Predictive Auto-scaling system’s performance.
analytics data_processing
9.9% 30.3%
batch_processing 14.8%
19.9% 25.1%
4.1. Workload Generation This section analyzes the characteristics of the workload produced by the CloudyGUI framework to validate its complexity and realism. The generated workload is composed of a diverse set of jobs and tasks, designed to rigorously test the performance of cloud scheduling and auto-scaling algorithms. To ensure a comprehensive output, the generated workload is captured in a structured format, the metadata structure of which is detailed in Table 2. Organized hierarchically, each row in the final output file represents a single instance while retaining the full context of its parent task and job. This structure is designed to capture all essential attributes for evaluation, including unique identifiers for tracing (e.g., Job ID, Instance ID), scheduling parameters like priority and dependencies, and the crucial distinction between requested resources (e.g., CPU Required) and actual measured usage (e.g., CPU Usage). This multi-level dataset provides the necessary granularity for indepth analysis of system behavior, scheduler performance, and the effectiveness of resource management strategies. We configured the workload generator with 10,000 jobs, 5 tasks per job, and 5 instances per task to derive the following graphs. Figure 3 illustrates the proportional distribution of job types within the generated workload. The composition is diverse, with a significant share of ’data_processing’ (30.3%) and ’machine_learning’ (25.1%) jobs, reflecting common, resource-intensive cloud use cases. This heterogeneity is a direct result of the weighted selection process and ensures the simulation is representative of a varied cloud environment. Figure 4 displays the distribution of job priorities. The number of jobs is nearly uniform across all five priority levels, which is essential for an unbiased evaluation of priority-aware scheduling policies by ensuring a balanced contention scenario between high and low-priority tasks. Figure 5 confirms the structural integrity of the generated jobs by providing a breakdown of the task types that constitute each job type. For instance, it shows that ’machine_learning’ jobs are composed of tasks like ’data_preprocessing’, ’training’, and ’evaluation’. The aggregate frequency of each task type across the entire workload is shown in Figure 6, where ’processing’ and ’data_preparation’ are the most common, underscoring the data-intensive nature of the simulation. Finally, the heatmap in Figure 7 visualizes the relationship between task types and their assigned priorities. The data confirms that priorities are well-distributed across all task types, preventing any single category from being systematically
web_service
machine_learning
Figure 3: Distribution of Jobs
Job Priority Distribution 17500
Number of Jobs
15000 12500 10000 7500 5000 2500 0
1
2
3 Priority Level
4
5
Figure 4: Priority Distribution of jobs
favored and thus creating a challenging and realistic scenario for evaluating advanced scheduling algorithms. Furthermore, the efficiency of resource consumption is summarized in Figure 8. The median utilization for CPU and Memory was approximately 85% and 75%, respectively, with significant variance indicating periods of both high and low usage. Figure 9 validates the simulation’s physical constraints by plotting instance CPU usage against the host VMs CPU capacity. As expected, all data points fall on or below the main diagonal, confirming that no instance exceeded the resources assigned to its VM. Figure 10, quantifies resource saturation events and the results show that over 40,000 instances became CPU-saturated, while none reached memory saturation. This identifies the workload as heavily CPU-bound, meaning processing power is the primary limiting resource, a crucial characteristic for testing resource provisioning strategies. Finally, Figure 11 presents the concurrency profile over the 7-day simulation period, plotting the number of active instances 13
Table 2: Hierarchical Metadata Schema for Generated Workloads
Attribute Job ID Job Type Task ID Task Type Priority Dependencies Dependency Types Instance ID Instance Status Instance Start Time Instance End Time CPU Required CPU Usage Memory Required (MB) Memory Usage (MB) GPU Required GPU Usage Disk Required (GB) Disk Usage (GB) VM ID VM CPU VM RAM VM GPU
Description Job Information Unique identifier for each job. Category or classification of the job. Unique identifier for each task within a job. Category of the task. Priority level of the job/task. Dependencies List of task IDs this task depends on. Types of dependencies between tasks. Instance Information Unique identifier for the compute instance. Current state of the instance (e.g., running, completed, failed). When the instance started processing. When the instance finished processing. Resource Requirements Number of CPU cores requested. Actual CPU cores used. Memory requested in MB. Actual memory used in MB. Number of GPUs requested. Actual GPUs used. Disk space requested in GB. Actual disk space used. Virtual Machine Details Identifier for the virtual machine. Total CPU cores available on the VM. Total RAM available on the VM in MB. Total GPUs available on the VM.
over time. The plot reveals a highly dynamic environment, with concurrent instances fluctuating between approximately 500 and 900. This non-static, fluctuating demand profile confirms that the generated workload provides a realistic and challenging testbed for evaluating the responsiveness and efficacy of auto-scaling systems.
for CPU, memory, GPU, and disk utilization, as illustrated in Figures 12, 13, 14, and 15, closely follow the actual usage patterns. It effectively captures the frequent, sharp spikes and subsequent drops that are characteristic of interactive workloads. The model’s ability to anticipate these volatile changes is crucial for proactive auto-scaling, as it allows the system to provision resources before a performance bottleneck occurs. The accuracy across all resource types is a significant validation point, confirming that the predictive framework can provide the necessary intelligence for making sound scaling decisions.
4.2. Resource Prediction The resource prediction phase is a critical component of CloudyGUI’s proactive auto-scaling system, representing the "Analyze" stage of the MAPE loop. This section presents a visual analysis of the predictive model’s performance, showcasing its ability to forecast future resource utilization across different resource types. As a single-step forecasting model, the system is designed to predict resource usage in the near future. The performance is evaluated by observing how closely the predicted values track the actual resource usage over time.
4.2.1. Comparative Analysis of Forecasting Models To validate the superiority of our XGBoost-based approach, we benchmarked the proposed model against standard forecasting baselines for both CPU and Memory utilization. As shown in Table 4, traditional statistical methods struggle with the volatility of cloud workloads, whereas the proposed model maintains high precision across different resource types.
Analysis of Prediction Accuracy. The predictive model demonstrates a strong capability in forecasting resource usage across all key metrics. As seen in Table 3, the model achieves high R2 and EVS scores, all above 0.96, indicating a strong relationship between predicted and actual values. The predicted values
• Naïve Approaches: The Naïve (Last-Value) and Seasonal Naïve models produced negative R2 scores across the board (e.g., -11.05 for Naïve Memory prediction). This confirms that the workload is highly non-stationary and 14
Task Type Distribution per Job Type Task Type aggregation analysis backend data_collection data_preparation data_preprocessing database evaluation frontend processing training visualization
25000
Number of Tasks
20000 15000 10000 5000
ice we b_s
erv
arn ing _le ma
ba
da
tch
ta_
ch ine
pro c
_pr oc e
an aly
tic
s
ssi ng
ess ing
0
Job Type
Figure 5: Compositional breakdown of task types per job
Table 3: Prediction Results Summary
Resource
RMSE
MSE
MAE
R2
EVS
GPU CPU Memory Disk
0.062659 2.773768 12.073929 70.037719
0.003926 7.693787 145.779770 4905.282013
0.024194 1.634416 7.214408 45.585369
0.997014 0.986673 0.983097 0.962239
0.997016 0.986682 0.983097 0.962262 Task Type vs Priority Heatmap
processing data_preparation aggregation evaluation training analysis visualization data_preprocessing data_collection frontend backend database
Task Type
Task Type
Task Type Distribution
0
2000
4000 6000 Number of Tasks
8000
aggregation
1786
1830
1758
1779
1773
analysis
1489
1549
1341
1596
1564
backend
1227
1243
1190
1116
1169
data_collection
1481
1397
1392
1349
1649
data_preparation
1869
1726
1758
1896
1975
data_preprocessing
1332
1553
1523
1652
1435
database
1161
1024
1330
1145
1212
evaluation
1490
1591
1319
1615
1626
frontend
1231
1272
1234
1190
1234
processing
1967
1773
1772
1795
1957
training
1493
1548
1392
1660
1521
visualization
1584
1427
1362
1554
1582
1
2
3 Priority Level
4
5
1800
1600
1400
1200
Figure 7: Heatmap visualizing the relationship between task types and Priorities
Figure 6: Aggregate frequency of each task type across the entire workload
ing the presence of a linear trend. However, its error rates remain prohibitively high for auto-scaling. For Memory prediction, Linear Regression yielded an RMSE of 53.46 MB, which is four times higher than the proposed model. ARIMAX (AutoRegressive Integrated Moving Average with
cannot be predicted by simple persistence or fixed lagbased seasonality. • Linear Models: Linear Regression achieved relatively high R2 scores (0.86 for CPU, 0.89 for Memory), suggest15
Resource Utilization Efficiency (%)