3.14 Đa người thuê và kiến trúc SaaS

Tổng quan và động lực

Đa người thuê là thực hành chạy một thể hiện duy nhất của phần mềm để phục vụ nhiều khách hàng riêng biệt cùng lúc, giữ dữ liệu và cấu hình của mỗi khách hàng tách biệt về mặt logic trong khi họ dùng chung mã và, thường là, cùng hạ tầng. Mỗi khách hàng là một người thuê. Ý tưởng duy nhất này là động cơ kinh tế của phần mềm như một dịch vụ (SaaS), mô hình trong đó bạn bán quyền truy cập vào một ứng dụng đang chạy thay vì một bản sao để cài đặt. Khi một nghìn người thuê dùng chung cùng một bản triển khai, bạn vá một lần, bạn mở rộng một hệ thống, và chi phí biên của khách hàng tiếp theo tiến về không. Đó là lý do một sản phẩm đa người thuê được xây tốt có thể phục vụ một công ty khởi nghiệp hai người và một doanh nghiệp trăm nghìn chỗ ngồi từ cùng một cơ sở mã, và là lý do mô hình thuê bạn chọn định hình biên lợi nhuận, tư thế bảo mật và tải vận hành của bạn trong nhiều năm.

Với các đội lớn, rủi ro sâu hơn chi phí. Đa người thuê đặt một yêu cầu cứng ở trung tâm kiến trúc của bạn: người thuê A không bao giờ được thấy dữ liệu của người thuê B, bao giờ cũng vậy, dưới bất kỳ lỗi, tranh đua hay cấu hình sai nào. Một lần rò rỉ xuyên người thuê có thể kết thúc một công ty. Đồng thời, toàn bộ ý nghĩa của việc chia sẻ là hiệu quả, nên mọi quyết định thiết kế nằm trên một dải giữa cô lập mạnh (an toàn hơn, đắt hơn) và chia sẻ dày đặc (rẻ hơn, rủi ro hơn). Làm đúng điều này là sự khác biệt giữa một sản phẩm mở rộng duyên dáng và một sản phẩm hoặc làm bạn phá sản vì hạ tầng hoặc đưa bạn lên tiêu đề báo. Chương này xây trên kiến trúc đám mây (chương 3.11), dựa nặng vào kiến trúc dữ liệu (chương 3.4) và bảo mật đám mây (chương 4.3), và liên hệ với khả năng mở rộng và phục hồi (chương 3.5) và phân bổ chi phí (chương 9.4).

Doanh nghiệp và chính phủ nâng thanh chuẩn lên nữa. Người mua doanh nghiệp thương lượng các bảo đảm dữ liệu theo hợp đồng, đòi cô lập riêng cho bậc của họ, và mong bạn di chuyển họ giữa các môi trường mà không có thời gian ngừng. Chính phủ thêm luật về nơi lưu trữ dữ liệu, sự tách biệt theo phân loại, và yêu cầu thường xuyên rằng mỗi cơ quan là một người thuê riêng với ranh giới kiểm toán riêng. Các quyết định thuê ở đây không phải chi tiết cài đặt; chúng là những cam kết bạn đưa ra với mọi khách hàng tin tưởng giao dữ liệu cho bạn.

Các nguyên tắc chính

Cô lập là một dải, không phải một công tắc. Các mô hình silo, pool và bridge đánh đổi hiệu quả lấy sự tách biệt; hãy chọn theo từng bậc và từng tài nguyên, không phải một lần cho mọi thứ.
Ngữ cảnh người thuê là thiêng liêng. Mọi yêu cầu, truy vấn, dòng nhật ký và công việc nền phải mang một định danh người thuê, và mọi truy cập dữ liệu phải được giới hạn bởi nó.
Rò rỉ xuyên người thuê là thất bại quan trọng nhất. Thiết kế để một bộ lọc bị thiếu đơn lẻ không thể phơi bày dữ liệu của người thuê khác; phòng thủ theo chiều sâu, không phải một mệnh đề WHERE.
Hàng xóm ồn ào là vấn đề kiến trúc. Không có hạn ngạch và công bằng, một người thuê nặng làm suy giảm mọi người; hãy lên kế hoạch trước khi nó xảy ra.
Cấu hình theo người thuê mở rộng được; mã theo người thuê thì không. Uốn sản phẩm bằng dữ liệu và cờ, không phải bằng nhánh rẽ.
Vòng đời người thuê là một tính năng sản phẩm. Tiếp nhận, cung cấp tài nguyên, chấm dứt và xuất dữ liệu phải là hạng nhất, tự động và kiểm toán được.
Bạn không thể quản lý những gì bạn không quy được. Khả năng quan sát và chi phí phải được cắt theo người thuê, nếu không bạn bay mù về cả độ tin cậy lẫn biên lợi nhuận.

Khuyến nghị

Chọn mô hình thuê theo từng bậc, dọc theo dải cô lập-so-với-hiệu quả

Ba mô hình neo dải này. Trong mô hình silo (riêng), mỗi người thuê có một ngăn xếp cô lập riêng: tính toán riêng, cơ sở dữ liệu riêng, đôi khi một tài khoản hay mạng riêng. Cô lập mạnh nhất và bán kính ảnh hưởng của một lỗi là một người thuê, nhưng bạn trả tiền cho năng lực nhàn rỗi theo từng khách hàng và vận hành nhiều bản sao. Trong mô hình pool (chung), mọi người thuê dùng chung tính toán và cơ sở dữ liệu, được tách chỉ bằng logic và một định danh người thuê. Hiệu quả cao nhất và chi phí biên của một người thuê gần bằng không, nhưng cô lập giờ phụ thuộc hoàn toàn vào mã của bạn đúng. Mô hình bridge (lai) pha trộn hai cái: tính toán chung với cơ sở dữ liệu riêng theo người thuê, hoặc một pool chung cho người thuê nhỏ và các silo riêng cho người thuê lớn hoặc chịu quy định.

