Preisstruktur für Code Engine

IBM Cloud® Code Engine unterscheidet sich von herkömmlichen Cloud-Computing-Technologien insofern, als Sie nur für die Ressourcen bezahlen, die Sie verwenden. Es entstehen Kosten für den Umfang an Speicher und vCPUs, der von Ihren Workloads genutzt wird, sowie für alle eingehenden HTTP-Aufrufe. Wenn Ihre App auf Null skaliert wird oder Ihr Job oder Build nicht aktiv ist, werden keine Ressourcen verbraucht und es entstehen Ihnen keine Kosten.

Code Engine beinhaltet ein kostenloses Nutzungskontingent, sodass Sie Code Engine ausprobieren können, bevor Sie sich definitiv für das Produkt entscheiden.

Es werden die folgenden Entitäten in Rechnung gestellt:

Für Entitäten wie Projekte entstehen keine Kosten. Sie dienen lediglich als Ordner für Ihre Entitäten. Für Entitäten wie geheime Schlüssel, Bindungen oder Abonnements werden keine Gebühren berechnet, diese Entitäten tragen jedoch zu dem Gesamtumfang der Ressourcennutzung Ihres Projekts bei und müssen bei den Grenzwerten berücksichtigt werden. Weitere Informationen finden Sie im Abschnitt Grenzwerte und Kontingente für Code Engine.

Bei den in diesem Abschnitt angegebenen Kosten handelt es sich um Richtwerte, die tatsächlichen Kosten können abweichen. Sie liefern einen Anhaltspunkt für Kostenschätzungen in Bezug auf Umgebungen mit ähnlicher Konfiguration. Die tatsächlichen Kosten können je nach Region variieren. Die aktuellsten Preise finden Sie unter Code Engine Preise.

Preisstruktur für Anwendungen

Wenn Sie eine Anwendung bereitstellen, fallen Gebühren für HTTP-Anforderungen sowie für die CPU- und Speicherressourcen an, die von aktiven Instanzen der Anwendung genutzt werden. Eingehende HTTP-Aufrufe werden entsprechend der Anzahl der HTTP-Aufrufe in Rechnung gestellt, die von Ihrer Anwendung empfangen werden. Wenn von Ihrer App beispielsweise 100 Aufrufe bedient werden, werden Ihnen 100 HTTP-Aufrufe in Rechnung gestellt. Der interne HTTP-Datenverkehr innerhalb eines Projekts zwischen Ihren Workloads wird bei der kostenpflichtigen Gesamtzahl der HTTP-Aufrufe nicht berücksichtigt.

Beispiel:

  • Wenn Sie eine Code Engine-App mit 2 GB (Gigabyte) Speicher und 1 virtuellen CPU mit einem minimalen und maximalen Instanzumfang von 1 erstellen, werden Ihnen nach einer Stunde Gebühren für 1 Stunde vCPU-Nutzung und 2 Stunden mit 1 GB berechnet.
  • Wenn Sie Ihren maximalen Instanzumfang anschließend auf 2 erhöhen und Ihre Anwendung genügend Anforderungen empfängt, um eine Skalierung auf 2 vorzunehmen, ergibt sich folgende Rechnung für Ihre Kosten pro Stunde: (number of instances) x (number of virtual CPUs) = 2 vCPU und 4 GB.

Informationen zu gültigen CPU-und Speicherkombinationen finden Sie unter Unterstützte Speicher-und CPU-Kombinationen.

Dabei ist zu beachten, dass die Zeit, die das Extrahieren des Images und Erstellen des Images aus dem Quellcode beansprucht, in die Berechnung der kostenpflichtigen Zeit einfließt.

Preisstruktur für Jobs

Wenn Sie einen Job ausführen, fallen Gebühren für die CPU- und Speicherressourcen an, die bei der Jobausführung genutzt werden. Für die Jobkonfiguration entstehen Ihnen keine Kosten.

Beispiel:

  • Wenn Sie einen Job zum Verarbeiten von Informationen aus IBM Cloud Object Storage mit einer einzigen Jobinstanz erstellen, der 1 h ausgeführt wird und 4 GB an Speicher verwendet, werden Ihnen 1 Stunde CPU-Nutzung und 4 Stunden mit 1 GB in Rechnung gestellt.
  • Wenn Sie denselben Auftrag auf 4 Instanzen skalieren und er dann in 15 Minuten abgeschlossen ist, werden Ihnen 4 vCPU und 16 GB für .25 Stunden berechnet.

Informationen zu gültigen CPU-und Speicherkombinationen finden Sie unter Unterstützte Speicher-und CPU-Kombinationen.

Dabei ist zu beachten, dass die Zeit, die das Extrahieren des Images und Erstellen des Images aus dem Quellcode beansprucht, in die Berechnung der kostenpflichtigen Zeit einfließt.

