摘要：本文简单介绍了Netflix公司利用其内部的spot市场节省了92％的视频编码成本。以下是译文。

Netflix利用其内部的spot市场节省了92％的视频编码成本。戴夫·哈恩在他《Netflix工程师生活中的一天》中讲述了这是如何做到的。 Netflix在2015年发表的两篇文章中谈到他们的spot市场：创建你自己的EC2 spot市场的部分和第二部分。

这个想法很简单：

• Netflix使用了三个AWS region，包括数十万个EC2实例，但很多实例在一天的不同时间段里并没有得到充分的利用。

• 视频编码占到Netflix计算需求的70％，运行在超过1000个不同的自动缩放组中的30多万个CPU上。

• 那么为什么不把那些未充分利用的保留实例集中起来创建Spot市场来进行视频的编码处理呢？

在回答这个问题之前，我们首先来定义一下什么是Spot市场：

Spot实例允许你使用未充分利用起来的EC2实例，从而显著降低Amazon EC2的使用成本。Spot实例的小时价格由Amazon EC2设置，并根据Spot实例的使用时间长短和需求进行调整。Spot实例在系统容量可用并且你请求的每小时高价格超过Spot价格才能运行。

AWS在任何时候都有很多未充分利用起来的实例，Netflix也是如此。要理解为什么建立内部Spot市场对Netflix的帮助如此之大，我们首先要了解他们是如何对视频进行编码的。

Netflix如何对视频进行编码

戴夫解释了视频编码的过程：

• Netflix从制作公司和工作室获取视频。Netflix首先对源文件进行验证、查找丢失的帧、数字防伪、颜色变化以及其他问题。如果在这过程中发现问题，则视频将被拒绝。

• 视频文件超级大，有几兆兆字节的大小。处理单个TB大小的视频文件是不合理的，因此，需要将视频分解成多个块，从而可以并行操作。

• 块通过媒体管道进行传递，在这过程中有很多编码工作要做。 Netflix支持2200个设备和多种不同的编解码器，因此，视频需要是指定的几种文件格式。

• 块编码完成后，需要再次进行验证，以确保没有引入新的问题。然后，块被组装成一个文件，并再次验证。

• 媒体管道中涉及超过70种不同的软件。

Netflix认为静态编码比动态编码能产生更高质量的视频观看体验，但同时也会产生很多的文件。

《怪奇物语（Stranger Things）》第二季以8K分辨率进行拍摄，有九集。源文件有百万兆大小。每一季需要19万CPU小时进行编码。这相当于2965个m4.16xlarge实例运行一个小时。静态编码过程会创建9570个不同的视频、音频和文本文件。

那么，你如何对视频进行编码呢？有两种方法。

容易想到的方法是设置一个只为媒体编码服务的静态实例场。这种方法的优点是你总能获取到所需的资源。

但是你想一下，编码是一个突发的重负载的工作，这意味着场在很多时候都无法得到充分的利用。

一旦你想到这一点，利用Spot市场的想法定会油然而生。

AWS已经有一个Spot市场了，为什么不使用它呢？为什么要从自己的保留实例中构建自己的Spot市场？

Netflix有着基准容量非常庞大的保留实例。他们每天从这个池中自动扩展和回收一万多个实例。当Netflix池自动缩小时，就出现了未使用的容量。未使用的容量是对金钱的浪费，而Spot市场则是充分利用起所有未使用容量的好方法。

所以，Netflix做了一件非常天才的事情，他们建立了自己的内部Spot市场来处理块的编码工作。工程工具团队构建了一个API，以分钟级实时显示未使用的容量。

使用内部Spot市场与静态编码场能节省的成本有多少呢？ 92％！

一切都跟经济有关

跟亚马逊一样，Netflix也创建了自己的内部Spot市场。云计算经济就是为了提高机器的利用率。AWS中的预留实例可以帮助节省大量的资金，从这些实例中尽可能地获取大价值是非常有意义的。CPU如果有一微秒不在工作就是在浪费金钱。

在过去，在AWS成为基础设施的吞噬者之前，我跟其他许多人一样，都在拼命思索AWS的创业想法。《构建超级可伸缩系统：Blade Runner满足环境云中的自主计算》一文中描述的内容正是当初我所追求的一些想法。

我乐衷于创建一个二级市场，以便让开发者们可以转售他们实例中未使用的容量。虚拟机的利用率仍然非常低。有很多未使用的CPU、网络和内存的实例。所以，这似乎是一个不错的主意。这是一个云中云。

它真正的优势是安全性。谁会在一台没有安全保证的机器上保存数据和运行代码呢？虽然我已经在FreeBSD上使用过Jails，但当初容器这个概念我还从来没有听说过。

我的想法跟lambda一样，这就是为什么在《Google App Engine的调价对Web架构的将来预示着什么》一文中我对GAE转向更高粒度的系统感到失望的原因：

我认为GAE会将实例映像这个概念完全抛弃，而将应用程序写入倒一个巨大的任务队列容器中。

这个设想或者说愿景的基础是GAE具创新性和深远影响力的发展和演变，即：任务队列。这是一个非常不错的功能，它可以将应用程序分解为异步流程。任务会被放到队列中，并在稍后的某个时间点执行。与GAE初使用的整体和同步模型不同，现在的应用程序可以是完全异步的，并能在任何一台机器上运行。

但问题是，任务队列仍然是基于映像的。具体的操作通过URL来指定，并且在运行时实例中终止。映像包含了应用程序执行的所有代码，它是一个整体。

当某个Web客户端的URL被调用时，它将在单个映像中执行代码。这些大型映像必须由GAE来管理，这也是为什么Google需要向你收取更多费用的原因。他们需要一定的资源对其进行管理，需要有一定的时间进行初始化，而且即使应用程序没有做任何事情，运行的时候也需要内存。

有人会问，为什么不能在一个任务队列工作项目中终止请求呢？那是因为异步编码模型存在的问题会导致这个单一的映像可能会被丢弃。是的，GAE仍然需要以某种奇异的方式来管理和分配这些代码库，这并不是一个简单的任务。这能解决资源粒度问题的匹配工作，不过他们反过来解决了另一个方向，即以映像作为分配单位，以实例作为执行单位。接下来我们将详细讨论颗粒度问题。

所以，随着这个超酷的任务队列框架和编程模型的出现，我认为他们已经准备好宣布单一映像将会消失，实例将会消失，并且你使用计费模型作为替代品的代价将会更高。但是，我错了，再一次错了。

这是一个量子力学方面的问题

程序运行在一个抽象的机器上，它使用的量化的资源与底层物理机器的是不同，这一切推动了这场剧变的发生。一台服务器上只能有一定数量的内存和CPU。即使程序处于空闲状态，只要它在运行，就会使用到内存，而Google就必须支付实例使用的机器资源。仅对程序使用的资源进行计费，而不是对用于托管程序所使用的所有资源进行计费，产生了这两种计费模式之间不可持续、无利可图的价格摩擦。

换句话说，程序被部署在拥有很大资源的虚拟机器上，但运行的时候只占用其中很小的一部分资源。更小的任务粒度使得任务能够在空闲时间运行，这就是我为什么认为任务队列模型的原因。

现在终于看到这些想法变成实现了，真是太好了！