在本文中，我们想分享2020年11月25日在北弗吉尼亚州（US-EAST-1）发生的服务中断的详细信息。
Amazon Kinesis实时收集，处理和分析流数据。除了客户直接使用之外，它还涉及许多AWS服务。这些服务也遭受中断。此事件的触发因素（但不是主要原因）是该服务的容量增加相对较小，该服务开始于太平洋标准时间凌晨2:44，结束于凌晨3:47。
关于Kinesis设备
Kinesis使用大量处理数据流的单元（单元）的“后端”群集。这些是Kinesis的主力军。他们负责流的分发，访问和扩展。流通过分片由前端服务器分发到后端服务器。后端群集“拥有”许多分片，并提供一致的扩展和故障隔离。在我们的案例中，前端工作很小，但是很重要。它负责身份验证，限制请求并将请求路由到后端集群上的正确线程分片。
我们正在为前端机器机队增加新的功能。每个前端服务器形成一个数据高速缓存，包括成员身份和分片所有者（在后端群集中），从而形成所谓的分片图。它通过将请求发送到提供成员资格信息的服务并从DynamoDB检索配置数据来获取此信息。
此外，每个服务器都会连续处理来自其他Kinesis前端服务器的消息。为此，在每个前端计算机的OS中为每个前端服务器创建线程。添加新容量后，前端园区中已经在运行的服务器将了解新成员并创建相应的流。每个现有的前端服务器最多需要一个小时来了解新机器。
诊断和问题解决
太平洋标准时间5:15，写入和检索Kinesis记录时出现第一个错误消息。我们的团队立即开始研究日志。怀疑立即落在新容量上，但是某些错误与新机器无关，即使我们删除了所有新容量，也很可能不会出现任何错误。
尽管如此，作为预防措施，我们仍然试图删除它们，并试图确定其他错误的原因。它们种类繁多，拖慢了我们的诊断速度。在前端机器机队的现有成员和新成员进行的各种调用的各个方面，我们都看到了错误，这使得很难将副作用与根本原因区分开。
太平洋标准时间（PST）上午7:51为止，我们已将可疑范围缩小到只有几个候选对象，并确定任何最可能的原因都需要完全重新启动前端。 Kinesis团队非常了解此过程应该缓慢而详细。
事实是，填充分片卡与处理前端服务器资源的传入请求竞争。因此，过快地使前端服务器恢复联机状态将在两个进程之间造成冲突，并且几乎没有时间处理传入的请求。结果是可以预见的：错误率增加，等待时间增加。另外，速度较慢的前端服务器可能被视为不正常的迹象，这可能导致它们从可用服务器列表中删除，从而进一步减慢了恢复过程。
所有可能的解决方案都涉及更改每个前端服务器的配置并重新启动它。尽管我们作为问题根源的主要人选（一个似乎给内存带来压力的问题）看起来很有希望，但如果我们做错了，我们就有可能将恢复时间加倍，因为我们必须重新修复并重新启动所有内容。为了加快重启速度，在调查的同时，我们开始对前端服务器的配置进行更改，使您可以在引导时直接从元数据存储中接收数据，而不必从前端邻居接收数据。
主要原因
太平洋标准时间下午9:39，我们终于能够确定撞车的根本原因。原来，这与内存无关。新容量的增加导致所有前端服务器上的线程数超过了系统配置所允许的最大数量。由于超出了限制，因此无法创建缓存（存储卡）。结果，前端服务器无法将请求转发到后端群集。
我们不希望在没有进行初步测试的情况下增加操作系统中的线程限制，并且由于当时已经删除了额外的容量，我们认为超出系统数量限制的线程的风险很小，因此继续重启服务器。第一组新鲜前端从太平洋标准时间10:07开始接受Kinesis流量。
前端机群由数千个服务器组成，由于上述原因，我们可以每小时不超过几百个的速度添加服务器。我们一直在缓慢地增加前端的流量，并注意到自午夜以来Kinesis服务错误呈稳定下降趋势。服务在太平洋标准时间晚上10:23完全反弹。
我们学到了什么
我们从Kinesis事件中学到了一些教训，并计划在不久的将来进行更正。
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
崩溃还影响了使用Kinesis的某些服务。
Amazon Cognito使用Kinesis Data Streams收集和分析API访问模式。尽管此信息对于Cognito服务的运行非常有用，但不能保证将其传递（尽最大努力）。数据在本地进行缓冲，以帮助服务应对Kinesis Data Streams服务中的延迟或短时间的不可用性。
不幸的是，Kinesis Data Streams的长期无法使用揭示了缓冲代码中的一个潜在错误，该错误导致Cognito Web服务器开始阻塞Kinesis Data Stream缓冲区。结果，Cognito消费者面临API崩溃以及Cognito用户池和身份池的延迟增加。外部用户无法认证或获取临时AWS凭证。
在中断的早期阶段，Cognito团队试图通过增加额外的容量并由此提高Kinesis的呼叫缓冲能力来减轻Kinesis错误的影响。最初，这对服务产生了有益的影响，但是到太平洋标准时间上午7:01时，错误率已大大提高。同时，该团队致力于减少Cognito对Kinesis的依赖性。在上午10:15，部署了此解决方案，错误率开始下降。到12:15 PM，错误率已显着下降，并且在太平洋标准时间下午2：18，Cognito正常运行。为防止再次发生此问题，我们修改了Cognito Web服务器。他们现在可以忍受Kinesis API错误而不会耗尽其缓冲区（导致用户问题）。
CloudWatch使用Kinesis Data Streams处理指标和日志。从凌晨5:15开始，CloudWatch遇到PutMetricData和PutLogEvents API的错误和延迟不断增加的情况，并且警报进入了状态
INSUFFICIENT_DATA。尽管某些CloudWatch指标在中断期间仍在继续处理，但大多数都成为众多错误和增加的延迟的牺牲品。
在太平洋标准时间下午5:47，随着Kinesis Data Stream情况的改善，出现了恢复的最初迹象，到10:31 PM，CloudWatch指标和警报已完全恢复。在接下来的几个小时中，继续处理延迟的指标和日志。当CloudWatch努力解决错误时，内部和外部客户端无法将指标数据传递到CloudWatch。结果，CloudWatch指标数据存在差距。
目前，CloudWatch服务依靠Kinesis收集指标和日志，但其团队将很快实施一项更改，此后CloudWatch将在本地存储中存储三个小时的数据。此更改将使与CloudWatch指标（包括AutoScaling）相关联的用户和服务直接访问新收集的指标（在本地CloudWatch数据存储中）。这个想法已经在US-EAST-1地区实施，并且在未来几周内，我们计划将其在全球范围内推广。
另外两项服务成为CloudWatch指标存在问题的人质：
- 首先，基于CloudWatch指标的AutoScaling策略经历了延迟，直到下午5:47，此时CloudWatch开始反弹。
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
从美国东部时间上午5:15开始，CloudWatch Events和EventBridge的API错误和事件处理延迟都在增加。提高可用性之后，Kinesis EventBridge恢复了将新事件传送给收件人的功能，同时处理了累积的事件。
Elastic Container Service（ECS）和Elastic Kubernetes Service（EKS）在其内部工作流程中使用EventBridge来管理客户端集群和任务。这影响了新集群的配置，现有集群的延迟扩展，并影响了任务的取消配置。太平洋标准时间（PST）下午4:15之前，大多数问题已解决。
客户通知
除了服务方面的困难外，在事件开始之初，我们在向客户传达有关服务状态的信息时遇到了某些延迟。
在运营活动期间，我们有两种与客户沟通的方式：
在此类事件中，我们通常将信息发布到服务运行状况仪表板上。但是，在这种情况下，在崩溃开始时，我们无法更新Service Health Dashboard中的信息，因为崩溃的Cognito使用了用于发布更新的工具。
我们有一个后备方法，可以以最小的服务依赖性更新Service Health Dashboard。它按预期工作，但是在事件开始时将信息发布到Service Health Dashboard时遇到了一些延迟。关键是，该备份工具的自动化程度更低，技术支持操作员也不太熟悉。
为了确保将更新及时交付给所有受影响的客户，支持团队利用了“个人健康信息中心”来提醒他们潜在的服务问题。我们还在服务运行状况仪表板上放置了带有最新信息的全局横幅，以使用户尽可能了解该事件。直到崩溃结束之前，我们继续使用Service Health Dashboard（带有全局横幅摘要以及特定服务的工作方式的详细信息）和Personal Health Dashboard的组合，在此我们试图使客户始终受到服务问题的影响。根据我们的经验，我们在常规支持工程师培训中引入了带有备用系统的强制性练习，用于将消息发布到Service Health Dashboard。
...
最后，对于此次事件对客户造成的负面影响，我深表歉意。我们以Amazon Kinesis的高可用性而感到自豪，并且深知这项服务和其他AWS服务对我们的客户，他们的应用程序/最终用户以及他们的业务有多么重要。我们将尽最大努力从此事件中学习并使用它来进一步改善可访问性。
聚苯乙烯
另请参阅我们的博客：