从Lambda运行失效，探讨Serverless和云HPC的适配场景与实现路径

本篇重点：

AWS Lambda在Serverless1.0场景的优势

Lambda在HPC场景中的表现如何？

一个Lambda运行HPC的实例

Serverless HPC可以实现吗？实现路径如何？

降低成本、提升效率是云服务永恒的主题。

自从2014年AWS推出Lambda服务后，Serverless一词越来越热，成为一种新型的软件设计架构，即Serverless Architecture。

谷歌搜索趋势显示，2018年对“Serverless”一词的搜索热度可以和历史巅峰时期的“MapReduce”一词相媲美，今年更是远远超过。

Serverless的出现标志着云计算将从“资源时代”过渡到“功能时代“，企业将逐步摆脱底层运维的管理负担，大幅降低云的使用门槛，给云服务行业带来质变。

云计算行业的竞争维度已悄然变化，从资源价格战转为对服务能力的比拼。

AWS Lambda

在Serverless1.0场景的优势

业界对Serverless尚无明确定义，当提到 Serverless 大家脑中立刻就会联想到 AWS 的 Lambda 服务。

狭义上 Serverless 的确指 Lambda 这类无需预置环境或管理服务器即可运行函数代码的服务。核心是帮助应用开发者摆脱服务器等底层基础设施管理的负担，专注于业务层的创新。

AWS Lambda已经满打满算运营了4年，其他厂商才刚刚开始。

能否从业务中抽象出共性功能直接提供给客户，帮助其产品快速投入市场，是云厂商竞争的关键。

通过AWS的Lambda案例可以看出，现实的Serverless1.0场景基本都是云端的大量的程序片断场景，例如识别一张图片、对一段音频/视频进行编解码、对IOT设备的请求返回部分数据、将客户提交的工单通过邮件通知客服人员等等。

 Serverless 视频转码服务

这些基于事件触发的程序片断在传统架构中实现起来相对复杂，往往需要为20%的核心业务运营80%的支撑业务。

Serverless完美地解决了这些问题，它可以成为复杂应用的一种补充架构。可以将无状态的、事件触发的业务拆分成Serverless应用，让整个架构变得更加的简洁和高效。

纵观各大厂商的实现，Serverless的优势主要有以下几点：

1) 不需要管理服务器–不需要提供或维护任何的服务器，不需要安装任何的软件或运行时。

2) 弹性伸缩–按函数调用自动进行的弹性扩缩容，不需要人为去管理伸缩问题。

3) 高可用－无服务器应用程序内置高可用和容错。无需考虑高可用，运行应用的服务默认提供高可用。

4) 低成本-没有闲置费用，不需要预留容量。代码不运行就不收费。

听起来相当诱人。

 Lambda在HPC场景中表现如何呢？

