GAEは、何百万ものアクティブユーザーが使用するアプリをホストできるインフラストラクチャですか？

下記のGAEの制限について知りたいのですが、GAEでそのアプリをホストすることで、Facebookなどの優れたソーシャルアプリを構築することもできますか？

言い換えれば、GAEは6億人のアクティブユーザーが使用するアプリをホストできるインフラストラクチャですか？

制限事項：いくつかのフォーラム/ブログから出てきました（不足しているものがあれば、リストに追加してください）。

1. HTTPリクエスト/レスポンス

   • 最大リクエストサイズ：32 MB
   • 最大応答サイズ：32 MB
   • すべてのリクエストは30秒以内に応答する必要があります。そうでない場合、GAEはDeadlineExceededExceptionをスローします
   • 各cronジョブは10分以内に実行する必要があります
   • cronジョブはマップ削減を利用できません
   • 別のサイトへのすべてのGETまたはPOSTは、5秒後に中止されます。最大10秒まで待機するように設定できます。（TwitterやFacebookと何度も連携するには中間サーバーが必要です）
   • クライアントはFTPを介してGAEに接続できません（HTTPおよびHTTPSのみ）。
   • カスタムドメインのhttpsはありません。your-app-id.appspot.comドメインの場合のみ。
   • ユーザーの流入が発生すると、「割り当て超過」エラーが発生します

2. データベース

   • ローカルの開発におけるデータベースの動作は、実際のサーバーの場合と同じではありません。
   • GQL。他には何もありません。
   • クエリで1000件を超えるレコードを取得することはできません（クライアントに「ワンクリックゴーオフラインナウ」ボタンを許可したい場合は真剣に考えます）。
   • 操作を実行するために大量のレコードへの線形アクセスが必要な場合は、運が悪い（Googleのシステムは大規模にクラスター化されている）
   • Memcache値の最大サイズは1 MBです。
   • 単純なテキスト検索はできません
   • 2つのテーブルを結合することはできません。
   • 遅い（継承を使用してテーブルを分離する方法について読んで、テーブルを検索し、キーを取得してから、親を取得して、逆シリアル化のパフォーマンスを回避する必要があります）
   • 「インデックスが多すぎます」ランタイム例外
   • エンティティは、インデックス内に最大5000個のプロパティ値を持つことができます
   • *という形式のキー名（2つのアンダースコアで開始および終了）は予約されているため、アプリケーションで使用しないでください。
   • キー名は500バイトに制限されています（UTF-8でエンコードされていると思います）。

3. 言語

   • pythonまたはjavaまたはGo（またはGroovy、ScalaなどのJVMを使用する言語）

4. サーバーの問題

   • 静的IPなし（サードパーティAPIの呼び出しでスロットルと割り当ての問題が発生する可能性があります）
   • 各アプリケーションは3000ファイルに制限されています
   • Webアプリを実行するOSまたはハードウェアの制御なし

この質問について私をいらいらさせるのは、あなたがそれを語り、最終的なnoを集めようとして「事実」をロードしたということです。

真実は、Facebook、Twitter、またはTumblrの機能を複製するApp Engineアプリを開発できることです。また、アプリが適切に作成されていると仮定すると、数億人のユーザーをサポートするように拡張されます。望まない主な理由（これは考慮事項ではないようです）は、App Engineでそのサイズのサービスを実行するコストです。

また、あなたがリストした制限のどれがあなたがそのようなアプリを開発するのを妨げるのかを見ることもできません。

