Kiến trúc của các hệ thống dữ liệu serverless

• Tương lai của các dịch vụ dữ liệu đám mây là cấu trúc "quy mô lớn, đa tenant"
  • Lý do các dịch vụ SaaS hàng đầu như S3 có thể cung cấp sự đơn giản, độ tin cậy, độ bền, khả năng mở rộng và chi phí thấp là vì công nghệ của các dịch vụ này được thiết kế ở cấp độ kiến trúc để mang lại những đặc tính đó
  • Việc cung cấp dịch vụ cho khách hàng thông qua các pool tài nguyên quy mô lớn giúp đảm bảo hiệu quả và độ tin cậy nhờ quy mô

[Định nghĩa hệ thống serverless đa tenant (Serverless Multi Tenant)]

Định nghĩa của "Multi-Tenancy"

• Đa tenant là việc cùng đặt tải công việc trên phần cứng dùng chung để chia sẻ tài nguyên
• Xây dựng hệ thống trên đám mây có nghĩa là nhiều tenant được phục vụ trên các instance tính toán dùng chung (ví dụ: Amazon EC2 hoặc Google Compute) hoặc các dịch vụ PaaS dùng chung (ví dụ: lưu trữ đối tượng trên đám mây)
• Định nghĩa đa tenant là "cung cấp dịch vụ cho nhiều tenant trên các tài nguyên dùng chung (máy chủ ảo hóa, ổ đĩa và các dịch vụ building block PaaS, v.v.)"
• Có thể sử dụng nhiều mô hình chia sẻ tài nguyên khác nhau, và một số hệ thống kết hợp nhiều mô hình chia sẻ trên toàn bộ các thành phần
  • Quy trình dùng chung: cùng một tiến trình phần mềm phục vụ nhiều tenant. Cách ly dữ liệu và bảo mật là ở mức logic
  • Container: chạy node đơn tenant và đóng gói nhiều container trên mỗi host. Thường được thực hiện qua Kubernetes, nơi một node K8s cụ thể có thể lưu trữ pod của rất nhiều tenant
  • Ảo hóa: chạy node đơn tenant trong VM (ví dụ: QEMU) hoặc microVM (ví dụ: Firecracker) và đóng gói nhiều VM trên mỗi host. Kubernetes cũng có thể dùng cùng VM thông qua Kata Containers
• Cũng có phương pháp cô lập V8, nơi các tenant chia sẻ cùng một tiến trình V8 nhưng sử dụng trong các ngữ cảnh nhẹ riêng biệt, tuy nhiên tôi vẫn chưa thấy cách này trong các hệ thống dữ liệu

Định nghĩa serverless

• Khách hàng không chọn loại máy chủ hay chỉ định phần cứng một cách tường minh
• Các hệ thống này dựa vào một mức độ đàn hồi và khả năng di chuyển nhất định để xử lý nhu cầu của mọi workload mà không buộc khách hàng phải điều chỉnh kích thước phần cứng một cách tường minh
  • Tính đàn hồi: khả năng mở rộng/thu nhỏ dịch vụ theo nhu cầu của workload
  • Khả năng di chuyển: khả năng của dịch vụ trong việc di chuyển và cân bằng workload nội bộ để đáp ứng yêu cầu về hiệu năng và độ ổn định
• Mô hình serverless sử dụng hình thức tính phí theo mức sử dụng, điều ngày càng trở nên quan trọng với khách hàng
  • Nhiều khách hàng không muốn cam kết quy mô lớn từ trước mà chỉ muốn bị tính phí đúng theo phần đã dùng
  • Tính phí theo mức sử dụng có nhiều biến thể, khác nhau đáng kể tùy vào workload và cách triển khai hệ thống bên dưới
    • Trả theo mỗi (triệu) thao tác
    • Trả theo mức sử dụng CPU và bộ nhớ của workload
    • Trả theo mỗi GB lưu trữ
    • Trả theo các đơn vị hiệu năng/dung lượng ảo gắn với tài nguyên và tốc độ xử lý (ví dụ: RCU/WCU của DynamoDB)
    • Mô hình lai, trong đó khách hàng trả cho một phần dung lượng cơ bản và trả thêm cho phần sử dụng vượt mức ("trả mức nền, trả thêm cho đỉnh tải")