Đừng chọn một mô hình cho cả sản phẩm. Câu trả lời đúng thường là một bridge ánh xạ với các bậc giá của bạn. Đặt cái đuôi dài các người thuê nhỏ vào một pool chung hiệu quả nơi kinh tế học của họ khả thi. Cung cấp một triển khai riêng hoặc đơn người thuê như một bậc cao cấp cho khách hàng doanh nghiệp sẵn sàng trả cho sự cô lập và các bảo đảm hợp đồng. Hãy ghi ánh xạ này ra thành hồ sơ quyết định kiến trúc (chương 3.11), vì “người thuê nào chia sẻ gì” là một tuyên bố mà đội bảo mật, bán hàng và tài chính của bạn đều phụ thuộc vào.

Phân vùng dữ liệu có chủ đích, và làm cho việc giới hạn theo người thuê không thể quên

Dữ liệu là nơi đa người thuê sống hoặc chết, nên hãy coi lựa chọn phân vùng là một quyết định kiến trúc dữ liệu cốt lõi (chương 3.4). Ba chiến lược song song với các mô hình thuê. Cơ sở dữ liệu riêng cho mỗi người thuê cho cô lập mạnh nhất, sao lưu và khôi phục theo người thuê dễ dàng, và xuất dữ liệu đơn giản, với cái giá là nhiều cơ sở dữ liệu để chạy và di chuyển lược đồ phải phân tán ra. Lược đồ riêng cho mỗi người thuê trong một cơ sở dữ liệu chung là đường trung gian: một máy chủ, tách biệt logic, vẫn nhiều đối tượng để di chuyển. Bảng chung có khóa bằng cột người thuê, nơi mỗi hàng mang một tenant_id, là dày đặc nhất và rẻ nhất, và nguy hiểm nhất, vì giờ một truy vấn đơn lẻ thiếu bộ lọc người thuê làm rò rỉ dữ liệu qua các khách hàng.

Nếu bạn chia sẻ bảng, đừng dựa vào việc lập trình viên nhớ bộ lọc. Hãy thực thi giới hạn theo người thuê trong một tầng không thể bị vượt qua: bảo mật mức hàng của cơ sở dữ liệu gắn một vị từ bắt buộc vào mọi truy vấn dựa trên người thuê của phiên, một ORM hay tầng truy cập dữ liệu tự động chèn mệnh đề người thuê, hoặc cả hai. Thắt lưng và dây đeo quần là đúng ở đây. Khi người thuê lớn lên, phân mảnh theo người thuê trở nên tự nhiên: đặt các nhóm người thuê trên các mảnh cơ sở dữ liệu khác nhau để không thể hiện đơn lẻ nào giữ tất cả mọi người, điều này cũng giới hạn bán kính ảnh hưởng của thất bại một mảnh và cho phép bạn chuyển một người thuê lớn sang mảnh riêng mà không đổi mô hình.

Lan truyền ngữ cảnh người thuê ở mọi nơi, và phòng thủ chống rò rỉ xuyên người thuê theo chiều sâu

Định danh người thuê phải đi cùng mọi đơn vị công việc. Hãy thiết lập nó ở rìa, thường từ phiên đã xác thực hoặc một tên miền con, xác thực nó, và luồn nó qua ngữ cảnh yêu cầu, mọi lệnh gọi dịch vụ hạ nguồn, mọi phiên cơ sở dữ liệu, mọi công việc được xếp hàng, và mọi dòng nhật ký cùng chỉ số. Các khoảng trống nguy hiểm là những khoảng bất đồng bộ: một công nhân nền xử lý công việc mà không thiết lập lại ngữ cảnh người thuê, một bộ đệm có khóa không có người thuê, một trình xử lý webhook tin một định danh người thuê từ bên gọi. Mỗi cái là một con đường phục vụ dữ liệu của người thuê này cho người thuê khác.

Hãy coi cô lập xuyên người thuê là một thuộc tính bảo mật với phòng thủ theo chiều sâu, và chuyển chi tiết sang chương 4.3. Áp dụng nguyên tắc đặc quyền tối thiểu để ngay cả một thành phần bị xâm phạm cũng chỉ với tới được người thuê mà nó đang hành động thay. Không bao giờ chấp nhận định danh người thuê từ đầu vào do máy khách kiểm soát cho các quyết định cấp quyền; hãy suy ra nó từ danh tính đã xác thực. Đặt không gian tên cho bộ đệm, tiền tố lưu trữ đối tượng và chỉ mục tìm kiếm theo người thuê để một va chạm khóa không thể vượt ranh giới. Rồi kiểm thử ranh giới có chủ đích: các bài kiểm thử tự động khẳng định thông tin xác thực của người thuê A không thể đọc bản ghi của người thuê B, và các bài tập đội đỏ định kỳ cố phá ra khỏi một người thuê. Một rò rỉ được bộ kiểm thử của bạn tìm thấy là một lỗi; một rò rỉ do khách hàng tìm thấy là một cuộc khủng hoảng.

Kiềm chế hàng xóm ồn ào bằng hạn ngạch, giới hạn tốc độ và công bằng

