Chaos Monkey 升级了

  • Rags Srinivas
  • 足下

2016 年 11 月 3 日

话题:DevOps语言 & 开发架构文化 & 方法

InfoQ 之前已经报道过,Netflix 公司宣布Chaos Monkey 升级了,这是一个通用的工具,通过在系统运行时随机地选择关闭服务器和容器,用以作为提高软件弹性的服务。通过这次升级,Chaos Monkey 和 Spinnaker 整合在一起了。Spinnaker是 Netflix 的持续交付平台。这个整合使其能融合各种各样的云平台,包括 Netflix 公司自己的关于 Docker 容器的Titus平台。

Chaos Monkey 通过 Spinnaker 接收配置信息,并且,Chaos Monkey 利用这些信息,制定计划来有选择的关闭一些资源。它能生成一个更好的 UX 来调度这样的关闭过程,并能够将 App、程序或集群分组。它也有可能由于各种不同的原因,选择退出 Chaos Monkey,包括已知的正在进行中的故障等。最后,这些资源结束过程可以很好地通过测量和报告跟踪工具等来跟踪。

InfoQ 就 Netflix 公司的新版本公告,采访了为此项目工作的工程师 Lorin Hochstein。

InfoQ:Chaos Monkey 的首次发布到现在已经超过五年了,对吗?你能谈谈过去的历史和产生最新版本的动机吗?

Hochstein:在我们开始升级之前,包含了旧版本 Chaos Monkey 的 Simian Army 项目已经到了我们难以做修改的艰难地步。Simian Army 的内部版本是根据开源版本定制的,包括了一些 Netflix 特定行为的方式,使我们难以推断我们想要做出的改变会带来怎样的影响。一个特别的痛点是管理 Chaos Monkey 的应用程序配置管理,这其中 Netflix 内部版本的 Chaos Monkey 管理了完全不同于开放源码的版本所管理的配置数据。

让事情变得更复杂的是,在 Netflix 内部 Simian Army 项目的责任在团队之间被分割开了:Chaos 团队负责 Chaos Monkey,Engtools 团队负责 Janitor Monkey 和 Conformity Monkey。我们甚至在内部运行着两套单独部署的 Simian Army:一套由 Chaos 团队管理,只启动了 Chaos Monkey,而另一套则由 EngTools 团队管理,他们把 Chaos Monkey 禁用了。

由于这些问题的存在,Chaos 团队觉得是时候做升级了。这样,我们可以更加迅速地更改代码,我们也将更有信心,它不会对我们的生产环境产生意外伤害。

InfoQ:你在你的博客描述说这是一次重大升级。与 Spinnaker 的整合是其中一个功能。你能详细说明这个整合和其他的改进吗?

Hochstein:与 Spinnaker 的整合使得 Chaos Monkey 支持不同云的后端这件事情变得更容易。例如,一旦我们有了最初的 Spinnaker 支持实施 AWS,我们毫不费力地就能支持我们内部的容器云 Titus。因为 Titus 是 Spinnaker 已经支持的后端之一。除了 AWS 之外,Spinnaker 还支持公共云平台,如谷歌的计算引擎和微软的 Azure,以及像 Kubernetes 和 OpenStack 这样的私有云平台。只要 Spinnaker 可以支持其后端,Chaos Monkey 就应该即时可用。

即使你只是在使用 AWS,如果你在多个地区运行或有多个帐户,与 Spinnaker 的整合都能使 Chaos Monkey 更简单地部署起来。旧版本的 Chaos Monkey 需要在每个区域和每个帐户内单独部署,而现在我们可以跨账户和地区,只用一套 Chaos Monkey 进行部署。

在 Netflix 内部,我们有多个工具来管理部署的不同方面,我们通过 Spinnaker 的 UI 正在管理越来越多这样的功能。鉴于这一趋势,让服务团队使用它们用来创建部署管道或者可视化当前部署状态的相同系统,以管理他们的 Chaos Monkey 配置,这样做非常合理。

另一个显著的变化是允许用户控制 Chaos Monkey 认定的是一组实例的逻辑组。旧版本的 Chaos Monkey 使用 AWS 自动缩放组 (AWS auto scaling groups,ASGs)作为一组实例的逻辑组:当被激活时,它会在每个 ASG 内部随机杀死一个实例。在 Netflix 内部,我们有应用程序、堆栈、集群和 ASGs 概念。常见的情况是,集群只与一个 ASG 相关。然而,当我们在内部谈到在 Netflix 内部的不同服务团队,不得不提及的是团队的逻辑集群概念并不总是与 Spinnaker 所认定的集群可以对应起来。我们在 Chaos Monkey 上增加了一种配置选项,让工程师选择他们所认为的逻辑集群:它可以映射到一个 Spinnaker 的集群,或 Spinnaker 堆栈,或一个 Spinnaker 的应用程序。这里,我使用修饰词“Spinnaker”,但“应用程序、堆栈、集群”这些概念在 Spinnaker 之前就存在,并已经用于 Netflix 以前的部署工具 Asgard。

