在超负荷中生存: 亚马逊 Prime Day 如何避免拥堵崩溃

云计算
re:Invent
0
0
## 视频 <video src="https://dev-media.amazoncloud.cn/30-LibaiGenerate/31-LiBaiRebrandingVideo/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse-LBrebrandingWCaptionCN.mp4" class="bytemdVideo" controls="controls"></video> ## 导读 拥塞崩溃在大型分布式系统中是一种奇怪但可能很常见的情况,即一组服务器的 CPU 利用率达到大约 100%,但实际上提供了零生产性工作。更糟糕的是,即使在系统扩展时也无法恢复!有多种方法可以提前恢复和检测系统中的问题。在本论坛中,加入对拥塞崩溃现象的讨论,以及它如何应用于 Web 应用程序。在论坛的后半部分,讨论转移到亚马逊云科技工具,您可以使用这些工具,主动测试问题,以及如何避免系统中的相关中断。 ## 演讲精华 <font color = "grey">以下是小编为您整理的本次演讲的精华,共1100字,阅读时间大约是6分钟。如果您想进一步了解演讲内容或者观看演讲全文,请观看演讲完整视频或者下面的演讲原文。</font> 演讲重点关注了复杂系统中常遭忽视的关键现象——拥塞崩溃,以及如何使用亚马逊云科技(Amazon Web Services)平台上的技术和工具来预防和应对这一问题。 演讲者通过从日常生活中的生动例子入手,引出了拥塞崩溃的概念。例如,高速公路上的交通拥堵就是拥塞崩溃的一个典型例子,高密度导致车速降低,出行时间延长。这反过来又使驾驶员在已拥堵的高速公路上花费更多时间,进一步增加密度,形成恶性循环。最终,这种恶性循环可能导致交通完全停滞,尽管高速公路的容量被100%利用。演讲者将这种情况比喻为“死亡螺旋”。 为了预防密度失控并避免这种情况的发生,高速公路使用了入口匝道处的计量灯来进行调节。通过限制进入高速公路的车辆,计量灯在拥堵期间人为地限制了需求,以适应减少的供应。这避免了反馈循环并保持流量,尽管入口匝道处的等待会给驾驶员带来一定的不便。关键在于,通过明确信号化拥堵并要求用户“退后一步”,可以维持总体通行量。 另一个例子是定期导致电话网络瘫痪的母亲节过载问题。母亲节早晨会出现大量呼叫尝试,超出电话交换机的承载能力。呼叫者会听到“忙”信号,并下意识地重试,不知道问题是由系统网络过载而不是单个繁忙线路引起的。这会触发指数级的过载,导致零呼叫完成,尽管网络利用率达到了100%。电话公司最终通过在故障期间播放预录消息来解决这个问题,提示呼叫者耐心等待并稍后再试,而不是立即重试。这样可以避免进一步的过载,因为明确了问题并非孤立。 演讲者还解释了TCP/IP网络如何在内置指数退后和重传机制下经历拥塞崩溃。在严重拥塞的情况下,路由器会对数据包进行排队然后丢弃。终端主机重发丢失的数据包,进一步超载网络。当检测到丢失时,TCP会以指数方式降低发送速率,但这需要时间来降低总负荷。网络可能会进入一个由拥塞和重传导致的完全过载的恶性循环。 演讲者随后提供了一些关于网络服务器过载的案例,在这些案例中,即使请求量略有增加也会导致队列和延迟。不耐烦的用户会刷新页面,从而使实际负载成倍增加,直到服务器无法承受,尽管资源利用率达到100%,但无法执行任何有用的工作。解决方法是快速拒绝请求,而不是无限期地排队。 最后,演讲者讲述了在2018年亚马逊会员日期间,热门商品是如何过载分布式哈希表数据库的部分分区的。超时触发上游服务进行指数级重试,导致系统崩溃。隐藏的大型TCP套接字缓冲区进一步加剧了过载。由于队列持续增长,系统在几小时内无法正常工作。 演讲者总结这些案例,强调了拥塞崩溃是一种系统现象,而不仅仅局限于网络。它可能影响任何复杂的系统,包括高速公路、电信网络、网络服务、数据库等。关键特征包括: 1. 轻微的过载导致系统中的某个地方开始建立队列。 2. 长队列导致用户/代理感受到延迟。 3. 用户尝试重新连接,导致负载呈指数级增加。 4. 系统在执行零有用工作的前提下,尽管资源利用率达到100%,但仍然陷入困境。 5. 在输入减少后,恢复需要很长时间。 演讲者接着概述了避免和应对拥塞崩溃的方法: 1. 过载会发生,因此系统必须快速失败并以优雅的方式减轻负载,而不是无限期地排队。 2. 对重试持谨慎态度,特别是针对超时。指数级重试风暴可能很容易摧毁系统。 3. 在超载时提高效率,例如批量处理、消除重复数据、丢弃过期工作等。 4. 在客户之前通过挤压测试发现潜在的瓶颈。 演讲者随后介绍了与这些原则一致的特定亚马逊云科技功能: 1. 使用亚马逊云科技边缘服务,如CloudFront、Shield和WAF,在原始服务器接收到DDoS攻击之前吸收它们。 2. 使用WAF速率限制和自定义错误页面,在过载期间让用户在早期放弃。 3. 使用SQS队列和Lambda函数来抑制生产者,当消费者过载时。 4. 监控关键的CloudWatch指标,如CPU、网络I/O和队列深度,以检测拥塞症状。 5. 通过加载小型模拟测试完整系统的负荷来测试拥塞崩溃。挤压测试每个组件。 6. 利用像Locust这样的工具重现实际流量并模拟额外负载。 7. 运用故障注入模拟器来模拟组件故障及高CPU使用情况。 8. 在故障发生时关注行为和用户体验。 9. 确保通过消除队列和解决瓶颈来实现故障后的快速恢复。 演讲者强调,拥堵崩溃是一种破坏性的系统现象,一旦触发则难以恢复。关键在于通过设计使系统在负载下能够优雅地失败并主动预防这一问题。大规模负载测试以及延迟尖峰等现象在大规模表现为客户拥堵崩溃之前揭示潜在瓶颈至关重要。 一名参会者提出了一个有趣的问题:是否可以依靠无限扩展云资源来完全避免拥堵崩溃?演讲者解释说,实际上,无限扩展并不现实,即使是像亚马逊云科技这样的大公司也存在扩展限制。关键在于使系统在设计时能够在达到扩展限制时边缘处优雅地降级。如果核心系统开始积累导致拥堵崩溃的队列,恢复将变得极其困难。 另一名参会者询问了关于[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)计算的问题,以及是否通过设计避免了拥堵崩溃问题。演讲者回应称,[无服务器](https://aws.amazon.com/cn/serverless/?trk=cndc-detail)确实有助于通过自动扩展无限的计算能力来适应负载。然而,其他资源,如数据库和网络,仍可能过载,因此仍需考虑拥堵崩溃的问题。 此次演讲得到了与会者的认可。一位参会者表示,他们的系统中曾出现过类似拥堵崩溃的停机现象,但现在他们已经找到了一个名称。另一位参会者则表示,他们会更加谨慎地进行重试和解决队列问题的操作,以便根据所学知识进行调整。总的来说,这次演讲成功地强调了这一重要且被低估的问题,并为工程师们提供了知识和工具来解决这一问题。 **下面是一些演讲现场的精彩瞬间:** 詹姆斯·罗斯金德受雇于亚马逊,负责利用亚马逊云科技的服务来降低亚马逊网站的计算成本。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_0.png) 据领导者的解释,即使在拥塞崩溃期间将流量减少50%,仍可能导致队列增长和应用故障螺旋上升。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_1.png) 领导者强调,压力测试对识别潜在瓶颈以及确保高可用性至关重要。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_2.png) 面对过载,需要实施服务降级策略,这意味着要愿意接受失败并限制请求量,而非让系统崩溃。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_3.png) 此外,需限制重试预算的总增长。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_4.png) 领导者还强调了系统在负载下变得更高效以避免故障螺旋的重要性。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_5.png) 为了测试系统的故障点,需要通过超出预期最大负载的方式进行测试,观察是否会出现无限延迟和问题重试风暴,然后评估超载后延迟恢复的速度。 ![](https://d1trpeugzwbig5.cloudfront.net/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse/images/rebranded/NET402-Surviving_overloads__How_Amazon_Prime_Day_avoids_congestion_collapse_6.png) ## 总结 该视频探讨了如何避免网络过载并提供在出现拥堵时恢复的方法。内容涵盖了诸如高速公路交通拥堵和母亲节电话网络过载等实际案例。导致问题的主要原因在于重试需求和队列放大的效应。为了应对这一问题,需要实施一系列解决方案,例如实时监控CPU使用情况、限制每次请求的重试次数、快速拒绝无效请求以及在过载情况下动态调整请求处理策略。此外,还可以通过设置阈值来检测潜在的队列问题,并在必要时采取相应措施以确保系统的快速恢复。 在应对Web应用程序的过载问题时,可以采取一些措施,如识别并阻止恶意流量、向用户发送直接通知以避免意外的负载压力,并在编写节流代码时注意优化性能。为了确保系统的安全性和稳定性,还可以采用小规模的混沌测试方法,模拟各种故障场景以评估其对整体性能的影响。 总之,通过采用上述策略并结合亚马逊云科技的诸多工具(如CloudWatch、WAF、SQS和FIS),可以有效提高系统在面对过载情况时的应对能力,从而确保在面临类似Prime Day这样的重大活动时的快速恢复。 ## 演讲原文 ## 想了解更多精彩完整内容吗?立即访问re:Invent 官网中文网站! [2023亚马逊云科技re:Invent全球大会 - 官方网站](https://webinar.amazoncloud.cn/reInvent2023/?s=8739&smid=19458 "2023亚马逊云科技re:Invent全球大会 - 官方网站") [点击此处](https://aws.amazon.com/cn/new/?trk=6dd7cc20-6afa-4abf-9359-2d6976ff9600&trk=cndc-detail "点击此处"),一键获取亚马逊云科技全球最新产品/服务资讯! [点击此处](https://www.amazonaws.cn/new/?trk=2ab098aa-0793-48b1-85e6-a9d261bd8cd4&trk=cndc-detail "点击此处"),一键获取亚马逊云科技中国区最新产品/服务资讯! ## 即刻注册亚马逊云科技账户,开启云端之旅! [【免费】亚马逊云科技“100 余种核心云服务产品免费试用”](https://aws.amazon.com/cn/campaigns/freecenter/?trk=f079813d-3a13-4a50-b67b-e31d930f36a4&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技“100 余种核心云服务产品免费试用“") [【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用”](https://www.amazonaws.cn/campaign/CloudService/?trk=2cdb6245-f491-42bc-b931-c1693fe92be1&sc_channel=el&trk=cndc-detail "【免费】亚马逊云科技中国区“40 余种核心云服务产品免费试用“")
目录
亚马逊云科技解决方案 基于行业客户应用场景及技术领域的解决方案
联系亚马逊云科技专家
亚马逊云科技解决方案
基于行业客户应用场景及技术领域的解决方案
联系专家
0
目录
关闭