Anwendungsskalierung konfigurieren

Mit IBM Cloud® Code Engine müssen Sie sich keine Gedanken über die Skalierung Ihrer Anwendung machen, da die Anzahl der laufenden Instanzen einer Anwendung auf der Grundlage der eingehenden Arbeitslasten automatisch nach oben oder unten (auf Null) skaliert wird. Da die Skalierung automatisch durchgeführt wird, zahlen Sie nicht für Ressourcen, die Sie nicht verwendet haben.

Code Engine überwacht die Anzahl der Anforderungen im System und skaliert die Anwendungsinstanzen nach oben und unten, um die Arbeitslast eingehender Anforderungen einschließlich aller HTTP-Verbindungen zu Ihrer Anwendung abzudecken. Diese HTTP-Verbindungen können Anforderungen sein, die von außerhalb Ihres Projekts, von anderen Workloads, die in Ihrem Projekt ausgeführt werden, oder von Ereignisproduzenten, die Sie möglicherweise abonniert haben, stammen, unabhängig davon, wo sich diese Produzenten befinden. Code Engine repliziert automatisch Anwendungsinstanzen und konfiguriert die Netzinfrastruktur, um einen Lastausgleich der Anforderungen auf alle Instanzen zu durchzuführen.

Funktionsweise der Skalierung

Code Engine überwacht die Anzahl der Anforderungen im System und skaliert die Anwendungsinstanzen gemäß den Einschränkungen, die durch die Einstellungen der Anwendung in Bezug auf Nebenläufigkeit bzw. gemeinsamen Zugriff gegeben sind.

Um die Anwendungsskalierung über die Code Engine-Konsole zu beobachten, navigieren Sie zu Ihrer bestimmten Anwendungsseite. Während die Anwendung ausgeführt wird, beträgt die Anzahl der aktiven Instanzen je nach der von Ihnen festgelegten Einstellung für die maximale Anzahl der Instanzen mindestens 1. Wenn die Anwendung weniger Anforderungen verarbeitet als der konfigurierte gemeinsame Zielzugriff, skaliert die Anwendung die Anzahl der aktiven Instanzen auf die konfigurierte Mindestanzahl von Instanzen. Wenn die Mindestanzahl der Instanzen auf 0 (Standardwert) eingestellt ist, wird die Anwendung auf Null skaliert und die Anzahl der Instanzen für die Anwendung entspricht 0. Wenn für die Anwendung ein Scale-down durchgeführt und eine Anforderung an die Anwendung weitergeleitet wird, skaliert Code Engine die Anwendung und leitet die Anforderung an die neu erstellte Anwendungsinstanz weiter.

Damit Anwendungen ein Scale-down ordnungsgemäß durchführen können, muss Ihr Anwendungscode ein SIGTERM-Signal verarbeiten. Wenn Code Engine automatisch skaliert wird, wird ein SIGTERM-Signal an Ihre Anwendung gesendet. Wenn Ihre Anwendung das SIGTERM-Signal nicht verarbeitet, bleiben Ihre App-Instanzen für die durch den Anforderungszeitlimitwert konfigurierte Zeit im Status Terminating (Standardwert ist 300 Sekunden). Nach Ablauf des Anforderungszeitlimits sendet Code Engine ein Signal SIGKILL, um das Stoppen der App-Instanzen im Status Terminating zu erzwingen.

Skalierungsgrenzwerte

Sie können Skalierungsgrenzen konfigurieren, indem Sie einen Bereich von Werten für die minimale und maximale Anzahl von Instanzen festlegen, in denen Code Engine die Anzahl der aktiven Instanzen Ihrer Anwendung automatisch skaliert. Konfigurieren Sie diesen Bereich, wenn Sie Anwendungen erstellen oder aktualisieren.

