2015 年 8 月 6 日:存储服务访问过慢的故障报告

8 月 6 日上午 10 点 55 分开始,LeanCloud 数据存储、网站等服务都突然变慢,之后持续 15 分钟整个存储服务都基本不可用;从 11 点 10 分开始存储服务逐步恢复,至 11 点 23 分才彻底正常。

出现这一事故的原因,与我们的智能索引优化有关。大家可能知道,我们使用 Mongodb 来存储结构化数据。为了方便开发者的使用,我们会根据应用查询性能数据来自动为数据表进行索引优化。因为近期有部分客户数据增长迅猛,我们的智能索引优化系统监控到部分查询耗时较长,便给出了索引优化建议。上午 10 点 55 分,智能索引系统开始自动为这些用户的部分数据表创建索引。但是由于此次操作实际执行时间过长,导致索引创建失败,并引发了 Mongodb 中大量操作的堆积,令整个 shard 处于崩溃状态。很快存储集群的故障就波及到了前端的 API Server。


我们的系统结构大致如下图所示:
Screen Shot 2015-08-06 at 8.41.13 PM
因为大部分的数据读写请求处于 pending 状态,所以 API Server 处理客户端请求的线程池被打满。内部报警产生后,我们的工程师立即强行终止了 Mongodb 中运行时间过长的操作(期间 Mongodb 的 shard master 出现了两次切换),并且重启了 API Server。到 11 点 10 分,我们抢救过来了大部分存储和 API Server 节点,对外服务开始恢复,直到 11 点 23 分系统最终恢复了正常。

本次事故共持续了 28 分钟,其中 10 点 55 分到 11 点 10 分之间,存储服务彻底瘫痪;11 点 10 分至 11 点 23 分,系统逐渐恢复。

受影响 的服务有:

  • 数据存储服务
  • 依赖于数据存储的云引擎服务(云引擎中的 web hosting 服务不受影响)
  • 短信验证码服务(因为 API Server 一段时间不可用)
  • 消息推送服务(因为 installation 表查询受到影响)

不受影响 的服务有:

  • 统计服务
  • 实时消息服务

为了保证后续不再发生类似事故,我们会采取如下措施:

  1. 调整索引自动更新的时机,采用更加保守的策略,避免在任何高峰时段做大规模的索引更新操作;
  2. API Server 流控算法优化,避免单个 shard 的存储故障波及所有对外服务的 API Server(已在进行中,预计本周或下周完成);
  3. 开始 Mongodb 小集群拆分。我们会先从内部系统开始尝试,稳定之后会部署到线上环境,这样万一出现故障时让受影响的客户范围尽可能小。

我们对此次故障非常愧疚,同时也对在修复期间向我们报告故障的用户表示感谢!我们不会辜负大家对我们的信任和期待,竭尽全力做好以后的工作。

发表评论

电子邮件地址不会被公开。 必填项已用*标注