Categories
程式開發

5個小時,我們將800個微服務遷移到了雲端


9 月16 日晚上,我們將FINN 的生產環境從本地數據中心遷移到了谷歌云平台(GCP)。這意味著要遷移一個高流量的網站,該網站由一個複雜的分佈式系統支持,由800 多個應用程序、145 個數據庫和16TB 數據組成。我們在夜間有規劃的停機時間窗口,但這一窗口越小越好。我們是怎麼做的?請繼續閱讀本文!

關於將FINN.no 移出我們的數據中心,並遷移到雲平台中的內部討論始於多年前。此後,我們一直在嘗試各種雲技術和雲提供商。當我們在2016 年選擇Kubernetes 作為平台時,我們的指導思想就是在雲平台中運行FINN。

從很久前開始,我們在思想上已經準備好將系統遷移到雲端了,但一直沒有製定真正實現這一目標的策略或計劃。我們產品的某些部件早在1998 年就開始使用了,因此遷移它們是一項艱鉅的任務。但是,隨著數據中心愈加不堪重負、對更靈活解決方案的需求,以及我們去年成功將Sybase 從Solaris 遷移到Linux 的經驗,都給了我們很多動力來認真考慮這一計劃。

我們從2019 年1 月開始評估各家云提供商。候選名單包括AWS、Google Cloud、IBM Cloud 和Azure。我們參加了很多研討會、會議和電話會議,評估了自行管理服務以及將我們的服務託管於其他雲提供商等許多選項,最終我們決定採用“多雲”方案,而選擇GCP 作為我們大多數服務的首選項。該方案最終於2019 年8 月中旬被Schibsted 批准。

準備工作

遷移即將進行,我們必須制定一個計劃,將我們擁有的一切轉移到GCP,同時保持FINN 的正常運行。我們決定逐步遷移,使開發人員能夠隨著時間的推移遷移服務。但是,時間過得真快,我們意識到可用時間越來越少。基礎架構的惡化、現有數據中心計劃中的網絡翻新以及資源的匱乏,使我們很難看到逐步遷移的成功前景。全球疫情大流行也讓工作變得更困難了。我們被迫做出一些艱難的決定。

2020 年6 月,我們了解到,我們需要採取更直接的方法,並確定向GCP 迅速切換的日期。我們將目標日期定為9 月15 日,並獲得了FINN 管理小組批准,准許FINN.no 停機一晚。 7 月,雲平台遷移被設置為FINN 的第一要務;這意味著所有團隊必須完成他們負責的所有與雲平台遷移相關的工作,然後才能進行其他計劃的任務。是時候該去(遠程)工作了。

當我們決定放棄逐步遷移,決定快速切換時,擺在我們面前的艱鉅任務就開始出現了。我們必須準備一個平台,使我們能夠在一夜之間移動800 多個應用、145 個數據庫、超過16TB 的數據以及183 個虛擬機。 FINN 的基礎架構團隊已經為雲平台遷移做了很長時間的準備,但是這個決定使我們重新集中精力。現在,我們必須堅定地確定優先級,在必要時花時間深入探索技術,且始終保持目標清晰。在某些情況下,這意味著我們需要改變甚至放棄我們曾經投入大量時間的一些解決方案。

從夏天結束的那一刻起,我們就努力使這一計劃取得成功。我們必須對我們需要花時間要做的事情和必須等待的事情做出艱難的選擇。但是我們盡量不走捷徑,堅持我們的原則,例如基礎設施即代碼。隨著遷移日越來越近以及工作量的增加,我們的信心也隨之增加。

5個小時,我們將800個微服務遷移到了雲端 1

該圖顯示了隨著切換時間的臨近,我們用於維護FINN 基礎架構的一個存儲庫的更改頻率不斷增長