Khi người thuê chia sẻ tài nguyên, đợt tăng đột biến của một người thuê trở thành sự cố của mọi người. Vấn đề hàng xóm ồn ào này không phải trường hợp biên; nó là hành vi mặc định của một pool chung dưới tải. Hãy thiết kế chống lại nó từ đầu. Đặt hạn ngạch theo người thuê trên các tài nguyên quan trọng (yêu cầu mỗi giây, công việc đồng thời, lưu trữ, chi phí truy vấn) và thực thi chúng bằng giới hạn tốc độ ở rìa và ở các ranh giới nội bộ tốn kém. Ưu tiên lập lịch công bằng cho mỗi người thuê một phần chia thay vì hàng đợi đến-trước-phục-vụ-trước để một người thuê bỏ đói những người còn lại.

Khớp việc thực thi với mô hình thuê của bạn. Trong một pool chung, hạn ngạch và công bằng là biện pháp phòng thủ chính, nên hãy đầu tư vào chúng. Với một người thuê mà tải thực sự vượt quá những gì chia sẻ công bằng có thể hấp thụ, câu trả lời thường là nâng họ ra khỏi pool sang một triển khai bridge hoặc silo, đó là một tính năng bạn có thể bán thay vì một thất bại. Hãy gắn điều này với công việc mở rộng và phục hồi của bạn (chương 3.5): loại bỏ tải, bộ ngắt mạch và áp suất ngược đều cần nhận biết người thuê để bỏ tải dư của một người thuê bảo vệ những người khác thay vì làm suy giảm cả hệ thống.

Cấu hình người thuê bằng dữ liệu, không phải các nhánh rẽ của mã

Mọi khách hàng sẽ muốn điều gì đó hơi khác: logo của họ, quy tắc quy trình của họ, tích hợp của họ, một trường bạn không có. Cách mở rộng được để nói đồng ý là cấu hình theo người thuê: cờ tính năng, thiết lập, quyền hạn và điểm mở rộng là dữ liệu, được đánh giá lúc chạy, và dùng chung bởi một cơ sở mã. Con đường phá hủy một doanh nghiệp SaaS là mã tùy chỉnh theo người thuê: một nhánh hay một bản rẽ hay một trường hợp đặc biệt trong đường mã cho một khách hàng lớn. Mười cái như vậy và bạn không còn một sản phẩm, bạn có mười sản phẩm khoác chung một chiếc áo choàng, và mọi thay đổi phải được kiểm thử mười lần.

Hãy vạch một lằn ranh vững chắc. Mô hình hóa các trục biến thể bạn sẵn sàng hỗ trợ như cấu hình hạng nhất, và coi các yêu cầu ngoài các trục đó là lộ trình sản phẩm hoặc một lời từ chối dứt khoát. Khi một khách hàng cần tùy biến thực sự, hãy cho họ các điểm mở rộng (webhook, API, plugin, trường tùy chỉnh) chạy logic của họ mà không rẽ nhánh của bạn. Hãy dành các triển khai thực sự theo yêu cầu cho bậc cao cấp đơn người thuê, nơi cô lập là mục đích và giá cao hơn bù đắp chi phí vận hành.

Làm vòng đời người thuê tự động, quan sát được và có phân bổ chi phí

Tiếp nhận một người thuê nên là một luồng tự phục vụ, tự động: cung cấp phân vùng dữ liệu của người thuê, gieo mặc định, đặt quyền hạn, và sẵn sàng trong vài giây, không phải một phiếu gửi đội vận hành. Chấm dứt cũng quan trọng không kém và dễ bị bỏ bê hơn. Khi một người thuê rời đi, bạn phải có thể xuất dữ liệu của họ ở định dạng dùng được, rồi xóa nó một cách chứng minh được, vì hợp đồng và luật riêng tư sẽ đòi cả hai. Hãy thiết kế xuất và xóa dữ liệu ngay từ ngày đầu; trang bị chúng vào một lược đồ bảng chung rất đau đớn.

Hãy đo đạc mọi thứ theo từng người thuê. Gắn thẻ nhật ký, truy vết và chỉ số bằng định danh người thuê để bạn trả lời “sự cố này là tất cả người thuê hay một?” và “người thuê nào đang tạo ra chi phí này?” trong vài giây. Phân bổ chi phí hạ tầng cho người thuê để bạn biết biên lợi nhuận thực của mình theo từng khách hàng và phát hiện người thuê mà mức sử dụng làm họ không có lãi ở mức giá hiện tại (chương 9.4). Khả năng quan sát và phân bổ chi phí nhận biết người thuê biến đa người thuê từ hộp đen thành một hệ thống bạn thực sự vận hành và định giá được.

Đánh đổi: ưu và nhược điểm

Mô hình thuê	Ưu điểm	Nhược điểm
Silo (ngăn xếp riêng cho mỗi người thuê)	Cô lập mạnh nhất, bán kính ảnh hưởng nhỏ nhất, tuân thủ và xuất theo người thuê dễ, câu chuyện hàng xóm ồn ào đơn giản	Chi phí cao nhất, năng lực nhàn rỗi theo người thuê, nhiều bản sao để vận hành và vá
Pool (chung hoàn toàn)	Chi phí biên thấp nhất, đóng gói dày đặc nhất, một hệ thống để mở rộng và nâng cấp	Cô lập hoàn toàn phụ thuộc vào tính đúng của mã, rủi ro hàng xóm ồn ào tệ nhất, xuất và xóa theo người thuê khó nhất
Bridge (lai, theo bậc)	Hiệu quả cho người thuê nhỏ, cô lập riêng cho người thuê lớn, ánh xạ với giá	Nhiều mô hình hơn để xây và vận hành, đường nâng cấp giữa các bậc phải duy trì
CSDL chung, lược đồ chung (cột người thuê)	Lưu trữ rẻ nhất, một lần di chuyển, vận hành đơn giản nhất	Một bộ lọc thiếu làm rò rỉ dữ liệu; cần bảo mật mức hàng làm điểm tựa
CSDL chung, lược đồ riêng cho mỗi người thuê	Cô lập logic, một máy chủ, xuất tạm được	Nhiều đối tượng lược đồ, di chuyển phân tán, giới hạn mở rộng mỗi máy chủ
CSDL riêng cho mỗi người thuê	Cô lập dữ liệu mạnh, sao lưu và xuất theo người thuê	Nhiều cơ sở dữ liệu, di chuyển phân tán, chi phí cao hơn