Funktionspreisgestaltung

Wenn Sie eine Funktion bereitstellen, fallen Gebühren für HTTP Anfragen und für die CPU- und Speicherressourcen an, die von den laufenden Instanzen der Funktion verbraucht werden. Eingehende HTTP Anrufe werden nach der Anzahl der HTTP Anrufe abgerechnet, die bei Ihrer Funktion eingehen. Beispiel:

  • Wenn Ihre Funktion 100 Anrufe bedient, werden Ihnen 100 HTTP Anrufe in Rechnung gestellt. Der interne HTTP Verkehr innerhalb eines Code Engine Projekts zwischen Ihren Arbeitslasten ist von der Summe der abrechenbaren HTTP Anrufe ausgeschlossen.
  • Wenn Sie eine Funktion des Typs Code Engine mit 2 GB Speicher und 0.5 virtueller CPU nach 600 Aufrufen erstellen (vorausgesetzt, jeder Aufruf benötigt 6 Sekunden, um das Ergebnis abzuschließen), werden Ihnen 0.5 vCPU-Stunden und 2 GB-Stunden in Rechnung gestellt.

Informationen zu gültigen CPU-und Speicherkombinationen finden Sie unter Unterstützte Speicher-und CPU-Kombinationen.

Die Zeit, die benötigt wird, um Ihr Codebündel zu erstellen oder es aus dem Quellcode zu erzeugen, ist in der abrechenbaren Zeit enthalten.

Preise für die Flotte

Wenn Sie eine Flotte ausführen, werden nur die CPU-, Speicher- und möglicherweise GPU-Ressourcen berechnet, die während der Ausführung der Flotte verbraucht werden.

Für jede Flotte, die Sie betreiben, können Sie Code Engine erlauben, Arbeitsknoten bereitzustellen, um die Ressourcenanforderungen der Flotte zu erfüllen, oder Sie können ein bestimmtes, von Ihnen festgelegtes Arbeitsknotenprofil bereitstellen. Im Folgenden finden Sie die Kostenüberlegungen für beide Optionen.

Wenn Sie Code Engine automatisch Worker Nodes bereitstellen lassen

Wenn Sie Ihre Flotte ausführen, geben Sie die Menge an Ressourcen an, die für die Ausführung einer Instanz Ihres Codes erforderlich ist, um eine Aufgabe zu erledigen, sowie die maximale Anzahl der gleichzeitig auszuführenden Instanzen. Code Engine setzt Arbeitsknoten mit potenziell verschiedenen Profilen ein, um diese Ressourcenanforderungen möglichst effizient zu erfüllen. In diesem Szenario basieren die Kosten auf den eingesetzten Arbeitsknoten, können aber anhand der von Ihnen angegebenen Anforderungen an die Instanzressourcen, der Anzahl der Aufgaben und der durchschnittlichen Laufzeit der Instanz geschätzt werden. Die Formel zur Schätzung der Kosten einer Flotte auf der Grundlage dieser Werte lautet:

