<figure><img src="image_1.png" /></figure>

HAL
open science

# ACADS: A Framework for Adaptive Cost-Aware Deployment of Stream Processing System in the Cloud

Farah Ait-Salaht, Laëtitia Della Maestra, Daniel Wladdimiro

► To cite this version:

Farah Ait-Salaht, Laëtitia Della Maestra, Daniel Wladdimiro. ACADS: A Framework for Adaptive Cost-Aware Deployment of Stream Processing System in the Cloud. 13th IEEE International Conference on Cloud Engineering, Sep 2025, Rennes, France. hal-05281010

HAL Id: hal-05281010

https://hal.science/hal-05281010v1

Submitted on 24 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# ACADS: A Framework for Adaptive Cost-Aware Deployment of Stream Processing System in the Cloud

Farah Aït-Salaht*, Laëtitia Della Maestra*, Daniel Wladdimiro*

farah.ait_salaht@devinci.fr, laetitia.della_maestra@devinci.fr, daniel.wladdimiro@devinci.fr

*De Vinci Higher Education, De Vinci Research Center, Paris, France

**Abstract**—The increasing volume of data from Internet of Things (IoT) devices, digital services, and user interactions has made cloud-based Stream Processing Systems (SPS) essential for real-time analytics. A primary challenge in deploying SPS in the cloud is efficiently provisioning resources: both the replication degree of each operator and the selection of virtual machines (VMs)—in type and quantity—must be carefully determined to balance performance and cost. In this work, we introduce ACADS (Adaptive Cost-Aware Deployment and Scaling), a unified planning model that formulates this provisioning task as a Constraint Satisfaction Problem (CSP). ACADS integrates logical and physical deployment decisions by jointly optimizing operator replication and VM placement, guided by workload characteristics and infrastructure constraints. Leveraging a queue-theoretic performance model and real-world pricing from Google Cloud Platform (GCP), ACADS minimizes a composite cost-latency objective. It supports dynamic, pre-execution planning by determining the necessary degree of operator parallelism, selecting cost-effective VM types, and computing optimal placements under CPU, memory, disk, and network constraints. Experimental results on synthetic workloads show that ACADS significantly improves resource utilization and reduces operational costs compared to heuristic baselines, providing a principled, adaptive approach for cloud-based SPS deployment.

**Keywords**—Stream Processing System, Cost-Aware, Cloud Computing, Constraint Satisfaction Problem, Operator Replication & Placement.

## I. INTRODUCTION

Exponentially increasing volumes of data streams, resulting from IoT infrastructures, digital services, and user interactions, define the current data-centric computing paradigm [1]. As a result, cloud computing has become the dominant paradigm for scalable data processing. In particular, a wide range of latency-sensitive applications rely on real-time processing of high-volume data streams to support tasks such as anomaly detection, trend analysis, and user personalized recommendations.

Stream Processing Systems (SPS) have emerged as a fundamental solution to this need by enabling data to be processed continuously as it is generated. These systems employ a directed acyclic graph (DAG) model [2], where vertices correspond to processing operators and edges represent dataflow over the DAG. To support scalability and low latency, operators can be replicated and distributed across multiple parallel instances. In cloud environments, this often means

that operators are distributed across multiple virtual machines (VMs) to meet performance and latency requirements. This distributed and parallel execution model allows SPSs to scale with input load, but it also introduces significant challenges in resource provisioning and deployment planning.

A challenge in this context is the allocation of resources within the SPS, as the amount of system load depends on the application or input rate [3]. On one hand, it is essential to determine the number of replicas required per operator to ensure reliable processing without degrading system performance. On the other hand, it is critical to determine the appropriate number of VMs needed to supply sufficient computational resources for the SPS to operate efficiently. Balancing performance and cost is non-trivial: over-provisioning incurs unnecessary costs, while under-provisioning can cause system overloads and performance degradation.

Most existing approaches to resource allocation rely on proactive, rule-based heuristics or simplistic assumptions that treat operator replication and VM allocation as separate, loosely coupled decisions. These strategies often fall short because they fail to address the complex interdependencies between logical and physical deployment decisions. Moreover, they typically neglect the varying pricing models of cloud infrastructures, which can significantly impact the total deployment cost. As a result, current solutions tend to be either inefficient in resource usage or ineffective at meeting application-level performance guarantees in a cost-effective manner.

In this work, we propose a unified deployment planning model for SPS that jointly addresses three key aspects: operator replication, virtual machine allocation, and cost optimization. Logically, our model computes the optimal number of replicas required for each operator based on the average input rate and service time. Physically, it determines the number and types of virtual machines needed from a predefined catalog (e.g., GCP n1-instances) and maps each operator replica to a suitable VM, taking into account resource capacities and pricing. This joint optimization captures the interplay between operator behavior and infrastructure provisioning, enabling more accurate and efficient deployment decisions.

Our main contribution is a cost-aware model, ACADS (Adaptive Cost-Aware Deployment and Scaling), which supports adaptive scaling, deployment, replica assignment, and
cost minimization while respecting both application and in-
frastructure constraints. ACADS formulates the provisioning
problem as a Constraint Satisfaction Problem (CSP) by in-
tegrating queue-theoretic performance modeling with cloud
pricing data to optimize a composite cost-latency objective
function. This model allows users to generate a globally op-
timized deployment plan before execution, thereby promoting
improved resource utilization and reducing operational costs.