Mindestanzahl der Instanzen-Die Mindestanzahl der Instanzen der App, die immer aktiv sind, auch wenn keine Anforderungen verarbeitet werden. Wenn für diese Option der Wert 0 (Standardwert) festgelegt ist, entfernt Code Engine alle Instanzen, sobald kein Datenverkehr die Anwendung erreicht. Wenn Sie immer eine aktive Instanz Ihrer Anwendung beibehalten möchten, setzen Sie diesen Wert auf einen Wert größer als 0. Wenn Sie eine Anwendung mit Code Engine über die Konsole erstellen oder aktualisieren, legen Sie den Wert für die Mindestanzahl von Instanzen im Abschnitt 'Automatische Skalierung' der Registerkarte Ressourcen & Skalierung fest. Mit der CLI geben Sie die Option --min-scale in den Feldern app create und app update befehle an.
Maximale Anzahl Instanzen-Die maximale Anzahl Instanzen, die für die App ausgeführt werden können. Die automatische Skalierung erfolgt bis zu dieser Grenze. Wenn Sie diesen Wert auf 0 setzen, skaliert die Anwendung nach Bedarf, und die Skalierung der Anwendung wird nur durch die Instanzen pro Ressourcenquote für das Projekt Ihrer Anwendung begrenzt. Grenzwerte und Kontingente für Code Engine enthält weitere Informationen hierzu. Wenn Sie eine Anwendung mit Code Engine über die Konsole erstellen oder aktualisieren, legen Sie den Wert für die maximale Anzahl von Instanzen im Abschnitt 'Automatische Skalierung' der Registerkarte Ressourcen & Skalierung fest. Mit der CLI geben Sie die Option --max-scale in den Feldern app create und app update befehle an. Der Standardwert für diese Option ist 10.

Wenn Sie Ihre Anwendungen mit Ereignisproduzenten verbinden, müssen Sie Häufigkeit und Umfang der von diesen Produzenten generierten Ereignisse bei der Festlegung der Skalierungsgrenzwerte berücksichtigen. Wenn Sie z. B. viele Ereignisse gleichzeitig erwarten und die Verarbeitung jedes Ereignisses mehrere Minuten dauern kann, benötigen Sie möglicherweise einen höheren maximalen Skalenwert als wenn jedes Ereignis schnell verarbeitet werden kann. Wenn Sie einen zu niedrigen Wert festlegen, können Verzögerungen beim Ereignisempfang eintreten und Ereignisse sogar aufgrund von Zeitlimits gelöscht werden, während auf verfügbare Verarbeitungsressourcen gewartet wird.

Einstellungen für automatische Skalierung für gemeinsamen Zugriff und Timing

Verwenden Sie die folgenden Konfigurationseinstellungen zur Steuerung der Anwendungsskalierung.