Căng thẳng trung tâm là cô lập so với hiệu quả, và nó chạy qua mọi hàng. Chia sẻ dày đặc hơn nhân lên biên lợi nhuận và nhân lên rủi ro trong cùng một chuyển động; cô lập mạnh hơn mua sự an toàn và đơn giản với một chi phí thực theo người thuê. Cách giải quyết không phải chọn một cực mà là đặt từng người thuê có chủ đích dọc theo dải, thường theo bậc: đóng gói dày đặc các người thuê nhỏ nơi kinh tế học đòi hỏi và rủi ro bị giới hạn, cô lập các người thuê lớn và chịu quy định nơi họ sẽ trả tiền và bán kính ảnh hưởng phải nhỏ. Rồi làm đầu dày đặc an toàn bằng giới hạn người thuê được thực thi, và làm đầu cô lập rẻ bằng tự động hóa, để không cực nào đau như phiên bản ngây thơ.

Câu hỏi để thảo luận với đội của bạn

Nếu một bộ lọc giới hạn người thuê bị thiếu vào ngày mai, một khách hàng có thấy dữ liệu của khách hàng khác không? Đây là câu hỏi phân biệt một sản phẩm đa người thuê có thể bảo vệ với một tai nạn đang chờ. Phép thử trung thực là truy một đường đọc thật và hỏi cái gì thực thi ranh giới người thuê: là một mệnh đề WHERE do lập trình viên viết, hay có một điểm tựa như bảo mật mức hàng của cơ sở dữ liệu hay một tầng truy cập dữ liệu chèn phạm vi bất kể gì? Hãy mang các đường truy vấn thực, công việc nền và bộ đệm của bạn, vì rò rỉ gần như luôn ẩn trong góc bất đồng bộ không ai giới hạn. Bạn cũng nên mang kết quả của một bài kiểm thử cố ý dùng phiên của người thuê A để yêu cầu bản ghi của người thuê B và khẳng định một sự từ chối. Nếu ranh giới chỉ dựa vào sự cảnh giác của con người, bạn có một vụ xâm phạm tiềm ẩn, và bản sửa (phòng thủ theo chiều sâu) nên nhảy lên đầu danh sách việc cần làm.
Mô hình thuê và phân vùng dữ liệu nào mà mỗi bậc khách hàng thực sự dùng, và nó có khớp với những gì chúng ta đã bán cho họ không? Nhiều đội trôi vào một mô hình duy nhất theo mặc định, rồi phát hiện giá và kiến trúc của họ bất đồng: khách hàng doanh nghiệp được hứa cô lập mà pool chung không cung cấp, hoặc khách hàng nhỏ nằm trong các ngăn xếp riêng đắt đỏ phá hỏng biên lợi nhuận. Hãy ánh xạ mỗi bậc với mô hình thực của nó (silo, pool hay bridge; cơ sở dữ liệu-theo-người-thuê, lược đồ, hay bảng chung) và đặt nó cạnh các bảo đảm dữ liệu theo hợp đồng mà đội bán hàng đưa ra. Ở nơi chúng khác nhau, bạn có hoặc rủi ro tuân thủ hoặc vấn đề chi phí, và cả hai đều đáng được phơi bày trước khi một khách hàng hay kiểm toán viên tìm thấy chúng. Bằng chứng cần mang là ánh xạ bậc-với-mô hình, chi phí theo người thuê, và ngôn từ thực trong các hợp đồng doanh nghiệp của bạn.
Khi tải của một người thuê lớn tăng đột biến, ai khác cảm nhận được, và kế hoạch của chúng ta là gì? Trong một pool chung câu trả lời thường là “mọi người,” và các đội thường không biết điều này cho đến khi một sự cố làm nó hiển nhiên. Hãy đi qua điều xảy ra khi người thuê lớn nhất của bạn chạy một lần nhập hàng loạt hoặc có một đợt tăng lưu lượng: hạn ngạch theo người thuê và lập lịch công bằng có kiềm chế được nó không, loại bỏ tải có bảo vệ hàng xóm không, hay cả hệ thống suy giảm cùng nhau? Hãy mang dữ liệu tải và câu chuyện về sự cố hàng xóm ồn ào gần nhất của bạn, vì người thuê làm hại bạn thường là người bạn gọi tên được. Câu trả lời nên định hình cả khoản đầu tư giới hạn tốc độ lẫn chiến lược phân bậc của bạn, vì cách sửa sạch nhất cho một người thuê vượt khỏi chia sẻ công bằng là nâng họ lên một triển khai bridge hoặc riêng mà bạn có thể tính phí.
Khi một người thuê chấm dứt vào ngày mai, chúng ta có thể trao cho họ một bản xuất sạch và chứng minh đã xóa mọi dấu vết, hay chúng ta sẽ chạy vạy? Chấm dứt là phần của vòng đời người thuê mà các đội bỏ bê cho đến khi một điều khoản thoát hợp đồng hoặc yêu cầu theo luật riêng tư buộc phải làm, và đến lúc đó lược đồ chung làm cho việc trích xuất và xóa trở nên đau đớn. Với một đội lớn rủi ro cộng dồn, vì dữ liệu của một người thuê rải rác qua cơ sở dữ liệu chính, bộ đệm, lưu trữ đối tượng, chỉ mục tìm kiếm, bản sao lưu và đường ống phân tích, và mỗi nơi phải được xuất ở định dạng dùng được rồi thanh trừ một cách chứng minh được. Các cân nhắc đối lập là thật: các bảng chung dày đặc cho bạn lưu trữ rẻ chính là những bảng khiến việc trích xuất và xóa theo người thuê khó nhất, nên hiệu quả bạn mua ở tầng lưu trữ bạn có thể trả lại ở lối ra. Hãy mang một buổi diễn tập sống về việc chấm dứt một người thuê thật, danh sách mọi kho chứa dữ liệu người thuê, và bằng chứng bạn sẽ cho xem rằng việc xóa thực sự đã xảy ra. Với người thuê doanh nghiệp và chính phủ, bản xuất phải được chứng nhận và việc xóa phải chứng minh được để thỏa mãn luật hồ sơ công và riêng tư, vì vậy hãy coi đường xóa bị thiếu là một khiếm khuyết tuân thủ cần đóng ngay bây giờ, không phải tính năng thêm khi một khách hàng rời đi.
Có bao nhiêu trường hợp đặc biệt riêng lẻ cho từng khách hàng đã sống trong đường mã của chúng ta, và lằn ranh chúng ta từ chối vượt qua ở đâu? Nhánh rẽ mã theo người thuê là cách lặng lẽ khiến một doanh nghiệp SaaS thôi là một sản phẩm và trở thành nhiều sản phẩm mang chung một tên, nơi mọi thay đổi phải được kiểm thử đối với mọi trường hợp đặc biệt và vận tốc phân rã khi bạn thêm khách hàng. Căng thẳng là một khách hàng lớn có nhu cầu thật thì khó từ chối, và một nhánh trong đường mã cảm thấy nhanh hơn xây một bề mặt cấu hình, nên các trường hợp đặc biệt tích tụ từng ngoại lệ hợp lý một. Hãy mang một bản kiểm kê trung thực: grep cơ sở mã tìm tên khách hàng và nhánh đặc thù bậc, đếm chúng, và ước tính chi phí kiểm thử và rà soát thêm mà mỗi cái áp đặt lên một thay đổi không liên quan. Cuộc thảo luận nên vạch một lằn ranh vững chắc giữa biến thể bạn mô hình hóa như cấu hình hạng nhất (cờ, quyền hạn, điểm mở rộng) và công việc thực sự theo yêu cầu bạn dành cho bậc cao cấp đơn người thuê nơi giá cao hơn bù chi phí vận hành. Với người mua doanh nghiệp đòi tùy biến sâu, câu trả lời bền vững là các điểm mở rộng chạy logic của họ mà không rẽ nhánh của bạn, để quản trị và kiểm toán vẫn khả thi qua toàn đội.
Chúng ta có thể nói, theo từng người thuê, cả sự cố đang tốn kém gì cho ai lẫn khách hàng nào không có lãi ở mức giá hiện tại không? Đa người thuê biến thành hộp đen ngay khoảnh khắc nhật ký, truy vết, chỉ số và chi phí hạ tầng của bạn không mang chiều người thuê, vì khi đó bạn không thể trả lời một sự cố là một người thuê hay cả đội, và bạn không thể gọi tên người thuê mà mức sử dụng khiến họ thua lỗ ở giá hợp đồng. Với một đội lớn sự phân bổ này là thứ phân biệt vận hành nền tảng với đoán mò về nó, và nó trực tiếp định hình cả phản ứng độ tin cậy lẫn giá cả. Các cân nhắc kéo ngược về chi phí đo đạc và lực lượng: gắn thẻ mọi thứ theo người thuê không miễn phí, và chỉ số có lực lượng cao làm căng ngân sách quan sát của bạn, nên bạn chọn có chủ đích cái gì cắt theo người thuê và cái gì lấy mẫu. Hãy mang độ bao phủ gắn thẻ người thuê hiện tại, một truy vấn thật quy chi tiêu đám mây cho một người thuê đơn lẻ, và bảng biên lợi nhuận cho phép bạn gọi tên khách hàng ít có lãi nhất. Trong bối cảnh doanh nghiệp và chính phủ, chi phí theo người thuê và khả năng quan sát có phạm vi kiểm toán cũng nuôi việc tính phí nội bộ, hoạch định năng lực, và ranh giới kiểm toán mà mỗi cơ quan hay đơn vị kinh doanh được hưởng, nên chiều người thuê là yêu cầu quản trị cũng như yêu cầu vận hành.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Hãy phát hành một pool chung duy nhất từ ngày đầu và dồn sự chú ý kỹ thuật khan hiếm vào điều duy nhất không thể trang bị bổ sung: giới hạn người thuê được thực thi. Một Postgres được quản lý với bảo mật mức hàng, một tenant_id trên mọi bảng, và ngữ cảnh người thuê được giải quyết ở rìa mua cho bạn mật độ an toàn mà không cần đội vận hành. Đừng xây các bậc silo hay hạ tầng theo người thuê một cách đầu cơ; chỉ thêm một bậc bridge khi một khách hàng tiềm năng doanh nghiệp trả tiền khiến sự cô lập đáng với chi phí của nó.

