Prezzi di Google App Engine Flexible env, una lezione da $ 500

Ho seguito il tutorial env flessibile di Nodejs su App Engine @: https://cloud.google.com/nodejs/getting-started/hello-world

Dopo aver distribuito e testato con successo il tutorial, ho cambiato il codice per sperimentare un po 'e l'ho distribuito con successo ... e poi l'ho lasciato in esecuzione poiché questo era un ambiente di test (non pubblico).

Un mese dopo, ricevo una fattura da Google per oltre $ 370!

Nei dettagli della transazione vedo quanto segue:

1 - 31 ottobre 2017 RAM istanza App Engine Flex: 5948,774 Gibibyte-ore ([MYPROJECT]) $ 42,24

1 - 31 ottobre 2017 Ore core istanza App Engine Flex: 5948,774 ore ([MYPROJECT]) $ 312,91

In che modo questo ambiente di test con quasi 0 richieste ha richiesto circa 6.000 ore di risorse? Nel peggiore dei casi, avrei supposto che 720 ore di funzionamento a tempo pieno per un mese a $ 0,05 l'ora mi costerebbero ~ $ 40. https://cloud.google.com/appengine/pricing

Qualcuno può aiutare a far luce su questo? Non sono riuscito a scoprire perché erano necessarie così tante risorse?

Grazie per l'aiuto!

Per ulteriori dati, questo è il traffico nell'ultimo mese (praticamente 0):

E dati di istanza

AGGIORNAMENTO: Nota che ho apportato una modifica a package.json: ho aggiunto nodemon come dipendenza e l'ho aggiunto come parte del mio script "nmp start". Anche se dubito che questo spieghi le 6000 ore di risorse:

  "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 (impostazione predefinita, nessuna modifica dal tutorial)

runtime: nodejs
env: flex

Dopo molteplici avanti e indietro con Google e ore di lettura di blog e analisi di rapporti, ho finalmente (un po ') trovato una spiegazione per quello che è successo. Lo posterò qui con i miei suggerimenti in modo che anche altre persone non cadano vittime di questo problema.

Nota, questo può sembrare ovvio per alcuni, ma come nuovo utente GAE, tutto questo era nuovo di zecca per me.

In breve, durante la distribuzione su GAE e utilizzando il seguente comando " $ gcloud app deploy ", crea una nuova versione e la imposta come predefinita, ma anche e, cosa più importante, NON rimuove la versione precedente che era stata distribuita.

Ulteriori informazioni su versioni e istanze sono disponibili qui: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

Quindi nel mio caso, senza saperlo, avevo creato più versioni della mia semplice app per nodi. Queste versioni sono ancora in esecuzione nel caso in cui sia necessario cambiare in seguito a un errore. Ma queste versioni richiedono anche istanze e l'impostazione predefinita, a meno che non sia specificato in app.yaml, è 2 istanze.

Google dice:

Per impostazione predefinita, App Engine ridimensiona il numero di istanze in esecuzione in base al carico, fornendo così prestazioni costanti per la tua app in ogni momento, riducendo al minimo le istanze inattive e riducendo i costi.

Tuttavia, dalla mia esperienza, non è stato così. Come ho detto prima, ho spinto la mia app del nodo con nodemon che sembra stesse causando errori.

Alla fine, seguendo il tutorial e senza chiudere il progetto, ho avuto 4 versioni, ciascuna con 2 istanze in esecuzione a tempo pieno per 1,5 mesi che servono 0 richieste e genera molti messaggi di errore e mi è costato $ 500.

RACCOMANDAZIONI SE VUOI ANCORA UTILIZZARE GAE FLEX ENV:

1. Innanzitutto, imposta un budget di fatturazione e avvisi in modo da non essere sorpreso da una costosa fattura che viene automaticamente addebitata al tuo CC: https://cloud.google.com/billing/docs/how-to/budgets

2. In un ambiente di test, molto probabilmente non hai bisogno di più versioni, quindi durante la distribuzione usa il seguente comando:
   $ gcloud app deploy --version v1

3. Aggiorna il tuo app.yaml per forzare solo 1 istanza con risorse minime:

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. Imposta il limite di spesa giornaliero

Vedi questo post del blog per maggiori informazioni: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-forrect-environment-104fc6736495

Vorrei che alcuni di questi passaggi fossero stati inclusi nel tutorial per proteggere coloro che stanno cercando di imparare e sperimentare, ma non è stato così.

L'env di Google App Engine Flex può essere complicato se non si conoscono tutti questi dettagli. Un amico mi ha indicato Heroku, che ha sia prezzi fissi che offerte gratuite / hobby. Sono stato in grado di spingere rapidamente una nuova app per nodi lì e ha funzionato a meraviglia! https://www.heroku.com/pricing

Mi è costato "solo" $ 500 per imparare questa lezione, ma spero che questo aiuti gli altri che guardano Google App Engine Flex Env.

Se vuoi ridurre i tuoi costi GAE, NON utilizzare manual_scalingcome suggerito in questo articolo o la risposta accettata!

La cosa bella di Google App Engine è che può scalare su e giù fino a centinaia di macchine in pochi millisecondi in base alla domanda. E paghi solo per le istanze in esecuzione.

Per poter ottimizzare i costi è necessario comprendere le diverse opzioni di ridimensionamento e i tipi di istanza:

1. Flessibilità del motore di app rispetto allo standard:

I dettagli sulle differenze possono essere trovati qui , ma un'importante differenza rilevante per questa domanda è:

[Standard is] Destinato a funzionare gratuitamente oa un costo molto basso, dove paghi solo per ciò di cui hai bisogno e quando ne hai bisogno. Ad esempio, la tua applicazione può scalare a 0 istanze quando non c'è traffico.

2. Opzioni di ridimensionamento:

• Ridimensionamento automatico: Google ridimensionerà la tua app in base alla richiesta e alla configurazione che hai fornito.
• Ridimensionamento manuale: nessun ridimensionamento, GAE eseguirà il numero esatto di istanze richieste, tutto il tempo (denominazione molto fuorviante)
• Ridimensionamento di base: si ridimensionerà fino al limite impostato e si ridurrà anche dopo un certo tempo

3. Tipi di istanza: ci sono 2 tipi di istanza e sostanzialmente differiscono nel tempo necessario per avviare una nuova istanza. Le istanze di classe F (utilizzate nel ridimensionamento automatico) possono essere create quando è necessario entro ~ 0,1 secondi e le istanze di classe B (utilizzate nel ridimensionamento manuale / di base) entro ~ 0,7 secondi:

Ora che hai capito le basi torniamo alla risposta accettata:

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

Ciò che indica a GAE è di eseguire una classe di istanza personalizzata ( più costosa ), tutto il tempo. Ovviamente questa non è l'opzione più economica perché potrebbe essere utilizzato invece il tipo di istanza B1 / F1 (ha specifiche inferiori) ed è anche in esecuzione un'istanza costantemente.

La soluzione più economica è disattivare l'istanza quando non c'è traffico. Se non ti dispiace il tempo di rotazione di ~ 0,1 secondi, potresti invece optare per questo:

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)