Gleichzeitigkeit - Dieser Wert gibt an, wie viele Anfragen jede Instanz Ihrer Anwendung auf einmal verarbeiten kann. Ein Währungswert von 100 bedeutet z. B., dass Ihr Code 100 gleichzeitige Anfragen gleichzeitig verarbeiten kann. Dieser Wert ist ein „fester Grenzwert". Dies bedeutet, dass Code Engine nicht mehr als die Anzahl der Anforderungen (wie in der Einstellung für den gemeinsamen Zugriff angegeben) zulässt, um eine beliebige Instanz Ihrer Anwendung zu erreichen. Wenn Ihr Code single threaded ist und nur eine Anfrage zur gleichen Zeit verarbeiten kann, sollten Sie die Gleichzeitigkeit auf 1 setzen. Wenn die angegebene Anzahl von Anfragen an alle laufenden Instanzen Ihrer Anwendung gesendet wurde, erhöht Code Engine die Anzahl der Instanzen in Vorbereitung auf weitere Anfragen. Wenn Sie eine Anwendung mit Code Engine über die Konsole erstellen oder aktualisieren, legen Sie den maximalen Wert für den gemeinsamen Zugriff im Abschnitt 'Autoscaling' der Registerkarte Resources & scaling fest. Geben Sie bei der CLI die Option --concurrency für die Befehle app create und app update an.
Zielgleichzeitigkeit - Dieser Wert dient als "weiche Grenze" oder als Anzahl von Anfragen pro Instanz, die Sie in einem belasteten System haben möchten. Wenn Sie z. B. concurrency als 100 und target concurrency als 70 angeben, versucht Code Engine, die Anzahl der Anfragen pro Instanz auf 70 zu begrenzen.Die Angabe dieser Option stellt nicht sicher, dass die Anfragen pro Instanz nicht höher als 70 werden, da dies bei einer Zunahme des Datenverkehrs sehr wahrscheinlich der Fall ist. Der Puffer zwischen 70 und 100 ermöglicht es dem System jedoch, neue Instanzen zu erstellen, um die Last pro Instanz wieder auf 70 (oder weniger) pro Instanz zu senken. Wird target concurrency nicht angegeben, gilt als Standardwert der Wert von concurrency. Wenn Sie eine Anwendung mit Code Engine von der Konsole aus erstellen oder aktualisieren, legen Sie den Zielwert für die Gleichzeitigkeit im Abschnitt Autoskalierung auf der Registerkarte Ressourcen und Skalierung fest. Mit der CLI geben Sie die Option --concurrency-target in den Feldern app create und app update befehle an.
Anforderungszeitlimit-Die Zeit in Sekunden, die die Anwendung auf Anforderungen antworten muss, andernfalls schlagen sie fehl. Wenn Sie eine Anwendung mit Code Engine über die Konsole erstellen oder aktualisieren, legen Sie das Anforderungszeitlimit im Abschnitt 'Autoscaling' der Registerkarte Resources & scaling fest. Mit der CLI geben Sie die Option --request-timeout in den Feldern app create und app update befehle an.
Scale-down-Verzögerung - Die Zeitspanne in Sekunden, die bei reduzierter Gleichzeitigkeit vergehen muss, bevor die Anwendung heruntergefahren wird. Wenn Sie das Muster eingehender Anforderungen für Ihre Anwendung kennen, können Sie einen Wert angeben, der größer als der Standardwert 0 ist, um das Scale-down Ihrer Anwendung zu verzögern. Wenn Sie einen hohen Wert für diese Option verwenden, kann sich die durchschnittliche Anzahl gleichzeitig aktiver Anwendungsinstanzen erhöhen, was zusätzliche Kosten verursacht. Selbst bei einer Scale-down-Verzögerungseinstellung von 0 wartet das System eine kurze Zeit, bevor die Anwendung die Anzahl der Instanzen nach unten skaliert, um sicherzustellen, dass ein Drop-in-Request-Concurrency stabil genug ist, um ein Scale-down zu rechtfertigen. Wenn Sie eine Anwendung mit Code Engine über die Konsole erstellen oder aktualisieren, legen Sie den Wert für die Scale-down-Verzögerung im Abschnitt 'Autoscaling' der Registerkarte Resources & scaling fest. Mit der CLI geben Sie die Option --scale-down-delay in den Feldern app create und app update befehle an.

Wenn beispielsweise der Wert für die maximale Anzahl von Instanzen auf 10 und der Wert für den gemeinsamen Zugriff auf 100 gesetzt ist, kann eine Anwendung 1000 gleichzeitige Anforderungen verarbeiten, bevor eine potenzielle Warteschlangensteuerung von Anforderungen auftreten kann. Wenn Sie mehr als 1000 Anforderungen gleichzeitig erwarten, sollten Sie in Erwägung ziehen, den Wert für die maximale Anzahl von Instanzen für Ihre App zu erhöhen.

Weitere Informationen über die Funktionsweise von Code Engine finden Sie unter Tuning IBM Cloud Code Engine Scale-Down Delay to Reduce Application Response Times.

Wenn Sie die Mindestanzahl von Instanzen auf die maximale Anzahl von Instanzen setzen, findet keine Skalierung statt und die Zielwährungs-und Scale-down-Verzögerungswerte werden nicht angewendet. Der Wert für den gemeinsamen Zugriff ist jedoch weiterhin wirksam.

Beispielszenario für automatische Skalierung

Angenommen, Sie haben eine Anwendung, die mit den folgenden Einstellungen für automatische Skalierung konfiguriert ist.

Minimale Anzahl von Instanzen = 4
Maximale Anzahl von Instanzen = 20
Gemeinsamer Zugriff = 2

Mit diesen Einstellungen kann Ihre Anwendung 2 gleichzeitige Anforderungen gleichzeitig verarbeiten. Wenn kein Datenverkehr vorhanden ist, wird Ihre Anwendung automatisch auf 4 Instanzen skaliert. Die 4 Instanzen können nur 4 * 2 (Währung) = 8 Anforderungen verarbeiten. Die Anwendung kann auf maximal 20 Instanzen skaliert werden, sodass die 20 Instanzen 20 * 2 (Währung) = 40 Anforderungen verarbeiten können, vorausgesetzt, dass die CPU-und Speichereinstellungen für die Anwendung ausreichen.

