An Approach for Deployment of Service-Oriented Simulation Run-Time Resources

Abstract

The requirements for low latency and high stability in large-scale geo-distributed training simulations have made cloud-edge collaborative simulation an emerging trend. However, there is currently limited research on how to deploy simulation run-time resources (SRR), including edge servers, simulation services, and simulation members. On one hand, the deployment schemes of these resources are coupled and have mutual impacts. It is difficult to ensure overall optimum by deploying these resources separately. On the other hand, the pursuit of low latency and high system stability is often challenging to achieve simultaneously because high stability implies low server load, while a small number of simulation services implies high response latency. We formulate this problem as a multi-objective optimization problem for the joint deployment of SRR, considering the complex combinatorial relationship between simulation services. Our objective is to minimize the system time cost and resource usage rate of edge servers under constraints such as server resource capacity and the relationship between edge servers and base stations. To address this problem, we propose a learnable genetic algorithm for SRR deployment (LGASRD) where the population can learn from elites and adaptively select evolution operators performing well. Extensive experiments with different settings based on real-world data sets demonstrate that LGASRD outperforms the baseline policies in terms of optimality, feasibility, and convergence rate, verifying the effectiveness and excellence of LGASRD when deploying SRR.

1. Introduction

Training simulation is a safe, controllable, and cost-effective training method that can improve the abilities of trainees, becoming a critical method of talent cultivation in various industries. In large-scale geo-distributed training simulations, simulation members, i.e., users, can be categorized into three types [1]: live (L), virtual (V), and constructive (C) members, such as actual aircraft with various sensors, aircraft simulators controlled by simulated cockpits and computer generated aircraft, respectively. These members dispersed across different locations are integrated into a virtual space, where they can see and interact with each other.

However, systems capable of supporting such large-scale simulation activities are often excessively large and require sufficient computing resources and network resources to support their operation. Otherwise, users will suffer from tremendous latency, which can significantly impair user experience quality.

To address this issue, researchers have proposed deploying simulation systems in the cloud-edge collaborative computing environment, utilizing both the computing resources of cloud computing and the networking resources of edge computing [2]. Under the cloud-edge collaborative simulation paradigm, developers usually adopt the micro-service (MS) architecture to develop simulation systems. By encapsulating common functional modules into containers to form services, MS architecture can achieve higher development efficiency, more efficient resource reuse, and better elasticity [3,4].

During the operation of an MS-based training simulation system deployed in cloud-edge collaborative computing architecture, simulation members send service requests to the system to realize the functions they need. They also send messages to other members through the middleware service to achieve the interaction between him/her and other members, and also promote the progress of the current simulation activity.

As shown in Figure 1, each service request is composed of multiple micro-services and can be formulated as a directed acyclic graph (DAG) [5,6], in which a node represents a task, defined as the execution of its corresponding MS instance. Each task also has its predecessor and successor tasks. After a task is completed, its successor tasks will either be completed on the same server or on other servers. The latter method will incur service communication time, a part of data transmission time. Furthermore, MS instances provide computation in a queue-based manner, which may lead to long service waiting times due to huge user demands and a small number of instances.

Furthermore, in large-scale geo-distributed training simulations, message sending may lead to long-distance data transmission, generating user interaction time. For example, in a training simulation activity, if user A needs to send a message to user B, the message needs to be sent to the middleware service first, and then the middleware will forward it to user B.

To implement the training simulation process mentioned above, the primary challenge is how to deploy edge servers, micro-services, and members in the cloud-edge collaborative computing environment before the start of the simulation. On the one hand, edge servers can provide both computing and communication capabilities, making them an important infrastructure for cloud-edge collaborative computing architecture. In reality, there often exist situations where there are n available edge servers but m ($n<m$) candidate server locations, typically base stations (BSs) [7,8,9,10,11]. Therefore, we need to determine where these n edge servers should be deployed. We assume that the cloud center has existed, so we do not focus on the deployment of it. On the other hand, simulation members are the main participants of training simulations, and micro-services are indispensable components for enabling members to perform their required functions, so they are also extremely important for training simulations. As software resources, we need to determine their deployment schemes on servers. Note that the referred members here are constructive members, because in large-scale geo-distributed simulations, live members and virtual members are often difficult to move due to their large numbers, so we assume that their locations are known and fixed. For convenience in the description, we define servers, micro-services, and constructive members as simulation run-time resources (SRR), and refer to the latter two software resources as simulation run-time software resources (SRSR).

Different deployment schemes of SRR have a great impact on the time cost of simulation systems, including data transmission time and service queuing time, as well as the resource occupancy rate of edge servers. Data transmission is caused by users’ service requests and interactions between users. Without the loss of generality, it is usually assumed that a task is always scheduled to be processed by the server with the corresponding MS instance that is closest to its input data [11,12]. Obviously, the same server will face different user demands under different deployment schemes of edge servers and simulation members. Deployment decisions of micro-services have a significant influence on task scheduling and service queuing time. In addition, scattered users will lead to large data transmission time due to their messages. On the other hand, although more micro-service instances can reduce time costs, they can increase resource usage of edge servers. This increases the risk of crashes and should be avoided as much as possible. Therefore [13], deployment schemes of SRR are closely coupled and should be considered together.

However, there is currently little research on this problem. Existing works mostly study one problem in service deployment or server deployment. As mentioned earlier, they are coupled and it is difficult to achieve the overall optimum by researching them separately. In addition, most works only consider the deployment of monolithic services, instead of micro-services, thus ignoring the data dependencies between micro-services [11,14]. However, this deployment scheme cannot fully capture the characteristics of systems based on MS architecture. Finally, the current related research focuses mainly on scenarios such as autonomous driving and the Internet of Things (IoT), rather than training simulation. However, there are some elements in training simulation that these fields do not possess, such as L, V, and C members and their interactions.

This work studies the joint deployment of SRR in cloud-edge collaborative computing environments, aiming to minimize system time cost, while minimizing the resource consumption rate of edge servers. We formulate the joint deployment problem and design a learnable multiple-objective evolutionary algorithm to solve it. Furthermore, we target the service-oriented training simulation field, a more specialized scenario. In this paper, the main contributions are as follows:

• We propose a complete process for deploying edge servers and software resources together, taking a more complex service modeling approach into account. This is an improvement over existing work.
• We formulate the joint deployment of edge servers and SRSR as a multi-objective optimization problem with two objectives: minimizing both the system’s time cost and the resource usage rate of edge servers. To solve this problem, we proposed a learnable genetic algorithm for simulation run-time resource deployment (LGASRD), which is capable of adaptively selecting genetic operators and evolving under the guidance of an elite population.
• Extensive experiments are implemented in Python to evaluate the performance of the LGASRD based on the real-world EUA data set [15] and scientific workflows [16]. The experimental results show that LGASRD outperforms the other typical benchmark policies.

The remainder of this article is organized as follows. Section 2 provides an overview of related works. Section 3 elaborates on the motivations behind our study on the joint deployment of SRR. Section 4 introduces the system model and formulates a multi-objective optimization problem. LGASRD is proposed to solve the problem in Section 5 and its performance analysis is conducted based on real-world data sets in Section 6. Finally, Section 7 concludes this article.

2. Related Works