The rest of the paper is organized as follows. Background concepts are presented in Section II. Section V discusses existing works from the literature on adaptive SPS. Section III presents our cost-aware model. Section IV describes our evaluation. Finally, Section VI concludes and outlines directions for future research.

II. STREAM PROCESSING SYSTEMS

Processing large amounts of data in real-time is the aim of SPS, according to [4]. A DAG represents SPS processing logic [5]. Each vertex in the DAG stands for a different operator in the SPS, and the unidirectional edges stand for the data flow. Typically, an operator is a simple task (e.g., counting, filtering, merging, etc.) that receives one or more data flows, processes them, and then sends the transformed data over its output DAG edges. There are two types of operators: *stateless* and *stateful*.

While the latter maintains a state based on previously
processed events, the former handles each event independently
from those before it. As a result, past events can affect how
current events are processed.

Additionally, each operator replica is connected to a thread, and an operator may have multiple replicas. They can therefore process the data concurrently. A data source provides the raw data stream for the operators to process over the DAG. While raw data may require cleaning, we assume a structurally homogeneous format-key-value tuples, as in [6].

When there are replicas, the data flow is divided and distributed among them. For instance, the Field Grouping approach uses the tuple's key to choose which replica will receive it, whereas the Shuffle Grouping approach sends tuples randomly to each replica and therefore guarantees load balancing. The disadvantage of the Field Grouping strategy is that load balance may not be achieved when key distributions are skewed. Other existing SPSs offer hash-based data partitioning [7], partial-key-based [8], or executor-centric [9] solutions to deal with the distribution problem.

An SPS logical design (DAG) example with an input data
source, three replicated operators, and multiple edges is shown
in Figure 1. The source provides the operator O<sub>A</sub> with the
raw data by partitioning the stream data input and sending it
to each of O<sub>A</sub>'s replicas (O<sub>A.1</sub>, O<sub>A.2</sub>, and O<sub>A.3</sub>). Following
data processing, O<sub>A</sub> transmits the processed data to O<sub>B</sub>, its
neighbour downstream in the DAG. Based on the grouping
technique, each operator processes the data sent to them and
then sends the processed output data to the next. In the absence
of an adjacent neighbour, data flow is stopped. O<sub>C</sub> is the final
operator to process the data in the figure.

<figure><img src="image_3.png" /><figcaption>Fig. 1. The SPS logical architecture.</figcaption></figure>

During physical deployment, the processing logic-typically
represented as a DAG must be mapped onto the execution
nodes of a distributed infrastructure such as a cluster, grid, or
cloud. This mapping is managed by a scheduling algorithm,
which assigns operators to available resources (e.g., cores or
virtual machines). However, this process may introduce load
imbalance. For example, a round-robin allocation strategy does
not guarantee uniform distribution of workload, as operator
complexity and resource heterogeneity can vary significantly
across the system. Even in environments with homogeneous
compute nodes, imbalance may arise due to uneven operator
behaviour or fluctuating input rates [10]. Figure 2 show an
example of mapping a DAG to physical resources (VMs of a
cluster).

<figure><img src="image_4.png" /><figcaption>Fig. 2. The SPS physical architecture.</figcaption></figure>

III. THE ACADS FRAMEWORK: COST-AWARE PLANNING FOR ADAPTIVE STREAM PROCESSING DEPLOYMENT

This section introduces the **ACADS** (*Adaptive Cost-Aware Deployment and Scaling*) framework, a comprehensive planning and optimization model for deploying adaptive stream processing applications in Cloud environments. By clearly articulating each decision step, ACADS tackles the critical
trade-off between minimizing infrastructure costs and maintaining low latency, thus delivering consistent performance across varying workloads. Leveraging a Constraint Satisfaction Problem (CSP) formulation, ACADS provides a rigorous method for determining both operator replication and virtual machine allocation under cost and performance constraints.

The rest of this section is structured as follows: we first define the deployment planning problem and its key components. We then detail the Cloud-based cost model used, followed by the formal CSP formulation, the optimization objectives, and the solving strategy adopted to find globally optimal deployment configurations.

For improved readability, the main parameters used in the formulation are summarized in Table I.

