Udacity 分享他们在 Google App Engine 上的架构

  • 郑柯

2012 年 10 月 31 日

话题:PythonMySQLDevOps架构

Udacity是一个以提供个性化计算机教育免费在线课程为主的网站,虽然该网站上目前只有 18 种课程,但是它的流量却相当可观,目前在 Alexa 的排名是 11926。

Chris Chew 是该网站的资深软件工程师。日前,他在 Google App Engine 的官方博客上分享了如何使用 App Engine 来构建 Udacity。

Chris 指出:使用 App Engine 的决策,是由 Udacity 的 CTO 和联合创始人 Mike Sokolsky 做出的。连续多周,Mike 必须不断加入新的服务器、管理 MySQL 复制数据库,以满足他们复杂的扩展模式。经过这段时间后,Mike 认为 App Engine 的运维简单方便,很有说服力。

到现在,Udacity 使用 App Engine 已经将近一年了,他们目前的架构如下:

其中:

  • 使用NDB完成海量数据集的复制。NDB 提供在无 Schema 的对象数据库中的持久化存储,支持自动化缓存、复杂查询和原子事务。
  • Memcache
  • Python Task Queues API 完成延迟执行、MapReduce、批处理工作。
  • App Engine Search API,索引课程内容和学生的简历。
  • Blobstore API,存储课程视频、简历,导出数据。
  • Image API,生成缩略图。
  • MapReduce API,数据每日使用分析、数据迁移、数据维护。
  • Trails 和 Trove,是由 Piotr Kaminski 主要开发的两个程序库。Trails 提供清晰的语法,可在 webapp2.RequestHandler 上创建 RESTful ,同时提供自动化分发。Trove 包装了 NDB,加入常用的属性类型,包括另一层的缓存,存储实体和之间的关系(包括处理中的和 memcache),还有事件“监控”框架,当数据变化时,可完成可靠的带外处理触发。

Chris 指出:图中没有标示出他们为 NDB 打的补丁,这些补丁能创建更好的 hook,类似于现有的 pre/post/put/delete 等 hook。这些自定义的 hook 为“监控”提供了抽象,让代码能对数据层中的变更反应。每个监控的执行都被延迟,并在请求之外完成,以避免增加响应时间。

Chirs 提到:在使用 App Engine 完成扩展的头一年中,他们发现,性能是一件很复杂的事情。响应时间是多种因素的函数,既在他们控制之内,又在他们控制之外。App Engine 确实有“水平扩展”的能力,但是他们发现对于某个给定请求的响应时间常常出现变化,即使是在系统负载很低的时候。因此,他们做了如下事情,以降低延迟变化的影响:

  • 使用新的 NDB API,而不是老的。
  • 尽可能使用NDB.tasklet协同程序(coroutines),在 RPC 操作阻塞时允许并行处理。
  • 不索引默认字段,仅在需要查询的时候才加入索引
  • 小心地避免索引热点,只在需要的时候才索引可以预测值的字段(比如当前日期和时间的 DateTime 类型字段,或是枚举类型的字符串字段)。
  • 大量使用实体化视图(Materialized view),这样可以限制每个请求尽可能少地查询数据集。

他们在最后一点上做的非常极端,把他们的数据集以去正规化的方式,专门生成为读操作优化的记录。比如,为读操作优化的用户档案记录包括:标准的档案信息、隐私配置、课程注册信息、课程进度和权限。这些数据都放在实体化视图中,只需要一个查询就可以完成。

对于 App Engine,Chris 给出的结论是:

App Engine 是非常完善、可靠的平台,符合为数众多的用户案例和场景。很明显,对于知道如何扩展 web 应用的人来说,它的服务和 API 是专门为他们设计的。……想要完成任何概念验证,都是轻而易举的事情,而且后续的应用扩展工作要比你自己搞一套基础设施要轻松得多。

跟其他平台一样,你也要做出一些让步。使用 App Engine 要做出的让步是:你要不留余地地降低延迟,这才能享用令人赞叹的、支持扩展的服务。这对于我们来说很容易,因为在多次令人兴奋的海量访问时,App Engine 已经有很好的表现。为了完成自己的使命,相对于自己搭建基础设施,我们现在的进度要快得多了。

PythonMySQLDevOps架构