战疫期,钉钉如何扛起暴增百倍的流量?

疫情期间,钉钉用户量激增,面临资源扩容挑战。借助阿里云资源编排服务ROS,钉钉实现了快速自动部署,2小时内新增1万台云服务器,满足在线办公和教育需求。

疫情期间,在线教育、在线办公需求持续井喷,钉钉作为很多企业首选的在线办公软件,用户量激增,特别是钉钉视频会议、直播的需求随之飙升。同时,钉钉为了响应教育部门“停课不停学”的号召,宣布老师们可以免费试用钉钉在线课堂。

流量如洪流般涌入钉钉,一场资源扩容的技术挑战拉开了帷幕。中小学生集体对钉钉展开了五星分期与在线写歌“泄愤”的策略,钉钉本钉不得不在线求饶。而在大战间隙,一声感叹传出:

流量这么大,钉钉为什么不崩?


从 1 月 28 日开始,钉钉音视频会议、直播的访问流量倍数级增长。作为一个在云上成长起来的产品,钉钉开启了在阿里云的资源扩容之路,满足了用户在家办公及在家上课的需求,保证了用户良好的体验,钉钉如何做到的?

如此大型的扩容,面临着两大困境:效率与资源供应

人工扩容困境:效率低下
  • 时间太短。 面对流量暴增,留给钉钉技术团队时间只有几天。从 1 月 29 日起,钉钉团队就已在阿里云上 24 小时开始全力扩容,截止 2 月 2 日,从最初的 2W vCPU 扩容到 3W vCPU,仅做到了数倍扩容,还远未达到业务需求。

  • 购买与配置非常复杂。 钉钉的系统架构包含多种资源,不同于单一的云服务器 ECS 服务集群,还包含 SLB、MongoDB、Redis、EIP 等产品。这些资源都需要一个个购买,其之间的关系也需要技人工自行配置。

  • 人工部署效率低、失误率高。 钉钉用户群量级大。如果人工部署集群,一个人部署 1 个集群需要 1 小时左右,同时也只能操作 3-4 个集群,还需要大量的配置操作,很容易失误。

  • 部署复杂度高。 集群的服务能力自闭环,支持无限扩展,但也会相应提升部署复杂度,而这次扩容涉及 8 个地域、16 个可用区,传统部署方式扩容场景效率低下
    大规模集群管理难度大。需要快速扩容近千集群,才能满足几亿人在家办公及学生在家上课的需求。当资源上千后,就很难管理资源之间的关系了,更何况超百万的资源规模。

  • 人工部署,容错率比较差,排查困难。 集群之间经常出现偏差,某个集群的 SLB 监听端口是 300,另一个集群是 3000,出现问题很难排查。

除却以上困难,建立和运维如此巨大的集群规模还会带来更多的技术挑战。

利用资源编排服务 ROS,实现快速自动部署

早在 2 月 2 日流量洪峰带来之前,钉钉就通过阿里云的资源编排服务(Resource Orchestration Service,简称 ROS)提高集群部署效率、帮助其快速扩容。而这款服务不负重托,帮助钉钉在短短 2 小时内新增部署了超过 1 万台云服务器,这个数字也创下了阿里云上快速扩容的新纪录。

什么选择资源编排服务?

资源编排服务是一款帮助阿里云用户简化云资源创建、更新和删除的自动化服务。其通过资源栈 (Stack) 这种逻辑集合来统一管理一组云资源(一个资源栈即为一组阿里云资源)。利用资源编排服务,云资源的创建、删除、克隆等操作都可以以资源栈为单位来完成。在 DevOps 实践中,资源编排可以轻松地克隆开发、测试、线上环境;同时,也可以更容易实现应用的整体迁移和扩容。

基础设施即代码(Infrastructure as Code)

资源编排服务是阿里云提供的基础设施即代码(Infrastructureas Code,简称 IaC)的云产品,使用 ROS 可以帮助最快速地实践 DevOps 中关于 IaC 的理念。

