WO2023152004A1 - Verfahren und vorrichtung zum betreiben einer cloud-applikation und zum auswählen einer skalierungstrategie - Google Patents

Verfahren und vorrichtung zum betreiben einer cloud-applikation und zum auswählen einer skalierungstrategie Download PDF

Info

Publication number
WO2023152004A1
WO2023152004A1 PCT/EP2023/052458 EP2023052458W WO2023152004A1 WO 2023152004 A1 WO2023152004 A1 WO 2023152004A1 EP 2023052458 W EP2023052458 W EP 2023052458W WO 2023152004 A1 WO2023152004 A1 WO 2023152004A1
Authority
WO
WIPO (PCT)
Prior art keywords
microservices
quality
measure
cloud application
resource
Prior art date
Application number
PCT/EP2023/052458
Other languages
English (en)
French (fr)
Inventor
Stephan Rhode
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Publication of WO2023152004A1 publication Critical patent/WO2023152004A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs

Definitions

  • the invention relates to cloud applications that are created as distributed applications using microservices.
  • the invention also relates to resource management measures for such a cloud application.
  • a software application that runs in a cloud i. H. a central unit remote from the end user, is often implemented as a distributed application with so-called microservices.
  • the microservices are individual, separately operated software modules that can be accessed via suitable interfaces, e.g. B. so-called REST interfaces and message queues, communicate with each other and thereby interact to provide a software task.
  • Microservices of a software application can be scaled using so-called scalers, i.e. duplicated or moved to modified processing resources or hardware platforms, e.g. hardware with higher or lower computing power.
  • scalers are inflexible and can only respond to the diverse possibilities of load requirements to a limited extent . Disclosure of Invention
  • a method for operating a software application in a cloud system according to claim 1 and a method for providing a scaling strategy for a cloud application according to the independent claim are provided.
  • the present application also relates to a corresponding computer program product and a corresponding machine-readable storage medium.
  • a method for operating a cloud application in a cloud system with multiple interacting microservices is provided, with the following steps:
  • the scaling strategy determines processing resources to be allocated to the microservices depending on a quality of service measure that indicates a performance of the cloud application, and depending on a resource measure that indicates an effort of the processing resources already assigned to the microservices.
  • Microservices are operated in a computing environment that is usually remote from users and has a communication connection with users, preferably wireless.
  • Microservices are individual, separately operated software modules that can be accessed via suitable interfaces, e.g. B. so-called REST interfaces and message queues, communicate with each other. This allows microservices to interact to provide a software task.
  • suitable interfaces e.g. B. so-called REST interfaces and message queues
  • Communication between the microservices and between microservices and one or more databases and/or users takes place via Communication messages, eg in the form of request or response information, either via HTTP request or via message queues.
  • the latter represent a message service that allows asynchronous processing of information. It works according to the FIFO (First In First Out) principle and enables information to be processed in parallel when there is a high load or high communication load.
  • microservice architecture is more heterogeneous than uniform software.
  • Microservices can also be developed for a cloud application in different programming languages and operated on different platforms, such as VM, Azure, ABS, on-premise clouds. Microservice architectures thus offer significantly greater freedom of design than uniform software applications.
  • a microservice can run on a processing resource, such as one or more computing devices, such as processors, compute cores, virtual machines, etc., and is scalable.
  • microservices of a software application are usually scaled using implemented scalers, which can be part of an operating system, such as K8S, or are implemented as automatic scalers.
  • a scaler microservices can be duplicated or moved to modified processing resources or hardware platforms, e.g. hardware with more or less computing power.
  • the communication messages can be made available to one or more parallelized microservices of the same type through the scalers.
  • Scalers are usually operated on a rule-based basis, with the scaling rules, i. H. the allocation of computing capacities to individual microservices is rule-based, e.g. B. depending on load requirements.
  • the scaling strategy is set up to determine processing resources to be allocated to the microservices based on at least one current value of the quality of service measure and at least one current value of the resource measure for processing resources currently allocated to the microservices.
  • the above method therefore provides a method of operating a scaler for a distributed application that is operated based on a reference variable, ie a quality-of-service measure that quantifies a quality-of-service (the higher the better the fulfillment of requirements).
  • the scaler is designed to maximize the quality of service measure so that resource allocation can always be done in an optimal manner.
  • the scaling strategy determines the processing resources to be allocated to the microservices in such a way that the amount of processing resources required to achieve or fulfill a predefined or definable quality of service measure is minimized.
  • a controller design is proposed for a scaler of a distributed application.
  • the allocation of resources is carried out according to the reference variable.
  • the resource allocation can be viewed by the scaler as the controller, the distributed software application as the control system, and the command variable as a measure of the quality of service.
  • the quality of service measure can depend on a maximum or average response time of the cloud application and/or on an average information content of a response from the cloud application.
  • the performance of the cloud application is considered over a specified period of time.
  • the response times can be determined over a specified period of time and a quality of service measure, e.g. B. can be determined as the average response time.
  • system statuses such as the filling statuses of the message queues and the like, can also be taken into account in the quality of service measure.
  • the quality of service measure can also be determined indirectly depending on hardware states, CPU load, memory utilization or a combination of both hardware states for each microservice and/or system states of one or more databases such as write and read rates become.
  • the hardware states and system states have the advantage that they are very easy to record compared to, for example, response times per user. Provision can be made for the scaling strategy to have a controller structure for regulation to one or more desired quality-of-service measures, in particular one or more values or value ranges of one or more quality-of-service measures.
  • the control by the scaler i.e. the "regulation" is designed in such a way that the total effort corresponding to an effort or cost function is minimized as much as possible.
  • the cost function may be based on one or more resource metrics, such as CPU load, memory used, message queue length, microservice response time, or a combination of one or more of these resource metrics.
  • a value of the effort function for a predetermined allocation of resources is greater the more technical resources are allocated and/or used.
  • the effort function can be a function which assigns a dimensionless number to one or, for example, a weighted combination of several of the resource measures mentioned above, which number represents an effort associated with the provision or allocation of the resources.
  • the scaler is operated in such a way that a trade-off between maximizing the quality of service measure and minimizing the effort, e.g. represented by cloud costs, which depend on the resource measure, is achieved.
  • the effort can correspond to the costs of the available or provided processing resources that are used for the execution of the microservices and their communication.
  • the maximum response time of a website that processes information through a microservice backend as a cloud application can increase the quality of service from e.g. B. 100 ms can be specified. If the number of website users increases, the cloud application can become overloaded and the response time increases. As a result, the quality of service decreases, and additional processing resources are allocated to the requested microservice until the response time of the website is acceptable again. Accordingly, a microservice that is too parallelized can be scaled down if the number of users of the website and thus the load requirement on the website increases reduced and thus the effort for the assigned processing resources are too high according to the effort or cost function.
  • a resource measure that quantitatively evaluates the processing resources provided can be used to evaluate the processing resources.
  • the processing resources can be adjusted according to the quality of service measure, a target specification for the quality of service measure and depending on an effort, for example cloud costs, which are carried out by a or several resource measures, such as a CPU load, a used memory, a length of the message queues, a response time of a microservice and a combination of one or more of these resource measures.
  • a method for providing a scaling strategy for a specific cloud application in a cloud system with a number of interacting microservices is provided, with the following steps: determining a runtime, a processor load and a memory requirement of the microservices using timing simulation software;
  • Provision of several different scaling strategies which, in particular, depend on a quality of service measure that indicates a performance of the cloud application, and depending on a resource measure that indicates the costs of the processing resources already assigned to the microservices determine processing resources to be allocated to microservices;
  • the scaling strategy can be selected from the plurality of scaling strategies using one or more predefined or predefinable criteria, for example threshold values for the corresponding aggregated quality of service measures and the corresponding aggregated resource measures. For example, a scaling strategy can be selected for which the corresponding aggregated quality of service measure exceeds a first threshold value and for which the corresponding aggregated resource measure falls below a second threshold value.
  • the above method provides a possibility of designing the scaler for a cloud application in a suitable manner.
  • the distributed software application can be modeled with timing simulation software in order to determine the runtime and memory requirements for the microservices it contains.
  • load simulations are carried out to determine an expected quality of service - measure to determine.
  • the load simulations are based on different scaling strategies, which are characterized by different strategies for allocating resources to the individual microservices depending on a load state through the usage scenarios, so that a quality of service measure and the resource expenditure for each combination resulting from different scaling strategies and different usage scenarios.
  • the load simulations are used to determine the quality of service measure and the effort involved in allocating the processing resources in order to be able to make a suitable selection of one of the scaling strategies based on the resulting Pareto front. This enables selection of an optimized scaling strategy for a distributed application.
  • the aggregated quality of service measure corresponds to an average or a maximum value of the quality of service measures for the evaluation period and/or wherein the aggregated resource measure corresponds to an average or a maximum value of the resource measures for the evaluation period.
  • the resource measure can specify a resource expenditure, in particular resource costs, in particular dependent on a number of the required cores, virtual machines and/or processors, a network bandwidth and/or a main memory requirement.
  • FIG. 1 shows a schematic representation of a cloud application formed from microservices
  • FIG. 2 shows a flowchart to illustrate a method for operating a scaler for the cloud application of FIG. 1;
  • FIG. 3 shows a flowchart to illustrate a method for selecting a scaling strategy for the scaling used for a specific cloud application
  • Figure 1 shows schematically the structure of a cloud application in a cloud system 1 as a distributed application with a variety of microservices 2.
  • the cloud system represents a computing environment for processing and executing the microservices 2.
  • the microservices 2 can be developed in different programming languages be and operated in different platforms of the cloud system 1, such as VM, Azure, AWS, on-premise clouds and the like.
  • the microservices 2 are connected to one another via communication interfaces 3 .
  • One or more databases 4 can also be provided, which are connected to one or more microservices 2 via a corresponding Communication interface 3 are connected, where one or more of the microservices 2 communicates.
  • the communication interfaces 3 can be in the form of a REST interface, for example, and is used to communicate between a respective microservice 2 and a database 4 or other microservices 2 .
  • the cloud application can be used by a large number of users via a network-accessible user interface 5, which can also be in the form of a microservice.
  • Communication can take place either via HTTP request or via message queues.
  • a message queue enables asynchronous processing and works according to the FIFO principle. This makes it possible to handle a short-term data backlog without affecting other system components, such as other microservices, without overloading other microservices.
  • a scaler 6 is provided which, according to a predefined scaling strategy, specifies specific processing resources for each microservice 2, for example in the form of a number of cores and/or processor power and the like, and can change them.
  • the scaler 6 can also duplicate microservices 2 and operate them in parallel as separate microservices 2, with corresponding tasks being able to be assigned to the similar microservices 2 in parallel for the load distribution.
  • the method for operating the scaler 6, in particular in the cloud system 1, is now described in more detail on the basis of the flowchart in FIG.
  • the proposed scaling strategy here corresponds to a "two-point control" through which the processing resources are allocated.
  • step S1 the scaler 6 is operated in accordance with a predetermined assignment of processing resources and a quality of service measure is continuously recorded.
  • the quality of service measure represents a measure that indicates a performance, such as a user-friendliness of the cloud application, such as, for example an average response time of a website, with which information is determined and provided by the microservice backend in the cloud application, over the total number of users and/or over a predetermined evaluation period.
  • Another way of evaluating the quality of service measure in a different way or in combination with the response time is to evaluate the degree of completeness of the information transmitted to the user.
  • system statuses such as the fill status of the message queues and the like, can also be taken into account in the quality of service measure.
  • the quality of service measure can also be determined indirectly depending on hardware states, CPU load, memory utilization or a combination of both hardware states for each microservice and/or system states of one or more databases such as write and read rate become.
  • the hardware states and system states have the advantage that they are very easy to record compared to e.g. response times per user.
  • the quality of service measure quantifies the overall performance of the cloud system 1 during the evaluation period.
  • step S2 it is checked whether the quality of service measure meets a predetermined first QoS criterion. If the quality of service measure is specified quantitatively, this can be done, for example, using a threshold value comparison with a QoS threshold value as the first QoS criterion. If the QoS threshold value, which indicates a falling quality of service, is undershot (alternative: no), the quality of service measure does not meet the specified first QoS criterion and the method continues with step S3, otherwise (alternative: yes) the method continues with step S4.
  • step S3 additional processing resources are assigned to the cloud application.
  • the resource allocation of the additional processing resources e.g. the number of booked computing nodes with the cloud provider (scale out procedure), or the allocated CPU performance and/or main memory per computing node (scale up procedure) can take place for one, several or all microservices and in particular depend on the CPU load they cause, the RAM they require or the filling status of the message queues connected to them or a combination of several of these details.
  • the determination of the CPU load, the memory required by the microservices or the filling status of the message queues connected to them is carried out via the cloud operating system, such as K8S. CPU and RAM utilization is recorded for each container (smallest unit of a microservice). The method then continues with step S1.
  • step S4 it is checked whether the quality of service measure meets a predetermined second QoS criterion. If the quality of service measure is specified quantitatively, this can be done, for example, using a further threshold value comparison with a further QoS threshold value as the second QoS criterion. If the further QoS threshold value, which indicates an increasing quality of service, is exceeded (alternative: no), the quality of service measure does not meet the specified second QoS criterion and the method continues with step S1, otherwise (alternative: Yes), the method continues with step S5.
  • step S5 allocations of processing resources are deleted from the cloud application.
  • the resource allocation of the processing resources to be removed e.g. the number of booked computing nodes with the cloud provider (scale out procedure), or the allocated CPU performance and/or main memory per computing node (scale up procedure) can be for one, several or all microservices take place and in particular depend on the CPU load caused by them, the main memory they require or the filling level of the message queues connected to them or a combination of several of these specifications.
  • the above scaling strategy corresponds to a two-point scaler that works in the form of a two-point control.
  • proportional scalers or the like can also be provided, which determine and allocate the resource allocation directly as a function of the quality of service measure.
  • FIG. 3 shows a method for determining a suitable scaling strategy with which the scaler 6 can be operated.
  • step S11 the distributed Application analyzed and the microservices parameterized with respective values for runtimes, processing loads and memory requirements.
  • step S12 various scaling strategies are provided or designed, which, in particular, each determine an allocation of processing resources depending on a quality of service measure.
  • step S13 usage scenarios are specified for different load situations. Load simulations are carried out for each load scenario and for each scaling strategy and the quality of service measure and the resource measure are recorded.
  • the quality of service measure can be specified as a function of usage properties, such as a maximum response time of a website, and/or the information content of the response from the cloud application.
  • the states CPU load, memory utilization, or a combination of these can be used for each microservice to determine the quality of service measure.
  • system states of databases such as write and read rates are system states that are suitable for determining the quality of service measure.
  • the quality of service measure is determined for an evaluation period that is based on the length of time of the usage scenario or corresponds to it.
  • the resource measure specifies a resource expenditure, for example represented by a number of computing nodes ordered from the cloud provider, or a network bandwidth reserved or available for the cloud application.
  • the resource measure can be determined by the cloud provider through the number of cores, virtual machines or processors required, the network bandwidth and the memory requirements.
  • a Pareto front can now result, which is determined by the aggregated quality of service measures QoS (e.g. quality of service measures averaged over the usage scenarios) and the resource measures K (e.g. over the usage scenarios average resource measures) for the different scaling strategies.
  • QoS quality of service measures averaged over the usage scenarios
  • K resource measures
  • the quality of service measure for the different N Usage scenarios are averaged in order to be able to optimally choose the scaling strategy across different loads, such as low, medium or high loads.
  • a scaling strategy is selected from the Pareto front, which indicates a good trade-off between the quality of service measure and the resource measure over the scaling strategies considered.
  • the scaling strategy can be selected using one or more predefined or predefinable criteria, for example threshold values for the quality of service measure and the resource measure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein computer-implementiertes Verfahren zum Betreiben einer Cloud-Applikation in einem Cloudsystem, mit mehreren interagierenden Microservices (2), mit folgenden Schritten: - Zuweisen (S3, S5) von Verarbeitungs-Ressourcen zu den Microservices (2) mithilfe eines Skalierers gemäß einer Skalierungsstrategie; - Betreiben (S1) der Cloud-Applikation gemäß den zugewiesenen Verarbeitungs-Ressourcen; wobei die Skalierungsstrategie abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand der den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices zuzuweisende Verarbeitungs-Ressourcen bestimmt.

