web-dev-qa-db-ja.com

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などのJVMを使用する言語、Scalaなど））

  4. サーバーの問題

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

この質問について私を困らせているのは、あなたがそれを言い表して、決定的な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インポートを使用できます（また、間違っている可能性もあります）。

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

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

28
Calvin

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

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

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

14
Drew Sears

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

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

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

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

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

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

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

3
Dean Harding

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

0
Jon K