Trong loạt hai phần này, chúng ta sẽ thảo luận về các thách thức mà OfferUp, một khách hàng Digital Native, đã phải đối mặt để đáp ứng sự phát triển kinh doanh và thời gian đưa sản phẩm ra thị trường. Hành trình của họ liên quan đến việc hiện đại hóa nền tảng DevOps hiện có của họ, từ kiến trúc truyền thống dựa trên máy ảo (VM) thành kiến trúc dựa trên container hiện đại và chạy các ứng dụng cloud-native để triển khai dự án theo phong cách Progressive Delivery an toàn để tăng tốc thời gian ra thị trường. Loạt bài viết này sẽ cung cấp các chiến lược, mô hình kiến trúc và các bước kỹ thuật mà bạn có thể áp dụng để trở nên linh hoạt và sáng tạo như OfferUp.

Các kỹ sư của OfferUp đã sử dụng nền tảng DevOps tự phát triển để xây dựng và phát hành các dịch vụ mới trên nền tảng thương mại điện tử của họ. Trong bài viết đầu tiên này, chúng ta sẽ thảo luận về các thách thức quan trọng mà các kỹ sư của OfferUp đã gặp phải với nền tảng DevOps hiện có, cũng như cách OfferUp đã hiện đại hóa nền tảng DevOps của mình bằng Amazon Elastic Kubernetes Service (Amazon EKS) và Flagger, tự động hóa việc triển khai sản phẩm với các kỹ thuật Progressive Delivery để tăng tốc thời gian đưa sản phẩm mới và dịch vụ ra thị trường. Amazon EKS là một dịch vụ quản lý container để chạy và mở rộng các ứng dụng Kubernetes trong môi trường đám mây hoặc on-premises.

Kiến trúc DevOps trước đây

OfferUp là một trang web và ứng dụng di động hàng đầu trong lĩnh vực thương mại điện tử người dùng đến người dùng (C2C), nơi người dùng có thể mua và bán hàng trên nền tảng. Người dùng có thể duyệt và mua sản phẩm từ nhiều loại danh mục khác nhau, bao gồm nội thất, quần áo, thiết bị thể thao, đồ chơi và nhiều loại khác. Là một công ty ưu tiên cho ứng dụng di động, OfferUp đặt nhiều sự chú ý vào việc giao tiếp trực tiếp giữa người mua và người bán.

OfferUp đã xây dựng một nền tảng DevOps tự phát triển và tự quản lý. Nền tảng này sử dụng một loạt quy trình thủ công và ứng dụng bên thứ ba cho phép cả các nhà phát triển và các kỹ sư vận hành xây dựng và triển khai mã vào môi trường sản xuất. Đường ống DevOps bao gồm các lĩnh vực chủ đề như kiểm soát mã nguồn, tích hợp liên tục/tuần tự triển khai (CI/CD), microservices, cũng như phương pháp phát triển và kiểm tra. Biểu đồ dưới đây mô tả kiến trúc trước đây của nền tảng DevOps của OfferUp, được tự quản lý trên Amazon Elastic Compute Cloud (Amazon EC2).

Hình 1: Kiến trúc DevOps trước đây của OfferUp

OfferUp đã sử dụng GitHub cho các kho lưu trữ mã nguồn. Khi mã nguồn đã được ghi lại trong kho lưu trữ mã nguồn, Jenkins đã kéo mã nguồn từ kho lưu trữ mã nguồn theo lịch trình hoặc theo yêu cầu và xây dựng hình ảnh Amazon Machine Images (AMI). Hình ảnh đã được xây dựng được triển khai trong môi trường sản xuất bằng một công cụ triển khai tự phát triển, Vanaheim, hỗ trợ triển khai canary và triển khai toàn bộ. Các kỹ sư DevOps đã phải tạo thủ công công việc triển khai trong cổng thông tin Vanaheim và sau đó theo dõi thủ công tỷ lệ thành công kiểm tra và các số liệu về dịch vụ để phát hiện bất kỳ ảnh hưởng nào từ việc triển khai. Khi tỷ lệ thành công đạt được, một triển khai sản xuất đầy đủ được thực hiện từ cổng thông tin Vanaheim.

Những thách thức quan trọng với đường ống DevOps trước đó

