Preisgestaltung von Google App Engine Flexible env, eine Lektion von 500 US-Dollar

Ich folgte dem Nodejs on App Engine Flexible env Tutorial @: https://cloud.google.com/nodejs/getting-started/hello-world

Nachdem ich das Tutorial erfolgreich bereitgestellt und getestet hatte, änderte ich den Code, um ein wenig zu experimentieren, und stellte ihn erfolgreich bereit ... und ließ ihn dann laufen, da dies eine Testumgebung war (nicht öffentlich).

Einen Monat später erhalte ich von Google eine Rechnung über 370 US-Dollar!

In den Transaktionsdetails sehe ich Folgendes:

1. - 31. Oktober 2017 RAM der App Engine Flex-Instanz: 5948,774 Gibibyte-Stunden ([MYPROJECT]) 42,24 USD

1. - 31. Oktober 2017 Kernstunden der App Engine Flex-Instanz: 5948,774 Stunden ([MYPROJECT]) 312,91 USD

Wie hat diese Testumgebung mit fast 0 Anfragen etwa 6.000 Stunden Ressourcen benötigt? Im schlimmsten Fall hätte ich angenommen, dass 720 Stunden Vollzeitbeschäftigung für einen Monat bei 0,05 USD pro Stunde mich ~ 40 USD kosten würden. https://cloud.google.com/appengine/pricing

Kann jemand helfen, Licht ins Dunkel zu bringen? Ich konnte nicht herausfinden, warum so viele Ressourcen benötigt wurden.

Danke für die Hilfe!

Für weitere Daten ist dies der Verkehr im letzten Monat (im Grunde 0):

Und Instanzdaten

UPDATE: Beachten Sie, dass ich eine Änderung an package.json vorgenommen habe: Ich habe nodemon als Abhängigkeit hinzugefügt und als Teil meines Skripts "nmp start" hinzugefügt. Obwohl ich bezweifle, dass dies die 6000 Stunden an Ressourcen erklärt:

  "scripts": {
    "deploy": "gcloud app deploy",
    "start": "nodemon app.js",
    "dev": "nodemon app js",
    "lint": "samples lint",
    "pretest": "npm run lint",
    "system-test": "samples test app",
    "test": "npm run system-test",
    "e2e-test": "samples test deploy"
  },

App.yaml (Standard - keine Änderung gegenüber dem Tutorial)

runtime: nodejs
env: flex

Nach mehrmaligem Hin und Her mit Google und stundenlangem Lesen von Blogs und Betrachten von Berichten habe ich endlich (etwas) eine Erklärung dafür gefunden, was passiert ist. Ich werde es hier mit meinen Vorschlägen veröffentlichen, damit nicht auch andere Menschen diesem Problem zum Opfer fallen.

Beachten Sie, dass dies für einige offensichtlich erscheint, aber als neuer GAE-Benutzer war dies alles für mich brandneu.

Kurz gesagt, bei der Bereitstellung in GAE und mit dem folgenden Befehl " $ gcloud app deploy " eine neue Version erstellt und als Standardversion festgelegt wird, wird vor allem die zuvor bereitgestellte Version NICHT entfernt.

Weitere Informationen zu Versionen und Instanzen finden Sie hier: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

In meinem Fall hatte ich, ohne es zu wissen, mehrere Versionen meiner einfachen Knoten-App erstellt. Diese Versionen werden weiterhin ausgeführt, falls nach einem Fehler gewechselt werden muss. Diese Versionen erfordern jedoch auch Instanzen, und die Standardeinstellung ist, sofern nicht in der app.yaml angegeben, 2 Instanzen.

Google sagt:

App Engine skaliert standardmäßig die Anzahl der hoch- und runterlaufenden Instanzen, um sie an die Last anzupassen. Auf diese Weise wird jederzeit eine konsistente Leistung für Ihre App bereitgestellt, während inaktive Instanzen minimiert und somit die Kosten gesenkt werden.

Nach meiner Erfahrung war dies jedoch nicht der Fall. Wie ich bereits sagte, habe ich meine Node-App mit nodemon gepusht, was anscheinend Fehler verursacht hat.

Am Ende hatte ich nach dem Tutorial und ohne das Projekt herunterzufahren, 4 Versionen mit jeweils 2 Instanzen, die 1,5 Monate lang in Vollzeit ausgeführt wurden, 0 Anfragen bedienten und viele Fehlermeldungen generierten. Das kostete mich 500 US-Dollar.

