Hành trình chuyển đổi hạ tầng của Duolingo: Từ ECS sang Kubernetes với hơn 500 dịch vụ

06 tháng 4, 2026·5 phút đọc

Franka Passing, Kỹ sư Nền tảng Cấp cao tại Duolingo, chia sẻ về quá trình di chuyển quy mô lớn của nền tảng học ngôn ngữ này từ AWS ECS sang EKS. Bài viết đề cập đến việc áp dụng GitOps với Argo CD, kiến trúc mạng IPv6-only, và những bài học thực tế về quản lý niềm tin của nhà phát triển cũng như các giới hạn tốc độ trên AWS.

Hành trình chuyển đổi hạ tầng của Duolingo: Từ ECS sang Kubernetes với hơn 500 dịch vụ

Duolingo, ứng dụng học ngôn ngữ hàng đầu với hơn 128 triệu người dùng hoạt động hàng tháng, đã thực hiện một bước tiến kỹ thuật quan trọng: chuyển đổi hơn 500 dịch vụ backend từ AWS ECS sang Kubernetes (EKS). Franka Passing, Kỹ sư Nền tảng Cấp cao tại Duolingo, đã có bài trình bày chi tiết về "cú nhảy Kubernetes" này, chia sẻ những thách thức, chiến lược kiến trúc và các bài học thực tế từ quá trình triển khai.

Duolingo Kubernetes MigrationDuolingo Kubernetes Migration

Tại sao lại là Kubernetes?

Trước khi chuyển đổi, Duolingo vận hành hệ thống trên AWS ECS, một giải pháp quản lý container đơn giản và hiệu quả. Tuy nhiên, khi quy mô mở rộng với hơn 400 kỹ sư và hàng trăm dịch vụ, nhu cầu về một hệ sinh thái phong phú hơn trở nên cấp thiết. Kubernetes mang lại tiêu chuẩn công nghiệp mã nguồn mở, hỗ trợ đa đám mây (multi-cloud) và tích hợp tốt với các công cụ nguồn mở mạnh mẽ.

Lý do cốt lõi thúc đẩy việc di chuyển bao gồm nhu cầu về các chiến lược triển khai linh hoạt như Blue-Green deployments và khả năng tạo ra các môi trường phát triển tạm thời (ephemeral dev deployments) để giải quyết vấn đề thiếu hụt môi trường staging tĩnh.

Xây dựng nền tảng với Argo CD và GitOps

Một trong những trụ cột chính của nền tảng mới là việc sử dụng Argo CD để triển khai theo mô hình GitOps. Điều này đảm bảo rằng cấu hình trong kho Git (GitHub) là nguồn sự thật duy nhất cho môi trường thực tế.

Kiến trúc Cellular (Cellular Architecture)

Đội ngũ kỹ sư tại Duolingo đã áp dụng một kiến trúc độc đáo gọi là "cellular architecture". Trong đó, mỗi tenant (khách thuê) chứa nhiều cluster nhưng được cô lập hoàn toàn. Điều này cho phép đội ngũ nền tảng thử nghiệm các thay đổi trên một cell riêng biệt mà không ảnh hưởng đến các dịch vụ đang chạy sản phẩm hoặc các kỹ sư phát triển khác. Điều này giúp quản lý rủi ro và đảm bảo tính ổn định cho hệ thống.

Thách thức với IPv6

Trong quá trình xây dựng hạ tầng mạng, Duolingo quyết định chuyển sang sử dụng IPv6-only cho các pod Kubernetes. Đây là bước đi hướng tới tương lai để tránh việc cạn kiệt địa chỉ IPv4, đặc biệt khi mỗi pod đều cần một địa chỉ IP riêng.

Tuy nhiên, việc này tạo ra một số thách thức lớn:

  • Cập nhật ứng dụng: Các dịch vụ cũ (container) không thể "lift-and-shift" trực tiếp. Các nhóm phát triển phải sửa đổi code để cấu hình các framework web (như Flask hay Java) chấp nhận kết nối IPv6.
  • Chi phí NAT: Mặc dù lưu lượng egress IPv6 miễn phí, nhưng nhiều dịch vụ vẫn cần gọi đến các máy chủ IPv4, dẫn đến việc vẫn phải sử dụng NAT Gateway tốn kém.
  • Hỗ trợ dịch vụ: Không phải tất cả các dịch vụ của AWS (ví dụ: DynamoDB trước đây) đều hỗ trợ endpoint IPv6, khiến việc tích hợp trở nên phức tạp.

Quy trình di chuyển và bài học thực tế

Quá trình di chuyển được chia thành ba giai đoạn chính: xây dựng nền tảng, triển khai dịch vụ thí điểm (pilot), và áp dụng rộng rãi. Đối với các dịch vụ thí điểm, Duolingo sử dụng phương pháp phân chia lưu lượng truy cập qua DNS có trọng số (weighted DNS records).

Kiểm soát Canary và Validation

Để đảm bảo an toàn, lưu lượng được chuyển dần từ ECS sang EKS (ví dụ: 10%, sau đó 50%, và cuối cùng là 99%). Đội ngũ thực hiện kiểm tra bằng cách so sánh độ trễ (latency) và tỷ lệ lỗi giữa dịch vụ cũ và mới. Ví dụ, một dịch vụ tên mã "owl-service" đã từng không vượt qua bài kiểm tra canary do độ trễ cao và buộc phải quay lại sửa đổi.

Quản lý niềm tin và "Recency Bias"

Một thách thức không phải kỹ thuật là tâm lý của đội ngũ phát triển. Franka Passing gọi đây là "recency bias" (thiên kiến gần đây) — xu hướng đổ lỗi cho mọi sự cố mới phát sinh cho nền tảng Kubernetes mới, dù thực tế nguyên nhân có thể do code hoặc nhà cung cấp bên thứ ba. Để giải quyết, đội ngũ nền tảng tập trung mạnh vào observability (khả năng quan sát), cung cấp dữ liệu rõ ràng để chứng minh nguyên nhân sự cố, và luôn hỗ trợ trực tiếp các đội ngũ trong các tình huống khẩn cấp để xây dựng lòng tin.

Vượt qua giới hạn tốc độ (Rate Limits)

Khi chuyển đổi quy mô lớn, Duolingo gặp phải vấn đề về giới hạn tốc độ API của AWS, đặc biệt là với EKS Pod Identity agent và AMP (Managed Prometheus). Việc triển khai chậm rãi và kiểm soát chặt chẽ phần trăm lưu lượng đã giúp họ phát hiện sớm这些问题 (vấn đề) và điều chỉnh kịp thời với sự hỗ trợ từ đội ngũ tài khoản của AWS.

Kết luận

Hành trình chuyển đổi sang Kubernetes của Duolingo là một minh chứng cho thấy việc lập kế hoạch kỹ lưỡng, xây dựng nền tảng vững chắc (với observability và security), và chọn đúng đối tác thí điểm sớm là chìa khóa thành công. Mặc dù vẫn đang trong quá trình hoàn thiện, nhưng việc chuyển đổi đã mang lại cho Duolingo sự linh hoạt cần thiết để tiếp tục phát triển sản xuất giáo dục tốt nhất thế giới.

Đối với các doanh nghiệp đang cân nhắc chuyển đổi tương tự, bài học lớn nhất là: Hãy chắc chắn về lý do "tại sao" bạn thực hiện nó, và luôn chuẩn bị tâm thế cho những "báo cáo từ thực chiến" đầy bất ngờ.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