Training simulation is one of the most effective and economical ways to enhance personnel’s professional ability, which has become a consensus. Faced with the service-oriented simulation and the use of cloud computing and edge computing for simulation, it is an inevitable trend in the development of computer simulation technology [17,18,19,20]. Therefore, the cloud-edge collaborative training simulation not only faces some challenges in the field of cloud computing and edge computing, such as server deployment [21,22,23,24] and service deployment [25,26,27,28], but also has some unique problems. Training simulation is different from other types of simulation such as supply chain, production, and manufacturing simulation. In the training simulation process, there will be a large amount of interaction between virtual and real entities. Therefore, unlike conventional research on edge computing technology, we need to consider the additional time cost, caused by interaction, of the edge computing systems used for training simulation. In addition, the deployment issue of computer-generated constructive simulation members, which can be regarded as a type of special simulation service, also needs to be resolved urgently. However, it is regrettable that we have not seen any relevant research yet.

Currently, research on how to deploy services to distributed edge computing systems is a hot topic. Chen et al. [29] defined the problem as a combinatorial contextual bandit learning problem. They utilized the Multi-armed Bandit theory to learn the optimal deployment scheme of services. Ouyang et al. [30] studied the problem of how to deploy services in the distributed edge computing environment in a mobility-aware and dynamic way, aiming to optimize the long-term averaged migration cost due to user mobility. To achieve this, they developed two efficient heuristic schemes based on the Markov approximation and best response update techniques. Gao et al. [28] designed an iterative algorithm to study how to achieve optimal service deployment and access network selection. Hu et al. [31] proposed an algorithm to adjust the task scheduling decisions and resource allocation by achieving a trade-off between the execution time of tasks and energy consumption.

However, those researchers only studied the services in a monolithic way, ignoring the composite property of services. Wang et al. [12,32] considered this factor, but only considered the linear combination relationship between services. However, in reality, the business logic relationships between services should be represented by DAG. In addition, though these works took different aspects into account, they assumed that all base stations could be deployed with edge servers. In fact, the number of available edge servers is limited and thus it is not reasonable that all base stations are enabled to execute computing tasks. Furthermore, different server deployment schemes will generate different service requests from users, resulting in different service deployment schemes. Therefore, the scheme of service deployment can be obtained unless the deployment of usable edge servers has finished. Considering this, these two elements should be deployed jointly.

In edge computing, the most common deployment method is to place edge servers at base stations [21,23]. Li et al. [21] identified a gap in the related works regarding energy efficiency in edge server deployment. To address this, they proposed a multi-objective optimization approach, incorporating an energy-aware edge server deployment algorithm. Their objective was to obtain a deployment solution that minimized energy consumption while maintaining access delay at an acceptable level. Mohan et al. [22] allowed edge servers to request processing of the extra workload from the cloud based on the assumption that the capacity constraints on each edge server were relaxed. Wang et al. [23] focused on the deployment of edge servers in a metropolitan area, assuming that all edge servers were homogeneous. They proposed a mixed-integer programming approach that aimed to minimize the edge server access latency as well as balance the workload among edge servers to achieve this goal. Lähderanta et al. [24] investigated the deployment of edge servers as a constrained location-allocation problem. The study incorporated the constraints of both upper and lower server capacities, aiming to minimize distance and achieve workload balance among the edge servers. However, the mentioned works just considered where to place the edge servers with different optimization goals and constraints, without taking the service placement under the current structure of the edge server placement scheme into account. They assume that each edge server hosts only one type of service, ignoring the demand of users for different services. In addition, they overlooked the diverse service requests of users with the assumption that each edge server was dedicated to hosting a single type of service.

3. Motivation

Figure 2 provides a more vivid illustration of the importance of considering the joint deployment of SRR, although there is currently little research on this topic. The figure includes training bases (TBs), edge servers (ESs), BSs, and a scheduling center located in the cloud. Software resources on ESs include MS instances and constructive members, depicted by colored circles and aircraft, respectively. To facilitate distinction, a jagged symbol is used to represent the middleware service instead of using a circle.

Taking Figure 2a as an example, only the deployment of servers is considered without considering data dependencies between services. In this case, three ESs are deployed on BS 1, 2, and 4, with purple, green, and middleware services deployed on them, respectively. A live user submits a service request for path planning. Since all ESs do not have the corresponding instance, the task can only be completed in the cloud, where all types of services are deployed. This will remarkably increase network latency. Additionally, a live user sends a message “Hello” to a constructive white aircraft, resulting in two data transmissions. However, if the white aircraft and middleware are deployed together, the second data transmission can be avoided.

The situation shown in Figure 2b optimizes the deployment of services and simulation members. The yellow service request submitted by a live user is dispatched to ES 1, avoiding huge communication costs generated by execution in the cloud. Additionally, some constructive members are deployed together with middleware, reducing user interaction costs to a certain extent. However, BS 3 and BS 5 are far away from TB A and B. Intuitively, it would be a better choice to deploy the two servers at BS 1 and 2.

Figure 2c illustrates the joint deployment of SRR, including ESs, micro-services, and constructive members, considering data dependencies between micro-services. A live user submits a request for path planning, including two tasks, $t_1$ and $t_2$. Task $t_1$ is scheduled to server 1, and then the output is sent to server 2 for processing the second task $t_2$. It should be noted that the yellow MS instances are deployed on both server 1 and server 2. The reason $t_1$ is scheduled to server 1 rather than server 2 is that the instance on server 2 has other two tasks to process and therefore has a long waiting time.

Another significant difference between Figure 2a–c is that Figure 2c considers micro-services, using a more complex service representation approach, DAG, whereas Figure 2a,b consider monolithic services. This is mainly caused by the granularity difference between the services that the simulation system can support and the services required by users. The performance of the micro-services architecture depicted in Figure 2c is more flexible, so it is currently the mainstream architecture for developing large systems, such as simulation systems, in both the present and future [33]. Therefore, it is important, reasonable, and practical to study simulation resource deployment based on MS architecture.

4. System Model and Problem Formulation

In this section, we first give mathematical definitions of services, tasks, servers, users, and the representation method for joint deployment decision-making. Then, we calculate two objective functions: time cost and resource occupancy rate. Finally, we formulate the joint deployment optimization model. The main notations used in this article are listed in

Table 1. Summary of key notations.

Notation	Description
$M{S}_i$	the i-th type of MS
$r_{M{S}_i}$	the resource requirement of $M{S}_i$
$S_i$	the i-th type of CS combined by micro-services
$S_{ij}$	the j-th type of service request from the i-th user
$t_{ijl}$	the l-th task in $S_{ij}$
$R_i$	the i-th edge server
$R_{C_i}$	the resource capacity of $R_i$
$L_{R_i}$	the location coordinate of $R_i$
$U_i$	the i-th user
$r_{C_i}$	the resource requirement of the i-th constructive member
$DS$	the deployment scheme, i.e., the solution of the problem to be solved
$R\left(M\right)$	the edge server deploying the middleware
$R_{U_i}\left(t_j\right)$	the closest edge server to user $U_i$ that deploying instances can execute $t_j$
$R\left(t_i\right)$	the edge server can process $t_i$ with the smallest average data transmission time from the server executing the predecessor tasks of $t_i$
$R\left(C_i\right)$	the edge server deploying constructive member $C_i$
$R\left(U_i\right)$	the edge server closest to user $U_i$
$t_i^C$	the communication time caused by the service request $S_i$
$t_i^M$	the total queuing time of all tasks in the service request $S_i$
$t^S$	the data transmission time caused by users’ service requests
$t^M$	the interaction time cost among users
$B_i$	the resource usage rate of $R_i$

.

4.1. Definitions