Doanh nghiệp nhỏ. Không có chuyên gia nền tảng và ngân sách eo hẹp, hãy dựa vào những gì đám mây và khung phát triển của bạn đã cho thay vì tự xây bộ máy cô lập. Cơ sở dữ liệu được quản lý với bảo mật mức hàng, một nền tảng-như-một-dịch-vụ giới hạn người thuê giúp bạn, và một nhà cung cấp xác thực mang danh tính người thuê thường rẻ hơn và an toàn hơn các bản tự chế tương đương. Hãy coi đa người thuê là quyết định mua-so-với-xây ở mọi tầng, và dành công việc tùy chỉnh cho các bài kiểm thử ranh giới người thuê mà chỉ bạn viết được.

Doanh nghiệp lớn. Vấn đề là quản trị danh mục qua nhiều đội: một kiến trúc bridge theo bậc, một hồ sơ quyết định kiến trúc ánh xạ mỗi bậc với mô hình thuê và phân vùng dữ liệu của nó, và phân bổ chi phí theo người thuê để tài chính biết biên lợi nhuận thực của từng tài khoản. Hãy chuẩn hóa việc lan truyền ngữ cảnh người thuê và điểm tựa giới hạn để không đội nào phát minh lại, ngân sách tường minh cho cô lập và tự động hóa vòng đời, và giữ một đường được hỗ trợ, có định giá để di chuyển một người thuê giữa các bậc không thời gian ngừng khi họ lớn lên hoặc nhu cầu tuân thủ của họ thay đổi.

