Blog công nghệ, News, Tin tức Cloud services
Duolingo chuyển hơn 500 services backend từ AWS ECS sang EKS
Th4
Duolingo là một case rất đáng học về cách một ứng dụng phát triển thành một platform công nghệ, và khi sản phẩm đã đủ lớn ở quy mô toàn cầu thì hạ tầng phải được nâng cấp như thế nào để tiếp tục tăng trưởng.
Hơn 130 triệu người dùng hoạt động hằng tháng, hơn 50 triệu người dùng hoạt động hằng ngày, hơn 250 khóa học ngôn ngữ, cùng vị thế ứng dụng có doanh thu cao nhất trong hạng mục Education trên cả Google Play lẫn Apple App Store khiến những quyết định kỹ thuật đều đáng chú ý.
Phía sau những con số đó là một hệ thống hơn 500 dịch vụ backend do hơn 400 kỹ sư phát triển và vận hành, nơi hạ tầng trở thành thứ quyết định tốc độ phát triển, độ an toàn khi triển khai và khả năng chịu lỗi của toàn nền tảng. Đó là lý do Duolingo migration từ AWS ECS sang AWS EKS.
Mục tiêu của chiến dịch chuyển đổi được xác định từ đầu với hai trọng tâm ưu tiên là blue-green deployments và ephemeral dev deployments, nhằm giải quyết tình trạng triển khai chậm và môi trường kiểm thử trung gian không sẵn sàng khi cần.
1) Vì sao rời ECS khi ECS vẫn đáp ứng tốt?
ECS là dịch vụ do AWS quản lý, khá đơn giản và đã phục vụ tốt trong giai đoạn trước. Lý do chuyển sang EKS nằm ở hai nhóm nguyên nhân kỹ thuật:
- Hệ sinh thái và khả năng mở rộng của nền tảng: Kubernetes có hệ sinh thái mã nguồn mở rất phong phú. Các công cụ như Argo CD cho GitOps và rollout, cùng Karpenter để tối ưu việc cấp phát node, đặc biệt hữu ích khi dùng Spot nhiều.
- Các chiến lược triển khai được chuẩn hóa thành cơ chế dùng chung: các mô hình như blue-green, rolling, canary tăng dần có thể được chuẩn hóa thành quy trình chung, thay vì phụ thuộc vào thao tác thủ công ở từng nhóm.
Chi phí thay đổi nền tảng không chỉ đến từ hạ tầng và nguồn lực triển khai, mà còn từ chi phí đào tạo và thời gian thích nghi của các đơn vị tham gia. Vì vậy, lý do và thông điệp của chương trình chuyển đổi phải được duy trì nhất quán xuyên suốt.
2) Đội nền tảng dẫn dắt chuyển đổi, đội sản phẩm tự chủ tiến độ
Nhóm phụ trách chuyển đổi của Duolingo có quy mô không lớn, chủ yếu gồm PM, Tech lead, Enginner, cùng các đại diện từ Observability, Security, CI/CD tham gia theo từng giai đoạn. Nền tảng này phục vụ hơn 30 nhóm phát triển đang sở hữu các dịch vụ backend.
Ba nguyên tắc phối hợp được Duolingo đặt ra để giảm trở ngại trong quá trình chuyển đổi:
- Đội nền tảng đảm nhận phần lớn công việc liên quan đến công cụ và quy trình chuyển đổi
- Có hỗ trợ theo sát từng dịch vụ trong suốt quá trình chuyển đổi
- Các đơn vị tham gia tự giữ tiến độ để hạn chế ảnh hưởng tới roadmap sản phẩm
3) Hoàn thiện hạ tầng nền tảng ban đầu, đưa nhóm dịch vụ đầu tiên vào production, tiếp đến là mở rộng
Chương trình được chia thành ba giai đoạn:
- H2 2024: hoàn thiện phần nền tảng ban đầu, dựng công cụ và một cụm dịch vụ thử nghiệm
- H1 2025: hoàn thiện nền tảng để sẵn sàng cho production và đưa nhóm service đầu tiên lên production
- Giai đoạn tiếp theo: chuyển các dịch vụ quan trọng, mở rộng tự động hóa, đồng thời xử lý các vấn đề phát sinh khi quy mô tăng lên
Cách tiếp cận này cho thấy Duolingo không chọn cách chuyển đổi đồng loạt, mà bắt đầu từ phần nền tảng, kiểm chứng từng bước, rồi mới mở rộng sang các dịch vụ quan trọng hơn.
4) GitOps và progressive delivery là trọng tâm của đợt chuyển đổi
4.1 Argo CD, GitOps và rollout dựa trên metrics
Argo CD được chọn làm công cụ triển khai theo mô hình declarative GitOps, trong đó Git là nguồn tham chiếu chuẩn cho cấu hình triển khai và Argo CD sẽ đồng bộ cấu hình đó vào cluster.
Hai trọng tâm được ưu tiên triển khai sớm:
- Blue-green deployments: rollout phiên bản mới, chuyển dần traffic có kiểm soát, theo dõi các metrics như latency và error rate, sau đó mới mở rộng traffic khi các chỉ số vẫn nằm trong ngưỡng cho phép
- Ephemeral dev deployments: tạo môi trường tạm thời cho từng PR để giảm phụ thuộc vào môi trường staging cố định
Điểm quan trọng ở đây là Duolingo không chỉ thay công cụ triển khai, mà còn tận dụng đợt chuyển đổi này để chuẩn hóa lại quy trình đưa thay đổi vào production.
4.2 Mô hình tenant/cell để giới hạn phạm vi ảnh hưởng
Duolingo triển khai mô hình tenant/cell, trong đó mỗi tenant là một môi trường tách biệt và bao gồm các lớp dev, stage, prod. Các thay đổi ở tầng nền tảng được thử nghiệm trước trong một tenant riêng, rồi mới áp dụng vào tenant chính của các nhóm dịch vụ. Mục tiêu của cách triển khai này là đưa thay đổi vào phạm vi nhỏ trước, giới hạn blast radius và giảm rủi ro lan rộng khi có lỗi hoặc hành vi ngoài dự kiến.
5) IPv6 pods là quyết định ở tầng nền tảng, kéo theo thay đổi ứng dụng và chi phí
IPv6 được chọn cho pods để giảm rủi ro cạn địa chỉ IPv4 khi Kubernetes gán IP cho từng pod. Để tương thích với hệ thống cũ và các dịch vụ phụ trợ vẫn còn dùng IPv4, VPC được vận hành theo mô hình dual-stack.
3 hệ quả thực tế:
- Một số framework của ứng dụng phải cập nhật cấu hình để chấp nhận kết nối IPv6 đi vào
- NAT cost vẫn phát sinh vì còn nhiều đích chỉ hỗ trợ IPv4
- Mức độ hỗ trợ endpoint IPv6 của một số AWS services chưa đồng đều tại thời điểm triển khai, tạo thêm yêu cầu kiểm tra tương thích
Chi tiết này cho thấy một quyết định ở tầng nền tảng không dừng ở hạ tầng, mà có thể kéo theo thay đổi ở cả ứng dụng lẫn chi phí vận hành.
6) Tách tín hiệu ECS và EKS trong giai đoạn chia traffic
Duolingo xem observability là phần nền tảng bắt buộc phải có ngay từ giai đoạn đưa nhóm dịch vụ đầu tiên vào production, với Honeycomb cho tracing, Sentry cho theo dõi lỗi, PagerDuty cho alerting và các tích hợp với AWS.
Khi traffic được chia giữa ECS và EKS, một vấn đề thực tế phát sinh là khâu phân loại và xử lý sự cố: khi có alert hoặc page, team không thể biết ngay tín hiệu đến từ ECS hay EKS. Cách xử lý là bổ sung các nhãn nhận diện, chẳng hạn Kubernetes cluster name, vào traces và dữ liệu telemetry để tách rõ tín hiệu giữa hai hệ thống.
Đây là chi tiết rất thực tế trong các chiến dịch chuyển đổi: nếu không tách bạch được tín hiệu từ hệ thống cũ và hệ thống mới, quá trình chẩn đoán rất dễ lệch hướng hoặc làm chậm việc xử lý sự cố.
7) Helm xử lý manifest, Terraform xử lý IAM và Pod Identity
7.1 Template khởi tạo service
Duolingo chuẩn hóa việc khởi tạo service bằng Helm chart cho hai dạng workload chính:
- Web service
- Worker không có HTTP ingress, dùng
KEDAđể scale theo queue
7.2 Terraform cho các phần tích hợp chặt với AWS
Ở ECS trước đây, Terraform module có thể bao phủ gần như toàn bộ cấu hình của một ECS service. Với EKS, Terraform module được tập trung vào các phần tích hợp chặt với AWS như IAM roles, EKS Pod Identity, cấu hình biến môi trường và secrets.
Nói ngắn gọn, Helm xử lý phần manifest và chuẩn hóa service theo mẫu chung, còn Terraform xử lý các thành phần gắn chặt với AWS.
8) Quy trình chuyển service sang EKS
Quy trình chuyển một service được Duolingo mô tả khá rõ theo các bước:
- Dùng Terraform để chuẩn bị quyền truy cập và cấu hình observability mặc định
- Dùng manifest của Argo CD để định nghĩa resources, scaling và rollout strategy
- Kiểm tra bằng metrics, traces, logs và so sánh response với service đang chạy trên ECS
- Chạy canary với tỷ lệ traffic tăng dần theo từng mốc quan sát
- Cutover khi hệ thống đã ổn định, đồng thời vẫn duy trì ECS chạy song song để giữ sẵn phương án rollback khi cần
Weighted DNS records được dùng để chia traffic giữa ECS và EKS. Đồng thời, Duolingo cũng lưu ý rằng DNS có độ trễ nhất định khi cần đổi hướng traffic nhanh, nên phải tính trước điều này trong kịch bản rollback.
Điểm đáng chú ý ở đây là họ luôn giữ sẵn rollback path, thay vì coi cutover là thời điểm không còn khả năng rollback.
9) Recency bias và cách tránh để các lỗi nhỏ
Khi nền tảng mới bắt đầu được đưa vào vận hành, các sự cố rất dễ bị quy hết về phía hệ thống mới. Nếu điều đó lặp lại nhiều lần, các trục trặc nhỏ sẽ tích lũy dần và bào mòn niềm tin của các nhóm sở hữu service.
Các biện pháp Duolingo nêu ra để tăng niềm tin khi vận hành nền tảng mới:
- Observability đủ chi tiết để xác định nguyên nhân
- Đào tạo và tài liệu để team nắm được quy trình xử lý ban đầu và các dashboard mới
- Đội nền tảng tham gia hỗ trợ trong incident response để rút ngắn thời gian xử lý và tăng mức tự tin khi vận hành
Đây là một điểm rất đáng chú ý: chuyển đổi hạ tầng không chỉ là bài toán kỹ thuật, mà còn là bài toán niềm tin giữa đội nền tảng và các nhóm sử dụng nền tảng.
10) Rate limit chỉ lộ ra khi traffic tăng lên
Khi số service tăng và tỷ lệ traffic tăng lên, một số giới hạn dịch vụ mới bắt đầu lộ ra, ví dụ:
EKS Pod Identityagent API bị rate limit, khiến pod không lấy được role- AWS Managed Prometheus (AMP) bị rate limit, nhưng chỉ lộ ra khi traffic tăng từ 50% lên 70%
Hai quyết định giúp giảm rủi ro trong giai đoạn này:
- Triển khai tăng dần để phát hiện giới hạn sớm
- Giữ khả năng rollback để có thể giảm traffic về mức an toàn khi cần
Các giới hạn kiểu này thường không xuất hiện ở giai đoạn đầu, mà chỉ lộ ra khi quy mô bắt đầu tăng đủ lớn.
11) Chặn workload mới phát sinh trên ECS
Một mốc triển khai quan trọng là mọi service mới đều phải chạy trên EKS ngay từ đầu, nhằm tránh làm tăng thêm khối lượng chuyển đổi còn lại và ngăn quy mô workload trên ECS tiếp tục phình ra.
Đây là một quyết định rất thực tế: nếu vẫn cho phép workload mới tiếp tục phát sinh trên ECS, chương trình chuyển đổi sẽ kéo dài đáng kể thời gian hoàn tất chuyển đổi.
Key takeaways
- Chuyển đổi cần đi cùng năng lực observability và khả năng kiểm chứng của nền tảng, thay vì chỉ đổi orchestrator.
- Hoàn thiện phần nền trước giúp giảm rủi ro: GitOps, deployment strategies, networking, observability, templates, access control cần hoàn chỉnh trước khi mở rộng quy mô.
- Kiến trúc cell hỗ trợ triển khai thay đổi ở tầng nền tảng với blast radius nhỏ và tạo môi trường thử nghiệm tách biệt.
- IPv6 pods là quyết định ở tầng nền tảng, kéo theo thay đổi ứng dụng và chi phí vận hành như NAT và tương thích endpoint.
- Chuyển traffic có cơ sở đối chiếu rõ ràng và có phương án rollback giúp kiểm soát rủi ro trong quá trình chuyển đổi.
Kết luận
Duolingo cho thấy một trong những ứng dụng học ngoại ngữ hàng đầu thế giới giải quyết bài toán hạ tầng công nghệ theo cách rất rõ ràng và thực tế. Việc sử dụng được ngoại ngữ để luôn cập nhật kiến thức và thông tin mới nhất đã trở thành điều gần như bắt buộc trong ngành công nghệ. Song hành với các bài học về hạ tầng, việc trực tiếp trải nghiệm ứng dụng của họ cũng là một cách giúp hình dung rõ hơn những vấn đề thực tế có thể hỗ trợ trực tiếp cho công việc.