<table><caption>TABLE I
TABLE OF SYMBOLS AND NOTATION.</caption><thead><tr><th colspan="2">Infrastructure and Cost Parameters</th></tr></thead><tbody><tr><td>V</td><td>Set of available VM types, indexed as V<sub>j</sub></td></tr><tr><td>U(V<sub>j</sub>)</td><td>Resource capacity of VM V<sub>j</sub>: U(V<sub>j</sub>) = &lt;CPU(V<sub>j</sub>), RAM(V<sub>j</sub>), etc.&gt;</td></tr><tr><td>Limit(V<sub>j</sub>)</td><td>Maximum number of VMs of types V<sub>j</sub></td></tr><tr><td>C(V<sub>j</sub>)</td><td>Hourly cost of VM type V<sub>j</sub></td></tr><tr><th colspan="2">Application and Workload Model</th></tr><tr><td>O<br>u(i)</td><td>Set of processing operators (e.g., {o<sub>1</sub>, o<sub>2</sub>, ..., o<sub>n</sub>})<br>Resource demand of operator o<sub>i</sub>: u(i) = &lt;REQCPU(o<sub>i</sub>), REQRAM(o<sub>i</sub>), etc.&gt;</td></tr><tr><td>&lambda;<sub>i</sub></td><td>Input arrival rate to operator o<sub>i</sub> (tuples/sec)</td></tr><tr><td>&mu;<sub>i</sub></td><td>processing rate of a single replica of o<sub>i</sub> (tuples/sec)</td></tr><tr><th colspan="2">Decision Variables</th></tr><tr><td>r<sub>i</sub></td><td>Number of replicas provisioned for operator o<sub>i</sub></td></tr><tr><td>x<sub>j</sub></td><td>Number of VMs of type V<sub>j</sub> to provision</td></tr><tr><th colspan="2">Performance and Objective</th></tr><tr><td>W<sub>i</sub></td><td>Estimated waiting time (latency) for a replica of o<sub>i</sub></td></tr><tr><td>T<sub>W</sub></td><td>Total cumulative latency across all operators</td></tr><tr><td>T<sub>C</sub></td><td>Total hourly cost of all used VMs</td></tr><tr><td>&alpha;, &beta;</td><td>Weights for cost and latency in objective function</td></tr><tr><td>F</td><td>Scalarized objective function</td></tr></tbody></table>

## A. Challenges and Objectives in Dynamic Stream Deployment

Stream processing applications operate continuously under highly variable and unpredictable input rates, consequently requiring deployment strategies that are both cost-efficient and responsive, dynamically adapting to workload fluctuations. On the one hand, uncontrolled resource usage drives up Cloud bills, wastes capacity, and can even incur overage penalties; on the other, insufficient provisioning risks SLA breaches, data loss, and degraded user experience. The primary challenge addressed by ACADS lies in solving a joint optimization problem: (i) determining the optimal number of replicas for each operator in the dataflow application, and (ii) placing these replicas across a heterogeneous VM pool to minimize costs while ensuring acceptable latency levels.

In particular, cost optimization must account not only for hourly VM rates but also for storage charges, network egress fees, and the overhead of frequent scaling actions. At the same time, performance optimization demands that queuing delays remain below strict thresholds to support real-time analytics, anomaly detection, and interactive dashboards. Balancing

these two objectives is critical: overly aggressive cost cutting can introduce unacceptable latency spikes, whereas prioritizing latency without regard for cost can exhaust budgets and limit scalability.

ACADS offers a unified approach by combining a Cloud-oriented cost model (covering CPU, memory, storage, and network egress) with a queuing-theoretic performance model that directly estimates latency as a function of replication and load. By casting placement and scaling decisions into a single CSP, ACADS produces deployment plans that consistently balance infrastructure budgets against service-level objectives, even under rapidly changing workloads. This joint optimization enables operators to meet real-time processing requirements at minimal expense, by leveraging accurate scaling and allocation rather than following static heuristic rules.

## B. Cloud-Centric Cost Modeling Using GCP Pricing

To account for deployment cost, ACADS employs a Cloud-native pricing model derived from Google Cloud Platform (GCP). The total hourly cost of running a VM is computed as:

$$ \text{Total Cost per Hour} = C_{\text{VM}} + D \cdot p_{d} + V \cdot p_{r}, \quad (1) $$

where $C_{\text{VM}}$ covers the base hourly cost of the VM instance (covering both CPU and RAM usage), $D$ is the provisioned disk size in gigabytes, $p_{d}$ the disk cost per gigabyte per hour, $V$ the volume of outgoing data in gigabytes, and $p_{r}$ the corresponding network egress price per gigabyte.

For our experimental evaluation, we adopt representative GCP rates: persistent disks are priced at approximately $0.04 per GB per month (or about $0.0000556 per GB per hour), while network egress costs are set at $0.12 per GB.<fnref n="1" /> These rates may vary with volume discounts and region-specific pricing, which ACADS can accommodate by updating $p_{d}$ and $p_{r}$ accordingly.

## C. A Constraint-Driven Model for Stream Deployment

ACADS formalizes the deployment problem as a Constraint Satisfaction Problem (CSP), enabling modular integration of infrastructure, performance, and cost constraints.

**Infrastructure.** The Cloud environment provides a finite set of virtual machine types, denoted by $V = \{V_1, V_2, ..., V_m\}$. Each VM type $V_j$ is characterized by a fixed resource configuration and an associated hourly cost. The resource capacity of a VM is represented as $U(V_j) = \langle CPU(V_j), RAM(V_j) \rangle$, while its cost per hour, $C(V_j)$, is determined using the pricing model in Equation 1. Furthermore, the number of available instances for each VM type is constrained by an upper bound $\text{Limit}(V_j)$, which specifies the maximum number of VMs of type $V_j$ that can be provisioned.

**Application.** The stream processing application is composed of a set of operators $O = \{o_1, o_2, ..., o_n\}$. Each operator $o_i$ receives an input stream at rate $\lambda_i$ and processes it at a rate $\mu_i$ per replica. A single replica of operator $o_i$ requires

<footnote n="1">¹Pricing source: https://cloud.google.com/compute/all-pricing</footnote>
a certain amount of computing resources, given by $u(o_i) = \langle \text{REQCPU}(o_i), \text{REQRAM}(o_i) \rangle$.