Chính phủ. Mua sắm, nơi lưu trữ dữ liệu và trách nhiệm giải trình công thúc đẩy mô hình. Hãy ghim dữ liệu của mỗi cơ quan vào các vùng trong nước bằng chính sách-dưới-dạng-mã, cho khối lượng công việc nhạy cảm hoặc phân loại cao vào silo trong các tài khoản riêng với ranh giới kiểm toán riêng, và cho mỗi cơ quan tích hợp danh tính, quy tắc lưu giữ và dấu vết kiểm toán riêng để kiểm toán viên của một cơ quan không bao giờ thấy hoạt động của cơ quan khác. Chấm dứt phải tạo ra bản xuất được chứng nhận và việc xóa chứng minh được để thỏa mãn luật hồ sơ công và riêng tư, và những bảo đảm về thuê bạn ký phải là những bảo đảm kiến trúc của bạn thực sự giữ được.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp mười lăm người xây sản phẩm của mình như một pool chung duy nhất từ ngày đầu và làm đúng. Mọi người thuê dùng chung một cơ sở dữ liệu Postgres được quản lý với tenant_id trên mọi bảng, bảo mật mức hàng thực thi vị từ người thuê tại cơ sở dữ liệu để một bộ lọc bị quên không thể gây rò rỉ, và ứng dụng giải quyết người thuê từ một tên miền con ở rìa rồi luồn nó qua mọi yêu cầu và công việc nền. Tiếp nhận là tự phục vụ: một lượt đăng ký mới cung cấp hàng người thuê của nó, gieo mặc định, và hoạt động trong vài giây. Hai kỹ sư chạy toàn bộ nền tảng vì chỉ có một hệ thống để vận hành. Khi khách hàng tiềm năng doanh nghiệp thực sự đầu tiên đòi một cơ sở dữ liệu riêng và một bảo đảm cô lập theo hợp đồng, họ thêm một bậc bridge: cùng cơ sở mã, nhưng người thuê này có cơ sở dữ liệu riêng trên mảnh riêng, bán ở mức giá bù đắp chi phí.

Doanh nghiệp lớn. Một nhà cung cấp SaaS phục vụ các tổ chức tài chính lớn vận hành một kiến trúc bridge theo bậc. Hàng nghìn khách hàng nhỏ và vừa sống trong các pool chung theo vùng, được phân mảnh theo người thuê, với hạn ngạch và lập lịch công bằng giữ hàng xóm ồn ào trong tầm kiểm soát. Khách hàng ngân hàng bậc cao nhất nhận các triển khai đơn người thuê trong các tài khoản đám mây cô lập, với cơ sở dữ liệu riêng, khóa mã hóa theo người thuê, và các bảo đảm hợp đồng về nơi lưu trữ dữ liệu và cô lập được viết vào thỏa thuận khung. Một năng lực nền tảng di chuyển một người thuê giữa các bậc không thời gian ngừng khi họ lớn lên hoặc nhu cầu tuân thủ của họ thay đổi. Chi phí của mọi người thuê được phân bổ qua gắn thẻ để tài chính biết biên lợi nhuận thực của từng tài khoản, và khả năng quan sát gắn thẻ người thuê cho phép kỹ sư trực ca nói trong vài giây một cảnh báo là của một người thuê hay cả đội.

Chính phủ. Một nhà cung cấp nền tảng quốc gia lưu trữ nhiều cơ quan chính phủ như các người thuê riêng và coi cô lập là yêu cầu pháp lý, không phải sở thích. Luật nơi lưu trữ dữ liệu ghim dữ liệu của mỗi cơ quan vào các vùng trong nước, được thực thi bởi chính sách-dưới-dạng-mã chặn bất kỳ tài nguyên nào ở vùng không được phép (chương 3.11). Phân loại thúc đẩy mô hình: các cơ quan xử lý tài liệu nhạy cảm nhận các triển khai silo hoàn toàn trong các tài khoản riêng với ranh giới kiểm toán riêng, trong khi khối lượng công việc phân loại thấp hơn dùng chung một pool được quản trị. Mỗi cơ quan là một người thuê riêng với tích hợp danh tính, quy tắc lưu giữ và xuất, và dấu vết kiểm toán có phạm vi theo ranh giới của mình, để kiểm toán viên của một cơ quan không bao giờ thấy hoạt động của cơ quan khác. Chấm dứt tạo ra một bản xuất dữ liệu được chứng nhận và một việc xóa chứng minh được, vì các hồ sơ chịu luật hồ sơ công và riêng tư.