EMPFEHLUNGEN, WENN SIE GAE FLEX ENV NOCH VERWENDEN WOLLEN:

1. Richten Sie in erster Linie ein Abrechnungsbudget und Benachrichtigungen ein, damit Sie nicht von einer teuren Rechnung überrascht werden, die automatisch Ihrem CC belastet wird: https://cloud.google.com/billing/docs/how-to/budgets

2. In einer Testumgebung benötigen Sie höchstwahrscheinlich nicht mehrere Versionen. Verwenden Sie daher während der Bereitstellung den folgenden Befehl:
   $ gcloud app deploy --version v1

3. Aktualisieren Sie Ihre app.yaml , um nur 1 Instanz mit minimalen Ressourcen zu erzwingen:

runtime: nodejs
env: flex

# This sample incurs costs to run on the App Engine flexible environment.
# The settings below are to reduce costs during testing and are not appropriate
# for production use. For more information, see:
# https://cloud.google.com/appengine/docs/flexible/nodejs/configuring-your-app-with-app-yaml
manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

4. Legen Sie das tägliche Ausgabenlimit fest

Weitere Informationen finden Sie in diesem Blogbeitrag: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-flexible-environment-104fc6736495

Ich wünschte, einige dieser Schritte wären in das Tutorial aufgenommen worden, um diejenigen zu schützen, die versuchen zu lernen und zu experimentieren, aber das war nicht der Fall.

Google App Engine Flex env kann schwierig sein, wenn man nicht alle diese Details kennt. Ein Freund hat mich auf Heroku hingewiesen, der sowohl festgelegte Preise als auch Free / Hobby-Angebote hat. Ich konnte dort schnell eine neue Knoten-App pushen, und es funktionierte wie ein Zauber! https://www.heroku.com/pricing

Es hat mich "nur" 500 US-Dollar gekostet, diese Lektion zu lernen, aber ich hoffe, dies hilft anderen, die sich Google App Engine Flex Env ​​ansehen.

Wir haben Code für GAE FE bereitgestellt, der aufgrund eines kaskadierenden, exponentiellen Fehlers (zurückgesendete E-Mails, generierte E-Mail-E-Mails usw.) absolut verrückt geworden ist, und wir konnten die fehlerhaften GAE-Instanzen NICHT deaktivieren. Nach mehr als 4 Stunden und mehr als 1 Million gesendeten E-Mails (Mailgun ließ uns das Konto einfach NICHT deaktivieren. Es hieß "Bitte warten Sie bis zu 24 Stunden, bis die Kennwortänderung wirksam wird", und das Widerrufen von API-Schlüsseln führte zu nichts) wurde gestoppt, die Datenbank heruntergefahren und der gesamte Code der Site auf eine einzige statische 503-Seite "Down For Maintenance" reduziert. Die E-Mails wurden weiterhin gesendet.

Ich habe festgestellt, dass GAE FE weder Docker-VMs noch Cloud Compute-VMs (Redis) beendet, die unter CPU-Last stehen. Vielleicht nie! Sobald wir die Compute VM tatsächlich gelöscht haben (anstatt sie "nur" zu stoppen), wurden die E-Mails sofort gestoppt.

Unsere Datenbank wurde jedoch noch bis zu 2 Stunden lang mit Benachrichtigungen "E-Mail konnte nicht gesendet werden" gefüllt, obwohl die GAE-App 100% der Versionen und Instanzen als "gestoppt" meldete. Am Ende musste ich das Google Cloud SQL-Passwort ändern.

Wir haben die Rechnung weiter überprüft, und die 7 Schurkeninstanzen haben weiterhin CPU verbraucht. Daher haben wir die auf diesem Konto verwendete Karte storniert, und die Website ist tatsächlich gesunken, als die Rechnung überfällig war, aber auch die Schurkeninstanzen. Mit dem GAE-E-Mail-Support konnten wir die Situation nie lösen.

Wenn Sie Ihre GAE Kosten senken bitte NICHT verwenden , manual_scalingwie in vorgeschlagen diesem Artikel oder die akzeptierte Antwort!

Das Schöne an Google App Engine ist, dass es je nach Bedarf innerhalb von Millisekunden auf Hunderte von Computern skaliert werden kann. Und Sie zahlen nur für laufende Instanzen.

Um Ihre Kosten optimieren zu können, müssen Sie die verschiedenen Skalierungsoptionen und Instanztypen kennen:

1. App Engine Flex vs Standard:

