Google App Engineフレキシブル環境の料金、500ドルのレッスン

AppjsでNodejsフレキシブルenvチュートリアルをフォローしました@：https ://cloud.google.com/nodejs/getting-started/hello-world

チュートリアルを正常にデプロイしてテストした後、コードを変更して少し実験し、正常にデプロイしました。次に、これはテスト環境（非公開）である​​ため、実行したままにしました。

1か月後、Googleから$ 370以上の請求書が届きました。

取引の詳細には以下が表示されます。

2017年10月1日〜31日App Engine FlexインスタンスRAM：5948.774ギビバイト時間（[MYPROJECT]）$ 42.24

2017年10月1〜31日App Engine Flexインスタンスのコア時間：5948.774時間（[MYPROJECT]）$ 312.91

リクエストがほとんどないこのテスト環境は、約6,000時間のリソースをどのように必要としましたか？最悪の場合、1か月間フルタイムで720時間実行すると、1時間あたり$ 0.05で約$ 40のコストがかかると想定していました。 https://cloud.google.com/appengine/pricing

誰かがこれに光を当てるのを手伝ってくれる？なぜこんなに多くのリソースが必要なのか、私にはわかりませんでしたか？

助けてくれてありがとう！

より多くのデータについては、これは先月のトラフィックです（基本的に0）：

そしてインスタンスデータ

更新：package.jsonに1つの変更を加えたことに注意してください：nodemonを依存関係として追加し、それを「nmp start」スクリプトの一部として追加しました。疑わしいのですが、これは6000時間のリソースを説明しています。

  "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（デフォルト-チュートリアルからの変更なし）

runtime: nodejs
env: flex

Googleと何度もやり取りし、何時間もブログを読んだり、レポートを確認したりして、ついに（やや）何が起こったかの説明を見つけました。他の人もこの問題の犠牲にならないように、ここに私の提案を添えて掲載します。

これは一部の人には明白に思えるかもしれませんが、新しいGAEユーザーとして、これらはすべてまったく新しいものでした。

つまり、GAEにデプロイして次のコマンド「$ gcloud app deploy」を使用すると、新しいバージョンが作成され、それがデフォルトとして設定されますが、さらに重要なことに、デプロイされた以前のバージョンは削除されません。

バージョンとインスタンスの詳細については、https：//cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engineをご覧ください。

そのため、私の場合、知らないうちに、単純なノードアプリの複数のバージョンを作成していました。エラー後に切り替える必要がある場合に備えて、これらのバージョンはまだ実行中です。ただし、これらのバージョンにはインスタンスも必要であり、app.yamlで指定されていない限り、デフォルトは2つのインスタンスです。

グーグルは言う：

App Engineはデフォルトで、負荷に合わせて実行中のインスタンスの数を増減し、常にアイドル状態のインスタンスを最小限に抑えながらアプリのパフォーマンスを一定に保ち、コストを削減します。

しかし、私の経験から、これはそうではありませんでした。先ほど言ったように、nodemonを使用してノードアプリをプッシュしましたが、エラーが発生しているようです。

結局、チュートリアルに従ってプロジェクトをシャットダウンせずに、4つのバージョンがあり、それぞれ2つのインスタンスが1.5か月間フルタイムで実行され、0のリクエストを処理し、大量のエラーメッセージを生成し、500ドルかかりました。

GAE FLEX ENVを使用する場合の推奨事項：

1. 何よりもまず、CCに自動的に請求される高価な請求書に驚かないように、請求予算とアラートを設定します。https：//cloud.google.com/billing/docs/how-to/budgets

2. テスト環境では、多くの場合、複数のバージョンは必要ないため、デプロイ中に次のコマンドを使用します。
   $ gcloud app deploy --version v1

3. 最小限のリソースで1つのインスタンスのみを強制するようにapp.yamlを更新します。

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. 1日の費用制限を設定する

詳細については、このブログ投稿を参照してください：https : //medium.com/google-cloud/three-simple-steps-to-save-costs-when-prototyping-with-app-engine-flexible-environment-104fc6736495

学習や実験をしようとしている人たちを保護するために、これらの手順の一部がチュートリアルに含まれていれば良かったのですが、そうではありませんでした。

これらすべての詳細を知らないと、Google App Engine Flexの環境は扱いにくい場合があります。友人がHerokuを私に指摘しました。Herokuには、価格設定と無料/ホビーの両方のオファーがあります。そこに新しいノードアプリを素早くプッシュすることができ、それは魅力のように機能しました！ https://www.heroku.com/pricing

このレッスンを学ぶのに500ドルしかかからなかったが、これがGoogle App Engine Flex Env​​を見る他の人に役立つことを願っている。