Angenommen, Ihre Anwendung ist eine statische Webanwendung, die sechs Aufrufe an Ihre Anwendung zum Laden einer Anmeldeseite erfordert. Angenommen, 10 Personen melden sich gleichzeitig auf der Anmeldeseite Ihrer Anwendung an (10 * 6 = 60 Aufrufe). Da 60 Aufrufe größer als 40 Anforderungen sind, die von Ihrer App verarbeitet werden können, beobachten Benutzer der Anwendung wahrscheinlich eine Langsamkeit, wenn die Aufrufe in die Warteschlange gestellt werden.

Nach einer Minute ohne Datenverkehr für Ihre App beginnt Code Engine mit dem automatischen Scale-down. Wenn für Ihre Anwendung ein Scale-down durchgeführt wird, haben einige Instanzen den Status Terminating. Code Engine sendet ein SIGTERM-Signal an Ihre Anwendung. Ihr Code muss dieses Signal verarbeiten und herunterfahren. Wenn Ihre Anwendung dieses Signal nicht verarbeitet, bleiben Ihre App-Instanzen für die durch das Anforderungszeitlimit konfigurierte Zeit im Status Terminating (Standardwert ist 300 Sekunden). Nach Ablauf des Anforderungszeitlimits sendet Code Engine ein Signal SIGKILL, um das Stoppen der App-Instanzen im Status Terminating zu erzwingen.

Wenn Sie über 8 aktive Instanzen verfügen und 12 Instanzen 300 Sekunden (5 Minuten) im Status Terminating verbleiben. Diese 12 Instanzen empfangen keine Anforderungen. Wenn mehr als 8 * 2 (Währung) = 16 Anforderungen eingehen, skaliert Code Engine neue Instanzen.

In diesem Beispiel ist der Wert 2 für den gemeinsamen Zugriff für diesen statischen Inhalt niedrig. Sie müssen die Werte für die automatische Skalierung festlegen, die für Ihre App festgelegt werden sollen. Dies hängt davon ab, was die Implementierung Ihrer App mit den zugeordneten CPU-und Speicherressourcen verarbeiten kann.

Latenz und Durchsatz optimieren

Um die Latenz und den Durchsatz Ihrer Anwendung zu optimieren, sollten Sie sich mit den Vor- und Nachteilen einiger gängiger Modelle und Best Practices für die Konfiguration des gemeinsamen Zugriffs auf Container vertraut machen.

Verwenden Sie die Einstellung für die Gleichzeitigkeit, um die maximale Anzahl von Anfragen anzugeben, die pro Instanz gleichzeitig verarbeitet werden können, wenn Sie eine Anwendung erstellen oder aktualisieren. Legen Sie in der Code Engine-Konsole den Wert für den gemeinsamen Zugriff im Abschnitt "Laufzeit" fest. Verwenden Sie in der Befehlszeilenschnittstelle die Option --concurrency (Alias --cn) mit dem Befehl app create oder app update.

