Electronic device comprising framework operating on basis of model for converting service level objectives (SLO) of network bandwidth into optimal CPU allocation, and operating method thereof

Abstract

According to various embodiments, an electronic device comprising a Tasador framework operating on the basis of a model for converting service level objectives (SLO) of a network bandwidth into an optimal CPU allocation value, comprises: a Tasador manager; a Tasador collector; a communication interface; and a processor, wherein the processor is configured to: allow the Tasador manager to receive user request information through the communication interface; predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth by applying the user request information to a CPU allocation prediction model as input data of the CPU allocation prediction model; and enforce CPU allocation corresponding to the optimal CPU allocation value by using the Tasador manager, wherein the CPU allocation prediction model may be trained on the basis of a training dataset received from the Tasador collector through the communication interface.

Description

An electronic device including a framework operating based on a model that converts SLO (SERVICE LEVEL OBJECTIVES) of network bandwidth into optimal CPU allocation, and an operating method thereof

[0001] The present invention relates to an electronic device and an operating method thereof, including a framework that operates based on a model for converting a network bandwidth SLO (Service level objectives) into an optimal CPU allocation, and more particularly, to an electronic device and an operating method thereof, including a general framework for network SLO to CPU conversion that enables optimal CPU allocation to both a VM and a hypervisor when an SLO (Service-Level Objective) in terms of network bandwidth is given.

[0002]

[0003] Recent cloud-based applications and online services increasingly require network service level objectives (SLOs) in terms of network bandwidth to ensure the target service quality.

[0004] For example, a web server that accommodates 1,000,000 monthly visitors with an average of 4 page views per user and an average of 10 MB of data transferred per page will typically require an average network bandwidth of about 120 Mbps.

[0005] Furthermore, given that virtual machines (VMs) are a core element of cloud computing environments, the ability to meet VM network SLOs is emerging as a critical factor in determining service quality within cloud computing.

[0006] To achieve the network bandwidth targets defined by the SLO, cloud operators must allocate not only sufficient network capacity but also an appropriate amount of CPU capacity. This is because processing network packets requires CPU resources on end hosts.

[0007] Therefore, to effectively achieve the desired network throughput, it is important to develop a method to convert network bandwidth SLOs into appropriate CPU utilization metrics.

[0008] However, converting "network SLO to CPU" is not straightforward, as the exact CPU utilization required for network processing to meet a specific network SLO varies depending on various factors such as VM workload, data size, hardware configuration, etc.

[0009] For this reason, network scheduling or vCPU prioritization was traditionally utilized.

[0010] The first approach directly controlled the transfer rate of each VM through a per-VM transfer queue. However, it lacked the ability to manage CPU allocation between VMs. Furthermore, the Linux CPU scheduler, which had this authority, was unaware of network SLOs. Consequently, insufficient CPU provisioning could lead to violations of network SLOs.

[0011] The second approach typically involves assigning higher priorities to the virtual CPUs (vCPUs) of VMs running SLO-configured network services. However, this rough CPU allocation often results in CPU overprovisioning because the exact CPU requirements to meet the network SLO cannot be known in advance, resulting in unnecessary CPU resource consumption.

[0012]

[0013] Accordingly, the technical problem to be solved by the present invention is to provide an electronic device including a framework that operates based on a model that converts the SLO (Service level objectives) of network bandwidth into optimal CPU allocation, and an operating method thereof, which was created to solve the aforementioned problem.

[0014] The technical problems to be solved by the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0015]

[0016] According to the present invention for solving the above technical problem, an electronic device including a framework that operates based on a model that converts an SLO (Service level objectives) of a network bandwidth into an optimal CPU allocation value includes a Tasador manager, a Tasador collector, a communication interface, and a processor, wherein the processor is configured to receive user request information through the communication interface, apply the user request information to the CPU allocation prediction model as input data of a CPU allocation prediction model, and predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth, and execute CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager, and the CPU allocation prediction model can be learned based on a learning data set received from the Tasador collector through the communication interface.

[0017] According to the present invention, an operating method of an electronic device including a Tasador framework that operates based on a model that converts an SLO (Service level objectives) of a network bandwidth into an optimal CPU allocation value includes a step of receiving user request information through a communication interface of the electronic device by a Tasador manager of the electronic device, a step of applying the user request information to a CPU allocation prediction model as input data of the CPU allocation prediction model to predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth, and a step of executing CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager of the electronic device, wherein the CPU allocation prediction model can be learned based on a learning data set received from a Tasador collector of the electronic device through the communication interface of the electronic device.

[0018]

[0019] The present invention has the feature of alleviating over- and under-allocation problems that occur in separate prediction methods.