• Service: In a system implemented with MS architecture, the granularity of service requests submitted by users is usually greater than the granularity of individual micro-services (also called simulation services) that the system can provide. In such cases, it is necessary to combine simulation services into a composite service (CS) to meet user needs. Typically, users’ service requests are modeled as DAG.
  Assuming that the MS library consists of n classes of micro-services, expressed by set $MS=[M{S}_1,\cdots ,M{S}_n]$. To simplify the problem, assume that the resource requirement of $M{S}_i$ is expressed as $r_{M{S}_i}={[cp{u}_{M{S}_i},gp{u}_{M{S}_i},ra{m}_{M{S}_i}]}^T$ and the input size and output size of $M{S}_i$ are $m{s}_i^{in}$ and $m{s}_i^{out}$, respectively. All micro-services can be combined to generate m composite services, represented by $S=[S_1,\cdots ,S_m]$, to meet users’ demands.
• Task: The execution of a fine-grained simulation service is referred to as a task. In the j-th type of service request $S_{ij}$ submitted by a user $U_i$, the l-th task $t_{ijl}$ has its predecessor and successor tasks, represented by sets $pred\left(t_{ijl}\right)$ and $succ\left(t_{ijl}\right)$, respectively. The initial task and final task in the request are $t_{ijI}$ and $t_{ijF}$, whose $pred\left(t_{ijI}\right)=succ\left(t_{ijF}\right)=U_i$. To facilitate the description of tasks and their corresponding micro-services, we define $tm{s}_i$ to represent the MS whose instances can process task $t_i$.
• Server: Assuming there are k available edge servers $R=[R_1,\cdots ,R_k]$ for training simulation. The resource capacity of edge server $R_i$ is $R{c}_i={[cp{u}_{R_i},gp{u}_{R_i},ra{m}_{R_i}]}^T$. Generally, each edge server is deployed on a BS. Assuming q$(q\ge k)$ BSs are available, and each BS can deploy one edge server at most. Once the mapping relationship between edge servers and BSs is determined, each server’s location can be described by a two-dimensional coordinate as $L_{R_i}=(x_{R_i},y_{R_i})$. Thus, the distance between k edge servers can be calculated as a matrix $A={\left[a_{ij}\right]}_{k\times k}$.
• User: Simulation users include live, virtual and h constructive simulation members, with a total of u $(u>h)$, so the user set can be represented as $U=$$[U_1,\cdots ,U_{u-h},U_{u-h+1},\cdots ,U_u]$. Without the loss of generality, live and virtual users only make small movements around their original positions. We ignore their movements and treat their positions as fixed. For a constructive user, its location is the same as the location of the server deploying it. Thus, the location of user $U_i$ can be expressed as $L_{U_i}=(x_{U_i},y_{U_i})$. As a kind of software resource, the computing resource demand of constructive member $C_i$ is defined as $r_{C_i}={[cp{u}_{C_i},gp{u}_{C_i},ra{m}_{C_i}]}^T$.
• Deployment scheme: Resources to be deployed include edge servers, simulation services, and constructive members. Servers need to be deployed on BSs and need to deploy software resources. Therefore, a deployment scheme $DS$ can be represented by a matrix, with the i-th column representing the deployment scheme for server $R_i$. The matrix is divided into three parts from top to bottom: $D{S}_R$, $D{S}_S$, and $D{S}_C$.
  The first part, $D{S}_R={[D{S}_1^R,\cdots ,D{S}_k^R]}_{1\times k}$, occupies one row of the matrix, indicating the mapping relationship between edge servers and BSs. The value of the i-th element in this row, $D{S}_i^R$, represents that the i-th edge server is determined to be deployed on BS $D{S}_i^R$. Note that a BS can deploy one edge server at most, so $1\le D{S}_i^R,D{S}_j^R\le q$ and $D{S}_i^R\ne D{S}_j^R$, for $\forall i,j=1,\cdots ,k$ and $i\ne j$.
  The second part, $D{S}_{MS}={[D{S}_1^{MS},\cdots ,D{S}_k^{MS}]}_{n\times k}$, is a n-row sub-matrix of matrix $DS$, where $D{S}_i^{MS}={[D{S}_{1i}^{MS},\cdots ,D{S}_{ni}^{MS}]}^T$. $D{S}_{ji}^{MS}$ indicates the number of instances of the j-th type of micro-services deployed on server $R_i$. The number of instances is non-negative integer, so $D{S}_{ji}^{MS}\in N$ for $\forall i=1,\cdots ,k$ and $\forall j=1,\cdots ,n$, where N is the set of natural numbers. Note that as a special simulation service, one and only one middleware is necessary for training simulation activities. To reduce the interaction cost, we assume that it is deployed on edge servers rather than the cloud. To distinguish it from other simulation services, we use $D{S}_M={[D{S}_1^M,\cdots ,D{S}_k^M]}_{1\times k}$, the first row of matrix $D{S}^{MS}$ as the deployment decision for it. Due to limitations mentioned above, $D{S}_i^M$ are binary variables for $\forall i=1,\cdots ,k$, and ${\sum }_{i=1}^{k}D{S}_i^M=1$.
  The third part, $D{S}_C={[D{S}_1^C,\cdots ,D{S}_k^C]}_{h\times k}$, is also a sub-matrix, with h rows, of $DS$, where $D{S}_i^C={[D{S}_{1i}^C,\cdots ,D{S}_{hi}^C]}^T$. The binary variable $D{S}_{ji}^C$ indicates that if the j-th constructive member is deployed on edge server $R_i$. We assume that all constructive users are deployed on the edge instead of the cloud, thus ${\sum }_{i=1}^{k}D{S}_{ji}^C=1$ for $\forall j=1,\cdots ,h$.
  Therefore, the deployment scheme decision $DS$ can be defined as

  $$DS={\left[\begin{array}{c}D{S}_R\\ D{S}_S\\ D{S}_C\end{array}\right]}_{(1+n+h)\times k}={\left[\begin{array}{c}\begin{array}{c}D{S}_R\\ D{S}_M\end{array}\\ \begin{array}{c}D{S}_{S/M}\\ D{S}_C\end{array}\end{array}\right]}_{(1+n+h)\times k}$$

  (1)

In addition to the previous definitions, we also define a few symbols for convenience.

• $R\left(M\right)$: the edge server deploying the middleware;
• $R_{U_i}\left(t_j\right)$: the closest edge server to user $U_i$ that deploying instances can execute $t_j$;
• $R\left(t_i\right)$: the edge server can process $t_i$, with the shortest summation of distances between the current server and other servers executing the predecessor tasks of $t_i$, i.e., the server executing task $t_i$;
• $R\left(C_i\right)$: the edge server deploying constructive member $C_i$;
• $R\left(U_i\right)$: the edge server closest to user $U_i$.

4.2. Time Cost Model

4.2.1. Service Response Model

In terms of service response, we consider two factors: the network communication time between users and servers and between tasks; the queuing time of tasks at their corresponding instances calculated by $M/M/c$ queuing model, where $c\ge 1$.