一个新的功能是钩子的存在,让用户可以整合 Chaos Monkey 与其他的服务。例如,用户可以定义自己的“追踪者”,当 Chaos Monkey 决定终止一个实例时,它们会被调用。我们在内部使用追踪者是为了向 Atlas 发送各种指标值,把终止事件记录到事件日志服务。Chaos Monkey 以前的版本已经支持发送电子邮件通知,并与亚马逊的简单电子邮件服务(SES)捆绑在了一起。在新的版本中,Netflix 公司的工程师可以用 Atlas 配置电子邮件警报。挂钩的另一个例子是提供了一个接口来查询现在是否存在还没有恢复服务的故障。如果当前已经发生了故障,Chaos monkey 将不会终止实例。

InfoQ:看来只能终止实例而不是可以加入其他故障,如延迟等等,这样看起来 Chaos Monkey 的最新版本功能似乎比较受限。你能评论一下这种限制背后的想法吗?

Hochstein:故障注入这些其他类型没有在 Netflix 内部的应用,并且他们需要 Chaos Monkey 有 ssh 访问实例的入口,或在每一个实例上都运行某种代理进程,我们也不想为我们没在使用的功能添加额外的复杂度。

当我们在 Netflix 的技术博客上宣布了对 Chaos Monkey 的升级之后,在博客上有一段评论说道,这些其他类型的失效模式甚至可以比一个简单的实例终止产生更多的问题,这绝对是真的。有一个被称为 Latency Monkey 的从未被开源的 monkeys,它会随机注入延迟。它没有在内部广泛使用,因为它被认为太危险了。

不支持随机注入这些类型的故障,我们正在采取一个更为集中的方法来测试,我们的服务是有弹性的。有许多不同种类的混乱可以被施加在一个实例上。例如,以前版本的 Chaos Monkey 支持许多种类型的故障,如增加中央处理器的使用率、增加 IO 的使用率和用尽本地磁盘空间等。从一个正在向遭受着故障的实例发起 RPC 调用的用户的角度来看,这些故障许多都表现为延迟增加、RPC 调用失败,或者这两种故障都有。这意味着,我们可以通过在 RPC 的层面注入延迟或故障来建立较大空间的故障模型。Netflix 公司已经有能力用一种称之为 FIT 的内部系统注入这些类型的 RPC 故障,并保持一段时间。

最近,Chao 团队开发了工具,使我们能够利用 FIT 去运行更为集中的故障注入实验。我的同事 Ali Basiri,会在即将到来的 QCon SF 上针对此方法发表演讲。我将在关于软件可靠性工程的 IEEE 国际研讨会上对此发表演讲。

InfoQ:如果我作为研发人员或架构师,我想要使用 Chaos Monkey,是否我只能用 Spinnaker?对想要用自己的云或容器平台整合 Chaos Monkey 的研发人员和架构师,你有什么建议吗?

Hochstein:如果你想使用 Chaos Monkey,而不使用 Spinnaker 作为你的部署平台,那么目前来说,恐怕你只能自认倒霉了。

Chaos Monkey 的主要复杂性并不是在终止部分。在上一次 Chao 社区日,来自 GitHub 的 Jesse Newland 在会议期间实现了一个 Kubernetes Pod Chaos Monkey。这是一个 20 行的脚本代码。复杂性来自于为部署实现域模型。对于我们这些 Netflix 公司的员工来说,Chaos Monkey 理解我们对于应用、堆栈、集群的概念,而这是公司中所有的团队都要遵守的,而且也和 Spinnaker 的概念一致。如果一个公司不使用 Spinnaker,我怀疑他们的部署不会跟随这种模型,所以我们的 Chaos Monkey 的实现会对他们不适合。

我会建议开发人员寻找一个与他们的部署模式配合得很好的 chaos 工具。还有一些其他的工具,包括 pumba、Chaos Lemur、Chaos Lambda、Blockade、 Simoorg、甚至微软 Azure 的故障分析服务等。如果找不到完全匹配的,我建议可以将一个匹配得最好的复制一份,并针对你的需求进行定制或者自己编写程序。

我也建议看看混沌工程的原理,它体现了我们对如何应用混沌工程的思考,以确保您的系统是有弹性的。

InfoQ:Netflix 公司是否是 Chaos Monkey 唯一贡献者?新版本会有变化吗?

Hochstein:在历史上,Netflix 公司已经是 Chaos Monkey 的主要贡献者,当然社区也在贡献代码。例如,有一个社区成员提供了额外的故障模式,这个故障模式已被添加到 Chaos Monkey 的初始版本里了。

在新版本中,我认为 Netflix 公司将继续是主要的贡献者。随着有更多人采用 Spinnaker,我想我们会看到更多的来自社区的对 Chaos Monkey 的贡献。

关于 Chaos Monkey 的github网站提供了更多信息,包括如何安装二进制版 go 工具和如何部署它等。

查看英文原文Chaos Monkey gets an Upgrade

DevOps语言 & 开发架构文化 & 方法