无人机自主飞行平台–存储服务选择和成本优化

无人机自主飞行平台概要回顾

在上一篇《无人机自主飞行平台建设实践：借助 Karpenter 和 Spot 实例，将平台计算成本降低 90%》中，我们介绍了平台的功能、特点，以及如何对计算部分进行灵活的弹性伸缩和成本优化。

无人机自主飞行平台对存储的需求

无人机自主飞行平台除了对算力的灵活需求外，另外一个重要部分就是数据的存储和流转。不管是数据平台、云测试平台、AI 训练平台，还是模拟仿真平台，都是以数据密集型的应用场景为主。

• 数据平台和云测试平台：并发任务数量多，从几十到几百个并发不等；数据集容量一般在几 GB～十几 GB；每个任务对存储带宽一般在十几～几十 MB 的数量级，但大多数任务独立运行，只有部分中间结果数据需要共享。
• AI 训练平台和模拟仿真平台：并发任务数量从几个到十几个；以 AI 训练任务为例，训练数据集的数据量从几百 G～十几 TB 不等；由于数据量大，数据加载时间也是一个重要考量点；AI 训练任务对存储的性能有着超高要求，存储带宽从几百 MB～几GB 不等；同时在数据预处理、分布式训练、超参调优等方面，都要求需要提供数据共享的功能。

无人机自主飞行平台存储架构

通常，一说到数据存储，我们首先会想到 Amazon S3。它是一种高可靠性、高扩展性的对象存储服务，提供可靠的数据存储和访问，适用于各种数据类型和规模。在无人机自主飞行平台中，我们以 Amazon S3 为数据底座：原始采集的各种飞行数据、标注后的数据、各子平台的结果数据……

但是在平台业务处理过程中，我们需要用到块存储或者文件存储来应对。亚马逊云科技提供丰富的存储服务，比如 Amazon S3，Amazon EBS，Amazon EFS, Amazon FSx 系列等，以满足客户各种业务场景的需求。

无人机自主飞行平台基于 Amazon EKS 来构建，所以在存储服务选择上，我们首先要考虑存储性能，以及它们与 EKS 服务的兼容性特点：

表格 1

根据各子平台的对存储的需求特点，同时综合考虑性能价格比。最终我们采用以下的存储方案组合：

• 数据平台和云测试平台：Amazon EBS + Amazon EFS

数据平台和云测试平台的任务基本都是各自独立的，所以在任务开始的时候，我们先把数据集从 S3 下载到任务 pod 挂载的 EBS PV 上，然后在 EBS 上进行数据处理。而对于部分需要共享中间结果的任务，我们把中间结果数据放到 EFS 上。当单个任务处理完成，把最终结果写会到 S3，Pod 和 PV 被回收；当最后一个有数据共享的任务执行完成后，把 EFS 上的中间结果数据也删除掉。通过这样的组合方式，充分利用每块 EBS 卷的性能；引入 EFS 解决了小量数据共享的需求。

• AI 训练平台和模拟仿真平台：Amazon FSx for Lustre

AI 训练和模拟仿真不但数据量大，而且对存储性能和共享要求也更高。还是以模型训练为例： 模型训练主要使用带 GPU 实例，它每小时的费用比配置同样 CPU/MEM 的普通非 GPU 实例可能要高 5～6 倍。而训练数据集从几百 G 到十几 TB 不等，如果用前面的方式，当训练任务运行起来后，才到 S3 上把训练数据拉下来，那么光这个时间可能就需要数小时。这样不但白白浪费了 GPU 实例的成本，同时也耽误了训练任务的时间。所以我们需要一种高性能，同时能提前从 S3 上自动导入/导出数据的共享文件存储服务，FSx for Lustre 正是为这类场景而设计。

图 1：无人机自主飞行平台存储架构

存储选择和优化要点

我们知道决定存储成本的其中一个重要因素是存储类型。同一种存储服务，不同的存储类型，其成本会有着明显差别，所以成本优化首先从选择合适的存储类型着手。