• Service communication model:
  Without the loss of generality, we assume that a j-th type of service request $S_{ij}$ from user $U_i$ is always first scheduled to $R_{U_i}\left(t_{ijI}\right)$ to process the initial task $t_{ijI}$, for $\forall i=1,\cdots ,u$ and $\forall j=1,\cdots ,m$. The data size from $U_i$ to $R_{U_i}\left(t_{ijI}\right)$ is $m{s}_{tm{s}_{ijI}}^{in}$. Subsequently, each task $t_{ijk}$ after $t_{ijI}$ will be scheduled to $R\left(t_{ijk}\right)$ in topological order, and the data dependency scale between this task and its predecessor task $t_{ijp}$ is $m{s}_{pk}^{trs}$. When the service request is finished, the result, i.e., the output of $t_{ijF}$ is sent to user $U_i$.
  Therefore, the communication time caused by the service request $S_{ij}$ is

  $$t_{ij}^C=\lceil \frac{a_{in}}{a}\rceil \frac{m{s}_{tm{s}_{ijI}}^{in}}{BW}+\sum _{k=2}^{N_{S_{ij}}}\sum _{t_{ijp}\in pred\left(t_{ijk}\right)}\lceil \frac{a_{R\left(t_{ijp}\right),R\left(t_{ijk}\right)}}{a}\rceil \frac{m{s}_{pk}^{trs}}{BW}+\lceil \frac{a_{out}}{a}\rceil \frac{m{s}_{tm{s}_{ijF}}^{out}}{BW}$$

  (2)

  where $a_{in}=a_{R\left(U_i\right),R_{U_i}\left(t_{ijI}\right)}$ and $a_{out}=a_{R_{U_i}\left(t_{ijF}\right),R\left(U_i\right)}$. $N_{S_{ij}}$ represents the number of small tasks in this request and a and $BW$ are the network distance of one hop and the network bandwidth, respectively. In the network environment uniformly configured for training simulations, they are all constants.
• Service queuing model: If a task is scheduled to a busy instance, it will suffer a long queuing time. To simplify the problem without the loss of generality, we assume that the calculation time of all MS instances is consistent, which is equal to $\mu$. Thus, the waiting time of task $t_k$ is calculated by $M/M/c$ queuing model as

  $$t_k^W=\frac{{{\rho }_k}^{c_k+1}{p}_k}{{\lambda }_k(c_k-1)!{(c_k-{\rho }_k)}^2}$$

  (3)

  where ${\lambda }_k$ represents the arrival rate of tasks of the same type as $t_k$ and ${\rho }_k={\lambda }_k/\mu \le 1$. $c_k\ge 1$ indicates the number of instances that can process $t_k$ deployed on the current server. Note that if a task is scheduled to the cloud rather than an edge server, we ignore its queuing time but emphasize the data transmission time. The parameter $p_k$ that can be calculated as

  $$p_k={(\sum _{n=0}^{c_k-1}\frac{{{\rho }_k}^n}{n!}+\frac{{{\rho }_k}^{c_k}}{c_k!}\frac{c_k}{c_k-{\rho }_k})}^{-1}$$

  (4)
  Therefore, the total queuing time of all tasks in the j-th type service request from user $U_i$, $S_{ij}$, can be represented as

  $$t_{ij}^W=\sum _{k=1}^{N_{S_{ij}}}{t}_{ijk}^W$$

  (5)

Based on the proposed service communication model and service queuing model, the total data transmission time caused by users’ service requests can be formulated as

$$t^S=\sum _{i=1}^u\sum _{j=1}^m{d}_{ij}(t_{ij}^C+t_{ij}^W)$$

(6)

where $d_{ij}$ represents the demand for service request $S_j$ of $U_i$.

4.2.2. User Interaction Model

In training simulation, a user can subscribe to messages of any other user on demand. If user $U_i$ subscribes to the messages of $U_j$, indicating that the results of service requests submitted by $U_j$ will be sent to $R\left(U_j\right)$ from $R\left(U_i\right)$, we define $It{a}_{ij}=1$. Thus, the time cost of the subscription of $U_i$ to $U_j$’s messages due to the service request $S_l$ from $U_j$ is

$$t_{ijl}^M=\lceil \frac{a_{R\left(U_j\right),R\left(U_i\right)}}{a}\rceil \frac{m{s}_{tm{s}_{lF}}^{out}}{BW}$$

(7)

Therefore, the time cost of the subscription of $U_i$ to $U_j$ can be calculated as

$$t_{ij}^M=\sum _{l=1}^m{t}_{ijl}^M{d}_{jl}$$

(8)

Furthermore, considering the subscription relationship between users, the interaction time cost is formulated as

$$t^M=\sum _{i=1}^u\sum _{j\ne i}(t_{ij}^{M}It{a}_{ij}+t_{ji}^{M}It{a}_{ji})$$

(9)

In summary, the first objective function, total time cost due to data transmission between tasks among each service request from all users and interactions between them, can be represented as

$$f_1\left(DS\right)=t^S+t^M$$

(10)

4.3. Resource Occupancy Rate Model

The software resources that may be deployed on a server include simulation services and constructive members, whose resource demands are represented by $r_{MS}$ and $r_C$, respectively. Once a deployment scheme is determined, the occupied resources of server $R_i$ can be modeled as a 3D column vector:

$$B_i=\sum _{j=1}^{n}D{S}_{ji}^{MS}{r}_{M{S}_j}+\sum _{j=1}^{h}D{S}_{ji}^C{r}_{C_j}$$

(11)

Assuming that server $R_i$’s resource consumption rate is $max(B_i/R_i)$. The second objective function, the resource usage rate of all edge servers, can be formulated as

$$f_2\left(DS\right)=\underset{i=1,\cdots ,k}{max}\left\{max(B_i/R_i)\right\}$$

(12)

4.4. Problem Formulation

The object of deploying SRR jointly is to minimize the overall time cost of the training simulation system while minimizing the resource consumption rate of edge servers. At the same time, constraints of resource capacities of edge servers, deploying rules, and variable properties should be satisfied. The joint deployment problem $\mathcal{P}$, which has been proven to be NP-Hard [13], is formally defined as follows:

$$\begin{array}{cc}\hfill min& f\left(DS\right)=(f_1\left(DS\right),f_2\left(DS\right))\hfill \end{array}$$

(13)

$$\begin{array}{cc}\hfill s.t.& max(B_i/R_i)<1,\forall R_i\in R\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill & {(D{S}_i^R-D{S}_J^R)}^2>0,\forall i,j=1,\cdots ,kandi\ne j\hfill \end{array}$$

(15)

$$\begin{array}{cc}\hfill & \sum _{i=1}^{k}D{S}_i^M=1\hfill \end{array}$$

(16)

$$\begin{array}{cc}\hfill & \sum _{j=1}^{k}D{S}_{ij}^C=1,\forall C_i\in C\hfill \end{array}$$

(17)

$$\begin{array}{cc}\hfill & D{S}_i^R\in \{1,\cdots ,q\},\forall i=1,\cdots ,k\hfill \end{array}$$

(18)

$$\begin{array}{cc}\hfill & D{S}_i^M\in \{0,1\},\forall i=1,\cdots ,k\hfill \end{array}$$

(19)

$$\begin{array}{cc}\hfill & D{S}_{ij}^S\in N,\forall i=1,\cdots ,nandj=1,\cdots ,k\hfill \end{array}$$

(20)

$$\begin{array}{cc}\hfill & D{S}_{ij}^C\in \{0,1\},\forall i=1,\cdots ,handj=1,\cdots ,k\hfill \end{array}$$

(21)

The related constraint formula is as follows: Equation (14) means that the software resources deployed on an edge server cannot exceed the server’s capacity limit. Equation (15) indicates that one BS can only deploy one edge server at most, that is, the BSs where two edge servers are deployed are different. Equations (16) and (17), respectively, specify that the middleware service and a constructive member must and can only be deployed on one edge server. Equations (18)–(21) specify the range of values for various decision variables, which must all be integers.

Obviously, $\mathcal{P}$ is a nonlinear integer optimization problem that requires finding the Pareto optimal solution of the training simulation system’s time cost and edge servers’ resource occupancy while not violating constraints, e.g., Equations (15)–(21).