Beispiele für gemeinsamen Zugriff in Code Engine Anwendungen
Modell	Vorteile	Nachteile
Ohne Nebenläufigkeit, `--cn=1`	Wählen Sie die Konfiguration mit einem gemeinsamen Zugriff aus, wenn die Anwendung eine speicherintensive oder CPU-intensive Workload bereitstellt, da nur eine Anforderung gleichzeitig in die Anwendungsinstanz eintritt und daher die vollständige Menge an CPU und Speicher, die für die Instanz konfiguriert ist, abgerufen wird.	Für Anwendungen, die das Modell für den einzelnen gleichzeitigen Zugriff verwenden, kann ein Scale-out rasch durchgeführt werden. Das Scale-out kann zusätzliche Latenz und einen geringeren Durchsatz mit sich bringen, weil durch die Erstellung einer neuen Anwendungsinstanz höhere Kosten als bei der Wiederverwendung einer vorhandenen Instanz entstehen. Wählen Sie dieses Modell nicht, wenn Anforderungen gleichzeitig verarbeitet werden können und die Latenz für die Anwendung kritisch ist.
Hoher gemeinsamer Zugriff, `--cn=100` (Standardwert) oder höher	Wählen Sie diese Konfiguration aus, wenn Ihre Anwendung viele Workloads für HTTP-Anforderungen oder -Antworten bedient, die nicht CPU- oder speicherintensiv sind und auf Ressourcen warten können. Sie könnten diese Gleichzeitigkeitskonfiguration für ein API-Backend wählen, das Daten bei Erstellungs-, Abruf-, Aktualisierungs- und Löschvorgängen in einer Remote-Datenbank liest und schreibt. Während einige Anforderungen auf die Ein-/Ausgabe warten, können andere Anforderungen verarbeitet werden, ohne dass die Latenz und der Durchsatz insgesamt beeinträchtigt werden.	Diese Einstellung ist nicht optimal, wenn gleichzeitige Anforderungen um CPU, Hauptspeicher und Ein-/Ausgabe konkurrieren, da der Wettstreit um Ressourcen die Ausführung verzögern und die Latenz sowie den Durchsatz beeinträchtigen kann.
Optimaler gemeinsamer Zugriff, `--cn=N`	Wählen Sie die Konfiguration für den optimalen gemeinsamen Zugriff aus, wenn Sie wissen, wie viele Ressourcen dafür benötigt werden, dass eine einzelne Anforderung die für Ihre Anwendung gewünschte Antwortzeit erfüllen kann. Sie könnten diese Konfiguration wählen, wenn es sich bei Ihrer Anwendung um eine Anwendung zur Übersetzung natürlicher Sprache handelt, bei der das maschinelle Lernmodell für die Sprachumwandlung `32` GB groß ist und eine einzelne Übersetzungsberechnung etwa `0.7` vCPU pro Anfrage benötigt. Pro Instanz können Sie eine Konfiguration mit `9` vCPUs und `32` GB Hauptspeicher auswählen. Der optimale gemeinsame Zugriff für Container beträgt ungefähr `13` (`9 vCPU/0.7 vCPU`).	Wählen Sie die Konfiguration für den optimalen gemeinsamen Zugriff nicht, wenn Sie den Ressourcenbedarf Ihrer Anwendung nicht kennen. Das Festlegen eines falschen gemeinsamen Zugriffs für Container kann eine entweder zu agressive oder zu schwache Skalierung bewirken, was die Latenz, die Fehlerrate und die Kosten Ihrer Anwendung beeinträchtigen kann. Weitere Informationen enthält der Abschnitt Gemeinsamen Zugriff für den Anwendungscontainer bestimmen.
Unendlicher gemeinsamer Zugriff, `--cn=0` (inaktiviert)	Inaktiviert	Die Konfiguration für den unendlichen gemeinsamen Zugriff wird in Code Engine nicht unterstützt. Bei der Konfiguration für den unendlichen gemeinsamen Zugriff werden so viele Anforderungen wie möglich an eine einzige Anwendungsinstanz weitergeleitet, was die Skalierung weiterer Anwendungsinstanzen verzögern kann.

Gemeinsamen Zugriff für den Anwendungscontainer bestimmen

Der optimale Wert für den gemeinsamen Container-Zugriff wird durch die maximale Anzahl gleichzeitig ablaufender Anforderungen bestimmt, die die Anwendung mit einer Latenzzeit für zulässige Anforderungen verarbeiten kann.

Der gemeinsame Container-Zugriff hat eine direkte Auswirkung auf die Erfolgsquote, die Latenz und den Durchsatz der Anwendung. Wenn der Gleichzeitigkeitswert des Containers für die Anwendung zu hoch ist, werden Latenz und Durchsatz negativ beeinflusst, und es können Fehlerreaktionen auf 502 und 503 auftreten.

Wenn der Wert des gemeinsamen Zugriffs für den Container zu niedrig für die Anwendung ist, führt das System schneller ein Scale-out der Anwendung durch und verteilt die Anforderung auf viele Anwendungsinstanzen, was zusätzliche Kosten und eine höhere Latenz verursacht. Während eines Bursts von Ladevorgängen kann ein geringer Wert für den gemeinsamen Zugriff auch zu vorübergehenden Antworten des Typs 502 führen, wenn die internen Puffer des Systems überlaufen.