[Các thách thức chung]

Làm việc trong các ràng buộc do workload áp đặt

• Nhiều ràng buộc do workload của một hệ thống dữ liệu nhất định áp đặt là động lực quan trọng của kiến trúc nền tảng.
  • Yêu cầu về độ trễ/tính sẵn sàng
  • Yêu cầu về tính nhất quán
  • Tương quan/phụ thuộc giữa request và dữ liệu
  • Mẫu truy cập tuần tự và mẫu truy cập ngẫu nhiên
  • Mức độ đa dạng của công việc được thực hiện trên mỗi request
  • Kích thước dữ liệu
  • Giao thức hướng phiên so với hướng request, cơ chế push so với pull
  • Cường độ tính toán của công việc
• Các yêu cầu thoáng hơn về độ trễ và tính nhất quán mang lại nhiều tự do hơn cho kỹ sư
  • Một ví dụ điển hình là tận dụng lợi ích chi phí thấp và độ bền cao của lưu trữ đối tượng đám mây, vì trong các hệ thống độ trễ thấp sẽ có ràng buộc khi đưa vào các thành phần có độ trễ cao
  • Các hệ thống Eventually Consistent có thể tránh thế lưỡng nan này bằng cách ghi dữ liệu bất đồng bộ vào object storage mà không đưa nó vào hot path dữ liệu đồng bộ
  • Các hệ thống có độ trễ thấp và tính nhất quán mạnh thì không có "lá bài miễn trừ" này
• Khi các ràng buộc như độ trễ thấp kết hợp lại, tính cục bộ theo không gian và thời gian của workload có thể ảnh hưởng đến các lựa chọn kiến trúc
  • Ví dụ, với workload đặc trưng bởi quét tuần tự, nên giữ các dải dữ liệu liền kề ở cùng nhau để quét nhanh và hiệu quả trên đĩa
  • Chia nhỏ các dải này thành các dải con nhỏ hơn giúp quản lý hotspot, nhưng đây là hai vấn đề đối nghịch nên cần tìm điểm cân bằng giữa chúng
  • Các mẫu truy cập ngẫu nhiên gần như không có tương quan giữa các request riêng lẻ có thể tận dụng không gian địa chỉ phẳng, thứ có thể phân tán đều và mỏng trên nhiều máy chủ
• Các giao thức hướng phiên thiết lập kết nối lâu dài thường khó hơn so với các giao thức hướng request, nơi mỗi request độc lập với request trước đó
  • Kết nối lâu dài có thể cần connection pooling, và khi xảy ra các xáo trộn như rolling node hay cân bằng dữ liệu thì có thể gây ra tác động có thể nhìn thấy từ phía client
• Có những hệ thống là API lưu trữ đơn giản như object storage hay Kafka API, và cũng có những hệ thống đòi hỏi tính toán cao như cơ sở dữ liệu SQL
  • Điều này dẫn đến chủ đề về khả năng dự đoán và mức biến thiên của khối lượng công việc cần thiết để xử lý mỗi request
  • Một ví dụ cực đoan là API streaming dữ liệu như Kafka, nơi chỉ cần truy xuất đơn giản các khối bản ghi liên tiếp; còn ở đầu kia là SQL, nơi khối lượng công việc có thể khác biệt rất lớn giữa các truy vấn

Cô lập tenant

• Chia sẻ tài nguyên giúp tăng mức sử dụng phần cứng, nhưng có thể dẫn đến tranh chấp tài nguyên, nơi workload của một tenant ảnh hưởng đến tenant khác
• Trong hệ thống đa tenant, cần bảo đảm rằng tenant được phục vụ trên tài nguyên phần cứng dùng chung vẫn có cảm giác như đang được phục vụ trên dịch vụ chuyên dụng riêng của mình

Tách biệt lưu trữ và tính toán

