Sản phẩm SaaS B2B nào sớm muộn cũng phải đối mặt với câu hỏi về tenancy, thường là vào cái ngày có một khách hàng lớn tiềm năng hỏi xem dữ liệu của họ có được lưu tách riêng khỏi các khách hàng khác không. Tôi đã chứng kiến cuộc thảo luận này ở hơn một công ty, và lần nào câu trả lời cũng quy về hai lựa chọn: cho mỗi khách hàng một instance riêng (single-tenant, multi-instance), hoặc cho tất cả chạy chung trên một instance (multi-tenant, single-instance). Không có lựa chọn nào là “đúng”. Mỗi cái chỉ gặp sự cố theo một kiểu khác nhau.
Thiết kế hạ tầng#
Single tenant, multi-instance#
Điểm hấp dẫn nhất ở đây là tính cô lập, và gần như mọi lợi ích khác đều xuất phát từ đó. Dữ liệu của mỗi khách hàng nằm trong một môi trường riêng, nên các đợt đánh giá bảo mật hay những buổi làm việc về compliance dễ thở hơn hẳn. Một lần deploy lỗi hay một workload quá nặng chỉ làm sập một khách hàng, chứ không kéo sập tất cả. Bạn có thể scale, tinh chỉnh và tùy biến từng instance một cách độc lập, và vì tài nguyên được cấp riêng nên hiệu năng của khách này không phụ thuộc vào việc tenant bên cạnh đang làm gì. Lịch bảo trì cũng có thể xếp theo từng khách hàng, nên thời gian downtime vừa ngắn vừa đúng chỗ. Và nếu định giá hợp lý, bạn có thể tính chi phí hạ tầng sát với mức sử dụng thực tế của từng tenant.
Cái giá phải trả là giờ bạn đang vận hành N bản sao của mọi thứ. Chi phí tài nguyên cộng dồn lại, cấu hình giữa các instance dần dần lệch nhau, và riêng việc giữ cho phiên bản lẫn dữ liệu đồng bộ trên cả dàn instance đã thành một dự án riêng. Chuyện scale, cô lập và quản lý chi phí vẫn cần được lên kế hoạch nghiêm túc. Các vấn đề không hề biến mất, chúng chỉ nhân lên.
Multi tenant, single instance#
Đây là lựa chọn mặc định cũng có lý do của nó: một lần deploy, một cơ sở dữ liệu cần backup, một phiên bản duy nhất trên production. Mô hình này tiết kiệm tài nguyên, vận hành đơn giản, và mọi khách hàng đều nhận bản cập nhật cũng như bản vá bảo mật cùng một lúc.
Những phần khó lại chính là mặt trái của việc dùng chung. Chỉ một tenant dùng nặng cũng có thể kéo hiệu năng của tất cả mọi người đi xuống. Khả năng tùy biến cho từng khách hàng thì bị hạn chế. Việc cô lập dữ liệu giờ nằm trong mã ứng dụng chứ không còn nằm ở tầng hạ tầng, nên chỉ một lỗi nhỏ cũng có thể dẫn tới rò rỉ dữ liệu giữa các tenant. Khi gặp bottleneck về scale thì mọi khách hàng cùng chịu ảnh hưởng, và việc bảo trì phải cẩn thận hơn, vì không còn kiểu sự cố “chỉ ảnh hưởng mỗi khách này” nữa.
Tìm hiểu thêm về giải pháp SaaS - Kiến trúc Multi-instance và Multi-tenant
Nếu chọn single-tenant thì bắt đầu từ đâu?#
Nếu bạn quyết định đi theo single-tenant, công cụ sẽ quyết định mọi thứ còn nằm trong tầm kiểm soát, hay trở thành một thảm họa diễn ra từ từ. Không ai quản lý thủ công nổi ba mươi môi trường cả.
Phần cốt lõi là container kết hợp với infrastructure as code. Docker đóng gói ứng dụng giống hệt nhau cho mọi tenant, Kubernetes lo việc deploy và scale cả đống instance đó, còn Terraform, Pulumi hay AWS CloudFormation cho phép bạn định nghĩa toàn bộ stack của một tenant bằng mã. Nhờ vậy, dựng thêm khách hàng thứ 31 chỉ tốn một pull request, chứ không phải mất trắng một cuối tuần. Nếu hệ thống của bạn thiên về VM, các công cụ quản lý cấu hình như Ansible, Chef hay Puppet cũng đóng vai trò tương tự. Ở mô hình này, một pipeline CI/CD vững chắc (Jenkins, GitLab CI/CD) còn quan trọng hơn bình thường, vì mỗi bản phát hành phải được rollout tới mọi instance mà không cần ai ngồi canh.
Ngoài những thứ đó ra thì tùy vào đặc thù sản phẩm của bạn. Serverless (AWS Lambda, Azure Functions) có thể loại bỏ hẳn tầng máy chủ cho một số workload. Các dịch vụ cơ sở dữ liệu managed như Amazon RDS hay Azure SQL Database giúp bạn khỏi phải tự tay quản trị từng cơ sở dữ liệu cho từng tenant. Giám sát bằng Prometheus, Grafana hay New Relic thì không còn là tùy chọn khi bạn đã có cả một dàn instance, vì bạn muốn biết instance nào đang trục trặc trước khi khách hàng gọi tới báo. Về định danh, một dịch vụ như Auth0 hay Okta sẽ lo phần quản lý người dùng và phân quyền truy cập, để bạn khỏi phải làm lại cho từng tenant. Dù bạn dùng ngôn ngữ nào thì chắc cũng có sẵn framework hay library hướng SaaS giúp bạn bớt được phần nào đống việc “đi dây” này, và cloud lớn nào (AWS, Azure, Google Cloud Platform) cũng sẵn lòng host hết cho bạn.
Đừng dùng hết cả danh sách này ngay từ ngày đầu. Hãy bắt đầu với container và IaC, bổ sung giám sát và IAM khi số tenant tăng dần, rồi để những khó khăn thực tế quyết định phần còn lại.