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

Babbel 是語言學習產品的完整生態系統，其中包括了世界上最暢銷的語言學習應用程式。我們銷售出超過 1,000 萬個訂閱，以及 6 萬節以上的課程 (適用於 14 種語言)，創造了全球語言學習者的首選服務。自 2007 年推出產品的第一天起，我們就一直在 Amazon Web Services (AWS) 上營運我們的平台，並且經常搶先採用 AWS 的新服務產品。因為 Babbel 學習生態系統處於純粹數位化環境，所以非常依賴基礎技術，這些技術不僅非得具備可靠和穩定性，而且還必須能在任何時間點進行調整。這在一路上帶來了挑戰和機遇，尤其是在產品增長和服務格局變化的同時。

Babbel 一直在擴大學習者人數，而流量也隨之在 2007-2020 年間增加。在 2020 年，Babbel 的學習者人數大幅增長，來自美國和我們主要歐洲市場的流量增加了兩到三倍。為因應全球不同的疫情法規，許多人選擇學習新語言，或精進自己的語言技能。這為我們帶來規模前所未有的額外傳入流量尖峰。在此期間，對於自己的基礎設施是否會因為使用者的需求不斷變化而受到挑戰，我們並未提出質疑。

不過，在 2020 年之前，我們在 Babbel 建置的託管 Babbel 服務平台，並未利用所有的 AWS 無伺服器服務。此平台依賴於 AWS OpsWorks 上執行的舊堆疊，而該堆疊不再適合所需的內容。在本文中，我們將說明讓 Babbel 思考改變的原因、考量的選項，以及最終如何將生產工作負載遷移到 AWS Fargate 上的 Amazon ECS 和 AWS Lambda。

我們處在不斷增長和變化的環境中，因此積極改變和改善事物。我們尋找著機會，而這些改進將為學習者提供更好的學習體驗。您可以想像，將技術主題作為優先考慮，並不總是很容易轉化為改進的學習者體驗，但是我們將一些支柱視為路標：

• 加速開發速度和發行時間
• 減少維護工作
• 擁有並維護最新的環境
• 改善功能交付時間

在開始專案之前，因為我們執行的是舊版 OpsWorks，所以必須使用過時版本的 Chef 來管理 OpsWorks EC2 執行個體的組態。因為這些執行個體是以較舊的執行個體類型為基礎，並使用接近其生命週期末期的 Ubuntu 版本，所以絕對需要採取行動。將 Chef 技術指南升級至新的 Chef 版本、升級 Ubuntu 版本，以及升級舊的 OpsWorks EC2 執行個體將花費大量時間。此外，我們的部署、回復和升級時間，讓開發人員在維護工作上耗費了大量的工時，而我們希望減少花費的時間。在流量急劇增加的情況下，我們的擴展時間會比原本希望的更久，而且自動擴展並不可靠。在某些情況下，最多需要 25 分鐘才能將額外的 EC2 執行個體新增至 OpsWorks 叢集。對於負載平衡，我們受限於使用 Classic ELB，這沒有我們希望使用的所有功能，例如透過 Cognito 和路由進行身分驗證。Application Load Balancer (ALB) 中可提供這些功能，但 OpsWorks 目前不支援 ALB。鑑於這些情況，我們得出理想的解決方案必須能解決這些主題，這意味著我們不得不淘汰我們的 OpsWorks EC2 設定。

在分析潛在的技術解決方案之前，我們從功能的角度討論了理想的解決方案。我們同意理想的解決方案應

• 與我們現有的 AWS 架構及我們的 Terraform 投資和結構完美整合
• 有專門的服務與支援團隊進行積極開發並保持最新狀態
• 騰出營運和維護時間，讓我們能夠處理可為學習者或 Babbel 工程團隊帶來更多價值的事務

我們很清楚，解決方案應該採用無伺服器架構。我們繼續研究可用的解決方案，以淘汰 OpsWorks，並取代整個計算和託管層。我們考慮的選項包括：

• AWS Lambda
• Amazon Elastic Container Service (Amazon ECS)
  
• Amazon Elastic Kubernetes Service (Amazon EKS)

我們就這些方案提出了以下結論：

在理想情況下，我們將在 Lambda 上執行幾乎所有內容。根據預設，系統會自動進行規模調整而不需設定，也無需維護任何執行個體，更不必在 OS 層上進行 OS 和安全性更新，並可即時進行部署/回復。這對我們的某些服務來說是可行的，所以我們決定為這些服務使用 Lambda。但是，我們判斷 Lambda 不是最適合所有服務的解決方案。我們有一些需要 Docker 的多功能服務，而在 2020 年初進行評估時，Lambda 尚未具備支援容器映像格式的功能。

因為 Lambda 不是這些類型服務的合適選項，所以我們必須決定要執行 (Docker) 容器的平台。我們評估了 Amazon EKS 和 Amazon ECS，我們有以下四個選項可供選擇：

• ECS on EC2
• ECS on Fargate
• EKS on EC2
• EKS on Fargate

