選擇無伺服器：Babbel 的遷移故事

亞馬遜雲開發者發表於2023-05-06
伺服器

Babbel 是什麼？

Babbel 是一個完整的語言學習產品生態系統，囊括了世界上最暢銷的語言學習應用程式。我們已售出超過 1000 萬份訂閱和超過 60,000 門涵蓋 14 種語言的課程，創造了全球第一語言學習目的地。自 2007 年推出產品的第一天起，我們就一直在 Amazon Web Services（ Amazon）上執行我們的平臺，並且經常是 AWS 新服務產品的早期採用者。由於我們的 Babbel 學習生態系統是純數字化的，因此它嚴重依賴於底層技術，這些技術不僅需要可靠穩定，而且需要能夠在任何時間點都具有可擴充套件性。這會帶來挑戰和機遇，尤其是隨著產品供應的增加和服務格局的變化。

Babbel 一直在不斷擴大我們的學員基礎，從 2007 年到 2020 年，我們的訪問量隨之增加。2020 年，Babbel 的學員群體大幅增長，來自美國和我們主要歐洲市場的流量增長了兩到三倍。隨著疫情導致全球出現各種不同的法規政策，許多人選擇學習一門新語言或提高他們的語言技能。這使傳入流量出現更多峰值，從未有過如此規模。在此期間，我們沒有擔心我們的基礎設施是否會受到使用者需求不斷變化所帶來的挑戰。

但是，在 2020 年之前，我們在 Babbel 構建的用於託管 Babbel 服務的平臺並未利用所有 Amazon 無伺服器服務。它依賴於在 Amazon OpsWorks 上執行的舊堆疊，這無法再滿足需求。在本文中，我們描述了促使 Babbel 考慮做出改變的原因、我們考慮的選項以及我們最終如何將生產工作負載遷移到 Amazon Fargate 上的 Amazon ECS 和 Amazon Lambda。

亞馬遜雲科技開發者社群為開發者們提供全球的開發技術資源。這裡有技術文件、開發案例、技術專欄、培訓影片、活動與競賽等。幫助中國開發者對接世界最前沿技術，觀點，和專案，並將中國優秀開發者或技術推薦給全球雲社群。如果你還沒有關注/收藏，看到這裡請一定不要匆匆劃過，點這裡讓它成為你的技術寶庫！

為什麼要改變我們的架構？

在一個不斷增長和動態變化的環境中，我們有動力去改變和改進事物。我們努力尋找改進機會，以便為我們的學員提供更好的學習體驗。可以想象，優先考慮技術層面並不一定會輕鬆實現學習體驗的改進，但我們會將一些支柱作為路標：

  • 加快開發速度並縮短髮布時間
  • 減少維護工作
  • 擁有並維護最新的環境
  • 縮短功能交付時間

在開始該專案之前，我們執行的是舊版本的 OpsWorks，這要求我們使用過時的 Chef 版本來管理 OpsWorks EC2 例項的配置。這些例項基於較舊的例項型別，並使用其生命週期即將結束的 Ubuntu 版本，因此絕對需要採取行動。將 Chef Cookbook 升級到新 Chef 版本、升級 Ubuntu 版本以及升級舊的 OpsWorks EC2 例項將花費大量時間。此外，我們的部署、回滾和升級佔用了開發人員大量的維護工作時間，而我們希望減少這些時間。在流量快速激增的情況下，我們的擴縮時間比我們預期的要長，而且自動擴縮不可靠。某些情況下，將額外的 EC2 例項新增到 OpsWorks 叢集需要長達 25 分鐘。對於負載均衡，我們只能使用 Classic ELB，它不具備我們想要使用的全部功能，例如透過 Cognito 進行身份驗證及路由。這些功能在應用程式負載均衡器（ALB）中可用，但 OpsWorks 當時不支援 ALB。鑑於這些情況，我們得出結論，理想的解決方案應解決這些問題，這意味著我們必須放棄 OpsWorks EC2 設定。

考慮遷移選項

