Preços do ambiente flexível do Google App Engine, uma lição de $ 500

Segui o tutorial do Nodejs no ambiente flexível do App Engine @: https://cloud.google.com/nodejs/getting-started/hello-world

Tendo implantado e testado o tutorial com sucesso, eu mudei o código para experimentar um pouco e o implantei com sucesso ... e então o deixei rodando porque este era um ambiente de teste (não público).

Um mês depois, recebo uma fatura do Google de mais de $ 370!

Nos detalhes da transação, vejo o seguinte:

De 1º a 31 de outubro de 2017 RAM da instância Flex do App Engine: 5948,774 Gibibytes-horas ([MYPROJECT]) $ 42,24

De 1º a 31 de outubro de 2017 Horas principais da instância do App Engine Flex: 5948,774 horas ([MYPROJECT]) US $ 312,91

Como esse ambiente de teste com quase 0 solicitações requer cerca de 6.000 horas de recursos? Na pior das hipóteses, eu presumiria que 720 horas em tempo integral por um mês a US $ 0,05 por hora me custaria cerca de US $ 40. https://cloud.google.com/appengine/pricing

Alguém pode ajudar a esclarecer isso? Não consegui descobrir por que tantos recursos foram necessários?

Obrigado pela ajuda!

Para obter mais dados, este é o tráfego do último mês (basicamente 0):

E dados de instância

ATUALIZAÇÃO: Observe que eu trouxe uma modificação para o package.json: adicionei o nodemon como uma dependência e o adicionei como parte do meu script "nmp start". Embora eu duvide que isso explique as 6.000 horas de recursos:

  "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 (padrão - sem alteração do tutorial)

runtime: nodejs
env: flex

Depois de várias idas e vindas com o Google e horas lendo blogs e olhando relatórios, eu finalmente (de alguma forma) encontrei uma explicação para o que aconteceu. Vou postar aqui com minhas sugestões para que outras pessoas também não sejam vítimas desse problema.

Observe que isso pode parecer óbvio para alguns, mas, como um novo usuário do GAE, tudo isso era novo para mim.

Resumindo, ao implantar no GAE e usar o seguinte comando " $ gcloud app deploy ", ele cria uma nova versão e a define como padrão, mas também e mais importante, NÃO remove a versão anterior que foi implantada.

Mais informações sobre versões e instâncias podem ser encontradas aqui: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine

Portanto, no meu caso, sem saber, criei várias versões do meu aplicativo de nó simples. Essas versões ainda estão em execução, caso seja necessário fazer a troca após um erro. Mas essas versões também requerem instâncias, e o padrão, a menos que declarado no app.yaml, é 2 instâncias.

Google diz:

Por padrão, o App Engine dimensiona o número de instâncias em execução para cima e para baixo para corresponder à carga, fornecendo desempenho consistente para seu aplicativo em todos os momentos, minimizando as instâncias ociosas e, assim, reduzindo o custo.

No entanto, por experiência própria, não foi esse o caso. Como eu disse antes, eu empurrei meu aplicativo de nó com o nodemon que parece estar causando erros.

No final, seguindo o tutorial e não encerrando o projeto, eu tinha 4 versões, cada uma com 2 instâncias rodando em tempo integral por 1,5 meses atendendo 0 pedidos e gerando muitas mensagens de erro e me custou $ 500.

RECOMENDAÇÕES SE AINDA QUER USAR O GAE FLEX ENV:

1. Em primeiro lugar, configure um orçamento de faturamento e alertas para não ser surpreendido por uma fatura cara que é automaticamente cobrada de seu CC: https://cloud.google.com/billing/docs/how-to/budgets

2. Em um ambiente de teste, você provavelmente não precisa de várias versões, portanto, durante a implantação, use o seguinte comando:
   $ gcloud app deploy --version v1

3. Atualize seu app.yaml para forçar apenas 1 instância com recursos mínimos:

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. Definir limite diário de gastos

Veja esta postagem do blog para mais informações: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-flexible-environment-104fc6736495

Eu gostaria que algumas dessas etapas tivessem sido incluídas no tutorial para proteger aqueles que estão tentando aprender e experimentar, mas não foi.

O ambiente flexível do Google App Engine pode ser complicado se não se conhece todos esses detalhes. Um amigo me indicou o Heroku, que definiu preços e ofertas gratuitas / hobby. Consegui enviar rapidamente um novo aplicativo de nó para lá e funcionou perfeitamente! https://www.heroku.com/pricing

Custou "apenas" US $ 500 para aprender esta lição, mas espero que isso ajude outras pessoas que procuram o ambiente flexível do Google App Engine.

