Database-per-User Architecture With Isolated Application Environments

Neon · 2024 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài hướng dẫn khái niệm của nhà cung cấp (Neon), phần tiếp của loạt bài database-per-user; mọi nhận định là theo Neon.

Bối cảnh

Bài trước trong loạt: database-per-user với môi trường ứng dụng dùng chung (một bản ứng dụng nói chuyện với DB riêng của từng khách). Bài này: môi trường ứng dụng cô lập, mỗi khách một bản sao toàn bộ hệ thống.
Theo Neon, đây không còn là multi-tenancy và mất lợi thế dùng chung tài nguyên, nên cần lý do thật:
- địa lý và quy định (data sovereignty, data residency, khách muốn hệ ở gần);
- khách tự quyết nhịp nâng cấp (tổ chức lớn, ngành truyền thống), điều không làm được khi schema chỉ có một phiên bản.
- Lý do không nên dùng: tuỳ biến riêng cho từng khách, vì mỗi bản thành một sản phẩm riêng phải vá riêng.

Không phải on-premises: nhà cung cấp vẫn vận hành hạ tầng và mạng (subdomain theo khách, có thể "mang URL riêng"). Bên trong hệ gần như single-tenant: không phải định tuyến query tới đúng DB; độ phức tạp dồn sang provisioning và deploy.
Giới hạn và tính năng cố định trong mỗi bản; nguồn sự thật về bật tính năng nằm ở catalog database trung tâm, nhưng được đẩy xuống DB của ứng dụng để không phải gọi về trung tâm ở mỗi request.
Control plane trung tâm vẫn cần để cấp phát, giám sát, bảo trì và hiển thị phiên bản đang chạy của từng khách; cấp phát một khách mới gồm cả pipeline deploy, mạng (có khi cần khách xin chứng chỉ TLS), observability. Mức tự động hoá tuỳ tần suất có khách mới; ít khách lớn thì tài liệu và quản lý tài khoản còn đủ dùng lâu.
Quản lý phiên bản: mỗi khách có thể ở phiên bản bất kỳ, bản vá được backport về các dòng cũ. Nên tuyến tính hoá đường nâng cấp (1.0.1 lên 1.2.0 phải đi qua dòng 1.1.x) và viết migration idempotent (kiểm cột, kiểu, ràng buộc trước khi sửa), để một thay đổi đã có qua bản vá không làm hỏng lần nâng cấp sau.

Cô lập theo khách là một cực của trục "chia dữ liệu theo tenant": cô lập nhất, đắt nhất; chỉ chọn khi quy định hoặc nhịp nâng cấp bắt buộc (Sharding và tách database).
Khi nhiều bản chạy nhiều phiên bản schema, migration phải idempotent và đường nâng cấp phải ít nhánh (Migration không downtime).
Dù cô lập, vẫn cần một control plane chung để biết mỗi khách đang ở đâu.