Vào năm 2020, OfferUp đã trải qua sự tăng trưởng đáng kể về lưu lượng giao dịch trên nền tảng Marketplace của họ với sự gia tăng của cơ sở người dùng. Khi OfferUp mua lại LetGo vào năm 2020, đã có nhu cầu xây dựng một nền tảng DevOps có khả năng mở rộng để hỗ trợ tích hợp và sự phát triển tự nhiên trong tương lai. Nền tảng DevOps trước đó, được thiết kế và triển khai hơn bảy năm trước, đã đạt đến giới hạn về khả năng mở rộng của nó và không còn đáp ứng được với sự phát triển của nền tảng. Kiến trúc trước đó đắt đỏ để vận hành và có cơ sở hạ tầng phức tạp làm cho việc nâng cấp và thêm tính năng mới trở nên khó khăn.

Các yếu tố quan trọng sau đây đã thúc đẩy sự đẩy mạnh cho việc hiện đại hóa:

• Yêu cầu xác minh thủ công để kiểm tra xem mã đã được triển khai đúng cách trên một trong các máy chủ trong môi trường sản xuất, và nếu việc triển khai đúng ở một máy chủ, thì nó được triển khai trên các máy chủ sản xuất khác. Việc triển khai hoàn toàn lên sản xuất không được tự động hóa do thất bại thường xuyên đòi hỏi phải quay lại thủ công.

• Nền tảng trước đây đòi hỏi thời gian triển khai lâu hơn (1-2 giờ) do quy trình batch uy quyền, điều này đôi khi gây trì hoãn trong việc phát hành và kiểm tra các tính năng mới.

• Tính tự quản lý của các cụm Jenkins và Vanaheim đã tiêu thụ quá nhiều thời gian của các kỹ sư. Hầu hết kiến thức cơ địa về nền tảng kế thừa này đã mất đi qua nhiều năm và nó không phù hợp với triết lý của OfferUp về các nhóm kỹ sư DevOps nhỏ. Sự đổi mới đã trì trệ một phần do sự khó khăn của việc nâng cấp nền tảng DevOps và phát hành các tính năng mới cùng một lúc.

Tự động hóa nền tảng DevOps với Flagger và Gloo Ingress Controller trên Amazon EKS

Một yêu cầu quan trọng cho hệ thống thế hệ tiếp theo là kiến trúc mới sẽ giảm gánh nặng vận hành đối với các nhóm kỹ thuật, chu kỳ triển khai và tổng chi phí sở hữu. OfferUp đã đánh giá nhiều nền tảng quản lý container cho Nền tảng DevOps của họ. Cuối cùng, họ đã chọn Amazon EKS cho tính sẵn sàng cao, giảm thời gian trung bình để triển khai thay đổi đến môi trường từ vài giờ xuống chỉ vài phút và giảm độ phức tạp trong việc quản lý và nâng cấp cụm Kubernetes. Trên nền tảng Amazon EKS, OfferUp sử dụng Flagger, một công cụ Progressive Delivery tự động hóa quy trình phát hành cho các ứng dụng chạy trên Kubernetes. Flagger thực hiện một số chiến lược triển khai (Canary releases, A/B testing và Blue/Green mirroring) bằng cách sử dụng Gloo Edge ingress controller để định tuyến lưu lượng. Datadog được sử dụng làm dịch vụ quan sát để theo dõi sức khỏe của các triển khai và quản lý canary sang Progressive Delivery một cách hiệu quả. Đối với phân tích phát hành, Flagger chạy truy vấn trên nhật ký Datadog và sử dụng Slack để thông báo và thông báo. Các thành phần công nghệ cloud-native của kiến trúc được mô tả như sau:

Kubernetes và Amazon EKS – Kubernetes là một hệ thống mã nguồn mở để tự động hóa việc triển khai, mở rộng và quản lý các ứng dụng được container hóa. Kubernetes là một dự án tốt nghiệp tại CNCF. Amazon EKS là một dịch vụ Kubernetes được quản lý hoàn toàn, tuân theo tiêu chuẩn Kubernetes và giúp đơn giản hóa quá trình xây dựng, bảo mật, vận hành và duy trì các cụm Kubernetes trên AWS. Amazon EKS tích hợp với các dịch vụ cốt lõi của AWS, chẳng hạn như Amazon CloudWatch, Auto Scaling Groups và AWS Identity and Access Management (IAM), để cung cấp trải nghiệm mượt mà cho việc theo dõi, mở rộng và cân bằng tải ứng dụng được container hóa của bạn.

