摘要：本文簡單介紹了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首先對源文件進行驗證、查找丟失的幀、數字防偽、顏色變化以及其他問題。如果在這過程中發現問題，則視頻將被拒絕。
視頻文件超級大，有幾兆兆字節的大小。處理單個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的創業想法?！?/span>構建超級可伸縮系統：Blade Runner滿足環境云中的自主計算》一文中描述的內容正是當初我所追求的一些想法。
我樂衷于創建一個二級市場，以便讓開發者們可以轉售他們實例中未使用的容量。虛擬機的利用率仍然非常低。有很多未使用的CPU、網絡和內存的實例。所以，這似乎是一個不錯的主意。這是一個云中云。
它真正的優勢是安全性。誰會在一臺沒有安全保證的機器上保存數據和運行代碼呢？雖然我已經在FreeBSD上使用過Jails，但當初容器這個概念我還從來沒有聽說過。
我的想法跟lambda一樣，這就是為什么在《Google App Engine的調價對Web架構的將來預示著什么》一文中我對GAE轉向更高粒度的系統感到失望的原因：
我認為GAE會將實例映像這個概念完全拋棄，而將應用程序寫入倒一個巨大的任務隊列容器中。
這個設想或者說愿景的基礎是GAE具創新性和深遠影響力的發展和演變，即：任務隊列。這是一個非常不錯的功能，它可以將應用程序分解為異步流程。任務會被放到隊列中，并在稍后的某個時間點執行。與GAE初使用的整體和同步模型不同，現在的應用程序可以是完全異步的，并能在任何一臺機器上運行。
但問題是，任務隊列仍然是基于映像的。具體的操作通過URL來指定，并且在運行時實例中終止。映像包含了應用程序執行的所有代碼，它是一個整體。
當某個Web客戶端的URL被調用時，它將在單個映像中執行代碼。這些大型映像必須由GAE來管理，這也是為什么Google需要向你收取更多費用的原因。他們需要一定的資源對其進行管理，需要有一定的時間進行初始化，而且即使應用程序沒有做任何事情，運行的時候也需要內存。
有人會問，為什么不能在一個任務隊列工作項目中終止請求呢？那是因為異步編碼模型存在的問題會導致這個單一的映像可能會被丟棄。是的，GAE仍然需要以某種奇異的方式來管理和分配這些代碼庫，這并不是一個簡單的任務。這能解決資源粒度問題的匹配工作，不過他們反過來解決了另一個方向，即以映像作為分配單位，以實例作為執行單位。接下來我們將詳細討論顆粒度問題。
所以，隨著這個超酷的任務隊列框架和編程模型的出現，我認為他們已經準備好宣布單一映像將會消失，實例將會消失，并且你使用計費模型作為替代品的代價將會更高。但是，我錯了，再一次錯了。
程序運行在一個抽象的機器上，它使用的量化的資源與底層物理機器的是不同，這一切推動了這場劇變的發生。一臺服務器上只能有一定數量的內存和CPU。即使程序處于空閑狀態，只要它在運行，就會使用到內存，而Google就必須支付實例使用的機器資源。僅對程序使用的資源進行計費，而不是對用于托管程序所使用的所有資源進行計費，產生了這兩種計費模式之間不可持續、無利可圖的價格摩擦。
換句話說，程序被部署在擁有很大資源的虛擬機器上，但運行的時候只占用其中很小的一部分資源。更小的任務粒度使得任務能夠在空閑時間運行，這就是我為什么認為任務隊列模型的原因。
現在終于看到這些想法變成實現了，真是太好了！
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