5. Simulation Run-Time Resources Deployment Algorithm

In this section, we elaborate on our Learnable Genetic Algorithm for Simulation Run-time Resources Deployment based on NSGA-II, called LGASRD, for $\mathcal{P}$. Firstly, we propose the framework of LGASRD and analyze its differences from NSGA-II. Then, based on the encoding method represented as Equation (1), we introduce some novel crossover and mutation operators and let LGASRD adaptively choose the operator with better performance. The details are presented as follows.

5.1. The LGASRD Algorithm

LGASRD is implemented based on the well-known Non-dominated Sorting Genetic Algorithm II (NSGA-II). As an evolutionary algorithm, NSGA-II requires multiple iterations before termination, has a poor ability to escape from local optimal solutions, and cannot guarantee a feasible solution when faced with constrained optimization problems. Furthermore, other improved methods have not completely solved this problem. For example, while accelerating the convergence speed of the algorithm, there is a high possibility of sacrificing the diversity of the population, which can result in the inability to find good solutions. We introduce the elite knowledge and operator performance knowledge to speed up the convergence rate without too much loss of diversity of the population. The constraint handling mechanism is also designed to guarantee the feasibility of obtained solutions.

5.1.1. Constraint Handling Mechanism

As shown in Equation (1), this encoding method makes it easy to ensure that some constraints are satisfied by reasonable crossover and mutation operators, which mainly restrict the properties of variables and the relationships between variables, as formulated in Equations (15)–(21). However, it is difficult to satisfy the server resource occupancy constraints, e.g., Equation (14), by intuition. In some cases where server resources are limited, we must adopt strategies to ensure that the solution obtained is feasible.

To address this issue and preserve the diversity of the population as much as possible, we have divided the algorithm into two stages. In the first stage, we transfer the two objectives into one by weighting them using ${\omega }_1$ and ${\omega }_2$ and apply a penalty function to penalize solutions that violate the resource capacity constraint. To enhance the effectiveness of this mechanism, the penalty coefficient $\mathbb{M}$ increases exponentially with the iteration of the algorithm. Therefore, the objective function in the first stage is

$$\begin{array}{c}\hfill f\left(DS\right)=f_1\left(DS\right){\omega }_1+f_2\left(DS\right){\omega }_2-max\{0,f_2\left(DS\right)-1\}\mathbb{M}\end{array}$$

(22)

In the second stage, we consider both $f_1\left(DS\right)$ and $f_2\left(DS\right)$. To enhance the algorithm’s exploratory ability, we apply a parameter $ϵ$ to relax the resource occupancy rate constraint and make $ϵ$ rapidly approach 0 with each iteration of the algorithm. This ensures the feasibility of the solution obtained.

To ensure the availability of feasible solutions, our basic idea is to accept some unfeasible solutions in the early stages of the algorithm to increase the diversity of individuals in the population, while focusing more on the feasibility of solutions as the algorithm iterates.

5.1.2. Elite Knowledge

Elitist refers to the individual in a population that has the highest fitness value, e.g., the optimal objective function, from the start of evolution until now. It possesses the best genetic structure and excellent traits. To prevent the destruction or loss of elitists in the current population during subsequent iterative optimization processes, the elite retention strategy should be adopted, which involves adding an elitist from each generation to the Elite Population (EP). Rudolph has theoretically proven that the standard genetic algorithm with elite retention strategy is globally convergent [34]. Therefore, we use the individuals in EP, called elite knowledge, to guide the subsequent optimization. There are two aspects to consider when using elite knowledge: updating EP and migrating elitists.

The size of EP is $\mathbb{E}$, and the top $\mathbb{E}$ individuals from the first generation population can be selected to form the first generation EP. Starting from the second-generation population, if there is an individual A in the current population that is superior to one of the individuals in EP, we replace this elitist with A. In the multi-objective stage, we consider that individual A is superior to individual B if one of the following three conditions is met:

• Condition 1:

  $$\begin{array}{cc}\hfill & f_1\left(A\right)\le f_1\left(B\right)\hfill \\ \hfill & f_2\left(A\right)\le f_2\left(B\right)\hfill \\ \hfill & A\notin EP\hfill \end{array}$$

  (23)
• Condition 2:

  $$\begin{array}{cc}\hfill & f_1\left(A\right)<f_1\left(B\right)\hfill \\ \hfill & f_2\left(A\right)\ge f_2\left(B\right)\hfill \\ \hfill & \frac{f_1\left(B\right)-f_1\left(A\right)}{f_1\left(B\right)}>\frac{f_2\left(A\right)-f_2\left(B\right)}{f_2\left(B\right)}\hfill \\ \hfill & randp<1-\frac{f_2\left(A\right)-f_2\left(B\right)}{f_2\left(B\right)}\frac{f_1\left(B\right)}{f_1\left(B\right)-f_1\left(A\right)}\hfill \end{array}$$

  (24)
• Condition 3:

  $$\begin{array}{cc}\hfill & f_1\left(A\right)\ge f_1\left(B\right)\hfill \\ \hfill & f_2\left(A\right)<f_2\left(B\right)\hfill \\ \hfill & \frac{f_1\left(A\right)-f_1\left(B\right)}{f_1\left(B\right)}<\frac{f_2\left(B\right)-f_2\left(A\right)}{f_2\left(B\right)}\hfill \\ \hfill & randp<1-\frac{f_1\left(A\right)-f_1\left(B\right)}{f_1\left(B\right)}\frac{f_2\left(B\right)}{f_2\left(B\right)-f_2\left(A\right)}\hfill \end{array}$$

  (25)

where $randp$ is a randomly generated probability. Equation (23) represents the case that A dominates B and no individual the same as A is in EP. Equations (24) and (25) mean that although A does not perform well in terms of $f_1$ or $f_2$, it performs exceptionally well in terms of another objective function. Take Equation (24) as an example, it indicates that although A is worse (larger) than B in terms of $f_2$, it is better (smaller) than B in terms of $f_1$ and the degree to which A is smaller than B for $f_1$ is greater than the degree to which B is smaller than A for $f_2$.

In addition to trying to replace the inferior individuals in EP with outstanding ones in the current population to ensure the excellence of EP, we hope to use EP to guide the subsequent optimization process, e.g., elite migration. Every ten rounds of iteration in the second stage, we randomly select an elitist located in the top Pareto rank of EP and replace one individual in the lowest Pareto rank in the current population with it. This approach can bring the population closer to EP to some extent and accelerate the algorithm’s convergence speed without too much loss of diversity within the population.

5.1.3. Operator Performance Knowledge (OPK)

In the genetic algorithm, three operations are necessary: parent selection, crossover, and mutation. For a particular problem, using different operators to perform these three operations can result in different outcomes. In standard NSGA-II [35], the operators of performing these three operations are fixed, and the algorithm can only perform them in one way. This makes the algorithm lack adaptive ability and learning ability. To improve this, we introduce OPK into NSGA-II, allowing the algorithm to record the performance of operators for each operation. The higher the historical performance of an operator, the greater the probability it will be selected during the corresponding operation in a certain iteration.

We design two crossover operators and three mutation operations (detailed later); thus, we can obtain six different genetic methods. During each iteration, the algorithm records which crossover and mutation operator each individual used. If a new individual A dominates the corresponding old one B, that is, $f_1\left(new\right)\le f_1\left(old\right)$ and $f_2\left(new\right)\le f_2\left(old\right)$, or A performs exceptionally better than B in terms of one objective function, represented as Equation (24) or Equation (25), the performance of the used crossover and mutation operators is increased by one. Take mutation operation as an example, if the current mutation operation is successful through the j-th mutation operator, the performance of the j-th mutation operator $PK\left(j\right)=PK\left(j\right)+1$. When selecting an operator to change an individual in the next iteration, the probability of the j-th operator will be selected as

