通过自动缩放Kinesis流实时传输资料
Kinesis是由AWS提供的一项流资料管理服务，可轻松收集、处理和分析实时流资料。本文详细介绍了迪士尼API服务团队如何实现Kinesis资料流的自动缩放功能，保证流量高峰时的资料传输效率，并有效降低成本。本文来自迪士尼技术部落格。文 / Nick Burkard
译 / 咪宝
原文
https://medium.com/disney-streaming/delivering-data-in-real-time-via-auto-scaling-kinesis-streams-72a0236b2cd9
摘要
Kinesis是Amazon Web Services（AWS）提供的一项托管式流资料服务，在迪士尼流媒体服务中被广泛应用于实时和批量分析，并支援个性化检视、流并发和应用程序域事件分析等功能。在本篇文章中，将详细介绍迪士尼流媒体服务的API服务团队是如何实现Kinesis资料流的自动缩放功能的，这项功能使我们能够在流量高峰时段稳定地传输资料，同时保持成本效益。问题
团队的工作
在迪士尼流媒体服务中，我们的API服务团队（包括我自己）负责那些向客户端公开公共API的应用程序，这意味着我们将大量参与客户端通讯协议、支援流量需求的扩充套件、通过回退和降级提供可靠性以及安全性。与大多数使用AWS部署的应用程序一样，我们的应用程序将事件记录到CloudWatch日志中。由于CloudWatch也是AWS提供的一项管理服务，因此我们可以很容易地整合它来储存和查询应用程序事件。我们还将应用程序事件释出到一个更大的资料湖平台中，这个平台支援对应用程序事件进行更丰富的分析和视觉化，这也就是Kinesis 资料流的来源。
动机
选择Kinesis流作为我们的资料湖平台的入口点，需要确保资料不会丢失或长时间落后于实时交付。一个简单的解决方案是过度供应流。然而，这并不划算，因为它相当于一天的大部分时间里都在浪费钱。
我们还研究了AWS Labs提供的一个应用程序Kinesis Scaling Utility，它可以通过CloudWatch来监控指标，并根据配置扩充套件Kinesis流。但是，它不是满足我们需求的最佳解决方案：
原因如下：
扩大规模的速度不够快。应用程序需要不断执行，这会产生额外的成本。上述两点是应用程序监控指标方法的结果，每隔设定的时间间隔来查询CloudWatch。我的团队需要尽快进行扩充套件并且节约成本，因此我们开始建立自己的解决方案。
有关Kinesis的基础知识
为了更好地理解为我们的解决方案做出的选择，我将介绍Kinesis流如何工作的一些基础知识。有关进一步介绍的文件，请参阅AWS提供的关键概念页面。（https://docs.aws.amazon.com/zh_cn/streams/latest/dev/key-concepts.html#terminology）分片
Kinesis流在建立时分配了一定数量的分片。流中的每个分片都有一个杂凑键范围，它是一系列有效的整数值。在建立时，这些分片被认为是开放的，这意味着它们可以接收资料并产生成本。对于新增到流中的每条记录，必须定义分割槽键。流杂凑此分割槽键，结果为整数。流确定生成的整数落入哪个杂凑键范围，并将记录传送到正确的已开启分片。
在向流中新增记录时，可以选择定义显式杂凑键，这将强制将记录传送到特定的开放分片。
缩放
缩放Kinesis流的过程称为重新分片，它可以通过呼叫UpdateShardCount来异步启动，必须提供目标分片用以计数（要缩放的分片数）。向下缩放流合并成对的分片以实现所需的总数。向上缩放流将多个分片分成两半以获得所需的总分。
这意味着可以将最小的流缩小到其当前开启的分片计数的一半。相反，这也意味着可以将最高的流扩充套件为其当前开启的碎片计数的两倍。
例如，Kinesis流有12个开放分片。在此流上呼叫UpdateShardCount时，目标分片计数必须在[6,24]的范围内，超出此范围的值将导致错误。
资料的可用性
Kinesis流具有设定的资料保留期，预设为24小时。重新进行分片后，分片将被关闭，这意味着它们无法再接收资料。它们不会产生成本并将保留到资料保留期后。
要求
为了实现将CloudWatch日志资料提供给自动扩充套件Kinesis流的目标，需要建立几个不同的元件。我们将这些元件组织成两个单独的堆叠，以确保将来可重用。自动缩放堆叠
在大量使用期间缩放Kinesis流及其相关资源，在非高峰时段缩小。Kinesis流
已处理资料的主要目标。此资料可以驱动实时处理或储存以进行批量分析。此流可以与其关联的扩充套件元件同时建立，也可以在AWS环境中存在。
扩充套件
Lambda可以扩充套件Kinesis流，根据Kinesis指标和可选的外部Lambda的计算吞吐量触发它的警报。处理触发扩充套件Lambda的警报跟踪Kinesis流报告的度量。
扩充套件架构
为了跟踪何时进行扩充套件，Lambda将在成功呼叫时向CloudWatch报告两个自定义指标（OpenShards和ConcurrencyLimit）。这些自定义指标将允许我们监控扩充套件行为。
缩小
Lambda可以缩小Kinesis流、缩放警报以及可选的外部Lambda到原始设定。在非高峰时段（处理失败的日志之后）每天一次，CloudWatch规则将以10分钟的间隔触发Scale Down Lambda。这样做的目的是为了抵消Kinesis缩小的限制（最低有效目标分片计数是当前开启分片计数的一半）。
如果当前正在大量使用流，如果当前正在按比例缩小或者已经缩小到预设的分片数量，则此Lambda将跳过缩小过程。
缩小架构
与扩充套件Lambda一样，只要成功呼叫，Lambda也会向CloudWatch报告两个自定义指标（OpenShards和ConcurrencyLimit）。
日志处理堆叠
从CloudWatch 日志处理事件，将结果传送到Kinesis流。记录处理器
Lambda将处理来自所选日志组的事件，将结果传送到Kinesis流。如果批处理中的任何日志事件未能传送到Kinesis流（带有错误程式码返回），则日志处理器Lambda将使用指数退避和抖动算法来尝试将失败的日志事件重新发送到Kinesis流。这使并发日志处理器能够在不同时间重新发送日志事件。
其保留的并发执行（一次可以执行多少并发Lambdas）将等于分配给Kinesis流的分片数。这样可以避免向Kinesis流写入比它可以处理的资料更多的资料，还能让我们直接控制资料流入Kinesis流的速度，这意味着资料将落后于实时交付，而不是完全丢失。
失败的日志处理器
为了解释上述日志处理器的潜在故障，任何失败的日志事件批次（已重试两次但仍然失败）将被储存到死信伫列中（DLQ）。在非高峰时段每天一次，CloudWatch规则将触发失败的日志处理器。这个单独的Lambda将向DLQ询问任何失败的日志事件，并通过日志处理器重新处理它们。
为了避免超时和长时间的执行，失败的日志处理器将能够异步地重新呼叫自身以继续重新处理失败的日志事件，假设有更多失败的日志事件可用。
架构解决方案概述
根据我们的体系结构元件的计划，我们可以转向如何利用它们来处理日志事件并自动扩充套件Kinesis流。关键指标
如前所述，扩充套件Lambda将使用警报来监控Kinesis指标，以检视它是否超过计算的阈值。建议的方法是在5分钟内从关联的Kinesis流中测量IncomingRecords或IncomingBytes的总和。这可以让我们直接了解流入流中的资料量并做出有关扩充套件的明智决策。
门限计算
选择上述推荐指标之一后，我们可以继续计算我们想要监控的阈值。对于具有n个分片的Kinesis流，Lambda将扩充套件到最多n个呼叫（由其保留的并发执行控制）。
每个Lambda每秒向Kinesis流传送平均m条记录。警报监视度量总和的时间是s秒。
因此，监视的阈值是n * m * s。
为确保在资料落后之前进行扩充套件，我们可以监控计算阈值的百分比。由于AWS的80％被认为是最佳实践，我们将继续监控该值。
架构
由于两个堆叠都是独立且通用的，因此它们可以单独部署或串联部署。当两者都部署为针对相同的Kinesis流时，结果是我们开始的问题的解决方案。
架构拓扑
验证结果
当为我们的某个应用程序部署架构时，我们需要验证我们的资料是否实时可用，并且在需要时进行扩充套件。首先，我们可以比较转发到日志处理器Lambda的日志事件数量与使用CloudWatch写入Kinesis流的记录数量，以确保资料不会落后。
转发日志与已处理日志
转发到日志处理器的日志事件总和等于每个资料点发送给Kinesis的记录总和。这意味着处理后的资料可以实时获得！
最后，我们可以使用Grafana将我们报告的自定义指标与并发日志处理器Lambda的平均数量进行视觉化。
自定义指标与平均并发
一旦超过设定的阈值就会发生放大，而在非高峰时段的设定时间开始按比例缩小并持续到结束。并发日志处理器Lambdas的平均数量也从未超过并发限制。这证实了我们正在自动扩充套件Kinesis流！
结论
我们已经成功开发了一个解决方案架构，其中包含两个可重复使用的CloudFormation模板，可以单独部署或者联合部署。日志处理模板使我们能够以最小的努力一般地转换资料。围绕CloudWatch日志和Kinesis的所有样板程式码都在后台处理。这使团队可以专注于如何转换资料。
自动缩放模板使我们能够定义Kinesis流安全放大和缩小的时间和方式。Kinesis流不再需要过度配置，以避免突然出现尖峰。这最大限度地减少了人工干预并降低了总体成本。
当这两个模板一起部署时，我们还可以控制将日志事件流转换为Kinesis流的速度。如果突然出现峰值，资料将暂时落后于实时交付，直到扩大规模完成为止。这比稍后重试失败的日志事件批要好得多，因为它将日志事件完全删除或多次处理的概率降到最低。
总的来说，构建这个解决方案架构非常有趣！虽然它最初是为API服务的用例开发的，但我很高兴我们将架构概括为两个独立的堆叠。这将使迪士尼流媒体服务的其他团队能够利用这两个模板并为体系架构做出改进。