**CSP-based Deployment formulation.** To determine how these operators are deployed over the available infrastructure, we introduce two key decision variables. These variables capture, respectively, the level of replication assigned to each operator and the number and types of virtual machines provisioned to host those replicas. Formally, we define:

a) Decision Variables and Domains:

* Replication variable $r_i \in \mathbb{N}$. This variable denotes the number of replicas for operator $o_i$. The value of $r_i$ is bounded by a stability-aware upper limit:

$$1 \le r_i \le R_i^{\max} = \left\lceil \frac{\lambda_i}{\rho_{\min} \cdot \mu_i} \right\rceil, \quad \forall i \in \{1, \dots, n\}. \quad (2)$$

The upper bound $R_i^{\max}$ ensures that each replica operates under a maximum load threshold $\rho_{\min} \in (0, 1)$. It is derived from queueing theory [11], where the utilization of a replica is defined as $\rho_i = \lambda_i/(r_i\mu_i)$. By maintaining $\rho_i \le \rho_{\min}$, we ensure system stability and avoid performance degradation due to overloading (the ceiling guarantees that $r_i$ remains integer).

* VM provisioning $x_j \in \mathbb{N}$. This variable represents the number of VMs of type $V_j$ to provision, constrained by:

$$0 \le x_j \le \text{Limit}(V_j), \quad \forall j \in \{1, \dots, m\}.$$

b) Constraints: Based on these variables, the deployment solution must satisfy the following constraints:

* Resource Sufficiency (C1): Total provisioned resources must cover the sum of replica demands:

$$\sum_i r_i \cdot \text{REQCPU}(o_i) \le \sum_j x_j \cdot \text{CPU}(V_j),$$

$$\sum_i r_i \cdot \text{REQRAM}(o_i) \le \sum_j x_j \cdot \text{RAM}(V_j).$$

* VM Availability (C2): The number of instantiated VMs must respect their availability limits:

$$0 \le x_j \le \text{Limit}(V_j), \quad \forall V_j \in \mathcal{V}.$$

* Service Stability (C3): Each operator must operate below capacity to maintain system stability:

$$\frac{\lambda_i}{r_i \mu_i} < 1 \quad \text{for all } o_i \in \mathcal{O}.$$

c) Objective Function: The ACADS framework aims to minimize a scalarized cost-latency function.

* Latency Model. The response time of a replica of operator $o_i$ is estimated using the Allen-Cunneen approximation for $G/G/c$ queues [11]:

$$W_i = \frac{1}{\mu_i} + \frac{\alpha \cdot \left( \frac{\lambda_i}{r_i \mu_i} \right)^{\sqrt{2(r_i+1)}-1}}{r_i \left( 1 - \frac{\lambda_i}{r_i \mu_i} \right) \mu_i}, \quad \text{with } \alpha = \frac{C_a^2 + C_s^2}{2}.$$

Here, $C_a$ and $C_s$ denote the coefficients of variation of interarrival and service times, respectively.

The total latency across all services is:

$$T_W = \sum_i W_i. \quad (3)$$

* Cost Model. The total hourly infrastructure cost is computed as:

$$T_C = \sum_j x_j \cdot C(V_j). \quad (4)$$

**Composite Objective.** The overall deployment objective is expressed as a weighted sum:

$$\min \mathcal{F} = \alpha \frac{T_C}{T_C^{\max}} + \beta \frac{T_W}{T_W^{\max}}, \quad (5)$$

where $\alpha$ and $\beta$ represent the relative importance assigned to cost and latency, and $T_C^{\max}$, $T_W^{\max}$ are normalization constants derived from the search space.

In this work, we adopt an additive formulation [12] due to its simplicity, ease of implementation, and broad applicability across diverse deployment scenarios. While Pareto frontier analysis offers a finer understanding of trade-offs, we defer its full treatment to future work.

d) Solving Strategy and Optimization Methodology: ACADS aims to determine the optimal replica count for each operator and the corresponding VM allocation that minimizes the objective $\mathcal{F}$. To tackle this problem, we adopt Constraint Satisfaction Problem [13] formulation, which offers strong capabilities for modeling complex optimization problems and efficiently exploring large combinatorial spaces through domain reduction and constraint propagation.

The solution proceeds in two main phases. First, all feasible replica configurations $r_i$ that satisfy the stability constraint (C3) are enumerated. Then, for each such configuration, an Integer Linear Program (ILP) is solved to determine the minimum-cost VM assignment satisfying constraints (C1) and (C2). By explicitly enumerating the space of stable configurations and solving the corresponding ILP for each, our approach ensures that the final solution represents the global optimum with respect to the weighted objective $\mathcal{F}$. While the parameter space is combinatorially large, it is fully explored within the bounds defined by application constraints and the available resource pool. This exhaustive evaluation guarantees that the selected solution achieves the best trade-off between cost and latency under the given weights $(\alpha, \beta)$, offering a principled and transparent way to reflect application-specific priorities.

## IV. COST-EFFICIENT CLOUD RESOURCE ALLOCATION: A COMPARATIVE ANALYSIS

This section presents performance results related to the evaluation of ACADS and its ability to adapt to the dynamics of the event stream without degrading the rate of processed events. The evaluation is organized into two parts: a theoretical resource estimation based on the optimization model (Section IV-B), and an experimental validation performed on GCP infrastructure (Section IV-C).
## A. Study case

