アプリリソースの管理

App Engine は、アプリケーションのパフォーマンスとリソース使用率に関する使用状況レポートを生成します。以下に、リソースをより効率的に管理するための方法を示します。詳しくは料金のページをご覧ください。

使用状況レポートを表示する

アプリケーションのパフォーマンスを評価するときには、アプリケーションが実行されているインスタンス数や、アプリケーションによるリソースの消費状況を確認する必要があります。

ダッシュボードに使用状況レポートを表示

[インスタンス] ページを表示

以下のセクションで、リソースを管理する方法をいくつかご提案します。

動的インスタンス スケーリングの管理

レイテンシを短縮する

アプリケーションのレイテンシは、トラフィックの処理に必要なインスタンス数に影響します。レイテンシを短縮できれば、アプリケーションを提供するために使用するインスタンス数を減らすことができます。Stackdriver Trace は、レイテンシに関するデータを確認して、レイテンシを短縮するために見直すべき点を特定できる便利なツールです。

Stackdriver Trace を使用してレイテンシを確認した後、レイテンシを短縮するために次の方法をお試しください。

  • アクセス頻度が高い共有データのキャッシュを大きくする: つまり、App Engine Memcache を使用することを意味します。また、アプリケーションのキャッシュ制御ヘッダーを設定すると、サーバーやブラウザによるデータのキャッシュ効率に大きな影響を与えることができます。数秒間キャッシュするだけでも、アプリケーションによるトラフィック処理の効率に影響を与えられます。Python アプリケーションでもランタイムのキャッシュを利用する必要があります。
  • App Engine Memcache をより効率的に使用する: 取得、設定、削除などの呼び出しを個々に行うのではなく、バッチで呼び出します。Memcache Async API を使用することをおすすめします。
  • リクエストにバインドされない機能にはタスクを使用する: ユーザー対応リクエストのスコープ外で処理できる作業をアプリケーションで実行する場合は、その作業をタスクに入れてください。その作業が完了してレスポンスが返るまで待機するのではなく、その作業を [タスクキュー](/appengine/docs/standard/python/taskqueue)に送信することで、ユーザー側のレイテンシが大幅に短縮されます。タスクキューを使用すると、実行速度をより細かく管理できるようになり、負荷を軽減できます。
  • Cloud Datastore をより効率的に使用する: 詳しくは下記をご覧ください。
  • 複数の URL Fetch 呼び出しを並列化する:
    • 複数の URL Fetch 呼び出しを個々のユーザー対応リクエスト内で個別に処理するのではなく、バッチにまとめ、非同期 URL Fetch を使用して 1 つのオフライン タスクで同時処理します。
    • 非同期 URL Fetch API を使用します。
  • HTTP セッションの場合は、非同期書き込みを行う

自動スケーリングのパフォーマンス設定を変更する

モジュール構成ファイルには、パフォーマンスとリソース負荷のバランスを調整するための 2 つの設定があります。

  • 最大のアイドル状態インスタンス: [最大のアイドル状態インスタンス] を設定すると、App Engine は指定した限度を超えるアイドル状態インスタンスをシャットダウンできるようになります。これにより、割り当てが余計に消費されたり、課金が発生したりすることがなくなります。ただし、アイドル状態のインスタンスが少ないと、トラフィックのスパイクが発生した場合に App Engine のスケジューラが新しいインスタンスを開始しなければならなくなります。その場合、ユーザーに認識されるアプリのレイテンシが増加する可能性があります。
  • 最小保留待ち時間: [最小保留待ち時間] の値を設定すると、リクエストの保留時間が指定した時間を超えるまで、App Engine のスケジューラは新しいインスタンスを開始しません。すべてのインスタンスがビジー状態の場合、ユーザー対応のリクエストはこのしきい値に到達するまで保留キューで待機する必要があります。この設定の値を大きくすると、開始されるインスタンス数は少なくなりますが、負荷が大きい場合にはユーザーに認識されるレイテンシが発生する可能性があります。

Python で同時リクエストを有効にする

Python のアプリケーション インスタンスでは、複数のリクエストを同時に処理することができます。この設定を有効にすると、アプリケーションのトラフィックの処理に必要なインスタンスの数が少なくなります。ただし、この機能が正常に動作するには、アプリケーションがスレッドセーフでなければなりません。app.yaml ファイルでスレッドセーフを有効にして、同時リクエストを利用する方法を確認してください。

タスクキュー設定を構成する

