4

成長しているように見える小さなGoogleAppEngineサイトがあり、別の場所に移行したいと考えています。

これは、Java / Stripes Framework / Objectifyに基づいており、GoogleサービスのURLFetchのみを使用します。現在、最大60のフロントエンド時間と最大4 GBのデータストアを使用しており、1日あたり最大5,000の訪問者が最大25kのページビューを実行しています。

移行する必要があると思う理由：

  • 私は早い段階でいくつかの仮定をしましたが、それはもはや有効ではなく、1MBのmemcache/datastoreの制限に達しています。これをリファクタリングすることはできますが、データストア操作の数が増える/全体的にパフォーマンス特性が悪化し、データベース変換ステップが必要になる可能性があります（これを使用して別の場所に移行することもできます）
  • 保存されたデータ（約100 GB）とフロントエンド時間の大幅な増加を伴ういくつかの機能を追加したいと思います
  • 無料の割り当てを超えてリソースを使用しているため、コストの増加は非常に速く上昇しているようです。今ではかなり扱いやすくなっていますが、アプリケーションの人気が高まると、もう手頃な価格ではなくなるのではないかと思います。
  • いくつかの安定性の問題（説明できないOutOfMemoryErrorsやその他のエラーが発生し、ローカル環境でうまく再現できない）

私は次のオプションを評価しています：

  1. GAEにとどまり、アプリケーションを最適化し、増大するコストに対応します（短所：依然として高いコストと信頼性の問題があります）

  2. データストアとしてMongoDBを使用するAWSEC2/ EBSへの移行（長所：おそらく最も成熟したソリューション、短所：セットアップが難しく、アーキテクチャ/設計の間違いを犯しやすいようです）。

  3. Appscaleを使用して、アプリケーションの大部分をそのままにしておきますが、AWS EC2でホストします（長所：紙の上では簡単に思えます、短所：主にUnix開発環境を想定しているようです、本番環境の準備ができているかどうか、または舞台裏で何が起こっているのかわかりません）

  4. CloudFoundry.comをMongoDBとともにデータストアとして使用します（短所：本番環境に対応しているかどうかはわかりませんが、ベータ後のコストは不明です）

  5. VPSまたはホスティングプロバイダーを備えた専用サーバーを入手し、MongoDBをデータストアとして使用してデプロイします（短所：おそらく、他のオプションよりも学びたいことを少なく、多くのsysadminingを実行することを教えてくれます）

趣味のサイトなので、実際にいくつかの新しいテクノロジーを学ぶことも目標の一部です。適切なテクノロジーを学ぶことに時間を費やしたいと思います。

注-私は、特にLinuxで、いくつかの、しかし非常に限られたシステム管理スキルを持っており、それを行うことを楽しんでいません。私は以前にMongoDBで小さなプロジェクトを行ったことがあります（ただし、本番環境には入れませんでした）。AWSインフラストラクチャを使用したことはありません。

私の質問：

a。AppScaleは、面倒な作業（バグ、ドキュメントの不足など）なしで小さなWebサイトを実行するために十分に成熟していますか？学習曲線は非常に急ですか？シナリオ＃3でそれを使用するシステム管理にはどのくらい必要ですか？そして最も重要なのは、Google 1MBなどの制限がすべてAppScaleにあることを正しく理解していますか？

b。CloudFoundryは、面倒なこと（バグ、ドキュメントの欠如など）なしで小さなWebサイトを実行するために十分に成熟していますか？学習曲線は非常に急ですか？シナリオ＃4でそれを使用するシステム管理にはどのくらい必要ですか？CloudFoundry.comから別のCloudFoundryへの移行は、必要に応じてかなり簡単なはずです。

c。説明されているアプリケーションでは、AWS EC2 / EBSへのデプロイにどのくらいのsysadminingが必要ですか？一時的な停止についてはそれほど気にしないが、永続的なデータ損失については気にすると仮定すると、EBSを自分でミラーリングする必要がありますか、それともAWSを離れてそれを行うことができますか？

d。Windows / Eclipseベースの開発アプローチでうまく機能する新しいオプション（AppScale、CloudFoundry、EC2 / EBS）はどれですか？最高のEclipseプラグインはどれですか？

AppScaleのドキュメントをざっと見てみると、開発用VMがUnixホストによってホストされていると想定しているようですが、これは私にとってもう1つの面倒です。

e。私のオプションのどれ1.-5。私の場合、お勧めしますか？

現在、私は＃2と＃4に分かれています。

4

1 に答える 1

4

いくつかの観察：

を。AppScale は、他のテクノロジ (ランタイム、データストア) のシン ラッパーであるため、一般に、これらの基礎となる部分と同じくらい信頼性があります。ミッション クリティカルではない小規模な Web サイトの場合、IMO の信頼性は十分です。ちなみに、memcache の 1MB の制限はオブジェクトごとであり、memcache ごとではありません。したがって、複数の小さなオブジェクトに分割できると思います。

b. 私は CloudFoundry の経験がありませんが、彼らは「ベータ版」であり、SLA を持っていないと言っています: http://support.cloudfoundry.com/entries/20971351-cloud-foundry-sla \

c. 週に数時間程度だと思います。ESB はディスクベースのサービスであるため、データを失うことはありません。ただし、ECB の S3 への増分バックアップは引き続き実行できます。自動的にそれを行う多くのソリューションがあります。

d. IMO EC2 は、利用可能なツールが最も多く、最も成熟しています。AppScale は単なるラッパーであることに注意してください。EC2 にデプロイできます。開発環境 (Eclipse+Windows) は、デプロイ環境 (通常は Linux、EC2 上の Windows も可能) とは関係ありません。

e. 個人的には、GAE (= オプション 1) を使用することをお勧めします。私見では、他のものは信頼性が低く、費用がかかります（セットアップ/サポートの費用が原因で、基本サービスの費用を比較することすらできません）。

ところで、OutOfMemoryErrors を取得している場合は、コードを実際に確認する必要があります。大量のデータをメモリ内のどこに保管していますか?

于 2012-12-21T12:09:37.867 に答える