Questo rientra nelle quote gratuite fornite da Google e non dovrebbe costarti nulla se non hai traffico reale.

PS: Si consiglia inoltre di impostare il limite di spesa giornaliero nel caso in cui si dimentichi qualcosa in esecuzione o si dispone di impostazioni costose da qualche parte.

Avevamo il codice distribuito su GAE FE impazzito a causa di un errore esponenziale a cascata (e-mail rimbalzate generate e-mail rimbalzate, ecc.) E NON potevamo disattivare le istanze GAE che presentavano bug. Dopo più di 4 ore e più di 1 milione di email inviate (Mailgun NON ci permetteva di disabilitare l'account. Diceva "Attendi fino a 24 ore affinché la modifica della password diventi effettiva" e la revoca delle chiavi API non ha fatto nulla), la VM redis è stato interrotto, il DB inattivo e tutto il codice del sito ridotto a una singola pagina 503 statica "Down For Maintenance"), le e-mail continuavano ad essere inviate.

Ho determinato che GAE FE semplicemente non termina né le VM docker né le VM Cloud Compute (redis) che sono sotto carico della CPU. Forse mai! Una volta che abbiamo effettivamente eliminato la VM di Compute (invece di "semplicemente" interromperla), le e-mail si sono interrotte immediatamente.

Tuttavia, il nostro database ha continuato a riempirsi di avvisi di "impossibile inviare e-mail" fino a 2 ore in più, nonostante l'app GAE abbia segnalato che il 100% delle versioni e delle istanze era stato "arrestato". Ho finito per dover cambiare la password di Google Cloud SQL.

Abbiamo continuato a controllare il conto e le 7 istanze non autorizzate hanno continuato a utilizzare la CPU e quindi abbiamo annullato la carta utilizzata su quell'account, e il sito, in effetti, è andato giù quando il conto era scaduto, ma anche le istanze non autorizzate. Non siamo mai stati in grado di risolvere la situazione con l'assistenza e-mail di GAE.

Tieni inoltre presente che se desideri comunque che la tua app abbia il ridimensionamento automatico ma non vuoi che il minimo predefinito di 2 istanze sia sempre in esecuzione, puoi configurare il tuo app.yaml in questo modo:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Dato che nessuno ha menzionato, ecco i comandi di gcloud relativi alle versioni

# 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

per gli ambienti di sviluppo in cui non mi dispiace un po 'di latenza, sto usando le seguenti impostazioni:

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

E se utilizzi la tua istanza più del permesso gratuito per l'istanza di backend, prova questo:

instance_class: F1
automatic_scaling:
  max_instances: 1

Nella dashboard di AppEngine, controlla le istanze, prendi nota dell'ora di inizio e verifica che dopo il periodo di idle_timeout il conteggio delle istanze scenda a zero e visualizzi il messaggio "Questa versione non ha istanze distribuite".