• Việc tách biệt lưu trữ và tính toán là nguyên tắc thiết kế cốt lõi mà tất cả các hệ thống được khảo sát đều triển khai ở một mức độ nào đó
• Xu hướng phần cứng đang khiến việc tách biệt lưu trữ và tính toán ngày càng khả thi hơn, một phần vì mạng không còn tạo ra nút thắt cổ chai như trước
• Thông lượng mạng đang tăng lên, nhưng với việc lưu trữ đối tượng đám mây được ưu tiên, vẫn còn các thách thức mới do sự tách biệt này mang lại
  • Lưu trữ đối tượng đám mây vẫn có độ trễ tương đối cao, nhưng độ bền tốt và chi phí thấp
  • Tuy nhiên, có thể khó đưa nó vào các workload thường yêu cầu độ trễ thấp như cơ sở dữ liệu OLTP
  • Ngoài ra, mô hình kinh tế của lưu trữ đối tượng đám mây không thuận lợi cho các thiết kế phụ thuộc vào rất nhiều object nhỏ; dữ liệu cần được gom vào các object lớn hơn với ít request hơn, điều này lại khiến vòng đời của hệ thống độ trễ thấp càng phức tạp hơn
• Kỹ sư có thể đưa object storage vào các hệ thống độ trễ thấp, đồng thời xử lý vấn đề độ trễ của nó bằng cách đặt một write cache bền vững, chịu lỗi và một read cache dự đoán phía trước object storage chậm
  • Write cache bền vững này về cơ bản là một cụm máy chủ triển khai giao thức sao chép và ghi dữ liệu xuống block storage
    • Ở chế độ nền, cụm sẽ tải dữ liệu lên object storage theo cách bất đồng bộ, theo mẫu kinh tế là ghi một số ít file lớn
    • Write cache chịu lỗi hỗ trợ rất tốt cho các ghi có độ trễ thấp
  • Trong kiến trúc này, phần có thể trở thành vấn đề là read cache
    • Các workload tuần tự như event streaming thì đơn giản và rất hiệu quả
    • Miễn là Aggregate Prefetching theo kịp nhu cầu, các lần đọc sẽ luôn chạm vào read cache cục bộ
    • Cơ sở dữ liệu gặp bài toán khó hơn vì các mẫu truy cập ngẫu nhiên khó dự đoán, nhưng quét bảng vẫn có thể hưởng lợi từ đọc trước
• Việc triển khai write cache phân tán, chịu lỗi bằng giao thức sao chép không hề đơn giản, và trong môi trường đa AZ có thể phát sinh thêm chi phí như phí cross-AZ
  • Nhưng hiện tại không có lựa chọn thay thế nào cho các hệ thống độ trễ thấp muốn dùng object storage rẻ và bền làm kho dữ liệu nền tảng
  • Những hệ thống độ trễ thấp khác nên tránh hoàn toàn việc dùng object storage đám mây, và trên hết là ưu tiên độ trễ thấp có thể dự đoán được
  • Lưu trữ đám mây được dùng rộng rãi, nhưng không phải phổ quát do các đánh đổi về độ trễ.

Quản lý nhiệt

• Quản lý nhiệt là phân phối tải càng đều càng tốt trên nhiều node lưu trữ để tránh hotspot, thứ có thể gây ra các vấn đề hiệu năng nhìn thấy từ bên ngoài như tăng vọt độ trễ hoặc giảm số thao tác mỗi giây
• Có thể gọi đây là cân bằng tải, nhưng thuật ngữ load balancer thường được dùng cho các node stateless
• Trong các hệ thống stateful, hotspot có thể xuất hiện khi các object có nhu cầu cao bị gom vào một node lưu trữ cụ thể, gây tranh chấp
• Load balancer có thể phân phối đều tải trên một tập node stateless bằng các chiến lược đơn giản như ngẫu nhiên, ít kết nối nhất hoặc một số biến thể FIFO, nhưng hệ thống stateful phải định tuyến request đến node dựa trên vị trí dữ liệu
• Việc di chuyển dữ liệu để phân phối lại tải thường được gọi là rebalancing
• Một vấn đề phức tạp hơn là sự phân phối tải có thể thay đổi theo thời gian
  • Phân phối dữ liệu trở thành một quá trình động phải xử lý mọi thứ, từ các đỉnh tải ngắn hạn ảnh hưởng đến một tập con dữ liệu nhỏ cho tới các biến động tải lớn hơn do mẫu theo ngày hoặc các sự kiện theo mùa xuất hiện trên nhiều tenant
