Chaos Monkey 在 Cassandra 中的运用

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 的严苛考验，事情的结果可能会变得完全不同。