写点什么

Chaos Monkey 在 Cassandra 中的运用

  • 2014 年 10 月 17 日
  • 本文字数:1693 字

    阅读完需:约 6 分钟

2014 年 9 月 25 号 AWS 就 EC2 维护事件向用户发出公告,称需要执行“一次适时的安全及运维更新”,因此必须对大量用例(约占总数的 10%)进行重启。而 2014 年 10 月 1 号,AWS 发布了后续消息,就此次重启的当前状态与 XSA-108 作出说明。

尽管我们希望宣称自己由于各项恢复策略的存在而对整个流程毫不担心,但实际上我们一直采取高度戒备状态、深恐此次重启会给服务带来潜在影响。我们讨论了多种不同备选方案,权衡了可能引发的风险并密切监控着我们的各项服务。经过观察,我们发现各大系统在预先部署到位的恢复措施的支持下获得了理想的重启效果。这些突发性事件对于我们进一步强化定期、控制内混乱状况并继续在混乱工程领域进行投入可谓很有必要。事实上,Chaos Monkey 正是在本次 EC2 维护更新中实现稳定性保障的头号功臣与最佳实践方案。

我们承诺通过引入混乱测试机制来帮助自身构建起良好的弹性表现,但其具体实施流程绝非一帆风顺或者轻而易举 ; 这一点在像 Cassandra 这样的状态性系统中体现得尤为明显。Netflix 公司的云数据库工程团队迎难而上,勇于接受混乱测试的挑战并于去年将 Chaos Monkey 方案引入生产环境。对于针对 Cassandra 设计的弹性机制而言,需要重启的节点数量将成为测试工作中决定最终结果的关键性因素。

数据库需要不怕折腾

数据库长久以来一直在应用程序领域扮演着饱受纵容与溺爱的宠儿角色。它们总能获得最强大的硬件与定制化管理,而且人们做梦也不会想到要对其进行可用性测试。但在以民主化著称的公有云世界中,这样的好日子已经一去不复返了。节点故障的出现绝非人力所能控制或者预测。这就要求数据库技术能够在遭遇故障状况的同时继续保持正常运行。

作为 Netflix 公司选择的理想数据库方案,Cassandra 在 CAP 定理当中同时满足了 A 与 P 两项(分别为 Availability 与 Partition Tolerance,可用性与分区容错性)。由于在 C(Consistency,一致性)方面作出了妥协,因此我们决定在应用程序的设计工作中充分考虑到一致性保障机制。我们认为 Cassandra 会坚守住自己的承诺,切实带来理想的可用性与分区容错性表现。通过过去几年的实际体会,Cassandra 确实显示出比较出色的故障抵御能力——但作为弊端,它需要大量人为干预介入其中。

去年,我们决定投入资源将自动化机制与 Cassandra 故障节点恢复方案加以结合。我们有能力检测并核实发生故障的确切节点。利用 AWS 提供给我们的云 API,我们得以顺利定位到故障节点、通过编程化方式更换上新的 Cassandra 节点并加以启动。在积累到丰富的经验之后,我们以充足的信心让 Cassandra 参与到 Chaos Monkey 演习当中。

遗憾的是其初期表现并不理想,随后的尝试也始终未有好转,为什么会这样?根据 Netflix 公司的一贯要求来看,我们无法快速并准确地实现问题修复。在接下来的几个月中,我们的自动化机制开始一路转好。误报状况得到了有效改善,而且我们的脚本几乎不需要什么人为干预即可顺利完成修复工作。

AWS 重新启动事件

“当我们听说 EC2 实例需要进行紧急重新启动时,简直惊讶得下巴都快掉下来了。一想到会有那么多 Cassandra 节点受到此次重启事件的影响,我就觉得浑身不舒服。但我旋即想起了此前我们曾经进行过的多次 Chaos Monkey 演习。我当时的反应是,‘让暴风雨来得更猛烈些吧!’”——Christos Kalantzis,云数据库工程技术部门工程经理