Helm – Helm quản lý các ứng dụng Kubernetes. Helm Charts xác định, cài đặt và nâng cấp ngay cả ứng dụng Kubernetes phức tạp nhất. Charts dễ tạo ra, phiên bản hóa, chia sẻ và xuất bản. Nếu Kubernetes là một hệ điều hành, thì Helm sẽ là trình quản lý gói. Helm là một dự án tốt nghiệp tại CNCF và được duy trì bởi cộng đồng Helm.

Flagger – Flagger là một công cụ progressive delivery tự động hóa quy trình phát hành cho các ứng dụng chạy trên Kubernetes. Flagger thực hiện một vòng lặp kiểm soát mà dần dần chuyển hướng lưu lượng sang Canary trong khi đo lường các chỉ số hiệu suất quan trọng như tỷ lệ thành công của yêu cầu HTTP, thời gian trung bình của yêu cầu và tình trạng của các pod. Dựa trên các ngưỡng được thiết lập, Canary sẽ được thúc đẩy lên hoặc bị hủy bỏ và phân tích của nó được đẩy lên một kênh Slack. Flagger đã trở thành một dự án tại CNCF – một phần của họ các công cụ GitOps thuộc gia đình Flux.

Gloo Edge – Gloo Edge là một bộ điều khiển Kubernetes-native có đầy đủ tính năng. Gloo Edge xuất sắc ở chức năng định tuyến cấp độ hàm; khả năng hỗ trợ ứng dụng cổ điển, microservices và serverless; khả năng khám phá; và tích hợp chặt chẽ với các dự án mã nguồn mở hàng đầu. Gloo Edge được thiết kế đặc biệt để hỗ trợ các ứng dụng kết hợp, trong đó nhiều công nghệ, kiến trúc, giao thức và đám mây có thể cùng tồn tại.

Nền tảng quan sát – Các tích hợp của Datadog với Kubernetes, Docker và AWS sẽ cho phép bạn theo dõi toàn bộ dải các số liệu về Amazon EKS, cũng như nhật ký và dữ liệu hiệu suất từ cụm và ứng dụng của bạn. Datadog cung cấp cho bạn sự bao phủ toàn diện về cơ sở hạ tầng động và ứng dụng của bạn với các tính năng như tự động khám phá để theo dõi dịch vụ trên các container, đồ họa phức tạp và tùy chọn cảnh báo.

Kiến trúc DevOps hiện đại

Trong kiến trúc mới, OfferUp sử dụng Github làm công cụ quản lý phiên bản và Github actions làm công cụ CI/CD của họ. Trên mỗi Pull request, các bài kiểm tra được thực hiện, các artifact được xây dựng và lưu trữ trong JFrog Artifactory, và các hình ảnh Docker được lưu trữ trong Amazon Elastic Container Registry (Amazon ECR). Các đường ống triển khai riêng biệt được kích hoạt dựa trên môi trường (dev, staging và production) được chọn. Flagger phát hiện bất kỳ thay đổi nào trong phiên bản của ứng dụng và dần dần chuyển hướng lưu lượng sản xuất sang Canary. Nó đo lường tỷ lệ thành công của yêu cầu và các chỉ số thời gian phản hồi trung bình từ Datadog để quyết định triển khai đầy đủ trong sản xuất. Đối với một việc triển khai ứng dụng, có thể định nghĩa việc thúc đẩy Canary bằng cách sử dụng tài nguyên tùy chỉnh của Flagger. Flagger quay trở lại quá trình triển khai khi tỷ lệ thành công thấp hơn các chỉ số tỷ lệ thành công mong muốn được xác định.

Hình 2: Kiến trúc DevOps hiện đại của OfferUp

Với nền tảng DevOps hiện đại, OfferUp đã chuyển từ kiến trúc monolithic sang kiến trúc microservices, trong đó các ứng dụng front-end và GraphQL chạy trên cụm Amazon EKS. Cụm sản xuất chạy 110 dịch vụ và hơn 650 pod trên 60 node. Cụm có khả năng mở rộng lên đến 100 node với nhóm tự động scaling dựa trên mô hình lưu lượng. Về phần mạng, cụm có một điểm cuối riêng và sử dụng cả plugin VPC CNI và tiện ích mở rộng CoreDNS. Có bốn cụm Amazon EKS, mỗi cụm dành cho môi trường sản xuất, thử nghiệm, tiện ích và staging. OfferUp có kế hoạch khám phá dự án tự động scaling mã nguồn mở Karpenter, và nó sẽ di chuyển các ứng dụng mới đến cụm Amazon EKS, cho phép tổng số lượng node tăng lên đến 200.

Lợi ích của kiến trúc hiện đại