全自动托管服务

ROS 产品为全托管服务,无需购买维护 IaC 模板本身执行所使用的资源,只需要关注业务所需要使用的资源,即模板中定义的资源。尤其需要创建多个项目(对应多个资源栈)时,全托管的自动化可以更快地完成任务。

可重复部署

无论客户是需要部署的环境是开发,测试和生产环境,都可以使用同一套模板进行创建。指定不同的参数可以满足环境的差异化,例如,测试环境的 ECS 实例数是 2 台,而生产环境的 ECS 实例数是 20 台。或是客户需要进行多地域的部署,使用同一套模板可以进行重复的部署,从而提高部署多地域的效率。

标准化部署

在实践中,不同环境的细微差异往往带来非常复杂的管理成本,延长了问题诊断的时间,从而影响了业务的正常运转。通过使用 ROS 重复部署,可以将部署环境标准化,减少不同环境的差异,将环境的配置沉淀到模板中。再通过类似代码的严格管理流程,从而保证部署的标准性。

统一的身份认证、安全和审计

和其它的同类产品对比,阿里云官方出品的 ROS 与其它阿里云产品有着最佳的集成。集成资源访问管理(RAM)提供了统一的身份认证,而无需为单独建立用户认证体系。所有的云产品操作都通过 OpenAPI 调用,意味着您可以使用操作审计服务(ActionTrail)来审查所有的运维操作,包括 ROS 本身。

ROS 如何服务钉钉扩容?

定义资源模板

ROS 帮助钉钉快速创建了描述其所需要用到的阿里云资源(如 ECS 实例、数据库实例等)的模板,以定义它的集群架构。ROS 提供可视化编辑器能力,可自动可使用的模板。模板完成后,ROS 将自动地创建并配置这些资源,即可实现基础设施即代码(Infrastructureas Code)的理念。

模板解析与执行

当 ROS 接收到用户创建资源栈的请求时,在执行创建前,首先会对模板进行解析。解析包括语法检查、参数校验、依赖分析等。

依赖分析就是分析出资源间的依赖关系,目的有两个:

  • 保证资源创建的正确性:被依赖资源创建完成后才会创建依赖资源。
  • 提供并行化创建的能力:无依赖关系的资源可以并行化创建。

模板解析完成后,ROS 会按照依赖关系创建资源,只有所有前置资源完成创建,后面的资源才会开始创建,类似状态机的机制。

该资源模板可以快速地重复部署,尤其多地域、多可用区部署的情况;同时也可以减少环境之间的偏差,将部署过程和结果标准化,减少因为环境偏差引入的系统问题。

总结

钉钉使用资源编排服务 ROS,扩容效率就提升了 100 倍,陆续为钉钉完成了 10 万台云服务器的快速扩容和部署,创下了阿里云上快速扩容的新纪录。

目前 ROS 已经拥有平均每分钟 1 个集群的扩容效率、每天超百万 vCPU 弹性能力。未来,可以预见到,疫情结束后,数百万资源回收释放也将是一个浩大的工程。资源编排服务 ROS 具有一键销毁功能,自动回收集群内所有资源,避免繁琐操作及遗漏。

弹性是云计算最大的优势,也是云计算对整个社会提供的普惠和便利,而阿里云弹性计算资源编排服务 ROS 作为阿里云上原生的自动化编排部署服务,让云计算的弹性发挥到极致,为钉钉提供了强有力的支持,让钉钉成为使用最频繁最流畅的平台。