• Các tập dữ liệu lớn như cơ sở dữ liệu quy mô lớn hoặc luồng sự kiện thông lượng cao cần được sharding để phân phối tải hiệu quả
  • Khi đó rebalancing sẽ là rebalancing các shard, và hệ thống cũng có thể tách hoặc gộp shard khi sự phân phối tải thay đổi
  • Tuy nhiên, có thể tồn tại các đánh đổi liên quan đến số lượng và kích thước shard, chẳng hạn như tính cục bộ dữ liệu
  • Một mặt, dữ liệu được đồng vị trí càng nhiều thì truy xuất càng hiệu quả
  • Mặt khác, chi phí của tác vụ tính toán phải lấy dữ liệu từ quá nhiều shard có thể lớn hơn lợi ích đạt được từ việc phân tán tải lên nhiều máy chủ hơn
• Quản lý nhiệt cũng có thể cần trong các hệ thống đơn tenant, nên đây không chỉ là vấn đề của đa tenant
  • Tuy nhiên, trong các hệ thống dữ liệu MT, quản lý nhiệt còn quan trọng hơn để đảm bảo tenant không gặp biến động về chất lượng dịch vụ

Đạt mức sử dụng tài nguyên cao

• Một trong những động lực chính của việc triển khai kiến trúc serverless đa tenant là cung cấp hiệu quả kinh tế tốt hơn bằng cách sử dụng phần cứng nền tảng hiệu quả hơn
• Tăng mức sử dụng tài nguyên thông qua pooling tài nguyên là điều tối quan trọng, nhưng đạt được điều đó đồng thời vẫn đảm bảo cô lập tenant và hiệu năng có thể dự đoán là một thách thức khó

Cold start

• Các hệ thống serverless có thể thu hẹp tài nguyên về 0 theo từng tenant có thể phải đối mặt với vấn đề cold start khi tenant khôi phục workload
• Cold start ngay từ đầu đã là trọng tâm của serverless function, và cũng có thể ảnh hưởng đến một số hệ thống dữ liệu serverless
• Một số hệ thống hoàn toàn không có cold start, trong khi ở các hệ thống khác, cold start gần như là điều không thể tránh khỏi do kiến trúc và cách cung cấp sản phẩm scale-to-zero
• Trong mọi trường hợp tôi từng thấy, vấn đề cold start là một quyết định sản phẩm, và mức độ thu hẹp tài nguyên có thể khác nhau tùy vào gói dịch vụ và mô hình định giá
• Cuối cùng, khách hàng và nhà cung cấp có thể chọn các đánh đổi phù hợp với nhu cầu riêng của mình

Các hệ thống đã khảo sát

• Nhóm 1 - Storage APIs (compute-light)
  • Amazon DynamoDB (chương 1)
  • Kora - engine Kafka serverless bên trong Confluent Cloud (chương 2)
  • Backblaze B2 (dự kiến)
• Nhóm 2 - Cơ sở dữ liệu SQL OLTP (compute-heavy)
  • Neon - PostgreSQL serverless (chương 3)
  • Kiến trúc đa tenant serverless của CockroachDB. (đang thực hiện)
  • Planetscale (dự kiến)
• Nhóm 3 - Cơ sở dữ liệu SQL OLAP và data warehouse (compute-heavy)
  • Google BigQuery (dự kiến)
  • ClickHouse Cloud (đang thực hiện).
• Công việc này sẽ còn tiếp tục, nhưng dự kiến sẽ có một bài đăng kiểu như 'kết luận' vào tháng 1/2 năm 2024