在分析潛在的技術解決方案之前，我們從功能角度討論了最適合我們的解決方案。我們一致認為，理想情況下，解決方案應該

  • 與我們現有的 Amazon 架構以及 Terraform 投資和結構完美整合
  • 透過專門的服務和支援團隊積極開發並保持最新狀態
  • 騰出運營和維護時間，使我們專注於能為學員或 Babbel 工程團隊帶來更多價值的事情 我們很清楚，正確的解決方案是實現無伺服器。我們接著研究了可用的解決方案，以擺脫 OpsWorks 並取代整個計算和託管層。我們考慮的選擇是：
  • Amazon Lambda
  • Amazon Elastic Container Service（Amazon ECS）
  • Amazon Elastic Kubernetes Service（Amazon EKS） 關於這些選項，我們得出了以下結論：

Amazon Lambda

理想情況下，我們將在 Lambda 上執行幾乎所有內容。預設情況下，擴縮是自動進行的，無需配置，無需維護例項，無需在作業系統層自己進行作業系統和安全更新，並且部署/回滾是即時的。對於某些服務，這是可能的，我們決定為它們使用 Lambda。但是，我們發現 Lambda 並非適合所有服務的解決方案。我們有一些需要 Docker 的多用途服務，在 2020 年初進行評估時，Lambda 尚不支援容器映像格式。

Amazon ECS

由於 Lambda 不適合此類服務，因此我們必須決定在哪個平臺上執行我們的（Docker）容器。我們評估了 Amazon EKS 和 Amazon ECS，有以下四個選項可供選擇：

  • EC2 上的 ECS
  • Fargate 上的 ECS
  • EC2 上的 EKS
  • Fargate 上的 EKS

由於使用 Fargate 上的 ECS 和 EC2 上的 ECS 非常相似，與 Kubernetes 和 EKS（在 EC2 或 Fargate 上）相比，它們對於整個生態系統而言，屬於同一種替代解決方案，因此我們權衡了使用這兩種技術堆疊的利弊。2019 年，我們開始在 Fargate 上執行 ECS，最初缺少我們當時需要的一些功能（例如容器的成本分配標籤）。我們的 AWS 客戶經理幫助我們處理了功能請求，這些功能隨後得以實施。這些功能釋出後，我們就順利地將所有新的 Docker 化的服務遷移到 Fargate 上的 ECS 了。對於我們的架構而言，在 EC2 和 Fargate 之間，Fargate 是更好的選擇，因為它消除了底層 EC2 機器的維護工作。該技術堆疊還很容易與其餘的 AWS 服務和 Terraform 程式碼庫整合，在這方面我們已經有管理經驗。

Amazon EKS

在權衡執行 EKS 的利弊時，我們認為這不是我們的用例和基礎設施設定所必需的。我們的主要目標是建立一個平臺，以最少的工作量擴充套件我們的 Docker 容器，同時對環境的其餘部分和 Amazon 服務整合進行最少的更改。此外，我們希望確保儘可能減少運維工作量，因為這不會給我們的學員帶來任何價值。使用 Kubernetes，我們認為學習難度更大，需要對現有環境進行更多更改，並需要更多的運營和維護工作。我們認為，我們可以使用更加以 Amazon 為中心的基礎設施即程式碼，更好地分離開發和基礎設施，我們正在透過 Terraform 管理這種基礎設施即程式碼（例如，使用 Amazon IAM）。簡而言之，我們希望改變我們的計算/託管環境，而不必對我們的系統和服務，以及我們執行部署、管理網路和安全組的方式等進行更大的調整。

2019/2020 年初，EKS 仍然是一項較新的服務。當時，我們決定不採用 EKS（或 Kubernetes）是擔憂不能很好地支援在 Amazon 上執行的 Kubernetes 功能。雖然 EKS 使用上游 Kubernetes 程式碼（不加修改），但我們擔心 Kubernetes 最新版本與 EKS 可用版本之間存在差異。當時，我們不確定能否立即訪問所有最新的 Kubernetes 功能。在這種情況下，特定功能並沒有成為障礙，但我們決定使用 Amazon 優先的服務，而不是 Amazon 託管的開源服務。當然，使用 Kubernetes 有很多好處，比如在執行混合雲環境時能夠進行更精細的控制，但這對我們來說並不重要。總而言之，由於上述原因，我們決定使用 ECS 而不是 EKS（因此我們沒有比較應該在 EC2 還是 Fargate 上執行 EKS）。

