FuboTV的MongoDB、Docker與Kubernetes實踐一覽

來自： http://dockone.io/article/1013

經歷了媒體的一輪又一輪宣傳轟炸，如今幾乎每位從業者都會將容器與非關系數據庫作為2016年IT行業的“熱門市場技術”，而新一代市場領導者也在積極利用這些成果實現創新并借此擊潰各傳統競爭對手。總部位于紐約的fuboTV就是其中的典型代表。

為了能夠及時與業務發展保持同步并盡可能加快軟件發布計劃，fuboTV已經將其MongoDB數據庫遷移至由Kubernetes編排系統于谷歌Cloud Platform之上負責管理的Docker容器環境當中。

抱著對其項目的高度關注，我與fuboTV工程技術主管Dan Worth以及云運營首席顧問Brian McNamara進行了面對面交流，旨在深入探討與之相關的各項議題。

您能否首先向我們簡要介紹您的這家企業？

fuboTV旨在為客戶隨時隨地提供最出色的足球直播服務。我們提供為北美市場的各位訂閱客戶提供一項流媒體服務，其中包括賽事直播、娛樂頻道、紀錄片、新聞以及更多與世界各地足球聯賽的資訊。

MongoDB在fuboTV當中扮演著怎樣的角色？

MongoDB是負責支撐我們業務的核心數據庫。我們利用它管理自己的客戶數據; 它存儲著節目指南以及內容目錄元數據; 另外還承載著用于處理驗證、訂閱服務管理、賽事與頻道調度乃至用戶設備數據在內的一切相關服務API調用。

圖一：頂級足球賽事直播

您是否在業務起步階段就一直在使用MongoDB？

我們的CTO可以說是MongoDB的忠實擁躉，因此我們自公司建立之初就一直在使用這套數據庫方案。

MongoDB對開發與運營流程的簡化作用使得我們能夠將精力集中在構建功能身上，從而快速擴展客戶群體，而非被底層數據庫所拖累。

我們最初在Compose.io平臺上使用MongoDB，但如今則開始著手將自身管理集群遷移至谷歌Container Engine（作為谷歌Cloud Platform之組成部分）之上，而這套云引擎則以Kubernetes編排系統與Docker容器為基礎。

面向谷歌Container Engine遷移主要源自以下幾項因素的推動：

1. 
   我們已經將自身剩余堆棧遷移至Docker與Kubernetes，同時也希望我們的MongoDB數據庫能夠充分發揮由此帶來的各項優勢。
2. 
   我們跨越多個地理區域進行服務規模擴展，同時亦希望能夠立足于谷歌云實現部署靈活性，并保持未來面向其它公有云平臺的可移植能力。
3. 
   我們希望能夠對MongoDB的日常運營與管理工作保持控制能力，從而更好地支持我們快速演進的業務需求。

為什么選擇Docker與Kubernetes？

二者能夠為我們的服務帶來無與倫比的靈活性、執行效率與正常運行時間水平。縱觀以往的業務流程，我們發現其中存在大量資源浪費狀況。而利用由Kubernetes管理的容器系統，我們能夠將環境中的全部機制——包括開發、測試、質量保證以及生產流程——交付給單一物理主機集群。我們利用Kubernetes調度程序的優勢以精確控制資源配額，從而保證自身最大程度提升利用率并降低運營成本。

MongoDB能夠與Docker容器及Kubernetes實現無縫化集成，進而支持我們的DevOps工作流程。

我們運行有一套持續集成與交付流程，從而保證自身能夠開發、測試、發布并在必要時以最快速度輕松回滾至原有版本。

我們確保業務體系在應用程序部署與升級過程中不會出現任何停機時間。我們能夠在實例發生故障時自動進行容器重新調度，而Kubernetes復制控制器的存在確保系統中始終存在必要數量的實例處于正常運行狀態——這就讓持續可用性擁有了強大的容錯性。數據冗余機制則由這套副本集中的MongoDB副本負責實現。

MongoDB是如何被部署在谷歌Container Engine之上的？

我們在每個谷歌云區域內跨越多個Kubernetes pod進行MongoDB副本集配置。其中每個實例都配置有32個CPU、28 GB內存以及SSD存儲資源。

