Code Engine-Planung

IBM Cloud® Code Engine unterstützt folgende grundlegende Arten von Workloads: Anwendungen, Jobs, Funktionen und Flotten.

Eine Anwendung oder App führt den Code für die Verarbeitung von HTTP-Anforderungen aus. Zusätzlich zu den traditionellen HTTP-Anforderungen unterstützt IBM Cloud® Code Engine auch Anwendungen, die WebSockets als Kommunikationsprotokoll verwenden. Die Anzahl der laufenden Instanzen einer App wird je nach eingehenden Anfragen und Ihren Konfigurationseinstellungen automatisch nach oben oder unten (bis auf null) skaliert. Eine App enthält eine oder mehrere Revisionen. Eine Revision stellt eine unveränderliche Version der Konfigurationseigenschaften der App dar. Bei jeder Aktualisierung einer Konfigurationseigenschaft der App wird eine neue Revision der App erstellt.

Ein Job führt eine oder mehrere Instanzen Ihres ausführbaren Codes parallel aus. Im Gegensatz zu Anwendungen, die HTTP-Anforderungen verarbeiten, sind Jobs so konzipiert, dass sie einmal ausgeführt werden und den Vorgang beenden. Wenn Sie einen Job erstellen, können Sie Informationen für die Workloadkonfiguration angeben, die bei jeder Ausführung des Jobs verwendet werden.

Eine Funktion ist ein zustandsloser Codeschnipsel, der Aufgaben ausführt, wenn er von HTTP aufgerufen wird. Mit IBM Code Engine können Sie Ihre Geschäftslogik skalierbar und serverlos ausführen. Die Funktionen IBM Code Engine bieten eine optimierte Laufzeitumgebung zur Unterstützung niedriger Latenzzeiten und schneller Skalierungsszenarien. Ihr Funktionscode kann in einer verwalteten Laufzeitumgebung geschrieben werden, die bestimmte Node.js oder Python enthält.

Eine Flotte, auch serverlose Flotte genannt, führt eine oder mehrere Instanzen von Benutzercode aus, um eine Reihe festgelegter Aufgaben zu erledigen. Flotten können große, rechenintensive Workloads verarbeiten, ermöglichen die Steuerung von Maschinenprofilen und können auf GPU-Ressourcen laufen. Flotten haben einen einzigen Mieter, implementieren eine dynamische Aufgabenwarteschlange und bieten volle Kontrolle über die Konfiguration der Maschinenprofile. Darüber hinaus können Flotten eine Verbindung zu Virtual Private Clouds (VPCs) herstellen, um sicher auf Benutzerdaten und -dienste zuzugreifen.

Vergleich von „ Code Engine “-Anwendungen, Aufgaben, Funktionen und Flotten
Merkmal	Anwendung	Job	Funktion	Flotte
Ausführungszeit (Dauer)	Mit langer Laufzeit (10 Minuten pro Anforderung)	Mit langer Laufzeit (bis zu 24 Stunden)	Kurze Laufzeit (maximal 2 Minuten)	Langfristig (Minuten bis Wochen)
Startlatenz	Mittel	Geplanter Start	Niedrig	Niedrig
Beendigung	Kontinuierlich ausführen	Ausführung bis Abschluss	Ausführung bis Abschluss	Ausführung bis Abschluss
Aufruftask	Auf Anforderung oder permanent aktiv	Geplant	Auf Anfrage, sofort	Geplant
Programmiermodell	Containerbasierter Build und containerbasierte Ausführung	Containerbasierter Build und containerbasierte Ausführung	Sprachspezifische Quellcodedateien und Abhängigkeitsmetadaten	Containerbasierter Build und containerbasierte Ausführung
Parallelität	Parallele Ausführung, flexibel	Niedrige bis mittlere parallele Ausführung	Hohe parallele Ausführung	Hochparallele Ausführung und Warteschlangen
Scale-out	Basierend auf der Anzahl der Anforderungen	Auf der Basis der Jobworkloaddefinition	Auf der Basis von Ereignissen oder direkten Aufrufen	Basierend auf der Anzahl der Aufgaben und gleichzeitigen Instanzen
Isolation	Multi-Tenant	Multi-Tenant	Multi-Tenant	Single-Tenant
GPU-Unterstützung	Nein	Nein	Nein	Ja
Kontrolle über die Maschinenkonfiguration	Keine Steuerung	Keine Steuerung	Keine Steuerung	full control
VPC-Konnektivität	Über Private Path	Über Private Path	Über Private Path	Nativ (über Subnetz-Pool)
Optimiert für	Scale-out mit langer Laufzeit, hoch komplexe Workloads und bedarfsgerechte Skalierung	Geplante oder geplante Workloads mit hohem Ressourcenbedarf	Startzeit und schnelles Scale-out	Groß angelegte, rechenintensive Workloads

