废话少说，直接上干货。AWS官方事件分析 - Summary of the Amazon Kinesis Event in the Northern Virginia (US-EAST-1) Region

全文观感（划重点）

• 本次事件可能是由于一次小规模扩容引起，真是蝴蝶扇翅膀引起的混沌效应
• Kinesis前端服务器会处理来源于其他前端服务器的信息，每个前端服务器都会为前端集群中的每个其他服务器创建操作系统线程
• 扩容之后，创建的新线程超过了操作系统允许的线程数上限
• 重启是终极的解决方案。重启一次不行，那就重启两次。
• 滚动重启也不容易，很有可能会造成资源竞争， 从而引起雪崩效应。
• 服务失效隔离是个难题
• Kinesis太好用了，AWS自己好多服务都使用Kinesis
• 有个深坑就是Kinesis失效，引起Cloudwatch/Cognito失效，Cloudwatch失效引起AutoScaling和Lambda失效, Congito失效引起ECS/EKS provision/deprovision失效。。。。。。
• 雪崩之下没有一片雪花是无辜的
• 技术债迟早是要还的

全文翻译

我们想为您提供有关2020年11月25日在北弗吉尼亚（US-EAST-1）地区发生的服务中断的更多信息。

Amazon Kinesis可以实时处理流数据。Amazon Kinesis不仅被客户直接使用，还被其他几种AWS服务使用。这些服务在服务中断期间也受到影响。尽管不是根本原因，触发此次事件的原因可能是一次小规模扩容，扩容在太平洋标准时间凌晨2:44开始，并在太平洋标准时间凌晨3:47完成。 Kinesis具有大量处理流的“后端”服务器集群。这些集群执行Kinesis的主要功能，为流处理提供分发，访问和可伸缩性。流通过“前端”服务器集群分片分布在后端集群。后端集群拥有许多分片，并提供一致的缩放单元和故障隔离。前端集群规模较小但是很重要。它处理身份验证，节流和将请求路由到后端集群的正确分片上。

小规模扩容发生在前端集群。前端集群中的每台服务器都维护着一个信息缓存，包括成员详细信息和后端集群的分片所有权信息（称为分片映射）。通过调用微服务可以提供成员信息，从DynamoDB检索配置信息以及对来自其他Kinesis前端服务器的消息进行连续处理。对于来源于其他前端服务器的信息，每个前端服务器都会为前端集群中的每个其他服务器创建操作系统线程。在增加容量时，前端集群中的服务器将获得新服务器的信息并建立适当的线程。已有的前端集群成员大约需要一个小时来添加所有新参与者的信息。

太平洋标准时间（PST）凌晨5:15，开始发出第一个有关写入和获取Kinesis记录错误信息的警报。团队开始审查日志，对是否与新扩容有关有所怀疑。日志存在许多与新扩容无关的错误，即使删除了该扩容，错误也可能会持续存在。尽管如此，作为预防措施，我们在研究其他错误的同时开始删除新扩容。由于观察到的各种错误，诊断工作变慢了。我们发现前端集群的现有成员和新成员在进行各种调用时在各个方面均存在错误，极大干扰了我们从各种表象中找到根本原因。太平洋标准时间上午7:51，我们已将根本原因缩小为几个候选对象，并确定不管是什么原因造成的问题现在都需要完全重新启动前端机队，这将漫长而非常小心的过程。前端服务器中用于填充分片映射的资源与用于处理传入请求的资源竞争。因此，前端服务器过快重启会在这两个需求之间造成争用，导致可用于处理传入请求的资源非常少，从而导致错误和请求等待时间的增加。结果，这些缓慢的前端服务器可能被认为是不正常的，并已从集群中删除，这反过来又会阻碍恢复过程。所有候选解决方案都涉及更改每个前端服务器的配置并重新启动。尽管相对最佳的解决方案（会造成内存压力）看起来很有希望，但是如果我们做错了，我们将恢复时间加倍，因为我们需要应用第二个修复程序并重新启动。为了加快重启速度，在进行调查的同时，我们开始修改前端服务器配置，使引导过程中直接从权威元数据存储而不是从周围前端服务器获取数据。

