Kiến trúc SaaS multi-tenant: thiết kế để hệ thống trụ vững khi tăng trưởng

Kiến trúc SaaS multi-tenant là gì?

Kiến trúc SaaS multi-tenant là cách thiết kế một sản phẩm phần mềm phục vụ nhiều khách hàng (tenant) trên cùng một nền tảng vận hành, trong đó mỗi tenant được cô lập về dữ liệu và trải nghiệm dù có thể dùng chung hạ tầng. Câu hỏi cốt lõi không phải “chia sẻ hay không”, mà là chia sẻ thành phần nào, cô lập thành phần nào, và bằng cơ chế gì. Lựa chọn này ảnh hưởng trực tiếp đến chi phí, bảo mật, hiệu năng và tốc độ phát triển khi số khách hàng tăng.

Ở quy mô nhỏ, câu hỏi là sản phẩm có chạy không. Khi tăng trưởng, câu hỏi trở thành: hệ thống có phục vụ khách hàng thứ một nghìn mà không làm chậm khách hàng đầu tiên không, và người không viết ra nó có sửa an toàn được không. Bài viết đi qua các quyết định kiến trúc quan trọng nhất, dựa trên AWS Well-Architected SaaS Lens và hướng dẫn multitenant của Azure Architecture Center.

Ba mô hình multi-tenant: silo, pool và bridge

AWS SaaS Lens xếp các mô hình kiến trúc SaaS vào ba nhóm. Silo là khi tenant được cấp tài nguyên riêng, ví dụ mỗi tenant có một stack hạ tầng độc lập hoặc một cơ sở dữ liệu riêng. Điểm quan trọng: dù tài nguyên riêng, silo vẫn dùng chung danh tính, quy trình onboarding và vận hành, điều phân biệt SaaS với mô hình dịch vụ được quản lý mà mỗi khách hàng chạy một phiên bản riêng. Pool là khi tenant dùng chung tài nguyên, khái niệm multi-tenant kinh điển nhằm đạt lợi thế quy mô và sự linh hoạt. Bridge thừa nhận thực tế rằng hệ thống thường lai: một số phần chạy silo, một số chạy pool, ví dụ quy định về dữ liệu và rủi ro noisy neighbour đẩy một microservice sang silo, trong khi chi phí và mẫu truy cập đẩy dịch vụ khác sang pool.

Azure Architecture Center mô tả cùng phổ lựa chọn: từ triển khai đơn tenant cho mỗi khách hàng (cô lập cao, nhưng hiệu quả chi phí thấp vì không chia sẻ hạ tầng), đến triển khai hoàn toàn multi-tenant, và ở giữa là phân vùng ngang như dùng chung tầng ứng dụng nhưng mỗi tenant một cơ sở dữ liệu. Azure cũng khuyến nghị mẫu Deployment Stamps: một stamp có thể phục vụ một nhóm tenant hoặc một tenant duy nhất.

Cô lập tenant và phân vùng dữ liệu

Cô lập tenant nghĩa là một tenant không thể truy cập dữ liệu hay tài nguyên của tenant khác, kể cả khi mã nguồn có lỗi. Danh sách kiểm tra multitenant của Azure khuyến nghị đảm bảo ánh xạ đúng mỗi yêu cầu tới tenant, đưa ngữ cảnh tenant vào hệ thống danh tính hoặc cơ chế phân quyền ở tầng ứng dụng, thiết kế cho cô lập và kiểm thử mô hình cô lập liên tục.

Với mô hình pool dùng chung bảng, rủi ro lớn nhất là một truy vấn quên lọc theo tenant. Một lớp phòng thủ là đưa ranh giới xuống cơ sở dữ liệu: ví dụ PostgreSQL có Row-Level Security, khi bật trên bảng thì mọi truy cập thông thường phải được một chính sách cho phép, và nếu không có chính sách nào thì mặc định từ chối. Lưu ý tài liệu PostgreSQL cũng ghi rằng chủ sở hữu bảng thường không chịu ràng buộc của các chính sách này, nên ứng dụng không nên kết nối bằng tài khoản chủ sở hữu.