那个周末,我们的待命人员始终打起十二分精神。整个云数据库工程技术团队都处于高度戒备状态。我们对自己的自动化机制充满信心,但稳健的执行团队仍然要在抱有最好希望的同时为最差结果作好准备。

在此期间,我们的 2700 多个生产性 Cassandra 节点中有 218 个进行了重启。其中 22 个 Cassandra 节点由于硬件问题而未能成功完成重启,这直接导致上述 Cassandra 节点无法按计划重新上线。我们的自动化机制检测到了故障节点并将其全部加以替换,整个过程将人为干预降至最低限度。Netflix 在整个周末完全没有出现任何停机事故。

对包括持久层在内的业务体系进行定期反复故障演习应该成为每一家企业恢复规划中的固有组成部分。如果不是因为提前让 Cassandra 经受了 Chaos Monkey 的严苛考验,事情的结果可能会变得完全不同。

2014 年 10 月 17 日 08:40662
用户头像

发布了 501 篇内容, 共 223.2 次阅读, 收获喜欢 45 次。

关注

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

程序员什么时候该考虑辞职

看山

随笔杂谈 辞职

Java ForEach语句判断是否为空

引花眠

bug

【Elasticsearch 技术分享】—— ES 常用名词及结构

程序员小航

Java 搜索引擎 elastic ES Lucene Elastic Search

商业计划书制作(5):业务发展的历史与未来

老壳有点爽

创业 财富自由 商业计划书 业务发展的历史与未来

高并发系统三大利器之缓存

java金融

Java 缓存 高并发 本地缓存 分布式缓存

高并发系统三大利器之限流

java金融

架构 高并发 分布式限流 限流 单机限流

disruptor 高性能队列最佳选择

柿子

队列 disruptoer 高性能队列

硬件产品管理(1):手板管理流程

老壳有点爽

创业 硬件产品 智能硬件 手板

硬件产品管理(2):产品QA检测

老壳有点爽

硬件产品 智能硬件 QA 产品管理

设计模式:建造者模式

看山

设计模式 建造者模式

ARTS-WEEK11

一周思进

ARTS 打卡计划

Java中的一些限制

xiaoxi666

架构师训练营 - 第 8 周学习总结

红了哟

商业计划书制作(6):商业模式

老壳有点爽

创业 商业模式 财富自由 商业计划书

商业计划书制作(8):财务分析部分

老壳有点爽

创业 财富自由 商业计划书 财务分析

键盘敲入 A 字母时,期间发生了什么....

小林coding

操作系统 计算机基础 键盘

什么是产品以及如何将一个开源软件项目产品化

常平

架构模式 架构设计 架构师 产品思维

ARTS Week13

时之虫

ARTS 打卡计划

硬件产品管理(4):人体工程学验证

老壳有点爽

硬件产品 智能硬件 产品管理 人体工程学

《我在一线做用户增长》读书笔记及感想

王新涵

用户增长

硬件产品管理(3):产品问题整理-举例

老壳有点爽

创业 硬件产品 智能硬件

顺时针遍历矩阵,提高系统高并发350倍,React Native原理浅析 组件设计原则 安全架构 防火墙ModSecurity John 易筋 ARTS 打卡 Week 14

John(易筋)

ARTS 打卡计划 组件设计原则 React Native 高并发优化

编程的乐趣与苦恼

看山

随笔杂谈 人月神话

ARTS打卡 第13周

引花眠

微服务 ARTS 打卡计划

硬件产品管理(5):硬件产品工作流程管理及案例分析

老壳有点爽

创业 硬件产品 智能硬件 产品管理

面试的时候不能做捧哏

escray

学习 面试

Java中的单例模式(完整篇)

看山

Java 设计模式 单例模式

商业计划书制作(7):编写规范及常见内容

老壳有点爽

创业 财富自由 商业计划书

可伸缩系统架构简介

Rayjun

分布式 可伸缩

如何做好项目时间管理?

石云升

项目管理 需求 项目排期

(2.6w字)网络知识点灵魂拷问——前端面试必问

执鸢者

面试 大前端 网络 HTTP

Chaos Monkey在Cassandra中的运用-InfoQ