Die Details zu Unterschieden finden Sie hier , aber ein wichtiger Unterschied, der für diese Frage relevant ist, ist:

[Standard is] Soll kostenlos oder zu sehr geringen Kosten ausgeführt werden, wobei Sie nur für das bezahlen, was Sie benötigen und wann Sie es benötigen. Beispielsweise kann Ihre Anwendung auf 0 Instanzen skaliert werden, wenn kein Datenverkehr vorhanden ist.

2. Skalierungsoptionen:

• Automatische Skalierung: Google skaliert Ihre App je nach Bedarf und Konfiguration.
• Manuelle Skalierung: Überhaupt keine Skalierung. GAE führt die genaue Anzahl der von Ihnen angeforderten Instanzen ständig aus (sehr irreführende Benennung).
• Grundlegende Skalierung: Sie wird vergrößert, um die von Ihnen festgelegten Werte zu begrenzen, und nach einer bestimmten Zeit auch verkleinert

3. Instanztypen: Es gibt zwei Instanztypen , die sich grundsätzlich in der Zeit unterscheiden, die zum Hochfahren einer neuen Instanz benötigt wird. Instanzen der F-Klasse (bei der automatischen Skalierung verwendet) können bei Bedarf innerhalb von ~ 0,1 Sekunden und Instanzen der B-Klasse (bei der manuellen Skalierung / Basis) innerhalb von ~ 0,7 Sekunden erstellt werden:

Nachdem Sie die Grundlagen verstanden haben, kehren wir zur akzeptierten Antwort zurück:

manual_scaling:
  instances: 1
resources:
  cpu: 1
  memory_gb: 0.5
  disk_size_gb: 10

Dies weist GAE an, eine benutzerdefinierte Instanzklasse auszuführen ( teurer , ständig ) . Offensichtlich ist dies nicht die billigste Option, da stattdessen der Instanztyp B1 / F1 verwendet werden könnte (er hat niedrigere Spezifikationen) und eine Instanz ständig ausgeführt wird.

Am billigsten wäre es , die Instanz auszuschalten, wenn kein Datenverkehr vorhanden ist. Wenn Ihnen die ~ 0,1 Sekunden Hochlaufzeit nichts ausmacht, können Sie stattdessen Folgendes tun:

instance_class: F1
automatic_scaling:
  max_instances: 1 (--> you can adjust this as you wish)
  min_instances: 0 (--> will scale to 0 when there is no traffic so won't incur costs)

Dies fällt unter die kostenlosen Quoten, die Google anbietet, und es sollte Sie nichts kosten, wenn Sie keinen echten Datenverkehr haben.

PS: Es wird außerdem dringend empfohlen, ein tägliches Ausgabenlimit festzulegen, falls Sie etwas vergessen haben oder irgendwo kostspielige Einstellungen vorgenommen haben.

Beachten Sie außerdem, dass Sie Ihre app.yaml folgendermaßen konfigurieren können, wenn Ihre App weiterhin automatisch skaliert werden soll, aber nicht mindestens 2 Instanzen standardmäßig ausgeführt werden sollen:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Da niemand erwähnt hat, sind hier die gcloud-Befehle, die sich auf die Versionen beziehen

# List all versions
$ gcloud app versions list

SERVICE  VERSION.ID       TRAFFIC_SPLIT  LAST_DEPLOYED              SERVING_STATUS
default  20200620t174631  0.00           2020-06-20T17:46:56+03:00  SERVING
default  20200620t174746  0.00           2020-06-20T17:48:12+03:00  SERVING
default  prod             1.00           2020-06-20T17:54:51+03:00  SERVING

# Delete these 2 versions (you can't delete all versions, you have to have at least one remaining)
$ gcloud app versions delete 20200620t174631 20200620t174746

# Help
$ gcloud app versions --help

Für Entwicklungsumgebungen, in denen mir eine kleine Latenz nichts ausmacht, verwende ich die folgenden Einstellungen:

instance_class: B1
basic_scaling:
  max_instances: 1
  idle_timeout: 1m

Wenn Sie Ihre Instanz mehr als die zulässige kostenlose Backend-Instanz verwenden, versuchen Sie Folgendes:

instance_class: F1
automatic_scaling:
  max_instances: 1

Im AppEngine-Dashboard können Sie die Instanzen überwachen, die Startzeit notieren und sicherstellen, dass nach Ablauf der Zeitspanne idle_timeout die Anzahl der Instanzen auf Null sinkt und die Meldung "In dieser Version sind keine Instanzen bereitgestellt" angezeigt wird.