Luận chứng kinh doanh: động lực, ROI và TCO

Luận chứng kinh doanh cốt lõi của đa người thuê là biên lợi nhuận. Một mô hình đơn người thuê, nơi bạn triển khai một bản sao mới cho mỗi khách hàng, nghĩa là chi phí hạ tầng và vận hành tăng gần tuyến tính theo số khách hàng, và kỹ sư của bạn dành cả ngày để vá nhiều bản sao. Một mô hình đa người thuê chung phá vỡ liên kết đó: bạn vá một lần, mở rộng một hệ thống, và đóng gói khách hàng đủ dày để chi phí biên của người thuê kế tiếp tiến về không. Đó là điều cho phép một doanh nghiệp SaaS tăng doanh thu nhanh hơn chi phí nhiều, và là lý do nhà đầu tư cùng hội đồng quản trị coi một kiến trúc đa người thuê sạch là đại diện cho một công ty có thể mở rộng.

Lợi tức hiện ra ở ba nơi: đòn bẩy vận hành (một đội chạy cả đội hình), phân phối nhanh hơn (một bản sửa đến mọi người thuê cùng lúc, nên vận tốc không phân rã khi bạn thêm khách hàng), và tính tùy chọn về giá (một gói chung cho cái đuôi dài và một gói cô lập cao cấp cho doanh nghiệp, cả hai từ một cơ sở mã). Hãy đặt những điều này đối chiếu với các chi phí bạn phải tài trợ trung thực: kỹ thuật để xây cô lập người thuê được thực thi, hạn ngạch, tự động hóa vòng đời, và khả năng quan sát theo người thuê, cộng với kỷ luật để giữ ranh giới nguyên vẹn. Chi phí của việc làm sai là bất đối xứng và nghiêm trọng, vì một vụ xâm phạm dữ liệu xuyên người thuê đơn lẻ có thể kích hoạt tiền phạt quy định, khách hàng bỏ đi hàng loạt và thiệt hại danh tiếng làm nhỏ bé hạ tầng bạn tiết kiệm được nhờ chia sẻ. Hãy đóng khung lập luận với ban lãnh đạo là biên lợi nhuận và khả năng mở rộng ở mặt lợi và rủi ro sống còn ở mặt hại. Hãy neo thỏa thuận mức dịch vụ và các bảo đảm dữ liệu theo hợp đồng vào mô hình thuê bạn thực sự giao được, vì một lời hứa mà kiến trúc của bạn không giữ được là một trách nhiệm, không phải một thương vụ.

Phản mẫu và cạm bẫy

Giới hạn người thuê theo quy ước. Dựa vào lập trình viên nhớ bộ lọc người thuê trên mọi truy vấn, không có điểm tựa ở mức cơ sở dữ liệu hay tầng truy cập dữ liệu; một thiếu sót là một vụ xâm phạm.
Tin định danh người thuê do máy khách cung cấp. Chấp nhận người thuê từ đầu vào yêu cầu để cấp quyền thay vì suy ra từ danh tính đã xác thực, cho phép bên gọi xin dữ liệu của người khác.
Công việc nền không giới hạn. Công việc, bộ đệm, webhook và bản xuất mất ngữ cảnh người thuê vì ai đó chỉ giới hạn đường yêu cầu đồng bộ.
Nhánh rẽ mã theo người thuê. Làm trường hợp đặc biệt cho một khách hàng lớn trong đường mã cho đến khi bạn bảo trì nhiều sản phẩm phân kỳ dưới một tên và mọi thay đổi tốn gấp mười.
Không phòng thủ hàng xóm ồn ào. Chạy một pool chung không có hạn ngạch hay công bằng theo người thuê, nên người thuê đầu tiên tăng đột biến kéo sập mọi người.
Chấm dứt như chuyện nghĩ sau. Xây mà không có xuất dữ liệu và xóa chứng minh được, rồi thất bại với điều khoản thoát của khách hàng hay yêu cầu theo luật riêng tư vì lược đồ chung khiến việc trích xuất đau đớn.
Bay mù theo người thuê. Nhật ký, chỉ số và chi phí không có chiều người thuê, nên bạn không thể nói sự cố của ai hay người thuê nào không có lãi.

Mô hình trưởng thành

