高访问量Web应用跨云端迁移的原因:权限和易用性 | 云防线技术博客

高访问量Web应用跨云端迁移的原因:权限和易用性

来源:本站原创 网站优化 超过围观 0条评论
摘要:Heroku和AWS都是优秀的云计算平台服务商,如果你正准备部署app到云端,在两个平台之间犹豫不决,Soundslice的经验或许可以给你一些启示。这是一个最近很火的吉他教学网页应用,开发者最近把它从Heroku迁移到了AWS。

导语:CSDN曾有篇文章 对Heroku和AWS两个云平台进行比较 ,结论是两个平台不分上下,各有优劣。本文作者 Adrian Holovaty 是一位来自芝加哥的创业者,曾开发过 EveryBlock(本地新闻网站,后被 MSNBC 收购),最近做了一个 HTML5 的网页应用 Soundslice。这个在线应用允许用户将网络视频做成吉他教程,然后供人们学习。以下为译文:

周五,我果断的把 SoundsliceHeroku直接迁移到了 AWS上。我真的非常开心,而且想要和全世界分享我是怎么做到的,以及为什么在类似处境下,需要进行迁移以及如何迁移。

“悲惨”的Heroku经历

Soundslice自从2012年11月上线以来,就部署在Heroku上。决定使用Heroku基于以下几个原因:

 

  • 我不是系统管理员,不喜欢也不擅长做一个系统管理员。
  • Soundslice是两个人的杰作(开发者和设计者)。我认为把自己的时间花在产品上比花在系统管理上会有更好的效果。
  • Heroku曾承诺,配置简单并且在高流量的情况下很容易扩展。

 

然而当我将Soundslice部署在Heroku上时,马上就出了问题。一方面,它们的Python/Django自动检测技术失效了。为了使它能够运行起我的app,我不得不重新修改四五次代码(settings.py应该放在这个目录下?还是子目录下?还是子目录的下一级目录下?)。自动检测这个功能真的很难调试。

然后我花了整整一天半的时间,试图让Django的自动发送错误邮件功能工作。我确认了服务器可以发送邮件,所有相关的重要代码都可以在Python shell正常运行,但是由于某些原因,app还是不能发送错误邮件。这个问题一直没解决——我放弃了,并选择使用 Sentry/Raven(强烈推荐)。

这些经验,以及其他一些怪事,让我厌倦了Heroku,但我一直在用它。

说到Heroku的信誉问题,Heroku在处理Soundslice的发布时表现很好,没有问题(命令行中ps和scale真的超级酷)。12月, Soundslice上了Reddit首页,几个小时内就达到了35万的访问量。我增加了dyno的数量后,Heroku处理得很好。

但在接下来的几个月中,让我抓狂的次数更多了。

首先,一月份,Heroku的部署出了问题。每当我要部署时,总会得到“恶心”的 错误信息。最终我放弃了纠缠于它们的bug,选择安装了一个不同的“buildpack”(多亏了Jacob的建议),但是这个问题给我留下了心理阴影。

然后,4月的一个晚上,我部署了我的app,当时Heroku决定升级Python版本从2.7.3到2.7.4(就这次更新而言,让人非常的郁闷。因为我并没有申请升级,但是鉴于我的代码在新版本上也能稳定的运行,所以说就算了)。然而部署完成后,我的网站整个挂掉了——这里产生了一个硬故障,而呈现给我用户的错误信息同样非常的不友好。我不知道怎么回事。我快速调查最近的提交信息,找问题。当我查看Heroku输出日志时,它只是显示发现不了 soundslice包里的一些内容。但是网站在本地运行得很好。那天的早些时候,我的部署还没有问题,并且我没有更改基本的包结构。

由于网站挂掉,浪费了几分钟时间后,我发送链接给一些潜在的客户(据我所知,他们当时正在评估这个网站)。我又重新部署,网站重新开始运行了。很显然,这些问题都是Heroku的部署过程造成的,问题并不在我。

这时,我不再相信Heroku了。从此,每当我部署网站都会有点紧张,害怕发生什么不好的事,脱离我的掌控。

大约在同一时间,Soundslice开始使用一些C扩展的Python模块和其它各种不能使用Heroku标准的requirements.txt步骤部署的非Python代码。虽然我可以像过去一样 使用Heroku编译和打包二进制文件,但是这要比在有root权限的服务器上运行一个apt-get命令花费更多的时间。

