web-dev-qa-db-fra.com

Tarification de Google App Engine Flexible env, une leçon de 500 $

J'ai suivi le tutoriel env de Nodejs sur App Engine Flexible @: https://cloud.google.com/nodejs/getting-started/hello-world

Après avoir déployé et testé avec succès le didacticiel, j'ai modifié le code pour l'expérimenter un peu et je l'ai déployé avec succès ... puis je l'ai laissé en exécution puisqu'il s'agissait d'un environnement de test (non public).

Un mois plus tard, je reçois une facture de Google pour plus de 370 $!

Dans les détails de la transaction, je vois ce qui suit:

1 - 31 oct. 2017 Inst Engine Flex Instance RAM: 5948.774 heures en Gibibytes ([MYPROJECT]) 42,24 $

1er au 31 oct. 2017 App Engine Flex Instance Core Heures: 5948,774 heures ([MYPROJECT]) 312,91 $

Comment cet environnement de test avec près de 0 demandes a-t-il nécessité environ 6 000 heures de ressources? Dans le pire des cas, j'aurais supposé que 720 heures de travail à plein temps pendant un mois à 0,05 $ l'heure me coûteraient environ 40 $. https://cloud.google.com/appengine/pricing

Quelqu'un peut-il aider à faire la lumière sur cela? Je n'ai pas pu comprendre pourquoi tant de ressources étaient nécessaires.

Merci pour l'aide!

Pour plus de données, il s’agit du trafic au cours du dernier mois (essentiellement 0): Traffic Data

Et des données d'instance Instance Data

UPDATE: Notez que j'ai apporté une modification à package.json: j'ai ajouté nodemon en tant que dépendance et l'ajouté à mon script "nmp start". Bien que je doute que cela explique les 6000 heures de ressources:

  "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 (défaut - pas de changement du tutoriel)

runtime: nodejs
env: flex
53
ddallala

Après plusieurs allers et retours avec Google, et des heures à lire des blogs et à consulter des rapports, j'ai enfin trouvé (quelque peu) une explication de ce qui s'est passé. Je vais l'afficher ici avec mes suggestions afin que d'autres personnes ne soient pas également victimes de ce problème.

Notez que cela peut sembler évident pour certains, mais en tant que nouvel utilisateur de GAE, tout cela était nouveau pour moi.

En bref, lors du déploiement sur GAE et à l'aide de la commande suivante " $ gcloud app deploy ", il crée une nouvelle version et la définit comme valeur par défaut, mais De plus, il ne supprime PAS la version précédente qui a été déployée.

Vous trouverez plus d'informations sur les versions et les instances ici: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

Donc, dans mon cas, sans le savoir, j'avais créé plusieurs versions de mon application de nœud simple. Ces versions sont toujours en cours d'exécution au cas où il serait nécessaire de commuter après une erreur. Mais ces versions nécessitent également des instances, et la valeur par défaut, sauf indication contraire dans app.yaml, est 2 instances.

Google dit:

Par défaut, App Engine adapte le nombre d'instances en cours pour qu'il corresponde à la charge, offrant ainsi des performances constantes pour votre application à tout moment, tout en minimisant les instances inactives et en réduisant ainsi les coûts.

Cependant, d'après mon expérience, ce n'était pas le cas. Comme je l'ai dit précédemment, j'ai poussé mon application de nœud avec nodemon qui, semble-t-il, causait des erreurs.

En fin de compte, après le tutoriel et sans arrêter le projet, j'avais 4 versions, chacune avec 2 instances fonctionnant à plein temps pendant 1,5 mois, servant 0 demandes et générant beaucoup de messages d'erreur, ce qui m'a coûté 500 $.

