Ảo tưởng về serverless
- Serverless đã trở thành xu hướng cốt lõi của công nghệ đám mây.
- Mô hình này cho phép các nhà phát triển tập trung vào logic nghiệp vụ mà không phải gánh nặng quản lý máy chủ.
- Mô hình thanh toán: chỉ trả tiền theo mức sử dụng, trong khi chi phí vận hành gần như về 0.
- Trên thị trường đã xuất hiện nhiều cơ sở dữ liệu serverless, với những tên tuổi cũ như Elastic, Confluent, Pinecone đang dẫn đầu cùng các đối thủ mới như Neon, WarpStream, Upstash và Turbopuffer cạnh tranh nhau.
Vấn đề của các cơ sở dữ liệu serverless hiện tại
- Nhiều cơ sở dữ liệu serverless thực ra không phải là serverless thực sự.
- Phần lớn dịch vụ dựa trên kiến trúc cloud-native, một thiết kế đổi mới cho thời đại server pool.
- Chúng vận hành cụm máy chủ và, bằng phần mềm phức tạp và can thiệp của con người, dự đoán tải và quản lý dung lượng.
- Ảo tưởng này gây ra các vấn đề thực tế cho người dùng.
Tác động của kiến trúc kém hiệu quả
- Sự không khớp kiến trúc không chỉ là chi tiết kỹ thuật mà còn gây ra vấn đề thực tế cho người dùng.
- Người dùng phải trả chi phí cho máy chủ nhàn rỗi, vì cụm máy chủ luôn chạy cho nhiều mục đích khác nhau.
- Vấn đề mở rộng: việc thêm máy chủ mới vào cụm mất vài phút, nên không thể xử lý ngay lập tức mức tăng đột biến traffic.
- Giới hạn lựa chọn: vì cần quản lý hạ tầng cho từng khu vực cloud, nên người dùng bị giới hạn lựa chọn vùng dịch vụ.
Mô hình không bền vững
- Các cơ sở dữ liệu “serverless” dựa trên kiến trúc server pool không bền vững.
- Nhà cung cấp cần đầu tư đáng kể để vận hành cụm máy chủ, vì vậy giá có thể thay đổi.
- Người dùng nhẹ phải trả phí cao để hỗ trợ hệ thống, trong khi người dùng thành công sẽ đối mặt với việc tăng giá không mong đợi.
Nhu cầu kiến trúc serverless-native
- Vào giai đoạn đầu của điện toán đám mây, hầu hết cơ sở dữ liệu “cloud” đều là cơ sở dữ liệu di sản.
- Kiến trúc serverless-native giao toàn bộ quản lý hạ tầng cho nhà cung cấp cloud, sử dụng hàm không trạng thái và dịch vụ serverless thay vì cụm máy chủ.
- Cách tiếp cận này xem hạ tầng cloud như một siêu máy tính lớn duy nhất, cho phép mở rộng tức thì và mô hình trả tiền theo từng yêu cầu thực sự.
- Bài kiểm tra litmus: để kiểm tra một cơ sở dữ liệu có thực sự serverless-native hay không, cần xác minh có thể triển khai lên tài khoản cloud mà không cần provision Kubernetes cluster hay VM.
Giới thiệu LambdaDB
- LambdaDB là một công cụ tìm kiếm mới được xây dựng theo kiến trúc serverless-native.
- Hệ thống này vận hành như một tập hợp các chức năng và tài nguyên serverless, tách hoàn toàn logic cơ sở dữ liệu khỏi hạ tầng.
- Yêu cầu người dùng đi qua regional gateway và được định tuyến đến Control Functions (Hàm điều khiển) hoặc Data Functions (Hàm dữ liệu) tùy theo loại yêu cầu.
- Tính năng doanh nghiệp: LambdaDB cung cấp các chức năng như point-in-time recovery và zero-copy cloning, không đòi hỏi quản lý hạ tầng.
Hoạt động của LambdaDB
- Kiến trúc LambdaDB: mọi thành phần được xây dựng bằng các dịch vụ đám mây serverless.
- Gateway xác thực API key của yêu cầu người dùng và định tuyến yêu cầu sang hàm điều khiển hoặc hàm dữ liệu.
- Hàm điều khiển xử lý các tác vụ CRUD và yêu cầu quản lý dữ liệu, trong khi hàm dữ liệu thực hiện việc ghi và đọc dữ liệu thực tế.
- Đường ghi: Writer Function ghi lại yêu cầu, lưu vào bộ đệm ghi serverless bền vững rồi trả về phản hồi cho client.
Nghịch lý về hiệu quả chi phí
- LambdaDB giảm chi phí tính toán so với cơ sở dữ liệu server pool.
- Đơn giá của Lambda cao hơn EC2 instance, nhưng nhờ mức nhân bản cần thiết để đảm bảo tính sẵn sàng cao và chịu lỗi, tổng chi phí lại thấp hơn.
- Lãng phí dung lượng cố định: mức sử dụng tính toán trung bình của doanh nghiệp chỉ 10-20%, vì vậy điện toán serverless có thể tiết kiệm 50-90% chi phí.
Hiệu năng và khả năng mở rộng
- Hiệu năng và khả năng mở rộng: LambdaDB đã chứng minh hiệu năng qua thí nghiệm thêm hàng triệu vector với 960 chiều.
- Độ trễ ghi: với 10 upsert mỗi giây, độ trễ trung vị là 43ms và vẫn gần như giữ nguyên khi traffic tăng 100 lần.
- Độ trễ truy vấn: độ trễ truy vấn ổn định ở nhiều tải khác nhau, với phần trăm bách phân vị 99 nằm trong khoảng 172ms đến 210ms.
- Nỗ lực tối ưu hóa: liên tục tối ưu để cải thiện độ trễ của hàm truy vấn, đồng thời cơ sở hạ tầng serverless cũng đang được cải thiện.
Lợi ích mang lại cho khách hàng
- Tiết kiệm chi phí: LambdaDB rẻ hơn hơn 10 lần vì không có máy chủ nhàn rỗi.
- Mở rộng tức thì và gần như vô hạn: LambdaDB có thể mở rộng lên hàng nghìn hàm song song trong vài mili giây.
- Bắt đầu và mở rộng đơn giản: có thể xây dựng ứng dụng AI mạnh mẽ, khi mở rộng thì kiến trúc vẫn đơn giản và hiệu quả chi phí.
- Tính năng doanh nghiệp: cung cấp điểm khôi phục thời gian và zero-copy cloning, có thể dùng mà không tăng thêm phức tạp hay chi phí.
Kế hoạch tương lai và tầm nhìn
- LambdaDB đã và đang xử lý hàng trăm triệu yêu cầu mỗi ngày cho hàng trăm triệu tài liệu.
- Kế hoạch dài hạn: sẽ hỗ trợ các mô hình dữ liệu khác (dữ liệu quan hệ, stream, key-value, graph, v.v.).
5 bình luận
Ý tưởng hay, nhưng để giảm độ trễ truy vấn thì bắt buộc phải có trạng thái (
state). Khi so sánh với MySQL, PostgreSQL và các hệ quản trị khác, dường như độ trễ truy vấn gần như cao hơn khoảng 100 lần. Nó giống như việc ghi vào và đọc ra từ hệ thống tệp.Cảm ơn ý kiến đóng góp rất hay của bạn. Điểm bạn nêu về việc cần có state để giảm độ trễ đã chạm đúng vào trade-off cốt lõi của kiến trúc của chúng tôi.
Trước tiên, về độ trễ truy vấn, trong benchmark của chúng tôi p99 (99th percentile) vào khoảng 130–210ms. Có lẽ phần bạn nói về chênh lệch 100 lần là đang dựa trên trường hợp xấu nhất trong bài viết là "có thể mất vài giây khi cold start". Như bạn đã chỉ ra, phần này chắc chắn là một nhược điểm của kiến trúc chúng tôi, và như đã đề cập trong bài, trong môi trường production nó xảy ra ở mức dưới 0,01% (P99.99). Ngoài ra, hầu hết các truy vấn còn lại đều được thiết kế để sử dụng bộ nhớ và ổ đĩa cục bộ của từng Lambda làm cache nhằm duy trì hiệu năng ổn định.
Do đó, như bạn đã nói, kiến trúc này có thể không phù hợp cho các hệ thống giao dịch tài chính siêu thấp trễ, nơi mọi truy vấn đều phải đảm bảo dưới 10ms. Tuy nhiên, đối với phần lớn ứng dụng tìm kiếm và gợi ý dựa trên AI, mức độ trễ 100–200ms theo chuẩn P99 đã là hiệu năng rất tốt, và tôi cho rằng lợi thế giảm hơn 90% chi phí hạ tầng và gánh nặng vận hành là lớn hơn nhiều.
Một lần nữa, xin cảm ơn những ý kiến sâu sắc của bạn.
Như bạn nói, tôi nghĩ đây sẽ là một giải pháp có thể được sử dụng theo kiểu "serverless" thực sự trong các trường hợp cụ thể, thay vì một cơ sở dữ liệu dùng cho mọi mục đích.
Không ngờ sẽ có người trả lời bằng tiếng Hàn! (Mình đã viết hơi châm biếm quá...)
Ban đầu tôi cũng nghĩ đây là một ý tưởng đột phá. Thật ra, điểm yếu lớn nhất của các cơ sở dữ liệu serverless nằm ở chỗ vẫn có server thực chạy ẩn dưới bề mặt, nơi mà vấn đề này không hề rõ ràng. Vì vậy khi lưu lượng truy cập tăng đột ngột, có thể xảy ra tình trạng treo cho đến khi server đó được cấp phát (khoảng 5 phút). Vì thế các DB serverless của các nhà cung cấp cloud hiện có (như AWS, v.v.) rất khó dùng ở cấp độ production.
Tôi từng nghĩ 'thử xem sao?', nhưng lo ngại khi nghĩ rằng nếu phải tự triển khai lại các logic nhị phân cho các chức năng như index, sort đã có sẵn ở MySQL, PostgreSQL, thì việc xây dựng lại một dự án cơ sở dữ liệu mã nguồn mở đáng tin cậy trên Lambda sẽ khó đến mức nào.
Vì đây là sản phẩm các bạn đang tự làm, nên tôi mong chờ nó sẽ tiến bộ nhiều hơn nữa~!
Cảm ơn bạn đã chia sẻ ý kiến rất hay. Như bạn đã nói, đây không phù hợp cho trường hợp sử dụng RDB và có thể xem là phù hợp cho vị trí của công cụ tìm kiếm (Elasticsearch), vector DB (Pinecone). Nội bộ chúng tôi cũng đang tận dụng Lucene, đã được kiểm chứng trong thời gian dài, để hỗ trợ các chức năng như lập chỉ mục, sắp xếp, tổng hợp, v.v. Cảm ơn bạn :)