20、MSC 原型实现架构与性能评估

MSC 原型实现架构与性能评估

1. MSC 原型实现架构

1.1 媒体仓库（Media Repository）

媒体仓库负责存储媒体数据，它可以添加内容去重和近似存储等功能。为了便于管理不断增长的媒体库，MSC 将媒体的元数据存储在与媒体片段分离的数据结构中，以便快速访问。这些元数据可供调度器模块用于做出调度决策。除了常见的预定义数据字段（如分辨率、比特率、编解码器）外，MSC 还允许将额外的自定义数据字段作为字典与其他数据一起存储。例如，额外信息可帮助提供商将其内容分类，使其仅对特定用户集（如高级用户或特定年龄以上的用户）可用。

在分布式或联合部署的情况下，每个 MSC 节点的媒体仓库可以只存储预期在该位置使用的整个媒体库的一个子集，而不是完整的仓库。如果请求的内容在该位置不存在，媒体仓库将从其他附近的 MSC 节点获取缺失的片段。

1.2 服务仓库（Service Repository）

服务仓库管理 MSC 可以执行的处理类型。在 MSC 中，用户（如流服务提供商甚至最终用户）可以动态定义新的流处理服务。传统上，每个无服务器函数是一个无状态的独立函数，用于执行一个任务（然后终止）。然而，由于媒体处理可能具有较大的框架依赖，MSC 还允许以持久容器的形式提供常用函数。即每个容器保持活动状态，以服务特定一组任务类型的多个实例（这些任务类型共享相同的处理框架）。这样，MSC 可以显著减少重复加载大型函数的开销。

1.3 请求摄取（Request Ingestion）

请求摄取处理观众提出的所有处理请求。当用户请求到达时，请求摄取组件会验证用户对内容的访问权限（包括用户计费余额的可用性）。然后，每个流请求会生成多个可以并行处理的任务。本质上，请求摄取组件将用户请求转换为 MSC 要处理的任务，并定义了截止日期。对于大多数媒体流，每个请求的截止日期是媒体片段的呈现时间。

在某些情况下，如果具有确切规格的指定媒体已经被缓存，则内容将直接发送给用户，而无需重新处理。

1.4 任务准入控制（Task Admission Control）

准入控制是任务队列（等待调度器调度的任务队列）的前门，它负责根据每个媒体片段的紧急程度为其分配优先级和某些内部元数据。此外，它还可以扩展以执行其他功能，如去重或将到达的任务与系统中现有的任务合并。

每个处理任务是以下三者的关联：
- 媒体流所需的预分割媒体片段（预分割方式允许它们独立并行处理）；
- 服务仓库中可用的处理服务；
- 处理规格和元数据。

需要注意的是，某个函数可能一次需要多个预分割媒体片段。例如，混音器功能可能需要人声媒体片段、音乐片段和效果片段，以便在流式传输给最终用户之前按照用户定义的音量设置进行组合。

1.5 任务队列（Task Queue）

在 MSC 中，任务被定义为对象（即媒体片段）和动作（即函数调用及其参数）的一对。任务正式定义为 (T_q = {(s_{xy}, f_i)|T_q \subset S \times F})，其中 (S = {s_{xy}|x \in \forall MediaID, y \in SegmentID})，(F = {f_i|\forall f_i \in ServiceRepository})。

此外，系统中的任务为了调度目的被分为四种状态：
- 未映射任务（Unmapped Task）：表示它们未被映射到计算单元上执行；
- 待处理任务（Pending Task）：已映射并等待在计算单元上执行；
- 运行任务（Running Task）：在每个计算单元上正在执行；
- 完成任务（Completed Task）：已从计算单元完成执行。

只有处于未映射阶段的任务驻留在中央任务队列中，其他状态的任务被分派到指定的计算节点。

1.6 任务调度器（Task Scheduler）

MSC 将调度器逻辑作为一个模块化的即插即用组件。实现了几个示例调度器，包括之前讨论过的一些调度器。要将它们部署到 MSC 中，每个调度器必须遵守以下几个限制以适应系统：
- 并非所有任务执行单元都能处理任何给定的任务类型。这是由于异构任务和计算资源的性质以及服务容器的可用性。
- 即使能够处理任务类型的任务执行单元也可能太忙而不能被视为候选者（即它们的等待队列太长）。
- 调度决策必须符合与流服务提供商定义的计费政策。

1.7 任务执行时间估计器（Task Execution Time Estimator）