We have deployed an application composed of four operators which analyzes and classifies tweet events, as shown in Figure 3. The events (tweets) were previously collected from Twitter and extracted using the Twitter API. Events classification is based on the tweets' content and the identity of the person who has published them. Classified tweets are stored in a database.

<figure><img src="image_5.png" /><figcaption>Fig. 3. Twitter application in SPS.</figcaption></figure>

We used a traffic model based on data from Twitter related to COVID-19, with 237 million tweets [14]. However, we have considered only a sample of these tweets in the experiments, i.e., those in periods of the datasets that present high rate variation. In other words, we select a combination of traffic spikes and under spikes to compose the input traffic for the experiments. The methodology adopted to compose the testing dataset was introduced in [15]. Figure 4 presents the dataset. The purple line represents the actual data trace behavior, while the green line is the composed traffic employed in our tests.

<figure><img src="image_6.png" /><figcaption>Fig. 4. Traffic shape of Covid Twitter dataset.</figcaption></figure>

## B. Theoretical evaluation

In this subsection, we present a series of analyses based solely on the ACADS optimization model to demonstrate its responsiveness to workload dynamics, its cost-latency behavior, solver scalability, and its advantage over a fixed-VM baseline. All results are based on a 1259-point COVID-19 Twitter traffic trace, using equal cost and latency weights ($α = β = 0.5$). The experiments are conducted in a simulated environment reflecting the GCP public cloud, with a catalog of 17 distinct VM types, each offering 10 available instances, resulting in a total VM pool of 170 virtual machines.

1) **Provisioning Dynamics:** The first analysis examines how ACADS adjusts the number of operator replicas in response to the input rate. Figure 5 shows the incoming event rate alongside the total provisioned replicas. During major traffic

surges-around $t = 200$s, $t = 500$s, and $t = 800$s-ACADS increases the replica count to keep each operator below its utilization threshold. Conversely, during lulls near $t = 300$s, $t = 700$s, and $t = 1000$s, it aggressively reduces replicas to reclaim resources. This behavior reveals two key properties: (1) *elastic responsiveness*, as replica adjustments track rate changes with minimal delay; and (2) *cost awareness*, as the model avoids overprovisioning during low-load periods.

<figure><img src="image_7.png" /><figcaption>Fig. 5. Total Replicas as functions of workload fluctuations.</figcaption></figure>

2) **Cost-Latency Trade-Offs:** Figure 6 overlays hourly cost and end-to-end latency. Although traffic triples between the early and mid-trace peaks, cost increases by only 1.5×, reflecting efficient VM packing. Latency remains below the 50 ms SLA throughout. Notably, at two “knee points” ($t \approx 350$s and $t \approx 950$s), small cost increases (~5%) yield latency reductions of up to 20%. These points represent the most favorable cost-performance trade-offs and suggest that modest changes to the weighting parameter $α$ could further improve SLA adherence with minimal budget impact.

<figure><img src="image_8.png" /><figcaption>Fig. 6. Hourly cost and latency as functions of workload fluctuations.</figcaption></figure>

3) **Scalability and Solver Performance:** To assess the practicality of dynamic reconfiguration, we measured ACADS's solve time for each traffic snapshot, averaging over 100 runs to reduce solver variability. Figure 7 shows that each optimization
completes in under 50 ms, with solve times gradually increas-
ing from 20 ms at 1,000 events/s to 45 ms at 6,000 events/s.
This millisecond-scale performance confirms that the CSP-
based approach supports frequent invocation, on the order of
seconds, allowing continuous adaptation to workload changes
with negligible computational overhead.

<figure><img src="image_9.png" /><figcaption>Fig. 7. ACADS solve time (ms).</figcaption></figure>

4) *Comparison to Fixed Baseline "7×8vCPU"*: Finally, we compare ACADS's largest configuration, computed over the full input-rate dataset, with a naïve static deployment using seven identical VMs (8 vCPU, 7.2 GB RAM each), where replicas are evenly distributed until CPU saturation. Figure 8 shows CPU under-utilization over time: the static baseline averages only 50% usage, while ACADS's cost-aware plan—using two VMs with 16 vCPU and 14.4 GB RAM each—maintains utilization above 80% throughout.

<figure><img src="image_10.png" /><figcaption>Fig. 8. CPU utilization: 7×8vCPU vs. ACADS 's largest config (full dataset).</figcaption></figure>

Taken together, these results confirm that ACADS (i) adapts replica counts to second-scale load changes, (ii) contains costs even under extreme spikes, (iii) maintains latency SLAs across all scenarios, (iv) solves optimization problems in tens of milliseconds, and (v) significantly outperforms static provisioning in both cost and resource utilization.

C. Experimental Evaluation

This subsection presents the experimental validation of
ACADS using a deployment on Google Cloud Platform
(GCP).

1) *Evaluation Metrics*: We have defined three evaluation metrics.

*   *Throughput degradation:* this metric, also described in [16], aims at analyzing the behavior of the system in terms of throughput stability. It is defined by $\frac{|input_{rate}-output_{rate}|}{input_{rate}}$. If the metric value is close to 0, the system has a good stability. On the other hand, if it is close to 1, the system is not capable to process the input rate and the system is unstable.