Um für Ihre Anwendung die Konfiguration des gemeinsamen Zugriffs für den Container zu ermitteln, untersuchen Sie Anforderungen und Latenz.

Erstellen Sie eine Anwendung und legen Sie den gemeinsamen Zugriff auf 1000 (max.) und sowohl min-scale als auch max-scale auf 1 fest.
```
ibmcloud ce application create --name APPNAME --image APPIMAGE --min-scale=1 --max-scale=1 --concurrency=1000
```
Senden Sie zunächst eine hohe Rate von Anforderungen. Wenn 502-Fehler auftreten, verringern Sie die Rate, bis das Ergebnis eine Erfolgsquote von 100% aufweist.
Suchen Sie die Anforderungslatenz der Ausgabe von Schritt 2. Wenn die Anforderungslatenz nicht akzeptabel ist, verringern Sie die Anforderungsrate weiter, bis die Anforderungslatenz akzeptabel erscheint. Hierbei ist zu beachten, dass auch die Anforderungsdauer von Bedeutung ist, weil es eine Rolle spielt, ob die Berechnung der Anforderung 2 Sekunden oder 100 Millisekunden dauert.

Die annehmbare Anforderungsrate und Latenz variiert abhängig von den Merkmalen Ihrer Anwendung sowie Ihrer Skalierungskonfiguration. Falls beispielsweise die Berechnung in Ihrer Anwendung ca. 100 Millisekunden dauert und Sie für den gemeinsamen Zugriff die Einstellung 10 verwenden, kann eine einzige Anwendungsinstanz ungefähr 100 Anforderungen pro Sekunde mit einer Latenz von 100 Millisekunden verarbeiten (ohne Berücksichtigung der Netzlatenz).
Um für Ihre Anwendung den Wert des gemeinsamen Zugriffs für den Container zu berechnen, teilen Sie die Rate aus Schritt 2 (angegeben in req/s, also Anforderungen pro Sekunde) durch die Latenz aus Schritt 3 (angegeben in Sekunden): CC = RATE/LATENCY. Beispiel: Beträgt die Rate 80 Anforderungen pro Sekunde und die Latenz 2 Sekunden, ergibt sich für den gemeinsamen Zugriff 80 req/s / 2 s = 40.
Aktualisieren Sie die Anwendung und legen Sie als gemeinsamen Zugriff für den Container den im vorherigen Schritt ermittelten Wert fest. Führen Sie anschließend die Workload erneut aus, um zu prüfen, ob die Erfolgsquote und die Latenz annehmbar sind.
Experimentieren Sie mit der Anwendung, indem Sie den Wert des gemeinsamen Zugriffs für den Container erhöhen und dann Erfolgsquote sowie Latenz beobachten.
Aktualisieren Sie Ihre Anwendung mit dem optimalen Containerwert für den gemeinsamen Zugriff und entfernen Sie die min-Scale- und max-scale-Grenzwerte, damit die Anwendung automatisch skaliert werden kann.

Sehen, wie Ihre App mit der CLI skaliert wird

Sie können die Anzahl der aktiven Instanzen Ihrer App über die Befehlszeilenschnittstelle beobachten.

Erstellen Sie eine Anwendung mit dem Befehl app create.

ibmcloud ce application create --name myapp --image icr.io/codeengine/helloworld

Rufen Sie die Anwendung auf. Sie können die URL Ihrer App aus der Ausgabe des Befehls app create abrufen oder den Befehl ibmcloud ce app get --name myapp --output url ausführen.
```
curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
```

Führen Sie den Befehl application get aus, um den Status der Anwendung anzuzeigen. Suchen Sie nach dem Wert für die aktiven Instanzen (Running instances). Im folgenden Beispiel verfügt die App über 1 aktive Instanz. Beispiel:

ibmcloud ce application get --name myapp

Beispielausgabe

[...]
OK

Name:          myapp
[...]

URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration

Status Summary:  Application deployed successfully