RECOMMANDATIONS SI VOUS VOULEZ TOUJOURS UTILISER GAE FLEX ENV:

  1. Avant tout, configurez un budget de facturation et des alertes pour ne pas être surpris par une facture onéreuse automatiquement facturée à votre CC: https://cloud.google.com/billing/docs/how-to/budgets

  2. Dans un environnement de test, vous n'avez probablement pas besoin de plusieurs versions. Par conséquent, lors du déploiement, utilisez la commande suivante:
    $ gcloud app deploy --version v1

  3. Mettez à jour votre app.yaml pour ne forcer qu'une instance avec des ressources minimales:

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
  1. Fixer une limite de dépense quotidienne

enter image description here

Voir ce billet de blog pour plus d'informations: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-flexible-environment- 104fc6736495

J'aimerais que certaines de ces étapes aient été incluses dans le tutoriel afin de protéger ceux qui tentent d'apprendre et d'expérimenter, mais ce n'était pas le cas.

Google App Engine Flex env peut être difficile si vous ne connaissez pas tous ces détails. Un ami m'a dirigé vers Heroku, qui propose à la fois une offre de prix et des offres Free/Hobby. J'ai pu rapidement y installer une nouvelle application pour nœud, et cela a fonctionné à merveille! https://www.heroku.com/pricing

Cette "leçon" ne m'a coûté que 500 dollars, mais j'espère que cela aidera les autres utilisateurs de Google App Engine Flex Env.

97
ddallala

Nous avions le code déployé dans GAE FE qui devenait complètement dingue à cause d'une défaillance exponentielle en cascade (emails rebondis générés, emails renvoyés, etc.) et nous ne pouvions PAS désactiver les instances GAE qui avaient été boguées. Après plus de 4 heures et 1M + courriels envoyés (Mailgun ne nous laisserait PAS désactiver le compte. Il était indiqué "Attendez 24 heures pour que le changement du mot de passe entre en vigueur", et la révocation des clés d'API ne faisait rien), redis = VM a été arrêté, la base de données a été arrêtée et tout le code du site a été réduit à une seule page statique 503 de "maintenance non planifiée"), les courriels ont été envoyés.

J'ai déterminé que GAE FE ne terminait tout simplement pas, ni les machines virtuelles docker ni les machines virtuelles Cloud Compute (redis) soumises à une charge de processeur. Peut-être jamais! Une fois que nous avons supprimé le calcul VM (au lieu de "simplement" l'arrêter)), les courriels se sont arrêtés instantanément.

Cependant, notre base de données a continué à être remplie de notifications "ne peut pas envoyer de courrier électronique" pendant 2 heures supplémentaires, bien que l'application GAE ait signalé que "100% des versions et des instances étaient" arrêtées ". J'ai finalement dû changer le mot de passe de Google Cloud SQL.

Nous avons continué à vérifier la facture et les 7 instances non autorisées ont continué à utiliser de l’ordinateur. Nous avons donc annulé la carte utilisée pour ce compte. Le site s’est en fait effondré lorsque la facture était en souffrance, mais les instances non autorisées ont fait de même. Nous n'avons jamais réussi à résoudre le problème avec l'assistance par courrier électronique de GAE.

7
Theodore R. Smith

Merci d'avoir partagé! Après avoir lu cet article, ma facture a baissé comme le graphique ci-dessous

Steep cliff

Mon problème était que je supposais que les anciennes versions étaient arrêtées lorsque je déployais une nouvelle version (ce qui est clairement indiqué par gcloud lorsque vous déployez, divisant le trafic et arrêtant la version ...). Mais après avoir examiné attentivement la page de la version, tas de vieilles machines fonctionnent toujours mais desservent 0% du trafic. Les erreurs coûteuses peuvent être facilement corrigées en spécifiant la version lors du déploiement.

gcloud app deploy --version v1

It serves someone, right?

5
Carl Engene

Notez également que si vous souhaitez toujours que votre application dispose d'une mise à l'échelle automatique, mais que vous ne voulez pas que le minimum par défaut de 2 instances s'exécute, vous pouvez configurer votre application.yaml comme suit:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1
2
Kat