- "Up: Portable Microservices Ready for the Cloud"
- Uber có 4.500 kỹ sư cùng vô số hệ thống tự động triển khai 4.500 microservice không trạng thái hơn 4.000 lần mỗi tuần
- Các dịch vụ này được phát triển, triển khai và vận hành bởi hàng trăm nhóm riêng biệt làm việc độc lập trên khắp thế giới
- Các dịch vụ có quy mô, hình dạng và chức năng đa dạng; một số nhỏ và dùng cho công việc nội bộ, một số lớn và dùng cho các phép tính thời gian thực quy mô lớn
Lịch sử các dịch vụ không trạng thái của Uber
- Năm 2014, Uber có một monolith viết bằng Python lưu dữ liệu trong một cơ sở dữ liệu PostgreSQL duy nhất
- Khi phát triển, công ty tuyển thêm kỹ sư và chuyển sang kiến trúc microservice
- Khi số lượng dịch vụ tăng lên, Uber tạo ra công cụ tên là µDeploy để triển khai mã tập trung ở quy mô lớn
- Container hóa toàn bộ dịch vụ không trạng thái và trừu tượng hóa việc quản lý host cũng như placement
- Cho phép nhóm hạ tầng quản lý fleet host độc lập với các microservice theo đơn vị kinh doanh
- Tuy nhiên, việc quản lý và placement dịch vụ vẫn còn thủ công
- Hạ tầng của Uber tuân theo mô hình trong đó các nhóm Zone tạo thành Region
- Độ trễ giữa các Zone trong cùng một Region đủ thấp để giao tiếp đồng bộ giữa các dịch vụ trong cùng khu vực diễn ra hiệu quả
- Mỗi Zone có thể là một cụm máy do Uber sở hữu hoặc của nhà cung cấp public cloud, nhưng một Zone cụ thể luôn chỉ thuộc về một nhà cung cấp duy nhất
- Nhìn chung, mọi microservice đều phải có khả năng gọi các dịch vụ khác mà không gặp vấn đề về độ trễ miễn là chúng ở trong cùng một Region
- µDeploy không tập trung hóa việc placement địa lý của workload trong hệ thống vì kỹ sư vẫn phải quản lý placement vật lý ở cấp Availability Zone
- Nói cách khác, kỹ sư dịch vụ vẫn phải quyết định không chỉ có chạy dịch vụ trong Zone on-premise hay không mà còn chạy ở Zone cụ thể nào
- Trong khi vận hành trung tâm dữ liệu on-premise, Uber đối mặt với lead time kéo dài do thiếu chip và các vấn đề chuỗi cung ứng
- Ngày 13 tháng 2 năm 2023, Uber công bố hợp tác với Oracle và Google nhằm giảm mức độ phơi nhiễm trước các vấn đề chuỗi cung ứng và đa dạng hóa
- Với hàng nghìn kỹ sư Uber phát triển hàng trăm dịch vụ khác nhau phục vụ hoạt động kinh doanh, chiến lược này là bất khả thi nếu không có "một hệ thống có thể trừu tượng hóa hạ tầng nền tảng"
Chuẩn bị để chuyển Uber lên cloud
- Để di chuyển 4.500 dịch vụ không trạng thái lên cloud trong khi vẫn duy trì hoạt động kinh doanh cần một lượng điều phối và nỗ lực khổng lồ
- Ngay từ đầu đã rõ rằng công việc này rất dễ phát sinh lỗi và gần như không thể quản lý chỉ bằng nỗ lực điều phối thủ công
- Để duy trì và quản lý microservice không trạng thái ở quy mô lớn, Uber phải chuyển đổi dịch vụ để có thể được hệ thống triển khai tập trung quản lý tự động mà không cần con người can thiệp
- Vượt ra ngoài Stateless để hướng tới Portability
- Dựa trên mô hình Region và Zone, Uber đưa ra khái niệm "tính di chuyển được (Portability)"
- Tính di chuyển được là khả năng của một dịch vụ có thể chạy ở mọi Zone trong một Region và được nền tảng hạ tầng tự động chuyển sang Zone mới mà không cần con người can thiệp
- Điều này bao gồm cả việc di chuyển giữa các nhà cung cấp public cloud lẫn di chuyển vào/ra các Zone on-premise
- Một số dịch vụ vốn không có tính di chuyển được vì chúng phụ thuộc vào cấu hình Zone và mức ưu tiên đối với tài nguyên của Zone
- Để thực hiện di chuyển tự động lên cloud, Uber phải đảm bảo mọi dịch vụ đều có tính di chuyển được
Làm cho Uber trở nên Portable
- Trong suốt năm 2021 và 2022, Uber triển khai một chương trình trên toàn bộ bộ phận kỹ thuật để xác minh mọi dịch vụ đều có tính di chuyển được
- Trong nhiều trường hợp, chỉ cần kiểm tra mã để xem việc sử dụng hằng chuỗi và tên tệp trong code cũng có thể phát hiện vi phạm tính di chuyển được
- Với các trường hợp đơn giản, Uber viết các quy tắc linter để đánh dấu code có vẻ bị hardcode nhằm chạy ở một vị trí vật lý cụ thể
- Để kiểm tra xem dịch vụ có thực sự di chuyển được hay không, Uber cần thực sự chuyển dịch vụ qua nhiều Zone mà không có con người can thiệp
- Uber xây dựng một bộ công cụ kiểm thử cho phép chủ sở hữu dịch vụ khởi động lần di chuyển đầu tiên của dịch vụ
- Bộ công cụ này dựa trên các công cụ sẵn có cho rollout mã an toàn và tăng dần, nên chủ sở hữu dịch vụ có thể bất kỳ lúc nào hoàn tác deployment về Zone ban đầu và khắc phục khi phát hiện vấn đề
- Khi việc di chuyển hoàn tất thành công, dịch vụ đó sẽ được đánh dấu để tự động di chuyển về sau
- Trong vài năm tiếp theo, Uber lặp lại quy trình này cho mọi dịch vụ và cuối cùng hoàn thành toàn bộ
- Sau khi hoàn tất, Uber có thể thay đổi topology Zone mà không cần kỹ sư dịch vụ can thiệp
- Để bảo đảm dịch vụ vẫn duy trì tính di chuyển được theo thời gian, Uber liên tục di chuyển mọi dịch vụ giữa các Zone vài tuần một lần để thường xuyên kiểm thử khả năng di chuyển
- Nhờ vậy, các regression của dịch vụ có thể được phát hiện dễ dàng, và theo thời gian các kỹ sư cũng quen với việc không giả định placement ở một Zone cụ thể cho dịch vụ của mình
Up: Mặt phẳng điều khiển liên hợp đa đám mây, đa tenant
- Uber đặt ra các mục tiêu ban đầu cho hệ thống như sau
- Cung cấp một Single Point of Entry để kỹ sư tương tác với hệ thống hạ tầng
- Quản lý và áp dụng best practice cho các dịch vụ được triển khai trực tiếp trên hệ thống, qua đó mang lại mức độ an toàn cao trong quá trình rollout mã
- Tự động hóa placement dịch vụ theo Availability Zone; khi có Availability Zone mới, thay đổi placement sang Zone mới, nhìn chung bao gồm điều phối placement tập trung để hỗ trợ tính sẵn sàng cao của Uber
- Tự động hóa các lần di chuyển ở cấp hạ tầng vốn rườm rà để kỹ sư dịch vụ không cần tham gia vào quá trình migration
- Kiến trúc cấp cao
- Experience Layer:
- Triển khai nhiều cách khác nhau để kỹ sư tương tác với hệ thống
- Bao gồm UI, Continuous Delivery, các robot giữ cho hệ thống ở trạng thái tốt, v.v.
- Balancer liên tục di chuyển workload sang các cluster và Zone có mức sử dụng thấp
- Auto Scaler liên tục tối ưu phân bổ dung lượng cho từng workload
- Platform Layer:
- Triển khai các lớp trừu tượng mà Experience Layer dùng để tương tác với dịch vụ
- Bao gồm các lớp trừu tượng về dịch vụ và môi trường dịch vụ tạo thành mô hình khái niệm cho vận hành dịch vụ, cùng với chính API ở cấp dịch vụ
- Trong Platform Layer, các ràng buộc của dịch vụ được biểu diễn thành trạng thái mục tiêu ở cấp cao mô tả các thuộc tính mong muốn của placement dịch vụ thực tế
- Có thể bao gồm các ràng buộc về hiệu năng của máy chạy và tổng năng lực tính toán dành cho dịch vụ theo từng Region
- Federation Layer:
- Triển khai tích hợp với các cluster tính toán
- Tổ chức toàn bộ cluster theo chức năng và vị trí vật lý để hiện thực các lớp trừu tượng Region và Zone mà các tầng trên sử dụng
- Lấy trạng thái mục tiêu dịch vụ cấp cao từ nền tảng rồi chuyển đổi thành placement theo Zone và cluster; quá trình chuyển đổi này dựa trên các ràng buộc của trạng thái mục tiêu và trạng thái thực tế của cluster, bao gồm dung lượng hiện có và các cluster có thể đáp ứng ràng buộc phụ trợ
- Kết quả chuyển đổi này có thể thay đổi theo thời gian và sau đó placement ở Zone hay cluster khác có thể trở nên phù hợp hơn
- Mọi lần gọi từ Balancer và các thao tác khác được khởi phát từ Experience Layer cũng có thể khiến placement này được tính toán lại và thay đổi
- Để hệ thống luôn an toàn và dịch vụ duy trì trạng thái tốt, thành phần quản lý thay đổi triển khai luồng rollout thay đổi trạng thái toàn cục một cách tăng dần từng chút thông qua tích hợp với mọi hệ thống giám sát sức khỏe dịch vụ
- Quy trình rollout bao gồm canarying trên toàn hệ thống và giám sát tín hiệu sức khỏe; nếu phát hiện vấn đề, hệ thống sẽ nhanh chóng rollback dịch vụ về cấu hình và placement trước khi bắt đầu thay đổi
- Regions
- Region chứa các instance cluster thực tế
- Bao gồm các cluster Peloton và Kubernetes®
- Chúng nằm bên ngoài bản thân Up nhưng là đích của việc placement dung lượng thực tế và quản lý placement container trên các host vật lý
Tác động
- Uber bắt đầu xây dựng Up vào năm 2018, cung cấp nguyên mẫu hoạt động được vào đầu năm 2019 và chính thức ra mắt nền tảng vào giữa năm 2020
- Kể từ đó, hơn 4.000 dịch vụ trên mọi mảng kinh doanh của Uber đã được di chuyển từ nền tảng triển khai cũ sang Up
- Phần lớn quá trình migration này được tự động hóa, nhờ đó nhóm có thể tập trung vào các trường hợp sử dụng tiên tiến nhất và hỗ trợ migration cho các nhóm khác
- Trong giai đoạn này, độ ổn định của nền tảng được đặt làm ưu tiên cao nhất, giúp Uber vận hành hoạt động kinh doanh ổn định trong bối cảnh hàng triệu người dùng sử dụng hệ thống mỗi ngày
- Toàn bộ quá trình di chuyển khoảng 2.000.000 lõi tính toán sang nền tảng mới diễn ra trong khoảng 2 năm và hoàn tất thành công vào năm 2022
- Nhờ migration này, các nỗ lực auto scaling và tối ưu hiệu quả đã hoàn trả cho doanh nghiệp thêm hàng chục triệu USD dung lượng
- Uber cũng tiết kiệm được hàng chục nghìn giờ công kỹ thuật từng phải dùng cho cập nhật dịch vụ thủ công, thiết lập và lấp đầy Zone mới, cũng như học cách điều hướng môi trường hạ tầng phức tạp của công ty, qua đó giảm đáng kể chi phí tiền bạc
Việc cần làm tiếp theo
- Sau khi hoàn tất migration từ µDeploy sang Up, giờ đây nhóm có thể tập trung xây dựng các giải pháp có thể áp dụng cho toàn bộ dịch vụ theo cách tự động hóa, tập trung và xây dựng trải nghiệm người dùng xoay quanh các khả năng đó
- Cloud migration
- Uber đang chuyển một phần đáng kể fleet của mình lên cloud
- Nhờ tự động hóa quy mô lớn và lớp trừu tượng do Up cung cấp, các nhóm dịch vụ có thể tách xa đáng kể khỏi những chi tiết hạ tầng cần thiết cho quá trình chuyển đổi này
- Continuous Delivery tự động hóa
- Uber hướng tới tự động hóa hoàn toàn việc triển khai mã đến production bằng cách sử dụng pipeline tự động để chạy nhiều bước kiểm tra và test trước khi mã được triển khai lên production
- Một hạng mục đặc biệt mà nhóm dự định tập trung trong năm 2023 là giữ dịch vụ ở "trạng thái cập nhật", để mọi mã chạy trong production luôn được cập nhật với các bản vá bảo mật và cập nhật thư viện mới nhất
- An toàn triển khai (Safety)
- Dữ liệu hiện có cho thấy phần lớn sự cố quan sát được có liên quan đến thay đổi mã và cấu hình
- Uber muốn tự động hóa các khía cạnh thủ công trong vòng đời dịch vụ, như chạy test trước production hoặc thiết lập chính sách rollout tăng dần, nhằm giảm mạnh tỷ lệ lỗi thực sự đi tới production
- Nền tảng
- Khi tổ chức toàn bộ fleet dịch vụ không trạng thái của Uber dưới một nền tảng umbrella duy nhất, công ty có thể mô hình hóa rõ ràng hơn các phụ thuộc và tương tác giữa các sản phẩm nền tảng hạ tầng
- Điều này không chỉ giúp cung cấp một mô hình thống nhất trong code mà còn mang lại trải nghiệm người dùng được tích hợp hoàn toàn cho phần còn lại của tổ chức kỹ thuật
- Mục tiêu lớn tiếp theo của nhóm là có thể quan sát và vận hành toàn bộ hạ tầng từ một nơi
Kết luận
- Nỗ lực xây dựng nền tảng Up giờ đây đại diện cho một thay đổi văn hóa đáng kể, ở chỗ mọi dịch vụ không trạng thái đều được triển khai tăng dần bằng cùng một bộ best practice và tự động hóa
- Những công việc trước đây cần hàng tháng để thực hiện, như thay đổi chính sách rollout hoặc xây dựng tự động hóa cho rollout thư viện quy mô lớn, nay đã có thể thực hiện theo cách tập trung
- Uber kỳ vọng sẽ tiếp tục hợp tác với các bên liên quan của Up và các chủ sở hữu dịch vụ để hiện thực hóa tầm nhìn giúp kỹ sư Uber chỉ cần tập trung vào code mà không phải lo về hạ tầng
Chưa có bình luận nào.