Noisy neighbour: khi một tenant làm chậm tất cả

Theo Azure Architecture Center, vấn đề noisy neighbour xảy ra khi hiệu năng của một tenant bị giảm do hoạt động của tenant khác. Nó cũng có thể xảy ra khi mỗi tenant chỉ dùng một phần nhỏ, nhưng tổng tải của nhiều tenant có mẫu sử dụng giống nhau tạo ra đỉnh vượt công suất. Chia sẻ tài nguyên vốn mang rủi ro này và không thể loại bỏ hoàn toàn, chỉ có thể giảm và kiểm soát.

• Giám sát mức dùng tài nguyên theo từng tenant, không chỉ tổng hệ thống; gắn mã tenant vào telemetry.
• Áp dụng quản trị tài nguyên: quota, giới hạn API, mẫu Throttling hoặc Rate Limiting.
• Cấu hình cảnh báo khi tài nguyên tăng đột biến và tự động mở rộng khi có thể.
• Chuyển tenant tải lớn hoặc nhạy cảm sang stamp riêng (silo) theo mô hình bridge.
• Kiểm thử để xác nhận dữ liệu không rò rỉ giữa tenant và tác động noisy neighbour ở mức chấp nhận được.

Mở rộng và giám sát hệ thống SaaS (observability)

Azure khuyến nghị thiết kế cho mức tăng trưởng dự kiến nhưng không thiết kế thừa cho mức tăng trưởng phi thực tế, định nghĩa SLO dựa trên yêu cầu của tenant, và kiểm thử khả năng mở rộng khi số tenant tăng. Với tài nguyên tính toán dùng chung, mở rộng giúp mọi tenant hưởng lợi, nhưng khi công suất không đủ thì tất cả cùng chịu ảnh hưởng; tài nguyên riêng cho phép mở rộng độc lập nhưng tốn hơn.

Về quan sát, hãy giám sát cả sức khỏe tổng thể và từng tenant, cấu hình và kiểm thử cảnh báo khi một tenant gặp sự cố hoặc vượt hạn mức. Tách control plane (onboarding, cấu hình, thanh toán) khỏi data plane (phục vụ yêu cầu) và tự động hóa vòng đời tenant thay vì làm thủ công. Azure liệt kê các phản mẫu cần tránh: chạy phiên bản riêng cho từng tenant, hard-code cấu hình theo tenant và triển khai thủ công. Chi phí hạ tầng khi mở rộng cũng cần được quản lý định kỳ (xem tối ưu chi phí cloud).

Đo lường theo tenant và thanh toán (metering)

Azure nêu hai lý do để đo mức tiêu thụ của từng tenant: biết chi phí thực để phục vụ mỗi tenant nhằm theo dõi lợi nhuận, và xác định số tiền cần thu khi dùng mô hình giá theo mức dùng. Khó khăn là phần lớn dịch vụ dùng chung không tự tách mức dùng theo tenant, ví dụ một cơ sở dữ liệu quan hệ chứa dữ liệu mọi tenant.

Một số nguyên tắc từ hướng dẫn của Azure:

• Xác định mục tiêu trước: ước lượng chi phí phục vụ (đủ cho giá cố định) hay đo chính xác (cần cho giá theo mức dùng).
• Không dùng công cụ giám sát ứng dụng làm nguồn dữ liệu thanh toán, vì chúng thường lấy mẫu dữ liệu; hãy xây pipeline ghi nhận riêng có độ chính xác cao.
• Không cần đo theo thời gian thực: ghi dữ liệu rồi tổng hợp bất đồng bộ.
• Tránh đo chính xác quá mức cần thiết, vì nó thêm độ phức tạp và làm quy trình dễ vỡ.
• Mô hình giá (theo người dùng, theo mức dùng, cố định) ảnh hưởng ngược lại kiến trúc: giá cố định dễ bán nhưng có thể lỗ với tenant dùng nhiều; giá theo mức dùng cần đo chính xác và lưu hồ sơ đối soát.