<think>我们正在讨论训练过程中损失值逐步暴增的情况(之前正常,后来突然增长到极大值)。这种情况通常是由于训练过程中某些因素累积导致的数值不稳定。以下是可能的原因和解决方案。</think>训练过程中损失值**初正常后暴增**是典型的训练失控现象,通常由以下原因导致: ### 根本原因分析 ```python def analyze_loss_surge(history): # 损失曲线分析 if history["loss"][:10].mean() < 100 and history["loss"][-10:].mean() > 1e10: print("🔍 诊断结果: 后暴增型异常") # 原因检测 if check_lr_schedule(): print(" ▸ 学习率衰减策略失效 (衰减不足或反增)") if check_grad_accum(): print(" ▸ 梯度累积导致数值溢出 (batch>1024需缩放)") if check_reg_weight(): print(" ▸ 正则化权重随时间异常增加") if check_data_shift(): print(" ▸ 训练中后数据分布突变 (脏数据批次)") if check_optim_state(): print(" ▸ 优化器状态数值溢出 (Adam的m/v变量爆炸)") # 示例调用 loss_history = {"loss": [5.2, 4.8, ..., 1e25]} # 模拟历史数据 analyze_loss_surge(loss_history) ``` ### 具体成因与解决方案 | 问题类型 | 发生阶段 | 关键特征 | 修复方案 | |-------------------------|--------------|------------------------------|-----------------------------------| | **学习率衰减失效** | 中后 | 验证集损失同步上升 | 改用指数衰减: `lr *= 0.95` | | **梯度累积爆炸** | 大批次训练 | 每N步损失突跳 | 添加缩放因子: `loss = loss/N` | | **正则化权重失控** | 中后 | L2损失项占比超50% | 冻结BN层: `bn.eval()` | | **数据分布偏移** | 随机出现 | 特定类别样本触发 | 启用异常检测: `torch.isnan(loss)` | | **优化器状态溢出** | 超长训练 | Adam的v变量值>1e30 | 添加状态裁剪: `clip_opt_state()` | ### 分阶段调试方案 **1. 中暴增(epoch 10-50)** ```python # 检查学习率调度器 current_lr = optimizer.param_groups[0]['lr'] if current_lr > initial_lr * 0.5: # 未充分衰减 scheduler = StepLR(optimizer, step_size=5, gamma=0.7) # 验证梯度健康度 grad_norms = [p.grad.norm() for p in model.parameters()] if max(grad_norms) > 1e6: nn.utils.clip_grad_norm_(model.parameters(), 1.0) # 梯度裁剪 ``` **2. 后暴增(epoch 50+)** ```python # 检测优化器状态爆炸 if 'exp_avg_sq' in optimizer.state_dict(): # Adam系列 for state in optimizer.state.values(): if torch.max(state['exp_avg_sq']) > 1e15: print("⚠️ Adam状态溢出! 重置优化器") optimizer = torch.optim.Adam(model.parameters()) # 重建优化器 # 防止正则化失控 for name, param in model.named_parameters(): if 'weight' in name and param.grad is not None: l2_grad = 2 * weight_decay * param # L2正则梯度 if torch.norm(l2_grad) > torch.norm(param.grad) * 0.5: param.grad -= l2_grad # 临时移除正则 ``` ### 预防性代码框架 ```python class SafeTrainer: def __init__(self, model): self.model = model self.loss_history = [] def step_monitor(self, loss): # 记录并检测异常 self.loss_history.append(loss.item()) # 暴增检测逻辑 if len(self.loss_history) > 100: avg_early = np.mean(self.loss_history[-100:-50]) avg_late = np.mean(self.loss_history[-50:]) if avg_late > avg_early * 1000: # 百倍增长 self._emergency_stop() def _emergency_stop(self): # 1. 保存当前模型快照 torch.save(model.state_dict(), "crash_snapshot.pth") # 2. 启用安全模式 for param in model.parameters(): param.grad = None # 清除梯度 # 3. 重建优化器 self.optimizer = type(self.optimizer)(model.parameters()) print("🚨 损失暴增! 已启用安全模式") ``` ### 关键结论 后损失暴增的核心原因是**训练动态系统的累积不稳定性**,需重点关注: 1. 学习率衰减策略的充分性 2. 大批次训练的梯度累积问题 3. 优化器状态变量的数值健康度 4. 中后数据质量的保持 5. 正则化与主损失的平衡关系
评论 13
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

优快云资讯

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值