$$\begin{array}{c}\hfill P\left(j\right)=\frac{PK\left(j\right)}{{\sum }_{i=1}^{3}PK\left(i\right)}\end{array}$$

(26)

where $P\left(j\right)$ represents the probability of the j-th operator is selected. As shown in

Table 2. Update and application performance knowledge of mutation operators.

PK	Historic Performance			Probability of Selection
Operator	Operator 1	Operator 2	Operator 3	Operator 1	Operator 2	Operator 3
Initialization	1	1	1	33.3%	33.3%	33.3%
mutation1	1	2	1	25%	50%	25%
mutation2	1	2	1	25%	50%	25%
⋯	⋯	⋯	⋯	⋯	⋯	⋯

, in the first iteration of our algorithm, the performance of each mutation operator is initialized to 1. The probability of each operator being selected is calculated as 33.3% according to Equation (26). If the second operator is selected and the mutated individual is better than the original one during the first mutation operation, the historic performance of it is increased to 2, and the probability of each operator being selected is calculated as 25%, 50%, and 25%. In the second mutation, if the first operator is chosen but the mutated individual does not become better, the performance and probability of selection of all operators remain unchanged.

5.1.4. The LGASRD Framework

Based on the well-known NSGA-II and the aforementioned operations, we obtain the proposed LGASRD in Algorithm 1. Firstly, we randomly generate the initial population and select $\mathbb{E}$ individuals performing well to create EP based on their fitness values (lines 3–5). After that, LGASRD starts the first phase of iteration. At the beginning of the iteration, executes three genetic operations, creating the new population. Note that LGASRD uses the roulette wheel strategy to perform the parent selection operation (line 7). Next, the fitness values of the new population are calculated, and then OPK and EP are updated (lines 8–10). At the final step of this phase, some parameters are updated (line 11). After the first stage, two objective functions of the current population are calculated and a new EP is created (lines 14–15). Compared to the first stage, there are several differences between the second stage of the algorithm:

• LGASRD uses tournament strategy for parent selection in the second stage (line 17);
• As the number of objective functions increases, some evaluation criteria become more complex, such as how to update OPK and EP (line 19);
• Elite migration strategy is introduced (lines 25–27);
• LGASRD stops iterating after multiple failed attempts to update EP (lines 28–30).

5.2. Crossover Operators

We design two crossover operators, which can be understood as vertical and horizontal combined with the encoding method shown as Equation (1).

The first operation is to exchange the three parts given in Equation (1) from the two parent individuals that will crossover with each other. It should be noted that the two parts related to micro-services and constructive members cannot be completely exchanged, or this crossover operation will be invalid. Instead, we will randomly select a range and exchange the parts that are within this range.

The second approach involves randomly selecting a server range and swapping the deployment schemes of servers within the range in the two parent chromosomes. However, this crossover operation may result in the newly obtained individuals violating certain constraints, such as Equations (14)–(17). Therefore, some repair mechanisms are introduced to ensure the feasibility of the resulting solutions.

These two crossover operators enable the exchange of chromosome segments between the two parent bodies in different ways, allowing LGASRD to adaptively select the crossover approach with better historic performance compared to using only one operator. As a result, information exchange between two parent individuals is more efficient.

5.3. Mutation Operators

We design two crossover operators, which can be understood as random and heuristic.

The first approach is random. It randomly selects two servers within the mutated chromosome, swapping the BSs deploying them, and randomly changing the locations of the middleware and constructive members. As for micro-services, it randomly selects a server and decides whether to increase or decrease the number of micro-services deployed on it based on its resource usage rate, i.e., the second optimization objective. The purpose of designing this operator is to enhance the randomness of our algorithm, thereby increasing its ability to escape from local optimal solutions.

Algorithm 1 Learnable GA-based Simulation Resources Deployment (LGASRD)

Require: Set of micro-services $MS$; Resource demand of micro-services $r_{MS}$; Set of composite services S; Set of edge servers R; Resource capacity of edge servers $R_C$; Location of base stations $L_{BS}$; Set of users U; Resource demand of constructive members $R_C$; Location of live and virtual members $L_{LV}$; User demand for composite services d; Counts of interactions among users $Ita$ Ensure: Deployment schemes $\mathcal{DS}$ and EP   1: $g\leftarrow 1$   2: $FailCount\leftarrow 0$   3: Randomly generate $\mathbb{P}$ individuals $D{S}_1,\cdots ,D{S}_{\mathbb{P}}$ to form the population $\mathcal{DS}$   4: Calculate $f\left(\mathcal{DS}\right)$ according to Equation (22)   5: Select the top $\mathbb{E}$ individuals in $\mathcal{DS}$ to form the first generation EP   6: while in the single-objective stage do   7:    Perform parent selection, crossover, and mutation operations to generate the next generation $\mathcal{DS}$ according to OPK   8:    Calculate $f\left(\mathcal{DS}\right)$   9:    Update OPK based on $f\left(\mathcal{DS}\right)$ 10:    Update EP based on $\mathcal{DS}$ and $f\left(\mathcal{DS}\right)$ 11:    Update parameters including $\mathbb{M}$, $ϵ$ and $P_m$ 12:    $g\leftarrow g+1$ 13: end while 14: Calculate $f_1\left(\mathcal{DS}\right)$ and $f_2\left(\mathcal{DS}\right)$ according to Equations (10)–(12) 15: Select the top $\mathbb{E}$ individuals in $\mathcal{DS}$ based on $f_1\left(\mathcal{DS}\right)$, $f_2\left(\mathcal{DS}\right)$ and their Pareto rank and congestion to form EP in the second stage 16: while in the multi-objective stage do 17:    Perform parent selection, crossover, and mutation operations to generate the next generation $\mathcal{DS}$ according to OPK 18:    Calculate $f_1\left(\mathcal{DS}\right)$, $f_2\left(\mathcal{DS}\right)$ according to Equations (10)–(12) 19:    Update EP and OPK according to Equations (23)–(25) 20:    if fail to update EP then 21:      $FailCount\leftarrow FailCount+1$ 22:    else 23:      $FailCount\leftarrow 0$ 24:    end if 25:    if $g\%Replace\_Freq==0$ then 26:      Replace one of the worst individuals in $\mathcal{DS}$ with one of the best individuals in EP 27:    end if 28:    if $FailCount==\mathbb{G}\times Stop\_Ratio$ then 29:      break 30:    end if 31:    Update parameters including $\mathbb{M}$, $ϵ$ and $P_m$ 32:    $g\leftarrow g+1$ 33: end while 34: return $\mathcal{DS}$, EP

The second variation operation is heuristic. It defines the weighted distance between live and virtual users and a BS, using the size of the communication data generated by these users as the weight to add up the physical distance between these users and the BS. Subsequently, it can be determined which BS currently deploying servers is the farthest from these users, and then a closer, idle BS will be selected to replace it. Additionally, with resource availability, the middleware and as many constructive members as possible will be deployed on the BS with the smallest weighted distance. Evidently, this heuristic operator primarily aims to reduce communication time caused by user interactions. We have also devised operations for other objectives, including service queuing time, service communication time, and resource occupancy rate, which are similar to the current operator and hence will not be elaborated on further. These operators can make use of some heuristic information to enable our algorithm to quickly find some not-bad solutions. In other words, while guaranteeing the lower bound of the obtained solution, they greatly speed up the convergence rate of LGASRD.