由于以上原因,我决定是时候离开Heroku了。我仍然在使用Heroku写这篇博客,可能将来也会用它来运行一些小型或者废弃的项目。但我个人不推荐用它来做一些更重要的工作,尤其是现在我知道从AWS获得强大性能是多么的简单。

AWS配置

我有幸和 Scott VanDenPlas(奥巴马竞选连任技术团队的开发总监)是朋友,他很了不起,备受关注。Scott帮我在AWS上为Soundslice申请了一个很棒的基础设施。尽管这些年来经常使用Amazon S3和EC2,但在Scott告诉我之前,我并不知道Amazon的全套服务如此强大。

Soundslice的配置方式相对简单,我们根据代码和依赖关系创建了一个自定义的AMI,然后根据自动缩放规则配置了一个 弹性负载均衡器。同时把app改为使用MySQL。详细步骤如下:

第1步:烹制AMI。我用一个现有的vanilla Ubuntu AMI(主要是Linux的静态镜像),然后用apt-get和 pip安装各种Soundslice需要的包。我也编译了一些非apt-get的代码,然后通过克隆Git知识库将app代码运行到上面。等我的代码和依赖关系都在实例上之后,我就创建了一个AMI(EC2控制面板上的“Create Image (EBS AMI)”)。

第2步:配置自动缩放规则。这很神奇。我们配置了一个负载均衡(使用Amazon ELB),可以根据流量自动生成app服务器。其中包括开启“启动配置”,“缩放策略”和“度量警报”。 点击查看我的Python代码可以看到详细信息。从根本上说,Amazon一直监控着app服务器,如果其中某些到达一定的CPU使用率,Amazon会自动加载几个新的服务器,并且在开启时就为它们配置负载均衡器。同样适用于流量下降的情况,你需要关闭几个实例。

第3步:更改app不使用共享缓存。直到向AWS的迁移,Soundslice一直在使用memcache存储Django的session数据。对于一个自缩放的环境,这会造成一些小问题,因为这意味着每一个服务器要访问同一个memcache实例。与其解决这个问题,不如使用 基于cookie的session,这样session数据会被存储在指定的cookie中而非memcache中。这样一来,Web应用服务器不用共享任何状态(除了数据库)。由于app不用再访问memcache获取session数据,对于终端用户来说访问速度也会变快。

第4步:迁移到MySQL。自从2003年左右,Frank Wiles让我看到了PostgreSQL的闪光点后,我一直都是PostgreSQL的死忠粉。但是在AWS上使用PostgreSQL的唯一方法是自己维护和扩展。相比MySQL,我更不擅长做系统管理。Amazon提供了 RDS(主要托管MySQL),采用point-and-click响应模式。当我仅在控制台点击几下就把可用区域从一个增加到两个时,我就爱上了AWS。操作简单得令人发指。

第5步:用Fabric添加优秀的API。用Heroku部署很简单,使用自定义的AWS环境同样很简单。我只要通过写Fabric任务做一些前期准备工作。关键是,因为你不知道在某一特定时刻有多少个服务器,或者它们的主机名,你可以通过Amazon API(使用 boto库)动态地查询主机名。 点击查看相关内容

后续:根据需要更新AMI。每当我的app需要新的代码位或者说一个新的apt-get包时,我会申请一个一次性的AMI实例来安装这个包,之后再作为一个新的AMI释放。然后将负载平衡器和新的AMI关联起来,这样一来每个新的app服务器都会使用新的AMI。通过在Amazon控制台终止它们,就可以强迫现存的实例使用新的AMI。负载均衡器可以检测到它们的终止,然后根据缩放规则为新的AMI创建一个实例。

另一种方法是使用 ChefPuppet,自动在新的服务器实例化时安装必要的包,而不是将包“烘烤”进AMI。我们没有这样做,没必要搞这么复杂。因为我的app足够简单,“烘烤”AMI的方式就很好。

总而言之,AWS是一个非常强大的装置,我认为它用起来和Heroku一样简单,完全的root权限,随处安装,设置自己的扩展规则等等。

版权信息:原创文章:云防线
本文链接:http://blog.cloudfence.cn/?p=544转载请注明转自云防线
如果喜欢:点此订阅本站