Categories
程式開發

從雲到數據中心,Dropbox 五年反向遷移的經驗總結


如今,將數據遷移上雲似乎成為了企業轉型的主流,但在企業上雲的潮流中,有一位逆行者,Dropbox 從 2015 年就開始將數據從雲端遷移到內部數據中心。截止到目前,Dropbox 反向遷移已有 5 年時間,實際效果到底如何呢?

Dropbox 為什麼要反向遷移呢?

故事可能要從2015 年AWS re:Invent 大會講起,當時AWS 首席執行官Andy Jassy 在主題演講中表示:“上雲之後,企業中最為稀缺的軟件工程師就可以從繁重的基礎設施運營工作中解放出來,真正幫助企業實現業務的差異化優勢。”

當 Andy Jassy 在會議上大談雲計算的好處時,曾是 AWS 明星用戶的 Dropbox 在早些時候卻選擇離開AWS,離開雲,朝著另一個方向發展。 2015 年 2 月至 10 月,Dropbox 成功將 90% 的用戶數據從雲端遷移至內部數據中心,這就是 Magic Pocket 項目。

為什麼 Dropbox 要反向遷移呢?一個比較直觀的原因就是成本,Dropbox 的工程副總裁 Aditya Agarwal 曾表示,“雲計算公司也是要賺錢的,規模大了以後,自建反而可以節省大量資金。”

其次,雲計算公司不足以支撐 Dropbox 的業務規模和需求。 2016 年,Dropbox 公司基礎設施副總裁Akhil Gupta 在博客中寫道:“我們一直很清楚,建立自身業務所需要的基礎設施只能由我們自己親手構建。因為開源社區中的任何成果都不足以可靠支撐我們的龐大業務規模與具體需求。事實上,全球範圍內很少有哪家企業擁有像我們這樣嚴苛的存儲需求。”

第三,性能問題。 Dropbox 認為自身產品的核心競爭力是性能,如果在內部數據中可以從端到端自定義整個技術棧,在特定的用例下提升性能。另外,Dropbox 的塊存儲與其它公司不同,因此可以根據產品規模和特定的用例來使用硬件和軟件,提升單位經濟效益。

從 Dropbox 反向遷移案例中,我們能獲得什麼

Dropbox 剛開始進行反向遷移時,大家都認為是“偶發事件”。五年過去了,其它企業和組織也意識到了公有云存在的局限,反向遷移有其存在的合理性。在這樣的背景下,Dropbox 的 Magic Pocket 項目自然成為了一個值得研究的案例。

從 Dropbox 反向遷移案例中,我們可以獲得什麼樣的經驗呢?

以更小的時間窗口來規劃

Dropbox 公司數據中心物理基礎設施負責人Latane Garetson 在接受采訪時表示,“Dropbox 公司製定了一項計劃,我們關注自身容量現狀,並藉此確定容量的之後增長預期。”根據慣例,他帶領的團隊為數據中心建立起規劃模型。

Garetson 帶領的團隊為數據中心建立規劃模型,Dropbox 採取了一種相當小眾的容量規劃方法。 Garetson 團隊以短期計劃為基礎,將遷移週期劃分為 6 個月甚至是 3 個月,並把時間窗口控制在這樣的水平,以細粒度方式專註解決具體問題。

Garetson 自己也認為這是一種“離經叛道”的處理方式。以更小的時間窗口做規劃,並不意味著Dropbox 放棄進行年度增長預測,只是在年度增長預測中,其與軟件團隊的溝通與預期交付週期總會出現多次變化。因此,Dropbox的做法是,在整個遷移過程中,基礎設施團隊與內部軟件團隊緊密合作,首先確定今年的運營期望是什麼,然後據此進行容量模型預測,按照季度、月度、甚至是星期來對預測結果做持續更新。

軟件先行,硬件再跟上

大多數 IT 部門部署工作的起點是先獲取或者自主構建硬件,然後對硬件進行劃分和部署,並將其整合到服務集群中,與業務軟件融合。而 Dropbox 的做法正好相反。

Dropbox 是軟件團隊先行,軟件團隊根據業務活動先做出容量預測,然後為數據中心設計出服務器模板,團隊中的開發者按照“圖紙”進行工作,預先完成服務配置與服務器擴展規劃。

打個比方,可能比較類似於麥當勞的得來速餐廳,軟件團隊在窗口處下達訂單,將上述配置結果按順序交付給硬件團隊,後者根據預期容量需求完成生產部署。由於軟件團隊方面已經制定了配置計劃,因此新增服務器擁有自配置能力,不再需要硬件工程師分擔額外的配置壓力。

Garetson 認為整個遷移過程中最重要的因素是構建時間。 2015 年,Dropbox 把構建週期從六個月縮短為三個月。而製定的年度規劃方案中,也會設置時間節點,如果預測結果發生變化,那麼就可以根據節點對規劃作出調整,從而將實際的構建週期控制在三個月。

構建週期的縮短,說明 Dropbox 對項目的控制力較強。一旦某項構建計劃因意外原因而推遲,Dropbox 可以隨時將其取消,並在不中斷正常業務的同時啟動新計劃。從微服務協調到分佈式軟件組件調度(當組件未響應時及時切換),Dropbox 認為只要規劃本身關注總體需求(而非一時一地的滯後問題),公司就能夠更靈活地實現容量構建目標。

容量變化

數據中心的容量變化也是需要時刻關心和密切關注的,Dropbox 技術團隊能夠在當前窗口內的任意給定時間內,根據新容量的交付規劃對現有庫存進行建模。通過這種方法,Dropbox 可以將整體容量目標拆分成多個可行的小項目。

相比於大多數存儲用途的數據中心,過去五年中,Dropbox 基礎設施中的機架密度始終保持增長。密度的提升,意味著總機架佔地空間降低的同時,客戶可用的存儲容量卻一直在快速上漲。 Garetson 表示:“相當於我們擁有了更多的物理空間。隨著密度的增加,以往需要 100 台機櫃才能滿足的需求,如今只要 30 台就可以解決。”

對於雲存儲廠商來說,動態增加容量建模的方法似乎正是最理想的規劃方法。到目前為止,大多數企業的數據中心都會根據核心服務與應用程序的空間與容量需求進行設計。 Dropbox 則反其道而行之,以存儲介質的增長作為前提,以此推斷能夠承載多少核心服務,最終將規劃週期控制在 6 個月以內。如果其它類似場景的企業,能夠和 Dropbox 一樣建立一套規劃模型,那麼就可以將服務運營體系保持在內部數據中心,而不是只有上雲一個選擇。

參考文章:

https://www.datacenterknowledge.com/manage/dropbox-s-reverse-migration-cloud-own-data-centers-five-years