Prix ​​de l'environnement flexible Google App Engine, un cours de 500 $

J'ai suivi le didacticiel d'environnement 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 tutoriel, j'ai changé le code pour expérimenter un peu et l'ai déployé avec succès ... puis je l'ai laissé en cours d'exécution car il s'agissait d'un environnement de test (non public).

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

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

1 - 31 octobre 2017 RAM de l'instance App Engine Flex: 5948,774 Gibibyte-heures ([MYPROJECT]) 42,24 $

1er au 31 octobre 2017 Heures de base de l'instance App Engine Flex: 5948,774 heures ([MYPROJECT]) 312,91 $

Comment cet environnement de test avec presque 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 fonctionnement à plein temps pendant un mois à 0,05 $ l'heure me coûteraient ~ 40 $. https://cloud.google.com/appengine/pricing

Quelqu'un peut-il aider à faire la lumière à ce sujet? Je n'ai pas été en mesure de savoir pourquoi tant de ressources étaient nécessaires?

Merci pour l'aide!

Pour plus de données, voici le trafic du mois dernier (essentiellement 0):

Et les données d'instance

MISE À JOUR: Notez que j'ai apporté une modification au package.json: j'ai ajouté nodemon en tant que dépendance et l'ai ajouté dans le cadre de 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 (par défaut - aucun changement par rapport au didacticiel)

runtime: nodejs
env: flex

Après de multiples allers-retours avec Google, et des heures à lire des blogs et à regarder des rapports, j'ai enfin (un peu) trouvé une explication à ce qui s'est passé. Je le posterai 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 de l'utilisation de la commande suivante " $ gcloud app deploy ", il crée une nouvelle version et la définit comme la version par défaut, mais aussi et plus important encore, 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 faudrait changer suite à une erreur. Mais ces versions nécessitent également des instances, et la valeur par défaut, sauf indication contraire dans app.yaml, est de 2 instances.

Google dit:

Par défaut, App Engine adapte le nombre d'instances en cours d'exécution en fonction de 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 plus tôt, j'ai poussé mon application de nœud avec nodemon, ce qui semble causer des erreurs.

En fin de compte, en suivant 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 requête et générant beaucoup de messages d'erreur et cela 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 coûteuse qui est automatiquement facturée sur 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, alors lors du déploiement, utilisez la commande suivante:
   $ gcloud app deploy --version v1

3. Mettez à jour votre app.yaml pour ne forcer qu'une seule 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

4. Définir la limite de dépenses quotidiennes

Consultez cet article 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'aurais aimé que certaines de ces étapes aient été incluses dans le didacticiel afin de protéger ceux qui essaient d'apprendre et d'expérimenter, mais ce n'était pas le cas.

L'environnement de Google App Engine Flex peut être délicat si l'on ne connaît pas tous ces détails. Un ami m'a indiqué Heroku, qui propose à la fois des prix fixes et des offres Free / Hobby. J'ai pu y installer rapidement une nouvelle application de nœud, et cela a fonctionné comme du charme! https://www.heroku.com/pricing

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

Si vous souhaitez réduire vos coûts GAE, veuillez NE PAS utiliser manual_scalingcomme suggéré dans cet article ou la réponse acceptée!

La belle chose à propos de Google App Engine est qu'il peut évoluer jusqu'à des centaines de machines en quelques millisecondes en fonction de la demande. Et vous ne payez que pour les instances en cours d'exécution.

Pour pouvoir optimiser vos coûts, vous devez comprendre les différentes options de mise à l'échelle et les types d'instances:

1. Flex du moteur d'application vs standard:

Les détails sur les différences peuvent être trouvés ici , mais une différence importante pertinente pour cette question est:

[Standard is] Destiné à fonctionner gratuitement ou à un coût très bas, où vous ne payez que pour ce dont vous avez besoin et quand vous en avez besoin. Par exemple, votre application peut évoluer vers 0 instance lorsqu'il n'y a pas de trafic.

2. Options de mise à l'échelle:

• Mise à l'échelle automatique: Google fera évoluer votre application en fonction de la demande et de la configuration que vous avez fournies.
• Mise à l'échelle manuelle: aucune mise à l'échelle du tout, GAE exécutera le nombre exact d'instances que vous avez demandé, tout le temps (dénomination très trompeuse)
• Mise à l'échelle de base: elle augmentera jusqu'à la limite que vous avez définie et diminuera également après un certain temps

3. Types d'instances: Il existe 2 types d'instances , et elles diffèrent fondamentalement dans le temps nécessaire pour créer une nouvelle instance. Les instances de classe F (utilisées dans la mise à l'échelle automatique) peuvent être créées en cas de besoin en ~ 0,1 seconde et les instances de classe B (utilisées dans la mise à l'échelle manuelle / basique) en ~ 0,7 seconde:

Maintenant que vous avez compris les bases, revenons à la réponse acceptée:

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

Ce que cela indique à GAE est d'exécuter une classe d'instance personnalisée ( plus coûteuse ), tout le temps. De toute évidence, ce n'est pas l'option la moins chère car le type d'instance B1 / F1 pourrait être utilisé à la place (il a des spécifications inférieures) et il exécute également une instance en permanence.

Ce qui serait le moins cher est de désactiver l'instance lorsqu'il n'y a pas de trafic. Si cela ne vous dérange pas le temps de rotation d'environ 0,1 seconde, vous pouvez utiliser ceci à la place:

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)

Cela relèvera des quotas gratuits fournis par Google et ne devrait rien vous coûter si vous n'avez pas de trafic réel.

PS: Il est également fortement recommandé de définir une limite de dépenses quotidiennes au cas où vous auriez oublié quelque chose en cours d'exécution ou si vous avez des paramètres coûteux quelque part.

Le code déployé sur GAE FE est devenu complètement fou en raison d'un échec exponentiel en cascade (les e-mails rebondis ont généré des e-mails rebondis, etc.) et nous ne pouvions PAS désactiver les instances GAE qui étaient buggées. Après plus de 4 heures et plus de 1 million d'e-mails envoyés (Mailgun ne nous a tout simplement PAS laissé désactiver le compte. Il disait "Veuillez attendre jusqu'à 24 heures pour que le changement de mot de passe entre en vigueur", et la révocation des clés API n'a rien fait), la VM redis a été arrêté, la base de données en panne, et tout le code du site réduit à une seule page statique 503 "Down For Maintenance"), les courriels ont continué à être envoyés.

J'ai déterminé que GAE FE ne mettait tout simplement pas fin aux VM docker ou aux VM Cloud Compute (redis) qui sont sous la charge du processeur. Peut-être jamais! Une fois que nous avons supprimé la machine virtuelle Compute (au lieu de "simplement" l'arrêter), les e-mails se sont arrêtés instantanément.

Cependant, notre base de données a continué à être remplie d'avis "Impossible d'envoyer un e-mail" pendant jusqu'à 2 heures de plus, bien que l'application GAE ait signalé que 100% des versions et des instances étaient "arrêtées". J'ai fini par devoir changer le mot de passe Google Cloud SQL.

Nous avons continué à vérifier la facture, et les 7 instances non autorisées ont continué à utiliser le processeur et nous avons donc annulé la carte utilisée pour ce compte, et le site a, en fait, baissé lorsque la facture était en souffrance, tout comme les instances voyous. Nous n'avons jamais été en mesure de résoudre la situation avec l'assistance par e-mail GAE.

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

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Puisque personne n'a mentionné, voici les commandes gcloud liées aux versions

# 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

pour les environnements de développement où la latence ne me dérange pas, j'utilise les paramètres suivants:

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

Et si vous utilisez votre instance plus que l'allocation gratuite d'instance backend, essayez ceci:

instance_class: F1
automatic_scaling:
  max_instances: 1

Dans le tableau de bord AppEngine, regardez les instances, prenez note de l'heure de début et vérifiez qu'après la période idle_timeout, le nombre d'instances tombe à zéro et le message "Cette version n'a aucune instance déployée" s'affiche.