[0020] Additionally, it has the feature of improving accuracy by providing predictions closer to actual values ​​at high CPU allocation ratios.

[0021] Tasador, presented in the present invention, reduces the time required to collect new workload data sets and train ML models, making it easily applicable to all types of workloads and hardware configurations.

[0022] Additionally, Tasador does not require any modifications to the VM's internals, allowing existing applications and guest OS to operate without any modifications.

[0023] Finally, Tasador has the advantage of improved CPU allocation efficiency compared to existing approaches.

[0024] The effects of the present invention are not limited to the effects described above, and the tentative effects expected by the technical features of the present invention can be clearly understood from the description below.

[0025]

[0026] FIG. 1 illustrates a block diagram of an electronic device and a network according to various embodiments of the present invention.

[0027] FIG. 2 is a flowchart illustrating a method of operating an electronic device according to various embodiments.

[0028] FIG. 3 is an exemplary diagram showing the entire operation sequence of the Tasador framework of the present invention according to various embodiments.

[0029] FIG. 4 is an exemplary diagram illustrating a connected CPU prediction method according to various embodiments.

[0030]

[0031] Hereinafter, various embodiments of the present document will be described with reference to the attached drawings. It should be understood that the embodiments and the terms used therein are not intended to limit the technology described in the present document to a specific embodiment, but rather include various modifications, equivalents, and / or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar components. The singular expression may include plural expressions unless the context clearly indicates otherwise. In this document, expressions such as "A or B" or "at least one of A and / or B" may include all possible combinations of the items listed together. Expressions such as "first," "second," "first," or "second," may modify the corresponding components regardless of order or importance, and are only used to distinguish one component from another, but do not limit the corresponding components. When it is said that a component (e.g., a first component) is “(functionally or communicatively) connected” or “connected” to another component (e.g., a second component), said component may be directly connected to said other component, or may be connected via another component (e.g., a third component).

[0032] In this document, "configured to" may be used interchangeably with, for example, "suitable for," "capable of," "modified to," "made to," "capable of," or "designed to," either in hardware or software. In some contexts, the phrase "a device configured to" may mean that the device is "capable of" doing something together with other devices or components. For example, the phrase "a processor configured to perform A, B, and C" may mean a dedicated processor (e.g., an embedded processor) for performing the operations, or a general-purpose processor (e.g., a CPU or application processor) that can perform the operations by executing one or more software programs stored in a memory device.

[0033] An electronic device according to various embodiments of the present document may include, for example, at least one of a smartphone, a tablet PC, a desktop PC, a laptop PC, a netbook computer, a workstation, and a server.

[0034] Referring to FIG. 1, an electronic device (101) within a network environment (100) according to various embodiments is described. The electronic device (101) may include a bus (110), a processor (120), a memory (130), an input / output interface (150), a display (160), and a communication interface (170). In some embodiments, the electronic device (101) may omit at least one of the components or additionally include other components. The bus (110) may include a circuit that connects the components (110-170) to each other and transmits communication (e.g., control messages or data) between the components. The processor (120) may include one or more of a central processing unit, an application processor, or a communication processor (CP). The processor (120) may, for example, execute operations or data processing related to control and / or communication of at least one other component of the electronic device (101).

[0035] The memory (130) may include volatile and / or non-volatile memory. The memory (130) may store, for example, commands or data related to at least one other component of the electronic device (101). According to one embodiment, the memory (130) may store software and / or programs (140). The programs (140) may include, for example, a kernel (141), middleware (143), an application programming interface (API) (145), and / or an application program (or “application”) (147). At least a portion of the kernel (141), middleware (143), or API (145) may be referred to as an operating system. The kernel (141) may control or manage system resources (e.g., a bus (110), a processor (120), or a memory (130)) used to execute operations or functions implemented in other programs (e.g., middleware (143), API (145), or application programs (147)). In addition, the kernel (141) may provide an interface that allows the middleware (143), API (145), or application programs (147) to control or manage system resources by accessing individual components of the electronic device (101).

[0036] The middleware (143) may, for example, act as an intermediary to enable the API (145) or the application program (147) to communicate with the kernel (141) to exchange data. In addition, the middleware (143) may process one or more task requests received from the application program (147) according to priority. For example, the middleware (143) may give at least one of the application programs (147) a priority to use the system resources (e.g., bus (110), processor (120), memory (130), etc.) of the electronic device (101) and process the one or more task requests. The API (145) is an interface for the application (147) to control functions provided by the kernel (141) or the middleware (143), and may include, for example, at least one interface or function (e.g., command) for file control, window control, image processing, or character control. The input / output interface (150) can, for example, transmit commands or data input from a user or another external device to other component(s) of the electronic device (101), or output commands or data received from other component(s) of the electronic device (101) to the user or another external device.