カスケード、指数関数的な失敗（バウンスされたメール、バウンスされたメールのメールなど）が原因で、GAE FEにコードをデプロイしましたが、まったく問題があり、バグのあるGAEインスタンスをオフにすることはできませんでした。4時間以上、100万件以上のメールが送信された後（Mailgunはアカウントを無効にできませんでした。「パスワードの変更が有効になるまで最大24時間お待ちください」と表示され、APIキーを取り消しても何も起こりませんでした）、redis VMが停止し、DBがダウンし、サイトのすべてのコードが単一の「メンテナンスのためのダウン」静的503ページに削減された場合）、メールは送信され続けました。

GAE FEは、CPU負荷がかかっているDocker VMもCloud Compute VM（redis）も単に終了しないと判断しました。多分決して！Compute VMを実際に削除すると（「単に」停止するのではなく）、メールは即座に停止しました。

しかし、GAEアプリがバージョンとインスタンスの100％が「停止」であると報告したにもかかわらず、DBは「メールを送信できませんでした」という通知でさらに最大2時間いっぱいになり続けました。Google Cloud SQLのパスワードを変更する必要がありました。

私たちは請求書をチェックし続け、7つの不正なインスタンスがCPUを使い続けたため、そのアカウントで使用されたカードをキャンセルしました。実際、請求書が期日を過ぎるとサイトはダウンしましたが、不正なインスタンスもダウンしました。GAEのメールサポートでは、この状況を解決することはできませんでした。

GAEのコストを削減したい場合は、この記事または承認された回答で提案されているように使用しないでください。manual_scaling

Google App Engineのすばらしいところは、要求に応じて数ミリ秒以内に数百台のマシンにスケールアップおよびスケールダウンできることです。また、実行中のインスタンスに対してのみ支払います。

コストを最適化するには、さまざまなスケーリングオプションとインスタンスタイプを理解する必要があります。

1. App Engineフレックスと標準：

違いの詳細はこちらにありますが、この質問に関連する1つの重要な違いは次のとおりです。

[標準]は、無料または非常に低コストで実行することを目的としており、必要な分だけ必要なときに支払うだけです。たとえば、トラフィックがない場合、アプリケーションを0インスタンスにスケーリングできます。

2.スケーリングオプション：

• 自動スケーリング：Googleは、提供された需要と構成に応じてアプリをスケーリングします。
• 手動スケーリング：スケーリングはまったく行われません。GAEは、要求したとおりのインスタンス数を常に実行します（非常に誤解を招くような名前付け）
• 基本スケーリング：設定した制限までスケールアップし、一定時間後にスケールダウンします

3.インスタンスタイプ： 2つのインスタンスタイプがあり、基本的に、新しいインスタンスを起動するのにかかる時間が異なります。Fクラスインスタンス（自動スケーリングで使用）は〜0.1秒以内に必要な場合に作成でき、Bクラスインスタンス（手動スケーリング/基本で使用）は〜0.7秒以内で作成できます。

基本を理解したところで、受け入れられた答えに戻りましょう。

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

これがGAEに指示するのは、カスタムインスタンスクラス（よりコストがかかる）を常に実行することです。明らかにこれは最も安価なオプションではありません。代わりにB1 / F1インスタンスタイプを使用でき（スペックが低い）、インスタンスも常に実行されているためです。

何だろう安いと、トラフィックがないときのインスタンスをオフにすることです。〜0.1秒の起動時間を気にしない場合は、代わりにこれを使用できます：

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)

これは、Googleが提供する無料の割り当ての範囲内に収まるため、実際のトラフィックがない場合でも費用はかかりません。

PS：何かを実行しているのを忘れた場合や、どこかに高価な設定がある場合に備えて、1日の支出制限を設定することを強くお勧めします。

また、アプリに自動スケーリングを設定したいが、デフォルトの最小2つのインスタンスを常に実行したくない場合は、app.yamlを次のように構成できます。

runtime: nodejs
env: flex
automatic_scaling:
  min_num_instances: 1

誰も言及していないため、バージョンに関連するgcloudコマンドを次に示します

# 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

少し待機時間を気にしない開発環境では、次の設定を使用しています。

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

また、無料のバックエンドインスタンスの許容量を超えてインスタンスを使用する場合は、次のことを試してください。

instance_class: F1
automatic_scaling:
  max_instances: 1

AppEngineダッシュボードでインスタンスを監視し、開始時刻をメモして、idle_timeout期間が経過した後、インスタンス数がゼロになり、「このバージョンにはインスタンスがデプロイされていません」というメッセージが表示されることを確認します。