Description

Beschreibung
Titel
Verfahren und Vorrichtung zum Betreiben einer Cloud-Applikation und zum Auswahlen einer Skalierunqstrateqie
Technisches Gebiet
Die Erfindung betrifft Cloud-Applikationen, die als verteilte Applikation mithilfe von Microservices erstellt sind. Die Erfindung betrifft weiterhin Maßnahmen zum Ressourcen-Management einer solchen Cloud-Applikation.
Technischer Hintergrund
Eine Software-Applikation, die in einer Cloud, d. h. einer endnutzerfernen Zentraleinheit, ausgeführt wird, wird häufig als verteilte Applikation mit sogenannten Microservices implementiert. Die Microservices sind einzelne separat betriebene Softwaremodule, die über geeignete Schnittstellen, z. B. sogenannten REST- Interfaces und Message Queues, miteinander kommunizieren und dadurch zum Bereitstellen einer Software-Aufgabe interagieren.
Microservices einer Software-Applikation können über sogenannte Skalkierer skaliert, d.h. vervielfältigt oder auf geänderte Verarbeitungs-Ressourcen bzw. Hardwareplattformen, z.B. rechenstärkere oder rechenschwächere Hardware, verschoben, werden, Bekannte Skalierer sind unflexibel und können auf die vielfältigen Möglichkeiten von Lastanforderungen nur in begrenztem Maße eingehen. Offenbarung der Erfindung
Erfindungsgemäß sind ein Verfahren zum Betreiben einer Software-Applikation in einem Cloud-System gemäß Anspruch 1 sowie ein Verfahren zum Bereitstellen einer Skalierungsstrategie für eine Cloud-Applikation gemäß dem nebengeordneten Anspruch vorgesehen. Gegenstand der vorliegenden Anmeldung sind auch ein entsprechendes Computerprogrammprodukt und ein entsprechendes maschinenlesbares Speichermedium.
Weitere Ausgestaltungen sind in den abhängigen Ansprüchen angegeben.
Gemäß einem ersten Aspekt ist ein Verfahren zum Betreiben einer Cloud- Applikation in einem Cloudsystem mit mehreren interagierenden Microservices vorgesehen, mit folgenden Schritten:
Zuweisen von Verarbeitungs-Ressourcen zu den Microservices mithilfe eines Skalierers gemäß einer Skalierungsstrategie;
Betreiben der Cloud-Applikation gemäß den zugewiesenen Verarbeitungs- Ressourcen; wobei die Skalierungsstrategie abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand der den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices zuzuweisende Verarbeitungs-Ressourcen bestimmt.
Zum Bereitstellen einer Cloud-Applikation wird diese häufig in Form eines Systems aus Microservices implementiert, die miteinander kommunizieren. Microservices werden in einer Rechenumgebung betrieben, die in der Regel nutzerfern ist und mit Benutzern in einer, bevorzugt drahtlosen, Kommunikationsverbindung steht.
Microservices sind einzelne separat betriebene Softwaremodule, die über geeignete Schnittstellen, z. B. sogenannten REST- Interfaces und Message Queues, miteinander kommunizieren. Dadurch können Microservices zum Bereitstellen einer Software-Aufgabe interagieren.
Die Kommunikation zwischen den Microservices und zwischen Microservices und einer oder mehreren Datenbanken und/oder Nutzern erfolgt über Kommunikationsmitteilungen, z.B. in Form von Anfrage oder Antwortinformationen, entweder über HTTP-Request oder über Message Queues. Letztere stellen einen Nachrichtendienst dar, der eine asynchrone Verarbeitung von Informationen erlaubt. Er arbeitet nach dem FIFO (First In First Out)-Prinzip und ermöglicht, bei hoher Last bzw. hoher Kommunikationslast Informationen parallel abzuarbeiten.
Die Microservice-Architektur ist heterogener als einheitliche Software. Microservices können auch für eine Cloud-Applikation in unterschiedlichen Programmiersprachen entwickelt sein und auf unterschiedlichen Plattformen betrieben werden, wie beispielsweise VM, Azure, ABS, On-Premise-Clouds. Microservice-Architekturen bieten dadurch eine deutlich größeren Gestaltungsfreiheit als einheitliche Software-Applikationen. Ein Microservice kann auf einer Verarbeitungsressource, die beispielsweise eine oder mehrere Recheneinrichtungen, wie beispielsweise Prozessoren, Rechen-Cores, Virtual Machines usw., ausgeführt werden und ist skalierbar.
Das Skalieren von einem, mehreren oder allen Microservices einer Software- Applikation erfolgt in der Regel über implementierte Skalierer, die Teil eines Betriebssystems, wie beispielsweise K8S, sein können oder als automatische Skalierer implementiert sind. Durch einen Skalierer können Microservices vervielfältigt oder auf geänderte Verarbeitungs-Ressourcen bzw. Hardwareplattformen, z.B. rechenstärkere oder rechenschwächere Hardware, verschoben werden. Durch die Skalierer können die Kommunikationsmitteilungen einem oder mehreren parallelisierten gleichartigen Microservices zur Verfügung gestellt werden. Skalierer werden in der Regel regelbasiert betrieben, wobei die Skalierungsregeln, d. h. die Zuordnung von Rechenkapazitäten zu einzelnen Microservices, regelbasiert erfolgt z. B. abhängig von Lastanforderungen.
Die Skalierungsstrategie ist eingerichtet, den Microservices zuzuweisende Verarbeitungs-Ressourcen basierend auf zumindest einem aktuellen Wert des Quality-of-Service-Maßes und zumindest einem aktuellen Wert des Ressourcenmaßes für aktuell den Microservices zugewiesenen Verarbeitungsressourcen zu bestimmen.
Das obige Verfahren sieht daher ein Verfahren zum Betreiben eines Skalierers für eine verteilte Applikation vor, der basierend auf einer Führungsgröße, d.h. ein Quality-of-Service-Maß, das einen Quality-of-Service quantifiziert (je höher desto bessere Anforderungserfüllung) angibt, betrieben wird. Der Skalierer wird so ausgelegt, dass das Quality-of-Service-Maß maximiert wird, so dass eine Ressourcenzuweisung stets in optimaler Weise erfolgen kann.
Das heißt, mit anderen Worten, die Skalierungsstrategie bestimmt den Microservices zuzuweisende Verarbeitungs-Ressourcen insbesondere derart, dass ein zum Erreichen bzw. Erfüllen eines vorgegebenen oder vorgebbaren Quality-of-Service-Maßes erforderlicher Aufwand von Verarbeitungs-Ressourcen minimiert wird.
Im Kern wird hierfür für einen Skalierer einer verteilten Applikation ein Reglerentwurf vorgeschlagen. Dabei wird die Ressourcenzuweisung entsprechend der Führungsgröße durchgeführt. Bei einer Microservice-Architektur kann die Ressourcenzuweisung durch den Skalierer als Regler, die verteilte Software-Applikation als Regelungsstrecke und die Führungsgröße als Maß des Quality of Service (Quality-of-Service-Maß) angesehen werden.
Weiterhin kann das Quality-of-Service-Maß abhängig von einer maximalen oder durchschnittlichen Antwortzeit der Cloud-Applikation und/oder von einem durchschnittlichen Informationsgehalt einer Antwort der Cloud-Applikation abhängen.
Zur Bestimmung des Quality-of-Service-Maß wird die Performance der Cloud- Applikation über einen vorgegebenen Zeitraum betrachtet. Beispielsweise können die Antwortzeiten über einen vorgegebenen Zeitraum ermittelt und daraus ein Quality-of-Service-Maß, z. B. als mittlere Antwortzeit bestimmt werden. Alternativ können auch Systemzustände, wie beispielsweise die Füllzustände der Message Queues und dergleichen, in dem Quality-of-Service-Maß berücksichtigt werden. Darüber hinaus kann das Quality-of-Service-Maß auch indirekt abhängig von Hardware-Zuständen CPU-Last, Speicherauslastung oder eine Kombination beider Hardware-Zustände für jeden Microservice und/oder Systemzustände einer oder mehrerer Datenbanken wie z.B. Schreib- und Lese-Rate bestimmt werden. Die Hardware-Zustände und Systemzustände haben den Vorteil, dass sie im Vergleich zu z.B. Antwortzeiten je Benutzer sehr einfach zu erfassen sind. Es kann vorgesehen sein, dass die Skalierungsstrategie eine Reglerstruktur für eine Regelung auf ein oder mehrere gewünschtes Quality-of-Service-Maße, insbesondere ein oder mehrere Werte oder Wertebereiche eines oder mehrerer Quality-of-Service-Maße aufweist.
Die Steuerung durch den Skalierer, d.h. die „Regelung“ ist so ausgelegt, dass ein Gesamtaufwand entsprechend einer Aufwands- oder Kostenfunktion möglichst minimiert werden. Die Aufwandsfunktion kann bspw. auf ein oder mehreren Ressourcenmaßen basieren, wie beispielsweise einer CPU-Last, einem genutzten Arbeitsspeicher, einer Länge der Message Queues, einer Antwortzeit eines Microservice oder einer Kombination aus einem oder mehreren dieser Ressourcenmaße. Hierbei ist ein Wert der Aufwandsfunktion für eine vorgegebene Zuweisung von Ressourcen umso größer je mehr technische Ressourcen zugewiesen und/oder benutzt werden. Die Aufwandsfunktion kann eine Funktion sein, welcher einem oder einer bspw. gewichteten Kombination von mehreren der vorstehend genannten Ressourcenmaßen eine dimensionslose Zahl zuordnet, welche einen mit der Bereitstellung bzw. Zuweisung der Ressourcen verbundenen Aufwand repräsentiert.
Dazu wird der Skalierer so betrieben, dass ein Trade-off zwischen einer Maximierung des Quality-of-Service-Maßes und einer Minimierung des Aufwands, bspw. repräsentiert durch Cloud-Kosten, die von dem Ressourcenmaß abhängen, erreicht wird. Der Aufwand kann den Kosten der verfügbaren bzw. bereitgestellten Verarbeitungs-Ressourcen, die für die Ausführung der Microservices und deren Kommunikation genutzt werden, entsprechen.
Beispielsweise kann der Quality of Service durch die maximale Antwortzeit einer Website, die Informationen durch ein Microservice-Backend als Cloud-Applikation verarbeitet, von z. B. 100 ms vorgegeben werden. Steigt die Anzahl der Nutzer der Website, kann die Cloud-Applikation überlastet werden und die Antwortzeit steigt. Dadurch nimmt der Quality of Service ab, und es erfolgt eine zusätzliche Zuweisung von Verarbeitungs-Ressourcen zu dem nachgefragten Microservice, bis die Antwortzeit der Website wieder akzeptabel ist. Entsprechend kann ein zu stark parallelisierter Microservice herabskaliert werden, wenn die Anzahl der Nutzer der Website und dadurch die Lastanforderung an die Webseite sich verringert und dadurch der Aufwand für die zugewiesenen Verarbeitungs- Ressourcen entsprechend der Aufwands- bzw. Kostenfunktion zu hoch sind.
Zur Bewertung der Verarbeitungs-Ressourcen kann ein Ressourcenmaß verwendet werden, dass die bereitgestellten Verarbeitungs-Ressourcen quantitativ bewertet. Gemäß einer Ausführungsform kann die Anpassung der Verarbeitungs-Ressourcen entsprechend dem Quality-of-Service-Maß, einer Soll- Vorgabe für das Quality-of-Service-Maß und abhängig von einem Aufwand, bspw. Cloud-Kosten, erfolgen, die von einem oder mehreren Ressourcenmaßen, wie beispielsweise eine CPU-Last, einen genutzten Arbeitsspeicher, eine Länge der Message Queues, einer Antwortzeit eines Microservice und eine Kombination aus einem oder mehreren dieser Ressourcenmaße erfolgen.
Gemäß einem weiteren Aspekt ist ein Verfahren zum Bereitstellen einer Skalierungsstrategie für eine bestimmte Cloud-Applikation in einem Cloudsystem mit mehreren interagierenden Microservices vorgesehen, mit folgenden Schritten: Bestimmen einer Laufzeit, einer Prozessorlast und eines Speicherbedarfs der Microservices mit einer Timing-Simulationssoftware;
Bereitstellen von mehreren verschiedenen Nutzungsszenarien, die jeweils für eine Auswertungszeitdauer einen zeitlichen Verlauf von Lastanforderungen an die Cloud-Applikation vorgeben;
Bereitstellen von mehreren verschiedenen Skalierungsstrategien, die, insbesondere jeweils, abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das Kosten der den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices zuzuweisende Verarbeitungs-Ressourcen bestimmen;
Durchführen von Lastsimulationen, um für jede der Skalierungsstrategien ein aggregiertes Quality-of-Service-Maß aus den Quality-of-Service-Maßen aller Nutzungsszenarien und ein aggregiertes Ressourcenmaß aus den Ressourcenmaßen aller Nutzungsszenarien zu bestimmen;
- Auswählen der Skalierungsstrategie aus den mehreren Skalierungsstrategien abhängig von den entsprechenden aggregierten Quality-of-Service-Maßen und den entsprechenden aggregierten Ressourcenmaßen. Das Auswahlen der Skalierungsstrategie aus den mehreren Skalierungsstrategien kann unter Verwendung eines oder mehrerer vorgegebener oder vorgebbarer Kriterien, bspw. Schwellenwerte für die entsprechenden aggregierten Quality-of- Service-Maße und den entsprechenden aggregierten Ressourcenmaßen erfolgen. Bspw. kann eine Skalierungsstrategie ausgewählt werden, für welche das entsprechende aggregierte Quality-of-Service-Maß einen ersten Schwellenwert überschreitet und für welche das entsprechende aggregierte Ressourcenmaß einen zweiten Schwellenwert unterschreitet.
Das obige Verfahren sieht entsprechend eine Möglichkeit vor, den Skalierer für eine Cloud-Applikation in geeigneter Weise auszulegen. Dazu kann die verteilte Software-Applikation mit einer Timing-Simulationssoftware modelliert werden, um für die enthaltenen Microservices die Laufzeit und den Speicherbedarf zu ermitteln. Basierend auf einer Mehrzahl vorgegebener unterschiedlicher Nutzungsszenarien, die sich beispielsweise durch zeitliche Verläufe der Nutzung bzw. der Last, insbesondere in Form der Anzahl der Nutzer, der angeforderten Aufgaben und dergleichen, unterscheiden können, werden Lastsimulationen durchgeführt, um ein voraussichtliches Quality-of-Service-Maß zu bestimmen. Die Lastsimulationen werden basierend auf verschiedenen Skalierungsstrategien, die sich durch unterschiedliche Strategien zur Zuordnung von Ressourcen zu den einzelnen Microservices abhängig von einem Belastungszustand durch die Nutzungsszenarien auszeichnen, vorgenommen, so dass sich jeweils ein Quality- of-Service-Maß und der Ressourcenaufwand für jede Kombination aus verschiedenen Skalierungsstrategien und verschiedenen Nutzungsszenarien ergibt. Die Lastsimulationen dienen dazu, das Quality-of-Service-Maß und den Aufwand der Zuordnung der Verarbeitungs-Ressourcen zu ermitteln, um eine geeignete Auswahl einer der Skalierungsstrategien anhand der sich daraus ergebenden Pareto-Front vornehmen zu können. Dies ermöglicht eine Auswahl einer optimierten Skalierungsstrategie für eine verteilte Applikation.
Es kann vorgesehen sein, dass das aggregierte Quality-of-Service-Maß einem Mittelwert oder einem Maximalwert der Quality-of-Service-Maße für die Auswertungszeitdauer und/oder wobei das aggregierte Ressourcenmaß einem Mittelwert oder einem Maximalwert der Ressourcenmaße für die Auswertungszeitdauer entsprechen. Weiterhin kann das Ressourcenmaß einen Ressourcenaufwand, insbesondere Ressourcenkosten, angeben, insbesondere abhängig von einer Anzahl der benötigten Cores, Virtual Machines und/oder Prozessoren, einer Netzwerkbandbreite und/oder eines Bedarfs an Arbeitsspeicher.
Kurzbeschreibung der Zeichnungen
Ausführungsformen werden nachfolgend anhand der beigefügten Zeichnungen näher erläutert. Es zeigen:
Figur 1 eine schematische Darstellung einer aus Microservices gebildeten Cloud-Applikation;
Figur 2 ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Betreiben eines Skalierers für die Cloud-Applikation der Figur 1 ; und
Figur 3 ein Flussdiagramm zur Veranschaulichung eines Verfahrens zum Auswählen einer Skalierungsstrategie für den für eine bestimmte Cloud-Applikation eingesetzten Skalieren
Beschreibung von Ausführungsformen
Figur 1 zeigt schematisch den Aufbau einer Cloud-Applikation in einem Cloud- System 1 als verteilte Applikation mit einer Vielzahl von Microservices 2. Das Cloud-System stellt eine Rechenumgebung zur Verarbeitung und Ausführung der Microservices 2 dar. Die Microservices 2 können in unterschiedlichen Programmiersprachen entwickelt sein und in unterschiedlichen Plattformen des Cloud-Systems 1 betrieben werden, wie beispielsweise VM, Azure, AWS, On- Premise-Clouds und dergleichen.
Die Microservices 2 sind über Kommunikationsschnittstellen 3 miteinander verbunden. Auch können eine oder mehrere Datenbanken 4 vorgesehen sein, die mit einer oder mehreren Microservices 2 über eine entsprechende Kommunikationsschnittstelle 3 verbunden sind, denen eine oder mehrere der Microservices 2 kommuniziert.
Die Kommunikationsschnittstellen 3 können beispielsweise in Form eines REST- Interface, ausgebildet sein und dient dazu, eine Kommunikation eines jeweiligen Microservice 2 mit einer Datenbank 4 oder anderen Microservices 2 durchzuführen. Weiterhin kann die Cloud-Applikation über eine netzwerkzugreifbare Benutzerschnittstelle 5, die ebenfalls als Microservice ausgebildet sein kann, durch eine Vielzahl von Nutzern genutzt werden.
Die Kommunikation kann entweder per HTTP-Request oder über Message Queues erfolgen. Eine Message Queue ermöglicht eine asynchrone Verarbeitung und arbeitet nach dem FIFO-Prinzip. Dies ermöglicht es, einen kurzfristigen Datenrückstau ohne Beeinträchtigung anderer Systemkomponenten, wie beispielsweise anderen Microservices, zu behandeln, ohne dass es zu Überlastungen anderer Microservices führt.
Es ist ein Skalierer 6 vorgesehen, der entsprechend einer vorgegebenen Skalierungsstrategie jedem Microservice 2 bestimmte Verarbeitungs-Ressourcen vorgibt, bspw. in Form einer Anzahl von Cores und/oder Prozessorleistung und dergleichen, und diese ändern kann. Zudem kann der Skalierer 6 auch Microservices 2 vervielfältigen und diese als separate Microservices 2 parallel betreiben, wobei entsprechende Aufgaben den gleichartigen Microservices 2 parallel zur Lastaufteilung zugeordnet werden können.
Anhand des Flussdiagramms der Figur 2 wird nun das Verfahren zum Betreiben des Skalierers 6, insbesondere in dem Cloud-System 1 , näher beschrieben. Die vorgeschlagene Skalierungsstrategie entspricht hier einer „Zweipunktregelung“, durch die die Verarbeitungsressourcen zugeordnet werden.
In Schritt S1 wird der Skalierer 6 entsprechend einer vorgegebenen Zuordnung von Verarbeitungs-Ressourcen betrieben und kontinuierlich ein Quality-of-Service- Maß erfasst.
Das Quality-of-Service-Maß stellt ein Maß dar, das eine Performance, wie z.B. eine Benutzungsfreundlichkeit der Cloud-Applikation angibt, wie beispielsweise eine durchschnittliche Antwortzeit einer Website, mit der Informationen durch das Microservice-Backend in der Cloud-Applikation ermittelt und bereitgestellt werden, über die Gesamtzahl der Nutzer und/oder über einen vorbestimmten Auswertungszeitraum. Weitere Möglichkeiten das Quality-of-Service-Maß auf andere Weise oder in Kombination mit der Antwortzeit zu bewerten, besteht darin, das Maß der Vollständigkeit der an den Benutzer übermittelten Information zu bewerten.
Zur Bestimmung des Quality-of-Service-Maß können weiterhin auch Systemzustände, wie beispielsweise die Füllzustände der Message Queues und dergleichen, in dem Quality-of-Service-Maß berücksichtigt werden. Darüber hinaus kann das Quality-of-Service-Maß auch indirekt abhängig von Hardware- Zuständen CPU-Last, Speicherauslastung oder eine Kombination beider Hardware-Zustände für jeden Microservice und/oder Systemzustände einer oder mehrerer Datenbanken wie z.B. Schreib- und Lese-Rate bestimmt werden. Die Hardware-Zustände und Systemzustände haben den Vorteil, dass sie im Vergleich zu z.B. Antwortzeiten je Benutzer sehr einfach zu erfassen sind. Das Quality-of- Service-Maß quantifiziert dabei die gesamte Performance des Cloud-Systems 1 während der Auswertungszeitdauer.
In Schritt S2 wird überprüft, ob das Quality-of-Service-Maß ein vorbestimmtes erstes QoS-Kriterium erfüllt. Wird das Quality-of-Service-Maß quantitativ angegeben, kann dies beispielsweise mithilfe eines Schwellenwertvergleichs mit einem QoS-Schwellenwert als erstes QoS-Kriterium erfolgen. Bei Unterschreiten des QoS-Schwellenwerts, das einen sinkenden Quality of Service angibt, (Alternative: Nein) erfüllt das Quality-of-Service-Maß das vorgegebene erste QoS- Kriterium nicht und das Verfahren mit Schritt S3 fortgesetzt, anderenfalls (Alternative: Ja) wird das Verfahren mit Schritt S4 fortgesetzt.
In Schritt S3 werden zusätzliche Verarbeitungs-Ressourcen der Cloud-Applikation zugewiesen. Die Ressourcen-Zuweisung der zusätzlichen Verarbeitungs- Ressourcen, z.B. die Anzahl gebuchter Rechenknoten beim Cloud Anbieter (scale out Verfahren), oder die zugewiesene CPU-Leistung und/oder Arbeitsspeicher je Rechenknoten (scale up Verfahren) kann für einen, mehrere oder alle Microservices erfolgen und insbesondere abhängen von der durch sie verursachten CPU-Last, den von ihnen jeweils benötigten Arbeitsspeicher oder den Füllzustand der mit ihnen verbundenen Message Queues oder Kombinationen aus mehreren dieser Angaben erfolgen. Die Bestimmung der CPU-Last, der von den Microservices jeweils benötigten Arbeitsspeicher oder den Füllzustand der mit ihnen verbundenen Message Queues erfolgt über das Cloud Betriebssystem, wie z.B. K8S. Je Container (kleinste Einheit eines Microservice) wird CPU und RAM Auslastung erfasst. Anschließend wird das Verfahren mit Schritt S1 fortgesetzt.
In Schritt S4 wird überprüft, ob das Quality-of-Service-Maß ein vorbestimmtes zweites QoS-Kriterium erfüllt. Wird das Quality-of-Service-Maß quantitativ angegeben, kann dies beispielsweise mithilfe eines weiteren Schwellenwertvergleichs mit einem weiteren QoS-Schwellenwert als zweites QoS- Kriterium erfolgen. Bei Überschreiten des weiteren QoS-Schwellenwerts, das einen steigenden Quality of Service angibt, (Alternative: Nein) erfüllt das Quality- of-Service-Maß das vorgegebene zweite QoS-Kriterium nicht und das Verfahren wird mit Schritt S1 fortgesetzt, anderenfalls (Alternative: Ja) wird das Verfahren mit Schritt S5 fortgesetzt.
In Schritt S5 werden Zuweisungen von Verarbeitungs-Ressourcen von der Cloud- Applikation gelöscht. Die Ressourcen-Zuweisung der zu entfernenden Verarbeitungs-Ressourcen, z.B. die Anzahl gebuchter Rechenknoten beim Cloud Anbieter (scale out Verfahren), oder die zugewiesene CPU-Leistung und/oder Arbeitsspeicher je Rechenknoten (scale up Verfahren) kann für einen, mehrere oder alle Microservices erfolgen und insbesondere abhängen von der durch sie verursachten CPU-Last, den von ihnen jeweils benötigten Arbeitsspeicher oder den Füllzustand der mit ihnen verbundenen Message Queues oder Kombinationen aus mehreren dieser Angaben erfolgen.
Die obige Skalierungsstrategie entspricht einem Zweipunktskalierer, der in Form einer Zweipunktregelung arbeitet. Alternativ können auch Proportionalskalierer oder dergleichen vorgesehen sein, die die Ressourcen-Zuweisung direkt abhängig von dem Quality-of-Service-Maß bestimmt und zuweist.
Figur 3 zeigt ein Verfahren zum Ermitteln einer geeigneten Skalierungsstrategie, mit der der Skalierer 6 betrieben werden kann.
In Schritt S11 wird dazu mithilfe einer Timing-Simulationssoftware die verteilte Applikation analysiert und die Microservices mit jeweiligen Werten für Laufzeiten, Verarbeitungslasten und Speicherbedarf parametrisiert.
Weiterhin werden in Schritt S12 verschiedene Skalierungsstrategien, die, insbesondere jeweils, eine Zuordnung von Verarbeitungs-Ressourcen abhängig von einem Quality-of-Service-Maß bestimmen, bereitgestellt oder entworfen.
In Schritt S13 werden für verschiedene Belastungssituationen Nutzungsszenarien vorgegeben. Es werden für jedes Lastszenario und für jede Skalierungsstrategie Lastsimulationen durchgeführt und das Quality-of-Service-Maß und das Ressourcenmaß erfasst. Das Quality-of-Service-Maß kann, wie oben beschrieben, abhängig von Nutzungseigenschaften, wie beispielsweise einer maximalen Antwortzeit einer Website, und/oder dem Informationsgehalt der Antwort der Cloud-Applikation angegeben werden. Darüber hinaus können die Zustände CPU- Last, Arbeitsspeicher-Auslastung, oder eine Kombination davon für jeden Microservice für die Bestimmung des Quality-of-Service-Maßes benutzt werden. Weiterhin sind Systemzustände von Datenbanken wie z.B. Schreib- und Lese- Rate Systemzustände, die zur Bestimmung des Quality-of-Service-Maßes geeignet sind. Dabei wird das Quality-of-Service-Maß für einen Auswertungszeitraum bestimmt, der sich an der zeitlichen Länge des Nutzungsszenarios orientiert oder dieser entspricht.
Das Ressourcenmaß gibt einen Ressourcenaufwand an, beispielsweise repräsentiert durch eine Anzahl bestellter Rechenknoten beim Cloud Anbieter, oder eine für die Cloud-Applikation reservierte bzw. verfügbare Netzwerkbandbreite. Das Ressourcenmaß kann durch die Anzahl der benötigten Cores, Virtual Machines oder Prozessoren, der Netzwerkbandbreite sowie des Bedarfs an Arbeitsspeicher durch den Cloud Anbieter ermittelt werden.
Wie in Figur 4 dargestellt, kann sich nun eine Pareto-Front ergeben, die durch die aggregierten Quality-of-Service-Maße QoS (z.B. über die Nutzungsszenarien gemittelten Quality-of-Service-Maße) und die Ressourcenmaße K (z.B. über die Nutzungsszenarien gemittelten Ressourcenmaße) für die verschiedenen Skalierungsstrategien erfasst.
Insbesondere wird das Quality-of-Service-Maß für die verschiedenen N Nutzungsszenarien gemittelt, um die Skalierungsstrategie über verschiedene Belastungen, wie beispielsweise niedrige, mittlere oder hohe Belastung, optimal wählen zu können.
In Schritt S14 wird aus der Pareto-Front eine Skalierungsstrategie ausgewählt, die über die betrachteten Skalierungsstrategien einen guten Trade-off zwischen dem Quality-of-Service-Maß und dem Ressourcenmaß angibt. Das Auswählen der Skalierungsstrategie kann unter Verwendung eines oder mehrerer vorgegebener oder vorgebbarer Kriterien, bspw. Schwellenwerte für das Quality-of-Service-Maß und das Ressourcenmaß, erfolgen.