[0037] The display (160) may include, for example, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a micro electro mechanical systems (MEMS) display, or an electronic paper display. The display (160) may, for example, display various contents (e.g., text, images, videos, icons, and / or symbols) to the user. The display (160) may include a touch screen and may receive, for example, a touch, gesture, proximity, or hovering input using an electronic pen or a part of the user's body. The communication interface (170) may, for example, establish communication between the electronic device (101) and an external device (e.g., a first external electronic device (102), a second external electronic device (104), or a server (106)). For example, the communication interface (170) can be connected to a network (162) via wireless communication or wired communication to communicate with an external device (e.g., a second external electronic device (104) or a server (106)).

[0038] The wireless communication may include, for example, cellular communication using at least one of LTE, LTE-A (LTE Advance), CDMA (code division multiple access), WCDMA (wideband CDMA), UMTS (universal mobile telecommunications system), WiBro (Wireless Broadband), or GSM (Global System for Mobile Communications). In one embodiment, the wireless communication may include, for example, at least one of WiFi (wireless fidelity), Bluetooth, Bluetooth low energy (BLE), Zigbee, near field communication (NFC), Magnetic Secure Transmission, radio frequency (RF), or body area network (BAN). In one embodiment, the wireless communication may include GNSS. The GNSS may be, for example, GPS (Global Positioning System), Glonass (Global Navigation Satellite System), Beidou Navigation Satellite System (hereinafter "Beidou"), or Galileo, the European global satellite-based navigation system. Hereinafter, in this document, "GPS" may be used interchangeably with "GNSS." Wired communication may include at least one of, for example, USB (universal serial bus), HDMI (high definition multimedia interface), RS-232 (recommended standard 232), power line communication, or POTS (plain old telephone service).The network (162) may include at least one of a telecommunications network, for example, a computer network (e.g., a LAN or WAN), the Internet, or a telephone network.