太平洋标准时间（PST）上午9:39，我们确定了根本原因，这并不是由内存压力引起的，而是扩容导致了集群中的服务器数目超过了操作系统配置所允许的最大线程数，缓存构建无法正常完成，前端服务器保存了无用的分片映射，从而无法将请求路由到后端集群。我们不想在没有充分测试的情况下增加线程数的限制，而且我们刚刚完成了触发该事件的扩容进行回退，因此我们确定线程数将不再超过操作系统的限制，并继续执行重启。我们开始在PST 10:07 AM恢复了与第一组前端服务器匹配的Kinesis流量。前端队列由成千上万的服务器组成，由于前面所述的原因，我们只能以每小时几百个的速度添加服务器。随着Kinesis错误率从中午开始稳步下降，我们继续缓慢地增加了前端集群的流量。 Kinesis在太平洋标准时间晚上10:23完全恢复正常。

通过这次事件，我们对于Kinesis有了更多了解，将立即实施许多改进。在短期内，我们将转移到有更大CPU和内存服务器，以减少服务器的总数，从而减少每台服务器在整个机群之间进行通信所需的线程。这将提供大量的线程空间，因为每个服务器必须维护的总线程数与机群中的服务器数量成正比。拥有更少的服务器意味着每台服务器维护更少的线程。我们正在为服务中的线程消耗添加细粒度的警报。我们还将完成对操作系统中线程数上限的测试，这将为每个服务器增加线程数上限，为我们带来更多的安全余量。此外，我们正在进行一些更改，以从根本上改善前端机队的冷启动时间。我们正在将前端服务器缓存移至专用队列。我们还将将一些大型AWS服务（例如CloudWatch）移至单独的分区前端集群。从中期来看，我们将极大地加快前端集群的网格化进程，使其与后端的产品相匹配。网格化是一种我们用来隔离服务失效影响，并使服务组件（在这种情况下为分片映射缓存）保持在预先设定的测试和操作范围内的方法。 Kinesis的前端集群已经在进行这项工作，但不幸的是这项工作工作量巨大，目前尚未完成。网格化将提供更好的保护，以防止将来出现任何未知的扩展限制。

有许多使用Kinesis的服务也受到了影响。 Amazon Cognito使用Kinesis Data Streams收集和分析API访问模式。Congito在本地进行数据缓存，从而使该服务能够应对Kinesis Data Stream服务的延迟或短期不可用。不幸的是，Kinesis Data Streams的长期问题在此缓冲代码中触发了一个潜在的错误，导致Cognito网络服务器开始阻塞积压的Kinesis Data Stream缓冲区。结果，Cognito客户遇到了更高的API故障，并且Cognito用户池和身份池的等待时间增加了，这阻止了外部用户对身份验证或获取临时AWS凭证的操作。在事件的早期阶段，Cognito团队致力于通过增加额外的功能来减轻Kinesis错误的影响，缓冲更多的Kinesis调用。虽然最初减少了影响，但PST错误率在上午7:01之前显着增加。Cognito团队同时研究对Cognito的更改，以减少对Kinesis的依赖。太平洋标准时间（PST）上午10:15，开始部署此更改，错误率开始下降。到PST 12:15 PM时，错误率显著降低，并且到PST 2:18 PM Cognito正常运行。为防止再次发生此问题，我们修改了Cognito Web服务器，以便它们可以承受Kinesis API错误，而不会耗尽缓冲区，导致用户错误。

