Categories
程式開發

大數據公司LiveRamp上雲記(五):如何使用雲原生技術重構本地系統


接下來呢?

在之前的遷移文章中,我們問過自己:

最後也最令人興奮的問題是,“接下來會發生什麼?”,“我們該如何重新設計從而充分利用GCP平台的優勢?”。

技術

雖然我們沒有將現有的基礎設施直接遷移到GCP上,最終做了不少改動,但我們在第一天還是使用了很多GCP的工具:

擴展:這很顯然,但是能夠在需要實例的時候添加它們而在不需要的時候關閉它們,這是一個能改變遊戲規則的能力。我們最大的批處理圖形構建程序在運行時需要大量資源,但其只佔一半的運行時間。在本地環境下,這意味著我們必須為峰值容量提供物理機器,而在GCP中,我們可以在不需要機器的時候自動關閉它們:

大數據公司LiveRamp上雲記(五):如何使用雲原生技術重構本地系統 1

Google Kubernetes Engine(GKE)+Google Container Registry(GCR):到目前為止,我們做的最大的重構就是消除了的本地Chef環境,轉而支持Kubernetes(通過GKE),並在GCR中存儲鏡像。雖然這是一項龐大的工程,但花費的時間卻是100%物有所值。

雲存儲(GCS):我們正在用GCS完全取代HDFS環境。採用對象存儲可以使我們更靈活地迭代計算基礎設施,而且不會有數據丟失的風險。

BigTable:我們已經用BigTable替換了內部的鍵值數據存儲。

CloudSQL:Liveramp非常依賴MySQL。除了使用數據庫的常規原因(數據規範、狀態協調)之外,我們內部還將數據庫用於隊列、統計倉庫等等。這項工作分成了幾十個數據庫,其中許多數據庫由應用程序團隊擁有。通過將輕量級數據庫轉移到CloudSQL中,應用程序團隊可以完全擁有MySQL實例,而不必成為數據庫管理員;團隊可以考慮數據庫的模式,而不必擔心數據的備份或複制。

BigQuery:儘管分析性查詢不是LiveRamp所做計算的主體,但這些查詢有一個重要的用途,即不需要通過工程師就可以將我們的日誌數據暴露給商業智能分析師。

FileStore:在本地,NFS是我們用來在虛擬機之間實現配置共享的粘合劑,也可以讓支持工程師在將數據保存到HDFS之前進行階段處理。 FileStore完全可以作為一個高性能NFS的替代品,並且不必由我們自己管理。

下一步如何?

短回答是:我們不知道,找到答案的時候我們會在這裡更新, : )

稍微長一點的回答是:我們不知道,但是我們非常肯定它會涉及到更多令人興奮的技術:

BigTable(第2次):我們使用BigTable來強化我們的像素服務器,但我們只是對可伸縮的實時查詢存儲做了一些淺嚐輒止的工作。還有一種可能是用一個真正的實時管道來補充(甚至替換)我們的批處理管道。

DataFlow:LiveRamp非常倚重Hadoop。我們構建了很多複雜的工具來幫助處理每天數百萬兆字節的數據,Hadoop支持所有這些工具。但是,我們不想用同一把錘子來處理所有問題;如果能不費力地用DataFlow來替換我們自己的ETL工作流,我們會這樣做的。

Cloud函數,CloudRun:LiveRamp運行了很多服務;其中大多數服務主要用來封裝不同團隊的數據庫,提供配置邏輯或封裝請求等。這些服務通常導致非常不穩定的負載,有時可能會處理數百個請求,有時一個也沒有:

大數據公司LiveRamp上雲記(五):如何使用雲原生技術重構本地系統 2

雖然Kubernetes自伸縮功能可以起到緩解作用,但云函數隨負載伸縮的原生能力將完全消除這個問題。

雲計算遷移通常是在技術權衡的背景下討論的。雲計算提供原生服務、更容易的區域複製、災難復制等(當然是有代價的)。

