XFaaS: nền tảng serverless của Meta xử lý hàng nghìn tỷ lượt gọi mỗi ngày

• Nền tảng FaaS được Meta sử dụng nội bộ
• Xử lý hàng nghìn tỷ lượt gọi hàm mỗi ngày trên hơn 100.000 máy chủ phân tán khắp hàng chục region trung tâm dữ liệu
• Được cho là hiệu quả hơn AWS Lambda và Azure Functions, và đã được công bố qua bài báo "XFaaS: Hyperscale and Low Cost Serverless Functions"

Những thống kê và hàm ý đáng chú ý

• Điểm cốt lõi của bài báo là hiệu năng serverless có thể được cải thiện bằng cách tối ưu hóa việc sử dụng phần cứng thông qua phần mềm
• Meta nhận ra sự lãng phí do startup overhead của Serverless Functions, và đặt mục tiêu mô phỏng một Universal Worker có thể thực thi ngay mọi chức năng mà không có độ trễ khởi động trên mọi worker
  • Ở quy mô này, chi phí phần cứng là cực lớn nên ngay cả một tỷ lệ cải thiện rất nhỏ cũng quan trọng
• XFaaS chỉ được dùng cho các chức năng không đối diện người dùng. Hàm serverless có độ trễ biến thiên quá lớn để có thể dùng nhất quán cho các chức năng đối diện người dùng
• Client của XFaaS thực hiện gọi hàm theo kiểu tăng vọt rất đột ngột. Nhu cầu đỉnh cao cao hơn 4,3 lần so với ngoài giờ cao điểm
  • Có trường hợp 20 triệu lượt gọi hàm được gửi tới XFaaS trong vòng chưa đầy 15 phút
  • Meta phát hiện rằng ngay cả các đợt tăng vọt của hàm cũng có mẫu hình, và đã tận dụng điều đó để làm cho các hàm tăng đột biến trong workload trở nên dễ dự đoán hơn

XFaaS hiệu quả đến mức nào?

• Đạt mức sử dụng CPU trung bình hằng ngày 66%, cao hơn rất nhiều so với mức trung bình của ngành
• Phân tán tải hiệu quả bằng cách dùng thời gian (thông qua độ trễ của hàm) và không gian (bằng cách chuyển sang các trung tâm dữ liệu ít tải hơn)

  Meta đang tiếp tục chuyển nhiều chức năng sang được lên lịch vào các khung giờ ít sử dụng hơn — nơi có thể dự đoán được tải và chi phí

• Vì là cloud nội bộ, Meta có thể thực hiện nhiều tối ưu hóa riêng, chẳng hạn chạy nhiều chức năng của nhiều người dùng trong cùng một process
• Phần lớn các hàm chạy trong dưới 1 giây, nhưng không phải tất cả đều như vậy

Những vấn đề được giải quyết bằng XFaaS

• Vấn đề: thời gian cold start dài
  • Nếu container bị kết thúc quá sớm thì phải khởi tạo lại toàn bộ container cho lần gọi tiếp theo
  • Nếu container bị kết thúc quá muộn thì nó sẽ ở trạng thái nhàn rỗi và lãng phí tài nguyên tính toán quý giá
  • Giải pháp: XFaaS xấp xỉ điều này bằng cách dùng các phương pháp như JIT compilation để mọi worker có thể thực thi ngay mọi hàm
• Vấn đề: cân bằng tải khó khăn
  • Over-provisioning làm phát sinh thêm chi phí phần cứng, còn thiếu cấp phát thì hệ thống bị chậm lại
  • Giải pháp: XFaaS trì hoãn thực thi các hàm chịu được độ trễ tới những thời điểm ít sử dụng hơn và phân tán các lời gọi hàm tới các region trung tâm dữ liệu trên toàn cầu
• Vấn đề: các dịch vụ downstream bị quá tải
  • Ví dụ: đã từng có trường hợp các lời gọi tăng vọt của hàm không đối diện người dùng làm gián đoạn các dịch vụ online đối diện người dùng
  • Giải pháp: XFaaS điều tiết việc thực thi hàm bằng một cơ chế tương tự kiểm soát tắc nghẽn TCP

So sánh với FaaS thông thường (AWS Lambda, Google Cloud Functions, Azure Functions)

• FaaS trên public cloud giới hạn việc thực thi hàm trong một region trung tâm dữ liệu duy nhất, trong khi XFaaS có thể phân tán lời gọi hàm trên toàn cầu để cải thiện load balancing
• Các nền tảng FaaS thường ưu tiên giảm độ trễ mà bỏ qua mức sử dụng phần cứng. XFaaS tập trung vào mức sử dụng phần cứng và throughput của lời gọi hàm
• Các kỹ thuật của XFaaS có thể hữu ích cho public cloud
  • Cho phép caller chỉ định thời điểm bắt đầu thực thi hàm
  • Cho phép chủ sở hữu hàm đặt service-level objective (SLO) về thời hạn hoàn thành (SLO thấp hơn có thể cho phép trì hoãn để đạt runtime tốt hơn)
  • Cho phép chủ sở hữu hàm chỉ định mức độ quan trọng cho hàm
• Public cloud không thể chạy chức năng của nhiều người dùng trong cùng một process như XFaaS, nhưng các khách hàng cloud quy mô lớn có thể áp dụng cách tiếp cận XFaaS trong virtual private cloud
• Một số ít đội ngũ tại Meta tiêu thụ phần đáng kể dung lượng của XFaaS. Những khách hàng quy mô lớn tương tự trên public cloud cũng có thể hưởng lợi từ chiến lược XFaaS

Background: giả định và yêu cầu

• Giả định
  • Insight cốt lõi là phần lớn các chức năng XFaaS được kích hoạt bởi workflow tự động hóa và có thể chấp nhận độ trễ
  • Nhờ đó, XFaaS có thể phân tán tải theo thời gian (bằng cách trì hoãn chức năng) và theo không gian (bằng cách chuyển sang các trung tâm dữ liệu ít tải hơn)
  • XFaaS hỗ trợ runtime cho PHP, Python, Erlang, Haskell và runtime dựa trên container chung cho mọi ngôn ngữ
  • Hàm có nhiều thuộc tính mà nhà phát triển có thể thiết lập, như tên hàm, đối số, runtime, mức độ quan trọng, thời điểm bắt đầu thực thi, thời hạn hoàn thành, quota tài nguyên, giới hạn đồng thời, chính sách retry..., và thời hạn hoàn thành có thể đặt từ vài giây đến 24 giờ
  • XFaaS có dung lượng phần cứng khác nhau theo từng khu vực nên việc load balancing phải tính đến điều này
• Loại workload
  • Meta hỗ trợ ba loại workload trên XFaaS
    • Hàm kích hoạt theo hàng đợi
    • Hàm kích hoạt theo sự kiện (sự kiện thay đổi dữ liệu trong hệ thống data warehouse và data stream)
    • Hàm kích hoạt theo bộ hẹn giờ (tự động chạy theo thời điểm được cài đặt trước)
  • XFaaS được dùng cho các chức năng không đối diện người dùng như hệ thống gợi ý bất đồng bộ, logging, bot năng suất, thông báo, v.v.

Kiến trúc tổng thể

(Phần này quá dài và gần như bê nguyên nội dung bài báo nên xin lược bỏ.)