• Feeds

  • Google的系统工程师(SA)如何工作

    本文根据系统管理领域知名博客 Thomas A. LimoncelliWhat is system administration like at Google 整理而成,添加了部分笔者观点。

    Google的系统工程师(System Administrator)如何工作

    由于Google的服务已经集群化,系统工程师并不大量接触硬件比如做安装服务器等事情。另外大部分工作也已经自动化了,比如架设LDAP, 负载均衡等。对照而言,国内目前大部分互联网公司SA仍然要做大量重复的底层工作,比如拿一个业务的数据库过大需要拆分为例,从系统管理员的角度,需要做以下事情

    1. 同技术人员沟通目前业务特点,制定拆分方案并评估程序风险
    2. 搭建测试环境,技术人员测试程序兼容性
    3. 制定实施方案,保证业务的不停机平稳过渡
    4. 深夜上线
    5. 观察1-2天运行情况

    我们需要思考上面工作是否是系统管理员以及技术人员有价值的工作。像Cassandra这样解决了分布式存储自动化扩展的问题是业内一种发展方向,尽管Cassandra的稳定性还需要改进)。

    Google的系统工程师怎么做?
    他们会通常1周值班,响应各种问题,比如完成上述场景中的扩容业务。然后有大约5周左右脱离一线工作来自由思考将这1周内碰到的工作进行自动化改进,将那些会反复碰到的问题通过脚本及监控程序完成,或者进一步反馈给技术人员改进应用程序来实现自动化。1:5只是个大约比例,时段可以灵活安排。比如也可以按天来安排,1天值班/7天改进。当改进完成之后,下次遇到相同的场景,自动化程序会完成大部分工作。如果在其他公司,SA通常忙碌在一线机械重复上述工作,但是在Google, 给系统工程师预留了相当多的时间让大家思考改进。

    这就是Google的System Administrator自称SRE(Site Reliability Engineers)的原因。SRE会不断在优化所负责的系统,一些人关注运维层面,另外一些可能关注自动化工具。所有的SA都需要具备一定程序或脚本开发能力。

    因此,当遇到Google的数据规模,自动化不是是否需要,而是如何更好实现的问题。

    在Google其他一些令人兴奋的工作还包括

    • 与开发技术人员是协同的关系。
    • 只需关心技术,在技术领域也有职业生涯上升通道,不必转向技术管理岗位或其他。
    • 同事都非常聪明,通常会觉得自己是最逊的那一个。
    • 很多挑战,保守的估计领先行业2-10年,在这里工作就象给了你一个魔法水晶球,通过你的工作可以预见这个行业的未来。

    受Google方式的启发,以下想到的一些可以研究的自动化方向

    1. 程序部署

    C/C++/Java/PHP/Python/Ruby/C# 等语言如何不停机自动发布
    自动发布如何简洁的解决模块依赖性,比如1天需要同时更新10个有相互依赖的模块,并且不能停止服务
    Web容器虚拟化,同一Web容器上可以部署多个业务,业务之间互相隔离,互不影响。
    将新开发的服务程序运维自动化。一般的服务程序从数量上来说,10是一个分水岭,10台以下的服务通过人工重复操作方式来管理也问题不大,但是10台以上就需要自动化管理的方法。很多优秀的开源程序(比如Tokyo Cabinet, Redis等)在单机上表现优秀,但是大规模部署不能。大公司中很多技术人员经常提到很多开源软件不适合他们就有这方面原因。

    2. 资源部署

    MySQL
    分布式文件存储
    Cache,拿cache自动化管理举例
    端口资源管理,不同业务使用不同端口,同一应用内不同的数据使用不同的端口,相关原因可以参看以前cache相关博文。
    容量管理,不同的数据需要不同的容量
    动态扩容,应用业务规模增长,比如从10G扩容到100G
    Proxy功能,比如虚拟化端口映射,程序访问的是固定虚拟端口,这样不需要重启服务也可以随时扩充,应用也不需要一致性hash, proxy帮你做了。

    3. 系统部署

    OS
    反向代理与负载均衡
    本地分区容量,批量管理
    程序发布与停止,比如一个程序一个点击部署到100台服务器
    虚拟化,比物理服务器更容易部署,资源利用率更高,部署更可控

    大部分国内互联网公司基础技术还是比较原始的,这跟行业过分强调“好产品是运营出来的”也有关系,基础研发通常不受重视,长此以往,只能在门槛低的领域打拼,与Google的技术差异就不止10年了。
    paper tape
    (图:大型机GEORGE的纸带编程年代)

    降低应用latency方法谈

    上个月发的谈团队每周技术交流引起不少同行感兴趣,如果那篇文章能起到促进业界公司内部技术交流那就是最大的贡献了。

    上周五我们继续内部技术讨论,对某Java Web应用进行了latency分析。Latency主要是分析一个URL高并发请求下消耗时间的分布,比如ab(ApacheBench)输出结果最后一段

    Percentage of the requests served within a certain time (ms)
      50%      5
      66%      6
      75%      6
      80%      6
      90%      7
      95%      8
      98%     10
      99%     18
     100%     92 (longest request)

    表示99%的调用是在18ms返回的,从结果来看latency比较低,反映相应URL的性能是比较理想。

    这次技术讨论首先是情况介绍,测试工程师介绍了主要URL从本地IDC到全国的latency的分布图。另外DBA也从数据库的角度介绍了DB层面常见的latency来源。这样会后我们可以对最明显的问题进行优化和改进。

    除去通用的问题之后当然是讨论方法,程序员关注的重心大部分还是从应用层面怎么降低latency。

    压力测试

    很多Web开发的朋友也经常讨论Web应用如何有效的进行压力测试,目前也没有万能的方法。可以使用的工具有loadrunner, 或者Erlang语言开发的tsung等,很多公司也有自己的内部工具。HTTP/Memcache/MySQL等协议压力测试其实相对简单,通常用自己脚本或者高级语言开发的工具比起通用工具来说效果会更佳。

    profiling

    对接口进行Profiling是发现瓶颈最直观的方法,Google据说就有很完善的内部profiler工具(当然Google内部什么工具都有)。我们讨论了目前不同开发人员使用的profiling方法的优缺点。

    1. 直接使用专业工具,比如JProfiler, 还有Java自带的JVisualVM等。
    2. AOP(Aspect-oriented programming)的方式,优点是对程序没有污染,在外部配置需要profiling的方法。
    3. 工具类的方法,需要在service方法前后加入小量关键点,优点是纯Java的实现,可以运行时动态打开或关闭profiler。比如通过给进程发signals的方法(见Signals and Java)动态让程序输出当前运行情况,起到了能够动态profiling服务器但在正常情况下又不影响服务器性能的作用。

    从讨论情况来看大部分开发人员还是倾向于方法3,我们也希望团队能逐步建立类似Google内部profiler之类自己的工具。

    Memcache mutex设计模式

    周六的S2 Web 2.0技术沙龙上介绍了memcache中使用mutex场景(文后要演讲稿),有网友对详情感兴趣,简单介绍如下。

    场景

    Mutex主要用于有大量并发访问并存在cache过期的场合,如

    • 首页top 10, 由数据库加载到memcache缓存n分钟
    • 微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
    • 需要执行多个IO操作生成的数据存在cache中, 比如查询db多次

    问题

    在大并发的场合,当cache失效时,大量并发同时取不到cache,会同一瞬间去访问db并回设cache,可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障

    解决方法

    方法一
    在load db之前先add一个mutex key, mutex key add成功之后再去做加载db, 如果add失败则sleep之后重试读取原cache数据。为了防止死锁,mutex key也需要设置过期时间。伪代码如下
    (注:下文伪代码仅供了解思路,可能存在bug,欢迎随时指出。)

    if (memcache.get(key) == null) {
        // 3 min timeout to avoid mutex holder crash
        if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
            value = db.get(key);
            memcache.set(key, value);
            memcache.delete(key_mutex);
        } else {
            sleep(50);
            retry();
        }
    }

    方法二
    在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候,马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下

    v = memcache.get(key);
    if (v == null) {
        if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
            value = db.get(key);
            memcache.set(key, value);
            memcache.delete(key_mutex);
        } else {
            sleep(50);
            retry();
        }
    } else {
        if (v.timeout <= now()) {
            if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
                // extend the timeout for other threads
                v.timeout += 3 * 60 * 1000;
                memcache.set(key, v, KEY_TIMEOUT * 2);
    
                // load the latest value from db
                v = db.get(key);
                v.timeout = KEY_TIMEOUT;
                memcache.set(key, value, KEY_TIMEOUT * 2);
                memcache.delete(key_mutex);
            } else {
                sleep(50);
                retry();
            }
        }
    }

    相对于方案一
    优点:避免cache失效时刻大量请求获取不到mutex并进行sleep
    缺点:代码复杂性增大,因此一般场合用方案一也已经足够。

    方案二在Memcached FAQ中也有详细介绍 How to prevent clobbering updates, stampeding requests,并且Brad还介绍了用他另外一个得意的工具 Gearman 来实现单实例设置cache的方法,见 Cache miss stampedes,不过用Gearman来解决就感觉就有点奇技淫巧了。

    附:本次Web2.0技术沙龙演讲主题:微博Cache设计谈,需下载请点击演讲稿下menu/download (需登录slideshare)。