Google App Engine は、 Google の提供する PaaS (Platform as a Service) です。
App Engine - 任意の言語でスケーラブルなウェブ バックエンドやモバイル バックエンドを構築 | App Engine | Google Cloud
App Engine の環境
App Engine にはインフラも含めてGoogleが管理する Standard Environment と、Compute Engine上で実行する Flexible Environment があります。本稿では、 Standard Environment を利用している場合について述べます。
App Engine Standard Environment のスケーリング設定
App Engine のスケーリング設定は app.yaml に記述します。詳細は公式ドキュメントを参照してください。
app.yaml リファレンス | Python 2 の App Engine スタンダード環境 | Google Cloud
本稿では、 automatic_scaling を利用している場合のチューニング観点について述べます。
初回リクエストに対する反応が遅い
min_idle_instances の値を 1 以上に設定しましょう。
アクセスが間欠的なサービスの場合には、インスタンスが存在しない状態になっている場合があります。インスタンスが存在しない状態での初回リクエストでは、インスタンス作成されてリクエストが処理されるまで、応答が遅延することになります。
そのような間欠的なリクエストを受けているサービスの場合には、この設定をすることによって、常に待機インスタンスが存在している状態になるので、「初回リクエストでのインスタンス起動待ち」に遭遇する可能性を減らすことができます。
App Engine では一定数のアイドル インスタンスが常に確保されるため、異常なほど負荷が急増した場合を除き、リクエストが保留中のキューに入る可能性は低くなります。
アプリケーションの構成によって、リクエスト処理可能になるまでの時間に幅があると思います。リクエスト処理可能になるまでの時間が長い場合にはある程度多めのインスタンスを用意しておくことが、パフォーマンスの改善に役立つでしょう。
料金の見積もり
min_idle_instances を 1 以上に設定した場合、常時稼働分のインスタンス料金が課金されます。
App Engine の料金 | App Engine ドキュメント | Google Cloud
例えば、 us-central1 リージョンにおいて、 F2 インスタンス利用しているときに、 min_idle_instances=2 を設定した場合を考えてみましょう。
2台のF2インスタンスが24時間起動しているので、 F1 インスタンスに換算すると 2(台) * 2 (F2のF1換算) * 24(時間) = 96インスタンス時間 となります。ここから、1日あたり 28インスタンス時間 は無料の割り当てがあるので差し引くと課金対象となるのは 68インスタンス時間 となります。
割り当て | App Engine ドキュメント | Google Cloud
月あたりの課金額目安は 68インスタンス時間 * $0.05/インスタンス時間 * 30日 = $102/月 となります。
サービス利用中の途中でリクエストに対する反応が遅い
max_idle_instances に大きめの値を設定しましょう。
SPA (Single Page Application) を利用しているような構成では、操作時に多数のリクエストが断続的に発生することがあります。
これは、多数のリクエストによってスケールアウトして作成されたインスタンスが、速やかにスケールインすることによって、インスタンスの不足が発生していることに由来します。
サービスの利用途中でリクエストが詰まるような現象が発生する場合には、 max_idle_instances を明示的に大きめの数値に設定することで回避できる可能性があります。
最大数を大きく設定すると、負荷レベルの急増後に通常のレベルに戻る際に、アイドル インスタンスの数がより緩やかに減っていきます。その結果、アプリケーションがリクエスト負荷変動の前後を通じて安定したパフォーマンスを維持しやすくなる一方で、そのような負荷の高い期間のアイドル インスタンスの数（その結果としてランニング コスト）も増えます。
料金の見積もり
max_idle_instances に設定した値は、エンドユーザからのリクエスト等によってインスタンスがスケールアウトした際にのみ意味を持ちます。
逆に、全くリクエストがない場合に max_idle_instances を 1000 に設定したとしても課金は発生しません。
max_idle_instances に大きな値を設定した場合、その台数までインスタンスがスケールアウトしたときにそのインスタンス台数が継続する期間が長くなります。
- リクエストが全くない状態で、
min_idle_instancesの台数だけインスタンスが存在する - 多数のリクエストによってスケールアウトが行われる
- スケールアウトの結果
max_idle_instancesを超える台数までインスタンスが作成される - リクエストが落ち着くと、速やかに
max_idle_instancesの台数までスケールインが行われる - リクエストが落ち着いている期間が継続すると、緩やかに
min_idle_instancesの台数までスケールインが行われる - インスタンスの台数は
min_idle_instancesに収束する (1. に戻る)
このパラメータによって増加する課金額は、上記の流れの 4. から 5. にかけて、緩やかにスケールインする期間のインスタンス稼働時間に対応します。
まとめ
パフォーマンス・チューニングは対象のアプリケーション特定によっても異なる部分が多いですが、少しでも参考になれば幸いです。