论文略读: Pocket

Pocket: ML Serving from the Edge

• Eurosys 2023

1. 重新设计了一个轻量级的进程间通信机制, 而不是使用传统的例如 GRPC 等
2. 自己实现了一个隔离机制, 防止不同前端共享后端时的相互干扰
3. 实现了一个资源放大(利用cgroup), 即 IPC 通信可以显式改变后端的资源分配

摘要

解决的问题: 边缘设备训练时的资源分配问题

Pocket:

• based on:

  • a shared ML runtime backend
  • lightweight ML application pocket containers

• key:

  • lightweight IPC (support for cross-client isolation)
  • a novel resource amplification method

Introduction

ML 程序内存占用大, 在数据中心可以通过横向扩展(增加配置)来解决, 但是在 MEC (Mobile Edge Computing) 中并不好解决.

思想:

将应用程序分为前端和后端组件, 后端组件在多个应用间共享:

The intuitive solution is to separate an application into two components, an application-specific frontend and a backend runtime component that can be shared across multiple ap- plications

但是跨容器共享会带来额外的开销 (grpc 引起的 per-client memory demand and runtime overheads)

pocket 的设计就是为了解决 shared heavy-weight runtimes

主要的设计思路:

1. lightweight IPC
2. cross-client isolation
3. resource amplification (本文提出的新概念)

Design

Lightweight pocket IPC

问题:

1. 避免容器之间的数据复制
2. 减少前后端之间传输的端到端延迟 (经过的软件层太多, 例如在一次 RPC 中, 一个请求需要经过宿主机的 network stack 和容器的 network stack)
3. IPC 机制可能带来内存压力, 由于其内置的冗余功能

因此 pocket 重新设计了一个轻量级 IPC, 采用 System V shared memory and message queues
(共享内存和消息队列)

Isolation

使用共享后端如何保证对前端的隔离问题

pocket 采用:

1. IPC namespace per container + nested IPC namespace in addition
2. Capabilities list to prevent unauthorized access

Resource Amplification

resources 如何在 pocket application 和 pocket service 之间分配的问题

静态预分配资源: 不好确定分配的资源数目, 因为由多个因素共同决定

pocket:

修改了 IPC 通信机制, 加入控制流, 即可以通过 IPC 显式请求资源的重新分配, 实现资源放大 (amplification)

如何实现?

1. 使用守护进程: 不是好的选择, 因为会产生额外地开销
2. 异步执行: 无法控制资源的"放大"何时完成

pocket 采用 cgroup 的资源限制调整来实现, 当 pocket 向后端发送 IPC 请求时候, 后端的资源分配会增加, 然后当后端服务完成后, 资源被重新返回给 pocket

资源放大的参数由前端配置, pocket 提供了一个 API 来集成了资源重新分配机制

实现

• python, 4000行, 目前只支持 tensorflow