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.