北弗吉尼亚州（美国东部-1）地区的亚马逊运动事件摘要

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

Amazon Kinesis可以实时处理流数据。除了由客户直接使用之外，Kinesis还被其他几种AWS服务使用。这些服务在活动期间也产生了影响。尽管不是根本原因，但触发的原因是容量的相对较小的增加，该容量在太平洋标准时间下午2:44开始添加到服务中，并在太平洋标准时间下午3:47完成。 Kinesis具有大量处理流的“后端”细胞簇。这些是Kinesis的主要功能，可为流处理提供分发，访问和可伸缩性。流通过“前端”服务器机群拥有的分片机制分布在后端。后端群集拥有许多分片，并提供一致的缩放单位和故障隔离。前端的工作虽然很小但是很重要。它处理身份验证，节流和将请求路由到后端群集上的正确流分片。

正在为前端机队增加容量。前端机群中的每个服务器都维护着信息缓存，包括后端集群的成员资格详细信息和分片所有权，称为分片映射。该信息是通过调用微服务（提供成员信息），从DynamoDB检索配置信息以及对来自其他Kinesis前端服务器的消息进行连续处理而获得的。对于后一种通信，每个前端服务器都会为前端机队中的每个其他服务器创建操作系统线程。在增加任何容量后，已经是机队成员的服务器将了解新服务器的加入并建立适当的线程。任何现有的前端舰队成员最多需要一个小时来学习新参与者。

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

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

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

有许多使用Kinesis的服务也受到了影响。 Amazon Cognito使用Kinesis Data Streams收集和分析API访问模式。尽管此信息对于操作Cognito服务非常有用，但此信息流旨在尽力而为。数据在本地进行缓冲，从而使该服务能够应对Kinesis Data Stream服务的延迟或短期不可用。不幸的是，Kinesis Data Streams的长期问题在此缓冲代码中触发了一个潜在的错误，导致Cognito网络服务器开始阻塞积压的Kinesis Data Stream缓冲区。结果，Cognito客户遇到了更高的API故障，并且Cognito用户池和身份池的等待时间增加了，这阻止了外部用户对身份验证或获取临时AWS凭证的攻击。在活动的早期阶段，Cognito团队致力于通过增加额外的功能来减轻Kinesis错误的影响，从而增加其缓冲对Kinesis的呼叫的能力。虽然最初减少了影响，但PST错误率在上午7:01之前显着增加。该团队正在并行研究对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来驱动用于管理客户集群和任务的内部工作流程。这影响了新集群的置备，现有集群的延迟扩展以及任务取消置备。太平洋标准时间（PST）下午4:15之前，大多数问题已解决。

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

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