在 Amazon EBS 的所有 SSD 型的卷中，GP3 的性价比最高。经过我们的测试，它的性能完全可以满足数据平台和云测试平台任务的要求。在数据平台和云测试平台中，以 Karpenter 弹性生成的每个节点挂载 400GB 的 Amazon EBS 卷为例，GP3 每小时的存储成本就比 GP2 要便宜 20%，而且性能还要好 2.5 倍。

数据平台和云测试平台中，只有部分任务的小量中间结果数据需要进行共享，对性能要求并没有那么敏感，所以我们选择了 Amazon EFS 的突增模式。

对于 AI 训练平台和模拟仿真平台，Amazon FSx for Lustre 提供 2 种文件系统：临时性文件系统 Scratch、持久性文件系统 Persistent。Scratch 只提供单一数据副本，特别适合数据的短期处理；而 Persistent 提供数据双副本，适合长期处理的业务数据。在 AI 模型训练这里，数据集和训练出来的模型，最终都是存储在 S3 中，所以在训练过程中采用 Scratch 是一个非常合适的选择。

而作为整个平台数据底座的 Amazon S3，则提供多达 7 种存储类型。无人机自主飞行平台在 S3 存放的数据主要是飞行采集的 RAW 数据、数据预处理/标注后的数据以及各子平台处理后的结果数据……首先，这些数据需要提供低延迟的访问性能；同时所有这些数据的冷热很难直接区分，因为各子平台的任务都是按需触发运行的，我们无法预测到底哪个时间段的数据可能不会被频繁使用。但如果将所有数据一直存放在 S3 标准层，这明显是不经济的。在这样的情况下，Amazon S3 Intelligent-Tiering 是一个非常理想的选择，它监控访问模式并将未访问的对象自动移动到较低成本访问层，以帮助我们节约存储成本；还不影响性能，也没有无层级间数据转换成本，无数据数据检索费用；同时也大大降低了 S3 操作管理的复杂度。

除了存储自身的成本，还有另外一部分是在数据处理过程中带来的数据传输费用。数据传输费用，我们主要聊聊区域内数据传输费用的优化。在无人机自主飞行平台的区域内数据传输，主要包括 3 个部分：任务 Pod 从 ECR 拉取镜像、任务 Pod 从 S3 下载数据到 EBS 以及从 EBS 将任务结果数据存储到 S3、FSx for Lustre 和 EFS 的跨可用区数据共享。

对于前面 2 个部分，我们主要通过 S3 和 ECR 终端节点来避免产生数据传输费用；EFS 中存储的中间结果数据量通常在几个 G～100G 以内，所以 EFS 产生的数据传输费用基本都在 1～2 美金/月，几乎可以忽略。

FSx for Lustre 是一个可用区级别的服务，在这里主要用于 AI 模型训练和模拟仿真，每个任务的数据量在大多数情况下都是 TB 级别的，如果任务 Pods 跨可用区访问 FSx for Lustre，根据我们当初的测算，这部分每个月的数据传输费也是一笔大的开销。此外，所有的这些任务都不是长期运行的，以 AI 模型训练任务来说，短的可能只需要 6～8 小时，长的可能 2～3 天；同时由于优先使用 Spot 实例，也设置了中断处理机制。所以单可用区的可用性是可以满足需求的。同时，在后续，如果在可用性上有更高要求，也可以采用 FSx for Lustre 的持久性文件系统 Persistent，它提供数据双副本。为此，在 EKS 中当 Karpenter 触发新建节点用于这 2 个子平台的临时任务时，我们将这些新建节点创建在与 FSx for Lustre 所在的可用区里，从而避免了由于数据共享需要而导致的跨可用区的数据传输费用。它们的配置可参考图 2：

图 2：FSx for Lustre 的 SC 和 Karpenter Provisioner 配置

总结和收益

本篇，我们重点探讨了在无人机自主飞行平台中根据不同的业务特点，对存储服务的选型和优化过程。我们通过 S3 和 ECR 终端节点、FSx for Lustre 与任务 Pods 同区部署的方式消除掉了这 3 部分的区域内数据传输费；而使用 S3 Intelligent-Tiering，将 S3 的存储成本节省约 30%。

本篇作者