时间估计器预测每个请求在每个任务执行单元上的任务执行时间（和完成时间）。为了平衡可用性和预测准确性，时间估计器模型的执行时间遵循正态分布。因此，时间预测的结果具有均值和标准差分量。然而，该类可以被重写，以更复杂的方式预测执行时间，例如根据需要使用概率质量函数（PMF）或概率密度函数（PDF）。

在 MSC 中对时间估计器进行了三种实现的原型设计：
- 配置文件模式（Profile Mode） ：时间估计器读取预定义的表格，获取每个媒体片段在指定任务执行单元类型上使用指定处理服务的预期执行时间。这种模式具有高度确定性，主要适用于测试和模拟调度器。
- 学习模式（Learn - Mode） ：时间估计器从先前的任务执行中积累历史数据，以形成对后续任务类型进行估计的知识。与配置文件模式不同，此模式下的时间估计器不会区分不同媒体片段的估计数据。即，在同一任务执行单元上执行相同操作的任务，无论涉及的媒体片段如何，都会得到相同的时间估计。这种模式在预期任务类型变化较大且没有完整的执行时间配置文件时很有用。
- 混合模式（Hybrid - Mode） ：当有估计配置文件可用时，使用配置文件模式中的预定义表格数据；对于没有预定义估计配置文件的情况，使用学习模式的逻辑进行预测。

1.8 执行引擎（Execution Engine）

执行引擎由可扩展的任务执行单元池组成。任务执行单元被定义为调度器视角下最细粒度的计算资源，它必须有自己的机器队列，调度器可以将任务分配到该队列。一旦启动，执行引擎中的每个任务执行单元都会监听其机器队列，等待调度器分配的任务。机器队列对于有效利用处理能力至关重要，它可以最小化调度事件之间的资源空闲时间。当任务到达机器任务队列时，任务执行单元会在轮到执行之前提前获取相应的媒体（如视频片段）。

对于具有正常优先级的任务，所有机器队列主要以先来先服务（FCFS）的方式管理。然而，高优先级任务可以插队以进行紧急执行。

1.8.1 执行引擎内的异构性

MSC 平台中的函数执行单元可以作为裸机、虚拟机（VM）或容器启动。在这个原型中，重点使用容器作为默认的函数执行单元，因为它比虚拟机具有更低的开销，同时仍提供一定的隔离性和可移植性。在容器平台内，有两种函数执行方案：
- 按需启动临时容器（Ephemeral Container） ：每个容器平台（如 Docker 平台）在函数容器外部有一个任务队列。收到任务请求后，会创建一个函数容器来服务该任务，任务完成后终止。这种执行模型允许多个函数分时共享计算资源。以临时容器的形式启动函数是在有限内存空间内支持大型函数仓库的重要方法。然而，这种类型的任务执行单元会带来重复启动和终止函数容器的显著开销，包括从仓库获取容器、启动容器以及将任务（包括视频片段）从共享队列转发和初始化到容器中。
- 预分配持久容器（Durable Container） ：函数执行单元的第二种配置是在每个容器内包含调度队列和功能代码。这样，每个容器都有自己的任务队列，可从主任务调度器访问，而无需首先使用容器平台的任务队列。每个容器被创建来服务特定一组函数的多个任务，这种方式执行的函数称为持久容器。

执行持久容器配置的任务可以减少重复启动和终止容器的开销，以及与临时容器相比更少的数据转发开销。然而，当没有任务使用容器时，保持函数可用会浪费内存。因此，需要一个供应器来最小化空闲的持久容器。

1.9 供应管理器和弹性管理器（Provisioning Manager and Elasticity Manager）

在大型函数仓库中，每个函数的使用频率各不相同，只有一小部分函数经常被使用，而其余的很少被访问。因此，扩展执行单元的内存以保持所有函数随时可用以便快速激活在经济上是不合理的。选择哪些函数分配专用资源以进行快速执行，而其他函数根据请求提供，这一点至关重要。此外，每个流行函数可能非常受欢迎，以至于单个函数执行单元（即容器）无法满足其使用需求。因此，复制流行函数的执行单元可能比将此类资源用于不太流行的函数更有益。

函数供应管理器监控和调整每个计算主机内可用的函数实例。具体来说，它决定在主机中保留哪些函数（容器）以及多少个工作实例，以服务即将到来的任务。

弹性管理器管理计算资源的扩展和缩减。当工作负载增加时，它会获取更多计算主机（物理和虚拟机）；当工作负载压力降低时，它会减少计算资源。如果 MSC 部署在无法控制实际供应的公共无服务器云上，MSC 的供应管理器将以另一种模式运行，即调整无服务器平台使用的适当预算限制，将实际的资源管理工作留给无服务器平台。