1. HTTPリクエスト/レスポンス

   • 最大リクエストサイズ：10 MB-不適切、32MBに引き上げ。
   • 最大応答サイズ：10 MB-不適切、32MBに引き上げ。

   -10MBを超えるページを頻繁に配信する必要があるソーシャルアプリを開発している場合、おそらくそれは間違っています。また、32MBを超えるコンテンツを配信する必要がある場合は、最大2GBのファイルにブロブストアを使用できます。

   • ファイルシステムにアクセスできません。（アップロードをファイルシステムに保存することを忘れてください）-間違っています。ローカルファイルシステムから読み取ることができ、ブロブストアにファイルをアップロードおよび読み取り/書き込みできます。

   -Facebook、Twitter、またはTumblrがユーザーのアップロードを取得してフォルダーにコピーするだけの方法はありません。問題ない。

   • すべてのリクエストは10分以内に応答する必要があります。そうでない場合、GAEはDeadlineExceededExceptionをスローします-間違っています。実は30秒です。

   -ユーザーのリクエストに結果を提供するために30秒を超える時間が必要な場合は、おそらく間違っています。

   • 各cronジョブは30秒以内に実行する必要があります-間違い、10分です。

   -長いタスクを10分のチャンクに分割できない場合、A：おそらくそれは間違っている、そしてB：リクエストに時間制限のないバックエンドインスタンスにそのタスクを移動できるようになりました。

   • cronジョブはマップ削減を利用できません。マップ削減を使用したことはありませんが、これには引用が必要だと思います。

   • 別のサイトへのすべてのGETまたはPOSTは、5秒後に中止されます。最大10秒まで待機するように設定できます。（TwitterやFacebookと何度も連携するには中間サーバーが必要です）-はい。

   -外部APIへのユーザー向けのリクエストに10秒以上かかる場合は、とにかくユーザーに再試行するように伝えることをお勧めします。ユーザー向けのリクエストでない場合は、APIが応答するまでタスクを自動的に再試行できます。

   • クライアントはFTPを介してGAEに接続できません（HTTPおよびHTTPSのみ）。-真

   -これはなぜ問題なのですか？FTP経由で変更を展開している大企業はあると思いますか？

   • カスタムドメインのhttpsはありません。your-app-id.appspot.comドメインの場合のみ。-そうです。

   -それはロードマップにも載っています。

   • ユーザーの流入が発生すると、「割り当て超過」エラーが発生します。

   -アプリの予算を適切に設定すれば、割り当て超過エラーは発生しません。Royal WeddingサイトはApp Engineでホストされ、1秒あたり32,000件のリクエストを受け取りました。割り当て超過エラーはありません。また、Twitterで失敗したクジラを見たり、Tumblrで容量超過エラーを確認したりしたことはありますか？これは基本的に、割り当て超過エラーです。

2. データベース

   • ローカルの開発におけるデータベースの動作は、実際のサーバーの場合と同じではありません。-誤り

   -ラップトップでのデータストアの実行がApp Engineのクラスターでの実行よりも遅い場合は、trueであり、それ以外の場合はまったくtrueではありません。

   • GQL。他には何もありません。-誤り

   -ほとんどの開発者は、dbフィルターを使用してデータストアをクエリします。さらに、MySQLでは「SQL。他には何も許可されない」と同じように言うことができます。

   • クエリで1000件を超えるレコードを取得することはできません（クライアントにワンクリックゴーオフラインナウボタンを許可する場合は真剣に考えます）-False。

   -1000レコードの制限はずっと前に解除されました。さらに、レンダリングに1000以上のレコードが必要なFacebook、Twitter、またはTumblrのユーザー向けページを表示します。

   • 操作を実行するために大量のレコードへの線形アクセスが必要な場合は、運が悪い（Googleのシステムは大規模にクラスター化されている）

   -ここで何を取得しているのかさえわかりません。ほとんどの人は、Googleの大規模なクラスターの速度をシステムの大きな利点と見なしています。

   • Memcache値の最大サイズは10 MBです。-実際には、他のすべてのmemcache実装と同じように、memcacheエントリごとに1MBです。

   • 単純なテキスト検索を実行できません-True。

   -それはデッキにある機能です。ほとんどの大規模なサイトは、独自のテキスト検索インデックスを作成しません。

   • 2つのテーブルを結合することはできません。-そうです。

   -App Engine開発者は、単一の大規模なマルチ結合SQLクエリからいくつかの小さな個々のクエリに思考を調整するか、結合が不要になるようにデータを非正規化する必要があります。

   • 遅い（継承を使用してテーブルを分離する方法について読んで、テーブルを検索し、キーを取得してから、そのシリアル化を回避するためにその親を取得する必要があります）-???

   -翻訳/引用が必要です。

   • 「インデックスが多すぎます」ランタイム例外-True

   -1つのアプリ内のインデックスの数には制限があります。しかし、学術研究のアプリケーションがそれにヒットするのを見ただけです。

   • エンティティは、インデックス内に最大5000個のプロパティ値を持つことができます-True

   -したがって、誰かが5000人を超える友達を持っている場合、友達グループに2つのエンティティが必要になります。

   • フォームのキー名__*__（2つのアンダースコアで開始および終了）は予約されているため、アプリケーションで使用しないでください。-真

   -しかし、何ですか？

   • キー名は500バイトに制限されています（UTF-8でエンコードされていると思います）-True

   -繰り返しになりますか？キー名は小説を保存するためのものではなく、エンティティを一意に識別するためのものです。