對FINN.no 的更改通常每天實行約350 次。在切換前的最後24 小時,我們決定建議使用“發行凍結”,這意味著那些既不能解決實時生產問題,又不能解決與雲平台遷移有關的更改應等到第二天。切換的前一天,更改頻率降低到一半左右,並且在雲平台切換開始前幾分鐘,最後一個產品部署到了我們的原有內部基礎架構中。

雲平台切換

9 月15 日23:00 時,基礎架構團隊聚在一起(在線),準備就緒並檢查切換前檢查清單。由於每個人都在不同的地理位置,因此我們依靠詳細的運行手冊和視頻會議進行協作。對FINN.no 的更改通常在不停機的情況下進行部署,站點停機是1 級嚴重事件。不過,這不是一個正常的星期二晚上。午夜時分,我們將用戶重定向到靜態後備頁面後關閉了​​FINN.no。半小時後,我們關閉了本地Kubernetes 集群中的所有應用程序。

5個小時,我們將800個微服務遷移到了雲端 2

轉換期間在FINN.no 上顯示的靜態後備頁面

然後我們準備遷移數據。 Kafka 是我們微服務架構的基礎之一。每天大約有20 億條消息(平均每秒30,000 條)通過我們的Kafka 集群,其穩定性對於FINN 的正常運轉至關重要。 Kafka 小組遷移了我們的Kafka 群集,該團隊暫時以“延伸集群”配置運行該集群,將我們的本地數據中心和雲平台作為單個集群。我們提前幾週仔細計劃和實施了延伸集群配置。 Kafka 中的主題在切換前一周已復製到GCP 的broker 中,而GCP 的broker 在轉換過程中成為主broker。

需要持久存儲的服務通常使用我們的25 個PostgreSQL 集群之一或我們的Sybase 集群。我們通過預先在GCP 中設置數據庫副本,並在切換過程中所有應用程序停止後切換主數據庫來遷移這些數據庫集群。在切換當天的01:35,Kafka 以及我們所有的PostgreSQL 和Sybase 數據庫都運行在了GCP 中。

移動持久數據後,我們觸發了所有應用程序到新的Google Container Engine(GKE)集群的部署。到02:30,所有800 個應用程序(超過1500 個Kubernetes 的pod)都已部署到GKE。至此,我們當晚只遇到了一些小的問題和延誤,並已經準備好進行內部測試。

在切換之夜前,我們在所有領域的遷移準備和測試計劃方面都做得非常出色,當午夜測試開始,看到綠燈亮起,我們的基礎架構團隊感到非常欣慰。對平台所有不同部分的自組織測試的效果甚至超出了我們的想像!

經過所有團隊的良好團隊合作,修復了一些應用部署、損壞的數據庫表和其他一些小問題之後,雲平台中的FINN 於04:43 啟用,沒有發生重大事故。

5個小時,我們將800個微服務遷移到了雲端 3

在FINN.no 在雲平台中於04:43 啟用後,通過某個負載均衡器的請求的速率增長曲線

我們為能夠成功進行雲平台切換而感到自豪!

沒有FINN Technology 的優秀人才,遷移不可能成功。我們在組織的各個部門都得到支持,當行動號召到來時,每個人都加入進來並做了應做的部分工作。在準備階段,開發團隊一直在努力處理防火牆、網絡路由和負載平衡器,發現我們新的GCP 基礎架構中的問題,並與基礎架構團隊合作解決這些問題。在切換之夜的前幾個星期,我們在工作時間還針對開發環境進行了轉換演習。這次“排演”使我們充滿信心,相信我們可以在指定的停機時間窗口內執行轉換,幫助我們發現和糾正工具方面的問題,並且對於完善生產切換的運行手冊非常有幫助。這兩件事都有助於將風險降低到可接受的水平。

由於我們的遷移工作有一個硬期限,因此許多系統必須採用直接遷移方式進行移動。當我們稍微適應云環境時,我們期待將基礎架構的這些部分也變得更加雲原生化。

原文鏈接

https://medium.com/finn-no/how-finn-no-moved-800-microservices-to-the-cloud-in-5-hours-601067997620