Code Engine Anwendungsfälle

Während die Anwendungsfälle für Code Engine sehr unterschiedlich sind, finden Sie hier einige Beispiele für den Einstieg.

Erfahrungen mit Containern, aber keine Kenntnisse oder kein Budget zur Verwaltung von Clustern: Sie sind ein Entwickler, der mit Containern vertraut ist. Sie möchten jedoch nicht die Komplexität oder den Zeitaufwand, den die Verwaltung eines Clusters in Anspruch nimmt. Bei Verwendung von Code Engine müssen Sie sich keine Gedanken um die Kenntnisse oder den Zeitaufwand für die Clusterverwaltung machen. Die komplexe Verarbeitung wird von Code Engine übernommen und die Infrastruktur wird von einem IBM Team als Bestandteil des IBM Cloud-Service verwaltet.
Workloads mit sporadisch auftretenden Lastspitzen: Ihre Website ist an den Wochenenden sehr ausgelastet, unter der Woche aber kaum. Da auf dieser Website solche Lastspitzen auftreten, auf die anschließend Zeiträume mit sehr wenig Aktivität folgen, ist Code Engine eine gute Lösung. Von Code Engine wird für die Anwendung der Website bei einer Zunahme des Datenverkehrs für die Anwendungsinstanzen automatisch ein Scale-up und anschließend wieder ein Scale-down für die Zeiträume mit nur sehr wenig Aktivität (sogar auf null) durchgeführt.
In Speicher integrierte Stapelworkloads: Ihr Batch-Job verarbeitet die Gehälter der Mitarbeiter am Ende eines jeden Monats. Da dieser Job monatlich ausgeführt wird, ist er die meiste Zeit inaktiv, beansprucht jedoch bei der Ausführung viel CPU-Leistung und Arbeitsspeicher. Der Batch-Job muss in den Speicher integriert werden, um die Ergebnisse zu speichern. Durch die Verwendung von Code Engine können Sie den Stapeljob in IBM Cloud Object Storage integrieren und Ihnen werden nur die Ressourcen in Rechnung gestellt, die der Job während seiner Ausführung verwendet. Wenn der Job inaktiv ist, werden keine Ressourcen verbraucht und somit keine Gebühren berechnet. Bei Verwendung der IBM Cloud Object Storage-Instanz würden für den Job jedoch Kosten entstehen.
Workload integrieren: Ein Teil Ihres Jobs besteht darin, Images zu erstellen und zu implementieren. Sie haben zwar Erfahrung mit der Erstellung von Container-Images und deren Bereitstellung, möchte diesen Prozess aber vereinfachen, um sich auf andere Aufgaben konzentrieren zu können. Mit Code Engine können Sie direkt in derselben Schnittstelle Images erstellen und bereitstellen; somit werden Ihre täglichen Aufgaben einfacher und Sie haben mehr Zeit für die Entwicklung von Code.
Tests, Konzeptnachweise oder unverbindliches Ausprobieren: Sie möchten mehr über die containerbasierte Architektur erfahren. Ihr Team hat eine Anwendung entwickelt, möchte diese aber testen, bevor sie den Stakeholdern präsentiert wird. Da diese Anwendung klein ist, möchten Sie nicht die Gebühr für einen kleinen dedizierten Cluster bezahlen. In diesem Fall können Sie die Anwendung testen und den Stakeholdern einen Konzeptnachweis des Designs zur Verfügung stellen, ohne die Kosten, die ein dedizierter Cluster erfordern würde.