[0039] Each of the first and second external electronic devices (102, 104) may be the same or a different type of device as the electronic device (101). According to various embodiments, all or part of the operations executed in the electronic device (101) may be executed in another one or more electronic devices (e.g., electronic devices (102, 104), or server (106). According to one embodiment, when the electronic device (101) is to perform a certain function or service automatically or upon request, the electronic device (101) may request at least some functions related thereto from another device (e.g., electronic device (102, 104), or server (106)) instead of executing the function or service by itself or in addition. The other electronic device (e.g., electronic device (102, 104), or server (106)) may execute the requested function or additional function and transmit the result to the electronic device (101). The electronic device (101) may process the received result as is or additionally to provide the requested function or service. For this purpose, for example, cloud computing, distributed computing, or client-server computing technology may be used.

[0040]

[0041] FIG. 2 is a flowchart illustrating a method of operating an electronic device according to various embodiments.

[0042] FIG. 3 is an exemplary diagram showing the entire operation sequence of the Tasador framework of the present invention according to various embodiments.

[0043] FIG. 4 is an exemplary diagram illustrating a connected CPU prediction method according to various embodiments.

[0044]

[0045] Before going into a detailed description of the present invention, referring to FIGS. 1 and 3, the electronic device (100) may include a Tasador framework (300), a communication interface (170), and a processor (120). Here, the Tasador framework (300) may be an executing entity that performs operations 201 to 211, which will be described later, and may be used with the same meaning as the electronic device (100) described above or may represent a component of the electronic device (100). In addition, the framework (300) may include a Tasador manager (310) and a Tasador collector (320), each of which will be described later in the description of operations 201 to 211. The communication interface (170) may be a component responsible for all communications occurring within the electronic device (100) and data transmission and reception with an external main device (not shown) and an adjacent terminal device (not shown). The processor (120) may be a subject that performs operations 201 to 211, which will be described later.

[0046]

[0047] In operation 201, according to various embodiments, the processor (120) of the electronic device (100) may receive user request information from the Tasador manager (310) via the communication interface (170). According to one embodiment, the user request information may include a network SLO specified in terms of network bandwidth, target workload, and message size.

[0048]

[0049] In operation 203, according to various embodiments, the processor (120) of the electronic device (100) may determine whether a learning dataset exists in the Tasador collector (320). Specifically, the learning dataset may refer to a pre-trained machine learning model for the target workload included in the user request information received in operation 201. According to one embodiment, if the learning dataset exists in the Tasador collector (320), operation 209, which will be described later, may be performed, and if the learning dataset does not exist, operation 205, which will be described later, may be performed.

[0050]

[0051] In operation 205, according to various embodiments, the processor (120) of the electronic device (100) may activate the Tasador collector (320) through the Tasador manager (310).

[0052] In operation 207, according to various embodiments, the processor (120) of the electronic device (100) may collect the required training dataset through the Tasador collector (320) activated in operation 205. Specifically, the Tasador manager (310) may create a test virtual machine (VM) 330 and then measure the network bandwidth while changing the CPU allocation for the target workload, thereby learning the CPU requirements for achieving the specified SLO. According to one embodiment, at least one training dataset learned through operation 207 may be returned to the Tasador manager (310). In addition, the Tasador manager (310) may internally store all of the training datasets returned in this manner. The training datasets stored in this manner may serve to skip operations 205 and 207 and move on to operation 209 when receiving user request information including the same target workload in the future.

[0053]

[0054] In operation 209, according to various embodiments, the processor (120) of the electronic device (100) may apply user request information as input data of the CPU allocation prediction model to the CPU allocation prediction model to predict an optimal CPU allocation value corresponding to the SLO of the network bandwidth. According to one embodiment, the CPU allocation prediction model may include Model-G (Guest) (340) and Model-H (Host) (350). According to further embodiments, the processor (120) of the electronic device (100) may be configured to input user request information to Model-G (340) to predict a CPU allocation of a virtual machine (VM), and may be configured to input user request information to Model-H (350) to predict a CPU allocation of a host. Specifically, the Tasador manager (310) may train a machine learning (ML) model for both Model-G (340) and Model-H (350). These models are trained using the same training dataset obtained from the Tasador collector (320), and can mainly use linear regression (LR), support vector regression (SVR), and random forest regression (RFR), but random forest regression (RFR) can be used in the present invention. However, this is only an example, and it is obvious that any kind of method can be used to facilitate the implementation of the present invention.

[0055] According to further embodiments, the processor (120) of the electronic device (100) may be configured to predict the CPU allocation of the host by additionally inputting the VM CPU allocation predicted by the Model-G (340) into the Model-H (350). Specifically, referring to FIG. 4, the CPU usage of the guest and the host can be predicted in a cascade manner using a linked CPU prediction method. First, the Model-G (340) receives the SLO and the message size as input and outputs the guest CPU prediction, and then the Model-H (350) receives the predicted guest CPU together with the SLO and the message size as input to predict the host CPU. Then, the accuracy of the separate and linked CPU prediction methods can be compared.

[0056]

[0057] In operation 211, according to various embodiments, the processor (120) of the electronic device (100) may execute CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager (310). Specifically, the Tasador manager (310) may apply the predicted CPU allocation of Model-G and Model-H to the physical system executing the VM (i.e., the target VM executing the target workload), and Tasador may allocate CPU resources to both the guest and the host so that the VM configured with the SLO may receive an appropriate CPU allocation close to the optimal CPU utilization for the specified SLO without unnecessary CPU waste. For example, Tasador may apply the predicted CPU allocation by utilizing the parameters provided by the Linux Cgroup, and may configure the relevant parameters so that the Linux CFS may provide the CPU allocation predicted by Model-G and Model-H without directly intervening in the process scheduling of the Linux CFS.

[0058] According to various embodiments, an electronic device including a Tasador framework that operates based on a model that converts a service level objective (SLO) of a network bandwidth into an optimal CPU allocation value includes a Tasador manager, a Tasador collector, a communication interface, and a processor, wherein the processor is configured to receive user request information through the communication interface, apply the user request information to a CPU allocation prediction model as input data of a CPU allocation prediction model, and predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth, and execute CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager, wherein the CPU allocation prediction model can be trained based on a training data set received from the Tasador collector through the communication interface.

[0059] According to various embodiments, the user request information may include a network SLO specified in terms of the network bandwidth, target workload, and message size.

[0060] According to various embodiments, the processor, if the learning dataset does not exist in the Tasador collector, activates the Tasador collector through the Tasador manager, and the Tasador collector is configured to collect the learning dataset, and the learning dataset may include a CPU allocation corresponding to at least one specific workload.

[0061] According to various embodiments, the CPU allocation prediction model includes Model-G (Guest) and Model-H (Host), and the processor is configured to input the user request information into Model-G to predict a CPU allocation of a VM (virtual machine), and to input the user request information into Model-H to predict a CPU allocation of a host, and each of Model-G and Model-H can be trained based on the training data set.

[0062] According to various embodiments, the processor may be configured to predict the CPU allocation of the host by additionally inputting the VM CPU allocation predicted by the Model-G into the Model-H.

[0063] According to various embodiments, a method of operating an electronic device including a Tasador framework that operates based on a model that converts an SLO of a network bandwidth into an optimal CPU allocation value, the method comprising: a step of receiving user request information through a communication interface of the electronic device, a step of applying the user request information to a CPU allocation prediction model as input data of the CPU allocation prediction model, thereby predicting the optimal CPU allocation value corresponding to the SLO of the network bandwidth; and a step of executing a CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager of the electronic device, wherein the CPU allocation prediction model can be learned based on a learning data set received from a Tasador collector of the electronic device through the communication interface of the electronic device.

[0064]

[0065] The term "module" or "part" used in this document includes a unit composed of hardware, software, or firmware, and can be used interchangeably with terms such as logic, logic block, component, or circuit, for example. The "module" or "part" can be an integrally configured component or a minimum unit or a part thereof that performs one or more functions. The "module" or "part" can be implemented mechanically or electronically, and can include, for example, an ASIC (application-specific integrated circuit) chip, FPGAs (field-programmable gate arrays), or a programmable logic device, known or to be developed in the future, that performs certain operations, and can be executed by the processor (120). At least a part of the device (e.g., modules or functions thereof) or method (e.g., operations) according to various embodiments can be implemented as instructions stored in a computer-readable storage medium (e.g., memory (130)) in the form of a program module. When the above command is executed by a processor (e.g., processor (120)), the processor can perform a function corresponding to the command. The computer-readable recording medium may include a hard disk, a floppy disk, a magnetic medium (e.g., a magnetic tape), an optical recording medium (e.g., a CD-ROM, a DVD, a magneto-optical medium (e.g., a floptical disk), a built-in memory, etc. The command may include a code generated by a compiler or a code executable by an interpreter. A module or program module according to various embodiments may include at least one or more of the above-described components, some of which may be omitted, or other components may be further included. Operations performed by a module, a program module, or other components according to various embodiments may be executed sequentially, in parallel, iteratively, or heuristically, or at least some operations may be executed in a different order, omitted, or other operations may be added.

[0066] The embodiments disclosed in this document are presented for the purpose of explaining and understanding the disclosed technical content, and do not limit the scope of the present disclosure. Therefore, the scope of the present disclosure should be interpreted to include all modifications or various other embodiments based on the technical concepts of the present disclosure.

Claims

1. An electronic device including a Tasador framework that operates based on a model that converts network bandwidth SLO (Service level objectives) into optimal CPU allocation values, Tasador Manager, Tasador Collector, Communication interface and Contains a processor, The above processor, Through the above communication interface, the Tasador manager receives user request information, As input data of a CPU allocation prediction model, the user request information is applied to the CPU allocation prediction model to predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth. Through the above Tasador manager, CPU allocation corresponding to the above optimal CPU allocation value is set to be executed, The above CPU allocation prediction model is learned based on a learning dataset received from the Tasador collector through the communication interface. Electronic devices.

2. In paragraph 1, The above user request information includes the network SLO specified in terms of the network bandwidth, target workload and message size. Electronic devices.

3. In paragraph 1, The above processor, If the above training dataset does not exist in the above Tasador collector, Through the above Tasador manager, activate the above Tasador collector, The above Tasdor collector is set to collect the above learning dataset, The above learning dataset includes CPU allocations corresponding to at least one specific workload. Electronic devices.

4. In paragraph 3, The above CPU allocation prediction model includes Model-G (Guest) and Model-H (Host), The above processor, By inputting the user request information into the Model-G, it is set to predict the CPU allocation of a VM (virtual machine), By inputting the user request information into the Model-H, it is set to predict the CPU allocation of the host, Each of the above Model-G and Model-H is trained based on the above learning dataset. Electronic devices.

5. In paragraph 4, The above processor, By additionally inputting the VM CPU allocation predicted by the Model-G into the Model-H, the CPU allocation of the host is set to be predicted. Electronic devices.

6. A method of operating an electronic device including a Tasador framework that operates based on a model that converts the SLO of network bandwidth into an optimal CPU allocation value, Through the communication interface of the electronic device, the Tasador manager of the electronic device receives user request information; As input data of a CPU allocation prediction model, a step of applying the user request information to the CPU allocation prediction model to predict the optimal CPU allocation value corresponding to the SLO of the network bandwidth, and A step of executing CPU allocation corresponding to the optimal CPU allocation value through the Tasador manager of the electronic device, The above CPU allocation prediction model is learned based on a learning dataset received from the Tasador collector of the electronic device through the communication interface of the electronic device. How an electronic device operates.

Images