高速でスケーラブルなアプリケーションの作成方法-これについては、この記事で説明します。
前述のすべては、主にJavaで記述されたアプリケーションに関連していますが、ほとんどの場合、Pythonで記述されたアプリケーションに当てはまります。
一秒
Google App Engineでは、各アプリケーションが1秒あたり最大500リクエストを処理できますが、これは各リクエストの平均時間が1秒以下である場合のみです。 そうしないと、非効率的なアプリケーションが制限され、負荷が比較的小さい場合でも、一部のリクエストがHTTP 500エラーで失敗し始めます。
残念ながら、Googleはリクエストを実行するための平均時間を計算する方法を開示していません。したがって、アプリケーションが「不利にならない」ことを保証するために、例外なくアプリケーションへのすべてのリクエストが1秒以内に完了することを保証する必要があります。
「長い」リクエストなしで実行できない場合は、それらの出現頻度（高速リクエスト間の「汚れ」）を最小限に抑え、アプリケーションが制限を受けないことを実験的に検証する必要があります。 システムによって制限が徐々に課され、削除されることを覚えておく必要があります。
30秒
App Engineのデータストレージにより、アプリケーションは分散アーキテクチャのために膨大な量のデータを効率的に処理できますが、平均して、ストレージでの3,000の操作のうち1つがタイムアウトになります。 このような操作は自動的に繰り返されますが、数回繰り返しても操作を完了できなかった場合、アプリケーションがHTTP 500エラーで終了するハンドラがない場合、DatastoreTimeoutExceptionがスローされます。
処理に1秒もかからない高速クエリの場合、自動再試行によりDatastoreTimeoutExceptionの頻度が減少します。 リポジトリを集中的に使用する「長い」リクエストの実行中は、例外がスローされる可能性が非常に高くなります。 多くの場合、このようなリクエストは通常、DeadlineExceededExceptionで終了します。繰り返しに対する失敗した「重い」アクセスが何度も繰り返されると、アプリケーションはリクエストの処理に割り当てられた30秒のタイムアウトを使い切る可能性があるためです。
アプリケーションは両方の例外をキャッチして処理できますが、依然として最善の解決策は、「重い」リクエストを完全に取り除くことです。たとえば、そのような各リクエストをいくつかのより軽いリクエストに分割します。 これにより例外が完全に排除されるわけではありませんが、例外は非常にまれなイベントになります。
毎秒10回
リポジトリ内のすべてのオブジェクトは、何らかのエンティティグループに属します。 各グループには、依存関係が定義されているオブジェクトが含まれます。 他のオブジェクトから独立したオブジェクトは、それ自体で構成されるグループに属します。 オブジェクトグループは、App Engineが関連オブジェクトを分散ストレージに一緒に格納するのに役立ちます。
分散ストレージアーキテクチャを使用すると、オブジェクトが異なるグループに属している場合のみ、オブジェクトと操作を並列化できます。 同じグループに属するオブジェクトの場合、1秒あたり10回までの書き込み操作がサポートされます。
アプリケーションへの2つの要求が、同じオブジェクトの同じグループに属する1つまたは複数のオブジェクトを同時に変更しようとすると、少なくとも1つの書き込み操作が失敗します。
衝突が発生します。 エラー操作は自動的に再試行されます。 ただし、何度か再試行した後も衝突が引き続き発生する場合、アプリケーションはDatastoreTimeoutExceptionによって中断されます。
アプリケーションを設計する際には、オブジェクトのグループへの結合方法、およびアプリケーションのユーザー数の増加を考慮に入れて、各オブジェクトが変更される頻度を明確に理解する必要があります。 アプリケーションを適切に拡張するには、オブジェクトの小さなグループに準拠する必要があり、頻繁に更新されるデータにはシャーディング手法を使用する必要があります。
まとめ
Google App Engineを使用すると、高負荷でも大量のデータでも確実に動作するアプリケーションを簡単に作成できますが、アプリケーションへのリクエストが迅速に実行され、データがストレージと小さな部分で交換され、データ自体が小さなオブジェクトのグループに編成されている場合のみです。
アレキサンダーオンハブレ- 風変わり