但人們往往忽略的是,雲遷移其實還是一個重新思考自己工程實踐的機會。雖然我相信LiveRamp在這次遷移中已經完成了一項令人驚訝的技術成就,但更讓我自豪的是,隨著對內部環境限制的擺脫,團隊也開始利用這個機會重新思考自己的責任。我們的工程團隊已經做了三個重要的改變,我將在下面提到。

不要在共享的基礎設施上進行構建

因為提供新的硬件需要幾個月的時間,在本地為新的應用程序團隊創建新的基礎設施是不切實際的;因此,我們在應用程序團隊之間共享基礎設施。我們最敏感的共享服務有:

  • Hadoop環境:YARN和HDFS被所有應用程序團隊共享。
  • 數據庫:一些團隊運行獨立的數據庫,但所有數據庫都由基礎設施團隊管理。
  • Kubernetes:跨團隊的應用程序將被部署到一個中央Kubernetes集群。
  • 虛擬機:虛擬機從中央資源池統一分配。

不幸的是,中央服務的便利性是以敏捷性為代價的。如果十幾個應用程序團隊使用相同的Hadoop環境,那麼最終就演變成無法升級基礎設施;每次更改都會破壞一些關鍵的東西。當不同的團隊以不同的方式使用相同的基礎設施時,即使簡單的性能調整也很難實現。

同樣,共享的基礎設施也非常容易受到單個應用程序或團隊的(通常是偶然的)濫用行為的影響。 Kubernetes可能會耗盡資源;NameNodes可能會被RPC調用壓垮。如果團隊的變更會影響不相關團隊編寫的應用程序,那麼團隊的變更迭代就會變得很不情願。

而在GCP上,我們只需要幾分鐘就可以為基礎設施提供一個新的輕量級副本,團隊不再需要自舉一個公共服務池。這在很大程度上提高了信心和迭代速度。

團隊負責自己的資源開支

當很多應用程序使用共享的服務是,這會很難準確地將成本劃分到單個團隊或應用程序。優化項目通常是由基礎設施驅動的;只有當基礎設施耗盡一組共享資源時,我們才會去主動回收這些資源。團隊通常不知道他們的應用程序耗費了太多的資源,直到基礎設施告訴他們這一點。

在GCP中,團隊在自己的項目中運行資源,所以劃分成本變得非常容易。應用程序團隊離客戶最近,他們現在也被授權去做成本權衡的選擇,如果花費2倍的資金但可以按2倍的速度交付數據,這就算物有所值,他們就可以去做。

基礎設施引導,團隊最終決定

資源和成本的共享把基礎設施團隊推到了技術仲裁者的尷尬位置上,因為基礎設施團隊最終將擁有所提供的任何基礎設施,我們不得不更頻繁地對實驗性技術說不。

在雲遷移的世界裡,我們重新定義了基礎設施團隊在工程團隊中的位置:

  • 基礎設施仍然處理安全和數據權限。
  • 核心基礎設施(例如,共享VPC網絡)仍然由基礎設施管理。
  • 在其他任何地方,基礎設施都可以通過構建工具和建議最佳實踐的方式來提供幫助;團隊可以自由使用他們認為最適合自己的工具,不論這些工具是內部的還是外部的。

沒有人(至少我們團隊中沒有人)喜歡成為一個中央計劃者;通過分解我們共享的基礎設施,我們可以回歸到基礎架構團隊的本質:構建工具和幫助其他工程師。

展望

這些都是很大的改變。寫一篇關於未來的文章是很容易的,但我們完全明白要達到這個目標需要很多年。但是,無論一年後最終使用哪種技術,我們相信我們仍在朝著正確的方向前進。

原文鏈接:

https://liveramp.com/engineering/migrating-a-big-data-environment-to-the-cloud-part-5/

相關閱讀:

大數據公司 LiveRamp 上雲記(一):為什麼選擇 GCP?

大數據公司 LiveRamp 上雲記(二):哪些功能可以直接遷移,哪些需要重新設計?

大數據公司 LiveRamp 上雲記(三):如何在吞吐量有限的情況下處理數據複製

大數據公司 LiveRamp 上雲記(四):如何在遷移時處理數百萬請求和 PB 級數據傳輸