遷移工作負載

由於我們以前有過執行 Amazon Lambda 的經驗，從 Amazon OpsWorks 到 Amazon Lambda 的初始服務遷移進展迅速，沒有出現任何不可預見的問題。由於我們沒有任何使用 Amazon Fargate 的經驗，因此在開始遷移到 Amazon Fargate 之前，我們必須將所有剩餘服務 Doker 化。除了由於缺乏此類遷移經驗而不得不克服的技術難題外，還需要進行大量的團隊間協調，因為遷移涉及 10 多種服務，包括面向客戶的服務和內部服務。當然，前幾項服務花費的時間最多，因為我們必須找出最好的方法來進行部署、微調我們的自動擴縮，並確保將服務遷移到 Docker 的過程正常進行。我們首先開始遷移對產品沒有影響的內部服務，然後遷移對客戶有影響的內部服務，最後是面向客戶的服務。現在，最終設定會有所不同，因為我們的服務具有不同的整合和環境（例如，有時我們會將 Amazon Cognito 與 ALB 一起使用，或者在 ALB 前面使用 CDN 等）。以下是簡化的之前/之後比較，如下所示：

結論

一旦我們完成了專案的技術變更，就該評估我們是否實現了目標。總而言之，最初的痛點是：

  • OpsWorks/Chef/EC2 的維護工作量很大，大量開發時間花在維護上，而不是為客戶改進應用程式
  • 由於底層的 OpsWorks 和 Chef 堆疊，擴縮不可靠，預熱時間長達 20 分鐘以上
  • 使用 OpsWorks 的設定無法使用應用程式負載均衡器，後者具有我們想要使用的功能 透過切換到 Amazon Fargate 上的 Amazon ECS，以及 Amazon Lambda，我們獲得了以下好處：
  • 更快的釋出和回滾速度，更少的維護時間，使我們能夠專注於為學員構建新功能。使用 Amazon Lambda 以及 Amazon Fargate 上的 Amazon ECS，我們從每個 OpsWorks 叢集 25-30 分鐘的部署時間，變為幾乎即時部署/回滾。
  • 與我們之前的設定相比，可實現快速的自動可擴充套件性。2020 年 3 月，我們的流量出人意料地快速增長，產生來自世界各地的全天候需求高峰，事實證明這樣做很有用。
  • 將特定 Amazon 服務與其他 Amazon 服務整合在一起，以實現不同的目的，例如透過使用 Amazon ECR 映像掃描或透過 ALB 直接身份驗證，將安全掃描作為釋出流程的一部分進行整合
  • 降低成本，這是以更高效的方式利用我們的計算工作負載的附帶結果。我們已經在 https://www.babbel.com/en/magazine/how-to-do-more-with-fewer-servers 中詳細描述了這一點

關於 Babbel

Babbel 的使命是：讓所有人都能學習語言。這意味著要開發能夠幫助人們跨文化聯絡和交流的產品。Babbel、Babbel Live 和 Babbel for Business 致力於在真實情境下、在真人之間運用語言。並且行之有效：耶魯大學、紐約城市大學和密歇根州立大學的研究證明了它的有效性。關鍵是人文與技術的融合。150 多名語言學家精心製作了超過 6 萬節課，涵蓋 14 種語言，不斷分析使用者行為，以塑造和調整學員的體驗。柏林和紐約總部共有來自 60 多個國家/地區的 750 名員工，正是他們之間的個體差異塑造了獨一無二的人類。Babbel 是全球最賺錢的語言學習應用程式，已售出超過 1000 萬份訂閱。欲瞭解更多資訊，請訪問 www.babbel.com 或在 App Store 或 Play Store 中下載應用程式。

本篇作者

Gyorgi Stoykov

Gyorgi Stoykov MSc. 是 Babbel 基礎設施團隊的高階經理，目前位於柏林。他在財富 500 強公司、初創企業和學術界等各種環境中的雲端計算和基礎設施方面擁有豐富的經驗。他對 DevOps、Amazon 以及透過應用敏捷和 DevOps 最佳實踐幫助組織構建雲原生產品充滿熱情。

文章來源：https://dev.amazoncloud.cn/column/article/6309a3fa0c9a20404da...

相關文章