# Viddler Architecture-每天嵌入 700 萬個和 1500 Req / Sec 高峰 > 原文： [http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html](http://highscalability.com/blog/2011/5/10/viddler-architecture-7-million-embeds-a-day-and-1500-reqsec.html)  Viddler 從事高質量視頻即服務業務，該業務面向想要支付固定成本，使用它完成并付諸實施的客戶。 與 Blip 和 Ooyala 相似，比 YouTube 更側重于業務。 他們為成千上萬的商業客戶提供服務，包括 FailBlog，Engadget 和 Gawker 等高流量網站。 Viddler 是一個很好的案例，因為它們是一家小型公司，試圖在擁擠的領域中提供具有挑戰性的服務。 我們正抓住他們，就像他們從一家以 YouTube 競爭者起步的初創公司過渡到一家規模稍大的公司（專注于為企業客戶付費）過渡一樣。 過渡是 Viddler 的關鍵詞：從免費的 YouTube 克隆過渡到高質量的付費服務。 從效果不佳的一些 Colo 站點過渡到新的更高質量的數據中心。 從典型的啟動架構過渡到具有冗余，高可用性和自動化功能的架構。 從大量實驗過渡到弄清楚他們想如何做并實現這一目標。 過渡到一種架構，在該架構中，功能使用不同的技術棧在地理上分散的團隊中分散，以明確定義角色。 換句話說，Viddler 就像其他所有即將成熟的初創公司一樣，值得一看。 Viddler 的系統架構師 Todd Troxell 非常友好地接受了我們的采訪，并分享了有關 Viddler 架構的詳細信息。 它是不同技術，組和流程的有趣組合，但似乎可以正常工作。 之所以行之有效，是因為所有活動部件的背后都是一個主意：讓客戶滿意并給予他們想要的東西，無論如何。 這并不總是很漂亮，但是確實可以取得結果。 網站： [Viddler.com](http://viddler.com) ## 統計資料 1. 每天大約有 700 萬個嵌入視圖。 2. 每天大約上傳 3000 個視頻。 3. 最高 1500 req / sec。 4. 高峰期約有 130 人按下播放按鈕。 5. 2 月份投放了 1PB 視頻 6. 80T 倉儲 7. 最近 30 天內花在視頻編碼上的 CPU 時間為 45,160 小時 8. 整天的使用量相對平穩，谷底和高峰之間只有?33％的差異，這表明它們在全球范圍內得到了大量使用。 [圖形](http://farm3.static.flickr.com/2704/5705121724_845db30833_o.png)。 ## 該平臺 ### 軟件 1. Debian Linux 2. Rails 2.x-儀表板，根頁面，競賽管理器，各種子功能 3. PHP-使用我們內部 API 的各種舊式子網站 4. Python / ffmpeg / mencoder / x264lib-視頻轉碼 5. Java 1.6 / Spring / Hibernate / ehcache- API 和核心后端 6. MySQL 5.0-主數據庫 7. Munin，Nagios，接站-監控 8. Python，Perl 和 ruby-許多*許多*監視器，腳本 9. Erlang - ftp.viddler.com 10. Apache 2 / mod_jk-后端 Java 應用程序的核心頭端 11. Apache / mod_dav-視頻存儲 12. Amazon S3-視頻存儲 13. Amazon EC2-上傳和編碼 14. KVM-臨時環境的虛擬化 15. Hadoop HDFS-分布式視頻源存儲 16. Nginx / Keepalived-所有網絡流量的負載均衡器 17. Wowza-RTMP 視頻錄制服務器 18. Mediainfo-報告視頻元數據 19. Yamdi-Flash 視頻的元數據注入器 20. 人偶-配置管理 21. Git / Github https://github.com/viddler/ 22. Logcheck-日志掃描 23. 重復性-備份 24. Trac-錯誤跟蹤 25. Monit-進程狀態監視/重啟 26. iptables-用于防火墻-無需硬件防火墻-還可處理內部網絡的 NAT。 27. maatkit，mtop，xtrabackup-數據庫管理和備份 28. [預引導執行環境](http://en.wikipedia.org/wiki/Preboot_Execution_Environment)-計算機的網絡引導。 29. 考慮將 OpenStack 的 [Swift](http://swift.openstack.org/) 作為替代文件存儲。 30. [FFmpeg](http://www.ffmpeg.org/) -完整的跨平臺解決方案，用于記錄，轉換和流傳輸音頻和視頻。 31. 阿帕奇雄貓 32. [MEncoder](http://en.wikipedia.org/wiki/MEncoder) -一個免費的命令行視頻解碼，編碼和過濾工具。 33. [EdgeCast](http://www.edgecast.com/) -CDN ### 硬件 1. 他們的 colo 中總共有 20 多個節點： 1. 2 個 Nginx 負載平衡器。 2. 2 個 Apache 服務器。 3. 8 個 Java 服務器運行該 API。 4. 2 個 PHP / Rails 服務器運行在前端。 5. 3 臺 HDFS 服務器 6. 1 監控服務器。 7. 1 個本地編碼服務器。 8. 2 個存儲服務器。 9. 2 個 MySQL 數據庫服務器以主從配置運行，計劃遷移到 6 個服務器。 10. 1 個登臺服務器。 2. Amazon 服務器用于視頻編碼。 ## 產品 注冊一個 Viddler 帳戶，他們會將您的視頻轉換為所需的任何格式，并將其顯示在任何設備上。 它們提供了嵌入代碼，儀表板和分析。 他們的目標是在一個簡單的界面后面解決視頻問題，使人們可以購買該服務而忘了它，它可以正常工作并完成您需要做的一切。 作為內容提供商，您可以出售視圖并將廣告添加到內容中。 他們將所有廣告網絡作為一種元界面引入 Viddler，以執行不同的廣告平臺。 ## 架構 [](http://farm3.static.flickr.com/2375/5704553989_0e42783c8f_o.png) 1. 當前時代 1. 他們目前的系統運行在美國西部某個地方的可樂中的裸機上。 他們正在搬到紐約的 Internap。 2. 1 gbps 鏈接將它們連接到 Internet。 CDN 提供視頻，并將視頻直接加載到 Amazon 中進行處理，因此對于他們的主要站點，他們不需要的網絡就更多。 3. 該系統由 2 個 Nginix 負載平衡器所控制，一個是主動的，另一個是使用 keepalived 的被動的。 選擇 Nginix 是因為它是基于 Linux 的開放源代碼，并且可以正常工作。 4. EdgeCast 用作分發內容的 CDN。 客戶將視頻直接上傳到 Amazon，然后將視頻處理并上傳到 CDN。 5. Nginx 可以故障轉移到兩個 Apache 服務器。 Apache 服務器可以故障轉移到運行 Tomcat 的后端服務器之一。 6. 他們的部分架構在 Amazon 中運行：存儲以及它們的上載和編碼服務。 7. 在 Cassandra 中進行了實驗，以存儲儀表板位置。 非常可靠，但將來可能會遷移到 MySQL。 8. Linode 上的兩個圖像縮放節點，用于為視頻創建任意縮略圖。 將來將移至紐約。 2. Internap 的很快時代 1. 該網站最初的想法是免費的視頻網站 YouTube，但更好。 然后，他們轉向提供更高質量的服務，這表明需要更好，更可靠的基礎架構。 2. 他們正在遷移到 Internap，因此尚未解決所有問題。 他們先前的數據中心中的一些問題促使此舉： 1. 網絡問題，某些 [BGP](http://en.wikipedia.org/wiki/Border_Gateway_Protocol) （邊界網關協議）提供程序將停止工作，不會自動進行對等，并且最終將死站點一個小時，并且必須真正推動手動建立數據中心 刪除對等體。 2. 他們被轉租給了一家提供商，后者將他們踢出局，這意味著他們不得不在很少的交貨時間內移動兩個機架的服務器。 3. Internap 以其良好的網絡而聞名，它是一種更好的工具，并且更可靠。 3. 一個主要目標是在其體系結構中具有**完全冗余**。 將 RTMP 服務器，專用錯誤記錄系統的數量加倍，將監視服務器的數量加倍，將 PHP 和 Rails 服務器分開，添加專用圖像縮放服務器，并將編碼服務器的數量加倍。 4. 另一個主要目標是**完全自動化**。 他們將通過網絡對計算機進行啟動，以獲取操作系統，并從 CVS 配置軟件包。 目前，他們的系統不可復制，他們想對此進行更改。 5. 試用 HDFS 作為視頻的文件存儲。 他們將其視頻的 10％（約 20TB）存儲在 3 個 HDFS 節點上，而且從未停機。 6. 當前的目標是使一切移交，整個系統要自動構建，并且在版本控制中，確保雇用了操作人員并制定了時間表。 7. 觀察到他們與亞馬遜的業務相似，因為在視頻世界中自己完成所有工作要便宜得多，但隨后您必須自己完成所有事情。 8. 沒有計劃使用服務體系結構。 它們具有內部 API 和外部 API。 兩者都用于創建站點。 與轉換為服務方法相比，要實現更高的獎勵功能。 3. 自動化將改變一切。 1. 便攜式 VM 將允許他們重現構建環境和實時環境。 目前這些是不可復制的。 每個人都使用不同版本的軟件包在自己的操作系統上進行開發。 2. 將允許他們在體系結構上進行迭代。 只需下載要運行的新 VM，即可嘗試新的存儲等。 3. 簡化向 OpenStack 的過渡。 同時考慮 VMware。 4. 當您上載到 Viddler 時，端點位于運行 Tomcat 的節點上的 Amazon EC2 上。 1. 該文件在本地緩存并發送到 S3。 2. 該文件從 S3 下拉以進行編碼。 3. 編碼過程在稱為 Viddler Core 的模塊中擁有自己的隊列。 4. 他們將在 colo 站點中運行的代碼與在 Amazon 中運行的代碼分開。 在 Amazon 中運行的代碼不會保持狀態。 生成的節點可能會死亡，因為所有狀態都保留在 S3 或 Viddler Core 中。 5. Python 編碼守護程序使工作脫離隊列： 1. 運行 FFmpeg，MEncoder 和其他編碼器。 2. 關于檢查 iPhone 視頻是否需要在編碼和其他測試之前進行旋轉，有很多時髦的東西。 3. 每個編碼節點都在 Amazon 8 核心實例上運行。 一次運行四種編碼。 他們還沒有嘗試優化它。 4. 作業按優先級順序運行。 有人要立即查看的實時上傳內容將在批量處理（例如說在其編碼中添加 iPhone 支持）之前得到處理。 5. Python 守護程序是運行時間很長的守護程序，它們沒有看到任何有關內存碎片的問題或其他問題。 5. 探索實時轉碼。 1. 在實時編碼中，節點實例像多部分表單一樣被饋送，通過 FFmpeg 進行流傳輸，然后再次進行流傳輸。 這可能是其 CDN 的一部分。 2. 這種體系結構的最大優點是無需等待。 客戶上傳視頻后，該視頻即會直播。 3. 這意味著僅需要存儲文件的一種視頻格式。 它可以按需轉碼到 CDN。 這樣可以為客戶節省大量的存儲成本。 6. 儲存費用： 1. CDN 和存儲是他們最大的成本。 存儲大約占其成本的 30％。 2. 希望他們的視頻在所有內容上播放的人的平均情況是四種格式。 HTTP 流將是另一種格式。 因此，存儲成本是客戶的主要支出。 7. 團隊設置： 1. 本地程序員在 PHP / Rails 中進行前端操作。 他們正在嘗試將所有前端移至該堆棧，盡管其中一些當前在 Java 中。 2. 核心 Tomcat / Java / Spring / Hibernate 由波蘭的一個團隊編寫。 Java 團隊的目標是實現 API 和后端邏輯。 3. 為 PHP / Rails 團隊計劃有一個單獨的數據庫，因為它們的移動速度比 Java 團隊快得多，并且他們希望盡可能地使團隊脫鉤，以使其彼此不依賴。 8. 進行可靠性調查，發現大多數故障是由于： 1. 網絡連接問題。 他們正在遷移到新的數據中心來解決此問題。 2. 數據庫過載。 要解決此問題： 1. 該數據庫包含約 100 個表。 用戶表大約有 100 個參數，其中包括諸如編碼首選項之類的信息。 從在 Word Perfect 上托管站點以來，該架構仍然具有舊結構。 2. 三倍的數據庫容量。 3. 使用速度更快且具有更多內存的服務器。 4. 使用雙主設備設置和 4 個讀取從設備。 5. 兩個讀取從站將具有較低的交互式通信查詢超時。 6. 兩個從屬將專用于報告，并且查詢超時時間較長。 慢速報告查詢不會使這種方法使網站癱瘓。 他們的熱門查詢正在處理具有 1000 萬行的表，因此計算熱門視頻所需的時間比以前要長得多，因為它開始創建臨時表。 可能導致系統停機 5 秒鐘。 9. 他們正在研究在自己的 colos 中使用 Squid 運行自己的 CDN。 1. 也許使用西海岸和東海岸的科魯斯在地理上分布同伴。 2. 對于他們的客戶，他們預計他們在美國需要 4 個站點，在歐洲需要 1 個站點。 3. EdgeCast 為他們提供了很多優惠，并為他們提供了有用的功能，例如每個 CNAME 的統計數據，但以盈利為基礎，構建自己的 CDN 值得開發。 CDN 成本是其成本結構的重要組成部分，隨著時間的流逝，值得一試。 10. **未來的**：長期目標是看退出 Amazon，在本地運行存儲，運行 OpenStack 并運行自己的 CDN 可以節省多少錢。 這將節省 80％的與人無關的運營支出。 根據他們自己的計算，他們可以做到比亞馬遜便宜。 ## 得到教訓 1. **混搭**。 他們正在使用來自不同提供商的節點的組合。 CDN 處理內容。 Amazon 用于無狀態操作，例如編碼和存儲。 colo 中的節點用于其他所有內容。 在幾個不同的位置使用功能可能會有些混亂，但是除非有令人信服的業務原因或易用性更改的原因，否則它們會堅持可行的方法。 將所有東西轉移到亞馬遜也許是有道理的，但是這也會使他們脫離他們的優先事項，這會帶來風險，并且會花費更多。 2. **注意表增長**。 一旦站點變大，過去需要花費相當長的時間的查詢便會突然使其崩潰。 使用報告實例可以從交互式流量中分擔報告流量。 而且不要寫令人討厭的查詢。 3. **查看成本**。 平衡成本是他們決策過程的重要組成部分。 他們更喜歡通過新功能實現增長，而不是整合現有功能。 這是一項艱難的平衡行為，但是有意識地將其作為一項戰略要務可以幫助每個人都知道自己的發展方向。 從長遠來看，他們正在考慮如何在利用自己的 colo 較低成本結構的同時獲得云運營模型的好處。 4. **實驗**。 Viddler 喜歡實驗。 他們將嘗試不同的技術以查看有效的方法，然后在生產中實際使用它們。 這使他們有機會了解新技術是否可以幫助他們降低成本并提供新的客戶功能。 5. **按技術堆棧細分團隊，并發布靈活性**。 擁有分散的團隊可能是一個問題。 在不同的技術堆棧和根本不同的發布周期上部署分布式團隊是一個大問題。 擁有具有強大依賴性和跨職能職責的分布式團隊是一個巨大的問題。 如果您必須處于這種情況下，那么遷移到組之間具有較少依賴關系的模型是一個很好的折衷方案。 6. **從中斷中學習**。 對您的網站為何崩潰進行調查，并查看可以解決的主要問題。 似乎很明顯，但是還不夠。 7. **將免費用戶用作豚鼠**。 免費用戶對 SLA 的期望較低，因此他們是新基礎設施實驗的候選人。 擁有免費套餐對于此目的非常有用，可以在不造成重大損害的情況下試用新功能。 8. **為頂級托管**支付更多費用。 他們遇到的最大問題是選擇好的數據中心。 他們的第一個和第二個數據中心有問題。 作為一家蓬勃發展的創業公司，他們尋找可以找到的最便宜但質量最高的數據中心。 事實證明，數據中心質量很難判斷。 他們選擇了一家名牌設施，并獲得了高昂的價格。 這工作了好幾個月，然后開始出現問題。 停電，網絡中斷，他們最終被迫轉移到另一家提供商，因為與他們在一起的一家提供商退出了該設施。 如今，任何時間都無法宕機是不可接受的，對于這樣一個小組，冗余站點將是很多努力。 從長遠來看，為更高質量的數據中心支付更多費用將降低成本。 9. **最終重要的是用戶看到的內容，而不是體系結構**。 迭代并著重于客戶體驗之上。 客戶服務的價值甚至超過理智或可維護的體系結構。 只構建所需的內容。 如果不運行超級草率的業務，他們就無法啟動這家維持 100％員工所有權的公司。 他們現在采用的是在草率階段學到的知識，并在頂級設施中構建非常靈活的多站點架構。 他們的系統并不是最有效或最漂亮的系統，他們采取的方式是客戶需要某種東西，因此他們構建了它。 他們追求客戶的需求。 他們選擇硬件和構建軟件（重點是完成工作）的方式就是建立公司的基礎。 10. **自動化**。 盡管所有試驗和解決客戶問題的直接方法都很好，但是您仍然需要一個自動化的環境，以便可以復制構建，測試軟件并提供一致且穩定的開發環境。 從一開始就自動化。 我真的很感謝 Todd Troxell 花時間參加這次采訪。 記住孩子們，如果您正在尋找工作，Viddler 也在為您尋找[。](http://www.indeed.com/q-Viddler-jobs.html) ## 相關文章 1. [我們可以處理您的交通！](http://blog.viddler.com/cdevroe/traffic/) ，作者 Colin Devroe 很高興閱讀... 我很想了解您不轉用云服務的原因，因為從今天起您需要管理和開發許多不同的技術... 大量的金錢和精力？