Ghi lại quyết định kiến trúc bằng ADR

Không ít hệ thống SaaS gặp khó không phải vì lưu lượng, mà vì không ai còn nhớ tại sao nó được xây như vậy. Architecture Decision Record (ADR) là một văn bản ngắn ghi lại một quyết định kiến trúc. Michael Nygard đề xuất định dạng này năm 2011, gồm Tiêu đề, Bối cảnh, Quyết định, Trạng thái và Hệ quả; ADR được đánh số tuần tự, không tái sử dụng số, và khi một quyết định bị thay đổi thì ADR cũ được giữ lại và đánh dấu là đã bị thay thế. Martin Fowler nhấn mạnh ADR nên ngắn, thường khoảng một trang, và việc viết ADR giúp làm rõ suy nghĩ của cả nhóm.

Mẫu ADR gợi ý cho quyết định multi-tenant (lưu trong kho mã, ví dụ docs/adr/0007-mo-hinh-tenant.md):

• Tiêu đề: ADR 0007 – Dùng mô hình pool cho gói tiêu chuẩn, silo cho khách hàng có yêu cầu riêng.
• Trạng thái: Đề xuất / Đã chấp nhận / Bị thay thế bởi ADR-xxxx.
• Bối cảnh: số tenant hiện tại và dự kiến, yêu cầu pháp lý về dữ liệu, mẫu tải, năng lực đội ngũ, ràng buộc ngân sách.
• Quyết định: “Chúng tôi sẽ…”, viết bằng câu chủ động, nêu rõ cơ chế cô lập (ví dụ Row-Level Security) và tiêu chí chuyển tenant sang silo.
• Hệ quả: điều gì dễ hơn, điều gì khó hơn, rủi ro đã chấp nhận, và những quyết định tiếp theo cần đưa ra.

Lộ trình chuyển đổi kiến trúc

Ít đội nào chọn đúng mô hình ngay từ đầu, và chuyển đổi mô hình tenant là việc tốn kém vì phải di chuyển dữ liệu từng tenant trong khi họ vẫn dùng sản phẩm. Azure lưu ý: nếu cho phép di chuyển giữa các triển khai, bạn cần tính trước cách chuyển khách hàng từ triển khai multi-tenant sang triển khai riêng, và luôn biết tenant nào đang ở đâu. Các lộ trình thường gặp:

• Đơn tenant (mỗi khách hàng một bản cài) sang SaaS: hợp nhất danh tính, onboarding và vận hành trước, rồi mới gộp hạ tầng.
• Pool sang bridge: tách tenant lớn hoặc có yêu cầu đặc biệt sang stamp hoặc cơ sở dữ liệu riêng; cần công cụ di chuyển dữ liệu theo tenant và danh mục tenant – vị trí.
• Monolith sang dịch vụ tách rời: tách dần các phần có yêu cầu cô lập hoặc mở rộng khác nhau, áp mô hình silo/pool riêng cho từng dịch vụ.
• Mỗi bước chuyển đổi nên có một ADR, kế hoạch kiểm thử cô lập và kế hoạch quay lui.

EYC hỗ trợ được gì

EYC phát triển Early Years Circle, nền tảng kết nối dành cho giáo dục mầm non, và áp dụng các nguyên tắc trong bài khi thiết kế phần mềm. Mảng Phần mềm và SaaS có thể cùng doanh nghiệp rà soát kiến trúc, chọn mô hình tenant, thiết lập thực hành ADR và lập lộ trình chuyển đổi; phạm vi và cam kết được xác định theo thỏa thuận trong hợp đồng. Liên hệ EYC để trao đổi.