Lambda Function是AWS推出的一款面向小任务，轻量化便携式的任务执行框架。它是在批处理和微服务之外，成功为计算定义Serverless的表现形式。借用AWS Lambda官网的一句话“Run code without thinking about servers. Pay only for the compute time you consume.” , 关注需要实现的code，无需关注底层服务，仅为运行时计算资源买单。
EC2/Docker Container对于很多云平台的应用而言，是计算和资源调度的最小单位。虽然它们的集装箱式管理和部署（AMI/Docker Image）大大简化了服务管理的难度，但是从应用的角度来看，它总是要完成一个具体的工作（Task），或者提供一个具体的服务（Micro-Service）。那么一个Task或者一个Micro-Service，即便足够小，维护EC2/Docker Container仍然会存在浪费。从SLA/SLO的角度，我们往往会为任务所需要的资源留有buffer，这必然会带来浪费。即使是充分优化的任务和机器配置，仍然会存在资源闲置的情况。如下图所示，红色部分代表workload，优化过的资源配置正好能覆盖peak workload，但是24小时下来却有超过60%的资源浪费。
AWS EC2 AutoScaling提供了一种可行的解决方案，即基于数据量和任务负载的自适应模型，实践中往往会通过资源利用率来做伸缩，也就是我们日常所说的Scale-Out/Scale-In。这种模型适用于无状态可扩展并且计算和存储分离的大任务。
K8S或者AWS EKS实现了微服务的调度和编排。我们在做服务的过程中，流量和请求都是随机和不可预测的。即使是可预测的事件触发的流量，例如秒杀/大型体育赛事直播等，为了支持这种流量的高并发，也需要提前申请很多机器，这往往也会导致浪费。下图是一个为了支持重大赛事高流量而做的扩容方案，可以看出资源的浪费程度和流量预测/系统容量评估/伸缩调整时间息息相关。
那么AWS Lambda适用于什么样的场景？
分散的，非频繁发生的执行需求。
聚焦的，执行时间较短的作业需求。
极其动态的执行需求。
无状态的执行任务。
Backend API调用[1]。
通过与AWS API Gateway或Application Load Balancer的集成，Lambda Function可以被封装成一个服务以对外提供。通过集成Kinesis（AWS 类似于Kafka的消息队列），可以实现事件处理的能力。当然最为常见的场景，还是通过CloudWatch来实现Lambda的调度执行，实现基于监控伸缩资源，以及定时调度任务的目标。近两年，Lambda成为了AWS无服务器轻量化任务调度的标配，越来越多的AWS原生服务开始在面向Lambda做集成。因此，Lambda逐渐成为了云原生的标准处理能力。
AWS Lambda只需要关注逻辑的开发，并限制最长执行时间15min和最大memory使用量3008MB。为了尽可能满足不同用户开发的需求，AWS Lambda支持Python/NodeJS/Ruby/Java/Go/C#等主流编程语言。要做到更好的code依赖管理，用户可以配置最多5个Lambda Layer到Rumtime。Lambda天生基因就是支持短小作业处理和非高并发的微服务。Lambda的执行仍然会被AWS调度到instance上进行，与EC2/EKS相比，只是这个部署执行的过程是由AWS全权代理。显然，尽可能复用那个看不见摸不着的instance，就可以避免package下载，runtime初始化等步骤，从而提升执行效率。至于，怎么warm up来长时间保持这个instance不被回收，可以有如下处理方式：
Peeking behind the curtains of serverless platforms. In USENIX Annual Technical Conference 2018) 由于是否复用instance，lambda执行效率有明显的差距，因此，它借助了这个特点，就可以推断闲置多长时间的instance会被回收，经过测试发现，inactive instance最多保持27分钟。是否回收instance还和同时间内VM是否有co-resident 的active instance有关。简单来说，如果创建一个ping-pong的lambda function，以更短的执行间隔，可以有效延长VM内共驻Lambda回收时间。根据论文测试，这样可能会延长1-3小时。
针对Lambda coldstart（冷启动）的开销问题，AWS在2019年底推出了Provisioned Concurrency，相当于预先分配好Instance，随时等待被调用。熟悉AutoScaling策略的同学，可能马上就会想到可以根据调用的metric来动态调整Provisioned Concurrency的大小。
“AWS Lambda function scaling” [点击阅读原文查看]详细讲解lambda concurrency的几个设置方案。如下图所示，lambda function scaling的策略。我们在EC2 Auto Scaling调整的EC2的个数，在EKS 调整的是Pod的个数，对等地，在lambda application是要根据调用并发次数调整预分配并发量。
Lambda的创新式运用。谈到这块内容，我就不得不佩服FAST[2] 2020的一篇文章。InfiniCache: Exploiting Ephemeral Serverless Functions to Build a Cost-Effective Memory Cache 翻译过来，借助无服务框架构建一个既经济实惠又高效的缓存系统。有没有缓存系统同时经济地缓存大对象和小对象，例如我们区分大小对象的标准是10MB。当前云平台的解决方案，S3或者GCS来存储大对象，Redis/ElastiCache来缓存小对象。显然，两种解决方案的成本开销和性能方面差距很大，我们需要在性能和成本之上做出取舍。可是，InfiniCache却在考虑有没有更好的解决方案。
借助ErasureCoding[3]实现数据冗余切片，Proxy来实现分片和Lambda之间的元数据管理。那么分片数据的缓存，都是在Lambda cache pool里实现。
使用Lambda来做Cache，由于Lambda长时间不被调用会被回收，因此为了提高缓存系统的可用性，系统支持定期的预热(WarmUp)和Primary-Backup的备份能力。
InfiniCache按照1分钟作为间隔来做预热，降低AWS Lambda的回收概率。1分钟间隔对比9分钟间隔的预热操作，效果更好。即使部分Lambda function 被回收，由于ErasureCoding数据可以容忍最多N-K（K，N是erasure coding的分片参数）片数据损坏，也不会影响其性能。
在cost方面，InfiniCache比ElastiCache有大概32-96倍的节省。从Performance来看，InfiniCache在large object的cache性能接近ElasticCache，对比AWS S3有明显的访问性能加速的效果。
Lambda的展望。Apache OpenWhisk提供了一个面向私有云的Serverless解决方案，但是在云平台上，不同厂商各自的协议和接口并没有形成标准，这给应用迁移带来了不小的困难。因此，serverless function标准化，是未来云平台治理的一个方向。为了更高效地发挥Lambda的能力，如何实现预分配资源的管理，实现Container和Lambda的混合部署，并在编程接口上整合和统一，将是工程上一个很有价值的实践方向。
Reference:
[1] Backend API: 区分于Client Facing的API，它侧重于后端服务平台的相互调用接口。
[2]FAST: 存储和文件系统的全球顶级学术会议。
[3]Erasure Coding: 是一种分片编码技术，应用于文件系统，并实现容错能力的可配置化。目前多运用于分布式文件系统。
欢迎大家关注译数据公众号。讲点你们听得懂用得上的大数据和云平台技术。