1.10 流管理器（Stream Manager）

流管理器位于处理管道的末端附近。它跟踪所有用户请求的所有媒体片段，并确保所有片段都得到正确及时的处理。如果某个片段缺失，流管理器可以请求准入控制以紧急优先级重新发送该片段的处理请求。流管理器还允许在系统中执行多阶段（即工作流）任务。当流管理器检测到某个任务需要使用不同的服务功能进行进一步处理以达到观众的规格要求时，它会相应地生成新任务。

1.11 媒体缓存（Media Caching）

媒体流到达观众之前的最后一个阶段是媒体缓存组件。媒体缓存管理流通道（直接流或通过 CD），并在此阶段进行计费。缓存系统可以确定每个片段的热度（即受欢迎程度）。预测在不久的将来会再次被请求的媒体片段可以缓存在本地缓存服务器或 CDN 上以供重用。

2. 性能评估

2.1 实验设置

实验分为两部分。前两个实验侧重于评估任务执行单元的部署配置，其余实验评估 MSC 作为一个整体系统在不同调度策略下的性能。

用于评估的媒体仓库包括一组视频，这些视频在内容类型和长度方面都具有多样性。仓库中的视频长度在 [10, 220] 秒之间，被分割成 5 - 110 个视频片段。基准视频是公开可用的，以便可重复性。实验中的处理服务包括降低分辨率、调整比特率和调整帧率。在每种情况下，都会检查两个转换参数。例如，帧率从 60 fps 降低到 30 或 24 fps。

为了评估系统在各种工作负载强度下的性能，用户请求被配置为在固定时间间隔内请求 [1500, 3000] 个媒体片段处理任务。除了前两个实验外，所有函数都以热启动函数的形式部署。处理任务一次以最多 20 个连续片段的组形式到达系统。为了准确描述在实际视频流系统中观察到的常见工作负载到达模式，每个工作负载会在基本周期和高负载周期之间反复切换到达率，高负载周期的到达率是基本周期的两倍，每个基本周期大约是高负载周期的三倍长。

2.2 评估任务执行单元配置

2.2.1 评估任务执行单元的启动延迟

比较了三种任务执行单元部署方式（裸机、容器和虚拟机）的启动延迟。评估了三种函数大小的启动延迟：
- 小函数：函数代码编译成 200 MB 的容器镜像。
- 中函数：需要多个视频处理依赖项，使函数容器总大小达到 400 MB。
- 大函数：需要 600 MB 的空间。

在设置中，启动虚拟机的延迟远远超过其他方案，在所有配置中都超过 12 秒。为了清晰显示其他配置，将虚拟机的数据从图表中排除。从性能上看，在裸机上启动任务执行单元的启动开销最小。然而，这种配置缺乏隔离性和扩展灵活性。在裸机上运行的函数执行单元可能会相互干扰，特别是因为每个函数都有自己的软件依赖项，可能会相互冲突。将任务执行单元部署在容器中可以消除这种缺点，同时只带来最小的开销。

2.2.2 评估临时容器与持久容器

评估了使用容器进行任务处理时临时容器和持久容器的开销。使用与上一个实验相同的三种函数大小进行实验。

从分配 1 到 4 个任务到从任务执行单元获得处理结果的往返时间来看，持久函数在运行第一个任务之前需要更多时间进行初始化，这额外的开销是由于与调度器的消息队列注册初始化。然而，后续任务（重用持久容器）的执行时间比使用临时函数容器时更短。因此，建议将常用函数分配为持久容器。

2.3 评估调度策略

评估了系统中用户在三种调度策略下的感知服务质量（QoS），即 QoS 感知（在图中称为优先级）、先来先服务（FCFS）和最早截止日期优先（EDF）。任务执行在八个并发的持久容器上运行。通过实验可以观察到不同调度策略下任务的截止日期错过情况等性能指标。

综上所述，MSC 原型实现通过合理的架构设计和组件配置，在媒体处理和调度方面具有一定的优势，并且通过性能评估可以为不同场景下的部署和优化提供参考。例如，根据函数的使用频率选择合适的容器部署方式，以及根据工作负载特点选择合适的调度策略等。

3. 架构组件关系与流程梳理

3.1 组件关系图

