Preços do Google App Engine env flexível, uma lição de $ 500
eu segui o tutorial Nodejs no App Engine Flexible env @: https://cloud.google.com/nodejs/getting-started/hello-world
tendo implantado com sucesso e testado o tutorial, alterei o código para experimentar um pouco e implementei-o com sucesso... e, em seguida, deixou-o funcionando, uma vez que este era um ambiente de teste (não Público).
Um mês depois, recebo uma conta do Google por mais de $370!nos detalhes da transacção vejo o seguinte:
Como é que este ambiente de testes, com quase 0 pedidos, requereu cerca de 6.000 horas de recursos? Na pior das hipóteses, teria assumido que 720 horas a correr a tempo inteiro durante um mês @ $ 0,05 por hora me custaria ~$40. https://cloud.google.com/appengine/pricing Alguém pode ajudar a esclarecer isto? Não consegui descobrir por que razão foram necessários tantos recursos? Obrigado pela ajuda!out 1-31, 2017 App Engine Flex Instance RAM: 5948, 774 Gibibyte-hours ([MYPROJECT]) $42,24
out 1-31, 2017 App Engine Flex Instance Core Hours: 5948.774 horas ([MYPROJECT]) $312.91
para mais dados, este é o tráfego durante o último mês (basicamente 0):
e dados de instância
Actualizar: Note que eu trouxe uma modificação para o pacote.json: eu adicionei nodemon como uma dependência e adicionei-o como parte do meu "nmp" começa o guião. Embora duvide que isto explique as 6000 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 (por omissão-nenhuma alteração do tutorial)
runtime: nodejs
env: flex
3 answers
Depois de várias vezes com o Google, e horas de leitura de blogs e olhando para relatórios, eu finalmente (um pouco) encontrei uma explicação para o que aconteceu. Vou postá-lo aqui com as minhas sugestões para que outras pessoas não também ser vítima deste problema.
Nota, Isto pode parecer óbvio para alguns, mas como um novo utilizador da GAE, tudo isto era novo para mim.Em resumo, ao enviar para o GAE e usar o seguinte comando "$ gcloud app deploy ", cria um nova versão e define-o como o padrão, mas também e mais importante, ele 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
Então, no meu caso, sem saber, eu tinha criado várias versões do meu aplicativo de nó simples. Estas versões ainda estão em execução no caso de ser necessário mudar após um erro. Mas estas versões também require instances, and the default, unless stated in the app.yaml, são duas instâncias.
O Google diz:No entanto, pela minha experiência, não foi esse o caso. Como eu disse antes, eu empurrei meu app node com nodemon que parece estar causando erro.O motor de aplicações por omissão calcula o número de instâncias que se encontram em funcionamento e baixo para igualar a carga, proporcionando assim um desempenho consistente para o seu app em todos os momentos, minimizando as instâncias inativas e, assim, reduzindo custo.
No final, seguindo o tutorial e não fechando o projeto, eu tinha 4 versões, cada uma com 2 instâncias executando em tempo integral por 1,5 meses servindo 0 pedidos e gerando muitas mensagens de erro e custou-me $500.
RECOMENDAÇÕES SE AINDA QUISER USAR GAE FLEX ENV:
Em primeiro lugar, configurar um orçamento de faturamento e alertas para que você não se surpreenda com uma fatura cara que é cobrada automaticamente para o seu CC: https://cloud.google.com/billing/docs/how-to/budgets
Em um ambiente de teste, você provavelmente não precisa de várias versões, então, ao implantar use o seguinte comando:
$ gcloud app deploy --version v1Actualiza a tua aplicação .yaml forçar apenas uma instância:
runtime: nodejs env: flex manual_scaling: instances: 1
Veja este post para mais informações: https://medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-flexible-environment-104fc6736495
Gostaria que alguns desses passos tivessem sido incluídos no tutorial para proteger aqueles que estão tentando aprender e experimentar, mas não foi.O Google App Engine Flex env pode ser complicado se não se souber todos estes detalhes. Um amigo me apontou para Heroku, que tem preços estabelecidos e ofertas de livre/Hobby. Eu fui capaz de empurrar rapidamente um nova aplicação de nódulos lá, e funcionou como um encanto! https://www.heroku.com/pricing
" apenas " custou-me 500 dólares para aprender esta lição, mas espero que isto ajude outros a olhar para o Google App Engine Flex Env.
Tivemos o código enviado para o GAE FE ficar completamente louco devido a uma falha exponencial em cascata (e-mails saltados gerados-e-mails saltados, etc.) e não podíamos desligar as instâncias GAE que estavam sob escuta. Depois de mais de 4 horas, e E-mails de 1M+ enviados (Mailgun apenas não nos deixaria desativar a conta. Ele disse: "Por favor, espere até 24 horas para a mudança de senha para entrar em vigor", e revogando as chaves API não fez nada), o redis VM foi parado, o DB para baixo, e todo o código do site reduzido a um single "Down For Maintenance" static 503 page), Os e-mails continuaram a ser enviados.
Eu determinei que o GAE FE simplesmente não termina nem o docker VMs nem o Cloud Compute VMs (redis) que estão sob carga de CPU. Talvez nunca! Uma vez que realmente excluímos o VM Compute (em vez de "meramente" parando-o), os e-mails pararam instantaneamente.
Mas, o nosso DB continuou a ser preenchido com avisos de" não podia enviar e-mail" por mais 2 horas, apesar do app GAE reportar 100% das versões e instâncias a serem "paradas". Acabei por ter de mudar a senha do Google Cloud SQL.
Continuámos a verificar a conta, e as 7 instâncias desonestas continuaram a usar CPU e por isso cancelámos o cartão usado naquela conta, e o site, de facto, caiu quando a conta já tinha passado, mas também as instâncias desonestas. Nós nunca fomos capazes de resolver a situação com o Suporte de E-mail GAE.Lembre-se também que, se ainda quiser que a sua aplicação tenha uma escala automática, mas não quiser que o mínimo por omissão de 2 instâncias esteja sempre a correr, poderá configurar a sua aplicação.yaml assim:
runtime: nodejs
env: flex
automatic_scaling:
min_num_instances: 1