Environment Variables:    
    Type     Name             Value  
    Literal  CE_API_BASE_URL  https://api.private.us-south.codeengine.cloud.ibm.com
    Literal  CE_APP           myapp  
    Literal  CE_DOMAIN        us-south.codeengine.appdomain.cloud  
    Literal  CE_PROJECT_ID    abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
    Literal  CE_REGION        us-south  
    Literal  CE_SUBDOMAIN     abcdabcdab
Image:                icr.io/codeengine/helloworld
Resource Allocation:
    CPU:                1
    Ephemeral Storage:  400M
    Memory:             4G

Revisions:
myapp-ds8fn-1:
    Age:                6m25s
    Traffic:            100%
    Image:              icr.io/codeengine/helloworld (pinned to fe0446)
    Running Instances:  1

Runtime:
    Concurrency:    100
    Maximum Scale:  10
    Minimum Scale:  0
    Timeout:        300

Conditions:
    Type                 OK    Age    Reason
    ConfigurationsReady  true  6m10s
    Ready                true  5m56s
    RoutesReady          true  5m56s

Events:
    Type    Reason   Age    Source              Messages
    Normal  Created  6m28s  service-controller  Created Configuration "myapp"
    Normal  Created  6m28s  service-controller  Created Route "myapp"

Instances:
    Name                                       Revision       Running  Status   Restarts  Age
    myapp-ds8fn-1-deployment-79bdd76749-khtmw  myapp-ds8fn-1  2/2      Running  0         32s

Warten Sie einige Minuten, da es mehrere Minuten dauern kann, bis für die App der Scale-down auf null durchgeführt wurde.

Führen Sie den Befehl application get erneut aus und beachten Sie, dass der Wert für Running instances auf null skaliert wurde. Wenn die Anwendung weniger Anforderungen verarbeitet als der konfigurierte gemeinsame Zielzugriff, skaliert die Anwendung die Anzahl der aktiven Instanzen auf die konfigurierte Mindestanzahl von Instanzen. In diesem Szenario wird die Anzahl aktiver Instanzen automatisch auf null skaliert. Wenn die Option --min-scale auf 0 (Standardwert) gesetzt ist, wird die Anzahl aktiver Instanzen automatisch auf null skaliert.

Warten Sie einige Minuten, da es mehrere Minuten dauern kann, bis für die App der Scale-down auf null durchgeführt wurde.

ibmcloud ce application get -n myapp

Beispielausgabe

OK

Name:          myapp
[...]

URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration

Image:                icr.io/codeengine/helloworld
Resource Allocation:
    CPU:                1
    Ephemeral Storage:  400M
    Memory:             4G

Revisions:
myapp-ds8fn-1:
    Age:                12m
    Traffic:            100%
    Image:              icr.io/codeengine/helloworld (pinned to 548d5c)
    Running Instances:  0

Runtime:
    Concurrency:         100
    Maximum Scale:       10
    Minimum Scale:       0
    Timeout:             300

Conditions:
    Type                 OK    Age    Reason
    ConfigurationsReady  true  3m7s
    Ready                true  2m54s
    RoutesReady          true  2m54s

Events:
    Type    Reason   Age    Source              Messages
    Normal  Created  3m21s  service-controller  Created Configuration "myapp"
    Normal  Created  3m20s  service-controller  Created Route "myapp"

Rufen Sie die Anwendung erneut auf, um von Null zu skalieren.

curl https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud

Führen Sie den Befehl application get erneut aus und beachten Sie, dass für den Wert für Running instances ein Scale-up von null durchgeführt wurde. Beispiel:

ibmcloud ce application get -n myapp

Beispielausgabe

OK

Name:          myapp
[...]

URL:           https://myapp.4svg40kna19.us-south.codeengine.appdomain.cloud
Cluster Local URL:  http://myapp.4svg40kna19.svc.cluster.local
Console URL:   https://cloud.ibm.com/codeengine/project/us-south/01234567-abcd-abcd-abcd-abcdabcd1111/application/myapp/configuration

Status Summary:     Application deployed successfully  

Environment Variables:    
    Type     Name             Value  
    Literal  CE_API_BASE_URL  https://api.private.us-south.codeengine.cloud.ibm.com
    Literal  CE_APP           myapp  
    Literal  CE_DOMAIN        us-south.codeengine.appdomain.cloud  
    Literal  CE_PROJECT_ID    abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
    Literal  CE_REGION        us-south  
    Literal  CE_SUBDOMAIN     abcdabcdab  
