Google App Engineでアプリを構築するのに良い経験があります。この最初のアプリのターゲットオーディエンスは、Google Appsユーザーであるため、Googleインフラストラクチャでホストされているという点で問題はありません。
私たちはそれを別のアプリで使用することを調査したいのでとても気に入っていますが、この次のプロジェクトは、それがどのテクノロジーにあるのかあまり興味がなく、ただそれが機能することを望んでいるクライアントのためのものです。時間。
このシナリオでは、テクノロジーの適用性と機能の側面がカバーされていることを考えると、このようなものはまだ比較的新しいものであり、従来のホスティングで行った場合ほど「制御」されていない可能性があるという懸念はありますか？
あなたは正しいです：あなたは従来のホスティングと比べてそれほど多くのコントロールを持っていません。ただし、うまくいけば、ゲインがネガを上回ります。AppEngineは非常にスケーラブルです。Google自体を実行するのと同じハードウェアで実行されます。どのくらいの頻度でhttp://google.comにアクセスし、そのページまたは検索結果が失敗しましたか？
あなたはGoogleにあなたのコードを実行させていますが、それでもあなたが好きなようにコードを実行することができます。django-nonrelのような新しいプロジェクトでは、ネイティブDjangoアプリをApp Engine上で直接作成して実行できます。それが将来のニーズを満たさない場合は、そのアプリをDjangoアプリをホストするISPに簡単に持ち込むことができます。 （そしてそれらはたくさんあります）。このプロジェクトの詳細については、以下をご覧ください。
ハードウェア、オペレーティングシステム、マシンイメージの作成、データベース、Webサーバー、フロントエンドロードバランサー、CDN /エッジキャッシング、ソフトウェア/パッケージのアップグレード、ライセンス料などについて心配する必要はありません。特定の問題を解決するために作成している、または作成する予定のWebまたはその他のアプリケーションに接しています。好むと好まざるとにかかわらず、この追加のインフラストラクチャはすべて必要です。ただし、App Engineを使用すると、アプリ/ソリューションについて考えるだけでよく、このような余分なことは何も考えられません。
明らかに、失うもう1つのことは、実行環境の一部です。クラウドネイバーとうまく連携するには（リソースの占有、セキュリティの問題など）、サンドボックスで実行する必要があります。つまり、アプリはローカルファイルを作成したり、ネットワークソケットを開いたりすることはできません。ただし、AppEngineには少なくとも意味のあるアプリを作成できるようにするための豊富なAPIと製品機能のセット：
また、完全なダッシュボード管理コンソールがあり、アプリの使用状況、課金設定と履歴、割り当て使用量の完全なダンプ、さらには表示またはダウンロードできるアプリケーションログを監視できます。
@Anuragの「主な問題点」に対処するには：
1a。無料の割り当てはかなり寛大です...月に500万ビューを取得するWebサイトを強化するのに十分です。また、Googleがクレジットカードを提供することを信頼している場合、彼らは無料の割り当てレベルをさらに高くします。割り当てページを見て、「無料のデフォルト割り当て」列と「請求が有効なデフォルト割り当て」列の両方の数値を参照してください...ここにいくつかの例があります：a）リクエスト数：デフォルト1.3MM、請求有効43MM（ wBE）、b）データストアAPI呼び出し：デフォルトで10MM、140MM wBE、c）URLフェッチ：デフォルトで657K、wBEで46MM
1b。リクエストの最大30秒：アプリが他のユーザーと遊び場にあるため、これはセキュリティが強化されます。Googleは、すべてのクラウドネイバーが互いにうまく機能し、CPUを占有しないようにする必要があります。ただし、App Engineチームは、より長く実行されるバックグラウンドタスクを可能にする方法に取り組んでいます...まだスケジュールはありませんが、公開ロードマップにあります。
1c。App Engineでチャットサーバーを作成することは可能であるだけでなく、非常に簡単です。これは、AppEngineのXMPPAPIを使用して作成されたものです。これはかなり馬鹿げており、送信者が送信した内容を送信者にエコーバックします（ユーザーをチャットに招待している必要があることに注意してください）。
from google.appengine.api import xmpp
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
class XMPPHandler(webapp.RequestHandler):
def post(self):
msg = xmpp.Message(self.request.POST)
msg.reply("I got your msg: '%s'" % msg.body)
application = webapp.WSGIApplication([
('/_ah/xmpp/message/chat/', XMPPHandler),
], debug=True)
def main():
run_wsgi_app(application)
if __name__ == '__main__':
main()
1d。公開ロードマップのもう1つの項目は、将来の「ブラウザプッシュ（Comet）通信の[サポート]」であるため、これも予定されています。
2a。「SQLではない」は、GoogleAppEngineの最大の強みの1つです。リレーショナルデータベースは拡張性がなく、RDBMSが倒れないように、ある時点でシャーディングする必要があります。ただし、従来の方法ではないため、移植が少し難しいのは事実です。Google Bigtableに基づくと、 AppEngineデータストアはスケーラブルな分散オブジェクトデータベースと考えることができます。App Engineを使用すると、Queryオブジェクトモデルを使用してデータストアにクエリを実行できます。または、必要に応じて、 SQLのようなGqlQueryインターフェイスも提供します。
2b。django-nonrelのような新しいアバンギャルドプロジェクトでは、Djangoアプリを作成してそのORMを使用すると、純粋なDjangoアプリを取得して、AppEngine上で直接実行できます。同様に、App Engineから切り離して、Djangoアプリケーションをホストする従来のISPベンダーに直接移動することもできます。クエリはまったく同じであり、SQLを実行するかどうかを気にする必要はありません。
3a。長時間実行されるプロセスは、上記の1bですでに対処されています。Googleはこの必要性を認識しており、それに取り組んでいます。
3b。TaskQueue APIは100kの呼び出しをサポートしますが、それは1MMwBEにぶつかります...そしてこれは毎日です。
3c。Googleでは、タスクを複数のサブタスクに分割することを強くお勧めします。低レイテンシのアプリは「システムを占有」しないように見え、低速でクラウドネイバーからより多くのリソースを消費するアプリよりも優れた処理が行われます。
はい、従来のホスティングほど制御できません。GAEの主な痛い点は
クォータなど、リクエストの場合は最大30秒なので、コメット/リバースajaxなどがウィンドウの外にあるか非常に困難です。GoogleAppEngineでチャットサーバーを作成してみてください。
SQLデータベースではないため、必要に応じて他のサーバーに移植するのは困難であり、Googleデータベースには制限がある場合があります。たとえば、並べ替えられた列以外の別の列で比較できるクエリを並べ替えてみてください。
長時間実行されるプロセスにはタスクAPIがありますが、長時間実行されるバックグラウンド処理を実行する場合はそれだけでは不十分です。そうしないと、タスクをサブタスクに分割する必要があるため、状況が複雑になり、1つあたりのタスク数にも割り当てがあります。実行できる秒。
GAEは、バックグラウンド処理をほとんど行わずに、アプリを要求/応答レジストリとしてモデル化できる場合に適しています。
これも参照 してくださいGoogleAppEngineの使用に関するフィードバック？