O código implantado no GAE FE enlouqueceu devido a uma falha exponencial em cascata (e-mails devolvidos gerados por e-mails devolvidos, etc.) e NÃO pudemos desligar as instâncias do GAE que foram bugadas. Depois de mais de 4 horas e mais de 1 milhão de e-mails enviados (o Mailgun simplesmente NÃO nos deixava desativar a conta. Dizia "Aguarde até 24 horas para que a alteração da senha entre em vigor" e a revogação das chaves de API não adiantou nada), o redis VM foi interrompido, o DB fora do ar, e todo o código do site reduzido a uma única página 503 estática "Down For Maintenance"), os emails continuaram sendo enviados.

Eu determinei que o GAE FE simplesmente não encerra as VMs docker ou VMs Cloud Compute (redis) que estão sob carga da CPU. Talvez nunca! Assim que excluímos o Compute VM (em vez de "simplesmente" interrompê-lo), os e-mails pararam instantaneamente.

Porém, nosso banco de dados continuou a ficar cheio de avisos de "não foi possível enviar e-mail" por até mais 2 horas, apesar do aplicativo GAE relatar que 100% das versões e instâncias foram "interrompidas". Acabei tendo que alterar a senha do Google Cloud SQL.

Continuamos verificando a fatura, e as 7 instâncias invasoras continuaram usando CPU, então cancelamos o cartão usado nessa conta, e o site, de fato, caiu quando a fatura estava vencida, mas o mesmo aconteceu com as instâncias invasoras. Nunca conseguimos resolver a situação com o suporte por e-mail do GAE.

Se você deseja reduzir seus custos de GAE, NÃO use manual_scalingconforme sugerido neste artigo ou a resposta aceita!

A beleza do Google App Engine é que ele pode aumentar ou diminuir a escala para centenas de máquinas em milissegundos com base na demanda. E você só paga pelas instâncias em execução.

Para otimizar seus custos, você precisa entender as diferentes opções de escalonamento e tipos de instância:

1. App Engine flexível vs. padrão:

Os detalhes sobre as diferenças podem ser encontrados aqui , mas uma diferença importante relevante para esta questão é:

[Padrão] Destina-se a funcionar gratuitamente ou a um custo muito baixo, onde você paga apenas pelo que precisa e quando precisa. Por exemplo, seu aplicativo pode ser dimensionado para 0 instâncias quando não há tráfego.

2. Opções de escala:

• Escalonamento automático: o Google escalonará seu aplicativo de acordo com a demanda e a configuração fornecida.
• Escalonamento manual: sem escalonamento, o GAE executará o número exato de instâncias que você solicitou, o tempo todo (nomenclatura muito enganosa)
• Escala básica: aumentará para limitar o que você definiu e também diminuirá após certo tempo

3. Tipos de instância: Existem 2 tipos de instância e eles diferem basicamente no tempo que leva para ativar uma nova instância. Instâncias de classe F (usadas em escalonamento automático) podem ser criadas quando houver necessidade em ~ 0,1 segundos e instâncias de classe B (usadas em escalonamento manual / básico) em ~ 0,7 segundos:

Agora que você entendeu o básico, vamos voltar à resposta aceita:

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

O que isso instrui o GAE é executar uma classe de instância personalizada ( mais caro ), o tempo todo. Obviamente, esta não é a opção mais barata porque o tipo de instância B1 / F1 pode ser usado em seu lugar (tem especificações mais baixas) e também está executando uma instância constantemente.

O que seria mais barato é desligar a instância quando não há tráfego. Se você não se importa com o tempo de rotação de ~ 0,1 segundo, você pode optar por este:

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)

Isso vai cair dentro das cotas gratuitas que o Google fornece e não deve custar nada se você não tiver nenhum tráfego real.

PS: Também é altamente recomendável definir um limite de gasto diário para o caso de você ter esquecido algo em execução ou de ter algumas configurações caras em algum lugar.

Observe também que se você ainda deseja que seu aplicativo tenha escalonamento automático, mas não deseja o mínimo padrão de 2 instâncias em execução o tempo todo, pode configurar seu app.yaml da seguinte maneira:

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

Como ninguém foi mencionado, aqui estão os comandos gcloud relacionados às versões

# 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

para ambientes de desenvolvimento em que não me importo com um pouco de latência, estou usando as seguintes configurações:

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

E se você usar sua instância mais do que a permissão de instância de back-end gratuita, tente o seguinte:

instance_class: F1
automatic_scaling:
  max_instances: 1

No painel do AppEngine, observe as instâncias, anote o horário de início e verifique se, após o período idle_timeout passar, a contagem de instâncias cai para zero e você vê a mensagem "Esta versão não possui instâncias implantadas".