Claims

Ansprüche
1 . Computer-implementiertes Verfahren zum Betreiben einer Cloud-Applikation in einem Cloudsystem, mit mehreren interagierenden Microservices (2), mit folgenden Schritten:
Zuweisen (S3, S5) von Verarbeitungs-Ressourcen zu den Microservices (2) mithilfe eines Skalierers gemäß einer Skalierungsstrategie;
Betreiben (S1) der Cloud-Applikation gemäß den zugewiesenen Verarbeitungs-Ressourcen; wobei die Skalierungsstrategie abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand von den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices zuzuweisende Verarbeitungs-Ressourcen bestimmt.
2. Verfahren nach Anspruch 1 , wobei die Skalierungsstrategie eine Reglerstruktur für eine Regelung auf ein oder mehrere gewünschte Quality-of-Service-Maße aufweist.
3. Verfahren nach Anspruch 1 oder 2, wobei das Quality-of-Service-Maß abhängig von einer maximalen oder durchschnittlichen Antwortzeit der Cloud-Applikation und/oder von einem durchschnittlichen Informationsgehalt einer Antwort der Cloud-Applikation abhängt.
4. Vorrichtung zum Betreiben einer Cloud-Applikation in einem Cloudsystem, mit mehreren interagierenden Microservices (2), wobei die Vorrichtung ausgebildet ist zum:
Zuweisen von Verarbeitungs-Ressourcen zu den Microservices (2) mithilfe eines Skalierers gemäß einer Skalierungsstrategie;
Betreiben der Cloud-Applikation gemäß den zugewiesenen Verarbeitungs-Ressourcen;
- wobei die Skalierungsstrategie abhängig von einem Quality-of-Service- Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand der den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices zuzuweisende Verarbeitungs-Ressourcen bestimmt. Computer-implementiertes Verfahren zum Bereitstellen einer Skalierungsstrategie für eine bestimmte Cloud-Applikation in einem Cloudsystem, mit mehreren interagierenden Microservices (2), mit folgenden Schritten:
Bestimmen (S11) einer Laufzeit, einer Prozessorlast und eines Speicherbedarfs der Microservices (2) mit einer Timing- Simulationssoftware;
Bereitstellen (S13) von mehreren verschiedenen Nutzungsszenarien, die jeweils für eine Auswertungszeitdauer einen zeitlichen Verlauf von Lastanforderungen an die Cloud-Applikation vorgeben;
Bereitstellen (S12) von mehreren verschiedenen Skalierungsstrategien, die abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand der den Microservices bereits zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices (2) zuzuweisende Verarbeitungs-Ressourcen bestimmen;
Durchführen (S13) von Lastsimulationen, um für jede der Skalierungsstrategien ein aggregiertes Quality-of-Service-Maß aus den Quality-of-Service-Maßen aller Nutzungsszenarien und ein aggregiertes Ressourcenmaß aus den Ressourcenmaßen aller Nutzungsszenarien zu bestimmen;
- Auswählen (S14) der Skalierungsstrategie aus den mehreren Skalierungsstrategien abhängig von den entsprechenden aggregierten Quality-of-Service-Maßen und den entsprechenden aggregierten Ressourcenmaßen. Verfahren nach Anspruch 5, wobei das aggregierte Quality-of-Service-Maß einem Mittelwert oder einem Maximalwert der Quality-of-Service-Maße für die Auswertungszeitdauer und/oder wobei das aggregierte Ressourcenmaß einem Mittelwert oder einem Maximalwert der Ressourcenmaße für die Auswertungszeitdauer entsprechen. Verfahren nach Anspruch 5 oder 6, wobei das Ressourcenmaß einen Ressourcenaufwand angibt, insbesondere abhängig von einer Anzahl der benötigten Cores, Virtual Machines und/oder Prozessoren, der Netzwerkbandbreite und/oder eines Bedarfs an Arbeitsspeicher. Vorrichtung zum Bereitstellen einer Skalierungsstrategie für eine bestimmte Cloud-Applikation in einem Cloudsystem, mit mehreren interagierenden Microservices (2), wobei die Vorrichtung ausgebildet ist zum:
Bestimmen einer Laufzeit, einer Prozessorlast und eines Speicherbedarfs der Microservices (2) mit einer Timing- Simulationssoftware;
Bereitstellen von mehreren verschiedenen Nutzungsszenarien, die jeweils für eine Auswertungszeitdauer einen zeitlichen Verlauf von Lastanforderungen an die Cloud-Applikation vorgeben;
Bereitstellen von mehreren verschiedenen Skalierungsstrategien, die abhängig von einem Quality-of-Service-Maß, das eine Performance der Cloud-Applikation angibt, und abhängig von einem Ressourcenmaß, das einen Aufwand der zugewiesenen Verarbeitungs-Ressourcen angibt, den Microservices (2) zuzuweisende Verarbeitungs-Ressourcen bestimmt;
Durchführen von Lastsimulationen, um für jede der Skalierungsstrategien ein aggregiertes Quality-of-Service-Maß aus den Quality-of-Service-Maßen aller Nutzungsszenarien und ein aggregiertes Ressourcenmaß aus den Ressourcenmaßen aller Nutzungsszenarien zu bestimmen;
- Auswählen der Skalierungsstrategie aus den mehreren Skalierungsstrategien abhängig von den entsprechenden aggregierten Quality-of-Service-Maßen und den entsprechenden aggregierten Ressourcenmaßen. Computerprogrammprodukt, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 3, 5 bis 7 auszuführen. Maschinenlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch einen Computer diesen veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 3, 5 bis 7 auszuführen.
PCT/EP2023/052458 2022-02-08 2023-02-01 Verfahren und vorrichtung zum betreiben einer cloud-applikation und zum auswählen einer skalierungstrategie WO2023152004A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022201291.7A DE102022201291A1 (de) 2022-02-08 2022-02-08 Verfahren und Vorrichtung zum Betreiben einer Cloud-Applikation und zum Auswählen einer Skalierungstrategie
DE102022201291.7 2022-02-08