Mức 1, Khởi đầu: Đa người thuê được ứng biến và phản ứng. Sự tách biệt người thuê dựa vào bộ lọc viết tay không có điểm tựa, mô hình là một-cỡ-cho-tất-cả, không có hạn ngạch, tiếp nhận thủ công, và nhật ký cùng chi phí không mang chiều người thuê. Đội biết về hàng xóm ồn ào và suýt rò rỉ qua các sự cố.
Mức 2, Phát triển: Các thực hành cơ bản xuất hiện nhưng không nhất quán giữa các đội. Một mô hình thuê được chọn và ngữ cảnh người thuê được lan truyền qua đường yêu cầu chính, một điểm tựa ở mức cơ sở dữ liệu hay truy cập dữ liệu thực thi giới hạn trên các bảng lõi, và hạn ngạch cơ bản theo người thuê tồn tại. Tiếp nhận được tự động hóa một phần và nhật ký mang định danh người thuê, nhưng các đường nền, xuất, và phân bổ chi phí khác nhau giữa các dịch vụ và không được viết ra ở đâu.
Mức 3, Chuẩn hóa: Cách tiếp cận thuê được lập tài liệu và thực thi trong toàn tổ chức. Thuê theo bậc ánh xạ với giá, với một pool chung cho người thuê nhỏ và các triển khai cô lập cho người thuê doanh nghiệp và chịu quy định, giới hạn người thuê được thực thi theo chiều sâu và kiểm thử có chủ đích, hạn ngạch và lập lịch công bằng kiềm chế hàng xóm ồn ào, vòng đời người thuê bao gồm xuất và xóa chứng minh được được tự động hóa, và khả năng quan sát cùng chi phí được cắt theo người thuê. Mọi đội theo cùng một tiêu chuẩn thuê thay vì tiêu chuẩn riêng của mình.
Mức 4, Quản lý: Hệ sinh thái thuê được đo và kiểm soát theo các đường cơ sở. Cô lập, công bằng, độ trễ và chi phí theo người thuê được theo dõi như chỉ số với mục tiêu đã thống nhất: độ bao phủ kiểm thử xuyên người thuê, tỷ lệ vi phạm hạn ngạch và sự cố hàng xóm ồn ào, thời gian tiếp nhận và chấm dứt, và biên lợi nhuận theo người thuê được báo cáo theo đường cơ sở, và các quyết định nâng một người thuê giữa các bậc hay định giá lại một người thuê không có lãi được đưa ra dựa trên bằng chứng đó thay vì giai thoại. Sự phù hợp về nơi lưu trữ và phân loại được giám sát liên tục, và sự trôi khỏi tiêu chuẩn kích hoạt một phản ứng có tài liệu.
Mức 5, Điều phối: Thuê được cải thiện liên tục và tích hợp trong toàn tổ chức. Các ranh giới xuyên người thuê được thực hành qua các bài tập đội đỏ thường lệ, người thuê di chuyển giữa các bậc không thời gian ngừng khi họ lớn lên hoặc nhu cầu tuân thủ của họ thay đổi, biên lợi nhuận theo người thuê nuôi việc định giá và hoạch định năng lực, và quy tắc nơi lưu trữ cùng phân loại được thực thi bằng chính sách thay vì rà soát. Mô hình thích ứng khi hỗn hợp khách hàng và bức tranh quy định dịch chuyển, và các bài học nuôi sản phẩm, bảo mật và tài chính như một vòng lặp.

Ý tưởng để thảo luận

Mỗi bậc khách hàng của bạn hôm nay nằm ở đâu trên dải cô lập-so-với-hiệu quả, và có bậc nào ở sai mô hình so với các bảo đảm đã bán hoặc biên lợi nhuận bạn cần không?
Nếu bạn phải chứng minh với kiểm toán viên rằng người thuê A không thể truy cập dữ liệu người thuê B, bạn có thể đưa ra bằng chứng gì ngay bây giờ, và bao nhiêu trong đó là tự động so với được khẳng định?
Đường bất đồng bộ nào của bạn (công việc, bộ đệm, webhook, bản xuất, chỉ mục tìm kiếm) thiết lập lại ngữ cảnh người thuê, và đường nào chỉ thừa hưởng nó hoặc tin bên gọi?
Khi một người thuê vượt khỏi chia sẻ công bằng, bạn có một đường nâng được hỗ trợ, có định giá vào một triển khai bridge hoặc riêng, hay câu trả lời mặc định là một sự cố?
Bạn có thể quy chi phí hạ tầng cho từng người thuê đủ tốt để gọi tên khách hàng ít có lãi nhất, và điều đó có thay đổi cách bạn định giá không?
Với một người thuê chính phủ hay chịu quy định, bạn có thể thực thi nơi lưu trữ dữ liệu và cô lập theo phân loại bằng chính sách, và chấm dứt với bản xuất được chứng nhận cùng việc xóa chứng minh được không?

Những điểm cần ghi nhớ

Đa người thuê, một thể hiện phục vụ nhiều người thuê, là động cơ kinh tế của SaaS: nó điều khiển biên lợi nhuận của bạn, và đặt cô lập xuyên người thuê ở trung tâm kiến trúc của bạn.
Coi cô lập so với hiệu quả là một dải và phân bậc nó: đóng gói người thuê nhỏ trong một pool chung hiệu quả, cô lập người thuê lớn và chịu quy định trong các triển khai bridge hoặc silo mà họ sẽ trả tiền.
Đừng bao giờ để giới hạn người thuê dựa vào một bộ lọc viết tay; hãy thực thi nó theo chiều sâu bằng bảo mật mức hàng hoặc tầng truy cập dữ liệu, và kiểm thử ranh giới có chủ đích.
Lan truyền ngữ cảnh người thuê qua mọi yêu cầu, công việc, bộ đệm và nhật ký, và bảo vệ các đường bất đồng bộ nơi rò rỉ ẩn nấp.
Kiềm chế hàng xóm ồn ào bằng hạn ngạch theo người thuê, giới hạn tốc độ và lập lịch công bằng, và nâng những người thuê vượt khỏi pool thay vì để họ làm suy giảm nó.
Uốn sản phẩm bằng cấu hình theo người thuê, không phải mã theo người thuê, và biến vòng đời người thuê cùng khả năng quan sát và phân bổ chi phí theo người thuê thành hạng nhất.

Tài liệu tham khảo và đọc thêm

Tom Kwok, Thao Nguyen và Linh Lam, A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application (IEEE International Conference on Services Computing)
Frederick Chong và Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
Amazon Web Services, SaaS Lens, AWS Well-Architected Framework và SaaS Tenant Isolation Strategies
Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Centre)
Google Cloud, Architecture for Multi-tenant SaaS Applications
Cor-Paul Bezemer và Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? (Proceedings of the Joint ERCIM Workshop on Software Evolution)
The Open Web Application Security Project, OWASP Application Security Verification Standard (các yêu cầu kiểm soát truy cập và đa người thuê)
Martin Kleppmann, Designing Data-Intensive Applications (phân vùng, phân mảnh và cô lập dữ liệu)