Step 1

• Poaper
• Video

题目摘要引言

Title

Boki：使用 Shared Logs 地有状态 Serverless Computing

Abstract

Boki 是一个 runtime，向 severless functions 导出 shared log。允许 severless 应用可以管理状态地存续、一致性以及容错性。

能实现高吞吐和低延时。

核心是metalog，一种用来 address ordering?（决定顺序）的新机制。

Introduction

Serverless 编程范式中的，key challenge，文章认为是：the mismatch between the stateless nature of serverless functions and the stateful applications built with them.

应用级别是有状态的，但是 serverless 函数本身是无状态的。

使用 cloud bases 来管理有状态的数据，很难在保证一致性和容错性前提下实现不错的性能和可拓展性。

shared log（这里看不是 Boki 提出的，ref 了文献 23，30，55），目前是一种流行的方法，用构建兼顾可拓展性、强一致性和容错能力的存储系统。

A shared log offers a simple abstraction: a totally ordered log that can be accessed and appended concurrently.

使用 shared log 还可以免除分布式应用的容错共识的细节，因为共识协议被隐藏在 API 中（见参考文献 22）。

文章构建的 Boki 就是一个 FaaS runtime 用以向无状态的函数暴露（exports） shared log API 来存储 shared state。 LogBook 抽象。

为了实现高性能，读一致性和 fault tolerance，处理与 Cloudburst 中提到的相似的问题，read locality 和 cache 的问题，提出了 metalog 机制。 Metalog 定义了 Boki 的内部状态的总顺序，应用程序可以用于在需要强制一致性。比如，monotonic reads 可以通过跟踪 metalog 位置来强制获得。因为 Boki 使用 metalog 的紧凑形式，持久性与一致性可以达成，但是不能获得大吞吐量。因此，Boki 使用简单的住区哦对那个设计存储和更新 Metalogs。

遵循先前的 shared log systems 设计，使用重新配置处理机器故障。因为 metalog 控制了 Boki 的内部状态迁移，密封 metalog（使之不能再写）会暂停状态转移。因此，Boki 就可以通过封存 metalog，修改系统配置，启动新的 metalog 来实现重新配置。

主要贡献：

• Boki 是一个 FaaSruntime 提供 LogBook API 帮助有状态的 serverless 应用来管理他们的状态的 durability，consistency 和 fault tolerance.
• Boki 提出了 metalog 的新机制，来确定 log ordering，读一致性和容错。metalog 分离了 LogBooks 的读写路径，使之实现高吞吐量和低延迟。
• 构建 Boki support libraries，支持库。使用 LogBook API 来说明有状态 serverless 应用 shared logs 的值。库实现了容错 workflows（BokiFlow），持久对象存储（BokiStore）和 serverless message queues（BokiQueue）
• 评估

基本理论概况

Boki 构建的使用 shared logs 机制的 runtime，对外提供 LogBooks API，并使用 metalog 来实现读一致性和容错，由于 metalog 分离了 LogBooks 的读写路径，使之实现高吞吐量和低延迟。

结论部分

继续阅读

主要目标：Serverless Computing 中的状态管理问题。

突出贡献：Boki 是第一个使用 shared logs 来允许 serverless functions 管理状态的系统。

文章的是实现和评估体现出他们在 Boki 中实现的 shared logs

回答基本问题

1. 类别

   原型系统描述

2. 内容

   对比之前阅读的 CloudBurst，Boki 的设计实现了 shared logs，这个是之前没听过的。

3. 正确性

   正确

4. 创新点

   在 Boki 成功实现了 shared logs 的 abstraction——LogBooks，并且也实现了 Serverless 所必需的 elasticity（Serverless 天然）和 data locality（为了低延时），这些都是在新的 metalog 设计上实现的。

5. 清晰度

   较为清晰

阅读选择

Step 2

细读笔记

Serverless Nature

Serverless 的天然环境，Serverless functions 是无状态的，所以状态管理问题，要么交给中间调度层，比如 Cache 和 Cache 一致性模块（类似 CloudBurst），或者完全交由存储层（cloud storage service）。后者难以提供低延迟、低开销、高吞吐。

Shared Log Approach for Stateful Serverless

云环境下的函数执行出现错误，一致性管理问题

• Write-ahead redo log: Olive, Beldi（拓展至 Transaction）
• State machine replication: 实现容错的通用方式，状态在多个机器是备份的使用共识算法计算的。通常在后台使用共识算法来进行。最近的研究表明：一个共享的 log，shared-log 可以提供更高效的抽象来支持 SMR-based 数据结构和协议。

But recent studies demonstrate a shared log can provide efficient abstraction to support SMR-based data structures and protocols.

衡量 Serverless Computing 需求，文章确定了三种 shared logs 提供解决方案的重要场合，Boki 针对这些场合提供了支持库。

• Fault-tolerant workflows: 建立提供事务状态更新，以及容错性的有状态函数工作流。 Beldi 在 DynamoDB 上构建了一个 atomic logging layer 来实现这些，Boki 采纳了 Beldi 的技术并以 LogBook API 的形式提供，无需建立额外的的 logging layer.
• Durable objectstorage: 受 Tango 和 vCorfu 等工作启发，使用 shared logs 来支持高级数据结构（比如对象）的一致性、持久化和可扩展性。
• Serverless message queues: 现有 FaaS 范式，函数无法直接彼此间沟通。Shared logs 可以很自然用来构建 message queues 来提供函数间的交流和 coordination.

Technical Challenges

