无服务器场景(serverless)的容错怎么做?我们的设计

无服务器架构和FaaS(Function-as-a-service 即服务 )近年来越来越受欢迎,这要归功于易用性、自动伸缩和按需付费的特性。然而,FaaS 基础设施中缺少应用程序的容错能力。

把坑留给码农?

默认情况下,AWS Lambda 或 Google Cloud Functions 等 FaaS 系统需要开发者自己考虑执行失败的情况。云服务的策略是:无论是应用程序自身错误还是基础设施故障,一旦函数执行失败就执行重试。这意味着函数可能会运行多次。
并且更可怕还有,你的业务代码也可能会运行 0.5 次,或者 3.2 次……这是怎么回事?
这个糟糕问题的原因是,大多数 FaaS 系统提供的能力不能保证资源层(如数据库或文件等)在执行失败后被清理。
在失败和重试的过程中,修改共享状态的应用程序会在不知不觉修改部分结果。如果一个请求将更新两个键 k 和 l,但函数在两次更新之间崩溃,那么现在客户端将看到较新版本的 k 和较旧版本的 l。
这就是云平台 FaaS 的现状。

FaaS 的无痛容错:原子性

为了避免这种类型的异常,开发人员需要一个简单的保证,那就是原子性:要么一个请求的所有操作全部成功,要么全部失败。传统做法中,原子性是由强一致性(事务式)存储引擎来保证的,但这些系统有众所周知的扩展和性能问题。如何才能让 FaaS 执行保证原子性?
为此,我们构建了一个名为 AFT(Atomicity for Fault Tolerance)的系统,它是一个位于任何无服务器计算层(如AWS Lambda、Google Cloud Functions)和存储层(如AWS DynamoDB、Redis)之间的胶 层。计算层的每个逻辑请求(可能由多个函数组成)都被视为一个事务。AFT 保证事务所做的所有更新都会在存储层原子化执行。
AFT 的设计是灵活的。我们对计算层不做任何假设,而对存储层的要求就是存储层要持久化。我们可以保证在 DynamoDB 和 S3 等最终一致的系统上运行的函数的原子性。AFT 有两个主要特点。(1)无协调、原子更新;(2)保证事务只读取已提交的数据。AFT 将每个新的key版本写到不同的物理存储位置,以避免写-写冲突。
为了保证事务读取语义上一致的数据,AFT 保证了读取原子性。读取原子性要求客户机只从已提交的事务中读取数据,并按照事务提交的顺序进行读取。也就是说,如果事务 T1 写了 key 的版本 K1,而后来的事务 T2 写了 K2 和 L2,那么客户端就读不到 K1 和 L2,因为事务 T2 写了一个较新版本的K,称为 K2。所有这些都可以在没有任何协调¹的情况下完成。这种类型的异常被称为断裂读。


在此之下,我们开发了新的协议,以确保写入是原子化更新的,同时也保证了读取的原子性。我们还开发了新的垃圾收集协议,以减轻存储系统版本化的开销。如果你有兴趣了解更多,请点击这里查看完整的论文 [1]。
我们在三个存储后端(AWS DynamoDB、AWS S3和Redis)上,用几千行 Go 代码实现了AFT及其协议。我们能够最大限度地减少(相对于直接从底层存储引擎读写)IO 开销(具体结果见论文第 6 节),AFT 可以平滑地扩展到数百个并行客户端和每秒数千个事务(见下图)的规模。同时,我们避免了没有 AFT 的情况下出现的大量异常现象。下表显示了在 10000 个事务中,读-写(事务内)和断裂读异常的频率。

下一步

我们对胶合层架构作为探索不同开发者保障的手段感到兴奋。特别是有一整类应用可以从无服务器架构中受益,但需要找到将更强的一致性引入 Faas 世界的方法。
熟悉数据库内部的朋友可能已经注意到,我们这里讲到的读取原子性保证类似于无协调版本的快照隔离,这是传统数据库中常用的强一致性形式。我们正计划在此背景下探索如何将强一致性引入到无服务器应用中。如果你对这些有兴趣可以通过原文链接反馈给我们。

原文地址:

https://medium.com/riselab/solving-serverless-computings-fault-tolerance-problem-122128fa5787

完整论文链接:

[1] https://arxiv.org/pdf/2003.06007.pdf

参考阅读:

本文由高可用架构翻译。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章