Cách Databricks tối ưu hóa cấu hình mạng cho hàng chục triệu máy chủ Serverless

Tóm tắt

Phát biểu vấn đề

Nền tảng tính toán serverless của Databricks vận hành hầu hết các sản phẩm dữ liệu và AI của chúng tôi, chẳng hạn như SQL warehouses, notebooks, ML serving endpoints, và nhiều sản phẩm khác. Nền tảng này khởi chạy hàng chục triệu máy ảo (VM) mỗi ngày trên AWS, Azure và GCP.

Trước khi bất kỳ khối lượng công việc serverless nào có thể thực thi, VM cần biết cấu hình mạng của nó: Nó có thể truy cập những đích lưu trữ nào? Có các private link endpoint nào mà nó cần định tuyến lưu lượng truy cập qua đó không? Có thay đổi gần đây nào trong Unity Catalog cấp quyền truy cập vào các đích lưu trữ mới không? Chúng ta có bắt đầu sử dụng các đích mới được chia sẻ qua Delta Sharing hay không?

Thách thức nằm ở chỗ cấu hình mạng không được lưu trữ tại bất kỳ nơi duy nhất nào. Nó phải được tổng hợp từ nhiều dịch vụ thượng nguồn (upstream services), mỗi dịch vụ đóng góp một phần vào bức tranh toàn cảnh.

Kiến trúc cũ

Trong thiết kế ban đầu, mỗi khi một cụm serverless khởi động, dịch vụ cấu hình mạng của chúng tôi sẽ đồng bộ gọi tất cả các dịch vụ thượng nguồn, tổng hợp phản hồi của chúng, tính toán cấu hình mạng cho từng workspace và trả về cho dataplane serverless. Quá trình này nằm trên đường dẫn quan trọng (critical path) của việc tạo cụm.

Mặc dù kiến trúc cũ đơn giản và hoạt động tốt ở quy mô nhỏ, nhưng nó lại gặp phải những vấn đề cơ bản, được phản ánh qua các chỉ số mà chúng tôi theo dõi trên bảng điều khiển vận hành:

Khi việc sử dụng serverless tiếp tục tăng trưởng nhanh chóng, mô hình đồng bộ ngày càng trở nên không bền vững. Mỗi lệnh gọi đồng bộ đều kích hoạt các thao tác tốn kém trên tất cả các workspace, thường dẫn đến việc tính toán trùng lặp. Điều này tạo thêm tải trọng tăng tỷ lệ thuận với số lượng khách hàng (tenants) và các tài nguyên được cấu hình của họ.

Giải pháp: Tính toán trước dựa trên sự kiện (Event Driven Precomputation)

Chúng tôi đã thực hiện tái cấu trúc toàn diện cách Databricks cung cấp cấu hình mạng. Giải pháp này được xây dựng dựa trên các nguyên tắc cốt lõi:

Kiến trúc phân tách rõ ràng hai đường dẫn. Đường dẫn quản lý chạy không đồng bộ trong nền: các dịch vụ thượng nguồn phát ra các sự kiện thay đổi vào một hàng đợi thông báo, nơi một bộ xử lý sự kiện sẽ tiêu thụ để xác định những workspace nào bị ảnh hưởng và phân tán thông báo cập nhật cho từng workspace. Sau đó, một trình quản lý sự kiện cục bộ sẽ tìm nạp các chi tiết liên quan từ thượng nguồn, tính toán lại cấu hình mạng của workspace và lưu trữ kết quả vào một kho lưu trữ snapshot đã được tính toán trước. Một trình đối soát định kỳ cũng đồng bộ lại tất cả các workspace trong nền, đảm bảo tính nhất quán cuối cùng ngay cả khi các sự kiện bị bỏ lỡ. Ngược lại, đường dẫn phục vụ là quan trọng và nhanh chóng: khi một cụm serverless khởi động và cần cấu hình mạng, dịch vụ cấu hình mạng sẽ phục vụ trực tiếp từ kho lưu trữ snapshot chỉ với một lần đọc lưu trữ, không yêu cầu bất kỳ lệnh gọi dịch vụ thượng nguồn nào và giảm đáng kể tải trọng lên các dịch vụ thượng nguồn.

Các quyết định thiết kế chính

Cách các sự kiện luân chuyển

Khi khách hàng tạo một kết nối Unity Catalog mới, Unity Catalog sẽ phát ra một sự kiện thay đổi vào hàng đợi thông báo. Bộ xử lý sự kiện sau đó nhận sự kiện, xác định những workspace nào được gắn với metastore bị ảnh hưởng và phân tán thông báo cập nhật cho từng workspace. Trong phân vùng của mỗi workspace, trình quản lý sự kiện nhận thông báo này, tìm nạp các chi tiết kết nối đã cập nhật, tính toán lại cấu hình mạng của workspace và lưu trữ nó với một dấu phiên bản mới. Kể từ thời điểm đó, khi một cụm serverless yêu cầu cấu hình mạng, nó sẽ được phục vụ trực tiếp từ kho lưu trữ snapshot mà không cần bất kỳ lệnh gọi thượng nguồn nào.

Tác động

Sau khi triển khai kiến trúc mới, kết quả mang tính chuyển đổi trên tất cả các chỉ số vận hành:

Ngoài các chỉ số hàng đầu:

Kết luận

Dự án này đã dạy chúng tôi một vài bài học về việc vận hành cơ sở hạ tầng mạng ở quy mô đám mây:

Việc tính toán trước giúp tách biệt các đường dẫn quan trọng. Bằng cách chuyển các phép tổng hợp tốn kém sang nền, đường dẫn phục vụ trở nên đơn giản và nhanh chóng một cách tối đa. Đây là quyết định kiến trúc có tác động lớn nhất. Nó đã biến một chuỗi phụ thuộc đa dịch vụ thành một lần đọc lưu trữ duy nhất.

Kiến trúc hướng sự kiện đánh đổi tính nhất quán để lấy khả năng mở rộng và việc đối soát cung cấp lưới an toàn. Việc đẩy dữ liệu dựa trên sự kiện xử lý hiệu quả các trường hợp thông thường, trong khi trình đối soát định kỳ sẽ bắt kịp bất kỳ sai sót nào.

Thiết kế để có khả năng mở rộng ngay từ đầu. Kiến trúc mô-đun theo từng giai đoạn có nghĩa là việc thêm hỗ trợ cho một nguồn dữ liệu thượng nguồn mới chỉ yêu cầu triển khai một giai đoạn mới mà không cần thay đổi gì đối với đường ống cốt lõi. Khi bề mặt sản phẩm của Databricks mở rộng, hệ thống cấu hình mạng cũng mở rộng theo.

Ngày nay, hệ thống này phục vụ hàng tỷ yêu cầu cấu hình mạng mỗi ngày trên toàn bộ đội ngũ serverless toàn cầu của Databricks, với độ trễ khoảng 125ms và độ khả dụng 99,99%. Khi tính toán serverless tiếp tục tăng trưởng nhanh chóng, kiến trúc hướng sự kiện đảm bảo rằng việc cung cấp cấu hình mạng sẽ mở rộng song hành cùng nó.

Chúng tôi luôn tìm kiếm các kỹ sư yêu thích việc giải quyết các thách thức về hệ thống phân tán ở quy mô toàn cầu. Nếu những vấn đề như thế này khiến bạn hứng thú, chúng tôi rất mong nhận được phản hồi từ bạn, vui lòng xem các vị trí đang tuyển dụng tại databricks.com/careers!