タスクキューのデフォルトの設定はパフォーマンスが高くなるように調整されています。これらのデフォルトの設定では、複数のタスクを同時にキューに入れると、新しいフロントエンド インスタンスが開始されます。インスタンス時間を節約するためにタスクキューを調整する方法の例を以下に紹介します。

  • レイテンシがあまり重要でないタスクに X-AppEngine-FailFast ヘッダーを設定します。このヘッダーは、既存のインスタンスを使用できない場合はすぐにリクエストを止めるようにスケジューラに指示します。タスクキューは既存のインスタンスでリクエストを処理できるようになるまで、再試行とバックオフを実行します。ただし、X-AppEngine-FailFast が設定されたリクエストで既存のインスタンスがすべて使用されている場合は、このヘッダーが設定されていないリクエストによって新しいインスタンスが開始されることがあるので注意してください。
  • タスクキューの設定を構成します。
    • 「rate」パラメータの値を小さくすると、タスクキューによるタスクの実行速度が低下します。
    • 「max_concurrent_requests」パラメータの値を小さくすると、同時に実行されるタスクの数が少なくなります。
  • バックエンドを使用して、タスク実行に使用するインスタンスの数を完全に制御します。動的バックエンドでは push キュー、常駐バックエンドでは pull キューを使用できます。

可能であれば静的コンテンツを提供する

Python で提供される静的コンテンツは専用の App Engine インフラストラクチャによって処理されます。ここではインスタンス時間は消費されません。カスタム ヘッダーの設定が必要な場合は、Blobstore API を使用します。実際の blob レスポンスの提供では、インスタンス時間は消費されません。

アプリケーション ストレージの管理

App Engine は、Cloud Datastore のエンティティのサイズ、Cloud Datastore インデックスのサイズ、タスクキュー内のタスクのサイズ、Blobstore の保管データ量を基にストレージ コストを計算します。次を実行すると、必要以上にデータが保管されるのを防ぐことができます。

  • アプリケーションで不要になったエンティティや blob を削除する。
  • 不要なインデックスを削除してインデックス ストレージ コストを削減する(次の Datastore の使用量の管理に関するセクションをご覧ください)。

Cloud Datastore の使用量の管理

App Engine は、Cloud Datastore で実行されたオペレーションの数を記録しています。次の方法により、Cloud Datastore のリソース消費量の削減と、Cloud Datastore へのリクエストのレイテンシ短縮を実現できます。

  • GCP Console のデータビューアには、ローカル Cloud Datastore で各エンティティの作成に必要とされた書き込みオペレーションの数が表示されます。この情報を基に、各エンティティの書き込みコストを把握できます。このデータの解釈方法については、書き込みコストについてをご覧ください。
  • 不要なインデックスを削除します。これにより、ストレージ コストとエンティティの書き込みコストが削減されます。インデックスの取得機能を使用して、アプリケーションでどのインデックスが定義されているか確認してください。現在アプリケーションに提供されているインデックスは、GCP Console の [検索] ページで確認できます。
  • データモデルの設計時に、カスタム インデックスを完全に除外するようにクエリを作成できます。App Engine によるインデックスの生成方法については、クエリとインデックスのドキュメントをご覧ください。
  • 可能であれば、インデックスありのプロパティ(デフォルト)をインデックスなしのプロパティに置き換えます(Python)。これにより、エンティティ挿入時のデータストア書き込みオペレーションの数を削減できます。後でそのインデックスなしのプロパティに対してクエリを実行する必要が生じた場合には、インデックスありのプロパティを使用できるようにコードを再修正するだけでなく、すべてのエンティティに対して map reduce を実行して再挿入する必要があるので注意してください。
  • App Engine 1.5.2 および 1.5.3 リリースでは Cloud Datastore クエリ プランナーの機能が改善されたため、クエリに必要なインデックスの数が以前より少なくなっている可能性があります。パフォーマンス上の理由で一部のカスタム インデックスを引き続き使用することにした場合でも、それ以外のカスタム インデックスを削除してストレージ コストとエンティティの書き込みコストを削減できる可能性があります。
  • データモデルを再構成して、クエリをキーによるフェッチに置き換えます。このほうが低コストで効率的です。
  • 可能であれば、エンティティ クエリではなくキーのみのクエリを使用します。
  • レイテンシを短縮するために、複数のエンティティの get() をバッチ get() に置き換えます。
  • ページ分割にはオフセットではなく Cloud Datastore カーソルを使用します。
  • 複数の Cloud Datastore RPC を非同期データストア API で並列化します。

注: 小規模な Cloud Datastore オペレーションには、Cloud Datastore ID を割り当てるための呼び出しや、キーのみのクエリなどがあります。コストについては、料金ページをご覧ください。

帯域幅の管理

送信帯域幅の使用量を抑える方法の 1 つとして、可能であれば、レスポンスに適切な Cache-Control ヘッダーを設定し、静的ファイルに妥当な有効期限を設定します。このようにパブリック Cache-Control ヘッダーを使用すると、プロキシ サーバーとクライアントのブラウザで指定の期間にわたってレスポンスをキャッシュできます。

受信帯域幅はユーザーがアプリに送信するデータ量であることから、制御は困難です。ただし、DoS 防御サービスを利用すれば、不正と思われる IP からのトラフィックをブロックできます。

その他のリソースの管理

Email API の使用状況を確認する最善の方法の 1 つとして、Appstats を使用して、必要以上に呼び出しをしていないか確認する方法があります。エラー率を確認し、無効な呼び出しをしていないか確認することは常に重要です。場合によっては、そのような呼び出しを早期に検出することも可能です。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Python 2 の App Engine スタンダード環境