Multi-tenacy và kiến trúc database cho hệ thống multi-tenacy

Multi-Tenancy là gì?

Multi-Tenancy là 1 kiến trúc phần mềm cho phép nhiều ứng dựng (tenant) có thể sử dụng chung dữ liệu, và các ứng dụng không thể truy cập dữ liệu của nhau

Tại sao lại là multi-tenancy ?

Multi-tenant Software as a Service (SAAS) là 1 ứng dụng rất phổ biến trong năm 2020, vậy tại sao lại thế ?

Hãy hình dung bạn muốn tạo 1 ứng dụng cung cấp cho nhiều tổ chức, khách hàng khác nhau. Làm cách nào bạn xây dựng hệ thống đó ? Cách đơn giản nhất là mỗi một tổ chức/khách hàng bạn sẽ copy 1 database khác nhau ? Điều đó có nghĩa là hệ thống của bạn sẽ phải hỗ trợ nhiều ứng dụng và mỗi ứng dụng sử dụng 1 database riêng. Điều đó cũng đồng nghĩa với việc developer sẽ phải quản lý nhiều hệ thống, nhiều database và việc cập nhật hệ thống là khá phức tạp

May thay là chúng ta có kiến trúc multi-tenancy, thay vì quản lý nhiều database và nhiều ứng dụng khác nhau. Chúng ta chỉ cần quản lý 1 ứng dụng SAAS và nhiều tenant khác nhau

Multi-tenant có nghĩa là có nhiều tổ chức/khách hàng khác nhau, với mult-tenat SAAS developer sẽ phải chỉ quản lý và deploy duy nhất 1 codebase - không phải là nhiều ứng dụng nữa. Bạn chỉ cần phải update ứng dụng SAAS đồng bộ với tất cả các tenant, về cơ bản nó dễ dàng hơn so với việc bạn phải quản lý nhiều ứng dụng.

Trước khi bạn xây dựng 1 ứng dụng SAAS, bạn phải xử lý 1 vấn đề chỉnh đó là: "Làm thế nào để bảo mật dữ liệu của tố chức/khách hàng với nhau". Dưới đây là 3 kiến trúc database cơ bản nhất để giải quyết vấn đề này.

Single Database for Single Tenant

Điểm chính của thiết kế này là "một database - một tenant", thiết kế này đảm bảo tính an toàn cao nhất cho dữ liệu. Mỗi database sẽ được lưu trữ trên 1 server vật lý khác nhau. Điều này có nghĩa là 1 tenant sẽ chỉ không thể truy cập data ở tenant khác.

Ưu điểm :

Tính linh hoạt cao, bạn thử hình dung 1 tenant cần mã hoá dữ liệu nhưng các tenant khác không cần. Bạn có cần phải mã hoá dữ liệu ở các tenant khác không ? Không bạn ko cần thiết, mỗi tenant sẽ là độc lập với nhau cả về cấu trúc và vật lý
Dễ dàng restore data, khi một tenant bị lỗi dữ liệu ta có thể khôi phục dữ liệu từ các tenant khac (vì chúng độc lập nhau)
Tính bảo mật dữ liệu cao

Nhược điểm:

Chi phí cao vì bạn phải trả tiền để lưu trữ các tenant database khác nhau (trên các server khác nhau)
Việc quản lý cũng tương đối khó khăn

Để giảm thiếu chi phí chúng ta cùng xem thiết kế dưới đây

Separate Schema for Each Tenant

Điểm chính ở thiết kế này là 1 database và nhiều schema. Mỗi tenant sẽ có 1 tập hợp schema khác nhau (1 tập các tables) bên trong 1 database.

Ưu điểm:

Chi phí rẻ: chỉ có 1 database và nhiều schema
Quản lý dễ dàng: chỉ có 1 server vật lý (chứa database thay vì nhiều server như kiến trúc trên)
Tính linh hoạt cao: bạn có thể cutomize các schemas khác nhau theo yêu cầu của bài toán

Nhược điểm:

Tính bảo mật thấp
Việc backup và restore khó khăn. Khi một dữ liệu ở 1 tenant bị lỗi, điều đó cũng sẽ ảnh hưởng đến các tenant khác, để tránh việc ghi đè dữ liệu sang khác schemas khác đòi hỏi 1 số kỹ thuật đặc biệt
Về cơ bản dữ liệu chỉ độc lập 1 phần (vẫn chung 1 database)

Ta đã đi qua 2 thiết kế tenant có độ bảo mật dữ liệu khá tốt, vậy chúng ta cùng đi đến thiết kế cuối cùng để xem ưu và nhược điểm nó thế nào

Shared Schema for Tenants

Việc triển khai chia sẽ schema cho các tenants là hướng dễ thực hiện nhất trong 3 cách. Dữ liệu của tất cả các tenants sẽ được lưu trữ trong cùng một bảng. Để tìm kiếm và truy cập dữ liệu cho mỗi tenant (mỗi row trong bảng), chúng ta phải gán cho mỗi row một tenant khác nhau. Ưng dụng SAAS của bạn sẽ phải sử dụng tenant ID.

Ưu điểm:

Dễ dàng triển khai
Không cần tạo và quản lý các shema cho các tenants
Không cần phải quản lý nhiều server
Chi phí rẻ

Nhược điểm:

Ứng dụng của bạn sẽ phải thêm nhiều tenants hơn theo thời gian (nhiều table cho mỗi tenant hơn), điều đó đồng nghĩa với query sẽ phức tạp hơn, nhiều index hơn và việc update data sẽ chậm hơn
Khó khăn cho việc quản lý truy cập data cho mỗi tenant: quản lý quyền truy cập, quản lý request đến database

Summary

Việc sử dụng design nào phải phục thuộc vào bài toán và ứng dụng của các bạn, nhưng theo quản điểm của mình thì "Shared Schema for Tenants" là cách dễ dàng tiếp cận và triển khai nhất. Đó là cách cần bắng nhất giữa việc phát triển và chi phí triển khai. Cuối cùng việc chọn design nào phải phục thuộc vào bài toàn thực tế