3. 言語

   • pythonまたはjavaまたはGo（他のものはこれらの言語に翻訳する必要があります）-真実

   -実際には、PHPやJRubyなど、JVMで実行される任意の言語も実行できます。なぜそれが問題なのかはわかりませんが、PythonとJavaは2つの強力な言語であり、多くの利用可能なツール、チュートリアル、経験豊富なプログラマーがいます。

4. サーバーの問題

   • 静的IPなし（サードパーティのAPIを呼び出すスロットリングと割り当ての問題）-真実

   -ほとんどのサードパーティAPIはApp Engineを認識しているか、Googleと関係があります。TwitterがApp Engineを誤ってブロックしたことが数回あり、数時間以内に修正されます。

   • 各アプリケーションは3000ファイルに制限されています-真実

   -Webアプリケーションに3000を超えるコードファイルが本当に必要な場合は、zipインポートを使用できます（また、間違っている可能性もあります）。

   • Webアプリを実行するOSまたはハードウェアの制御なし-True

   -App Engineはサービスとしてのプラットフォームです。OSやハードウェアの保守について心配する必要がないことは、人々がお金を払っているところです。これは、App Engineの主な利点であり、制限ではありません。

いいえ、App Engineは6億人のアクティブユーザーがいるアプリには適していません。

現実的には、この大規模なアプリは、独自のデータセンターの高度にカスタマイズされたインフラストラクチャで実行されます。そのようなアプリをGoogleでホストすることはおそらく可能ですが、販売チームと直接協力してソリューションを設計します。上にリストしたサンドボックスの制限は、長い間無関係でした。

始めたばかりの場合、Facebookと同じくらい人気になると想定して設計するのはばかげています。これほど大きくなったアプリは、段階的にリファクタリングを繰り返しながら実行します。最初に、6億人のユーザーを引き付ける機能の設計について心配します。増加するユーザーベースをサポートするように実装を再設計することは、比較すると、ささいな問題です。

そのFAQのポイントはいくつかの主要な分野に分類されると思います。

まず第一に、デメリットではなく、実際にスケーラビリティの利益になるポイントがあります。非常にスケーラブルなアプリケーションでは、すべてのリクエストが他のリクエストからほぼ独立していること、およびすべてのリクエストが同じ「サイズ」（CPU使用率、メモリ、ネットワークなどの点で）であることを確認することを目指しています。

このようにして、同じノードで小さなリクエストが不足する「大きな」リクエストのグループを心配することなく、リクエストをクラスター内のノード間で簡単に分散できます。これにより、メンテナンス、パフォーマンス、信頼性の点でインフラストラクチャがシンプルになります。

したがって、それは次のようなものをカバーします：

• 最大リクエスト/レスポンスサイズ
• リクエストの応答時間
• 外部リクエストの応答時間制限
• Memcacheの最大サイズ（実際、memcacheのデフォルトのビルドでは、最大値サイズは1 MBであるため、Googleはその制限を10倍に増やすカスタムバイナリを実行しています）
• 最大データベース応答サイズ（つまり、1,000行の制限）
• 等

2番目のカテゴリは、単に古くなっているものです。

• Google GoがApp Engineの言語として利用できるようになりました。高性能言語に関しては、Goよりもはるかに優れているわけではありません。本当にこれが好き
• データストアは失敗する可能性があります- 高レプリケーションデータストアでは当てはまりません（明らかにmemcacheは失敗する可能性がありますが、これは単なるキャッシュです）
• ファイル数の制限は1,000ではなく3,000です

さて、GoogleがcronジョブがMap Reduceを利用できるようにインフラストラクチャを開放し、データセット全体に対してクエリを実行できるようにしておくとよいでしょう。しかし、6億人のユーザーのかなりの部分でさえ、あなたはすでにGoogleの非常に大きな顧客になり、いずれにしても、App Engineで利用可能なものよりも多くのオプションを持つことになります。

100人、さらには600、、000,000人のユーザーをも引き付けるアイデアを思いついた場合、ベンチャーキャピタルと技術チームがあり、それを開発してインフラストラクチャで実行することができます。また、その場合は、GoogleがすべてのGAEアプリのソースコードにアクセスする必要があるため、GAEが提供しない知的財産も保護する必要があります（とにかく、PythonおよびJavaコードを実際に保護することはできません）。
GAEは、ITインフラストラクチャのコストをなくし、コードIPを保護する必要がなく、データのみを保護する必要がある企業に適しています。