The third approach utilizes the information of EP, allowing the current variant individual to either become more similar to or less similar to one elitist. If the current individual’s crowding distance is not equal to 0, it learns from the elitist and becomes more similar to it. For example, if the elitist deploys the middleware on server A, the variant individual will deploy it on B, which is the closest server to A among all servers. If the current individual’s crowding distance is equal to 0, we want it to be unique. In other words, we will let it be different from other individuals in the current population. From an algorithmic perspective, the entire population tends towards EP, so we can make the current variant individual distant from them by reducing its similarity to the imitated elitist. If the variant individual overlaps with its adjacent individuals (solutions), this mutation operator increases the diversity of the population. Otherwise, when the current individual is approaching the imitated elitist, it may obtain better objective function values.

6. Experiment Evaluation

In this section, we report evaluation results using real-world data sets to verify the superiority of the proposed LGASRD. We first introduce the benchmark policies for evaluation. Then, we describe the data set and experimental settings. Finally, the detailed experiment results of LGASRD with respect to the compared methods are presented and discussed.

6.1. Benchmark Policies

Referring to the experimental evaluation in [8,10,13,35], we provide the following five representative baselines for comparative studies.

• K-Means Clustering + NSGA-II (KMNSGA): This strategy first deploys edge servers on k BSs using the K-Means clustering algorithm. On this basis, it uses NSGA-II to determine how other software resources should be deployed.
• NSGA-II: This approach is to directly use NSGA-II to solve the deployment problem for SRR we are facing.
• K-Means Clustering + Top-k Service Placement (TServiceD): This algorithm first deploys k edge servers using the K-Means clustering algorithm. Then, it greedily deploys micro-services by first deploying the MS with the highest user demand, then the service with the second highest user demand, and so on. Finally, it randomly deploys the simulation middleware and constructive members.
• Top-V Server Deployment + Top-V Service Deployment (TSD${}^2$): This method first selects the k most heavily used BSs to deploy edge servers. Then, it greedily deploys micro-services by prioritizing the MS with the highest user demand, followed by the second highest, and so on. Finally, like TServiceD, it also randomly deploys the simulation middleware and constructive members.
• Random: This policy randomly determines the deployment scheme while ensuring its feasibility.

6.2. Data Sets

In our evaluation, we utilized the EUA data set [15], which was derived from the Wireless Communications Licensing data set published by the Australian Communications and Media Authority (ACMA). This data set contains detailed information about the geographic locations of all cellular base stations in Australia, including their respective latitudes and longitudes. We randomly selected q base stations for use in our experiment, which we referred to as base stations M. To model user distribution, we drew upon the distribution generated by the EUA data set, which comprised $(u-h)$ users.

To simulate the business logic relationships between multiple tasks in a service request, we used five workflows, provided by [16], that have been widely used in related research: Montage, Cybershake, Epigenomics, LIGO, SIPHT. Each workflow has a certain number of tasks, and each task can only be executed by containers that encapsulate the corresponding MS. The number of different types of micro-services included in each workflow is shown in

Table 3. Number of micro-services each workflow contains.

Workflow (Service Request)	Number of Micro-Services
Montage (WfM)	9
Cybershake (WfC)	5
Epigenomics (WfE)	8
LIGO (WfL)	4
SIPHT (WfS)	13

.

6.3. Experimental Settings

