Uber vượt ra ngoài giới hạn số lõi CPU với giải pháp điều phối nhận biết hiệu năng dành cho các khối lượng công việc có trạng thái

Trang chủ InfoQ Tin tức Uber vượt qua giới hạn số lõi CPU với cơ chế lập lịch nhận biết hiệu năng cho các khối lượng công việc lưu trạng thái DevOps Uber vượt qua giới hạn số lõi CPU với cơ chế lập lịch nhận biết hiệu năng cho các khối lượng công việc lưu trạng thái Ngày 27/10/2026 3 phút đọc Tác giả Craig Risi Theo dõi chúng tôi trên YouTube 232 nghìn người theo dõi LinkedIn 26 nghìn người theo dõi Instagram Mới RSS 19 nghìn độc giả X 57,1 nghìn người theo dõi Facebook 21 nghìn lượt thích Bluesky Mới Nghe bài viết này - 0:00 Bản ghi âm đã sẵn sàng phát Trình duyệt không hỗ trợ phát âm thanh. 0:00 0:00 Chuẩn 1,25x 1,5x Thích Danh sách đọc Uber đã giới thiệu Đơn vị Điện toán Chuẩn hóa (Normalized Compute Units - NCU) nhằm nâng cao tính đồng nhất trong việc phân bổ CPU trên toàn bộ hệ thống máy chủ đa dạng của doanh nghiệp. Phương pháp này được triển khai trên nền tảng điều phối có trạng thái (stateful orchestration platform) Odin của Uber, tính đến sự khác biệt về hiệu năng bộ vi xử lý thay vì coi mọi nhân (core) CPU đều tương đương nhau. Odin hiện quản lý khoảng 5 triệu nhân CPU trên các trung tâm dữ liệu tại chỗ (on-premises) và các nền tảng điện toán đám mây công cộng, bao gồm nhiều thế hệ phần cứng x86 và bộ vi xử lý ARM. Uber nhận thấy hiệu năng đơn luồng giữa các nhân nhanh nhất và chậm nhất có thể chênh lệch gần hai lần. Do đó, cùng một khối lượng công việc có thể đòi hỏi số lượng nhân CPU vật lý rất khác nhau tùy thuộc vào vị trí vận hành. Thực trạng này dẫn đến hai rủi ro trái ngược nhau. Việc phân bổ tài nguyên dựa theo phần cứng chậm nhất có thể gây lãng phí công suất trên các máy chủ nhanh hơn, trong khi phân bổ theo mức sử dụng trung bình lại khiến các tác vụ bị thiếu hụt tài nguyên khi chuyển sang máy chủ chậm hơn. Đối với các tác vụ có trạng thái (stateful), vốn thường không thể điều hướng lưu lượng sang máy khác, rủi ro thứ hai có thể ảnh hưởng tiêu cực đến độ tin cậy của hệ thống. Giải pháp của Uber là tách biệt mức hiệu năng tính toán mà một khối lượng công việc yêu cầu khỏi số lượng nhân vật lý được sử dụng để đáp ứng yêu cầu đó. Odin gán cho mỗi loại máy chủ một hệ số hiệu năng, lấy thế hệ máy chủ cũ hơn làm mốc chuẩn 100. Các phần cứng mới hơn có thể có chỉ số cao hơn đáng kể; Uber cho biết hệ số này tiệm cận mức 190 đối với một số máy chủ nhất định. Các hệ số này ban đầu được xác định trong quá trình đánh giá chất lượng phần cứng, sau đó được tinh chỉnh bằng dữ liệu khối lượng công việc thực tế trong môi trường sản xuất. Mức độ sử dụng CPU được quy đổi thành các đơn vị chuẩn hóa thông qua các hệ số nêu trên. Từ đó, Odin có thể xác định dung lượng tính toán cụ thể mà một khối lượng công việc cần, đồng thời chuyển đổi yêu cầu đó thành số lượng nhân vật lý khác nhau tùy thuộc vào máy chủ lưu trữ. Do vậy, một tác vụ chạy trên phần cứng nhanh hơn có thể được cấp ít nhân hơn, trong khi chính tác vụ đó chạy trên phần cứng chậm hơn sẽ được nhận nhiều nhân hơn. Mục tiêu của phương pháp này không nhằm đồng nhất số lượng nhân, mà là tạo ra sự tương đồng về năng lực tính toán. Uber cũng ghi nhận các hệ số hiệu năng có sự khác biệt giữa các nền tảng công nghệ. Đơn cử, các phép đo đối với hệ thống Kafka cho thấy hiệu năng khác biệt đáng kể giữa ARM, phần cứng tại chỗ thế hệ cũ và các hệ thống x86 đời mới. Do đó, doanh nghiệp cập nhật các hệ số dựa trên dữ liệu đo lường thực tế thay vì chỉ phụ thuộc vào các công cụ đo kiểm chuẩn tổng hợp (synthetic benchmarks). Đối với các dịch vụ không trạng thái (stateless), sự chênh lệch giữa các máy chủ thường có thể được giải quyết thông qua cơ chế cân bằng tải. Lưu lượng truy cập có thể được chuyển hướng đến các máy chủ tải nhẹ hơn hoặc có tốc độ xử lý nhanh hơn. Tuy nhiên, các hệ thống có trạng thái lại không có được sự linh hoạt tương tự. Một yêu cầu có thể cần được gửi chính xác đến máy chủ chứa một phân mảnh (shard) hoặc một phần dữ liệu cụ thể. Việc chuyển hướng yêu cầu sang vị trí khác không thể giải quyết được vấn đề tài nguyên cốt lõi. Trong bài viết, Uber mô tả những khối lượng công việc mà nút điều phối chính (leader) tiêu thụ CPU gấp hơn mười lần so với các nút phụ thuộc (follower). Nếu nút chính này chuyển từ máy chủ nhanh sang máy chủ chậm hơn, mức tiêu thụ CPU có thể tăng mạnh, tiềm ẩn nguy cơ gây quá tải tài nguyên dù bản thân khối lượng công việc không thay đổi. Uber đã áp dụng phương pháp này trên khoảng 1,4 triệu nhân CPU thuộc các khối lượng công việc được co giãn tự động trên Odin. Đối với Kafka, tỷ lệ sử dụng CPU ban đầu chênh lệch khoảng 8 điểm phần trăm giữa các loại máy chủ, trong đó phần cứng chịu tải cao nhất hoạt động với công suất cao hơn khoảng 50% so với phần cứng chịu tải thấp nhất. Sau khi áp dụng phương thức phân bổ dựa trên hiệu năng, mức chênh lệch... Mức chênh lệch giảm xuống còn khoảng 3 điểm phần trăm, trong đó phần cứng có mức tải cao nhất chỉ cao hơn khoảng 10% so với phần cứng chậm nhất. Uber cũng giảm tổng mức phân bổ CPU cho Kafka khoảng 8%, với phần lớn mức cắt giảm diễn ra trên các phần cứng nhanh hơn, nơi việc tiết kiệm tài nguyên có khả năng mang lại giá trị cao hơn. Phương pháp này khác với cơ chế trừu tượng hóa CPU do Kubernetes sử dụng, vốn biểu thị các yêu cầu CPU dưới dạng core hoặc millicore. Kubernetes chủ định coi một đơn vị CPU là một lượng thời gian CPU tuyệt đối, không phụ thuộc vào quy mô của máy chủ vật lý bên dưới. Cơ chế trừu tượng hóa đó phát huy hiệu quả đối với các định nghĩa khối lượng công việc mang tính linh hoạt, song về bản chất không phản ánh được hiệu năng tương đối giữa các thế hệ bộ vi xử lý khác nhau. Mô hình NCU của Uber giải quyết một bài toán tương đối khác: giúp bản thân tài nguyên có khả năng tự nhận biết hiệu năng. Thay vì tập trung xác định số lượng khối lượng công việc có thể đáp ứng trên một máy chủ hoặc mức CPU mà một khối lượng công việc cần tiếp nhận, mô hình này xác định năng lực tính toán thực tế mà một định mức phân bổ CPU đại diện. Thông tin tác giả Craig Risi Xem thêmThu gọn Đánh giá bài viết này Mức độ ứng dụng Văn phong Đã liên hệ tác giả Nội dung này thuộc chủ đề DevOps Các chủ đề liên quan: DevOps AI, ML & Data Engineering