和Serverless相比，HPC绝对算是个老古董。(有对HPC前世今生感兴趣的可以点这里）。

高性能计算的分类方法很多。从并行任务间的关系角度来看，高性能计算任务可以分为集群计算和网格计算两类：

集群计算的应用，通常需要高带宽、低延时的特殊硬件如InfiniBand。另外，软件一般需要使用统一的消息传递接口开发库MPI来进行所有进程间通信和数据交换。

这种类型的应用无论从性能需求还是运行方式上目前都不具有在当前的主流云厂商Serverless架构上直接运行的可能性。

而网格计算型的HPC属于可极致并发的应用，这一特点和Serverless的弹性伸缩特性非常匹配。

理论上看Lambda完全可以解决这类应用的基础架构问题。

用户只要写一个函数，上传到Lambda，就可以轻松地按需触发成千上万个并行的任务，不用担心架构的扩展和可用性，这比自己维护一个高性能计算集群要省心很多。

但是仍然有以下几点可能制约这种类型的任务跑在Lambda上的可能性：

1. Lambda目前对单次函数调用的时间限制是15分钟，超过15分钟将被关闭。

虽然可以缓存函数状态以便下次调用代码时进行热启动，但无法返回到同一个虚拟机。

2. 性能需求。Lambda目前根据内存的分配来决定CPU的算力，目前没有明确的SLA，对计算密集型应用，要多次测试去决定适合的配置。

另外，有研究显示，Lambda会试图把同一个用户的函数放到一个虚拟机上运行，每个函数得到的带宽有限，在数据量较大的情况下会有IO瓶颈。

3. 当前Lambda没有API或者其它机制支持使用GPU，只支持通用CPU类型应用。

4. 成本，现实中的成本可能会更高。

前三点很好理解，主要是受目前Lambda的架构所限。第四点就有点费解了，说好的节省成本呢？

我们来看一个Lambda运行HPC的实例

这篇《一小时内完成百万计算任务？》里提到的就是一个典型的网格计算模型，当任务被分解后，使用Lambda实现一个函数，然后上传要计算的分子，Lambda就会自动按照上传的分子数按需计算了。

试验结果：

使用1024M的内存运行这个函数，完成一个分子计算的平均时间为3.2分钟（注：个别的大分子计算时间会高于15分钟，这类分子比较少，暂且忽略）。

Lambda 1024M内存的费用为0.0000113477元/100ms, 平均计算一个分子的费用为0.0000113477x10x3.2x60=0.02179元。

这样算下来，10000个分子的总费用为217.9元。

而之前我们使用spot成本优化过的费用在50元左右。

当然，目前Lambda每月会免费赠送计算时间，如果计算任务不多，确实可以考虑一下。但遇到百万分子计算任务的话，使用Lambda的成本将大幅上升。

通过以上分析我们可以得出结论，目前主流厂商的Serverless产品并不适合运行HPC应用。

现在的Serverless1.0更多的是面向运行时间极短，业务波峰和波谷特别明显的片段任务。对于一些小的应用开发商，也许每月用免费的额度就够用了。

Serverless HPC是可以实现的吗？

实现路径是什么？

让我们再来理解一下Serverless到底是什么。

广义上讲，Serverless 是在用户和云服务之间搭建了一个抽象层，用户直接使用功能，而对其中的云服务无感知的一种云服务方式。

在这个定义下，Serverless HPC可以怎么实现呢? 

首先，基于Serverless的核心概念。

我们认为对于基本的计算资源的调度，管理，分配应该像主流的Serverless一样由平台负责, 用户只需要关心他们需要完成的计算任务。

这就需要平台对于底层的资源做一定的抽象, 提供统一的资源访问方式。

其次, 应用本身需要由统一的打包工具来打包, 分发和运行。

对于一些常见的传统HPC应用，因为其行业应用使用方式相对固定，则可以由平台预先打包成功能模块或者函数。 用户只需要提供用于计算用的数据就可以完成计算，省去了构建复杂计算资源的负担。

针对cloud HPC场景，我们进行了一系列试验和探索。

我们提供fastone compute platform，让用户可以选择将应用打包成容器镜像上传，或者选择现有的已经由我们预先打包好的应用，确定分析任务，上传输入文件，像使用主流Serverless的服务一样，即可以开始运行计算任务。 

而fastone后端服务，将自动为任务选择合适的实例（GPU/CPU/FPGA），创建集群，运行任务。可以根据用户定义的成本和性能策略自动在多云中选择最经济或最佳性能的实例，在提高效率的同时大大降低了成本。

这些功能，我们都通过API的方式开放出来，HPC用户只需要调用这些API，写一个函数，上传代码到fastone平台，就可以在云上运行HPC任务。

这又何尝不是一种Serverless的尝试呢？

Serverless作为一种全新的架构，是云计算发展演化的必然结果。
追求更细粒度的计费单元，更加专注于核心业务、将支撑业务外包给基础设施提供商是云计算的趋势。

目前主流Serverless架构的特点，让编写事件触发的短时间任务变得更加容易。同时它也有自身内在的局限性，并不适合复杂的应用场景。

Serverless技术演进才刚刚开始，我们也在路上。

- END -

你也许有兴趣：