谷歌GAE运维揭秘:如何做到每天处理超过1000亿个请求


文章由才云科技翻译,如若转载,必须注明转载自“才云科技”

在这篇博客帖中,我们请到了Chris Jones(他做了三年半Google App Engine运维工程师,到目前为止已经当了9年的谷歌运维工程师),来探索更多关于在Google上运行产品系统的细节。Chris也是《Site Reliability Engineering: How Google Runs Production Systems》这本书的编辑之一,该书由 一直处于互联网发展前沿的O’Reilly Media出版,现在已经可以买到。

Google App Engine每天都服务超过1000亿个请求。就像你听说的那样,是我们的运维工程师让这成为可能。这的确有点像是魔术,将计算机科学和工程原则运用到编程系统的设计和开发中——这个总体来说是十分庞大。
谷歌运维是一套工程方法,让我们或者任何人更好的运行产品系统。它将运维的推广到更大的IT社区。它用有趣的方式来大规模提高性能和可靠性,这对于任何公司来说都是有用的。做得好的话,SRE技术可以提高操作编程服务的效率。

Q:Chris,能告诉我们有多少SRE在操作App Engine吗,现在有多大规模呢?

Chris:我们每天有百万级以上的应用程序在处理1000亿以上的请求,支持的SRE大概几十个的样子。

Q:只有那么少的人,是如何做到这样的规模的呢?

Chris:SRE也是一个工程方法,它可以操作大规模分布式编程服务。但是让系统高度标准化也是有争议的。高度标准化意味着所有的系统工作都是相似的,这也就意味着对操作人员的需求越来越小了,因为操作的复杂性大大降低了。
自动化也十分重要:我们的启动进程是全自动的,所以我们可以很好地用计算机来对这些进程进行扩容,而不是雇更多的人。如果想要将人放到进程上,那会显得很无趣,很多余。你会发现错误飙升。计算机的对错误的反应次数远远比我们人要来得多,而且快。在我们还没有注意到错误的时候,计算机就已经在将流量引到另一个数据中心了,同时保证服务继续运行。让人做人擅长的事情,让计算机做计算机擅长的事情。

Q:在SRE模式后,还有什么其他的方法吗?

Chris:因为有很多SRE团队在处理Google的服务,所以我们可以在产品上扩展标准化原则:SRE-创建工具原本是用于部署新版本的Gmail 的,例如,可以被整理来覆盖更多的场景。这也就意味着每个团队都不需要再自己创建方法来部署更新。这就确保每个产品在工具提升之后,都会得到改进,这就使得整个系统更好的使用工具。
另外, 软件工程和系统工程知识的结合,令解决方案囊括两者优点。谷歌的软件网络负载均衡器,Maglev,就是一个例子———而且它是Google云平台负载均衡器的底层技术。

Q:那么这些方法是如何影响App Engine和我们运行在AppEngine上的用户的呢?

Chris:我说个故事来阐述这个。在2013年的夏天,我们将所有App Engine的美国区域从国家的一边转移到另一边。这个举动招致没有停工期给我们的用户。

Q:怎么做到的呢?
Chris:我们先关闭一个App Engine集群,然后就如设计的那样,在上面运行的apps自动移动到了剩下的集群。我们早就事先在目标数据中心创建了美国区域的High Replication Database(https://www.youtube.com/watch?v=xO015C3R6dw)的复本,这样那些应用程序的数据(PB级别的数据!)就在该在的地方;对数据存储的修改是自动复制的,这样就可以实时更新。当在新的本地打开App Engine的时候,apps自动被分配到那个从他们备份集群中转移的集群,而且他们所有的数据是已经在适当的地方了。然后我们用剩下的集群来重复进程,直到我们完成之后。
事先准备,将大量的测试和应变计划结合,这就意味着当事情出错时候可以将冲击减少到最小。当然,我们将内部事后析误——SRE如何工作的另一个重要部分——放在一起来理解到底什么出错了,以及如何修复对长远比较好,没有指责。

Q:So cool!那么我们如何找关于SRE更多的消息?
Chris:如果你对SRE是如何在Google运行很感兴趣的话,那么就点击这个网站:https://landing.google.com/sre/,我们这周(四月7-8)也会在SREcon:https://landing.google.com/sre/就这个话题给出不同的演讲。

文章由才云科技翻译,如若转载,必须注明转载自“才云科技”
原文链接:https://cloudplatform.googlebl ... 551a8

想要了解更多关于Kubernetes的信息,欢迎关注Caicloud公众平台

图片_1副本.png

0 个评论

要回复文章请先登录注册