最终GAE与AWS架构决策

Question

我知道之前已经有过这样或那样的问题,但大多数与GAE稳定性有关的主要问题似乎都是在2008年底,2009年初提出来的,或者与大规模的游戏没有直接关系(我对此感兴趣.

基本上,我一直在与我的业务合作伙伴争论是否使用GAE或AWS作为社交游戏引擎的后端,现在是关键时刻.我喜欢GAE(Java)有很多原因,虽然它曾经不稳定,但它现在还不错.支持AWS的主要理由是AWS已证明自己每天运行数千万活跃用户的多个游戏.AWS的明显炙手可热的孩子是Zynga,其Farmville达到80 +百万DAU.这只是在AWS基础架构上运行的非常成功的游戏之一.卓越的成就.

所以,这种或那种方式已经知道了.另一方面,GAE没有任何我能找到这些数字的例子.差远了. 我可以信任吗？是否有一个使用GAE的200万+每日活跃用户的大型社交游戏的例子？

我们社交游戏后端的主要考虑因素是:

1. 可靠的CDN(Amazon CloudFront/S3非常适合这种情况,Google显然也是出色的DataStore).
2. 能够扩展而不会摔倒(AWS-EC2在这里得到证明,GAE似乎没有大型游戏应用程序的例子,每秒可以遇到1000个请求.GAE在这方面过去很不稳定,所以我的主要关注).
3. 可靠的无SQL数据库.(AWS-SimpleDB和Google的DataStore都非常出色.我们真的不需要SQL).
4. 支持/有人在遇到问题时致电/联系.(这是对GAE最大的担忧之一.我不知道我可以打电话给谁,或者甚至可能.我们有一个SLA和支持.)

我期待着你的想法,但请注意,这并不是为了开始任何形式的火焰战争.我喜欢这两种系统,但两者都有积极的和消极的,但我即将做出一个可能不会被推进的架构决策.

问候,

巴蒂尔

Answer 1

我从未使用过AWS-EC2,因此我将在Google App Engine上分享我的知识.

1. Google App Engine并不是CDN ; 虽然它可以通过其强大的基础设施提供静态内容,提供靠近用户的缓存,但它并不能保证真正CDN的同类高质量和高可用性服务,因为它不是其职责的一部分.
   更多数据:
   • 使用BlobStore服务的文件的最大大小:2千兆字节
   • 静态文件的最大大小:10兆字节
   • 目前App Engine 总是为静态文件返回200状态,即使在条件获取上也是如此(例如,你必须依赖第三方缓存库,例如cirruxcache).

2. 最近Google App Engine团队关闭了App Gallery,原因很简单:玩具应用程序太多了!
   谷歌想要抵消这种成功的企业案例研究的趋势; 这里是其中的一些:

   • BuddyPoke(病毒式Facebook应用程序,安装量为6500万)
   • WalkScore(每天向成千上万的房地产合作伙伴网站提供300万请求)
   • Webfillings
   • Snapabug
   • Optimizely
   • Ubisoft Facebook TikTok游戏

   其他有趣的案例研究在这里

3. " 我们非常了解停机时间和可靠性问题,并正在努力解决这些问题: Google开发者关系经理最近在此处表示,提高App Engine的可靠性是我们的首要任务."
   App Engine仍处于测试阶段,是一个不断发展的平台,因此您必须准备好应对停机和问题.

4. Google App Engine团队刚刚推出了App Engine for Business预览版,提供99.9%的正常运行时间服务水平协议和高级开发人员支持.

以下是我对它的价值的看法:
我知道这是一个艰难的电话; 阅读了很多关于GAE的文章我对此感到好奇,因为你可以从最近的灾难性Carlos Ble报告到花园或Gri.pe的快乐体验.
App Engine for Business看起来很有前途,我会考虑在严肃的商业项目计划中.新的SDK 1.4.0非常庞大,它清楚地表明团队正在努力解决一些恼人的问题(预热请求)并放松一些限制(在TaskQueue上进行10分钟的过程).

最后要考虑的事情是:如果你要获得大数字,谷歌应用引擎团队可能会将你的应用作为一个成功的案例研究,以推动免费和强大的炒作.

Answer 2

BuddyPoke是在GAE上运行的大型社交应用程序的一个示例.多大我不确定.这篇文章说每天30米的页面浏览量(不是用户):

http://googleappengine.blogspot.com/2008/10/app-engine-case-studies.html

他们的Facebook页面显示每月270万(非日常)用户:

http://www.facebook.com/buddypoke

虽然,他们也在其他社交网络堆上:

http://www.buddypoke.com/

我个人决定选择GAE,主要原因如下:

• 可伸缩性单元是单个请求,而不是像AWS一样的整个实例.
• 我可以在更高级别工作,而不必担心配置实例.

如果您的第4点对您来说很重要,那么您可能会更好地使用AWS.使用GAE,您似乎无能为力,也无法与您联系.

大约一个星期前,我的应用程序出现了问题 - 它突然开始在Google的代码中失败,在过去5天一直运行良好的位置,即自从我上次上传我的应用程序以来.向Google报告问题的唯一方法似乎是通过他们的生产问题模板,在这里:

http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue

我报告了这个问题,但没有听到任何消息.由于它在谷歌的服务器上运行,我无法采取任何"通常"的紧急策略,如重新启动服务器.一个小时之后,问题就解决了 - 我不确定Google的某个人是否看到了我的消息并修复了某些内容,或者它是否已经消失.我更新了我的错误报告,说问题已经修复,但即使是现在一周后问题仍未解决或甚至被确认.此外,由于问题必须公开发布,我的应用程序现在从机器人随机点击.

不可否认,我的应用程序目前仅处于测试阶段,因此只有大约一百个用户,因此对我来说这不是一件大事.如果我获得了数千/数百万次点击,那么谷歌可能会更早地注意到这个问题,或者他们会更加关注我的错误报告.

在您的观点3,即使我的小应用程序有少量流量也会引发偶尔的数据存储错误(即使在可用性图表中未报告为中断的时间内)也是如此.

话虽如此,我仍然喜欢GAE(我正在使用Python版本),并计划坚持下去.GAE的承诺是它的可扩展性 - 虽然它现在偶尔会因为我的小流量而有所下降,但是当它扩展到更多流量时(即你的第2点)它不应该再落后了,前提是我已正确编码以避免争.我会看看它是怎么回事.

最后关于您的观点1,blobstore和/或静态文件更像是GAE上的CDN,而不是数据存储区.然而,对于非常大量的流量,真正的CDN可能更便宜.它也不一定是CDN,请参阅Google应用引擎和CDN.