All the experiments are implemented in Python 3.10.9 on a desktop computer equipped with a 2.30 GHz Intel Core i7-11800H CPU and 16 GB RAM (The source code is available by accessing https://github.com/ZkofZhang/An-Approach-for-Deployment-of-Service-Oriented-Simulation-Run-time-Resources (accessed on 1 September 2023)). The parameter settings are discussed as follows.

We conducted experiments with various scales, involving scale parameters such as the number of tasks in a workflow (Nt), the number of micro-services (Nms), the number of available edge servers (Nes), and the number of users (Nu), i.e., simulation members, and the number of available BSs that was fixed to 50. Users can be divided into live, virtual, and constructive users. In our experiments, we do not distinguish between live and virtual users and use normal users in the EUA data set to represent them. Moreover, for simplicity, we assume that the number of these two types of users is the same as that of constructive users. To facilitate description, we summarized the scale parameter settings for each set of experiments, as shown in

Table 4. Summary of scale parameters.

Setting	Nt	Nms	Nes	Nu
A	50	WfM	10	10 + 10
B	50	WfM	15	30 + 30
C	50	WfM	20	50 + 50
D	50	All except WfC	10	10 + 10
E	50	All except WfC	15	30 + 30
F	50	All except WfC	20	50 + 50
G	50	All	10	10 + 10
H	50	All	15	30 + 30
I	50	All	20	50 + 50
J	100	WfM	10	10 + 10
K	100	WfM	15	30 + 30
L	100	WfM	20	50 + 50

. Note that the middleware is a type of MS that exists in all settings, so it does not appear in the table.

In our experiments, the resources required by each MS are directly read from the corresponding XML file. In the service-oriented training simulation, all members rely on requesting services to achieve their desired functions, and the execution process of services is not performed locally for constructive members. Therefore, they do not require a large amount of CPU resources for calculation. On the contrary, they need a certain amount of memory resources to store a large number of data. Taking this factor into account, we assume that each constructive member only needs one unit CPU resource and does not need any GPU resources. The amount of memory resources they require, which is randomly generated, is between 0.5 and 1.5 times the average memory required by all micro-services. Based on the above settings, we can obtain the total amount of resources consumed in the simulation system and set the resource capacity of each edge server to be between 0.05 and 0.75 times this total amount, reflecting the heterogeneity among servers. At the same time, we set the demand for various service requests by each member to be a random integer between 0 and 20. During our experiments, we also adopted an extreme scenario where all members needed to interact with each other by sending messages.

In LGASRD, we set the population size $\mathbb{P}$ to 50, and the maximum number of iterations $\mathbb{G}$ to 250. Every 5 generations, we select an elitist to replace one individual in the lowest Pareto rank of the current population. If EP fails to be updated for consecutive $0.15\mathbb{G}$ generations, LGASRD will terminate.

6.4. Experiment Results

We conducted extensive experiments to demonstrate the advantages of LGASRD over comparison methods. Firstly, we presented the results of six algorithms under settings A to L to illustrate that LGASRD has better performance than others over multiple problem scales. Then, we reduced the resources provided by edge servers to verify the effectiveness of the constraint-handling mechanism in LGASRD. Under one experimental setup, each algorithm was run 20 times, and we took the average of these 20 runs.

6.4.1. Optimality and Scalability

Figure 3, Figure 4 and Figure 5 present the two objective function values of solutions in the highest Pareto rank generated by the mentioned six algorithms in the upper half when the number of micro-services is 10, 35, and 40, respectively. They also illustrate the iteration process of three evolutionary algorithms, including KMNSGA, NSGA-II, and LGASRD, in the lower half. Due to the fact that some parameters related to resources and user demand were randomly generated for each run, TServiceD and TSD2 obtained different results even though they have specific deployment rules. In these figures, we present the results of LGASRD in two forms: the normal population and the elite population, represented by red and green stars, respectively. Note that since the solutions obtained by LGASRD are too dense, they appear as a single point in the figures. Therefore, we enlarged the points representing the results calculated by LGASRD and placed them in a black box in the blank area.

As can be observed from Figure 3, Figure 4 and Figure 5 and

Table 5. Performance of mentioned algorithms on two objective functions across nine experimental settings.

Algorithm	Best on O1	Better than LGASRD on O1	Best on O2	Better than LGASRD on O2
KMNSGA	0	0	3	3
NSGA-II	0	1	1	2
LGASRD	7		5
Random	2	2	0	0
TServiceD	0	0	0	0
TSD${}^2$	0	0	0	0

, LGASRD exhibits the best comprehensive performance among the six algorithms tested. In experiments conducted with settings A, C, and D, both two objective functions achieved minimal values by LGASRD. This fully demonstrates the effectiveness of the strategies we used, such as elite knowledge and OPK, in enhancing the performance of NSGA-II. Under other experimental settings, LGASRD always obtained solutions that were not dominated by those of other algorithms, with a minimum value for a specific objective function.

Under these experimental settings, the performance of two other evolutionary algorithms, including KMNSGA and NSGA-II, and TServiceD, was also good and they sometimes obtained smaller values on another objective function than LGASRD. The reason for this may be that when the scale of experiments increased, LGASRD reached the termination condition before fully converging, failing to obtain better solutions. It can also be observed that Random, TServiceD, and TSD2 often produce unfeasible solutions. This may be due to their failure to consider the resources required by the simulation middleware and constructive members when using heuristic deployment rules for micro-services, thus directing a large amount of resources towards the deployment of micro-services.

Under three experimental settings where the number of micro-services is consistent, i.e., experiments presented in Figure 3, Figure 4 and Figure 5, as the number of edge servers and simulation members increases, the time cost within the system also increases. This is normal, as an increase in the number of elements within the simulation system will inevitably result in an increase in the scale and frequency of requests for services and data transmission.

In order to explore this in more detail, we summarize how the time costs of Pareto optimal solutions obtained by three evolutionary algorithms change as the scale of our experiment varies, as shown in

Table 6. Changes in Time Cost with the Increase in the Number of Edge Servers, Users, and Micro-services.

Number of Edge Servers and Users					Number of Micro-Services
Setting	Scale	KMNSGA	NSGA-II	LGASRD	Setting	Scale	KMNSGA	NSGA-II	LGASRD
A	1	1	1	1	A	1	1	1	1
B	4.5	8.17	5.76	10.40	D	3.5	1897.87	2052.43	1517.05
C	10	37.14	22.62	29.66	G	4	2378.72	2059.93	2238.64
D	1	1	1	1	B	1	1	1	1
E	4.5	7.87	6.77	10.07	E	3.5	1828.13	2409.09	1469.95
F	10	32.74	18.98	34.27	H	4	1505.21	1103.90	890.71
G	1	1	1	1	C	1	1	1	1
H	4.5	5.17	3.09	4.14	F	3.5	1672.39	1721.85	1752.87
I	10	12.74	9.13	11.19	I	4	815.58	831.16	844.83

. The experimental scale mentioned here mainly refers to the product of the number of users and edge servers, as well as the number of micro-services. In Table 6, they are presented in the left half and the right half, respectively. To provide a visual representation, we have only provided ratios of time costs under different scales without providing specific numerical values. We are only interested in the impact of the experiment scale on time cost and not comparing the performance of the mentioned algorithms, so the results for each algorithm are independent. Due to the limited data, it is difficult to quantitatively describe the growth trend of time cost with experimental scale increases. However, it is evident that the increase in time cost caused by the increase in the number of micro-services is significant, and the underlying reasons still need to be explored. On the contrary, the impact of the number of edge servers and users on time cost is relatively small, even though when the quantity of edge servers and simulation users increases, the increment of time cost exceeds the increase in experimental scale.

From the lower part of Figure 3, Figure 4 and Figure 5, it can be observed that, unlike KMNSGA and NSGA-II, LGASRD exhibits significant fluctuations in its iteration curve. After reaching a local minimum, LGASRD often continues to reduce the objective function value through guided by EP and OPK. This indicates that LGASRD possesses a stronger ability to escape local optimal solutions compared to the other two evolutionary algorithms, which is one of the main reasons for its superior performance. Furthermore, compared to KMNSGA and NSGA-II, LGASRD also exhibits a faster convergence speed. When EP fails to update consecutively for multiple generations, the algorithm terminates even if the normal population is still becoming better.

We also conducted experiments with settings J, K, and L, and the results are shown in Figure 6. It can be observed that LGASRD still exhibits excellent optimization performance, with its solutions dominating those generated by other comparison algorithms, except for slightly higher time cost compared to the solutions produced by TServiceD and TSD${}^2$ in Figure 6b. Furthermore, if we compare the numerical values of time cost in Figure 3 and Figure 6, we will find that if other settings are the same, the granularity of service requests does not have a significant impact on the magnitude of the training simulation system’s time cost. The granularity of a service request refers to the number of micro-services involved in it, i.e., the number of tasks in a workflow application.

6.4.2. Effectiveness of Constraint Handling Policy

The SRR deployment problem is an optimization problem with constraints. When solving this problem, certain rules can be set to ensure that the obtained solution does not violate the constraints. However, this approach is ineffective for constraints like the one shown in Equation (14). Therefore, additional constraint-handling methods, which have already been discussed in Section 5.1.1, need to be introduced into our algorithm. To validate the effectiveness of the constraint-handling approach used in LGASRD, we conducted experiments using some of the previous experimental settings. In contrast to previous experiments, we reduced the resource capacity of edge servers to one-tenth of their original capacity to simulate a resource-constrained scenario. Previous experiments’ results have shown better performance for three evolutionary algorithms, while Random, TServiceD, and TSD${}^2$ performed poorly and generated infeasible solutions under certain settings. Therefore, we will not discuss them further in this section.

As shown in Figure 7, in most cases, KMNSGA and NSGA-II can only generate a fraction of feasible solutions, or even produce entirely infeasible solutions, as illustrated in Figure 7a. In contrast, LGASRD is capable of producing feasible solutions in all scenarios, with the minimal time cost among the three algorithms. This clearly demonstrates the effectiveness and significance of the constraint-handling mechanism we employed.

In Figure 8, we present a comprehensive depiction of the time costs of solutions obtained from three algorithms in resource-constrained scenarios. The training simulation system’s time cost is the summation of service communication time, service queuing time, and user interaction time. We can observe that the time spent on queuing at MS instances is relatively small compared to the data transmission time incurred due to the system’s response to user-initiated service requests. Moreover, these two types of time costs do not exhibit significant increments with the increase in the granularity of service requests, the number of servers, and simulation users. In contrast, the time resulting from user interaction tends to increase significantly with the increase in the number of edge servers and users. This is evident. If micro-services are deployed properly, users may experience low service latency. However, as the number of simulation members increases, it inevitably leads to an increase in the frequency of interactions between users, resulting in a significant growth in user interaction time.

7. Conclusions

This paper investigates the deployment problem of SRR in the cloud-edge collaborative computing architecture, effectively improving the user experience during training simulation activities. Firstly, we formulate this problem as a multi-objective optimization problem, aiming to simultaneously minimize the time cost of the training simulation system and the resource occupancy rate of edge servers under various constraints. It is worth noting that we adopt a combinatorial service modeling approach, which is unique and valuable. Subsequently, we propose LGASRD to solve this problem. The algorithm is a two-stage approach that incorporates elite knowledge and operator performance knowledge, enabling it to adaptively learn and find better solutions at a faster pace. Extensive experiments based on real-world and widely used data sets demonstrate the superiority of LGASRD compared to the benchmark algorithms across multiple evaluation metrics. In future work, we plan to validate our algorithm in training simulation prototype systems, and explore more complex and coupled research by integrating resource deployment with task scheduling.