因為使用 ECS on Fargate 和 ECS on EC2 的體驗非常相似，這是整個生態系統對比 Kubernetes 和 EKS (在 EC2 或 Fargate 上) 的替代解決方案，所以我們對使用這兩種技術堆疊都衡量了利弊。在 Fargate 上執行 ECS 的功能於 2019 年推出，但起初缺少了我們當時所需的部分功能 (例如容器的成本分配標籤)。AWS 客戶經理協助我們處理功能請求，並隨後實作了這些功能。這些功能發佈後，我們就能順暢無阻地將所有剛 Docker 化的服務移至 ECS on Fargate。因為 Fargate 為我們省去了基礎 EC2 機器的維護成本，所以和 EC2 相比來說，Fargate 是我們架構的最佳選擇。本技術堆疊也很容易與剩下的 AWS 服務和 Terraform 程式碼基底整合，且我們已經擁有該程式碼基底的管理經驗。

在權衡執行 EKS 優缺點的同時，我們判斷不需要使用案例和基礎設施設定。我們的主要目標是擁有一個平台，以最少的精力擴展 Docker 容器，並在其餘環境和 AWS 服務整合中進行最少的變更。此外，因為營運工作不會為學習者帶來任何價值，所以我們希望確保將該工作量降至最低。我們認為自己會在使用 Kubernetes 時擁有更陡峭的學習曲線，需要對現有環境進行更多變更，並有更多的營運和維護工作。我們認為可以使用更多以 AWS 為中心的基礎設施即程式碼，在開發和基礎設施之間進行更好的區隔，且我們正在透過 Terraform 管理基礎設施即程式碼 (例如使用 AWS IAM)。簡而言之，我們希望改變運算/託管環境，而無需對我們的系統、服務，以及執行部署、管理網路、安全群組等項目的設定方式進行更大調整。

在 2019 年/2020 年初，EKS 仍然是一項較新的服務。當時，我們決定不採用 EKS (或 Kubernetes)，是考慮到在 AWS 上執行之 Kubernetes 功能的支援問題。雖然 EKS 使用上游 Kubernetes 程式碼 (無修改)，但我們擔心的是 Kubernetes 最新版本與 EKS 提供版本之間的差異。當時，我們不確定是否可以立即存取所有最新的 Kubernetes 功能。在這種情況下，因為所有功能都沒有不可接受的缺點，所以我們決定要使用 AWS 優先的服務，而不是 AWS 受管的開放原始碼服務。使用 Kubernetes 肯定有許多優點，例如能夠以更精細的控制執行混合式雲端環境，但這對我們來說並不重要。總之，因為上述原因，我們決定使用 ECS 而不是 EKS (所以我們沒有比較我們應在 EC2 上還是 Fargate 上執行 EKS)。

因為我們先前有執行 AWS Lambda 的經驗，所以將服務從 AWS OpsWorks 初步遷移至 AWS Lambda 十分快速，而且沒有出現任何意外。因為我們沒有任何使用 AWS Fargate 的經驗，所以在開始遷移到 AWS Fargate 之前，我們必須先將所有剩餘服務 Docker 化。除了缺乏這類遷移經驗所必須克服的技術挑戰之外，這項工作還需要大量團隊間協調，因為遷移觸及 10 多種面向客戶的服務和內部服務。當然，因為我們必須找出最好的方法進行部署、微調我們的自動擴展，並確保從服務到 Docker 的遷移如期運作，所以前幾項服務花費了最多的時間。我們首先開始遷移產品未受影響的內部服務，接著遷移對客戶產生影響的內部服務，最後遷移面向客戶的服務。現在，因為我們的服務具有不同的整合和環境，所以最終設定會有所不同 (也就是說，有時候我們會將 AWS Cognito 與 ALB 搭配使用，或在 ALB 之前使用 CDN 等)。下列是一個簡化的前後對比圖：

在完成專案的技術變更後，就是時候該評估我們是否達成了我們的目標。總結而言，最初的痛點為：

• OpsWorks/Chef/EC2 的大量維護工作，花費大量的開發時間進行維護，而不是為客戶改進應用程式
• 因為基礎 OpsWorks 和 Chef 堆疊之故，所以擴展不可靠，且暖機時間高達 20 分鐘以上
• OpsWorks 的安裝無法使用 Application Load Balancer，其中包含我們想要使用的功能

透過切換至 AWS Fargate 上的 Amazon ECS 和 AWS Lambda，我們獲得了下列好處：

• 更快的發行和回復時間、減少維護時間，使我們能夠專注於為學習者建置新功能。我們在每個 OpsWorks 叢集的部署時間，從每個 OpsWorks 叢集 25-30 分鐘，變為使用 AWS Fargate 上的 AWS Lambda 和 Amazon ECS 時，幾乎即時的部署/回復。
• 與之前的設定相比，更快速的自動化可擴展性。事實證明，當 2020 年 3 月的流量非預期快速增加，產生全天和來自世界各地的需求峰值時，這項特性非常有用。
• 使用我們與其他 AWS 服務整合的 AWS 服務以達成不同用途，例如使用 Amazon ECR 映像掃描或透過 ALB 直接身份驗證，將安全性掃描整合為發行程序的一部分
• 以更有效率的方式利用我們的運算工作負載，並額外降低成本。我們已在 https://www.babbel.com/en/magazine/how-to-do-more-with-fewer-servers 下描述這一點
  
  

關於 Babbel

關於作者