Publications (1)

Publication Number Publication Date
WO2023152004A1 true WO2023152004A1 (de) 2023-08-17

Family

ID=85173008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/052458 WO2023152004A1 (de) 2022-02-08 2023-02-01 Verfahren und vorrichtung zum betreiben einer cloud-applikation und zum auswählen einer skalierungstrategie

Country Status (2)

Country Link
DE (1) DE102022201291A1 (de)
WO (1) WO2023152004A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021040584A1 (en) * 2019-08-26 2021-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Entity and method performed therein for handling computational resources

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130019015A1 (en) 2011-07-12 2013-01-17 International Business Machines Corporation Application Resource Manager over a Cloud
DE102011079429A1 (de) 2011-07-19 2013-01-24 Siemens Aktiengesellschaft Performancesimulation von medizintechnischen Prozeduren in einer Client-Server-Umgebung
US8756609B2 (en) 2011-12-30 2014-06-17 International Business Machines Corporation Dynamically scaling multi-tier applications vertically and horizontally in a cloud environment
US9697045B2 (en) 2015-03-24 2017-07-04 International Business Machines Corporation Selecting resource allocation policies and resolving resource conflicts
DE102015207570A1 (de) 2015-04-24 2016-10-27 Siemens Aktiengesellschaft Ressourcen-Optimierer für Software-Ökosysteme
DE202016101711U1 (de) 2016-03-31 2017-07-03 Dextradata Gmbh Kapazitätsplanungswerkzeug, insbesondere einer Informationstechnologie-Infrastruktur
US11281499B2 (en) 2017-02-05 2022-03-22 Intel Corporation Microservice provision and management
CN108059928B (zh) 2018-01-02 2019-12-03 厦门致力金刚石科技股份有限公司 一种片材胶及其胶合方法
WO2020172692A2 (en) 2020-04-27 2020-08-27 Futurewei Technologies, Inc. Dynamic resource tuning cloud service

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021040584A1 (en) * 2019-08-26 2021-03-04 Telefonaktiebolaget Lm Ericsson (Publ) Entity and method performed therein for handling computational resources

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SAVAS PARASTATIDIS ET AL: "Grid Computing Using Web Services Technologies", 20 August 2005, PEER-TO-PEER, GRID, AND SERVICE-ORIENTATION IN DIGITAL LIBRARY ARCHITECTURES; [LECTURE NOTES IN COMPUTER SCIENCE;;LNCS], SPRINGER-VERLAG, BERLIN/HEIDELBERG, PAGE(S) 9 - 24, ISBN: 978-3-540-28711-7, XP019014910 *