Verwendung einer App, eines Jobs oder einer Funktion

Anwendungen und Jobs sind sich sehr ähnlich, schließlich führen beide einfach Code aus. Es gibt jedoch einige wichtige Aspekte zu beachten, wenn Sie sich entscheiden, Ihren Code als App oder Job zu strukturieren.

Muss Ihr Code auf ein Ereignis reagieren?: Im Kontext von Code Engine gilt jede eingehende HTTP-Anforderung (auch die Anforderung zum Laden einer Webseite) oder ein REST-API-Aufruf als Ereignis. Das Konzept der ereignisgesteuerten Ausführung ist häufig der Schlüsselfaktor, wenn Sie zwischen einer App oder einem Job wählen, da Apps per Definition aufgrund einer HTTP-Anforderung ausgeführt werden, während Jobs als Ergebnis eines Aufrufs ausgeführt werden.; Wenn Ihnen bekannt ist, dass die Workload auf eingehende HTTP-Anforderungen reagiert, ist eine App die geeignete Option. Wenn die Workload jedoch nur die Ausführung des Codes bis zu deren Abschluss umfasst, ist ein Job besser geeignet.
Wie skaliert Ihr Code?: Sowohl Apps als auch Jobs sind skalierbar. Apps werden als Reaktion auf messbare Echtzeitkriterien skaliert, wie z. B. die Anzahl aktiver eingehender Anforderungen, da jede Instanz der App möglicherweise nur eine bestimmte Anzahl von Anforderungen gleichzeitig verarbeiten kann. Jobs werden auf der Basis der Anzahl der Instanzen skaliert, die bei der Erstellung des Jobs angegeben werden.; Wenn Sie wissen, dass eine bestimmte Anzahl von Instanzen Ihres Codes ausgeführt werden soll und dass jede Instanz ohne eingehende HTTP-Anforderung ausgeführt werden kann, ist ein Job die geeignete Option. Muss jedoch die Anzahl der Instanzen dynamisch auf der Basis der eingehenden HTTP-Workload skaliert werden, sind Apps besser geeignet.

Gängige Szenarios für Code Engine

Lesen Sie einige dieser allgemeinen Szenarios, um zu verstehen, wann Sie einen bestimmten Workloadtyp auswählen müssen.

