パラメータを設定して、Google App Engine の請求額を削減しようとしていautomatic_scalingます。平均して、私のアプリでは 7 ～ 10 個のインスタンスが実行されており、そのうち 2 ～ 3 個はアイドル状態です。しかし、添付のグラフの午前 3 時から午前 6 時の間のように、アクティブなインスタンスとアイドル状態のインスタンスの差がとてつもなく大きい場合があります。また、アクティブなインスタンスの数を減らして、最終ユーザーの応答時間を増やしたいと考えています (設定min_pending_latencyとmax_pending_latency)。しかし、これまでのところ、これらの設定はどれも効果を発揮していません。
これは私の app.yaml 構成です:
automatic_scaling:
min_pending_latency: 250ms
max_pending_latency: 750ms
max_idle_instances: 2
と の両方min_pending_latency を max_pending_latency設定すると、混合メッセージがオートスケーラーに送信されます。
より一般的には、オートスケーラーを微調整して、コストを抑えるかmax_idle_instances( に低い値を設定するか、高い値を設定するmin_pending_latency)、またはスケーラビリティを向上させます。つまり、トラフィックの急増に対してレイテンシを低く保ちます (高い値を設定します)。および/またはのmin_idle_instances低いものmax_pending_latency)。
2 種類の微調整を混ぜないでください。私の経験では、そのような「混合メッセージ」は、コストやサージ中のレイテンシーに良い影響を与えることは決してありません。
はい、私はこの基本的な情報を Google Cloud Platform の公式ドキュメントの一部にするために取り組んでいます。思ったよりも時間がかかっているため、この回答を投稿しています。
時間の経過に伴うトラフィックのパターンや急増の可能性などについて非常に確信がある場合は、より高度な代替手段として、自動スケーリングされたモジュールから基本スケーリングまたは手動スケーリングのモジュールに切り替えて、独自のコードを記述します。Modules APIを介してインスタンスを開始および終了します。
とはいえ、(タスクキューや cron ベースの「バックエンド」作業とは対照的に) ユーザー トラフィックの処理専用のモジュールでは、これが最適に機能したことはありませんでした。ユーザーの急増と時間パターンは決して予測可能ではありませんでした。過去の記録を分析すると、興味をそそられるように示唆されました。そのため、最終的には、(ユーザー トラフィック サービスのために) 常に古き良き自動スケーリングに戻りました。おそらく、上で推奨したように、コストを削減するため、またはスケーラビリティを向上させるために、ささやかな微調整を行いました。