Kiến trúc mới đã giúp OfferUp đưa ra các quyết định tự động để triển khai phiên bản mới và cải thiện thời gian đưa sản phẩm ra thị trường trong khi giảm thiểu thời gian ngừng sản xuất không kế hoạch.

• Triển khai nhanh hơn và Rollback nhanh chóng – Kiến trúc mới giảm thời gian Triển khai Dịch vụ từ một giờ xuống còn năm phút và tự động hóa thời gian Rollback xuống còn năm phút từ thời gian Rollback thủ công là một giờ.
• Tự động hóa việc triển khai phiên bản mới – Việc thiếu quy trình triển khai Canary trong kiến trúc trước đây đòi hỏi các kỹ sư của OfferUp phải can thiệp thủ công để xác minh tình trạng triển khai, điều này dẫn đến thêm công việc quản trị và sự cố sản xuất. Các triển khai Canary quản lý việc chuyển đổi lưu lượng một cách tự động bằng cách tự đo lường tỷ lệ thành công của các yêu cầu và các chỉ số thời gian trễ từ Datadog và sau đó phát hành dịch vụ ra sản xuất. Triển khai tự động được quay trở lại khi tỷ lệ thành công thấp hơn ngưỡng chỉ số thành công được xác định.
• Đơn giản hóa Cấu hình – Cấu hình đã được đơn giản hóa một cách đáng kể và tích hợp trong đường ống CI/CD trong kiến trúc mới, từ đó giảm thiểu phức tạp về cấu hình, loại bỏ các quy trình thủ công và tiết kiệm thời gian của các nhà phát triển.
• Nhiều thời gian để Tập trung vào Đổi mới – Với việc triển khai tiến bộ hoàn toàn tự động, các nhà phát triển không còn phải dành thời gian để kiểm tra và phát hành mã nguồn trong sản xuất nữa. Tương tự, việc di chuyển từ một nền tảng DevOps tự quản lý sang các dịch vụ Managed Amazon EKS giảm đi gánh nặng quản lý cơ sở hạ tầng của nền tảng DevOps lên đội ngũ kỹ thuật. Điều này giúp các nhà phát triển dành thời gian nhiều hơn để tập trung vào việc xây dựng và kiểm tra tính năng và đổi mới mới.
• Giảm chi phí – Việc di chuyển từ kiến trúc dựa trên Amazon EC2 tự quản lý sang cụm Amazon EKS giúp giảm chi phí vận hành thông qua việc sử dụng các node được chia sẻ và cải thiện mật độ pod. Kiến trúc trước đây sử dụng 200 node của các phiên bản Amazon EC2. Cùng khối lượng công việc đó đã được chuyển sang cụm Amazon EKS với 50 node. Hơn nữa, các ứng dụng tùy chỉnh (Vanaheim và Jenkins) đã được loại bỏ, giúp giảm thiểu chi phí thêm nữa.

Kết luận

Trong bài viết này, bạn thấy được cách OfferUp đã bắt đầu hành trình để hiện đại hóa nền tảng DevOps của họ để hỗ trợ sự phát triển và tốc độ phát triển của các nhà phát triển. Các yếu tố quan trọng đã thúc đẩy quyết định hiện đại hóa là khả năng mở rộng nền tảng để hỗ trợ kiểm tra tự động các tính năng trong sản xuất, việc phát hành nhanh chóng các tính năng mới, giảm chi phí và để tạo điều kiện cho sự đổi mới trong tương lai. Nền tảng DevOps hiện đại trên Amazon EKS cũng giảm bớt gánh nặng hỗ trợ hoạt động liên tục cho các kỹ sư, và tính mở rộng của thiết kế mở ra nhiều cơ hội cho sự phát triển.

Chúng tôi khuyến nghị bạn nghiên cứu cách hiện đại hóa đường ống CI/CD hiện có của bạn trên Amazon EKS với cơ chế triển khai tiến bộ của Flagger. Amazon EKS loại bỏ công việc nặng nề không khác biệt của việc quản lý và cập nhật cụm Kubernetes. Các nhóm node quản lý tự động việc cung cấp và quản lý vòng đời của các worker node trong một cụm Amazon EKS, điều này giúp đơn giản hóa các hoạt động vận hành, chẳng hạn như triển khai các phiên bản Kubernetes mới.

Trong phần tiếp theo của loạt bài này, bạn sẽ khám phá cách triển khai Flagger và Gloo Edge Ingress Controller trên Amazon EKS để tự động hóa quy trình phát hành cho các ứng dụng chạy trên Kubernetes.