* Latency: is the average time taken by an event between the moment it enters and leaves the SPS (end-to-end latency). This metric is relevant since SPSs are supposed to deliver real-time processed events.

* *Difference in the number of processed events:* is the difference between the total number of processed events and the total number of received events. It is an important metric since SPSs are used to process high volumes of data.

2) *Experiment Environment:* Experiments were conducted on the Google Cloud Platform (GCP) using a set of Virtual Machines (VMs). The cluster was composed of a three node for Zookeeper, a single node for Nimbus, and a variable number of Supervisor nodes depending on the deployment scenario. The VMs base were n1-standard-1 (1 vCPU, 2.2 GHz, 3.75 GB RAM) for Zookeeper and n1-standard-1 (4 vCPUs, 2.2 GHz, 15 GB RAM) for Nimbus.

To evaluate the impact of cost-aware deployment, we con-
sider two scenarios:

*   **Overprovisioning:** This setup includes a fixed allocation of seven n1-highcpu-8 Supervisor VMs which is based on work [17], independently of the actual workload or resource demand. It reflects a common practice in production environments where performance margins are prioritized over cost efficiency.

*   **ACADS:** In this setting, the number of Supervisor VMs is determined by ACADS, which estimates the minimum set of virtual machines required to meet the application workload while minimizing infrastructure costs. In our theoretical evaluation, the maximum number of Supervisor VMs used was two n1-highcpu-16 instances. This scenario aims to reflect a more resource-aware and cost-efficient deployment strategy.

3) *Cost Evaluation:* We analyze the deployment cost of both execution scenarios to validate the effectiveness of our optimization strategy. The objective is to demonstrate that ACADS can reduce infrastructure expenses while maintaining performance guarantees. Table II presents a cost evaluation of the deployment infrastructure on GCP, detailing the daily and hourly expenditures for each scenario. The results indicate a monthly cost reduction of approximately 36.7%, confirming the benefits of the proposed cost-aware deployment approach.

4) *Application Evaluation:* In this evaluation, the number of replicas per operator was set according to the peak traffic observed during the workload. This approach ensures the system is dimensioned to sustain the highest input rate, regardless of when it occurs, with a fixed replica count throughout execution. For the overprovisioned configuration, we used the
<table><caption>TABLE II
COST COMPARISON BETWEEN THE DIFFERENT SCENARIOS ON GCP.</caption><thead><tr><td>Scenario</td><td>Daily Cost (USD)</td><td>Hourly Cost (USD)</td></tr></thead><tbody><tr><td>Overprovisioning</td><td>$39.60</td><td>$1.6500</td></tr><tr><td>ACADS</td><td>$25.05</td><td>$1.0438</td></tr></tbody></table>

maximum number of replicas reported in the workload by [17]. In contrast, the ACADS configuration adopts the highest number of replicas derived dynamically from theoretical analysis (see Section IV-B), reflecting a more adaptive and cost-aware provisioning strategy.

<table><caption>TABLE III
EVALUATION METRICS COMPARISON BETWEEN THE DIFFERENT SCENARIOS.</caption><thead><tr><td>Scenario</td><td>Latency (ms)</td><td>Throughput Degradation</td><td>Total Events Processed</td></tr></thead><tbody><tr><td>Overprovisioning</td><td>161.54</td><td>0.0384</td><td>0.9649</td></tr><tr><td>ACADS</td><td>180.44</td><td>0.0495</td><td>0.9558</td></tr></tbody></table>

As demonstrated in Table III, the ACADS deployment achieves substantial infrastructure cost reductions compared to the overprovisioning scenario, while incurring only minor performance variations. These include modest increases in latency and throughput degradation (both under 12%) and a negligible drop in total events processed (under 1%). Consequently, ACADS offers a compelling cost-performance trade-off, cutting expenses while maintaining responsiveness and reliability at near-optimal levels.

## V. RELATED WORK

Two basic performance requirements for stream processing systems (SPSs) are application topology distribution and scalability. To address these, several SPSs have been developed that support adaptive resource usage. Apache Storm [18] provides mechanisms for resource reconfiguration, but typically requires user intervention and manual execution. In contrast, more recent systems like Apache Flink [19] and Apache Kafka [20] offer built-in mechanisms for dynamic scaling and resource adaptation, thus minimizing manual intervention.

Truong et al. [21] introduce a dynamic provisioning strategy for cloud-based SPSs, which adjusts CPU core allocations at runtime to balance resource usage and latency violations using a cost function. Their model, grounded in queueing theory, incorporates a stability mechanism to limit reconfiguration frequency. However, it does not address lower-level deployment aspects such as VM types or operator-to-node placement.

In the context of Apache Storm, Zhao et al. [22] propose CE-Storm, a cost-driven scheduling algorithm that evaluates task assignments based on a composite model incorporating resource consumption, energy usage, and inter-node communication overhead. Their solution includes monitoring and detection modules to prioritize execution nodes according to cost-efficiency, thus reducing system cost without compromising performance guarantees.

Kleiminger et al. [23] explore a hybrid deployment strategy that offloads processing from local resources to the cloud when queue thresholds are exceeded. Although they do not propose an explicit cost model, their approach implicitly targets cost reduction by minimizing unnecessary cloud usage. Processing in the cloud is performed at the window level using a MapReduce-style mechanism, enabling elastic scaling without overprovisioning local infrastructure.