Ist für die Workload eine geringe Latenz erforderlich oder handelt es sich um eine interaktive Workload?: Wenn es für Ihre Workload erforderlich ist, dass ein Client oder Benutzer synchron auf die Antwort auf die Anfrage wartet, und die Antwort innerhalb von Millisekunden verfügbar sein muss, verwenden Sie eine Anwendung. Anwendungen stellen einen extern erreichbaren Endpunkt bereit und antworten synchron auf die Anforderung. Beispiele für solche Workloads sind Websites, Chatbots und mobile Anwendungen. Verwenden Sie Anwendungen.
Handelt es sich um eine einfache Workload, die geringe CPU- und Hauptspeicherkapazität und wenige Ein-/Ausgabeoperationen erfordert?: Wenn Ihre Workload kompakt ist und geringe Anforderungen an CPU, Speicher und Ein-/Ausgabe stellt, kann die bei Anwendungen verfügbare Option für den gemeinsamen Zugriff hilfreich sein. Ein typisches Beispiel ist ein API-Server, der Basisoperationen bereitstellt und mit einer NoSQL-Datenbank arbeitet. Diese Anforderungstypen umfassen normalerweise geringe Datenmengen und erfordern eine geringe Hauptspeicherkapazität bzw. eine geringere Anzahl von CPU-Zyklen. Bei einem höheren gemeinsamen Zugriff kann die Anwendung die Daten einer ersten Anforderung verarbeiten, während die zweite Anforderung auf Ein-/Ausgabe wartet. Da die CPU- und Speicheranforderungen gering sind, können viele Anforderungen gleichzeitig ausgeführt werden. Verwenden Sie Anwendungen.
Ist die Verarbeitung an CPU, Hauptspeicher oder E/A gebunden?: Wenn eine bestimmte Datenmenge verarbeitet werden soll, deren einzelne Datenblöcke groß sind und eine erhebliche Menge an CPU- und Hautpspeicherkapazität erfordern, sind Jobs in der Regel besser geeignet. Wenn für die Workload jedoch ein Anforderungs-/Antwortmuster erforderlich ist, können auch Apps verwendet werden. In beiden Fällen wird die Verarbeitungstask ohne Nebenläufigkeit ausgeführt. Jede Anwendungsinstanz oder Job-Task verarbeitet nur eine Anforderung oder einen Datenblock gleichzeitig, um die für die Instanz konfigurierten Ressourcen vollständig zu nutzen. Die Parallelität wird durch die Anzahl der Instanzen oder Tasks erreicht. Dabei ist der Aufwand für die Erstellung einer zusätzlichen Task aufgrund der erheblichen Ressourceneinschränkungen zu vernachlässigen. Ein typisches Beispiel ist die Verarbeitung von Imagedaten in einem Object Storage-Bucket oder die Ausführung von Machine Learning-Modellen. Verwenden Sie Anwendungen oder Jobs.
Nimmt die Verarbeitung viel Zeit in Anspruch?: Wenn die Verarbeitung viel Zeit in Anspruch nimmt, sind Jobs besser geeignet, da sie asynchron ausgeführt werden. Die maximale Dauer von Anwendungsausführungen ist stets begrenzt, da die Bereitstellung skalierbarer geöffneter Verbindungen kostenintensiv ist. Typische Workloads hierfür sind das Trainieren von Machine Learning-Modellen oder die Optimierung von Hyperparametern. Verwenden Sie Jobs.
Kann das Aufkommen gleichzeitiger Verarbeitungsprozesse vorab bestimmt werden?: Wenn Sie das anfallende Verarbeitungsvolumen vorab kennen, können Sie einen Job mit der genauen Anzahl von Instanzen ausführen, bis er abgeschlossen ist. Typische Beispiele hierfür sind die Optimierung von Hyperparametern und das Trainieren eines neuronalen Netzes. Verwenden Sie Jobs.
Reagiert die Workload auf ein Ereignis?: Wenn die Workload auf eine Ereignis reagieren muss, wie z. B. auf eine Git-Festschreibung, die mit einer Push-Operation an das Repository übertragen wird, ein Objekt, das in ein Object Storage-Bucket hochgeladen wird, oder ein Dokument, das in der Datenbank geändert wird, verwenden Sie Anwendungen. Anwendungen stellen einen Endpunkt bereit, der so konfiguriert werden kann, dass er Ereignisse von der Ereignisquelle empfängt. Verwenden Sie Anwendungen.
Müssen als Reaktion auf Ereignisse oder Anforderungen große Datenmengen in kurzer Zeit verarbeitet werden?: Wenn die Workload eine schnelle Antwort auf nicht vorhergesehene Anforderungen oder Ereignisse erfordert, sind Anwendungen normalerweise besser geeignet, da diese dynamisch skaliert werden und auch ein Scale-up von null möglich ist. Verwenden Sie Anwendungen.
Apps und Jobs kombinieren: Apps und Jobs können auch kombiniert werden. Dabei kann eine Anwendung einen Job starten, um bestimmte Verarbeitungsprozesse auszulagern. Jobs können auch Abfragen an eine Anwendung senden. Ein typisches Beispiel einer Kombination aus Jobs und Apps ist das Trainieren und Ausführen von Machine Learning-Modellen. Jobs werden normalerweise zum Trainieren der Modelle verwendet, Anwendungen zur Ausführung der Modelle. Verwenden Sie Anwendungen und Jobs.