使用混沌工程增强 API 的可恢复性

  • Daniel Bryant
  • 盖磊

2018 年 5 月 28 日

话题:DevOps语言 & 开发

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

Gremlin 团队在博客上给出了一种简单的混沌实验,可用做验证一个组织的 API 是否具有可恢复性的方法。与适当地使用此领域中涌现的商业和开源工具一样,使用混沌工程的原则以及运行“游戏日”(可看成是 IT 系统和人员的消防演练)等技术同样可体现出自身的价值。

在这篇由 Gremlin 首席站点可靠性工程师Tammy Butow撰写的博客帖子中,一开篇就指出,尽管很多组织通过基于 Web 的 API 提供自身的服务(以及提供核心商业价值),但是从作者的经验看,这些 API 及相关的架构常被看成是“二等公民”。随着组织规模的扩张,这种方式存在着一些风险,例如可导致用户体验降级的 API 层失败,甚至是非常严重的事故。在与之相关的运行模式中,增加 API 的使用将会增大相关后台系统的压力,并且由请求数量增加而产生的负载可能并非与性能和可靠性呈线性关系。因此,工程师应该制定并运行一些试验,了解负荷增加、系统退化和基础设施失效的影响情况,并最终设计出可降低风险的系统。

Butow 建议,使用“混沌工程”原则和“游戏日”是形成上述理解并设计实验的最好方式。对于不熟悉“游戏日”概念的读者,Adrian Cockcroft 在 QCon 旧金山大会将其比喻为“IT 领域的消防演练”。出乎意料的应用行为或架构失败,常会导致工程师的人为介入,这会使情况变得更糟。在日常生活中,消防演习可训练人们接受如何应对火灾,进而在真正发生火灾的情况下挽救生命,IT 游戏日发挥了同样的作用。

该 Gremlin 博客帖子中,给出了一个针对典型 API 网关重度负载情况的例子脚本,并介绍了如何使用 Gremlin 的“可恢复服务”SaaS 商业平台实现在运行 API 网关的计算实例上注入失败(例如,高 CPU 或内存使用率,或者完全终止)。Butow 在博客帖子中强调指出(她同样也曾在先前的QCon 伦敦大会演讲中提及),在开始运行混沌实验之前,对监控和可观察性的需求是至关重要的。

“在着手测定 API 可恢复性之前,你应该做的一件事情就是在一致的基础上运行混沌实验。确保你具有良好的可见性(监控),并增加回退覆盖率,所有这些将有助于强化你的系统。”

混沌工程原则正逐渐被主流大众所采纳。这一方面是在 Gremlin 等商业混沌工具和服务业务的驱动下,另一方面的驱动力也来自于一些该领域的先驱者(例如Netflix,早期chaos monkey的创立者)、一些由社区牵头的工作(例如Chaos Toolkit)以及一些企业组织(例如Expedia和 Bloomberg。后者发布了专用于 Kubernetes 的开源混沌工具“PowerfulSeal”)。

随着混沌工程日渐广为采用,这正引导组织考虑是否应构建或购买相关工具,Gremlin 团队推荐工程师应在一些权衡上做出考虑,包括:构建自身混沌实验平台的 TCO(总体拥有成本,Total Cost of Ownership)、将内部系统暴露给外部 SaaS 平台的能力(以及可取性),以及团队当前技能集及团队在平台路线图方面对控制的需求。一些领域引领者,例如 Adaptive Capacity Labs 的联合创始人John Alspaw,也提醒说不应忽视可恢复工程中人的因素,这事实上要比相关的工具更为重要。

更多信息,提供在Gremlin 官方网站上,首届混沌大会将于 2018 年 9 月 28 日在旧金山举行。

查看英文原文: Increasing the Resilience of APIs with Chaos Engineering

DevOps语言 & 开发