A complementary perspective is offered by Truong et al. [24], who present a queueing-theoretic performance analysis methodology for distributed SPSs in the cloud. Their model captures operator behaviour using queuing theory and introduces effective utilization as a predictor of system stability. While the study omits cost considerations, it provides valuable guidance for system dimensioning and identifying throughput bottlenecks.

Henning and Hasselbring [25] benchmark modern stream processing frameworks deployed as microservices on Kubernetes. Their analysis reveals that while all frameworks scale with workload, performance characteristics vary considerably depending on architectural design and resource allocation.

Although not directly focused on SPS, recent work in the area of cloud computing addresses cost-aware deployment strategies that could be adapted to SPS environments. Rac and Brorsson [26] propose a scheduling and placement model for distributed applications in edge-cloud infrastructures, incorporating both computational and networking costs. Their approach includes initial placement heuristics based on latency and observed communication patterns, as well as a dynamic rescheduling mechanism that adapts to workload variations.

More directly related to our contribution, Cardellini et al. [27] formulate the joint optimization of operator replication and placement for distributed SPSs using a MILP approach focused on throughput maximization under latency constraints. Similarly, Aït-Salaht et al. [28] address operator replication and placement for IoT applications in Fog computing using a CSP formulation. However, both approaches aim to compute the exact placement of each operator replica over a set of physical nodes, while explicitly modeling the duplication and mapping of logical communication links onto the underlying infrastructure. This level of granularity introduces a high degree of combinatorial complexity and assumes relatively stable execution contexts. In Cloud-based SPS deployments, especially under elastic and pay-as-you-go models, a more critical challenge lies in dynamically selecting the number and types of virtual machines based on fluctuating workloads and heterogeneous pricing models. Thus, focusing on high-level resource provisioning decisions, rather than low-level link assignments, can offer better scalability, faster reactivity, and improved suitability for cost-sensitive, cloud-native environments. DSP operator replication across heterogeneous resources has also been investigated in recent efforts such as Ching et al. [29] and Russo et al. [30], which propose autoscaling frameworks for stream processing engines. These focus on hierarchical scaling and edge-aware deployment but rely on reactive heuristics rather than global optimization.
Existing solutions tend to address individual aspects of stream processing deployment—such as coarse-grained autoscaling rules, per-operator queueing analysis, or heuristic task placement-without offering a unified, fine-grained optimization that spans both replication and VM selection. In particular, most approaches either omit explicit modeling of heterogeneous VM costs (including storage and egress), lack formal latency guarantees under variable load, or rely on reactive heuristics with no bounds on reconfiguration latency. Our work fills these gaps by formulating the full deployment problem as a single optimization model, capturing end-to-end cost components and queuing-theoretic performance bounds, and demonstrating solver performance compatible with online adaptation.

## VI. CONCLUSION

In this paper, we have introduced ACADS, a unified framework that dynamically adapts cloud resources for stream processing systems under realistic workloads. By jointly optimizing operator replication and virtual machine selection, our approach stabilizes system performance while reducing infrastructure costs. Experimental results show that ACADS delivers significant cost savings with minimal performance loss, effectively balancing cost-efficiency and responsiveness in cloud environments.

Future work will extend the ACADS model with reliability and energy-efficiency objectives, and investigate how to "smooth" reactive scaling using techniques like hysteresis windows or minimum dwell times, to avoid jitter and oscillations, yielding a hybrid approach that remains responsive yet more stable and cost-effective.

## ACKNOWLEDGEMENT

Daniel Wladdimiro wants to thank to STIC-AmSud ITERATION-D project number 24-STIC-13.

## REFERENCES

[1] V. K. Prasad, D. Dansana, M. D. Bhavsar, B. Acharya, V. C. Gergiannis, and A. Kanavos, "Efficient resource utilization in iot and cloud computing," *Inf.*, vol. 14, no. 11, p. 619, 2023.

[2] S. Chakravarthy and Q. Jiang, *Stream Data Processing: A Quality of Service Perspective - Modeling, Scheduling, Load Shedding, and Complex Event Processing*, ser. Advances in Database Systems. Kluwer, 2009, vol. 36.

[3] X. Liu and R. Buyya, "Resource management and scheduling in distributed stream processing systems: A taxonomy, review and future directions," *ACM Computing Surveys*, vol. 1, no. 1, 2018.

[4] M. Kleppmann, *Making Sense of Stream Processing*. O'Reilly Media, Incorporated, 2016.

[5] P. Carbone, G. E. Gévay, G. Hermann, A. Katsifodimos, J. Soto, V. Markl, and S. Haridi, "Large-scale data stream processing systems," *Handbook of big data technologies*, pp. 219–260, 2017.

[6] H. Andrade, B. Gedik, and D. Turaga, *Fundamentals of Stream Processing: Application Design, Systems, and Analytics*. Cambridge University Press, 2014.

[7] M. A. Shah, J. M. Hellerstein, S. Chandrasekaran, and M. J. Franklin, "Flux: An adaptive partitioning operator for continuous query systems," in *ICDE*. IEEE Computer Society, 2003, pp. 25–36.

[8] M. A. U. Nasir, G. D. F. Morales, D. Garcia-Soriano, N. Kourtellis, and M. Serafini, "The power of both choices: Practical load balancing for distributed stream processing engines," in *ICDE*. IEEE Computer Society, 2015, pp. 137–148.

