- CCFA
- Conference
- ASPLOS
- USENIX ATC
- 2022
- 1.RunD: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing
- 2.Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing
- 3.Tetris: Memory-efficient Serverless Inference through Tensor Sharing
- 2021
- 2020
- 2018
- 2022
- ISCA
- FAST
- FSE/ESEC
- SOSP
- OSDI
- NSDI
- VLDB
- INFOCOM
- ASE
- Journal
- Conference
- CCFB
- Conference
- SoCC
- 2022
- 1.Owl: performance-aware scheduling for resource-efficient function-as-a-service cloud
- 2.QFaaS: accelerating and securing serverless cloud networks with QUIC
- 3.Cypress: input size-sensitive container provisioning and request scheduling for serverless platforms
- 4.Hermod: principled and practical scheduling for serverless functions
- 5.SIMPPO: a scalable and incremental online learning framework for serverless resource management
- 6.SimLess: simulate serverless workflows and their twins and siblings in federated FaaS
- 2021
- 1.Faa$T: A Transparent Auto-Scaling Cache for Serverless Applications
- 2.Atoll: A Scalable Low-Latency Serverless Platform
- 3.Kraken: Adaptive Container Provisioning for Deploying Dynamic DAGs in Serverless Platforms
- 4.Mu: An Efficient, Fair and Responsive Serverless Framework for Resource-Constrained Edge Clouds
- 5.Mind the Gap: Broken Promises of CPU Reservations in Containerized Multi-tenant Clouds
- 6.Characterizing Microservice Dependency and Performance: Alibaba Trace Analysis
- 7.ServerMore: Opportunistic Execution of Serverless Functions in the Cloud
- 8.On Merits and Viability of Multi-Cloud Serverless
- 9.Speedo: Fast dispatch and orchestration of serverless workflows
- 10.Cloud-Scale Runtime Verification of Serverless Applications
- 2020
- 1.Wukong: a scalable and locality-enhanced framework for serverless parallel computing
- 2.Characterizing serverless platforms with serverlessbench
- 3.Photons: lambdas on a diet
- 4.Serverless linear algebra
- 5.Kappa: a programming framework for serverless computing
- 6.Sequoia: enabling quality-of-service in serverless computing
- 7.Particle: ephemeral endpoints for serverless networking
- 2019
- 2022
- CLUSTER
- ICDCS
- 2022
- 2021
- 1.Defuse: A Dependency-Guided Function Scheduler to Mitigate Cold Starts on FaaS Platforms
- 2.Gillis: Serving Large Neural Networks in Serverless Functions with Automatic Model Partitioning
- 3.Poster: Function Delivery Network: Extending Serverless to Heterogeneous Computing
- 4.A Multi-Tenant Framework for Cloud Container Services
- 2020
- EuroSys
- ICPP
- IPDPS
- HPDC
- ICWS
- Middleware
- 2021
- 2020
- 1.Prebaking Functions to Warm the Serverless Cold Start
- 2.SplitServe: Efficiently Splitting Apache Spark Jobs Across FaaS and IaaS
- 3.Sledge: a Serverless-first, Light-weight Wasm Runtime for the Edge
- 4.Fifer: Tackling Resource Underutilization in the Serverless Era
- 5.Xanadu: Mitigating cascading cold starts in serverless function chain deployments
- 2019
- HOTOS
- CRDI
- SoCC
- Journal
- Conference
- CCFC
- Conference
- HPCC
- HiPC
- CCGRID
- 2022
- 1.Pushing Serverless to the Edge with WebAssembly Runtimes
- 2.Tiny Autoscalers for Tiny Workloads: Dynamic CPU Allocation for Serverless Functions
- 3.KneeScale: Efficient Resource Scaling for Serverless Computing at the Edge
- 4.Energy-Aware Resource Scheduling for Serverless Edge Computing
- 5.On Realizing Efficient Deep Learning Using Serverless Computing
- 6.A Serverless Engine for High Energy Physics Distributed Analysis
- 7.Towards a Model-Based Serverless Platform for the Cloud-Edge-IoT Continuum
- 8.LatEst: Vertical elasticity for millisecond serverless execution
- 9.AIBLOCK: Blockchain based Lightweight Framework for Serverless Computing using AI
- 10.CASY: A CPU Cache Allocation System for FaaS Platform
- 11.Type, pad, and place: Avoiding data leaks in Cloud-IoT FaaS orchestrations
- 2021
- 1.Data-driven scheduling in serverless computing to reduce response time
- 2.Deadline-aware Dynamic Resource Management in Serverless Computing Environments
- 3.Benchmarking Serverless Workloads on Kubernetes
- 4.Algorithms for scheduling scientific workflows on serverless architecture
- 5.High Performance Serverless Architecture for Deep Learning Workflows
- 6.A Reinforcement Learning Approach to Reduce Serverless Function Cold Start Frequency
- 7.AI-based Resource Allocation: Reinforcement Learning for Adaptive Auto-scaling in Serverless Environments
- 8.Scheduling Containers Rather Than Functions for Function-as-a-Service
- 9.Virtual Device Model extending NGSI-LD for FaaS at the Edge
- 10.QoS aware FaaS platform
- 2020
- 2019
- 2022
- ICPADS
- Journal
- Conference
- Others
摘要截止日期 2022.10.20
2022.2.28-3.14
有专门的关于 serverless 的会议主题
摘要：
无服务器计算是一种新兴的计算模式，它依赖于在预期执行前的 "预热 "函数，以便为用户提供更快、更经济的服务。不幸的是，预热函数可能是不准确的，并且在预热期间会产生令人望而却步的昂贵成本（即函数保活成本）。在本文中，我们介绍了 IceBreaker，这是一种新颖的技术，通过用异构节点（昂贵和便宜）组成系统来减少服务时间和 "保活 "成本。IceBreaker 的做法是，根据函数的时间变化概率，动态地确定在具有成本效益类型的节点来预热函数。通过采用异构性，IceBreaker 允许在相同的成本预算下拥有更多数量的节点，因此可以保活更多数量的函数，并减少高负载时的等待时间。我们的实际系统评估证实，IceBreaker 使用具有代表性的无服务器应用程序和行业级工作负载跟踪，将整体保持不变的成本降低了 45％，执行时间降低了 27％。IceBreaker 是第一个采用并利用昂贵和便宜节点混合的想法来改善无服务器函数的服务时间和保持成本的技术--为研究人员和从业者开辟了一条在异构服务器上进行无服务器计算的新研究途径。
摘要：
现代网站越来越依赖机器学习（ML）来提高其业务效率。开发和维护 ML 服务会给开发者带来高昂的成本。虽然无服务器系统是一个很有前途的降低成本的解决方案，但我们发现目前的通用无服务器系统不能满足 ML 服务的低延迟、高吞吐量的需求。
虽然简单地 "修补 "通用无服务器系统并不能完全解决这个问题，但我们建议这样的系统应该将推理的特点与无服务器范式天然地结合起来。我们提出了 INFless，这是第一个针对 ML 领域的无服务器平台。它在 CPU 和加速器之间提供了一个统一的、异构的资源抽象，并利用内置的批处理和非统一的扩展机制实现了高吞吐量。它还通过协调管理批处理排队时间、执行时间和冷启动率支持低延迟。我们使用本地集群测试平台和大规模模拟来评估 INFless。实验结果表明，INFless 在系统吞吐量上优于最先进的系统 2-5 倍，满足了 ML 服务的延时目标。
摘要：
无服务器计算（Function-as-a-Service）通过在容器中运行函数（或 Lambda）提供细粒度的资源共享。依赖于数据的函数需要按照预先定义的逻辑进行调用，这就是所谓的无服务器工作流。然而，我们的调查显示，传统的基于 master-worker 工作流执行架构在无服务器背景下表现不佳。master-worker 工作流调度模式导致了一项重大开销，其中函数在主节点中触发并分配给工作节点执行。此外，worker 之间的数据移动也降低了吞吐量。
为此，我们提出了一种用于无服务器工作流执行的 worker-side 工作流计划模式。根据该设计，我们实现了 FaaSFlow，以便在无服务器环境下实现高效的工作流执行。此外，我们提出了一个自适应存储库 FaaStore，它能够在同一节点上的函数之间快速传输数据，而无需通过数据库。实验结果表明，FaaSFlow 有效地将工作流调度开销平均降低了 74.6%，数据传输开销最多降低了 95%。当网络带宽波动时，FaaSFlow-FaaStore 可以减少 23.0% 的吞吐量下降，并且能够使网络带宽的利用率提高 1.5-4 倍。
摘要：
现有的无服务器计算平台是建立在同构计算机基础上的，限制了函数密度，并将无服务器计算限制在有限的场景中。我们介绍Molecule，这是第一个利用异构计算机的无服务器计算系统。Molecule 使通用设备（如 Nvidia DPU）和特定领域的加速器（如 FPGA 和 GPU）都能用于无服务器应用，从而显著提高函数密度（高出 50%）和应用性能（高达 34.6 倍）。为了实现这些结果，我们首先提出了 XPU-Shim，这是一个分布式的 Shim，用于弥补底层多操作系统（当使用通用设备时）和我们的无服务器运行时间（即 Molecule）之间的差距。我们进一步介绍了矢量化沙箱，这是一种抽象硬件异构性的沙箱抽象（当使用特定领域的加速器时）。此外，我们还回顾了关于启动和通信延迟的最先进的无服务器优化，并克服了在异构计算机上实现这些优化的挑战。我们已经在实际平台上用 Nvidia DPU 和 Xilinx FPGA 实现了 Molecule，并使用基准和实际应用对其进行了评估。
研讨会
2021.4.19-4.23
1.Nightcore: efficient and scalable serverless computing for latency-sensitive, interactive microservices
摘要：
微服务架构是一种流行的软件工程方法，用于构建灵活的大规模在线服务。无服务器计算或者函数计算提供了一个简单的无状态函数编程模型，它是实现微服务的无状态 RPC 处理程序的自然基础，是容器化 RPC 服务器的替代方案。但是，当前的无服务器平台具有毫秒级的运行时开销，使其无法满足现有交互式微服务所需的严格的亚毫秒级延迟目标。
我们展示了 Nightcore，这是一个具有微秒级开销的无服务器函数运行时，可在函数之间提供基于容器的隔离。Nightcore 的设计仔细考虑了具有微秒级开销的各种因素，包括函数请求的调度、通信原语、I/O 的线程模型和并发函数执行。 Nightcore 目前支持用 C/C++、Go、Node.js 和 Python 编写的无服务器函数。我们的评估表明，在运行延迟敏感的交互式微服务时，Nightcore 实现了 1.36–2.93 倍更高的吞吐量和高达 69% 的尾部延迟减少。
摘要：
函数即服务（也称为无服务器计算）有望彻底改变应用程序使用云资源的方式。但是，由于在开始执行之前初始化其代码和数据依赖关系的开销，函数会遇到冷启动问题。在函数完成执行后保活函数可以减轻冷启动开销。Keep-alive 策略必须根据函数的资源和使用特性保持函数处于活动状态，由于 FaaS 工作负载的多样性，这具有挑战性。
我们的见解是，keep-alive 类似于缓存。与当前方法相比，我们受缓存启发的 Greedy-Dual keep-alive 策略可以有效地将冷启动开销减少 3 倍以上。重用距离和命中率曲线等缓存概念也可用于自适应的服务器资源配置，这可以将 FaaS 提供商对现实世界动态工作负载的资源需求降低 30%。我们在基于 OpenWhisk 的 FaasCache 系统中实施基于缓存的保活和资源配置策略。我们希望我们的缓存类比为未来的 FaaS 工作负载和平台打开了更多原则和优化的保活和资源配置技术的大门。
摘要：
无服务器计算因其高可扩展性和灵活的即用即付计费模式而被迅速采用。在无服务器中，开发人员将他们的服务构建为一组函数，由各种事件（如点击）零星地调用。函数调用的时间间隔变化很大，致使提供者在每次调用时都要启动新的函数实例，从而导致严重的冷启动延迟，降低了用户体验。为了减少冷启动延迟，业界已转向快照，即在磁盘上存储一个完全启动的函数的镜像，与从头开始启动函数相比，调用速度更快。
这项工作引入了 vHive，这是一个用于无服务器实验的开源框架，旨在使研究人员能够在整个无服务器堆栈中进行研究和创新。使用 vHive，我们描述了一个最先进的基于快照的无服务器基础设施，它基于业界领先的 Containerd 协调框架和 Firecracker 管理程序技术。我们发现从快照开始的函数的执行时间平均比同一个函数驻留在内存时高 95%。我们表明高延迟归因于频繁的缺页故障，因为函数的状态一次一页地从磁盘进入客户内存。我们的分析进一步表明，在同一函数的不同调用中，函数访问的是相同的稳定工作页面集。通过利用这一洞察，我们**构建了 REAP，这是一种用于无服务器主机的轻量级软件机制，它可以记录函数的客户内存页的稳定工作集，并主动将其从磁盘预取到内存中。**与基线快照相比，REAP 将冷启动延迟平均减少了 3.7 倍。
2020.3.18-3.20
摘要：
无服务器计算为高效软件开发提供了成本效益和弹性。要实现这一点，**Serverless 沙箱系统必须解决两个挑战：函数实例之间的强隔离，以及低启动延迟以保证用户体验。**虽然基于虚拟化的沙箱可以提供强隔离，但沙箱和应用程序的初始化会导致不可忽略的启动开销。传统沙箱系统由于其与应用程序无关的特性而在低延迟启动方面存在不足：它们只能通过管理程序和客户内核的定制来减少沙箱初始化的延迟，这是不充分的，不能缓解大部分的启动开销。
本文提出了 Catalyzer，一种无服务器沙箱系统设计，提供强大的隔离和极快的函数启动。 Catalyzer 不是从头开始启动，而是从一个形式良好的检查点镜像中恢复一个基于虚拟化的函数实例，从而跳过关键路径上的初始化（无初始化）。Catalyzer 通过按需恢复用户级内存状态和系统状态来提高恢复性能。我们还提出了一个新的 OS 原语 sfork（沙箱分叉），通过直接重用正在运行的沙箱实例的状态来进一步减少启动延迟。从根本上说，Catalyzer 通过重用状态消除了初始化成本，从而实现了对各种无服务器函数的一般优化。评估表明，Catalyzer 将启动延迟降低了几个数量级，在最佳情况下实现了 < 1ms 的延迟，并显着降低了实际工作负载的端到端延迟。 Catalyzer 已被蚂蚁金服采用，我们也分享了产业发展的经验教训。
该会议只有 2020 年之后才陆陆续续收录有关 serverless 的文章，之前的年限里是没有这方面的文章的
摘要截止日期 2023.01.05
2022.7.11-7.13
1.RunD: A Lightweight Secure Container Runtime for High-density Deployment and High-concurrency Startup in Serverless Computing
在微型虚拟机（VM）中承载单个容器的安全容器现在被用于无服务器计算，容器是通过微型虚拟机隔离的。由于无服务器平台中的用户函数是细粒度的，因此对高密度的容器部署和高并发的容器启动有很高的要求，以提高资源利用率和用户体验。我们的调查显示，整个软件堆栈，包括**主机操作系统中的 cgroup、来宾操作系统和用于函数工作负载的容器 rootfs，共同导致了低部署密度和高并发时的慢启动性能。**因此，我们提出并实现了一个轻量级的安全容器运行时，命名为 RunD，通过一个整体的 guest-to-host 的解决方案来解决上述问题。通过 RunD，在一秒钟内可以启动超过 200 个安全容器，在一个拥有 384GB 内存的节点上可以部署超过 2500 个安全容器。采用 RunD 作为阿里巴巴无服务器容器运行时，支持高密度部署和高并发的启动。
2.Help Rather Than Recycle: Alleviating Cold Startup in Serverless Computing Through Inter-Function Container Sharing
在无服务器计算中，每个函数的调用都是在容器（或虚拟机）中执行的，而容器的冷启动会导致长时间的响应延迟。我们**观察到，一些函数受到容器冷启动的影响，而其他函数的温暖容器则处于闲置状态。基于这一观察，除了为一个函数从头开始启动一个新的容器外，我们建议通过重新利用另一个函数的温暖但闲置的容器来缓解冷启动的影响。**我们实现了一个容器管理方案，名为 Pagurus，以实现这一目的。Pagurus 包括一个函数内管理器，用于将闲置的热容器替换成其他函数可以使用的容器，而不引入额外的安全问题；一个函数间调度器，用于在函数间调度容器；以及一个集群级的共享感知函数平衡器，用于平衡不同节点的工作负载。使用 Azure 无服务器追踪的实验表明，Pagurus 减轻了 84.6% 的冷启动，如果减轻了冷启动延迟，则从数百毫秒减少到 16 毫秒。
执行复杂的、内存密集型的深度学习推理服务对无服务器计算框架是一个重大挑战，它将密集地部署和维护推理模型的高吞吐量。我们观察到无服务器推理系统中由于大尺寸模型和高数据冗余而导致的过度内存消耗问题。
我们提出了 Tetris，这是一个迎合推理服务的无服务器平台，它的内存占用率要低一个数量级。Tetris 的设计仔细考虑了运行时和张量的广泛内存共享。它支持通过批处理和并发执行的组合优化来最小化运行时冗余，并使用轻量级和安全的张量映射机制来消除来自相同或不同函数的实例之间的张量冗余。我们的综合评估表明，Tetris 为推理服务节省了高达 93% 的内存占用，并在不影响延迟的情况下将函数密度提高了 30 倍。
2021.7.14-7.16
摘要：
数据分析应用程序越来越多地利用无服务器执行环境，因为它们易于使用，而且随用随付。这类应用的结构通常由多个函数组成，这些函数被串联起来形成一个工作流。当前在函数之间交换中间（临时）数据的方法是通过远程存储（例如 S3），这会引入显着的性能开销。我们比较了三种数据传递方法，我们称之为 VM-Storage、Direct-Passing 和 state-of-practice Remote-Storage。至关重要的是，我们表明，没有一种单一的数据传递方法在所有场景下都占主导地位，最优选择取决于动态因素，例如输入数据的大小、中间数据的大小、应用程序的并行度和网络带宽。我们提出了 **SONIC，一种优化应用程序性能和成本的数据传递管理器，通过为无服务器工作流 DAG 的每个边缘透明地选择最佳数据传递方法并实现通信感知函数放置。SONIC 监控应用程序参数并使用简单的回归模型来相应地调整其混合数据传递。**我们将 SONIC 与 Open-Lambda 集成，并使用在无服务器环境中流行的三个分析应用程序评估 Amazon EC2 上的系统。与四个基准相比，SONIC 在各种条件下提供更低的延迟（原始性能）和更高的性能/美元：SAND、vanilla OpenLambda、OpenLambda with Pocket 和 AWS Lambda。
【以上三种方法在文件大小，并行度、网络带宽不同的情况下分别是最优方法，优先考虑 VM，不可行或牺牲并行性的情况下考虑另外两种，如果并行度低，网络带宽小考虑直接传输，并行度高、网络带宽大考虑远程调用。】
2.FaaSNet: Scalable and Fast Provisioning of Custom Serverless Container Runtimes at Alibaba Cloud Function Compute
摘要：
无服务器计算或函数即服务 (FaaS) 通过允许用户部署细粒度函数，同时提供完全托管的资源配置和自动扩展，实现了一种构建和扩展应用程序的新方式。自定义 FaaS 容器支持越来越受欢迎，因为它可以更好地控制操作系统、版本控制和工具，以实现 FaaS 应用程序的现代化。然而，提供快速的容器配置给 FaaS 提供商带来了不小的挑战，因为容器配置成本高昂，而且现实世界的 FaaS 工作负载表现出高度动态的模式。
在本文中，我们设计了 FaaSNet，这是一个用于加速 FaaS 容器配置的高度可扩展的中间件系统。 FaaSNet 由全球最大的云提供商之一阿里云函数计算的 FaaS 平台的工作负载和基础设施要求驱动。FaaSNet 通过轻量级的自适应函数树 (FT) 结构实现可扩展的容器配置。FaaSNet 使用高效的 I/O 按需获取机制来进一步大规模降低配置成本。我们在阿里云函数计算中实现并集成了 FaaSNet。评估结果表明，FaaSNet：（1）在 8.3 秒内完成在 1000 个虚拟机上配置 2500 个函数容器，（2）扩展速度比阿里云当前的 FaaS 平台和最先进的 P2P 容器注册中心 (Kraken) 快 13.4 倍和 16.3 倍 和 (3) 维持突发工作负载的时间比优化基线少 75.2%。
摘要：
在 FaaS 工作流中，一组函数通过相互交互和交换数据来实现应用程序逻辑。现代 FaaS 平台在单独的容器中执行工作流的每个函数。当工作流中的函数交互时，产生的延迟会减慢执行速度。
Faastlane 通过努力将工作流的函数作为线程在容器实例的单一进程中执行，从而最大限度地减少了函数交互延迟，这通过简单的加载/存储指令简化了数据共享。对于操作敏感数据的 FaaS 工作流，Faastlane 使用英特尔内存保护密钥（MPK）提供轻量级的线程级隔离域。虽然线程便于共享，但 Python 和 Node.js 等语言的实现（广泛用于 FaaS 应用程序）不允许线程的并发执行。Faastlane 动态地识别 FaaS 工作流中的并行机会，分叉进程（而不是线程）或产生新的容器实例，以并发执行工作流的并行函数。
我们在 Apache OpenWhisk 上实现了 Faastlane，并表明它将工作流实例的速度提高了 15 倍，与 OpenWhisk 相比，将函数交互延迟降低了 99.95%。
2020.7.15-7.17
1.Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider
摘要：
函数即服务（FaaS）作为一种在云中向无服务器后端部署计算的方式，已经越来越受欢迎。这种模式将分配和配置资源的复杂性转移给了云提供商，云提供商必须以尽可能低的资源成本提供永远可用的资源的假象（即没有冷启动的快速函数调用）。这样做需要供应商深入了解 FaaS 工作负载的特点。不幸的是，关于这些特征的公开信息几乎没有。因此，在本文中，我们首先描述了 Azure Functions 的整个生产型 FaaS 工作负载的特点。我们举例说明，大多数函数被调用的频率很低，但调用频率有 8 个数量级的范围。通过观察我们的特征，我们提出了一个实用的资源管理策略，该策略可以大大减少函数冷启动的次数，同时花费的资源也比现行的策略少。
摘要：
无服务器计算非常适用于大数据处理，因为它可以快速而廉价地扩展到成千上万的并行函数。现有的无服务器平台将函数隔离在短暂的、无状态的容器中，防止它们直接共享内存。这迫使用户反复复制和序列化数据，增加了不必要的性能和资源成本。我们认为需要一种新的轻量级隔离方法，它支持函数之间直接共享内存，并减少资源开销。
我们介绍了**Faaslets，这是一种用于高性能无服务器计算的新隔离抽象。Faaslets 使用 WebAssembly 提供的 \emph{software-fault isolation} (SFI) 隔离已执行函数的内存，同时允许内存区域在同一地址空间的函数之间共享。因此，当函数在同一台机器上共存时，Faaslets 可以避免昂贵的数据移动。**我们的 Faaslets 的运行时间 Faasm 使用标准的 Linux cgroups 隔离其他资源，例如 CPU 和网络，并为网络、文件系统访问和动态加载提供低级别的 POSIX 主机接口。为了减少初始化时间，Faasm 从已经初始化的快照中恢复 Faaslets。我们将 Faasm 与一个标准的基于容器的平台进行了比较，结果表明，在训练机器学习模型时，它实现了 2 倍的加速，同时内存减少了 10 倍；为了服务于机器学习推理，Faasm 将吞吐量翻了一番，并将尾部延迟降低了 90%。
原文摘要就是 \emph{software-fault isolation} (SFI)
2019 年没有和 serverless 相关的内容
2018.7.11-7.13
无服务器计算承诺为应用程序提供成本节约和极致弹性。不幸的是，缓慢的应用和容器初始化会损害无服务器平台上的常见延迟。在这项工作中，我们分析了 Linux 容器原语，确定了与存储和网络隔离有关的可扩展性瓶颈。我们还分析了 GitHub 上的 Python 应用程序，并表明导入许多流行的库会使启动时间增加约 100ms。基于这些发现，我们实现了SOCK，一个为无服务器工作负载优化的容器系统。小心避免了内核的可扩展性瓶颈，使 SOCK 的速度比 Docker 提高了 18 倍。一个广义的 Zygote 配置策略产生了额外的 3 倍速度。基于 Zygotes 的更复杂的三层缓存策略使 SOCK 的速度比没有 Zygotes 的 SOCK 提高了 45 倍。相对于 AWS Lambda 和 OpenWhisk，在一个图像处理案例研究中，带有 SOCK 的 OpenLambda 分别减少了 2.8 倍和 5.3 倍的平台开销。
无服务器计算是一种新兴的范式，其中应用程序的资源配置和扩展由第三方服务管理。例子包括 AWS Lambda、Azure Functions 和 Google Cloud Functions。在这些服务易于使用的 API 背后是不透明的、复杂的基础设施和管理生态系统。我们从无服务器客户的角度出发，进行了迄今为止最大规模的测量研究，在这三种服务中启动了超过 5 万个函数实例，以描述其架构、性能和资源管理效率。我们解释了这些平台如何使用虚拟机或容器来隔离不同账户的函数，这具有重要的安全意义。我们从可扩展性、冷启动延迟和资源效率等方面来描述性能，重点包括 AWS Lambda 采用类似 bin-packing 的策略来最大化虚拟机的内存利用率，在 AWS 和 Azure 中可能出现函数之间的严重争用，以及谷歌有允许客户免费使用资源的 bug。
无服务器计算框架允许用户以高弹性和细粒度的资源计费启动数千个并发任务，而无需显式管理计算资源。虽然在物联网和网络微服务方面已经取得了成功，但人们对利用无服务器计算来运行数据密集型工作（如交互式分析）的兴趣越来越大。在无服务器平台上运行分析工作负载的一个关键挑战是使不同执行阶段的任务能够通过共享数据存储在彼此之间有效地交流数据。在本文中，我们探讨了不同的云存储服务（如对象存储和分布式缓存）作为无服务器分析的远程存储的适用性。我们的分析得出了指导无服务器云存储系统设计的关键见解，包括 Flash 存储的性能和成本效益，以满足无服务器应用的要求，以及需要一种按需付费的存储服务，以支持高度并行应用的高吞吐需求。
无服务器计算已经成为一种新的云计算范式，在这种范式中，一个应用由可以单独管理和执行的各个函数组成。然而，现有的无服务器平台通常在独立的容器中隔离和执行函数，并不利用函数之间的相互作用来提高性能。这些做法导致了函数执行的高启动延迟和低效的资源使用。本文介绍了 SAND，一个新的无服务器计算系统，它比现有的无服务器平台具有更低的延迟、更好的资源效率和更大的弹性。为了实现这些特性，**SAND 引入了两项关键技术。1）应用层面的沙箱 2）分层的消息总线。**我们已经实现并部署了一个完整的 SAND 系统。我们的结果表明，SAND 的性能明显优于最先进的无服务器平台。例如，在一个常用的图像处理应用中，与 Apache OpenWhisk 相比，SAND 实现了 43% 的速度提升。
2021.6.14-6-18
摘要：
无服务器计算已经成为现代云计算中的一个事实。无服务器函数可能会处理来自客户端的敏感数据。使用硬件 enclave 保护这样的函数不受不信任的云的影响，对用户的隐私有吸引力。在这项工作中，我们在 SGX enclave 中运行现有的无服务器应用程序，并观察到性能下降可高达 5.6 倍，甚至 422.6 倍。我们的调查发现，这些减速与架构特征有关，主要来自于分页的 enclave 初始化。利用我们对开销分析的洞察力，我们重新审视了 SGX 的硬件设计，并对其 enclave 模型做了最小的修改。我们用一个新的基元 - 区域 - 插件 enclave 来扩展 SGX，这些 enclave 可以被映射到现有的 enclave 中，以重用各函数之间已被证实的共同状态。通过重新映射插件 enclave，enclave 允许就地处理，以避免函数链中昂贵的数据移动。实验表明，我们的设计将飞地函数的延迟降低了 94.74-99.57%，并将自动缩放的吞吐量提高了 19-179 倍。
摘要：
互联网规模的网络应用正变得越来越存储密集，并在很大程度上依赖于内存中的对象缓存以达到所需的 I/O 性能。我们认为，新兴的无服务器计算范式为对象缓存提供了一个非常合适的、具有成本效益的平台。我们提出了 InfiniCache，这是第一个完全建立并部署在无服务器函数之上的内存中对象缓存系统。InfiniCache 利用并协调了无服务器函数的内存资源，以实现弹性的按使用量付费的缓存。InfiniCache 的设计结合了擦除编码、智能计费持续时间控制和高效的数据备份机制，以最大化数据可用性和成本效益，同时平衡丢失缓存状态和性能的风险。我们在 AWS Lambda 上实现了 InfiniCache，并表明它。(1) 与 AWS ElastiCache 相比，在仅有大对象的生产工作负载中，实现了 31-96 倍的租户方成本节约，(2) 可以有效地在每个一小时的窗口中提供 95.4% 的数据可用性，(3) 实现了典型内存缓存中看到的比较性能。
2021.8.23-28
摘要：
无服务器计算是一种新兴的云计算范式，在视频处理和机器学习等广泛的应用中获得了关注。这种新范式可以让开发者在函数的粒度上专注于基于 serverless 计算的应用（简称 serverless-based applications）的逻辑开发，从而将开发者从繁琐且容易出错的基础设施管理中解放出来。同时，也给基于 serverless 的应用的设计、实现和部署带来了新的挑战，目前的 serverless 计算平台还远远不能令人满意。然而，据我们所知，这些挑战尚未得到很好的研究。为了填补这一知识空白，**本文首次全面研究了从开发人员的角度理解开发基于无服务器的应用程序所面临的挑战。我们从 Stack Overflow（开发者热门问答网站）中挖掘和分析了 22,731 个相关问题，展示了无服务器计算的日益流行趋势和开发者的高难度水平。**通过对 619 个抽样问题的人工检查，我们构建了开发人员遇到的挑战的分类，并报告了一系列发现和可操作的含义。包括应用程序开发人员、研究人员和云提供商在内的利益相关者可以利用这些发现和影响来更好地理解和进一步探索无服务器计算范式。
摘要：
DevOps 在跨职能团队中统一软件开发和运营，以提高软件交付和运营 (SDO) 性能。理想情况下，跨职能的 DevOps 团队独立部署他们的服务，但一个服务的正确运行往往需要其他服务，需要协调以确保正确的部署顺序。此问题目前通过集中部署或跨团队的手动带外通信（例如，通过电话、聊天或电子邮件）来解决。不幸的是，两者都与团队的独立性相矛盾，阻碍了 SDO 的性能——这也是 DevOps 最初被采用的原因。
在这项工作中，我们对 73 位 IT 专业人员进行了一项研究，结果表明，在实践中，即使他们希望通过完全自动化的方法获得更好的 SDO 性能，他们也会通过手动协调来进行正确的部署。**为了解决这个问题，我们提出了 µs ([mju:z] “muse”)，这是一种新颖的 IaC 系统，以完全去中心化的方式自动化部署协调，与今天的解决方案相比，仍然保持与 DevOps 实践的兼容性。**我们实现了 µs，证明它有效地实现了自动化协调，引入了可忽略的定义开销，没有性能开销，并且广泛适用，如 64 个第三方 IaC 项目的迁移所示。
2021.10.26-29
摘要：
Boki 是一个新的无服务器运行时，它将共享日志 API 导出到无服务器函数。Boki 共享日志使有状态的无服务器应用程序能够以持久性、一致性和容错性来管理其状态。Boki 共享日志实现了高吞吐量和低延迟。关键促成因素是 metalog，这是一种允许 Boki 独立处理排序、一致性和容错的新机制。metallog 以高吞吐量对共享日志记录进行排序，并提供读取一致性，同时允许服务提供商以不同方式优化共享日志的写入和读取路径。为了展示共享日志对有状态无服务器应用程序的价值，我们构建了 Boki 支持库来实现容错工作流、持久对象存储和消息队列。我们的评估表明，共享日志可以将重要的无服务器工作负载加速高达 4.7 倍。
摘要：
无服务器计算因其易于编程、快速弹性和细粒度计费而变得越来越流行。但是，无服务器提供商仍需要为托管其平台的虚拟机 (VM) 配置、管理和支付 IaaS 提供商的费用。这将无服务器平台的成本与底层虚拟机的成本联系在一起。显着降低成本的一种方法是使用备用资源，云供应商以大幅折扣租用这些资源。 Harvest VM 提供了如此廉价的资源：它们会增长和缩小以获取主机服务器中所有未分配的 CPU 内核，但可能会被驱逐以腾出空间容纳更昂贵的 VM。因此，使用 Harvest VM 运行无服务器平台会带来两个必须小心管理的主要挑战：VM 驱逐和每个 VM 中动态变化的资源。
在这项工作中，我们探讨了在 Harvest VM 上托管无服务器（函数即服务或简称 FaaS）平台的挑战和好处。我们描述了 Microsoft Azure 的无服务器工作负载和 Harvest VM，并设计了一个无服务器负载均衡器，它可以感知 Harvest VM 中的驱逐和资源变化。我们修改了广泛使用的开源无服务器平台 OpenWhisk，以监控收获的资源并相应地平衡负载，并对其进行实验评估。我们的结果表明，采用收获的资源可以提高效率并降低成本。在相同的成本预算下，与使用专用资源相比，在收获的资源上运行无服务器平台可实现 2.2 到 9.0 倍的吞吐量。在使用相同数量的资源时，由于更好的负载平衡，在收获的资源上运行无服务器平台可以节省 48% 到 89% 的成本，同时延迟更低。
摘要：
无服务器函数的快速配置对于无服务器平台来说非常重要。尽管轻量级沙箱（例如容器）仅包含必要的文件和库，但冷启动仍需要最多几秒钟才能完成。这种缓慢的配置会延长无服务器函数的响应时间，并对用户体验产生负面影响。本文分析了这种放缓的主要原因，并介绍了一个有效的容器化框架 FlashCube。FlashCube 不是从头开始构建容器，而是通过一组预先创建的通用容器部件（例如，命名空间、cgroup 和语言运行时）快速有效地组装它。此外，FlashCube 的用户空间实现使其轻松适用于现有的商品无服务器平台。我们的初步评估表明，FlashCube 可以在不到 10 毫秒的时间内快速配置容器化函数（而使用 Docker 容器的时间约为 400 毫秒）。
2021.07.14-16
1.Dorylus: Affordable, Scalable, and Accurate GNN Training with Distributed CPU Servers and Serverless Threads
摘要：
图神经网络 (GNN) 支持对结构化图数据进行深度学习。有两个主要的 GNN 训练障碍：1）它依赖于具有许多 GPU 的高端服务器，这些 GPU 的购买和维护成本很高，以及 2）GPU 上有限的内存无法扩展到当今的十亿边图。**本文介绍了 Dorylus：一种用于训练 GNN 的分布式系统。独特的是，Dorylus 可以利用无服务器计算以低成本提高可扩展性。 **
指导我们设计的关键见解是计算分离。计算分离使得构建一个深度的、有界的异步管道成为可能，其中图和张量并行任务可以完全重叠，有效地隐藏了 Lambdas 引起的网络延迟。在数千个 Lambda 线程的帮助下，Dorylus 将 GNN 训练扩展到十亿边图。目前，对于大型图，CPU 服务器提供的每美元性能优于 GPU 服务器。与仅使用 CPU 服务器进行训练相比，仅在 CPU 服务器上使用 Lambda 可提供高达 2.75✕ 的每美元性能。具体来说，对于海量稀疏图，Dorylus 比 GPU 服务器快 1.22✕，便宜 4.83✕。与现有的基于采样的系统相比，Dorylus 的速度提高了 3.8✕，成本降低了 10.7✕。
2020.11.04-06
摘要：
本文介绍了 Beldi，这是一个用于编写和组合容错和事务有状态无服务器函数的库和运行时系统。 Beldi 在现有提供商上运行，允许开发人员编写需要容错和事务语义的复杂有状态应用程序，而无需处理负载 平衡或维护虚拟机等任务。Beldi 的贡献包括使用新的数据结构、事务协议、函数调用和垃圾收集扩展 Olive (OSDI 2016) 中基于日志的容错方法。它们还包括调整生成的框架以在每个无服务器函数对其自己 的数据拥有主权的联合环境中工作。我们在 Beldi 上实现了三个应用程序，包括电影评论服务、旅行预 订系统和社交媒体网站。我们对 1,000 个 AWS Lambda 的评估表明，Beldi 的方法有效且经济实惠。
摘要：
无服务器平台促进了透明的资源弹性和细粒度的计费，使其成为数据分析的一个有吸引力的选择。我们发现，以服务器为中心的分析框架通常通过作业间调度策略来优化作业完成时间（JCT）、资源利用率和隔离度，而无服务器分析则需要对 JCT 和执行成本进行优化，从而引入了一个新的调度问题。我们提出了Caerus，一个用于无服务器分析框架的任务调度器，它采用了细粒度的 NIMBLE 调度算法来解决这个问题。NIMBLE 在工作中有效地对任务执行进行管道化，使执行成本最小化，同时在任意分析工作的成本和 JCT 之间达到帕累托最优。为此，NIMBLE 建立了广泛的执行参数模型----可管道和不可管道的数据依赖关系、数据生成、消耗和处理率等。--- 以确定理想的任务启动时间。我们的评估结果表明，在实践中，Caerus 能够为各种分析工作负载的查询实现最佳成本和 JCT。
摘要：
无服务器容器和函数被广泛用于在云中部署和管理软件。它们的流行是由于降低了运营成本，提高了硬件的利用率，以及比传统部署方法更快的扩展性。无服务器应用的经济性和规模要求来自多个客户的工作负载在同一硬件上运行，开销最小，同时保持强大的安全性和性能隔离。传统观点认为，可以在安全性强、开销大的虚拟化和安全性弱、开销小的容器技术之间做出选择。这种权衡对公共基础设施供应商来说是不可接受的，他们既需要强大的安全性，又需要最小的开销。为了满足这一需求，我们开发了Firecracker，这是一个新的开源虚拟机监控器（VMM），专门用于无服务器工作负载，但在合理的约束条件下，一般对容器、函数和其他计算工作负载有用。我们已经在 AWS 的两个公开的无服务器计算服务（Lambda 和 Fargate）中部署了 Firecracker，它支持数百万的生产工作负载，每月有数万亿的请求。我们描述了无服务器的专业性如何影响了 Firecracker 的设计，以及我们从将 AWS Lambda 客户无缝迁移到 Firecracker 中所学到的东西。
摘要：
无服务器计算正准备实现透明弹性和毫秒级定价的长期承诺。为了实现这一目标，服务提供商强加了一个细粒度的计算模型，每个函数都有一个最大的持续时间，有固定的内存量，没有持久的本地存储。我们观察到，无服务器的细粒度弹性是实现一般计算（如分析工作负载）高利用率的关键，但由于资源限制，这类应用需要在时间上不重叠的函数之间移动大量数据，因此实施起来很有挑战性。在本文中，我们介绍了 Locus，一个无服务器的分析系统，它将（1）廉价但缓慢的存储与（2）快速但昂贵的存储明智地结合起来，以实现良好的性能，同时保持成本效益。Locus 应用一个性能模型来指导用户选择存储的类型和数量，以实现理想的成本 - 性能权衡。我们在一些分析应用上评估了 Locus，包括 TPC-DS、CloudSort、Big Data Benchmark，并表明 Locus 可以驾驭性价比的权衡，与仅有慢速存储的基线相比，性能提高了 4 倍 -500 倍，减少了高达 59% 的资源使用，同时在一个虚拟机集群上实现了相当的性能，与 Redshift 相比，慢了 1.99 倍。
摘要：
函数即服务（FaaS）平台和 "无服务器 "云计算正变得越来越流行。目前的 FaaS 产品针对的是无状态函数，这些函数做最小的 I/O 和通信。我们认为，无服务器计算的好处可以扩展到更广泛的应用和算法。我们介绍了Cloudburst 的设计和实现，这是一个有状态的 FaaS 平台，提供熟悉的 Python 编程，具有低延迟的可变状态和通信，同时保持无服务器计算的自动扩展优势。Cloudburst 通过利用 Anna（一个自动扩展的键值存储）来实现这一目标，该存储用于状态共享和叠加路由，并与函数执行器共同定位的可变缓存来实现数据定位。性能良好的缓存一致性是该架构的一个关键挑战。为此，Cloudburst 为分布式会话一致性提供了格子封装的状态和新的定义及协议的组合。基准测试和各种应用的实证结果表明，Cloudburst 使有状态的函数变得实用，将当前 FaaS 平台的状态管理开销降低了几个数量级，同时也改善了无服务器一致性方面的技术水平。
摘要：
在无服务器模式中，用户将应用代码上传到云平台，云提供商承担应用的部署、执行和扩展，将用户从所有操作环节中解脱出来。尽管非常流行，但目前的无服务器产品对本地应用状态的管理提供了很差的支持，主要原因是管理状态并在大规模下保持一致是非常具有挑战性的。因此，无服务器模型对于执行有状态的、延迟敏感的应用来说是不够的。在本文中，我们提出了一个高层次的编程模型，用于开发有状态的函数并将其部署在云中。我们的编程模型允许函数保留状态以及调用其他函数。为了在云基础设施中部署有状态的函数，我们将函数和它们的数据交换转换为有状态的数据流图。通过这篇论文，我们旨在证明使用一个开源数据流引擎的修改版作为有状态函数的运行时间，我们可以在云中部署可扩展和有状态的服务，并具有令人惊讶的低延迟和高吞吐量。
摘要：
函数即服务 (FaaS) 提供了细粒度的资源供应模型，使开发人员能够构建高度弹性的云应用程序。用户请求由一系列 serverless 函数一步步处理，形成基于函数的工作流。开发人员需要为功能设置适当的资源配置，以满足服务水平目标（SLO）并节省成本。然而，开发资源配置策略具有挑战性。这主要是因为云函数的执行经常会遇到冷启动和性能波动，这需要动态配置策略来保证 SLO。在本文中，我们介绍了 StepConf，这是一个框架，可在工作流运行时自动执行功能的资源配置。StepConf 优化了工作流中每个函数步骤的内存大小，并考虑了函数间和函数内的并行性。 我们在 AWS Lambda 上评估 StepConf。与基线相比，实验结果表明 StepConf 在保证 SLO 的同时可以节省高达 40.9% 的成本。
摘要截止日期 2023.04.28
Java 虚拟机 (JVM) 存在众所周知的启动和预热速度慢的问题。这是因为 JVM 需要在达到峰值性能之前动态地创建许多运行时数据，包括类元数据、方法配置文件数据和即时 (JIT) 编译的本地代码，即使是同一个应用程序的每一次运行也是如此。许多技术被提出来 在不同的运行中重复使用和共享这些运行时数据。例如，类数据共享 (CDS) 和提前 (AOT) 编译分别旨在保存和共享类元数据和编译后的本机代码。不幸的是，这些技术都是独立开发的，不能很好地利用彼此的能力。 本文提出了一种系统地重用 JVM 运行时数据以加速应用程序启动和预热的方法。 我们首先提出并实现了 JWarmup，这是一种可以记录和重用 JIT 编译数据（例如，编译的方法及其配置文件数据）的技术。然后，我们将 JIT 编译数据提供给 AOT 编译器，以执行Profile-Guided 优化 (PGO)。我们还集成了现有的 CDS 和 AOT 技术，以进一步优化应用程序启动。对实际应用程序的评估表明，该方法可以为应用程序的启动带来 41.35% 的改进。而且，我们的方法可以提前触发 JIT 编译，减少高峰时间的 CPU 负载。
2022.01
摘要：
无服务器计算正在成为云中分布式深度神经网络 (DDNN) 训练的一个有前途的范例，因为它允许用户将复杂的模型训练分解为多个函数，而无需管理虚拟机或服务器。尽管提供了更简单的资源接口（即功函数数量和内存大小），但函数资源供应不足（供应不足或过度供应）很容易导致无服务器平台中不可预测的 DDNN 训练性能。我们对 AWS Lambda 的实证研究表明，无服务器 DDNN 训练的这种不可预测的性能主要是由 Parameter Servers (PS) 的资源瓶颈和较小的本地批量大小造成的。在本文中，我们设计并实现了 λλDNN，这是一种具有成本效益的函数资源供应框架，可为无服务器 DDNN 训练工作负载提供可预测的性能，同时节省供应函数的预算。利用 PS 网络带宽和函数 CPU 利用率，我们构建了一个轻量级的分析型 DDNN 训练性能模型，以实现我们设计的 λλDNN 资源供应策略，从而保证 DDNN 训练性能与无服务器函数。AWS Lambda 上的大量原型实验和互补的跟踪驱动模拟表明，与最先进的资源配置策略相比，λλDNN 可以提供可预测的 DDNN 训练性能，并节省高达 66.7% 的函数资源货币成本，但具有可接受的运行时开销。
2022.03
摘要：
凭借通过一键上传和轻量级执行来简化代码部署的能力，无服务器计算已成为一种有前途的范式，并且越来越受欢迎。然而，在将数据密集型分析应用程序调整到无服务器环境时仍然存在开放的挑战，其中 {\em 无服务器分析} 的用户在跨不同阶段协调计算和在大型配置空间中配置资源时遇到困难 。本文介绍了我们对 {\em Astrea} 的设计和实现，它以自主方式配置和编排无服务器分析作业，同时考虑到灵活指定的用户需求。 {\em Astrea} 依赖于性能和成本的建模，它表征了多维因素（{\em e.g.}、函数内存大小、每个阶段的并行度）之间复杂的相互作用。我们根据用户对提高性能或降低成本的特定要求制定优化问题，并开发一组基于图论的算法以获得最佳作业执行。 我们在 AWS Lambda 平台上部署 {\em Astrea}，并针对具有代表性的基准进行真实世界的实验，包括不同规模的大数据分析和机器学习工作负载。广泛的结果表明，与各种供应和部署基线相比，{\em Astrea} 可以实现无服务器数据分析的最佳执行决策。例如，与三个配置基线相比，{\em Astrea} 在给定的预算约束下设法将作业完成时间性能提高了 21% 到 69%，同时在不违反性能要求的情况下节省了 20% 到 84% 的成本。
2021.01
摘要：
近年来，函数即服务 (FaaS) 和无服务器应用程序由于其高可扩展性、易于资源管理和按需付费定价模式而大幅增加。然而，云用户在将应用程序迁移到 serverless 模式时面临着实际问题，即缺乏分析性能和计费模型，以及在有限的预算和所需的 serverless 应用程序服务质量之间进行权衡。在本文中，我们通过提出和回答两个关于无服务器应用程序的性能和成本的预测和优化的研究问题来填补这一空白。我们提出了一种新结构来正式定义无服务器应用程序工作流，然后实施分析模型来预测平均端到端响应时间和工作流成本。因此，我们提出了一种名为概率精炼关键路径贪心算法 (PRCP) 的启发式算法，该算法具有四种贪心策略来回答关于性能和成本的两个基本优化问题。我们通过对 AWS Lambda 和 Step Functions 进行实验来广泛评估所提出的模型。我们的分析模型可以预测无服务器应用程序的性能和成本，准确率超过 98%。PRCP 算法可以实现无服务器应用程序的最佳配置，平均准确率为 97%。
2020.01
摘要：
无服务器计算已经成为一种新的云计算执行模型，它将用户和应用程序开发人员从显式管理“物理”资源中解放出来，将这种资源管理负担留给服务提供商。在本文中，我们研究了多租户无服务器计算平台的资源分配问题，明确考虑了包括突然激增在内的工作负载波动。特别是，我们调查了租户（他们的应用程序）具有不同工作负载特征的这些平台中性能下降的不同根本原因。为此，我们开发了一个细粒度的 CPU 上限控制解决方案作为资源管理器，可以动态调整具有相同/相似性能要求的应用程序（即应用程序组）的 CPU 使用限制（或 CPU 上限）。CPU 上限的调整主要适用于 serverless 计算平台的同地工作进程，以尽量减少资源争用，这是性能下降的主要来源。实际的调整决策是基于使用组感知调度算法的性能指标（例如，节流时间和队列长度）做出的。在我们的本地集群中进行的大量实验结果证实，即使在传入工作负载存在波动和突然激增的情况下，所提出的资源管理器也可以有效地消除显式预留计算能力的负担。我们通过将提议的资源管理器与实践中广泛使用的几种启发式方法进行比较来衡量其鲁棒性，包括增强版本的循环和最小长度队列调度策略，在实际场景驱动的各种工作负载强度下。值得注意的是，我们的资源管理器优于其他启发式方法，将偏度和平均响应时间分别降低了 44% 和 94%，同时它不会过度使用 CPU 资源。
摘要：
为高性能计算 (HPC) 调整云是一项具有挑战性的任务，因为 HPC 应用程序的软件依赖于快速的网络连接并且对硬件故障很敏感。因此，在许多情况下，使用云基础设施重建传统的 HPC 集群是一种将 HPC 应用程序迁移到云的不可行解决方案。作为通用提升和移位方法的替代方法，我们考虑了地震成像的特定应用，并展示了一种无服务器和事件驱动的方法，用于在云中运行该问题的大规模实例。我们的工作流程不是永久运行的计算实例，而是基于具有高吞吐量批处理计算和事件驱动计算的无服务器架构，其中计算资源只有在使用时才会运行。我们证明了这种方法非常灵活，并允许弹性和嵌套级别的并行化，包括用于求解基础偏微分方程的域分解。虽然事件驱动的方法会在计算资源反复重启时引入一些开销，但它本质上为实例关闭提供了弹性，并通过避免空闲实例来显着降低成本，从而使云成为本地集群的可行替代方案大尺度地震成像。
摘要：
视频处理在广泛的基于云的应用程序中起着至关重要的作用。它通常涉及多个流水线阶段，如果正确配置以匹配视频的成本和延迟约束，则非常适合最新的细粒度无服务器计算范例。然而，现有的配置工具主要是为具有一般工作负载的传统虚拟机集群开发的。本文介绍了 CharmSeeker，这是一种用于无服务器视频处理管道的自动配置调整工具。我们首先仔细研究了现代无服务器平台上视频处理的关键步骤和性能瓶颈。然后，我们确定处理管道的配置空间，并利用精心设计的序列贝叶斯优化搜索方案来确定有希望的配置 。我们进一步解决了将我们的解决方案集成到实际系统中的实际挑战，并使用 AWS Lambda 开发原型。评估结果表明，CharmSeeker 可以找出最佳或接近最佳的配置，将相对处理时间提高到 408.77%。与最先进的解决方案相比，它还更健壮且可扩展到各种视频处理管道。
在过去的五年里，所有主要的云平台供应商都新增了他们的无服务器产品。许多早期采用者报告说，基于无服务器的应用比传统应用有很大的好处，许多公司也在考虑自己转向无服务器。然而，目前关于无服务器应用何时适合，以及实施无服务器应用的最佳实践是什么，只有少数零散的报告，有时甚至相互矛盾。我们在关于无服务器应用状态的本研究中解决了这个问题。我们从开源项目、学术文献、工业文献和特定领域的反馈中收集了89个无服务器应用的描述。我们分析了16个特征，这些特征描述了成功采用者为何和何时使用无服务器应用，以及他们如何构建这些应用。我们进一步将我们的特征研究结果与10个现有的，主要是工业界的研究和数据集进行比较；这使我们能够确定多个研究中的共识点，调查分歧点，并从整体上确认我们结果的有效性。本研究的结果可以帮助管理者决定是否应该采用无服务器技术，帮助工程师了解当前构建无服务器应用的做法，帮助研究人员和平台提供商更好地了解当前无服务器应用的情况。
2022.11.7-11.11
这项工作记录了我们在阿里巴巴 FaaS 平台上改进调度器的经验。我们观察到，在大多数 FaaS 沙箱中，内存和 CPU 都没有得到充分的利用。一个自然的解决方案是在分配沙箱时过度配置虚拟机资源，而随之而来的争夺可能会导致性能下降并影响用户体验。更为复杂的是，FaaS 的退化可能来自外部因素，例如用户函数的失败依赖。
我们设计 Owl 来实现高利用率和性能稳定性。它引入了一个可定制的规则系统，让用户指定他们对退化的容忍度，并以一种双重方法过度投入资源。(1) 对于较少调用的函数，它通过基于使用的启发式方法将资源分配到沙箱中，持续监测其性能，并对任何检测到的退化进行补救。它通过分离出一个无竞争环境，并将受影响的沙箱迁移到那里作为比较基线，来区分退化的沙箱是否受到外部影响。(2) 对于经常被调用的函数，Owl 对搭配的沙箱之间的干扰模式进行分析，并将沙箱置于分析的指导下。搭配分析的设计是为了解决分析必须在生产中进行的限制。Owl 进一步整合了闲置的沙箱，以减少资源浪费。我们在生产系统中建立了 Owl 的原型，并实施了一个有代表性的基准测试套件来评估它。结果表明，该原型可以减少 43.80% 的虚拟机成本，并有效地缓解延迟的退化，而产生的开销可以忽略不计。
无服务器计算大大简化了云编程。它将云租户从各种系统管理和资源管理任务中解放出来，如配置和供应。在这种新的云计算模式下，单一的单体应用被划分为独立的无状态函数，即函数即服务（FaaS），然后被协调在一起以支持复杂的业务逻辑。但是，这种增强的灵活性有一个基本的成本。现在频繁启动函数之间的内部网络连接，以支持无服务器函数，如敏捷自动缩放和函数链，从而提高通信延迟。为了减轻这一成本，目前的无服务器供应商为了性能而牺牲了安全，保持内部函数通信不加密。
我们认为，新兴的 QUIC 协议可以为这一挑战提供解决方案，该协议在广域范围内保证了 HTTP 通信的安全和加速。我们设计了一个基于 QUIC 的 FaaS 框架，称为 QFaaS，并在 OpenFaaS 平台上实施。我们的设计明确地确保了现有的无服务器应用程序可以直接从 QFaaS 中受益，而无需修改任何应用代码。对合成函数和真实世界应用的实验表明，QFaaS 可以将单个函数和函数链的通信延迟分别降低 28% 和 40%，并为终端用户的响应时间节省多达 50 毫秒。
3.Cypress: input size-sensitive container provisioning and request scheduling for serverless platforms
随着无服务器平台的日益普及，部署在该平台上的应用程序（app）的数量和种类也在增加。这些应用中的大多数都会处理用户提供的输入，以产生预期的结果。输入敏感分析领域的现有工作经验表明，许多此类应用的执行时间与输入大小有关，可以通过建模技术来确定。然而，现有的无服务器资源管理框架对这些应用程序的输入规模敏感性质不了解。我们在本文中证明，这有可能导致容器过度供应或违反端到端服务水平目标（SLO）。为了解决这个问题，我们提出了 Cypress，一个输入尺寸敏感的资源管理框架，它可以最大限度地减少为应用程序提供的容器，同时确保高度的 SLO 合规性。我们在 Kubernetes 管理的集群之上对 Cypress 进行了广泛的评估，使用了来自 AWS 无服务器应用库和 Open-FaaS 函数商店的 5 个应用，这些应用具有真实世界的痕迹和不同的输入大小分布。我们的实验结果表明，与最先进的框架相比，Cypress 生成的容器数量减少了 66%，从而提高了容器利用率，并将整个集群的能耗分别节省了 2.95 倍和 23%，同时保持高度的 SLO 合规性（高达 99.99%）。
无服务器计算因其提供的易用性和成本效益而迅速增长。然而，作为无服务器系统的一个重要组成部分，函数调度却被忽视了。我们采用第一原则方法来设计一个调度器，该调度器能够迎合现实部署中所见的无服务器函数的独特特性。我们首先沿着三个维度创建了一个调度策略的分类法。接下来，我们使用模拟来探索调度策略空间，并表明常用的特性（如延迟绑定和随机负载平衡）对于常见的执行时间分布和负载范围来说是次优的。我们使用这些见解来设计 Hermod，一个具有两个关键特性的无服务器函数调度器。首先，为了避免由于高函数执行时间可变性而导致的队头阻塞，Hermod 将早期绑定和处理器共享相结合，用于单个工作机的调度。其次，Hermod 具有成本、负载和位置意识。与纯基于负载的策略相比，它改进了低负载下的整合，在高负载下采用最小负载平衡以保持高性能，并减少了冷启动次数。我们为 Apache OpenWhisk 实现了 Hermod，并证明，对于在真实世界跟踪中观察到的函数模式，与现有的生产和最先进的研究调度程序相比，它实现了高达 85% 的函数减慢和高达 60% 的吞吐量。
无服务器函数即服务（FaaS）为客户提供了更好的可编程性，但它并不是 "无服务器"，而是以云供应商更复杂的基础设施管理（如资源配置和调度）为代价。为了保持服务水平目标（SLOs）并提高资源利用效率，最近的研究集中在应用在线学习算法，如强化学习（RL）来管理资源。尽管应用 RL 取得了初步成功，但我们在本文中首先表明，与孤立环境相比，最先进的单代理 RL 算法（S-RL）在多租户无服务器 FaaS 平台上的 p99 函数延迟退化高达 4.8 倍，并且在训练期间无法收敛。然后，我们设计并实现了一个基于近似策略优化（SIMPPO）的可扩展和增量的多代理 RL 框架。我们的实验证明，在多租户环境中，SIMPPO 使每个 RL 代理在训练过程中有效收敛，并提供与孤立训练的 S-RL 相当的在线函数延迟性能，而且退化很小（<9.2%）。此外，与 S-RL 相比，SIMPPO 在多租户情况下将 p99 函数延迟降低了 4.5 倍。
许多研究人员将科学无服务器工作流或函数编排（FCs）迁移到函数即服务（FaaS）上，以受益于其高可扩展性和弹性。不幸的是，联邦 FaaS 的异质性阻碍了关于运行 FC 的适当参数设置的决定。因此，科学家们必须在精确但繁琐且昂贵的实验或简单但便宜且不太精确的模拟之间做出选择。遗憾的是，相关工作要么支持在虚拟机和容器上运行的全服务器工作流的仿真模型，要么支持个别无服务器函数的部分 FaaS 模型，这些模型侧重于执行时间，而忽略了各种联合的开销。
本文介绍了SimLess，这是一个 FC 仿真框架，用于在多个 FaaS 提供商之间进行准确的 FC 仿真，参数设置简单且轻量级。与使用时间序列的机器学习来预测 FC 行为的昂贵方法不同，SimLess 引入了两个轻量级的概念：（1）双胞胎，代表用相同的计算、通信和存储资源部署的相同函数，但在同一 FaaS 提供商的其他区域，以及（2）兄弟姐妹，代表用不同的计算资源部署在同一区域的相同函数。新颖的 SimLess FC 仿真模型将一个函数的往返时间分割成几个参数在双胞胎和同胞之间重用，而不一定要运行它们。我们用部署在 18 个 AWS、谷歌和 IBM 地区的两个科学 FC 评估了 SimLess。SimLess 模拟的累积开销的平均误差为 8.9%，各地区的学习和验证没有明显的差异。此外，SimLess 使用在单一地区执行的低并发 FC 的测量结果来模拟在其他地区有 2500 个函数的高并发 FC，其误差高达 9.75 %。最后，与其他仿真方法相比，SimLess 减少了 77.23% 的参数设置工作。
2021.11.1-11.4
摘要：
函数即服务 (FaaS) 已成为一种越来越流行的用户部署应用程序的方式，而无需管理底层基础设施。然而，现有的 FaaS 平台依赖远程存储来维护状态，限制了可以高效运行的应用程序集。FaaS 平台最近的缓存工作试图解决这个问题，但未能成功：它忽略了 FaaS 应用程序的广泛不同的特性，不根据数据访问模式扩展缓存，或者需要对应用程序进行更改。为了解决这些限制，我们提出了 Faa**$** T，这是一种用于无服务器应用程序的透明自动扩展分布式缓存。每个应用程序都有自己的缓存。在函数执行并且应用程序变为非活动状态后，缓存会随应用程序从内存中卸载。在为下一次调用重新加载时，Faa**$T 用可能被访问的对象预热缓存。除了传统的基于计算的扩展之外，Faa$T 还根据工作集和对象大小进行扩展，以管理缓存空间和 I/O 带宽。我们通过全面研究 Azure Functions 上的数据访问模式来激发我们的设计。我们为 Azure Functions 实施 Faa$T，并表明与最先进的缓存系统相比，Faa$**T 可以将具有挑战性的应用程序的性能提高多达 92%（平均 57%），并为大多数用户降低成本，即必须支持额外的服务器资源的成本。
【FaaS 程序缓存状态，自动拓展卸载】
摘要：
随着面向用户的应用程序采用无服务器计算，无服务器平台良好的延迟性能已成为一项强大的基本要求。然而，由于其底层控制和数据平面的设计特别不适合具有不可预测的到达模式的短期函数，因此在今天的平台上很难实现这一点。我们展示了 Atoll，一个无服务器平台，它通过重新设计控制和数据平面来克服挑战。在 Atoll 中，每个应用程序都与延迟期限相关联。Atoll 通过以下方式实现其每个应用程序请求的延迟目标：(a) 将集群划分为（半全局调度程序、工作池）对，(b) 执行截止时间感知调度和主动沙箱分配，以及 (c) 使用负载平衡层进行沙盒感知路由，并自动扩展每个应用程序的半全局调度程序。我们的结果表明，与最先进的替代方案相比，Atoll 将错过的最后期限减少了约 66 倍，尾部延迟减少了约 3 倍。
【低延迟无服务器平台】
摘要：
微服务的日益普及导致了基于在线云服务的应用激增，这些应用通常被建模为有向无环图（DAG），由几十到几百个微服务组成。这些应用绝大多数都是面向用户的，因此有严格的 SLO 要求。无服务器函数具有较短的资源配置时间和即时可扩展性，是开发此类延迟关键型应用的合适人选。然而，现有的无服务器供应商并不了解应用 DAG 的工作流特性，在许多情况下导致容器的过度配置。在动态 DAG 的情况下，这种情况进一步加剧，因为应用的函数链并不事先知道。在这些观察的激励下，我们提出了 Kraken，一个工作流感知的资源管理框架，在确保符合 SLO 的前提下，最大限度地减少应用 DAG 的容器供应数量。我们在 OpenFaaS 上设计和实现 Kraken，并在一个多节点 Kubernetes 管理的集群上对其进行评估。我们使用 DeathStarbench 工作负载套件和真实世界的痕迹进行了广泛的实验评估，证明 Kraken 产生的容器数量减少了 76%，从而提高了容器的利用率，与无服务器平台中使用的最先进的调度器相比，集群范围内的能量分别节省了 4 倍和 48%。
【工作流感知资源管理，减少容器冗余】
摘要：
无服务器计算平台简化了模块化软件函数的开发、部署和自动化管理。然而，现有的无服务器平台通常假定有一个超额的云，这使得它们不适合资源稀缺的边缘计算环境。在本文中，我们提出了一个重新设计的无服务器平台，全面解决了资源有限的边缘云中无服务器函数的关键挑战。
我们的 Mu 平台简洁地整合了无服务器平台的核心资源管理组件：自动缩放、负载均衡和放置。Mu 中的每个工作节点都会在响应头中透明地传播服务速率和队列长度等指标，将这些信息反馈给负载均衡系统，使其能够更好地路由请求，并反馈给我们的自动缩放器，以预测工作负载的波动并主动满足 SLO 要求。然后，来自自动调节器的数据被放置引擎用来考虑异质性和竞争函数函数之间的公平性，确保整体资源效率，并最大限度地减少资源碎片。我们将我们的设计作为 Knative 无服务器平台的一套扩展来实现，并展示了其在资源效率、公平性和响应时间方面的改进。
【资源受限的无服务器平台】
摘要：
容器化正变得越来越流行，但不幸的是，容器通常无法通过分配的资源提供预期的性能。在本文中，我们首先证明了在容器位于同一位置的多租户环境中，性能差异和退化是显着的（高达 5 倍）。然后，我们调查这种性能下降的根本原因。与通常认为这种降级是由资源争用和干扰引起的看法相反，我们发现容器预留的 CPU 数量与实际获得的 CPU 数量之间存在差距。根本原因在于当今 Linux 调度机制的设计选择，我们称之为 Forced Runqueue Sharing 和 Phantom CPU Time。实际上，预留 CPU 资源的需求与 Completely Fair Scheduler 的工作节约性质之间存在根本冲突，这种矛盾阻碍了容器充分利用其请求的 CPU 资源。作为概念验证，我们在广泛使用的 Kubernetes 和 Linux 上实现了一种新的资源配置机制，以展示其潜在优势并为未来的调度程序重新设计提供启示。与现有调度程序相比，我们的概念验证将批处理和交互式容器化应用程序的性能提高了 5.6 倍和 13.7 倍。
摘要：
在容器中运行的松散耦合和轻量级微服务正在逐渐取代单体应用程序。了解微服务的特性对于善用微服务架构至关重要。但是，目前还没有关于生产环境中的微服务及其相关系统的全面研究。在本文中，我们对阿里巴巴集群中的大规模微服务部署进行了深入的分析。我们的研究侧重于微服务依赖的表征及其运行时性能。我们对微服务调用图进行了深入剖析，以量化它们与数据并行作业的传统 DAG 之间的差异。特别是，我们观察到微服务调用图是重尾分布的，它们的拓扑类似于树，而且许多微服务都是热点。我们揭示了三种可用于优化微服务设计的有意义的调用依赖。我们对微服务运行时性能的调查表明，大多数微服务对 CPU 干扰比对内存干扰更敏感。为了合成更具代表性的微服务跟踪，我们建立了一个数学模型来模拟调用图。实验结果表明，我们的模型可以很好地保留从阿里巴巴跟踪中观察到的那些图属性。
摘要：
无服务器计算允许客户将他们的工作提交到云中执行，资源供应由云提供商负责。无服务器函数通常是短暂的并且具有适度的资源需求，因此提供了通过与延迟敏感的客户工作负载共存来提高服务器利用率的机会。本文介绍了 ServerMore，这是一种服务器级资源管理器，可将客户无服务器作业与有服务器的客户 VM 有机地共存。ServerMore 动态调节服务器上的 CPU、内存带宽和 LLC 资源，以确保 serverful 和 serverless 工作负载之间的托管不会影响应用程序尾部延迟。通过选择性地承认无服务器函数并推断黑盒服务器工作负载的性能，ServerMore 与之前的工作相比，资源利用率平均提高了 35.9% 至 245%；同时对服务器应用程序和无服务器函数的延迟影响最小。
【共存提高资源利用率】
摘要：
无服务器计算是云行业中快速发展的范例，将函数设想为应用程序的计算构建块。云提供商不是强迫应用程序开发人员为其应用程序提供云资源，而是为每个函数“在后台”提供所需的资源。在这项工作中，我们设想虚拟无服务器提供商 (VSP) 来聚合无服务器产品。通过这样做，VSP 允许开发人员（和企业）摆脱供应商锁定问题，并通过每次适应性地利用最佳供应商来利用供应商之间的定价和性能差异，迫使供应商竞争以提供更便宜和更优质的服务。我们讨论了 VSP 的优点，并表明与虚拟机相比，无服务器系统非常适合跨提供商聚合。我们提出了一个 VSP 系统架构并实现了一个初始版本。通过实验评估，我们的初步结果表明，VSP 可以将最大持续吞吐量提高 1.2 倍至 4.2 倍，将 SLO 违规减少 98.8%，并将总调用成本提高 54%。
【无服务器函数的云际】
注：VSP 的提出有以下的理论基础：(1) 无服务器计算函数通常是轻量级的，因此可以“无痛”地在多家云计算提供商之间部署和迁移服务；(2) 存在较多开源的无服务器计算框架；(3) 已有的工作研究无服务器计算中函数性能的可预测性，有助于优化服务厂商的选择。
摘要：
将云应用结构化为相互作用的细粒度微服务的集合，使其具有可扩展性，并提供了对应用部分进行热升级的灵活性。目前无服务器计算（FaaS）的化身及其动态资源分配和自动扩展能力使其成为此类应用的首选部署模式。随着微服务的粒度接近几毫秒的执行时间，再加上每秒接近数万个请求的负载，拥有低于一毫秒的低调度延迟对于跟上线路速率至关重要。当这些微服务是构成应用程序的工作流的一部分时，协调微服务执行顺序的协调器也需要以微秒级的延迟运行。我们的观察显示，调度/编排延迟的最重要组成部分是请求从网络进入和离开用户空间所需的时间。由于今天的 SmartNIC 上存在大量的低功耗内核，要跟上这些高线速和严格的延迟预期，一种方法是在 SmartNIC 上靠近网络运行调度器和编排器。FaaS 调度器/协调器的短时短暂状态和低 CPU 突发要求的运行特性使它们成为从服务器卸载到 NIC 核心的理想候选者。这也带来了释放服务器 CPU 的其他好处。我们在基于 ASIC 的 Netronome Agilio 智能网卡上实现了 Speedo，我们的综合评估表明，Speedo 在每秒 10K 个请求的负载下，将调度延迟从150ms 降至140μs。
摘要：
无服务器平台旨在简化云应用程序的部署、扩展和管理。无服务器应用程序本质上是分布式的，并且使用短暂的临时进程执行。使用短暂的临时进程简化了应用程序的扩展和管理，但也意味着现有的监控分布式系统和检测错误的方法不能应用于无服务器应用程序 。在本文中，我们提出了 Watchtower，这是一个能够对无服务器应用程序进行运行时监控的框架。Watchtower 将程序属性作为输入，并且可以检测应用程序违反这些属性的情况。我们设计 Watchtower 以最大限度地减少应用程序更改，并以与应用程序相同的速率进行扩展。 我们通过检测库而不是应用程序代码来实现前者，而后者通过将 Watchtower 构建为无服务器应用程序来实现。一旦发现错误，开发人员可以使用 Watchtower 调试器来识别和解决错误的根本原因。
2020.10.19-20.21
摘要：
执行复杂的、突发并行的有向无环图 (DAG) 作业对无服务器执行框架提出了重大挑战，它需要以高吞吐量快速扩展和调度任务，同时最大限度地减少跨任务的数据移动。我们证明，对于无服务器并行计算，分散式调度使调度能够分布在可以并行调度任务的 Lambda 执行程序中，并带来多种好处，包括增强数据局部性、减少网络 I/O、自动资源弹性和提高成本效益.我们描述了我们新的无服务器并行框架 Wukong 在 AWS Lambda 上的实施和部署。我们表明 Wukong 实现了近乎理想的可扩展性，并行计算作业的执行速度高达 68.17 倍，网络 I/O 减少了多个数量级，与 numpywren 相比，租户端成本节省了 92.96%。
摘要：
无服务器计算保证了高生产力软件开发的自动可扩展性和成本效率（以“按需付费”的方式）。由于其优点，无服务器计算在云中推动了越来越多的新应用程序和服务。然而，这也带来了新的挑战，包括如何高效地设计高性能无服务器平台以及如何在平台上高效地编程。
本文提出了 ServerlessBench，这是一个用于表征无服务器平台的开源基准测试套件。它包括探索无服务器计算特征指标的测试用例，例如通信效率、启动延迟、无状态开销和性能隔离。我们已应用基准套件来评估最流行的无服务器计算平台，包括 AWS Lambda、Open-Whisk 和 Fn，并从研究中展示新的无服务器影响。例如，我们展示了将应用程序解耦为无服务器函数组合的场景，这有助于节省成本和提高性能，而无服务器计算中的“无状态”属性可能会损害无服务器函数的执行性能。这些影响形成了几个设计指南，可以帮助平台设计人员优化无服务器平台和应用程序开发人员设计最适合平台的函数。
摘要：
无服务器计算允许用户创建简短的无状态函数并同时调用数百个函数来处理大规模并行工作负载。我们观察到，即使无服务器函数的大部分足迹在其调用中是固定的——语言运行时、库和其他应用程序状态——今天的无服务器平台并没有利用这种冗余。这种低效率会产生一系列负面影响：更长的启动时间、更低的吞吐量、更高的延迟和更高的成本。为了缓解这些问题，我们构建了 Photons，这是一个利用工作负载并行性在同一运行时内共同定位同一函数的多个实例的框架。然后并发调用可以透明地共享运行时和应用程序状态，而不会影响执行安全。光子每次调用将函数的内存消耗减少 25% 到 98%，与当今的无服务器平台相比，性能没有下降。我们还表明，我们的方法可以将整体内存利用率降低 30%，将冷启动总数降低 52%。
摘要：
数据中心分解为数据中心运营商和应用程序设计者提供了许多好处。然而，从以服务器为中心的模型切换到分解模型需要开发新的编程抽象，这些抽象可以实现高性能，同时受益于更大的弹性。为了探索数据中心分解的局限性，我们研究了一个几乎最大程度地受益于当前以服务器为中心的数据中心的应用领域：密集线性代数。我们构建了 NumPyWren，这是一个建立在分解的无服务器编程模型上的线性代数系统，以及 LAmbdaPACK，一种为高度并行的线性代数算法的无服务器执行而设计的配套领域特定语言。我们表明，对于矩阵乘法、奇异值分解、Cholesky 分解和 QR 分解等许多线性代数算法，NumPyWren 的性能（完成时间）在优化的以服务器为中心的 MPI 实现的 2 倍以内，并且具有计算效率（总 CPU 小时数）提高 15%，同时提供容错能力。
【应用】
摘要：
无服务器计算最近已成为在云上运行软件的新范例。在这种范式中，程序需要表示为一组短期任务，每个任务都可以在很短的有限时间内完成（例如，AWS Lambda 上的 15 分钟）。无服务器计算有利于云提供商——通过允许他们更好地利用资源——以及对用户——通过简化管理和实现更大的弹性。然而，开发在这种环境中运行的应用程序具有挑战性，需要用户适当地划分他们的代码，开发新的协调机制，并处理故障恢复。在本文中，我们提出了 Kappa，一个简化无服务器开发的框架。它使用检查点来处理 lambda 函数超时，并提供支持并行计算和协调的并发机制。
摘要：
无服务器计算是一种快速发展的范式，可以轻松利用云的力量。借助无服务器计算，开发人员只需向云提供商提供事件驱动的函数，并且提供商可以无缝扩展函数调用以满足事件触发发生时的需求。由于当前和未来的无服务器产品支持各种无服务器应用程序，因此管理无服务器工作负载的有效技术成为一个重要问题。这项工作检查了云提供商当前的管理和调度实践，发现了许多问题，包括应用程序运行时间膨胀、函数下降、分配效率低下以及其他未记录和意外行为。为了解决这些问题，设计了一种新的服务质量函数调度和分配框架，称为 Sequoia。Sequoia 允许开发人员或管理员根据易于配置的灵活策略轻松定义无服务器函数和应用程序的部署、限制、优先级或更改方式。受控和现实工作负载的结果表明，Sequoia 可以无缝适应策略，消除链中掉线，将排队时间减少多达 6.4 倍，实施严格的链级公平性，并将运行时性能提高多达 25 倍。
摘要：
突发并行无服务器应用程序调用数千个短暂的分布式函数来完成复杂的工作，例如数据分析、视频编码或编译。虽然这些任务可以在几秒钟内执行，但启动和配置它们所依赖的虚拟网络是一个主要瓶颈，可能会占用高达 84% 的总启动时间。在本文中，我们在三个流行的覆盖网络 Docker Swarm、Weave 和 Linux Overlay 中描述了这种网络冷启动问题的严重程度。我们专注于端到端的启动时间，包括启动一组容器的时间以及互连它们的时间。我们的主要观察结果是，现有的无服务器网络覆盖方法在短暂的无服务器环境中扩展性很差。根据我们的发现，我们开发了 Particle，这是一种专为多节点无服务器覆盖网络量身定制的网络堆栈，可在不牺牲多租户、通用性或吞吐量的情况下优化网络创建。当集成到无服务器突发并行视频处理管道中时，Particle 将应用程序运行时间提高了 2.4--3 倍于现有覆盖。
2019.11.20-11.23
摘要：
无服务器计算因其细粒度供应、大规模多租户和按需扩展而受到关注。但是，它也迫使应用程序将远程存储中的状态外部化，从而增加了大量开销。为了解决这个“数据传输问题”，我们构建了 Shredder，这是一个低延迟的多租户云存储，允许直接在存储节点内执行小型计算单元。存储租户为 Shredder 提供 JavaScript 函数（或 WebAssembly 程序），这些函数可以直接与数据交互，而无需通过网络移动它们。
Shredder 的主要挑战是安全隔离数千个租户存储函数，同时最大限度地降低数据交互成本。Shredder 使用一种独特的方法，其数据存储和网络路径在本机代码中实现以确保性能，而隔离的租户函数使用 V8 特定的中间表示与数据交互，避免了昂贵的跨保护域调用和数据复制。因此，Shredder 每秒可以执行 400 万个远程调用的租户函数，分布在数千个租户中，中位数和 99% 的响应延迟分别小于 50 微秒和 500 微秒。我们的评估表明，与传统远程存储相比，Shredder 在获取它们之间只有一到三个数据依赖关系的项目时实现了 14% 到 78% 的加速。我们还展示了 Shredder 在加速数据密集型应用程序方面的有效性，包括显示数量级增益的社交图上的 k-hop 查询。
摘要：
机器学习 (ML) 工作流程极其复杂。典型的工作流由用户交互的不同阶段组成，例如预处理、训练和调整，这些阶段由用户重复执行，但具有异构的计算要求。这种复杂性使 ML 用户难以正确配置和管理资源，并且在实践中构成了一个重大负担，经常导致过度配置并损害用户生产力。一般来说，无服务器计算是解决资源管理问题的一个引人注目的模型，但由于对本地资源的重大限制，将其用于现有的 ML 框架存在许多挑战。
这项工作提出了 Cirrus——一个 ML 框架，它通过有效利用无服务器基础架构来自动化 ML 工作流的数据中心资源的端到端管理。Cirrus 结合了无服务器接口的简单性和无服务器基础设施（AWS Lambdas 和 S3）的可扩展性，以最大限度地减少用户工作量。我们展示了一种专门用于无服务器计算和迭代 ML 训练的设计，以便在无服务器基础架构上进行稳健高效的 ML 训练。我们的评估表明，Cirrus 优于单一维度的专门框架：Cirrus 比通用无服务器系统 [36] 快 100 倍，比传统基础设施的专门 ML 框架快 3.75 倍 。
摘要：
无服务器计算在函数即服务 (FaaS) 执行模型中越来越受欢迎。无服务器计算不会产生与配置云实例相关的开销，并且具有高可用性和可扩展性，使开发人员可以专注于使用其他开发良好的云服务来实现核心应用程序逻辑。通过抽象复杂的资源管理任务，无服务器计算为云服务的采用开辟了新的机会，甚至对非云专家 [2]。随着流行，许多研究成果已经使用 FaaS 执行模型发表。它们包括调查无服务器计算机会 [1]、提出新的无服务器应用程序、函数运行时优化和公共服务比较。在没有通用测试基准套件的情况下，之前工作中的作者使用相当简单的 FaaS 应用程序评估了提议的系统，例如专门强调特定资源的微基准测试，例如 CPU、磁盘 I/O 和网络。然而，如此简单的工作负载并不代表真实的 FaaS 系统应用程序，并且评估可能无法适当地比较提议的系统。
为了克服无服务器计算和 FaaS 执行模型缺乏综合基准套件的限制，作者创建了 FunctionBench，它提供了各种 FaaS 工作负载，可以在公共云函数执行服务——AWS Lambda、Google Cloud Functions 和 Azure 上执行函数 1.自从服务于 FaaS 工作负载以来，我们一直在努力扩展支持的应用程序，并在大数据处理、后端 Web 应用程序和安全性方面添加场景。为了表示大数据应用程序，我们添加了 MapReduce WordCount 工作负载，它计算来自维基百科的给定分区输入数据集中每个单词的出现次数。为了涵盖 Web 后端应用程序，我们添加了 Chameleon。应用程序使用 Python PIP 库中的 Chameleon 模块呈现模板，以创建作为输入参数提供的 N 行和 M 列的 HTML 表。另一个与 Web 相关的应用程序是 JSON 序列化反序列化模块。该应用程序使用从公共对象存储服务下载的 JSON 编码字符串数据集（Awesome JSON Dataset）执行 JSON 反序列化，并再次序列化 JSON 对象。为了表示与安全相关的应用程序，我们添加了执行基于私钥的加密和解密的 Pyaes 基准测试。它是 CTR 模式下 AES 分组密码算法的纯 Python 实现。我们还添加了 gzip 压缩基准来表示现实的磁盘 IO 繁重的应用程序。表 1 总结了新提出的应用程序的资源使用特性程度（高、中、低）。请参阅[3]阅读综合应用程序列表的描述。
提议的 FunctionBench 提供了多个类别的多种 FaaS 应用，我们相信它将使相关领域的新研究工作与实际应用场景得到公平的评价。
2022 年截稿日期 2022.7.8
2021.9.7-10
1.Tackling Cold Start of Serverless Applications by Efficient and Adaptive Container Runtime Reusing
摘要：
在过去几年中，无服务器计算由于其独特的优势，包括易于管理、自动扩展、内置容错等，已经改变了云和边缘的应用开发和部署模式。尽管如此，无服务器计算也面临着挑战，如冷启动带来的长延迟。在本文中，我们对无服务器框架中的冷启动进行了深入的性能分析，并提出了 HotC，一个基于容器的运行时管理框架，利用轻量级容器来缓解冷启动，提高无服务器应用程序的网络性能。HotC 维护一个实时的容器运行时池，分析用户输入或配置文件，并提供可用的运行时供立即重用。为了精确预测请求并有效地管理热容器，我们设计了一种结合指数平滑模型和马尔科夫链方法的自适应实时容器控制算法。我们的评估结果表明，HotC 引入的开销可以忽略不计，并且可以有效地提高云服务器和边缘设备中不同网络流量模式的各种应用的性能。
摘要：
LSM-tree 在许多键值存储中被广泛用作写优化存储引擎。但是，LSM-tree 中的周期性压缩操作会消耗大量 I/O 带宽和本地服务器的 CPU 资源，导致系统吞吐量下降。针对这个问题，本文提出了一种新的基于 FaaS（Functions as a Service）集群的 compaction 方案，称为 FaaS Compaction。它利用 FaaS 集群的弹性计算能力，将压缩推送到 FaaS 集群。FaaS 集群会进行实际的 compaction 操作，不会影响本地服务器的处理。因此，即使触发了周期性压缩，我们也可以保持稳定的性能。我们实现了 FaaS 压缩并将 FaaS 压缩与 RocksDB 和最先进的卸载压缩策略进行比较。结果表明了我们提议的效率和弹性。
2019 年及以前没有 serverless 相关的文章
截稿日期：2023.1.14
摘要： 本文推动了容器环境中自动资源分配的极限。最近的工作是根据过去的资源使用情况，自动调整容器的CPU和内存限制。然而，这些系统都是重量级的，在粗粒度的时间尺度上运行，当预测不正确时，会导致性能不佳。我们提出了Escra，一个容器编排器，能够为单个容器进行细粒度的、基于事件的资源分配，并通过分布式资源分配来管理容器的集合。Escra在主机内和主机间以亚秒级的时间间隔进行资源分配，使运营商能够在不影响性能的情况下经济有效地扩展资源。我们在两种类型的容器化应用上评估Escra：微服务和无服务器函数。在微服务环境中，细粒度和基于事件的资源分配可以将应用的延迟降低96.9%，与当前最先进的技术相比，吞吐量增加了3.2倍。Escra可以在提高性能的同时，将第50和第99%的CPU浪费分别减少10倍和3.2倍以上。在无服务器环境中，Escra可以将CPU预留量减少2.1倍以上，内存预留量减少2倍以上，同时保持类似的端到端性能。
2021.7.7-7.10
摘要：
函数即服务 (FaaS) 正在成为开发云应用程序的流行范式。使用 FaaS，客户可以将应用程序开发为无服务器函数，将资源管理的负担留给云提供商。但是，FaaS 平台会遭受函数冷启动导致的性能下降。当无服务器函数在加载到内存之前被调用时，就会发生冷启动。这个问题是不可避免的，因为数据中心的内存通常太有限，无法同时容纳所有无服务器函数。冷函数调用的延迟会极大地降低 FaaS 平台的性能。
目前，FaaS 平台采用各种调度方法来减少冷启动的发生。但是，他们没有考虑无服务器函数之间普遍存在的依赖关系。观察到使用依赖项来缓解冷启动的潜力，我们提出了 Defuse，这是一个在 FaaS 平台上的依赖项引导的函数调度程序。具体来说，Defuse 识别了无服务器函数之间的两种依赖类型，即强依赖和弱依赖。它使用频繁模式挖掘和正点互信息分别从函数调用历史中挖掘这种依赖关系。这样，Defuse 就构造了一个函数依赖图。可以安排图表上的连接组件（即依赖函数）以减少冷启动的发生。我们通过将 Defuse 应用于工业无服务器数据集来评估其有效性。实验结果表明，与最先进的方法相比，Defuse 可以减少 22% 的内存使用量，同时函数冷启动率降低 35%。
摘要：
深度神经网络的使用增加刺激了对基于云的模型服务平台的需求不断增长。无服务器计算提供了一种简化的解决方案：用户将模型部署为无服务器函数，并让平台处理供应和扩展。然而，无服务器函数限制了 CPU 和内存中的资源，使其效率低下或无法为大型神经网络提供服务——这已变得越来越流行。在本文中，我们介绍了 Gillis，这是一个基于无服务器的模型服务系统，它自动将大型模型划分为多个无服务器函数，以加快推理速度并减少每个函数的内存占用。Gillis 采用了两种新颖的模型划分算法，分别实现了延迟最优服务和成本最优服务，并符合 SLO。我们已经在三个无服务器平台（AWS Lambda、Google Cloud Functions 和 KNIX）上实现了 Gillis，并将 MXNet 作为服务后端。针对流行模型的实验评估表明，Gillis 支持服务非常大的神经网络，大大降低了推理延迟，并以较低的服务成本满足了各种 SLO。
摘要：
当今的一些云计算应用分布在异构连接的计算资源上，并且在结构和资源需求上高度动态化。然而，无服务器计算和函数即服务**（FaaS）平台仅限于同构集群和同构函数**。我们**介绍了 FaaS 对异构计算的扩展，并通过分布式异构目标平台的网络支持异构函数，称为函数交付网络（FDN）。目标平台是同构计算系统的集群和其上的 FaaS 平台的组合。**FDN 提供函数交付即服务（FDaaS），将函数调用交付给合适的目标平台。我们展示了 FDN 在实现两个目标方面提供的机会，如多个目标平台之间的协作执行和不同目标平台的特性。我们通过对五个分布式目标平台的评估，展示了 FDN 在满足两个目标方面提供的机会，如多个目标平台之间的协作执行和不同的目标平台特性：服务水平目标（SLO）要求和调度函数调用时的能源效率。
摘要：
云原生时代，容器技术发展迅速。Kubernetes 作为生产级容器编排平台，已被证明在管理本地数据中心的容器化应用程序方面取得了成功。然而，Kubernetes 在设计上缺乏足够的多租户支持，这意味着在云环境中，需要专用集群来服务多个用户，即租户。这种限制显着削弱了云计算的优势，并使得使用 Kubernetes 构建多租户软件即服务 (SaaS) 产品变得困难。在本文中，我们提出了 Virtual-Cluster，这是一种新的多租户框架，它通过足够的多租户支持扩展了 Kubernetes。基本上，虚拟集群提供控制平面和数据平面隔离，同时在租户之间共享底层计算资源。新框架通过避免修改 Kubernetes 核心组件来保持 API 兼容性。因此，它可以很容易地与现有的 Kubernetes 用例集成。我们的实验结果表明，VirtualCluster 引入的开销在延迟和吞吐量方面是适中的。
2020.11.29-12.1
摘要：
人们对无服务器计算越来越感兴趣，这是一种云计算模式，可以自动分配和管理基础设施资源，同时只对客户使用的资源收费。像流处理这样的工作负载得益于这些无服务器框架的高弹性和细粒度的定价。然而，到目前为止，服务器 CPU 有限的并发性和高延迟使许多交互式工作负载（如网络服务器和数据库客户端）无法利用无服务器计算实现高性能。在本文中，我们认为服务器 CPU 不适合运行无服务器工作负载（即 λ-NIC 是一个开源框架，它直接在 SmartNIC 上运行交互式工作负载；更确切地说，是一个基于 ASIC 的 NIC，由密集的网络处理单元（NPU）内核组成。λ-NIC 利用 SmartNIC 靠近网络的特点和大量的 NPU 内核，在一个 NIC 上同时运行成千上万的 lambdas，并有严格的尾部延迟保证。为了简化 lambdas 的开发和部署，λ-NIC 公开了一个基于事件的编程抽象，即 Match+Lambda，以及一个机器模型，允许开发者在 SmartNIC 上轻松地编排和执行 lambdas。我们的评估显示，λ- NIC 在工作负载的响应延迟和吞吐量方面分别实现了高达 880 倍和 736 倍的改进，同时大大减少了主机 CPU 和内存的使用。
摘要：
廉价的云服务，如无服务器计算，往往容易受到滞留节点的影响，从而增加分布式计算的端到端延迟。我们在无服务器系统中提出并实施了简单而有原则的矩阵乘法的滞留缓解方法，并在机器学习和高性能计算的几个常见应用中进行了评估。所提出的方案受到纠错码的启发，采用无服务器工作者对存储在云中的数据进行并行编码和解码。这创造了一个完全分布式的计算框架，不需要使用主节点来进行编码或解码，这消除了主节点的计算、通信和存储瓶颈。在理论方面，我们建立了我们提出的方案在解码时间上是渐进最优的，并提供了它能容忍的高概率的散兵人数的下限。通过广泛的实验，我们表明我们的方案比现有的方案，如投机执行和其他编码理论方法，至少要好 25%。
摘要：
数据中心正目睹着越来越多的趋势，即采用基于微服务的架构进行应用设计，它由不同的微服务组合而成。通常情况下，这些应用的寿命很短，并且在管理上有严格的服务水平目标（SLO）要求。传统的基于虚拟机（VM）的配置对于这类应用来说，不仅在配置资源时存在较长的延迟（因为虚拟机往往需要几分钟才能启动），而且还将服务器管理和配置的额外开销放在用户身上。这导致了无服务器函数的采用，在这种情况下，应用程序被组成为函数并托管在容器中。然而，无服务器平台中采用的最先进的调度器倾向于将基于微服务的应用与传统的单体黑盒应用类似。为了检测所有的低效率，我们在这项工作中描述了这些基于微服务的应用程序的端到端生命周期。我们的研究结果表明，由于在工作负载波动期间的反应性容器供应，这些应用遭受了微服务的不良调度，从而导致违反 SLO 或巨大的容器过度供应，反过来导致资源利用率低。我们还发现，在应用程序执行的每个阶段都有大量的松弛，这有可能被用来提高应用程序的整体性能。
2019 年及以前没有 serverless 方向文章
2021.426-4.28
摘要：
基于 "函数即服务"（FaaS）范式的云应用已经变得非常流行。然而，由于它们的无状态性质，它们必须经常与外部数据存储互动，这限制了它们的性能。为了缓解这个问题，我们引入了OFC，一个透明的、垂直和水平弹性的内存缓存系统，用于 FaaS 平台，分布在工作节点上。OFC 通过利用两种常见的资源浪费来源，以成本效益的方式提供这些好处。(i) 大多数云租户过度配置为其函数预留的内存资源，因为它们的足迹与输入无关；(ii) FaaS 供应商将函数沙箱保持几分钟，以避免冷启动。使用针对典型函数输入数据类别（如多媒体格式）调整的机器学习模型，OFC 估计每个函数调用所需的实际内存资源，并囤积剩余的容量以供给缓存。我们基于对 OpenWhisk FaaS 平台、Swift 持久性对象存储和 RAM-Cloud 内存存储的改进来建立我们的 OFC 原型。通过使用一组不同的工作负载，我们表明 OFC 可以将单级和流水线函数的执行时间分别提高 82% 和 60%。
摘要：
近年来，无服务器计算越来越受欢迎，越来越多的应用程序被构建在函数即服务（FaaS）平台上。默认情况下，FaaS 平台支持基于重试的容错，但这对于修改共享状态的程序来说是不够的，因为它们会在不知不觉中坚持部分更新集，以防出现故障。为了应对这一挑战，我们希望 FaaS 应用程序所做的更新具有原子可见性。
在本文中，我们介绍了无服务器应用的原子容错垫片 aft。aft 介于商品 FaaS 平台和存储引擎之间，通过执行读原子隔离保证来确保更新的原子可见性。aft 支持新协议，以保证无服务器环境中的读原子隔离。我们证明，相对于现有的存储引擎，aft 引入了最小的开销，并能平稳地扩展到每秒数千个请求，同时防止了大量的一致性异常情况。
摘要：
本文介绍了一种在 FaaS 环境中实现无服务器函数的快速部署和高密度缓存的系统级方法**。为了减少启动时间，函数从单内核快照中部署，绕过了昂贵的初始化步骤。为了减少快照的内存占用，我们在运行一个函数所需的整个软件栈中应用了页级共享。我们通过在 FaaS 平台架构的计算节点上替换 Linux 来证明我们技术的效果。使用我们的原型操作系统，一个函数的部署时间从 100 多毫秒下降到 10 毫秒以下。在完全由新函数组成的工作负载上，平台的吞吐量提高了 51 倍。我们能够在内存中缓存超过 50,000 个函数实例，而使用标准的操作系统技术只能缓存 3,000 个**。综合来看，这些改进使 FaaS 平台具有处理大规模突发请求的新能力。
2019 年以及之前不含 serverless 方向的文章
2021.8.9-8.12
无服务器计算突出的按使用付费的特性，推动了其作为各种工作负载的替代计算范式的不断渗透。然而，在将机器学习工作负载转移到无服务器环境中时，出现了一些挑战，并且仍然没有解决。具体来说，无服务器平台对部署规模的限制与神经网络模型的复杂性相结合，使得在单个无服务器函数中部署大型模型变得困难。在本文中，我们旨在充分发挥无服务器计算范式在机器学习工作负载中的优势，在满足响应时间服务水平目标（SLO）的同时，减轻管理和整体成本。我们设计并实现了 AMPS-Inf，一个为无服务器计算中的模型推理而定制的自主框架。在成本效益和及时响应的驱动下，我们提出的 AMPS-Inf 为推理工作负载自动生成最佳执行和资源配置计划。AMPS-Inf 的核心依赖于混合整数二次编程问题的制定和解决，用于模型分区和资源配置，目标是在不违反响应时间 SLO 的情况下实现成本最小化。我们在 AWS Lambda 平台上部署了 AMPS-Inf，用 Keras 中最先进的预训练模型进行评估，包括 ResNet50、Inception-V3 和 Xception，并与 Amazon SageMaker 和三个基线进行比较。实验结果表明，AMPS-Inf 在不降低响应时间性能的情况下实现了高达 98% 的成本节约。
2021.5.17-5.21
由于能够通过一键上传和轻量级执行来简化代码部署，无服务器计算已经成为一种很有前途的范式，并且越来越受欢迎。然而，在使数据密集型分析应用适应无服务器环境时，仍然存在公开的挑战，无服务器分析的用户在协调不同阶段的计算以及在大的配置空间中配置资源方面遇到了困难。本文介绍了我们对 Astra 的设计和实现，它以自主方式配置和协调无服务器分析工作，同时考虑到灵活指定的用户需求。Astra 依赖于性能和成本的建模，该模型描述了多维因素（例如，函数内存大小、每个阶段的并行程度）之间错综复杂的相互作用。我们根据用户的具体要求制定了一个优化问题，以提高性能或降低成本，并开发了一套基于图论的算法，以获得最佳作业执行。我们在 AWS Lambda 平台上部署了 Astra，并在三个不同规模的代表性基准上进行了真实世界的实验。结果表明，与三种基线配置算法相比，Astra 可以实现无服务器分析的最佳执行决策，在给定的预算约束下提高 21% 到 60% 的性能，并在不违反性能要求的情况下降低 20% 到 80% 的成本。
2020.5.18-5.22
虽然有严格的服务质量限制的微服务被部署在云中，但由于昼夜负载模式，除了高峰时段，承载微服务的长期租用的基础设施的利用率很低。在高负荷时将微服务部署在长期基础设施中，在低负荷时将微服务部署在无服务器计算平台中，这对云计算供应商来说具有资源效率，对服务维护者来说具有成本效率。然而，先前的工作未能利用这一机会，因为无服务器平台上的微服务之间的争夺严重影响了它们的响应延迟。我们的调查显示，微服务的负载、无服务器平台上的共享资源争夺及其对争夺的敏感度共同影响了平台上微服务的响应延迟。为此，我们提出了 Amoeba，一个能动态切换微服务部署的运行时系统。Amoeba 由一个竞争意识的部署控制器、一个混合执行引擎和一个多资源竞争监视器组成。部署控制器根据微服务的负载和无服务器平台上的争用情况预测微服务的尾部延迟，并确定微服务的适当部署。混合执行引擎可以实现两种部署模式的快速切换。争用监视器定期对多种类型的共享资源的争用情况进行量化。实验结果表明，与传统的基于 IaaS 的纯部署方式相比，Amoeba 能够显著减少高达 72.9% 的 CPU 使用量和高达 84.9% 的内存使用量，同时确保达到所需的延迟目标。
2019 年及以前没有 serverless 领域的文章
2022.06.30
众所周知，将高度可扩展的无服务器平台用于 Web 微服务和 IoT 应用程序。但是，由于无服务器功能的无状态特性，它们在数据密集型应用程序中的使用受到限制。使用对象存储、数据库、缓存等云存储服务可以满足无服务器部署中应用程序的任何数据检索、存储和点对点通信需求。不同云服务提供商提供的异构云存储服务有独特的交付性能。一个关键挑战是找到从无服务器平台到云存储服务的最大可实现数据传输速率。
在这项工作中，我们评估了可用于来自多个云供应商的无服务器平台的存储系统的性能。此外，我们研究了云服务特性和配置对加速它们之间的数据传输的影响。实验数据提供了一些关键见解，以帮助使用无服务器平台和云存储服务设计应用程序架构。
2021.6.21-6.25
我们介绍Xtract，一个用于从大型分布式研究数据库中批量提取元数据的自动化和可扩展的系统。Xtract 协调元数据提取器在文件组中的应用，决定对每个文件应用哪些提取器，以及对每个提取器和文件在哪里执行。建立在 funcX 联合 FaaS 平台上的混合计算模型，使 Xtract 能够通过将每个提取任务分配到最合适的位置来平衡提取时间和数据传输成本之间的权衡。在一系列云和超级计算机上的实验表明，Xtract 可以通过协调成千上万个节点上的基于容器的提取器的并发执行，有效地处理数百万个文件库。我们通过将 Xtract 应用于一个大型的、半整理的科学数据库和一个未整理的科学 Google Drive 数据库来强调 Xtract 的灵活性。我们表明，通过在分散的存储和计算节点上远程协调元数据提取，Xtract 可以在 50% 的时间内处理大型存储库，而这只是将相同的数据传输到同一计算设施内的机器上。我们还表明，当传输数据是必要的（例如，没有本地计算），Xtract 可以扩展到处理文件的速度，甚至通过一个多 GB/s 的网络。
无服务器计算已经成为在云中运行短暂计算的新范式。由于其处理物联网工作负载的能力，人们对在边缘运行无服务器函数产生了相当大的兴趣。然而，边缘的约束性和工作负载的延迟敏感性给无服务器平台带来了许多挑战。在本文中，我们介绍了LaSS，一个使用模型驱动的方法在边缘资源上运行延迟敏感的无服务器计算的平台。LaSS 使用基于排队的原则性方法来确定对每个托管函数的适当分配，并根据工作负载的动态变化自动扩展分配的资源。LaSS 使用公平分享的分配方法，保证在过载的情况下为每个函数分配最小的资源。此外，它利用基于容器放空和终止的资源回收方法，将资源从超额配置的函数中重新分配给不足配置的函数。我们在 OpenWhisk 无服务器边缘集群上实现了我们方法的原型，并进行了详细的实验评估。我们的结果表明，LaSS 可以准确地预测无服务器函数在高动态工作负载下所需的资源，并在数百毫秒内重新配置容器容量，同时保持公平份额的分配保证。
2021.09.05-10
摘要：
主要云提供商越来越多地推出其无服务器工作流服务来编排无服务器函数，从而有效地构建复杂的应用程序。有必要进行全面的研究，以帮助开发人员了解优缺点，并在这些无服务器工作流服务中做出更好的选择。然而，这些 serverless 工作流服务的特点并没有得到系统的分析。为了填补知识空白，我们对四种主流的无服务器工作流服务进行了全面的测量研究，重点关注特性和性能。首先，我们回顾他们的官方文档，从编程模型、状态管理等六个维度提取他们的特征。然后，我们比较他们的性能（即函数的执行时间、工作流的执行时间、工作流的编排开销时间）在考虑到工作流的活动复杂性和数据流复杂性以及无服务器函数的函数复杂性的各种设置下。我们的发现和启示可以帮助开发人员和云提供商提高他们的开发效率和用户体验。
2021.12.6-10
摘要：
函数即服务 (FaaS) 是未来云服务最有前途的方向之一，无服务器函数已快速成为构建可扩展且具有成本效益的微服务和应用程序的新中间件。然而，快速发展的技术阻碍了可重复性，并且缺乏标准化的基准测试套件导致临时解决方案和微基准测试被用于无服务器研究，进一步复杂化研究解决方案的元分析和比较。为了应对这一挑战，我们提出了 Serverless Benchmark Suite：第一个 FaaS 计算基准，系统地涵盖了广泛的云资源和应用程序。我们的基准包括代表性工作负载的规范、随附的实施和评估基础设施，以及促进可重复性和可解释性的评估方法。我们证明了 FaaS 执行环境的抽象模型确保了我们的基准对 AWS、Azure 和 Google Cloud 等多个商业提供商的适用性。我们的工作为无服务器系统的实验评估提供便利，并提供标准化、可靠和不断发展的中间件 FaaS 平台的性能、效率、可扩展性和可靠性评估方法。
摘要：
在本文中，我们研究了允许在支持事务因果一致性 (TCC) 的情况下增强 FaaS 中间件的机制。乍一看，为 FaaS 应用程序提供 TCC 似乎很容易实现，因为 FaaS 模式不会阻止应用程序选择具有所需属性的存储服务。不幸的是，大多数 TCC 存储服务仅确保单个客户端进程的一致性，而 FaaS 应用程序由多个独立的工作进程执行。因此，需要协调工作人员，这项任务可能是开销的重要来源。我们提出了一种新的架构来支持 FaaS 中的 TCC，名为 FaaSTCC，它显着降低了协调开销。FaaSTCC 通过使用缓存层增加工作人员并实施最大化缓存使用率的新机制来实现这一目标。首先，我们的存储层向缓存层提供了一个承诺，它设定了一个范围，保证缓存检索到的版本是一致的。其次，在 FaaSTCC 中，函数使用快照间隔进行协调，支持读取快照的延迟识别，增加使用缓存值的机会。我们已经实施并通过实验评估了 FaaSTCC。我们的结果表明，与以前的工作相比，FaaSTCC 的平均延迟降低了 5 倍，尾部延迟降低了 6 倍。
2020.12.07-11
摘要：
函数即服务 (FaaS) 平台承诺为云计算提供更简单的编程模型，其中开发人员专注于编写其应用程序。相比之下，平台提供商负责资源管理和管理。由于 FaaS 用户是根据函数的执行来计费的，因此平台提供商有一种自然的动机，即不以平台为代价保持闲置资源的运行。但是，这种策略可能会导致冷启动问题，其中一个函数的执行被延迟，因为没有准备好的资源来承载执行。冷启动可能需要数百毫秒到几秒的时间，并且对于某些应用程序来说是一个令人望而却步且令人痛苦的缺点。**这项工作描述并评估了一种启动函数的技术，该技术从先前执行的函数进程中恢复快照。我们基于 CRIU 进程检查点/恢复 Linux 工具开发了该技术的原型。我们通过运行将其启动时间与标准 Unix 进程创建/启动过程进行比较的实验来评估此原型。**我们分析了以下三个函数：i）“无操作”函数，ii）Image Resizer 函数，以及 iii）渲染 Markdown 文件的函数。获得的结果表明，该技术可以将函数副本的启动时间提高 40%（在“无操作”函数的最坏情况下），图像调整器的启动时间提高 71%。进一步分析表明，运行时初始化是一个关键因素，我们通过基于不同代码大小的综合生成函数进行敏感性分析来证实这一点。这些实验表明，决定何时创建函数的快照至关重要。当创建暖函数的快照时，预烘焙技术实现的加速比更高：对于小型合成函数，加速比从 127.45% 提高到 403.96%；而对于更大的综合函数，这个比率从 121.07% 增加到 1932.49%。
摘要：
由于与虚拟机 (VM) 相比，它们具有更低的启动延迟和更精细的定价，Amazon Lambda 和其他云函数 (CF) 已被确定为处理简单、无状态工作负载中的意外峰值的理想候选者。但是，目前尚不清楚 CF 在自动扩展涉及跨分布式应用程序组件的重要状态传输的复杂工作负载方面是否同样有效。我们发现，通过精心设计，当前可用的 CF 确实可以用于复杂的工作负载。为了证明这一点，我们设计并实现了 SplitServe，它是 Apache Spark 的增强版。如果现有 VM 上没有足够的执行程序可用于新到达的延迟敏感作业，SplitServe 能够使用 CF 快速弥补 VM 中的这一不足，从而避免新请求的 VM 的启动延迟。如果在性能或成本方面需要，当新请求的 VM 或现有 VM 上的执行程序确实可用时，SplitServe 能够将正在进行的工作从 CF 转移到它们。我们使用四种不同的工作负载（在基于 VM 的执行程序和 CF 或仅 CF 的混合）上对 SplitServe 的实验评估表明，对于具有少量到适度改组的工作负载，它可以将执行时间提高多达 (a) 55%，并且 (b) 与仅基于 VM 的自动缩放相比，具有大量 shuffle 的工作负载占 31%。
摘要：
具有实时延迟限制的新兴物联网应用程序需要在边缘运行的新数据处理系统。无服务器计算提供了一种新的引人注目的范例，用户可以执行一个小型应用程序，而无需处理服务器配置和资源管理的操作问题。尽管有各种现有的商业和开源无服务器平台（利用虚拟机和容器），但这些解决方案对于资源受限的边缘系统来说太重了（由于大内存占用和高调用时间）。此外，专注于每个客户端的短期运行计算的无服务器工作负载并不适合现有的通用计算系统。
在本文中，我们介绍了 Sledge 的设计和实现——一种新颖且高效的基于 WebAssembly 的边缘无服务器框架。Sledge 针对支持无服务器工作负载的独特属性进行了优化：需要高密度多租户、低启动时间、突发的客户端请求率和短暂的计算。Sledge 通过提供 (i) 优化的调度策略和针对短期计算的有效工作分配，以及 (ii) 使用我们自己的基于 WebAssembly 的软件故障隔离基础设施实现的轻量级函数隔离模型来解决这些限制。这些轻量级沙箱旨在支持高密度计算：具有快速启动和拆卸时间来处理高客户端请求率。对具有不同工作负载和实际无服务器应用程序的 Sledge 进行的广泛评估证明了为边缘设计的无服务器优先运行时的有效性。与最快的开源无服务器框架之一 Nuclio 相比，Sledge 支持高达 4 倍的吞吐量和 4 倍的延迟。
摘要：
数据中心见证了为基于微服务的应用程序采用无服务器函数的快速增长。这些微服务中的绝大多数通常跨度不到一秒，具有严格的 SLO 要求，并根据应用程序的要求链接在一起。上述特征带来了一系列新挑战，尤其是在容器配置和管理方面，因为在无服务器平台中采用的最先进的资源管理框架倾向于着眼于类似于传统单体应用程序的基于微服务的应用程序。因此，这些框架遭受微服务不可知的调度和巨大的容器过度配置，特别是在工作负载波动期间，从而导致资源利用率低下。
在这项工作中，我们使用由 Kubernetes 和 Brigade 无服务器框架管理的多节点集群上的各种工作负载来量化上述缺点。为了解决这些问题，我们提出了 Fifer——一种自适应资源管理框架，可有效管理无服务器平台上的函数链。关键思想是使 Fifer (i) 通过使用函数感知容器扩展和智能请求批处理将打包作业有效地分箱到更少的容器中来提高使用意识，以及 (ii) 同时通过主动生成容器以避免冷启动，从而符合 SLO -starts，从而最大限度地减少整体响应延迟。结合这些优势，与无服务器平台采用的最先进的调度程序相比，Fifer 将容器利用率和集群范围的能耗分别提高了 4 倍和 31%，而不会影响 SLO。
摘要：
将任务组织为工作流是扩展无服务器计算框架适用性的基本特征。现有的无服务器平台要么对函数链（作为函数组合的工作流）不可知，要么依赖于无服务器框架的幼稚供应和管理机制——例如，它们在工作流中每个函数的触发器到达之后供应资源为工作流中的每个函数强制设置延迟。在这项工作中，我们专注于缓解级联冷启动问题——根据工作流规范触发一系列无服务器函数时的延迟开销。我们首先确定跨多个商业服务器平台和云提供商的冷启动情况下级联效应的性质和程度。为了减轻这些级联开销，我们设计和开发了一些优化，这些优化内置在我们的工具 Xanadu 中。Xanadu 根据所需的运行时隔离要求提供多个实例化选项，并支持有或没有明确的工作流规范的函数链接。 Xanadu 解决级联冷启动问题的优化是建立在资源的推测性和即时供应之上的。我们对 Xanadu 系统的评估表明，以最低的成本开销几乎完全消除了级联冷启动，优于可用的最先进平台。即使是相对较短的工作流程，与 Knative 相比，Xanadu 也将平台开销降低了近 18 倍，与 Apache Openwhisk 相比降低了 10 倍。
2019.12.9-13
摘要：
无服务器计算是一种新兴的范式，它极大地简化了云资源的使用，并且非常适合许多任务。最值得注意的是，函数即服务 (FaaS) 使程序员能够将云应用程序开发为可以独立运行和扩展的单独函数。然而，由于 FaaS 中存储和计算资源的分解，需要对可变状态和同步进行细粒度支持的应用程序（例如机器学习和科学计算）很难构建。在这项工作中，我们展示了 Crucial，这是一个使用无服务器架构对高度并发的有状态应用程序进行编程的系统。它的编程模型保持了 FaaS 的简单性，并允许轻松地将多线程算法移植到这个新环境。Crucial 建立在 FaaS 类似于数据中心规模的并发编程的关键见解之上。因此，分布式共享内存层是无服务器中细粒度状态管理和协调需求的正确答案。我们在微基准和各种应用程序的帮助下验证我们的系统。特别是，我们实现了两种常见的机器学习算法：k-means 聚类和逻辑回归。在这两种情况下，Crucial 都获得了与同等 Spark 集群更优或可比的性能。
2021.6.1-3
摘要：
无服务器计算模型利用 JavaScript 和 Java 等高级语言来提高云编程的抽象级别。然而，当今基于无状态短寿命函数的无服务器计算平台设计导致现代运行时错失了通过 JIT 编译和代码分析等技术优化无服务器函数的机会。
在本文中，我们展示了现代无服务器平台，例如 AWS Lambda，并没有充分利用语言运行时优化。我们发现在热容器上运行的大量函数调用是使用未优化的代码（热启动）执行的，导致性能下降几个数量级。
我们探索利用遍布潜在数千个节点的运行时知识来分析和优化代码的想法。为此，我们提出了 Ignite，这是一个无服务器平台，可以跨机器编排运行时，以便从一开始就运行优化的代码（热启动）。我们提供的证据表明，运行时编排有可能通过在数千个无服务器函数上运行优化代码来大大降低无服务器工作负载的成本和延迟。
摘要：
我们考虑云计算的未来，并询问我们如何将其引导到我们称为天空计算的更连贯的服务。障碍比技术更经济，我们建议将互惠对等作为关键的启用步骤。
摘要：
云提供商 API 已成为构成公共云的仓库规模计算机的实际操作系统接口。与单服务器操作系统一样，它们为这些大型机器提供资源分配、保护、通信路径、命名和调度。云提供商 API 还提供各种操作系统不具备的函数，例如大数据分析、机器学习模型训练或工厂自动化。某处，潜伏在这个服务群中，有一个操作系统接口连接到一台非常大的计算机，即今天的应用程序开发人员所针对的计算机。这台计算机不像单个服务器那样工作，但它也不是像互联网那样的分散分布式系统。这是介于两者之间的东西。现在是从众多云提供商 API（最好是可移植的 API）中提炼和完善连贯的“云系统接口”的时候了。在本文中，我们将讨论什么进入，什么被排除，以及为这些决定提供依据的原则。
摘要：
从云诞生之日起，运行多租户工作负载就给 Linux 内核的抽象带来了压力。在通过虚拟化绕过其抽象多年后，内核以本机容器抽象作为响应，该抽象正急切地应用于云中。在本文中，我们指出历史正在重演：随着无服务器计算的引入，即使是原生容器抽象也不适合。我们表明，使用 unikernels 绕过内核可以产生至少 6 倍的延迟和吞吐量。面对比以往任何时候都更复杂的内核和相对要求不高的计算模型，我们必须重新考虑内核是否应该尝试适应，我们应该继续绕过内核，或者是否终于是时候为这个重要的尝试新的原生操作系统了未来的云工作负载。
摘要：
无服务器是一个有吸引力的平台，适用于云中的各种应用，因为它具有弹性、低成本和快速部署的承诺。尽管这个想法很吸引人，但最近的工作表明，对于数据处理应用（不管是 OLTP、OLAP 还是 ML），现有的无服务器平台是不够的，在实践中需要额外的服务，往往是为了解决函数之间缺乏通信能力的问题。在本文中，我们展示了如何使用传统的 TCP/IP 实现函数与函数之间的通信能力，并展示了如何利用通信能力在无服务器平台上实现数据处理。在无服务器平台上以一种比现在更有效的方式实现数据处理。我们的基准测试显示，在 TPC-H 中查询的速度比使用云存储进行通信的系统快 11 倍。函数间的持续吞吐量 621 Mbit/s，往返延迟小于1 ms。
摘要：
无服务器计算提供了以自动扩展、随用随取的方式对云进行编程的潜力。在本文中，我们讨论了第一代无服务器计算的关键差距，这些差距使其自动扩展的潜力与现代计算的主流趋势不一致：特别是以数据为中心的分布式计算，以及开源和定制硬件。综合来看，这些差距使得目前的无服务器产品不适合云计算创新，尤其不适合数据系统创新。除了指出当前无服务器架构的一些主要缺陷外，我们还提出了一系列我们认为必须应对的挑战，以释放云--其超字节的存储和数以百万计的内核--应该为创新开发者提供的根本潜力。
摘要：
根据需求变化进行弹性扩展是无服务器计算的主要好处。当突发的工作负载到来时，无服务器平台会启动许多新的容器并初始化函数环境（称为冷启动），这就会产生大量的启动延迟。为了减少冷启动，平台通常在为一个请求提供服务后暂停一个容器，并为后续请求重用这个容器。然而**，这种重用策略不能有效地减少冷启动**，因为调度器对容器的生命周期是不可知的。例如，它可能会忽略很快可用的容器或驱逐很快需要的容器。我们为无服务器计算提出了一种容器生命周期感知的调度策略--CAS。其关键思想是控制请求的分配，并根据容器的不同生命周期阶段来决定容器的创建或驱逐。我们在 OpenWhisk 上实现了一个 CAS 的原型。我们的评估显示，CAS 减少了 81% 的冷启动，因此与 OpenWhisk 中的原生调度策略相比，在工作负载之间存在工人竞争的情况下，95 分位数的延迟减少了 63%，并且没有增加明显的性能开销。
2.AuctionWhisk: Using an auction-inspired approach for function placement in serverless fog platforms
响应需求变化的弹性扩展是无服务器计算的主要优势。当突发性工作负载到来时，无服务器平台会启动许多新容器并初始化函数环境（称为冷启动），这会导致显着的启动延迟。为了减少冷启动，平台通常会在服务请求后暂停容器，并将此容器重用于后续请求 。但是，这种重用策略不能有效地减少冷启动，因为调度程序与容器生命周期无关 。例如，它可能会忽略很快可用的容器或驱逐很快需要的容器。我们提出了一种用于无服务器计算的容器生命周期感知调度策略 CAS。其核心思想是控制请求的分布，根据容器的不同生命周期阶段确定容器的创建或驱逐 。我们在 OpenWhisk 上实现了一个 CAS 原型。我们的评估表明，当工作负载之间存在工作争用时，CAS 减少了 81% 的冷启动，因此与 OpenWhisk 中的本机调度策略相比，在 95% 的延迟处减少了 63%，并且不会增加显着的性能开销。
3.Standards-based modeling and deployment of serverless function orchestrations using BPMN and TOSCA
函数即服务（FaaS）是一种云服务模式，可以为各种使用情况实现无服务器应用程序。其范围从单一函数的预定调用到使用协调服务（如AWS步骤功能）执行的复杂函数协调。然而，由于现有的函数协调技术在函数、支持的建模语言和API方面各不相同，因此对此类函数协调的建模及其部署需要大量特定的技术知识。此外，由于供应商和技术的特殊细节，所产生的模型通常是不可移植的，并且由于这种锁定，在交换协调器或供应商时需要做出重大努力。为了解决这个问题，我们为无服务器函数协调的建模和部署引入了一种供应商和技术无关的方法，该方法依靠业务流程模型和符号（BPMN）以及云应用的拓扑和协调规范（TOSCA）标准，分别用于函数协调的建模及其部署。我们还介绍了一个工具链，用于在BPMN中对无服务器函数协调进行建模，从BPMN模型中生成不同函数协调技术支持的专有模型，在TOSCA中指定其实际部署，然后实施这种部署。最后，我们说明了在实践中应用我们的方法和工具链的案例研究。
摘要：
无服务器计算是一种新兴的事件驱动的编程模型，它可以加速云计算系统上可扩展的网络服务的开发和部署。虽然无服务器计算与公共云广泛结合，但在基于边缘的物联网（IoT）部署中，无服务器计算的使用还处于起步阶段。在这项工作中，我们提出了 STOIC（无服务器远程操作混合云），这是一个物联网应用部署和卸载系统，以三种方式扩展了无服务器模型。首先，STOIC 采用动态反馈控制机制，精确预测延迟，并使用分布式无服务器框架在边缘和云系统中统一调度工作负载。第二，STOIC 利用硬件加速（如 GPU 资源）在底层云系统可用的情况下进行无服务器函数执行。第三，STOIC 可以通过多种方式进行配置，以克服与公共云使用相关的部署差异性。我们概述了 STOIC 的设计和实现，并使用真实世界的机器学习应用和多层物联网部署（边缘和云）对其进行了经验评估。具体来说，我们表明 STOIC 可以用于训练图像处理工作负载（用于物体识别）--曾经被认为对边缘部署来说资源过于密集。我们发现，STOIC 减少了整体执行时间（响应延迟），并实现了 92% 至 97% 的安置精度。
摘要：
在亚马逊的 Lambda 平台推出后，无服务器计算迅速发展。函数即服务（FaaS）是无服务器计算的一个关键推动因素，它允许将一个应用程序分解为简单、独立的函数，并在 FaaS 平台上执行。FaaS 平台负责为这些函数部署和提供资源。今天的几个云计算应用分布在异构连接的计算资源上，并且在结构和资源要求上都是高度动态的。然而，FaaS 平台仅限于同质集群和同质函数，并且在调度前没有考虑到函数的数据访问行为。我们介绍了FaaS 对异构集群的扩展，并通过分布式异构目标平台的网络支持异构函数，称为函数交付网络（FDN）。一个目标平台是一个同质节点集群和其上的 FaaS 平台的组合。FDN 提供函数交付即服务（FDaaS），将函数交付给合适的目标平台。我们展示了各种机会，如不同目标平台的特点，多个目标平台之间协作执行的可能性，以及 FDN 在实现两个目标时提供的数据本地化。通过使用我们开发的分布式目标平台基准测试工具 FDNInspector 对五个以上的分布式目标平台进行评估，展示了在调度函数时服务水平目标（SLO）要求和能源效率。在我们的评估中，在边缘目标平台上调度函数，与在高端目标平台上调度相比，在不违反 SLO 要求的情况下，总体能耗降低了 17 倍。
Function-as-a-Service（FaaS）是无服务器云计算范例的一种形式，通过FaaS平台（例如AWS Lambda）执行事件触发代码段（即函数）来定义。 许多实证评估FaaS平台性能的研究已经开始出现，但我们目前缺乏对整个领域的全面理解。 为了解决这一差距，我们进行了一项多学科文献综述(MLR)，涵盖了来自学术（51）和灰色（61）文献的112项研究。 我们发现，现有的工作主要是研究AWS Lambda平台，并侧重于使用简单函数来测量CPU速度和FaaS平台开销（即容器冷启动）的微基准测试。 此外，我们发现在测试的平台配置上学术和工业来源之间的不匹配，发现函数触发器仍然没有得到充分的研究，并将HTTP API网关和云存储确定为使用最多的外部服务集成。 根据现有的云系统实验指南，我们发现了许多缺陷，这些缺陷威胁到所调查的研究中提出的实验的可重复性。 我们最后讨论了文献中的差距，并强调了可能有助于改进未来FAAS性能评估研究的方法学建议。
1.A Mixed-Method Empirical Study of Function-as-a-Service Software Development in Industrial Practice
FaaS 是一种可以使基础设施组件对开发人员透明化的云服务，是属于 “无服务器” 计算模型的一种。当使用FaaS产品 (如AWS Lambda) 时，开发者为他们的函数提供原子化的、短时运行的代码，FaaS服务提供商会按需执行和水平伸缩扩展它们。然而，对于开发人员如何使用serverless，哪些类型的应用程序适合serverless，以及相关应用程序应当基于什么样的架构样式和实践方式，至今没有系统的研究。我们采用了多种方法进行研究，包括与基于FaaS进行开发的工程师进行交流，对灰色文献进行系统分析以及在互联网上进行Web调查等。最终，我们发现，成功应用FaaS需要一种不同的思维模型——应用主要是通过组合已经存在的服务进行构建的，FaaS在其中则是充当将这些服务结合在一起的 “粘合剂”。并且，工具的可用性和成熟度，尤其是与测试和部署相关的工具，仍然是主要的困难。此外，我们发现当前的FaaS系统缺乏对函数复用的系统级支持，以及抽象和编程模型在构造较大的应用程序时受到一定的限制。最后，我们讨论了对FaaS服务提供商，软件开发人员和研究人员来说，Faas的意义是什么。
无服务器计算因其轻量级和简单的管理而越来越受欢迎。它通过将计算单元的粒度降低到函数级别来实现这些优点。具体来说，Serverless 让用户可以专注于功能本身，而将其他繁琐的管理和调度问题留给平台提供商，平台提供商负责在高性能调度和低资源成本之间取得平衡。在本文中，我们对无服务器计算进行了全面调查，特别关注其基础设施特征。从而确定了一些现有的挑战，并分析了相关的前沿解决方案。有了这些结果，我们进一步研究了一些典型的开源框架，并研究了它们如何应对已确定的挑战。鉴于无服务器计算的巨大优势，预计其部署将主导未来的云平台。因此，我们还设想了一些有前途的研究机会，需要在未来进一步探索。我们希望我们在本文中的工作能够激发相关领域的研究人员和从业者欣赏无服务器计算，从而涉足这个有前途的领域并为其发展做出巨大贡献。
无服务器计算是目前增长最快的云服务领域。最突出的无服务器产品是函数即服务 (FaaS)，用户在其中编写函数，云自动部署、维护和可扩展性。尽管 FaaS 非常适合执行无状态函数，但它不能充分支持微服务和可扩展、低延迟的云应用程序等有状态结构。最近，有多次尝试在 FaaS 系统中添加一流的状态支持，例如 Microsoft Orleans、Azure Durable Functions 或 Beldi。这些方法在无状态函数中执行业务代码，将其状态移交给外部数据库。 相比之下，Apache Flink 的 StateFun 等方法遵循不同的设计：Apache Flink 等数据流系统通过执行状态数据流图来处理所有状态管理、消息传递和检查点，从而提供精确一次的状态处理保证。 这种设计使程序员不必通过分布式系统错误检查、管理和缓解来“污染”他们的业务逻辑。尽管程序员可以轻松地开发应用程序而无需担心消息传递和状态管理，但跨有状态函数执行事务仍然是一个悬而未决的问题。
在本文中，我们介绍了一种用于有状态无服务器函数的事务编排的编程模型和实现。我们的编程模型支持具有两阶段提交的可序列化分布式事务，以及与 Sagas 最终一致的工作流。我们在 Apache Flink StateFun 上设计和实现我们的编程模型，以利用 Flink 的一次性处理和状态管理保证。我们的实验表明，在数据流图之上构建事务系统的方法可以实现非常高的吞吐量，但由于检查点机制保证了精确一次处理，因此存在延迟开销。我们将我们的方法与 Beldi 进行比较，后者在由 DynamoDB 支持的 AWS lambda 函数上实现两阶段提交以进行状态管理，以及使用 CockroachDB 作为其后端的系统实现。
1.Descriptive and Predictive Analysis of Aggregating Functions in Serverless Clouds: the Case of Video Streaming
无服务器云将多个用户的多个任务（如微服务）分配到一个共享的计算资源池中。这使得无服务器云提供商能够通过透明地聚合某种背景下的类似任务（如视频处理）来减少其资源使用量，这些任务共享其全部或部分计算。为此，了解通过聚合任务实现的时间节省量是至关重要的。缺乏这样的知识会导致不知情的合并和调度决策，反过来又会导致合并后的任务或其他后续任务违反最后期限。因此，在本文中，我们以视频处理为例，研究了估算合并任务带来的执行时间节省问题。为了了解不同形式的合并所节省的执行时间，我们首先建立了一组基准视频，并检查了各种各样的视频处理任务--有无合并。我们观察到，尽管合并可以节省 44% 的执行时间，但可能的合并案例的数量是难以解决的。因此，在第二部分，我们利用基准测试结果，开发了一种基于梯度提升决策树（GBDT）的方法来估计任何给定任务合并情况下的时间节省。实验结果表明，根据均方根误差（RMSE）衡量，该方法可以估计出节省的时间，误差率为 0.04。
在这项工作中，我们提出了 FaaSter，一个加速函数即服务（AFaaS）产品，它将函数即服务模式与 GPU 加速资源统一起来。FaaSter 提供了一个加速函数库作为服务，而这又是在异构的 GPU 上提供的。为了提供对这些加速函数的无缝访问，并确保每个函数具有最佳的响应时间，我们利用 GPU 内核切片，在多个异构 GPU 上分割和执行一个加速函数实例。核心挑战是要能够快速决定将每个函数分割成多少片，然后将这些片映射到合适的 GPU 上。为此，我们提出了一种调度启发式方法，与非切片的全 GPU 调度方法相比，能够显著减少函数的平均周转时间。我们的评估结果显示，FaaSter 调度器在平均周转时间方面实现了 62% 的平均改善，最高可达 80%，并且总是与非可分片的 GPU 调度表现相当或更好。
摘要截止日期 2022.11.25
无服务器计算已经成为云计算模式的一个流行部分，这要归功于对基础设施管理的抽象化，使开发者能够编写在多语言环境中自动扩展的函数，而只需为使用的计算时间付费。虽然这种模式是处理不可预测和突发工作负载的理想选择，但数百毫秒或更多的冷启动延迟仍然阻碍了它对延迟关键型物联网服务的支持，而且当无服务器函数部署在边缘时，可能会取消因接近而带来的延迟优势。此外，边缘主机通常具有的 CPU 功率和内存限制使延迟更高。问题的根源在于无服务器函数的运行环境，即 Docker 等容器技术。因此，一个激进的方法是用一个更轻量级的替代方案来取代它们。为此，我们研究了 WebAssembly 作为无服务器容器运行时的适用性，重点是边缘计算环境，并介绍了基于 WebAssembly 的无服务器边缘计算运行时环境的设计和实现。我们在 Apache QpenWhisk 中执行 WebAssembly 的原型 WOW，与标准的基于 Docker 的容器运行时相比，在低端边缘计算设备上为各种无服务器工作负载减少了高达 99.5% 的冷启动延迟，可以提高 5 倍以上的内存消耗，并提高了高达 4.2 倍的函数执行产量。
在无服务器计算中，应用程序在轻量级的虚拟化和隔离环境下执行，如容器或微型虚拟机。通常情况下，它们的内存分配是由用户在部署前设置的。所有其他资源，如**CPU，都由供应商静态地分配，并与内存分配成比例。这导致了利用不足或节流。前者严重影响了提供者，而后者则影响了客户。**为了解决这个问题并同时满足客户和供应商的需求，一个解决方案是通过自动缩放实现动态 CPU 分配。使用基于历史的技术和预测，已经对长期运行的应用进行了自动缩放的研究。然而，无服务器应用是短期运行的工作负载，这种技术并不适合。在本文中，我们研究了微小的自动缩放器以及动态 CPU 分配技术在短时运行的无服务器工作负载中的表现。**我们将 Kubernetes 作为底层平台进行实验，并利用其 VPA 实现了几种动态 CPU 权限分配技术。**我们使用最新的无服务器工作负载来比较这些技术。我们的实验表明，针对短时运行的无服务器函数的动态 CPU 分配是可行的，并且可以通过提供良好性能的轻量级算法实现。
无服务器计算是为网络边缘的物联网（IoT）应用提供服务的一种有前途的模式。它的事件触发式计算，以及细粒度和敏捷的资源扩展，非常适合资源有限的边缘计算环境。然而，**在云环境中占主导地位的通用自动扩展器对边缘的无服务器计算表现不佳。这主要是由于在资源预算约束和动态工作负载下难以快速确定最佳资源分配。在本文中，我们提出了一个自适应自动缩放器 KneeScale，它可以动态地调整无服务器函数的副本数量，以达到增加资源分配的相对成本不再值得相应的性能优势。**我们将 KneeScale 设计并实现为轻量级的系统软件，利用 Kubernetes 来管理资源。使用函数即服务（FaaS）基准 FunetionBeneh 和开源无服务器计算平台 OpenFaaS 的实验结果表明了 KneeScale 的卓越性能和资源效率。在给定的资源预算下，它的累计性能比 Kubernetes Horizontal Pod AutoScaler（HPA）和 OpenFaaS 的内置调度器分别高出 32% 和 106%。KneeScale 实现了比两种竞争技术更高的累积吞吐量，比 OpenFaaS 内置调度器更低的延迟，而与 HPA 相比，各种无服务器函数的延迟也很相似。
在本文中，我们提出了无服务器边缘计算的能源意识调度。能源意识至关重要，因为在许多物联网（IoT）领域，边缘节点要由可再生能源供电，而可再生能源是可变的，这使得低功率和/或过载（瓶颈）的节点不可用，不能运行其服务。这种意识也是需要的，因为能源挑战以前没有被 Serverless 解决过，主要是由于它起源于云计算。为了实现这一目标，我们对无服务器边缘计算中的能源意识资源调度问题进行了正式建模，给定了一个由电池供电和可再生能源供电的节点集群。然后，我们设计了面向分区和基于优先级的算法，以提高瓶颈节点的运行可用性。作为资产，我们的算法为了服务质量（QoS）的利益，创造了 "粘性卸载 "和 "温暖调度 "的术语。我们根据众所周知的基准，在一个支持容器编排、Kubernetes 和无服务器计算 OpenFaaS 的 Raspberry Pis 集群上使用真实世界的实现来评估我们的提案，其中边缘节点由真实世界的太阳辐射供电。，其中边缘节点由现实世界的太阳能照射提供能量。实验结果显示，在保持 QoS 的同时，帮助瓶颈节点的运行可用性有了明显的改善，最高可达 33%。有了能源意识，现在无服务器可以无条件地在边缘提供其资源效率和可移植性。
无服务器计算正在迅速普及，因为它能够实现快速的应用部署和无缝的应用扩展，而无需管理复杂的计算资源。最近，它已被探索用于运行数据密集型的工作负载，如深度学习（DL），以提高应用性能和降低执行成本。然而，**无服务器计算带来了资源层面的限制，特别是固定的内存分配和短暂的任务超时，这导致了工作失败。在本文中，我们解决了这些限制，并开发了一个有效的运行时框架DiSDeL，它通过利用数据分割技术来提高 DL 作业的性能，并确保为容器分配适量的内存来存储应用数据，并根据无服务器部署中的复杂性为每个作业选择合适的超时。**我们使用 Apache OpenWhisk 和 TensorFlow 平台实现了我们的方法，并使用代表性的 DL 工作负载对其进行了评估，结果显示，与默认的无服务器计算框架相比，它消除了 DL 作业的失败，并将动作内存消耗和总训练时间分别减少了 44% 和 46%。我们的评估还显示，与多租户环境下的裸机 TensorFlow 相比，DiSDeL 实现了高达 29% 的性能提升。
欧洲核子研究中心的大型强子对撞机（LHC）在过去十年中为高能物理（HEP）领域产生了前所未有的大量数据。对分析这些数据感兴趣的科学合作机构往往需要超出单台机器的计算能力。这个问题传统上是通过使用有状态、有管理的批处理计算系统在分布式环境中运行分析来解决的。虽然这种方法到目前为止是有效的，但目前对该领域未来计算需求的估计带来了巨大的扩展挑战。这种管理方法可能不是解决这些问题的唯一可行方法，无服务器架构可以提供一个有趣的选择，以实现更大的扩展潜力。这项工作描述了一种通过分布式无服务器计算引擎运行真实 HEP 科学应用的新方法。该引擎建立在 ROOT 的基础上，ROOT 是一个成熟的 HEP 数据分析软件，并将其计算分布到亚马逊网络服务 Lambda 无服务器平台上的一个大型并发执行池。由于所开发的工具，物理学家能够访问存储在欧洲核子研究中心的数据集（也包括那些受限制的访问政策），并在其典型环境之外的远程基础设施上处理它。无服务器函数的分析在运行时被监控，以收集性能指标，包括数据和计算密集型的工作负载。
无服务器编程模型的一个最突出的实现是函数即服务（FaaS）。使用 FaaS，应用程序开发人员提供无服务器函数的源代码，通常只描述较大应用程序的一部分，并定义触发器，以便在 FaaS 供应商管理的基础设施组件上执行这些函数。仍有一些挑战阻碍了 FaaS 模式在整个云端 - 边缘 - 物联网连续体中的广泛采用。这些挑战包括边缘和物联网基础设施的高度异质性、供应商锁定、需要在网络物理执行环境中部署和适应无服务器函数及其支持服务和软件堆栈。作为应对这些挑战的第一步，我们推出了 SERVERLEss4I0T 平台，用于设计、部署和维护云 - 边缘 - 物联网连续体上的应用。特别是，我们的平台能够在云和边缘资源上规范和部署无服务器函数，以及在整个云 - 边缘 - 物联网连续体上部署其支持服务和软件堆栈。
目前最先进的无服务器框架无法在几毫秒内执行突发工作负载的函数。其原因在于，它们通常依靠水平弹性来应对对资源的不同需求，这在冷启动的情况下会产生很高的开销。最近的文献集中在使用快照等机制来最小化水平弹性的开销。然而，新函数实例的生成仍然需要几十毫秒的时间。**本文提出了垂直弹性来扩展无服务器函数的资源，以应对突发的工作负载。我们设计了 LatEst，这是一个用于无服务器框架的控制器，可以适应活动函数实例的分配资源。**通过垂直扩展，LatEst 可以在几毫秒内适应函数调用的爆发。LatEst 实现了一个反馈控制回路，以 (1) 预测工作负载变化期间所需的资源；(2) 对这种变化作出快速和准确的反应。此外，当底层服务器的资源达到极限时，LatEst 为函数生成新的实例。我们将 LatEst 作为 vHive 的扩展进行评估，发现 LatEst 与 vHive 相比，可以将无服务器函数的尾部延迟提高 25 倍。
最近开展了基于人工智能（AI）的研究，用于早期检测 COVID-19。其目的是防止该疾病的传播和死亡病例的数量。在基于人工智能的 COVID-19 诊断研究中，数据的完整性对于获得可靠的结果至关重要。在本文中，我们提出了一个基于区块链的框架，称为 AIBLOCK，以提供工业 4.0、医疗保健和网上银行等应用所需的数据完整性。此外，所提出的框架与谷歌云平台（GCP）- 云函数相结合，这是一个无服务器计算平台，通过提供动态可扩展性自动管理资源。五个不同的机器学习模型的性能被评估，并在准确性、精确性、召回率、F-Score 和曲线下面积（AUC）方面进行比较。实验结果显示，决策树在准确性方面给出了最好的结果（98.4%）。此外，已经确定利用区块链技术可以增加内存的负载。
函数即服务（FaaS）已经成为云中的一项关键服务。它使客户能够将他们的应用设想为最小的无服务器函数的集合，彼此之间进行互动。FaaS 平台将所有的管理复杂性抽象给客户。这种新兴的范式也很有吸引力，因为它的计费模式。客户端根据函数的执行时间来收费，允许更精细的定价。因此，尽可能快地执行函数对降低成本是非常重要的。**一些研究已经调查了 FaaS 环境中的运行时间优化，但没有一项研究探索了 CPU 缓存分配。事实上，CPU 缓存争用是软件中一个众所周知的问题，FaaS 也不能免于这个问题。**为了解决 CPU 高速缓存的分区问题，已经进行了各种硬件改进。其中，英特尔在他们的新处理器中实施了一项新技术，允许缓存分区。缓存分配技术（CAT）。这项技术允许将缓存方式分配给进程，每个进程对缓存的使用将被限制在分配的数量内。在本文中，我们提出了 CASY（CPU Cache Allocation SYstem），这是一个使用英特尔 CAT 技术为无服务器函数执行 CPU 缓存分配的系统。CASY 使用机器学习为函数建立缓存使用概况，并使用该概况根据函数的输入数据预测缓存需求。由于 CPU 的缓存大小较小，CASY 集成了一种分配算法，确保缓存负载在所有的缓存方式上得到平衡。我们实现了我们的系统，并将其整合到 OpenWhisk 平台中。我们的评估显示，一些无服务器函数的执行时间减少了 11%，而没有降低其他函数的性能。
将作为协调的无服务器函数组成的应用程序放置在云计算基础设施上是一个棘手的问题，因为它必须考虑硬件、软件、网络服务质量和服务互动的限制。在本文中，我们提出了一种新颖的声明式方法，可以处理上述所有问题，同时还依靠信息流分析和填充技术来防止信息通过旁路泄漏。一个来自增强现实的激励性用例被用来展示实现我们建议的开源原型。
2021.5.10-2021.5.13
在函数即服务 (FaaS) 中，一种无服务器计算变体，客户部署函数而不是完整的虚拟机或 Linux 容器。维护这些函数的运行时环境的是云提供商。所有主要云提供商（例如 Amazon Lambda、Google Cloud Functions、Azure Functions）都提供 FaaS 产品；以及独立的开源软件（例如 Apache OpenWhisk）及其商业变体（例如 Adobe I/O Runtime 或 IBM Cloud Functions）。我们采用 FaaS 集群中单个节点的自下而上的视角。我们假设已经安装了分配给该节点的一组函数的所有执行环境。我们的目标是安排由负载均衡器传递的函数的单独调用，以最小化与响应时间相关的性能指标。部署的函数通常会重复执行以响应最终用户的多次调用。因此，我们的调度决策基于本地收集的信息：记录的调用频率和执行时间。我们提出了一些启发式方法，并且我们还采用了一些具有理论基础的启发式方法，例如 SEPT 或 SERPT。我们的模拟使用最近发布的 Azure Functions Trace。我们表明，与基线 FIFO 或循环相比，我们的数据驱动调度决策显着提高了性能。
无服务器计算通过大规模组合松散耦合的微服务来实现快速的应用程序开发和部署。这种新兴的范式极大地减轻了云环境用户的负担，无需提供和管理底层云资源。随着责任的转移，云提供商面临的挑战是在不影响可靠性的情况下向用户提供可接受的性能，同时对应用程序要求的了解最少。次优资源分配，特别是 CPU 资源，可能会导致违反应用程序的性能要求。此外，细粒度的无服务器计费模型仅根据函数执行时间对资源使用收费。同时，提供者必须将底层基础设施保持在永远在线模式，以方便异步函数调用。因此，在不影响应用程序需求的情况下实现云资源的最佳利用对提供商来说非常重要。当前的大部分工作只关注最小化由基础设施设置延迟引起的函数执行时间，并降低最终用户的资源成本。然而，在本文中，我们同时关注提供者和用户的观点，并为部署在无服务器计算环境中的应用程序提出了函数放置策略和动态资源管理策略。这些策略在满足用户的应用需求（即期限）的同时，最大限度地降低了服务提供者的资源消耗成本。所提出的解决方案对截止日期很敏感，并有效地提高了提供商的资源利用率，同时动态管理资源以改善函数响应时间。我们使用 ContainerCloudSim 工具包通过模拟来实施和评估我们的方法。与基线调度技术相比，所提出的函数放置策略可以将资源消耗减少多达三倍。使用固定资源分配策略和比例 CPU 份额策略评估动态资源分配策略时，在满足所需的函数期限方面表现出高达 25% 的改进。
作为云领域的颠覆性范式，无服务器计算因其降低运营成本和外包基础设施管理的独特价值主张而备受关注。然而，企业函数即服务 (FaaS) 平台可能会带来重大风险，例如供应商锁定、多租户导致缺乏安全控制、复杂的定价模型以及法律和法规遵从性——尤其是在移动计算场景中。这项工作提出了一种生产级容错无服务器架构，该架构基于使用开源框架的高可用性 Kubernetes 拓扑，部署在 OpenStack 实例上，并以现实中的缩小的 Azure 工作负载跟踪数据集为基准。通过测量成功率、吞吐量、延迟和自动可扩展性，我们成功地评估了三种不同代表性工作负载在逻辑模型下的弹性和持续性能。我们的测试执行表明，有 95% 的置信度，70 到 90 个并发用户可以访问系统，同时体验可接受的性能。超出确定的断点（即每秒 91 个事务），Kubernetes 集群必须扩展或扩展以满足 QoS 和可用性要求。
无服务器计算是一种新颖的云计算范式，云提供商管理底层基础设施，而用户只需要上传应用程序的代码。函数即服务 (FaaS) 是一种无服务器计算模型，其中短期方法在云中执行。FaaS 有前途的用例之一是运行科学工作流应用程序，它代表了由相关任务组成的科学过程。由于 FaaS 的独特函数，包括快速资源供应、间接基础设施管理和细粒度计费模型，因此需要创建专用的调度方法，以有效地将新型基础设施用作工作流应用程序的环境。在本文中，我们提出了两种新颖的调度算法 SMOHEFT 和 SML，它们旨在创建一个时间表，用于在无服务器基础设施上执行有关时间和成本限制的科学工作流。我们通过执行实验来评估提出的算法，我们计划执行三个应用程序：Ellipsoids、Vina 和 Montage。SDBWS 和 SDBCS 算法被用作基线。SML 在执行 Ellipsoids 工作流时取得了最好的结果，成功率在 80% 以上，而其他算法在 60% 以下。在 Vina 的情况下，除 SDBWS 之外的所有算法的成功率都在 87.5% 以上，而在 Montage 的情况下，所有算法的成功率相似，都在 87.5% 以上。所提出的算法的成功率与其他研究解决方案提供的相当或更好。
无服务器架构是一种快速发展的范例，用于部署执行临时计算和服务突发工作负载的深度学习应用程序。无服务器架构保证了推理深度学习模型的自动扩展和成本效率，同时最小化操作逻辑。但是，无服务器计算是无状态的，对本地资源有限制。因此，部署包含大型模型、框架和库的复杂深度学习应用程序是一项挑战。在这项工作中，我们讨论了将深度视觉算法和基于模型的应用程序迁移到无服务器计算平台的方法和架构。我们使用 AWS 基础设施（AWS Lambda、预置并发、VPC 端点、S3 和 EFS）测试了我们的方法，以缓解部署包含大型深度学习模型和框架的 API 组合的挑战。我们针对用于文档处理的真实企业应用程序评估我们的架构的性能和成本。
无服务器计算是一种事件驱动的云计算架构，用于按需处理请求，使用轻量级函数容器和微服务模型。物联网 (IoT) 服务、边缘计算和流处理等各种应用程序已被引入到无服务器范式中。这些应用程序的特点是它们对响应时间的要求很严格，因此期望应用程序能够提供快速且容错的反馈。无服务器或函数即服务 (FaaS) 范式面临函数“冷启动”挑战，其中无服务器平台需要时间来设置依赖项、准备运行时环境和代码以供执行，然后再为传入的工作负载提供服务。目前大多数工作通过（1）减少函数容器的启动或准备时间，或（2）减少平台上函数冷启动的频率来解决冷启动问题。最近的工业研究发现，诸如运行时环境、CPU 和内存设置、调用并发和网络要求等因素会影响函数的冷启动。因此，我们提出了强化学习（Q-Learning）代理设置，通过提前准备函数实例来分析识别的函数 CPU 利用率等因素，确定函数调用模式并降低函数冷启动频率。所提出的 Q-Learning 代理通过分别使用每个实例的 CPU 利用率、可用的函数实例和响应的成功或失败率来离散化环境状态、动作和奖励，与 Kubeless 无服务器平台交互。使用 Apache JMeter 非 GUI 工具包复制工作负载，并根据 Kubeless 的基线默认自动扩展函数评估我们的代理。代理展示了学习调用模式的能力，通过在受控环境设置下在学习期间准备最佳数量的函数实例来做出明智的决策。
7.AI-based Resource Allocation: Reinforcement Learning for Adaptive Auto-scaling in Serverless Environments
近年来，无服务器计算已成为一种引人注目的云计算模型新范式。它承诺以大规模和低成本为用户提供服务，同时消除对基础设施管理的需求。在云提供商方面，需要灵活的资源管理来满足波动的需求。它可以通过自动配置和取消配置资源来启用。商业和开源无服务器计算平台之间的一种常见方法是基于工作负载的自动缩放，其中指定的算法根据传入请求的数量来缩放实例。在最近发展的无服务器框架 Knative 中，提出了一种基于请求的策略，其中算法通过配置的最大请求数来扩展资源，每个实例可以并行处理，即所谓的并发。正如我们在基线实验中所展示的，这种预定义的并发级别会强烈影响无服务器应用程序的性能。但是，由于各种因素，例如，识别产生最高服务质量的并发配置是一项具有挑战性的任务。不同的工作负载和复杂的基础设施特征，影响吞吐量和延迟。尽管已经对用于优化虚拟机配置的自动扩展的智能技术进行了大量研究，但该主题尚未在无服务器计算领域进行讨论。出于这个原因，我们研究了强化学习方法在无服务器框架中对基于请求的自动扩展的适用性。我们的结果表明，在有限的迭代次数内，我们提出的模型学习了每个工作负载的有效扩展策略，与默认的自动扩展配置相比，提高了性能。
函数即服务 (FaaS) 是一项引人注目的技术，它允许用户以事件驱动的方式运行函数，而无需担心服务器管理。基于容器的虚拟化使函数能够在轻量级和隔离的运行时环境中运行，但伴随着容器初始化（冷启动）的频繁函数执行会使平台繁忙且无响应。出于性能考虑，鼓励暖启动，即在已经初始化的容器上执行函数，因此 FaaS 平台努力将函数调度到暖容器。根据我们操作本地 FaaS 平台的经验，我们发现现有的调度程序对多租户和高并发工作负载表现出较差的性能和不稳定的行为。本文提出了一种新的 FaaS 调度算法，名为 FPCSch，它调度 Function-Pulling-Containers，而不是将函数调度到容器。由于 FPCSch 让容器不断拉取相同类型的函数，冷启动显着减少。我们的评估表明，配备 FPCSch 的 Apache OpenWhisk 具有许多适合 FaaS 平台的特性； (1) 相对于越来越多的函数类型混合的多租户工作负载，吞吐量相当稳定，(2) 吞吐量增加以增加并发性，(3) 均匀负载平衡资源密集型工作负载，以及 (4) 几乎成比例的性能向外扩展。
智能环境是由越来越多的异质资源和设备组成的，用于收集和处理大量的环境数据。这些活动可以在智能区域的边缘，通过分布式和异构的基础设施进行，以便接近终端用户并优化响应时间。然而，很难定义一个能够支持不同系统之间以及系统和用户之间数据交换的数据模型。本文介绍了智能环境的主要特征，并引入了虚拟设备的概念，即以特定的高级函数为特征的抽象化组件。然后，本文提出了一个数据模型，用于表示和优化智能环境中的虚拟设备的采用。为了更好地解释数据模型的特点和好处，我们参考了一个视频监控用例，其中一个智能摄像机能够提供实心角检测服务。
函数即服务（FaaS）是无服务器计算的一种形式，是最近的云计算服务产品之一，它将资源的管理和配置以及应用程序的部署抽象化和自动化。它提供了强大的抽象，将应用程序组成无状态函数，并通过事件触发其执行。该平台为应用程序提供自主扩展，并提供 "即用即付 "的秒级计费模式。然而，当代 FaaS 平台在说明资源需求方面提供的函数有限。它们往往缺乏表达应用特性和与服务质量（QoS）相关的资源要求的规范。这样的规范可以有效地指导资源提供者的资源配置和函数部署，从而实现高效的资源利用和成本节约。这项研究探索激发了对 FaaS 的 QoS 规范框架的需求，并提出了实现初始 QoS 感知 FaaS 平台的想法。基于现实世界工作负载跟踪的实验结果表明，QoS 可以为 FaaS 平台带来成本节约和有效的资源利用。
2020.5.11-2020.5-14
我们提出了一个使用动态任务放置的无服务器边缘云平台的性能优化框架。我们专注于智能边缘设备的应用，例如智能相机或扬声器，它们需要在实时或接近实时的情况下对输入数据执行处理任务。我们的框架允许用户为每个应用任务指定成本和延迟要求，对于每个输入，它决定是在边缘设备上还是在云中执行任务。此外，对于云端执行，该框架确定了满足性能目标所需的容器资源配置。我们利用从 AWS Lambda 和 AWS Greengrass 中的无服务器应用中收集的测量数据对我们的框架进行了模拟评估。此外，我们还实现了我们的框架原型，在这些相同的平台上运行。在对我们的原型进行的实验中，我们的模型可以预测平均端到端延迟，误差小于 6%，而且与纯边缘执行相比，我们获得了几乎三个数量级的端到端延迟减少。
2.Cost-Effective Malware Detection as a Service Over Serverless Cloud Using Deep Reinforcement Learning
目前云计算的总体趋势，特别是无服务器计算，影响到组织活动的多个方面。各种规模的组织都在将其部分业务从内部过渡到外部，以降低成本并更有效地扩展其业务。网络安全领域也不例外，许多组织都在利用分布式和可扩展的云环境。由于无服务器计算的收费模式是 "随用随付"（即按行动付费），减少所需的计算次数就会转化为巨大的成本节约。这种理解也与恶意软件检测领域有关，在该领域，各组织经常部署多种类型的检测器以提高检测精度。在这项研究中，我们利用深度强化学习来减少云计算中的计算成本，只选择性地查询可用的检测器的子集。我们证明，我们的方法不仅对企业内部和基于云的计算架构有效，而且将其应用于无服务器计算可以降低成本一个数量级，同时保持接近最优的性能。
在函数即服务（FaaS）平台中快速部署和执行云函数是至关重要的，例如，对于微服务架构。然而，需要大型包或库的函数是臃肿的，而且启动缓慢。一种优化方法是在工作节点上缓存软件包，而不是将其与函数捆绑在一起。然而，现有的 FaaS 调度器是虚有其表的负载均衡器，不知道为响应先前的函数执行而缓存的包，因此不能适当地获得包缓存的好处。我们研究了包感知调度的情况，并提出了 PASch，这是一种新颖的调度算法，在调度过程中寻求包的亲和力，以便工作节点可以重新使用预装包的执行环境。PASch 利用一致的散列和 2 种选择的力量，同时积极避免工人过载。我们在 OpenLambda 框架的新调度器中实现了 PASch，并使用模拟和实际实验对其进行评估。当使用 PASch 而不是负载最小的平衡器时，任务感知到的平均速度提高了 1.29 倍，而第 80 个百分点的延迟则提高了 23 倍。此外，对于本文研究的工作负载，PASch 超过了有界负载的一致散列算法--一种最先进的负载平衡算法--产生了 1.3 倍的平均速度，在第 80 百分位数时速度提高了 1.5 倍。
2018 年及 2018 年之前没有该 serverless 方向的论文
2020 年没有该 serverless 方向的论文
2019.12.4-12.6
无服务器计算已成为应用程序和服务部署的一种新的引人注目的范式，它使开发人员能够更多地关注业务逻辑而不是基础设施。Serverless 计算平台使函数容器规模为零，这导致了一个严重的问题，称为冷启动。冷启动严重影响了无服务器计算平台的响应能力，并限制了无服务器计算在更广泛的应用程序中的使用和采用。传统策略以牺牲资源为代价来减少冷启动延迟。如何同时最小化冷启动延迟和减少策略执行的资源消耗是一个具有挑战性的问题。在本文中，我们首先提出了一种自适应预热策略（AWUS）来预测函数调用时间并预热函数，从而减少冷启动延迟。我们使用函数链模型来改进 AWUS。我们采用细粒度回归方法来更准确地预测函数链中的非第一函数。其次，我们提出了一种自适应容器池扩展策略（ACPSS）来减少函数启动时间。我们动态调整容器池的容量，减少资源浪费。AWUS 和 ACPSS 协同工作以减少冷启动延迟和资源浪费。最后，我们实现了一个无服务器计算平台并进行了广泛的实验来评估我们的策略。评估结果证明了我们策略的有效性。
2018 年及以前没有该 serverless 方向的论文
2021.03
1.Deployment Management and Topology Discovery of Microservice Applications in the Multicloud Environment
摘要：
云计算推动了现代软件应用程序设计的发展。基于微服务架构的应用程序就是一个例子。同时，多云作为一种基础架构战略被企业广泛接受；然而，挑战依然存在。现代应用程序的自主性和可分布性，以及多云基础设施的复杂性，通常使通用应用程序部署管理变得不切实际。这种现象可能会进一步阻碍应用程序的质量和效率。因此，多云基础设施环境中的部署资源控制和拓扑发现是云计算研究的一个有趣领域。本文提出了一个框架来管理多云环境中的应用程序部署。该框架使用基于策略的部署控制从多云基础架构中自动选择和提供部署资源，随后使用拓扑发现来可视化和验证实际部署。论文中介绍了所提出的框架设计，并实现了概念验证原型。在经验场景中进行实验。实验结果表明，所提出的框架在控制部署资源和呈现跨云的实际部署方面是有效的。
摘要：
本文介绍了一个开源平台，以支持跨云连续体的基于科学数据处理工作流的应用程序的无服务器计算（即同时涉及本地和公共云平台来处理在边缘捕获的数据）。这是通过为 FaaS 平台提供动态资源来实现的，该平台与归零方法兼容，可最大限度地减少具有不同弹性要求的动态工作负载的资源使用和成本。该平台结合了在本地云上动态部署的自动扩展 Kubernetes 集群和自动云突发入 AWS Lambda 以实现更高级别的弹性。智能城市公共卫生用例用于评估该平台，负责从捕获的视频中检测未戴口罩的人。面部被模糊以增强本地云中的匿名性，并且通过深度学习模型在 AWS Lambda 中执行此数据驱动的容器化工作流程的检测。结果表明，跨云连续体的混合工作流可以有效地执行本地数据处理以增强法规遵从性，并执行云爆发以提高弹性水平。
摘要：
为了处理来自世界各地的用户请求，在线服务需要调度资源以满足地理分布式数据中心对各种资源的相应随机需求。为充分发挥云资源优势，挖掘私有基础设施潜力，最优调度方案应考虑不同类型数据中心的异构性。它导致了一个高度复杂的非线性规划问题。为了找到有效的解决方案，我们引入了一个相关且简单的问题，以快速获得接近最优的可行解决方案，然后利用具有特殊步骤的差分进化过程来快速解决它。通过使用模拟和真实数据对算法进行测试，我们发现我们的算法优于现有算法，可以增加 34% 以上的收入。
摘要：
函数即服务 (FaaS) 引起了人们对如何“驯服”无服务器计算以支持特定领域用例的兴趣，例如数据密集型应用程序和机器学习 (ML) 等等。最近，已经实施了几个系统来训练 ML 模型。当然，这些研究文章是朝着正确方向迈出的重要一步。但是，它们并没有完全回答无服务器 ML 训练何时比传统的“服务式”计算更具成本效益这一棘手问题 。为了帮助完成这项工作，我们提出了 MLLess，这是一个基于 FaaS 的 ML 训练原型，构建在 IBM Cloud Functions 之上。 为了提高成本效率，MLLess 针对无服务器计算的特点实施了两项创新优化：一方面，一个显着性过滤器，使间接通信更有效，另一方面，一个扩展自动调谐器，以减少受益于 FaaS 亚秒计费模型（通常每 100 毫秒），从而降低成本。我们的结果证明，对于表现出快速收敛的稀疏 ML 模型（例如稀疏逻辑回归和矩阵分解），MLLess 可以比 serverful ML 系统快 15 倍，而且成本 更低。此外，我们的结果表明，MLLess 可以轻松扩展到越来越大的无服务器工作者队伍。
摘要：
最先进的无服务器平台使用硬编码的调度策略，不知道函数可能的拓扑约束。 在调度函数时考虑这些约束可以显着提高性能，例如，最小化加载时间或数据访问延迟。当在新兴的多云和边缘云连续系统中考虑时，这个问题变得更加紧迫，在这些系统中，只有特定的节点才能访问专门的本地资源。为了解决这个问题，我们提出了一种用于定义无服务器调度策略的声明性语言，以表达对调度程序和执行节点的拓扑结构的约束。我们将我们的方法实现为 OpenWhisk 平台的扩展，并展示我们的扩展与普通 OpenWhisk 相当或优于普通 OpenWhisk 的相关场景。
摘要：
无服务器云计算处理几乎所有的系统管理操作，使程序员更容易使用云。它提供了一个界面，大大简化了云计算的编程，并代表了一种与从汇编语言到高级编程语言的过渡相类似的进化。本文简要介绍了云计算的历史，包括对 2009 年《伯克利云计算观》论文的预测的说明，解释了无服务器计算的动机，描述了拉伸无服务器当前极限的应用，然后列出了无服务器计算发挥其全部潜力所需的障碍和研究机会。正如 2009 年的论文指出了云计算的挑战，并预测这些挑战将得到解决，云计算的使用将加速，我们预测这些问题是可以解决的，无服务器计算将发展到主导云计算的未来。
摘要：
函数即服务 (FaaS) 是一种极具吸引力的云计算模型，可简化应用程序的开发和部署。但是，当前的无服务器计算平台在调度函数时不考虑数据放置。随着对边缘云连续体、多云和多无服务器应用程序的需求不断增长，这个缺陷意味着无服务器技术仍然不适合媒体流等对延迟敏感的操作。这项工作通过展示一个名为 FaDO 的工具提出了一个解决方案：FaaS Functions and Data Orchestrator，该工具旨在允许跨位于不同位置（例如边缘和云中）的多服务器无服务器计算集群进行数据感知功能调度。 FaDO 通过基于标头的 HTTP 反向代理工作，并使用三种负载平衡算法：1) 最少连接，2) 循环，以及 3) 随机基于集合在合适的无服务器计算集群中对函数的调用进行负载平衡存储策略。FaDO 进一步为用户提供了对无服务器计算集群存储的抽象，允许用户通过统一的接口跨不同的存储服务与数据进行交互。此外，用户可以配置自动和策略感知的粒度数据复制，使 FaDO 在遵守位置限制的同时跨集群传播数据。负载测试结果表明，它能够对高吞吐量工作负载进行负载平衡，将函数放置在其数据附近，而不会产生任何显着的性能开销
摘要：
无服务器计算的出现为向云用户交付计算资源带来了重大进步。随着基础架构、平台和执行环境的抽象化，这些层的管理开销转移到了云提供商身上。因此，云用户可以专注于应用层，同时依靠云提供商来配置和操作底层。此外，自动缩放和高可用性等理想功能由云提供商实现，并由用户代码采用，无需额外开销。尽管取得了这些进步，但随着应用程序从单片独立部署过渡到无服务器计算的短暂和无状态微服务模型，必须克服重大挑战。这些挑战与无服务器计算的概念和实现模型的独特性有关。在本文中，我们研究了无服务器函数执行的服务水平协议 (SLA) 的建模。我们强调无服务器 SLA 与早期云交付模型的根本区别。然后，我们提出了一种根据函数执行的资源利用指纹来定义无服务器函数的 SLA 的方法，以及一种评估执行是否符合该 SLA 的方法 。最后，我们展示了我们提出的方法的经验验证，该方法能够以超过 76% 和高达 100% 的准确度检测执行 SLA 违规。
摘要：
虚拟机 (VM) 从共享的物理基础设施中逻辑地抽象出单用户的计算，从而构成了现代云计算的基础。这些服务的用户需要不同大小和配置的被供应商放置于不同物理机 (PMs) 上的虚拟机。同一 PM 上的 VM 共享内存和 CPU 资源，因此放置 (Placement) 不当会直接影响用户体验的质量。我们考虑放置 Firecracker VMs (一种 Micro-VM 或 μVM) - 通常用于短期任务的轻量级 VM。我们的目标是当每个 VM 到达时放置 VM，以使 PM 之间的资源使用峰值与平均值的比值达到最小。放置 VM 具有挑战性，因为我们需要从多个维度考虑资源使用，例如 CPU 、内存，并且资源使用会随着时间的推移而变化。过去解决类似问题的方法表明，预测用于放置 VM 的资源使用是可行的。我们发现，在我们的生产流量中，μVM 资源的使用是有波峰的和短暂的，且预测算法没有用处。我们针对此问题评估了强化学习 (RL) 方法，但发现现有的 RL 算法并不总是有好的性能。我们提出了一种称为 FirePlace 的无预测算法。它使用Hindsigth优化 (HOP) 的变体来学习放置决策，我们称之 Hindsight 模仿。我们用来自 AWS Lambda 的 μVM 使用的生产流量跟踪来评估我们的方法。FirePlace 在 100K μVM 的生产数据跟踪上比基准算法提高了 10%。
摘要：
我们描述了一家主要云提供商的无服务器 DAG 的生产工作负载。我们的分析强调了限制性能的两个主要因素：（a）在 DAG 中的无服务器函数之间缺乏有效的通信方法，以及（b）当 DAG 阶段调用一组并行函数时，这些函数必须在开始下一个 DAG 阶段之前完成.为了解决这些限制，我们提出了 WISEFUSE，这是一种针对用户指定的延迟目标或预算为无服务器 DAG 生成优化执行计划的自动化方法。我们引入了三个优化：(1) Fusion 将串联函数组合在一个 VM 中，以减少级联函数之间的通信开销。 (2) Bundling 在一个 VM 中执行一组函数的并行调用，以改善并行工作者之间的资源共享，以减少 skew。 (3) 资源分配为 DAG 中的每个函数或函数组分配正确的 VM 大小，以减少 E2E 延迟和成本。 我们实施 WISEFUSE 以使用具有不同 DAG 结构、内存占用和中间数据大小的三个流行的无服务器应用程序对其进行实验性评估。与竞争方法和其他替代方案相比，WISEFUSE 在端到端延迟和成本方面有显着改善。具体来说，对于机器学习管道，WISEFUSE 在不增加成本的情况下，实现了比 Photons 低 67%、比 Faastlane 低 39%、比 SONIC 低 90% 的 P95 延迟。
摘要：
无服务器是云服务架构师的热门选择，因为它可以以最少的开发人员工作量提供可扩展性和基于负载的计费。函数即服务 (FaaS) 最初是无状态的，但新兴框架添加了有状态抽象。例如，广泛使用的 Durable Functions (DF) 允许开发人员以选择的编程语言编写高级无服务器应用程序，包括可靠的工作流和参与者 。 DF 隐式且持续地持久化应用程序的状态和进度 ，这极大地简化了开发，但会造成 IOps 瓶颈。
为了提高效率，我们引入了 Netherite，这是一种用于在弹性集群上执行无服务器工作流的新颖架构。 Netherite 将众多应用程序对象分组到较少数量的分区中，并通过管道传输每个分区的状态持久性 。这改善了延迟和吞吐量，因为它使工作流步骤能够对提交进行分组，即使是因果相关的。此外，Netherite 利用 FASTER 的混合日志方法来支持大于内存的应用程序状态，并实现计算主机之间的高效分区移动。
我们的评估表明，(a) Netherite 比原始 DF 引擎实现了更低的延迟和更高的吞吐量，在某些情况下提高了一个数量级以上，并且 (b) Netherite 的延迟低于一些常用的替代方案，例如 AWS Step Functions 或云存储触发器。
1.A Holistic View on Resource Management in Serverless Computing Environments: Taxonomy and Future Directions
摘要：
近年来，无服务器计算已成为云应用程序的一种有吸引力的部署选项。这种计算模型的独特之处包括快速自动扩展、强大的隔离性、细粒度的计费选项以及访问自主处理资源管理决策的大规模服务生态系统。由于这些特征，这种模型也越来越多地被探索用于地理分布的边缘和雾计算网络中的部署。计算资源的有效管理一直受到研究人员的广泛关注。对资源供应、分配、调度、监控和扩展的整个过程自动化的需求导致需要专门关注无服务器模型下的资源管理 。在本文中，我们确定了涵盖无服务器环境中更广泛的资源管理概念的主要方面，并提出了影响这些方面的元素分类法，包括系统设计的特征、工作负载属性和利益相关者的期望。我们全面了解跨边缘、雾和云计算网络部署的无服务器环境。我们还使用此分类法分析了讨论无服务器资源管理方面的现有工作。本文进一步确定了文献中的空白，并强调了未来提高该计算模型能力的研究方向。