Also Published As

Publication number Publication date
DE102022201291A1 (de) 2023-08-10

Similar Documents

Publication Publication Date Title
DE69822935T2 (de) Vorrichtung und Verfahren zur dynamischen Regelung der Betriebsmittelzuweisung in einem Computersystem
DE60301202T2 (de) Verfahren und vorrichtung zur verkehrssteuerung einer web-farm
DE602004011890T2 (de) Verfahren zur Neuverteilung von Objekten an Recheneinheiten
DE112010005096T5 (de) Verfahren und Vorrichtungen zum Bewerten der Ressourcen-Kapazität in einem System von virtuellen Containern
EP3125056B1 (de) System und verfahren zur steuerung und/oder analytik eines industriellen prozesses
EP1831786A1 (de) Verfahren zur verteilung von rechenzeit in einem rechnersystem
DE112020004651B4 (de) Multi-tenant-etl-ressourcenaufteilung
EP1924913B1 (de) Steuerung eines zugriffs auf dienste und/oder ressourcen eines datenverarbeitungssystems
DE112021005586T5 (de) Automatisches skalieren einer abfrage-steuerungsroutine für arbeitslasten im bereich big data auf unternehmensebene
EP2804134B1 (de) Verfahren und System zur Fuzzy-basierten Regelung einer Zuordnung von Ressourcen in einem System
DE69825118T2 (de) Autonome Überlaststeuerung für verteilte Echtzeitsysteme
DE102016125020B4 (de) Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme
WO2023152004A1 (de) Verfahren und vorrichtung zum betreiben einer cloud-applikation und zum auswählen einer skalierungstrategie
EP1149338A1 (de) Lastverteilungsverfahren eines multiprozessorsystems und multiprozessorsystem
DE102016125023B4 (de) Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme
DE69724270T2 (de) Verfahren und vorrichtung zur feststellung der anzahl von zugeteilten zugriffen während der latenz des schlechtesten falles
CN112667392A (zh) 云计算资源分配方法、装置、计算机设备和存储介质
DE102018219852A1 (de) Verfahren und Vorrichtung zum Ermitteln einer Systemkonfiguration für ein verteiltes System
DE602004011757T2 (de) Datenverarbeitungssystem zur Zuweisung von Objekten an Verarbeitungseinheiten
EP1708086A2 (de) Computersystem und Verfahren zur Aufteilung und Zuteilung von Rechenleistung innerhalb eines Computersystems
EP1047990B1 (de) Vorrichtung und verfahren zur steuerung von prozessen auf einem computersystem
DE60008265T2 (de) Methode zur Bandbreitenzuteilung für Netzwerkendgeräte in einem Kommunikationsnetzwerk mit einen Medienzugriffssteuerungsgerät zur Ausführung dieser Methode
EP4064044A1 (de) Dynamische verteilung einer gesamtressource in einer container-laufzeitumgebung
DE112021001257T5 (de) Informationsverarbeitungsvorrichtung
DE102022204718A1 (de) Verfahren für eine adaptive Ressourcenzuweisung für Anwendungen in einem verteilten System heterogener Rechenknoten

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23703178

Country of ref document: EP

Kind code of ref document: A1