为了更清晰地展示 MSC 原型实现架构中各组件之间的关系，我们可以用 mermaid 绘制如下流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A[媒体仓库]:::process --> B[服务仓库]:::process
    C[请求摄取]:::process --> D[任务准入控制]:::process
    D --> E[任务队列]:::process
    E --> F[任务调度器]:::process
    F --> G[任务执行时间估计器]:::process
    F --> H[执行引擎]:::process
    H --> I[供应管理器和弹性管理器]:::process
    H --> J[流管理器]:::process
    J --> K[媒体缓存]:::process
    B --> F
    A --> H

从这个流程图中可以看出，媒体仓库和服务仓库为后续的任务处理提供基础数据和服务支持。用户请求经过请求摄取、任务准入控制后进入任务队列，再由任务调度器根据任务执行时间估计器的结果进行调度，最终由执行引擎执行任务。供应管理器和弹性管理器负责资源的调配，流管理器保证媒体片段的正确处理，媒体缓存则是媒体流到达用户前的最后一站。

3.2 任务处理流程

下面我们详细梳理一下 MSC 系统中任务处理的流程：
1. 请求阶段 ：
- 用户向系统发送媒体处理请求，请求摄取组件接收请求，验证用户的访问权限和计费余额。
- 如果请求的媒体已缓存且符合要求，直接从媒体缓存发送给用户；否则，将请求转换为多个可并行处理的任务。
2. 任务准备阶段 ：
- 任务准入控制为每个任务分配优先级和内部元数据，可能进行去重或合并操作。
- 任务进入任务队列，处于未映射状态。
3. 调度阶段 ：
- 任务调度器根据任务执行时间估计器的预测结果，结合计费政策和任务执行单元的可用性，将任务分配到合适的任务执行单元。
- 任务执行时间估计器可以采用配置文件模式、学习模式或混合模式进行时间预测。
4. 执行阶段 ：
- 执行引擎中的任务执行单元监听机器队列，获取分配的任务。
- 任务执行单元提前获取相应的媒体数据，开始执行任务。执行单元可以是临时容器或持久容器，持久容器适用于常用函数以减少开销。
- 供应管理器和弹性管理器根据函数使用频率和工作负载调整资源。
5. 监控与调整阶段 ：
- 流管理器跟踪所有用户请求的媒体片段，确保处理的及时性和正确性。如果有片段缺失，请求重新处理。
- 媒体缓存管理流通道和计费，根据片段的热度进行缓存。

4. 性能评估结果总结与应用建议

4.1 性能评估结果总结

评估项目	评估内容	结果
任务执行单元启动延迟	裸机、容器和虚拟机三种部署方式	裸机启动开销最小，但缺乏隔离性和扩展性；容器启动开销小且具有隔离性；虚拟机启动延迟大
临时容器与持久容器开销	分配 1 - 4 个任务的往返时间	持久容器初始化开销大，但后续任务执行时间短
调度策略	QoS 感知、先来先服务、最早截止日期优先	不同调度策略下任务的截止日期错过情况不同

4.2 应用建议

根据性能评估结果，我们可以为不同场景下的 MSC 系统应用提供以下建议：
1. 任务执行单元部署 ：
- 对于对隔离性要求不高、函数使用相对固定的场景，可以考虑使用裸机部署任务执行单元，以获得最小的启动开销。
- 对于大多数情况，建议使用容器部署，既能保证一定的隔离性，又能控制启动开销。
- 对于常用函数，应分配为持久容器，以减少重复启动和终止容器的开销；对于不常用函数，可以使用临时容器。
2. 调度策略选择 ：
- 如果系统对服务质量要求较高，需要优先处理紧急任务，可以选择 QoS 感知调度策略。
- 如果任务之间没有明显的优先级差异，且希望公平处理每个任务，可以选择先来先服务调度策略。
- 如果任务有明确的截止日期，且需要保证任务按时完成，最早截止日期优先调度策略可能更合适。

5. 总结

MSC 原型实现架构通过多个组件的协同工作，实现了高效的媒体处理和调度。媒体仓库和服务仓库提供基础支持，请求摄取、任务准入控制、任务队列、任务调度器等组件确保任务的合理分配和执行，执行引擎负责具体的任务处理，供应管理器和弹性管理器、流管理器、媒体缓存则从不同方面保障系统的性能和稳定性。

通过性能评估，我们了解了不同任务执行单元部署方式和调度策略的优缺点，这为实际应用中根据具体需求进行系统配置和优化提供了重要依据。在未来的媒体处理系统开发和部署中，可以参考这些架构设计和性能评估结果，以提高系统的效率和服务质量。同时，随着技术的不断发展，还可以进一步研究和改进这些组件和策略，以适应不断变化的媒体处理需求。