CloudWatch使用Kinesis数据流来处理指标和日志数据。从太平洋标准时间（PST）上午5:15开始，CloudWatch遇到了PutMetricData和PutLogEvents API的错误率和延迟增加的问题，并且警报已转换为INSUFFICIENT_DATA状态。尽管在整个事件中某些CloudWatch指标继续处理，但错误率和延迟的增加阻止了大多数指标的成功处理。太平洋标准时间（PST）下午5:47，随着Kinesis Data Stream可用性的提高，CloudWatch开始出现恢复的早期迹象；太平洋标准时间（PST）晚上10：31，CloudWatch指标和警报已完全恢复。延迟的指标和日志数据回填在接下来的几个小时内完成。当CloudWatch遇到这些不断增加的错误时，内部和外部客户端都无法将所有指标数据持久化到CloudWatch服务。这些错误将显示为CloudWatch指标中的数据缺失。尽管CloudWatch当前依靠Kinesis来提供完整的指标和日志记录功能，但CloudWatch团队正在做出更改，以将3个小时的指标数据保留在CloudWatch本地指标数据存储中。此更改将使CloudWatch用户和需要CloudWatch指标（包括AutoScaling）的服务可以直接从CloudWatch本地指标数据存储区访问这些最新指标。这项更改已在US-EAST-1地区完成，并将在未来几周内全球部署。

由于CloudWatch指标存在问题，两项服务也受到影响。首先，依赖于CloudWatch指标的响应式AutoScaling策略会遇到延迟，直到CloudWatch指标在太平洋标准时间下午5:47开始恢复。其次，Lambda产生了影响。 Lambda函数调用当前需要将度量标准数据发布到CloudWatch作为调用的一部分。如果CloudWatch不可用，则Lambda指标代理旨在在一段时间内本地缓冲指标数据。从太平洋标准时间上午6:15开始，指标数据的这种缓冲增长到一定程度，导致在用于Lambda函数调用的基础服务主机上引起内存争用，从而导致错误率增加。太平洋标准时间（PST）上午10:36，工程师采取了措施来减轻内存争用，从而解决了函数调用错误率上升的问题。

从PST 5:15 AM开始，CloudWatch Events和EventBridge遇到了API错误增加和事件处理延迟的问题。随着Kinesis可用性的提高，EventBridge开始提供新事件并缓慢处理较旧事件的积压。 Elastic Container Service（ECS）和Elastic Kubernetes Service（EKS）都使用EventBridge来驱动用于管理客户集群和任务的内部工作流程。这影响了新集群的provision， 导致现有集群的延迟扩展，影响了任务deprovision。太平洋标准时间（PST）下午4:15之前，大多数问题已解决。

除服务问题外，在此事件的早期，我们在向客户传达服务状态方面也遇到了一些延迟。在运营事件期间，我们有两种通信方式：“服务运行状况”仪表板（这是我们的公共仪表板，用于提醒所有客户有关广泛的运营问题）和“个人健康仪表板”，用于与受影响的客户直接进行沟通。对于此类事件，我们通常会将其发布到Service Health Dashboard。在此事件的早期，我们无法更新Service Health Dashboard，因为我们用来发布这些更新的工具本身使用的是Cognito，而它也受到了此事件的影响。我们有一种备份方法，可以以最小的服务依赖性更新Service Health Dashboard。在事件开始时，我们在使用此备份工具发布到Service Health Dashboard时遇到了一些延迟，因为对于我们的支持操作人员来说，它是一种更加手动且不太熟悉的工具。为了确保客户及时得到更新，支持团队使用“个人健康信息中心”通知受影响的客户是否受到服务问题的影响。我们还在服务运行状况仪表板上发布了全球横幅摘要，以确保客户对该事件有广泛的了解。在事件的其余部分中，我们继续结合使用服务运行状况仪表板，全局标语摘要和服务特定详细信息，同时还继续通过Personal Health Dashboard更新受影响的客户。展望未来，我们已经升级了支持培训，以确保我们的支持工程师定期接受有关备份工具的培训，以发布到服务运行状况仪表板上。

最后，对于此次事件对客户造成的影响，我们深表歉意。尽管我们为Amazon Kinesis方面的长期可用性感到自豪，但我们知道此服务以及其他受影响的AWS服务，对于我们的客户，他们的应用程序和最终用户以及他们的业务有多么重要。我们将竭尽所能，从这次活动中学习并使用它来进一步提高可用性。

未完待续

我将在下一篇文章中复盘此次事件对我团队云服务造成的影响。

版权声明

转载请注明出处