[9] L. Wang, T. Z. J. Fu, R. T. B. Ma, M. Winslett, and Z. Zhang, "Elasticutor: Rapid elasticity for realtime stateful stream processing," in *SIGMOD Conference*. ACM, 2019, pp. 573–588.

[10] M. Shahakar, S. A. Mahajan, and L. Patil, "A survey on various load balancing approaches in distributed and parallel computing environment," *International Journal of Intelligent Systems and Applications in Engineering*, vol. 11, no. 4, pp. 187–196, September 2023. [Online]. Available: https://ijisae.org/index.php/IJISAE/article/view/3511

[11] J. F. Shortle, J. M. Thompson, D. Gross, and C. M. Harris, *Fundamentals of queueing theory*. John Wiley & Sons, 2018.

[12] K. P. Yoon and C.-L. Hwang, *Multiple attribute decision making: an introduction*. Sage publications, 1995.

[13] P. R. Kotecha, M. Bhushan, and R. D. Gudi, "Efficient optimization strategies with constraint programming," *AIChE Journal*, vol. 56, no. 2, pp. 387–404, 2010.

[14] A. Gruzd and P. Mai, "COVID-19 Twitter Dataset," 2020. [Online]. Available: https://doi.org/10.5683/SP2/PXF2CU

[15] P. Bodík, A. Fox, M. J. Franklin, M. I. Jordan, and D. A. Patterson, "Characterizing, modeling, and generating workload spikes for stateful services," in *SoCC*. ACM, 2010, pp. 241–252.

[16] F. Lombardi, L. Aniello, S. Bonomi, and L. Querzoni, "Elastic symbiotic scaling of operators and resources in stream processing systems," *IEEE Trans. Parallel Distrib. Syst.*, vol. 29, no. 3, pp. 572–585, 2018.

[17] D. Wladdimiro, L. Arantes, P. Sens, and N. Hidalgo, "PA-SPS: A predictive adaptive approach for an elastic stream processing system," *Journal of Parallel and Distributed Computing*, vol. 192, p. 104940, 2024.

[18] A. Toshniwal, S. Taneja, A. Shukla, K. Ramasamy, J. M. Patel, S. Kulkarni, J. Jackson, K. Gade, M. Fu, J. Donham *et al.*, "Storm@ twitter," in *Proceedings of the 2014 ACM SIGMOD international conference on Management of data*. ACM, 2014, pp. 147–156.

[19] P. Carbone, A. Katsifodimos, S. Ewen, V. Markl, S. Haridi, and K. Tzoumas, "Apache flink™: Stream and batch processing in a single engine," *IEEE Data Eng. Bull.*, vol. 38, no. 4, pp. 28–38, 2015.

[20] B. Bejeck, *Kafka Streams in Action: Real-time apps and microservices with the Kafka Streams API*. Simon and Schuster, 2018.

[21] T. M. Truong, A. Harwood, R. O. Sinnott, and S. Chen, "Cost-efficient stream processing on the cloud," in *2019 IEEE 12th International Conference on Cloud Computing (CLOUD)*, 2019, pp. 209–213.

[22] H. Li, H. Fang, H. Dai, T. Zhou, W. Shi, J. Wang, and C. Xu, "A cost-efficient scheduling algorithm for streaming processing applications on cloud," *Clust. Comput.*, vol. 25, no. 2, pp. 781–803, 2022.

[23] W. Kleiminger, E. Kalyvianaki, and P. R. Pietzuch, "Balancing load in stream processing with the cloud," in *ICDE Workshops*. IEEE Computer Society, 2011, pp. 16–21.

[24] M. T. Truong, A. Harwood, R. O. Sinnott, and S. Chen, "Performance analysis of large-scale distributed stream processing systems on the cloud," in *IEEE CLOUD*. IEEE Computer Society, 2018, pp. 754–761.

[25] S. Henning and W. Hasselbring, "Benchmarking scalability of stream processing frameworks deployed as microservices in the cloud," *Journal of Systems and Software*, vol. 208, p. 111879, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121223002741

[26] S. Rac and M. Brorsson, "Cost-aware service placement and scheduling in the edge-cloud continuum," *ACM Trans. Archit. Code Optim.*, vol. 21, no. 2, p. 29, 2024.

[27] V. Cardellini, V. Grassi, F. Lo Presti, and M. Nardelli, "Optimal operator replication and placement for distributed stream processing systems," *ACM SIGMETRICS Performance Evaluation Review*, vol. 44, no. 4, pp. 11–22, 2017.

[28] F. Ait-Salaht, M. Rebai, and N. Izri, "Optimizing service replication and placement for iot applications in fog computing systems," in *European Conference on Parallel Processing*. Springer, 2024, pp. 283–297.

[29] C.-W. Ching, X. Chen, C. Kim, T. Wang, D. Chen, D. Da Silva, and L. Hu, "Agiledart: An agile and scalable edge stream processing engine," *IEEE Transactions on Mobile Computing*, 2025.

[30] G. Russo Russo, V. Cardellini, and F. Lo Presti, "Hierarchical auto-scaling policies for data stream processing on heterogeneous resources," *ACM Transactions on Autonomous and Adaptive Systems*, vol. 18, no. 4, pp. 1–44, 2023.