這些副本集由四種具備完整彈性的部分共同構成：其中三者專門用于處理運營流量，另一部分則被配置為隱藏副本集成員，專門用于對備份分卷進行快照保存。

圖二：fuboTV的Kubernetes平臺跨越多個谷歌Container Engine區域分布。

您是如何將MongoDB與Kubernetes加以結合的？

相較于其它常見應用場景，在Kubernetes之上運行MongoDB需要額外考慮以下幾項因素：

• 
  MongoDB數據庫節點具備狀態性特征。一旦某一容器發生故障并進行重新調度，其中的數據將出現無法接受的丟失狀況（我們可以利用副本集中的其它節點實現數據恢復，但這會拖慢整體彈性副本集的恢復速度）。為了解決這項難題，我們利用Kubernetes分卷并以抽象化方式將容器中ephemera1 MongoDB數據目錄映射至持久性網絡連接存儲資源，并借此保證故障容器內數據的完整性及重新調度。
• 
  副本集內的MongoDB數據庫節點必須有能力隨時實現彼此間通信。單一副本集內的全部節點都必須相互了解對方地址，但當某一容器進行重新調度，其很可能在Kubernetes Pod中重新啟動并被分配一個不同于原本的IP地址。在這種情況下，該MongoDB節點將無法重新加入對應副本集。我們采取的解決辦法是將一項Kubernetes服務同每個MongoDB節點相關聯——在這里，Kubernetes DNS服務負責在重新調度過程中為該服務提供一個固定不變的主機名稱。
• 
  一旦各個MongoDB節點全部處于運行狀態（每個節點立足于自己的容器當中），該副本集必須進行初始化并將各個節點添加進來。我們已經利用CircleCI實現了一套持續交付工作流，其與Kubernetes及Docker相結合以檢索必要配置，而后執行MongoDB初始化步驟。

您是如何對fuboTV服務進行規模擴展的？

我們流媒體服務的流量配置需要充分考慮“突發”因素這一條件。我們的站點往往在大型賽事開始前的十分鐘起應對達到平均水平百倍的峰值訪問請求。為了解決如此龐大的負載，我們將數據庫操作分布在全部副本集成員當中。我們的用戶遍布北美各地，為了為每位用戶提供理想的延遲效果，我們利用最近原則作為線路首選項，從而保證用戶能夠始終接入到與之地理位置最接近的副本當中。MongoDB的數據中心識別機制在確保服務質量方面發揮著巨大作用。

您目前使用的是MongoDB的哪個版本？

MongoDB 3.0以及WiredTiger存儲引擎給我們留下了深刻印象。其文檔層級的并發控制與壓縮能力幫助我們顯著提升性能與存儲效率，并切實符合我們的現有服務發展水平。舉例來說，我們得以在單一數據集中實現了高達二十分之一的數據壓縮效果。

我們于去年12月MongoDB 3.2完成生產環境調整后立即加以升級，從而確保自身始終享受由其帶來的各項創新成果。

您是如何量化MongoDB與Kubernetes對業務所產生之影響的？

最明顯的一項指標就是開發敏捷性與部署速度表現。我們能夠以遠高于以往的速度實現新服務啟動、用戶反饋意見收集、問題修復以及功能迭代等等。

您對于考慮使用MongoDB、Docker與Kubernetes構建下一個項目的朋友們有哪些建議？

MongoDB在彈性層面擁有大量理想的功能組合。要充分發揮這些優勢，大家需要確保自己擁有在不同故障情況下實現應用正常運行的能力。

Docker也是一套非常出色的解決方案，但大家需要首先開發出對應工作流、工具以及管理機制，并以此為指導利用其構建并運行應用程序。

Kubernetes目前仍是個相對年輕的項目，但其成熟速度極快。大家需要認真評估自己是否希望將整體平臺遷移至其中，或者選擇使用托管服務——我們選擇的就是后一種方法，即使用谷歌Container Engine。

感謝Brian與Dan拿出寶貴的時間與我們以及整體技術社區分享自己的實踐經驗。

原文鏈接：Leaf in the Wild: Leading Soccer Streaming Service fuboTV Scales its Business with MongoDB, Docker Containers and Kubernetes