• Elasticity and locality: Serverless 受益于分离，可以提供弹性/可扩展性，但是物理上的分层带来了延迟问题。
  • Boki 的解决方法：解耦读取和写入路径，将函数的读取部分放置在一起。
• Resource efficiency: 逻辑日志 LogBook 的高效利用
  • Boki 的解决方法：复用可以解决 LogBook 分布不均匀？但是带来了 LogBook 的读，如何确定 LogBook 的记录位置，引入 log index。
• ephemeral nature：FaaS 函数的 in-memory state 不被保证在调用之间保留？TODO: 这部分不太明白
  • Boki 的解决方法：使用 auxiliary data? 实现类似 Tango 的本地视图。

Booki API 解读

每个 function 在唤醒时关联一个 LogBook（由book_id确定），多个函数可以通过相同book_id共享相同的 LogBook。

遵循先前 log systems 的设计，API 提供append,read,trim操作。对应写，读，删除。

• Read consistency
• seqnum
• log tags
• auxiliary data: TODO:后面一段有提到，auxiliary data 只设计作为 cache 使用，boki 不保证它的持久性，也不 maintain 它的一致性。Boki 相信应用会为相同的 log 记录提供一致的 auxiliary data。这些弱化容许 Boki 获得一个足够简单且高效的后端来储存这些 auxiliary 数据。

Boki Design

粗略了解了 Boki 的设计思路以及提供的 API，第二遍阅读粗略浏览 Boki 的设计。

Metalog

实现 shared logs 系统的三个主要问题：

• how to determine the global total order
• how to ensure read consistency
• how to tolerate machine failures

（TODO: 个人感觉，使用 SMR 实现强一致性的系统都面临这些问题）

关注表格，Boki 对比 Scalog 和 vCorfu，其中 Scalog 在 orderring log records 和 Failure Handling 中都使用了 Paxos 协议，这是比较熟悉的，而 Boki 则都用 metalog 相关操作解决了这个问题。

所以文章中才说 metalog 提供了单一解决方案。每个 physical log 有一个单一关联的 metalog，记录内部状态转换。

每个 metalog 都被 3 个序列器储存，决定一个主序列器，控制 metalog 的 append。

Architecture

Boki拓展了

问题记录

未读（且值得读）文献记录

Shared logs 相关

• 传统的 replicated command log 到 shared log：
  • Tango: Distributed Data Structures over a Shared Log （支持 SMR-based 数据结构）
  • vCorfu: A Cloud-Scale Object Store on a Shared Log（支持 SMR-based 数据结构）
  • Virtual Consensus in Delos （支持 SMR-based 协议）
  • Log-structured Protocols in Delos（支持 SMR-based 协议）

Step 3

思路复现

证明与推理复现

实验验证复现

Video 笔记

FaaS 平台，当有状态需求时会变得复杂。

云服务商提供了多种存储服务，比如 Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service，来帮助 serverless 函数储存他们的状态（直接在存储层解决状态问题）。

In reality, service applications often compose multiple functions. For example: Service workflows.

现实中 serverless application 通常组合多个函数。比如 serverless workflows。同时每个函数也可能会在执行过程中 fail，从而引发 DB 中不一致的问题。

State consistency with fault tolerance is difficult with current infrastructure!

因而状态的一致性，并提供容错性对于这种架构来说是困难的。

以用户注册（函数 X）并参加会议（函数 Y）为例进行说明，故障可能发生在 X 执行过程中，没有向 DB 中写入新的 uid，也可能故障发生在 X 调用 Y 时，导致 Y 没有被调用。

Shared Logs: The Missing Piece in Serverless

一个常见做法。Shared logs，

• The shared log as write-ahead redo log for fault tolerance.记录了对 DB 的操控和函数的调用，当故障发生时，workflow 可以通过审查 log 了解哪些过程是完成的哪些是未完成的。

（除了 WAL，shared log 还可以用在另一个重要的服务上）那么怎样在并发的函数中维护一个 shared state 呢？The shared log for state machine replication(SMR)。在这一例子下，并发的函数会在 shared log 中并发地 append 命令，log 用来 order 这些命令，之后这些并发的函数会从 shared log 中读取命令来重新构建 state machine.

Total order provided by the shared log is 他和 source of consistency.

Boki: FaaS + Shared Logs + Support Libraries

Boki 的架构。使用先前的工作 FaaS Runtime(Nightcore ASPLOS'21)，加上 Boki Shared Logs。Boki 对外暴露 Boki's LogBook API，Serverless functions 通过调用 API 来使用 BOki Shared Logs. 作者还在最上层构建了 Boki Support Libraries（进一步简化了使用，构建了 BokiFlow，BokiStore 和 BokiQueue 中间件）.

LogBook API

A LogBook，本质上是一个 append-only log

由 seqnum（顺序号）和 data slot，还由可选的 set of tags。Tags 是用来实现选择性读，LogBook Read API 允许提供一个 tag，从而只读取包含指定 tag 的 record 记录。因此，携带有相同的 log tag 构成了全日志的逻辑子串，该特性在特定场合时会很有用。

Boki 中，每个 Serverless Function 的唤醒都会关联一个 LogBook，对于由多个函数构成的 Serverless Application，这些函数会关联相同的 logbook。这样 LogBook 就可以用来管理一致性和容错。

以上就是用户层面（user level）Log API 的使用。

Dig into Boki Shared Logs Design

已有 Shared Logs 针对 Serverless 环境面对的困难。

Serverless environment requires Boki to efficiently support diverse use patterns of shared logs.

• High Throughput
• Low Latency
• High Density
  • high density of small LogBooks