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à managed, đơ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 lý do kỹ thuật:
- Hệ sinh thái và khả năng mở rộng chức năng nền tảng: Kubernetes có hệ sinh thái open source phong phú. Các công cụ như Argo CD cho GitOps và rollout strategies, cùng Karpenter để tối ưu cấp phát node, đặc biệt hữu ích khi sử dụng Spot nhiều.
- Deployment strategies được chuẩn hóa thành trọng tâm của nền tảng: các mô hình triển khai như blue-green, rolling, phased canary có thể được tiêu chuẩn hóa thành quy trình chung của platform, giảm phụ thuộc vào thao tác thủ công theo từng team.
Chi phí thay đổi nền tảng không chỉ nằm ở hạ tầng và nguồn lực kỹ thuật, mà còn ở đào tạo và thời gian product teams thích nghi, vì vậy lý do và thông điệp cần nhất quán trong toàn chương trình.
2) Nhóm triển khai tinh gọn, coi product teams là khách hàng của platform
Core team triển khai có khoảng 6-7 người, gồm PM, technical lead, platform engineers, và các đại diện từ observability, security, CI/CD tham gia theo từng giai đoạn. Người dùng của platform là hơn 30 product teams sở hữu các backend services.
Ba nguyên tắc hợp tác được Duolingo đặt ra để giảm khó khăn trong phối hợp:
- Platform team đảm nhiệm phần lớn khối lượng công việc liên quan đến tooling và quy trình chuyển đổi
- Có hỗ trợ theo từng service trong quá trình chuyển đổi
- Product teams giữ quyền quyết định về timeline để hạn chế ảnh hưởng đến roadmap sản phẩm
3) Foundation trước, early adopters sau, rồi mở rộng cho các dịch vụ quan trọng
Chương trình được chia thành ba phase:
- H2 2024: xây foundation, dựng tooling và thử nghiệm trên test services
- H1 2025: ổn định hóa nền tảng cho production và đưa early adopters lên production
- Giai đoạn tiếp theo: chuyển các dịch vụ quan trọng và mở rộng tự động hóa, đồng thời xử lý các vấn đề phát sinh khi tăng quy mô
4) GitOps và progressive delivery là trục chính
4.1 Argo CD, GitOps và triển khai theo metrics
Argo CD được chọn làm deployment agent theo mô hình declarative GitOps, trong đó cấu hình trong Git là source of truth và Argo CD đồng bộ vào cluster.
Hai trọng tâm được ưu tiên triển khai sớm:
- Blue-green deployments: triển khai phiên bản mới, điều hướng traffic có kiểm soát, theo dõi metrics như latency và error rate, sau đó chuyển traffic theo điều kiện
- Ephemeral dev deployments: tạo môi trường tạm theo PR để giảm phụ thuộc vào môi trường stage cố định
4.2 Tenant isolation để giảm blast radius
Duolingo triển khai mô hình tenant hoặc cell: mỗi tenant là một môi trường cô lập, bên trong có dev, stage, prod. Platform changes được thử nghiệm trong tenant riêng trước khi áp dụng vào tenant chính của product teams. Mục tiêu là triển khai thay đổi platform theo phạm vi nhỏ, hạn chế tác động ngoài ý muốn.
5) IPv6 pods là quyết định 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 tình trạng hết địa chỉ IPv4 khi Kubernetes gán IP cho từng pod. Để tương thích với hệ thống cũ và dependency IPv4, VPC được vận hành theo mô hình dual-stack.
Ba hệ quả thực tế :
- Một số service frameworks cần cập nhật cấu hình ứng dụng để chấp nhận IPv6 inbound
- NAT cost vẫn phát sinh vì còn nhiều destination IPv4-only
- Phạm vi hỗ trợ IPv6 endpoints 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
6) Phân biệt signal đến từ ECS hay EKS khi chia traffic
Duolingo coi observability là phần nền bắt buộc ngay từ early adopters, với Honeycomb cho tracing, Sentry cho bug tracking, PagerDuty cho alerting và các AWS integrations.
Khi chia traffic giữa ECS và EKS, một vấn đề phát sinh là phân loại và xử lý sự cố: khi có page, team không chắc signal đến từ ECS hay EKS. Cách xử lý là gắn thêm nhãn nhận diện như Kubernetes cluster name vào traces và dữ liệu telemetry để tăng khả năng phân biệt nguồn.
7) Helm cho manifests, Terraform cho IAM và Pod Identity
7.1 Service templates
Việc khởi tạo service được Duolingo chuẩn hóa bằng Helm charts cho hai dạng workload:
- Web service
- Worker không có HTTP ingress, dùng
KEDAđể scale theo queue based scheduling
7.2 Terraform cho các phần AWS-specific
Trong ECS trước đây, Terraform module có thể bao phủ gần như toàn bộ cấu hình ECS service. Với EKS, Terraform module tập trung vào các phần AWS-specific như IAM roles, EKS Pod Identity, đồng bộ biến môi trường và secrets.
8) Terraform, Argo manifest, validation, canary, cutover
Quy trình chuyển một service được Duolingo làm rất rõ ràng theo các bước:
- Terraform cho permissions và observability defaults
- Argo CD manifest để định nghĩa resources, scaling và rollout strategy
- validation bằng metrics, traces, logs và so sánh response với service ECS
- canary test với phần trăm traffic tăng dần theo thời gian quan sát
- chuyển hẳn khi ổn định, đồng thời duy trì ECS chạy song song để có đường quay lại khi cần
Weighted DNS records được dùng để chia traffic ECS và EKS, đồng thời cần lưu ý DNS có thể chậm khi cần thay đổi nhanh nên phải tính trước trong kịch bản rollback.
9) Recency bias và cách giảm tích lũy các vấn đề nhỏ
Một rủi ro khi platform mới được đưa vào là các sự cố dễ bị quy về nền tảng mới. Nếu lặp lại, các vấn đề nhỏ tích lũy sẽ làm giảm niềm tin của product teams.
Các biện pháp Duolingo nêu để củng cố niềm tin vận hành:
- Observability đủ chi tiết để xác định nguyên nhân
- Training và tài liệu để team biết quy trình triage và dashboard mới
- Platform team tham gia hỗ trợ trong incident response để giảm thời gian xử lý và tăng mức tự tin khi vận hành
10) Rate limits chỉ lộ khi tăng traffic
Khi số service tăng và tỷ lệ traffic tăng lên, các rate limits mới liên tục lộ ra, ví dụ:
EKS Pod Identityagent API rate limiting khiến pod không lấy được role- AWS managed Prometheus AMP rate limiting, chỉ lộ khi tăng traffic từ 50% lên 70%
Hai quyết định giảm rủi ro:
- Triển khai tăng dần để phát hiện giới hạn sớm
- Đảm bảo khả năng rollback để giảm traffic về mức an toàn khi cần
11) Ngăn phát sinh thêm workload trên ECS
Một mốc triển khai quan trọng là mọi service mới tạo ra đều chạy trên EKS ngay từ đầu, nhằm tránh tăng thêm khối lượng chuyển đổi trong tương lai và ngăn mở rộng footprint ECS.
Key takeaways
- Migration cần gắn với platform capability có thể quan sát và kiểm chứng, thay vì chỉ thay orchestrator.
- Foundation-first 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ô.
- Cellular architecture hỗ trợ triển khai thay đổi platform theo blast radius nhỏ và tạo môi trường thử nghiệm tách biệt.
- IPv6 pods là quyết định platform, kéo theo thay đổi ứng dụng và chi phí vận hành như NAT và tương thích endpoints.
- Traffic migration có đường so sánh và đường quay lại giúp kiểm soát rủi ro khi chuyển đổi.
Kết luận
Duolingo cho thấy một trong những ứng dụng học tiếng Anh hàng đầu thế giới giải quyết bài toán hạ tầng công nghệ theo cách rõ ràng và thực tế như thế nào. 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 tất yếu trong ngành công nghệ. Song hành với các bài học 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 thực tế hơn những vấn đề có thể hỗ trợ trực tiếp cho công việc.