Image:                  icr.io/codeengine/helloworld  
Resource Allocation:      
CPU:                1  
Ephemeral Storage:  400M  
Memory:             4G  

Revisions:     
myapp-00001:    
    Age:                42s  
    Latest:             true  
    Traffic:            100%  
    Image:              icr.io/codeengine/helloworld (pinned to 1cee99)  
    Running Instances:  1  

Runtime:       
Concurrency:       100  
Maximum Scale:     10  
Minimum Scale:     0  
Scale Down Delay:  0  
Timeout:           300  

Conditions:    
Type                 OK    Age  Reason  
ConfigurationsReady  true  25s    
Ready                true  12s    
RoutesReady          true  12s    

Events:        
Type    Reason   Age  Source              Messages  
Normal  Created  44s  service-controller  Created Configuration "myapp"  
Normal  Created  43s  service-controller  Created Route "myapp"  

Instances:     
Name                                    Revision     Running  Status   Restarts  Age  
myapp-00001-deployment-d59b87654-xkqh7  myapp-00001  3/3      Running  0         43s

Anzahl der minimalen und maximalen Instanzen für Ihre App festlegen

Sie können die Anzahl der aktiven Instanzen Ihrer App ändern, indem Sie den Mindest-und Maximalwert für die Anzahl der App-Instanzen aktualisieren.

Der Standardwert für die Mindestanzahl von Instanzen für Ihre Anwendung ist 0. Wenn Ihre App keinen Datenverkehr empfängt, wird sie auf 0 skaliert und es werden keine Instanzen Ihrer App ausgeführt. In dieser Situation kann Ihre Anwendung langsamer reagieren, wenn sie erneut Datenverkehr empfängt, während sie ein Scale-up durchführen kann. Sie können dieses Verhalten ändern, indem Sie Ihre Anwendung aktualisieren und die Mindestgröße entweder in der Konsole oder über die Befehlszeilenschnittstelle auf 1 setzen.

Der Standardwert für die maximale Anzahl von Instanzen für Ihre App ist 0, wodurch Ihre App nach Bedarf skaliert werden kann. Weitere Informationen finden Sie unter Grenzen skalieren.

Bereich für automatische Skalierung über die Konsole ändern

Führen Sie die folgenden Schritte aus, um den Bereich zu ändern, in dem Code Engine die Anzahl der aktiven Instanzen für eine App über die Konsole automatisch skaliert.

Navigieren Sie zu Ihrer App.
Wählen Sie die Registerkarte Konfiguration.
Wählen Sie die Registerkarte Ressourcen und Skalierung.
Legen Sie die Anzahl der minimalen und maximalen Instanzen für Ihre App fest.
(Optional) Überprüfen und definieren Sie die Einstellungen für gemeinsamen Zugriff auf Anforderungen und Timing für die automatische Skalierung Ihrer App.
Klicken Sie auf Bereitstellen, um Ihre Änderungen zu speichern und die App-Revision bereitzustellen.

Wenn Sie Ihre Anwendung aktualisieren, erstellt Ihre App eine neue Revision und leitet Datenverkehr an diese Instanz weiter.

Bereich für automatische Skalierung über die Befehlszeilenschnittstelle ändern

Zum Ändern des Bereichs, in dem Code Engine die Anzahl der aktiven Instanzen für eine App über die Befehlszeilenschnittstelle automatisch skaliert, führen Sie den Befehl application update mit den Optionen --min-scale und --max-scale auf die Anzahl der Instanzen aus, die Sie für Ihre App verwenden möchten. Sie können optional Einstellungen für gemeinsamen Zugriff auf Anforderungen und Ablaufsteuerung für Ihre App definieren. Zu diesen Optionen gehören --concurrency, --concurrency-target, --request-timeout und --scale-down-delay. Weitere Informationen zum Festlegen dieser Werte für die automatische Skalierung finden Sie unter Skalierungsgrenzen und Einstellungen für automatische Skalierung für gemeinsamen Zugriff und Timing.

Wenn Sie Ihre Anwendung aktualisieren, erstellt Ihre App eine neue Revision und leitet Datenverkehr an diese Instanz weiter.