[ (total cost of vCPU seconds) + (total cost of GB seconds) ] x (# of tasks) x (average runtime of each task in seconds)

Wenn beispielsweise eine Instanz Ihres Codes 2 vCPU und 4 GB benötigt, Sie 100 Tasks ausführen und die durchschnittliche Laufzeit jedes Tasks 0.5 Sekunden beträgt, lautet die Formel zur Schätzung der Gesamtkosten:

[ 2 x (cost of 1 vCPU second) + 4 x (cost of 1 GB second) ] x (100) x (0.5)

Die Gesamtkosten für den Betrieb der Flotte sind die Summe der Kosten für jeden Arbeitsknoten, der während der Laufzeit der Flotte genutzt wird. Darüber hinaus können sich bei erfolglosen Instanzen die Laufzeiten durch Wiederholungsversuche verlängern, was die Kosten für die Flotte erhöhen kann. Sie können die Einstellungen für die Wiederholungsversuche bei der Erstellung der Flotte konfigurieren.

Code Engine setzt nicht automatisch GPUs für Flotten ein. Um GPUs für Ihre Flotte bereitzustellen, müssen Sie sich für ein bestimmtes Worker-Profil oder eine GPU-Familie entscheiden.

Wenn Sie ein bestimmtes Arbeitnehmerprofil wählen

Wenn Sie sich dafür entscheiden, ein bestimmtes Arbeitsknotenprofil oder eine bestimmte Familie für Ihre Flotte bereitzustellen, wird nur dieser Typ von Arbeitsknoten für Ihre Flotte bereitgestellt. Die Gesamtkosten für den Betrieb der Flotte sind die kumulierten Kosten für den Betrieb jedes eingesetzten Arbeitsknotens. Sie können auch Arbeiterprofile mit GPUs wählen.

Diese Option ist derzeit nur in der CLI verfügbar.

Bedenken Sie, dass dies möglicherweise nicht die effizienteste Art ist, Ihren Fuhrpark zu betreiben, und zu höheren Kosten führen kann, wenn die eingesetzten Arbeitskräfte die benötigten Ressourcen übersteigen.

Nicht-GPU-Arbeiterprofile

Wenn Sie keine Grafikprozessoren verwenden, können die Kosten für die Ausführung eines Workers mit der folgenden Formel angenähert werden:

[ (total cost of worker VPU seconds) + (total cost of worker GB seconds) ] x (average worker runtime in seconds)

Wenn Sie zum Beispiel ein Arbeitsprofil von 16 vCPU und 64 GB wählen und Ihre Flotte 10 Sekunden lang läuft, lautet die Formel zur Schätzung der Gesamtkosten:

[ 16 x (cost of 1 vCPU second) + 64 x (cost of 1 GB second) ] x (10)

Die Gesamtkosten für den Betrieb der Flotte sind die kumulierten Kosten für den Betrieb jedes Arbeitsknotens, der eingesetzt wird. Wenn beispielsweise 2 Arbeitsknoten eingesetzt werden, würden Sie die obigen Formeln mit 2 multiplizieren, um die Gesamtkosten zu ermitteln. Beachten Sie, dass die Anzahl der Worker Nodes von den benötigten Instanzressourcen und der maximalen Anzahl gleichzeitiger Instanzen abhängt.

GPU-Arbeiterprofile

Für jeden GPU-Worker fällt eine zusätzliche Gebühr für GPU-Sekunden an. Sie können die Kosten für den Betrieb eines GPU-Arbeitsplatzes mit der folgenden Formel abschätzen:

[ (total cost of GPU-seconds) + (Total cost of vCPU seconds) + (total cost of 1 GB second) ] x (average worker runtime in seconds)

Betrachten wir zum Beispiel das Profil des Arbeitsknotens gx3-24x120x2l40s. Sie können die Werte im Profil des Arbeitsknotens verwenden, um die Kosten für die Nutzung des Arbeitsknotens zu schätzen. Das Profil setzt sich aus diesen Teilen zusammen:

  • Der erste Wert gx3 ist die Kategorie des Arbeitsknotens.
  • Der zweite Wert, 24, ist der vCPU
  • Der dritte Wert 120 ist das GB des Speichers
  • Der vierte Wert 2 L40s steht für die Anzahl der L40s GPU-Kerne.

Die ungefähren Kosten pro Sekunde für die Nutzung eines Arbeitsknotens mit diesem Profil betragen:

[ 24 x (cost of 1 vCPU second) + 120 x (cost of 1 GB second) + 2 x (cost of 1 L40 GPU-second) ] x (average worker runtime in seconds)

Die Gesamtkosten für den Betrieb der Flotte sind die kumulierten Kosten für den Betrieb jedes Arbeitsknotens, der eingesetzt wird. Wenn zum Beispiel 2 GPU-Arbeiter eingesetzt werden, würden Sie die obigen Formeln mit 2 multiplizieren, um die Gesamtkosten zu ermitteln. Beachten Sie, dass die Anzahl der Arbeitsknoten von den erforderlichen Instanzressourcen und der maximalen Anzahl gleichzeitiger Instanzen abhängt.

Preisstruktur für Builds

Wenn Sie ein Image aus dem Quellcode erstellen, um das Image als App bereitzustellen oder als Job auszuführen, werden Ihnen Speicher- und vCPU-Nutzung des Builds in Form einer entsprechenden Stundenanzahl in Rechnung gestellt. Diese Kosten sind jedoch separat von den Kosten, die Ihnen bei Verwendung des resultierenden Images in einer Anwendung oder einer Jobausführung entstehen können. Die Buildkonfiguration wird Ihnen nicht in Rechnung gestellt.

Builds werden als small, medium, large, xlarge und xxlarge Größe klassifiziert. Die Größe des Builds definiert die Zuordnung von CPU-Kernen, Hauptspeicher und Plattenspeicherplatz beim Ausführen des Builds. Ein kleinerer Build ist weniger kostenintensiv, aufgrund der geringeren Anzahl an CPU-Kernen in der Regel jedoch auch langsamer. Darüber hinaus können die Speicher- und Plattenanforderungen Ihres Builds dazu führen, dass der Build fehlschlägt, wenn die gewählte Buildgröße nicht ausreicht. Weitere Informationen zur Buildgröße finden Sie unter Größe des Builds ermitteln.

Dabei ist zu beachten, dass die Zeit, die beim Extrahieren des Quellcodes und beim Übertragen des erstellten Images beansprucht wird, in die Berechnung der kostenpflichtigen Zeit einfließt.